mkdocs/docs/Регламенты/Регламент на срабатывание систем мониторинга..md

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

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

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

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. Оповестить о разрешении ситуации руководителя отдела и ответственных