https://github.com/eabykov/sre
Надежность — это не отсутствие сбоев. Это способность системы, команды и человека вместе подняться после падения, переосмыслить, перестроить и идти дальше — с новыми правилами игры, где человеческая уязвимость не угроза, а часть уравнения
https://github.com/eabykov/sre
chaos-testing error-budget incident monitoring mttd mttm mttr postmortem reliability sla sli slo sre stamp
Last synced: 2 months ago
JSON representation
Надежность — это не отсутствие сбоев. Это способность системы, команды и человека вместе подняться после падения, переосмыслить, перестроить и идти дальше — с новыми правилами игры, где человеческая уязвимость не угроза, а часть уравнения
- Host: GitHub
- URL: https://github.com/eabykov/sre
- Owner: eabykov
- Created: 2022-06-02T13:36:22.000Z (almost 4 years ago)
- Default Branch: sre
- Last Pushed: 2025-06-04T12:18:29.000Z (10 months ago)
- Last Synced: 2025-08-04T22:32:09.325Z (8 months ago)
- Topics: chaos-testing, error-budget, incident, monitoring, mttd, mttm, mttr, postmortem, reliability, sla, sli, slo, sre, stamp
- Homepage: https://eabykov.github.io/sre/
- Size: 231 KB
- Stars: 3
- Watchers: 1
- Forks: 1
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
### Материалы и подготовка
1. [Вопросы на собеседовании](questions.md)
2. [Основные принципы SRE](main.md)
3. [Пример хронологии инцидента с ключевыми метриками](example-incident.md)
4. [Паттерны надежности](patterns-of-reliability.md)
5. [Четыре столпа наблюдаемости](observability.md)
6. [Создание неуязвимого мониторинга](disaster-prevention.md)
7. [Внедрение STAMP в Google](stamp-google.md)
8. [Критика MTTx метрик](critic-mttx-metrics.md)
### Основные термины SRE
| Термин | Значение |
|-|-|
| **SLI** | Текущий показатель обслуживания — 99.9% успешных запросов или 99.9% запросов обрабатываются менее чем за 1 секунду
| **SLO** | Цель уровня обслуживания — приложение отвечает быстрее 1 секунды в 99% случаев или сервис доступен 99,5% времени в году
| **SLA** | Документально утвержденная договоренность об уровне обслуживания с потребителями сервиса аналогична SLO, с возможными санкциями за нарушение или премиями за соблюдение
| **Error Budget** | Бюджет проблем — соотношение SLI к SLO, которое помогает разработчикам планировать выполнение задач по улучшению показателей устойчивости и задач с добавлением или изменением функциональности в сервис. Если это соотношение меньше 100%, то в приоритете проблемы с доступностью или производительностью
| **Состояние Опасности** | Свойство системы или набор условий, которые вместе с определенным набором наихудших обстоятельств окружающей среды приведут к инциденту
| **Инцидент** | Ситуация, при которой сервис выходит из нормального (стабильного) состояния, например диск базы данных заполняется с значительно большей скоростью, чем раньше, и на нем не останется места через 1 месяц, время ответа возросло с 1 сек до 2 сек, процент ошибок стал 0.4% вместо 0.06%
| **Postmortem** | Проработка после инцидента — это анализ произошедшего и планирование мероприятий по предотвращению повторения подобного или уменьшению его последствий
| **MTTD** | Время с начала инцидента до его обнаружения (командой мониторинга, сработавшее оповещение и т. д.)
| **MTTI** | Время с обнаружения инцидента до его изоляции - идентификации места поломки, например `Сломан сервис Х` или `Проблемы на балансиловщике Y`
| **MTTM** | Время от изоляции проблемы до устранения ее воздействия на пользователей/партнеров (например, путем переключения трафика на резервную систему или включения обходного пути).
| **MTTR** | Время с изоляции проблемы до полного ее устранения и восстановления нормальной работы сервиса
| **RTO** | Максимально допустимое время простоя системы до её восстановления (определяется в зависимости от критичности системы)
| **RPO** | Максимально допустимая потеря данных (измеряется во времени: например, данные за последние 15 минут могут быть потеряны)
| **STAMP** | Система, спроектированная на достижение безопасного состояния системы (уход от Состояние Опасности). Для понимания причин произошедшего инцидента необходимо определить, почему система управления была неэффективной. Для предотвращения будущих инцидентов необходимо переключить внимание с предотвращения инцидентов на более широкую цель - разработку и внедрение средств контроля, которые обеспечат соблюдение необходимых ограничений для безопасности.