Service Level Indicators и Objectives¶
Требования применяются к production-сервисам, data pipelines и клиентским
приложениям. Уровни обязательности определены в корневом README.md.
Критичной считается возможность или результат обработки, отказ которых нарушает внешнее обязательство, приводит к потере или недоступности защищаемых данных либо требует оперативного реагирования.
OPS-SLO-001. Пользовательские SLI¶
Уровень: MUST
Применяется к: каждой критичной возможности production-сервиса, data pipeline или клиентского приложения
Проект должен определить Service Level Indicator (SLI) успешности или доступности и задержки на границе, наблюдаемой потребителем. Запрос SLI должен точно определять хорошие и учитываемые события, окно и исключения.
Обоснование¶
Внутренняя работоспособность не равна результату пользователя.
Проверка¶
- review формул SLI;
- сопоставление с
OBS-MET-003; - тест успешного, ошибочного и исключённого трафика.
Исключения¶
Асинхронная возможность может измерять время до результата вместо HTTP latency.
OPS-SLO-002. Численные SLO¶
Уровень: MUST
Применяется к: каждому SLI production-сервиса, data pipeline или клиентского приложения
Владелец проекта должен установить численный Service Level Objective (SLO), окно измерения и дату пересмотра. Корпоративное значение по умолчанию не устанавливается. Цель должна быть достижима по данным SLI и строже порога, после которого результат неприемлем потребителю.
Обоснование¶
Без числа и окна соответствие цели невозможно определить.
Проверка¶
- автоматический расчёт за полное окно;
- проверка владельца и даты пересмотра;
- сопоставление цели с контрактом сервиса.
Исключения¶
Новый сервис может использовать временную цель с численным сроком калибровки.
OPS-SLO-003. Error budget¶
Уровень: SHOULD
Применяется к: SLO успешности или доступности
Проекту следует рассчитывать оставшийся error budget и скорость его расходования, если SLO используется для решений о темпе поставки. Политике следует определять численные пороги, при которых ограничиваются рискованные изменения и приоритет получает восстановление надёжности.
Обоснование¶
Error budget связывает цель надёжности с решениями о поставке.
Проверка¶
- проверка расчёта на контрольных данных;
- тест превышения burn-rate;
- review действий при исчерпании.
Исключения¶
Error budget MAY не использоваться, если SLO служит только внешним отчётным показателем и решения о поставке принимаются по другому проверяемому критерию.
OPS-SLO-004. Оповещения по SLO¶
Уровень: MUST
Применяется к: alert, требующему оперативного действия
Alert должен использовать burn-rate или иной показатель угрозы SLO, иметь численные пороги, окна, severity, владельца и ссылку на runbook. Health checks, служебный и синтетический трафик должны исключаться либо классифицироваться отдельно.
Обоснование¶
Оповещение по пользовательскому ущербу уменьшает шум.
Проверка¶
- тест быстрого и медленного расходования budget;
- проверка маршрута уведомления;
- сверка фильтров с формулой SLI.
Исключения¶
Infrastructure alert допустим отдельно, если требует самостоятельного действия.
OPS-SLO-005. Полнота и неизменность данных¶
Уровень: MUST
Применяется к: вычислению SLI и SLO
Отсутствие телеметрии не должно автоматически считаться успешным результатом. Изменение формулы, источника или фильтра должно быть версионировано и пересчитать сравнимый период либо обозначить разрыв ряда.
Обоснование¶
Пробел или скрытая смена формулы создаёт ложное соблюдение SLO.
Проверка¶
- тест отсутствующих данных;
- review истории запросов;
- проверка обозначения разрыва.
Исключения¶
Не допускаются.