DevOps

Зачем вам DevOps

DevOps — способ работы, при котором те, кто пишет программы, и те, кто потом держит их на ходу, отвечают за результат вместе. Отсюда и название: Dev — от английского development, разработка; Ops — от operations, эксплуатация, то есть повседневное поддержание системы13.

Само слово говорит лишь о том, что эти две задачи связаны. Остальное сложилось на опыте: за продукт отвечают сообща, а не перебрасывают его через стену в соседний отдел; ручные операции автоматизируют; о поломке узнают быстро.

И сразу главное: у DevOps нет владельца и нет свода-документа. Об этом — следующий раздел.

Нужен, если выпуск версии превращается в спецоперацию с ночными дежурствами и списком ручных шагов.

Нужен, если разработка и эксплуатация меряются разными показателями и потому тянут в разные стороны.

Не нужен как проект с датой окончания. Это способ работы, а не внедрение системы: у него нет момента «внедрили». Сандживи Шарма, написавший книгу о внедрении DevOps, говорит то же жёстче: проекта «DevOps» не бывает16.

Текста свода здесь нет: его не существует. Ниже — кто и что выдаёт за первоисточник, что можно считать нормативным документом и где подход ломается.

У DevOps нет владельца

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

Конференция, где родился термин, — devopsdays. Первую провели в бельгийском Генте в 2009 году, и её основатель Патрик Дебуа до сих пор значится в списке советников серии1. Это событие и сообщество, а не свод. Организаторы описывают devopsdays как серию технических конференций по всему миру — о разработке программ, об их эксплуатации и о том, где эти два занятия пересекаются2. Каждую встречу проводят местные добровольцы2.

Две коммерческие организации, которые выдают сертификаты. Первая — DevOps Institute. Он входит в группу PeopleCert, которой принадлежат ITIL и PRINCE2; там же, на площадке PeopleCert, покупают и экзамен3. Вторая — DASA. Что это нидерландская компания из Роттердама, записано в её же условиях пользования4. Владельцем DevOps не называет себя ни одна.

Международный стандарт, изданный в 2022 году, через тринадцать лет после появления термина. ISO/IEC/IEEE 32675:2022 существует, действует и стоит денег5. С нуля его не писали: сначала документ вышел как стандарт IEEE 2675-2021, 16 апреля 2021 года12, а потом ISO приняла его целиком — по ускоренной процедуре, заведённой для стандартов организаций-партнёров18. Две записи в каталогах, текст один. И это документ о DevOps, а не «свод DevOps».

Если во внутреннем регламенте нужно сослаться на «стандарт DevOps», то в международной стандартизации такой документ ровно один — ISO/IEC/IEEE 32675. А вот единого списка «официальных принципов DevOps» нет: свой набор у стандарта, свой — у книги «The DevOps Handbook», свой — у DASA, и все три разные. Об этом — следующий раздел.

Что можно считать первоисточником

Стандарт. Своё назначение ISO/IEC/IEEE 32675 формулирует так: он задаёт требования и даёт руководство по внедрению DevOps, чтобы организация могла описывать, контролировать и улучшать процессы жизненного цикла программного обеспечения6. Годится он и для целой организации, и для отдельного проекта: собрать, упаковать и развернуть программы и системы безопасно и надёжно6. Восемьдесят одна страница, первая редакция, август 2022 года5.

Сам DevOps стандарт определяет так: набор принципов и рабочих приёмов, помогает заинтересованным сторонам лучше общаться и работать сообща — чтобы задавать, разрабатывать и эксплуатировать программы и системы и всё время их улучшать17. Ни слова про инструменты: только про людей и про весь жизненный цикл. Там же снято ходовое заблуждение. DevOps часто считают делом самого конца, выкладки, — а в стандарте написано, что он идёт через весь цикл и каждой стадии уделяет равное внимание17.

Ничего отдельного стандарт для DevOps не изобретает. Он прямо говорит, что заданные в нём работы и их результаты соотнесены с моделями процессов двух других стандартов12. Первый из них, ISO/IEC/IEEE 12207, занят жизненным циклом программного обеспечения; второй, ISO/IEC/IEEE 15288, — тем же для систем целиком. DevOps ложится в те же понятия, которыми при разработке пользуются давно.

Четыре принципа из самого стандарта. В тексте они стоят отдельными пунктами, с 5.2.1 по 5.2.417:

• business or mission first — задача организации идёт впереди процедурных и технических соображений, а риск и польза для клиента всё время держатся в равновесии;
• customer focus — работу выстраивают от того, что нужно клиенту, и от его рисков; сюда же стандарт относит защиту личных данных;
• left-shift and continuous everything — проверки, тестирование и безопасность сдвигают к началу работы и делают непрерывными: тесты пишут вместе с продуктом, а не после него;
• systems thinking — на систему смотрят целиком, от края до края, потому что сложная поломка редко сводится к одной неисправности.

