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