Готовность к продакшену: чеклист запуска, что и есть весь трек

«Готово ли к продакшену?» — вопрос, что заканчивает каждый проект и начинает каждый инцидент, и большую часть карьеры ты будешь отвечать на него ощущением — смутной уверенностью, что код работает, потому что тесты проходят и демо прошло гладко. Весь этот трек был аргументом, что ощущение бесполезно, потому что тесты бегут в чистой комнате, а продакшен — нет. Семь юнитов дали тебе семь конкретных вещей, что ощущение не может проверить: получает ли процесс реально SIGTERM, размерен ли пул под медленнейшую зависимость, может ли ретрай списать дважды, есть ли у breaker реальный таймаут для счёта, влезает ли дренаж внутрь grace period, можешь ли ты видеть p99. «Готов к продакшену» — не свойство, что ты чувствуешь; это свойство, что ты проверяешь, гейт за гейтом, и весь трек схлопывается в один артефакт: чеклист. Этот финальный урок — тот чеклист — не как бюрократическое проставление галочек, а как вынесенная вовне форма сеньорного суждения, что ты строил. Каждый пункт — юнит, каждый юнит — режим отказа, что кто-то пережил, а ревью запуска — лишь дисциплинированный акт спросить, вслух и до прибытия трафика, закрыт ли каждый из тех режимов отказа. Цель трека никогда не была знать семь механизмов. Она была в том, чтобы суметь встать перед сервисом, что вот-вот возьмёт реальный трафик, и сказать да, и вот откуда я знаю.

Чеклист — это трек, перевёрнутый

Каждый юнит этого трека определил режим отказа и дисциплину, что его закрывает. Ревью готовности к продакшену проходит те дисциплины в обратную — не «что мы выучили», а «что должно быть истинным до прибытия трафика». Каждый гейт — вопрос с проверяемым ответом, не да/нет-вайб:

1. Lifecycle и сигналы. Получает ли процесс реально SIGTERM (он PID 1 или есть init, что форвардит сигналы)? На месте ли лимиты размера тела и backpressure, чтобы кривой запрос не исчерпал память? Обеспечен ли таймаут запроса на краю?
2. Middleware и DI. Есть ли единое место, где ставится бюджет таймаута, и распространяется ли он вниз по стеку? Внедрены ли зависимости так, чтобы сервис был тестируем, а проводка явной, не спрятанной в порядке загрузки модулей?
3. Async I/O и loop. Блокирует ли что-нибудь event loop (синхронная криптография, синхронный файловый I/O, тугой CPU-цикл)? Наблюдается ли лаг loop? Один блокирующий вызов стопорит каждый конкурентный запрос.
4. Пулинг. Ограничен ли каждый пул и размерен ли под пропускную способность своей медленнейшей зависимости? Есть ли таймаут получения, чтобы насыщенный пул падал быстро вместо зависания? Насыщение — метрика?
5. Идемпотентность и ретраи. Идемпотентна ли каждая ретраенная запись (ключ идемпотентности, таблица дедупа или no-op-на-применённом стейт-машина)? Ограничены ли ретраи с backoff и jitter? Неидемпотентный ретрай — двойное списание; неограниченный ретрай — шторм.
6. Circuit breakers и bulkheads. Есть ли у каждого внешнего вызова таймаут и breaker? Изолирован ли радиус поражения, чтобы одна падающая зависимость не съела всю ёмкость? Состояние breaker — первоклассная метрика?
7. Graceful shutdown. Влезает ли дренаж внутрь grace period (preStop sleep + дренаж keep-alive + разборка в обратном порядке + запас безопасности)? Работа в полёте либо закончена, либо безопасно переочередена? Дерегистрируется ли shutdown до того, как дренирует?
8. Наблюдаемость и контроль нагрузки. Выпускает ли сервис RED, перцентильную латентность (не среднее) и внутреннее состояние каждого механизма? Есть ли SLO и error budget? Есть ли сбрасыватель нагрузки на краю, завязанный на насыщение?

Чеклист — не бюрократия, а вынесенная вовне экспертиза

Инстинкт сильного инженера — не доверять чеклистам как инструменту людей, что не понимают систему. Тот инстинкт задом наперёд. Чеклист существует потому что эксперты забывают — не от невежества, а от когнитивной нагрузки, давления времени и того факта, что режимы отказа независимы, так что любой из восьми может быть тем, о котором ты случайно не подумал в 3 ночи перед запуском. Чеклист превращает набор тяжело давшихся, по отдельности болезненных уроков в надёжный процесс, что не зависит от того, помнит ли какой-то один человек всё под стрессом. Это тот же ход, что pre-flight чеклист в авиации: пилоты — эксперты, и они читают чеклист всё равно, ровно потому что экспертиза плюс усталость всё ещё пропускает пункты. Ревью готовности — то, как команда делает сеньорное суждение своего опытнейшего члена повторяемым и обучаемым, вместо проживающего в одной голове.

Готовность — спектр, завязанный на радиус поражения

Не каждому сервису нужны все восемь гейтов закрытыми до одной глубины, и притворяться иначе — собственный сбой — это учит людей играть чеклист. Внутренний инструмент, обслуживающий десять инженеров, и платёжный API, обслуживающий миллионы, сидят в разных точках спектра готовности, и верная глубина каждого гейта пропорциональна радиусу поражения: сколько пользователей, сколько денег, насколько необратим урон при сбое. Сеньорный навык — не закрывать каждый гейт максимально; это калибровать каждый гейт под цену сбоя, что он предотвращает, и быть явным насчёт того, какие гейты ты сознательно оставляешь приоткрытыми и почему. Ревью готовности, что возвращает «всё зелёное, без оговорок» на сложном новом сервисе, не успокаивает — обычно это значит, что кто-то не был честен насчёт компромиссов.