Инцидент
Инцидент в ИТ — это незапланированное прерывание или снижение качества услуги, которое угрожает работе системы или бизнеса. Под инцидентом подразумевается любое событие, при котором в ИТ что-то работает неправильно и мешает процессам. Инциденты могут надолго парализовать работу компании, поэтому сроки их устранения считаются ключевым параметром в соглашениях об уровне сервиса (SLA).
Примеры инцидентов:
- Перестала работать электронная почта,
- Возникли проблемы с базой данных,
- Не открываются сайты в интернете,
- Вирус зашифровал данные на компьютере.
Наше мнение
- Бизнесу не нужны инциденты, поэтому их количество всегда должно стремиться к нулю.
- Повторяющиеся инциденты сигнализируют о хронической проблеме в системе. Задача ИТ-менеджера или руководителя технической поддержки — найти её и устранить, а не просто лечить симптомы. В этом поможет ведение статистики инцидентов с корректными описаниями задач и решений, что также полезно для обмена опытом с коллегами.
- Главное во время инцидента — восстановить работу сервиса в кратчайшие сроки. Если вернуть систему в исходное состояние сразу невозможно, необходимо искать обходные пути: ставить «костыли» или запускаться по временной схеме. Важно как можно быстрее вернуть пользователям возможность работать, а уже после разбираться с источником проблемы и дорабатывать решение.
- Процесс управления эскалацией — ключевой элемент в работе с инцидентами. Специалисты первой линии должны иметь чётко установленные предельные сроки для самостоятельного решения проблемы. Если сроки превышены, задача должна быть эскалирована (передана) вышестоящим специалистам. В некоторых случаях это нужно делать незамедлительно — например, при остановке системы, критически важной для всего предприятия. Такой подход снижает вероятность того, что сотрудники будут пытаться героически справиться с проблемой, которую быстрее решат на другом уровне. По мере приближения предельного срока к концу, специалист обязан уточнить у старшего коллеги, стоит ли передавать задачу дальше или продолжать решать её самостоятельно.
- Предельные сроки устранения инцидентов включают время, отведенное не только на решение проблемы, но и на оценку необходимости эскалациии. Специалисты первой линии должны иметь право передавать запросы на следующий уровень, если это ускорит решение. Однако важно предусмотреть механизм для предотвращения злоупотребления эскалацией, чтобы ответственность не перекладывалась слишком рано. Например, в некоторых контрактах на поддержку специалисты третьей линии могут возвращать запросы, которые не были должным образом обработаны второй линией. Таким образом, ответственность возлагается только по тем задачам, которые действительно требуют вмешательства третьего уровня.
- Разница между инцидентом и запросом на обслуживание определяется соглашением с бизнесом. Например, обычная замена картриджа в принтере может стать инцидентом, если бизнес-процессы компании зависят от бесперебойной печати, и её остановка приведет к убыткам. В таком случае требуется немедленное реагирование и приоритетная замена картриджа.
- Обращение в техническую поддержку — это обязанность, а не возможность. Если пользователь сталкивается с проблемой, мешающей работе, он должен немедленно сообщить о ней специалистам. Это правило должно стать частью корпоративной культуры компании. В противном случае ответственность за снижение эффективности или за простой в работе ложится на самого пользователя.
Поделиться 
