Запуск CosDevDirector: зачем мы создали единый дашборд для IT-инфраструктуры

Примерно год назад один из наших инженеров уволился в понедельник утром. Не скандально — просто отправил письмо, собрал вещи и ушёл. Хороший специалист, работал у нас три года. И только когда мы начали разбираться, что он делал и как, оказалось, что в его голове было сосредоточено знание о шестнадцати разных инструментах, которые мы использовали для управления инфраструктурой. Grafana на одном сервере, Zabbix на другом, доступы к Timeweb в личном кабинете, GitHub Actions где-то в браузере, статус Bitrix24 проверялся вручную через API-запросы в Postman, логи 1С смотрелись через SSH прямо на Windows-сервере. И всё это — в его голове, в его закладках, в его локальных скриптах, которые он не успел задокументировать.

Мы потратили две недели на то, чтобы просто понять, что где лежит и как работает. Не на то, чтобы починить что-то сломанное — на тот момент, слава богу, всё более-менее держалось. Просто на инвентаризацию того, что у нас вообще есть. Два инженера ходили по серверам, записывали IP-адреса, разбирались в чужих bash-скриптах, звонили уволившемуся коллеге с вопросами — он, к его чести, отвечал. Но даже при этом некоторые вещи мы обнаружили случайно, уже после. Например, что на одном из серверов стоит самописный Python-скрипт, который проверяет доступность нескольких сервисов и молча пишет в лог. Никто про него не знал. Он просто работал.

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

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

Я начал искать готовые решения. И вот здесь начинается долгая история о том, почему мы в итоге написали своё.

Я потратил примерно месяц на изучение рынка. Смотрел Datadog, New Relic, Zabbix, Prometheus с Grafana, Portainer для Docker, различные комбинации open-source инструментов. Всё это — достойные продукты, многие из них я сам использовал годами и продолжаю рекомендовать для определённых задач. Но у каждого из них была одна и та же фундаментальная проблема применительно к нашей ситуации: они решают часть задачи, а не всю задачу.

Datadog — прекрасный инструмент для мониторинга приложений и серверов. Глубокая трассировка, APM, логи, метрики — всё это сделано профессионально и удобно. Но он не знает ничего про ваш Bitrix24. Не умеет смотреть в 1С. Не показывает статус GitHub Actions в контексте того, что происходит с продакшн-сервером прямо сейчас. Более того — даже если вы захотите интегрировать всё это через кастомные метрики и логи, это потребует значительного инженерного ресурса. И стоит Datadog так, что для небольшой команды это просто неприлично. Мы прикинули — при нашей инфраструктуре только базовый мониторинг вышел бы в 40-50 тысяч рублей в месяц. Это не считая дополнительных модулей для логов, APM, синтетического мониторинга. Итого могло выйти за 100 тысяч в месяц — и это для команды из пяти человек, которая управляет инфраструктурой одной компании.

Portainer решает проблему управления Docker-контейнерами и делает это хорошо. Но Docker — это один слой из десяти в нашей инфраструктуре. Prometheus + Grafana — отличная связка для метрик, но настройка дашбордов под каждый новый источник данных — это отдельная работа, которая никогда не заканчивается. Grafana хороша когда у тебя есть посвящённый человек, который её настраивает и поддерживает. Когда такого человека нет — ты получаешь либо куцый дашборд с тремя метриками, либо монстра из ста панелей, в котором никто не может разобраться. А главное — ни один из этих инструментов не видит бизнес-системы: CRM, ERP, телефонию, облачные сервисы. Для них нужен отдельный инструмент, который снова нужно как-то интегрировать с остальным стеком.

Я долго думал, почему так происходит. И пришёл к выводу, который кажется банальным, но почему-то его мало кто формулирует прямо: большинство инструментов мониторинга создавались для чистых DevOps-команд в технологических компаниях, которые работают только с инфраструктурой и приложениями. Там нет 1С. Там нет Bitrix24. Там нет сайта на 1С-Битрикс, который каждые две недели обновляется и иногда после обновления теряет связь с базой данных. А реальный бизнес — особенно в сегменте среднего российского рынка — это не только серверы и контейнеры. Это 1С, в которой живёт весь учёт. Это Bitrix24 или amoCRM, где работает отдел продаж. Это сайт, который тормозит и теряет клиентов. Всё это взаимосвязано, и когда что-то идёт не так, причина часто на стыке этих систем.

