Куда пропали 14 млрд рынка observability?

Сразу честно: я основатель Monq, российского разработчика observability-платформы. Поэтому у меня есть очевидный конфликт ^[1] интересов. Но есть и полезный побочный эффект: последние годы я регулярно вижу один и тот же архитектурный спор с обеих сторон — и как инженер, и как человек, который считает экономику продукта, попробую в этой статье оценить эффекты выбора .

Сразу неприятный тезис.

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

Инженерия вообще-то является экономикой под ограничениями, а не олимпиадой «кто быстрее соберёт свой Datadog из GitHub». Если банк, завод или ретейлер не продаёт observability, его внутренняя платформа должна пройти тот же инвестиционный комитет, что и любой новый продукт: заказчик, владелец, бюджет на пять лет, SLO, измеримый эффект, риски и критерий прекращения разработки.

Почему-то к мониторингу это правило применяют редко.

Есть фраза, которую я слышу на встречах чаще, чем хотелось бы:

«Зачем нам вендор? У нас уже есть observability-платформа на Prometheus и Grafana».

Обычно её произносит сильный инженер. За его спиной — несколько кластеров, тысячи таргетов, десятки дашбордов, Alertmanager, Loki или ELK, немного VictoriaMetrics, где-то сбоку Jaeger, пара самописных интеграций, а в углу тихо плачет CMDB, с которой это хозяйство так и не подружилось.

Я не иронизирую над качеством такой работы. Часто всё сделано блестяще. Именно поэтому спор сложнее, чем «open source плохой, вендор хороший».

Для крупнейшего бигтеха внутренняя observability-платформа может быть стратегически оправданной. На масштабе Ozon, Яндекса, VK, крупного банка или телекома экономика телеметрии, управление кардинальностью, интеграция с developer platform и скорость изменений сами становятся конкурентным преимуществом. Там самосбор действительно может победить.

Предмет этой статьи — не критика самосбора как такового. Предмет статьи — критика выбора самосбора по религиозным соображениям.

Что именно мы называем observability

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

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

• инструментацию и сбор метрик, логов и трассировок;

• транспорт, хранение, ретенцию и управление кардинальностью;

• запросы, дашборды, APM, RUM и профилирование;

• события, инциденты, дедупликацию, runbooks и автоматизацию;

• сервисный и бизнес-контекст, SLI, SLO и SLA.

OpenTelemetry стандартизирует генерацию, сбор и экспорт телеметрии, но не является backend-платформой. Prometheus прекрасно решает значительную часть задачи метрик. Grafana великолепно визуализирует данные. Но три сильных компонента не превращаются в промышленную операционную модель от одного факта совместной установки.

PostgreSQL, React и Kafka сами по себе тоже не становятся интернет-банком.

Это принципиальная разница: компонент — ещё не продукт, а стек — ещё не платформа.

Как после 2022 года изменился выбор

До 2022 года крупный российский заказчик мог строить мониторинг вокруг IBM Netcool и Instana, Micro Focus Operations Bridge, Cisco AppDynamics, Splunk, Dynatrace, New Relic и других зрелых платформ. Затем прямые продажи, поддержка и предсказуемое продление для многих решений исчезли или стали сложнее.

Российским разработчикам досталось редкое окно возможностей. Одновременно крупные компании ускорили внутренний самосбор: бизнесу нельзя было ждать, пока рынок созреет.

Прошло четыре года. Российский рынок уже не пуст, но привычка строить всё внутри никуда не исчезла.

Шесть миллиардов на витрине и двадцать — в разговорах

Если сложить опубликованные в обзоре TAdviser ^[2] показатели пятнадцати участников российского рынка систем мониторинга и управления ИТ-инфраструктурой за 2025 год, получится около 6,16 млрд рублей. В том же материале верхняя экспертная оценка широкого рынка без ITAM и ITSM — около 20 млрд рублей.

Это разные периметры. 6,16 млрд — видимые показатели поставщиков из выборки (весьма сомнительной, кстати, так как половинарынка туда не попала, а попали поставщики неванильных куберов). 20 млрд — широкая экспертная оценка того, сколько экономика может тратить на лицензии, внедрение, интеграцию, инфраструктуру, поддержку и внутреннюю разработку observability платформ. С этой оценкой я в целом соглашусь, если туда включить и инфраструктурный мониторинг, и observability, и aiops, и зонтичный мониторинг.

Но арифметический вопрос всё равно красивый: если на витрине 6,16 млрд, где остальные 13,84 млрд?

Красивый ответ для Telegram: «всё ушло в Prometheus, Grafana и зарплаты самописцев». Но это, конечно, не так.

