Три года назад в группе компаний ЦФТ задачи бизнеса потребовали увеличения штата разработчиков в два раза. Перед отделом эксплуатации встало две задачи: не допустить линейного роста OPS и уменьшить TTM, не потеряв при этом в недоступности, непрерывности и безопасности.

В результате в компании теперь есть всё — и NoOps, и DevOps. Где-то пришлось пойти на компромиссы и доработать концепт NoOps напильником под себя. Сергей Бердников, руководитель отдела эксплуатации, сегодня расскажет, что получилось, и разберет — почему.

С одной стороны, мы — банковский сектор, и у нас есть много рисков при внедрении новых технологий. Мы всегда были серьёзными банковскими ИТ-шниками: Oracle, Solaris, серьёзный монолит, процедуры в процессинге.

С другой — мы, конечно, менялись и распиливались, активно внедряли стек с Kubernetes. Хотя какое-то время у нас ходил прикол, что мода писать код в базу вернулась, а мы уже в тренде — 20 лет так делаем.

Расскажу, как мы вписались в процесс NoOps с одновременным увеличением у нас числа разработчиков. Для тех, кто предпочитает смотреть — видео моего выступления на конференции HighLoad Весна 2021. 

Запросы vs Люди

Дисклеймер. Я не могу взять точное количество персонала в компании. Это округлённые данные, которые плюс-минус коррелируют.

На графике видно, что количество Ops у нас за три года почти не менялось, а количество разработчиков росло и к концу 2020 года подошло к 500. Мы считаем нашу нагрузку в двух параметрах: запросы на обслуживание и запросы на изменения. В целом видно, что первые хорошо росли, а вторые — не так активно. Расскажу, почему так.

Запросы на обслуживание

Простая история — чтобы, например, получить доступ к базе данных — у нас всегда начинается с заявки от человека. И нам нужно было сделать этот процесс удобным. Потому что когда людей у вас становится больше, эта история растет пропорционально.

Чтобы решить это, мы просто вложились в разработку системы Cft-Automation.

Cft-Automation

Эту систему мы сами написали и сами поддерживаем. Одна ее часть — это фактер, который собирает информацию о продакшн: какие есть сервера, таблицы, базы данных, namespaces и приложения в Kubernetes. Данные передаются в аналитическую систему, откуда любой ваш любимый трекер может её забрать и отдать пользователю.

Вторая часть Cft-Automation — огромное количество роботов, которые смотрят на уже созданную заявку. Заявки мы полностью параметризировали,  поэтому роботы их легко могут выполнить.

Мы начали внедрять систему в 2019 году, и сейчас из наших средних 400 запросов в месяц 95% делают роботы. На графике это видно. 

Поддержкой этой системы занимаются полтора человека, которые постоянно её оптимизируют. Да, в целом получается, что это оверхед и много-много Python. Но в нашем масштабе это оправданно — мы спокойно это делаем, зная, что вся команда счастлива, потому что им не надо делать рутинную monkey-работу.

CFT-Aprover

С запросами на обслуживание у нас  связана также безопасность. Чтобы его выполнить, нам надо пройти три этапа согласования. Для этого в ЦФТ есть две отдельные службы безопасности, потому что они друг друга перепроверяют. А третий ОК нужно получить от ответственного за сервис.

Мы долго думали, что с этим делать — Time to Market с этой историей не вырулит. И разработали другую систему — CFT-Aprover. По факту это acl’ки с нашими прикладными терминами, где мы перевели политику ИБ в наш прикладной язык. Сейчас у нас любое изменение проверяется двумя разными наборами правил от двух разных безопасников.

Заявка с такой автоматизацией выполняется за 15 минут, при этом 30% всех запросов автоматически подтверждается, 5% — автоматически отклоняется, а 65% пока разбирается людьми. В наших планах автоматизировать 60-70% запросов, и это реально повлияет на TTM. 

Но с запросами на изменения всё не так просто, потому что любые изменения сталкиваются с людьми. 

Запросы на изменения

В этой группе у нас все запросы по установке версий, изменению конфигурации и всё то, что не описать запросами на обслуживание. С ними получается не так гладко, так как у нас  500 разработчиков — они все разного уровня, а команды — с разным бэкграундом. Почти невыполнимо обучить всех одинаково работать на проде, как в компаниях с 20 разработчиками. 

До 2017 года у нас работала простая схема. Разработчик писал приложение. Потом инженеры DevOps собирали все изменения, используя CI и CD. После чего передавали в operations, которые отвечали за изменения и накат. Любые изменения у нас всегда делаются в две руки — один делает, а другой проверяет. Для этого была (и есть) отдельная служба саппорта. И в конце этого цикла она проверяла что Ops правильно изменение накатили и всё работает. 

