Чем инцидент отличается от бага

— Что такое инцидент? Каждый баг — это инцидент?

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

— То есть если баг заметили три человека за год, это не инцидент?

Даже если этот баг заметили вообще все пользователи, но он не ломает ключевую функциональность, это тоже не обязательно инцидент. Если на сайте начала моргать картинка, физически это раздражает, но на бизнес, репутацию или возможность пользоваться продуктом никак не влияет.

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

— Есть какая-то методология или бенчмарк, на которую можно ориентироваться при работе с инцидентами? Или каждая компания сама решает, что считать инцидентом?

Всё гибридно и ситуативно. Для разных компаний критично разное.

Есть стандартные критерии, которые описываются в практиках ITIL и других подходах к инцидент-менеджменту: недоступность чего-то ключевого или полная недоступность продукта. Это очень явные критерии, в реальности мы не всегда понимаем, насколько продукт аффектит то, что сломалось. Так бывает в крупных компаниях со сложной инфраструктурой и большим количеством сервисов — что-то отвалилось, но на что это влияет, сложно сказать, пока всё не загорелось.

Если горит, мы идём к бизнесу и спрашиваем: «Вот, что мы наблюдаем. Это насколько критично?»

Поддержка может предположить, что это инцидент, потому что пользователи страдают и напишут про нас в твиттер плохо, но бизнес смотрит на ситуацию шире: «Продажи идут, юридических и репутационных рисков не видим, значит, не критично». Остаётся исходить из этой позиции. Если даже на вроде ОЧЕВИДНЫЙ инцидент бизнес говорит: «Мы понимаем риски и готовы взять их на себя», — мы киваем головой. Для инцидент-менеджмента продуктовая позиция в этом смысле важнее учебника или собственного ощущения того, что происходит.

Это не значит, что каждый раз нужно бегать спрашивать: «А это точно инцидент?» Для этого должны быть инструкции — ранбук.


— Что должно быть в ранбуке?

Главное, чтобы был порядок действий. Например, если срабатывает алерт, мы открываем инструкцию и видим, куда бежать: сначала к дежурным, проверяем состояние сервиса, смотрим логи, перезапускаем нужный компонент, проверяем, восстановилась ли работа. Если ранбук помог, заканчиваем на этом и ни у кого не спрашиваем.

Если инструкций нет или они не помогают, тогда уже эскалируем проблему и идём к бизнесу согласовывать, как тушить будем.

Инцидент менеджмент — это как?

— А насколько вообще развит процесс инцидент-менеджмента в обычной российской компании? Ну в средней какой-то.

Проблема в том, что многие компании не понимают, зачем вообще это нужно. Выглядит как муть: зачем каждый раз дёргать разработку по каким-то непонятным поводам? Напридумывали инцидентов, баг зафиксируйте и никого не дёргайте.

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

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

Это нормально, если вы маленькие. По мере развития продукта зоны ответственности начинают расходиться: поддержка, разработка и инцидент-менеджмент расходятся по разным углам.


— Тогда давай разделим зоны ответственности: есть поддержка, продукт, сервис, бизнес и отдельный инцидент-менеджер. Какая у последнего роль?

Инцидент-менеджер не решает проблему технически. В этом его принципиальное отличие от поддержки.

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

А команда инцидент-менеджмента изначально не должна обладать глубокой технической экспертизой конкретного продукта. Их задача — реагировать на всплеск, понимать, где функция важная, где не очень; знать, кто за неё отвечает, и организовывать людей вокруг решения проблемы. Инц-менеджер должен точно знать, кто со стороны бизнеса и технических команд может подключиться к решению: кто отвечает за конкретный сервис, кто разработчик, кто деповс, кто технический директор, чем они могут помочь. Это вопросы «что, куда, кому», но не «как». Мы фасилитируем максимально быстрое завершение инцидента, но сами его не чиним.

В мире здорового человека команда инц-менеджмента должна быть достаточно независимой и подчиняться непосредственно техническому директору, чтобы оставаться непредвзятой и не зависеть от разработчиков. Только так можно чувствовать себя безопасно и не переживать, что ты сейчас укажешь на чей-то косяк, который привёл к катастрофе, а тебя потом обвинят в некомандной работе.

Что делать, если всё сломалось

— Я саппорт на линии, работаю в поддержке и подозреваю, что начинается инцидент. Что мне делать? Какие вопросы задавать, какую информацию собирать и как правильно подать сигнал?

Если ты как сапорт подозреваешь, что что-то отвалилось или стало недоступно, скорее всего, сама ты ничего не починишь: у тебя нет нужной экспертизы, доступов и прав. Поэтому главное правило очень простое: ничего не можешь сделать — эскалируй.

Ты можешь посмотреть, что происходит: если резко выросло количество обращений, посмотреть, что пишут пользователи, проверить, одна и та же ли там проблема, но на сбор информации не должно уходить много времени. Допустим, ты за три минуты посмотрела обращения и поняла: «У нас не работает кнопка, пользователи массово об этом пишут, вот несколько примеров» — этого уже достаточно, чтобы передать сигнал дальше.

Если у тебя есть вторая или третья линия поддержки, разработка — эскалируй туда. Параллельно сообщи своему руководителю. Не надо проводить полноценное расследование и собирать массив данных, прежде чем сообщить о проблеме. Инициативные могут дополнительно спросить: «Что отвечать пользователям? Какой номер у инцидента? Можем ли мы массово сообщить о проблеме?», но честно говоря, ответы на эти вопросы и так должны быть учтены в процессе.

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

— Что саппорту точно не стоит делать при подозрении на инцидент?

Разбираться самостоятельно, как это починить.

Если это действительно инцидент — технический сбой или критическая недоступность, — 99%, что причина находится за пределами компетенций поддержки. У тебя физически может нет доступа к инструментам, которые нужны для исправления проблемы.

Если ты в это время начинаешь долго выяснять детали, уточнять что-то у пользователя и самостоятельно искать решение, ты увеличиваешь время от начала инцидента до начала его устранения.

Это влияет на метрики доступности:

Особенно если ты один из немногих сотрудников на линии. А если таких сотрудников много, ситуация ещё хуже: вместо того чтобы эскалировать проблему, десять человек начинают одновременно её исследовать.

Поэтому твоя задача — быстро понять, что что-то сломалось, и быстро это эскалировать.

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

— Какой минимальный набор инструментов должен быть у поддержки, чтобы нормально работать с инцидентами?