Мониторинг против Observability: в чем разница и зачем бизнесу понимать ее? Подкаст TAdviser

Игорь Пустоветов: Мониторинг и observability — очень близкие понятия. Все началось с мониторинга, и он понятен большинству специалистов. Observability, или наблюдаемость, — это более широкий подход. Разница в том, что мониторинг — это процесс, который позволяет собирать технические данные о работе систем: попросту говоря, работает сервер или нет, высокий или низкий процент CPU — то есть базовые метрики. Observability же — это набор метрик, событий, логов, трейсов, складывающиеся в единую систему, которая позволяет не только видеть, что идет не так, но и понимать, почему и где именно. Это значительно больший объем данных, включающий как техническую информацию, так и бизнес-метрики, KPI и финансовые показатели.

Приведу простую метафору-сравнение. Мониторинг как градусник: он показывает конкретную температуру тела, это его функция. Наблюдаемость же — как Apple Watch или браслет Whoop: она оценивает состояние всего организма, учитывая различные данные, как человек спал, ел, какой у него уровень стресса, сахара в крови и другие показатели.

Игорь Пустоветов: Не сказал бы, что возникает именно путаница. Просто понятие observability пришло на рынок с зарубежными вендорами, которые стали популярными в России в 2015-2016 годах. До 2021–2022 годов он был недостаточно распространен, поэтому сейчас и возникает вопрос. Если бы термин был более известен, о нем бы знали шире. Например, недавно «Яндекс» анонсировал Yandex Observability Platform, тогда как за рубежом такие платформы существуют уже давно. Мы же свою платформу выпустили в 2022 году. Так что это естественное развитие рынка мониторинга. При этом важно понимать: мониторинг показывает одно, а наблюдаемость охватывает гораздо больше параметров, которые нужны бизнесу.

Игорь Пустоветов: Возьмем пример с высокотранзакционными операциями, например, сервисы СБП (Система быстрых платежей) от НСПК, которые активно используют банки и их клиенты. Внутри банка есть интеграция с НСПК, системы антифрода и противодействия отмыванию денег (anti-money laundering), дополнительные проверки, базы данных и код, обслуживающий эти процессы. Если сервис перестает работать, как понять, в какой из десятков точек произошла проблема — внутри банка или у НСПК?

В этот момент крупный банк теряет десятки миллионов рублей, потому что СБП просто не работает. Так вот, observability система позволяет увидеть в какой конкретной строчке кода последнего релиза была ошибка — например, неправильно построен запрос к базе данных, которая в итоге переполнилась, и сервис встал. Такая система не просто подсвечивает проблему, она может предупредить о ней заранее, когда процесс начинает деградировать. Если бы использовался только мониторинг, мы бы увидели лишь то, что процесс или сервер под ним не работает, без деталей о причине.

Игорь Пустоветов: Чем сложнее система, тем сложнее ее настройка. Снова метафора: LADA Granta починится в любом сервисе, а BMW последней модели требует официального дилера для обновлений. Команда, умеющая работать с observability или open source платформами, может решать эти задачи, но observability постоянно развивается, и многое зависит от квалификации команды.

Игорь Пустоветов: Основное отличие, опять же на примере СБП: когда собирается набор технических метрик, observability платформа может вывести параметры вроде потери выручки в конкретный момент. Допустим, я понимаю, что через конкретный сервис должно проходить 10 млн руб./мин. Очевидно если простой составит минуту, компания недополучит 10 млн руб. Можно эти понятия усложнять, добавлять различные метрики, но все они будут крутиться вокруг KPI бизнеса и недополученной выручки, ведь бизнес существует для того, чтобы получать прибыль. Observability связывает работу сервисов с KPI бизнеса и помогает понять влияние каждого сервиса на выручку. Мониторинг такого дать не может.

Игорь Пустоветов: Можно привести пример из ритейла. Магазины начинают экономить на сотрудниках и упрощают процесс покупки, внедряя кассы самообслуживания. Важно, чтобы они работали стабильно, но кто это контролирует? Ритейлу нужен инструмент, который изнутри покажет, что вся сеть касс, например у «Пятёрочки» или «Магнита», работает 99,9% времени. Эту задачу выполняет observability платформа. Главное — чтобы она поддерживала технологии, на которых работают кассы.

