Три месяца назад я опубликовал историю про то, как не получилось из проекта сделать продукт, как он обратно превратился в проект и так и не вышел на рынок (прочитать об этом можно тут).
Второй подход к снаряду начался несколько лет назад, и пока полет нормальный. Уже есть клиенты, выручка, призовые места на международных конкурсах, интерес со стороны инвесторов. Историю развития продукта я бы хотел рассказать в этой статье. А также поделиться уроками, которые были выучены во время забега к продукту. Эта статья будет интересна и тем, кто строит продукт, и тем, кто занимается мониторингом в крупной организации. Так как мы строим именно систему для автоматизации, зонтичного мониторинга, функционального мониторинга и предиктивной аналитики.
Как родилась идея
Жила-была в 2014 году в одном интеграторе команда технарей, которая мечтала сделать свой продукт и выйти с ним на рынок. Нет, даже не так. Команда и не мечтала сделать свой продукт, она сначала увидела возможность помочь своим коллегам поддерживать информационные системы более эффективно.
Этот интегратор занимался тогда в основном поддержкой высоконагруженных систем с огромным числом пользователей и большим числом процессорных ядер на каждую систему. Поддержка была в лучших традициях жанра 24/7. В одной смене могли работать по 20-30 человек. Кто-то смотрел в экраны инфраструктурного мониторинга, кто-то следил за обращениями пользователей, кто-то в непрерывном режиме тестировал руками функционал, кто-то поддерживал автотесты на селениуме и т.д.
Было две проблемы, за решение которых можно было взяться:
- Руками проверять функционирование систем очень тяжело и дорого, надо этот процесс автоматизировать;
- Летит безумное число оповещений из систем мониторинга, надо найти способ сократить число оповещений и выявить из них только “важные”.
На обе проблемы было дано решение.
Первая решилась развертыванием Jenkins, на нем запускались сборки тестов на Selenium, далее данные парсились и выводились в виде метрик в Zabbix, на которые были построены триггеры. По сработавшим триггерам приходили оповещения команде поддержки.
Вторая решилась написанием небольшого приложения, где в RabbitMQ падали все оповещения из систем мониторинга, далее они по жестко заданными правилам обрабатывались, результаты складывались в базу PostgreSQL, был построен небольшой дашборд на Bootstrap шаблоне, где были выведены эти события. Назвали его “Сервис-монитор”. После чего стоял тот же Zabbix, который следил за возникающими событиями и высылал уже команде предобработанные события в почту.
Для интегратора задача была решена относительно быстро и недорого. И команда гордилась тем, что сделала. В то время подобной автоматизацией мало кто мог похвастаться.
И вот однажды, на одной из встреч с одним из крупных заказчиков, руководитель проекта со стороны интегратора показал заказчику этот дашборд. Похвалился, как теперь они узнают о сбоях. Заказчик попросил доступ в дашборд и попросил оповещать его о критических сбоях, которые были не решены за 1 час.
Потом руководитель заказчика увидел данный дашборд и попросил настроить на него оповещение, если критический сбой длится более 2 часов.
Как в том мультфильме про Винни-Пуха. Они посидели еще немного, а потом еще немного. Заказчик попросил настроить еще несколько правил: особое правило для выходных дней, особое правило, если инцидент массовый, особое правило на обработку ночных событий. Вручную правила в коде писать было очень неудобно. Росло число правил, и росло время на поддержку системы.
Так внутренний продукт интегратора фактически получил первого внешнего клиента. Именно тогда пришла мысль: а что, если из этого сделать продукт, с которым потом можно было бы выйти на рынок? До этого было еще очень долго, но команде нравилась своя работа и то, что получалось сделать что-то реально полезное.
Если у вас есть технические наработки, которые помогают вам, покажите их своим клиентам, возможно им они даже нужнее.
Функциональный мониторинг
В 2015 году этот заказчик эксплуатировал более ста информационных систем, работал с двадцатью подрядчиками, а в эксплуатации были заняты более 50 инженеров внутри организации и 300 со стороны подрядчиков. Затраты на мониторинг были очень высокими, а эффективность – низкая из-за понятных сложностей в координации всех разрозненных процессов, ну, и, конечно, человеческого фактора, который делал систему оценки качества непрозрачной. При этом мониторинг был зачастую в руках подрядчиков, которым было невыгодно регистрировать инциденты, чтобы не портить свои KPI занижением SLA.
У организации были две наиболее сильные боли, для которых она искала решение:
- Пользователи систем обнаруживали проблемы в работе ИТ сервисов раньше специалистов эксплуатации;
- Подрядчики иногда не регистрировали инциденты и завышали SLA.
Так как заказчику была известна система Сервис-монитор, он выбрал ее в качестве решения. За первые полгода к мониторингу были подключены 87 информационных систем (в среднем 3-7 тестов по 10 шагов на каждую систему), использовали более 7 000 метрик и более 2600 триггеров. Было написано более 50 разных правил эскалации. Все это позволило ответить на самый главный вопрос – работают ли услуги у заказчика и кто из подрядчиков “врёт”. Оказалось, что некоторые инциденты не замечались не только ночью, но и днем, если пользователи не писали о проблемах.
Есть одна распространенная проблема, с которой сталкиваются при внедрении мониторинга методом синтетических транзакций или непосредственной проверке функционирования через имитацию действий пользователей. Систему хочется проверять боевую, а вносить изменения тестовому пользователю нельзя. Так произошло с центральной бухгалтерской системой, построенной на базе 1С и Парусе. Проблема, как тестировать толстый клиент решилась быстро, а что делать со сценариями, где надо проводить платежи, но делать этого нельзя — было непонятно.
Там, где речь идет о финансовом и зарплатном учете, робот может просматривать данные, но никаких изменений вносить было нельзя. Представьте заработную плату сотруднику изменить, или уволить сотрудника. А размер заработной платы вообще вещь очень чувствительная. К таким данным надо относиться со всей заботой и безопасностью. Пришлось рядом с каждым подразделением, на той же инфраструктуре модернизировать препрод, сделать зеркало системы с похожими, но трансформированными данными. Уже сюда можно было вносить изменения и смотреть, как поведет себя система, и, если все работало (входные данные же практически неотличимы) мы знали, что и на проде всё тоже будет работать. Собственно, кейс подтверждался на 100%: сбои и на дублере, и на боевой системе происходили одновременно.
Он был бы не очень информативен, так как некоторые операции совершались редко. Нужно было выявить проблему раньше, чем ее заметит пользователь. А мониторинг реальных транзакций показал бы проблему, когда ее уже обнаружит пользователь.
Вот так, например, выглядит отчет о выполненных проверках:
Как говорится, аппетит приходит во время еды. Сначала была решена проблема с достоверностью и контролем подрядчиков, но теперь многократно возросла нагрузка на ситуационные центры, которые получили еще одну систему мониторинга.
“Сервис-монитор” у заказчика тогда не воспринимался как средство объединения данных из разных систем мониторинга. Эту функцию он исполнял внутри интегратора, где он реально помогал снизить число “мусорных” оповещений и повысить эффективность работы дежурной смены.
Когда у тебя 10 инженеров и 200 оповещений в день внутри нескольких проектов интегратора, это не одно и тоже, когда у тебя 100 систем, 350 инженеров и 10 тысяч оповещений от систем мониторинга в день у крупной организации, где миллионы клиентов и десятки тысяч сотрудников.
В 2016 году “Сервис-монитор” принесли показать в ситуационный центр заказчика и было понятно, что продукт еще очень и очень сырой. Внедрять его в том виде, каким он был, было невозможно.
Самые ценные советы по развитию продукта дают те, кто от него отказывается.
В интеграторе было принято решение, что продукт надо развивать быстрее и было выделено дополнительное финансирование на расширение команды R&D. Были взяты на карандаш все требования ситуационного центра. А они были примерно такие:
- Ролевая модель доступа к разным объектам инфраструктуры;
- Написание правил эскалации из интерфейса, желательно в визуальном конструкторе;
- Шаблоны оповещений для разных групп пользователей;
- Возможность подключать разные системы мониторинга, такие как Zabbix или SCOM;
- Автоматическая регистрация инцидентов в системе Сервис-деск не через почтовый канал;
- Просмотр информации по инциденту (протокол) из интерфейса системы.
Заказчик в 2016 году архитектуру своего мониторинга видел так:
Требования были разумные и полезные для развития продукта.
В 2017 году все требования были в той или иной степени удовлетворены. В непрерывном режиме мы показывали, что у нас получается, руководителю ситуационного центра. Была заинтересованность, и она вселяла уверенность, что продукт будет полезен.
Нам очень повезло, что заказчик не выбрал другой более зрелый продукт известного западного вендора. Если бы мы не напоминали о себе, скорее всего так бы и произошло.
Так, например, в итоге стали выглядеть правила в конструкторе правил и действий:
Зонтичный мониторинг
У заказчика было очень много информационных систем, написанных разными разработчиками на разных языках, и у каждой информационной системы зачастую был свой мониторинг, который генерировал огромный поток событий, среди которых нужными и важными оказывались далеко не все (максимум 10%). Обычно за этот мониторинг уровня работы приложений, среды исполнения, баз данных, отвечали подрядчики.
На более низких уровнях: виртуализация, сервера, сети, были свои системы мониторинга, которые уже были на стороне заказчика. Данные с этих систем стекались в ситуационный центр. Также ситуационный центр мониторил обращения пользователей. И было так, что пошел массовый инцидент, инженеры ищут на уровне сети/серверов проблему, дальше дергают подрядчиков, те говорят, что у них все хорошо и проблема в ЦОДе. Знакомо такое?
Приходилось обмениваться скринами из своих мониторингов, показывать, доказывать, а время шло, инцидент висел в работе, клиенты оставались без сервиса. И так было несколько лет и воспринималось нормой.
И тут приходит зонтичная система аналитики и говорит, что все их проблемы быстро будут решены, что одно информационное пространство быстро всех помирит, что можно будет быстро расследовать инцидент.
На эту тему у меня есть картинка, которая говорит, что прогресс, если он нужен людям, победит.
Человек на картинке с красным флагом (или лампой) предупреждает людей о приближении автомобиля. Это требование Locomotive Act 1865. Его отменили в 1896 году, 31 год спустя запуска на дорогу первого автомобиля. Представьте, через какой протест прошли первые автостроители.
Наверное, руководитель ситуационного центра тогда также нелепо смотрелся таким же мужичком с красным флагом. Через два года, к слову сказать, ситуационный центр был трансформирован в центр эксплуатации, где работали менеджеры процессов и проектов, а не операторы. Из 10 экранов осталось два, и на них теперь висит ресурсно-сервисная модель с набором фильтров по бизнес-направлениям и дашборд здоровья основных систем.
Несколько лет назад, когда продукт встал в ситуационный центр, некоторые подрядчики скрытно саботировали использование “Сервис-монитора”. Да и некоторые специалисты ситуационного центра выбрали для себя тактику “во что бы то ни стало найти косяки в работе продукта”, который, как они думали, может их когда-то заменить. Таким образом, у продукта появились первые несколько сотен пользователей. И это было очень ценно, так как они помогали развивать продукт. Но работать в таких условиях было непросто. Приходилось за каждый релиз биться, не спать ночами, фиксить баги.
Трудности обязательно будут. Преодолеть их поможет только трудолюбие и стремление к результату.
Вот, например, самый ненавистный экран для слабых подрядчиков по эксплуатации, где заказчик сейчас сам проверяет уровень сервиса. Тут показан расчет, по которому идет определение штрафных санкций по контракту, если SLA не выполнен:
За год работы системы в контуре заказчика помимо двух тысяч функциональных роботизированных проверок, нескольких сотен правил, более тысячи пользователей, система на борт себе взяла управление ресурсно-сервисной моделью. Вот так она выглядит со стороны. Мне кажется, это практически искусство.
А вот такой экран здоровья систем появился не так давно:
Развитие продукта
Каждый функциональный пользователь системы “Сервис-монитор” хотел чего-то своего. Незаметно система стала “настольной” для большого числа специалистов, занятых в процессах поддержки, поменяла бизнес-процессы организации и изменила привычки людей. Что в 2015 году казалось «космосом», в 2016 году это представлялось очень сложной задачей, а в 2019 году уже эксплуатировалось.
Продукт развивался вместе с развитием требований заказчика. В 2019 году появилась автоматизация, был сделан большой рефакторинг бэкэнда и фронтенда, в 2020 году появился анализ логов, аналитические модели с использованием ML. Сейчас мы понимаем, кто наши конкуренты и что мы делаем, какое у нас позиционирование, что мы AIOps-платформа. Мы в 2019 году также изменили название, стали называться платформой MONQ, вывели продукт в отдельный спин-офф, получили статус резидента Сколково. В 2020 году стали наконец-таки операционно прибыльными, победили на Startrup Village, но это все уже другая история, которая относится к другой стадии стартапа.
Если вы сейчас читаете эту статью и у вас есть наработки, которые кому-то упрощают жизнь, попробуйте о них рассказать другим. Возможно они нужны еще кому-то. Не теряйте возможностей, самое страшное, что произойдет, вы просто потеряете время на рассказ о них. Внимательно слушайте критику, она поможет вам сфокусировать ваш продукт на клиента. Не теряйте надежду и не оставляйте коммуникацию с теми, кто дал вам фитбэк по вашей идее, особенно с теми, кто высказался в негативном ключе. Ну и если есть идея, прототип, есть понимание клиента, приготовьтесь к тяжелой работе. Дорогу осилит идущий.