13,84 млрд рублей — не «сгоревшие деньги» и не выручка open source. Это слепая зона между двумя оценками с разной методологией. Я буду называть её тёмной материей рынка: мы не видим её напрямую, но можем разложить возможный состав и проверить порядок величины.

Что может находиться в тёмной материи

• выручка российских вендоров, не попавших в рейтинг;

• иностранное legacy, которое продолжает жить в контурах;

• услуги интеграторов, дистрибьюторов и внешней поддержки;

• серверы, хранение, резервирование и каналы;

• внутренние платформенные команды и стоимость эксплуатации.

Я не знаю, какая доля приходится на каждый пункт. Судя по открытым данным, этого точно не знает никто. Поэтому честнее не объявлять все 13,84 млрд самосбором, а построить сценарии: что будет, если на внутреннюю разработку приходится 25%, 50% или, в качестве намеренно экстремального предела, 100% разрыва. Не думаю, что на самосборе менее 25% рынка, по нашим оценкам явно больше.

Санитарная проверка мировым рынком

Оценки мирового рынка observability расходятся в несколько раз: аналитики считают разные наборы продуктов и услуг. Если механически умножить опубликованный диапазон мировых оценок на долю России в мировых ИТ-расходах, получается порядок примерно 1,6–7,6 млрд рублей.

Это не прогноз. Это проверка масштаба. И она подсказывает довольно логичную конструкцию: около 6 млрд могут быть рынком собственно отечественных продуктов, а 20 млрд — более широким экономическим контуром со всеми услугами, инфраструктурой и внутренними командами.

Сколько стоит один внутренний вендор

Возьмём нижнюю границу, без желания напугать финансового директора. По данным Хабр Карьеры ^[3], ориентир для DevOps-инженера — около 240 тыс. рублей в месяц. Команда из трёх-пяти специалистов — 8,64–14,4 млн рублей зарплатного фонда в год. За пять лет — 43,2–72 млн рублей без индексации.

Добавим только 25% на страховые взносы, оборудование, управление и прочие расходы работодателя — намеренно скромно. Получаем 10,8–18 млн рублей в год, или 54–90 млн рублей за пять лет. Хранилище, резервная площадка, миграции и цена ошибок сюда ещё не вошли.

Отдельная оговорка про 24×7. Google SRE ^[4] выводит восемь инженеров как минимум для single-site-команды с двумя параллельными ротациями primary/secondary и ограничением on-call 25% рабочего времени. Это не означает, что любая observability-платформа требует отдельную команду из восьми человек. Общую смену можно разделять с соседними подразделениями и сервисами. Но если в TCO заявлена полноценная собственная поддержка 24×7, покажите, кто фактически несёт эту нагрузку.

Теперь посмотрим не на точную оценку страны, которой у нас нет, а на масштаб трёх сценариев.

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

Внутренний вендор, которого нет в оргструктуре

Типичная история начинается совершенно правильно. Команде нужен мониторинг Kubernetes. Инженер ставит kube-prometheus-stack. За несколько дней появляются метрики и красивые дашборды. Лицензия — ноль рублей, запуск быстрый, руководство довольно.

Через полгода выясняется, что нужно:

• разделить доступ между командами и контурами;

• обеспечить отказоустойчивость и длинную ретенцию;

• победить кардинальность и нормализовать теги;

• собирать логи и трассировки;

• обновлять десятки компонентов без потери данных;

• закрывать CVE и вести SBOM;

• дедуплицировать события и связать их с сервисами;

• интегрироваться с ITSM, CMDB, телефонией и мессенджерами;

• передать знания человеку, который не писал первые пять тысяч строк конфигурации.

Поздравляю. Вы больше не «поставили Prometheus». Вы открыли внутри компании разработчика observability-платформы на базе иностранного open source.

Только у этого разработчика часто нет продуктового владельца, отдельной экономики, roadmap, обязательств по совместимости и плана прекращения разработки. Приоритеты определяет последний громкий инцидент, а себестоимость растворяется между зарплатами, инфраструктурой и временем команд-пользователей.

Самое забавное, что backlog у таких «уникальных» продуктов почти одинаковый: HA, ретенция, мультитенантность, RBAC, аудит, резервное копирование, обновления, нормализация тегов, дедупликация, ITSM, сервисная модель, документация. Через два года — «давайте прикрутим AI».

На этом месте обычно звучит: «Зато мы контролируем код».

Формально — да. Практически компания контролирует набор репозиториев, Helm charts, конфигураций и неявных знаний. Настоящий контроль начинается со способности предсказуемо изменить систему, проверить результат, откатиться и передать ответственность. Ссылка на репозиторий сама по себе такой способности не даёт.

