Задача и границы
Для темы «sLO и error budget для продуктовой команды» используется артефакт «карта SLO и бюджета ошибок». Он отвечает на вопрос: как согласовать измеримый уровень надёжности и допустимый объём риска для продуктовых изменений. Модель «карта SLO и бюджета ошибок» разделяет факт и гипотезу. Для «карта SLO и бюджета ошибок» самостоятельно назначают ответственного и дату повторной проверки. Причинную связь артефакт не доказывает.
Редакционная методика «карта SLO и бюджета ошибок» проверяется на завершённом рабочем эпизоде. В границах «карта SLO и бюджета ошибок» правовые, трудовые, клинические и контрактные — в практике «SLO и error budget для продуктовой команды» — случаи рассматриваются в специализированных процессах.
Проверенные основания
Google SRE балансирует риск через — с учётом темы «SLO и error budget для продуктовой команды» — error budget. основание В артефакте «карта SLO и бюджета ошибок» это основание проверяет компонент «пользовательский SLI».
Google SRE ограничивает ручную операционную — применительно к теме «SLO и error budget для продуктовой команды» — работу. основание В артефакте «карта SLO и бюджета ошибок» это основание проверяет компонент «целевая граница SLO».
DORA оценивает темп, стабильность и доработки. основание В артефакте «карта SLO и бюджета ошибок» это основание проверяет компонент «окно измерения».
AWS проверяет операционную готовность вопросами — применительно к теме «SLO и error budget для продуктовой команды» —. основание В артефакте «карта SLO и бюджета ошибок» это основание проверяет компонент «бюджет ошибок».
Внешние источники задают ориентиры. Конкретная схема «карта SLO и бюджета ошибок» остаётся редакционной методикой и требует проверки на данных команды.
Рабочая модель
Пользовательский sli. В «карта SLO и бюджета ошибок» фиксируют вход, решение и ожидаемый выход. Связь «пользовательский SLI → окно измерения» проверяют критерием «SLI отражает пользовательский опыт»; ошибка «использовать инфраструктурную метрику без связи с пользователем» служит отрицательным тестом.
Целевая граница slo. В «карта SLO и бюджета ошибок» фиксируют вход, решение и ожидаемый выход. Связь «целевая граница SLO → бюджет ошибок» проверяют критерием «цель имеет объяснимую цену»; ошибка «ставить сто процентов как цель» служит отрицательным тестом.
Окно измерения. В «карта SLO и бюджета ошибок» фиксируют вход, решение и ожидаемый выход. Связь «окно измерения → политика расходования» проверяют критерием «бюджет виден команде»; ошибка «создавать SLO без управленческого решения» служит отрицательным тестом.
Бюджет ошибок. В «карта SLO и бюджета ошибок» фиксируют вход, решение и ожидаемый выход. Связь «бюджет ошибок → действие при исчерпании» проверяют критерием «политика определяет действие»; ошибка «игнорировать частичную деградацию» служит отрицательным тестом.
Политика расходования. В «карта SLO и бюджета ошибок» фиксируют вход, решение и ожидаемый выход. Связь «политика расходования → пользовательский SLI» проверяют критерием «данные устойчивы к пересчёту»; ошибка «менять определение после плохого периода» служит отрицательным тестом.
Действие при исчерпании. В «карта SLO и бюджета ошибок» фиксируют вход, решение и ожидаемый выход. Связь «действие при исчерпании → целевая граница SLO» проверяют критерием «SLO пересматривается по расписанию»; ошибка «использовать инфраструктурную метрику без связи с пользователем» служит отрицательным тестом.
Минимальная версия «карта SLO и бюджета ошибок» включает компоненты «пользовательский SLI», «окно измерения» и «политика расходования». Остальное добавляют только при влиянии на решение по теме «sLO и error budget для продуктовой команды».
Порядок внедрения
Шаг 1: Выбрать критический пользовательский результат. В «карта SLO и бюджета ошибок» обновляют компонент «пользовательский SLI». Результат подтверждает критерий «SLI отражает пользовательский опыт»; ограничение «новый сервис имеет мало исторических данных» записывают рядом.
Шаг 2: Определить измеримый sli. В «карта SLO и бюджета ошибок» обновляют компонент «целевая граница SLO». Результат подтверждает критерий «цель имеет объяснимую цену»; ограничение «редкое событие требует длинного окна» записывают рядом.
Шаг 3: Задать достижимую цель и окно. В «карта SLO и бюджета ошибок» обновляют компонент «окно измерения». Результат подтверждает критерий «бюджет виден команде»; ограничение «регулируемая доступность может быть задана договором» записывают рядом.
Шаг 4: Рассчитать допустимый бюджет. В «карта SLO и бюджета ошибок» обновляют компонент «бюджет ошибок». Результат подтверждает критерий «политика определяет действие»; ограничение «несколько пользовательских путей требуют разных SLO» записывают рядом.
Шаг 5: Согласовать политику изменений. В «карта SLO и бюджета ошибок» обновляют компонент «политика расходования». Результат подтверждает критерий «данные устойчивы к пересчёту»; ограничение «error budget не заменяет анализ критических рисков» записывают рядом.
Шаг 6: Пересмотреть цель по фактическому опыту. В «карта SLO и бюджета ошибок» обновляют компонент «действие при исчерпании». Результат подтверждает критерий «SLO пересматривается по расписанию»; ограничение «новый сервис имеет мало исторических данных» записывают рядом.
После внедрения «карта SLO и бюджета ошибок» проверяют на другом случае. Если решение неясно, «карта SLO и бюджета ошибок» упрощают и проверяют повторно.
Практический пример
Команда считала сервис доступным, пока отвечал API, хотя платежи завершались с задержкой. Карта SLO выбрала долю операций, подтверждённых за две минуты, и связала исчерпание бюджета с остановкой рискованных релизов.
В примере «карта SLO и бюджета ошибок» связывает «пользовательский SLI» с действием «выбрать критический пользовательский результат». Затем компонент «бюджет ошибок» проверяют шагом «рассчитать допустимый бюджет» и критерием «политика определяет действие».
Контрольный разбор темы «sLO и error budget для продуктовой команды» рассматривает ошибку «использовать инфраструктурную метрику без связи с пользователем» и ограничение «новый сервис имеет мало исторических данных». Если другой участник не может повторить проверку, артефакт «карта SLO и бюджета ошибок» остаётся экспериментальным.
Типовые ошибки
-
Использовать инфраструктурную метрику без связи с пользователем. В «карта SLO и бюджета ошибок» страдает компонент «целевая граница SLO». Исправление начинают действием «задать достижимую цель и окно» и проверяют на следующем рабочем случае.
-
Ставить сто процентов как цель. В «карта SLO и бюджета ошибок» страдает компонент «окно измерения». Исправление начинают действием «рассчитать допустимый бюджет» и проверяют на следующем рабочем случае.
-
Создавать slo без управленческого решения. В «карта SLO и бюджета ошибок» страдает компонент «бюджет ошибок». Исправление начинают действием «согласовать политику изменений» и проверяют на следующем рабочем случае.
-
Игнорировать частичную деградацию. В «карта SLO и бюджета ошибок» страдает компонент «политика расходования». Исправление начинают действием «пересмотреть цель по фактическому опыту» и проверяют на следующем рабочем случае.
-
Менять определение после плохого периода. В «карта SLO и бюджета ошибок» страдает компонент «действие при исчерпании». Исправление начинают действием «выбрать критический пользовательский результат» и проверяют на следующем рабочем случае.
В «карта SLO и бюджета ошибок» одновременно исправляют две ошибки максимум. Затем «карта SLO и бюджета ошибок» сравнивают с новым результатом.
Критерии качества
-
Sli отражает пользовательский опыт. В «карта SLO и бюджета ошибок» критерий проверяют после шага «выбрать критический пользовательский результат» на компоненте «бюджет ошибок». Подтверждением служит наблюдаемый результат или журнал решения.
-
Цель имеет объяснимую цену. В «карта SLO и бюджета ошибок» критерий проверяют после шага «определить измеримый SLI» на компоненте «политика расходования». Подтверждением служит наблюдаемый результат или журнал решения.
-
Бюджет виден команде. В «карта SLO и бюджета ошибок» критерий проверяют после шага «задать достижимую цель и окно» на компоненте «действие при исчерпании». Подтверждением служит наблюдаемый результат или журнал решения.
-
Политика определяет действие. В «карта SLO и бюджета ошибок» критерий проверяют после шага «рассчитать допустимый бюджет» на компоненте «пользовательский SLI». Подтверждением служит наблюдаемый результат или журнал решения.
-
Данные устойчивы к пересчёту. В «карта SLO и бюджета ошибок» критерий проверяют после шага «согласовать политику изменений» на компоненте «целевая граница SLO». Подтверждением служит наблюдаемый результат или журнал решения.
-
Slo пересматривается по расписанию. В «карта SLO и бюджета ошибок» критерий проверяют после шага «пересмотреть цель по фактическому опыту» на компоненте «окно измерения». Подтверждением служит наблюдаемый результат или журнал решения.
Итоговая оценка «карта SLO и бюджета ошибок» называет остаточный риск и событие будущего пересмотра. Ограничение «регулируемая доступность может быть задана договором» остаётся видимым даже при выполнении критериев.
Ограничения применимости
-
Новый сервис имеет мало исторических данных. Для компонента «пользовательский SLI» в «карта SLO и бюджета ошибок» требуется отдельная проверка. Перенос чужого вывода остаётся гипотезой.
-
Редкое событие требует длинного окна. Для компонента «целевая граница SLO» в «карта SLO и бюджета ошибок» требуется отдельная проверка. Перенос чужого вывода остаётся гипотезой.
-
Регулируемая доступность может быть задана договором. Для компонента «окно измерения» в «карта SLO и бюджета ошибок» требуется отдельная проверка. Перенос чужого вывода остаётся гипотезой.
-
Несколько пользовательских путей требуют разных slo. Для компонента «бюджет ошибок» в «карта SLO и бюджета ошибок» требуется отдельная проверка. Перенос чужого вывода остаётся гипотезой.
-
Error budget не заменяет анализ критических рисков. Для компонента «политика расходования» в «карта SLO и бюджета ошибок» требуется отдельная проверка. Перенос чужого — в разборе «SLO и error budget для продуктовой команды» — вывода остаётся гипотезой.
Три ограничения требуют пересборки «карта SLO и бюджета ошибок». Для темы «sLO и error budget для продуктовой команды» новый вопрос заменяет список исключений — для сценария «SLO и error budget для продуктовой команды» —.
Практика пересмотра.
Команда сохраняет исходную версию «карта SLO и бюджета ошибок», результат шага «определить измеримый SLI» и решение по критерию «данные устойчивы к пересчёту». На следующем цикле «карта SLO и бюджета ошибок» сравнивают с изменениями, отдельно отмечая ограничение «несколько пользовательских путей требуют разных SLO».
Полезность «карта SLO и бюджета ошибок» подтверждает новый участник. Он повторяет проверку «карта SLO и бюджета ошибок» без устного контекста; для темы «sLO и error budget для продуктовой команды» это важнее объёма.
Вывод
Практику «sLO и error budget для продуктовой команды» начинают с «карта SLO и бюджета ошибок» и действия «выбрать критический пользовательский результат». Первый результат проверяют критерием «SLI отражает пользовательский опыт» и сопоставляют с ограничением «новый сервис имеет мало исторических данных». Так решение, остаточный риск и пересмотр остаются прозрачными.