Классический пример из нашей практики: продажники жаловались, что Bitrix24 «тормозит» и звонки плохо работают. Мы смотрели в Bitrix — там всё зелёное, API отвечает в пределах нормы. Смотрели в сервер — нагрузка в пределах нормы. Смотрели в сеть — всё чисто. А проблема оказалась в том, что ночью 1С запустила тяжёлый регламентный процесс, который создал очередь блокировок на уровне базы данных, которая через цепочку интеграций начала влиять на время отклика Bitrix24 при обращении к данным из 1С. Чтобы это увидеть, нужно было одновременно смотреть на четыре разные системы и понимать связи между ними. Ни один готовый инструмент такой картины не даёт — он просто не знает о существовании этих связей.

Был ещё один момент, который окончательно убедил меня делать своё. Я поговорил с несколькими коллегами из компаний, где стоит Zabbix. Все говорили примерно одно и то же: «Да, Zabbix стоит, но мы им почти не пользуемся». Почему? Потому что он был настроен три года назад под другие задачи, с тех пор инфраструктура изменилась, добавились новые серверы и сервисы, а поддерживать конфигурацию в актуальном состоянии некому. В итоге Zabbix стоит, присылает кучу алертов, большинство из которых ложные или неактуальные, и все научились их игнорировать. Это худшее из состояний — инструмент есть, но доверие к нему потеряно.

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

Я собрал всех, кто работал с нашими системами: два бэкенд-разработчика, девопс-инженер, аналитик, который смотрит в 1С, руководитель отдела продаж, который каждый день жалуется на Bitrix. Мы потратили несколько сессий на то, чтобы каждый описал своё «утро понедельника» — что он проверяет первым делом, чего боится не заметить, что обычно вызывает проблемы. Это была важная точка зрения: не «что можно мониторить», а «чего люди боятся пропустить». Разница принципиальная.

Из этих разговоров вышел список, который на первый взгляд казался хаотичным. Сервера живы? Контейнеры работают? Бэкапы сделаны? Сайты открываются? SSL сертификаты не просрочены? 1С не завалена блокировками? В Bitrix24 нет ошибок API? CI/CD не завис? GitHub Actions прошли? Есть ли неотработанные инциденты? Баланс на хостинге не кончился? Новые уязвимости в образах? Открытые порты, которых не должно быть?

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

Дальше пошли технические решения. Главный принцип, который мы приняли с самого начала: никакой агентской инфраструктуры. Мы не хотели ставить агентов на серверы — это и сложность установки, и ещё один потенциальный источник проблем, и ограничение для серверов, к которым нет возможности что-то дополнительно поставить. Всё должно работать через API или SSH. Это накладывает ограничения — например, нет возможности собирать метрики на уровне конкретных процессов с той же глубиной, что агентский подход. Но зато делает систему независимой от состояния самих серверов и гораздо проще в обслуживании.

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

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

Четвёртый принцип — простота первого запуска. Первое впечатление от инструмента определяет, будут ли им пользоваться. Если для того чтобы увидеть хоть что-то полезное, нужно потратить три дня на настройку — большинство бросит на первый день. Мы ставили цель: подключить первый сервер и увидеть живые данные за 10 минут. Добавить Bitrix24 за 5 минут. Подключить 1С за 15. Это задача и UX, и архитектурная.

CosDevDirector сегодня — это единая точка наблюдения за всем, что составляет IT-инфраструктуру типичной российской компании среднего размера. Я опишу не список функций — это можно прочитать на сайте cos-it.ru — а то, как это работает в реальном режиме дня.

