На 31 июля 2026 года строгий аудит проходит 205 из 358 созданных материалов. Остальные 153 не считаются «почти готовыми»: их нужно заменить, а не косметически удлинить.
На 31 июля 2026 года строгий аудит проходит 208 из 358 созданных материалов. Остальные 150 не считаются «почти готовыми»: их нужно заменить, а не косметически удлинить.
- Голос: М6, октябрь 2023. Системный практик начинает с наблюдаемого сбоя и цены, затем проходит путь «симптом → причина → проверка → действие», называет owner, границу данных и обратимость. Текст не выдаёт учебную модель за собственный production-опыт.
- Созданы ровно пять sidecar-файлов: этот review, один import-safe script и три локальные SVG. `articles.json`, registry, README, очередь, Git и чужие файлы не менялись; пакет не интегрирован.
- Fixture работает только с фиксированными synthetic JS-объектами в памяти. Он не читает проект, файлы, переменные окружения, часы, monitoring, CI, сеть, HTTP, SDK или production-конфигурацию. Его PASS не заявляет реальный SLI, availability, incident, burn rate, traffic, alert, rollout или release authority.
## Проход 1 — факты, источник и техника
- Источники перепроверены 31.07.2026; все существовали до конца октября 2023: [Google SRE Book, Service Level Objectives, copyright 2017](https://sre.google/sre-book/service-level-objectives/), [Google SRE Workbook, Example SLO Document, 19.02.2018](https://sre.google/workbook/slo-document/), [Example Error Budget Policy, 19.02.2018](https://sre.google/workbook/error-budget-policy/) и [Alerting on SLOs, copyright 2018](https://sre.google/workbook/alerting-on-slos/). Первые два дают определения SLI/SLO, scope и пример четырёхнедельного rolling window; policy описывает баланс надёжности и изменения, а не наказание; alerting разбирает отдельную модель burn rate и проблему low traffic.
- В статьях эти материалы ограничены их фактическими выводами. Четырёхнедельное окно названо примером Google, а не универсальной нормой. Формула fixture не названа burn rate. Policy не превращена в автоматический release gate. Google-примеры не используются как доказательство поведения неизвестного сервиса.
-`createSyntheticSloContract()` принимает только полный `synthetic-slo-contract-input-v1` с фиксированными synthetic scope, 28-day window, good/eligible rules, target и owner. Отрицательные ветки отвергают неотмеченный вход, лишнее network-like поле без его вызова, пропущенное обязательное поле, другую область, другое окно, размытый индикатор, target 100, нулевой знаменатель и impossible counts.
-`runSloFixture()` вычисляет только учебные `syntheticGoodCount`, `syntheticEligibleCount`, `syntheticBadCount`, допустимые synthetic bad и synthetic остаток. Он явно возвращает `observed=not-observed`, `realSli=not-claimed`, `realIncident=not-claimed`, `realBurnRate=not-calculated`, `realAvailability=not-claimed`, `releaseAuthority=not-granted`.
- На техническом проходе найден и исправлен дефект отрицательной ветки rollback: она ошибочно пробовала accepted exhausted sample. Теперь ей передаётся отклонённый `wrongScope`, а assertion требует `restored=false`. Это проверяет границу модели, а не создаёт ложный operational rollback.
-`rollbackSyntheticSloContract()` возвращает только snapshot договора и явно сообщает: monitoring/CI не затронуты, сеть не использовалась, production effect не предпринимался. Он не удаляет данные и не управляет release.
## Проход 2 — редактура, полнота и голос
- Три статьи различаются вопросом. Practice собирает SLI-contract от пользовательского пути; mechanism раскрывает арифметику окна, знаменателя и policy; field строит петлю решения с owner и evidence. Они не пересказывают один текст разными заголовками.
- В первых двух абзацах каждого текста названы проблема и цена: декоративный процент ведёт к неверному релизному решению, неполная формула — к ложной остановке или рисковому rollout, а красный график без owner — к скрытым полномочиям и плохой диагностике.
- В каждой ревизии есть доступная таблица, figure с содержательными `alt` и подписью, исполнимый synthetic fixture, явные ограничения, rollback, финальный следующий шаг и упорядоченный маршрут «симптом → причина → проверка → действие».
-`audit:draft` зафиксировал объём основного текста, включая короткий executable пример и без источников: practice — 9 606, mechanism — 9 892, field — 9 770 знаков. Все три текста находятся в заданной цели 8–10 тыс. и обязательном диапазоне 5–15 тыс. знаков.
- Речь краткая и предметная: термины `SLI`, `SLO`, `eligible`, `good`, `window`, `policy`, `owner` и `proxy` привязаны к контракту или решению. Нет обобщений про «современный мир», фантазий о production-инциденте, обещаний «универсальной доступности» или подмены технической проверки ярким заголовком.
## Проход 3 — визуал, безопасность и выпуск
- SVG разделяют понятия: договор SLI, окно с synthetic арифметикой и петля ручного решения. В них нет `script`, `foreignObject`, внешних URL, `data:image`, event-handler-атрибутов или пользовательского ввода.
- Sharp-render всех трёх SVG на ширине 375 px открыт вручную. После первого рендера были перенесены две нижние подписи и сокращён заголовок петли решения, чтобы текст не обрезался справа. Финальные 375 px варианты читаемы: блоки, стрелки, числа, ограничения и ручная граница release decision не перекрываются.
- Выполнены проверки: `node --check web/scripts/upgrade-2023-10.mjs` — PASS; `node web/scripts/upgrade-2023-10.mjs --verify-fixture` — PASS 22/22 после независимого model review; `cd web && npm run audit:draft -- scripts/upgrade-2023-10.mjs` — PASS для трёх slug; import-safe export без `date`/`author` — PASS; `xmllint --noout` — PASS; SVG safety scan — чистый результат; Sharp 375 px — PASS.
- Пакет не коммитился, не пушился, не интегрировался в registry и не запускал production build: эти действия намеренно оставлены за пределами sidecar и пользовательского ограничения ровно пяти файлов.
## Интеграционное ревью главного агента
Отдельно сверены первичные страницы Google SRE: SLO — target/range измеряемого
SLI; error budget связывается с решением о риске; Example SLO Document даёт
четырёхнедельное rolling window как пример; Example Error Budget Policy не
называет остановку изменений наказанием; Alerting on SLOs разбирает burn rate
и особенно риск ложной чувствительности low-traffic систем. В статьях эти
утверждения сохранены как исторический контекст, не как политика проекта.
Model review закрыл форму synthetic-входа. Раньше helper запрещал лишние keys,
но не требовал полный набор собственных полей. Теперь top-level и все nested
records обязаны быть plain records с точным expected shape; добавлена
отрицательная ветка без `sample`. Fixture после исправления проходит `22/22`
assertions и по-прежнему не получает полномочие на release.
На визуальном проходе в SLI-схеме мобильный рендер обрезал последнюю часть
подписи исключения. Подпись разбита на две строки; повторный Sharp-render 375
px читаем. Все SVG прошли XML и safety scan. Повторный draft audit: 9 640 /
9 892 / 9 770 знаков; строгий archive audit — PASS для трёх slug; registry
содержит 199 уникальных ревизий. `npm run build` успешно сгенерировал 374
<titleid="title">Учебная арифметика окна и error budget</title>
<descid="desc">Слева показано фиксированное synthetic окно 28 дней и synthetic вход. В центре приведён расчёт synthetic eligible, good, bad и допустимых bad. Справа вручную выбирается следующий шаг; это не реальный burn rate или доступность.</desc>
<textx="80"y="652"fill="#243B53"font-family="Arial, sans-serif"font-size="27"font-weight="700">Изменили окно, eligible set или target — получили другую модель.</text>
<textx="80"y="690"fill="#243B53"font-family="Arial, sans-serif"font-size="27"font-weight="700">Это не новая краска графика.</text>
<titleid="title">Петля решения по SLI SLO и error budget</title>
<descid="desc">Петля ведёт от synthetic сигнала через проверку SLI-контракта и контекст разрешённой среды к решению владельца, обратимому действию и повторной проверке. Линия к релизу обозначена как ручное решение без автоматического gate.</desc>
<textx="411"y="690"fill="#7A4D00"font-family="Arial, sans-serif"font-size="24"font-weight="700">No automatic release gate; no real incident claim</text>
<titleid="title">Учебный договор SLI для одного пути пользователя</title>
<descid="desc">Слева указан synthetic путь checkout. В центре eligible события содержат good события, а исключение вынесено отдельно. Справа перечислены synthetic окно, цель и владелец. Внизу указано, что это договор, а не дашборд.</desc>
<textx="76"y="84"fill="#FFFFFF"font-family="Arial, sans-serif"font-size="38"font-weight="700">SLI начинается с договора, а не с процента</text>
<textx="76"y="145"fill="#486581"font-family="Arial, sans-serif"font-size="25">Учебный synthetic контракт: путь, граница событий, окно, цель и владелец</text>
note:'Первичный материал Google SRE: определяет SLI как количественную меру, SLO как целевое значение или диапазон и связывает error budget с решением о риске. Он не задаёт порог, окно, формулу или владельца для конкретного проекта.',
},
{
title:'Google SRE Workbook: Example SLO Document, 19.02.2018',
url:'https://sre.google/workbook/slo-document/',
note:'Официальный пример документа с датой 19.02.2018: в нём есть scope, SLI, SLO и четырёхнедельное rolling window. Это пример формы, а не обязательное окно для любого сервиса.',
},
{
title:'Google SRE Workbook: Example Error Budget Policy, 19.02.2018',
note:'Официальный пример policy: расход бюджета служит правилом приоритизации и не должен быть наказанием. Он не разрешает автоматически блокировать или выпускать чужие изменения.',
},
{
title:'Google SRE Workbook: Alerting on SLOs, copyright 2018',
note:'Официальная глава о том, что alert должен относиться к действенной угрозе бюджету; отдельно разбираются ограничения low-traffic систем. Она не подтверждает реальный burn rate, alert или incident этого учебного пакета.',
// Полный synthetic вход и отрицательные ветки находятся в этом же модуле.
// Нет чтения проекта, monitoring, CI, сети, real SLI, incident, burn rate или availability.`;
constfixtureCommand=syntheticExample+'\n\nnode web/scripts/upgrade-2023-10.mjs --verify-fixture\n\n# PASS подтверждает только согласованность synthetic договора и его отрицательных веток.';
constpractice=revision({
slug:'editorial-2023-10-practice-sli-slo',
title:'SLI без декоративной метрики: минимальный договор пути пользователя',
excerpt:'Как начать SLI/SLO не с процента на дашборде, а с договора: какой путь пользователя считаем, какие события входят в знаменатель, что означает успех, кто владеет решением и чего такой договор пока не доказывает.',
readingMinutes:12,
},[
p('Проблема начинается не с отсутствия графика. График обычно уже есть: процесс отвечает, балансировщик отдаёт коды, на панели горит хороший процент. Но пользовательский путь «отправить заказ» может останавливаться после принятого HTTP-запроса, а этот процент продолжает выглядеть спокойно. Команда видит число, но не знает, чью работу оно представляет. Цена ошибки — релизное решение принимают по декоративной метрике: исправляют не тот участок, спорят о «доступности» и не могут показать, какое условие действительно важно пользователю.'),
p('Быстрый ремонт обычно звучит так: возьмём все ответы без 5xx, назовём их успехом и поставим цель 99,9%. Это не договор, пока не названы путь, знаменатель, исключения, окно и владелец. Одно и то же значение будет честным для API-приёма заказа и бесполезным для завершённого checkout. Цена второй ошибки — не выдуманный инцидент и не обещанный downtime. Это потеря причины: в следующий раз команда снова будет выяснять, какие события вообще считает и почему один участник исключил отмену клиента, а другой — нет.'),
h2('Сначала вопрос пользователя, затем SLI'),
p('SLI — service level indicator, количественная мера выбранного свойства сервиса. SLO — цель этой меры в оговорённых условиях. Эти определения были опубликованы в Google SRE Book в 2017 году. Для практики важнее порядок: не спрашивать «какие метрики уже экспортируются», а закончить фразу от имени пользователя. Например: «после подтверждения формы checkout получает осмысленный ответ о приёме запроса». Это ещё не готовый SLI, но уже ограничивает маршрут, а не весь набор сервисных счётчиков.'),
p('Дальше разбираем путь на события, которые можно проверить. В знаменатель входят только завершённые попытки выбранного маршрута. Числитель — подмножество этих попыток, для которых заранее назван хороший результат. Событие, которое не дошло до точки измерения, нельзя бесшумно считать и успехом, и ошибкой: его правило должно быть записано отдельно. В учебном контракте ниже отмена до отправки запроса исключена. Это не рекомендация для каждого продукта, а пример того, как исключение перестаёт быть скрытым допущением.'),
table('Минимальный договор для одного учебного пути',['Часть договора','Точное значение в учебной модели','Зачем это нужно','Чего из этого нельзя вывести'],[
['Путь','synthetic-checkout-submit','не смешивать checkout с любым HTTP-трафиком','что такой маршрут есть в production'],
['Знаменатель','synthetic-checkout-request-finished','видеть все завершённые попытки выбранной границы','реальное число запросов или пользователей'],
['Хороший исход','synthetic-checkout-response-non-5xx','отделить правило успеха от кода графика','фактическую доступность или корректность заказа'],
['Исключение','synthetic-client-cancel-before-request','сделать границу спора явной','что отмены можно не учитывать в чужом сервисе'],
['Окно и владелец','synthetic-four-week-window-A; synthetic-checkout-owner','назвать срок сравнения и того, кто принимает решение','право автоматически выпускать или блокировать изменение'],
]),
figure('/assets/editorial/2023/slo-error-budget-2023-sli-contract.svg','Учебный SLI-контракт: путь synthetic checkout ограничивает множество eligible событий; good events являются его подмножеством, а отдельное исключение названо явно. Рядом стоят окно, целевое значение и synthetic owner.','Схема показывает структуру договора до запроса к мониторингу. Это не дашборд, не реальный SLI и не измерение доступности, инцидента или burn rate.'),
h2('Почему uptime процесса часто декоративен'),
p('Процесс может быть жив, а пользовательская операция — нет. Обратная ситуация тоже возможна: один backend ответил ошибкой, но продукт показал пользователю допустимый fallback. Поэтому «uptime» без объекта измерения нельзя автоматически переименовать в SLI. Он может быть полезен для диагностики конкретного компонента, но вопрос «успел ли пользователь сделать нужное действие?» остаётся отдельным. В Google SRE Book прямо различаются пользовательски важная мера и доступный proxy; proxy надо называть proxy, а не выдавать за прямой пользовательский результат.'),
h2('Окно и цель принадлежат договору'),
p('Окно измерения не является оформлением графика. В Example SLO Document Google SRE Workbook от 19 февраля 2018 года показано четырёхнедельное rolling window; это хороший пример того, что окно записывают вместе с SLI. В нашем fixture есть другое, намеренно фиксированное учебное окно 28 дней. Не переносите его в проект автоматически: для редких операций, сезонного трафика, пакетной обработки или юридического SLA могут понадобиться другая граница и отдельное решение владельцев.'),
p('Цель также не берут из текущего красивого значения. Сначала продукт, разработка и эксплуатация называют ожидаемую ценность пути, стоимость деградации и границу измерения. Затем выбирают достижимый target и правило пересмотра. Цель 100% fixture отвергает не потому, что любая система не может иметь жёсткого требования, а потому, что этот маленький пример учит явно отличать цель от бесконечного обещания. Реальный выбор всё равно требует контекста и согласования.'),
h2('Исполнимый synthetic fixture проверяет форму, а не систему'),
p('Fixture хранит входные объекты прямо в модуле и принимает только полный явно названный набор synthetic полей. Он собирает один договор: путь, окно, определение good/eligible, target, owner и две synthetic счётные величины. Затем он отвергает неотмеченный вход, лишнее или пропущенное поле, чужую область, другое окно, размытый индикатор, невозможную цель и отсутствующий знаменатель. Так можно проверить, что review не потерял поле договора ещё до настройки реального monitoring.'),
code(fixtureCommand),
p('PASS здесь означает только: учебный объект непротиворечив и отрицательные ветки сработали. Он не читает репозиторий, не подключается к monitoring, не запускает CI, не вызывает сеть и не знает, существуют ли реальные события. `syntheticGoodCount=994` и `syntheticEligibleCount=1000` — числа для арифметики fixture, не измерение traffic, availability, SLI, incident или burn rate. Поле `releaseAuthority=not-granted` специально не позволяет прочитать вывод как разрешение на изменение.'),
h2('Маршрут: симптом → причина → проверка → действие'),
ol([
'<strong>Симптом.</strong> На панели есть процент, но при вопросе «какой пользовательский путь он покрывает?» команда называет разные ответы.',
'<strong>Причина.</strong> Источник событий, знаменатель, good outcome, исключения, окно и owner появились в разных местах: запросе, dashboard и устной договорённости.',
'<strong>Проверка.</strong> На одном пути составьте таблицу из пяти строк. Для одного good, одного bad и одного спорного события укажите: входит ли оно в знаменатель, почему и где это можно проверить.',
'<strong>Проверка границы.</strong> Отдельно назовите proxy. Если measure стоит на backend, а ценность происходит в клиентском сценарии, запишите расхождение и не называйте proxy прямой доступностью пользователя.',
'<strong>Действие.</strong> Сохраните короткий SLI-contract рядом с owner, window, target и методом пересмотра. Сначала стабилизируйте определения, затем строите query и alert.',
'<strong>Следующий контроль.</strong> В разрешённой среде получите evidence для трёх примеров и проверьте, что одинаковая формула используется в отчёте и в релизном обсуждении.',
]),
h2('Rollback возвращает текст договора, не данные'),
p('Если формула оказалась неверной, первым обратимым действием будет вернуть предыдущую версию договора и пометить новую как неутверждённую. Это не значит «удалить метрики»: до такой команды надо знать backend, retention, права, потребителей alert и факт уже выполненного rollout. Учебный `rollbackSyntheticSloContract()` возвращает только snapshot пяти полей и прямо сообщает `monitoring=not-touched`, `ci=not-touched`, `network=not-used`. Он полезен тем, что не маскирует отсутствие операционного плана.'),
p('В настоящем изменении rollback должен содержать версию правила, владельца, условие возврата и способ проверить, что новый расчёт больше не используется. Если этого нет, не добавляйте к дашборду ещё один процент. Сначала сузьте изменение до одного пути и одного места измерения. Для автора уровня M6 это не бюрократия: это способ не выдать красивую визуализацию за доказательство пользовательского результата.'),
h2('Ограничения и следующий шаг'),
p('В статье нет production-данных, настоящего SLI, availability, incident, burn rate, alert, dashboard, SLO compliance, traffic или реальной стоимости простоя. Нет чтения проекта, файлов, часов, monitoring, CI, сети, HTTP, SDK и конфигурации. Внешние источники объясняют исторические термины и форму документов, но не назначают формулу, target или policy конкретной команде. Даже корректный SLI-contract не показывает причину ухудшения: для этого понадобится отдельный диагностический сигнал.'),
p('Следующий шаг — выбрать один действительно ценный путь и провести короткий review с его владельцем. Результатом должен стать не скриншот, а запись: scope, eligible event, good event, исключения, окно, источник, target, owner, способ пересмотра и известный proxy-gap. Только после этого имеет смысл обсуждать dashboard и error budget. Если любой из пунктов неизвестен, честный статус — «договор не готов», а не «метрика зелёная». '),
h2('Историческая граница октября 2023'),
p('К концу октября 2023 уже существовали использованные здесь первичные материалы Google: SRE Book с copyright 2017 и SRE Workbook с документами 2018 года. Они обосновывают термины SLI, SLO, окно и policy, но не делают эту учебную схему историческим production-кейсом автора. В тексте нет более позднего инструмента и нет утверждения, что любой backend уже реализует эти правила.'),
]);
constmechanism=revision({
slug:'editorial-2023-10-mechanism-sli-slo',
title:'Error budget без магии: границы окна, знаменателя и решения',
excerpt:'Разбор механизма error budget: почему процент нельзя читать без числа eligible событий, окна, target и policy; как отделить учебную арифметику от реального burn rate, инцидента и решения о релизе.',
readingMinutes:12,
},[
p('Проблема появляется, когда в релизном обсуждении говорят: «мы потратили бюджет», но никто не может показать, из какого окна, знаменателя и цели получилась фраза. Два отчёта могут дать разные проценты из одних и тех же событий, если один начал считать после смены версии, а второй оставил в знаменателе отмены до запроса. Цена — не математическая придирка. Команда способна заморозить полезное изменение по шумному сигналу или, наоборот, продолжить рискованный rollout, потому что неудобные события тихо исчезли из формулы.'),
p('Вторая ловушка — копировать target как число с девятками и считать, что появился error budget. Бюджет — это допустимая доля неуспеха в конкретной модели, а не универсальный счётчик проблем. Без scope и policy он становится красной полосой, которой каждый объясняет своё решение задним числом. Цена — у команды нет общей точки остановки: инженер приносит график, продукт говорит о сроке, а владелец сервиса не может назвать, какое действие разрешено именно при этом состоянии.'),
h2('Механизм состоит из пяти связанных частей'),
p('У простого success-ratio договора есть eligible count, good count, target, window и правило реакции. Сначала считают долю good среди eligible. Затем target определяет допустимую долю bad в том же окне. Разница между допустимым и фактическим числом bad — остаток учебного бюджета. Если поменять хотя бы одну часть, получится другая величина. Поэтому нельзя взять число ошибок за день и назвать его расходом четырёхнедельного бюджета без явного правила агрегации.'),
p('В коде этой партии target равен 99, synthetic eligible count — 1000, synthetic good count — 994. Из этого следуют шесть synthetic bad и десять допустимых synthetic bad, то есть остаток четыре условные единицы. Это именно проверяемая арифметика модели, а не расчёт для услуги: в коде нет источника событий, часов, реального окна, monitoring или backend. Слово `synthetic` повторяется намеренно, чтобы понятная формула не превратилась в несуществующий отчёт о доступности.'),
table('Что меняет каждый элемент error-budget модели',['Элемент','Вопрос','Если он не назван','Что проверять до решения'],[
['Scope','какой путь пользователя оцениваем?','в одну цифру попадают разные операции','маршрут, версию и границу владельца'],
['Eligible','какие попытки имеют право попасть в знаменатель?','часть ошибок или отмен исчезает неявно','источник, фильтр и отрицательные примеры'],
['Good','какой исход считается допустимым?','HTTP-код или технический ответ подменяет смысл результата','связь статуса с пользовательским действием'],
['Window','за какой период сравниваем?','один всплеск и долгий тренд смешиваются','rolling/fixed правило, reset и низкий трафик'],
['Policy','кто и что делает при состоянии бюджета?','цвет графика выдают за автоматический gate','owner, evidence, исключения и обратимое действие'],
]),
figure('/assets/editorial/2023/slo-error-budget-2023-budget-window.svg','Учебное окно из 28 synthetic дней: eligible и good события образуют долю, target задаёт допустимое число synthetic bad, а остаток бюджета передаётся на ручной decision step. Визуально отделены окно, арифметика и policy.','Диаграмма показывает только фиктивную формулу. Она не читает временной ряд, не считает реальный burn rate, не фиксирует incident и не сообщает доступность сервиса.'),
h2('Окно — это граница сравнения, а не подпись оси'),
p('Окно отвечает на вопрос «какие события имеют право повлиять на это решение сейчас». В Example SLO Document Google показано rolling window в четыре недели; этот документ датирован 19 февраля 2018 года. Это не доказывает, что четыре недели подходят всем. Для малотрафикового пути один failure может резко изменить процент, а для потоковой задачи важнее задержка завершения. Google SRE Workbook отдельно предупреждает, что подходы alerting для высокотрафиковых сервисов дают ложный сигнал на low traffic. Значит, размер окна и способ действия надо выбрать вместе с характером события, а не после того, как график уже настроен.'),
p('Нужно также решить, что происходит на границе окна. Fixed window проще объяснить: все события относятся к явно названному периоду, затем начинается следующий. Rolling window быстрее показывает недавнее ухудшение, но требует точного описания того, как момент измерения сдвигает набор событий. Нельзя менять режим в середине отчёта без новой версии договора: сравнение с прошлым значением потеряет смысл. В fixture выбран fixed 28-day object только потому, что его отрицательную ветку легко проверить; он ничего не говорит о реальном календаре.'),
h2('Знаменатель не должен прятаться в query'),
p('Есть соблазн исключить неудобные ответы, чтобы сделать ratio спокойнее. Исключение может быть законным, например событие не дошло до измеряемой операции, но его надо объяснить на языке пользователя и фиксировать в контракте. «Не успели отправить запрос» и «операция завершилась ошибкой на сервере» — разные состояния. Их нельзя склеить под общим названием «шум». Хороший SLI не обязан учитывать всё; он обязан честно говорить, что именно не учитывает и какой другой сигнал требуется для этой слепой зоны.'),
h2('Арифметика не заменяет policy'),
p('Google SRE Book 2017 связывает error budget с решением о риске, а Example Error Budget Policy 2018 прямо описывает policy как способ защитить пользователя, а не наказать команду. Из этого следует практический вывод: после расчёта должна появиться не автоматическая команда, а заранее согласованная развилка. Например, владелец может назначить review, сузить rollout или запланировать reliability work. Какое действие верно, зависит от продукта, класса изменения, обратимости, security-исключений и качества evidence. Ни один процент сам по себе не знает этих условий.'),
p('В учебной модели `proposal` имеет только два значения: `synthetic-review-before-change` и `synthetic-reliability-work-first`. Рядом стоит `releaseAuthority=not-granted`. Это намеренно ограничивает fixture: он показывает, что состояние арифметики может привести к вопросу владельцу, но не даёт право останавливать CI, менять feature flag или выполнять rollout. Такой запрет полезен в коде примера, потому что в реальной системе именно место принятия решения и права на действие чаще всего оказываются неявными.'),
h2('Исполнимый fixture ловит плохую границу раньше графика'),
p('Ниже один и тот же fixture. Он проверяет не PromQL, не правила alerting и не production telemetry, а форму входа. Хорошая ветка содержит ровно один synthetic scope, фиксированное 28-day окно, explicit good/eligible event, target меньше 100 и целые счётные значения. Плохие ветки пытаются подменить окно 30 днями, размыть eligible event, записать невозможную цель, передать нулевой знаменатель или сделать good count больше eligible. Эти ошибки должны быть заметны ещё в review, а не после публикации красивого отчёта.'),
code(fixtureCommand),
p('При запуске код не использует дату, файл, environment, monitoring API, CI, HTTP или сеть. У него нет clock и нет таблицы реальных точек. Даже строка `syntheticBudgetSpentShare=0.6` не является burn rate: она лишь результат деления шести fixed synthetic bad на десять synthetic допустимых bad внутри одного объекта. PASS не подтверждает, что система выдерживает цель, что произошёл incident или что изменение безопасно выпускать.'),
h2('Маршрут: симптом → причина → проверка → действие'),
ol([
'<strong>Симптом.</strong> В обсуждении звучит «бюджет потрачен», но для числа нельзя назвать scope, окно, eligible count и target.',
'<strong>Причина.</strong> Процент, период и policy живут в разных запросах, документах или головах участников; одинаковое слово обозначает разные формулы.',
'<strong>Проверка модели.</strong> Выпишите пять частей из таблицы. На synthetic примере пересчитайте good, eligible, bad и допустимое число bad; отдельно отметьте события вне scope.',
'<strong>Проверка данных.</strong> В разрешённой среде подтвердите, что источник предоставляет именно те поля и границы, которые обещает договор. Не подменяйте это прогоном fixture.',
'<strong>Действие.</strong> Версионируйте договор и policy вместе: изменение фильтра, окна или target — это новое правило сравнения, а не косметика дашборда.',
'<strong>Следующий контроль.</strong> Перед спорным релизом попросите owner показать входные определения и evidence, затем выбрать обратимый шаг. Если evidence нет, статус — «решение отложено», а не «бюджет зелёный».',
]),
h2('Изменение формулы требует своего rollback'),
h2('Ограничения и следующий шаг'),
p('Этот текст не вычисляет настоящий error budget, real SLI, availability, burn rate, incident, traffic, alert или SLO compliance. Fixture не читает проект, не использует monitoring/CI/сеть/HTTP/SDK и не открывает production-данные. Он не устанавливает цель 99 для чьей-либо услуги, не утверждает, что 28 дней универсальны, и не создаёт release gate. Источники доступны до конца октября 2023, но их примеры не заменяют договор команды и не дают готовую формулу для неизвестного продукта.'),
p('Следующий шаг — взять одну существующую метрику и провести обратный путь: от цвета панели к точному user journey, eligible set, good outcome, window и policy. Если хотя бы один пункт невозможно восстановить, метрика пока diagnostic, а не основа для error budget. После этого можно сравнить fixed и rolling варианты на известном наборе данных в разрешённой среде и зафиксировать, какой вопрос каждый вариант отвечает. Выбирать можно не самый красивый процент, а самый проверяемый договор.'),
h2('Историческая граница октября 2023'),
p('Все источники в статье существовали к концу октября 2023: Google SRE Book имеет copyright 2017, а SRE Workbook и его Example SLO Document, Error Budget Policy и Alerting on SLOs — copyright или даты 2018 года. Поэтому материал не приписывает автору позднюю платформу и не ссылается на более новые методы как на обязательный стандарт. Уровень M6 здесь проявляется в границе модели, версии правила и обратимом решении, а не в лозунге о «культуре SRE». '),
]);
constfield=revision({
slug:'editorial-2023-10-field-sli-slo',
title:'SLI/SLO в релизном разговоре: бюджет как петля решения, не как красный график',
excerpt:'Как превратить SLI/SLO и error budget в воспроизводимый путь решения: от симптома к scope, данным, причинам и обратимому действию — без автоматического gate, выдуманного incident или декоративного burn rate.',
readingMinutes:12,
},[
p('Проблема релизного дня редко звучит технически чисто. На панели красный блок, кто-то говорит «бюджет почти закончился», другая команда просит не задерживать изменение, а on-call не может объяснить, какой пользовательский путь пострадал. Если принять решение только по цвету, можно остановить безопасное исправление или выпустить изменение в момент, когда полезнее сначала разобраться с надёжностью. Цена — не только риск для пользователя. Команда привыкает считать SLO отчётностью, потому что число не связывается с действием и ответственностью.'),
p('Обратная ошибка — превратить budget в автоматический запрет. Формула сама не знает, является ли изменение обратимым, закрывает ли оно security-уязвимость, относится ли к тому же пути и подтверждены ли входные данные. Без policy владелец узнаёт о решении уже после того, как CI или чей-то скрипт сделал необратимое действие. Цена — скрытые полномочия и плохая диагностика: красный график объясняет «что-то не так», но не показывает причину, границу или следующий безопасный шаг.'),
h2('Error budget нужен для вопроса, а не для победы в споре'),
p('Google SRE Book в главе 2017 года описывает error budget как способ обсудить допустимый риск между разработкой и надёжностью. В Example Error Budget Policy Google SRE Workbook от 19 февраля 2018 года отдельно сказано, что policy не является наказанием за missed SLO. Практический смысл для небольшой команды: заранее договориться, какое evidence нужно перед решением и какие обратимые действия допустимы. Тогда цифра не заканчивает разговор; она запускает один и тот же маршрут для релиза, reliability-задачи и разбора расхождения.'),
p('Это особенно важно, когда SLI — proxy. Низкая доля good событий может относиться к одному backend-ответу, но не объяснять весь пользовательский путь. Высокая доля может скрывать ошибку после точки измерения. Поэтому петля решения содержит два разных перехода: сначала проверить, что сигнал соответствует договору, затем искать причину в разрешённых данных. Нельзя перепрыгнуть из одного synthetic процента к выводу «был инцидент» или «нужно заблокировать production». Эти утверждения требуют других фактов и других владельцев.'),
table('Запись для решения вместо одного цвета',['Шаг','Что должен принести owner','Допустимое действие','Чего не делает шаг'],[
['Сигнал','версия SLI-contract, scope, окно, target и time of observation','открыть разбор','не объявляет incident автоматически'],
['Контекст','диагностические данные разрешённой среды и known changes','сформировать гипотезу','не подменяет продуктовый impact'],
['Решение','owner, policy, обратимость и evidence','сузить rollout, исправить, отложить или продолжить с контролем','не выдаёт CI-право учебному fixture'],
['Повторная проверка','та же формула и критерий после действия','подтвердить или пересмотреть гипотезу','не обещает отсутствие следующих сбоев'],
]),
figure('/assets/editorial/2023/slo-error-budget-2023-decision-loop.svg','Петля решения: synthetic сигнал сверяется с SLI-контрактом, затем в разрешённой среде ищется контекст; owner выбирает обратимое действие и повторную проверку. У стрелки к релизу стоит ручное решение, а не автоматический gate.','Схема не является журналом инцидента, CI pipeline или мониторингом. Она не получает реальные SLI, availability, burn rate или данные о выпуске.'),
h2('Один сигнал не объясняет причину'),
p('SLI отвечает на заранее узкий вопрос: выполняется ли выбранная мера в выбранной границе. Он не обязан хранить корневую причину. Когда сигнал отклоняется, следующей задачей становится диагностика: изменение версии, зависимость, класс ответов, очередь, лимит, данные или сценарий клиента. Набор диагностических сигналов зависит от архитектуры и доступа. Нельзя заранее объявить, что trace, log или dashboard всегда дадут ответ. Но можно заранее назначить, кто проверяет scope и кто подтверждает, что данные относятся к одному и тому же периоду.'),
p('В Google SRE Workbook 2018 о SLO alerting подчёркнута разница между alerting metric и данными, которые помогают расследовать причину. Этот вывод не позволяет сказать «любая красная точка требует page». Он учит не смешивать роль меры и роль объяснения. Для одних путей нужен срочный response, для других — ticket, review или временное ограничение rollout. Сначала должна быть policy с владельцем и уровнями действий, а затем выбранные thresholds. Без этого alert просто переносит спор из чата в notification channel.'),
h2('Policy должна быть короткой и исполнимой людьми'),
p('Минимальная policy помещается в несколько строк: какие SLO относятся к релизу, кто владелец решения, какие данные обязательны, что считается обратимым действием, какие исключения требуют отдельного одобрения и когда договор пересматривают. Важно указать не только «при exhausted budget остановить изменения», но и что именно означает exhausted по версии формулы, какая проверка защищает от ложного сигнала и кто может разрешить security fix. Иначе правило будет жить только в памяти того, кто однажды настроил дашборд.'),
h2('Synthetic fixture оставляет полномочие у владельца'),
p('Здесь fixture специально не играет роль release gate. Он возвращает `proposal`, но всегда сохраняет `releaseAuthority=not-granted`. В хорошей synthetic ветке остаётся четыре условные единицы бюджета, поэтому proposal — review before change. В другой ветке условный budget exhausted, но это всё равно не incident и не команда остановить реальную выкладку. Fixture не видит code diff, security context, CI result, feature flag, owner approval или production traffic; выдавать ему полномочие было бы ошибкой модели.'),
code(fixtureCommand),
p('Запуск создаёт фиксированные JS-объекты в памяти и завершается. Он не читает проект, не вызывает monitoring, CI, сеть, HTTP, SDK или часы. У него нет реальных SLI, availability, incident, burn rate, event stream либо dashboard. Даже отрицательная ветка `synthetic-reliability-work-first` описывает только ожидаемую форму учебной развилки. PASS проверяет, что она не перепутана с разрешением на release, а не то, что какой-либо сервис достиг цели.'),
h2('Маршрут: симптом → причина → проверка → действие'),
ol([
'<strong>Симптом.</strong> Релизная команда видит красный budget-показатель, но не может связать его с конкретным путём, окном и версией SLI-contract.',
'<strong>Причина.</strong> Сигнал, формула, диагностические данные и policy развивались отдельно; график получил вес решения, но не получил owner и границы полномочий.',
'<strong>Проверка формулы.</strong> Сверьте scope, good/eligible events, exclusions, окно, target и источник. Если версия правила неизвестна, остановите интерпретацию, а не релиз по умолчанию.',
'<strong>Проверка контекста.</strong> В разрешённой среде соберите минимальные данные для одной гипотезы и отделите их от synthetic fixture. Не называйте correlation или событие доказанными, пока источник не подтверждён.',
'<strong>Действие.</strong> Owner выбирает обратимый шаг согласно policy: сузить exposure, исправить причину, отложить non-urgent change или продолжить с явным контролем. Выбор фиксируется вместе с evidence.',
'<strong>Повтор.</strong> После действия примените ту же версию формулы и проверьте известный критерий. При расхождении пересматривайте гипотезу, а не подгоняйте denominator.',
]),
h2('План обратного действия должен предшествовать спору'),
p('Слова «если что, откатим» не являются policy. До изменения нужно назвать, что именно меняется: код, конфигурация, правило обработки или ограничение exposure. Затем — какую версию вернуть, кто это сделает, что будет считаться подтверждением и какие потребители затронуты. Если действие нельзя обратить, policy должна сказать это прямо и потребовать иной уровень review. Error budget полезен тем, что превращает такое обсуждение в ожидаемую часть работы, а не в реакцию на громкий график.'),
p('Учебный rollback нарочно скучный: он возвращает пять полей synthetic договора и говорит, что monitoring, CI и сеть не затронуты. Он не может остановить deploy или удалить записи, потому что ничего такого не создавал. В реальной системе это ограничение не повод делать вид, что rollback существует. Это повод вынести операционный план в отдельный runbook с теми системами, где у команды действительно есть права и наблюдение.'),
h2('Ограничения и следующий шаг'),
p('Пакет не показывает production incident, доступность, SLI, burn rate, error budget, алерт, CI run, релиз, пользователя или стоимость. Он не читает проект и не обращается к monitoring, CI, сети, HTTP, SDK, clock или dashboard. Все имена, события, количества и состояния имеют synthetic marker и существуют только в памяти Node. Google-источники задают исторические определения и примеры policy, но не предоставляют автоматический gate и не дают этому fixture права оценивать реальный риск.'),
p('Следующий шаг для команды — сделать одну реальную decision record до следующего спорного изменения. В ней должны быть SLI-contract version, owner, scope, источник evidence, окно, target, policy branch, обратимое действие и повторная проверка. Если не хватает хотя бы одной строки, не скрывайте пробел новой визуализацией. Сначала назначьте владельца и сузьте вопрос. Тогда SLO перестанет быть декорацией и станет способом честно выбрать следующий инженерный шаг.'),
h2('Историческая граница октября 2023'),
p('К октябрю 2023 уже были доступны Google SRE Book 2017 и Google SRE Workbook 2018 с примерами SLO document, error budget policy и SLO alerting. Статья опирается на эти документы, не добавляя поздние платформенные практики и не имитируя чужую production-историю. Автор уровня M6 здесь связывает измерение с owner, evidence и обратимостью, но не выдаёт учебную модель за статистику своей системы.'),
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
