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

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

Мифы

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

  • Who
  • What
  • How

Who

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

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

What

Мы поняли, что devops — это не кто. Теперь попробуем разобраться со следующей группой мифой, на этот раз относительно вопроса “Что”. Интересно, что сейчас есть целый набор современных технологий, которые ассоциируются с devops тематикой. В итоге, задавая людям вопрос “what is devops”, можно получить ответ, что это Ansible, Docker, Kubernetes, Jenkins, Gitlab и т.д. В общем, чем моднее, тем лучше.

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

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

How

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

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

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

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

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

Реальность

В реальности получается достаточно интересно. Есть 2 взгяда на происходящее с разработкой: со стороны IT и со стороны бизнеса. Первые знают про все уровни: физическую инфраструктуру, вируализированную, Infrastructure as a Service, Platform as a Service и сверху как вишенка уже приложения. А бизнес обычно заботит только последний уровень, а все остальные это уже лишние детали.

В рамках такого подхода современная разработка обычно движется в сторону того, чтобы распилить монолит на микросервисы, производя которые можно легко показывать инкрементальное увелечение объема функционала. Так как сложность в этом случае смещается в сторону 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.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store