Comments 240
Нецензурная лексика в заголовке это не слишком?
Вы правы, я лучше замажу часть слова. Однако это скорее маркетинговый ход. Я сам по образованию инженер и айтишник, и не отношусь ни к кому привратно, писал так скорее с целью привлечения внимания
Вы куда то торопитесь, пишете с ошибками, исправляете заголовки, наверное вы с вашими девопсами в противофазе:) вы импульсивный, а они наверное спокойные аки удавы и не любят суеты.
Если что, я такой же. И с педантичными сотрудниками часто в натянутых отношениях.
Я писал ее под ночь и вышла и правда не очень аккуратно. Если вы укажите на ошибки, буду очень признателен!
Люди не постоянны, я например сейчас уставший и несколько на надрыве делаю многие вещи, однако после хорошего сна последовательности в действиях и спокойствия гораздо больше
Теперь совсем другое дело! Вы заменили одну букву на звёздочку и слово перестало быть обсценной лексикой. Теперь никто не догадается, что там было написано!
На хабре большое количество статей, которые содержат в названии слово мудак или в описании слова похлеще. При этом я не называют devops мудаками и скорее статья на целена на то чтобы если кто-то их таковыми считает - перестали это делать
Однако если у вас есть комментарий как улучшить название, я буду только рад ему!
Я поправил название чтобы не задевать никого, что-то я сгоряча написал такое название
Поздравляю, у вас Devops обратно деградировал в замшелое сисадминство. А может, никогда и не эволюционировал :)
Это, впрочем, никак не отменяет того, что задачи должны быть сначала как следует описаны, а уж только потом взяты в работу. Если девопс-инженер не в состоянии из приехавшего от PMa потока сознания итеративно вылупить технически верный тикет - значит, нужен другой инженер, более высокого грейда (скажем, мидл).
А ведь, как уже было написано - так ведут себя попросту хреновые сисадмины, а уж девопсы они или нет - дело второе.
О, спасибо, я эту статью что-то пропустил когда серфил по хабру, добавлю на нее ссылку в свою
Была ли у вас такая ситуация? Если да, то как решали? (ну окромя ротации людей)
Вообще, для меня дико читать про описанное вами - я, конечно, видел места, где были какие-то точечные проблемы, но чтобы одновременно фигово было и с межкомандным взаимодействием, и с оформлением задач, и с документированием, и с ревью (это я про тот кривой конфиг, который как-то добрался до прода) - такого ещё не встречал.
У вас такой флеш-рояль, что я даже не знаю, что посоветовать тут всю систему менять надо, начиная с СТО.
Я такое наблюдал несколько раз, благо на текущем месте несколько иначе и многие идут на контакт, а devops даже с интересом заглядывает на встречи
Действительно здесь махровая проблема с процессами и зонами ответственности. Как по мне, это частично лечится переведом части девопсов в продуктивные команды, чтобы поменять их приоритеты на командоориентированные, оставив пару на платформе. Тогда они уже сами между собой договорятся в интересах продуктов и платформы. Но да, сверху должен быть тот, кто будет смазывать их общение и не даст перетянуть одеяло на себя ни одной из сторон
devops-ов нужно помещать в команды, с обязательным посещением стендапов - в этом случае все нормализуются. Они будут говорить, что тогда не будут двигаться инфраструктурные проекты. Тогда можно поделить на две части: ядро под инфраструктуру, но часть должна быть в полях и понимать проблемы команд, боль бизнеса, разработки, тестирования - заниматься автоматизацией и вовлечением разработчиков и тестировщиков в культуру devops. Яростно плюсую ky0, у вас нет devops-а, у вас классические сис.админы избегающие взаимодействия с командой.
PS Когда оказывался в вашей ситуации, всеми правдами и не правдами старался заполучить devops-а себе в команду и на стендапы.
Ага, спасибо за опыт. Я пробовал делать схоже, но каждый раз сталкивался с примерно следующей позицией - у них совершенно другие задачи, да они иногда делают задачи от команды, но в целом они работают для всех команд и на тем чтобы команды вообще могли работать. Поэтому нет, нельзя их помещать в команду, тем более как условный тимлид будет за ними присматривать?
Я пробовал делать схоже, но каждый раз сталкивался с примерно следующей позицией - у них совершенно другие задачи, да они иногда делают задачи от команды
Да, они так нередко говорят. Но вам нужно отделить собственно девопс от сисадминов. Девопс, это как раз непосредственно про поддержку разработки. Они должны быть частью девелоперской команды, и их продуктом должны быть те же самые релизы, новый доставленный пользователям функционал. Потому что если вы их отделите от девелоперов и посадите к сисадминам, у них и целевым продуктом будет то же самое, что у сисадминов - стабильная работающая инфраструктура. А стабильно работающая она бывает в том случае, когда изменения в ней происходят пореже, в идеале - вообще никогда. Поэтому девопс в команде сисадминов будет закручивать гайки для разработчиков по самое небалуй, препятствуя релизам. Отсюда и конфликты между девопсами и разрабами возникают.
Хмм, спасибо за пищу для размышлений! Но точно ли devops в таком случае должен быть отдельный инженер? А не сами разработчики например?
Если это удобно делать разработчикам, то почему бы и нет? Девопс возник как способ освободить разработчиков от непрофильной деятельности, например, командировок.
А не сами разработчики например?
Если они хотят и могут - вполне. Другое дело, что это хоть и смежные, но несколько разные скиллы, и далеко не всегда сочетаются в одном инженере.
Проблема с девопсами в том, что они (хорошие девопсы) должны иметь в бекграунде и опыт разработки и опыт запуска / эксплуатации причём под нагрузкой. Обычно это уставшие (выгоревшие) разработчики. Обычные девы часто дальше "а у меня на компе всё работает" не мыслят и к продакшену их подпускать надо очень осторожно. Тем более, если дев замотивирован не особо грамотным менеджером выпускать фичи побыстрее. Нужен человек, который менеджера может отшить, именно поэтому девопс в другой юрисдикции.
Узкое место в том, что коммунальная инфраструктура должна строиться с учётом интересов всех команд и быть максимально гомогенной, прозрачной и управляемой и нужно хорошо в ней разбираться, чтобы переделывать и развивать её адекватным способом. Если просто дать рули разработчикам отдельных продуктов, то обычно она очень быстро потеряет все эти 3 качества, в том числе разделившись на много слабосовместимых контуров с разными подходами и технологиями. И по моему скромному опыту проблема усугубляется тем, что среднее время жизни разработчика на проекте около 1,5 лет и участники изменений из команд достаточно быстро меняются, а весь техдолг остаётся, накапливаясь. Как в переписке правильно заметили, часть девопсовой ответственности должна включать релизы продуктов, чтобы они не окукливались в обеспечении стабильности инфры и прикладов, каковая проще всего достигается остановкой изменений.
но часть должна быть в полях и понимать проблемы команд, боль бизнеса, разработки, тестирования - заниматься автоматизацией
Наоборот. Девопсы и есть 'Поля' Т.е. эксплуатация. (В статье, впрочем, смешано - есть инфраструктура разработки и есть инфраструктура эксплуатации того, что разработали. Это не одно и то же и не всегда одни и те же девопсы и даже организации).
И это разработчикам нужно бывать в эксплуатации и/или поддержке инфраструктуры хотя бы иногда. Тогда они будут понимать, какую боль они создают для окружающих.
Позволю себе немножко не согласиться. Поток сознания от PM - это повод найти нормального PM, который общается не потоком сознания, а чем-то более вразумительный и приближенным к делам, компании, продукту и процессу.
Поток сознания может выливать только заказчик, который платит деньги. И только это может оправдывать такое поведение. Все остальные в рамках компании - это сотрудники осваивающие деньги клиентов и в идеале приносящие этим самым клиентам пользу. Но вот когда менеджер начинает вести себя как клиент, получая такую же зарплату и не оплачивая труд других из своего кармана. То это просто воровство ресурсов компании временем других сотрудников, которые не обязаны разбирать такие потоки. Для этого и есть менеджер, а если он не может то бизнес-аналитик. Который переводит с потоков на понятный технический язык. Технари должны получить задачу и выполнить ее, а не переводить поток сознания во что-то человеко-разборчивое. Это весьма непростое и стоящее многих нервов занятие.
Я с вами полностью согласен! Однако я привожу пример того, когда заведение и исчерпыющее описание задачи ставится поверх приоритета разбора с проблемами. Я прекрасно понимаю такую позицию и часто делаю также, когда ко мне приходит другая команда, в работу просто не попадут не описанные задачи. Да и мои задачи другие не возьмут. Но если у нас серьезная проблема, которая сильно бьет, то в целом можно и по голосовому сообщению работать
Что такое голосовое сообщение? Вы голосовые как в тг отправляете?
Простите, я просто уже не в первый раз тут в ветке читаю об этом, не могу понять.
Без баланса никуда.
С одной стороны можно потратить рабочий день на описание задачи (да? можно? удивительно :)) и не делать работу, с другой стороны голосовые распоряжения по задаче могут быть взяты в работу - но их придется переделывать. Нет гарантии, что технический исполнитель поймет слова правильно, будет делать корректно (особо интересно если исполнителей будет два или три) и постановка задачи приведет к тому, что условный менеджер будет в ужасе что все делают не то и не так. Зато не писали задачу текстом и все только голосом. =)
Из хорошей практики - договорились с активным менеджером оформить задание не словами (а ему надо быстро и очень, он чуть ли не каждые 15 минут звонил и интересовался как дела и чем помочь) но двумя предложениями в жире. Я на самом деле сам написал =) и сам уточнил правильно ли я понял. Сошлись на том, что он мне не звонит 4 часа и через 4 часа спрашивает как дела (спойлер - все ок =) ). Я не знаю каких ему усилий далось не писать и не звонить =) но фокусировка на задаче дала свои плоды и все было сделано в согласованное время.
На текущий момент менеджер балдеет :) ставит задачу в жире текстом (сам пишет, по своему по менеджерски) потом звонит и просит сроки решения и спрашивает нас что не понятно в его задаче.
Коммуникация отличная получилась и все всех хвалят =))
Главное - баланс. Имхо. :)
Поток сознания от PM - это повод найти нормального PM, который общается не потоком сознания
РМ'а посередине проекта, как правило, так вот просто не заменишь. Особенно если он уже пустил корни в коммуникации с заказчиком. Но зато его можно (и нужно) заставить систематизировать свои требования.
Резануло глаз, поэтому позволю себе заметить, что DevOps, тот самый, который не человек, а методология, это больше всего про общение и совместное непрерывное нанесение ценностей работодателю и его пользователям, а не цепочка "должен, должен, должен", обёрнутая в ITIL с согласованными сроками рассмотрения.
Как люди в IT видят друг друга.жпг если коротко.
Я читаю и прям в сердце
Ну что могу сказать: фу таким быть. Если мы откроем этот ящик пандоры и пойдем чихвостить своих коллег, то на хабре места живого не останется. И я вас уверяю, полоскать менеджеров будут в 100 раз больше, чем кого-либо еще. Потому как каждому технарю есть, что про них рассказать.
Я не чихвосчу своих коллег. Сама тема безусловно провокационная, однако если ее не поднимать, то она так и останется на уровне "так исторически сложилось". Честно говоря было даже страшновато ее писать
Дорогой, автор.) Как вы точно заметили девопсов мало). Вы в какой-то детской позиции, что раз вас заставляют писать тикет, то это возводит кого-то в какой-то ранг выше вас, но на самом деле это простая гигиена и защита от менеджеров, чтобы не гонять сообщения в тгшечки вместо работы. Пишите нормальные тикеты, которые дают ответы, а не запускают недельные уточнения и будет вам счастье))
Меня точно также мало. И зачему я не говорю что тикеты писать не надо, я сам писал изрядные портянки для devops по документированию алертов и скрипты для графаны. Я больше подсвечиваю ситуацию, что грамотное оформление тикетов, призванное по идее для структурности и удобства начинает использоваться для отгораживания
Вы же сами написали, что DevOps - выделенная команда, а не проектная. У них таких проектов как ваш может быть довольно много. Т.е. они не могут работать в линейной иерархии, как обычный проект. Там просто нет выхода как работать по матрице. А в случае матричной структуры, без тикетов - никак.
Вот есть у них, например, 50 проектов. И возможно ваш - далеко не самый приоритетный. Если дать возможность влиять напрямую, то вы его "пропихнете". Именно поэтому, вводится изоляция команды DevOps и тикеты. Только с помощью тикетов и их приоритезации, можно не поехать кукухой в этом хаосе. И да, вам неприятно, ваши личные метрики идут на дно. Но для компании в целом, возможно, это было меньшим злом и выгоднее, возможно были 5 других более важных и денежных проектов, которые взлетели за ваш счёт.
Это всё конечно теория и домыслы как должно быть. Конкретный кейс может быть вовсе не таким счастливым.
Прекрасно понимаю, однако на тот момент это был приоритет топ 1 за которым и CTO присматривал
50 клиентских + куча внутренних (потому, что проекты сущестуют не в вакууме), и да, многие менеджеры кладут на договорённости, устраивают чайка-менеджмент, капают на мозг. Работа превращается в 16 часов в день + в выходные, притом без премий, доплат и отпусков.
Более того, менеджеры ещё любят лезть в те процессы, в которых ничего не понимают. Им главное, как-то, ну хоть как-то, а виноват потом будет спец, который не послал менеджера и не сделал на день дольше, но нормально (обычно это устраняет типа 90% проблем).
" грамотное оформление тикетов " используется исключительно для структурирования и полноты информации. Если вы считаете, что это вас отгораживает, посмотрите на паспорт, водительские права, СНИЛС, ИНН.
Замечу что в приведенных мной примерах требовалось быстрое участие и когда возникают проблемы, кажется тикет оформить задним числом стоит
Проблемы которые надо решить вчера с девопсом решается точно так же как и с бабкой на регистратуре и с начальником-самодуром - обычным уважительным и доброжелательным образом, а не обвинением в том, что он м**дак, который отгородился тикетами))
Я понимаю ваше возмущение. На хабре столько постов какие менеджеры ополоумевшие безумцы
Повторюсь, я сознательно решил назвать статью так, но внутри нее я именно иронично разбираю проблему. Честно говоря не люблю так щитпостить, но решил ради дискуссии так написать, иначе статья бы затерялась в просторах хабра
Никакого возмущения, только опыт) То что кто-то что-то не успел и надо сделать быстро - вина не девопса, который тикетами отгородился, а менеджера) Это отдельная больная тема для вас, я уверен, но я с радостью почитаю ваш следующий пост о том, как вы воспитали девопсов и наладили коммуникации)
Честно говоря не очень понимаю позицию, почему в случае проблем, которые влияют на продукт и цели компании отгораживание бюрократией это нормально?
Там история длиннее, конфиг вообще не моя команда должна была править и тд, но акцент больше на другом, что в случае проблем они стали перекрываться неуместной бюрократией
Нормально потому, что вы не видите дальше собственного носа и не понимаете, что не вся работа связана лично с вами и крутится вокруг вас.
Вообще говоря, половина работы может быть вообще не связана с текущими проектами и продуктами и тоже положительно влияет на компанию.
Каждый менеджер мнит себя центром мира, тяне одеяло на себя, кладёт на процессы и вообще думае, что занимается самым важным делом, на планете земля.
Бюрократия это как барьер. Когда вместо задрачивания мозга в телегу, вас надо создать тикет, это уже отсеивает часть инфошума для специалиста (который ещё может прыгать между контекстами несколько раз в час). Когда вас тикет могут развернуть, это ещё снижает желание схалтурить.
Просто привычка - менеджер никогда не скажет, что он хреново работает, он будет винить всех вокруг. А бюрократия это способ ткнуть его носом. Как в госках. Ну и прикрыть себя.
Если б менеджеры вели себя иначе, способ взаимодействия был бы иной.
Печально что у вас был такой опыт, по крайней мере то что я замечаю, стараюсь находиться в позиции чтобы работа делалась благодаря мне, а не вопреки. При этом я не идеален, меня заносит и иногда мы сильно спорим с разработчиками или devops
Ага, это как тебе пишут в чат с просьбой, ты в ответ просишь оформить тикет, а человек внезапно просто навсегда исчезает.... Возможно даже из компании.
ты в ответ просишь оформить тикет, а человек внезапно просто навсегда исчезает.
не нужно было вскрывать эту тему. (ц)
Отчасти из-за этого меня многие считают токсичным кстати (похоже на кейс поднятый в теме). Если ко мне прийти с задачей, она не попадет в команду сразу, я буду узнавать что за задача, в чем суть, почему это важно, где полное описание в тикете и тд. Если важно для другой команды, почему в целом важно для компании
Я не воспитываю devops и вообще кого бы то ни было. Учусь работать совместно и устраняю непонимание, пожалуй
Сам пост рефлексия, а не жалобы на хабр на текущее место работы, здесь благо такого не наблюдается
Поддержали это мнение: на ночь глядя выплеснули поток, с руганью в заголовке. ¯\_(ツ)_/¯
Однако нюанс ситуации в том, что баг возник из-за кривого конфига Nginx, который правился по хорошему на лету.
Для этого нужны dev, uat, staging окружения
Если бы devops-инженеры не коммуницировали через сервис деск и вызов дежурного через команду в слаке, а потом не требовали детальной постановки;
Не законченная фраза. Мысль не понятна.
У нас достаточно жестко проседали сроки и я долго не мог понять в чем дело
Ошибка руководства что не спросили почему так долго
Отправился бить челом к devops и оказывается наши выделенные раннеры больше не наши, а выдленные, ибо так им удобнее.
Надо было сразу спрашивать почему так долго. Выделенные скорее всего из-за денег.
На этом история застряла где-то на полгода.
DevOps тут причем? Мысль не раскрыта
Их день начинается с проверки Slack-бота дежурных
Проверки алертов, а не Slack-бота дежурных
Основные задачи - контролировать свободное место на дисках серверов, следить за успешным прохождением бэкапов, проверять корректность создания и масштабирования нод в ClickHouse и других кластерах
Основная задача - автоматизация
Для тестовых стендов действует жёсткий принцип: только DevOps могут создать или свичнуть окружение по заранее прописанным правилам
Это почему? можно сделать review окружение в новом namespace в kubernetes и установить в него приложение из feature ветки
Документация - это гигантская папка .md-файлов во внутренней вики, где все описано максимально кратко
Непонятно это плохо или хорошо. Раскройте мысль.
Общение почти исключительно через Jira-таски с детальными описаниями - неполные заявки сразу возвращают на доработку
А здесь что не так?
Еженедельные 20-минутные стендапы для планирования крупных работ по переездам, вне их встреч обсуждения считаются отвлечением
DevOps тут не причем. От человека зависит
Любая попытка изменить конфиги или Vault воспринимается как угроза стабильности и этоневашазонаотвественности
какие конфиги ? приложения?
Slack-каналы - закрытая экосистема для обсуждения только релевантных вопросов вопросов. Обычно есть группы Infra, Core, Alerts и бот для дежурств
А здесь что не так?
Вместо фото аватарки и на созвонах не включают камеру;
DevOps тут не причем. От человека зависит
Крайне рады в целом если созвона не будет или возможности с него уйти. Если звать на созвон, на котором они считают что не нужны - идут жаловаться CTO
DevOps тут не причем. От человека зависит
Иногда это доходит до того, что даже тимлидам разработчиков запрещают участвовать в обсуждениях или вносить изменения, ибо работает не трогай. Такая жесткая защита естественно создаёт ощущение особого статуса у DevOps.
Непонятно кто запрещает
Масло в огонь подливает то что часто (хотя возможно только в моем опыте было такое) у DevOps достаточно детализированный технический роадмап миграций на новые версии БД, настройки датацентров и тд., а у команд это отдано на самотек.
Так это плюс DevOps инженеров.
Но вместе с тем это только усиливает их замкнутость и создаёт дополнительный барьер между DevOps и остальными командами. Да и просто они бесить начинают. В итоге мы вступаем в цикл: devops изолируются→на них раздражаются→devops изолируются
Больше технических деталей пожалуйста и меньше эмоций
DevOps вырос из противостояния: разработка гнала фичи, админы держали прод на замке.
Что значит админы держали прод на замке?
Метрики успеха для DevOps обычно предельно просты:
аптайм (uptime)
среднее время до восстановления (MTTR)
иногда - скорость отката к предыдущей версии (если гитлаб на premium-плане, можно удобно мерить)
Где вы такое прочитали? У вас неполная и неправильное мнение о метриках успеха DevOps
Успех оценивается не по тому, насколько удобно работать другим командам, а по отсутствию аварий и стабильности сервисов.
Это у вас в соглашениях о разработке написано? или откуда вы это взяли?
Формализованные процессы воспринимаются как “бюрократия”, которую проще обойти, чем внедрять.
Какие имеете ввиду Формализованные процессы?
DevOps на стабильности инфраструктуры
Вы перепутали. Это SRE фокусируется стабильности
Каждое изменение для DevOps - это буквально failure, риск падения стабильности, поэтому у Ops-команды естественное стремление замедлить и тщательнее контролировать выпуски.
Если при выкатке новой версии вы получаете failure, то это проблема команды в первую очередь. Команда может нажать на кнопку rollback (helm rollback)
DevOps-культура!!!! зародилась в инженерной среде, а там ценят автоматизацию и сниженение участия человека, поэтому традиционные менеджерские практики (регламенты, миты, отчеты) воспринимаются как бюрократическая шляпа.
Где вы это прочитали?
Обычно девопсы - это бывшие сисадмины или разработчики, не горящие энтузиазмом от Scrum-ритуалов или документации. Если проектный менеджер настойчиво требует от DevOps-команды следовать формальным процессам это типично провоцирует агрессию. Интровертивные инженеры часто избегают чрезмерной коммуникации, а тут их заставляют “играть по правилам” Agile, ага, щас.
DevOps тут не причем. От человека зависит
Поскольку работа DevOps требует изрядного уровня технического погружения, многие инженеры скептически относятся к людям, не обладающим таким же уровнем техглубины. Если менеджер проекта не отличает виртуализацию от контейнеризации, DevOps-инженеры невольно начинают считать его бесполезным посредником
Пытаюсь понять связь между названием статьи и этим текстом и не нахожу. Раскройте мысль
Пока DevOps-барьер стоит непроходимым, Lead Time и Time-to-Market медленно, но верно растут → конкуренты выкатывают новые фичи быстрее, а мы зависаем в бесконечных согласованиях
Возможно это только у вас.
Для проектных менеджеров это превращается в марафон эскалаций и попыток пробиться сквозь джиру
То есть вы говорить devops инженеру, вот это срочная задача, потом через пол часа говорите, текущую задачу бросай, нужно другую задачу сделать?
В командах накапливается раздражение: каждое новое обращение превращается в мини-конфликт, где уже не задача обсуждается, а воюют за территорию и ресурсы
Похоже что у вас там аврал или просто много конфликтов, а DevOps тут не причем.
Итого: DevOps у вас не внедрен. Похоже что у вас там аврал или просто много конфликтов
Ух, сложно будет комментировать (много), но я постараюсь на все ответить!
Для этого нужны dev, uat, staging окружения
Тут на самом деле печаль, на прошлых местах работы были фича-окружения и прод. Без промежуточных, ибо сложно-дорого-куча микросервисов
А вот это вообще root cause 90% провалом на проектах. Когда хотят "скраежопить", абсолютно не понимая чем это обернется.
Не хотим держать свои сервера, CapEx - зло, переходим на облака, мы любим OpEx. И по налогам приятнее и денег сразу столько не нужно. А потом прибегает менеджер. Ой, что-то там такой счёт выставили из облаков. А давайте не будем сервера держать по выходным. Но отчёты по тестам в понедельник я хочу. А сервера по выходным не включайте. Это вместо того, чтобы настроить нормально автостарт и автостоп для окружений. Но менеджер же не хочет знать. Это же для него технические детали, хотя тут речь про деньги.
А так да, мир такой - все что просто, стоит дополнительных расходов. Хочешь сэкономить - придётся освоить довольно сложные схемы и автоматизацию.
Если и дорого и слишком сложно, то зачем вообще начинать проект? Можно же совсем ничего не делать.
Мне кажется или у вас позиция что менеджеры во всем виноваты и проблема в них?
менеджеры обычно неплохо понимают язык денег, когда фичи оцениваются деньгами на выбор: тогда они сами бегают и выбивают бюджеты или смиряются. Поэтому умение аллоцировать стоимость ресурсов на проекты часто здорово облегчает коммуникации после прохождения менеджерами этапа принятия.
Запуск нового проекта в проде, при грамотном планировании, позволяет его запустить без пользователей и походить в боевой прод тестерам и всем, кому надо, прежде чем туда пускать клиентов.
Не законченная фраза. Мысль не понятна.
Дописал, спасибо за внимательное прочтение!
Ошибка руководства что не спросили почему так долго
Спрашивали, просто не поднимался вопрос и никто на это особо не обращал внимание. Когда долго работаешь глаз замыливается
Ладно, я не потянул все комментировать, прошу прощения. Меня крайне интересует последняя мысль "DevOps у вас не внедрен". Можете ее раскрыть пожалуйста?
Фразу "DevOps у вас не внедрен" уже не уберу. Фраза некорректна. Нет признаков чтобы сказать внедрен или не внедрен DevOps. Скорее уровни зрелости DevOps в компании - https://habr.com/ru/articles/727568/
Уверен, каждый кто общался с Девопсами понимает, что Гилфойл из Кремниевая долина это не художественный образ, а каждый первый Девопсер…
Ну почему, я это скорее для красного словца. Часто отличные ребята, которые просто оказались в такой ситуации и начинают возникать противоречия
скорее каждый, кто никогда не общался с инфраструктурщиками думает именно так.
уверен, что каждый, кто приходил к стоматологу с идеями как поставить себе титановые челюсти для разгрызания тросов знает, какие эти стоматологи негодяи и токсики
Бесполезные передасты
Это я про то как выглядят проектные менеджеры часто.
это пять!
ув. автор! не останавливайтесь, пишите. если принять иронию и небольшое преувеличение, то изнанка этой 'кухни' показана здорово.
Если менеджер проекта не отличает виртуализацию от контейнеризации, DevOps-инженеры невольно начинают считать его бесполезным посредником
что не так?
А менеджер должен? Зачем ему это?
Разбираться-то в азах специальности? Да нет, конечно, зачем? Сегодня сникерсами торговал, завтра строительством атомного реактора управлять будет.
Это как если бы Калашников не умел стрелять.
Руководитель, который не понимает работу подчинённого, не способен поставить ему задачу.
Почему для менеджера вдруг виртуализация и контейнеризация азы специальности? Это безусловно важная тема, но не необходимая для понимая контекста. Я искренее не понимаю почему в вашей картине мира условный проджект или продакт должен разбраться во всех нюансах
Почему для менеджера вдруг виртуализация и контейнеризация азы специальности?
Нет такой специальности "менеджер". Есть инженер или лицо без специального образования на позиции менеджера проекта. Если проектом управляет лицо без образования, это уже само по себе повод для беспокойства. Если оно при этом фактически не разбирается в предмете на уровне второго курса, то это однозначный крах.
Нюансы – это точный синтаксис параметров загрузки ядра Xen. А речь идёт именно об азах.
Это ваше мнение. Однако вполне себе есть целое направление менеджмент, высшее, узкая специализация, как менеджмент программных проектов, международные сертификации и тд. Можно безусловно считать всех проджектов, продактов и тд проходимцами, но реальность такова что это вполне себе профессии, существующие ни одни десяток лет
Можно поинтересоваться кодом специальности "менеджмент программных проектов"?
5.38.03. и под ними есть специализации. Я заканчивал СПбПУ по направлению инновационный менеджмент программных продуктов по отраслям и сферам экономики
Справка гугла:
Основные аспекты инновационного менеджмента программных продуктов:
Определение потребностей отраслей:
Анализ специфических нужд и вызовов различных отраслей и сфер экономики, таких как здравоохранение, финансы, логистика, розничная торговля и т.д.
Разработка инновационных решений:
Применение передовых технологий и подходов для создания программных продуктов, которые отвечают уникальным требованиям каждой отрасли
Управление инновационным процессом:
Организация разработки, тестирования, внедрения и поддержки программных продуктов с учетом принципов инновационного менеджмента
Оценка и мониторинг результатов:
Анализ эффективности инновационных программных продуктов и их влияния на бизнес-процессы и показатели компании
Какое отношение это имеет к управлению проектами? Это работа с продуктами.
Я выше обратил про себя внимание, что вы почему-то ставите в один ряд управление проектами и продуктами, но тогда не стал возражать, потому что это было не по основной теме обсуждения. Но вообще-то это разные вещи. Продукт существует ради своих потребительских свойств, то есть своей интегральной ценности в глазах покупателей, а проект – ради функциональных характеристик, то есть конкретных заданных технических параметров.
Простите, что врываюсь в вашу уютную дискуссию.
Но вообще-то это разные вещи. Продукт существует ради своих потребительских свойств, то есть своей интегральной ценности в глазах покупателей, а проект – ради функциональных характеристик, то есть конкретных заданных технических параметров.
Продукт – более широкое понимание, проект – более узкое. Менеджмент вообще, и проекты, и продукты, существуют не только в IT и существовали задолго до IT как такового, и будут существовать после. Как пример, новая модель автомобиля – это продукт. "Внутри" этого продукта есть множество разных проектов. Иногда очень сильно разных, как, например, разработка тормозной системы и разработка UI бортовой системы.
При этом сам по себе отдельно взятый проект также может являть своим результатом вполне себе законченный продукт. Так, наш автомобиль содержит книжечку - руководство пользователя, удалённо контролируется через мобильное приложение, а авторизованные дилеры имеют доступ к онлайн ресурсу, содержащему каталог деталей и предписания по выполнению сервисных процедур. Эта книжка, это приложение и этот сайт – вполне себе можно рассматривать как отдельные продукты в экосистеме "вышестоящего" продукта – новой модели автомобиля.
Поэтому, отличие между менеджером продукта и менеджером проекта в большей степени иерархическое, чем фактическое. По сути оба из них делают одну и ту же работу, но на разных уровнях детализации с разной зоной охвата.
Менеджер продукта в принципе не может достаточно глубоко разбираться одновременно и в пошиве кресел, и в вёрстке печатных изданий, и в программировании контроллера внутри ЭБУ двигателя, и проч.
А насчёт существования - всё это существует только лишь для того, чтоб коммерческая организация получила прибыль от продажи продукта.
А насчёт существования - всё это существует только лишь для того, чтоб коммерческая организация получила прибыль от продажи продукта.
Вы в целом всё верно излагаете, о с продуктовой точки зрения. В то время как совершенно необязательно получать прибыль именно от продажи продукта.
В частности, если рассматривать автомобильное производство, как проект, то результатом этого проекта является автомобильный завод, а не автомобиль.
А многие организации (и среди них подавляющее большинство ведущих сложные проекты) вообще не имеют продуктов в основном объёме реализации. Они получают деньги за услуги по решению задач заказчика.
Я лично имею более чем 30-летний опыт проектной разработки и определённые признанные обществом успехи в этой области, но за свою жизнь не участвовал в разработке ни одного продукта.
Хотя некоторые авторы относят услуги к продуктам, но это просто софистика.
Менеджер продукта в принципе не может достаточно глубоко разбираться одновременно и в пошиве кресел, и в вёрстке печатных изданий, и в программировании контроллера внутри ЭБУ двигателя, и проч.
Некто Киитиро Тойода, по образованию инженер-механик, считал, что руководить производством автомобиля может только тот, кто лично прошёл путь от рабочего на конвейере (цитирую не дословно, но по смыслу). К слову, инженерное образование дал ему отец, основавший Тойоту.
Директор АвтоВАЗа, с другой стороны, имеет экономическое образование. Поэтому Тойота терпит убытки, а АвтоВАЗ процветает. Но езжу я на Тойоте. В этом отличие продукта от проекта.
Некто Киитиро Тойода, по образованию инженер-механик, считал, что руководить производством автомобиля может только тот, кто лично прошёл путь от рабочего на конвейере
Не пытаясь поставить под сомнение авторитет господина Тойоды, замечу лишь, что если вы попытаетесь пройти его путь в современном мире, то с большой вероятностью столкнётесь с проблемой "войти в айти в nn+ лет" и получите тонну гневных комментариев в стиле "крутил пол-жизни гайки на конвейере, вот и крути дальше, ишь выискался тут, пойдём за ряд Тейлора перетрём". Современное IT совсем не то же, что во времена Митника, Возняка и бума доткомов. Постоянные дискуссии на Хабре "стоит ли брать джуна колхозана немытого без красного диплома Физтеха и золота на олимпиаде по математике" лишь подтверждают. Путь от простого рабочего до управленческих высот стал очень длинным.
В частности, если рассматривать автомобильное производство, как проект, то результатом этого проекта является автомобильный завод, а не автомобиль.
Это вы говорите верно. Но завод строится не как самоцель, не для того, чтобы быть. Завод – для того, чтобы производить продукт, который будет, продаваясь, приносить прибыль.
Иногда же сам завод является продуктом. Но здесь, опять же, возвращаясь к моему комментарию, вопрос иерархии и точки зрения. Для Альберта Кана завод – продукт, для И.В. Сталина продукт – автомобиль ГАЗ.
Они получают деньги за услуги по решению задач заказчика.
Это лишь вопрос терминологии. Лично я под продуктом понимаю некоторое законченное решение. Оно не обязательно материально, как автомобиль, но оно самодостаточно и отделимо от окружения, как приложение, или сайт, или фреймворк, например.
И снова это вопрос ракурса. Если производитель автомобилей поручает на аутсорс специализированной компании разработку программной оболочки - интерфейса для мультимедиа, эта оболочка – услуга или продукт? Я не знаю однозначного ответа.
Не пытаясь поставить под сомнение авторитет господина Тойоды, замечу лишь, что если вы попытаетесь пройти его путь в современном мире, то с большой вероятностью столкнётесь с проблемой "войти в айти в nn+ лет" и получите тонну гневных комментариев в стиле "крутил пол-жизни гайки на конвейере, вот и крути дальше, ишь выискался тут, пойдём за ряд Тейлора перетрём"
Наоборот. Его путь очень даже приветствуется в IT. Он учился на инженера, а тем временем работал на заводе, крутя гайки (почти так же, кстати, начинал Экклстоун). Лучшие студенты-айтишники так и делают, работают джуниорами параллельно с учёбой, чтобы, получив диплом, быть уже твёрдыми миддлами.
И снова это вопрос ракурса. Если производитель автомобилей поручает на аутсорс специализированной компании разработку программной оболочки - интерфейса для мультимедиа, эта оболочка – услуга или продукт? Я не знаю однозначного ответа.
Коль скоро требования к ней выдвигает заказчик, беря на себя соответствующие финансовые обязательства, то это услуга.
Лично я под продуктом понимаю некоторое законченное решение.
Обычно принято считать, что результат труда сам по себе не является продуктом. Он становится продуктом тогда, когда обращается на свободном рынке.
Он учился на инженера, а тем временем работал на заводе, крутя гайки (почти так же, кстати, начинал Экклстоун). Лучшие студенты-айтишники так и делают, работают джуниорами параллельно с учёбой, чтобы, получив диплом, быть уже твёрдыми миддлами.
Вы серьёзно не видите разницы между кручением гаек на заводе и работой разработчиком, пусть и с приставкой "младший"? Иными словами, между синим и белым воротничком?
Мнение г-на Тойоды имеет вообще противоположный смысл относительно вашей его трактовки. И, будучи выходцем из очень богатой семьи, Тойда не пошёл в джуны, как вы говорите. Он пошёл крутить гайки, т.е. на место простого рабочего. И говорил он о том, что перед тем, как примерять под себя уютное офисное кресло, и вершить судьбы людей, сперва выйди на улицу и побудь обычным человеком. То есть, экстраполируя на программистов, сперва постой за конвейером, собирая эти самые сервера, а уже потом изобретай программные продукты, которые будут изменять жизнь вот этих самых парней в цехах.
работают джуниорами параллельно с учёбой
Ну это тоже очень спорный момент, как и кем можно работать, если ты целый день сидишь на парах (и кому вообще такой джун нужен, при нынешних-то требованиях к ним). Или наоборот, как и чему учиться, если ты целый день на работе, а универ прогуливаешь.
Обычно принято считать, что результат труда сам по себе не является продуктом. Он становится продуктом тогда, когда обращается на свободном рынке.
А если свободного рынка нет в принципе, как с СССР или КНДР? А если свободный рынок есть, но продукт на этом рынке не обращается, как ракета с ядерной боеголовкой? Финансовые инструменты обращаются на свободном рынке – это продукт? Ядро Linux – это продукт? А драйвер видеокарты?
Вы серьёзно не видите разницы между кручением гаек на заводе и работой разработчиком, пусть и с приставкой "младший"?
Серьёзно не вижу. Работа младшего разработчика является неквалифицированным трудом, не требует специального образования.
Иными словами, между синим и белым воротничком?
Воротнички тут вообще не причём. Если они в офисе работают (т.е. в непроизводящей сфере), то оба белые, а если на производстве, то оба синие.
А если свободного рынка нет в принципе, как с СССР или КНДР?
Нет и продуктов. Есть только овеществленный результат труда в виде товаров групп А и Б. Вы экономику социализма не изучали, что ли?
А если свободный рынок есть, но продукт на этом рынке не обращается, как ракета с ядерной боеголовкой?
Ракета не является продуктом, а представляет собой (относительно небольшую) часть услуги по выполнению гособоронзаказа. В более общем плане - по обеспечению безопасности государства. Она ничем не отличается по сути от службы офицера, откуда и возникает понятие военно-промышленного комплекса.
Финансовые инструменты обращаются на свободном рынке – это продукт?
Да.
Ядро Linux – это продукт?
Нет.
А драйвер видеокарты?
Нет.
Вот чтобы не сыпаться на таких вопросах, и предназначено инженерное образование.
Работа младшего разработчика является неквалифицированным трудом, не требует специального образования.
И даже вакансию показать можете, где человека, закончившего 9 классов школы и умеющего нажать кнопку включения системника, берут джуном?
Первая же попавшаяся вакансия:
Обязанности:
Front-end разработка на ts, react, rtk, react hook form, TanStack query;
Back-end разработка на ts, node, express, sequelize, knex;
CodeReview коллег;
Работа с legacy кодом, рефакторинг.
Hard skill:
Typescript, Node.js, ExpressJS, React + Redux, Sequilize или другие ORM;
Уверенные знания: ES6/7, SQL, HTML/CSS;
Базовое знание bash, docker;
Знание английского языка на уровне чтения технической документации.
Это неквалифицированный труд? Типа дворника, ага?
Есть только овеществленный результат труда в виде товаров групп А и Б.
То есть, продукт. Даже показатель такой был в СССР: валовый общественный продукт, потовый суммировал все произведённые продукты и оказанные услуги.
Ракета не является продуктом
Является. Более того, они продаются. Примерно так же, как и кирпичи или телевизоры. Только не на свободном рынке и не каждому желающему.
Ядро Linux - это продукт.
Драйвер видеокарты - это продукт.
Финансовый инструмент - нет.
Инженерное образование и инженерия к вопросам менеджмента и экономики ровным счётом никакого отношения не имеет.
Это неквалифицированный труд? Типа дворника, ага?
Конечно. Даже среднее специальное образование не требуется.
Рабочего - квантового оптика в миллион раз сложнее найти или обучить, чем такого программиста.
Ракета не является продуктом
Является. Более того, они продаются. Примерно так же, как и кирпичи или телевизоры. Только не на свободном рынке и не каждому желающему.
Вы не в теме. Причём, в отличие от вас, я участвовал в разработке ракет и понимаю, как устроена эта деятельность. На кирпичи и телевизоры это совсем не похоже. Например, сама по себе продажа ракет убыточна.
Конечно. Даже среднее специальное образование не требуется.
Ссылку на вакансию в студию, молю лишь об одном!
Так вы ж сами привели. Таких вакансий большинство. И бо́льшая часть людей, работающих программистами, не имеет специального программистского образования.
Так вы ж сами привели.
Нет, в этой вакансии, где я привёл, требуется профильное высшее образование и приведённый перечень скиллов широко выходит за рамки программы общеобразовательной школы: там не преподают ни JS, ни React, на технический английский.
Таких вакансий большинство.
Большинство не надо, хотя бы одну ссылочку, пожалуйста.
Мойка полов тоже выходит за рамки программы общеобразовательной школы. А уж тем более вождение машины. Знание языков программирования и фреймворков не требует профессионального образования и, между прочим, не является его предметом. Это обычный трудовой навык рабочей специальности. Станок с ЧПУ в сто раз сложнее, чем ваш джаваскрипт в объёме формошлёпства.
Про технический английский, выходящий за школьную программу, не смешите даже.
Мойка полов тоже выходит за рамки программы общеобразовательной школы
Нет, не выходит.
Знание языков программирования и фреймворков не требует профессионального образования
Ваши личные инсинуации. Раз не требуется профессионального образования, значит, человек уже из школы выходит с этими знаниями. В какой школе у нас преподают языки программирования и фреймворки?
К счастью, у нас есть трудовое законодательство и отраслевые стандарты. Открываем "ОК 010-2014 (МСКЗ-08). Общероссийский классификатор занятий" и внимательно читаем:
В ОКЗ принято четыре уровня квалификации. Первый уровень квалификации соответствует основному общему образованию и среднему общему образованию, второй уровень квалификации - профессиональному обучению; третий - среднему профессиональному образованию; четвертый - высшему образованию и ученой степени.
...
Основная группа 9. Неквалифицированные рабочие
Неквалифицированные рабочие выполняют простые и стандартные задачи, которые могут требовать использования ручных инструментов и существенных физических усилий. Большинство занятий данной основной группы требуют квалификации, соответствующей первому уровню.
Ручной физический труд с использованием ручного инструмента. Никаких фреймворков и никакого английского.
между прочим, не является его предметом
Очень даже является. Если своего диплома нет, откройте образовательные стандарты и почитайте. Лично у меня была куча разнообразных "программирований" в универе, от Pascal до PHP.
Станок с ЧПУ в сто раз сложнее, чем ваш джаваскрипт в объёме формошлёпства
Сразу видно, со станками ЧПУ не знакомы.
Основная группа 9. Неквалифицированные рабочие
А не надо передёргивать, вот и всё. Я написал, что труд большинства программистов является неквалифицированным и не требующим специального образования. А не то, что это именно самый нижний слой – неквалифицированные рабочие. С точки зрения классификации, конечно, рядовые программисты являются квалифицированными рабочими.
Раз не требуется профессионального образования, значит, человек уже из школы выходит с этими знаниями
Я этого не говорил. Человек из обычной средней школы не выходит со знаниями ни по одной специальности, в том числе и рабочей. Но не любое приобретение знаний делает человека квалифицированным специалистом.
Очень даже является. Если своего диплома нет, откройте образовательные стандарты и почитайте. Лично у меня была куча разнообразных "программирований" в универе, от Pascal до PHP.
У меня диплом кафедры Математического обеспечения и применения ЭВМ ЛЭТИ по специальности 220400 "Программное обеспечение вычислительной техники и автоматизированных систем". Поскольку учебно-методический совет по этой специальности находился на нашей кафедре, то есть именно она определяла национальный стандарт обучения, то я уверен, что преподавалась эта специальность там правильно. Изучения языков программирования в качестве самостоятельной темы обучения у нас не было. Более того, бывали такие слова: "На следующей неделе у вас начинается производственная практика, там надо будет писать программы на Фортране, с которым мы с вами раньше не работали; если кто не знает этого языка, до понедельника изучите, пожалуйста" (конечно, тут речь о Фортране IV, который не большой и не сложный язык, но, тем не менее, суть подхода ясна).
Можно, поинтересоваться, кто выдал вам диплом и какие в нём указаны предметы, которые вы интерпретируете как "Pascal" или "PHP"?
Ручной физический труд с использованием ручного инструмента. Никаких фреймворков и никакого английского.
Ну это у нас колониального неквалифицированного труда мало. Но если, например, в эскорт пойти работать, то там знание языков может оказаться необходимым на определённом уровне. Или натуральную клубнику собирать вот в Финляндию некоторые ездили в 90-е.
А не надо передёргивать, вот и всё. Я написал, что труд большинства программистов является неквалифицированным и не требующим специального образования. А не то, что это именно самый нижний слой – неквалифицированные рабочие.
Передёргиваете как раз вы, используя устоявшиеся термины не в их общеизвестном значении, а в каком-то вашем собственном. Квалификация работника - это чётко определённый термин.
И да, вы написали именно это, я ещё переспросил: "неквалифицированный труд, это в смысле как у дворника?" - и вы ответили "конечно, даже образования не надо". А теперь начинаете выстраивать дополнительные подпорки и юлить вокруг них.
Человек из обычной средней школы не выходит со знаниями ни по одной специальности, в том числе и рабочей.
Если человек не выходит из школы со знаниями, значит, он их приобретает посредством дальнейшего получения образования - профессионального, среднего, высшего и проч. Если же специального образования не надо - значит, достаточно того, что дают в школе. Третьего здесь нет, знания – не живот, сами по себе не растут. TypeScript в школе не преподают, значит, нужно дополнительно учиться = получать дальнейшее образование.
Но не любое приобретение знаний делает человека квалифицированным специалистом.
Снова открываем стандарт и читаем, там прямо про это есть. Квалификация - это термин, имеющий четкую трактовку. А то, что пишете вы - вольное сочинение где-то около заданной темы.
Программное обеспечение вычислительной техники и автоматизированных систем
Какое совпадение, у меня тоже.
Изучения языков программирования в качестве самостоятельной темы
Во-первых, таки было, на первом курсе. Во-вторых, опять начинаем передёргивать. Про самостоятельную тему речь не шла, потому что в принципе язык программирования не является самостоятельной темой. У плотников тоже нет изучения рубанка в качестве самостоятельной темы, однако пользоваться рубанком их таки учат. В ВУЗе нет самостоятельной темы "язык Java" или там "язык SQL", однако языкам учат. Так же, как нет и самостоятельной темы "ряд Тейлора", но, вы не поверите, есть математика, в которой это учат.
Ну, в общем, я понял. Ссылки на вакансию не будет.
Передёргиваете как раз вы, используя устоявшиеся термины не в их общеизвестном значении, а в каком-то вашем собственном. Квалификация работника - это чётко определённый термин.
И да, вы написали именно это, я ещё переспросил: "неквалифицированный труд, это в смысле как у дворника?" - и вы ответили "конечно, даже образования не надо".
Правильно, труд рабочего в общем является неквалифицированным. Если сравнивать его с другими видами труда, например, техника или инженера. Но всё верно в определённом масштабе. Если под микроскопом рассмотреть только рабочих, то среди них тоже есть более и менее квалифицированный труд. Труд квалифицированного рабочего не является квалифицированным трудом в общем рассмотрении.
Если человек не выходит из школы со знаниями, значит, он их приобретает посредством дальнейшего получения образования - профессионального, среднего, высшего и проч. Если же специального образования не надо - значит, достаточно того, что дают в школе. Третьего здесь нет, знания – не живот, сами по себе не растут. TypeScript в школе не преподают, значит, нужно дополнительно учиться = получать дальнейшее образование.
Обучение не равно образованию, тем более профессиональному.
Для работы водителем, безусловно, надо научиться водить машину. Ещё и обучиться в автошколе и на права сдать государству экзамен (чего в случае программистов-рабочих нет). Но это не является профессиональным образованием.
Во-первых, таки было, на первом курсе.
На первом курсе мы в дисциплине "конструирование программ" разбирали синтаксис и семантику языка Паскаль. Но не с целью научиться программировать на Паскале (этому, кстати, нас учили в школе), а с целью понять, как вообще устроены программы и языки программирования.
Так же, как нет и самостоятельной темы "ряд Тейлора", но, вы не поверите, есть математика, в которой это учат.
Хороший пример, показывающий ошибочность вашего подхода. Без ряда Тейлора крайне затруднительно понять и использовать матанализ. Без любого отдельно взятого языка программирования изучение и практическое занятие программированием не представляет труда. Хотя, конечно, культурный минимум полезно знать, но не более того.
Вы полезли в какие-то дикие софистические дебри. Не нужно придумывать свои значения и свои толкования для вещей, уже без вас ясно, чётко, общепринято определённых.
Программист не является рабочим, даже начинающий. Квалификация любого рабочего, даже самого квалифицированного, намного ниже квалификации любого программиста, даже самого начинающего.
Обучение не равно образованию, тем более профессиональному
См. выше. Для вас, может, и не равно, для остальных: "образование - единый целенаправленный процесс воспитания и обучения" (ФЗ "Об образовании", ст.2).
Но это не является профессиональным образованием.
Является. Автошкола является образовательным учреждением с соответствующей лицензией. Окончив её, человек получает право работать по профессии "водитель". Обратимся снова к законодательству, а не к выдумкам: "профессиональное образование - вид образования, который направлен на приобретение ... знаний, умений, навыков и формирование компетенции определенных уровня и объема, позволяющих вести профессиональную деятельность в определенной сфере и (или) выполнять работу по конкретным профессии или специальности".
Вы в своей демагогии дошли уже до того, что противоречите не только здравому смыслу, но и напрямую законодательству: "В соответствии со статьей 26 Федерального закона № 196-ФЗ обучение водителей транспортных средств является профессиональным обучением. Согласно пункту 12 статьи 2 Федерального закона № 273-ФЗ профессиональное обучение - это вид образования, ... " (Письмо МинОбрНауки РФ от 18 сентября 2015 г. № АК-2726/06).
Но не с целью научиться
Да без разницы, как лично вы воспринимаете цели тех или иных составляющих образовательного процесса. Вы соврали, утверждая, что изучение языков программирования не является предметом профессионального образования.
Без любого отдельно взятого языка программирования изучение и практическое занятие программированием не представляет труда
Разумеется, если писать "программы" на доске мелом в псевдокоде русскими словами. А так, снова софистика. Любой не означает каждый.
Вы полезли в какие-то дикие софистические дебри. Не нужно придумывать свои значения и свои толкования для вещей, уже без вас ясно, чётко, общепринято определённых.
Это вы пишете софизмы и банальности. Ясно, что при помощи бамбуковой палки можно заставить хорошо мыть пол любого здорового человека, а хорошо программировать даже простейшие программы удастся заставить не любого, в силу природных особенностей мышления. Это, однако, не делает массовое программирование квалифицированным трудом специалистов. Просто не каждый способен к определённому виду неквалифицированного труда. Опять уместна аналогия с эскортом (вообще, если глядеть на вещи без предубеждений, аналогии между трудом программиста и проститутки в ряде случаев очень точны).
Обучение не равно образованию, тем более профессиональному
См. выше. Для вас, может, и не равно, для остальных: "образование - единый целенаправленный процесс воспитания и обучения" (ФЗ "Об образовании", ст.2).
И как из этого вы делаете вывод о том, что образование равно обучению? Странно для человека с высшим программистким так работать с высказываниями.
Вы в своей демагогии дошли уже до того, что противоречите не только здравому смыслу, но и напрямую законодательству: "В соответствии со статьей 26 Федерального закона № 196-ФЗ обучение водителей транспортных средств является профессиональным обучением.
А профессиональное обучение не равно профессиональному образованию.
Вы соврали, утверждая, что изучение языков программирования не является предметом профессионального образования.
Естественно, не является предметом. Как из того, что язык Паскаль используется для иллюстрации процесса конструирования программ, вам могло прийти в голову, что он сам – предмет этого курса? У вас какая оценка по КП была?
Если вы изучаете течение заболевания чумой на мышах, то это не значит, что мыши являются предметом изучения.
Вам не мешало бы внимательнее отнестись к значению слов русского языка, прежде чем пытаться хамить.
Без любого отдельно взятого языка программирования изучение и практическое занятие программированием не представляет труда
Разумеется, если писать "программы" на доске мелом в псевдокоде русскими словами. А так, снова софистика. Любой не означает каждый.
Так именно поэтому конкретный язык неважен, и знаете вы джаваскрипт или нет – ничего не значит в характеристике вашей профессиональной квалификации, как программиста.
Точнее, помню, был один драйвер видеокарты в виде продукта, SDD for OS/2. Но он недолго просуществовал в таком качестве, авторы продали исходный код IBM, и он продуктом быть перестал.
Для меня виртуализация такой же нюанс как для вас условный KPI
Разница между нами в том, что я знаю и что такое KPI, и что такое виртуализация, и что такое контейнеризация. Кстати, я сдавал на сертификат PMI – там всего обучения в лучшем случае на месяц для человека с техническим образованием.
продуктовый менеджер не должен уметь в инфраструктуру: его задача быстро разрабатывать и катить продукт, ценный бизнесу. А для технических знаний есть отдельные технические люди
А зачем нужен менеджер, который не понимает, с чем он работает? Это буквально задача менеджера - организовывать работу. А как он будет её организовывать, если ничего не понимает?
Вы говорите о всех нюансах, но тут нет всех нюансов. ут буквально отсутствие базовых знаний.
Да должен. Он не должен это уметь делать. Но знать разницу между двумя словами и разницу в стоимости и применимости для его проекта знать обязан. Контейнеризация дешевле в использовании, как по эксплуатации, так и банально по стоимости у облаков. Но, не все проекты можно делать на ней.
Вы видимо не видели, что будет происходить если команда разработки/выделенный человек начинает делать изменения в "инфраструктуре" самостоятельно, но "без бюрократии". В конечном итоге будет хаус, выделенные мощности, будут "переиспользоваться" под другие проекты, часть будет висеть в "вечном" статусе ожидания, или "а вдруг понадобится". Не понятно будет, что критически важное, что нужно бекапить, что нет. Какие креды, кто владелец сервера, что на нем крутится и тд.
Что касается тикетов с точным описанием задачи, то почему под условную фичу, вы расписываете таск для разработки, а под инфру вы считаете, что это не нужно? Если девопс/инженер выполнит задачу как он понял из-за неполного/неточного описания, а в результате релиз не полетит, кто будет виноват?
В конечном итоге будет хаус,
Хаус? Доктор? ))
Я не говорю что нужен хаос, я лишь описываю случай когда бюрократией отгораживаются от решения проблем и это лишь один из примеров
Я тикеты всем ставлю одинаково подробно, как минимум описывая цель зачем это делается и критерии приемки с важным контекстом
Видимо, недостаточно подробно для ваших коллег из "DevOps", раз они возвращают вам заявки.
Интересно увидеть пример вашей задачи в Jira и что написали когда вернули на доработку
Я не говорю что нужен хаос, я лишь описываю случай когда бюрократией отгораживаются от решения проблем и это лишь один из примеров
Бюрократия не на пустом месте возникает. Мы после пары простоев (я девопс да) по вине разработки, тоже внедрили бюрократию и нудные проверки идеи "фиганем миграции на проде в час-пик". Раньше прокатывало "мамой клянусь", потом мамы кончились. Бюрократия выросла, простой продового окружения снизился. Почти все довольны.
Прекрасно понимаю, сам стопаю релизы без ролл бэка и грамотного подхода к миграции. Правда вот сегодня был конфьюз, я настаивал на ближайшем релизе нового микросервиса и не принимал обоснования вида "ну там доделать еще надо", но когда влезли и выяснили что мы токены рефрешим не совсем корректно сейчас, без проблем сдвинули и план выкатки стали еще больше детализировать на все случаи
Ковбойские катки позволительны, но только при инфраструктуре, позволяющей тестировать их процентом трафика со всем соответствующими метриками. Нет инфраструктуры - значит очень строгий процесс деплоймента и тестирования, независимо от того, на сколько там пригорает у бизнеса.
Это то чего хочется добиться в целом не ради выкатки с плеча, а ради минимизации инцидентов и возможности быстрой проверки, работает ли оно вообще. Зацепить за минуту 10 пользователей не так страшно, если максимум что случится у них это инвалидация кеша
По опыту вот эти вот быстрые проверки на продах регулярно становятся причиной авралов, потому и реакция такая: все регулярно бьют себя пяткой в грудь "да ничего страшного, я сто раз так дома на ноуте делал" и оно регулярно же от такого сыпется из-за разных неучтённых моментов и банального человеческого фактора. Отдайте ответственность за доступность вашего прода вашему командному девопсу и тогда вы сами сможете управлять рисками и подобными тестами. Но хорошей практикой является выстраивание отлаженной цепочки релизов DEV->UAT->PROD, которую вы в любой момент можете быстро прогнать: тогда у вас сохраняется управляемость и появляется скорость.
Многое вполне может работать и не быть описанным, и довольно долго, когда это всё тянет один человек. Была система, которую на нескольких контурах вывозил разработчик и на другой работе были системы, где разработка стандартизировала подход к проектам, а девопс стандартизировал подходы, но не до маразма. Второй держится дольше. В условиях, когда ПМ или руководитель команды прилетал чаечкой тяжело было и аналитикам, и QA, и поддержке, а инфраструктура получала весь список негатива, как последняя по течению
все эти проблемы сильно проще решаются, когда в компании есть общая курилка.
мне кажется там в неформальной обстановке у нас решались вопросы за 5-10 минут, которые через тикеты шли бы куда дольше.
Смешно как то стало даже. Как девопс могу сказать, проблема с тем кто этих людей набирал, и кто ими руководит, вот и все.
Возможно. Я не прям чтобы очень знаком с хабром, но почему ваш комментарий был выделен отдельно я мог его отклонить или одобрить? Как это работает?
Не в курсе )
Окей. А вы получается были в схожей ситуации?
я давно в ит, по сути везде решает:
1. Хороший начальник. Простой пример, 6 лет работал в крупном ресторанном холдинге, все было супергут, все решали наперед, сменился начальник и все пошло под откос, тк ему плевать на кадры и он не в зуб ногой в матчасти
2. Кадры, часто встречал сисадминов, которые не понимают что их задача не быть "самыми умными", а обеспечивать работу, и не просто работу, а то как это ожидают (в пределах разумного, тут возвращаемся к начальнику, он решает политические вопросы). Принцип я сделал какнибудь, оно работает, и вам нужно прочитать инструкцию на 100 страниц, а то что вы просто хотите кнопку, так это ваши проблемы.
3. Интерес, часто встречаю людей, которым попросту не интересна их работа)
4. Коммуникация, она должна быть и должна быть выстроенна понимающими людми.
Как не крути, но работаем мы все за деньги, а эти деньги должны откуда-то браться, в разработке это пресловутый ci/cd, быстрее разработка, быстрее ттм, мы на коне, у конторы есть деньги => у нас есть зп и премии. Для того чтоб это работало, как раз и есть инженеры, которые должны быть проводниками команды разработки в инфраструктуру, и делать (в пределах разумного, тут возвращаемся к начальнику, он решает политические вопросы) эту самую разработку комфортной. По сути инженеры и разработчики это винтики одного механизма, суть которого выкатывать фичи и зарабатывать деньги). Для этого и нужно общение, миты и прочее, чтоб все были в курсе что происходит и не выпадали сильно из контекста.
Возможно мне везло с местами работы, а скорее всего так и есть. Я работал и 1 с несколькими командами, и командой девопс с несколькими проектами, в маленьких интеграторах, в крупном банке, подрабатываю на некоторых проектах. Гл всегда придерживаюсь философии девопс, и считаю что моя работа закончена, только когда продукт закрыт, т.е. снят с прома, до этого момента, я, разработчики и тестировщики 1 команда, задача которых постоянно развавать этот самый продукт.
У меня нет контекста именно по сабжу, т.к. не понятно, какая численность там отдела инженеров, сколько инфры, сколько команд разработки на эту инфру и отдел инженеров и т.п. Я просто описал то, что видел сам. Лично для меня, девопс это не про - был админом с виртуалками, стал девопсом с трубами и контейнерами, это про изменение непосредственно подхода, и самой роли инженера.
Я не буду писать про регламенты, зоны ответственности и вещи в этом духе, это все везде индивидуально, и выстраевается непосредственно руководителями команд, на основе общих договоренностей. Если это не работает, то видимо договориться не смогли)
Как мы докатились до жизни такой, что DevOps это отдельные пафосные инженеры
Тут все зависит от команды, DevOps в принципе не при чем. Между любыми изолированными, но жестко связанными частями будет расти недоверие. К примеру, я работал в одной компании над Node.js приложением, команда была распределенная, почти по всем частям света — часть в США, часть в Европе и часть в России. Для удобства менеджер устраивал отдельные созвоны с частью из США и России, т.е. мы никогда не общались с ребятами из США, но кодовая база была общей, случались казусы и примерно также росло недоверие.
Отдельный DevOps-отдел, отсутствие общей ответственности, дефицит коммуникации и поддержка сверху без баланса – это приводит к тому, что сервисная команда обособляется и начинает смотреть свысока на остальных, а те отвечают ей недоверием и неприязнью.
А нет хорошего решения. Все равно есть общая инфрастуктура, кто ей занимается? Плюс, привязанный к проекту девопс быстро становится круглосуточным дежурным по инфре данной команды, а потом - обновляет резюме. Особенно весело, когда днем ты привязан к команде, а ночью, во время дежурства, отвечаешь за всю инфру компании. В том числе и незнакомую из других проектов. Поэтому или надо 2 отдела, или один общий.
У нас достаточно жестко проседали сроки и я долго не мог понять в чем дело, пока на одной из встреч QA не пожаловались на то что сборки собираются медленно. Я открыл гитлаб и что я вижу - пайплайн тестовой сборки идет в среднем 35 минут. Отправился бить челом к devops и оказывается наши выделенные раннеры больше не наши, а общие, ибо так им удобнее.
Приходит менеджер и говорит - надо быстро. Приходит СТО / управляющих расходами и говорит - снижаем расходы. Приходится выбирать не в пользу быстроты сборок.
Для тестовых стендов действует жёсткий принцип: только DevOps могут создать или свичнуть окружение по заранее прописанным правилам
Вы не представляете, какое количество раработчиков/тестеров не компетентны в администрировании и какую дичь они могут накрутить, а потом затребовать это в прод, ведь они это накрутили быстро и самостоятельно в тесте.
Знаете, в чем проблеме? В том, что у вас все отделы не общаются между собой. И считают других чудаками. Вместо решения этих вопросов, вы воюете друг с другом, распыляя силы. Два отдела не знают специфику работы друг друга, но уже обвиняют других в бюрократии и нежелании идти навстречу.
Если бы мог поставил бы миллион лайков! Да, зрите в корень и ровно для того чтобы люди задумались об этом, написал эту статью
А как это работает у вас? Очень любопытен опыт, если был по бороьбе со схожими проблемами
У нас отдельно команды разработки и отдельно девопс-отдел общий. Днем каждый из нас поглядывает одним глазом на "свои" проекты, но в целом, все - универсальные солдаты. Дальше есть ночные дежурства, и там уже ты за все вообще отвечаешь. Удобно тем, что ночью фичи никто не катает, тонкую специфику проекта знать не надо, а днем - есть знающий проект. Плюс, опять же, ночью поднимают и ответственного за упавший/проблемный сервис разработчика.
Еще в отделе по сути 2 руководителя - техлид и тимлид, через них удобно договариваться именно между отделами. Есть много дружеских и неформальных связей, многое решается напрямую, но для этого было проделано много работы. Раньше и у нас было "разрабы козлы" и "инфра козлы", но в какой-то момент это парализует работу. Изменения были сверху, с СТО. Он сумел запрячь все отделы в единую упряжку.
Но, пример бюрократии. Просят сделать миграцию на проде в базе, которая обрабатывает платежи. Или удалить индексы лишние, которых там прорва. Говорят, что все проверили. Мы, как инфра, выполняем запрос и оказывется, индекс был критически нужен, и на 2 часа пользователи столкнулись ну не с простоем прода, но с задержками, пока индекс в базе обратно строился. Потом ситуация через неделю повторилась - и после этого появилась бюрократия, углубленные тесты на копии продовой базы, планы отката, планы работ, согласования. Слишком дорого выходят такие простои.
Добавьте пожалуйста в статью технические детали:
Используются ли облачные провайдеры или свое железо?
Используется ли Kubernetes?
Если используется Kubernetes, то какой? самосбор или managed решение?
Используется ли платный GitLab ?
Какие CI/CD инструменты используются для автоматизации сборки и деплоя?
Какие инструменты мониторинга и логирования применяются в продакшене?
Есть ли метрики Dora?
Как часто происходят релизы?
Какие метрики отслеживаются для оценки производительности приложений?
Используется ли helm?
Как организован incident management?
Пишите ли постмортемы?
Соотношение кол-ва devops инженеров к разработчикам?
Может ли разработчик сделать самостоятельно review стенд?
Уфф, я тут писал по опыту нескольких предыдущих компаний. Но могу по памяти написать (если что не в курсе всего и могу ошибаться)
1. Облачные провайдеры на прошлом, на позапрошлом свое железо
2. Да
3. Managed
4. Нет. бесплатный on-premise
5. Gitlab ci/cd, немного argo ci иногда
6. ELK стек и был краем датадог
7. Нет
8. Раз в 3-4 недели
9. Речь про сборки? Или скажем например про мобилку? Могу рассказать про крешрейт, mtbi, перфоманс и тд
10. Вроде нет
11. Был под конец на прошлом месте стандартный кусок ITSM про пост-мортемы и дежурства , на позапрошлом не было
12. Да
1) Как может быть managed kubernetes, если вы облака не используете?
4) Вот список фич gitlab premium, которые могли бы закрыть часть проблем из статьи:
• Merge Request Analytics - детальная аналитика кода, метрики производительности - что то вроде DORA метрик
• Advanced Search - глобальный поиск по коду, коммитам, issues
• Push Rules - продвинутые правила для коммитов и веток
• Approval Rules - обязательные аппрувы от конкретных людей/групп
6) У вашей компании есть деньги на дорогой ELK и датадог, а на еще одного devops инженера денег нет.
9) Речь не бекенд, фронтенд
10) а oncall/pagerduty или аналог используется?
Соотношение кол-ва devops инженеров к разработчикам?
Может ли разработчик сделать самостоятельно review стенд?
У вас микросервисы или монолит?
Компания относится к банкам или финансам? Есть ли персональные или банковские данные?
Как я и говорил, все точно не помню
1. Там где было облако был менеджед
4. Да, про DORA знаю, а вот про аналитику MR слышу впервые, спасибо за рекомендацию!
6. Получается так
9. Дефолтные вещи с крашрейтом, перфомансом, инцидент рейтом и тд
10. Не припомню
Соотношение кол-ва devops инженеров к разработчикам?
Ту сложно, но думаю в районе 1 на 15
Может ли разработчик сделать самостоятельно review стенд?
В одном месте да, в другом нет
У вас микросервисы или монолит?
Микросервисы
Компания относится к банкам или финансам? Есть ли персональные или банковские данные?
В предыдущем случае к финтеху
Я вообще эникей фактически, отношения к разработке не имею, работаю на "предприятии" и половину написанного не понял естественно. НО вот вам взгляд считай со стороны - выглядит опус так, что это просто излагание частного случая и проблема локальная, особо не проецируемая на другие коллективы.
Наверно надо руководство ногтем потереть, вдруг татарин прячется именно там(с)
Если бы devops-инженеры не коммуницировали через сервис деск и вызов дежурного через команду в слаке, а потом не требовали детальной постановки, то сроки не были бы настолько безможно сорваны (1.5 дня на решение проблемы);
А каким образом тогда предлагаете работать команде DevOps? Дать личный контакт девопса в тг, чтобы его ддосили вопросами в личку в любое время дня и ночи? Моя практика показывает, что есть разработчики и руководители разработки, которые любят поработать вечерами и ночами и если у них есть личный контакт девопса - не стесняясь пишут ему в 23.00 с проблемой невыкатки сервиса в stage. pre-production и тд. У девопсов есть и ифраструктурные задачи внутри отдела, которые не связаны с процессом разработки. Как их выполнять переключаясь на задачу со срочностью "критично" от менеджера, где в описание скриншот ошибки и больше ничего? Потратить свои 20-30 минут времени, чтобы понять о чем вообще речь идет? Почему-то менеджеры и разработчики очень дорожат своим временем, но при этом часто не уважают время девопсов.
Основные задачи - контролировать свободное место на дисках серверов
Весело читать, что Вы считаете (напрашивается вывод о том, что разработка тоже) это главной задачей девопса, раз указали её первой. Возможно, проблема в вашей команде кроется где-то рядом.
Вместо фото аватарки и на созвонах не включают камеру
Соглашусь с комментатором выше, что это личное желание человека, а не проблема девопса, да и как это влияет на рабочие процессы - непонятно.
Крайне рады в целом если созвона не будет или возможности с него уйти
А кто не рад? Только те, у кого работа - ходить на созвоны.
Если менеджер проекта не отличает виртуализацию от контейнеризации, DevOps-инженеры невольно начинают считать его бесполезным посредником
Тут не соглашусь, никто не требует таких глубоких знаний от менеджера, но понимать что такое ОС Linux и как работает Интернет я считаю менеджер должен, в противном случае коммуникация по какой-либо проблеме действительно превращается в ад.
Рекомендации в конце статьи отличные, только вот есть проблема, что бОльший процент менеджеров и разработчиков не хочет вникать в инфраструктурные вопросы: на презентации не ходит, либо ходит и не слушает, документацию предоставленную девопсами не читает, вопросы по ней не задает, в тикете в поле "Тип запроса" пишут "Инцидент", а тикет о том, что надо новый сервис развернуть. Понятно, что всё разнится от команды к команде, я сам работал и с менеджерами и разработчиками, которые интересуются, как, что и где работает, читают доку от девопсов, умеют выстраивать общение и взаимодействие - в таких здоровых командах здорово работать, проблемы решаются моментально. Работал и с токсичными командами, где любой пук и чих в приложении - все стрелки на девопсов, бежим жаловаться СТО на девопсов. Так что исходя из Вашей статьи либо Вам не повезло с девопсами, либо девопсам не повезло с Вами ;)
Очень солидный и обстоятельный комментарий! Спасибо. Я думаю нам не повезло друг с другом в вопросах коммуникаций и они вполне себе решились не портя впечатлений друг о друге. Поэтому и решил написать эту статью
Интересно ещё, а аватарка на Хабре вместо фото это тоже ориентир на то, что человек ЧСВ, или все же нет?
Господи, какая ахинея.
Из текста явно видна ситуация, что автор пытался примерить корону "менеджера по менеджменту", но был поставлен на место грамотным CTO: "1-3 штуки инженеров", "повадки", "Ощущение "пальцев веером", даже приписал свои собственные фобии всем: "любые попытки вмешательства воспринимаются как угроза, а дистанция между DevOps и остальными командами приводит к напряжённости и недоверию", "Интровертивные инженеры"...
Я - не CTO, я просто руковожу разными лидами в крупной компании. :)
Итак, по порядку.
"Общение почти исключительно через Jira-таски с детальными описаниями - неполные заявки сразу возвращают на доработку".
Да, так как именно PM имеют привычку, бросить на ходу какой-то кусок инфы, или пару слов в чат. Я даже не говорю о том, что человек может быть в тот момент занят - понятия DoR/цифровой след изобрели явно не для них."Еженедельные 20-минутные стендапы для планирования крупных работ по переездам, вне их встреч обсуждения считаются отвлечением"
А с чего вдруг автор (PM, судя по всему) решил, что он задаёт темп команде DevOps? Или он занимается их тайм-менеджментом?"Любая попытка изменить конфиги или Vault воспринимается как угроза стабильности и этоневашазонаотвественности"
Какие-то личные фобии автора."Slack-каналы - закрытая экосистема для обсуждения только релевантных вопросов. Обычно есть группы Infra, Core, Alerts и бот для дежурств"
И что же автора (PM) тут смущает? То, что ему некуда кидать кусок инфы в известном одному только ему формате?"Вместо фото аватарки и на созвонах не включают камеру;"
И что дальше? Автор, если бы PM попробовал бы в таком ключе обратиться к моему человеку, его бы ждал разговор короткий, но не факт, что приятный. Но конструктивный. Может быть, ваша работа - торговать лицом, но кто-то должен заниматься и архитектурно/инженерно/техническими работами."Крайне рады в целом если созвона не будет или возможности с него уйти. Если звать на созвон, на котором они считают что не нужны - идут жаловаться CTO"
И будут правы, и будет прав CTO, когда в конце месяца подаст руководству сводку со стоимостью трудозатрат на ненужные созвоны.
Вывод: автор, не "многие" думают, что DevOps - Гилфойл (кстати, классный, высокомотивированный и увлечённый специалист), просто вы сами - Бахман.
Понавылазило блин менеджерья в последние годы, которые понаслушались инфоцыган про то, как внедрение модных метрик, показателей и абревиатур сразу "запустит бизнес в космос". И "писают" в уши руководству, рассказывая, что они вот-вот сейчас все зарешают, и сделают компанию самой богатой в мире. Руководство обычно тоже из "альтернативных", которые "мы каждую минуту теряем миллионы, но на новогодние/майские удачно всем отдохнуть".
Не раскрыта тема "как мы дошли до жизни такой", где стоимость создания и владения инфраструктурой может в разы превыщать стоимость ПО, для которого, собственно, вся эта инфраструктура и существует.
Ух, кстати хороший комментарий, эту точку зрения не раскыл. Можно ваш попросить чуть больше накинуть на этот счет?
Тут несколько направлений, например:
распределенная архитектура ПО на порядок более дорога в разработке, развертывании и сопровождении, чем централизованная. Однако мало кого заботят даже простые обоснования такого выбора
облачная инфраструктура легко масштабируется, но стоимость владения в разы превышает on premises аналог. Однако, см. предыдущий пункт, каждый стартап считает, что завтра у него будет миллион запросов в секунду
"по умолчанию" используются "бесплатные" компоненты, прежде всего СУБД. Отсутствие знания продвинутых коммерческих продуктов приводит к раннему переходу на горизонтальное масштабирование и в итоге, многократно большим затратам на поддержку, несмотря на первоначальную экономию на лицензиях. Простой пример, производительность SQL Server примерно на порядок выше PostgreSQL (на CRUD ниже), там где можно обойтись одним-двумя узлами, придется делать десять реплик.
засилье Питона на бэкенде, производительность которого ниже на порядок даже Java, удивительным образом совмещается с заявлениями о высокой нагруженности.
Уххх, сильное напоминание пред-предыдущее место. На текущем у нас вместо бесплатной постгри кокроач, мне нравится
А как быстро масштабироваться в случае он премиса, если действительно смогли дать большой трафик?
На счёт MSSQL vs postgress можно побольше деталей? Мы как раз наконец недавно пристрелили последний MSSQL и вздохнули свободней, так как и руки развязали, и косты уменьшили, и производительность подняли. Базы не петабайтные конечно, но и не совсем детские.
А что у вас за продукт? Просто на mssql обычно достаточно редко задумываются о переходе
Довольно популярный тревел. Проблема MSSQL в первую очередь - дорогая горизонтальная масштабируемость. В результате базы омоналичиваются, обрастают годовыми кольцами, со всеми вытекающими. Сам то движок мощный, но не дающий ничего такого, что оправдывало бы косты, по крайней мере на "обычных" объёмах.
Что именно дороже в горизонтальной масштабируемости у SQL Server за вычетом того, что узлов потребуется в разы меньше?
Лицензия стоит заметных денег. Сам факт, что нужно выбивать заметный бюджет под новые инстансы сковывает руки по архитектуре и начинаешь обвешиваться слоями вокруг SQL, лишь бы этот вопрос не поднимать.
Ну вот с чего потребуется в разы больше инстансов постгреса? Очень сильно от профиля нагрузки зависит. Далеко не всегда вакуум проблема. На своём продукте мы нагрузку на CPU снизили в 2 раза с переходом на пострес. IO плюс минус такой же.
Спасибо, картинка ясна. Если раньше приходилось выжимать из имеющихся CPU вдвое больше (и сервер справлялся), то теперь "гуляй, рванина!" можно плодить сколь угодно инстансов постгреса - он же "бесплатный", да... В смысле, за лицензии можно не платить, если работать с community версиями, а не с постгреспро или энтерпрайзДБ. А про постоянные издержки - да кто ж про них думает-то.
А выставили бы MAXDOP в 1 и была бы вам низкая нагрузка на CPU, прям как в постгресе, который уже 30 лет учится параллельным планам запросов.
У любого сервера есть свои лимиты, как бы не вылизывали базу, рано или поздно возникнет вопрос с горизонталкой. И вот тут начинаются нюансы. Реплики какое-то время выручают, но всё равно упираешься во write нагрузку. И приходится шардировать сами данные, причём по материкам. И вот тут MSSQL, как бы это сказать.... Натянуть сову и на глобус можно, но есть способы решать задачу более подходящими инструментами.
Шардирование (распределенное по узлам секционирование) начинается с приближением к отметке "петабайт", что по вашим же словам, не ваш случай. Для начала нагрузка записи снижается (на порядки) прозрачным для приложений секционированием, которое, опять же, в SQL Server "из коробки" с 2005 года, а постгресу еще лет 10-15 догонять.
На много раньше. Как только потребуется локализация нагрузки на другом континенте.
И расскажите, как будете делать что-то уровня TimescaleDB на MSSQL
Не путайте тёлое с мягким. Для геолокализации нагрузок с 2008 года "из коробки" есть geo cluster. Шардировать же, если мы одинаково понимаем смысл термина, начинают по другим причинам, прежде всего по объемам данных.
Я не принижаю MSSQL, я люблю его. У нескольких клиентов только он. Но вот есть задачи, где его притягивать за уши смысла просто нет никакого. В том проекте, где мигрировали на посгрес - всё что нас держало годами от миграции - были килотонны хранимок разной степени тухлости. И вот с появлением LLM - переписали основную кодовую базу за месяц.
есть geo cluster.
стоимость этого решения понимаете? главный вопрос - зачем? что бы было? У нас бизнес деньгами не сорит.
Неподходящие модели данных задачи найдутся всегда, я их приводил в книжке, например с анкетированием на 100-1000 измерений. Если нужна работа с графами, то несмотря на поддержку таковых с версии 2017 в SQL Server, могут найтись более специализированные и лучшие платформы.
Мой поинт в другом: SQL Server превосходит постгрес по всем параметрам, по многим - с большим запасом. Это СУБД, основанные на реляционной модели данных. Поэтому обоснования, принимаемые в расчет - стоимость лицензий (без учета последующих затрат на поддержку) или политические риски.
И еще такой, очень частый ныне: начинали делать из говна и палок, ничего не знали о коммерческих решениях, теперь уже поздно.
стоимость этого решения понимаете?
Ну, а что же вы хотите, и рыбку съесть и ... Нет денег на энтерпрайз решения - у SQL Server 4 вида репликаций "из коробки" в самой базовой версии. Почти 25 лет назад делал на них "геокластер" на два континента. И ничего, работало
Вв эти репликации запускали между континентами? Я запускал. Такое себе. То, что существует номинально - не означает, что на этом надо строить распределеннве системы. В современном хайлоаде никто не поймет этих аргументов про необхолимость энтерпрайз версий с поддержкой кем.. Индусами в майкрософте? При даунтаймах лайва? Не смешно даже. Если архитеетор построил продукт, зааисимый от внешней поддержки - он профнепригоден. Про нишевое не говорю..
Распределенные БД имеют разнообразную топологию в зависимости от требований к системе, и при любом раскладе они основаны на репликациях или, не к ночи буде упомянутой N-фазной фиксации. Не нужно делать обобщений и, тем более, ссылаться на "хайлоад", если вы переходите на менее производительные платформы. Ладно, вы пошли на второй круг, так что удачи.
Напишу с другого конца. Сам подход к репликации классических реляционок просто неправилен для типичных продуктов, которые мы видем в вебе. Вот именно там шардирование отдельных сущностей с независимой репликацией, как это умеет всякий NOSQL работает понятней и лучше и притягивание туда SQLов за уши - неправильно от слова вообще. То же шардирование - это не про петабайты, а про отдельные домены данных с НЕЗАВИСИМОЙ синхронизацией. Это просто другое, совсем другие принципы и подходы. То, что из RDBMS можно сваять похожее - факт, но применение RDBMS для таких целей - элементарное невладение современными подходами к разработке. К примеру использовать MSSQL для распределённого keyvalue придёт в голову только в пьяном угаре =)
Вы снова отклонились от темы. Видимо, использовать для тех же целей постгрес не будет считаться "пьяным угаром". И, внезапно, keyvalue на SQL Server быстрее Redis, можете проверить на досуге.
Я читал ту статью, на которую вы ссылались в другой теме, но проигнорировали важный абзац в заключении. Нельзя так базы тестить вообще. Уж RDBMS будет занят в реальности многими другими запросами и key value запросы в реальности будут значительно медленней. Кроме того, redis - это далеко не только key value. Списки, expiration и т.п. Вот такие сценарии надо тестить тоже.
Навскидку, оптимизатор запросов даёт примерно на порядок лучший результат (простой CRUD только в 2-3 раза за счет кластерных ПК), always on постгрессу пока даже не снился (реплики - это совсем другое, но и их в SQL Server несколько типов на выбор) как и прочая инфраструктура администрирования "из коробки". Обычно ваш кейс происходит из-за недостаточной компетентности в SQL Server и нежелании её иметь
производительность SQL Server примерно на порядок выше PostgreSQL
а сможете пруфы привести?
Посмотрел ссылки. Никакого подтверждения тезису, что на одной и той же железке джоин пары таблиц с фуллсканом оракл будет делать на два порядка быстрее постгресса не увидел. Увидел обсуждение неких специфичных конкретных кейсов, которых может просто не существовать в куче мест и которые в случае возникновения решаемы самим владельцем сервиса несколькими разными способами.
Решение проблем владельцем сервиса стоит денег этому владельцу. Соответственно, отсутствие проблем ничего не стоит. Вижу, что тема сложновата для вас, начните с простых кейсов типа кластерных индексов и CRUD, воспроизводимых на любой железке.
Статью надо было назвать "Пьяные бредни некомпетентного менеджера".
Сначала автор утверждает, что документация у DevOps плохая.
Документация - это гигантская папка .md-файлов во внутренней вики, где все описано максимально кратко.
Через пару абзацев он утверждает, что документация у DevOps очень классная и подробная, и что он очень завидует такой детализированной документации.
у DevOps достаточно детализированный технический роадмап миграций на новые версии БД, настройки датацентров и тд., а у команд это отдано на самотек. Немного, но нотку завести вызывает.
Затем автор утверждает, что фикс проблемы сразу на проде - это нормально и что 1,5 дня на фикс - это слишком много.
баг возник из-за кривого конфига Nginx, который правился по хорошему на лету. Если бы devops-инженеры не коммуницировали через сервис деск и вызов дежурного через команду в слаке, а потом не требовали детальной постановки, то сроки не были бы настолько безможно сорваны (1.5 дня на решение проблемы);
Но парой абзацев ниже, он возмущается тем, что DevOps делают всё быстро и это плохо, т.к. нет зрелых сервисных процессов, и что фиксы сразу на проде приводят к проблемам и нарушают принципы инцидент менеджмента.
Формализованные процессы воспринимаются как “бюрократия”, которую проще обойти, чем внедрять. В результате про построение зрелых сервисных процессов не вспоминают, а от инцидент менеджмента мы имеем только способ обнаружения постфактум. Зато быстро!
Так и хочется написать, да определись ты уже наконец, что такое хорошо, а что такое плохо. Ты же через каждые несколько абзацев меняешь своё мнение на прямо противоположное, как политическая проститутка.
Вполне естественно, что никто не хочет работать с таким менеджером и по любым вопросам его отправляют делать тикет, т.к. только так можно хоть как-то зафиксировать постоянно меняющиеся требования этой проститутки.
Всю жизнь сидел на Хабре, даже не регистрируясь, а после этой статьи захотелось написать комментарий.
Однако нюанс ситуации в том, что баг возник из-за кривого конфига Nginx
Интересно было бы узнать, кто в вашей разработке ответственен за конфигурацию nginx: devops, ваша команда разработки, другая команда.
Также методология scrum предполагает некоторого владельца продукта, которой в заданной области имеет право выбирать задачи и соответственно согласовывать изменения. Мне понятно желание пм везде и всюду пытаться приоритизировать свои фичи как самые главные, особенно обратившись напрямую к исполнителям, но если конфиги nginx например общие, я бы на месте devops тоже бы не стал по голосовому их править, потому что они также могут затронуть функционал других команд, а брать ответственность за потенциальные убытки бизнеса из-за голосового сообщения, которое нигде в системе разработки не логируется никто не захочет.
Прошу прощения, случайно нажал минус, промахнулся. В данном случае конфиг был у другой команды, но мы совместно катили изменения
Эх первый же комментарий на Хабре и сразу минус.
Исходя же из скромного опыта, слияние множественных фич зачастую может ломать друг друга, что выявляется обычно на этапе тестирования. Совсем уж простые вещи отсекаются ещё на этапе слияния ветвей в системе контроля версий политиками, если не проходит сборка или автоматические тесты, остальное же требует внимания.
В идеальном мире, как мне видится, следовал бы немедленный rollback в случае возникновения ошибок на проде, что как раз скорее всего в ведении devops инженеров, а далее согласование конфигов с командой ответственной за них.
Вспоминая свой начальный опыт коммерческого программирования, попытка быстренько пофиксить релиз на горячую, обычно ведёт лишь к непредсказуемому поведению в других частях программы и переработкам в попытке все таки поднять релиз.
DevOps это метдология, а не роль. Запомните уже.
Есть специалисты по инфраструктуре. Они могут работать по разным методологиям.
Сборка и эксплуатацию могут происходить по разному, в разных компаниях. Например там может не быть дежурных, Service Desk и изоляции.
В общем статья какая-то хрень
У меня одного сложилось ощущение, что автор не совсем понимает, кто такие devops? А их якобы devops - это так называемый шива, который должен уметь все и вся?
Как бы то ни было, по-моему опыту проблема в сроках при обращении к devops в том, что срок решения тикета ожидается вчерашним числом, а devops пока не изобрел машину времени. Почему-то никто не задумывается над тем, почему вообще на столь позднем этапе была выявлена та или иная необходимость.
Подскажите пожалуйста, исходя из чего у вас сложилось впечатление что они должны уметь все и все вообще мне что-то должны?
Из общего описания того, что от них якобы ожидается и какие задачи "в основном выполняют", если верить словам в статье.
Нет, я в принципе понимаю, что вы имели ввиду, потому что это распространенный кейс, когда на devops, помимо его основных обязанностей, навешивают всю инфраструктуру, вплоть до метрик свободного места на диске.
Увы, это только говорит о незрелости выбранного подхода такими организациями.
Ага, понял вас! Ну в целом если подумать, да, задачи весьма разнообразным. Особенно меня умиляет когда из devops-инженера пытаются сделать хранителя ключей и сикретов
К тому, что было высказано до меня, я бы хотел вот что ещё добавить от себя лично.
Большая проблема, что если с горем пополам чем занимаются программисты понятно, то объяснить чем занимаются люди ответственные за эксплуатацию для менеджмента сложнее. Вы не понимаете проблем и задач эксплуатации, поэтому вам и кажется, что они что-то делают неправильно, но в общем все ровным счётом наоборот.
В свое время я начинал один свой проект с того, что не было ни тикетов, ни малейшей бюрократии, по итогу триста человек начали звонить, писать, а то и ходить ногами. И при этом остальная работа никуда не исчезла. Это безусловно было очень удобно для моих коллег, правда вся моя работа фактически вставала, это вело к огромным переработкам, к необходимости бежать в два раза быстрее, чтобы двигаться вперёд, чтобы успеть все, при этом документально куда тратится моё рабочее время я ничем не мог подтвердить.
На хабре есть полно статей, где люди также пришли к тикетам, чтобы хотя бы как-то было возможно планировать работу, фиксировать задачи и отчитываться о результатах своей детальности. Это делается не из-за большой прихоти, не для желания отгородиться, а потому что жизнь заставила.
Это действительно так бюрократия нужна с определенного момента, это как процессный скелет компании. Повторюсь, я менеджер и для меня создавать разумную бюрократию, например отгораживая команду планом на 2 недели от неразумного переключения контекста, переработок и тд - основа работы. Однако тут я привел как пример возникающей стены как раз неуместную в моменте бюрократию
Лично мне в целом понятно чем занимаются devops-инженеры, хоть я и не очень силен в технической части
Но вот за остальных менеджеров не скажу. Как на ваш взгляд можно повысить вот эту долю понимания?
Тимлидю девопсов уже N лет. Статья - оторвана от понимания. Тимлид вменяемый все решит. У вас же явно перекос и общие уставшие девопсы. Которых дёргают. Проблема в организации, а не в процессах. Накидывать itil, itsm это бессмыленно
От понимания чего на ваш взгляд оторвана статья? Не совсем уловил мысль, поясните пожалуйста)
И что не так в данных случаях в организации?
Вы увидели верхушку айсберга и пошли писать об этом. У вас есть 3 инженера, которые являются высокорисковыми активами, на которых повесили все риски. Добавим к этому то, что скорее всего все построено на костылях и архитектором и сто, которые в этом не шуршат, нет бюджета на рефактор автоматизации, а девопсы задрочены сразу всеми проектами. Ещё в догонку докинем местную бюрократию и тимлидов разработки, которые сразу бегут жаловаться наравне с сто. DevOps as a service? А бюджет у сервисного подразделения есть? А сами бюджет считали на свой проект для них, или пришли с криком "дай дай дай"?) Строить as service можно когда есть грамотный Лид и техлид, которые как раз находят ресурсы, чтобы не держать все на честном слове. Если есть три с половиной инженера, которые бегают каждый день между проектами и должны в голове держать сразу весь контекст, поддерживать прод и слушать какие они плохие, то проблема не в них. У вас целый спектр описан, почему в итоге девопсы запираются и играют в вашу бюрократию ещё сильнее.
Не совсем понимаю комментарий про верхушку айсберга. Я отрефлексировал прошлый опыт и решил привлечь внимание к теме, не более
На прошлом месте работы, если не изменяет память было суммарно порядка 35 devops-инеженеров, не считаю 5 их лидов, 2 проджектов и head of devops. Полагаю бюджет там также был выделен существенный
Мне как раз не нравится то что произошло в прошлом и я не хотел бы чтобы это повторялось и поэтому написал статью. Возможно кто-то, кто ее прочитает задумается, и у него не будет так плохо в коммуникациях
Несомненно ITIL нужен, как и введение команд Operations (Service Desk) и R&D. У вас DevOps занимаются всем, только не тем, что эта методология предполагает.
Дочитал до момента, когда sre задачи (бакапы, дежурства, мониторинг, в общем эксплуатация) зачем то начали приписываться девопсу. Автор, ты их путаешь.
Порызмышляв, я пришел к выводу что образ «высокомерного DevOps» — не вымысел, а следствие конкретных организационных ошибок и культурных перекосов.
уже довольно давно, пришел к выводу, что в девопсы склонны попадать высокомерные и самодовольные граждане. вернее, они там чаще задерживаются, вытесняя остальных. исключения бывают, но их не так много.
Почему многие думают, что DevOps — Гилфойл