azakharko / devopsfactors Goto Github PK

Методика построения правильной DevOps культуры

Приоритеты у Ops и Dev команд должны быть одинаковыми. Желательно что б был один и тот же менеджер. Такое объединение позволяет ввести error budget и снижает накладные расходы на коммуникацию между командами. Этот пункт самый важный и не может меняться в зависимости от имплементации.

Антипаттерн:

Ops отвечает за стабильность, а Dev за фичи

Это очень важно. Коммуникация это основной фундамент DevOps. Ваши Soft skills необходимы и часто важнее технического бэкграунда. Приходя в новую компанию, Вам, скорее всего, придется продвигать культуру, ломать стереотипы и часто встречать poor engagement людей в около-DevOps сфере.

Антипаттерн:

постоянно сидеть в наушниках, и пилить свою часть системы

Концепт Infrastructure as Code является основополагающим в DevOps методологии. IaC важна и нужна, чтобы восстановиться после инцидента, при минимальных затратах усилий переехать на другую платформу, версионировать изменения для прозрачности управления, удобства работы над инфраструктурой в команде, возможности отката на предыдущее состояние. Также инфраструктуру необходимо качественно тестировать, согласно принципам пирамиды тестирования(юнит, интеграционные, системные тесты).

Антипаттерн:

мануальные не документируемые изменения

В хорошей DevOps команде должна быть полная взаимозаменяемость, плоская структура и взаимопомощь. В случае, если у Вас в компании несколько продуктов или выделенных частей системы необходимо периодически брать задачи не из своей основной специализации для расширения кругозора и культивирования взаимозаменяемости. Хорошая DevOps команда снаружи должна выглядеть как цельная система - все члены команды могут выполнить задачу, которая поступила.

Антипаттерн:

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

Сильный knowledge gap даже внутри одной команды всегда влечет за собой проблемы. Совершенно разная экспертиза у людей по разным компонентам платформы всегда будет понижать перфоманс команды и усложнять предсказания по деливери. Наличие уникальных скилов у одного инженера делает его незаменимым и рано или поздно он превращается в живую point of failure. Поэтому нужно стараннее заранее определять gap'ы и их критичность, оперативно устранять их путем обмена опытом и информацией. Качественная документация и прозрачность процесса разработки сильно упрощает этот процесс.

Антипаттерн:

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

Нужно предиктить проблемы, а не тушить пожары.

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

Антипаттерн:

не тестировать приложение

реализовывать доставку артефакта в контексте CI процесса

CD - это процесс, описывающий последовательность действий для доставки артефакта. Основной концепт состоит в унификации этого процесса для всех окружений. Существуют разные стратегии доставки: blue/green, canary, и другие. В большинстве случаев будет справедливым утверждение, что чем мельче доставляемые изменения, тем меньше вероятность поломать работающий продукт. Доставка ценности должна быть всегда в рабочем состоянии и по первому требованию бизнеса доставлять ценность клиентам. Следующим этапом развития Continious Delivery является Continious Deployment.

Антипаттерн:

ручная выкатка на окружение по чек-листу

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

Антипаттерны:

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

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

Антипаттерны:

выяснять, почему система не работает, вместо оперативного восстановления

писать документацию о том как чинить, вместо предотвращать глобально

У хорошей DevOps команды должен быть нечеткий план развития на ближайшие 3-6 месяцев с основной глобальной целью, которую диктует бизнес. План не имеет смысла детализировать и описывать техническую реализацию - очень вероятно, что команда в определенные моменты будет от него отходить, и менять тактику достижения глобальной цели.

Антипаттерн:

четко и детально расписывать план развития на ближайшие 10 лет

На данный момент существует огромное количество инструментов для решения каждой отдельно взятой проблемы, и нужно максимально правильно выбрать right tool for the job и не гнаться за модными трендами, которые постоянно появляются. Это рационально для решения проблем низкого и среднего уровней. В случае же дизайна архитектурных решений стоит обратить внимание на современные практики и подходы - в результате это позволит косвенно сэкономить время и деньги на переделывании и внедрении "костылей". Здесь есть два хороших правила: 'plan before execute' и 'code wins arguments' (в смысле, что лучше попробовать и сравнить несколько решений самому на своих задачах, чем слепо хватать инструменты, о которых где-то услышал)

Антипаттерн:

вышла новая бета-версия фреймворка Х, завтра переезжаем