Тест для CTO простой. Если внутренняя платформа — продукт, покажите полный бюджет и экономику. Если этого нет, перед нами не стратегия суверенной импортонезависимости. Перед нами инженерная инициатива, которую бухгалтерия по ошибке ^[5] считает обычной эксплуатацией, а по факту это частично экономические потери.

«Но у нас уникальная инфраструктура»

Конечно.

В России удивительно много уникального: уникальные банки, уникальные заводы, уникальные ритейлеры, уникальные сервера, уникальные СУБД, ОС и особенно уникальные интеграции с 1С.

Действительно уникальные требования существуют. Но полезно отделять уникальность бизнеса от повторяемой платформенной механики. Рабочая гипотеза для пилота — не статистика рынка, а именно гипотеза — может выглядеть так: 20–30% требований действительно специфичны для заказчика, а 70–80% повторяются.

Обычно уникальны:

• модель сервисов и бизнес-контекст;

• специфические источники данных;

• правила приоритизации и реакции ^[6];

• несколько критичных интеграций;

• требования конкретного закрытого контура.

А хранение, права, аудит, алертинг, обновления, дедупликация, резервирование, типовые коннекторы и управление конфигурацией повторяются от компании к компании.

Когда самосбор действительно рационален

У собственного продукта есть сильные случаи применения. Самосбор может победить, если:

• объём телеметрии или объектов делает лицензионную модель вендора экономически абсурдной;

• observability глубоко встроен во внутреннюю разработку;

• платформенная команда уже существует и обслуживает сотни команд;

• скорость изменения backend и ingestion pipeline критична для бизнеса;

• внутренняя технология сама является конкурентным преимуществом;

• компания готова финансировать продукт, а не временный проект.

Это нормальная стратегия. Но тогда внутренняя команда должна честно называться платформенной продуктовой командой, а не «несколькими DevOps, которые ещё поддерживают Grafana».

Когда вендорский выбор рационален

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

И чаще всего разумный ответ — гибрид:

• открытая инструментация и протоколы для переносимости;

• Prometheus, OpenTelemetry и другие компоненты там, где они сильны;

• готовая платформа для повторяемых функций и промышленной эксплуатации;

• свой код только для действительно уникальной логики.

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

Open source здесь ни при чём

Важно не перепутать объект критики.

OpenTelemetry ^[7] снижает стоимость смены backend и унифицирует инструментацию. Prometheus стал фактическим стандартом cloud-native-метрик. Grafana дала отрасли удобный путь от данных к визуализации. Критиковать инженера за использование этих проектов было бы примерно так же неразумно, как бороться с PostgreSQL или Linux.

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

Grafana Labs в Observability Survey 2026 ^[8] получила 1 363 ответа от своего сообщества и участников отраслевых мероприятий. Выборка вендорская, переносить её на весь рынок нельзя. Но внутри неё хорошо виден конфликт:

• 77% считают open source и открытые стандарты важными для observability-стратегии;

• 50,8% работают преимущественно или полностью на self-managed-модели;

• 38% называют сложность и операционную нагрузку главной проблемой;

• 76,7% уже экономили время или деньги благодаря централизации observability.

Open source побеждает — и одновременно его сложность заставляет компании централизовать управление. Никакого парадокса ^[9] нет. Открытые сенсоры и протоколы прекрасно совместимы с тиражируемой платформой.

Внешний вендор тоже должен сдать экзамен

До сих пор я предъявлял требования внутренней команде. Было бы нечестно автоматически выдать зрелость готовому продукту только за наличие отдела продаж.

Вендор должен доказать:

• подтверждённый масштаб сбора, запросов и кардинальности;

• SLO самой платформы, RPO/RTO и сценарии восстановления;

• обновление и откат без потери данных;

• прозрачную лицензионную метрику и пятилетний TCO;

• SBOM, сроки устранения CVE и безопасную разработку;

• открытые форматы, экспорт данных и понятную цену выхода;

• реальные сроки реакции поддержки;

• референсы на сопоставимом масштабе;

• финансовую устойчивость и способность выполнять roadmap.

Сильная формула звучит симметрично: внутренняя команда должна доказать, что способна быть вендором. Внешний вендор должен доказать, что он лучше стратегии “собрать на open source”. Кажется, это честно.

Российский рынок не пуст

Исследование TeDo «Созвездие Observability 2025» ^[10] рассмотрело девять российских систем. Более широкий периметр TAdviser ^[2] включает пятнадцать участников. Если добавить соседние сегменты, получается не один «правильный импортозаместитель», а несколько инженерных школ: cloud-native, APM и телеметрия, зонтичный мониторинг и AIOps, инфраструктура, сети и SLA.

