Devops культура: мифы и реальность

В конце прошлого года я выступал на конференции с докладом на эту тему. Мне не известно когда будет запись этого выступления и будет ли она вообще, но мне было интересно оцифровать презентацию и сделать из нее статью, которую вы сейчас читаете. Уточню, что мифы я здесь рассказываю общие, а реальность свою, и конкретно свой опыт в управлении привлечением Tinkoff, где я исполняю роль CTO последние годы. Причем я сначала рассказываю мифы мифов, а к концу статьи добираюсь и до реальности.

Update

Мифы

Среди мифов я выделил самые интересные и вкусные. А потом я сгруппировал их по темам, которых получилось 3

  • Who
  • What
  • How

Who

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

What

Для более консервативных компаний термин devops может быть просто ребрендингом для старых добрых понятий типа ITIL/ITSM. С учетом моих ограниченных знаний ITIL’а кажется, что это далеко от реальности:)

Самые скептически настроенные люди отвечают, что devops — это просто buzzword слова относительно культуры и всего остального нематериального, о чем легко говорить и сложно измерить.

How

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

Вторые ребята— это консультанты с модными технологиями. Например, такие, которые, приходя в любую компанию, говорят, что проблемы были из-за того, что раньше велосипеда (k8s) не было. А вот когда этот инструмент появится, то заживете:) Интересный подход, но не слишком рабочий.

Третьи — это консультанты, которые пытаются забрать процессы разработки целиком себе на аутсорс. Зачастую рассказывая, что у них devops-подходы полностью реализованы:)

А еще есть вариант, когда некоторые крупные компании целиком выкупают части других компаний. Например, когда выкупается департамент devops из одного банка в другой.

Реальность

В рамках такого подхода современная разработка обычно движется в сторону того, чтобы распилить монолит на микросервисы, производя которые можно легко показывать инкрементальное увеличение объема функционала. Так как сложность в этом случае смещается в сторону operations, то происходит разделение it-команды на команду разработки и инженерную команду. Команда разработки отвечает за написание кода, а инженерная команда, которых иногда называют yaml-инденерами, помогает с рантаймом приложений и настройкой CI/CD пайплайнов. Зачастую эта инженерная команда работает уже с *aaS уровнем, например, используя сервисы типа GKE, которые закрывают нижнюю часть it пирамиды Маслоу. Также эти команды помогают со стандартными инструментами для логгинга, мониторинга, service mesh (забавно, что обычно это есть в fully managed сервисах, но стоит обычно слишком дорого). Также эта инженерная команда помогает с настройкой CI/CD систем и отвечает за их operations.

Потом проходит немного времени и команда разработки тоже разбивается на части:

  • часть, которая отвечает за разработку фич
  • часть, которая отвечает за разработку общих библиотек, сервисов

Вторая часть часто называется core-командой и она начинает интенсивнее взаимодействовать с инженерной командой относительно улучшений и в конце обычно получается некоторая своя кастомная PaaS, которая позволяет рантаймить стандартные нагрузки и экономит ФОТ разработчиков, т.к. каждому из них уже не требуется быть экспертом в underlay уровне инфраструктуры. И людей в эти feature команды можно подбирать гораздо проще и быстрее. Кстати, про взаимодействие продуктовых и платформенных команд разработки я подробно рассказывал в отдельной статье.

В качестве заключения приведу последний значимый слайд этой презентации.

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.