SRE (Site Reliability Engineering)

SRE — подход к управлению операциями и надежностью систем.
Объединяет программирование и системное администрирование, чтобы автоматизировать и улучшать надежность систем.

Цель: баланс между внедрением новых функций и поддержанием стабильности

Роль SRE: следить за тем, чтобы платформа или сервис были доступны клиентам в любой момент и в любых обстоятельствах.

Задачи

🤎поддержание стабильности сложных систем
🤎устранение рутинных задач
🤎управление рисками сбоев при внедрении новых функций

Где используется

💚крупные технологические компании
💚облачные провайдеры
💚организации с критической инфраструктурой
💚высокоавтоматизированные среды с быстрыми циклами разработки


Принципы SRE

✔ Бюджет ошибок: количество простоев или ошибок, которые может иметь сервис без нарушения SLO
🤎 если SLO доступности — 99.9%, то 0.1% времени простоя может быть использовано для тестирования новых фич

✔ Автоматизация: использовать инструменты для управления и эксплуатации сложных систем, сокращения количества ручных действий (Terraform, Ansible, Grafana и т.д)
🤎 автоматизация для уменьшения времени реакции на инцидент

✔ Мониторинг и оповещение: постоянный мониторинг систем и настройка оповещений только по важным метрикам, чтобы не перегружать команды.
🤎 настройка алертов на время отклика сервиса или процент отказов.

✔ Реагирование на инциденты и постмортемы: следование четко установленным процедурам управления инцидентами.
Подготовка постмортемов— специальных документов с анализом первопричины проблемы и планом дальнейших действий по предотвращению.
🤎 после сбоя в работе сервиса команда проводит постмортем для выявления системных ошибок.


MTTR , MTBF, MTTR

Это характеристики отказоустойчивости систем

✨MTBF (Mean Time Between Failures) -- среднее время между исправляемыми сбоями.
✨MTTR (Mean Time to Repair) -- среднее время восстановления после сбоя
✨MTTA (Mean Time to Acknowledge) -- среднее время с момента отправки оповещения до начала работы над исправлением


SLO, SLI, SLA

Показатели управления уровнем обслуживания

✨SLI (Service Level Indicator) — метрика, измеряющая параметры работы системы.
🤎 пример: время отклика (95% запросов должны обрабатываться менее чем за 200 мс), доступность (99.9% времени сервис должен быть доступен), процент успешных транзакций.

✨Service Level Objectives (SLOs) -- целевое значение для SLI.
SLI определяет фактическое состояние, SLO - устанавливает желаемый уровень этого состояния.
🤎 пример: 95% запросов должны обрабатываться менее чем за 200 мс

✨SLA (Service Level Agreement) — договор между провайдером и клиентом о минимальном уровне обслуживания.
🤎 пример: обещание, что проблему с продуктом X в течение 24 часов.: обещание, что проблему с продуктом X в течение 24 часов.

✅SLIs могут включать метрики, связанные с MTBF и MTTR.
Например, процент времени безотказной работы. SLA может требовать определенный MTBF
✅SLA может содержать обещания по времени восстановления (MTTR), чтобы обеспечить выполнение обязательств перед клиентом


Отличие SRE от DevOps

Имеют общие принципы, но отличаются по основным целям и задачам
➡️ DevOps стремится сократить время между разработкой и развёртыванием через автоматизацию и совместную работу
⬅️ SRE акцентирует внимание на поддержании стабильности и надежности в продакшене, используя инженерные подходы к операционным задачам

➡️ DevOps отвечает за инфраструктуру и автоматизацию
⬅️SRE отвечает за отказоустойчивость "собственного" приложения, разработка ПО


Подборка материалов в следующем посте👇

#развитие #devops