DevOps — путь в 16 лет. Куда мы идём?

НачалоЗарождение DevOpsРазвитие DevOpsDevOps сейчасПроблемы DevOpsDevOps OriginsПример: Continuous IntegrationЧто в итоге

Евгений Харченко работает над тем, чтобы DevOps стал конкретнее. Ведёт личный проект на GitHub, который посвятил развитию в DevOps. Там же рассказывает, как строит CI/CD на работе. В докладе Евгений поделился своим видением истории DevOps, проблемами этой методологии и путями дальнейшего развития.

Кто-то может удивиться числу 16, но я веду отсчёт от 2007 года, когда Патрик Дебуа работал в организации Notary Federation Brussels. Там он занимался вопросами отказоустойчивости — не только в техническом смысле, но ещё и в организационном, в процессном. Там к нему пришла мысль, которая послужила отправной точкой для DevOps-движения.

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

В 2009 году произошли три ключевых события:

В своём блоге Патрик написал: «В последние месяцы движение начало обретать форму. Это движение людей, которые считают, что пришло время перемен в IT — время прекратить терять деньги попусту и начать делать крутое ПО, масштабируемое и отказоустойчивое. Это движение называется DevOps».

C 2010 года термин DevOps стал общеупотребительным. А в 2013 году появилась и программная книга — The Phoenix Project, написанная Джимом Кимом и другими. Она объясняла, что такое DevOps, описывала образ мышления и подход.

В том же году опубликовали первый State of DevOps Report — отчёт о положении дел в индустрии. В нём начали вырабатывать метрики для оценки этого положения — например, классификацию по частоте деплоя. Категория Elite Performer присваивалась тем, кто деплоит более одного раза в день.

Вскоре появилась организация DORA (DevOps Research and Assessment), которая выработала четыре главные метрики DevOps:

  1. Lead time for changes — время внесения изменений.
  2. Mean time to restore — среднее время восстановления.
  3. Deployment frequency — частота деплоя.
  4. Change failure rate — коэффициент ошибок.

Теперь, чтобы считаться Elite Performer, нужно было получить хорошую оценку по всем четырём метрикам.

В России DevOps-практики начали внедряться примерно с 2013 года: прошёл DevOps Moscow Meetup, дальше были DevOpsDays Moscow, DevOops, DevOpsConf и другие конференции. Так стало формироваться российское DevOps-комьюнити.

Сейчас DevOps на подъёме. С 2018 по 2023 год количество вакансий DevOps-инженеров каждый год увеличивалось примерно вдвое. В 2021–2022 годах был небольшой спад, но затем рост восстановился.

Кроме того, появляются разные оттенки DevOps после адаптации к разным областям. Например, в финансовом секторе это FinOps, в области машинного обучения — MLOps, в Data Science — DataOps.

Очевидно, что организации заинтересованы в развитии DevOps-подхода. Но не всё так гладко.

Проблема 1: отсутствие единства. Даже среди основателей нет единого мнения, что же такое DevOps. Были попытки такое мнение выработать, на базе сообщества DevOpsDays создан DevOps Manifesto, но его не принял отец-основатель Патрик Дебуа. Он заявил, что DevOps не нужны скрижали, что у него нет цели — только бесконечный путь.

Иронично: ключевая идея DevOps — коммуникация, однако столпы сообщества не могут договориться между собой.

Проблема 2: обилие моделей. Тот, кто хочет внедрять DevOps-подход, неизбежно столкнётся с вопросом: какой именно? Популярные модели DevOps уже нельзя пересчитать по пальцам одной руки, они находятся в сложных взаимосвязях друг с другом. Это создаёт неоправданную когнитивную нагрузку и повышает порог входа.

Проблема 3: проблема измерения. Как осознал ещё Патрик Дебуа, DevOps — это не только технические аспекты, но и процессные и культурные. Культуру измерить очень сложно. Процессы — чуть легче, но тут встаёт вопрос выбора метрик. Это возвращает нас к предыдущим двум проблемам.

Проблема 4: понимание DevOps как класса. Легче всего сказать, чем DevOps не является. DevOps — это не:

  • сертификация
  • роль
  • должность
  • набор инструментов
  • решение всех проблем

Чем тогда DevOps является, к какому классу сущностей принадлежит? На этот вопрос до сих пор нет ответа, который устроил бы всех.

