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.png
Group 46.png
Group 47.png
Group 48.png
Group 49.png
Group 50.png
Group 51.png
Group 52.png
image_2025-10-16_18-01-16.png
image_2025-10-16_18-01-17 (1).png

Комментировать могут только авторизованные пользователи.
Предлагаем Вам в систему или зарегистрироваться.

Год
Предметная область
Отрасль
Управление
Мы используем файлы cookie в аналитических целях и для того, чтобы обеспечить вам наилучшие впечатления от работы с нашим сайтом. Заходя на сайт, вы соглашаетесь с Политикой использования файлов cookie.