Перейти к содержанию

# Регламент на срабатывание систем мониторинга.

В обязанности дежурного инженера входит реагировать на срабатывание системы мониторинга.
Наблюдение ведется за инфраструктурными сервисами и электропитанием ЦОД.
Каналы получения алертов:
- Срабатывания выводится на панель в кабинете.
- Поступают уведомления в телеграмм
- Поступают уведомления на почту тех поддержки. По этим уведомлениям автоматически заводятся заявки.

### Действия инженера на срабатывание алерта:

1) Принять в работу заявку, заведенную на срабатывание. Если заявка не завелась (сломались интеграции, не работает автозавдение и т.д.), то завести ее самостоятельно в системе Intraservice сервис Alerting
2) Сориентироваться к чему относится сервис, какую функцию выполняет. Выяснить кто ответственный за данный сервис.
3) Оценить критичность сервиса. Если сервис является критическим оповестить руководителя отдела о проблеме.
4) Оповестить ответственных за сервис о срабатывании системы мониторинга. Оповещение выполняется по почте, телефону или месенджерах.
5) Приступить к решению проблемы, если это возможно силами дежурного инженера. Если решение проблемы не в компетенции инженера, то эскалировать проблему на инженера отвечающего за этот сервис.
Шаблон оповещения по почте.

    Здраствуйте. В (Дата ) (Время) произошло срабатывания системы мониторинга. Зафиксирована проблема (название проблемы) на хосте (название хоста)
    Прошу провести диагностику и устранить проблему.
    По завершении работ прошу предоставить информацию о решении проблемы.

### Классификация систем

#### Критически важные.

Работа критически важных систем напрямую влияет на работу ЦОД. SLA данных систем должен составлять 99.9%. При отказе данной системы восстановление работы является высшим приоритетом. К таким системам относятся:
1) Кластера виртуализации, СХД, ядро сети
2) Системы мониторинга инженерных систем
3) Система допусков, система отрисовки стоек, СОРМ

#### Инфраструктурные

Данные системы выполняют вспомогательную функцию. Отказ данных систем не влияет на работу ЦОД, но может нести в себе очень негативные последствия.
1) Отказ внутреннего мониторинга
2) Отказ инфраструктурных сервисов (бекапы, логирование, сервер автоматизации, сервер времени, ВПН)
3) Контроллер домена
4) Внутренние сервисы (некстклауд, ВМ менджеров, Гитлаб, прочее)

#### Тестовые

Данные сервисы находятся в разработке. Они стоят на мониторинге и готовятся к внедрению в продуктив. Они помечены как тестовые
При поступлении алертов от таких системы оповестить отвественного за разработку

### Классификация проблем

Проблемы от срабатывания системы мониторинга делятся на:
- Критические - недоступность хоста или сервиса, которые влияют на работу ЦОДА.
Виды проблем:
1) Сбой питания (отключение здания\зала\стойки). Одновременный выход БП из строя.
2) Перегрев
3) Сбой компонентов (рейд контроллер, материнская плата)
4) Недостаток ресурсов (диск, оперативка, сеть, цп), который привел к отказу сервиса.

- Системные - проблемы не ведущие к отказу в обслуживании. Обычно более мелкие проблемы.
  1) Сбой компонента. (ЦП, опертиваня память, диск, сетевой порт, вентилятор)
  2) Недостаток ресурсов, который не привел к отказу. (диск, оперативка, сеть, цп)
  3) Отключение вспомогательного процесса

### Действия инженера для решения проблемы.

Провести проверку доступности:
- Определить сервис и хост на котором она запущена.
- Произвести проверку доступности сервиса. (пинг, проверка через браузер, попытка подключится). В заявке указать результаты проверки
- Произвести проверку доступности хоста. (пинг, проверка IPMI). В заявке указать результаты проверки.
По результатам проверки доступности выполняем следующие действия.
- Если сервис и хост не доступны, то требуется:
1) Проверить возможность восстановления хоста. Если сервис является критическим, то оцениваем что быстрее, восстановить хост или перезапустить сервис на рабочем хосте.
2) Если можно быстро починить хост, то восстановить хост и сервис
3) Если быстрее перенести сервис, то запускаем его на рабочем хосте. Убедится что старый хост не доставит проблем.
4) Подтвердить штатную работу сервиса
5) Зафиксировать информацию о сбое хоста, восстановлении сервиса и диагностике
6) Оповестить о разрешении ситуации руководителя отдела и ответственных
- Если сервис не доступен, но хост доступен.
1) Провести глубокую диагностику сервиса
2) Если есть возможность восстановить штатную работу.
3) Если возможности нет, отключить сервис и востановится из бекапа
4) Зафиксировать информацию о сбоесервиса, восстановлении сервиса и диагностике
5) Оповестить о разрешении ситуации руководителя отдела и ответственных