Product/Feature Operational Readiness в Amazon

Некоторые команды в Amazon перед запуском новой фичи или продукта создают документ, который помогает ответить на вопрос: готов ли продукт или фича к эффективной поддержке в продакшене.

Для этого документа существует шаблон со списком вопросов, на которые необходимо дать ответы. По сути, это анкета, которую требуется заполнить. Сам документ хранится в виде страницы на внутренней вики.

Документ заполняется перед самым запуском в проде. К тому времени дизайн и реализация уже сделаны. Код, обычно, уже в проде, но еще не включен. Регулируется это при помощи feature-switch/kill-switch.

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

Какие, основные, пункты/вопросы в этом документе?

1) Краткое описание фичи. Что за фича, зачем она нужна, как работает. Описание должно быть простым, чтобы его можно было понять, если вас разбудят в 3 часа ночи и вы понятия до этого не имели о чем эта фича. Т.к. часто нужно поддерживать функционал, которые ты не очень глубоко знаешь, который был разработан другими коллегами.
2) Ссылка на дизайн док. Позволяет быстро найти дизайн фичи и ознакомиться с ним.
3) Ключевые бизнес метрики/KPI. Какие бизнес-показатели необходимо мониторить при работе данного функционала и почему. Нужно указать ссылку на метрику или дашборд. На графике обязательно, помимо самого показателя, должен быть указан трешхолд, при превышении или недостижении которого автоматически должна создаваться таска для саппорта (alert) или sev. График должен легко читаться, даже если вас разбудят в 3 часа ночи.
4) Операционные метрики. Ссылка на дашборды и метрики технического характера. Они также должны легко читаться, иметь трешхолды и алерты. Смотря на график должно быть понятно о чем график и когда все плохо и когда все хорошо. Эти графики помогают во время саппорта проводить быстрые инвестигации инцидента.
5) Ссылки на runbooks. Ссылки на ранбуки, в которых описана последовательность действий, которые нужно совершить во время того или иного инцидента. Эти ранбуки должны быть простыми и детальными, чтобы их мог выполнить кто угодно без подготовки в 3 часа ночи. Шаги должны быть направлены на митигацию инцидента, а не на поиск и устранение root cause. Обычно, это какие-то rollback, рестарты или killswicth. Эти ранбуки должны автоматически попадать в дескрипшен саппорт таски или sev, которые создаются алертами.
6) Список dependency и влияние их отказа на систему. Обычно, продукт или фича зависят от других компонент. Нужно описать, что произойдет при частичном и полном отказе этих зависимостей. Есть ли circuit breaker для каждой из dependency, есть ли retry, если ли throttling/rate limiting и т.д.
7) Как выключить фичу? Есть ли killswitch и как быстро выключить функционал.
8) Ссылки на алерты. В каких случаях автоматически будет создана таска саппорта или инцидент. На каких метриках это базируется, какие трешхолды. Какое описание таски будет создано. Какие ранбуки будут прикреплены.
9) Ссылки на тесты. Unit тесты, интеграционные, end-to-end, перфоманс, load тесты, стресс тесты и т.д.

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