Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-03-10

1 15 лет назад DevOps начинался в попытке “подружить” разработку и эксплутацию - через культуру, обмен знаниями и совместную работу. Затем быстро развернулся в сторону ускорения поставки изменений из разработки в продакшн (активность Lean Value Stream Mapping), продолжился в понимание того, что программисты создают не просто код в репозитории (и даже не протестированный код в репозитории), а работающее приложение в продакшне (практики Observability и SRE). И последние несколько лет DevOps перешел к рассмотрению взаимодействие команд на масштабе (фреймворк Team Topologies).

2 Что при этом менее заметно, так это происходящая одновременно с этим эволюция корпоративной архитектуры:

3 <ul><li>Сперва одно подразделение (Ops) предоставляло сервис пользователям при помощи инструментов, которые разрабатывает другое подразделение (Dev)</li>

4 <li>Затем взгляд сместился на построение цепочки добавленной стоимости (Value Stream), которое включает как оба этих подразделения, так и новые роли (например Product)</li>

5 <li>Сегодня же говорят о построении инфраструктурных платформ и выделение особых интеграционных команд (enabling teams) для создания гибкости на продуктовом ландшафте</li>

6 </ul>По сути современный DevOps (и DevOps ближайшего будущего) и заключается в:

7 <ul><li>предоставлении сервисов при помощи которых команды разработки сами могут строить свой рабочий процесс, при этом сами эти сервисы должны соответствовать стандартам качества заданным в организации (по ИБ, SLA и т.д.)</li>

8 <li>создании на базе этих сервисов типовых решений для быстрого старта, которые каждая команда разработки может адаптировать под себя</li>

9 <li>активностях по интеграции, обучению и передаче экспертизы для еще более быстрого старта команд разработки</li>

10 <li>практиках SRE, которые по факту уходят от инфраструктурных команд в команды разработки</li>

11 </ul>Важный вопрос, который встает в такой картине если хотя бы чуть-чуть отойти в сторону от разработки: зачем командам строить свои уникальные рабочие процессы? Зачем делать свои велосипеды? Почему не взять один стандартный процесс разработки, сделать его частично кастомизируемым и работать по нему?

12 Ответ на это достаточно простой: у разных продуктов и компонентов разная частота внесения изменений, разные “нефункциональные” требования (например, критичность для бизнеса, требования к доступности и нагрузке, или требования compliance), а часто и разный технологический стек (бэк, фронт, два вида мобилки). Один универсальный набор инструментов и процессов не подойдет для этих таких разных компонентов - для каких-то продуктов он может начать тормозить разработку, а для каких-то не будет обеспечивать необходимый уровень качества. С другой стороны слишком широкие возможности кастомизации затрудняют использование инструментов, и польза от точечной кастомизации “стандартного пайплайна” для маленьких низкокритичных компонентов с быстрым циклом разработки будет невелика.

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

14 В случае старой парадигмы (ITIL/ITSM подход) это сделать невозможно, т.к. реинжениринг процессов дорог и ограничивает скорость изменений самих рабочих процессов.

15 Кросспост:

16 https://www.facebook.com/tbatyrshin/posts/5019698084732749 https://timurbatyrshin.medium.com/82d220c4afa1 https://t.me/devops_architecture/5