добавлен регламент

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

@@ -0,0 +1,68 @@
+
+В обязанности дежурного инженера входит реагировать на срабатывание системы мониторинга.
+Наблюдение ведется за инфраструктурными сервисами и электропитанием ЦОД.
+Каналы получения алертов:
+- Срабатывания выводится на панель в кабинете.
+- Поступают уведомления в телеграмм
+- Поступают уведомления на почту тех поддержки. По этим уведомлениям автоматически заводятся заявки.
+
+### Действия инженера на срабатывание алерта:
+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) Оповестить о разрешении ситуации руководителя отдела и ответственных