Platform health нельзя измерить только observability. Ключ — developer experience и реальное принятие платформы.
Проблема проявляется не сразу. Платформа может выглядеть стабильной: метрики зелёные, (uptime) высокий, алерты под контролем. Но в какой-то момент команды начинают обходить её. Появляются кастомные скрипты, ручные процессы и “теневые” workflow. Это классический сигнал ghost town platform: система технически здорова, но не используется. Observability отвечает на вопрос “что сломалось”, но не отвечает “почему этим не пользуются”. Здесь начинается расхождение между доступностью и реальной ценностью.
Решение упирается в смену модели оценки. Platform health — это не availability, а utility. Ключевой сигнал — adoption, а не usage. Usage можно навязать через ограничения. Adoption нужно заслужить. Если разработчики выбирают “золотой путь” (golden path), значит он быстрее и безопаснее альтернатив. Метрики смещаются: onboarding time, self-service rate, органическое подключение команд. При этом важно учитывать trade-off: высокая adoption не гарантирует удовлетворённость. Если инструмент используют “потому что заставили”, это скрытая деградация.
Реализация требует добавить в систему измерений человеческий слой. Технические метрики дополняются обратной связью. Простейший инструмент — регулярный developer NPS с открытым текстовым полем. Именно там выявляются узкие места: повторяющиеся ручные шаги, неочевидные ошибки, неэффективные сценарии. Отдельный акцент — на feedback loops. Исследования DORA показывают: ключевой фактор developer experience — ясная обратная связь о результате действий. Не сложность tooling, а предсказуемость системы. Если платформа оставляет инженера в неопределённости при сбое, это проблема архитектуры взаимодействия, а не только reliability.
Надёжность при этом не исчезает, но меняет форму. (Uptime) становится базовым уровнем, а не целью. Важнее поведение системы при сбоях. Mean Time to Recovery (MTTR) и change failure rate начинают отражать реальный опыт. SLO также смещаются: не “99.9% доступности”, а “99% деплоев проходят с первого раза”. Это переводит reliability в плоскость developer experience. Дополнительно появляется ещё один сильный сигнал — toil. Ручная работа, которая масштабируется с ростом, напрямую снижает throughput. Если платформа здорова, она системно поглощает toil.
Результаты таких изменений измеряются иначе. Если нет данных — это уже сигнал незрелости платформы. Но при наличии метрик картина становится управляемой. Снижение onboarding time, рост self-service, уменьшение доли toil — это показатели, которые можно связать с бизнес-эффектом. DORA-метрики, такие как lead time for changes и deployment frequency, дополняют картину скорости. В совокупности это формирует язык для диалога с бизнесом, а не только инженерный статус.
Финальный сдвиг — организационный. Платформа становится продуктом. Это означает roadmap на основе developer feedback, регулярные health-отчёты и явную ответственность за улучшение developer experience. Без этого платформа остаётся инфраструктурным проектом без доказуемой ценности. И в таких условиях инициативы часто теряют финансирование, потому что observability сама по себе не объясняет “so what”.