Зарождение DevOps
Кто-то может удивиться числу 16, но я веду отсчёт от 2007 года, когда Патрик Дебуа работал в организации Notary Federation Brussels. Там он занимался вопросами отказоустойчивости — не только в техническом смысле, но ещё и в организационном, в процессном. Там к нему пришла мысль, которая послужила отправной точкой для DevOps-движения.
Патрик увидел, что основная проблема с отказоустойчивостью — не в софте и не в навыках, а в том, как люди общаются внутри организации. Отдел эксплуатации обладал хорошей экспертизой, но из-за того, что он мало взаимодействовал с отделом разработки, эта экспертиза в нём замыкалась и не масштабировалась. Именно с этого и началась идея о том, что для обеспечения устойчивости организации требуется преодолеть барьер в коммуникации и передачи опыта.
В 2009 году произошли три ключевых события:
- Доклад Эндрю Шафера на AgileRoots: тезис о сближении Dev и Ops
- Доклад Джона Олслоу и Пола Хаммонда на O’Reilly Velocity с тем же месседжем
- Первая конференция DevOpsDays: в организаторах — тот самый Патрик Дебуа
В своём блоге Патрик написал: «В последние месяцы движение начало обретать форму. Это движение людей, которые считают, что пришло время перемен в IT — время прекратить терять деньги попусту и начать делать крутое ПО, масштабируемое и отказоустойчивое. Это движение называется DevOps».
Развитие DevOps
C 2010 года термин DevOps стал общеупотребительным. А в 2013 году появилась и программная книга — The Phoenix Project, написанная Джимом Кимом и другими. Она объясняла, что такое DevOps, описывала образ мышления и подход.
В том же году опубликовали первый State of DevOps Report — отчёт о положении дел в индустрии. В нём начали вырабатывать метрики для оценки этого положения — например, классификацию по частоте деплоя. Категория Elite Performer присваивалась тем, кто деплоит более одного раза в день.
Вскоре появилась организация DORA (DevOps Research and Assessment), которая выработала четыре главные метрики DevOps:
- Lead time for changes — время внесения изменений.
- Mean time to restore — среднее время восстановления.
- Deployment frequency — частота деплоя.
- Change failure rate — коэффициент ошибок.
Теперь, чтобы считаться Elite Performer, нужно было получить хорошую оценку по всем четырём метрикам.
В России DevOps-практики начали внедряться примерно с 2013 года: прошёл DevOps Moscow Meetup, дальше были DevOpsDays Moscow, DevOops, DevOpsConf и другие конференции. Так стало формироваться российское DevOps-комьюнити.
DevOps сейчас
Сейчас DevOps на подъёме. С 2018 по 2023 год количество вакансий DevOps-инженеров каждый год увеличивалось примерно вдвое. В 2021–2022 годах был небольшой спад, но затем рост восстановился.
Кроме того, появляются разные оттенки DevOps после адаптации к разным областям. Например, в финансовом секторе это FinOps, в области машинного обучения — MLOps, в Data Science — DataOps.
Очевидно, что организации заинтересованы в развитии DevOps-подхода. Но не всё так гладко.
Проблемы DevOps
Проблема 1: отсутствие единства. Даже среди основателей нет единого мнения, что же такое DevOps. Были попытки такое мнение выработать, на базе сообщества DevOpsDays создан DevOps Manifesto, но его не принял отец-основатель Патрик Дебуа. Он заявил, что DevOps не нужны скрижали, что у него нет цели — только бесконечный путь.
Иронично: ключевая идея DevOps — коммуникация, однако столпы сообщества не могут договориться между собой.
Проблема 2: обилие моделей. Тот, кто хочет внедрять DevOps-подход, неизбежно столкнётся с вопросом: какой именно? Популярные модели DevOps уже нельзя пересчитать по пальцам одной руки, они находятся в сложных взаимосвязях друг с другом. Это создаёт неоправданную когнитивную нагрузку и повышает порог входа.
Проблема 3: проблема измерения. Как осознал ещё Патрик Дебуа, DevOps — это не только технические аспекты, но и процессные и культурные. Культуру измерить очень сложно. Процессы — чуть легче, но тут встаёт вопрос выбора метрик. Это возвращает нас к предыдущим двум проблемам.
Проблема 4: понимание DevOps как класса. Легче всего сказать, чем DevOps не является. DevOps — это не:
- сертификация
- роль
- должность
- набор инструментов
- решение всех проблем
Чем тогда DevOps является, к какому классу сущностей принадлежит? На этот вопрос до сих пор нет ответа, который устроил бы всех.
DevOps Origins
В попытке решить указанные проблемы мы создали 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. Мы выделяем пять уровней зрелости:
- Следовать.
- Применять/выполнять.
- Советовать/инициировать/влиять.
- Вдохновлять / стратегически внедрять.
- Создавать / делать вклад в практику.
Эта модель зрелости мотивирует людей идти вперёд, показывая, к чему следует стремиться.
Пример: Continuous Integration
Статус практики: 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 станет лучше.