Перевести это в деньги сложно, но пример наглядный. Представьте: в магазине есть 10 касс самообслуживания и один кассир. После работы люди приходят за покупками, и 9 из 10 вынуждены встать в очередь, потому что кассы самообслуживания не работают, а обслуживает только кассир. Легко экстраполировать, сколько денег магазин теряет в такой ситуации. Похожая история может произойти на АЗС, где тоже внедряются кассы самообслуживания и системы лояльности. Клиент приезжает заправиться, но карта лояльности на смартфоне не открывается — снова очередь, простой, недополученная выручка.

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

Игорь Пустоветов: Да, помогает и даже не в некоторой степени. Когда в компании ИТ-специалисты сами разрабатывают системы, сервисы, интегрируют коробочные решения и связывают это все между собой, сложность цифрового контура растет. Возникает зависимость: чем сложнее контур, тем больше ресурсов требуется на его поддержание. Получается, цифровой контур улучшается, но при этом постоянно растут издержки на его сопровождение. Так вот observability платформа позволяет сократить эти издержки и повысить эффективность работы команд.

Игорь Пустоветов: Практики переплаты у нас не было. Те, кто внедряет observability, делают это грамотно. Шкала простая: чем больше процессы компании завязаны на цифровую выручку, тем больше нужна observability и, соответственно, наоборот. Если это малый бизнес или, например, какая-то угольно добывающая компания, и у нее не много процессов в «цифре», следовательно, можно обойтись и мониторингом. А если это, скажем, «Т-Банк», то у него вся выручка построена на цифровых продуктах — без observability не обойтись.

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

Игорь Пустоветов: Думаю, что сейчас в России рынок observability распределяется примерно так: около 30% приходится на банки, примерно 20% — на ритейл, еще около 20% — на страховые и промышленные компании. И другие разные компании из различных секторов. Примерно такое же распределение и у нас в компании. Ритейл, вероятно, занимает у нас большую долю, потому что мы начинали именно с этого сегмента — он очень активен в России. Примерно треть приходится на промышленные компании.

Игорь Пустоветов: Сроки внедрения зависят от компетенций команды, которая занимается процессом. Иногда бывает, что мониторинг развертывается дольше — все зависит от задач. Если просто расставить, так сказать, «градусники», как в моем примере, и собрать информацию без конкретной цели, это можно сделать довольно быстро, независимо от сложности контура. Процессы observability занимают больше времени. Например, в GMONIT мы поддерживаем функцию автоинструментации приложений. Простыми словами: допустим, ИТ-«дочка» нашего клиента создала множество сервисов на Java. Мы можем автоматически развернуть библиотеку на все эти сервисы, и данные с метриками сразу начинают поступать в GMONIT. Система обрабатывает их и строит карту всех сервисов компании автоматически. По сути, это можно сделать за день, при этом обеспечивая бесперебойную работу сервисов клиента. Так быстро мониторинг развернуть не всегда удается.

Но бывают и более сложные ситуации, когда, например, необходимо состыковать путь клиента из SAP систем, из тех систем, которые написал сам клиент и еще какие-то сторонние интеграции вроде «Сбермаркета». В таких случаях процесс займет больше времени. Но и мониторинг в этом случае будет настраиваться дольше. Все зависит от сложности системы, но мы стараемся сделать внедрение максимально просто. Могу сказать точно, что развертывание GMONIT на контур клиента идет быстрее, чем ручная установка open source.

Игорь Пустоветов: Вообще, у нас не стоит вопрос интеграции с какими-то российскими решениями или новыми вышедшими. Чтобы собрать информацию для observability платформы, необходимы международные технологии, такие как Java или PHP. И даже если появляются новый российский стек, к примеру, Postgres Pro — это тот же международный PostgreSQL. Мы все эти технологии поддерживаем.