В результате на продакшене случалась магия, и такая схема достаточно долго работала. Но когда мы стали масштабироваться, то поняли, что это узкое горлышко. Этот пайплайн не даст нам переварить то количество изменений, которое мы хотим. И, конечно, еще важно не потерять качество этих изменений.

Так у нас родился новый концепт. Идея была достаточно простой, поэтому казалась нам красивой. 

На его основе мы разработали такой же простой и красивый план — найти компоненты в опенсорсе, которые заменяют этих людей.

После чего собрали всех разработчиков на его презентацию. И тут начались первые спецэффекты. Все люди разные, и все по-разному отреагировали. Саппорты сказали: «Ребята, неконтролируемые изменения на продакшен нельзя!» Разработчики возмутились: «Опять какая-то фигня! Зачем вы напрягаете нас лишней работой?»

Безусловно, в таком масштабе всегда есть парочка людей, которым интересны изменения: «Прикольно! Можно пощупать, посмотреть». Мы решили начинать именно с них, понемногу встраивая их в процесс. А дальше уже получая фидбек, начинать масштабировать на всех.

Мы собрались на конструктив после презентации, и у нас образовалось 4 вопроса. Первым был: «Кто будет отвечать за СУБД?» С резонным объяснением: «Я выкатил, я не знаю вашего MySQL и какие там индексы. Я могу отвечать только за свой код».

Вторым вопросом стал: «Кто отвечает за бэкапы?» С точки зрения разработчика непонятно было, зачем нужны бэкапы и мониторинги с алертами. У людей не было понимания, и это было нашей ошибкой, что мы не донесли им ценность всей этой истории. 

Следующий вопрос был: «ОК, вы нам дали на наше приложение мониторинги и логи. А как мы узнаем, что стало со смежным сервисом, если мы за него не отвечаем?» И вдобавок к нему: «А как мониторить, дежурные у всех или как?»

Мы стали менять нашу структуру.

Изменения в структуре

В Ops мы выделили группу Infra, которая ответственна за весь стек: хоть за Kubernetes, хоть за доступы, хоть за бэкап, мониторинг, и СУБД. В целом они отвечают на любой неизвестный алерт, который получила система. Если не знаем, кому прислать, то шлем им. 

Для усиления компетенций и унификации стека мы перевели большую часть DevOps  инженеров в команду OPS, организовав группу DevOps. К тому же  когда у вас 500 человек, для изменения процессов реально нужен «каток». Один человек в разрозненной команде к сожалению, не может изменить тулинг и процессы — один в поле не воин. Остальные devops осталась в команде разработки, они и сами очень эффективно решали задачи, здесь мы руководствовались принципом «Не трогай то, что хорошо работает». 

На Sup оставили контроль и мониторинг, помимо этого они читают код, понимают структуру приложений и баз данных, но они не имеют права ничего изменять, в отличие от Ops. Dev готовили изменения. А на группу DevOps возложили переподготовку по middleware — изучить новое ПО и разобраться, как оно работает. Они действуют теперь как менторы, помогая с СУБД, очередями, любыми middleware, cd и ci.

Вторым шагом в ответ на все вопросы разработчиков мы стали менять зоны ответственности.

Как поделены полномочия

Самое простое в этой схеме — мы разработчиков по правам приравняли к DevOps . Разработчик у нас теперь — внутри себя безусловный DevOps, он должен сам разбираться, как его приложения доставляются до продакшена . Мы это как мантру повторяем, хотя это изменение долго внедрялось.

После этого мы разделили стек на критический и некритический. Обычно в банковской сфере есть критический сегмент PCI DSS с карточками, персональными данными и другой банковской тайной, и есть сегменты, к которым требований меньше. Для критичного стека мы добавили разработчикам понимания — дали посмотреть мониторинги,  чтобы они понимали, как их приложения ведут себя в бою. Они реально заинтересовались! Сейчас бывает, что разработчики пишут в 9 утра в пятницу: «Что-то на продакшене не так! Давайте посмотрим внимательно!». Мы сами не ожидали этот профит.

Мы также разделили приложения на «ядерные», которые нельзя шатать и доступ к ним ограничен — это тоже отнесли к критичному стеку. И на приложения, которые можно спокойно трогать и нет импакта на весь комплекс от проблем с ним. Зачастую это все новые микросервисы написанные недавно. В критичных приложениях весь стек поставки мы автоматизировали — приложение может накатиться на продакшен без человека, мы дали кнопку «Deploy»  сотрудникам   сопровождения.  Теперь они  сами выкатывают изменения на наши критические компоненты, но в случае очень важных изменений привлекают сотрудников  группы infra.

