Эволюция SRE: Системный подход к надёжности на примере Google

«Инженеры Google теперь проектируют системы, которые не просто работают — они не могут сломаться непредвиденным и опасным образом»

Надёжность — это не отсутствие ошибок, а способность системы безопасно управлять сложностью. STAMP даёт инструменты для этого, смещая фокус с «тушения пожаров» на проектирование устойчивых систем.

Основные выводы

1. От компонентов к системам
   Традиционные методы, такие как анализ цепочек событий, недостаточны для сложных систем. STAMP фокусируется на взаимодействиях компонентов, включая человеческий фактор и программные контроллеры.
   Пример: Сбой в системе квотирования Google (2021) произошёл из-за некорректной обратной связи, а не из-за ошибки в одном компоненте.

2. Состояния опасности (Hazard States)
   Авария — это результат длительного нахождения системы в опасном состоянии, а не мгновенного события. Обнаружение таких состояний позволяет предотвратить сбои.
   Пример: Автоматическое снижение квоты ресурсов привело к нехватке, но система находилась в «опасном состоянии» несколько недель до аварии.

3. Обратные связи так же важны, как контроль
   STPA (System-Theoretic Process Analysis) выявляет уязвимости не только в алгоритмах управления, но и в цепочках данных.
   Пример: Ошибка в агрегации данных об использовании ресурсов привела к неверным решениям правсизера квот.

Практические рекомендации

1. Внедряйте системно-теоретический анализ
   • Проводите STPA-сессии при проектировании систем. Это помогает выявить unsafe control actions (UCA) — сценарии, где корректные действия компонентов приводят к рискам.
   • Используйте карты контроля и обратных связей для визуализации взаимодействий.
2. Мониторинг состояний опасности
   • Разработайте метрики для обнаружения Hazard States (например, длительные отклонения в данных обратной связи).
   • Добавьте «буферы безопасности» — как задержка применения изменений квот в примере Google.
3. Обучение команды
   • Изучайте основы теории управления и системного мышления.
   • Анализируйте инциденты через призму STAMP: спрашивайте не «что сломалось?», а «какие взаимодействия привели к сбою?».
4. Проактивность вместо реактивности
   • Замените поиск «корневых причин» анализом системных ограничений.
   • Внедряйте автоматизацию для проверки корректности обратных связей (например, валидацию данных перед применением изменений).