В статье коллеги рассказали, как эволюционировали практики SRE в Google, чтобы справляться с растущей сложностью систем и необходимостью повышения их надежности.
Как было раньше. Изначально SRE-инженеры использовали цели уровня обслуживания (SLO), бюджеты ошибок, стратегии изоляции, тщательные разборы инцидентов (постмортемы) и прогрессивные развертывания, чтобы поддерживать надежность систем.
Что произошло. Сложность систем кратно растет, поэтому риски сбоев увеличиваются. Это и утечки данных, и нарушения конфиденциальности. Традиционные подходы перестали работать — их просто не хватает.
Что теперь. Чтобы справляться с новыми вызовами, Google принял модель STAMP (System-Theoretic Accident Model and Processes), разработанную в MIT.
STAMP смещает фокус с предотвращения отдельных отказов компонентов на понимание и управление сложными взаимодействиями в системе.
Эта модель подразумевает анализ причинных связей на основе системной теории (CAST) для расследования инцидентов, и системно-теоретический процессный анализ (STPA) для выявления потенциальных угроз.
В итоге команды SRE в Google стремятся к проактивному проектированию безопасных систем. То есть, они не реагируют, а стараются прогнозировать и предотвращать эти сбои.
Этот сдвиг в парадигме представляет будущее SRE в Google и, возможно, в индустрии в целом. Или это лишь дополнительная спираль привычных процессов? Как считаете?
@DevOpsKaz 😛