{
  "index": 153,
  "slug": "editorial-2023-10-practice-sli-slo",
  "title": "SLI и SLO: как измерять пользовательский результат, а не цвет графика",
  "excerpt": "Процент успешных ответов не становится SLI сам по себе. Разбираем путь пользователя, знаменатель, хороший исход, окно и цель; показываем учебный расчёт, отрицательный путь и критерий готового договора.",
  "contentHtml": "<p>На дашборде сервис зелёный: 99,9% запросов завершились без HTTP 5xx. Пользователь всё равно нажимает «Оплатить» второй раз. Первый запрос принял API, но очередь не создала платёж, а клиент получил тайм-аут после точки измерения. Команда видит хороший процент и плохой результат. Цена ошибки — неверный приоритет: релиз считают безопасным, расследуют не тот компонент и позже спорят, был ли сбой частью SLO.</p>\n<p>SLI и SLO исправляют эту ошибку только при точном договоре. SLI отвечает на вопрос «что измеряем?». SLO задаёт цель для этого измерения. Договор должен назвать путь пользователя, события в знаменателе, хороший исход, исключения, окно, источник данных и владельца решения. Если хотя бы одно поле скрыто, процент остаётся удобной, но декоративной метрикой.</p>\n<h2>Тезис: начинайте с результата пользователя</h2>\n<p>Google SRE определяет SLI как количественную меру свойства сервиса, а SLO — как целевое значение или диапазон для этой меры. Из этого следует практический порядок: сначала назвать важное для пользователя действие, затем выбрать измеримый признак. Не начинайте с готового счётчика HTTP-кодов только потому, что он уже есть в системе.</p>\n<p>Для checkout полезный вопрос звучит так: «Как часто завершённая попытка оформления получает подтверждение, которое клиент может показать пользователю?» Это ещё не SLI. Он задаёт границу. Теперь нужно решить, какое событие означает завершённую попытку и какое событие означает успех. Ответы должны быть наблюдаемыми и одинаково понятными владельцу продукта, разработчику и on-call.</p>\n<p>Уptime процесса может остаться диагностическим сигналом. Он показывает состояние компонента, но не доказывает успех пользовательского маршрута. И наоборот, один backend-ответ может быть плохим, а продукт — успешно показать fallback. Поэтому название proxy должно оставаться явным. Proxy нельзя выдавать за прямое измерение результата.</p>\n<h2>Механизм договора</h2>\n<p>Для success ratio удобно разделить события на eligible и good. Eligible — все попытки, которые имеют право попасть в знаменатель. Good — подмножество eligible с заранее названным допустимым исходом. Тогда показатель считают так: <code>SLI = good / eligible</code>. SLO задаёт нижнюю границу, например 99% в выбранном окне. Error budget равен допустимой доле bad-событий в том же знаменателе и окне.</p>\n<p>Правило исключения нужно записывать рядом с формулой. Отмена клиентом до отправки запроса может не входить в eligible. Отмена после принятия запроса может быть уже частью результата, если сервис обязан её обработать. Нельзя молча вычёркивать спорное событие после того, как оно ухудшило график. Иначе два отчёта получат разные знаменатели, хотя ссылаются на один маршрут.</p>\n<div class=\"table-scroll\"><table><caption>Минимальный договор для учебного пути checkout</caption><thead><tr><th scope=\"col\">Часть</th><th scope=\"col\">Значение</th><th scope=\"col\">Проверка</th><th scope=\"col\">Ограничение</th></tr></thead><tbody><tr><td>Путь</td><td>Отправка оформленного checkout</td><td>Есть идентификатор попытки и граница завершения</td><td>Не описывает весь сайт</td></tr><tr><td>Eligible</td><td>Запрос дошёл до точки завершения API</td><td>Событие содержит request_id и итоговый статус</td><td>Не включает отмену до запроса</td></tr><tr><td>Good</td><td>Клиент получил подтверждение приёма платежа</td><td>Статус связан с пользовательским ответом, а не только с 2xx</td><td>Не доказывает фактическое списание</td></tr><tr><td>Окно</td><td>28 дней в учебном примере</td><td>Все сравнения используют одну границу времени</td><td>Не является универсальным окном</td></tr><tr><td>Цель и владелец</td><td>99%; владелец checkout</td><td>Есть правило пересмотра и способ связи</td><td>Не даёт автоматического права блокировать релиз</td></tr></tbody></table></div>\n<figure><img src=\"/assets/editorial/2023/slo-error-budget-2023-sli-contract.svg\" alt=\"Схема SLI-контракта: путь checkout, eligible-события, good-подмножество, исключение, окно, цель и владелец\" loading=\"lazy\" /><figcaption>Схема показывает структуру договора до подключения отчёта. Она не является production-дашбордом и не измеряет доступность реального сервиса.</figcaption></figure>\n<p>Число 99% без окна и знаменателя неполно. Сто успешных попыток из ста дают 100%, но один сбой при десяти попытках меняет показатель сильнее, чем один сбой при миллионе. Для малотрафикового маршрута процент может быть шумным. Для пакетной обработки важнее throughput или время завершения. Окно выбирают вместе с типом нагрузки и решением, которое SLO должно поддержать.</p>\n<h2>Учебный пример расчёта</h2>\n<p>Ниже — ограниченный пример. Он проверяет только арифметику договора на заранее заданных числах. Он не читает логи, не обращается к мониторингу и не сообщает состояние какого-либо сервиса. В учебном окне есть 1 000 eligible-событий, из них 994 good. Показатель равен 99,4%. При SLO 99% допустимы 10 bad-событий, а в примере их 6. Остаток условного бюджета — 4 события.</p>\n<pre><code>const eligible = 1000;\nconst good = 994;\nconst target = 0.99;\n\nconst bad = eligible - good;\nconst sli = good / eligible;\nconst allowedBad = eligible * (1 - target);\nconst budgetLeft = Math.max(0, allowedBad - bad);\n\nconsole.log({\n  sliPercent: sli * 100,\n  bad,\n  allowedBad,\n  budgetLeft,\n});\n// Учебный вывод: 99.4%, 6, 10, 4\n// Числа не являются измерением production-сервиса.</code></pre>\n<p>Формула полезна только при сохранении условий. Если из знаменателя убрать неудачные попытки, показатель вырастет без улучшения пути. Если заменить good на «ответ не 5xx», можно начать считать принятый запрос успехом, хотя пользователь ещё не получил подтверждение. Если смешать 28-дневное окно с дневным числом ошибок, error budget потеряет смысл.</p>\n<p>Цель 100% в таком примере не нужна: она скрывает допустимый риск и превращает каждое событие в повод для ручного спора. Это не запрет на строгие требования. Для финансовой операции продукт может выбрать особое правило, но оно должно быть обосновано сценарием, риском и способом проверки. Учебный target не переносится в рабочую систему автоматически.</p>\n<h2>Симптом → причина → проверка → действие</h2>\n<ol><li><strong>Симптом:</strong> на панели есть процент, но разные люди по-разному называют путь, который он покрывает. <strong>Причина:</strong> запрос, дашборд и документация используют разные границы. <strong>Проверка:</strong> попросите показать одно исходное событие и восстановите его путь от начала до результата. <strong>Действие:</strong> зафиксируйте scope и идентификатор операции.</li><li><strong>Симптом:</strong> SLI растёт после фильтрации части ошибок. <strong>Причина:</strong> исключение добавили без правила для знаменателя. <strong>Проверка:</strong> сравните eligible до и после фильтра и разберите один спорный случай. <strong>Действие:</strong> назовите исключение в договоре или верните событие в расчёт.</li><li><strong>Симптом:</strong> «успех» означает любой ответ 2xx, но клиент не подтверждает действие. <strong>Причина:</strong> технический статус подменил пользовательский исход. <strong>Проверка:</strong> проследите, что получает клиент после ответа и где фиксируется завершение. <strong>Действие:</strong> разделите технический proxy и SLI пользовательского пути.</li><li><strong>Симптом:</strong> один сбой в малом потоке меняет решение о релизе. <strong>Причина:</strong> окно и минимальный объём данных не согласованы с трафиком. <strong>Проверка:</strong> покажите число eligible по окну и влияние одного события на процент. <strong>Действие:</strong> выберите иной метод агрегации или оставьте сигнал диагностическим.</li><li><strong>Симптом:</strong> красный график автоматически блокирует изменение. <strong>Причина:</strong> SLO смешали с policy и полномочием на действие. <strong>Проверка:</strong> найдите владельца, правило исключений и обратимый шаг. <strong>Действие:</strong> оставьте решение за владельцем; метрика поставляет evidence, а не разрешение.</li></ol>\n<h2>Порядок внедрения</h2>\n<ol><li>Опишите один пользовательский путь и точку, после которой попытка считается eligible.</li><li>Назовите good event и приведите один пример успеха, один пример ошибки и один спорный случай.</li><li>Запишите исключения, источник событий, окно, target и владельца в одной версии договора.</li><li>Сравните формулу с техническими proxy. Отдельно отметьте расхождение, если измерение заканчивается раньше пользовательского результата.</li><li>Проверьте учебную арифметику на фиксированных числах, но не называйте её наблюдением сервиса.</li><li>В разрешённой среде получите реальные evidence для нескольких событий и убедитесь, что отчёт и обсуждение релиза используют одну формулу.</li><li>Добавьте policy: кто проверяет сигнал, какое действие обратимо, когда пересматривается договор и какие исключения требуют отдельного решения.</li></ol>\n<p>Последний шаг важен. SLO не объясняет корневую причину. Для неё нужны диагностические сигналы: логи, метрики, трассы или данные продукта. OpenTelemetry описывает эти сигналы как разные виды наблюдений: trace показывает путь запроса, metric — измерение во времени, log — запись события. Их можно связать контекстом, но ни один сигнал не доказывает причину без проверки источника и границы времени.</p>\n<h2>Ограничения и отрицательный путь</h2>\n<p>Если событие не содержит request_id, нельзя надёжно связать его с пользовательской попыткой. Если good event появляется раньше фактического завершения, SLI измеряет промежуточный шаг. Если трафика мало, процент может не поддерживать срочное решение. Если внешний провайдер недоступен, нужно заранее определить, входит ли его сбой в договор и кто владеет реакцией. Если событие потеряно, отсутствие строки нельзя считать успехом.</p>\n<p>Отрицательный путь должен быть виден в примерах: нет знаменателя; good больше eligible; в событии отсутствует поле, необходимое для границы; отмена произошла после отправки и ошибочно исключена; два источника считают разные окна. В каждом случае честное действие — остановить интерпретацию и исправить договор или источник. Нельзя дорисовать процент, чтобы сохранить зелёный статус.</p>\n<p>Учебная арифметика также не доказывает SLO compliance, availability, burn rate, incident или безопасность релиза. Она не показывает реальную стоимость простоя. Официальные документы Google помогают выбрать термины и форму описания, но не назначают target конкретному продукту. Производственный критерий должен опираться на реальные события, согласованный владелец и проверяемое правило реакции.</p>\n<h2>Критерий готовности</h2>\n<p>Договор готов, если независимый инженер может без устных пояснений ответить на семь вопросов: какой путь измеряем; что входит в eligible; что считается good; какие исключения действуют; за какое окно считается показатель; где лежат исходные события; кто принимает решение при отклонении. Для трёх заранее выбранных событий формула должна дать одинаковый результат в отчёте и в проверочном запросе. После изменения должен существовать обратимый шаг и способ повторить ту же проверку.</p>\n<p>Если на любой вопрос нет ответа, готовность не достигнута. Сначала исправьте границу и названия событий. Потом меняйте дашборд, алерт или policy. Такой порядок защищает от главной ошибки SLI/SLO: принять число, которое легко измерить, за результат, который действительно важен пользователю.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://sre.google/sre-book/service-level-objectives/\" target=\"_blank\" rel=\"noopener noreferrer\">Google SRE Book: Service Level Objectives</a> — определения SLI и SLO, правила выбора цели, окно измерения и связь с error budget.</li><li><a href=\"https://sre.google/workbook/slo-document/\" target=\"_blank\" rel=\"noopener noreferrer\">Google SRE Workbook: Example SLO Document</a> — официальный пример записи scope, SLI, SLO и условий измерения; это пример формы, а не обязательный шаблон.</li><li><a href=\"https://opentelemetry.io/docs/concepts/signals/\" target=\"_blank\" rel=\"noopener noreferrer\">OpenTelemetry: Signals</a> — официальное описание traces, metrics, logs и других telemetry signals.</li></ul>"
}