В попытке решить указанные проблемы мы создали DevOps Origins. Это проект, посвящённый формированию единого видения DevOps среди участников движения. Мы собираем лучшие практики и подходы, структурируем их, приводим в простой и понятный вид. А главное — мы пробуем и применяем их сами.

При создании DevOps Origins мы опирались на двух китов.

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

SFIA — глобальная система навыков и компетенций для цифрового мира. В её терминах удобно описывать развитие DevOps-подхода в организации (а DevOps — это про развитие).

Мы выработали критерии хорошей практики. Она должна быть:

  • Эффективной — с эффективностью, подтверждённой опытом, историями успеха или авторитетными источниками
  • Адаптируемой — она должна быть применима к разным конечным технологиям
  • Измеримой — должны быть метрики, показывающие успешность и неуспешность внедрения
  • Согласованной с другими практиками
  • Обучаемой — в том смысле, что практика должна обучать инженеров и мотивировать их на развитие

Что касается эффективности, стоит упомянуть, какие источники мы считаем авторитетными. Во-первых, это индивидуальные контрибьюторы, сформировавшие индустрию, такие как Патрик Дебуа, Джин Ким, Джез Хамбл, Николь Форсгрен. Во-вторых, это программная литература — The DevOps Handbook, Accelerate, The Unicorn Project, The Phoenix Project. В-третьих, это данные организаций, таких как DORA.

Полный список опубликован у нас на GitHub, там же можно найти список практик, которые удовлетворяют критериям, и их подробно документированную структуру.

Мы внедрили четыре статуса для практик:

  • NOVEL — экспериментальная практика, о которой ещё почти нет данных
  • EMERGENT — когда после мелкомасштабных экспериментов собраны данные, но ещё нет хорошего понимания причин и следствий, на что влияет эта практика и что влияет на неё
  • GOOD — когда есть понимание, какие решения работают лучше всего и как их адаптировать
  • BEST — это значит, что можно прямо сейчас эту практику брать и внедрять и она будет работать

Разумеется, статус практики — это лишь маленькая часть её структуры. В своём документе мы подробно описываем практику, рассказываем о проблемах и решениях, говорим о рисках и реализации, а также о том, какие навыки будет давать практика и как измерить уровень зрелости. Для описания навыков мы используем систему SFIA. Мы выделяем пять уровней зрелости:

  1. Следовать.
  2. Применять/выполнять.
  3. Советовать/инициировать/влиять.
  4. Вдохновлять / стратегически внедрять.
  5. Создавать / делать вклад в практику.

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

Статус практики: BEST. Она используется повсеместно и хорошо себя зарекомендовала.

Описание: сборки для развёртывания и выпуска цифрового продукта формируются инкрементально, результаты труда разработчика ежедневно в них интегрируются.

Какую проблему решает: практика ускоряет командную разработку, уменьшает time2market, обеспечивает качество продукта.

Какие риски: если внедрять CI неправильно, вместо решения проблем можно их усугубить. Снизится устойчивость продукта, time2market увеличится, а команде обеспечено выгорание.

Как можно реализовать: для этого есть различные технологии — например, можно сделать CI/CD на основе GitHub.

Какие навыки даёт практика: в системе SFIA это навык Systems integration and build.

Какие у этой практики уровни зрелости:

  • Уровень 1: по коммиту происходит сборка и запускаются автотесты, при необходимости возможно ручное вмешательство. Есть запрет на пуш в main. Метрики — процент коммитов, которые приводят к сборке, и проверка флага запрета.
  • Уровень 2: ручное вмешательство исключается. Должно быть версионирование, пайплайн для merge requests, а артефакты сборки доступны всем разработчикам. И, соответственно, появляются новые метрики — проверяющие.
  • Уровень 3: стабильность и скорость сборки, а также метрики.
  • Уровень 4: на этом уровне вы должны быть амбассадором CI/CD, уметь внедрять его в других командах, делиться опытом и экспертизой.
  • Уровень 5: пятого уровня в нашей спецификации нет, но если бы он был, на нём бы дорабатывали практику и писали новые инструменты.

Каждая проблема несёт в себе возможность. DevOps Origins возник как ответ на объективные проблемы движения. Мы надеемся, что с нами DevOps станет лучше.

Поделитесь увиденным

Скопировать ссылку
ТелеграмВКонтакте