Привет! Меня зовут Арвидас Гафиулин, я руководитель отдела эксплуатации и развития ИТ-инфраструктуры в Яндексе. Важнейшее направление работы отдела — наша внутренняя служба поддержки, ServiceDesk. Именно команда SD отвечает за то, чтобы у сотрудников компании была возможность работать из офиса или на удалёнке со всеми необходимыми доступами, оборудованием и комфортом. В среднем служба получает десять тысяч запросов каждую неделю и постоянно работает над тем, чтобы решать их качественнее и быстрее, а также предотвращать новые инциденты, устраняя корни проблем.

Мы уже писали на Хабр о том, как работает вендомат ServiceDesk, выдающий расходники и компьютерные аксессуары без согласований и бумажек, а сегодня расскажем, как выглядит работа службы изнутри и какие технические решения живут у ServiceDesk «под капотом», помогая нам автоматизировать львиную долю задач. Добро пожаловать под кат, если вам интересно, откуда техподдержка знает, кому уже пора апгрейдить технику, а кому придётся ещё немного подождать, у кого устарела версия ОС или доживает последние дни жёсткий диск, какие автоматизации мы можем создавать на основе пользовательских данных, а главное — от скольких часов ожидания и кругов согласований это избавляет сотрудников Яндекса.


^{Welcome-зона службы ИТ-поддержки в одном из офисов}

Рассказываю о нашем хозяйстве

Вернёмся на полтора-два года назад. Яндекс уже превратился в огромную компанию, служба поддержки тоже была большой, но неструктурированной: все занимались всем понемногу. Например, некоторые сотрудники с узкой специализацией много времени тратили совсем не на те задачи, в которых были спецами. И, наоборот, были люди без специализации, которым периодически прилетали задачи повышенного уровня сложности. Мы поняли, что пришло время сегментировать поддержку на классические уровни, описанные в best practices ITIL.

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

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

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

Чтобы получить помощь на месте, пользователи также могут сами прийти в зону Welcome. Здесь работает электронная очередь: сотруднику нужно пикнуться бейджем в специальный интерактивный экран с котиком и немного подождать. Ожидание занимает не больше 15 минут. Заранее заводить задачу или записываться не нужно — все хлопоты возьмут на себя специалисты onsite-поддержки.


^{Котик для авторизации в зоне Welcome и вендомат с расходниками и аксессуарами}

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

Мы поддерживаем больше 15 000 пользователей, 20 000 ноутбуков и примерно 700 переговорных комнат с оборудованием для видеосвязи. Яндекс исповедует свободу выбора ОС, из-за чего у специалистов ServiceDesk, обеспечивающих доступность рабочих инструментов, всегда много дел: они выравнивают автоматизации и технические возможности для ПО. 60% сотрудников в компании работает на Mac, 35% — на Windows, 5% — на Linux. Новым сотрудникам не навязывают выбор ОС — они просто получают компьютеры с той системой, которую выбрали, без отдельных согласований и обоснований.

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

Ныряем в озеро данных

Если посмотреть на структуру задач ServiceDesk (те самые 10 тысяч запросов в неделю), мы увидим, что около 20% из них решаются на аутсорсе, 30% — силами людей внутри (из них около 10 задач в неделю — сложные проблемы), а ещё 50% полностью автоматизированы. Расскажу, за счёт чего удалось добиться такой степени автоматизации.

В нашем ведении находится около 30 сервисов для пользователей, и их количество лишь растёт. Мы отвечаем за пользовательские компьютеры, дополнительное оборудование и расходные материалы, доступы к внутренним ресурсам, учётные записи, сертификаты, VPN, Wi-Fi, компьютеры в общих зонах, софт (локальный и облачный) и облачные хранилища, корпоративную почту, оборудование в переговорных комнатах, сервис печати, офисную сетевую инфраструктуру, вывод новых сотрудников, техническую поддержку мероприятий и многое другое. Обращения от пользователей поступают по четырём каналам:

— через формы на внутреннем портале техподдержки,
— в мессенджере,
— в почте,
— по телефону.

Все они превращаются в тикеты и попадают в Личный кабинет хелпа — наш (довольно своеобразный) аналог crm-системы, о котором чуть позже.

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

И здесь нам повезло. Мы работаем в data-driven компании, где любят собирать и анализировать данные, а ещё руководствуются принципом здорового альтруизма по отношению к другим командам. Если в информации нет ничего супер чувствительного, получить к ней доступ несложно — нужно просто договориться, объяснить свою мотивацию и, скорее всего, вам не откажут. Почти у всех внутренних сервисов есть API, через которые можно настроить передачу и регулярное обновление данных.

Явление CMDB

Итак, в Яндексе есть системы с интересными нам данными, например:

