6.0 Введение в часть 6: Метрики надёжности, эксплуатации и безопасности

Часть 2 охватывала то, как изменение попадает от коммита до продакшена; эта часть охватывает то, что происходит, как только оно там запускается, бесконечно, в реальных условиях, которые команда не может полностью контролировать. Метрики надёжности, эксплуатации и безопасности это то место, где обещания программной инженерии встречают устойчивую реальность: не «удалось ли это развёртывание», а «продолжает ли эта система работать, ночь за ночью, под нагрузкой, под атакой и под напряжением дежурства, которое должно быть устойчивым годами, а не только до следующего инцидента».

Четыре темы этой части следуют сознательной дуге. Индикаторы и цели уровня сервиса (тема 6.1) устанавливают словарь и дисциплину установки целей, от которых зависит всё остальное в этой части. Метрики инцидентов (тема 6.2) измеряют то, что происходит, когда эта цель упущена. Метрики дежурства и мощности (тема 6.3) измеряют человеческую и инфраструктурную стоимость поддержания достижения цели. Метрики безопасности и уязвимостей (тема 6.4) расширяют ту же дисциплину надёжности на отдельный, но тесно связанный риск: не «откажет ли это само по себе», а «заставит ли кто-то это отказать намеренно». Все четыре темы разделяют центральную дисциплину этой книги: назвать метрику, назвать то, как она манипулируется, и сочетать её со страховочной метрикой, ловящей это манипулирование.

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

Темы этой части

• 6.1 Индикаторы и цели уровня сервиса, и бюджеты ошибок: Словарь и дисциплина установки целей, лежащие в основе всей инженерии надёжности сайта, и то, как бюджет ошибок превращает надёжность в расходуемый, управляемый ресурс, а не недостижимый абсолют.
• 6.2 Метрики инцидентов: обнаружение, реагирование и восстановление: Измерение того, как быстро организация замечает отказ, реагирует на него и устраняет его, и безвиновная дисциплина, сохраняющая это измерение честным.
• 6.3 Метрики дежурства, мощности и операционной нагрузки: Человеческая и инфраструктурная стоимость поддержания надёжности, и почему неустойчивое бремя дежурства в конечном итоге само проявляется как проблема надёжности.
• 6.4 Метрики управления безопасностью и уязвимостями: Расширение того же дисциплинированного, сочетанного со страховочной метрикой подхода на риск безопасности, от обнаружения уязвимости до устранения.

Как эти темы взаимосвязаны

Тема 6.1 закладывает основу, на которой строится каждая более поздняя тема этой части: без ясной цели уровня сервиса «насколько плохим был этот инцидент» (тема 6.2) и «устойчива ли наша нагрузка дежурства» (тема 6.3) не имеют общей точки отсчёта для измерения против неё. Метрики инцидентов темы 6.2 в реальном смысле это запись расходования бюджета ошибок, который вводит тема 6.1; тема 6.3 измеряет устойчивость человеческой системы, ответственной за удержание этого расходования в рамках бюджета; а тема 6.4 применяет то же мышление цели и бюджета к позиции безопасности, которая, оставленная неизмеренной, имеет тенденцию получать внимание только реактивно, после инцидента, а не проактивно.

Эта часть напрямую связывается обратно с частью 2: доля неудачных изменений DORA и время восстановления после неудачного развёртывания (обе охвачены в теме 2.10) соответственно опережающий индикатор для метрик инцидентов этой части и их экземпляр. Она также связывается вперёд с частью 8, где руководство по панелям и зрелости программы сильно опирается на модель бюджета ошибок этой части как на отработанный пример превращения абстрактной цели (надёжность, безопасность) в конкретную, отслеживаемую, неабсолютную цель, которой команда может фактически управлять изо дня в день.