Из новых интеграций у нас есть «1С»: до нас никто в мире, кроме нашей команды, не внедрял «1С» в observability платформу. Мы сделали это, потому что видим переход от SAP — российским компаниям просто некуда деваться, кроме как на «1С». Наша задача — поддерживать клиентов в этом процессе. В остальных случаях критичности нет, и все решается довольно просто.

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

Игорь Пустоветов: Если смотреть формально, может показаться, что мы конкурируем с «Тинькофф» или «Яндексом» — у них тоже есть observability платформы с другими командами. Но на самом деле это не совсем так. Крупные компании, такие как «Яндекс», называют это observability платформой, потому что они собирают и сводят метрики, логи и трейсы. В классическом понимании это действительно платформа наблюдаемости, но сделана она прежде всего как высоконагруженный инструмент для технических специалистов. Они выпустили ее в «Яндекс Облаке» и позже планируют выход на рынок. Да, это круто. Но чем отличается GMONIT?

Мы вышли раньше и научились связывать метрики, логи и трейсы с KPI бизнеса. Сейчас к этому добавляется искусственный интеллект: мы стараемся предсказывать события, которые будут происходить внутри цифрового контура, находить корреляции между различными системами и прогнозировать инциденты. Даже предсказание за 5–7 минут приносит ощутимую экономическую выгоду. Пока «Яндекс» и другие не связывают технические метрики с бизнес-показателями. Именно в этом состоит ключевое конкурентное преимущество GMONIT: мы можем говорить с клиентами на языке бизнеса.

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

Второе — использование open source нейросетей для усиления нашей рекомендательной платформы. Мы хотим, чтобы внутри нее был искусственный интеллект, который выступал бы экспертом и помогал быстрее разбираться в происходящем. По моему мнению, задача observability вендора — делать сложное простым, в том числе для технических специалистов и разработчиков. Не нужно тратить лишние ресурсы на решение рутинных задач, если их много.

Игорь Пустоветов: Если говорить конкретно про машинное обучение, последняя зафиксированная точность у нас была 98,7%. Этого достаточно, чтобы выявлять аномалии и автоматизировать процессы, о которых я упоминал. В будущем планируем углублять работу в этой области. Искусственный интеллект сейчас находится на пике интереса, но помимо ИИ существует множество задач, которые напрямую влияют на недополученную выручку компании, и их нужно решать в первую очередь с помощью подходов observability.

Игорь Пустоветов: Нужно расшифровать, что такое ROI — return on investment, или возврат инвестиций. И важно понять, насколько стоимость observability платформы оправдана с точки зрения создаваемой ценности. Этот показатель можно посчитать, и мы делаем это в пилотных внедрениях, подтверждая результат на конкретных данных и метриках сервисов клиента. Допустим, стоимость платформы для наблюдаемости составляет 10 млн рублей, а за год ее использования бизнес получает дополнительно 100 млн рублей. Профит в 90 млн складывается из показателей MTTR и MTTD — то есть времени, затраченного на выявление и разбор инцидентов, а также на работу специалистов по поиску информации. Именно на основе этих показателей формируется ROI.

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

Игорь Пустоветов: Я обычно все привожу в деньгах, потому что речь идет о коммерческих предприятиях. Но можно говорить и о других вещах, например, об удобстве или упрощении работы. У DevOps-инженера под присмотром множество сервисов и систем, каждая из которых сложна. Классно же, когда у специалиста все отображается на едином экране. Еще круче, когда разработчик заходит в свою систему, а потом DevOps заходит с другой стороны — и вместе они видят все в GMONIT и понимают, что происходит. Если случается инцидент и в нем участвуют, скажем, пять человек, observability дает единое окно, позволяющее каждому на своем языке понять ситуацию. А еще здорово, когда система подсказывает, что делать дальше. Это и делает GMONIT.

Наша цель — не просто создавать observability платформу, а сделать инструмент, который позволяет команде работать быстрее. Это в первую очередь платформа для совместной работы. Без нее все становится сложнее. Есть, например, компания Miro из Пензы: она делает интерактивные онлайн-доски, которые ускоряют совместную работу команды. Мы делаем то же самое, но в сфере observability, поэтому удобство анализа метрик внутри системы у нас на первом месте. Так что если отбросить вопрос выручки, для всей команды разработчиков и инженеров работа становится гораздо проще. А топ-менеджмент уверен, что все функционирует корректно. Если гендиректору интересно, он сам может найти строчку кода и проверить.