• Стафф, где хранится информация о подразделении, должности сотрудника и его контакты;
• ERP с данными об оборудовании и ПО, которое использует сотрудник;
• Система с информацией о сертификатах;
• Система с настройками телефонии;

И так далее, систем очень много. Пару лет назад мы задумались, что нам не хватает инструментов для работы с ними (делать выгрузки из ITSM, JAMF и др. по отдельности долго и неудобно), и решили объединить все данные в одной CMDB — configuration management database. Такие базы описаны в ITIL и используются как единый каталог, содержащий информацию обо всех ИТ-объектах компании и связях между ними. В классическом подходе CMDB может содержать информацию о:

• серверах и рабочих станциях,
• периферийном оборудовании и комплектующих,
• софте,
• локальных и облачных ИТ-сервисах,
• сетевом оборудовании,
• принтерах, сканерах, МФУ и так далее.

При этом у нас в фокусе внимания всегда находились люди, а не оборудование. Мы включили в базу данные о пользователях, поэтому нашу CMDB можно назвать неканоничной. Скорее, по мере роста у нас получился data-lake на корпоративных MapReduce-кластерах для всего ServiceDesk, в который мы можем ходить со сквозными запросами. Например, узнать сколько лицензий ПО выдано сотрудникам, и когда они в последний раз пользовались своими приложениями. Во многих компаниях ответ на такой вопрос потребует выгрузки нескольких Excel-отчётов, потом их нужно будет сопоставить между собой, из-за каких-то ограничений может вообще ничего не получиться, а мы решаем эту задачу за 5–10 минут, просто написав запрос на sql–подобном языке.

При этом CMDB консолидирует данные не только из внутреннего контура Яндекса, но и из внешних сервисов, например, Zoom и Office 365. Принципы интеграции здесь те же. Мы используем API, которые предоставляют крупные облачные сервисы, а если приходится — что-то дописываем. Такой уровень контроля над внешними сервисами позволяет делать всякие интересные штуки. Например, в Яндексе, как и во многих других компаниях, во время пандемии кратно возросло количество пользователей Zoom. Периодически они жаловались на качество связи, а мы думали, как им помочь. В итоге мы построили дашборды на базе выгрузок из CMDB, которые отражают качество ВКС в реальном времени. Благодаря этим данным мы можем локализовать проблемы, понять, происходят ли сбои на стороне Zoom, и в этом случае создать для них сервисный тикет, или же дело в машине пользователя, и нужно поковыряться в ней.

С данными из внутренних систем тоже можно сделать много интересного, например, мы смотрели, с какими вопросами в техподдержку чаще всего обращаются сотрудники, которые вышли на работу неделю, две недели или месяц назад, чтобы разобраться, какие моменты стоит исправить сразу на входе. Аналитика помогает тюнить программу адаптации со стороны SD, делать онбординг более комфортным для новичков.


^{Если оборудование в офисе сломалось, есть быстрый способ сообщить об этом нам}

Например, мы получали много вопросов от новичков о том, где в одном месте можно посмотреть все наши услуги и оставить заявку, и в ответ на эти вопросы запустили внутренний портал. Также мы начали устанавливать по умолчанию часть ПО, которое раньше выдавалась по запросу. Тот же Office 365 раньше не ставили сразу всем, но запросов на него было очень много, и теперь офисный пакет стоит на каждом новом ноутбуке. Некоторые кастомизируемые настройки образа системы мы тоже корректируем после фидбека от пользователей.

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

Личный кабинет хелпа

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

Итак, в ServiceDesk вышел новый сотрудник и получил свое первое обращение — кому-то в Яндексе потребовалось завести корпоративный номер телефона. Как обычно решается такая задача? Новичок, который ещё почти никого не знает, должен написать администратору, администратор через какое-то время увидит заявку, возможно, задаст уточняющие вопросы, и потом уже выдаст номер. И так в каждой из систем: когда нужно получить сертификат от сотрудника СИБ, лицензию от администратора сервиса на Zoom и т. д. Сотрудник может запутаться, времени на всё уходит много, пользователи долго ждут согласований и в целом не рады.

Личный кабинет хелпа устроен иначе. Когда к нам приходит новый сотрудник, мы сразу настраиваем для него список разрешённых действий. Действий?! Всё верно, личный кабинет связан через API со всеми нужными внутренними системами, поэтому в интерфейсе появится кнопка «Выдать номер телефона». Одна кнопка вместо 20 сложных настроек в CUCM — ничего не получится сломать и сделать лишнего тоже не получится, потому что действия преднастроены. Благодаря консолидированным данным из CMDB мы можем выстраивать сложные критерии для разных категорий сотрудников ServiceDesk и тонко разграничивать, кто и что может сделать в личном кабинете. А главное — заявки не болтаются где-то между службами, пользователи быстро получают нужные услуги.


