Playbook инцидентов для малого IT

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

Playbook инцидентов - это не толстый регламент для корпорации. Для малого ИТ это короткая инструкция: как распознать проблему, кого предупредить, что проверить первым, когда эскалировать владельцу, что записать после восстановления. Такой документ экономит время именно тогда, когда у команды нет спокойствия на размышления.

Что считать инцидентом

Не каждая заявка - инцидент. У одного сотрудника не печатает принтер - это обращение поддержки. Не открывается 1С у всей площадки - инцидент. Не проходит оплата на киосках - инцидент. Пропал интернет в филиале, телефония не принимает звонки, сайт не отправляет заявки, касса не синхронизируется - все это требует отдельного порядка.

Важно договориться о признаках заранее. Иначе каждый раз начинается спор: «это критично или подождет?» Для малого бизнеса достаточно трех уровней: критично для работы с клиентами, мешает части сотрудников, обычная заявка. Чем проще шкала, тем выше шанс, что ей будут пользоваться.

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

Playbook для падения 1С

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

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

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

В playbook стоит указать, кто может разрешить восстановление из копии, потому что это может означать потерю части данных за последний период. Технически восстановить можно быстро, но бизнес должен понимать последствия.

Playbook для интернета

Когда пропал интернет, сотрудники часто начинают перезагружать все подряд. Лучше идти по короткой цепочке.

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

Если площадка работает с клиентами, в playbook должен быть ручной режим: как принимать заявки, что делать с оплатой, кого предупредить, какие операции нельзя проводить без связи. Это уже не чисто ИТ, но без такого блока сотрудники будут импровизировать.

Для сетей клубов полезно хранить контакты провайдеров по филиалам, номера договоров, адреса оборудования и фото стойки. В аварии фраза «там черная коробочка сверху» съедает больше времени, чем кажется.

Playbook для телефонии

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

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

После восстановления важно проверить не только «звонок проходит», но и запись, история в CRM, уведомления о пропущенных. Иначе часть воронки останется сломанной.

Эскалация без паники

В playbook обязательно должен быть блок «кого и когда зовем». Не список всех телефонов компании, а конкретные роли: администратор площадки, ИТ-подрядчик, управляющий, владелец, провайдер, поставщик 1С, телефония.

Формат сообщения тоже помогает. Вместо «ничего не работает» лучше: что затронуто, где, когда началось, сколько пользователей, что уже проверили, нужен ли бизнес-режим. Это экономит первые десять минут разговора.

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

Что записать после инцидента

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

Не превращайте разбор в поиск виноватого. Цель - улучшить процесс: добавить мониторинг, обновить контакт провайдера, проверить бэкапы, купить резервный роутер, убрать устаревшую инструкцию. Один маленький вывод после каждого инцидента постепенно делает ИТ устойчивее.

Вместо заключения

Playbook для малого ИТ должен быть коротким, живым и доступным в момент аварии. Начните с трех сценариев: 1С, интернет, телефония. Опишите первые проверки, ответственных, ручной режим и эскалацию владельцу. Этого уже достаточно, чтобы в следующий раз команда действовала спокойнее.

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