Игорь Пустоветов: Один фактор — это уход иностранных вендоров. А второй, на мой взгляд, еще более важный: в России сильные инженеры, а не просто разработчики — они придумывают инженерные решения. Берут open source, соединяют с различными инструментами, чтобы достигнуть нужных показателей. Если не хватает метрик — развивают их, если не хватает трейсов — добавляют. На этом и строится выбор open source.

Но важно понимать: использование open source для мониторинга и применение проприетарных решений, таких как GMONIT, решает разные задачи. Мониторинга обычно хватает компаниям, чья выручка не сильно зависит от цифрового контура, и если есть команда, которая может обеспечить работоспособность сервисов. А если вы хотите полностью контролировать бизнес и у вас разрозненный цифровой контур, где множество ИТ-решений и, например, кассы самообслуживания, нужен проприетарный продукт. Это связано с тем, что для каждого направления требуются разные компетенции. В проприетарном решении вендор концентрирует все усилия, чтобы дать максимальную ценность.

Игорь Пустоветов: Да, инженеры могут решить инженерную задачу, однако при этом есть риск упустить разные факторы. Например, система должна развиваться и соответствовать последним технологиям. На ее поддержку тратится очень много ресурсов. Я не говорю, что этим нельзя заниматься самостоятельно — надо покупать GMONIT, просто нужно учитывать реальные трудозатраты серьезных инженеров на поддержание собственной платформы и сравнивать с альтернативой вроде GMONIT.

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

Мы тоже поступаем так: собираем экосистему вокруг наблюдаемости и эффективности цифрового контура, включая безопасность и process mining. При этом подключаем инженеров, которые работают не у нас, и привлекаем компании к совместной работе.

Игорь Пустоветов: Не думаю, что нужно специально убеждать кого-то переходить на проприетарное решение. Главное — понимать, зачем ты что-то делаешь, и критически оценивать свои подходы: насколько они действительно соответствуют цели. Если open source решает твою задачу, используй его. При этом топ-менеджеры должны задать себе вопросы: действительно ли я понимаю, как работает мой цифровой контур? Уверен ли я, что завтра он не выйдет из строя в каких-то местах, и если что-то сломается, мои сотрудники смогут починить это за минуты, а не за часы или дни? В нашей практике бывало так: мы продавали GMONIT условно за 10 млн рублей, а уже в течение месяца компания на этом зарабатывала 200 млн рублей.

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

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

Игорь Пустоветов: Цель GMONIT на ближайшие 10 лет — стать полноценной экосистемой для повышения эффективности цифрового контура. В системе есть базовый слой — серверы и виртуальные машины, и верхний слой — бизнес-приложения. Когда разные сервисы, разработанные ИТ-«дочками» компаний, начинают взаимодействовать между собой, возникает вопрос: насколько эффективно все это работает. Observability здесь выступает как первый шаг к оценке и улучшению работы цифрового контура.

Есть и другие подходы для анализа эффективности. Во-первых, process mining — он связывает весь процесс взаимодействия с клиентом, учитывая процессы, которые проходят через людей в разных компаниях. Этот метод уже активно используется, и на его основе можно значительно оптимизировать расходы и вернуть недополученную выручку.

Другое направление — кибербезопасность. Без ИБ невозможно говорить об эффективном цифровом контуре, поэтому это тоже направление для нашего развития. Здесь возникает вопрос использования open source и его безопасности для государственных информационных систем. Таким образом, возвращаясь к вопросу, GMONIT развивается в продукт, который позволяет крупным компаниям комплексно оценивать и повышать эффективность своего цифрового контура.

