Меня зовут Тимур Батыршин. Я развиваю методологию 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). Однако если говорить о дисциплинированной практике проектирования разница между ними будет только в части имплементации.

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