Перевод статьи «Are you the lonely DevOps engineer doing 24/7 on-call? Change it!».
Вы единственный человек в команде, отвечающий за прод? Даже в свободное время вы носите за собой ноутбук, чтобы иметь возможность оперативно разбираться с проблемами? Это, конечно, не официально, но вы на связи 24 часа 7 дней в неделю?
Мне случалось находиться в подобном положении. Быть единственным DevOps-инженером может быть весьма обременительно, даже если вы при этом являетесь частью большой команды.
Но как перейти от этого театра одного актера к тому, чтобы за прод отвечала вся команда? Вот несколько советов относительно того, как помочь делу.
Парное программирование и парная отладка
Кооперируйтесь с каким-то одним товарищем по команде, когда пишете код или занимаетесь отладкой.
- Делитесь своим экраном и объясняйте коллеге, что вы делаете. Попросите коллегу помочь вам в поиске лучших решений и предотвращении ошибок.
- Проинструктируйте коллегу, как вносить изменения в инфраструктуру с его машины. Не забывайте пояснять все «почему?».
- Наблюдайте за тем, как коллега самостоятельно проделывает все, что вы ему показали. Пускай он проговаривает свои действия, поясняя их уже вам. Давайте обратную связь, но только время от времени.
Повторите процесс с каждым членом команды.
Безопасная для обучения среда
Вашей команде страшно учиться оперировать сложной облачной инфраструктурой. Очень важно сделать так, чтобы коллеги не боялись сломать прод. Обеспечьте вашей команде доступ в безопасную среду обучения. Например, создайте AWS аккаунт, используемый только чтобы испытать свои силы. Будет даже лучше, если у каждого члена команды будет отдельный AWS-аккаунт.
Документация по инфраструктуре и операциям
Уделите время и силы созданию и обновлению документации вашей облачной инфраструктуры и операций. Может, это не самое любимое ваше занятие, но сделать это необходимо. Понаблюдайте, какие вопросы чаще всего задают коллеги, и в соответствии с этим усовершенствуйте документацию.
- Проиллюстрируйте высокоуровневую архитектуру с помощью схем. Мои любимые инструменты для создания схем архитектуры – Lucidchart и Cloudcraft.
- Проиллюстрируйте топологию сети с помощью рисунков.
- Опишите различные части вашей архитектуры.
- Изложите вашу стратегию бэкапов и восстановлений.
- Объясните, где найти показатели, предупреждения и логи в системе мониторинга.
«Покажи и расскажи»
Вы планируете существенные изменения на проде? Вы улучшили мониторинг или логирование? Поставьте всех в известность об этом: организуйте собрание в стиле «покажи и расскажи». Тридцати минут вам вполне хватит. Не забудьте зарезервировать 10 минут для вопросов ваших коллег.
Документация по задачам
Мысль о том, что придется быть на связи и решать задачи, внезапно возникающие на проде, может вызывать у ваших коллег легкие приступы тошноты. Чтобы приобрести уверенность в своей способности справиться с любой ситуацией нужно время и опыт. Поддержите ваших коллег, создав документацию с порядком действий в случае распространенных проблем.
В этой документации должны быть ответы на следующие вопросы:
- Как определить, к какой категории относится инцидент?
- Как локализовать причину отказа?
- Как исправить то, что привело к инциденту?
В качестве примера можно посмотреть «ALB UnHealthyHostCount».
«Разбор полетов» без обвинений
При передаче ответственности команде количество происшествий, вызванных человеческим фактором, возрастет. Подавайте хороший пример. Не вините людей в допущенных проколах. Вместо этого организуйте спокойную работу над ошибками. Помогите вашей команде извлечь уроки из допущенных промахов. Не забывайте, что ваш менеджмент должен поступать также.
Хвалите людей, берущих на себя ответственность
Благодарите коллег, которые соглашаются побыть на связи и берут на себя ответственность за прод.
- Хвалите коллег после их первой смены, когда им пришлось быть на связи (например, в выходные или ночью).
- Благодарите товарищей, согласившихся заступить на смену заболевшего коллеги.
- Награждайте званиями в стиле «инженер месяца», исходя из количества проблем, с которыми людям удалось справиться в свою смену.
- Если коллега просто превзошел себя во время своей смены, предоставьте ему отгул.
Подумайте о возможности геймификации, которая соответствовала бы духу вашей команды. Заручитесь поддержкой менеджмента в плане поощрения людей, согласившихся заступать на смены.
Итоги
Вы единственный DevOps-инженер, которому приходится быть на связи круглосуточно, причем 7 дней в неделю? Измените это! Конечно, универсальных решений не бывает, но изложенные в этой статье советы помогут вам начать процесс.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]