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

### Действия инженера на срабатывание алерта:
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) Оповестить о разрешении ситуации руководителя отдела и ответственных