Как писать надёжное и отказоустойчивое ПО в 2026: SLO, паттерны и метрики DORA

Почему Фора Софт написала этот плейбук

Фора Софт с 2005 года выпускает продукты для видеосвязи в реальном времени, e-learning, телемедицины и стриминга. Каждый из них живёт или умирает по одному критерию — надёжности: зависший звонок стоит клинике приём, оборванный live-стрим в шопинге — час продаж, неустойчивая лекция в LMS — целый учебный день. Мы провели множество постмортемов. Паттерны оказались удивительно одинаковыми в разных категориях продуктов — и исправления тоже.

Этот плейбук объединяет всё, что мы проверили на практике, в рамках проектов BrainCert (LMS на базе WebRTC с годовой выручкой 750 млн ₽), Sprii (платформа live-шопинга, где прошло более 72 тыс. прямых трансляций и было заработано продавцами более 365 млн евро) и ProVideoMeeting (корпоративный видеостек, поддерживающий более 1000 участников в одной комнате), в единый фреймворк для принятия решений. Он адресован основателям, CTO и техническим лидерам, которые выбирают: «выпустить быстро, а потом исправить» или «инвестировать в надёжность уже сейчас».

Цифры ниже взяты из открытых источников (Google SRE workbook, AWS Well-Architected, отчёты ITIC и Gartner о стоимости простоя, метрики DORA 2024, постмортемы CrowdStrike и Datadog). Там, где мы ссылаемся на собственные клиентские проекты, указываем диапазоны, а не конкретные цифры, чтобы не нарушать NDA.

Что «надёжное» означает в 2026 году

Отказоустойчивого ПО без сбоев не существует. Есть ПО, которое падает в рамках допустимого, восстанавливается быстрее, чем пользователь успеет это заметить, и постепенно ухудшает работу вместо того, чтобы сломаться полностью. Именно это сегодня и называют Site Reliability Engineering (SRE). Google SRE workbook определил ключевые термины десять лет назад, и с тех пор индустрия пришла к общему пониманию этой терминологии.

Три понятия задают любой разговор о надёжности. Service Level Indicator (SLI) — это метрика, которую вы измеряете: процент доступности, задержка на 99-м перцентиле, доля ошибок. Service Level Objective (SLO) — целевое значение этой метрики за определённый период: «99,95% запросов отвечают быстрее 250 мс за 30 дней». Service Level Agreement (SLA) — то, что вы обязаны предоставить клиенту по договору, если не выполнили SLO, обычно — компенсация. Бюджет ошибок — это разница: SLO в 99,95% даёт вам 21,6 минуты допустимого простоя в месяц.

Пока бюджет ошибок не исчерпан, вы быстро выпускаете новые функции. Когда он заканчивается — останавливаете релизы и укрепляете систему. Это одно правило заменяет расплывчатую речь о «надёжности» на конкретный компромисс, по которому инженерные команды могут договориться без споров.

Сколько стоит время простоя (данные индустрии)

Разговор о надёжности всегда сводится к деньгам. Индустриальные опросы выделяют несколько ключевых ориентиров, которые стоит запомнить перед следующей встречей по бюджету.

Инвестиции в надёжность, которые предотвращают один час простоя в SaaS среднего сегмента, обычно окупаются уже в ту же неделю. Именно так финансовый директор должен слышать об этом — в рублях, а не в инженерном жаргоне.

Восемь категорий отказов, на которые приходится большинство инцидентов

Когда мы проводим аудит надёжности кодовой базы клиента, одни и те же восемь категорий повторяются снова и снова. Проверка по этому списку в начале аудита экономит неделю работы.

1. Утечки памяти. Незакрытые соединения с базой данных, забытые обработчики событий, кэши, которые не освобождают память. Симптом: задержки постепенно растут, но исчезают после перезапуска сервиса. Решение: анализ использования памяти и проверка, как объекты создаются и удаляются.

2. Каскадные сбои и шторм ретраев. Один внешний API замедляется до 8 секунд; все начинают делать повторные попытки; пул соединений выше по стеку исчерпывается; следующий хоп падает. Решение: circuit breaker, bulkhead, бюджеты на ретраи.

