The DevOps-Factors
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
docs Moved changes to bottstrap layout, deprecated telegra, link Jun 8, 2018
.gitignore
LICENSE
README.md

README.md

DevOps Factors

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


1. Приоритеты

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

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

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

2. Коммуникация

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

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

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

3. Автоматизация

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

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

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

4. Структура команды

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

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

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

5. Шаринг опыта

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

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

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

6. Мониторинг

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

7. Continious Integration

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

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

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

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

8. Continious Delivery

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

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

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

9. Непрерывное улучшение

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

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

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

10. Инцидент менеджмент

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

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

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

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

11. Роадмап, мувмент

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

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

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

12. Рациональное принятие решений

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

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

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