Названия оставлены по-английски, пояснения наши: официального русского перевода у стандарта нет, а сам текст требований — платный.

Пятого принципа не ищите. В аннотации стандарта их перечисляют через запятую, и left-shift с continuous everything выглядят там как два разных12. В тексте это один пункт — 5.2.317.

Определение, которое можно померить. Лен Басс, Инго Вебер и Ливен Чжу в книге «DevOps: A Software Architect's Perspective» описывают подход через время: сколько его проходит между двумя точками. В первой изменение внесли в систему; во второй оно уже работает в продуктивной среде, и качество не упало20.

Определение хорошо тем, что проверяется секундомером, а «культура сотрудничества» — нет. Тот же промежуток меряет исследование DORA, к которому мы отсылаем внизу страницы. И оговорка, без которой было бы нечестно: книги у нас нет, формулировка приведена пересказом по тому, как её обычно излагают, а дословно по тексту не сверена20.

Три пути из «The DevOps Handbook». Ещё один набор принципов записан не в документе организации, а в книге. «The DevOps Handbook» написали Джин Ким, Джез Хамбл, Патрик Дебуа и Джон Уиллис; издательство IT Revolution выпустило её в 2016 году, а во втором издании 2021 года к авторам добавилась Николь Форсгрен14.

Дебуа здесь тот самый — человек, с которого началась конференция devopsdays1. Стандарта ISO/IEC/IEEE 32675 в 2016 году ещё не было.

Три пути — рамка, из которой авторы выводят всё остальное14:

• поток — работа идёт слева направо: от разработки к эксплуатации и дальше к человеку, который программой пользуется. Чтобы поток не вставал, работу дробят на мелкие части и не передают дальше брак;
• обратная связь — сведения о неполадках идут навстречу, справа налево, и появляются на каждом шаге, а не только в конце: так находят поломку до крупного сбоя;
• постоянное обучение — в организации доверяют друг другу настолько, что пробовать и ошибаться не страшно. Выводы делают и из удач, и из провалов, а найденное одной командой становится общим.

И это не канон. Авторы сами пишут, что взяли три пути из «Проекта „Феникс“» — романа, который до этого написал Джин Ким14. Отраслевого согласования за ними нет, есть позиция авторов книги.

Шесть принципов DASA. Последний из трёх наборов — собственная модель сертифицирующей организации: действие в интересах клиента, ориентация на конечный результат, сквозная ответственность, самостоятельные команды, где собраны все нужные специальности, постоянное улучшение, автоматизация везде, где она возможна7.

Оговорка, без которой список выше врёт

Это принципы DASA, а не «принципы DevOps». Наборов выше три — у стандарта, у «The DevOps Handbook» и у DASA, — и расходятся они и по составу, и по числу. Главного среди них нет. Каждый стоит здесь как позиция того, кто его написал, а не как канон.

Сертификация

Сертификаций много, и все — по программам коммерческих организаций, а не «по своду».

У DevOps Institute: начальный и лидерский уровни по DevOps, наблюдаемость, эксплуатационный ИИ, надёжность сервисов в двух уровнях, безопасная разработка в двух уровнях, непрерывное тестирование, управление потоком создания ценностиЦенностьПольза и выгода, которые сторона получает от услуги; величина субъективная.ITIL 4, книга ITIL Foundation8.

У DASA: основы DevOps, непрерывная безопасность, эксплуатационный ИИ, платформенная инженерия, надёжность сервисов, управление продуктом, лидерство в переходе, коучинг, роль владельца продукта, масштабирование и пара курсов о постановке и проверке требований8.

Перед покупкой курса стоит посмотреть на одну мелочь. В подвале сайта DevOps Institute на 16.08.2026 стоял копирайт 2024 года10. Сам по себе он ничего не доказывает: площадки годами живут с прошлогодней датой. Но спросить у провайдера, когда программу пересматривали в последний раз, он повод даёт. У DASA с этим проще — новые программы она выпускает и в 2026 году9.

Там же рядом ещё одна оговорка: размер своего сообщества DevOps Institute показывает числами без даты, на которую они посчитаны9. Опираться на них нельзя — неизвестно, к какому году они относятся.

Сколько стоит

Сам подход — ничего: платить не за что, канонического текста не существует. Материалы devopsdays и статьи обеих организаций открыты.

Единственная цена, подтверждённая первоисточником, — у стандарта: 227 швейцарских франков за электронную или бумажную версию5. Это цена у ISO; тот же текст продаётся и у IEEE, под обозначением IEEE Std 2675-202118. Курсы и экзамены тоже платные, но их продают через партнёров, и общего прейскуранта нет.

В России