3. Гонки. Два запроса одновременно обновляют одну и ту же строку — побеждает не тот, который должен, и данные клиента без предупреждения портятся. Решение: оптимистичные блокировки, чёткие границы транзакций, ключи идемпотентности.

4. Необработанные исключения. Null pointer в редко используемой ветке останавливает весь воркер. Решение: структурированная обработка ошибок, panic budgets, мониторинг sentinel-ошибок.

5. Сбои зависимостей и цепочки поставок. В три часа ночи сторонний SDK выпускает проблемную версию, и ваш CI автоматически её подтягивает. Сценарий CrowdStrike. Решение: фиксированные версии, поэтапный релиз, каналы связи с вендорами для инцидентов.

6. Сбои из-за деплоя. Отчёт DORA 2024 показывает: частота сбоев при изменениях — самый сильный рычаг повышения надёжности. Решение: поэтапный запуск, автоматические механизмы отката, контрактные тесты.

7. Сбои инфраструктуры. В регионе AWS us-east-1 с 2017 года происходит как минимум один серьёзный инцидент в год. Решение: для критически важных сервисов использовать как минимум multi-AZ и multi-region, а также подготовить runbook-сценарии на случай сбоев у облачного провайдера.

8. Дрейф конфигурации. Флаг включён на одном сервере, а на другом — забыт; на staging всё работает, а в production — ошибка. Решение: GitOps, инфраструктура как код, проверка конфигураций в CI.

Шесть паттернов, которые предотвращают большинство сбоев

Нет единого «фреймворка надёжности», который можно поставить и забыть. Устойчивость строится из проверенных паттернов. Шесть из них играют ключевую роль.

Circuit breaker

Circuit breaker отслеживает долю ошибок при обращении к внешнему сервису. Когда доля переваливает за порог, breaker размыкается и ваш код быстро отдаёт ошибку в течение периода остывания, вместо того чтобы копить запросы. Боевые библиотеки: resilience4j для JVM, Polly для .NET, gobreaker для Go.

Bulkhead

Bulkhead изолирует домены отказа. Один пул потоков на каждую зависимость, один пул соединений на каждую базу, один namespace в Kubernetes на каждый радиус поражения. Когда падает платёжный микросервис, остальное приложение продолжает работать. Сбой Datadog в марте 2023 года стал тотальным именно потому, что между control plane и data plane не было такой изоляции.

Ретраи с экспоненциальной задержкой и джиттером

Ретраи без задержки превращают одну ошибку в цепную реакцию. Стандартный подход: 100 мс, потом 200, потом 400, потом 800 — с добавлением случайного джиттера (±25%), чтобы распределить попытки во времени. Ограничьте количество попыток пятью и установите общий лимит в 30 секунд. В Reliability Pillar от AWS есть каноническая эталонная реализация.

Ключи идемпотентности

Изменяющие данные эндпоинты принимают от клиента заголовок Idempotency-Key. Сервер сохраняет результат на 24 часа; при повторных запросах возвращается тот же ответ без побочных эффектов. Этот паттерн популяризировал Stripe; сегодня его поддерживают большинство платёжных и резервирующих API.

Фича-флаги и поэтапный запуск

Любое рискованное изменение выпускается под флагом и постепенно раскатывается по схеме 1% → 10% → 50% → 100% с проверкой метрик на каждом этапе. Популярные инструменты: LaunchDarkly, GrowthBook и Unleash. При поэтапном развертывании инцидент CrowdStrike затронул бы только 1% хостов вместо 8,5 млн по всему миру.

Наблюдаемость на базе OpenTelemetry

Логи, метрики и трейсы передаются в формате OpenTelemetry и далее направляются в нужный вам бэкенд — Datadog, New Relic, Honeycomb, Grafana Cloud или Sentry. Зависимость от одного вендора больше не проблема. Основная цель — оповещать о скорости расхода бюджета по SLO, а не реагировать на жёсткие пороговые значения. Сам по себе такой подход даёт большинству команд самое заметное улучшение в борьбе с избыточными оповещениями.

