Обзор уровня сервиса должен объяснить, что получили пользователи, как это соотносится с согласованной целью и что команде делать дальше. Одного зелёного процента недостаточно. Слушателям нужно знать, что посчитано, за какой период и не оказался ли опыт небольшой группы пользователей значительно хуже, чем показывает общий результат.
Начните с утверждения, которое можно проверить: «Сервис отправки заявок достиг цели по доле успешных операций, но основная часть ошибок пришлась на один инцидент. Прежде чем повышать цель, предлагаем исследовать этот сценарий отказа». Затем покажите расчёт и затронутый процесс. Это полезнее снимка дашборда с двенадцатью необъяснёнными числами.
Согласованные заметки можно превратить в редактируемые слайды с помощью инструмента Presenti для создания презентации из текста. Источниками доказательств остаются системы мониторинга и поддержки. Presenti помогает организовать и отредактировать слайды, но не собирает телеметрию сервиса и не определяет, выполнен ли SLO.
Определите сервис, показатель и период
Ограничьте обзор одним пользовательским сценарием, поддерживающим его сервисом и отчётным окном. «Надёжность платформы» — слишком широкая формулировка, если данные относятся только к отправке заявок. Успешная отправка не доказывает, что вход, поиск и уведомления тоже работали.
На первом слайде с результатами или в небольшом словаре рядом нужны три термина. Руководство Google SRE по целям уровня сервиса разделяет показатель, целевое значение и соглашение:
| Термин | Значение | Что показать |
|---|---|---|
| SLI — показатель уровня сервиса | Количественное измерение поведения сервиса. | Измеренный результат и способ расчёта. |
| SLO — цель уровня сервиса | Целевое значение показателя за определённый период. | Согласованный порог, охват и временное окно. |
| SLA — соглашение об уровне сервиса | Соглашение, предусматривающее последствия невыполнения обязательств по сервису. | Применимое соглашение и его правила измерения, если оценивается выполнение договора. |
Не называйте результат внутреннего SLO «соблюдением SLA» только из-за похожих процентов. У соглашения могут быть другие границы сервиса, исключения и период расчёта. Разделяйте операционный результат и договорную оценку: сам слайд не устанавливает нарушение договора или право на компенсацию.
Пример: сервис отправки заявок
Сервис, записи и числа ниже вымышлены. Они объясняют структуру обзора, а не описывают работу Presenti или случай клиента.
Платформа поддержки проверяет, могли ли клиенты отправлять новые заявки. Согласованный SLO по успешности составляет 99,90% за этот фиксированный 28-дневный период. Карточка измерения должна находиться рядом с результатом, а не в скрытом приложении.
| Поле | Определение в примере |
|---|---|
| Пользовательский сценарий | Отправить новую заявку в поддержку и получить пригодный для использования ID заявки. |
| Окно | С 1 сентября, 00:00 UTC, до 29 сентября, 00:00 UTC, не включая конечную границу: 28 полных дней. |
| Учитываемое событие | Авторизованная попытка отправки корректного запроса в рабочей среде, принятая шлюзом. У каждой попытки свой ID запроса. |
| Успешное событие | Заявка сохранена, а отправивший её клиент получил пригодный ID заявки. |
| Исключённый трафик | Проверки работоспособности, помеченный тестовый трафик и запросы, не соответствующие заранее согласованным правилам отбора. Правила установлены до отчётного периода. |
| Основание | Зафиксированная выгрузка шлюза, соединённая с результатами сервиса заявок по ID запроса. Версия запроса к данным и время выгрузки приложены к презентации. |
| Граница измерения | Сбои до поступления запроса на шлюз в этот SLI не попадают. |
Знаменатель — попытки отправки, а не клиенты. Повторная отправка по этому определению создаёт ещё одну попытку. Если клиент сделал в общей сложности десять попыток отправки, в обзоре будет десять событий, а не десять пострадавших клиентов. Сохраняйте различие и в подписи графика, и в заметках докладчика.
Граница измерения тоже важна. Неисправная страница входа может не дать клиентам добраться до шлюза, хотя этот SLI останется хорошим. Покажите пробел рядом с результатом и используйте отдельные данные для полного пользовательского пути. Не улучшайте процент, исключая неуспешные запросы после окончания периода.
Покажите расчёт бюджета ошибок, а не только цвет
Руководство Google по внедрению SLO описывает событийные показатели как отношение успешных событий к общему числу. Для процентной цели ниже 100% разность задаёт допустимую долю неуспешных событий. Рассчитаем результат за завершившийся период нашего примера.
| Величина | Расчёт | Результат |
|---|---|---|
| Учитываемые попытки | Число ID запросов в согласованных границах | 2 000 000 |
| Успешные попытки | Подтверждённые успешные исходы | 1 998 600 |
| Неуспешные попытки | 2 000 000 − 1 998 600 | 1 400 |
| Измеренная успешность | 1 998 600 ÷ 2 000 000 × 100 | 99,93% |
| Допустимые неуспешные попытки | 2 000 000 × (1 − 0,9990) | 2 000 |
| Использованный бюджет | 1 400 ÷ 2 000 × 100 | 70% |
| Неиспользованный допуск этого периода | 2 000 − 1 400 | 600 попыток |
Цель достигнута: 99,93% выше 99,90%. Запас составляет 0,03 процентного пункта. Команда использовала 70% допустимых ошибок, а не 70% всех запросов.
Аккуратно назовите оставшиеся 600 попыток. Они относятся к завершённому отчётному периоду и не разрешают вызвать 600 ошибок в следующем месяце. Для рабочего SLO со скользящим окном нужен собственный расчёт по текущему окну. Событийный бюджет также не является допустимым простоем в минутах: минута высокой нагрузки и минута низкой нагрузки могут дать совершенно разное число ошибок.
Сохраните полную точность в исходной таблице и применяйте единое округление на слайдах. Рядом с порогом не округляйте невыполнение до кажущегося успеха. Сохраняйте запрос к данным и период вместе со слайдом, чтобы другой человек мог воспроизвести расчёт.
Объясните, кого затронули ошибки
В вымышленных записях на один инцидент приходится 1 200 из 1 400 неуспешных попыток. Эти 1 200 попыток связаны со 140 разными ID аккаунтов. Значит, инцидент использовал 60% всего бюджета ошибок периода: 1 200, делённые на 2 000. Остальные 200 ошибок использовали ещё 10%.
Подходящий заголовок слайда: «Один инцидент использовал большую часть бюджета ошибок и затронул 140 аккаунтов». Но данные не поддерживают фразы «140 человек не могли работать» или «потеряно 1 200 заявок». В аккаунте может быть несколько пользователей, повторные попытки могут относиться к одной задуманной заявке, а число ошибок не показывает, была ли она в итоге создана.
Рядом с количеством покажите затронутый процесс. В примере во время инцидента клиенты не могли надёжно получить подтверждение заявки. Обращения в поддержку помогают понять последующие действия, но несколько разговоров нельзя превращать в вывод обо всех затронутых аккаунтах.
Небольшой блок о последствиях может состоять из трёх строк:
- Наблюдали: 1 200 неуспешных попыток связаны с инцидентом; в записях 140 разных ID аккаунтов.
- Пока не установили: сколько задуманных заявок пользователи так и не отправили, а сколько успешно отправили повторно.
- Следующее действие: сопоставить попытки с итоговым созданием заявок до публикации числа отказов от отправки.
Поэтому общий результат и пользовательские последствия нужны вместе. Выполнение цели отвечает на один вопрос, а сбой, затронувший отдельный процесс — на другой. Одно не должно стирать другое.
Переведите результат в решение о надёжности
Обзор — не конкурс на максимально высокий целевой процент. Спросите, какое действие устранит наблюдаемую проблему, чем оно обосновано и какую работу придётся отложить. Само предложение перейти с 99,90% на 99,99% сервис не улучшает.
В нашем примере владелец сервиса может сравнить такие варианты:
| Вариант | Какую проблему решает | Что нужно до следующих обязательств |
|---|---|---|
| Исследовать сценарий массового отказа | Инцидент с 1 200 неуспешными попытками. | Воспроизведение сбоя и тест вариантов смягчения; совпадение по времени само по себе не устанавливает причину. |
| Расширить измерение до шлюза | Слепую зону между браузером клиента и текущим SLI. | Ограниченное по объёму предложение с охватом измерения, обращением с данными и оценкой трудозатрат. |
| Сразу ужесточить SLO | Более строгое обязательство по надёжности. | Подтверждение соответствия цели потребностям пользователей и согласованный план дополнительной работы. |
Первые два варианта отвечают на конкретные наблюдения. Третий требует отдельного решения об ожиданиях и затратах. Не снижайте цель незаметно, чтобы сделать отчёт зелёным, и не повышайте её только ради амбициозного слайда.
Если в организации есть политика бюджета ошибок, укажите требуемое ею действие и полномочия на исключения. Если нет, представляйте предлагаемую политику именно как предложение. Докладчик не должен придумывать автоматическую остановку релизов и создавать впечатление, что все уже согласились.
Соберите шесть слайдов, полезных и после встречи
Основная презентация может быть короткой, если подробности сохранены в пакете доказательств. Отведите каждому слайду одну задачу:
- Результат и решение: успешность 99,93% при цели 99,90%; один основной инцидент; конкретная работа, на которую нужно разрешение.
- Границы измерения: пользовательский сценарий, даты, учитываемые и успешные события, источник и пробел охвата.
- Бюджет: числитель, знаменатель, допустимые ошибки и расчёт использованных 70%.
- Последствия для пользователей: затронутый процесс, 140 наблюдаемых ID аккаунтов и неизвестные обстоятельства.
- Варианты: альтернативные действия, нужные для них данные и работа, которую они отложат.
- Запись решения: ответственный, утверждённый объём, следующая проверка и ожидаемые к ней доказательства.
Храните выгрузки метрик и запросы вместе с презентацией, но не копируйте персональные данные клиентов на слайды. Для широкой аудитории подготовьте обезличенную сводку последствий. Изменение определения показывайте как будущую версию, а текущий результат оставляйте связанным с правилом, по которому он рассчитан.
Готовая запись решения вымышленной встречи может выглядеть так:
Одобрить исследование сценария сбоя подтверждения заявки объёмом два инженерных человеко-дня с руководителем сервиса в качестве ответственного. Представить воспроизведение, варианты смягчения и результаты тестов; снижение будущих ошибок пока не заявляется. Оставить SLO успешности 99,90% без изменений. На следующем обзоре также представить ограниченное по объёму предложение по измерению ошибок отправки до шлюза. Любая реализация за пределами исследования требует отдельного решения о выделении ресурсов.
Такая запись задаёт конкретную основу следующей встречи. Команда будет обсуждать данные определённой работы, а не снова показывать тот же зелёный процент и повторять то же обещание.