Игорь Пустоветов: Не могу точно сказать, как обстоят дела с observability в госструктурах. Мониторинг там, вероятно, есть, но непонятно, в каком объеме и с какой глубиной процессов. Этот сегмент нам интересен. Например, недавно в период уплаты налогов наблюдались перебои в работе отдельных систем ФНС. В итоге пользователи столкнулись с задержками. Если бы там была полноценная observability, велика вероятность, что подобных массовых сбоев удалось бы избежать или минимизировать. Хотя речь не идет о выручке, здесь есть критически важные пользовательские транзакции и социальная значимость. Может быть актуально для портала госуслуг или сервиса «Госключ», например.

Игорь Пустоветов: Поэтому мы этим и занимаемся, и именно поэтому я здесь.

Игорь Пустоветов: Думаю, что мониторинг как понятие в ближайшие 5 лет станет ближе к observability, потому что само слово «observability» — сложное. С технической точки зрения специалисты, работающие в этой области, станут лучше разбираться в подходах, о которых я говорил. И тот же «Яндекс» в этом помогает: на своей конференции они объясняли техническим специалистам, что observability — это не мониторинг. Так что мониторинг будет эволюционировать, усложняться, становиться более эффективным, переходить в наблюдаемость. А уж как его называть — дело каждого. Главное, чтобы задачи бизнеса решались, а системы работали корректно.

Игорь Пустоветов: Хотелось бы, конечно, сказать, что GMONIT не хуже Dynatrace, но прямого сравнения мы не делали, и оно не совсем релевантно: Dynatrace существует уже 20 лет, технологии за это время сильно изменились. Кроме того, GMONIT базируется на иных подходах, нежели зарубежные игроки. Приведу метафору: раньше все «молились» на конвейер Ford как лидера производства автомобилей, а сейчас открываются китайские фабрики, потому что им понятно, как делается подвеска, кузов и прочее. Грубо говоря, это open source, где подходы уже ясны, и ценность достигается иначе. У нас — аналогичная ситуация.

Поэтому могу сказать, что GMONIT соответствует мировым ожиданиям, т.к. использует современные технологии, в том числе open source. Единственное, в чем мы слегка отстаем, — это применение ИИ и AIOps, что связано с общей задержкой в развитии ИИ в России. На Западе в эти направления активно инвестируют, и технологии там развиваются быстрее.

Но есть позитивная сторона: базируясь на новых технологиях, мы берем лучшие мировые практики, совмещаем их и делаем то, что нужно бизнесу. Например, у нас есть агенты open telemetry — это часть мировых observability подходов, и мы эту информацию складываем в ClickHouse — популярную российскую базу данных, которая легко масштабируется. Мы ее применяем, потому что это самый эффективный способ сбора и хранения информации. И мы используем несколько агентов, а не один, т.к. это позволяет эффективно управлять нагрузкой на систему. А тот же Dynatrace, например, до сих пор использует подход одного агента, потому что так исторически сложилось. Это все создает конкурентные преимущества. Думаю, и на международном рынке GMONIT будет конкурировать. Мы собираемся в первую очередь выходить на растущие рынки ЮВА, Африки, МЕНА и СНГ.

Игорь Пустоветов: Да, у нас уже есть зарубежные «пилоты», пока в СНГ. Там тоже хорошо развиты банковские платформы, создаваемые в том числе с участием русских разработчиков. Нас сравнивают с AppDynamics — эта платформа оценивает не только техническую сторону, но и влияние на бизнес. Мы делаем то же самое. Радует, что мы участвуем в таких пилотах: у нас уже три кейса. В одном из них мы обошли зарубежный продукт. Мы предложили более выгодное решение, и при этом, без сильного демпинга, технически оно оказалось удобнее.

Игорь Пустоветов: Важно понимать, какие задачи в данный момент решает компания. Если она активно выходит на цифровой рынок — например, быстро запускает платформу e-commerce — логично сразу использовать observability от вендора. Если же компания постепенно развивает цифровой контур, она может постепенно наращивать собственную команду разработки и мониторинга. В таком случае можно начать с мониторинга, а потом перейти к observability. Главное — не отставать в развитии. Вот и вся разница.

Игорь Пустоветов: И вам тоже спасибо за вопросы, Наталья. Мне было интересно пообщаться, надеюсь, что и слушателям было интересно тоже.