Пять громких сбоев и один урок из каждого

Публичные постмортемы — самое близкое к бесплатному обучению в индустрии. Пять последних, краткое содержание которых должен уметь пересказать любой основатель.

Надёжность на мобильных: метрики, которые влияют на удержание

Для mobile-first продуктов — приложений для звонков, e-learning, стриминга, телемедицины — серверный разговор про SLO — это только половина истории. Вторая половина происходит на устройстве и измеряется в Firebase Crashlytics или Sentry Mobile.

Crash-free user rate. Главная метрика. Базовый уровень — 99% на Android, 99,5% на iOS. Премиальные продукты держат 99,9% и выше. Падение на 0,5 пункта обычно за две недели превращается в волну отзывов с одной звездой в магазине.

ANR rate (только Android). Показатель Application Not Responding должен быть ниже 0,5% сессий. Если выше — Google Play начинает понижать приложение в поиске, не уведомляя разработчиков. Проблему почти всегда вызывает выполнение фоновых задач в главном потоке: например, ввод-вывод в Compose, декодирование изображений на UI-потоке или десериализация в адаптерах.

Watchdog на foreground service. Для приложений со звонками и стримингом — активный FOREGROUND_SERVICE_TYPE_PHONE_CALL или FOREGROUND_SERVICE_TYPE_MEDIA_PLAYBACK с новым дедлайном в пять секунд на вызове startForeground в Android 14+. Если не уложитесь — система выбросит ForegroundServiceDidNotStartInTimeException: звонок обрывается, пользователь винит приложение. Эти сценарии мы подробно рассмотрели в нашем гайде по foreground service и deep link на Android 14.

Устойчивость к сети. Синхронизация по принципу «сначала оффлайн», лимиты на повторные попытки, которые передают задачи фоновым воркерам, экспоненциальная задержка между вызовами API и breadcrumbs в Sentry, фиксирующие тип сети (LTE / 5G / Wi-Fi / нет подключения) в момент сбоя.

Матрица OEM. Поведение стокового Pixel не предсказывает поведение Xiaomi. Мы включаем топ-5 OEM в матрицу устройств на этапе CI каждого Android-клиента — точно так же, как описано в нашем гайде по кастомным уведомлениям о звонках на Android.

Real-time и AI-нагрузки: своя планка надёжности

Стандартные SLO разрабатывались для сервисов типа «запрос-ответ». Видео в реальном времени и функции на основе LLM требуют новых метрик и дополнительных мер защиты.

Видео в реальном времени. Важные метрики: mean opinion score (MOS), доля потерянных пакетов (цель — ниже 2%) и round-trip- time p95 (цель — ниже 200 мс). Используйте архитектуру SFU/MCU с запасом мощности в два раза больше пиковой нагрузки. Компромиссы мы подробно рассмотрели в гайде по архитектуре кастомной видеоконференции.

Фичи на LLM. Обработка галлюцинаций, ограничение расходов по токенам, переключение между моделями (Claude ↔ OpenAI ↔ Llama). Langfuse, LangSmith и Helicone обеспечивают отслеживание поведения моделей. Относитесь к LLM как к ненадёжной зависимости: оборачивайте в circuit breaker, применяйте повторные попытки, ограничивайте зону влияния.

Стриминг. Доля пустых буферов плеера — менее 1%, время до первого кадра — менее 2 секунд, ABR-лестница протестирована на медленных каналах. В плейбуке live-шопинга Sprii есть синтетический поток, который запускается каждые 60 секунд и оповещает дежурного, как только MOS падает.

DORA 2024: как топовые команды выпускают обновления безопасно

Ежегодный отчёт Google DORA (DevOps Research and Assessment) измеряет четыре ключевые метрики в тысячах инженерных организаций и делит их на элитные, высокие, средние и низкие группы. Цифры за 2024 год — это ориентир, на который должна стремиться любая программа по обеспечению надёжности.

Контринтуитивный вывод по итогам десятилетия данных DORA: элитные команды выпускают обновления чаще — и при этом сталкиваются с меньшим количеством сбоев. Надёжность и скорость доставки идут рука об руку, а не противопоставляются друг другу. Общая причина — строгая поэтапная выкатка и зрелая наблюдаемость, которые дают инженерам уверенность выпускать обновления чаще.

