Как устроена техническая поддержка ИБ-продукта: опыт «Солара»
В конце 2022 года «Солар» добавил к своему портфелю новый продукт — систему Solar SafeInspect — и взял на себя техническую поддержку действующих заказчиков и партнеров. За прошедшее время мы переосмыслили эту задачу, построив надежный и основательный сервис. Никита Игонькин, руководитель отдела технической экспертизы и контроля качества продуктов ГК «Солар», делится опытом.
Рассказываем о том, как устроена наша команда поддержки и процессы, как выглядит классический кейс и чего обычно ждут заказчики от постпродажного обслуживания на примере нашего продукта для управления привилегированным доступом Solar SafeInspect.
На рынке ИБ есть два основных вида технической поддержки. Вендорская и интеграторская, или экспертная и проектная — назвать можно по-разному. Суть сводится к тому, что главная задача интегратора — решение возникающих инцидентов, а вендора — глубокий анализ проблем.
В нашем случае, «Солар» — и вендор, и интегратор, и сервис-провайдер одновременно. Мы видим все (или почти все) боли и ожидания заказчиков и партнеров с разных сторон. Это позволяет корректировать наш портфель сервисных услуг, формировать roadmap по продуктам, находить и исправлять узкие места.
Соответственно, наша поддержка объединяет экспертную и проектную модель, и обе задачи выполняет одна и та же команда. В результате мы получаем надежную конструкцию, в которой все инциденты и проблемы прозрачно доносятся до разработчиков без потери информации по пути или её неверной интерпретации.
Чтобы прийти к сегодняшнему результату, мы обменивались опытом внутри команды, меняли процессы и делали выводы, которые помогли нам перейти от «тушения пожаров» к построению реальной картины использования продукта заказчиком, и, соответственно, комплексному решению проблем.
Кого и как мы поддерживаем
После того, как заказчик приобрел и инсталлировал ИБ‑решение, наступает этап постпродажного обслуживания. Когда «Солар» сам выступает интегратором Solar SafeInspect, у нас предусмотрен отдельный процесс передачи системы на сервис. Команда внедрения передает всю необходимую информацию: описание архитектуры, проблемы, возникшие при внедрении, контакты заказчика. Затем мы информируем заказчика о начале поддержки, при необходимости создаем учетную запись на нашем портале самообслуживания.
Мы не всегда сами выступаем интеграторами, у нас развитая партнерская сеть. Партнеры выступают в качестве 1 и 2‑й линии, а мы оказываем им поддержку, при необходимости подключаемся к общению с заказчиком. Соответственно, когда проект внедрения реализует партнер, то этап передачи на сервис мы опускаем. Когда нужно понять сценарии использования продукта и боли заказчика, чтобы на основе этих данных строить или адаптировать планы развития продукта, мы обращаемся к заказчику через партнера, чтобы команда поддержки оставалась в контексте всех обсуждений.
В 2023 году, когда мы переводили на нашу поддержку действующих заказчиков Solar SafeInspect, мы постарались сделать этот переход максимально бесшовным, и в первое время изменения для них коснулись только контактов для обращения. Для новых контрактов и продлений технической поддержки мы постепенно меняем условия, синхронизируя их с другими нашими продуктами. Получилось достаточно прозрачно и понятно, поэтому, если заказчик использует несколько наших продуктов, условия будут практически одинаковыми, и отличия будут только в специфике продуктов.
Как устроена поддержка
В поддержке работают инженеры с необходимым опытом работы и квалификацией. Их основные задачи — обработка сервисных обращений, но кроме них возникают задачи по поддержке и участию в проектах внедрения и пилотах. В свободное от работы по заявкам время (да, такое случается) ребята пишут статьи для базы знаний, изучают новые версии поддерживаемых продуктов и улучшают знания по существующим функциям.
Первая линия поддержки в «Соларе» работает в режиме 24/7. Команда, расположенная в Нижнем Новгороде, принимает и осуществляет первичную обработку обращений, предоставляет решения из базы знаний, мониторит работоспособность наших продуктов в эксплуатации у Заказчиков, участвует в регламентных работах, в том числе в ночное время. Построили мы ее в 2018 году под один проект и с тех пор планомерно масштабируем на все наши проекты и продукты. В начале пути сложнее всего было найти специалистов, готовых работать в сменах по 12 часов, а затем в короткий срок обучить команду нашим достаточно сложным продуктам. Со временем и опытом требования к подбору кадров стали тоньше и разнообразнее, а методика подготовки совершенствовалась и отлаживалась. Сегодня у нас не очень большая, но эффективная команда: например, за квартал проходит более 2 200 обращений, из них порядка 700, то есть около 30% закрывается на первой линии. Это очень хороший результат.
Для второй линии мы прорабатывали вопрос круглосуточной работы, но пока что реальной потребности в этом у нас не возникало. Мы пошли другим путем, чтобы увеличить рабочий день и закрыть больший временной интервал: инженеры начинают и, соответственно, заканчивают работать в разное время. При возникновении критических инцидентов в ночное время сотрудники первой линии или лично руководитель (то есть я) могут позвонить и попросить ребят со второй линии помочь. Мы согласовываем с каждым конкретные даты, когда можно обратиться с такой просьбой. Эти случаи скорее исключение, не более пяти раз в год, и оплачиваются отдельно, поэтому дискомфорта такой режим никому не доставляет.
Мне кажется, какие‑то ноухау в построении поддержки изобрести трудно — все давно придумано и описано, например, в том же ITIL, откуда и мы взяли на вооружение лучшие практики. Основная точка приложения усилий — это построение системы обмена знаниями, когда данные об инцидентах обогащают продукт, а экспертиза вендора позволяет системно решать проблему, а не устранять «симптомы». Самые заметные изменения по качеству поддержки у нас начали происходить, когда мы начали переопыляться знаниями, проводить внутренние технические семинары, в том числе просили разработчиков рассказывать инженерам об архитектурных особенностях, не всегда очевидных.
Сейчас мы продолжаем улучшать этот процесс, делая получение знаний проще и комфортнее для инженеров. Раз в квартал проводим работу над ошибками по работе с заявками, чтобы повышать качество предоставляемых услуг, находить узкие места в процессах поддержки, soft‑ и hard‑ скиллах инженеров.
Поддержка решения для управления привилегированным доступом
Если говорить об особенностях поддержки PAM-системы, на организационном уровне их нет. Но важно, что это бизнес-критичная система — через нее организовывается доступ к защищаемым серверам. Если Solar SafeInspect перестанет корректно функционировать, то администраторы не смогут выполнять свои задачи. Это справедливо и для других ИБ‑решений, например, DLP-системы, стоящей «в разрыв» почтового трафика, или IdM-системы, управляющей правами доступа всех сотрудников в компании.
На техническом уровне при поддержке PAM важно знать, как устроена сетевая инфраструктура у заказчика, как маршрутизируются пакеты, как работают сетевые протоколы. Кроме этого, нужно понимать возможности интеграции со смежными средствами защиты, с использованием каких протоколов осуществляется интеграция (например, ICAP, syslog, HTTPS), к каким негативным последствиям может привести некорректно настроенная интеграция.
Для всех поступающих сервисных заявок у нас есть классификатор по приоритету (то есть в зависимости от критичности инцидентов для бизнеса) и по категории обращений (например, «консультация», «дефект», «восстановление работоспособности»). Помимо организационной задачи, разбивка на категории обращений помогает нам строить статистику и выявлять узкие места в продукте или документации к нему, формировать Базу Знаний.
Раньше все вопросы по Solar SafeInspect решались в различных чатах, но на текущий момент мы практически полностью прекратили такой формат взаимодействия с партнерами и заказчиками. Теперь только оперативные консультации, когда ответить в мессенджере быстрее, чем заводить заявку, проводятся в чате. Все долгоиграющие кейсы или любые вопросы уровня «простой+» и выше попадают в наш Service Desk.
И это дало огромный выхлоп с точки зрения процессов: мы увидели реальную картину использования продукта на площадках заказчика, частые инциденты и проблемы, сделали выводы и частично поменяли приоритет задач.
Отвечаем на ожидания заказчика
По опыту могу сказать, что есть несколько главных требований к поддержке, которые разделяют почти все заказчики.
Все инциденты, возникающие при эксплуатации продукта, должны быстро решаться
Увы, это утопия, ведь за инцидентами всегда скрываются какие‑то глубинные проблемы, и качественно их исправить не всегда получается быстро. Значит, нужно предложить временные решения, пока не будет устранена сама причина инцидента.
Должен быть прозрачный SLA и понятные условия поддержки
Вполне разумное требование к любой системе. «Солар», помимо гарантийной поддержки (bug fixing), которая включена в первый год действия лицензии, предлагает заказчикам три уровня сервиса.
- Стандартная ТП. На базовом уровне мы решаем инциденты и предлагаем «мягкий» SLA.
- Расширенная ТП. Мы добавляем профилактику, проактивное реагирование на отклонения от нормальной работы и дополнительное информирование заказчика. Условия SLA жестче для нас.
- Премиальная ТП. Высший уровень SLA и расширенный перечень предоставляемых услуг.
Вендор должен быть вовлечен и заинтересован в решении возникающих проблем и задач
«Солар» автоматически отвечает этому условию, так как мы и вендор, и интегратор. Разрыв между командами внедрения и разработки который часто бывает в классической схеме вендор—интегратор, у нас попросту отсутствует. Если внедрение Solar SafeInspect происходит через подрядчиков, то мы работаем с ними в плотном контакте, помогаем им решать задачи заказчиков.
Должны учитываться пожелания по доработкам системы
Здесь наши интересы совпадают, ведь без пожеланий заказчика не сформируется roadmap продуктов. Ресурсы разработчиков ограничены, все реализовать невозможно, поэтому приходится расставлять приоритеты. В первую очередь берем в работу одинаковые бизнес-задачи, которые поступают от разных заказчиков.
Не должно быть подвешенных вопросов
Частое опасение заказчиков — неопределенность, когда обращения долго обрабатываются, а никакого обходного решения не предложено или, того хуже, вопрос вообще остается без ответа.
Да, случается, что обращения «подвисают» в команде разработки и, будем честны, на уровне команды поддержки. В первом случае мы общаемся с разработкой, просим дать актуальный статус по решению и примерные сроки, чтобы транслировать эту информацию заказчику и проинформировать, если сроки меняются. Не всегда получается делать это своевременно, но мы работаем над этим.
А чтобы задержек не происходило на уровне поддержки, мы мониторим такие показатели как время реакции, качество обработки и время решения обращений, чтобы инженеры давали обратную связь оперативно и при необходимости предлагали временные решения по тикетам.
ТОП-3 самых частых обращений
Ошибки при развертывании новых инсталляций Solar SafeInspect
Обычно такие обращения связаны с поддержкой физических серверов или отечественных сред виртуализации. Проверить на этапе тестирования все возможные варианты оборудования на совместимость с Solar SafeInspect невозможно. Поэтому, когда приходят подобные обращения, мы сначала смотрим на ошибки при развертывании. Дальше либо у нас получается запустить SafeInspect на новом оборудовании, либо мы приходим к выводу, что оборудование или схема развертывания не поддерживается. В этом случае мы предлагаем альтернативные варианты развертывания системы, чтобы решить задачу здесь и сейчас. А сами берем на доработку поддержку указанного оборудования.
Не получается настроить компонент системы или какую-то функцию системы по инструкции
Как правило, все просто — пользователь пропустил какой-то пункт инструкции. После повторного прохождения по инструкции и обнаружении ошибки все благополучно получается настроить.
Бывают относительно сложные обращения, когда, казалось бы, все настроили правильно, но все равно что‑то не работает. При этом на наших тестовых стендах ситуация не воспроизводится, все работает один в один так, как описано в документации. Начинаем анализировать глубже и видим, что все-таки что-то сделали не по инструкции.
К сожалению, не обходится и без случаев, когда в ходе анализа обращения выявляем дефект в продукте. Тогда мы воспроизводим кейс заказчика на стенде и по возможности предлагаем обходное решение.
Интеграция с различными смежными системами
Обработка таких обращений — типовые консультации в формате «вопрос—ответ», иногда с дополнительной информацией, которая может быть не описана в документации.
Наши планы по развитию сервиса
У нас в планах два проекта, которые улучшат клиентский опыт заказчиков и партнеров. Ранее мы запустили Личный кабинет ИБ — единую платформу, на которой наши заказчики могут получить актуальную информацию обо всех подключенных инструментах защиты «Солар». Доступ к ней могут получить конечные заказчики и партнеры. Через ЛК ИБ мы уже реализовали централизованный доступ к дистрибутивам и документации по продуктам, настроили интеграцию с нашим Service Desk для работы по обращения прямо из личного кабинета. Сейчас в процессе формирования база знаний с описанием типовых кейсов и их решений, различными статьями по администрированию продуктов.
Во‑вторых, мы планируем дополнительный, отдельный портал для партнеров, в котором будет размещаться вся необходимая информация по продуктам и не только. Иными словами, мы развивает self-service.
