Три месяца назад я опубликовал историю про то, как не получилось из проекта сделать продукт, как он обратно превратился в проект и так и не вышел на рынок (прочитать об этом можно тут).

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

Как родилась идея

Жила-была в 2014 году в одном интеграторе команда технарей, которая мечтала сделать свой продукт и выйти с ним на рынок. Нет, даже не так. Команда и не мечтала сделать свой продукт, она сначала увидела возможность помочь своим коллегам поддерживать информационные системы более эффективно.

Этот интегратор занимался тогда в основном поддержкой высоконагруженных систем с огромным числом пользователей и большим числом процессорных ядер на каждую систему. Поддержка была в лучших традициях жанра 24/7. В одной смене могли работать по 20-30 человек. Кто-то смотрел в экраны инфраструктурного мониторинга, кто-то следил за обращениями пользователей, кто-то в непрерывном режиме тестировал руками функционал, кто-то поддерживал автотесты на селениуме и т.д.

Было две проблемы, за решение которых можно было взяться:

1. Руками проверять функционирование систем очень тяжело и дорого, надо этот процесс автоматизировать;
2. Летит безумное число оповещений из систем мониторинга, надо найти способ сократить число оповещений и выявить из них только “важные”.

На обе проблемы было дано решение.

Первая решилась развертыванием Jenkins, на нем запускались сборки тестов на Selenium, далее данные парсились и выводились в виде метрик в Zabbix, на которые были построены триггеры. По сработавшим триггерам приходили оповещения команде поддержки.

Вторая решилась написанием небольшого приложения, где в RabbitMQ падали все оповещения из систем мониторинга, далее они по жестко заданными правилам обрабатывались, результаты складывались в базу PostgreSQL, был построен небольшой дашборд на Bootstrap шаблоне, где были выведены эти события. Назвали его “Сервис-монитор”. После чего стоял тот же Zabbix, который следил за возникающими событиями и высылал уже команде предобработанные события в почту.

Для интегратора задача была решена относительно быстро и недорого. И команда гордилась тем, что сделала. В то время подобной автоматизацией мало кто мог похвастаться.

И вот однажды, на одной из встреч с одним из крупных заказчиков, руководитель проекта со стороны интегратора показал заказчику этот дашборд. Похвалился, как теперь они узнают о сбоях. Заказчик попросил доступ в дашборд и попросил оповещать его о критических сбоях, которые были не решены за 1 час.

Потом руководитель заказчика увидел данный дашборд и попросил настроить на него оповещение, если критический сбой длится более 2 часов.

Как в том мультфильме про Винни-Пуха. Они посидели еще немного, а потом еще немного. Заказчик попросил настроить еще несколько правил: особое правило для выходных дней, особое правило, если инцидент массовый, особое правило на обработку ночных событий. Вручную правила в коде писать было очень неудобно. Росло число правил, и росло время на поддержку системы.

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

Функциональный мониторинг

В 2015 году этот заказчик эксплуатировал более ста информационных систем, работал с двадцатью подрядчиками, а в эксплуатации были заняты более 50 инженеров внутри организации и 300 со стороны подрядчиков. Затраты на мониторинг были очень высокими, а эффективность – низкая из-за понятных сложностей в координации всех разрозненных процессов, ну, и, конечно, человеческого фактора, который делал систему оценки качества непрозрачной. При этом мониторинг был зачастую в руках подрядчиков, которым было невыгодно регистрировать инциденты, чтобы не портить свои KPI занижением SLA. 

У организации были две наиболее сильные боли, для которых она искала решение:

1. Пользователи систем обнаруживали проблемы в работе ИТ сервисов раньше специалистов эксплуатации;
2. Подрядчики иногда не регистрировали инциденты и завышали SLA.

Так как заказчику была известна система Сервис-монитор, он выбрал ее в качестве решения. За первые полгода к мониторингу были подключены 87 информационных систем (в среднем 3-7 тестов по 10 шагов на каждую систему), использовали более 7 000 метрик и более 2600 триггеров. Было написано более 50 разных правил эскалации. Все это позволило ответить на самый главный вопрос – работают ли услуги у заказчика и кто из подрядчиков “врёт”. Оказалось, что некоторые инциденты не замечались не только ночью, но и днем, если пользователи не писали о проблемах.

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

Там, где речь идет о финансовом и зарплатном учете, робот может просматривать данные, но никаких изменений вносить было нельзя. Представьте заработную плату сотруднику изменить, или уволить сотрудника. А размер заработной платы вообще вещь очень чувствительная. К таким данным надо относиться со всей заботой и безопасностью. Пришлось рядом с каждым подразделением, на той же инфраструктуре модернизировать препрод, сделать зеркало системы с похожими, но трансформированными данными. Уже сюда можно было вносить изменения и смотреть, как поведет себя система, и, если все работало (входные данные же практически неотличимы) мы знали, что и на проде всё тоже будет работать. Собственно, кейс подтверждался на 100%: сбои и на дублере, и на боевой системе происходили одновременно. 

Вот так, например, выглядит отчет о выполненных проверках:

Как говорится, аппетит приходит во время еды. Сначала была решена проблема с достоверностью и контролем подрядчиков, но теперь многократно возросла нагрузка на ситуационные центры, которые получили еще одну систему мониторинга.