Организация и процессы: человеческая сторона надёжности

Одних инструментов надёжности недостаточно. Один и тот же набор паттернов в карательной культуре постмортемов не сработает, а в безвиновной on-call культуре — сработает. Пять процессных привычек, общих для всех надёжных инженерных организаций.

1. Безвиновные постмортемы. Шаблон Etsy — публичный эталон. Акцент делается на системе, а не на человеке. Каждый постмортем завершается тремя–пятью пунктами с ответственными и сроками.

2. Дежурства с ритуалами передачи. Смены — не дольше 12 часов. Передача по средам с чётким переходом ответственности. Пейджи — это работа, а не подвиг.

3. Pre-prod, совпадающий с prod. Те же версии компонентов Kubernetes, тот же менеджер секретов, та же сетевая топология. Различия между окружениями приводят к багам вроде «у меня на staging всё работает», которые обязательно проявятся в самый неподходящий момент — например, ночью.

4. Учения по восстановлению после катастроф. Раз в квартал. Восстановите данные из резервной копии, переключитесь на резервный регион, отключите основную базу данных. Непроверенный план восстановления — это лишь теория.

5. Пирамида тестов. Много быстрых юнит-тестов, меньше интеграционных, ещё меньше end-to-end. Обратная форма (много медленных E2E, мало юнит-тестов) — второй по частоте антипаттерн в наших аудитах после отсутствия наблюдаемости.

Мини-кейс: как мы сократили MTTR с 6 часов до 22 минут на SaaS-платформе

К нам пришёл американский B2B SaaS-клиент, похожий по профилю на BrainCert — с двумя недавними многочасовыми инцидентами и корпоративным заказчиком, который угрожал применить пункт о компенсациях по SLA. У них был настроен Sentry, но отсутствовали SLO и бюджеты ошибок; вся инфраструктура работала в одном регионе AWS. Среднее время восстановления составляло 6 часов.

Наш план на четыре недели: определить SLO в 99,95% доступности и p95 задержки ниже 350 мс для 99% запросов; настроить инструментирование каждого эндпоинта через OpenTelemetry; направлять данные в Honeycomb с алертами по скорости расхода SLO; добавить три circuit breaker для внешних API, которые стали причиной обоих инцидентов; внедрить поэтапный релиз с использованием фича-флагов в GrowthBook. На финальной неделе — два учения по хаосу: имитация отказа основной базы данных и сбоя сервиса аутентификации, с обязательным составлением письменного runbook.

Результат за 60 дней: MTTR снизился с 6 часов до 22 минут, доля провальных изменений — с 31% до 12% (с уровня «высокий» до «элитный» по DORA), клиентских инцидентов не было. Корпоративный заказчик продлил контракт. Инженерные затраты составили 2,5 человеко-месяца за 4 календарные недели. Агентная инженерия позволила использовать 40% дашбордов Honeycomb из предыдущих клиентских проектов повторно.

Пять ловушек надёжности, которые мы видим в аудитах каждую неделю

1. SLO без принуждения. SLO размещён на странице вики; в пайплайне деплоя его никто не проверяет; релизы не блокируются, даже если бюджет исчерпан. Решение: алерты по скорости сжигания бюджета, которые будят дежурного, и правило-блокер релиза, встроенное в шлюз CI.

2. Ретраи без задержки. Три ретрая подряд превращают один неудачный запрос в четыре попытки. Добавьте экспоненциальную задержку и джиттер, а также ограничьте общее количество попыток.

3. Health-проверки, которые врут. Эндпоинт /healthz возвращает 200, даже если база данных недоступна. Балансировщик продолжает направлять трафик. Решение: использовать глубокие health-проверки, которые тестируют критичные зависимости и показывают реальную степень деградации.

4. Бэкапы, которые никогда не проверялись. Бэкапы базы данных создаются каждый день, но восстановление никто не тестировал. Первую попытку провести восстановление делают только во время реального сбоя. Решение: ежемесячно автоматически восстанавливать данные в песочницу и проверять контрольную сумму.

