- Регистрация
- 23 Август 2023
- Сообщения
- 2 818
- Лучшие ответы
- 0
- Реакции
- 0
- Баллы
- 51
Offline
Вместо интро
Я думаю каждый сотрудник IT-компании, где есть эта выделенная роль, особенно проектный менеджер, сталкивался с этим: есть отдельный мир конфигураций и скриптов, где изолирована коммуникация и технический тикет основное средство общения. Обычно CTO ставит их под свой колпак, изолируя от остальных команд и создавая эффект “касты избранных”. Простые запросы превращаются в бесконечные уточнения, а работа стоит в ожидании“благословения”. Я уверен, ты догадался о ком я.
Предупреждение: пост пронизан ироний с целью привлечь внимание к проблеме, а не очернить кого-то
Этот пост у меня зрел давно. И решил таки его написать когда размышлял, а почему всякие аджайлы часто не заводятся у компаний. Кейсов релевантных истории было полно, но вот два моих любимых:
Мы жестко сорвали релиз супераппа на важное гео из-за критичного бага. Причем в случившимся есть мой косяк как менеджера - я не составил полный план выхода с роллбэком. Однако нюанс ситуации в том, что баг возник из-за кривого конфига Nginx, который правился по хорошему на лету. Если бы devops-инженеры не коммуницировали через сервис деск и вызов дежурного через команду в слаке, а потом не требовали детальной постановки;
У нас достаточно жестко проседали сроки и я долго не мог понять в чем дело, пока на одной из встреч 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 изолируются
Очень красноречивая ветка на реддите про это: View: https://www.reddit.com/r/devops/comments/1k5a862/devops_why_are_you_guys_so_annoying_and_full_of/
Как мы докатились до жизни такой, что DevOps это отдельные пафосные инженеры
Продолжатиле сисадминов и идей SRE
DevOps вырос из противостояния: разработка гнала фичи, админы держали прод на замке. Концепция возникла как мост между этими мирами, но на практике стала эволюцией старых сисадминских привычек - главное, чтобы не падало, а всё остальное вторично. Можно нанять универсала которые и на связи 24/7 и сможет жонглировать всем зоопарком тех ландшафта один.
Когда писал наткнулся на отличную статью, очень советую https://www.everythingdevops.dev/bl...devops-and-its-impact-on-software-development
Забавно, что многие компании восприняли DevOps как чисто техническую роль — «новый сисадмин, только со скриптами»
Спрос только за аптайм и восстановление
Метрики успеха для DevOps обычно предельно просты:
аптайм (uptime)
среднее время до восстановления (MTTR)
иногда - скорость отката к предыдущей версии (если гитлаб на premium-плане, можно удобно мерить)
Успех оценивается не по тому, насколько удобно работать другим командам, а по отсутствию аварий и стабильности сервисов. Отсюда и недоверие ко всем внешним «инициативам», особенно если они могут помешать стабильности. Сценарий классический: если всё работает - лучше ничего не трогать.
Процессные практики не транслируются
На всех популярных roadmap’ах для DevOps, том же https://roadmap.sh/devops блоки про процессы, ITIL, ITSM и CMDB обычно где-то в самом низу —- если вообще есть. Прокачка идёт по Linux, CI/CD, Docker, Kubernetes, облакам, мониторингу и скриптам, а вот про ITSM или Service Line редко кто вспоминает. Формализованные процессы воспринимаются как “бюрократия”, которую проще обойти, чем внедрять. В результате про построение зрелых сервисных процессов не вспоминают, а от инцидент менеджмента мы имеем только способ обнаружения постфактум. Зато быстро!
Про хайп и элитарность я опущу, кажется это уже проходит, как и в целом “золотая эра IT” как “особенной” сферы. Хотя я помню как писались такие статьи в свое время… https://habr.com/ru/articles/469277/
Бесполезные передасты
Это я про то как выглядят проектные менеджеры часто.
На мой взгляд причины конфликтов между devops-инженерами и проектными менеджерами (упуси боже скрам-мастерами) лежат сугубо в этих 3 плоскостях:
Противоборство целей
Менеджер фокусируется на попадании в ожидания заинтересованных лиц, а DevOps на стабильности инфраструктуры, автоматизации и частоте выпуска (но не всегда про последнее). Эти цели явно вступают в конфликт, особенно когда надо в сжатые сроки
Каждое изменение для DevOps - это буквально failure, риск падения стабильности, поэтому у Ops-команды естественное стремление замедлить и тщательнее контролировать выпуски.
Неприязнь к бюрократии
DevOps-культура!!!! зародилась в инженерной среде, а там ценят автоматизацию и сниженение участия человека, поэтому традиционные менеджерские практики (регламенты, миты, отчеты) воспринимаются как бюрократическая шляпа.
Обычно девопсы - это бывшие сисадмины или разработчики, не горящие энтузиазмом от Scrum-ритуалов или документации. Если проектный менеджер настойчиво требует от DevOps-команды следовать формальным процессам это типично провоцирует агрессию. Интровертивные инженеры часто избегают чрезмерной коммуникации, а тут их заставляют “играть по правилам” Agile, ага, щас.
Критика компетентности менеджеров
Поскольку работа DevOps требует изрядного уровня технического погружения, многие инженеры скептически относятся к людям, не обладающим таким же уровнем техглубины. Если менеджер проекта не отличает виртуализацию от контейнеризации, DevOps-инженеры невольно начинают считать его бесполезным посредником
Последствия для бизнеса
В целом более подкованный товарищ все изложил тут https://habr.com/ru/companies/moex/articles/594509/, но я повторюсь:
Пока DevOps-барьер стоит непроходимым, Lead Time и Time-to-Market медленно, но верно растут → конкуренты выкатывают новые фичи быстрее, а мы зависаем в бесконечных согласованиях
Для проектных менеджеров это превращается в марафон эскалаций и попыток пробиться сквозь джиру → в какой-то момент выгораешь и перестаёшь верить, что можно договориться по-человечески
В командах накапливается раздражение: каждое новое обращение превращается в мини-конфликт, где уже не задача обсуждается, а воюют за территорию и ресурсы
В конечном счёте компания теряет и в скорости, и в качестве → срываются сроки, страдает пользователь, и вместо движения вперёд все буксуют на ровном месте
Зато можно выступить на DevOps Days с кейсом нового витка развития IaC.
Рекомендации по взаимодействию
Идите на встречу друг другу.
Проектным менеджерам и вообще менеджерам
Не бойтесь подтянуть базовый системный дизайн и разобраться, как устроена ваша инфраструктура - это проще, чем кажется и сразу сокращает количество недопониманий. Когда вы говорите на одном языке это приятно. Хорошая книга https://www.litres.ru/book/aleks-suy/system-design-podgotovka-k-slozhnomu-intervu-67193183/
Найдите время и честно попросите DevOps провести вам экскурсию по техландшафту компании: как работают основные сервисы, где лежат ключевые конфиги и тд. Возможно даже вы поймете только четверть. Но даже один такой разговор снижает предубеждения
Ведите в Confluence FAQ или просто небольшой справочник по инфраструктуре, а ещё хотя бы раз в месяц устраивайте «дни открытых дверей» - собирайте коллег, рассказывайте и отвечайте на вопросы про то, как и почему у вас всё так устроено
В таск-трекерах почти всегда можно настроить шаблоны задач: пусть любой запрос к DevOps проходит по чёткому брифу с ответами на ключевые вопросы (версия сервиса, окружение, цель запроса и т.д.). Это не только облегчает жизнь DevOps, но и позволяет автоматически выставлять SLA по каждой категории - прозрачнее, быстрее, честнее для всех
Следите, чтобы в развитии DevOps-инженеров появлялись не только новые «технические игрушки», но и хотя бы базовые процессные компетенции — понимание ITSM, навыки коммуникации и сервисное мышление для внутреннего клиента.
И, кстати, самим CTO полезно хотя бы раз пролистать руководство по ITIL 4, чтобы не превращать свою инфраструктурную команду в касту брахманов
Я не знаю кто автор этого чуда, но вот нашел папку про ITIL и там много на русском https://disk.yandex.ru/d/NgmkI3yYY4p1bA
Вместо послесловия
Порызмышляв, я пришел к выводу что образ “высокомерного DevOps” – не вымысел, а следствие конкретных организационных ошибок и культурных перекосов.
Предугадывая комментирии я не только размышлял, но и поообщался с парой банков и телекомов.
Отдельный DevOps-отдел, отсутствие общей ответственности, дефицит коммуникации и поддержка сверху без баланса – это приводит к тому, что сервисная команда обособляется и начинает смотреть свысока на остальных, а те отвечают ей недоверием и неприязнью. Для продуктовой компании это крайне опасно: вместо паверапа Dev и Ops мы возвращаемся в эру кабинетных войн. Те же яйцп, только в профиль
Цель этой статьи - не очернить всех DevOps-инженеров (среди них множество отличных командных игроков), а привлечь внимание к этим тревожным сигналам.
