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

Всем привет, это команда продуктов SimpleOne ITSM и ITAM. Это дело разберем как детектив. Сначала посмотрим на заявки и на то, как их закрывали, потом на расследование и разгадку, а в конце покажем, как увидеть ту же причину уже по второй заявке. Попробуйте вычислить её раньше Димы, улик по дороге будет достаточно.

Три поломки и пятнадцать заявок

Первым, в 9:20, пишет Олег из отдела продаж, у которого с утра расписаны созвоны с клиентами:

Третий раз за утро в переговорке пропадает звук на созвоне с клиентом. Клиент уже спросил, не из подвала ли я звоню.

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

В заявках каждый пишет о своём: про звук, портал, принтер. В карточку заявки попадают текст жалобы, время, имя и услуга, которую выбрали по симптому. Заявку про оборванный созвон относят к услуге «Видеосвязь», про портал — к «Доступу к сети и внутренним системам», про принтер — к «Печати». Так в поддержку попадают несколько заявок про три разные поломки.

Каждый чинит своё 

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

На каждый симптом у групп уже есть отработанный сценарий. Команда видеосвязи проверяет сервер конференций, видит, что он работает штатно и нагрузка обычная, и решает, что дело в рабочем месте: пользователю советуют переподключить гарнитуру и обновить клиент. У сетевых инженеров портал и 1С со своих мест открываются быстро, пинг до серверов проходит, дашборды мониторинга весь день зелёные, а по IP заявителя ничего не поймёшь, потому что весь офис сидит в одном VLAN. Заявителю предлагают перезагрузить компьютер и закрывают заявку с пометкой «не воспроизводится». К приходу инженера по печати принтер снова в сети, и драйвер переустанавливают на всякий случай.

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

Давайте соберем вручную журнал заявок с этого загадочного вторника:

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

Расследование: план рассадки, декрет и кабельный журнал

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

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

Портал опять висит. У кого-нибудь ещё так или только у нас на третьем?

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

Чтобы проверить догадку, Дима выгружает заявки за день и сверяет заявителей с планом рассадки, который АХО обновляло ещё до последнего переезда. Заодно он выясняет, кто из соседей тоже пострадал, но заявку не завёл. По плану у окна в бухгалтерии сидит Марина. Дима пишет ей в мессенджер и через полчаса получает автоответ: Марина полгода в декрете. За её столом теперь работает новый экономист, которого нет в плане, а компьютер на этом столе в учёте до сих пор числится за Мариной. Ещё одного заявителя приходится искать по внутреннему телефону.

По таблице MAC-адресов порт нашёлся бы за пару минут, если бы Дима знал, с каких компьютеров работают заявители. Но учёт рабочих мест расходится с реальностью так же, как план рассадки. Остаётся идти от розеток к портам. Кабельный журнал лежит в Excel на общем диске. Последнюю правку в нём полтора года назад сделал монтажник Вася, который с тех пор уволился, и у трети розеток в столбце «Порт» стоит «уточнить». Какие розетки на какой порт заведены, Дима в итоге выясняет у шкафа у лифта, сверяя маркировку патч-кордов. Там же, ближе к шести вечера, он находит и причину.

Поиск занял у Димы около четырёх часов, хотя данные для него в компании были, пусть и устаревшие: рассадка у АХО, учёт рабочих мест, розетки в журнале, порты на маркировке. Учёт оборудования ведётся, но отдельно от заявок, поэтому собирать сведения пришлось руками. Если сложить время поддержки за вторник, не считая перенесённых звонков Олега, выходит почти рабочий день:

15 заявок × 15 минут на разбор + 4 часа поиска = 7 часов 45 минут

Итак, что поддержка знала ещё до обеда

• три услуги работают через раз и восстанавливаются сами, ни одна не падает целиком;

• сервер конференций работает штатно, а у сетевых инженеров портал со своих мест открывается быстро;

• принтер то пропадает из сети, то возвращается и допечатывает очередь;

• мониторинг весь день зелёный;

• все заявители сидят рядом друг с другом, только ни в одной заявке этого не видно.

Как увидеть общую причину уже по второй заявке

Для этого заявке нужна цепочка из четырёх звеньев: пользователь, его рабочее место, оборудование, к которому это место подключено, и услуги, которые через это оборудование работают. В SimpleOne ITSM такую цепочку собирают в CMDB. Услуги из каталога там уже связаны с конфигурационными единицами (КЕ), так что остаётся добавить сетевое оборудование и рабочие места.

Каждый патч-корд заносить не нужно: такую базу перестанут обновлять раньше, чем она кому-то пригодится. Коммутатор доступа SW-3F-01 заводится как КЕ и связывается с услугами «Доступ к сети и внутренним системам», «Видеосвязь» и «Печать». Рабочие места достаточно завести укрупнённо, одной КЕ на кабинет. Принтеры и видеотерминал переговорной заводятся отдельными КЕ, и все они связываются с коммутатором зависимостью. Где сидит сам пользователь, подскажет местоположение в его карточке.

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

Представим тот же вторник с такой CMDB. В 10:00 Света пишет про портал. Сотрудник первой линии видит в её карточке кабинет 305, открывает КЕ «Ноутбуки бухгалтерии, каб. 305» и по карте зависимостей замечает, что этот кабинет и переговорную 310, откуда сорок минут назад Олег жаловался на пропавший звук, обслуживает один и тот же коммутатор [⚠ уточнить у продакта, есть ли подсказка, что по этому коммутатору уже открыта заявка]. Он заводит инфраструктурный инцидент, указывает SW-3F-01 в связанных КЕ и в 10:05 передаёт инцидент сетевым инженерам. Без такой базы, напомним, Дима заподозрил коммутатор только после обеда, а причину нашёл ближе к шести.

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

Связка заявок с оборудованием работает при трёх условиях: 

• местоположение пользователя остаётся актуальным после переездов, в том числе когда человек уходит в декрет и его стол занимает новый сотрудник;

• коммутаторы заведены в учёт, а их связи с кабинетами и услугами обновляются;

• первая линия не забывает указать в заявке оборудование: поле со связанными КЕ в инциденте необязательное, и оставить его пустым проще всего.

Резюме

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

А у вас по заявке можно понять, к какому коммутатору подключен её автор?