Модель здоровья продукта¶

Понедельник, 11:00. Продукт-менеджер говорит: «Всё отлично — MAU растёт, конверсия в платёж выросла на 5%». Разработчик хмурится: «p99 latency скакнул до трёх секунд после вчерашнего релиза». Инженер поддержки добавляет: «Клиенты жалуются, что биллинг тормозит уже третью неделю».

Кто из них прав? Все трое. И в этом беда. У каждого своя правда о продукте, потому что каждый смотрит на него через свои метрики. Единой картины нет, а значит нет и единого понимания, стоит ли бить тревогу или можно допивать кофе.

Модель здоровья продукта (Health Model) это попытка собрать одну картину вместо трёх.

Что такое модель здоровья¶

Модель здоровья это небольшой, тщательно отобранный набор сигналов (обычно 5–10), которые дают однозначный ответ на вопрос: «Как дела у продукта прямо сейчас?»

Это не «ещё один дашборд с сотней графиков». Это система приоритетов. Вы договариваетесь с командой: вот эти пять индикаторов — главные. Если они зелёные — мы в порядке, даже если где-то в глубине что-то шумит. Если красные — мы останавливаемся и разбираемся, даже если «вроде всё работает».

Модель здоровья отличается от SLO-дашборда уровнем абстракции. SLO-дашборд — это приборная панель технаря: десятки чисел, графиков, перцентилей. Он отвечает на вопрос «что именно и где болит?». Модель здоровья — это приборная панель капитана: пять ключевых индикаторов и общий вердикт. Она отвечает на вопрос «стоит ли паниковать?».

Представьте кабину современного авиалайнера. Там сотни переключателей, циферблатов и экранов. Но у пилота перед глазами Primary Flight Display — шесть ключевых параметров: высота, скорость, крен, тангаж, курс, вертикальная скорость. Именно по ним пилот понимает, летит самолёт или падает. Всё остальное — для диагностики, когда что-то пошло не так.

Модель здоровья продукта — это наш Primary Flight Display.

Четыре слоя модели здоровья¶

Любой продукт можно рассматривать на четырёх уровнях, и модель здоровья должна покрывать их все. Если вы смотрите только на инфраструктуру, вы пропустите проблему с биллингом. Если только на бизнес-метрики — узнаете о сбое, когда клиенты уже ушли.

Бизнес-метрики — видят руководители и продукт. Выручка, активные пользователи, конверсия. Они не технические, но без них модель неполная: можно иметь идеальный uptime, но терять деньги.

Пользовательский опыт — видят клиенты. Время загрузки страницы, успешность оформления заказа, частота ошибок. Это ваши SLI и SLO, именно здесь модель здоровья пересекается с SLO и Error Budget.

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

Инфраструктура — видят дежурные. CPU, память, диск, сеть. Важно, но недостаточно: инфраструктура может быть идеальной, а продукт — мёртвым (упал код, а не сервер).

Для каждого слоя вы выбираете 1–3 ключевых сигнала. В сумме получается 5–10. Всё, что больше, — уже не модель здоровья, а технический дашборд.

Три цвета, по которым живёт компания¶

Модель здоровья оперирует тремя состояниями:

🟢 Здоров:   SLO соблюдаются, Error Budget не тает, пользователи довольны
🟡 Болеет:   SLO нарушается, запас Error Budget тает, продукт работает,
             но хуже, чем мог бы
🔴 Критичен: Error Budget исчерпан, продукт не выполняет свои функции

Зелёный значит «живём как обычно — релизим, пилим фичи, спим спокойно». Жёлтый значит «смотрим, разбираемся, планируем исправление, но не останавливаем релизы». Красный значит «остановка: Error Budget на нуле, все силы на восстановление».

Важно: красный — это не «уволить дежурного». Это системный сигнал, что продукт требует немедленного внимания. Точно как красная лампочка давления масла в машине: вы не ищете, кого наказать, вы глушите двигатель и смотрите, что случилось.

