Тема оптимального выбора ПО, особенно в нынешних условиях России, актуальна как никогда. Однако пользователи вендорских систем и решений с открытым кодом сталкиваются с принципиально разными проблемами. К чему надо быть готовым и что стоит предпочесть?
- 1. Введение
- 2. Мониторинг ИТ-инфраструктуры. Кому нужно и как делается
- 3. Как выбрать систему мониторинга
- 4. Российский рынок. Каким он был и каким стал
- 5. Вендорское ПО против открытого. Кому какое подходит?
- 6. Выводы
Введение
Количество сбоев постоянно растёт. Это касается как мира в целом, так и России. Причин тому много, как объективных, так и субъективных. К ним приводят неисправности в работе оборудования, проблемы с энергоснабжением, повреждения каналов связи, в конце концов, человеческие ошибки. В итоге со сбоями, согласно данным Uptime Institute, сталкивалось 93 % организаций по всему миру.
Как показывает исследование компании Monq, в России количество сбоев растёт опережающими темпами. За 2024 год, например, оно выросло на 22 %, и предпосылок для снижения в 2025 и 2026 годах нет.
Тут сказывается сочетание сразу целого комплекса неблагоприятных факторов. С одной стороны, в нынешнее время сложно менять ИТ-оборудование, которое дорожает и его сложнее доставлять в страну. При этом то, что эксплуатируется, изнашивается со временем со всеми, как говорится, вытекающими последствиями в виде сбоев.
Много проблем доставляет и ПО. Зарубежное, которое до сих пор используют многие, в силу опасений, связанных с санкционными ограничениями, боятся обновлять. В том числе это касается установки различных патчей. Российское же не всегда в должной степени отлажено с одной стороны, плюс ко всему многие особенности работы с ним серьёзно отличаются, что ведёт к росту количества ошибок персонала — с другой.
В таких условиях развёртывание систем мониторинга является мерой, которая поможет компаниям вовремя локализовать и устранить сбой до того, пока он не нанесёт существенного ущерба. Такие системы разворачивают не только крупные, но и относительно небольшие компании.
Мониторинг ИТ-инфраструктуры. Кому нужно и как делается
Системы мониторинга собирают данные о работе различных компонентов ИТ-инфраструктуры, анализируют их и выявляют всевозможные аномалии. Такие отклонения обычно являются симптомом возможных проблем ещё до того, когда на них обратят внимание пользователи и они могут создать угрозу бесперебойной работе систем.
Как показал опрос зрителей эфира AM Live «Автоматизация ИТ-инфраструктуры: реальные кейсы, тренды и ошибки компаний», который состоялся в ноябре 2025 года, мониторинг занимает не первое, но всё же довольно весомое место среди тех задач управления ИТ-инфраструктурой, которые уже автоматизированы (рис. 1). Он уступил только сбору заявок и задачам резервного копирования.
Рисунок 1. Задачи, автоматизированные ИТ-службой
Однако успешное решение задач мониторинга невозможно без инвентаризации ИТ-активов. Это самая первая задача, которую приходится решать при внедрении платформ ITSM (IT Service Management, сервисная методология организации обслуживания ИТ) — создание базы данных управления конфигурациями, или CMDB. Это требует определённого уровня зрелости ИТ в организации. Однако в условиях массовой цифровизации не редкость, когда на внедрение сервисной модели идут и относительно небольшие компании, деятельность которых сильно зависит от ИТ.
Плюс ко всему, внедрение сервисной модели позволяет правильно организовать сбор метрик, которые реально нужны для создания системы мониторинга. Чем их больше, тем сложнее и дороже будет организовать хранение и обработку соответствующих данных, что прямо сказывается на стоимости проекта и эффективности работы систем.
Непосредственно система мониторинга состоит из двух подсистем:
Сбора и анализа данных. Включает непосредственно инструменты мониторинга работы оборудования и ПО, а также базовые средства анализа параметров их работы.
Предотвращение инцидентов. Включает модуль более продвинутой аналитики, часто предсказательной (предиктивной), который использует не только данные, собранные средствами мониторинга, но и заявки от пользователей о различных проблемах.
Системы мониторинга делятся на классические (они же инфраструктурные) и зонтичные. Первые фокусируются на управлении отдельными объектами или их функциональными группами (ПК, серверы, сетевое оборудование, датчики, контроллеры, базы данных и т. д.). Они проще в реализации, но при этом не учитывается взаимосвязь отдельных компонентов между собой.
Зонтичный же представляет собой комплексную систему, которая отслеживает всю ИТ-инфраструктуру. Однако его реализация сложнее и требует высокого уровня зрелости ИТ. Однако именно такой подход рекомендуют использовать тем организациям, работа которых критически зависит от ИТ.
Для решения данных задач существует целый ряд программных платформ, среди которых наиболее популярны BMC Patrol, IBM Tivoli и MicroFocus OpenView. В силу ряда обстоятельств в России оказались более популярны продукты с открытым кодом: Nagios, Zabbix, Cacti, OpenNMS и его форк (ответвление) Icinga на более быстром и «легком» движке. Впрочем, на основе некоторых из них, в частности Zabbix существуют и коммерческие продукты.
Как выбрать систему мониторинга
Критериев выбора таких систем несколько. Однако ключевыми являются масштаб инфраструктуры, желаемый уровень доступности сервисов (может отличаться для разных групп в зависимости от стоимости возможного простоя), или SLA (service level agreement, дословно — соглашение об уровне сервиса). Важно также соблюдение регуляторных требований (необходимость включения ПО в реестр Минцифры для госсектора и компаний с госучастием, наличие сертификатов для работы на объектах критической информационной инфраструктуры).
Впрочем, стоит иметь в виду, что в России широко распространена практика внутренней разработки. В качестве основы вполне можно взять продукт с открытым кодом и провести его доработку. Примеры такой практики есть, в том числе в сильно зарегулированных сегментах, в частности, как минимум в двух крупнейших банках.
Однако тут сдерживающим фактором является наличие разработчиков довольно высокой квалификации, хорошо знающих как сам прототип, так и особенности инфраструктуры в компании. Причём для доработки прототипа с открытым кодом в разумные сроки, как показывает практика, необходимо не менее 10 человек.
Важным фактором является стоимость проекта. Причём внедрение формально бесплатного продукта может обойтись не дешевле, чем коммерческого, за счёт целого ряда факторов, которые не всегда на виду. Впрочем, об этом более подробно будет сказано ниже. При этом надо быть готовым к тому, что внедрение системы мониторинга — сложный, длительный и дорогой интеграционный проект.
Не менее значимым параметром является зрелость ИТ в компании. Следует иметь в виду, что частые кардинальные изменения в ИТ-инфраструктуре делают проект мало полезным, поскольку это сильно осложняет сбор данных, необходимых для работы таких систем. Плюс ко всему, только в зрелой компании можно рассчитывать на то, что можно будет выбрать только те метрики, которые будут по-настоящему значимы, а не все какие только есть.
Плюс ко всему, как уже было сказано выше, распространённым мнением является необходимость внедрения подходов ITSM, причём на довольно высоком уровне. Например, при внедрении «тяжёлых» решений, по крайней мере, по мнению некоторых экспертов, необходимо наличие работающей подсистемы управления инцидентами. Но наличие базы активов (CMDB) — минимально необходимое условие даже для систем, считающихся начальным уровнем.
Также система должна быть удобной и понятной не только техническим специалистам, но и бизнесу. Это может создавать довольно большие сложности, поскольку бизнес не сразу осознаёт, что ему на самом деле необходимо, что создает как минимум сложность при выборе метрик. Плюс ко всему, у разных подразделений разные потребности, и это также приходится учитывать.
Российский рынок. Каким он был и каким стал
Рынок систем мониторинга оказался одним из тех, где процесс замены коммерческих зарубежных систем начался задолго до ухода зарубежных вендоров в 2022 году. Точкой бифуркации, по крайней мере по мнению некоторых аналитиков, стал 2015 год, именно тогда спрос на зарубежные коммерческие системы начал резко снижаться. Это было связано с резким падением курса рубля.
До 2014 года коммерческие зарубежные продукты занимали 90 % отечественного рынка. Как и в остальном мире, доминировали решения от BMC, HP (сейчас проданы MicroFocus), IBM, Splunk. В 2022 году резко активизировались и российские вендоры, однако их продукты также представляли собой часто те же системы с открытым кодом, но, что называется, «доработанные напильником» и с предоставлением технической поддержки. Причём на этот рынок выходили и неожиданные игроки, например, Т-Банк с системой Sage, которая изначально была создана для внутренних нужд.
Однако внедрения «тяжёлых» систем вроде OpenView или Tivoli имеют очень длительный жизненный цикл, который сопоставим со сроком жизни управленческих платформ вроде ERP или АСУ ТП — не менее 10 лет, часто больше. Поэтому такие решения составляют довольно весомую долю до сих пор, и в целом их доля до 2022 года снижалась довольно медленно.
Однако по состоянию на конец 2024 года российские продукты занимали почти ровно две трети рынка. Объём его, по разным оценкам, составил от 3 до 17 млрд рублей. Тут зависит от того, что включать: только стоимость лицензий или учитывать также сопутствующие услуги по внедрению и сопровождению. Крупнейшими игроками являются «Сател», ГК «Астра», Naumen, Monq, Tibbo Systems и «Ред Софт». Выручка этих вендоров по итогам 2024 года составила немногим более 1,6 млрд рублей, что составляет около половины от общего объема продажи лицензий такого ПО.
Значительную долю составляют и продукты с открытым кодом. Наиболее популярны пять из них: Nagios, Zabbix, Cacti, OpenNMS и Icinga. Помимо сообществ пользователей, услуги по их внедрению оказывают и интеграторы.
Вендорское ПО против открытого. Кому какое подходит?
Одной из ключевых сессий на первой профессиональной конференции, посвящённой мониторингу ИТ-инфраструктуры Observability Conf, которая прошла в Москве 19 марта 2026 года, стал круглый стол «Вендорские решения для мониторинга VS opensource» (рис. 2).
Рисунок 2. Участники круглого стола «Вендорские решения для мониторинга VS opensource»
Цена open source: не так бесплатно, как кажется
Как отметил модератор мероприятия, руководитель отдела систем мониторинга «Инфосистемы Джет» Алексей Акопян, его задачей является помочь сделать осознанный выбор в нынешних условиях, что непросто.
По практически единодушному мнению участников, ПО с открытым кодом отнюдь не бесплатно, несмотря на формально нулевую стоимость лицензирования. В любом случае придётся нести затраты на поддержку. В целом, если считать стоимость проекта внедрения коммерческого и свободного продуктов, как показывает реальная практика внедрений, затраты оказываются как минимум близкими.
К слову, это эмпирическое правило практически не зависит от класса продуктов и решений. Однако если речь идёт о «тяжёлых» классах, включая системы мониторинга, внедрение продукта с открытым кодом, с учётом всех скрытых «подводных камней» и двойного дна, может оказаться и дороже.
Также, как напомнил инженер DevOps Cloud.ru Антон Быстров, свободные продукты представляют собой фактически бесконечные бета-версии, и это также стоит учитывать. Особенно часто так действуют сами вендоры, распространяя предварительные версии своих продуктов под свободными лицензиями. Таким образом они обкатывают экспериментальные функции, причём далеко не все из них в итоге попадают в коммерческие версии.
Обратной стороной такой политики разработчиков является риск нестабильной работы экспериментальных функций, которые к тому же могут влиять на все остальные. Это может стать причиной сюрпризов, причём не самого приятного свойства. Данное обстоятельство практически исключено в коммерческих системах, даже основанных на продуктах с открытым кодом.
Кроме того, как подчеркнул технический директор Proto Observability Platform Денис Безкоровайный, использование ПО с открытым кодом для решения сложных задач, включая мониторинг ИТ-инфраструктуры, требует получения серьёзных компетенций командой, которая будет внедрять, а затем обслуживать и развивать продукт. На это необходимы время и ресурсы.
Не стоит забывать, что на время обучения эти сотрудники не смогут выполнять свои обязанности в полную силу, что также чревато серьёзными издержками, особенно на фоне кадрового дефицита, когда во многих компаниях один ИТ-специалист решает те задачи, которые в принципе должны решать двое.
Гибкость open source и возможности кастомизации
Как напомнил управляющий партнёр Monq Николай Ганюшкин, свободное ПО можно дорабатывать под свои нужды. Однако, как было сказано выше, для того чтобы полноценно доработать более-менее серьёзный продукт с открытым кодом под нужды компании, нужно как минимум 10 человек, а лучше 15. Но собрать команду специалистов со всеми необходимыми навыками не так просто.
Среди компаний, которые собираются внедрять системы мониторинга, согласно данным Tadviser, только в лучшем случае треть считает, что они в состоянии вести доработку продуктов мониторинга ИТ-инфраструктуры. Скорее всего, далеко не все из них способны это делать на самом деле.
По мнению Николая Ганюшкина, многое может изменить использование генеративного искусственного интеллекта (ИИ) для доработки продуктов с открытым кодом (вайбкодинг). Это, по его оценке, может кардинально изменить ситуацию за счёт того, что доработка может больше не потребовать наличия команды квалифицированных разработчиков.
Обратной стороной тут будет то, что изменения, которые вносит ИИ, многие сообщества и компании, которые стоят за проектами с открытым кодом, не принимают, по крайней мере, в настоящее время. Однако по мере совершенствования генеративного ИИ, которое происходит не просто быстро, а молниеносно, возможно, такие ограничения будут сняты.
Однако успешные крупные проекты на базе продуктов с открытым кодом есть. В рамках этой же конференции Observability Conf представители «Газпромбанка» — руководитель Центра ИТ-мониторинга Валентин Лебедев и технический директор Ян Ашенкампф — поделились опытом построения системы мониторинга на базе свободных продуктов Zabbix и OpenTelemetry.
В ходе этого внедрения пришлось учитывать целый ряд особенностей этих систем применительно к большой и территориально распределённой инфраструктуре отнюдь не маленького банка. Так, количество метрик достигало 700 тыс. Много сложностей и проблем вызывала интеграция данных. Все эти сложности были успешно решены. Выше также приводился пример Т-Банка, который не просто создал и внедрил систему на базе продукта с открытым кодом, но и выпустил её на открытый рынок.
С другой стороны, как отметил Антон Быстров, в полном смысле вендорских продуктов в России сейчас просто нет. Хотя, с другой стороны, это всё же преувеличение. Это видно даже по составу топ-6 по версии TAdviser, где представлены как минимум 4 продукта, которые созданы «с нуля» на базе собственных разработок: СОВА, Astra Monitoring, все системы от Naumen и AggreGate Network Manager.
Но, как обратил внимание Николай Ганюшкин, мелким вендорам сложно понять нужды крупных заказчиков, как верно и обратное. Это касается любых продуктов, не только относящихся к ИТ.
Когда стоит выбирать вендорское ПО
Однако коммерческие системы, даже если они представляют собой те же продукты с открытым кодом, как минимум предоставляют техническую поддержку и у них более дружественный интерфейс. Также там имеются функции, которые отсутствуют в ванильной версии. Но именно эти доработки, по мнению Антона Быстрова, дают право вендору на то, чтобы позиционировать свой продукт как готовое решение бизнес-задачи уже «из коробки».
У вендорского ПО основным приоритетом является поддержание заданного уровня сервиса (SLA). Именно по этой причине, как подчеркнул TeamLead DevSecOps «Лаборатории Касперского» Андрей Сухоруков, системы с открытым кодом оказываются в проигрышном положении при «тяжёлых» внедрениях. Плюс ко всему, внедрение коммерческого продукта обычно менее трудоёмко. Это означает сокращение сроков проектов и снижение затрат на услуги интеграторов, если проект идёт с их привлечением.
Однако обратной стороной коммерческого ПО, как подчеркнул Антон Быстров, является зависимость от вендора. Именно это обстоятельство является основной проблемой проектов с использованием вендорских продуктов. А уход вендора с рынка, как обратил внимание Андрей Сухоруков, может и вовсе создать сложности, часто непреодолимые. А такие прецеденты были.
Однако зависимость, но другого рода, возникает и у пользователей продуктов с открытым кодом. Она исходит уже от внутренней команды, которая его дорабатывала и сопровождает. Это признали, пусть и косвенно, и представители «Газпромбанка».
Но всё же, как согласились все участники круглого стола, получить дополнительные очки за внедрение вендорского продукта сейчас в России не получится. Хотя до 2015 года, а в каких-то компаниях и после, пусть и по инерции, за это можно было получить хорошие KPI.
Выводы
Однозначных плюсов нет у обоих классов систем мониторинга ИТ-инфраструктуры. И у систем с открытым кодом, и у вендорских есть как плюсы, так и минусы. У вендорских систем это более чёткая ориентация на бизнес-результаты, у систем с открытым кодом — гибкость, возможность адаптации под нужды организации и нулевая стоимость лицензирования. В обоих случаях организация становится зависимой: от вендора в случае коммерческого продукта или, если речь идёт о платформе с открытым кодом, то от команды, которая её адаптирует и поддерживает.
С другой стороны, применительно к текущим условиям, которые сложились на российском рынке, вендорские решения также представляют собой продукты с открытым кодом. Отличия заключаются в наличии коммерческой технической поддержки, некоторых доработках интерфейса и ориентации на решении тех или иных бизнес-задач, часто декларативной.
