Доступность посчитали одним способом и подняли с 97,3% до 98,5%

Что болело

Городской портал mos.ru и связанные с ним цифровые сервисы обслуживают больше миллиона уникальных пользователей в сутки — до 150 000 обращений за услугами. За этим стоят 35 самостоятельных бизнес-юнитов и 22 внешних подрядчика, у каждого своя зона ответственности и, что здесь главное, своя система мониторинга. Больше сотни информационных систем в эксплуатации, и единой картины их состояния не было.

Отсюда три конкретные боли, названные в источнике:

О сбое узнавали от пользователей, а не от систем. ИТ-подразделение обнаруживало падение сервиса по жалобам, а не по алертам — то есть последним.

Шум вместо сигнала. Одна система могла присылать несколько сотен оповещений в день, и понять, какое из них критично, а какое — фон, было нечем. 50 инженеров вручную разбирали события в каждом юните.

Дорогой и не поддающийся проверке ручной контроль. Проверка 80 систем по 5 сценариям и 10 проверкам в день — это 4 000 ручных проверок в сутки, каждая занимает минимум 20 минут. При этом подрядчики не были заинтересованы честно фиксировать простой: инциденты не регистрировались, особенно в ночные часы, а достоверность заявленного SLA оставалась на слово исполнителя.

Что хотели получить

Собрать разрозненный мониторинг подрядчиков в одну картину и на этой картине построить объективный расчёт доступности и SLA-отчётность — так, чтобы факт простоя не зависел от честности подрядчика, который его допустил.

Что сделали

Внедрение описано пятью шагами.

1. Синтетический мониторинг. Связка Zabbix + Jenkins + Selenium + Allure заменила ручные проверки: 87 информационных систем получили по 3–7 автоматических сценариев из 10 шагов каждый — от простой проверки авторизации до сложных сценариев с электронной подписью и разбором документов.

2. Единая точка сбора данных. Все системы мониторинга клиента подключили к Monq, получили один экран состояния и настроили автокластеризацию и дедупликацию событий — система стала обрабатывать до 30 000 событий и триггеров в сутки, определяя важность автоматически, а не руками дежурного.

3. Ресурсно-сервисная модель. Зависимости выстроили «сверху вниз» — от услуги для пользователя через сервис к инфраструктуре, а не наоборот, — и получили граф, на котором видно, какое конкретно падение критично влияет на доступность конечной услуги.

4. Автохилинг и эскалация. На типовые сбои Monq запускает скрипты самовосстановления (bash и REST-вызовы), а по остальным — оповещает по правилам: сбой короче 5 минут — письмо, дольше 5 минут — сообщение ответственному, дольше 10 минут — официальная регистрация инцидента в ITSM. У оповещений четыре уровня приоритета.

5. Автоматизация SLA-отчётности. Систему научили считать недоступность каждой услуги самостоятельно, с исключением плановых окон обслуживания, и регистрировать инцидент на нужного подрядчика или субподрядчика — на один проект их бывает до десяти.

Чем автоматизировали

Monq — платформа зонтичного мониторинга, ядро решения. Вокруг неё — существующий стек клиента, который не заменили, а подключили: 26 серверов Zabbix для инфраструктурного мониторинга, Jenkins для оркестрации синтетических тестов, Selenium для их выполнения, Allure для отчётности по тестам. Автовосстановление держится на собственных bash- и REST-скриптах, интеграция с ITSM — штатная.

Что получилось

Источник даёт таблицу «было — стало»:

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

Источник приводит и такое сравнение: раньше на регистрацию одного инцидента у сотрудника ситуационного центра уходило около 20 минут; чтобы вручную закрыть тот же объём, который сейчас обрабатывает Monq, понадобилось бы держать десять таких сотрудников одновременно.

Что не получилось и где было тяжело

Кейс с сайта вендора, и это определяет его границы. Сравнение «было — стало» независимо не проверить: и базовые 97,3%, и итоговые 98,5% — цифры заказчика, а по какой из трёх методик считалась доступность (по инцидентам, по инфраструктуре или синтетическими проверками), в тексте не сказано, хотя от выбора методики зависит сама цифра.

Источник не называет ни сроки внедрения, ни его стоимость, ни состав команды Monq на проекте. Про сопротивление системных администраторов закрытых контуров упомянуто одной фразой — что оно было и что его преодолели, без единой детали о том, как именно.

Что отсюда забрать

1. Мониторинг подрядчика — не мониторинг подрядчиком. Пока систему контроля SLA ставит и обслуживает та же сторона, чью работу она оценивает, у заказчика нет объективной картины. Здесь заказчик забрал измерение себе.
2. Синтетика — раньше, чем сложная аналитика. Прежде чем строить графы зависимостей и автохилинг, свели ручные проверки к автоматическим сценариям — это самый быстрый способ вообще начать видеть систему.
3. Порог эскалации завязан на длительность, а не на факт сбоя. 5 и 10 минут — грубый, но рабочий фильтр против шума: не каждый сбой требует немедленной регистрации инцидента.
4. Модель «сверху вниз». Строить граф зависимостей от пользовательской услуги к инфраструктуре, а не наоборот, — тогда сразу видно, какое падение действительно критично, а какое нет.

На какую зрелость это тянет

По AVLУправление доступностью и EVNМониторинг и управление событиями — третий уровень с элементами четвёртого. Порядок описан, работает по всем 87 системам разом, есть автоматический расчёт показателей и регулярная SLA-отчётность — это уже не разовый контроль, а встроенный в контур процесс.

До управляемого четвёртого уровня не хватает того, что скрыто источником: независимо проверяемой методики расчёта доступности и данных о том, насколько стабильны сами эти 98,5% на длинном отрезке, а не в моменте среза.

Оговорка обязательна: оценка сделана по одному публичному рассказу вендора о своём внедрении, а не по обследованию заказчика. Цифры внутренние и независимой проверке не поддаются.