Меня зовут Тимур Батыршин. Я развиваю методологию DevOps и связанные с этим архитектурные и организационные подходы.

Менеджер практики Инфраструктура и лидер направления DevOps в AXENIX, член программного комитета конференции DevOpsConf, преподаватель в OTUS.

Это копия https://timurb.ru/ — не блог, а скорее база знаний и глоссарий. Статьи могут обновляться, при этом оставаться по одному и тому же адресу.

Здесь я размещаю как тексты своего авторства, так и чужие цитаты. Если это цитата обычно я ставлю ссылку на источник.

Тексты могут и будут дорабатываться со временем, это может происходить прямо внутри статей, не отдельными страницами.

Статьи также публикуются по адресам:
https://timurb.ru/
https://timurbatyrshin.medium.com/

Мои контакты:
Facebook: fb.com/tbatyrshin
LinkedIn: linkedin.com/in/timurb
Telegram: @TimurBatyrshin

Различение между проектом и процессом

Из комментариев к обсуждению различия между проектом и процессом https://www.facebook.com/alex.turkhanov/posts/10227176872024711 :

- а) процесс не мобилизует ресурсы (проект мобилизует), он использует выделенные и зарезервированные под него;
- б) у процесса множественная причинность (у проекта токен-причинность), если мы сделаем вот такие действия над вот такими объектами, то из такой ситуации перейдем вот в такую;
- в) процесс есть инвариант , неизменная и неполная по составу и структуре основа для действий. Например, у Росатома есть процесс сооружения АЭС, события и действия, которые должны произойти, чтобы соорудить АЭС. Каждый отдельный экземпляр процесса сооружения порождает еще и проект сооружения, в рамках программы конкретной АЭС, в которой еще есть и куча процессов (проектов) эксплуатации и вывода из эксплуатации и пр.
Т.е., проект и процесс - это разные методы описания архитектуры действия.

