23 дек. 2025 г.·6 мин
Бюджеты ошибок для маленьких команд: реалистичные SLO и ритуалы
Как маленькие команды могут задать реалистичные SLO для ранних продуктов, решить, какие инциденты важны, и проводить простой еженедельный ритуал надёжности.
Как маленькие команды могут задать реалистичные SLO для ранних продуктов, решить, какие инциденты важны, и проводить простой еженедельный ритуал надёжности.
Маленькие команды выпускают быстро, потому что иначе не получается. Риск обычно не в одном драматическом падении — это одна и та же мелкая ошибка, что повторяется: нестабильная регистрация, корзина, которая иногда ломается, деплой, что время от времени ломает один экран. Всё это крадёт часы, подрывает доверие и превращает релизы в кошелек с монеткой.
Бюджеты ошибок дают маленьким командам простой способ двигаться быстро, не притворяясь, что надёжность «просто случится».
SLO (service level objective) — это явное обещание о пользовательском опыте в виде числа за окно времени. Пример: «Успешные оплаты — не менее 99.5% за последние 7 дней.» Бюджет ошибок — это допустимая доля «плохого» внутри этого обещания. Если ваш SLO 99.5%, ваш недельный бюджет — 0.5% неуспешных оплат.
Речь не о перфекционизме или показной доступности. Это не тяжёлая бюрократия с бесконечными встречами и табличкой, которую никто не обновляет. Это способ договориться, что значит «достаточно хорошо», заметить отклонение и спокойно выбрать, что делать дальше.
Начните с малого: выберите 1–3 пользовательских SLO, привязанных к самым важным сценариям, измеряйте их с помощью сигналов, которые у вас уже есть (ошибки, задержки, неудачные платежи) и проводите короткий еженедельный обзор, где смотрите расход бюджета и выбираете одно последующее действие. Привычка важнее инструментов.
Представьте надёжность как план питания. Вам не нужны идеальные дни. Нужна цель, способ её измерить и запас на реальную жизнь.
SLI (service level indicator) — число, за которым вы следите, например «% успешных запросов» или «p95 загрузки страницы < 2 секунды». SLO — целевой уровень для этой метрики, например «99.9% запросов успешны». Бюджет ошибок — это то, насколько вы можете отклониться от SLO и оставаться в рамках.
Пример: если SLO — 99.9% доступности, бюджет — 0.1% простоя. За неделю (10 080 минут) 0.1% — это примерно 10 минут. Это не значит, что нужно пытаться «использовать» эти 10 минут. Это значит, что когда вы их расходуете, вы сознательно обмениваете надёжность на скорость, эксперименты или фичи.
Ценность в том, что надёжность становится инструментом принятия решений, а не просто отчётом. Если вы сожгли большую часть бюджета уже к среде — вы приостанавливаете рискованные изменения и чините то, что ломается. Если бюджет почти не используется — можно релизить увереннее.
Не всё требует одинакового SLO. Публичное клиентское приложение может требовать 99.9%. Внутренний админ-инструмент часто может быть мягче, потому что меньше людей заметят и последствия меньше.
Не начинайте с измерения всего. Начните с защиты моментов, где пользователь решает, работает ваш продукт или нет.
Выберите 1–3 пользовательских пути, которые несут наибольшее доверие. Если они стабильны, большинство других проблем кажутся менее критичными. Хорошие кандидаты: первый контакт (регистрация или вход), момент денег (оплата или апгрейд) и основное действие (публикация, создание, отправка, загрузка или критический API-вызов).
Опишите, что значит «успех», простыми словами. Избегайте технической формулировки вроде «200 OK», если ваши пользователи не разработчики.
Несколько адаптируемых примеров:
Выберите окно измерения, которое соответствует скорости ваших изменений. 7 дней подходит, если вы релизите ежедневно и хотите быстрый фидбек. 28 дней спокойнее, если релизы реже или данные шумные.
У ранних продуктов есть ограничения: трафика может быть мало (один плохой деплой искажает числа), потоки быстро меняются, телеметрии часто мало. Это нормально. Начните со простых счётчиков (попытки vs успехи). Уточняйте определения, когда сам путь перестанет меняться.
Исходите из того, что вы реально выпускаете сегодня, а не из желаемого. В течение недели-двух зафиксируйте базовую линию для каждого ключевого пути: как часто он успешен и как часто — нет. Используйте реальный трафик, если он есть. Если нет — используйте собственные тесты, тикеты поддержки и логи. Вы строите приблизительную картину «нормы».
Первый SLO должен быть таким, который вы сможете выполнять большую часть недель, продолжая выпускать. Если ваш базовый уровень — 98.5%, не ставьте 99.9% наудачу. Поставьте 98% или 98.5%, затем ужесточайте позже.
Задержка заманчивa, но может отвлекать в начале. Многие команды получают больше пользы от SLO по успешности (запросы завершаются без ошибок). Добавляйте показатели задержки, когда пользователи действительно начинают её чувствовать и у вас достаточно стабильных данных.
Удобный формат — одна строка на сценарий: кто, что, цель и окно времени.
Держите окно длиннее для моментов денег и доверия (биллинг, аутентификация). Короткие окна лучше для ежедневных потоков. Когда вы легко достигаете SLO — немного повышайте и продолжайте.
Маленькие команды тратят много времени на надёжность, когда каждая мелочь превращается в пожар. Цель проста: пользовательская боль списывается с бюджета; всё остальное решается как обычная задача.
Небольшого набора типов инцидентов достаточно: полный аутейдж, частичный сбой (ломается ключевой путь), деградация производительности (работает, но медленно), плохой деплой (релиз вызывает ошибки), и проблемы с данными (неверно, пропущено, дублирование).
Держите шкалу маленькой и пользуйтесь ею всегда.
Решите, что считается расходом бюджета. Считайте пользовательские видимые ошибки как расход: сломанная регистрация или оплата, тайм-ауты, которые чувствует пользователь, всплески 5xx, останавливающие путь. Плановое обслуживание не должно считаться, если вы заранее сообщили и приложение вело себя ожидаемо в это окно.
Одно правило решает большинство споров: если реальный внешний пользователь заметил бы проблему и не смог бы завершить защищённый путь, это считается. Иначе — нет.
Это правило покрывает и серые зоны: сторонний провайдер считается только если он ломает ваш путь, часы с низким трафиком считаются, если пользователь пострадал, внутренние тестеры не учитываются, если только догфудинг не основной способ использования.
Цель — не идеальное измерение. Цель — общий, повторяемый сигнал, который показывает, когда надёжность становится дорогой.
Для каждого SLO выберите один источник правды и придерживайтесь его: дашборд, логи приложения, синтетическая проверка одного эндпоинта или одна метрика вроде успешных оплат в минуту. Если позже меняете способ измерения, зафиксируйте дату и считайте это точкой отсчёта, чтобы не сравнивать яблоки с апельсинами.
Алерты должны отражать расход бюджета, а не каждую мелочь. Короткий всплеск может раздражать, но не должен будить команду, если он едва коснулся месячного бюджета. Один простой шаблон работает хорошо: алерт на «быстрый расход» (вы на пути сожрать месячный бюджет за день) и мягкий алерт на «медленный расход» (вы сожрёте его за неделю).
Ведите крошечный лог надёжности, чтобы не полагаться на память. Достаточно одной строки на инцидент: дата и длительность, влияние на пользователей, вероятная причина, что изменили и кто отвечает с дедлайном.
Пример: команда из двух человек делает новый API для мобильного приложения. Их SLO — «99.5% успешных запросов», измеряется одним счётчиком. Плохой деплой снизил успех до 97% на 20 минут. Сработал алерт «быстрый расход», они откатились, и последующее действие — «добавить канареечную проверку перед деплоем».
Вам не нужен большой процесс. Нужна маленькая привычка, которая держит надёжность видимой, не крадя разработку. 20-минутная короткая проверка работает, потому что всё сводится к одному вопросу: тратим ли мы надёжность быстрее, чем планировали?
Назначьте одно и то же время в календаре каждую неделю. Ведите одну общую заметку, в которую дописываете (не переписывайте). Последовательность важнее деталей.
Простая повестка, которая помещается:
Между задачами и обязательствами решите правило релизов на неделю и держите его простым:
Если в регистрации были два коротких простоя и она сожгла большую часть бюджета, вы можете заморозить только изменения, связанные с регистрацией, и при этом продолжать выпускать остальное.
Бюджет ошибок важен только если он меняет то, что вы делаете на следующей неделе. Смысл не в идеальной доступности. Смысл — в понятном способе решения: релизим фичи или закрываем долг по надёжности?
Политика, которую легко проговорить:
Это не наказание. Это публичный обмен, чтобы пользователи не платили за это потом.
Когда вы замедляетесь, избегайте расплывчатых задач типа «улучшить стабильность». Выбирайте изменения, которые влияют на следующий результат: добавьте страховку (тайм-ауты, валидацию ввода, лимиты), улучшите тест, который бы поймал баг, упростите откат, почините основной источник ошибок или добавьте один алерт, привязанный к пользовательскому пути.
Держите отчётность отдельно от обвинений. Поощряйте быстрые отчёты об инцидентах, даже если детали неаккуратны. Единственный по-настоящему плохой постмортем — тот, что появляется поздно, когда никто не помнит, что изменилось.
Одна частая ошибка — установить «золотой» SLO с первого дня (99.99% звучит круто) и тихо его игнорировать, когда реальность вмешивается. Ваш стартовый SLO должен быть достижим с текущими людьми и инструментами, иначе он станет фоном.
Ещё одна ошибка — измерять не то. Команды смотрят пять сервисов и граф базы данных, но пропускают путь, который действительно чувствует пользователь: регистрация, оплата или «сохранить изменения». Если вы не можете объяснить SLO одним предложением с точки зрения пользователя — вероятно, он слишком внутренний.
Усталость от алертов выжигает единственного человека, кто может фиксить продакшен. Если каждая мелочь будит кого-то — оповещения становятся «нормой», и настоящие пожары пропускаются. Пейджьте по влиянию на пользователя. Всё остальное — в ежедневную проверку.
Более тихая проблема — непоследовательный подсчёт. Одна неделя вы считаете двухминутную заминку инцидентом, другая — нет. Тогда бюджет превращается в предмет спора, а не в сигнал. Описывайте правила один раз и применяйте их последовательно.
Страховые меры, которые помогают:
Если деплой ломает вход на 3 минуты, учитывайте это всегда, даже если починили быстро. Последовательность делает бюджет полезным.
Поставьте таймер на 10 минут, откройте общий документ и ответьте на пять вопросов:
Если вы пока не можете измерить — начните с прокси, который видно быстро: неуспешные платежи, 500 ошибки или тикеты поддержки с меткой «checkout». Меняйте прокси по мере улучшения трекинга.
Пример: команда из двух человек увидела три сообщения «не могу сбросить пароль» за неделю. Если сброс пароля — защищённый путь, это инцидент. Они пишут короткую заметку (что случилось, сколько пользователей, что сделали) и выбирают одно последующее действие: добавить алерт на сбои сброса или добавить ретрай.
Майя и Джон ведут стартап из двух человек и релизят по пятницам. Они движутся быстро, но первые платящие пользователи заботятся лишь об одном: могут ли они создать проект и пригласить коллегу, не сломавшись?
На прошлой неделе был реальный аутейдж: «Создание проекта» падало 22 минуты после плохой миграции. Были ещё три периода «медленно, но работает» — экран крутился 8–12 секунд. Пользователи жаловались, а команда спорила, считать ли медленную работу «падением».
Они выбрали один путь и сделали его измеримым:
В понедельник они проводят 20-минутный ритуал. То же время, тот же документ. Отвечают на четыре вопроса: что случилось, сколько бюджета сожжено, что повторилось и какое одно изменение предотвратит повтор.
Торговля становится очевидной: аутейдж плюс медленные периоды сожгли большую часть недельного бюджета. Значит, следующая неделя вместо «одной большой фичи» превращается в «добавить индекс БД, сделать миграции безопаснее и поставить алерт на ошибки create-project».
Результат — не идеальная доступность, а меньше повторяющихся проблем, более ясные решения и меньше ночных боёв, потому что заранее договорились, что значит «достаточно плохо».
Выберите один пользовательский путь и дайте ему простое обещание по надёжности. Бюджеты ошибок работают лучше, когда они скучные и повторяемые, а не идеальные.
Начните с одного SLO и одного еженедельного ритуала. Если через месяц это всё ещё легко — добавьте второй SLO. Если тяжело — уменьшите объём.
Держите математику простой (неделя или месяц). Ставьте цель, реалистичную для текущего состояния. Напишите одностраничную заметку, отвечающую: какой SLO и как измеряете, что считается инцидентом, кто отвечает на этой неделе, когда проверка и что делать по умолчанию, если бюджет сжигается слишком быстро.
Если вы собираете на платформе вроде Koder.ai (koder.ai), это помогает сочетать быстрые итерации с практиками безопасности, особенно снимками и откатами, чтобы «вернуть к последнему рабочему состоянию» оставалось привычным и отработанным действием.
Держите цикл коротким: один SLO, одна заметка, одна короткая еженедельная встреча. Цель не в том, чтобы устранить инциденты, а в том, чтобы замечать их рано, решать спокойно и защищать те вещи, которые действительно чувствуют пользователи.
SLO — это обещание по надёжности, которое описывает пользовательский опыт и измеряется за выбранное окно времени (например, 7 или 30 дней).
Пример: «99.5% успешных завершений оплаты за последние 7 дней.»
Бюджет ошибок — это допустимая доля «плохого» внутри вашего SLO.
Если SLO — 99.5% успеха, то бюджет — 0.5% неудач за это окно. Когда бюджет расходуется слишком быстро, вы замедляете рискованные изменения и исправляете причины.
Начните с 1–3 пользовательских сценариев, которые пользователи замечают сразу:
Если эти сценарии надёжны, большинство других проблем кажутся менее важными и проще к приоритизации.
Выберите базовую линию, которую вы действительно можете достигать большую часть недель.
Если сегодня у вас 98.5%, начать с 98–98.5% полезнее, чем заявлять 99.9% и игнорировать это.
Используйте простые счётчики: попытки vs. успехи.
Хорошие источники начальных данных:
Не ждите идеальной наблюдаемости — начинайте с прокси и держите его постоянным.
Засчитывайте инцидент, если внешний пользователь заметит проблему и не сможет завершить защищённый сценарий.
Типичные примеры, идущие против бюджета:
Не учитывайте внутренние неудобства, если только внутренняя эксплуатация не является основным способом использования продукта.
Правило простое: алертьте по расходу бюджета, а не по каждой мелкой аномалии.
Два полезных типа алертов:
Это уменьшает усталость от оповещений и концентрирует внимание на проблемах, которые действительно поменяют план релизов.
Держите встречу 20 минут, в одно и то же время, в одном документе:
В конце решите режим релизов на неделю: , или .
Используйте простую политику, которую можно озвучить вслух:
Цель — спокойный обмен приоритетами, а не наказание.
Несколько практических правил помогают:
Если вы строите на платформе вроде Koder.ai, делайте «вернуть к последнему рабочему состоянию» обычным и отрабатываемым действием; повторные откаты сигнализируют о необходимости тестов или безопасных проверок при деплое.