Утром я открываю дашборд и за 15 секунд вижу полную картину. Три раздела на главном экране: инфраструктура (серверы Timeweb и выделенные, Docker-контейнеры), бизнес-системы (Bitrix24, 1С), разработка (GitHub репозитории, CI/CD пайплайны). Каждый элемент — это не просто зелёная или красная точка, а контекст: когда последний раз проверялось, какой тренд, были ли инциденты за последние 24 часа. Если всё зелёное — я иду пить кофе. Если что-то жёлтое или красное — открываю детали.

Серверный блок — это данные напрямую из Timeweb API плюс SSH-сбор метрик каждые 30 секунд для критичных серверов. CPU, RAM, диски, сетевые интерфейсы. История за 30 дней. Графики с аномалиями, подсвеченными автоматически. Система поддерживает серверы Timeweb, выделенные серверы любых провайдеров, и в ближайших планах — Hetzner и AWS для тех, кто работает с зарубежными облаками. Рядом — Docker: все контейнеры, их статус, потребление ресурсов, логи последних событий. Не нужно заходить на сервер по SSH, открывать консоль, вводить docker ps и docker logs — всё прямо в браузере. Для тех случаев, когда всё-таки нужна консоль — есть встроенный веб-терминал с записью сессии. Последнее важно и для безопасности: все терминальные сессии логируются, поэтому всегда можно восстановить, кто что делал на сервере.

Блок бизнес-систем — это то, чего нет ни в одном другом инструменте мониторинга, который я видел. Bitrix24 показывает не просто «API работает / не работает». Видно количество звонков за последние часы в разрезе по операторам, активные сделки с изменениями за день, статус SIP-телефонии, баланс на счёте провайдера телефонии (чтобы не проснуться однажды с выключенной связью). Система автоматически обнаруживает дубли в базе контактов — это отдельная боль в любой CRM, которая работает несколько лет без систематической чистки. Все эти данные обновляются каждые 15-20 минут фоновыми коллекторами без какого-либо участия пользователя.

1С — отдельная история, и я хочу остановиться на ней подробнее, потому что именно здесь мы потратили больше всего усилий. Работа с 1С через API это всегда приключение: OData-интерфейс есть, но документация скудная, поведение в разных конфигурациях отличается, производительность варьируется в широких пределах. Мы прошли через несколько подходов, прежде чем пришли к рабочей архитектуре. Сейчас система подключается через OData и SSH одновременно: OData даёт данные о бизнес-операциях (заказы, документы, контрагенты), SSH даёт технические данные (сеансы, блокировки, регламентные задания, технологический журнал).

Именно SSH-подключение к 1С-серверу потребовало специальных мер. Это Windows-сервер с ограниченным числом одновременных сессий. Если слать запросы параллельно или слишком часто — можно получить блокировку учётной записи на 15 минут. Поэтому мы реализовали очередь SSH-команд: запросы отправляются строго последовательно, с нужными интервалами. Это незаметно для пользователя, но критично для стабильной работы.

Мониторинг сайтов работает каждые пять минут: HTTP-статус, время отклика, SSL-сертификат с предупреждением за 30 дней до истечения. Если сайт упал — инцидент создаётся автоматически и летит уведомление в Telegram. Если сайт стал отвечать медленно, но не упал совсем — это тоже фиксируется как деградация, не игнорируется. История проверок хранится, поэтому можно посмотреть, когда именно начались проблемы и как долго они продолжались. Для бизнеса, который продаёт через сайт, это прямые деньги: каждая минута простоя или тормозов — это потерянные заявки.

Алерты и инциденты — пожалуй, самая продуманная часть системы, потому что здесь самое легко ошибиться. Я уже упоминал проблему «alert fatigue» — когда уведомлений так много, что на них перестают обращать внимание. Это состояние опасней, чем полное отсутствие алертов, потому что создаёт ложное ощущение наблюдаемости при полном её отсутствии. В CosDevDirector можно настроить пороги для каждого типа метрик, задать время «тишины» (не беспокоить по некритичным вещам в ночное время), настроить разные каналы для разных типов событий и разных уровней критичности. Telegram-бот для срочных алертов — упал сервер, недоступен сайт. Email для еженедельных отчётов и не срочных предупреждений. Инциденты имеют статусы и полный таймлайн — можно видеть, когда проблема была обнаружена, когда взята в работу, когда и как закрыта. Это важно не только для текущей работы, но и для ретроспектив.

