SRE постоянно стремится к надежности и стабильности наших систем. Но чтобы к чему-то стремиться, нужно понимать, к чему. Иначе мы либо приедем не туда, либо будем ездить по кругу. Стремительно. 🚗💨
Чтобы знать, куда двигаться, есть три ключевые концепции, которые помогут в этом: SLI, SLO и SLA.
🔍 Коротко о каждом
SLI (Service Level Indicator)
Индикатор уровня обслуживания. Это метрика, которая измеряет конкретный аспект производительности вашего сервиса. Проще говоря, это то, что можно посчитать и отследить. Например, процент неудачных запросов или 95-й процентиль времени отклика.
SLO (Service Level Objective)
Цель уровня обслуживания. Это целевое значение для SLI, которое определяет желаемый уровень производительности. Это своего рода планка, к которой мы стремимся. Например, не более 0,1% запросов с ошибкой или 95-й процентиль времени отклика не превышает 100 мс.
SLA (Service Level Agreement)
Соглашение об уровне обслуживания. Это официальный договор между вами (как поставщиком услуги) и вашими пользователями (клиентами). Он определяет гарантированный уровень сервиса и последствия его нарушения. Внутри компании SLA редко применяется — это больше про работу с внешними клиентами.
🤏 Если совсем коротко:
SLI: Измеряем производительность и доступность.
SLO: Ставим цели для выбранных метрик.
SLA: Договариваемся об обязательствах.
🔄 Связь между ними
SLI играет ключевую роль в определении SLO и, в конечном счете, SLA. SLI предоставляет данные для оценки текущего уровня обслуживания, на основе которых устанавливаются SLO. SLO, в свою очередь, является основной частью SLA, определяя ожидаемый уровень обслуживания, к которому стремится поставщик услуг.
На первый взгляд может показаться, что это просто цифры и графики в Grafana, которые никому не нужны. Но это заблуждение. Приведу цитату из статьи Google:
У каждого сервиса должен быть уровень доступности — без него ваша команда и заинтересованные стороны не смогут принимать принципиальные решения о том, нужно ли сделать ваш сервис более надежным (увеличивая стоимость и замедляя разработку) или менее надежным (обеспечивая большую скорость разработки). Избыточная доступность может стать проблемой, потому что теперь это ожидание. Не делайте свою систему чрезмерно надежной, если вы не намерены делать ее настолько надежной.
Без SLO невозможно принимать обоснованные решения о балансе между надежностью, стоимостью и скоростью разработки. Кроме того, работа над надежностью становится хаотичной и неэффективной.
📖 Что ещё почитать по теме:
- https://cloud.google.com/blog/products/devops-sre/sre-fundamentals-slis-slas-and-slos
- https://www.atlassian.com/incident-management/kpis/sla-vs-slo-vs-sli
До связи!
P.S. Добавил комменты. Давайте общаться и делиться мыслями 💬
#sre #sla #slo #sli #надежность