В не критичном стеке мы дали эту кнопку командам разработки. Они также видят все мониторинги, могут нажимать эту кнопку и реагировать на изменения. Но им мы не дали полный алертинг. За весь алертинг с продакшена до сих пор отвечают две команды — Infra и Sup. А разработчики только смотрят в мониторинги во время наката, всё ли хорошо. 

Такое деление на крит / не крит позволило получить гибкость в накате приложений и при этом остаться в рамках законов по персональным данным, а также уменьшить риски для всего комплекса. 

Что из этого получилось?

Коллективная безответственность

Когда разработчикам дали права и у нас везде стал DevOps, то они стали творить разные веселые и прикольные истории.

Много было детских ошибок от разработчиков, но в целом это было не критично, лечилось все легко, хоть и о не всегда быстро. Основной труд был — донести мысль, что так делать нельзя и вредно, потому что количество хаоса в продакшен-среде значительно выросло. Приложений в боевом кластере — тысяча, а в команде ops’ов 10 человек. Раньше каждая ops-команда знала все свои приложения в лицо, а теперь стало непонятно: «Что это за новое название? Что это за Пушкина выкатили?»

Но если говорить про ключевые показатели, то недоступность и непрерывность стали страдать. С точки зрения бизнеса выполнялись все требования при выкатке приложения, оно в бою, деньги зарабатываются. Но с точки зрения недоступности ничего не было выполнено — не было бэкапов системы, мониторинги непонятно как были настроены, про страшное слово «перцентиль» мы вообще не слышали. Понятно, что недоступность сервиса никак не измеряется.

Мы стали активно бороться с проблемой, так как любое не критичное приложение может в один прекрасный момент стать мега-критичным, а подход «Давайте все признаем критичным» — нам не подходил.  

Снижаем градус проблемы

Понятно, что для простых историй поможет база знаний. Метод рабочий, но в нашем случае слабый. Нельзя надеяться на сознательность людей, когда их много — всегда найдется несознательный. Конечно, мы выступали, проводили техтолки и рассказывали про то, как правильно делать. От этого тоже был профит, но самым эффективным оказался  метод автоматизированного контроля выкатываемого кода инфраструктуры. 

Мы стали использовать опенсорсное решение OPA — следующая его реинкарнация GateKeeper v2 — чтобы описывать политики: как ваши helm charts  должны выглядеть и реализовываться. Это не статья в Вики, а код, который проверяет реализацию того, что хотят выкатить наши разработчики в соответствии с нашими лучшими практиками. 

Это действительно начало нас спасать и мы стали лучше контролировать и понимать что происходит в нашем продакшене.  

Infra: on-call rotation

Но мы не смогли избежать роста численности Ops, которые нам потребовались для мониторинга. Потому что у нас происходит непрерывная поставка новых мониторингов, и все — изначально критичны. Хотелось бы автоматизировать всё, но инциденты автоматизировать нельзя — они сыпятся один за другим. 

Раньше у нас человек одну неделю выполнял заявки с трекера, а на следующей отвечал за мониторинги. Нам потребовалось в on-call rotation внедрить третью неделю, чтобы человек после недели дежурства по инцидентам выходил и разбирал все тесты мониторинга которые срабатывали на его неделе дежурства. После чего принимал решения о правильности срабатывания и критериях тестов. На этой же неделе он занимался постмортемами.  

Для этой работы нам потребовался +1 Ops.

Заключение

У нас случилась очень странная история: DevOps, как культура, стал разваливаться. Раньше для выкатывания изменения мы собирали с командами разработки и обсуждали насущные проблемы, искали пути решения и подходящие инструменты. Но когда мы дали им возможность работать самодостаточно, стало теряться чувство локтя, люди стали отдаляться друг от друга, появились невидимые стены. Неожиданно оказалось, что DevOps, как процесс и культура, при высоком уровне автоматизации начинает деградировать. Мы очень долго эту историю исправляли, и все еще находимся в процессе.

Конечно, NoOps не должен отменять DevOps, но он повлиял на взаимодействие с разработкой. Многие наши достижения с точки зрения выстраивания процессов взаимодействия с разработкой были отброшены назад. Плохо это или хорошо, не знаю — наверное, это эволюция. Что будет дальше, посмотрим. 

Из этой истории мы вынесли, что когда разработчик самодостаточный, то повышается безопасность и общая производительность команд. Это уменьшает ttm, но приносит и побочные эффекты. В целом для нас это был позитивный и полезный опыт и результат. Обучайте своих людей всему в каком-то необходимом масштабе, и тогда вам не придется искать DevOps’ов с непонятными зарплатами и раздувать штат в десятки раз.

В этом году нас ждёт ещё два HighLoad++: 20-21 сентября в Санкт-Петербурге и 25-26 ноября — в Москве.

Питерское расписание уже готово. Билеты можно купить здесь. Не забывайте, что скоро очередное повышение цен.