В этом контексте начинает новыми красками играть понятие о Платформенной стратегии (https://platformdesigntoolkit.com/toolkit/) – она также мобилизует экосистему.

Кросспост:
https://timurb.ru/kb/project-vs-process/
https://timurbatyrshin.medium.com/8b873d6be48d

Тестирование в подходе Infrastructure as Code

Подход “Инфраструктура как Код” (IaC) противопоставляется подходу “Infrastructure as Scripts” в том, что к коду (в отличие от скриптов) начинают применять практики обычные для программирования, например тестирование.

Вот что имеет смысл тестировать в IaC:
- контракты (входы и выходы) модулей
- мутации параметров ( "${env}-${name}" или if env=prod then https should be enabled )
- внешние ограничения (“не должно быть security group с полностью открытыми портами”)

Сами ресурсы, которые мы создаем внутри модуля тестировать, конечно же, смысла не имеет – эта часть декларативна и уже протестирована провайдером ресурса.

Кросспост:
https://timurb.ru/kb/testing-the-iac/
https://timurbatyrshin.medium.com/a2df631c5aaa
https://www.facebook.com/tbatyrshin/posts/4708317799204114

Эволюция DevOps

15 лет назад DevOps начинался в попытке “подружить” разработку и эксплутацию — через культуру, обмен знаниями и совместную работу. Затем быстро развернулся в сторону ускорения поставки изменений из разработки в продакшн (активность Lean Value Stream Mapping, https://www.atlassian.com/continuous-delivery/principles/value-stream-mapping), продолжился в понимание того, что программисты создают не просто код в репозитории (и даже не протестированный код в репозитории), а работающее приложение в продакшне (практики Observability и SRE, https://sre.google/sre-book/table-of-contents/). И последние несколько лет DevOps перешел к рассмотрению взаимодействия команд на масштабе (фреймворк Team Topologies, https://teamtopologies.com/).

Что при этом менее заметно, так это происходящая одновременно с этим эволюция корпоративной архитектуры:
- Сперва одно подразделение (Ops) предоставляло сервис пользователям при помощи инструментов, которые разрабатывает другое подразделение (Dev)
- Затем взгляд сместился на построение цепочки добавленной стоимости (Value Stream), которое включает как оба этих подразделения, так и новые роли (например Product)
- Сегодня же говорят о построении инфраструктурных платформ и выделение особых интеграционных команд (enabling teams) для создания гибкости на продуктовом ландшафте

По сути современный DevOps (и DevOps ближайшего будущего) и заключается в:
- предоставлении сервисов при помощи которых команды разработки сами могут строить свой рабочий процесс, при этом сами эти сервисы должны соответствовать стандартам качества заданным в организации (по ИБ, SLA и т.д.)
- создании на базе этих сервисов типовых решений для быстрого старта, которые каждая команда разработки может адаптировать под себя
- активностях по интеграции, обучению и передаче экспертизы для еще более быстрого старта команд разработки
- практиках SRE, которые по факту уходят от инфраструктурных команд в команды разработки

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

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

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

Это осуществимо при помощи списка составляющих перечисленных в середине статьи.

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

Кросспост:
- https://timurb.ru/kb/devops-evolution/
- https://timurbatyrshin.medium.com/82d220c4afa1
- https://www.facebook.com/tbatyrshin/posts/5019698084732749

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

Agile часто продают как способ повысить вовлеченность команды в процесс. На деле все наоборот — сначала вовлеченность, потом Agile.

Возможно многие “серебряные пули” не работают именно потому что пытаются при помощи их решить то, что они требуют.

К примеру, DevOps пытаются применять для того, чтобы с его помощью улучшить скорость поставки фич в продакшн, хотя на деле наоборот - улучшение такой скорости (помимо всего прочего) приводит к DevOps.

(из архива 2020)

При разговоре о "бирюзовых организациях" или "аджайле" часто считают, что это организации плоские и без особой структуры. Мол хорошо мотивированные высококлассные специалисты могут сами организоваться наиболее эффективным образом.

Но давайте вспомним про закон Конвея — "Организации проектируют системы, которые копируют структуру коммуникаций в этой организации".
Плоская структура без иерархии (либо развитой параллельной управляющей структуры в виде например HR или архитектурной функции) будет означать, что эта компания разрабатывает монолит. Свободное перемещение между командами и изменение их конфигурации и зон ответственности — то, что этот монолит будет сильносвязанным. Это действительно светлое будущее, или же мы движемся в будущее микросервисов?

Есть ли примеры организаций с плоской структурой, для которых это не наблюдается?

Об принятие инженерных решений

Каждый раз когда мы говорим о реализации некоей системы (например, инфраструктурной платформы) одной из наших ключевых задач (возможно, важнейшей) будет принятие множества решений — как важных, так и не очень (нас интересуют важные). Эти решения самые разнообразные — решение о том, кто будет пользователями нашей системы, а кого оставляем за бортом, каким образом система будет устроена технологически, как мы ее будем реализовать и кто будет в нашей команде, и самое главное — будем ли мы эту систему реализовывать вообще, или будем жить дальше по старинке.

Для принятия таких решений нам важно понимать, нужна ли наша система пользователям (и каким) или им и без нее неплохо живется? Смогут ли они ей пользоваться или их нужно будет долго и трудно обучать? Какие технологии у нас есть в распоряжении? Удобны и пригодны ли эти технологии для использования в системе? Умеет ли наша команда пользоваться этими технологиями? Хватает ли у нас в команде людей и компетенций? В конце концов, есть ли у нас (или у нашего заказчика) бюджет и время, которые могут быть потрачены на создание разрабатываемой системы? Пусть в контексте нашей статьи нашей системой будет инфраструктурная платформа, но с тем же успехом можно говорить и о мобильном приложении или интернет-магазине.

Чем лучше мы понимаем ответы на эти вопросы (и на все сопутствующие), тем более качественные решения мы можем принимать. Так, стартапы при поиске ниши проверяют сперва наиболее рискованные гипотезы, чтобы принять решение о том, стоит ли им развиваться дальше, стоит ли перестроиться, или лучше вообще прекратить деятельность. Если посмотреть не на стартапы, а на планирование проектов, в первую очередь производят обычно предпроектную подготовку и обследование, оценку рисков, оценку стоимости проекта, и в итоге принимают решение о том, будет ли проект вообще запущен или нет. При итеративном планировании спринтами а ля скрам владелец продукта вместе с командой каждый спринт принимает решение о том, что именно будет реализовано в этом спринте.

Чем сложнее принимать решения, чем дольше к принятию решения нужно готовиться (например, собирать информацию), чем менее понятна картина, тем решения будут более дорогими, либо менее качественными. Иными словами, некачественные решения снижают неопределенность не слишком сильно, нивелируют риски меньше чем нам бы хотелось. При этом принятие качественного решения может само по себе оказаться небольшим проектом, предпроектное обследование иногда стоит вполне себе заметных денег.

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

Здесь выглядит интересным то, что наши технические инструменты оказывают самое прямое влияние на неопределенность проекта, стоимость и скорость принятия решений. Чем лучше мы знаем наши инструменты, и чем инструмент лучше подходит к конкретной задаче тем более качественным будет принятое решение о его использовании или неиспользовании. Естественно, инструменты постоянно появляются новые и мы не знаем их всех, и на первый план выходит не столько функциональность инструмента, сколько скорость и предсказуемость его освоения и использования. Чем проще пользоваться инструментом, чем он более предсказуемый (как с точки зрения функциональности, так и с точки зрения устройства и обслуживания) тем быстрее мы его осваиваем, и тем более качественные решения относительно использования этих инструментов мы можем принимать. Под инструментами здесь понимаются как инструменты командной строки и публичные веб-сервисы, так и языки программирования и библиотеки к ним. Одним словом, все технические компоненты нашей системы, которые мы берем как есть, а не разрабатываем с нуля сами.

Парадоксальным образом в условиях высокой неопределенности _новые_ многофункциональные гибкие инструменты становятся менее пригодны для использования - по причине высокой стоимости принимаемых вокруг них решений. Большое количество функций и настроек делает их изучение и освоение более долгим (и следовательно дорогим), большая гибкость усиливает естественную неопределенность проекта еще и неопределенностью того, как этот инструмент будет использоваться. Более же пригодными окажутся инструменты знакомые, либо простые в освоении. По той же причине во многих программах есть два варианта настроек - “простые” и “для экспертов”. Интерфейс и предсказуемость становятся важнее гибкости и многофункциональности.

Но каким образом использовать многофункциональные и гибкие, но дорогие в освоении инструменты? Есть же какая-то ниша, где они будут лучше всего для использования?

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

Во всех остальных случаях предпочтительно использование тех инструментов, при использовании которых будет меньше всего сюрпризов, ну или если эти сюрпризы будут хорошо прогнозируемы.

Наконец, мы подходим к цели нашей статьи, вопросу - использование каких из инфраструктурных инструментов оправдано с точки зрения снижения рисков проекта и повышения его предсказуемости?

Какие из инструментов помогают принимать наиболее качественные решения? Какие из них просты в освоении и при этом многофункциональны, а какие лишь немного превосходят своих конкурентов в функциональности и гибкости, но при этом содержат в себе много неизвестного, количество которого к тому же сложно предсказать? Для каких из этих инструментов можно дешево принять решение о том, чтобы использовать или не использовать их в своем проекте, а для каких из них процесс принятия качественного решения будет дорогим?
К каким категориям относятся средства виртуализации, облака, Ansible, Terraform, Zabbix, и наконец любимец публики Kubernetes?
Помогают ли они принимать проектные решения, или же затрудняют эту задачу?
К сожалению, в рамках данной статьи места на это уже не остается, и подробный анализ инструментов по данной методике остается читателю в качестве домашнего задания.

Обеспечение жизненного цикла компонентов обеспечивающих жизненный цикл

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

Компоненты, обеспечивающие практики жизненного цикла (т.е. песочницы для разработчиков, автотесты, системы сборки, пайплайны CI/CD, система логирования и т.д.) становятся настолько же важны как и сами компоненты приложения — они теперь проектируются, разрабатываются, тестируются, эксплуатируются точно так же. Для них самих прорабатывается обеспечение жизненого цикла и интегрируются инструменты его автоматизации.

Этим в частности и отличается подход Infrastructure as Code от подхода Infrastructure as Scripts. А именно, тем, что теперь инфракод (в т.ч. CI/CD, мониторинг и т.п.) это точно такой же программный компонент самого приложения как и, например, его web-фронтенд. Если же говорить про больший масштаб — инфра-компоненты будут точно такими же компонентами многокомпонентного приложения, примерно как “сервис нотификаций” или “сервис некоей бизнес-отчетности”.

В этом и состоит тот же самый платформенный подход, который как мы помним является одним из центральных паттернов современного DevOps.

Об outsourcing

Интересным, но не совсем понятным в современной парадигме разработки (https://t.me/devops_architecture/12) становится место аутсорсинга в любом виде.

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

Это очень похоже на описание проектной деятельности: проектная стадия “transition” рассматривается как просто как “передача в эксплуатацию”. При таком подходе после приемки следующей важнейшей задачей заказчика будет обеспечить эксплуатацию нашей системы. Со стороны заказчика понадобится команда/организация, которая будет заниматься этой эксплуатацией, обеспечивать режим “Run”. Для этой команды необходимо представить инструкции по эксплуатации, и у нее должны быть все необходимые навыки, а значит возможно понадобится предусмотреть и обучение этой команды. Без соответствующих инструкций/обучения эта команда будет выяснять особенности эксплуатации новой системы методом проб и ошибок, т.е. скорее всего работать не с тем качеством, которое требуется заказчику.

Если вы слышите (или говорите) “разработайте нам такую-то штуку”, но при этом не говорится о том, кто ее будет поддерживать и что ему с ней нужно будет при это делать — знайте, здесь рано или поздно что-то взорвется (хорошо если рано).

Но чаще всего мы хотим не просто получить новую систему, а также хотим в дальнейшем в ней что-то менять. Иными словами, мы сразу предполагаем проекты аналогичные проекту первоначальному созданию системы, возможно в меньшем масштабе. Для такого рода доработок нам нужна подробная актуальная техническая документация к системе (не путать с инструкциями по эксплуатации!): это как собственно программный код, так и требования/описания фич системы, принятые важнейшие решения (https://t.me/devops_architecture/10), схемы работы, разворачивания и т.д. — одним словом все то, что понадобится разработчику разобраться в том, как работает система и выполнить свою часть работы. Если эта документация сохранилась только в голове самого разработчика “предыдущего этапа разработки”, новой команде разразработки придется заниматься практикой Reverse Engineering, а именно по имеющейся функциональности и низкоуровневым описаниям (т.е. коду) воссоздавать описания более высокоуровневые описания (например, решения почему сделано именно так, а не иначе) и требования к разработке. Если подходить к этой практике ответственно, после того как мы в процессе reverse engineering мы получаем модульное разбиение нашей системы, мы в соответствие с обратным законом Конвея аналогичным способом должны структурировать и нашу организацию. (Я вряд ли слышал о том, чтобы так кто-то делал при reverse engineering, и возможно многие проблемы развития legacy-систем связаны именно с этим). Это же соображение становится важным и в следующем пункте.

Итак, если мы хотим продолжать менять что-то в нашей системе после ее передачи/transition, нам нужно передавать реализацию всех практик ее жизненного цикла, в ином случае для каждой последующей доработки придется проводить reverse engineering. Иными словами, невозможно передать систему, которая будет меняться в дальнейшем без передачи команды (или организации), которая создает эту систему, выполняет все необходимые практики ЖЦ (управление фичами и их оценку, разработку, тестирование и т.д.). Невозможно (или непростительно дорого) построить систему одной организацией, а затем на этом месте построить новую организацию для ее доработки.

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

Теперь вернемся к вопросу, который мы поставили в начале статьи. В каком виде может существовать аутсорсинг? Может ли существовать вообще? На мой взгляд, это будет либо создание систем “под ключ”, которые не предполагают дальнейших изменений (таких проектов множество, хотя конечно на слуху проекты другие). Либо продолжительное сотрудничество заказчика с аутсорсером.

Какие еще есть варианты?

Инженерия и подход Infrastructure as Code

Подход “Инфраструктура как код” является ничем иным как особой формой разработки/программирования, и к этой форме разработки применимы большинство практик, принципов и паттернов, используемых в “классическом программировании”.

В статье [1] мимоходом отлично прояснен этот вопрос через определение того, что такое “инженерия”:

<<<Ideally the construction design phase results first into an ontological model of the object system, i.e. a white-box model that is completely independent of its implementation. Gradually this ontological model is transformed into more detailed (and more implementation dependent) whitebox models, the last one being the implementation model. This process is called implementation design or just engineering. If the object system is a software application, then the implementation model would be the source code in some programming language. The act of implementing consists of assigning appropriate technological means to the implementation model, e.g. running the source code on an appropriate platform.>>>

Мой вольный перевод:

<<<В идеальном случае, фаза конструктивного проектирования дает на выходе онтологическую модель целевой системы, т.е. модель прозрачного ящика (whitebox), которая полностью независима от ее имплементации. Постепенно эта онтологическая модель трансформируется в несколько более детализированных (и более зависимых от имплементации) моделей прозрачных ящиков, последняя из них будет моделью имплементации. Этот процесс называется “проектирование имплементации” или просто “инженерия”. Если разрабатываемая система это программа/приложение, имплементацией модели будет исходный код на некотором языке программирования. Акт имплементации состоит в назначении на эту модель соответствующих технологических средств, т.е. запуск исходного кода на подходящей платформе.>>>

Таким образом, если сравнивать “классическое программирование” и подход “инфраструктура как код” (что угодно как код) отличиями между ними будут только платформа, на которой запускается полученный исходный код и реализация практик жизненного цикла связанная с этой платформой (например, нельзя потестировать через Selenium не-веб-приложение, но сами по себе тесты можно писать на любую функциональность). Более того, если придерживаться этого определения, “инфраструктура как код” спроектированная через описание и последующую детализацию прозрачного ящика будет в большей степени программированием/инженерией, чем “классическое программирование” выполненное в виде “наматываем лапшу, подпираем костылями, заклеиваем изолентой”.

Иными словами, подход “инфраструктура как код” будет отличаться от “классического программирования” только если говорить о конкретной имплементации в коде и технологиях (и отличаться будет сравнимо с отличиями языка C от Haskell). Однако если говорить о дисциплинированной практике проектирования разница между ними будет только в части имплементации.

Есть ли какие-то аспекты, которые я упустил в рассуждениях?

Путь развития разработчика в Infrastructure as Code

Недавно вышли новые роадмапы профессионального развития на https://roadmap.sh/ и они на мой взгляд очень хорошо помогают прояснить мой предыдущий пост про то, что подход Infrastructure as Code — это особая форма разработки. Я не уверен, что согласен с названиями роадмапов, но разделение на роадмапы мне кажется очень хорошо сделанным:

- Software Architect — список навыков указывают, что основные задачи это построение систем, состоящих из множества отдельно разрабатываемых компонентов (и интеграция этих компонентов между собой), коммуникация с разработчиками, другими архитекторами и руководством компании, и организация проекта. Одним словом, чтобы множество команд разработки и программные сервисы которые они разрабатывают интегрировались друг с другом и при этом решали бизнес-задачи. Нужны ли эти практики в подходе Infrastructure as Code? Не уверен, скорее всего если выходишь на такой уровень в организации тебе уже не нужен IaC, но вместе с тем практически все эти темы в той или иной мере затрагиваются если ты занимаешься методологией DevOps.

- Software Design and Architecture (напомню, что “design” переводится как “проектирование”) — список навыков указывает, что основные задачи это структурирование программного кода, разбиение на модули и интеграция между ними. Одним словом, все то, что нужно для того, чтобы код в рамках одного сервиса был не лапшой, а был поддерживаемым, тестируемым, изменяемым, надежным и т.п. Нужны ли эти практики в подходе Infrastructure as Code? Несомненно. Если размер инфраструктурного кода десятки тысяч строк, применение всех этих практик и концептов поможет справиться со сложностью и в декларативных языках — сложность в них с ростом кодовой базы растет медленнее чем в императивных, но все же растет. Отдельные принципы скорее всего неприменимы, но не столько неприменимы сами по себе, сколько по причине относительно более простой и относительно маленькой кодовой базы в случае инфраструктуры, и относительно стабильного пространства понятий которые мы при помощи IaC описываем.

- Backend Developer — здесь говорится об инструментах и концепциях применяемых собственно в процессе разработки. Что-то из этого если находимся в контексте инфраструктуры мы знаем и так, что-то становится применимо сразу же как-только мы начинаем заниматься SRE, а не только писать код. В целом кажется применимым не столько к IaC, сколько к SRE.

Напомню свой тезис, который прозвучал в начале: практика Infrastructure as Code является не чем иным как программированием в “особой” доменной области на “особом” языке. Примерно так же как современное фронтенд-программирование имеет довольно мало общего с тем программированием на языке Паскаль, которое мы изучали в школе. Основные отличия находятся в решаемой проблематике и в конкретных языках программирования, которые применяются для решения задач.

Есть ли что-то, что я упустил в рассуждениях?

Исследование DORA и его проблемы

Кажется, спустя полтора года после прочтения книги Accelerate наконец удалось кратко и компактно сформулировать в чем проблема с отчетом State Of Devops.

Проблема в том, что в книге и отчете выпячивается та несомненно большая сложная часть работы по статистическим предсказаниям, которая однако по факту никому не нужна, и которая не имеет смысла.

1. DORA статистически показали, что использование CI/CD приводит ("предсказывает") к сокращению Lead Time, увеличению частоты поставки и снижению количества ошибок при развертывании.
На деле же это и есть основная функция CI/CD  —  он строится как раз для того, чтобы именно это и происходило.
Если ваш процесс CI/CD не приводит к ускорению поставки он не выполняет свою основную функцию, и скорее всего вы что-то делаете не так, и это можно сказать без исследований. 
Ждем горячих заголовков "Доказано научно: передвигаться на велосипеде быстрее чем пешком".

2. Аналогичная ошибка просматривается относительно выводов "высокая частота релизов приводит к высокой производительности разработки, а та в свою очередь приводит к господствующему положению на рынке".
Здесь тоже зависимость обратная. Если компания постоянно меняется и адаптируется к рынку, постоянно выпускает новые фичи (которые технически могут ломать старые), то без высокопроизводительного IT ей делать нечего. А "быстрый процесс поставки"  — это как мы уже заметили, функция внутри IT (также как и сам IT это функция внутри бизнеса).
Т.е. и здесь перевернули все с ног на голову.

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

Релизы и деплои

Периодически поднимается тема того, чем отличается deploy от release, и на это есть элегантный ответ в недавно вышедшей новой версии стандарта IT4IT от The Open Group.

- Deploy — это собственно инсталляция новой версии продукта на продакшн (сюда же включают и удаление старых версий с продакшна). В этот процесс входят и все стратегии деплоя — в том числе canary deploy, раскатка на какую-то небольшую часть аудитории, или деплой функциональности вообще прикрытой через feature flags и недоступной никому.
- Release — это предоставление новой версии сервиса (или услуги, если вспомнить ITIL) потребителям. При этом всякие хотфиксы в релиз закономерно не войдут, да и кажется далеко не каждый мажорный релиз по такой классификации можно будет назвать релизом.
Но релизом станет, например, изменение SLA сервиса при неизменной функциональности или изменение стоимости подписки на него.
Еще один пример релиза — в софте не меняется вообще ничего, меняются только гарантии на LTS поддержку (см Terraform 1.0 который от 0.15 отличается только гарантиями долговременной поддержки).
А еще точнее, получается что релиз всегда привязан к сегменту потребителей, и это во многом маркетинговая штука. Рефакторинг софта, который ничего для пользователя не меняет, но даёт возможность писать фичи быстрее — это релиз для разработчиков, но не релиз для пользователей. Для первых релиз есть, для вторых его нет, хотя софт один и тот же.

Что это значит для нас?

- В первую очередь в том, призыв “релизиться чаще” должен вызывать ответный вопрос “для каких пользователей?” (естественно, сегменты пользователей для своих цифровых продуктов нужно выявить сразу же как только мы с начинаем работать со своим продуктом). И мы тут же понимаем, что с одной стороны нельзя всем угодить, а с другой стороны есть пользователи разного приоритета и важности, и пауза в релизах на подготовку к единственному долгому и важному релизу может оказаться для нас важнее, чем выпуск серии релизов низкой важности.
- На мой взгляд, нельзя релизиться чаще чем раз в месяц, потому что каждый релиз это стресс для пользователя. И уж точно не стоит планировать релизиться каждый день. Как часто вы предпочитаете обновлять операционную систему на своем компьютере или в своем телефоне?
Если же вы успешно релизитесь чаще (вспоминаем отличия релиза от деплоя), значит постоянная эволюция и развитие вашего сервиса — часть вашего сервисного предложения и вероятно является вашим конкурентным преимуществом. И тогда важно “частоту релизов” отслеживать именно для отслеживания состояния этого самого конкурентного преимущества, а не потому что DORA предсказала. И не важно идет ли речь про SaaS или про устанавливаемый софт — вспомните каким релизом вашего броузера вы пользуетесь.
Если же постоянное непрерывное и быстрое развитие продукта для вас таким конкурентным преимуществом по той или иной причине не является (например, у вас другая стратегия), поддерживать актуальным в течение длительного времени сервисное предложение “наш продукт постоянно значимо и заметно развивается и улучшается” скорее всего окажется слишком дорого.
- Частота деплоев не важна вообще. Для оценки качества работы CI/CD может оказаться важна частота запуска пайплайнов (и в этом случае деплой входит в пайплайн, и будет одним из результатов его выполнения), для кросс-командной работы — частота релизов для внутренних пользователей (разработчиков). А что дает частота деплоев сама по себе? Ну разве что ее можно померять для определения предельно допустимых нагрузок на инструмент деплоя.

DORA выбрали частоту деплоев в качестве метрики лишь по той причине, что это единственный подходящий показатель, который можно более-менее убедительно измерить через опросник рассылаемый веером по интернету (с частотой релизов и частотой запуска пайплайнов это сложнее), и они явно про это говорили в книге Accelerate.

В сообществе регулярно ставят под сомнение пользу измерения частоты деплоев (вот пример, если у вас есть другие — смело присылайте).

Но тем не менее все прикладывают усилия чтобы “релизиться чаще”.

Почему?

Методология, дисциплины, практики (часть 1)

Существует мнение, что тяжеловесные подходы проектирования (ITIL, TOGAF, ГОСТ34 и т.д.) несовместимы с быстрыми частыми релизами и изменениями. А следовательно, зачем их изучать? Это верно только отчасти.

Во-первых вспомним всем известную методологическую максиму, которая упрощенно звучит как: “практика = дисциплина + технология”. И далее эта самая практика адаптируется под вполне конкретный контекст организации.

Дисциплина описывает мотивацию, взаимоотношения с окружающим миром, онтологию и принципы. К примеру, CI/CD предназначен для ускорения поставки разрабатываемого софта в продакшн, состоит из последовательной цепочки преобразований, которую проходит описание фичи до продакшна (в процессе превращаясь в код, затем в некий набор артефактов), подразумевает активное участие команды в процессах этой цепочки, и наконец можно говорить о принципах Shift Left и Fail Fast как примере более частных описаний.

Технология описывает конкретные инструменты — например, Gitlab CI или Jenkins.

И наконец, практика "CI/CD на базе Gitlab" будет описывать типовые паттерны применения данной технологии для реализации задач, которые задаются дисциплиной. Некоторые авторы практику не делают специфичной по отношению к инструменту, что на мой взгляд неверно — если ты умеешь делать отличные пайплайны на Gitlab-CI не факт, что ты вообще что-то вразумительное сможешь сделать под Jenkins. Или другой пример для дисциплины "программирование": если ты будучи программистом отлично умеешь писать код на Python далеко не факт, что ты будешь успешно исполнять практику "программирование на Java".

Таким образом, практика — это конкретный вид деятельности, который осуществляется для реализации дисциплины с использованием технологии.

Что здесь еще важно рассмотреть? Рассмотреть как практика будет вписываться в реальную организацию — в частности, есть ли у человека ее исполняющего необходимые компетенции, да даже есть ли у него необходимые средства для этого. Если человеку нужно писать многокилобайтные YAML для Kubernetes, а ему отдел ИБ не разрешает поставить редактор с поддержкой YAML, то практика "развертывание приложений в кластере Kubernetes" будет в этой компании работать со скрипом.

И наконец мы подходим к самому важному, что обычно обсуждается в контексте Devops, различных трансформаций и подобных темах — к интеграции наших практик в нашу организацию, с тем чтобы достичь целей описываемых дисциплиной. Если разрабатываемое приложение — сильносвязанный монолит с высокой интенсивностью разработки и низкой частотой релизов (т.е. не соответствует ни мотивации, ни принципам дисциплины CI/CD), то польза от практики "CI/CD на базе Gitlab", конечно будет, но ее будет очень немого. Подобная же история будет если разработчики, тестировщики и эксплуатация сидят по разным функциональным колодцам и не спешат из них вылезать. Иными словами, чтобы реализовать всего одну конкретную практику DevOps требуется полная перестройка приложения, либо полная перестройка организации, а часто и то и другое одновременно. Именно над этим в контексте DevOps бьются светлейшие умы всего мира.

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

И сопутствующий вопрос — изменилась ли с тех пор мотивация? Что нам важнее сейчас — поставлять изменения быстро, или же сократить затраты? В достаточно большом спектре решений это цели противоположные, и возможно только поставлять изменения быстро и как-то контролировать затраты, либо же сократить затраты и как-то контролировать скорость поставки изменений. Какой должна быть компания, чтобы следовать этим целям и каким должно быть приложение?

(продолжение)

Методология, дисциплины, практики (часть 2)
(начало)

Мне кажется, в таких примерах в какой-то момент истории их развития незаметно изменилась мотивация, а в след за ней должна была измениться архитектура организации и приложения. А архитектуру сложно изменить по самому определению архитектуры:

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

Вариантов определений множество но суть у всех примерно такая.

При этом по причине того, что в прошлом такое архитектурное проектирование велось с применением подходов предлагаемых, например, ITIL или ГОСТ34 публика такую неудачу автоматически приписывают им.

(я знаю, что ни то ни другое не является методом архитектурного проектирования в строгом смысле этого понятия, но для целей статьи это различие не играет значимой роли)

Но давайте вспомним взаимоотношения организации, применяемых в ней практик, дисциплин и технологий, про которые мы говорили в начале статьи, и попробуем разобраться что из этого является неотъемлемой частью этих подходов проектирования, а что — особенностью реализации.

Конкретные практики, которые применяются в организации (например, "Управление изменениями через собрание CAB") раскладываются на дисциплину "Управление изменениями" и технологию "Собрание CAB".

При этом, в настоящее время чаще применяется совсем другая практика, а именно, "Управление изменениями через планирование спринта и Pull Request". Но изменилась ли при этом сама дисциплина "Управление изменениями" (т.е. в первую очередь, изменились ли мотивация и принципы) от того, что мы одну технологию "Собрание CAB" заменили на другую технологию "Pull-request в Github"? Изменилась ли дисциплина "Управление инцидентами" от того, что в современном мире маленьких кросс-функциональных команд практика "Триаж инцидентов сервисдеском" чаще всего не очень нужна и алерты когда они происходят обычно считаются критическими? Изменилась ли мотивация этой дисциплины, взаимоотношения с внешним миром, содержание ключевых понятий, и выводимые в ней принципы? Что-то наверняка изменилось, но вспомним что у многих стандартов, методик и фреймворков регулярно выходят обновления в которых это может быть учтено на уровне самих дисциплин. Технологии же и практики применения этих дисциплин наверняка меняются намного чаще, чем сами дисциплины.

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

Итого собирается следующая картина:
- Применимость тех или иных подходов проектирования к каждому конкретному случаю определяется мотивацией содержащейся в этом подходе (“для чего он предназначен”), и эта мотивация достаточно легко верифицируется (хоть и далеко не всегда легко выявляется).
- Любой подход проектирования требует адаптации к архитектуре конкретной организации и конкретного приложения. Важно использовать самую современную версию дисциплины изложенной в конкретных подходах проектирования и проверять современность предлагаемых практик в условиях окружающей действительности. Более того — при необходимости заменять их на более современные (при этом оставаться в рамках дисциплины).

При этом, если мы на секунду забудем обо всем, что мы только что обсуждали и посмотрим на относительно легковесные и простые практики DevOps или SRE — их адаптация к реалиям конкретных организаций часто тоже является очень болезненным процессом. При этом достаточно часто проблемы адаптации состоят в том, что напрочь игнорируется мотивационная часть (“— Для чего нам Kubernetes? — Потому что сейчас все его используют”), а нередко при применении DevOps игнорируют и его фундаментальные понятия и принципы с закономерно плачевным результатом.

(окончание)

Методология, дисциплины, практики (часть 3)
(начало)

При осмыслении всего вышесказанного у меня возникают вопросы:

- Действительно ли вместе с переизобретением практик на базе новых технологий необходимо переизобретать и дисциплины? Почему chatops и автоматизированное создание алертов нельзя обсуждать в контексте классической дисциплины "Управление инцидентами", которая появилась еще задолго до появления компьютеров?
- Что мешает использовать классические детально проработанные (но адаптированные под современность! это важно!) методы проектирования для построения практик на базе современного тулчейна и современных архитектур как организации, так и приложений?
- И, наконец, можно ли при проектировании целевого видения процессов в организации игнорировать решения принятые много лет назад? И если нет, как их встраивать процесс проектирования?

Как на это смотрите вы?


.