Бюджет ошибок для небольшой команды: как задать реалистичные SLO для раннего продукта, решить какие инциденты важны и вести еженедельный ритуал.
Хаос обычно начинается не с падений продакшена, а со споров. Один говорит: «Нужно срочно делать фичи». Другой отвечает: «Сначала починим стабильность». Оба правы, потому что нет общих правил, по которым вы решаете, что важнее сегодня.
В маленькой команде надежность быстро превращается в бесконечное тушение пожаров. Ошибка в релизе, пара недовольных пользователей, ночной алерт, быстрый фикс, новый релиз, новый баг. План на неделю растворяется, а обсуждение превращается в обмен впечатлениями вместо решений.
Обычно это выглядит так:
Без рамок решения принимаются на эмоциях. Самый осторожный тормозит релиз, потому что страшно. Самый смелый пушит изменения, потому что «и так сойдет». В итоге скорость падает у всех: продуктовые задачи стоят, а надежность все равно не растет.
Система SLO и бюджет ошибок нужны не для красивых таблиц. Они должны дать несколько простых ответов, которые снимают споры:
Даже если вы быстро собираете продукт (например, прототипы и сервисы через TakProsto), эти правила помогают не застрять между «делаем фичи» и «чинить все». Когда рамки ясны, обсуждение становится коротким: бюджет ошибок еще есть или уже нет, и что вы делаете на этой неделе.
Чтобы говорить о надежности спокойно, полезно разнести четыре похожих слова по полочкам. Это не про бюрократию, а про ясность: что именно вы измеряете, чего хотите достичь и сколько сбоев считаете приемлемыми.
SLI (Service Level Indicator) - это измерение, один понятный показатель качества сервиса. Простыми словами: что именно вы считаете «хорошо». Например, доля успешных запросов к API, время ответа страницы, процент успешных оплат, число успешных запусков сборки. Если у вас продукт вроде TakProsto, SLI может быть «процент успешных сборок проекта без ошибок» или «доля чатов, которые завершились созданием рабочего результата».
SLO (Service Level Objective) - это целевой уровень SLI. Не обещание маркетинга, а рабочая цель команды. Например: «99,5% запросов к основному эндпоинту успешны за 30 дней» или «95% сборок завершаются успешно за неделю». SLO нужен, чтобы принимать решения: что чинить, что можно отложить, когда стоит притормозить релизы.
SLA (Service Level Agreement) - это уже договор с клиентом: юридически или финансово значимые обязательства (например, компенсации при простое). На ранней стадии SLA часто не нужен: он связывает руки и требует зрелых процессов поддержки. Многие команды стартуют с SLO внутри, а SLA вводят позже для платных тарифов или крупных клиентов.
Бюджет ошибок - это обратная сторона SLO: сколько «плохих» событий допустимо за период. Если SLO 99,5% успешных запросов в месяц, то 0,5% - ваш бюджет ошибок. Он нужен, чтобы спорить меньше и решать быстрее:
Так бюджет ошибок превращается в простой регулятор темпа, а не в вечную тревогу про аптайм.
Главная ошибка маленьких команд - пытаться измерять все сразу. Для старта достаточно 1-3 сценариев, которые напрямую влияют на деньги или на доверие: если они ломаются, пользователи уходят или пишут в поддержку.
Выбирайте сценарии не по тому, что проще замерить, а по тому, что больнее всего сломать. Обычно это вход в аккаунт, оплата, создание ключевого объекта (заказ, заявка, публикация, загрузка файла). Если продукт ранний и оплат пока нет, замените ее действием, после которого человек чаще всего возвращается.
Дальше каждому сценарию нужно простое определение успеха. Не усложняйте формулами: успех - это когда действие завершилось правильным результатом за разумное время.
Вот вопросы, которые помогают оформить метрику:
Не забывайте про сегменты, иначе «средняя температура» вас обманет. Минимум: мобильные против десктопа, регионы, пиковые часы. Иногда полезно отделить новых пользователей от постоянных: у новичков чаще всплывают проблемы с регистрацией и восстановлением доступа.
И сразу решите, откуда брать данные. Логи дают точные ошибки и статусы, мониторинг показывает доступность и задержки, а поддержка подсказывает, что реально бесит людей. Например, если вы собираете сервис в TakProsto и выкатываете часто, полезно завести правило: для каждого ключевого сценария есть один источник правды (метрики) и один источник контекста (логи и обращения). Тогда разбор инцидента занимает минуты, а не часы.
Первые SLO нужны, чтобы команда понимала, что считается нормой и в какой момент надежность начинает мешать росту. Для небольшой команды важно, чтобы правила были простыми и их реально было соблюдать.
Начните с одного пользовательского сценария, который чаще всего приносит деньги или удержание: вход, оплата, создание проекта, отправка сообщения.
Выберите окно измерения. Для маленькой команды удобны неделя (быстрее видно проблемы) или 28 дней (меньше шума от одного плохого дня).
Задайте SLO от реальности. Посмотрите последние 2-4 недели и поставьте цель чуть выше текущего уровня, а не «99.99» по привычке.
Посчитайте бюджет ошибок простым способом. Переведите SLO в понятные минуты простоя или в проценты неуспешных операций за выбранное окно.
Согласуйте SLO с продуктом и графиком релизов. Если впереди агрессивные фичи, цель должна учитывать, что команда будет чаще рисковать изменениями.
Запишите одно правило на случай перерасхода бюджета. Одно, не десять, чтобы не спорить в моменте.
Допустим, у вас веб-сервис, и главный сценарий - пользователь не может завершить ключевое действие (например, создать рабочее пространство или оплатить подписку). Вы выбираете окно 7 дней и цель 99,5% успешных попыток. Это значит, что из 10 000 попыток вы допускаете до 50 неуспешных, или, если меряете доступность по минутам, заранее фиксируете допустимый простой на неделю.
Правило при перерасходе может быть таким: на ближайшую неделю замораживаете релизы новых фич и тратите фиксированное время на исправления, пока не вернетесь в бюджет. Это предсказуемо и помогает не превращать надежность в бесконечный спор.
В маленькой команде частый провал не в том, что нет мониторинга, а в том, что слово «инцидент» означает все подряд. Тогда вы либо тушите каждый чих, либо перестаете реагировать вообще. Лучше заранее договориться, что именно считается инцидентом.
Инцидентом обычно стоит считать три класса событий: недоступность (пользователь не может сделать действие), деградацию (может, но медленно или с ошибками) и неверные данные (действие прошло, но результат неправильный). Третий пункт часто больнее первых двух: он бьет по доверию, даже если интерфейс выглядит «живым».
Полезно делить инциденты по влиянию, а не по эмоциям. Для старта достаточно такой шкалы:
Чтобы это не превратилось в бюрократию, фиксируйте инцидент за 5 минут. Достаточно короткой карточки:
«Мелочь» становится важной, когда повторяется. Один редкий таймаут может быть шумом. Но если одно и то же происходит каждую неделю, это уже системная деградация, которая съедает бюджет ошибок и силы поддержки.
Для эскалации нужен простой порог, чтобы не спорить каждый раз. Например: эскалируем, если проблема длится дольше 15 минут для ключевого действия, или затрагивает больше 5% активных пользователей за час, или приводит к неверным данным хотя бы у нескольких клиентов.
Пример: у сервиса вроде TakProsto, где пользователи создают приложения через чат, «чат иногда медленный» может быть неудобством. Но «созданный проект не сохраняется» или «экспорт исходников выдает чужие данные» сразу переходит в категорию критично для доверия, даже если случилось у малого числа людей.
Маленькой команде не нужен комитет по надежности. Нужна короткая встреча, которая повторяется раз в неделю в один и тот же день и не съедает роадмап. Обычно хватает 30-45 минут, с понятным владельцем и понятным результатом.
Хороший ритм выглядит так: в календаре стоит один слот, а готовиться к нему можно за 5 минут. Один человек ведет встречу (часто тот, кто отвечает за продукт или релизы), другой фиксирует решения в заметках.
Начинайте с фактов, а не с мнений:
После встречи сразу зафиксируйте 1-3 задачи на надежность. Больше обычно не выполняется. Задачи должны быть конкретными: добавить алерт на рост 500 ошибок, ограничить таймауты на одном эндпоинте, включить обязательный откат при росте ошибок после релиза.
Чтобы разговор оставался спокойным и полезным, держите простые правила:
Пример: после релиза выросло число ошибок, но откат не сделали, потому что «не были уверены». Решение на неделю: добавить понятный порог отката и использовать снимки и rollback (это удобно, если платформа уже поддерживает такие механики, как TakProsto) и назначить владельца, который проверит это на следующем релизе.
Бюджет ошибок работает только тогда, когда влияет на решения. Иначе это просто цифра в отчете. Для небольшой команды он особенно полезен: помогает спорить не «на ощущениях», а по простому правилу, которое все приняли заранее.
Договоритесь, что происходит с релизами в зависимости от того, сколько бюджета уже потрачено за период (например, за 30 дней). Это можно описать одним абзацем.
Важно: «красная зона» не означает остановку всего. Выпускать можно то, что снижает риск: фиксы, наблюдаемость, ограничения нагрузки, улучшение отката.
Лучше всего работает короткое правило: если вы в желтой или красной зоне, вы не спорите о каждом релизе отдельно, а автоматически снижаете риск. Продукту проще принять это, когда есть понятный список того, что откладывается.
Например, в TakProsto команда может продолжать улучшать планирование и стабильность генерации, но отложить изменения, которые сильно трогают деплой, хостинг или экспорт кода, если бюджет уже «горит». А чтобы не блокировать работу, держите готовый план отката - снапшоты и rollback помогают, когда релиз все же нужен.
Чтобы разговор был честным, фиксируйте не только «что не выпускаем», но и «что делаем вместо»:
Так бюджет ошибок становится понятным «светофором» для релизов, а не поводом для взаимных обвинений.
Самая частая проблема не в том, что у команды нет метрик. Проблема в том, что метрики выбраны так, что с ними невозможно жить. Тогда SLO превращается в бумажку, а бюджет ошибок быстро теряет смысл.
Первая ловушка - поставить слишком высокий SLO (например, 99,99%), а потом молча его игнорировать. Если команда не может поддерживать такой уровень без остановки разработки, SLO должен быть ниже. Иначе вы учите себя, что правила не важны.
Вторая ловушка - мерить «среднее». Среднее время ответа красиво выглядит на графике, но плохо показывает боль пользователей. Лучше смотреть долю успешных операций: какой процент запросов прошел без ошибок и уложился в порог по времени. Среднее может быть «нормальным», даже если у части пользователей все еле работает.
Третья ловушка - считать только падения. Сервис может не падать, но деградировать: ответы становятся медленнее, очереди растут, мобильное приложение «думает» по 10 секунд. Пользователь это воспринимает как поломку, даже если в логах нет 500-х.
Еще одна боль - постоянная смена определений. Если каждую неделю вы меняете, что считается «успехом», сравнивать периоды невозможно. Договоритесь о формулировке и держите ее хотя бы квартал.
Чтобы не утонуть, держите фокус на малом наборе сигналов. Обычно хватает 2-3 метрик:
И последнее: разборы инцидентов без изменений в системе. Если после постмортема не появилось конкретное действие (алерт, лимит, кэш, таймаут, тест, откат), это была беседа, а не улучшение надежности. Маленькой команде важнее один небольшой фикс каждую неделю, чем идеальный отчет.
Если вы можете честно поставить галочки в пунктах ниже, у вас уже есть рабочий минимум. Этого достаточно, чтобы бюджет ошибок не превращался в бесконечные обсуждения, а помогал принимать решения.
Метрики не должны требовать сложной аналитики. На раннем продукте лучше грубо, но регулярно, чем идеально, но никогда.
И обязательно нужно правило действий при перерасходе бюджета ошибок. Например: на неделю замораживаете рискованные релизы, чините топ-1 причину падений и только потом возвращаетесь к фичам. Без этого чеклист выглядит красиво, но не влияет на реальность.
Команда: 2 разработчика и 1 продакт. Продукт только вышел в тестовую аудиторию, баги еще есть, а роадмап забит фичами. Чтобы не спорить «на ощущениях», вы вводите простой бюджет ошибок на ключевые пользовательские действия.
Выбираете 3 сценария, без которых сервис теряет смысл: регистрация, оплата, просмотр основного экрана (например, ленты, дашборда или списка задач). Не берете «все подряд», иначе никто не будет это считать.
Первые SLO ставите на окно 28 дней (так проще сравнивать месяцы) и сразу переводите в минуты:
Неделя с инцидентом выглядит так: во вторник платежи падали 35 минут из-за ошибки в конфигурации, а в четверг еще 20 минут часть пользователей не могла открыть основной экран после релиза. На ритуале вы классифицируете события по влиянию: «блокирующее» (нельзя оплатить), «сильное ухудшение» (часть пользователей не может работать), «мелочь» (косметика, редкий кейс). В бюджет идут только первые два типа и только для выбранных сценариев.
Если по оплате бюджет уже в красной зоне (например, осталось меньше 30 минут на 28 дней), решения становятся простыми:
Через месяц вы пересматриваете SLO. Часто оказывается, что «основной экран» лучше мерить не по аптайму, а по доле быстрых загрузок, а по регистрации нужно разделить «создание аккаунта» и «подтверждение кода». Если вы собираете продукт в TakProsto, удобно опираться на снапшоты и откат, чтобы быстрее возвращаться в зеленую зону и не выбрасывать весь план работ.
Цель на первый месяц простая: договориться о минимальных SLO, начать фиксировать инциденты одним способом и завести короткий ритм, который не съедает разработку. Это и есть практичный бюджет ошибок для маленькой команды - без отдельной роли SRE и без бесконечных таблиц.
Начните с короткого цикла, где каждый шаг полезен сам по себе:
Шаблон нужен не «для отчетности», а чтобы каждый инцидент заканчивался действием. Держите его коротким:
Дальше решите, что стабилизировать перед ростом. Обычно первыми идут: аутентификация, платежи и тарифы, критичные интеграции, база данных и деплой. Хорошее правило: укрепляйте то, что чаще всего бьет по ключевому сценарию, даже если «в целом все работает».
Если вы делаете продукт в TakProsto, зафиксируйте договоренности в Planning mode (какие SLO и что считаете инцидентом), а для релизов используйте snapshots и rollback, чтобы безопасно откатываться. Когда команда растет, такие привычки проще поддерживать на одной платформе, например takprosto.ai, чем собирать процесс из разрозненных инструментов.
Запланируйте первую еженедельную встречу сразу: 25-30 минут, один владелец, один список действий. Через месяц у вас появится ритм, который не мешает роадмапу, а защищает его.
