Как создавать надёжное, отказоустойчивое ПО в 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) — это метрика, которую вы измеряете: процент доступности, p99 задержки, доля ошибок. Service Level Objective (SLO) — целевое значение этой метрики на интервале: «99,95% запросов отвечают быстрее 250 мс на горизонте 30 дней». Service Level Agreement (SLA) — то, что вы по договору должны клиенту, если SLO не выполнен, обычно компенсация. Бюджет ошибок — это разница: SLO в 99,95% даёт вам 21,6 минуты допустимого простоя в месяц.

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

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

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

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

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

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

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

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

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

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

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

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

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

8. Дрейф конфигурации. Флаг выставлен на одном сервере, забыт на другом; в staging работает, в production взрывается. Решение: GitOps, infrastructure-as-code, линтинг конфигурации в 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%), чтобы разнести толпу во времени. Ограничьте 5 попытками и общим лимитом в 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, а не на сырые пороги. Один этот сдвиг даёт большинству команд самое большое улучшение в борьбе с alert fatigue.

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

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

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

Для 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 молча понижает приложение в выдаче. Лечится почти всегда тем, что фоновая работа уехала на main thread: рекомпозиции 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.

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

Матрица 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. Учения по восстановлению после катастроф. Раз в квартал. Восстановите из бэкапа, переключитесь на резервный регион, убейте основную базу данных. Непротестированный DR — это теоретический DR.

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. Финальная неделя — два chaos-учения (убить основную базу, убить сервис аутентификации) с письменным 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 дней), p99 задержки, доля ошибок и crash-free user rate на мобильных клиентах (цель — выше 99,5%).

Бизнес-KPI. Число клиентских инцидентов в месяц (цель — меньше одного), отток, связанный с жалобами на надёжность, и выплаты по 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% без выращенной chaos-практики — больший репутационный риск, чем заявить более скромный SLO.

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

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

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

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

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

Нет. Chaos engineering окупается после того, как у вас есть наблюдаемость, алертинг, runbook-сценарии и здоровая on-call культура. Без этого chaos-учения порождают панику, а не выводы. Данные 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 продуктах за два десятилетия, — мы в одном звонке от вас.