5. Силосы знаний на одного человека. «Как работает платёжный сервис, знает только Аня». Аня в отпуске. Решение: парные дежурства, письменные сценарии runbook для каждого сервиса и чёткая цель по ротации знаний в OKR.

KPI: что измерять, начав укреплять систему

KPI качества. Соответствие SLO по каждому сервису (цель — 100% в течение 30 дней), задержка на 99-м перцентиле, доля ошибок и доля пользователей без сбоев на мобильных клиентах (цель — выше 99,5%).

Бизнес-метрики. Количество инцидентов от клиентов в месяц (цель — менее одного), отток из-за жалоб на надёжность и выплаты по SLA (цель — 0 ₽).

KPI надёжности. Доля неудачных изменений (цель — ниже 15%), MTTR (цель — ниже 60 минут), MTTD (цель — ниже 5 минут), частота деплоев (цель — несколько раз в неделю).

Фреймворк решения — сколько вкладывать в надёжность, в пяти вопросах

В1. Сколько стоит один час простоя в выручке? Ориентируйтесь на эту цифру при принятии решений по надёжности. Если меньше 375 тыс. ₽ — ограничьтесь базовым набором (SLO, наблюдаемость, бэкапы). Если больше 3,7 млн ₽ — включайте полный набор паттернов, включая chaos engineering и multi-region.

В2. Регулируемая ли у вас отрасль? HIPAA, PCI, SOC 2, GDPR предъявляют свои минимальные требования к надёжности. Доступность ниже 99,9% сразу вызывает замечания при аудите. Учитывайте эти требования при установке SLO с самого начала.

В3. Вы релизите ежедневно, еженедельно или раз в месяц? Чем чаще релизы — тем больше нужны поэтапный запуск и фича-флаги. При месячном ритме можно обойтись canary-деплоями, а при ежедневных — нужна полноценная система флагов, как у LaunchDarkly.

В4. От скольких внешних API вы зависите? Каждый из них — потенциальный источник сбоя. Оборачивайте каждый в circuit breaker, ограничивайте количество попыток повторных запросов, кэшируйте ответы, если требования к актуальности данных это позволяют.

В5. Кто сегодня носит пейджер? Если ответ «основатель» или «все», вам нужны ротации и инструменты. Проблемы людей не решаются ещё одним дашбордом.

Когда НЕ нужно переинвестировать в надёжность

Три случая, когда стоимость устойчивости превышает её ценность. Первый — стартапы до product-market fit, с числом активных пользователей меньше 100: SLO бессмысленны, пока вы не понимаете, что вообще строите. Поднимите CI, базовое логирование и Sentry — всё остальное отложите.

Второй — внутренние инструменты для 50 сотрудников и меньше с допустимым окном простоя. Multi-region для внутреннего HR-портала — перебор. Бюджет на отказоустойчивость стоит выделять только тогда, когда инструмент становится критически важным для бизнеса.

Третий — продукты в реальном MVP-режиме, где каждый час на надёжность конкурирует с часом на фичи, которые просит рынок. Поставьте жёсткий лимит на задачи по надёжности (10–20% мощности команды) до достижения product-market fit и пересматривайте его на каждом раунде инвестиций.

Смежные темы, которые стоит прочитать

Надёжность не возникает сама по себе. Три смежные области требуют внимания.

QA-тестирование — это верхний слой профилактики. В нашем гайде о важности QA-тестирования в разработке мы разбираем пирамиду тестов, контрактные тесты и стратегии shift-left.

Планирование бюджета важно, потому что надёжность стоит денег. В нашем гайде по стоимости разработки мобильных приложений 2025 мы показываем, как бюджет на надёжность вписывается в P&L типичного продукта.

Build- vs buy полностью меняет разговор о надёжности. Наш материал о low-code/ no-code и найме разработчиков — хорошая отправная точка, если вы ещё выбираете модель команды.

FAQ

Какой SLO по доступности взять на старте SaaS?