Как построить модель здоровья: пошаговая инструкция¶

Шаг 1: Определите 3–5 ключевых пользовательских сценариев¶

Не «все функции, которые есть в продукте», а именно те, без которых продукт теряет смысл. Для облачного провайдера это «создать ВМ», «зайти на ВМ по SSH», «оплатить счёт». Для интернет-магазина «найти товар», «добавить в корзину», «оплатить заказ».

Шаг 2: Для каждого сценария — SLI и SLO¶

Каждый сценарий должен быть измерим. Измеряем latency, success rate, throughput. Ставим целевые SLO. Не ниже, чем принято в книжке про SLO — но и не выше, чем реально нужно бизнесу.

Шаг 3: Расставьте веса¶

Не все сценарии одинаково важны. Оплата товара важнее, чем просмотр истории заказов. Расставьте веса от 1 до 5, где 5 — критично для бизнеса.

Health Score = sum(вес_i × SLO_выполнение_i) / sum(вес_i)

Шаг 4: Определите пороги¶

• Health Score ≥ 95% → 🟢 Здоров
• 90% ≤ Health Score < 95% → 🟡 Болеет
• Health Score < 90% → 🔴 Критичен

Числа — для примера. В вашем продукте пороги могут быть другими. Главное, чтобы они были согласованы с бизнесом, а не придуманы инженерами в пятницу вечером.

Шаг 5: Настройте алертинг¶

Зелёный — не алертим, живём. Жёлтый — шлём предупреждение в общий чат. Красный — эскалация дежурному, блокировка релизов, созыв команды.

Пример: модель здоровья облачного провайдера¶

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

Health Score = (5×99,5 + 5×99,9 + 4×99,9 + 5×99,5 + 3×99) / (5+5+4+5+3) = 99,6% → 🟢

Даже если CPU на хостах загружен на 90%, но сценарии работают — модель зелёная. Потому что сейчас это шум, а не проблема для клиента.

Другой месяц: Health Score упал до 89% из-за проблем с биллингом и медленного создания ВМ. Система автоматически остановила некритичные релизы и собрала экстренный митинг. Команда не гадает «а что случилось?» — она знает, что делать.

Модель здоровья и Error Budget¶

Модель здоровья — это не про «посчитать девятки». Это про принятие решений. Когда вы видите, что Health Score ушёл в жёлтую зону, вы не сидите и не гадаете, что делать. У вас есть протокол:

Главное отличие от просто SLO-дашборда: модель здоровья даёт контекст. SLO-дашборд знает, что p99 latency вырос. Модель здоровья знает, что это влияние на ключевой сценарий «Оплата» — и это важнее, чем рост latency на странице «Сменить аватар».

Антипаттерны¶

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

Модель без SLO. Если у вас нет целевых показателей, вы не можете определить, здоров продукт или болен. Это как смотреть на термометр без шкалы и гадать, нормальная ли температура.

Мёртвая модель. Определили раз и забыли на год. А продукт изменился: появились новые сценарии, старые ушли. Модель здоровья должна пересматриваться с каждым значительным изменением продукта. Хотя бы раз в квартал задавайте вопрос: «Эти пять сценариев — действительно самое важное в нашем продукте сегодня?»

Health Score как KPI для премии. Как только вы привяжете Health Score к бонусам, команды начнут его оптимизировать, а не заниматься продуктом. Модель здоровья — это приборная панель, а не система мотивации.

Резюме¶

Модель здоровья продукта — это договорённость. Договорённость о том, по каким простым и понятным признакам вы вместе будете судить о самочувствии продукта. Это единый источник правды для продукта, разработки и эксплуатации.

Вы не можете управлять продуктом, если у вас нет единого ответа на вопрос «как дела?». Даже если у вас лучший мониторинг в мире, даже если вы настроили SLO для каждого эндпоинта — без модели здоровья вы будете тонуть в зелёных дашбордах, пропуская красные сигналы.

Модель здоровья — это пять ключевых сценариев, три цвета, один экран.