Вместо интро
Я думаю каждый сотрудник IT‑компании, где есть эта выделенная роль, особенно проектный менеджер, сталкивался с этим: есть отдельный мир конфигураций и скриптов, где изолирована коммуникация и технический тикет основное средство общения. Обычно CTO ставит их под свой колпак, изолируя от остальных команд и создавая эффект «касты избранных». Простые запросы превращаются в бесконечные уточнения, а работа стоит в ожидании»благословения». Я уверен, ты догадался о ком я.
Предупреждение: пост пронизан иронией с целью привлечь внимание к проблеме, а не очернить кого‑то
Этот пост у меня зрел давно. И решил таки его написать, когда размышлял, а почему всякие аджайлы часто не заводятся у компаний. Кейсов релевантных истории было полно, но вот два моих любимых:
Мы жестко сорвали релиз супераппа на важное гео из‑за критичного бага. Причем в случившемся есть мой косяк как менеджера — я не составил полный план выхода с роллбэком. Однако нюанс ситуации в том, что баг возник из‑за кривого конфига Nginx, который правился по хорошему на лету. Если бы devops‑инженеры не коммуницировали через сервис деск и вызов дежурного через команду в слаке, а потом не требовали детальной постановки, то сроки не были бы настолько безможно сорваны (1.5 дня на решение проблемы);
У нас достаточно жестко проседали сроки и я долго не мог понять в чем дело, пока на одной из встреч QA не пожаловались на то что сборки собираются медленно. Я открыл гитлаб и что я вижу — пайплайн тестовой сборки идет в среднем 35 минут. Отправился бить челом к devops и оказывается наши выделенные раннеры больше не наши, а общие, ибо так им удобнее. На этом история застряла где‑то на полгода.
Безусловно менеджеры также любят городить свои проектные офисы и обмазываться КСУП, сторипойнтами и гантами. Однако мне интересно в данном стать происследовать природу явления и привлечь внимание к теме. Почему вдруг в компании возникает такое явление.
Изолированный мир DevOps
Я думаю любому кто работал в продуктовой компании прошедшей через трансформацию и трансляцию DevOps as Service описанное ниже будет знакомо, как родное.
Устройство быта DevOps
В типичной DevOps‑команде 1–3 штуки инженеров.
Их день начинается с проверки Slack‑бота дежурных и того, дергало ли кого‑то, почты с Tier-1 алертам по Golden Metrics.
Основные задачи — контролировать свободное место на дисках серверов, следить за успешным прохождением бэкапов, проверять корректность создания и масштабирования нод в ClickHouse и других кластерах.
Всё хранится в закрытом проекте GitLab: Ansible‑плейбуки, Terraform‑модули и Vault‑секреты, к которым доступ имеют только они.
Для тестовых стендов действует жёсткий принцип: только DevOps могут создать или свичнуть окружение по заранее прописанным правилам.
Документация — это гигантская папка.md‑файлов во внутренней вики, где все описано максимально кратко.
DevOps-повадки
Общение почти исключительно через Jira‑таски с детальными описаниями — неполные заявки сразу возвращают на доработку.
Еженедельные 20-минутные стендапы для планирования крупных работ по переездам, вне их встреч обсуждения считаются отвлечением.
Любая попытка изменить конфиги или Vault воспринимается как угроза стабильности и этоневашазонаотвественности.
Slack‑каналы — закрытая экосистема для обсуждения только релевантных вопросов. Обычно есть группы Infra, Core, Alerts и бот для дежурств.
Вместо фото аватарки и на созвонах не включают камеру.
Крайне рады в целом если созвона не будет или возможности с него уйти. Если звать на созвон, на котором они считают что не нужны — идут жаловаться CTO.
Ощущение «пальцев веером» любые попытки вмешательства воспринимаются как угроза, а дистанция между DevOps и остальными командами приводит к напряжённости и недоверию. Да чего уж там, часто я и мои коллеги проджекты просто напросто были в контрах с Devops.
CTO как хранитель «святости»
CTO считает DevOps ключевым элементом, который отвечает за стабильность всей инфраструктуры компании. Они ему понятны, ведь часто CTO — это бывший самый первый бекенд разработчик в компании. Чтобы не допустить ошибок и лишних вмешательств, он лично контролирует каждый запрос в команду, доступы, миграции и тд. В целом минимизируя человеческий фактор, что вроде есть хорошо, если бы не нюансы.
Иногда это доходит до того, что даже тимлидам разработчиков запрещают участвовать в обсуждениях или вносить изменения, ибо работает не трогай. Такая жесткая защита естественно создаёт ощущение особого статуса у DevOps.
Масло в огонь подливает то что часто (хотя возможно только в моем опыте было такое) у DevOps достаточно детализированный технический роадмап миграций на новые версии БД, настройки датацентров и тд., а у команд это отдано на самотек. Немного, но нотку зависти вызывает.
Но вместе с тем это только усиливает их замкнутость и создаёт дополнительный барьер между DevOps и остальными командами. Да и просто они бесить начинают. В итоге мы вступаем в цикл: devops изолируются → на них раздражаются → devops изолируются.
Очень красноречивая ветка на реддите про это.
Как мы докатились до жизни такой, что DevOps это отдельные пафосные инженеры
Продолжатели сисадминов и идей SRE
DevOps вырос из противостояния: разработка гнала фичи, админы держали прод на замке. Концепция возникла как мост между этими мирами, но на практике стала эволюцией старых сисадминских привычек — главное, чтобы не падало, а всё остальное вторично. Можно нанять универсала которые и на связи 24/7 и сможет жонглировать всем зоопарком тех ландшафта один.
Когда писал наткнулся на отличную статью, очень советую.
Забавно, что многие компании восприняли DevOps как чисто техническую роль — «новый сисадмин, только со скриптами»
Спрос только за аптайм и восстановление
Метрики успеха для DevOps обычно предельно просты:
аптайм (uptime)
среднее время до восстановления (MTTR)
иногда — скорость отката к предыдущей версии (если гитлаб на premium‑плане, можно удобно мерить)
Успех оценивается не по тому, насколько удобно работать другим командам, а по отсутствию аварий и стабильности сервисов. Отсюда и недоверие ко всем внешним «инициативам», особенно если они могут помешать стабильности. Сценарий классический: если всё работает — лучше ничего не трогать.
Процессные практики не транслируются
На всех популярных roadmap»ах для DevOps, том же https://roadmap.sh/devops блоки про процессы, ITIL, ITSM и CMDB обычно где‑то в самом низу ‑- если вообще есть. Прокачка идёт по Linux, CI/CD, Docker, Kubernetes, облакам, мониторингу и скриптам, а вот про ITSM или Service Line редко кто вспоминает. Формализованные процессы воспринимаются как «бюрократия», которую проще обойти, чем внедрять. В результате про построение зрелых сервисных процессов не вспоминают, а от инцидент менеджмента мы имеем только способ обнаружения постфактум. Зато быстро!
Про хайп и элитарность я опущу, кажется это уже проходит, как и в целом «золотая эра IT» как «особенной» сферы. Хотя я помню как писались такие статьи в свое время…
Бесполезные передасты
Этоя про то как выглядят проектные менеджеры часто.
На мой взгляд причины конфликтов между devops‑инженерами и проектными менеджерами (упаси боже скрам‑мастерами) лежат сугубо в этих 3 плоскостях:
Противоборство целей
Менеджер фокусируется на попадании в ожидания заинтересованных лиц, а DevOps на стабильности инфраструктуры, автоматизации и частоте выпуска (но не всегда про последнее). Эти цели явно вступают в конфликт, особенно когда надо в сжатые сроки.
Каждое изменение для DevOps — это буквально failure, риск падения стабильности, поэтому у Ops‑команды естественное стремление замедлить и тщательнее контролировать выпуски.
Неприязнь к бюрократии
DevOps‑культура!!!! зародилась в инженерной среде, а там ценят автоматизацию и сниженение участия человека, поэтому традиционные менеджерские практики (регламенты, миты, отчеты) воспринимаются как бюрократическая шляпа.
Обычно девопсы — это бывшие сисадмины или разработчики, не горящие энтузиазмом от Scrum‑ритуалов или документации. Если проектный менеджер настойчиво требует от DevOps‑команды следовать формальным процессам это типично провоцирует агрессию. Интровертивные инженеры часто избегают чрезмерной коммуникации, а тут их заставляют «играть по правилам» Agile, ага, щас.
Критика компетентности менеджеров
Поскольку работа DevOps требует изрядного уровня технического погружения, многие инженеры скептически относятся к людям, не обладающим таким же уровнем техглубины. Если менеджер проекта не отличает виртуализацию от контейнеризации, DevOps‑инженеры невольно начинают считать его бесполезным посредником.
Последствия для бизнеса
В целом более подкованный товарищ все изложил тут, но я повторюсь:
Пока DevOps-барьер стоит непроходимым, Lead Time и Time-to-Market медленно, но верно растут → конкуренты выкатывают новые фичи быстрее, а мы зависаем в бесконечных согласованиях
Для проектных менеджеров это превращается в марафон эскалаций и попыток пробиться сквозь джиру → в какой-то момент выгораешь и перестаёшь верить, что можно договориться по-человечески
В командах накапливается раздражение: каждое новое обращение превращается в мини-конфликт, где уже не задача обсуждается, а воюют за территорию и ресурсы
В конечном счёте компания теряет и в скорости, и в качестве → срываются сроки, страдает пользователь, и вместо движения вперёд все буксуют на ровном месте
Зато можно выступить на DevOps Days с кейсом нового витка развития IaC.
Рекомендации по взаимодействию
Идите навстречу друг другу.
Проектным менеджерам и вообще менеджерам
Не бойтесь подтянуть базовый системный дизайн и разобраться, как устроена ваша инфраструктура — это проще, чем кажется и сразу сокращает количество недопониманий. Когда вы говорите на одном языке это приятно. Хорошая книга.
Найдите время и честно попросите DevOps провести вам экскурсию по техландшафту компании: как работают основные сервисы, где лежат ключевые конфиги и тд. Возможно даже вы поймете только четверть. Но даже один такой разговор снижает предубеждения.
DevOps
Ведите в Confluence FAQ или просто небольшой справочник по инфраструктуре, а ещё хотя бы раз в месяц устраивайте «дни открытых дверей» — собирайте коллег, рассказывайте и отвечайте отвечайте на вопросы о том, как и почему всё так устроено.
В таск‑трекерах почти всегда можно настроить шаблоны задач: пусть любой запрос к DevOps проходит по чёткому брифу с ответами на ключевые вопросы (версия сервиса, окружение, цель запроса и т. д.). Это не только облегчает жизнь DevOps, но и позволяет автоматически выставлять SLA по каждой категории — прозрачнее, быстрее, честнее для всех.
CTO:
Следите, чтобы в развитии DevOps‑инженеров появлялись не только новые «технические игрушки», но и хотя бы базовые процессные компетенции — понимание ITSM, навыки коммуникации и сервисное мышление для внутреннего клиента.
И, кстати, самим CTO полезно хотя бы раз пролистать руководство по ITIL 4, чтобы не превращать свою инфраструктурную команду в касту брахманов.
Я не знаю кто автор этого чуда, но вот нашел папку про ITIL и там много на русском.
Вместо послесловия
Порызмышляв, я пришел к выводу что образ «высокомерного DevOps» — не вымысел, а следствие конкретных организационных ошибок и культурных перекосов.
Предугадывая комментарии я не только размышлял, но и поообщался с парой банков и телекомов.
Отдельный DevOps‑отдел, отсутствие общей ответственности, дефицит коммуникации и поддержка сверху без баланса — это приводит к тому, что сервисная команда обособляется и начинает смотреть свысока на остальных, а те отвечают ей недоверием и неприязнью. Для продуктовой компании это крайне опасно: вместо паверапа Dev и Ops мы возвращаемся в эру кабинетных войн. Те же яйцп, только в профиль
Цель этой статьи — не очернить всех DevOps‑инженеров (среди них множество отличных командных игроков), а привлечь внимание к этим тревожны м сигналам.
Update: в комментах и сообществе посоветовали еще 2 отличных статьи на эту тему, добавлю сюда:
Если вдруг интересно — мой канал.
Комментарии (221)
ky0
28.05.2025 05:36Поздравляю, у вас Devops обратно деградировал в замшелое сисадминство. А может, никогда и не эволюционировал :)
Это, впрочем, никак не отменяет того, что задачи должны быть сначала как следует описаны, а уж только потом взяты в работу. Если девопс-инженер не в состоянии из приехавшего от PMa потока сознания итеративно вылупить технически верный тикет - значит, нужен другой инженер, более высокого грейда (скажем, мидл).
А ведь, как уже было написано - так ведут себя попросту хреновые сисадмины, а уж девопсы они или нет - дело второе.
Renewal_Studio Автор
28.05.2025 05:36О, спасибо, я эту статью что-то пропустил когда серфил по хабру, добавлю на нее ссылку в свою
Renewal_Studio Автор
28.05.2025 05:36Была ли у вас такая ситуация? Если да, то как решали? (ну окромя ротации людей)
ky0
28.05.2025 05:36Вообще, для меня дико читать про описанное вами - я, конечно, видел места, где были какие-то точечные проблемы, но чтобы одновременно фигово было и с межкомандным взаимодействием, и с оформлением задач, и с документированием, и с ревью (это я про тот кривой конфиг, который как-то добрался до прода) - такого ещё не встречал.
У вас такой флеш-рояль, что я даже не знаю, что посоветовать
тут всю систему менять надо, начиная с СТО.Renewal_Studio Автор
28.05.2025 05:36Я такое наблюдал несколько раз, благо на текущем месте несколько иначе и многие идут на контакт, а devops даже с интересом заглядывает на встречи
budnikovsergey
28.05.2025 05:36Действительно здесь махровая проблема с процессами и зонами ответственности. Как по мне, это частично лечится переведом части девопсов в продуктивные команды, чтобы поменять их приоритеты на командоориентированные, оставив пару на платформе. Тогда они уже сами между собой договорятся в интересах продуктов и платформы. Но да, сверху должен быть тот, кто будет смазывать их общение и не даст перетянуть одеяло на себя ни одной из сторон
Renewal_Studio Автор
28.05.2025 05:36Как часто вы работали в таком месте, где был человек-балансировщик на уровне C-lvl?
budnikovsergey
28.05.2025 05:36Я как-то всё по крупным компаниям обретаюсь и обычно везде C-level назначал владельца DevOps-экосистемы и продуктовые менеджеры вполне могли обсуждать с ним потребное взаимодействие, в случае необходимости эскалируя.
Renewal_Studio Автор
28.05.2025 05:36Я тоже, но часто там бизнес и разработка были жестко разграничены и разработка находилась в состоянии подчиненного сервиса
igorsimdyanov
28.05.2025 05:36devops-ов нужно помещать в команды, с обязательным посещением стендапов - в этом случае все нормализуются. Они будут говорить, что тогда не будут двигаться инфраструктурные проекты. Тогда можно поделить на две части: ядро под инфраструктуру, но часть должна быть в полях и понимать проблемы команд, боль бизнеса, разработки, тестирования - заниматься автоматизацией и вовлечением разработчиков и тестировщиков в культуру devops. Яростно плюсую ky0, у вас нет devops-а, у вас классические сис.админы избегающие взаимодействия с командой.
PS Когда оказывался в вашей ситуации, всеми правдами и не правдами старался заполучить devops-а себе в команду и на стендапы.
Renewal_Studio Автор
28.05.2025 05:36Ага, спасибо за опыт. Я пробовал делать схоже, но каждый раз сталкивался с примерно следующей позицией - у них совершенно другие задачи, да они иногда делают задачи от команды, но в целом они работают для всех команд и на тем чтобы команды вообще могли работать. Поэтому нет, нельзя их помещать в команду, тем более как условный тимлид будет за ними присматривать?
PerroSalchicha
28.05.2025 05:36Я пробовал делать схоже, но каждый раз сталкивался с примерно следующей позицией - у них совершенно другие задачи, да они иногда делают задачи от команды
Да, они так нередко говорят. Но вам нужно отделить собственно девопс от сисадминов. Девопс, это как раз непосредственно про поддержку разработки. Они должны быть частью девелоперской команды, и их продуктом должны быть те же самые релизы, новый доставленный пользователям функционал. Потому что если вы их отделите от девелоперов и посадите к сисадминам, у них и целевым продуктом будет то же самое, что у сисадминов - стабильная работающая инфраструктура. А стабильно работающая она бывает в том случае, когда изменения в ней происходят пореже, в идеале - вообще никогда. Поэтому девопс в команде сисадминов будет закручивать гайки для разработчиков по самое небалуй, препятствуя релизам. Отсюда и конфликты между девопсами и разрабами возникают.
Renewal_Studio Автор
28.05.2025 05:36Хмм, спасибо за пищу для размышлений! Но точно ли devops в таком случае должен быть отдельный инженер? А не сами разработчики например?
vadimr
28.05.2025 05:36Если это удобно делать разработчикам, то почему бы и нет? Девопс возник как способ освободить разработчиков от непрофильной деятельности, например, командировок.
PerroSalchicha
28.05.2025 05:36А не сами разработчики например?
Если они хотят и могут - вполне. Другое дело, что это хоть и смежные, но несколько разные скиллы, и далеко не всегда сочетаются в одном инженере.
akod67
28.05.2025 05:36Проблема с девопсами в том, что они (хорошие девопсы) должны иметь в бекграунде и опыт разработки и опыт запуска / эксплуатации причём под нагрузкой. Обычно это уставшие (выгоревшие) разработчики. Обычные девы часто дальше "а у меня на компе всё работает" не мыслят и к продакшену их подпускать надо очень осторожно. Тем более, если дев замотивирован не особо грамотным менеджером выпускать фичи побыстрее. Нужен человек, который менеджера может отшить, именно поэтому девопс в другой юрисдикции.
budnikovsergey
28.05.2025 05:36Узкое место в том, что коммунальная инфраструктура должна строиться с учётом интересов всех команд и быть максимально гомогенной, прозрачной и управляемой и нужно хорошо в ней разбираться, чтобы переделывать и развивать её адекватным способом. Если просто дать рули разработчикам отдельных продуктов, то обычно она очень быстро потеряет все эти 3 качества, в том числе разделившись на много слабосовместимых контуров с разными подходами и технологиями. И по моему скромному опыту проблема усугубляется тем, что среднее время жизни разработчика на проекте около 1,5 лет и участники изменений из команд достаточно быстро меняются, а весь техдолг остаётся, накапливаясь. Как в переписке правильно заметили, часть девопсовой ответственности должна включать релизы продуктов, чтобы они не окукливались в обеспечении стабильности инфры и прикладов, каковая проще всего достигается остановкой изменений.
Renewal_Studio Автор
28.05.2025 05:36А как часто вообще команды спрашивают какая им нужна инфра, окружения и тд? Там где я работал обычно это просто устанавливал CTO и точка
budnikovsergey
28.05.2025 05:36Вам нужна не инфра, а возможности для релизов, тестирования и эксплуатации. Вот именно они и являются темой для обсуждения с DevOps-командой. А уж как они там работают внутри оставьте инфраструктурщиками и их коммунальным решениям
inkelyad
28.05.2025 05:36но часть должна быть в полях и понимать проблемы команд, боль бизнеса, разработки, тестирования - заниматься автоматизацией
Наоборот. Девопсы и есть 'Поля' Т.е. эксплуатация. (В статье, впрочем, смешано - есть инфраструктура разработки и есть инфраструктура эксплуатации того, что разработали. Это не одно и то же и не всегда одни и те же девопсы и даже организации).
И это разработчикам нужно бывать в эксплуатации и/или поддержке инфраструктуры хотя бы иногда. Тогда они будут понимать, какую боль они создают для окружающих.
Chelyuk
28.05.2025 05:36Позволю себе немножко не согласиться. Поток сознания от PM - это повод найти нормального PM, который общается не потоком сознания, а чем-то более вразумительный и приближенным к делам, компании, продукту и процессу.
Поток сознания может выливать только заказчик, который платит деньги. И только это может оправдывать такое поведение. Все остальные в рамках компании - это сотрудники осваивающие деньги клиентов и в идеале приносящие этим самым клиентам пользу. Но вот когда менеджер начинает вести себя как клиент, получая такую же зарплату и не оплачивая труд других из своего кармана. То это просто воровство ресурсов компании временем других сотрудников, которые не обязаны разбирать такие потоки. Для этого и есть менеджер, а если он не может то бизнес-аналитик. Который переводит с потоков на понятный технический язык. Технари должны получить задачу и выполнить ее, а не переводить поток сознания во что-то человеко-разборчивое. Это весьма непростое и стоящее многих нервов занятие.Renewal_Studio Автор
28.05.2025 05:36Я с вами полностью согласен! Однако я привожу пример того, когда заведение и исчерпыющее описание задачи ставится поверх приоритета разбора с проблемами. Я прекрасно понимаю такую позицию и часто делаю также, когда ко мне приходит другая команда, в работу просто не попадут не описанные задачи. Да и мои задачи другие не возьмут. Но если у нас серьезная проблема, которая сильно бьет, то в целом можно и по голосовому сообщению работать
Destros
28.05.2025 05:36Что такое голосовое сообщение? Вы голосовые как в тг отправляете?
Простите, я просто уже не в первый раз тут в ветке читаю об этом, не могу понять.
Renewal_Studio Автор
28.05.2025 05:36Нет, я не пишу коллегам голосовые, это лишь фигурацильное выражение, иллюстрирующее что если у нас аврал, то можно и по голосовому работать, тут уже без разницы
wnder
28.05.2025 05:36Без баланса никуда.
С одной стороны можно потратить рабочий день на описание задачи (да? можно? удивительно :)) и не делать работу, с другой стороны голосовые распоряжения по задаче могут быть взяты в работу - но их придется переделывать. Нет гарантии, что технический исполнитель поймет слова правильно, будет делать корректно (особо интересно если исполнителей будет два или три) и постановка задачи приведет к тому, что условный менеджер будет в ужасе что все делают не то и не так. Зато не писали задачу текстом и все только голосом. =)
Из хорошей практики - договорились с активным менеджером оформить задание не словами (а ему надо быстро и очень, он чуть ли не каждые 15 минут звонил и интересовался как дела и чем помочь) но двумя предложениями в жире. Я на самом деле сам написал =) и сам уточнил правильно ли я понял. Сошлись на том, что он мне не звонит 4 часа и через 4 часа спрашивает как дела (спойлер - все ок =) ). Я не знаю каких ему усилий далось не писать и не звонить =) но фокусировка на задаче дала свои плоды и все было сделано в согласованное время.
На текущий момент менеджер балдеет :) ставит задачу в жире текстом (сам пишет, по своему по менеджерски) потом звонит и просит сроки решения и спрашивает нас что не понятно в его задаче.
Коммуникация отличная получилась и все всех хвалят =))
Главное - баланс. Имхо. :)Renewal_Studio Автор
28.05.2025 05:36Я рад что у вас все выстроилось, однако у меня нет такого что я приношу задачу в 2 словах или прошу написать за меня. Хотя последнее бывает в редких кейсах, когда я действительно не понимаю как поставить задачу и прошу совместно обсудить, но напишу ее я
PerroSalchicha
28.05.2025 05:36Поток сознания от PM - это повод найти нормального PM, который общается не потоком сознания
РМ'а посередине проекта, как правило, так вот просто не заменишь. Особенно если он уже пустил корни в коммуникации с заказчиком. Но зато его можно (и нужно) заставить систематизировать свои требования.
Renewal_Studio Автор
28.05.2025 05:36У вас кажется опыт больше пронизан аутсорсом, я в последние 5 лет больше в продуктовых компаниях, там по сути 1 заказчика нет
budnikovsergey
28.05.2025 05:36Резануло глаз, поэтому позволю себе заметить, что DevOps, тот самый, который не человек, а методология, это больше всего про общение и совместное непрерывное нанесение ценностей работодателю и его пользователям, а не цепочка "должен, должен, должен", обёрнутая в ITIL с согласованными сроками рассмотрения.
randomsimplenumber
28.05.2025 05:36Как люди в IT видят друг друга.жпг если коротко.
Renewal_Studio Автор
28.05.2025 05:36Да вполне нормально видим (тут говорю за себя и свое окружение), просто есть множество недопониманий, как раз про это и написал статью
randomsimplenumber
28.05.2025 05:36просто есть множество недопониманий
Да, картинка именно про это ;)
Да вполне нормально видим
Да, негры они такие же люди. Только негры ;)
Renewal_Studio Автор
28.05.2025 05:36Здорово устранить эти недопонимания. Я рад что она привлекла внимание, но печалит что все сакцентировались на названии, а не на наполнении
dbuhonov
28.05.2025 05:36Я читаю и прям в сердце
Renewal_Studio Автор
28.05.2025 05:36Я рад что вам откликнулось! Подскажите, а как у вас обстоят дела?
panzerfaust
28.05.2025 05:36Ну что могу сказать: фу таким быть. Если мы откроем этот ящик пандоры и пойдем чихвостить своих коллег, то на хабре места живого не останется. И я вас уверяю, полоскать менеджеров будут в 100 раз больше, чем кого-либо еще. Потому как каждому технарю есть, что про них рассказать.
Renewal_Studio Автор
28.05.2025 05:36Я не чихвосчу своих коллег. Сама тема безусловно провокационная, однако если ее не поднимать, то она так и останется на уровне "так исторически сложилось". Честно говоря было даже страшновато ее писать
Pkgc
28.05.2025 05:36Почему не подняли её внутри своей компании?
Был один PM, вёл себя также: потоки сознания в чаты, инфы структурированной 0, постоянные истерики и звонки по вечерам. Я вопрос поднял не на хабре. После мероприятия был за один раз принят чёткий регламент, ОС от подчинённых - стал как шёлковый.
Renewal_Studio Автор
28.05.2025 05:36Почему не поднял в свое время - вопрос отдельный. Прошлое не исправишь, но я решил просто поднять на мой взгляд важную тему
Pkgc
28.05.2025 05:36Мой наиболее употребляемый каомодзи: ¯\_(ツ)_/¯
Вольному - воля, спасённому - Рай. Кто-то решает вопросы, кто-то - поднимает.
Parfu
28.05.2025 05:36Дорогой, автор.) Как вы точно заметили девопсов мало). Вы в какой-то детской позиции, что раз вас заставляют писать тикет, то это возводит кого-то в какой-то ранг выше вас, но на самом деле это простая гигиена и защита от менеджеров, чтобы не гонять сообщения в тгшечки вместо работы. Пишите нормальные тикеты, которые дают ответы, а не запускают недельные уточнения и будет вам счастье))
Renewal_Studio Автор
28.05.2025 05:36Меня точно также мало. И зачему я не говорю что тикеты писать не надо, я сам писал изрядные портянки для devops по документированию алертов и скрипты для графаны. Я больше подсвечиваю ситуацию, что грамотное оформление тикетов, призванное по идее для структурности и удобства начинает использоваться для отгораживания
Chelyuk
28.05.2025 05:36Вы же сами написали, что DevOps - выделенная команда, а не проектная. У них таких проектов как ваш может быть довольно много. Т.е. они не могут работать в линейной иерархии, как обычный проект. Там просто нет выхода как работать по матрице. А в случае матричной структуры, без тикетов - никак.
Вот есть у них, например, 50 проектов. И возможно ваш - далеко не самый приоритетный. Если дать возможность влиять напрямую, то вы его "пропихнете". Именно поэтому, вводится изоляция команды DevOps и тикеты. Только с помощью тикетов и их приоритезации, можно не поехать кукухой в этом хаосе. И да, вам неприятно, ваши личные метрики идут на дно. Но для компании в целом, возможно, это было меньшим злом и выгоднее, возможно были 5 других более важных и денежных проектов, которые взлетели за ваш счёт.
Это всё конечно теория и домыслы как должно быть. Конкретный кейс может быть вовсе не таким счастливым.Renewal_Studio Автор
28.05.2025 05:36Прекрасно понимаю, однако на тот момент это был приоритет топ 1 за которым и CTO присматривал
opusmode
28.05.2025 05:3650 клиентских + куча внутренних (потому, что проекты сущестуют не в вакууме), и да, многие менеджеры кладут на договорённости, устраивают чайка-менеджмент, капают на мозг. Работа превращается в 16 часов в день + в выходные, притом без премий, доплат и отпусков.
Более того, менеджеры ещё любят лезть в те процессы, в которых ничего не понимают. Им главное, как-то, ну хоть как-то, а виноват потом будет спец, который не послал менеджера и не сделал на день дольше, но нормально (обычно это устраняет типа 90% проблем).
Pkgc
28.05.2025 05:36" грамотное оформление тикетов " используется исключительно для структурирования и полноты информации. Если вы считаете, что это вас отгораживает, посмотрите на паспорт, водительские права, СНИЛС, ИНН.
Renewal_Studio Автор
28.05.2025 05:36Замечу что в приведенных мной примерах требовалось быстрое участие и когда возникают проблемы, кажется тикет оформить задним числом стоит
Parfu
28.05.2025 05:36Проблемы которые надо решить вчера с девопсом решается точно так же как и с бабкой на регистратуре и с начальником-самодуром - обычным уважительным и доброжелательным образом, а не обвинением в том, что он м**дак, который отгородился тикетами))
Renewal_Studio Автор
28.05.2025 05:36Я понимаю ваше возмущение. На хабре столько постов какие менеджеры ополоумевшие безумцы
Повторюсь, я сознательно решил назвать статью так, но внутри нее я именно иронично разбираю проблему. Честно говоря не люблю так щитпостить, но решил ради дискуссии так написать, иначе статья бы затерялась в просторах хабраParfu
28.05.2025 05:36Никакого возмущения, только опыт) То что кто-то что-то не успел и надо сделать быстро - вина не девопса, который тикетами отгородился, а менеджера) Это отдельная больная тема для вас, я уверен, но я с радостью почитаю ваш следующий пост о том, как вы воспитали девопсов и наладили коммуникации)
Renewal_Studio Автор
28.05.2025 05:36Честно говоря не очень понимаю позицию, почему в случае проблем, которые влияют на продукт и цели компании отгораживание бюрократией это нормально?
Там история длиннее, конфиг вообще не моя команда должна была править и тд, но акцент больше на другом, что в случае проблем они стали перекрываться неуместной бюрократиейopusmode
28.05.2025 05:36Нормально потому, что вы не видите дальше собственного носа и не понимаете, что не вся работа связана лично с вами и крутится вокруг вас.
Вообще говоря, половина работы может быть вообще не связана с текущими проектами и продуктами и тоже положительно влияет на компанию.
Каждый менеджер мнит себя центром мира, тяне одеяло на себя, кладёт на процессы и вообще думае, что занимается самым важным делом, на планете земля.
Бюрократия это как барьер. Когда вместо задрачивания мозга в телегу, вас надо создать тикет, это уже отсеивает часть инфошума для специалиста (который ещё может прыгать между контекстами несколько раз в час). Когда вас тикет могут развернуть, это ещё снижает желание схалтурить.
Просто привычка - менеджер никогда не скажет, что он хреново работает, он будет винить всех вокруг. А бюрократия это способ ткнуть его носом. Как в госках. Ну и прикрыть себя.
Если б менеджеры вели себя иначе, способ взаимодействия был бы иной.
Renewal_Studio Автор
28.05.2025 05:36Печально что у вас был такой опыт, по крайней мере то что я замечаю, стараюсь находиться в позиции чтобы работа делалась благодаря мне, а не вопреки. При этом я не идеален, меня заносит и иногда мы сильно спорим с разработчиками или devops
Destros
28.05.2025 05:36Ага, это как тебе пишут в чат с просьбой, ты в ответ просишь оформить тикет, а человек внезапно просто навсегда исчезает.... Возможно даже из компании.
randomsimplenumber
28.05.2025 05:36ты в ответ просишь оформить тикет, а человек внезапно просто навсегда исчезает.
не нужно было вскрывать эту тему. (ц)
Renewal_Studio Автор
28.05.2025 05:36Отчасти из-за этого меня многие считают токсичным кстати (похоже на кейс поднятый в теме). Если ко мне прийти с задачей, она не попадет в команду сразу, я буду узнавать что за задача, в чем суть, почему это важно, где полное описание в тикете и тд. Если важно для другой команды, почему в целом важно для компании
Renewal_Studio Автор
28.05.2025 05:36Я не воспитываю devops и вообще кого бы то ни было. Учусь работать совместно и устраняю непонимание, пожалуй
Сам пост рефлексия, а не жалобы на хабр на текущее место работы, здесь благо такого не наблюдается
Pkgc
28.05.2025 05:36Поддержали это мнение: на ночь глядя выплеснули поток, с руганью в заголовке. ¯\_(ツ)_/¯
chemtech
28.05.2025 05:36Однако нюанс ситуации в том, что баг возник из-за кривого конфига 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 у вас не внедрен. Похоже что у вас там аврал или просто много конфликтовRenewal_Studio Автор
28.05.2025 05:36Ух, сложно будет комментировать (много), но я постараюсь на все ответить!
Renewal_Studio Автор
28.05.2025 05:36Для этого нужны dev, uat, staging окружения
Тут на самом деле печаль, на прошлых местах работы были фича-окружения и прод. Без промежуточных, ибо сложно-дорого-куча микросервисов
Chelyuk
28.05.2025 05:36А вот это вообще root cause 90% провалом на проектах. Когда хотят "скраежопить", абсолютно не понимая чем это обернется.
Не хотим держать свои сервера, CapEx - зло, переходим на облака, мы любим OpEx. И по налогам приятнее и денег сразу столько не нужно. А потом прибегает менеджер. Ой, что-то там такой счёт выставили из облаков. А давайте не будем сервера держать по выходным. Но отчёты по тестам в понедельник я хочу. А сервера по выходным не включайте. Это вместо того, чтобы настроить нормально автостарт и автостоп для окружений. Но менеджер же не хочет знать. Это же для него технические детали, хотя тут речь про деньги.
А так да, мир такой - все что просто, стоит дополнительных расходов. Хочешь сэкономить - придётся освоить довольно сложные схемы и автоматизацию.
Если и дорого и слишком сложно, то зачем вообще начинать проект? Можно же совсем ничего не делать.Renewal_Studio Автор
28.05.2025 05:36Мне кажется или у вас позиция что менеджеры во всем виноваты и проблема в них?
ZimniY
28.05.2025 05:36Почему найти вменяемого технического специалиста гораздо проще, чем вменяемого менеджера?
opusmode
28.05.2025 05:36ну, вообще-то так и есть. Менеджер это буквально управленец. Если он по 10 раз на дню меняет вектор, то кто виноват? Те, кто это реализует или всё же принимающий решение?
budnikovsergey
28.05.2025 05:36менеджеры обычно неплохо понимают язык денег, когда фичи оцениваются деньгами на выбор: тогда они сами бегают и выбивают бюджеты или смиряются. Поэтому умение аллоцировать стоимость ресурсов на проекты часто здорово облегчает коммуникации после прохождения менеджерами этапа принятия.
hyperwolf
28.05.2025 05:36Запуск нового проекта в проде, при грамотном планировании, позволяет его запустить без пользователей и походить в боевой прод тестерам и всем, кому надо, прежде чем туда пускать клиентов.
Renewal_Studio Автор
28.05.2025 05:36Если изолированный да, но если результат проекта - изменения существующей системы, это куда больнее
Renewal_Studio Автор
28.05.2025 05:36Не законченная фраза. Мысль не понятна.
Дописал, спасибо за внимательное прочтение!
Renewal_Studio Автор
28.05.2025 05:36Ошибка руководства что не спросили почему так долго
Спрашивали, просто не поднимался вопрос и никто на это особо не обращал внимание. Когда долго работаешь глаз замыливается
Renewal_Studio Автор
28.05.2025 05:36Ладно, я не потянул все комментировать, прошу прощения. Меня крайне интересует последняя мысль "DevOps у вас не внедрен". Можете ее раскрыть пожалуйста?
chemtech
28.05.2025 05:36Фразу "DevOps у вас не внедрен" уже не уберу. Фраза некорректна. Нет признаков чтобы сказать внедрен или не внедрен DevOps. Скорее уровни зрелости DevOps в компании - https://habr.com/ru/articles/727568/
Renewal_Studio Автор
28.05.2025 05:36Очень напоминает SAFe Devops радар, но как будто чуть осмысленнее. Спасибо, почитаю!
Timmek
28.05.2025 05:36Уверен, каждый кто общался с Девопсами понимает, что Гилфойл из Кремниевая долина это не художественный образ, а каждый первый Девопсер…
Renewal_Studio Автор
28.05.2025 05:36Ну почему, я это скорее для красного словца. Часто отличные ребята, которые просто оказались в такой ситуации и начинают возникать противоречия
opusmode
28.05.2025 05:36скорее каждый, кто никогда не общался с инфраструктурщиками думает именно так.
Renewal_Studio Автор
28.05.2025 05:36Или разработчиками. Или с системными аналитиками. Или с тестировщиками. Или с ... можно продолжать бесконечно)
Все мы для кого-то токсики, когда не понимаем друг друга
budnikovsergey
28.05.2025 05:36уверен, что каждый, кто приходил к стоматологу с идеями как поставить себе титановые челюсти для разгрызания тросов знает, какие эти стоматологи негодяи и токсики
oliva80
28.05.2025 05:36Бесполезные передасты
Это я про то как выглядят проектные менеджеры часто.
это пять!
ув. автор! не останавливайтесь, пишите. если принять иронию и небольшое преувеличение, то изнанка этой 'кухни' показана здорово.
Renewal_Studio Автор
28.05.2025 05:36Спасибо! Гипертрофирование возможно излишне использовал, но думаю оно полезно ради дискуссии. Думаю если хотя бы 1 ПМ и 1 devops прочитают и что-то наладят у себя в коммуникациях, уже победа
Renewal_Studio Автор
28.05.2025 05:36К тому же статей про то как выглядят ПМ-ы для инженеров, даже для devops навалом, а про наоборот почему-то очень мало
vadimr
28.05.2025 05:36Если менеджер проекта не отличает виртуализацию от контейнеризации, DevOps-инженеры невольно начинают считать его бесполезным посредником
что не так?
Renewal_Studio Автор
28.05.2025 05:36А менеджер должен? Зачем ему это?
vadimr
28.05.2025 05:36Разбираться-то в азах специальности? Да нет, конечно, зачем? Сегодня сникерсами торговал, завтра строительством атомного реактора управлять будет.
Это как если бы Калашников не умел стрелять.
Руководитель, который не понимает работу подчинённого, не способен поставить ему задачу.
Renewal_Studio Автор
28.05.2025 05:36Почему для менеджера вдруг виртуализация и контейнеризация азы специальности? Это безусловно важная тема, но не необходимая для понимая контекста. Я искренее не понимаю почему в вашей картине мира условный проджект или продакт должен разбраться во всех нюансах
vadimr
28.05.2025 05:36Почему для менеджера вдруг виртуализация и контейнеризация азы специальности?
Нет такой специальности "менеджер". Есть инженер или лицо без специального образования на позиции менеджера проекта. Если проектом управляет лицо без образования, это уже само по себе повод для беспокойства. Если оно при этом фактически не разбирается в предмете на уровне второго курса, то это однозначный крах.
Нюансы – это точный синтаксис параметров загрузки ядра Xen. А речь идёт именно об азах.
Renewal_Studio Автор
28.05.2025 05:36Это ваше мнение. Однако вполне себе есть целое направление менеджмент, высшее, узкая специализация, как менеджмент программных проектов, международные сертификации и тд. Можно безусловно считать всех проджектов, продактов и тд проходимцами, но реальность такова что это вполне себе профессии, существующие ни одни десяток лет
vadimr
28.05.2025 05:36Можно поинтересоваться кодом специальности "менеджмент программных проектов"?
Renewal_Studio Автор
28.05.2025 05:365.38.03. и под ними есть специализации. Я заканчивал СПбПУ по направлению инновационный менеджмент программных продуктов по отраслям и сферам экономики
vadimr
28.05.2025 05:36Справка гугла:
Основные аспекты инновационного менеджмента программных продуктов:
-
Определение потребностей отраслей:
Анализ специфических нужд и вызовов различных отраслей и сфер экономики, таких как здравоохранение, финансы, логистика, розничная торговля и т.д.
-
Разработка инновационных решений:
Применение передовых технологий и подходов для создания программных продуктов, которые отвечают уникальным требованиям каждой отрасли
-
Управление инновационным процессом:
Организация разработки, тестирования, внедрения и поддержки программных продуктов с учетом принципов инновационного менеджмента
-
Оценка и мониторинг результатов:
Анализ эффективности инновационных программных продуктов и их влияния на бизнес-процессы и показатели компании
Какое отношение это имеет к управлению проектами? Это работа с продуктами.
Я выше обратил про себя внимание, что вы почему-то ставите в один ряд управление проектами и продуктами, но тогда не стал возражать, потому что это было не по основной теме обсуждения. Но вообще-то это разные вещи. Продукт существует ради своих потребительских свойств, то есть своей интегральной ценности в глазах покупателей, а проект – ради функциональных характеристик, то есть конкретных заданных технических параметров.
Flexits
28.05.2025 05:36Простите, что врываюсь в вашу уютную дискуссию.
Но вообще-то это разные вещи. Продукт существует ради своих потребительских свойств, то есть своей интегральной ценности в глазах покупателей, а проект – ради функциональных характеристик, то есть конкретных заданных технических параметров.
Продукт – более широкое понимание, проект – более узкое. Менеджмент вообще, и проекты, и продукты, существуют не только в IT и существовали задолго до IT как такового,
и будут существовать после. Как пример, новая модель автомобиля – это продукт. "Внутри" этого продукта есть множество разных проектов. Иногда очень сильно разных, как, например, разработка тормозной системы и разработка UI бортовой системы.При этом сам по себе отдельно взятый проект также может являть своим результатом вполне себе законченный продукт. Так, наш автомобиль содержит книжечку - руководство пользователя, удалённо контролируется через мобильное приложение, а авторизованные дилеры имеют доступ к онлайн ресурсу, содержащему каталог деталей и предписания по выполнению сервисных процедур. Эта книжка, это приложение и этот сайт – вполне себе можно рассматривать как отдельные продукты в экосистеме "вышестоящего" продукта – новой модели автомобиля.
Поэтому, отличие между менеджером продукта и менеджером проекта в большей степени иерархическое, чем фактическое. По сути оба из них делают одну и ту же работу, но на разных уровнях детализации с разной зоной охвата.
Менеджер продукта в принципе не может достаточно глубоко разбираться одновременно и в пошиве кресел, и в вёрстке печатных изданий, и в программировании контроллера внутри ЭБУ двигателя, и проч.
А насчёт существования - всё это существует только лишь для того, чтоб коммерческая организация получила прибыль от продажи продукта.
vadimr
28.05.2025 05:36А насчёт существования - всё это существует только лишь для того, чтоб коммерческая организация получила прибыль от продажи продукта.
Вы в целом всё верно излагаете, о с продуктовой точки зрения. В то время как совершенно необязательно получать прибыль именно от продажи продукта.
В частности, если рассматривать автомобильное производство, как проект, то результатом этого проекта является автомобильный завод, а не автомобиль.
А многие организации (и среди них подавляющее большинство ведущих сложные проекты) вообще не имеют продуктов в основном объёме реализации. Они получают деньги за услуги по решению задач заказчика.
Я лично имею более чем 30-летний опыт проектной разработки и определённые признанные обществом успехи в этой области, но за свою жизнь не участвовал в разработке ни одного продукта.
Хотя некоторые авторы относят услуги к продуктам, но это просто софистика.
Менеджер продукта в принципе не может достаточно глубоко разбираться одновременно и в пошиве кресел, и в вёрстке печатных изданий, и в программировании контроллера внутри ЭБУ двигателя, и проч.
Некто Киитиро Тойода, по образованию инженер-механик, считал, что руководить производством автомобиля может только тот, кто лично прошёл путь от рабочего на конвейере (цитирую не дословно, но по смыслу). К слову, инженерное образование дал ему отец, основавший Тойоту.
Директор АвтоВАЗа, с другой стороны, имеет экономическое образование. Поэтому Тойота терпит убытки, а АвтоВАЗ процветает. Но езжу я на Тойоте. В этом отличие продукта от проекта.
Flexits
28.05.2025 05:36Некто Киитиро Тойода, по образованию инженер-механик, считал, что руководить производством автомобиля может только тот, кто лично прошёл путь от рабочего на конвейере
Не пытаясь поставить под сомнение авторитет господина Тойоды, замечу лишь, что если вы попытаетесь пройти его путь в современном мире, то с большой вероятностью столкнётесь с проблемой "войти в айти в nn+ лет" и получите тонну гневных комментариев в стиле "крутил пол-жизни гайки на конвейере, вот и крути дальше, ишь выискался тут, пойдём за ряд Тейлора перетрём". Современное IT совсем не то же, что во времена Митника, Возняка и бума доткомов. Постоянные дискуссии на Хабре "стоит ли брать джуна
колхозана немытогобез красного диплома Физтеха и золота на олимпиаде по математике" лишь подтверждают. Путь от простого рабочего до управленческих высот стал очень длинным.В частности, если рассматривать автомобильное производство, как проект, то результатом этого проекта является автомобильный завод, а не автомобиль.
Это вы говорите верно. Но завод строится не как самоцель, не для того, чтобы быть. Завод – для того, чтобы производить продукт, который будет, продаваясь, приносить прибыль.
Иногда же сам завод является продуктом. Но здесь, опять же, возвращаясь к моему комментарию, вопрос иерархии и точки зрения. Для Альберта Кана завод – продукт, для И.В. Сталина продукт – автомобиль ГАЗ.
Они получают деньги за услуги по решению задач заказчика.
Это лишь вопрос терминологии. Лично я под продуктом понимаю некоторое законченное решение. Оно не обязательно материально, как автомобиль, но оно самодостаточно и отделимо от окружения, как приложение, или сайт, или фреймворк, например.
И снова это вопрос ракурса. Если производитель автомобилей поручает на аутсорс специализированной компании разработку программной оболочки - интерфейса для мультимедиа, эта оболочка – услуга или продукт? Я не знаю однозначного ответа.
vadimr
28.05.2025 05:36Не пытаясь поставить под сомнение авторитет господина Тойоды, замечу лишь, что если вы попытаетесь пройти его путь в современном мире, то с большой вероятностью столкнётесь с проблемой "войти в айти в nn+ лет" и получите тонну гневных комментариев в стиле "крутил пол-жизни гайки на конвейере, вот и крути дальше, ишь выискался тут, пойдём за ряд Тейлора перетрём"
Наоборот. Его путь очень даже приветствуется в IT. Он учился на инженера, а тем временем работал на заводе, крутя гайки (почти так же, кстати, начинал Экклстоун). Лучшие студенты-айтишники так и делают, работают джуниорами параллельно с учёбой, чтобы, получив диплом, быть уже твёрдыми миддлами.
И снова это вопрос ракурса. Если производитель автомобилей поручает на аутсорс специализированной компании разработку программной оболочки - интерфейса для мультимедиа, эта оболочка – услуга или продукт? Я не знаю однозначного ответа.
Коль скоро требования к ней выдвигает заказчик, беря на себя соответствующие финансовые обязательства, то это услуга.
Лично я под продуктом понимаю некоторое законченное решение.
Обычно принято считать, что результат труда сам по себе не является продуктом. Он становится продуктом тогда, когда обращается на свободном рынке.
Flexits
28.05.2025 05:36Он учился на инженера, а тем временем работал на заводе, крутя гайки (почти так же, кстати, начинал Экклстоун). Лучшие студенты-айтишники так и делают, работают джуниорами параллельно с учёбой, чтобы, получив диплом, быть уже твёрдыми миддлами.
Вы серьёзно не видите разницы между кручением гаек на заводе и работой разработчиком, пусть и с приставкой "младший"? Иными словами, между синим и белым воротничком?
Мнение г-на Тойоды имеет вообще противоположный смысл относительно вашей его трактовки. И, будучи выходцем из очень богатой семьи, Тойда не пошёл в джуны, как вы говорите. Он пошёл крутить гайки, т.е. на место простого рабочего. И говорил он о том, что перед тем, как примерять под себя уютное офисное кресло, и вершить судьбы людей, сперва выйди на улицу и побудь обычным человеком. То есть, экстраполируя на программистов, сперва постой за конвейером, собирая эти самые сервера, а уже потом изобретай программные продукты, которые будут изменять жизнь вот этих самых парней в цехах.
работают джуниорами параллельно с учёбой
Ну это тоже очень спорный момент, как и кем можно работать, если ты целый день сидишь на парах (и кому вообще такой джун нужен, при нынешних-то требованиях к ним). Или наоборот, как и чему учиться, если ты целый день на работе, а универ прогуливаешь.
Обычно принято считать, что результат труда сам по себе не является продуктом. Он становится продуктом тогда, когда обращается на свободном рынке.
А если свободного рынка нет в принципе, как с СССР или КНДР? А если свободный рынок есть, но продукт на этом рынке не обращается, как ракета с ядерной боеголовкой? Финансовые инструменты обращаются на свободном рынке – это продукт? Ядро Linux – это продукт? А драйвер видеокарты?
vadimr
28.05.2025 05:36Вы серьёзно не видите разницы между кручением гаек на заводе и работой разработчиком, пусть и с приставкой "младший"?
Серьёзно не вижу. Работа младшего разработчика является неквалифицированным трудом, не требует специального образования.
Иными словами, между синим и белым воротничком?
Воротнички тут вообще не причём. Если они в офисе работают (т.е. в непроизводящей сфере), то оба белые, а если на производстве, то оба синие.
А если свободного рынка нет в принципе, как с СССР или КНДР?
Нет и продуктов. Есть только овеществленный результат труда в виде товаров групп А и Б. Вы экономику социализма не изучали, что ли?
А если свободный рынок есть, но продукт на этом рынке не обращается, как ракета с ядерной боеголовкой?
Ракета не является продуктом, а представляет собой (относительно небольшую) часть услуги по выполнению гособоронзаказа. В более общем плане - по обеспечению безопасности государства. Она ничем не отличается по сути от службы офицера, откуда и возникает понятие военно-промышленного комплекса.
Финансовые инструменты обращаются на свободном рынке – это продукт?
Да.
Ядро Linux – это продукт?
Нет.
А драйвер видеокарты?
Нет.
Вот чтобы не сыпаться на таких вопросах, и предназначено инженерное образование.
Flexits
28.05.2025 05:36Работа младшего разработчика является неквалифицированным трудом, не требует специального образования.
И даже вакансию показать можете, где человека, закончившего 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 - это продукт.
Драйвер видеокарты - это продукт.
Финансовый инструмент - нет.
Инженерное образование и инженерия к вопросам менеджмента и экономики ровным счётом никакого отношения не имеет.
vadimr
28.05.2025 05:36Это неквалифицированный труд? Типа дворника, ага?
Конечно. Даже среднее специальное образование не требуется.
Рабочего - квантового оптика в миллион раз сложнее найти или обучить, чем такого программиста.
Ракета не является продуктом
Является. Более того, они продаются. Примерно так же, как и кирпичи или телевизоры. Только не на свободном рынке и не каждому желающему.
Вы не в теме. Причём, в отличие от вас, я участвовал в разработке ракет и понимаю, как устроена эта деятельность. На кирпичи и телевизоры это совсем не похоже. Например, сама по себе продажа ракет убыточна.
vadimr
28.05.2025 05:36Точнее, помню, был один драйвер видеокарты в виде продукта, SDD for OS/2. Но он недолго просуществовал в таком качестве, авторы продали исходный код IBM, и он продуктом быть перестал.
-
Renewal_Studio Автор
28.05.2025 05:36Для меня виртуализация такой же нюанс как для вас условный KPI
vadimr
28.05.2025 05:36Разница между нами в том, что я знаю и что такое KPI, и что такое виртуализация, и что такое контейнеризация. Кстати, я сдавал на сертификат PMI – там всего обучения в лучшем случае на месяц для человека с техническим образованием.
Renewal_Studio Автор
28.05.2025 05:36Я точно также знаю и волонтер PMI и готовлюсь к PMP, но это знание мне пока что не дало никакой пользы
vadimr
28.05.2025 05:36Мне тоже не дало никакой пользы, кроме KPI. Управление проектами даётся техническим опытом.
Renewal_Studio Автор
28.05.2025 05:36Не могу целиком согласиться, но определенно с большим опытом и насмотренностью можно многое решать и без знакомства с типовыми практиками менеджмента
budnikovsergey
28.05.2025 05:36продуктовый менеджер не должен уметь в инфраструктуру: его задача быстро разрабатывать и катить продукт, ценный бизнесу. А для технических знаний есть отдельные технические люди
vadimr
28.05.2025 05:36А причём здесь продуктовый менеджер?
budnikovsergey
28.05.2025 05:36при том, что менеджеры бывают всякие, а Вы их всех в своём комментарии уравняли и потребовали от них техскиллов инженеров инфраструктуры
vadimr
28.05.2025 05:36Речь вообще идёт про проектного менеджера, а не продуктового. Которому насрать на ценности бизнеса, его задача – достичь целей проекта.
Кстати, крупные проекты часто переживают несколько юридических лиц и уж тем более их ценностей.
opusmode
28.05.2025 05:36А зачем нужен менеджер, который не понимает, с чем он работает? Это буквально задача менеджера - организовывать работу. А как он будет её организовывать, если ничего не понимает?
Вы говорите о всех нюансах, но тут нет всех нюансов. ут буквально отсутствие базовых знаний.
Chelyuk
28.05.2025 05:36Да должен. Он не должен это уметь делать. Но знать разницу между двумя словами и разницу в стоимости и применимости для его проекта знать обязан. Контейнеризация дешевле в использовании, как по эксплуатации, так и банально по стоимости у облаков. Но, не все проекты можно делать на ней.
Renewal_Studio Автор
28.05.2025 05:36Окей. Тут я не готов говорить кто и что должен, однако лично сам ковыряю, чтобы не было стыдно, ибо вещи не рокет саенс
Ermowkin
28.05.2025 05:36Вы видимо не видели, что будет происходить если команда разработки/выделенный человек начинает делать изменения в "инфраструктуре" самостоятельно, но "без бюрократии". В конечном итоге будет хаус, выделенные мощности, будут "переиспользоваться" под другие проекты, часть будет висеть в "вечном" статусе ожидания, или "а вдруг понадобится". Не понятно будет, что критически важное, что нужно бекапить, что нет. Какие креды, кто владелец сервера, что на нем крутится и тд.
Что касается тикетов с точным описанием задачи, то почему под условную фичу, вы расписываете таск для разработки, а под инфру вы считаете, что это не нужно? Если девопс/инженер выполнит задачу как он понял из-за неполного/неточного описания, а в результате релиз не полетит, кто будет виноват?Renewal_Studio Автор
28.05.2025 05:36Я не говорю что нужен хаос, я лишь описываю случай когда бюрократией отгораживаются от решения проблем и это лишь один из примеров
Я тикеты всем ставлю одинаково подробно, как минимум описывая цель зачем это делается и критерии приемки с важным контекстом
Areso
28.05.2025 05:36Видимо, недостаточно подробно для ваших коллег из "DevOps", раз они возвращают вам заявки.
chemtech
28.05.2025 05:36Интересно увидеть пример вашей задачи в Jira и что написали когда вернули на доработку
Renewal_Studio Автор
28.05.2025 05:36С предыдущих мест работ боюсь не найду, но поищу есть ли что-то релевантное по смыслу, что я приносил devops
hyperwolf
28.05.2025 05:36Я не говорю что нужен хаос, я лишь описываю случай когда бюрократией отгораживаются от решения проблем и это лишь один из примеров
Бюрократия не на пустом месте возникает. Мы после пары простоев (я девопс да) по вине разработки, тоже внедрили бюрократию и нудные проверки идеи "фиганем миграции на проде в час-пик". Раньше прокатывало "мамой клянусь", потом мамы кончились. Бюрократия выросла, простой продового окружения снизился. Почти все довольны.
Renewal_Studio Автор
28.05.2025 05:36Прекрасно понимаю, сам стопаю релизы без ролл бэка и грамотного подхода к миграции. Правда вот сегодня был конфьюз, я настаивал на ближайшем релизе нового микросервиса и не принимал обоснования вида "ну там доделать еще надо", но когда влезли и выяснили что мы токены рефрешим не совсем корректно сейчас, без проблем сдвинули и план выкатки стали еще больше детализировать на все случаи
akod67
28.05.2025 05:36Ковбойские катки позволительны, но только при инфраструктуре, позволяющей тестировать их процентом трафика со всем соответствующими метриками. Нет инфраструктуры - значит очень строгий процесс деплоймента и тестирования, независимо от того, на сколько там пригорает у бизнеса.
Renewal_Studio Автор
28.05.2025 05:36Это то чего хочется добиться в целом не ради выкатки с плеча, а ради минимизации инцидентов и возможности быстрой проверки, работает ли оно вообще. Зацепить за минуту 10 пользователей не так страшно, если максимум что случится у них это инвалидация кеша
budnikovsergey
28.05.2025 05:36По опыту вот эти вот быстрые проверки на продах регулярно становятся причиной авралов, потому и реакция такая: все регулярно бьют себя пяткой в грудь "да ничего страшного, я сто раз так дома на ноуте делал" и оно регулярно же от такого сыпется из-за разных неучтённых моментов и банального человеческого фактора. Отдайте ответственность за доступность вашего прода вашему командному девопсу и тогда вы сами сможете управлять рисками и подобными тестами. Но хорошей практикой является выстраивание отлаженной цепочки релизов DEV->UAT->PROD, которую вы в любой момент можете быстро прогнать: тогда у вас сохраняется управляемость и появляется скорость.
Renewal_Studio Автор
28.05.2025 05:36Ну считать что катить что-то с миграцией и капитальным изменением бизнес-логики вот так идея априори плохая. Канарейка придумана для того чтобы для рисковых релизов огребать поменьше, а не для того чтобы катить релизы, которые сделали рисковыми из-за недоработок
privetbelka
28.05.2025 05:36Многое вполне может работать и не быть описанным, и довольно долго, когда это всё тянет один человек. Была система, которую на нескольких контурах вывозил разработчик и на другой работе были системы, где разработка стандартизировала подход к проектам, а девопс стандартизировал подходы, но не до маразма. Второй держится дольше. В условиях, когда ПМ или руководитель команды прилетал чаечкой тяжело было и аналитикам, и QA, и поддержке, а инфраструктура получала весь список негатива, как последняя по течению
zxspectrum128k
28.05.2025 05:36все эти проблемы сильно проще решаются, когда в компании есть общая курилка.
мне кажется там в неформальной обстановке у нас решались вопросы за 5-10 минут, которые через тикеты шли бы куда дольше.
visuospatial
28.05.2025 05:36соглашусь. сам тестировщик и часто общаюсь с разрабами во время перекура. часто закрываем какие-то вопросы во время разговора
Skiffspb
28.05.2025 05:36Смешно как то стало даже. Как девопс могу сказать, проблема с тем кто этих людей набирал, и кто ими руководит, вот и все.
Renewal_Studio Автор
28.05.2025 05:36Возможно. Я не прям чтобы очень знаком с хабром, но почему ваш комментарий был выделен отдельно я мог его отклонить или одобрить? Как это работает?
Skiffspb
28.05.2025 05:36Не в курсе )
Renewal_Studio Автор
28.05.2025 05:36Окей. А вы получается были в схожей ситуации?
Skiffspb
28.05.2025 05:36я давно в ит, по сути везде решает:
1. Хороший начальник. Простой пример, 6 лет работал в крупном ресторанном холдинге, все было супергут, все решали наперед, сменился начальник и все пошло под откос, тк ему плевать на кадры и он не в зуб ногой в матчасти
2. Кадры, часто встречал сисадминов, которые не понимают что их задача не быть "самыми умными", а обеспечивать работу, и не просто работу, а то как это ожидают (в пределах разумного, тут возвращаемся к начальнику, он решает политические вопросы). Принцип я сделал какнибудь, оно работает, и вам нужно прочитать инструкцию на 100 страниц, а то что вы просто хотите кнопку, так это ваши проблемы.
3. Интерес, часто встречаю людей, которым попросту не интересна их работа)
4. Коммуникация, она должна быть и должна быть выстроенна понимающими людми.
Как не крути, но работаем мы все за деньги, а эти деньги должны откуда-то браться, в разработке это пресловутый ci/cd, быстрее разработка, быстрее ттм, мы на коне, у конторы есть деньги => у нас есть зп и премии. Для того чтоб это работало, как раз и есть инженеры, которые должны быть проводниками команды разработки в инфраструктуру, и делать (в пределах разумного, тут возвращаемся к начальнику, он решает политические вопросы) эту самую разработку комфортной. По сути инженеры и разработчики это винтики одного механизма, суть которого выкатывать фичи и зарабатывать деньги). Для этого и нужно общение, миты и прочее, чтоб все были в курсе что происходит и не выпадали сильно из контекста.
Возможно мне везло с местами работы, а скорее всего так и есть. Я работал и 1 с несколькими командами, и командой девопс с несколькими проектами, в маленьких интеграторах, в крупном банке, подрабатываю на некоторых проектах. Гл всегда придерживаюсь философии девопс, и считаю что моя работа закончена, только когда продукт закрыт, т.е. снят с прома, до этого момента, я, разработчики и тестировщики 1 команда, задача которых постоянно развавать этот самый продукт.
У меня нет контекста именно по сабжу, т.к. не понятно, какая численность там отдела инженеров, сколько инфры, сколько команд разработки на эту инфру и отдел инженеров и т.п. Я просто описал то, что видел сам. Лично для меня, девопс это не про - был админом с виртуалками, стал девопсом с трубами и контейнерами, это про изменение непосредственно подхода, и самой роли инженера.Я не буду писать про регламенты, зоны ответственности и вещи в этом духе, это все везде индивидуально, и выстраевается непосредственно руководителями команд, на основе общих договоренностей. Если это не работает, то видимо договориться не смогли)
Renewal_Studio Автор
28.05.2025 05:36Мне дополнить нечего, у вас прекрасный комментарий и очень по делу. Я очень надеюсь на него кто-то, кого триггернул пост, наткнется и он многое для себя подчерпнет
ALapinskas
28.05.2025 05:36Как мы докатились до жизни такой, что DevOps это отдельные пафосные инженеры
Тут все зависит от команды, DevOps в принципе не при чем. Между любыми изолированными, но жестко связанными частями будет расти недоверие. К примеру, я работал в одной компании над Node.js приложением, команда была распределенная, почти по всем частям света — часть в США, часть в Европе и часть в России. Для удобства менеджер устраивал отдельные созвоны с частью из США и России, т.е. мы никогда не общались с ребятами из США, но кодовая база была общей, случались казусы и примерно также росло недоверие.
Renewal_Studio Автор
28.05.2025 05:36Действительно это так. И как вы верно подметили, надо бороться с изолированностью, для этого и написал статью
hyperwolf
28.05.2025 05:36Отдельный DevOps-отдел, отсутствие общей ответственности, дефицит коммуникации и поддержка сверху без баланса – это приводит к тому, что сервисная команда обособляется и начинает смотреть свысока на остальных, а те отвечают ей недоверием и неприязнью.
А нет хорошего решения. Все равно есть общая инфрастуктура, кто ей занимается? Плюс, привязанный к проекту девопс быстро становится круглосуточным дежурным по инфре данной команды, а потом - обновляет резюме. Особенно весело, когда днем ты привязан к команде, а ночью, во время дежурства, отвечаешь за всю инфру компании. В том числе и незнакомую из других проектов. Поэтому или надо 2 отдела, или один общий.
У нас достаточно жестко проседали сроки и я долго не мог понять в чем дело, пока на одной из встреч QA не пожаловались на то что сборки собираются медленно. Я открыл гитлаб и что я вижу - пайплайн тестовой сборки идет в среднем 35 минут. Отправился бить челом к devops и оказывается наши выделенные раннеры больше не наши, а общие, ибо так им удобнее.
Приходит менеджер и говорит - надо быстро. Приходит СТО / управляющих расходами и говорит - снижаем расходы. Приходится выбирать не в пользу быстроты сборок.
Для тестовых стендов действует жёсткий принцип: только DevOps могут создать или свичнуть окружение по заранее прописанным правилам
Вы не представляете, какое количество раработчиков/тестеров не компетентны в администрировании и какую дичь они могут накрутить, а потом затребовать это в прод, ведь они это накрутили быстро и самостоятельно в тесте.
Знаете, в чем проблеме? В том, что у вас все отделы не общаются между собой. И считают других чудаками. Вместо решения этих вопросов, вы воюете друг с другом, распыляя силы. Два отдела не знают специфику работы друг друга, но уже обвиняют других в бюрократии и нежелании идти навстречу.
Renewal_Studio Автор
28.05.2025 05:36Если бы мог поставил бы миллион лайков! Да, зрите в корень и ровно для того чтобы люди задумались об этом, написал эту статью
Renewal_Studio Автор
28.05.2025 05:36А как это работает у вас? Очень любопытен опыт, если был по бороьбе со схожими проблемами
hyperwolf
28.05.2025 05:36У нас отдельно команды разработки и отдельно девопс-отдел общий. Днем каждый из нас поглядывает одним глазом на "свои" проекты, но в целом, все - универсальные солдаты. Дальше есть ночные дежурства, и там уже ты за все вообще отвечаешь. Удобно тем, что ночью фичи никто не катает, тонкую специфику проекта знать не надо, а днем - есть знающий проект. Плюс, опять же, ночью поднимают и ответственного за упавший/проблемный сервис разработчика.
Еще в отделе по сути 2 руководителя - техлид и тимлид, через них удобно договариваться именно между отделами. Есть много дружеских и неформальных связей, многое решается напрямую, но для этого было проделано много работы. Раньше и у нас было "разрабы козлы" и "инфра козлы", но в какой-то момент это парализует работу. Изменения были сверху, с СТО. Он сумел запрячь все отделы в единую упряжку.
Но, пример бюрократии. Просят сделать миграцию на проде в базе, которая обрабатывает платежи. Или удалить индексы лишние, которых там прорва. Говорят, что все проверили. Мы, как инфра, выполняем запрос и оказывется, индекс был критически нужен, и на 2 часа пользователи столкнулись ну не с простоем прода, но с задержками, пока индекс в базе обратно строился. Потом ситуация через неделю повторилась - и после этого появилась бюрократия, углубленные тесты на копии продовой базы, планы отката, планы работ, согласования. Слишком дорого выходят такие простои.
Renewal_Studio Автор
28.05.2025 05:36Я восторге с некоторых комментариев, они крайне дружелюбные и по делу. Я бы хотел чтобы совместная работа в командах с devops и devops с менеджерами вызывала такие же ощущения, как после прочтения комментариев
Renewal_Studio Автор
28.05.2025 05:36А что у вас глобально поменял в позиционировании CTO, если не секрет?
chemtech
28.05.2025 05:36Добавьте пожалуйста в статью технические детали:
Используются ли облачные провайдеры или свое железо?
Используется ли Kubernetes?
Если используется Kubernetes, то какой? самосбор или managed решение?
Используется ли платный GitLab ?
Какие CI/CD инструменты используются для автоматизации сборки и деплоя?
Какие инструменты мониторинга и логирования применяются в продакшене?
Есть ли метрики Dora?
Как часто происходят релизы?
Какие метрики отслеживаются для оценки производительности приложений?
Используется ли helm?
Как организован incident management?
Пишите ли постмортемы?Соотношение кол-ва devops инженеров к разработчикам?
Может ли разработчик сделать самостоятельно review стенд?Renewal_Studio Автор
28.05.2025 05:36Уфф, я тут писал по опыту нескольких предыдущих компаний. Но могу по памяти написать (если что не в курсе всего и могу ошибаться)
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. Даchemtech
28.05.2025 05:361) Как может быть 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 стенд?
У вас микросервисы или монолит?
Компания относится к банкам или финансам? Есть ли персональные или банковские данные?Renewal_Studio Автор
28.05.2025 05:36Как я и говорил, все точно не помню
1. Там где было облако был менеджед
4. Да, про DORA знаю, а вот про аналитику MR слышу впервые, спасибо за рекомендацию!
6. Получается так
9. Дефолтные вещи с крашрейтом, перфомансом, инцидент рейтом и тд
10. Не припомню
Renewal_Studio Автор
28.05.2025 05:36Соотношение кол-ва devops инженеров к разработчикам?
Ту сложно, но думаю в районе 1 на 15
Может ли разработчик сделать самостоятельно review стенд?
В одном месте да, в другом нет
У вас микросервисы или монолит?
Микросервисы
Компания относится к банкам или финансам? Есть ли персональные или банковские данные?
В предыдущем случае к финтеху
THEOILMAN
28.05.2025 05:36Я вообще эникей фактически, отношения к разработке не имею, работаю на "предприятии" и половину написанного не понял естественно. НО вот вам взгляд считай со стороны - выглядит опус так, что это просто излагание частного случая и проблема локальная, особо не проецируемая на другие коллективы.
Наверно надо руководство ногтем потереть, вдруг татарин прячется именно там(с)
Renewal_Studio Автор
28.05.2025 05:36Да нет, я такого навалом видел и от коллег слышал, сперва прежде чем писать поспрашивал коллег и обнаружил +- схожее
zuffa
28.05.2025 05:36Если бы devops-инженеры не коммуницировали через сервис деск и вызов дежурного через команду в слаке, а потом не требовали детальной постановки, то сроки не были бы настолько безможно сорваны (1.5 дня на решение проблемы);А каким образом тогда предлагаете работать команде DevOps? Дать личный контакт девопса в тг, чтобы его ддосили вопросами в личку в любое время дня и ночи? Моя практика показывает, что есть разработчики и руководители разработки, которые любят поработать вечерами и ночами и если у них есть личный контакт девопса - не стесняясь пишут ему в 23.00 с проблемой невыкатки сервиса в stage. pre-production и тд. У девопсов есть и ифраструктурные задачи внутри отдела, которые не связаны с процессом разработки. Как их выполнять переключаясь на задачу со срочностью "критично" от менеджера, где в описание скриншот ошибки и больше ничего? Потратить свои 20-30 минут времени, чтобы понять о чем вообще речь идет? Почему-то менеджеры и разработчики очень дорожат своим временем, но при этом часто не уважают время девопсов.
Основные задачи - контролировать свободное место на дисках серверовВесело читать, что Вы считаете (напрашивается вывод о том, что разработка тоже) это главной задачей девопса, раз указали её первой. Возможно, проблема в вашей команде кроется где-то рядом.
Вместо фото аватарки и на созвонах не включают камеруСоглашусь с комментатором выше, что это личное желание человека, а не проблема девопса, да и как это влияет на рабочие процессы - непонятно.
Крайне рады в целом если созвона не будет или возможности с него уйтиА кто не рад? Только те, у кого работа - ходить на созвоны.
Если менеджер проекта не отличает виртуализацию от контейнеризации, DevOps-инженеры невольно начинают считать его бесполезным посредникомТут не соглашусь, никто не требует таких глубоких знаний от менеджера, но понимать что такое ОС Linux и как работает Интернет я считаю менеджер должен, в противном случае коммуникация по какой-либо проблеме действительно превращается в ад.
Рекомендации в конце статьи отличные, только вот есть проблема, что бОльший процент менеджеров и разработчиков не хочет вникать в инфраструктурные вопросы: на презентации не ходит, либо ходит и не слушает, документацию предоставленную девопсами не читает, вопросы по ней не задает, в тикете в поле "Тип запроса" пишут "Инцидент", а тикет о том, что надо новый сервис развернуть. Понятно, что всё разнится от команды к команде, я сам работал и с менеджерами и разработчиками, которые интересуются, как, что и где работает, читают доку от девопсов, умеют выстраивать общение и взаимодействие - в таких здоровых командах здорово работать, проблемы решаются моментально. Работал и с токсичными командами, где любой пук и чих в приложении - все стрелки на девопсов, бежим жаловаться СТО на девопсов. Так что исходя из Вашей статьи либо Вам не повезло с девопсами, либо девопсам не повезло с Вами ;)
Renewal_Studio Автор
28.05.2025 05:36Очень солидный и обстоятельный комментарий! Спасибо. Я думаю нам не повезло друг с другом в вопросах коммуникаций и они вполне себе решились не портя впечатлений друг о друге. Поэтому и решил написать эту статью
Destros
28.05.2025 05:36Интересно ещё, а аватарка на Хабре вместо фото это тоже ориентир на то, что человек ЧСВ, или все же нет?
Renewal_Studio Автор
28.05.2025 05:36Я наполнил статью кучей иронии и гиперболизации именно чтобы на это обратили внимание наконец. Нет, у меня вообще ник с времен когда была студия (лет 7 назад) и к сожалению не поправить, но поддержка переодически пишет что это должен быть корпоративный блог
Destros
28.05.2025 05:36Я тоже уже давно мастер лигу взял в Старкрафте, а аватарка так и осталось жалкой даймонд лиги
Pkgc
28.05.2025 05:36Господи, какая ахинея.
Из текста явно видна ситуация, что автор пытался примерить корону "менеджера по менеджменту", но был поставлен на место грамотным CTO: "1-3 штуки инженеров", "повадки", "Ощущение "пальцев веером", даже приписал свои собственные фобии всем: "любые попытки вмешательства воспринимаются как угроза, а дистанция между DevOps и остальными командами приводит к напряжённости и недоверию", "Интровертивные инженеры"...
Я - не CTO, я просто руковожу разными лидами в крупной компании. :)
Итак, по порядку."Общение почти исключительно через Jira-таски с детальными описаниями - неполные заявки сразу возвращают на доработку".
Да, так как именно PM имеют привычку, бросить на ходу какой-то кусок инфы, или пару слов в чат. Я даже не говорю о том, что человек может быть в тот момент занят - понятия DoR/цифровой след изобрели явно не для них."Еженедельные 20-минутные стендапы для планирования крупных работ по переездам, вне их встреч обсуждения считаются отвлечением"
А с чего вдруг автор (PM, судя по всему) решил, что он задаёт темп команде DevOps? Или он занимается их тайм-менеджментом?"Любая попытка изменить конфиги или Vault воспринимается как угроза стабильности и этоневашазонаотвественности"
Какие-то личные фобии автора."Slack-каналы - закрытая экосистема для обсуждения только релевантных вопросов. Обычно есть группы Infra, Core, Alerts и бот для дежурств"
И что же автора (PM) тут смущает? То, что ему некуда кидать кусок инфы в известном одному только ему формате?"Вместо фото аватарки и на созвонах не включают камеру;"
И что дальше? Автор, если бы PM попробовал бы в таком ключе обратиться к моему человеку, его бы ждал разговор короткий, но не факт, что приятный. Но конструктивный. Может быть, ваша работа - торговать лицом, но кто-то должен заниматься и архитектурно/инженерно/техническими работами."Крайне рады в целом если созвона не будет или возможности с него уйти. Если звать на созвон, на котором они считают что не нужны - идут жаловаться CTO"
И будут правы, и будет прав CTO, когда в конце месяца подаст руководству сводку со стоимостью трудозатрат на ненужные созвоны.
Вывод: автор, не "многие" думают, что DevOps - Гилфойл (кстати, классный, высокомотивированный и увлечённый специалист), просто вы сами - Бахман.
Renewal_Studio Автор
28.05.2025 05:36Я рад что пост привлек ваше мнение, комментарии относительно вашего анализа меня давать не буду
DarkHost
28.05.2025 05:36Понавылазило блин менеджерья в последние годы, которые понаслушались инфоцыган про то, как внедрение модных метрик, показателей и абревиатур сразу "запустит бизнес в космос". И "писают" в уши руководству, рассказывая, что они вот-вот сейчас все зарешают, и сделают компанию самой богатой в мире. Руководство обычно тоже из "альтернативных", которые "мы каждую минуту теряем миллионы, но на новогодние/майские удачно всем отдохнуть".
cross_join
28.05.2025 05:36Не раскрыта тема "как мы дошли до жизни такой", где стоимость создания и владения инфраструктурой может в разы превыщать стоимость ПО, для которого, собственно, вся эта инфраструктура и существует.
Renewal_Studio Автор
28.05.2025 05:36Ух, кстати хороший комментарий, эту точку зрения не раскыл. Можно ваш попросить чуть больше накинуть на этот счет?
cross_join
28.05.2025 05:36Тут несколько направлений, например:
распределенная архитектура ПО на порядок более дорога в разработке, развертывании и сопровождении, чем централизованная. Однако мало кого заботят даже простые обоснования такого выбора
облачная инфраструктура легко масштабируется, но стоимость владения в разы превышает on premises аналог. Однако, см. предыдущий пункт, каждый стартап считает, что завтра у него будет миллион запросов в секунду
"по умолчанию" используются "бесплатные" компоненты, прежде всего СУБД. Отсутствие знания продвинутых коммерческих продуктов приводит к раннему переходу на горизонтальное масштабирование и в итоге, многократно большим затратам на поддержку, несмотря на первоначальную экономию на лицензиях. Простой пример, производительность SQL Server примерно на порядок выше PostgreSQL (на CRUD ниже), там где можно обойтись одним-двумя узлами, придется делать десять реплик.
засилье Питона на бэкенде, производительность которого ниже на порядок даже Java, удивительным образом совмещается с заявлениями о высокой нагруженности.
Renewal_Studio Автор
28.05.2025 05:36Уххх, сильное напоминание пред-предыдущее место. На текущем у нас вместо бесплатной постгри кокроач, мне нравится
А как быстро масштабироваться в случае он премиса, если действительно смогли дать большой трафик?cross_join
28.05.2025 05:36В on premisis высокий трафик - редкое явление, если речь ведь о внутренней системе предприятия. Если речь о публично доступном продукте, то почти всё зависит от архитектуры ПО. Масштабирование тормозится не монолитностью, а наличием внутреннего состояния.
akod67
28.05.2025 05:36На счёт MSSQL vs postgress можно побольше деталей? Мы как раз наконец недавно пристрелили последний MSSQL и вздохнули свободней, так как и руки развязали, и косты уменьшили, и производительность подняли. Базы не петабайтные конечно, но и не совсем детские.
Renewal_Studio Автор
28.05.2025 05:36А что у вас за продукт? Просто на mssql обычно достаточно редко задумываются о переходе
akod67
28.05.2025 05:36Довольно популярный тревел. Проблема MSSQL в первую очередь - дорогая горизонтальная масштабируемость. В результате базы омоналичиваются, обрастают годовыми кольцами, со всеми вытекающими. Сам то движок мощный, но не дающий ничего такого, что оправдывало бы косты, по крайней мере на "обычных" объёмах.
cross_join
28.05.2025 05:36Что именно дороже в горизонтальной масштабируемости у SQL Server за вычетом того, что узлов потребуется в разы меньше?
akod67
28.05.2025 05:36Лицензия стоит заметных денег. Сам факт, что нужно выбивать заметный бюджет под новые инстансы сковывает руки по архитектуре и начинаешь обвешиваться слоями вокруг SQL, лишь бы этот вопрос не поднимать.
Ну вот с чего потребуется в разы больше инстансов постгреса? Очень сильно от профиля нагрузки зависит. Далеко не всегда вакуум проблема. На своём продукте мы нагрузку на CPU снизили в 2 раза с переходом на пострес. IO плюс минус такой же.
cross_join
28.05.2025 05:36Спасибо, картинка ясна. Если раньше приходилось выжимать из имеющихся CPU вдвое больше (и сервер справлялся), то теперь "гуляй, рванина!" можно плодить сколь угодно инстансов постгреса - он же "бесплатный", да... В смысле, за лицензии можно не платить, если работать с community версиями, а не с постгреспро или энтерпрайзДБ. А про постоянные издержки - да кто ж про них думает-то.
А выставили бы MAXDOP в 1 и была бы вам низкая нагрузка на CPU, прям как в постгресе, который уже 30 лет учится параллельным планам запросов.
akod67
28.05.2025 05:36У любого сервера есть свои лимиты, как бы не вылизывали базу, рано или поздно возникнет вопрос с горизонталкой. И вот тут начинаются нюансы. Реплики какое-то время выручают, но всё равно упираешься во write нагрузку. И приходится шардировать сами данные, причём по материкам. И вот тут MSSQL, как бы это сказать.... Натянуть сову и на глобус можно, но есть способы решать задачу более подходящими инструментами.
cross_join
28.05.2025 05:36Шардирование (распределенное по узлам секционирование) начинается с приближением к отметке "петабайт", что по вашим же словам, не ваш случай. Для начала нагрузка записи снижается (на порядки) прозрачным для приложений секционированием, которое, опять же, в SQL Server "из коробки" с 2005 года, а постгресу еще лет 10-15 догонять.
akod67
28.05.2025 05:36На много раньше. Как только потребуется локализация нагрузки на другом континенте.
И расскажите, как будете делать что-то уровня TimescaleDB на MSSQL
cross_join
28.05.2025 05:36Не путайте тёлое с мягким. Для геолокализации нагрузок с 2008 года "из коробки" есть geo cluster. Шардировать же, если мы одинаково понимаем смысл термина, начинают по другим причинам, прежде всего по объемам данных.
akod67
28.05.2025 05:36Я не принижаю MSSQL, я люблю его. У нескольких клиентов только он. Но вот есть задачи, где его притягивать за уши смысла просто нет никакого. В том проекте, где мигрировали на посгрес - всё что нас держало годами от миграции - были килотонны хранимок разной степени тухлости. И вот с появлением LLM - переписали основную кодовую базу за месяц.
есть geo cluster.
стоимость этого решения понимаете? главный вопрос - зачем? что бы было? У нас бизнес деньгами не сорит.
cross_join
28.05.2025 05:36Неподходящие модели данных задачи найдутся всегда, я их приводил в книжке, например с анкетированием на 100-1000 измерений. Если нужна работа с графами, то несмотря на поддержку таковых с версии 2017 в SQL Server, могут найтись более специализированные и лучшие платформы.
Мой поинт в другом: SQL Server превосходит постгрес по всем параметрам, по многим - с большим запасом. Это СУБД, основанные на реляционной модели данных. Поэтому обоснования, принимаемые в расчет - стоимость лицензий (без учета последующих затрат на поддержку) или политические риски.
И еще такой, очень частый ныне: начинали делать из говна и палок, ничего не знали о коммерческих решениях, теперь уже поздно.
стоимость этого решения понимаете?
Ну, а что же вы хотите, и рыбку съесть и ... Нет денег на энтерпрайз решения - у SQL Server 4 вида репликаций "из коробки" в самой базовой версии. Почти 25 лет назад делал на них "геокластер" на два континента. И ничего, работало
cross_join
28.05.2025 05:36Навскидку, оптимизатор запросов даёт примерно на порядок лучший результат (простой CRUD только в 2-3 раза за счет кластерных ПК), always on постгрессу пока даже не снился (реплики - это совсем другое, но и их в SQL Server несколько типов на выбор) как и прочая инфраструктура администрирования "из коробки". Обычно ваш кейс происходит из-за недостаточной компетентности в SQL Server и нежелании её иметь
akod67
28.05.2025 05:36Ну не надо тапками кидаться, с компетенцией порядок. Мы не упирались в MSSQL. Его цена была тупо необоснована нашим профилем нагрузки, а возможности роста сковывал.
budnikovsergey
28.05.2025 05:36производительность SQL Server примерно на порядок выше PostgreSQL
а сможете пруфы привести?
cross_join
28.05.2025 05:36budnikovsergey
28.05.2025 05:36Посмотрел ссылки. Никакого подтверждения тезису, что на одной и той же железке джоин пары таблиц с фуллсканом оракл будет делать на два порядка быстрее постгресса не увидел. Увидел обсуждение неких специфичных конкретных кейсов, которых может просто не существовать в куче мест и которые в случае возникновения решаемы самим владельцем сервиса несколькими разными способами.
cross_join
28.05.2025 05:36Решение проблем владельцем сервиса стоит денег этому владельцу. Соответственно, отсутствие проблем ничего не стоит. Вижу, что тема сложновата для вас, начните с простых кейсов типа кластерных индексов и CRUD, воспроизводимых на любой железке.
budnikovsergey
28.05.2025 05:36Вы точно честно сравниваете между собой стоимость инсталляции Оракла с его сертифицированным под него железом и стоимость решения на Постгрессах поверх чего попалось, где дельту можно смело вложить в Департамент Разработки Великолепных Решений и не остаться в накладе по итогу?
cross_join
28.05.2025 05:36Полагаю, "решения на постгресах поверх чего попало" должны продолжать жить в своем мире
Thomas_Hanniball
28.05.2025 05:36Статью надо было назвать "Пьяные бредни некомпетентного менеджера".
Сначала автор утверждает, что документация у DevOps плохая.
Документация - это гигантская папка .md-файлов во внутренней вики, где все описано максимально кратко.
Через пару абзацев он утверждает, что документация у DevOps очень классная и подробная, и что он очень завидует такой детализированной документации.
у DevOps достаточно детализированный технический роадмап миграций на новые версии БД, настройки датацентров и тд., а у команд это отдано на самотек. Немного, но нотку завести вызывает.
Затем автор утверждает, что фикс проблемы сразу на проде - это нормально и что 1,5 дня на фикс - это слишком много.
баг возник из-за кривого конфига Nginx, который правился по хорошему на лету. Если бы devops-инженеры не коммуницировали через сервис деск и вызов дежурного через команду в слаке, а потом не требовали детальной постановки, то сроки не были бы настолько безможно сорваны (1.5 дня на решение проблемы);
Но парой абзацев ниже, он возмущается тем, что DevOps делают всё быстро и это плохо, т.к. нет зрелых сервисных процессов, и что фиксы сразу на проде приводят к проблемам и нарушают принципы инцидент менеджмента.
Формализованные процессы воспринимаются как “бюрократия”, которую проще обойти, чем внедрять. В результате про построение зрелых сервисных процессов не вспоминают, а от инцидент менеджмента мы имеем только способ обнаружения постфактум. Зато быстро!
Так и хочется написать, да определись ты уже наконец, что такое хорошо, а что такое плохо. Ты же через каждые несколько абзацев меняешь своё мнение на прямо противоположное, как политическая проститутка.
Вполне естественно, что никто не хочет работать с таким менеджером и по любым вопросам его отправляют делать тикет, т.к. только так можно хоть как-то зафиксировать постоянно меняющиеся требования этой проститутки.
faqmoroz
28.05.2025 05:36Всю жизнь сидел на Хабре, даже не регистрируясь, а после этой статьи захотелось написать комментарий.
Однако нюанс ситуации в том, что баг возник из-за кривого конфига NginxИнтересно было бы узнать, кто в вашей разработке ответственен за конфигурацию nginx: devops, ваша команда разработки, другая команда.
Также методология scrum предполагает некоторого владельца продукта, которой в заданной области имеет право выбирать задачи и соответственно согласовывать изменения. Мне понятно желание пм везде и всюду пытаться приоритизировать свои фичи как самые главные, особенно обратившись напрямую к исполнителям, но если конфиги nginx например общие, я бы на месте devops тоже бы не стал по голосовому их править, потому что они также могут затронуть функционал других команд, а брать ответственность за потенциальные убытки бизнеса из-за голосового сообщения, которое нигде в системе разработки не логируется никто не захочет.
Renewal_Studio Автор
28.05.2025 05:36Прошу прощения, случайно нажал минус, промахнулся. В данном случае конфиг был у другой команды, но мы совместно катили изменения
faqmoroz
28.05.2025 05:36Эх первый же комментарий на Хабре и сразу минус.
Исходя же из скромного опыта, слияние множественных фич зачастую может ломать друг друга, что выявляется обычно на этапе тестирования. Совсем уж простые вещи отсекаются ещё на этапе слияния ветвей в системе контроля версий политиками, если не проходит сборка или автоматические тесты, остальное же требует внимания.
В идеальном мире, как мне видится, следовал бы немедленный rollback в случае возникновения ошибок на проде, что как раз скорее всего в ведении devops инженеров, а далее согласование конфигов с командой ответственной за них.
Вспоминая свой начальный опыт коммерческого программирования, попытка быстренько пофиксить релиз на горячую, обычно ведёт лишь к непредсказуемому поведению в других частях программы и переработкам в попытке все таки поднять релиз.
chupasaurus
28.05.2025 05:36Эх первый же комментарий на Хабре и сразу минус.
Такие вещи с положительной кармой я б не стал писать. /sarcasm
Renewal_Studio Автор
28.05.2025 05:36Зато на этот поставил! Странно что нельзя ставить -, +, + , по идее люди иногда могут промахиваться
opusmode
28.05.2025 05:36DevOps это метдология, а не роль. Запомните уже.
Есть специалисты по инфраструктуре. Они могут работать по разным методологиям.
Сборка и эксплуатацию могут происходить по разному, в разных компаниях. Например там может не быть дежурных, Service Desk и изоляции.
В общем статья какая-то хрень
Renewal_Studio Автор
28.05.2025 05:36Cпасибо за отзыв! Замечу что в статье часто идет обращение к специалистам как к devops-инженерам (хоть и безусловно не везде)
Destros
28.05.2025 05:36У меня одного сложилось ощущение, что автор не совсем понимает, кто такие devops? А их якобы devops - это так называемый шива, который должен уметь все и вся?
Как бы то ни было, по-моему опыту проблема в сроках при обращении к devops в том, что срок решения тикета ожидается вчерашним числом, а devops пока не изобрел машину времени. Почему-то никто не задумывается над тем, почему вообще на столь позднем этапе была выявлена та или иная необходимость.
Renewal_Studio Автор
28.05.2025 05:36Подскажите пожалуйста, исходя из чего у вас сложилось впечатление что они должны уметь все и все вообще мне что-то должны?
Destros
28.05.2025 05:36Из общего описания того, что от них якобы ожидается и какие задачи "в основном выполняют", если верить словам в статье.
Нет, я в принципе понимаю, что вы имели ввиду, потому что это распространенный кейс, когда на devops, помимо его основных обязанностей, навешивают всю инфраструктуру, вплоть до метрик свободного места на диске.
Увы, это только говорит о незрелости выбранного подхода такими организациями.
Renewal_Studio Автор
28.05.2025 05:36Ага, понял вас! Ну в целом если подумать, да, задачи весьма разнообразным. Особенно меня умиляет когда из devops-инженера пытаются сделать хранителя ключей и сикретов
kinsei
28.05.2025 05:36Вот когда будете отвечать за информационную безопасность, тогда и поймёте, для чего devops бдят за ключами и секретами, особенно если у вас нет отдельной команды ИБ или devsecops.
hellosamurai
28.05.2025 05:36К тому, что было высказано до меня, я бы хотел вот что ещё добавить от себя лично.
Большая проблема, что если с горем пополам чем занимаются программисты понятно, то объяснить чем занимаются люди ответственные за эксплуатацию для менеджмента сложнее. Вы не понимаете проблем и задач эксплуатации, поэтому вам и кажется, что они что-то делают неправильно, но в общем все ровным счётом наоборот.
В свое время я начинал один свой проект с того, что не было ни тикетов, ни малейшей бюрократии, по итогу триста человек начали звонить, писать, а то и ходить ногами. И при этом остальная работа никуда не исчезла. Это безусловно было очень удобно для моих коллег, правда вся моя работа фактически вставала, это вело к огромным переработкам, к необходимости бежать в два раза быстрее, чтобы двигаться вперёд, чтобы успеть все, при этом документально куда тратится моё рабочее время я ничем не мог подтвердить.
На хабре есть полно статей, где люди также пришли к тикетам, чтобы хотя бы как-то было возможно планировать работу, фиксировать задачи и отчитываться о результатах своей детальности. Это делается не из-за большой прихоти, не для желания отгородиться, а потому что жизнь заставила.
Renewal_Studio Автор
28.05.2025 05:36Это действительно так бюрократия нужна с определенного момента, это как процессный скелет компании. Повторюсь, я менеджер и для меня создавать разумную бюрократию, например отгораживая команду планом на 2 недели от неразумного переключения контекста, переработок и тд - основа работы. Однако тут я привел как пример возникающей стены как раз неуместную в моменте бюрократию
Лично мне в целом понятно чем занимаются devops-инженеры, хоть я и не очень силен в технической части
Renewal_Studio Автор
28.05.2025 05:36Но вот за остальных менеджеров не скажу. Как на ваш взгляд можно повысить вот эту долю понимания?
devops_sergeant
28.05.2025 05:36Тимлидю девопсов уже N лет. Статья - оторвана от понимания. Тимлид вменяемый все решит. У вас же явно перекос и общие уставшие девопсы. Которых дёргают. Проблема в организации, а не в процессах. Накидывать itil, itsm это бессмыленно
Renewal_Studio Автор
28.05.2025 05:36От понимания чего на ваш взгляд оторвана статья? Не совсем уловил мысль, поясните пожалуйста)
И что не так в данных случаях в организации?devops_sergeant
28.05.2025 05:36Вы увидели верхушку айсберга и пошли писать об этом. У вас есть 3 инженера, которые являются высокорисковыми активами, на которых повесили все риски. Добавим к этому то, что скорее всего все построено на костылях и архитектором и сто, которые в этом не шуршат, нет бюджета на рефактор автоматизации, а девопсы задрочены сразу всеми проектами. Ещё в догонку докинем местную бюрократию и тимлидов разработки, которые сразу бегут жаловаться наравне с сто. DevOps as a service? А бюджет у сервисного подразделения есть? А сами бюджет считали на свой проект для них, или пришли с криком "дай дай дай"?) Строить as service можно когда есть грамотный Лид и техлид, которые как раз находят ресурсы, чтобы не держать все на честном слове. Если есть три с половиной инженера, которые бегают каждый день между проектами и должны в голове держать сразу весь контекст, поддерживать прод и слушать какие они плохие, то проблема не в них. У вас целый спектр описан, почему в итоге девопсы запираются и играют в вашу бюрократию ещё сильнее.
Renewal_Studio Автор
28.05.2025 05:36Не совсем понимаю комментарий про верхушку айсберга. Я отрефлексировал прошлый опыт и решил привлечь внимание к теме, не более
На прошлом месте работы, если не изменяет память было суммарно порядка 35 devops-инеженеров, не считаю 5 их лидов, 2 проджектов и head of devops. Полагаю бюджет там также был выделен существенный
Renewal_Studio Автор
28.05.2025 05:36Мне как раз не нравится то что произошло в прошлом и я не хотел бы чтобы это повторялось и поэтому написал статью. Возможно кто-то, кто ее прочитает задумается, и у него не будет так плохо в коммуникациях
kinsei
28.05.2025 05:36Несомненно ITIL нужен, как и введение команд Operations (Service Desk) и R&D. У вас DevOps занимаются всем, только не тем, что эта методология предполагает.
Renewal_Studio Автор
28.05.2025 05:36Вероятно, но вот на последнем месте как раз оба направления были представлены, даже была сцепка L1-L2-L3
andreynekrasov
28.05.2025 05:36Дочитал до момента, когда sre задачи (бакапы, дежурства, мониторинг, в общем эксплуатация) зачем то начали приписываться девопсу. Автор, ты их путаешь.
RoasterToaster
Нецензурная лексика в заголовке это не слишком?
Renewal_Studio Автор
Вы правы, я лучше замажу часть слова. Однако это скорее маркетинговый ход. Я сам по образованию инженер и айтишник, и не отношусь ни к кому привратно, писал так скорее с целью привлечения внимания
RoasterToaster
Вы куда то торопитесь, пишете с ошибками, исправляете заголовки, наверное вы с вашими девопсами в противофазе:) вы импульсивный, а они наверное спокойные аки удавы и не любят суеты.
Если что, я такой же. И с педантичными сотрудниками часто в натянутых отношениях.
Renewal_Studio Автор
Я писал ее под ночь и вышла и правда не очень аккуратно. Если вы укажите на ошибки, буду очень признателен!
Люди не постоянны, я например сейчас уставший и несколько на надрыве делаю многие вещи, однако после хорошего сна последовательности в действиях и спокойствия гораздо больше
RoasterToaster
Да ну по мелочи, я же не из этих самых! (но превратно пишется через Е, DevOps-м*даки - два пробела возле тире, инчае это одно слово, две заглавные буквы в подписи к картинке тоже бросились в глаза )
Да кого я обманываю, я - зануда.
Renewal_Studio Автор
Я признателен за то что есть такие люди, так как это заставляем меня быть внимательнее и расти над собой. Видели бы вы мои первые посты в тг...
RoasterToaster
Ну! За рост над собой!
1dNDN
Теперь совсем другое дело! Вы заменили одну букву на звёздочку и слово перестало быть обсценной лексикой. Теперь никто не догадается, что там было написано!
Renewal_Studio Автор
На хабре большое количество статей, которые содержат в названии слово мудак или в описании слова похлеще. При этом я не называют devops мудаками и скорее статья на целена на то чтобы если кто-то их таковыми считает - перестали это делать
Renewal_Studio Автор
Однако если у вас есть комментарий как улучшить название, я буду только рад ему!
Renewal_Studio Автор
Я поправил название чтобы не задевать никого, что-то я сгоряча написал такое название