WatchDog - автоматизация контроля инфраструктуры и операций Day2
- Заказчик:
- VTB.Cloud
- Руководитель проекта со стороны заказчика
- Поставщик
- WatchDog
- Год завершения проекта
- 2025
- Сроки выполнения проекта
- ноябрь, 2022 — ноябрь, 2025
- Масштаб проекта
- 2000 автоматизированных рабочих мест
- Цели
Формализовать паттерны сопровождения Инфраструктуры, Надежности, ИБ, Архитектуры в формате регулярного контроля чек-листов. С возможность отслеживать в динамике изменения для Стримов, ИС, критичностей в отдельном разделе “Тепловая Карта”.
Реализовать сервис предсказания по объему БД, сервис сравнения конфигураций (включая структуру БД), сервис запрета DDL-изменений, сервис Контроля Второй Рукой (КВР).
Упростить формирования отчётностей по отклонениям, с возможностью нотификации и автоматизации приведения к эталонным значениям.
Автоматизировать типовые задачи сопровождения (Day1\Day2), минимизировать риски ручных операций, включая контроль по зонтичным проблемам и рискам.
Создать инструмент run-time анализа для СУБД PostrgreSQL, “по примеру” activity monitor.
С возможностью формирования awr-отчетов, выдачей рекомендаций по настройкам\запросам\структуре.
-
17 продуктов на поддержке
-
1730 собираемых параметров
-
Более 50000 экземпляров СУБД и СП на контроле
-
Более 30 готовых отчетов
-
Более 2000 уникальных пользователей
-
Уникальность проекта
Новый подход и переосмысление всех процессов для классического сопровождения и перехода в автоматизацию.
Это не выстраивание четких границ между run и change, это возможность двустороннего направления постановки задач.
Автоматизация не работает на недостоверных данных, и поддержке необходимо вести и актуализировать источник данных.
Включая Ролевую Модель компании. Что, в современных реалиях фокуса на Информационную Безопасность - становится чуть ли не первостепенной задачей.
Объединить в одном месте регулярно собираемые и перепроверяемые данные (чек-листы и динамика), дать возможность администраторам Информационных Систем и СУБД\СП с этими данными работать (статусы и сами операции модификации), получать рекомендации, сравнивать контура, формируя ключевые отчетные метрики за секунды (вместо недель) – реализованная задача от нужд не бизнеса, а самой поддержки СУБД и СП.
В поглощении , разворот WatchDog’а - одна из ключевых задач, “что бы понять, как все плохо”.
- Использованное ПО
Astra Linux, React, GoLang, Python, PostgreSQL, Kafka, Redis, ClickHouse, Ansible
- Сложность реализации
-
Необходимость менять сознание. То, что казалось хорошей работой на протяжении 4-5 лет, с развитием систем и ростом объектов на поддержке, просто перестает таковым быть.
-
Коллег зачастую трудно убедить в необходимости внедрения перемен, для которых, к тому же, должны быть готовы процессы.
-
Модернизации занимают намного более длительное время, чем сама разработка.
-
Легаси, адаптация под множество сегментов, требования ИБ.
-
- Описание проекта
Сервис WatchDog (включая весь инструментарий) – прежде всего, закрытие нужд и потребностей dba, которые ежедневно выполняют типовые операции, решают инциденты, участвуют в ПСИ. Созданный dba для dba, прошедший путь от “БД инвентаризации” до полноценного “Портала” Надежности, ИБ, Архитектуры, представляет собой регулярный сбор всех параметров, их обработку (включая вычисления), вывод в удобный интерфейс. С возможностью “брать в работу”, “принимать в исключения”, настройками оповещений.
WatchDog начинал с охвата только по MS SQL и PostgreSQL, в 100 суммарных проверок.
На данный момент закрыт весь целевой стек VTB.Cloud (17 продуктов, 1730 проверок). Это не только СУБД, но и Сервера Приложений.
Каждый ответственный за продукт максимально заинтересован в наполнении своего шаблона. Формирование такой культуры - это долгий и не всегда очевидный путь.
Сбор происходит через “сервис-сборщика”, написанный на pyton. Есть возможность агентского сбора. Регулярность определяет ответственный за продукт в компании.
На основании собранных данных и выявления расхождений по Шаблонам (могут быть разные, в зависимости от критичности ИС, типов нагрузки, принятых исключениях (реализовано на стороне сервиса), информация выводится в раздел Тепловой Карты и, по принятому процессу, ведутся работы по устранению. Тем или иным подразделением, в чьей зоне ответственности отклонение. Согласно критичности параметра, контроль проходит несколько стадий (особенно актуально для допущения ИС к HS).
Возможность иметь актуальные данные, без прямого захода на сервера – в разы сокращает нагрузку на dba, минимизирует человеческий фактор.
Развитие подобного подхода дает импульс к еще большему упрощению типовых операций, недопущению инцидентов.
Сценарии автоматизации по типовым операциям, отчеты, возможность строить прогнозы (отдельный модуль предсказаний) по росту БД – очевидные шаги, призванные упрощать и не нести дополнительные траты на поддержку, при росте серверов
В Шаблонах и проверках, как очевидные параметры, так и те, которые рекомендует вендор, из-за которых были инциденты.
В дефиците или полном отсутствии инструментов анализа для СУБД PostgreSQL был создан и внедрен модуль PGAM.
С аналогичной WatchDog “идеологией”, упрощения жизни dba. На одной страничке любой мог получить моментальный анализ состояния работы экземпляра СУБД.
Сейчас это и рекомендации и возможно ретроспективы, с интегрированным расширением построения awr-отчетов.
- География проекта
Российская Федерация
- Дополнительные презентации:
- Group 44.pngGroup 46.pngGroup 47.pngGroup 48.pngGroup 49.pngGroup 50.pngGroup 51.pngGroup 52.pngimage_2025-10-16_18-01-16.pngimage_2025-10-16_18-01-17 (1).png