Ниже — не рейтинг и не магический квадрант домашнего приготовления. Это грубая карта публичного позиционирования, которая нужна только для одного вывода: в России есть из чего собирать.

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

Почему российские платформы редко попадают в инженерный шортлист

Причина не только в снобизме заказчика. Российские вендоры сами много лет приучали рынок к недоверию:

• мало публичных бенчмарков;

• непрозрачные цены и лицензионные метрики;

• слабая документация;

• недостаток референсов на экстремальном масштабе;

• неочевидная цена выхода и страх ^[12] привязки;

• обещания, которые не исполняются;

• маркетинг, обещающий AI раньше, чем продукт научился нормально обновляться.

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

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

Откуда берётся самосборное мышление

Есть ещё одна причина, почему самосбор кажется вариантом «по умолчанию». Большинство инженерных курсов совершенно правильно учат развернуть Prometheus, подключить exporters, собрать Grafana, добавить Alertmanager, логи и трассировки.

Специалист обязан пройти этот путь руками. Невозможно хорошо выбрать платформу, не понимая её механики.

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

Возьмём два публичных примера, но их много, все устроены одинаково.

В актуальной программе OTUS ^[13] есть SLI/SLO/SLA, error budget, OpenTelemetry и обзор инструментов. Это важное уточнение: курс нельзя честно описывать как одну лишь ведомость компонентов.

Но курс всё равно решает прежде всего образовательную задачу — учит инженерной механике. Он не обязан заменять procurement-проект компании. Ошибка возникает позже, когда владение Prometheus, Thanos, VictoriaMetrics, ELK, Loki и Tempo автоматически принимают за доказательство оптимальности собственного промышленного стека.

Слёрм: честный курс про Kubernetes, а не инвестиционный комитет

Слёрм прямо учит мониторингу и логированию Kubernetes: Prometheus, Grafana, VictoriaMetrics, алертинг, эксплуатация. Требовать от него полного make-or-buy-анализа корпоративной observability-платформы было бы странно.

Но образовательная драматургия та же: детали установлены, дашборд открылся, алерт пришёл — значит, «система построена». В лаборатории этого достаточно. В промышленном контуре после этого только начинаются ретенция, отказоустойчивость, права, обновления, on-call, безопасность и экономика.

Рис. 5. Публичная программа Слёрма на момент подготовки исходного материала

Я не предлагаю превратить инженерные курсы в каталог Monq, wiSLA или Пульт. Это была бы та же ошибка, только с российским логотипом.

Но в обучении ^[14] архитекторов и руководителей полезно добавить один обязательный модуль: сравнить самосбор, вендора и гибрид на одинаковом пятилетнем горизонте. Не по вере и не по красоте дашборда, а по измеримым параметрам.

Чек-лист, который стоит положить на стол до решения

• Экономика телеметрии. Сколько стоят 1 млн samples, 1 млн spans и 1 ГБ логов с нужной ретенцией?

• Производительность. Каковы ingest rate, p95/p99 запросов и допустимая кардинальность на вашем контуре?

• Надёжность. Какой SLO у самой платформы, сколько данных она может потерять, каковы RPO/RTO?

• Эксплуатация. Сколько нужно FTE, ручных операций и аварийных обновлений?

• Пользовательский эффект. Сколько занимает подключение нового сервиса? Снижаются ли MTTD, MTTA и MTTR? Растёт ли точность алертов?

• Изменяемость. Как быстро добавить новый источник, интеграцию, правило бизнеса или класс телеметрии?

• Lock‑in. Можно ли экспортировать данные, запросы, дашборды и сценарии? Сколько стоит выход?

• Безопасность. Есть ли требования к сертификации, модель угроз, журнал аудита и измеримые сроки закрытия CVE?

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

Если сомневаетесь, проведите пилот на одном и том же наборе сервисов и телеметрии. Заранее зафиксируйте критерии победы. И разрешите внутренней команде сделать open source и вендору проиграть.

Вместо заключения: зрелость — это умение не строить

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

13,84 млрд рублей не доказаны как стоимость самосбора. Это тёмная материя между узкой видимой выручкой поставщиков и широкой оценкой расходов. Внутри неё есть legacy, услуги, инфраструктура и внутренняя разработка.

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

Создать работающую систему — признак сильного инженера. Решить проблему бизнеса с минимальной полной стоимостью — его профессиональная обязанность. Понять, какую систему создавать не нужно, — признак зрелой инженерной организации.

А теперь можно начинать холивар. Расскажите в комментариях: сколько FTE, серверов и лет разработки на самом деле стоит ваш «бесплатный» observability — и какой результат бизнеса вы им покупаете?