Порядок построения — иерархия надёжности

Роадмап отвечает на два вопроса про инженера: что он обязан уметь в роли (priority) и на каком уровне зрелости (SFIA во фронт-маттере листьев). Есть третий вопрос, который они не закрывают: в каком порядке всё это имеет смысл строить в конкретном сервисе. На него отвечает иерархия надёжности Микки Дикерсона из SRE-книги — пирамида, где каждый слой опирается на нижние.

Практическая ценность модели в том, что она объясняет провалы внедрения. Я регулярно вижу, как команда затаскивает chaos engineering или progressive delivery, не имея работающего алертинга и внятного разбора инцидентов, — верхние слои строятся на песке, и через полгода инициатива тихо умирает. Обратный перекос тоже встречается: три года полируем дашборды, а требования к надёжности с продуктом так и не обсудили.

Семь слоёв

1. 7Product

   Требуемый уровень надёжности — продуктовое решение: сколько недоступности переживёт пользователь и бизнес.

   • Dev Team Partnership
   • Stakeholder Management
   • SLO / Budget Review
2. 6Development

   Надёжность закладывается в архитектуру и код, а не докручивается мониторингом сверху.

   • Resilience Patterns
   • Infrastructure as Code
   • Chaos Engineering
3. 5Capacity Planning

   Отказ от нехватки ресурсов — предсказуемый и потому предотвратимый класс отказов.

   • Capacity Planning
   • Cost Management
4. 4Testing + Release procedures

   Самая частая причина инцидентов — изменение; слой ограничивает ущерб от собственных релизов.

   • Test Strategy
   • CI/CD
   • Progressive Delivery
5. 3Postmortem / Root Cause Analysis

   Инцидент превращается в изменение системы, а не в устный опыт одного дежурного.

   • Blameless Postmortem
   • Postmortem Culture
   • Systematic Troubleshooting
6. 2Incident Response

   Сигнал превращается в действие: кто разбирает, по какой роли, за какое время.

   • Incident Response
   • On-Call Rotation
   • Severity Classification
7. 1Monitoring

   Без измерений всё выше — угадывание: непонятно, сломано ли, насколько и стало ли лучше после починки.

   • SLO Engineering
   • SLI-based Alerting
   • Symptom vs Cause Alerting

Снизу вверх: каждый слой опирается на нижние. Номер — уровень иерархии, не приоритет и не SFIA.

Как читать пирамиду

Слои не проходятся строго по очереди. Организация занимается несколькими одновременно; модель говорит не про очередь задач, а про то, где основание, а где надстройка. Практический вопрос звучит так: если слой ниже сломан, имеет ли смысл вкладываться в тот, что выше. Обычно не имеет — сначала чинится основание.

Пирамида описывает состояние сервиса и команды, а не карьеру инженера. Её нельзя путать ни с priority, ни с SFIA: компетенция из верхнего слоя вполне может быть Must Have для роли — например, ревью SLO с продуктом. Инженер растёт по своей оси, сервис — по этой.

Слои не равны по объёму работы. Мониторинг и incident response ставятся за недели, capacity planning живёт кварталами, а продуктовый разговор о надёжности — это не проект с датой завершения, а постоянный режим. По моим наблюдениям, команды недооценивают именно верх: там нет тикетов, которые можно закрыть, поэтому слой тихо остаётся пустым.

Что с этим делать на практике

Я использую пирамиду как диагностику перед тем, как соглашаться на инициативу. Три вопроса снизу вверх: видим ли мы деградацию раньше пользователя, превращается ли сигнал в действие с понятной ролью, превращается ли инцидент в изменение системы. Если хоть на одном ответ «нет», а команда предлагает game day или service mesh — разговор идёт не о том слое.

Обратная сторона: пирамида не оправдывает бесконечное вылизывание основания. Слой считается закрытым не когда он идеален, а когда перестал быть узким местом. Мониторинг с 95% actionable-алертов достаточно хорош, чтобы заниматься релизной дисциплиной.

Связанные документы

• Приоритеты — ось обязательности компетенции для роли.
• Методология — как устроены обе оси проекта и почему они независимы.
• Формат проекта — как устроена карта и из чего состоит лист.