Итак, мое первое дежурство, и я вижу, что некоторые системы падают с завидной регулярностью.
После анализа я вижу следующее:
1. Система выступает как центральное звено, ее падение вызывает падение зависящих от нее приложений.
2. Система используется для решения задач, для которых она не предназначена (Например event sourcing система используется так же как долгосрочное хранилище событий).
3. Система была спроектирована под определенную нагрузку и объем данных и теперь она не справляется.

С ростом объемов и нагрузки можно справиться либо оптимизацией производительности и рефакторингом, либо добавлением ресурсов, если рост органичен.

Другое дело с неправильной архитектурой.

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

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

То есть старший инженер с 10+ годами в конторе и вчера нанятый младший разработчик имеют одинаковый вес голоса.

Я поставил перед собой две цели:
- Избавить нас от проблем 1 и 2 в кратчайшие сроки.
- Сделать так, чтобы этого не повторилось в будущем.

Чтобы достичь первой цели в первую очередь нужно думать по принципу win-win.
То есть не идти к разработке с operations требованием (сделайте так, чтобы ваши приложения не падали), а мотивировать их разрабатывать с reliability in mind, что в итоге будет плюсом и для всех.
Решение было простым, но потребовался административный ресурс. Я поговорил с нашим техническим директором, и мы договорились о следующем:
- Необходимый SLO ставится одной из целей в KPI команды (от KPI зависит годовой бонус)
- 20% спринта выделяется на уничтожение технического долга. Ops определяют приоритет задач, как stakeholders.
- В нашей (Ops) команде на ближайшее время 50% ресурсов уходит на уничтожение технического долга.

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

Во-первых, общение между инженерами и разработкой как пункт чек-листа перенесли из Definition of Done в Definition of Ready. Это позволило инженерам участвовать в grooming и planning сессиях (то есть на самих ранних стадиях) разработки.
Участником от инженерной команды назначается текущий дежурный инженер. Это позволяет соблюдать определенный нейтралитет и минимизировать риск принятия неправильного решения под воздействием эмоций или дружеских отношений между инженером и разработчиком. Также нет “привязки” конкретной задачи к конкретному инженеру, и тот может спокойно идти в отпуск или на больничный.
Помимо этого перед планированием дежурный инженер и один или несколько разработчиков разрабатывают несколько PoC с использованием разных сервисов AWS, которые затем демонстрируются перед началом работ по разработке и имплементации. Наилучшее решение (то есть то, которое эффективнее всего решает данную задачу и не конфликтует с зависимостями) уходит непосредственно в разработку.

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

Например, мы решили заменить DC/OS на Fargate. Эта инициатива требует переработки всех существующих CI/CD pipeline’ов, тестирования и, как результат, - времени разработчиков.

Прежде чем презентовать Fargate как преемника контейнерной оркестрации мы проводим тренинг, где разработчики сами создают кластер и разворачивают dummy приложение на оном.

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