Блок разработки показывает все GitHub-репозитории, последние коммиты, статус веток и их синхронизацию с продакшном, результаты CI/CD пайплайнов с историей. Это особенно ценно не для самого разработчика — он и так смотрит в GitHub — а для технического директора или DevOps-инженера, которому нужна картина: какие пайплайны упали, где деплой завис, нет ли проблем с автоматическим деплоем. Также есть сканирование локальных репозиториев — для команд, которые работают с кодом не только в GitHub.

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

Мы не претендуем на то, что CosDevDirector заменит полноценный security-аудит или SIEM-систему. Но мы сделали базовый уровень безопасности доступным без специальных знаний. Сканирование открытых портов показывает, что реально торчит наружу — иногда это становится неприятным открытием. CVE-сканирование Docker-образов через Trivy запускается регулярно и показывает уязвимости с классификацией по критичности. Зашифрованное хранение секретов (API-ключи, пароли, токены) — так, чтобы они не лежали в git-репозитории или в заметках.

Двухфакторная аутентификация и запись SSH-сессий включены по умолчанию. Журнал всех действий пользователей сохраняется — кто, когда, что делал. Это особенно важно, когда к системе имеют доступ несколько людей. Инструмент, который имеет доступ ко всей вашей инфраструктуре, сам по себе должен быть максимально защищённым — это казалось бы очевидно, но я видел мониторинговые системы, у которых не было даже нормальной авторизации. Всё это по умолчанию, без дополнительной настройки.

Отдельно про хранение данных. Всё хранится в вашей базе данных — мы не делаем копий ваших инфраструктурных данных в каком-то нашем облаке. Если вы используете self-hosted версию, данные вообще не покидают ваш контур. Для компаний, которые работают с чувствительными данными или имеют требования по локализации — это важно.

Я хочу остановиться на одной теме, которая кажется мне важной и которую часто упускают в разговорах про инструменты мониторинга. Мониторинг — это не самоцель. Это средство. Средство для чего? Для принятия решений с минимальными потерями времени и нервов.

Реальная работа IT-директора или DevOps-инженера в компании среднего размера — это постоянное балансирование между «тушением пожаров» и «строительством нового». Когда системы мониторинга настроены плохо или их слишком много и они противоречат друг другу, ты постоянно тушишь пожары — реагируешь на то, что уже сломалось, и никогда не видишь приближающихся проблем. Когда есть нормальная картина, ты начинаешь видеть проблемы до того, как они стали инцидентами. Диск заполняется — система говорит об этом за несколько дней. Нагрузка растёт по определённому паттерну — видно, что через неделю нужно будет масштабировать. SSL истекает — предупреждение за месяц, а не за день.

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

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

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

Именно поэтому мы уделили столько внимания разделу документации в CosDevDirector. Каждый сервер, каждая интеграция, каждый инцидент — всё это сопровождается историей, которую можно прочитать и понять. AI-аналитика умеет генерировать стартовую документацию на основе собранных данных: взять конфигурацию, метрики, запущенные сервисы — и выдать читаемое описание того, что на этом сервере работает и как. Это не замена настоящей документации, которую пишут люди с пониманием бизнес-контекста. Но это начальная точка, которая может сэкономить несколько часов разведки при онбординге нового человека или при разборе инцидента.

Я долго думал над тем, для кого мы делаем этот продукт. И чем больше я разговаривал с потенциальными пользователями — а я провёл, наверное, больше сотни разговоров за последний год — тем чётче становился портрет. Это не стартап с тремя серверами и не корпорация с выделенной NOC-командой. Это «серединка» — компании от 20 до 300 человек, где IT-отдел это 1-5 человек, которые отвечают за всё одновременно: серверная инфраструктура, 1С, сайт, CRM, почта, видеосвязь, VPN. Люди, которые каждый день жонглируют десятком систем и при этом должны успевать разрабатывать что-то новое и отвечать на запросы бизнеса.

