В работе любого сервиса возникают аварийные ситуации. Полностью обезопасить себя от них невозможно, даже если перестать что-либо изменять вовсе. А раз количество инцидентов нельзя свести на нет, вокруг них нужно выстроить такой процесс, который будет приносить пользу.
#incident
Многие команды выбирают такую парадигму: при возникновении проблем сначала запустить откат,а потом уже разбираться,в чём заключается проблема.Подавляющее кол-во инцидентов лечится откатом сервисов,те это по умолчанию будет экономить время на восстановление→минимизировать убытки.
Алгоритм работы над увеличением uptime очень похож на любую другую оптимизацию:
измеряй → анализируй → пробуй улучшить → оценивай результат
#uptime
Когда говорят об uptime/downtime,часто упоминают показатель MTTR (mean time to repair) — среднее время от начала инцидента до окончания.Проблемы с ним начинаются прямо с первого слова в аббревиатуре.Учитывая, что все инц. разные,усреднение ни о чем в системном плане нам не скажет
Иногда, чтобы все это просчитать/спрогнозировать делают "карту рисков", где у каждого сценария (который смогли предположить) есть вероятность + эффект воздействия (даунтайм короткий/длинный, потеря данных, репутационные потери etc).
Другой прием, который можно использовать — классификация прошедших инцидентов. Сейчас много говорят о том, что очень полезно писать "разборы" (post mortem) инцидентов, где анализируются причины проблемы, действия людей, прорабатываются возможные будущие действия.
Но чтобы быстро взглянуть на причины всех аварий за прошлый период, удобно просуммировать их длительность с группировкой по "классам" проблем и там, где больше всего downtime, принимать меры.
Какие могут быть проблемы при инцидентах и что делать:
- человеческие ошибки: снижать кол-во ручных действий в проде
- неудачные релизы: улучшать тестирование(в т.ч. нагрузочное)
- ошибки в приложениях: чинить утечки, крэши, зависания
- сеть: купить оборудование, нанять сетевиков
Какие еще могут быть проблемы при инцидентах и что делать:
- базы данных: нанять DBA, позаботиться об отказоустойчивости, купить железо получше
- ДЦ: думать про резервный/переезд
- внешние воздействия: запастись проксями, замониторить срок действия доменов/сертификатов
На мой взгляд, приоритет – одна из самых важных категорий в контексте работы с инцидентами. В части критериев, кмк, нет универсальных решений, потому что должны быть учтены особенности продукта и потребности бизнеса.
Можно работать даже с двумя приоритетами - критичным и нормальным. Гораздо важнее прописать, как определить, к какому из них отнести конкретный инцидент.
Во-первых, определение приоритета не должно выполняться «на глаз». Во-вторых, в приоритетах должны мыслить все участвующие стороны, как минимум, разработка и поддержка.
Один из профитов работы с четко прописанными приоритетами в том, что как минимум серьезные проблемы не останутся без внимания. Когда все обращения льются в одном потоке, критичную для бизнеса ситуацию можно упустить.
Второй важный плюс четко прописанных приоритетов – саппорт перестает отвлекать своих разработчиков на каждую мелочь. Если проблема не критичная, значит, ее обсуждение можно отложить до ближайшей встречи, PBR или передать на проработку продакт-менеджеру.
При этом мне кажется важным не относиться к регламенту как к чему-то железобетонному. Регламент – это инструмент, который должен работать во благо, а не существовать где-то в параллельной вселенной.
Подводя итоги, Incident management process базируется на трех слонах и черепахе:
- приоритизация проблем
- общий язык для обмена информацией между командами
- люди, готовые поддерживать процесс
- регистрация инцидентов в любом виде
#IncidentManagement
Валентина Казачкова