ГОСТ-аналога нет: поиск по базе Росстандарта не находит ни одного документа — ни по запросу «DevOps», ни по «ДевОпс»11. ГОСТ-адаптации стандарта 32675 тоже нет.

Отдельная ловушка для тех, кто ищет по номеру: в базе есть ГОСТ 32675-2014, но он про стеклянную тару11. Совпадение по числу.

По-русски у стандарта есть заглавие, но нет текста. В каталоге ФГБУ «Институт стандартизации» карточка ISO/IEC/IEEE 32675:2022 подписана так: «Стандарт IEEE для DevOps. Создание надёжных и безопасных систем, включая сборку, упаковку и развёртывание приложений»19. Язык оригинала — английский19. То есть перевели заглавие, а не документ, и ГОСТа от этого не прибавилось.

Что покрывает

Одну границу стоит провести сразу. Непрерывная поставка — это когда новая версия программы доезжает до рабочих серверов сама, а не руками по списку шагов. Её часто принимают за весь DevOps. Эберхард Вольф, автор книги A Practical Guide to Continuous Delivery, возражает: поставка входит в DevOps как одна из практикПрактикаНабор ресурсов организации для выполнения работы определённого типа.ITIL 4, не больше15.

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

Где ломается применение

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

Дженнифер Дэвис и Кэтрин Дэниелс в «Философии DevOps» говорят о том же, только про людей: назначать «devops-директора» или другого единственного ответственного за внедрение смысла нет. DevOps — культурное движение, и работать его идеи должны на всех уровнях организации сразу13. Есть у них и оговорка. Если команда со словом «devops» в названии уже сложилась и работает, переименовывать её незачем13.

Шарма в «The DevOps Adoption Playbook» заносит это прямо в список антипаттернов. Назначить вице-президента по DevOps и подчинить ему разработку с эксплуатацией — ход, который меняет мало: два разобщённых подразделения остаются теми же двумя16.

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

Дэвис и Дэниелс называют четыре опоры работающего DevOps: сотрудничество, близость (их слово — отношения между разными командами: у каждой свои задачи и свои показатели, а цель одна на всех), инструменты и масштабирование13. Две первые — про людей. В книге на этом настаивают отдельно: одни инструменты ни рабочих привычек, ни договорённостей не меняют13.

Берут принципы одной организации за канон. Шесть принципов DASA полезны, но это позиция одной компании7. Рядом лежат ещё два набора: четыре принципа из самого стандарта17 и три пути из «The DevOps Handbook»14. Полностью они не совпадают.

Ищут сертификат «по DevOps» как подтверждение зрелости компании. И DevOps Institute, и DASA сертифицируют людей, а не организации: сертификата на компанию по DevOps мы не нашли ни у той, ни у другой.

Ссылаются на «стандарт DevOps», не открыв его. Речь всегда об одном документе — ISO/IEC/IEEE 32675. Он платный и написан языком процессов жизненного цикла6 — это не сборник советов из блогов.

С чего начать

1. Возьмите один продукт и опишите путь одного изменения — от готового к выпуску кода до продуктивной среды, то есть до той, где программой пользуются люди. Выпишите всё: шаги, ручные операции и время, когда изменение просто ждёт. Обычно выясняется, что работы там на час, а ожидания — на неделю.
2. Уберите один ручной шаг и одно ожидание. Не весь конвейер — один шаг.
3. Договоритесь, что команда отвечает за продукт и после выпуска. Без этого остальное косметика.

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

Это не наша отговорка. Шарма написал про внедрение DevOps целую книгу и в приложении к ней, разбирая случай крупной финансовой компании, оговаривается: универсального маршрута внедрения нет и не будет16. Два его совета ложатся прямо на шаги выше. Пилот берут типичный для организации, а не самый удобный: на исключении ничему не научишься. И меняют в нём что-то одно. Иначе потом не разобрать, что сработало16.

Что читать дальше

Рядом три страницы. ISO/IEC/IEEE 32675 — стандарт о внедрении подхода. SRE — практика о том, как удерживать работающие сервисы в строю. DORA — исследование, показателями которого меряют, стала ли поставка изменений быстрее и надёжнее.

Свода нет, а книги есть — эта страница опирается на четыре. «The DevOps Handbook» Джина Кима, Джеза Хамбла, Патрика Дебуа и Джона Уиллиса: оттуда три пути14. «Философия DevOps» Дженнифер Дэвис и Кэтрин Дэниелс: про людей, культуру и четыре опоры13. A Practical Guide to Continuous Delivery Эберхарда Вольфа: про конвейер и про то, где он кончается; есть и русское издание15. «The DevOps Adoption Playbook» Сандживи Шармы: про большую организацию и про то, почему готового маршрута не бывает16. Все четыре платные, и ни одна не свод.