“Сервис-монитор” у заказчика тогда не воспринимался как средство объединения данных из разных систем мониторинга. Эту функцию он исполнял внутри интегратора, где он реально помогал снизить число “мусорных” оповещений и повысить эффективность работы дежурной смены.

Когда у тебя 10 инженеров и 200 оповещений в день внутри нескольких проектов интегратора, это не одно и тоже, когда у тебя 100 систем, 350 инженеров и 10 тысяч оповещений от систем мониторинга в день у крупной организации, где миллионы клиентов и десятки тысяч сотрудников.

В 2016 году “Сервис-монитор” принесли показать в ситуационный центр заказчика и было понятно, что продукт еще очень и очень сырой. Внедрять его в том виде, каким он был, было невозможно.

В интеграторе было принято решение, что продукт надо развивать быстрее и было выделено дополнительное финансирование на расширение команды R&D. Были взяты на карандаш все требования ситуационного центра. А они были примерно такие:

1. Ролевая модель доступа к разным объектам инфраструктуры;
2. Написание правил эскалации из интерфейса, желательно в визуальном конструкторе;
3. Шаблоны оповещений для разных групп пользователей;
4. Возможность подключать разные системы мониторинга, такие как Zabbix или SCOM;
5. Автоматическая регистрация инцидентов в системе Сервис-деск не через почтовый канал;
6. Просмотр информации по инциденту (протокол) из интерфейса системы.

Заказчик в 2016 году архитектуру своего мониторинга видел так:

Требования были разумные и полезные для развития продукта.

В 2017 году все требования были в той или иной степени удовлетворены. В непрерывном режиме мы показывали, что у нас получается, руководителю ситуационного центра. Была заинтересованность, и она вселяла уверенность, что продукт будет полезен.

Так, например, в итоге стали выглядеть правила в конструкторе правил и действий:

Зонтичный мониторинг

У заказчика было очень много информационных систем, написанных разными разработчиками на разных языках, и у каждой информационной системы зачастую был свой мониторинг, который генерировал огромный поток событий, среди которых нужными и важными оказывались далеко не все (максимум 10%). Обычно за этот мониторинг уровня работы приложений, среды исполнения, баз данных, отвечали подрядчики.

На более низких уровнях: виртуализация, сервера, сети, были свои системы мониторинга, которые уже были на стороне заказчика. Данные с этих систем стекались в ситуационный центр. Также ситуационный центр мониторил обращения пользователей. И было так, что пошел массовый инцидент, инженеры ищут на уровне сети/серверов проблему, дальше дергают подрядчиков, те говорят, что у них все хорошо и проблема в ЦОДе. Знакомо такое?

Приходилось обмениваться скринами из своих мониторингов, показывать, доказывать, а время шло, инцидент висел в работе, клиенты оставались без сервиса. И так было несколько лет и воспринималось нормой.

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

На эту тему у меня есть картинка, которая говорит, что прогресс, если он нужен людям, победит.

Человек на картинке с красным флагом (или лампой) предупреждает людей о приближении автомобиля. Это требование Locomotive Act 1865. Его отменили в 1896 году, 31 год спустя запуска на дорогу первого автомобиля. Представьте, через какой протест прошли первые автостроители.

Наверное, руководитель ситуационного центра тогда также нелепо смотрелся таким же мужичком с красным флагом. Через два года, к слову сказать, ситуационный центр был трансформирован в центр эксплуатации, где работали менеджеры процессов и проектов, а не операторы. Из 10 экранов осталось два, и на них теперь висит ресурсно-сервисная модель с набором фильтров по бизнес-направлениям и дашборд здоровья основных систем.

Несколько лет назад, когда продукт встал в ситуационный центр, некоторые подрядчики скрытно саботировали использование “Сервис-монитора”. Да и некоторые специалисты ситуационного центра выбрали для себя тактику “во что бы то ни стало найти косяки в работе продукта”, который, как они думали, может их когда-то заменить. Таким образом, у продукта появились первые несколько сотен пользователей. И это было очень ценно, так как они помогали развивать продукт. Но работать в таких условиях было непросто. Приходилось за каждый релиз биться, не спать ночами, фиксить баги.

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

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

А вот такой экран здоровья систем появился не так давно:

Развитие продукта

Каждый функциональный пользователь системы “Сервис-монитор” хотел чего-то своего. Незаметно система стала “настольной” для большого числа специалистов, занятых в процессах поддержки, поменяла бизнес-процессы организации и изменила привычки людей. Что в 2015 году казалось «космосом», в 2016 году это представлялось очень сложной задачей, а в 2019 году уже эксплуатировалось.

Продукт развивался вместе с развитием требований заказчика. В 2019 году появилась автоматизация, был сделан большой рефакторинг бэкэнда и фронтенда, в 2020 году появился анализ логов, аналитические модели с использованием ML. Сейчас мы понимаем, кто наши конкуренты и что мы делаем, какое у нас позиционирование, что мы AIOps-платформа. Мы в 2019 году также изменили название, стали называться платформой MONQ, вывели продукт в отдельный спин-офф, получили статус резидента Сколково. В 2020 году стали наконец-таки операционно прибыльными, победили на Startrup Village, но это все уже другая история, которая относится к другой стадии стартапа.

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