Для таких компаний цена Datadog — это из другой реальности. Строить полноценный стек Prometheus + Grafana + Alertmanager + Loki — это недели работы и постоянная поддержка специалиста. Нанимать отдельного DevOps только для настройки мониторинга — дорого и избыточно для текущего масштаба. А работать вообще без нормального мониторинга — это жить в режиме постоянной фоновой тревоги и узнавать о проблемах от клиентов раньше, чем от собственных систем. Я прекрасно знаю это состояние — сам в нём жил несколько лет.

Именно здесь CosDevDirector находит свою нишу. Мы не пытаемся конкурировать с Datadog по глубине мониторинга приложений — там они бесспорно сильнее. Мы не пытаемся заменить Grafana для команд, которым нужны сложные кастомные дашборды с десятками источников данных. Мы делаем инструмент, который можно поднять за час и сразу видеть живую картину. Без yaml-файлов, без настройки экспортёров, без понимания PromQL. Просто подключить серверы, добавить API-ключи нужных сервисов — и всё работает.

Если говорить о тайминге запуска: мы выходим на рынок в 2025 году, и это не случайно. Последние несколько лет показали российскому IT-рынку, что зависимость от зарубежных инструментов — это реальный риск, не только политический, но и практический. Многие западные SaaS-сервисы стали недоступны или работают с ограничениями. Платёжные методы заблокированы. Техподдержка не отвечает на вопросы от российских компаний. Запрос на отечественные альтернативы есть, и он живой — не надуманный бюрократический нарратив, а реальная потребность компаний, которые ищут, чем заменить инструменты, которые они привыкли использовать.

Бесплатный план позволяет подключить до трёх серверов — этого достаточно, чтобы попробовать и понять, подходит ли инструмент. Мы сознательно сделали бесплатный план функциональным, а не кастрированным. Pro-план за 2990 рублей в месяц открывает до 50 серверов, все интеграции с бизнес-системами, AI-аналитику и полный набор алертов. Enterprise — для тех, кому нужно больше, с кастомными интеграциями и приоритетной поддержкой.

Про ROI говорить всегда неловко, но давайте честно. Один предотвращённый инцидент с серьёзным простоем сайта или продакшн-сервера — это, как правило, десятки тысяч рублей прямых потерь плюс время команды на восстановление. Один потерянный бэкап, который обнаружили уже когда понадобился — это иногда конец бизнеса. Один инцидент с Bitrix24, из-за которого отдел продаж не работал полдня — это потерянные сделки. При таком раскладе цена подписки окупается одним предотвращённым событием в год. Это не преувеличение — это математика.

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

Тот инженер, который ушёл год назад — я иногда думаю: если бы у нас тогда было то, что мы создали сейчас, насколько легче прошёл бы тот переход. Его знания всё равно были бы ценными — нет инструмента, который заменяет опыт думающего человека. Но они были бы дополнением к системе, а не её заменой. Следующий человек, который пришёл бы на его место, открыл бы дашборд и за несколько часов понял бы, как устроена наша инфраструктура. Не потому что кто-то потратил время на документацию — а потому что система сама знает о себе достаточно, чтобы это объяснить.

Это, собственно, и есть главная идея за CosDevDirector. Инфраструктура должна быть наблюдаемой — не потому что это модный DevOps-принцип, и не потому что так написано в книжках. А потому что это единственный способ управлять ею уверенно, не тратя половину рабочего дня на ручную сверку с реальностью. Без фоновой тревоги «а всё ли работает». Без зависимости от одного человека, который всё держит в голове. Без ежеутренних тридцати минут на сборку картины из шестнадцати вкладок браузера.

Попробуйте. Бесплатный план доступен на cos-it.ru — подключить первый сервер занимает минут десять. А если что-то пошло не так или хочется что-то обсудить — мы читаем все обращения и отвечаем на них лично. Продукт живёт и дышит отзывами реальных пользователей, и мы очень хотим услышать ваш.