Как избежать простоев при поломке оборудования

С виду кажется, что это самая простая тема — случилась авария, устранил, записал, готово. Но дьявол кроется в деталях — начиная от того, кто "устранил", заканчивая работой после аварий — выявлением боттлнеков и уменьшением количества инцидентов.

Помимо простых запросов на изменение от пользователей (в простонародье — заявок), бывает такой класс событий, как аварии, которые ведут к простоям в критичных сервисах. Это и будем считать инцидентами.

Инцидент может быть как на стороне нашей инфраструктуры, так и по вине внешнего поставщика услуг — провайдера связи, электричества, охлаждения и прочих. Чтобы упорядочить работу с инцидентами, настроить единообразную работу с ними, я ввёл инцидентный регламент.

Весь документ приводить не буду, изложу только основные идеи.

Основная мысль регламента — инженер ведёт инцидент.

• Независимо от того, по чьей вине произошла авария или на чьей стороне отказ, у инцидента обязательно есть ответственный инженер. Он должен в любое время ответить, в каком статусе находится решение данного вопроса.
• Оформляется инцидент заявкой через систему заявок — Gandiva. Оформить инцидент может либо сам инженер, либо очень ограниченный круг ответственных пользователей. Всем остальным пользователям предлагается написать обычный запрос на изменение — заявку. Инженер при необходимости самостоятельно произведет переклассификацию.

После появления инцидента, инженер должен за 30 минут понять, что конкретно сломалось, попытаться самостоятельно решить или оставить запрос либо техподдержке поставщика услуг, либо в отдел ведущих инженеров компании — в зависимости от того, на чьей стороне авария.

После решения инцидента инженер закрывает заявку и заполняет информацию о времени начала и окончания инцидента, о причинах возникновения и методах решения.

Данная работа с инцидентами позволяет не только донести до инженера правила поведения в аварийных ситуациях, но и задаёт основы для расчёта времени доступности сервисов. Достаточно снять отчёт в Gandiva и получить всю необходимую информацию. Периодические отчёты по доступности сервисов помогают найти боттлнеки (узкие места) в инфраструктуре и выявить проблемных поставщиков услуг.

Уже есть опыт окончания взаимоотношений с провайдерами услуг связи по результатам повторяющихся инцидентов, не говоря уже о большом количестве запросов на поднятие качества услуг.

Следующий логичный шаг развития идеи — автоматическое создание инцидентных заявок при возникновении проблемы на системе мониторинга Zabbix.

Оригинал статьи