Production Ready: 4 вопроса, которые важно задать перед созданием чек-листа
Эта заметка содержит краткую выжимку опыта автора совместно с вольным переводом статьи Blameless: 4 things you need to know about writing better production readiness checklists.
Чтобы не было как у Вовки в Тридевятом царстве, стоит подумать о хорошо подготовленных чек-листах и пройтись по ним перед тем как нажать волшебную кнопку «deploy» и отправить ваш сервис в продакшн.
Ведение
Случай из жизни
Мы просыпаемся, умываемся, чистим зубы, делаем зарядку, завтракаем и начинаем готовиться к полёту. Мы просыпаемся не потому, что прозвенел будильник, а потому, что прилетел алерт и сегодня ваша очередь дежурства. Выясняется, что в новом приложении задеплоенном в продакшн не были выставлены лимиты на выделение ресурсов в pod«е kubernetes и при росте нагрузки приложение изволило скушать всю память, как следствие к нему пришел ООМ, ну дальше вы знаете.
Но как же так случилось, ведь в предыдущих проектах эти настройки везде были выставлены и казалось бы это очевидная вещь.
Этот продукт деплоила команда с новыми сотрудниками и видимо некоторые моменты они забыли, т.к чек-листа не было или он был изменен для требований тестовой среды.
История вымышленная, но не далека от истины. Кейсов может быть множество, но зато она отражает суть того, как подобных проблем можно избежать на ранних этапах с помощью грамотного чек-листа.
Зачем ?
Чек-листы хорошо зарекомендовали себя на протяжении столетия в таких критически чувствительных к ошибкам областях для человека как медицина и авиация (поэтому в примере выше первая строчка говорит о пилоте, а не об инженере).
Современные информационные системы сложны и их сложность только увеличивается. Как ни странно, в IT цена ошибки зачастую тоже высока. Инженеры люди умные и они перенимают лучшие практики из других областей, как например Chaos engineering on Amazon, который был взят у пожарных или вот чек-листы, о которых поговорим сегодня. Эти подходы проверены временем и их полезность сложно переоценить.
Чек-листы помогают уменьшить количество ошибок начиная с момента проектирования продукта до деплоя в прод. Тут и далее мы будем говорить о чек-листах для подготовки проекта к релизу в продакшн.
В этой заметке мы попытаемся ответить на вопросы ниже:
Чем чек-лист полезен в сложных проектах ?
Как создать чек-лист ?
Как держать размер чек-листа под контролем ?
Как интегрировать чек-лист в процесс создания проекта ?
Чем чек-лист полезен в сложных проектах ?
Очевидно, что чек-лист добавляет дополнительные часы в разработку продукта. Однако вовремя выполненное домашнее задание превентивно предотвращает большую часть уже известных проблем в вашем продукте и помогает обеспечить успешный релиз продукта.
Чек-лист поможет решить следующие вопросы:
Избавитесь от мыслей, что вам нужно держать в памяти абсолютно всеВедь люди — не роботы. Что-то может просто вылететь из головы даже если вы делаете одно и то же действие 101-й раз.
Сможете обнаруживать и решать проблемы превентивно, до момента их появления
Большинство известных проблем можно избежать на моменте проектирования или разработки, до момента релиза используя хорошо составленные чек-листы.Сможете прогнозировать требуемые для проекта ресурсы заранее
Добавив в чек-лист задание на исследование о требуемых ресурсах при неких прогнозируемых нагрузках, вы сможете подготовить релизный плацдарм при стремительном масштабировании проекта.Расставите приоритеты по ключевым и опциональным требованиям к продукту
Расставив приоритеты таким образом, вы сможете наиболее верно оркестрировать порядком выполнения задач и планировать сроки релиза.Мотивируете отдел разработки на реализацию необходимых задач
Некоторые задачи могут быть не очень интересными, но необходимым условием для запуска проекта в продакшн. Добавив такое требование в чек-лист, вы мотивируете разработчиков на выполнение подобных задач, т.к. без выполненной задачи проект не отправится в релиз.Например, предоставление метрик в нужно формате не самая интересная задача, но она необходима для хорошей наблюдаемости продукта.Создадите план на случай непредвиденных обстоятельств, повысите стабильность продукта
Как пример, k8s обладает некоторыми способностями к «самолечению» приложения с помощью liveness probes. Конкретно эту особенность стоит использовать с большой осторожностью.Сможете отслеживать прогресса готовности продукта
Например, сравнив минимально необходимый список требований к продукту с реализованным вы можете судить о степени готовности продукта к релизу.Единая точка входа в продакшн для всех подобных проектов
Мы можем быть уверены, что все приложения имеют минимально необходимый стандарт качества работы в продакшене. Например: проблемы, которые были решены в предыдущих проектах, не будут лежать граблями для новых проектов.
Как создать чек-лист ?
Хорошо, этот подход нужен для нашего проекта, что я должен сделать? Ниже рассмотрим процесс создания чек-листа.
Чек-лист должен быть целостными. В чек-листе должны быть затронуты моменты начиная с логистических (дата запуска, материально-техническое обеспечение) вещей необходимых для запуска, заканчивая планом действий при нештатной ситуации.
Давайте рассмотрим более детально шаги для составления этого списка:
Определите необходимый целевой уровень обслуживания проекта
Чем более надежный продукт нужен конечным потребителям, тем более детальный будет ваш чек-лист.
С одной стороны появляется желание сделать максимально детализированный чек-лист, но с другой это отнимет много ресурсов и может быть вовсе без надобности, т.е. Чем более надежный продукт вам необходим, тем дороже он будет стоить. Более критичные сервисы лучше и более детально структурированы, чем остальные. Например, Mercari определяет этот показатель основываясь на SLO.Mercari разделяет проекты на три группы с корреляцией по Service-Level Objective (SLO), а далее в зависимости от требуемого уровня определяет детализацию чек-листа и минимальный набор элементов в нем.
Service Levels | Required SLO |
A critical microservices | > 99.9% |
B standard microservices | 99% ~ 99.9% |
C experimental microservices | 95% ~ 99% |
Определите группы, в которых должны находиться элементы списка (Map out all the checklist areas)
Перечислите все основные компоненты и связи вашего продукта с другими компонентами.
Эти компоненты могут разрабатывать разные команды. Нам важно знать все команды, с кем необходимо пообщаться перед запуском продукта и чем раньше это будет сделано, тем лучше.Ниже рассмотрены некоторые группы вопросов, которые стоит взять во внимание:Серверные вопросы (server-side): Какие типы серверов необходимы для продукта ? Если мы работаем в облаке, то достаточно ли лимитов, покрывает ли текущий тариф планируемую нагрузку ?
Конечные потребители (client-side): Будет ли удобен и доступен ваш продукт для всех потенциальных клиентов ?
Мониторинг: Предоставляет ли ваш продукт метрики в нужном формате?
Рост, развитие: Есть ли у вас дорожная карта того, как вы будете поддерживать, улучшать проект в будущем? Что делать, если произойдет планируемый рост количества пользователей, не планируемый всплеск? Что делать вам нужно сделать, чтобы добавить новую фичу?
Зависимости: От каких других внутренних и внешних компонентов зависит ваш проект? Будут ли они интегрироваться постепенно или единоразово?
Тестирование: Были ли проведены тесты нового проекта? Было ли произведено тестирование в условиях приближенных к реальному продакшену ? Какой уровень покрытия тестами ?
Безопасность: Должен ли ваш проект пройти проверку в отделе безопасности?
Надежность: Какой уровень надежности ожидают ваши пользователи? Есть ли у вас план действий на случай, если вы не сможете оправдать эти ожидания?
Реагирование на происшествия (incident management): Что вы будете делать, если инцидент приведет к остановке сервиса или ухудшению качества обслуживания (напр. недоступен в некоторых регионах)? Имеется ли у вас runbook для описания способов решения известных проблем?
Юридический аспект: У вас есть соглашение об уровне обслуживания (SLA), которое гарантирует доступность? Оперирует ли проект личной информацией или приватными данными, которые должны обрабатываться особым образом в соответствии с правовыми требованиями в регионах присутствия.
Логистика: Каков график релизов? Что вам понадобится для запуска?
Больше деталей по этим вопросам можно найти на этих ресурсах Google«s Launch Coordination Checklist, gruntwork.io«s AWS checklist, Mercari«s checklists. Особенно рекомендую обратить внимание на последний проект, там можно найти много интересного.
Добавьте элементы чек-листа в созданные группы
Каждая из обозначенных групп может содержать множество подводных камней. Для решения этой проблемы предлагается задать правильный вопрос, который даст ответ как обойти подводные камни. А ответить на эти вопросы поможет команда, ответственная за эту группу вопросов. Этот пункт мы прорабатывали на предыдущем шаге.
Пример, как может быть реализован подход с вопросами.Хорошая мысль — добавить контактное лицо, с кем можно обсудить ту или иную группу вопросов. Отмечайте выполненные элементы списка по мере реализации. Стоит обратить особое внимание на чек-лист и пройтись несколько раз по списку. Так же имеет смысл пройтись по списку перед самым запуском проекта, ведь могло что-то измениться или остаться «на потом».
Как держать размер чек-листа под контролем ?
В процессе создания чек-листа вы будете затрагивать все больше и больше групп вопросов и вам захочется добавлять новые аспекты. Чтобы ваш чек-лист не превратился в произведение в трех томах, убедитесь, что информация содержащаяся в чек-листе действительно полезна и востребована для запуска проекта.В книге SRE book by Google имеется два критерия, которые помогают понять, следует ли добавлять новый элемент в список:
Добавление каждого элемента должна быть обоснована, в идеале, предыдущими проблемами при запуске продукта.
Каждая инструкция должна быть конкретной, практичной и разумной с точки зрения реализации разработчиками.
Как интегрировать чек-лист в процесс создания проекта ?
Чтобы процесс интеграции чек-листов в ваш проект прошел наиболее безболезненно и плавно можно использовать подход описанный ниже.
Стоит разделить чек-лист на разные стадии и начать процесс интеграции на этапе проектирования продукта, а затем постепенно реализовывать пункты из списка.Например, в Production Readiness Checklist at Mercari подходе существует 2 стадии:
Этап проектирования (Design Checklist)
Этап разработки, время создания продукта до момента релиза (Pre-production Checklist)
Этот поход поможет вам с меньшей болью проходить все пункты чек-листа, а именно:
Время учтено при проектированииВремя затраченное на выполнение условий чек-листа будет заложено в разработку и вы не будете нарушать dead-line сроки по этой причине (как могло бы случится, если бы эти пункты выполнялись на поздних этапах)
Создать с чистого листа проще, чем переделывать готовый проектЗачастую переделывать уже готовый проект под условия чек-листа намного сложнее, что влечет за собой желание отложить прохождение некоторых пунктов списка в технический долг, до следующего рефакторинга
Разработчики возьмут этот подход на вооружение При проектировании следующего компонента разработчики уже будут знать требования к продукту и смогут на этапе проектирования учесть многие нюансы
Подход разделяй и властвуй себя хорошо зарекомендовал еще с давних времен, поэтому вы можете разделить процесс на большее количество стадий, чтобы процесс был наиболее удобным.
Конечно можно добавить нужное вам количество стадий, например часто используется чек-лист созданный для проверки после запуска проекта. В частности, после запуска проекта важно внести правки в пройденный чек-лист, таким образом итеративно улучшается составленный список.
Если вопрос об интеграции чек-листа нужно «продать» руководителю проекта, то можно обратиться к разделу выше, где мы рассматривали причины, чем чек-лист полезен в сложных проектах.
Заключение
Из этой заметки можно извлечь несколько уроков.
Первый, очевидно, заключается в том, что вам стоит использовать чек-лист. Он должен быть создан с учетом требований вашей компании и вашего продукта.
Во-вторых, чек-листы должны быть хорошо продуманы. Это совсем не то же самое, что и список покупок всего, что может потребоваться. Чек-лист больше похож на ловушку для ошибок и популярных проблем. Мы сокращаем количество известных проблем, которые могут помешать нашим планам по запуску продукта.
Список используемых материалов
На этом все. А всех желающих в преддверии старта курса DevOps практики и инструменты от OTUS, приглашаю на бесплатный вебинар по теме:»Управление конфигурацией. Знакомство с Ansible».