99,9% (43,8 минуты простоя в месяц) — стандарт для ранних SaaS-проектов. Уровень до 99,95% (21,6 минуты в месяц) обычно устанавливают, когда появляются корпоративные клиенты; до 99,99% (4,4 минуты в месяц) — только если вы работаете в финансах, здравоохранении или у вас есть чёткое контрактное требование. Обещать 99,99% без отработанной практики хаотичных нагрузок — больший репутационный риск, чем указать более скромный SLO.

Стоит ли использовать микросервисы ради надёжности?

Микросервисы обеспечивают изоляцию на сетевом уровне, но при этом усложняют систему и вводят новые режимы сбоев — например, сетевые вызовы, распределённую трассировку и eventual consistency. Для большинства продуктов с командой до 50 инженеров хорошо спроектированный модульный монолит с внутренними механизмами изоляции (отдельные пулы потоков, библиотеки circuit breaker) оказывается надёжнее, чем преждевременный переход на микросервисы.

Сколько закладывать на работу по надёжности?

Распространённая эвристика из Google SRE — 50% времени SRE тратится на проекты по надёжности (остальное — рутина и дежурства). Для продуктовых инженерных команд без выделенных SRE 15–20% мощности — реалистичная долгосрочная цифра. После крупного инцидента можно временно увеличить долю до 40–50% на один-два спринта и устранить конкретный режим отказа.

Нужен ли chaos engineering с первого дня?

Нет. Chaos engineering окупается только тогда, когда уже есть наблюдаемость, система оповещений, сценарии действий (runbook) и зрелая культура дежурств. Без этого эксперименты с хаосом вызывают панику, а не полезные выводы. Данные ThoughtWorks показывают: практика действительно связана с элитной надёжностью, только если она строится на основе зрелых SRE-практик.

Какой стек наблюдаемости выбрать в 2026?

С первого дня отправляйте данные в формате OpenTelemetry. Коллектор уже направляет их в подходящий бэкенд в зависимости от стадии: Sentry — для раннего отслеживания ошибок, Honeycomb или Datadog — для полноценной наблюдаемости на масштабе, Grafana Cloud — если нужен контролируемый self-host. Главное — использовать инструментарий OpenTelemetry, а не привязываться к конкретному вендору. Выбор поставщика — обратимое решение.

Чем фича-флаги улучшают надёжность?

Фича-флаги позволяют выпустить код «вслепую» — развернуть его на 1% пользователей, посмотреть метрики и либо продолжить до 100%, либо отключить фичу за секунды. Они делают деплой обратимой операцией — и это самое большое улучшение, которое большинство команд может применить, чтобы снизить долю провальных изменений. Популярные варианты: LaunchDarkly, GrowthBook (open source) и Unleash (open source).

Какая самая частая причина крупных сбоев в 2025–2026?

Сбои, вызванные деплоями — с большим отрывом. Публичные базы постмортемов и DORA 2024 ставят долю провальных изменений на первое место среди факторов надёжности. Самый громкий пример — инцидент CrowdStrike: конфигурация была изменена без поэтапного внедрения и вывела из строя security-продукт по всему миру.

Сколько обычно занимает работа по укреплению надёжности?

Сфокусированный двухнедельный спринт даёт SLO, наблюдаемость, базовые circuit breaker и письменный runbook. Полноценное укрепление (chaos-учения, multi-region, DR-учения) обычно занимает 6–8 недель. Наша агентная инженерия сжимает типичный график. Чтобы оценить объём для вашей кодовой базы, обычно достаточно 30-минутного звонка.

Что почитать дальше

Готовы выпускать продукты, которым пользователи могут доверять?

Отказоустойчивое ПО — это не «да или нет», а вопрос бюджета. Выберите SLO, настройте сбор метрик через OpenTelemetry, добавьте circuit breaker и bulkhead, выпускайте изменения под фича-флагами с постепенным развёртыванием и проводите безвиновные постмортемы, если что-то пойдёт не так. Набор подходов уже известен; работа здесь — рутинная, а не героическая.

Если хотите второе мнение по своему стеку или команду, которая внедрила эти паттерны в 50+ real-time продуктах за два десятилетия, — мы всего в одном звонке от вас.