^{Оффтоп: во время пандемии мы ввели дополнительную, более просторную зону ожидания, чтобы сотрудникам было проще сохранять социальную дистанцию}

Автоматизируй это

Два наших столпа: CMDB и Личный кабинет хелпа стали хорошей базой для дальнейшего совершенствования работы службы и создания автоматизаций. Мы собрали статистику и посмотрели, как много времени отнимают элементарные повторяющиеся операции. Поняли, что для многих из них можно написать специальные скрипты (которые мы зовем роботами), чтобы полностью закрыть часть задач автоматикой, а ещё часть дел попробовать передать нейронной сети.

Так мы решили делать с помощью нейросети первичную разметку support-тикетов. В службе нет специалистов по ML, поэтому проект был реализован на чистом энтузиазме ребят, которые хотели погрузиться в тему и сделать ServiceDesk лучше. С технической точки зрения в Нейрохелпе (так мы назвали нашу нейронку) нет ничего супер сложного, но результаты его работы нам очень даже нравятся.

Сеть может определить, относится тикет к ИТ-поддержке или его нужно направить в смежное подразделение, а также требуется ли для решения проблемы участие специалиста или можно использовать автоответ с инструкцией. Например, если у сотрудника сломался VPN, в 90% случаев это решается простой переустановкой. Здесь робот может сразу отправить инструкцию в тикет, что сэкономит массу времени и нам, и нашим пользователям. При этом мы не маскируем роботов под людей и честно пишем, что ответ автоматизированный.

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

1. Вывод новых сотрудников. Здесь за счёт роботов делается многое — они создают параллельные задачи для разных подразделений с нужными связями, что позволяет сэкономить до недели в таком большом процессе. Все доступы и учёные записи во внутренних системах тоже создаются автоматически.
2. Услуги на портале. Пару лет назад мы запустили внутренний портал ServiceDesk для сотрудников Яндекса с каталогом услуг и возможностью оставить заявку на любую из них. Часть услуг полностью автоматизирована, например, выдача большинства типов ПО. А в заявке на получение или апгрейд оборудования робот пройдётся по дереву решений и проверит её на соответствие формальным критериям.
3. Приложение Self Service Для macOS позволяет выполнять скриптовые задачи без привлечения техподдержки: устанавливать ПО и чинить мелкие неисправности. Например, если сломался поиск Spotlight, можно с помощью одной кнопки очистить кэш и перезапустить индексирование. Обычно же такая задача решается через терминал, и нужно либо присылать сотруднику скрипт, либо подключаться к устройству.
4. Для ноутбуков на Windows есть интерфейс, который отслеживает, как долго загружается ОС при включении. Часто долгое время загрузки свидетельствует о том, что на компьютере скоро откажет диск. Мы настроили мониторинг, который реагирует, если компьютер загружается дольше нормы. По результатам робот создаёт тикет, и проблема решается превентивно.
5. Удалённая автоматизированная диагностика ПК. Например, если есть проблемы с Wi-Fi, пользователь может нажать одну кнопку в SelfService, после чего запустится диагностика, и робот создаст тикет, к которому будут прикреплены все логи.
6. ПО для удалённого управления планшетами — Mobile device management. Мы написали собственную систему управления устройствами на iOS, которая автоматизирует работу с планшетами в переговорных: установку обновлений, перезагрузку и настройку.

Заключение

Итак, настало время поделиться результатами в цифрах. Сколько времени и сил автоматизация экономит нам и нашим пользователям?

• роботы выполняют работу, сопоставимую по объему с трудом 80 сотрудников техподдержки,
• без участия людей решается от 50% до 60% всех задач (в зависимости от направления работы),
• средняя скорость решения инцидентов сократилась с 60 до 24 часов, а по отдельным направлениям (например, по выдаче популярного ПО) — до нескольких минут.

Мы уверены, что это только начало — в работе ServiceDesk всегда есть место новым решениям, а останавливаться достигнутом никто не планирует. Надеемся, что рассказ о нашем опыте был вам интересен. Делитесь впечатлениями в комментариях, я с радостью отвечу на любые вопросы. А мы ещё обязательно вернёмся в блог на Хабре, потому что рассказывать есть о чём. Например о том, как мы переосмыслили и переделали переговорные комнаты в Яндексе во время пандемии, когда почти все рабочие встречи стали проходить по видеосвязи, — и как эта система помогает сейчас. Stay tuned!

^{P. S. У меня не получилось бы написать эту статью без участия коллег. Хочу сказать спасибо Антону Горшанову, Денису Литовских, Виктору Летенкову, Людмиле Малой, Андрею Глазкову, Сергею Баландину, Артёму Королькевичу и Мике Ко.}