Из‑за критики и споров вокруг DevOps я написал эту статью. Посмотрим на путаницу в отрасли, коснемся интересного вопроса «Когда DevOps перестанет существовать» и обсудим когда на проекте нет DevOps.

Подход DevOps сформирован опытными инженерами рынка так же, как например Agile. По причине растущей сложности проектов и конкуренции, практическим путем стало ясно, что ценности команд Development и Operations нужно объединять. Это была одна из причин возникновения движения.

Определение DevOps ниже лучше выучить если вы читаете его впервые. Фраза «никто не может сформулировать что это» на интервью в компаниях мирового уровня не прокатит.

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

(Amazon AWS: What is DevOps?, Atlassian: What Is DevOps?, Google DevOps: DevOps, Wikipedia: DevOps etc..)

Действительно, то что DevOps это набор практик направленных на «что‑то» воспринимается трудно. И первое время точное определение отсутствовало. Такой же проблемой восприятия обладал Agile подход (методология). Это интересно обсуждали на Podlodka Podcast. На мой взгляд, наиболее заметные проблемы создающие путаницу в DevOps:

1. Действительно, первое время, на рынке, было принято путать и пугать людей с формулировкой.

2. Отличия регионов рынка IT.

3. Масштабы проектов.

Разные регионы IT отрасли

Рынок несет разные требования и ожидания к инженеринговым позициям. В такой же ситуации и оказался SRE. Инженеры Google в первой книге писали что SRE это в первую очередь разработчик хорошо умеющий мониторить и обслуживать свой код в PROD. Сейчас, часто, SRE это отдельная позиция не связанная с разработкой.

На американском рынке за DevOps практики часто отвечают разработчики когда как на рынке СНГ за DevOps чаще ответственный Ops инженеры (SysAdmins). Таким образом вопрос «Что такое DevOps для вас?» имел право на существование.

Разные масштабы проектов

Иногда звучит вопрос «чем занимаются SysAdmin/Operations». Вопрос тоже имеет право на существование и часто задается инженерами небольших сервисов.

Например, есть маленький интернет магазин продающий один Ferrari в месяц. Для такого магазина достаточно самой простой но фантастически красивого Frontend. После сдачи такого интернет‑магазина конечному заказчику и выхода в лайф, на выпуск новых фич достаточно одно или двух программистов.

Для сравнения, для медиаплатформы типа Youtube только для одного плеера понадобится сеть серверов с разными ролями. Потом прибавятся сервера/службы отвечающие за высокую нагрузку, отказоустойчивость и т. д. Подготовка и деплоймент кода, автоматизация и обслуживание инфраструктуры на таких проектах занимает дни. Это не то что бы является проблемой или неинтересно. Просто на регулярной основе разработчик занят написанием фич или основного кода сервиса а не обслуживанием автоматизации для CI/CD и инфраструктуры. Зато вопрос «чем занимаются SysAdmin/Operations» на таких проектах отпадает.

Когда у нас нет DevOps

Что бы глубже понять определение, можно посмотреть на вопрос с другой стороны: а когда у нас нет DevOps?

• если нет кросфункциональной команды (Например вы пишите ядро Linux. Тогда упрощенно, вы системный программист, которому нужно что бы был настроен CI для командной работы и сокращения интеграционных издержек при мерджах)

• если нет Time To Market (Нет потребности доставки новых фич пользователям)

• если "нет" культуры (Языковая ловушка, культуры не может "не быть". Когда "все плохо" это тоже культура, просто она такая. Пример приведу простой: команда не разделяет ответственность за ценности. Например, для Dev это могут быть частые выпуски фич а для Ops - стабильность прода)

Когда DevOps перестанет существовать

Так же как Agile, Scrum или ITIL, DevOps сформировал модель зрелости и переходит в подход по умолчанию (PMI Defining DevOps, ITIL® 4 and DevOps White Paper ). Когда появился Scrum, его все "внедряли", проходили длительные тренинги, покупали книги, делились опытом. Сейчас присоединяясь к Scrum команде, достаточно прочитать как реализован Scrum фреймворк на одном листке.

Можно посмотреть на путь DevOps через цикл зрелости технологий. Рынок регулирует процесс и DevOps переходит с вершины хайпа на плато реальной востребованности как стандарта по умолчанию Этот процесс вы видели относительно недавно с BigData. Сейчас по похожей кривой двигается artificial intelligence.

Можно сказать что и DevOps становится менее заметным но никуда не исчезает укрепляясь в своем сегменте рынка. Скорость обучения практикам и подходу становится быстрее и доступнее. Интересно, а какой следующий виток развития отрасли?

Дополнительная информация:

"Ускоряйся! Наука DevOps Как создавать и масштабировать высокопроизводительные цифровые организации".

Интересный курс по SRE от Google (можно смотреть бесплатно если выбрать кнопку "Audit" при старте курса).

Книги "основателей" SRE (на русском): 

• Site Reliability Workbook: практическое применение

• Site Reliability Engineering. Надежность и безотказность как в Google

• бесплатные оригиналы

DevOps Vs. SRE: Competing Standards or Friends? (Cloud Next '19).

Love DevOps? Wait until you meet SRE | Atlassian.

Книга "основателей" DevOps (на русском).