Как мы передаем наши продукты на техподдержку

Этап 0. До первого релиза.

Всё начинается задолго до первого релиза в Prod. Можно сказать, что система или приложение еще даже и не написаны. Еще только проработано ядро MVP, а техническая поддержка уже начинает раскручивать свой маховик в нескольких направлениях:

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

·       Список заинтересованных сторон

·       Обучение работе с проектом

·       Бизнес-назначение проекта

·       Логическая схема решения

·       Физическая схема решения

·       Логирование

·       Мониторинг и алертинг

·       Окружения

·       Трекеры задач с бэклогом проекта

·       Репозитории кода и артефактов

·       Пространство базы знаний проекта

·       Плановые работы по поддержке проекта

·       Отчетность

2.       Под клиента готовится целевая презентация, в которой рассказывается, что такое техническая поддержка и что такое проект по внедрению.

3.       Мы утверждаем и детально прорабатываем условия для системного и бизнес-мониторинга и алертинга. Для каждой измеряемой величины создается отдельная задача ("Product Backlog Item") с подробными условиями, в которой определяется, что можно решить с помощью стандартных средств, таких как Grafana, Zabbix, или путем анализа журналов с использованием ELK стека, а что требует доработки в самом программном коде. Этот этап интегрируется в спринты и дальнейшую разработку.

4.       С клиентом согласовываются правила приоритезации заявок, процесс их маршрутизации и отработки, отчетные формы и их зоны ответственности, план коммуникаций, основные и резервные каналы информирования.

5.       При необходимости прорабатываются SLA и юридические документы, необходимые для полноценного функционирования и оплаты техподдержки. Часто вопросы оплаты решаются легче, чем согласование доступов, VPN-каналов, синхронизации helpdesk систем и т.д. Сами линии поддержки тоже согласовываются – их количество и зоны ответственности.

6.       Создается база знаний, в рамках которой совместно с командой разработки описывается продукт по нашим стандартам, а также возможные и уже возникающие запросы от клиентов и реакция на них.

7.       Руководитель проекта и команда разработки проводят обучение инженеров поддержки по общей работе продукта, архитектуре решения, ключевому функционалу. Как правило, это формат вебинара с записью лекции и последующим переносом знаний в статьи. Ничего не пропадает и помогает потом при онбординге новых сотрудников.

И еще раз обращаем ваше внимание – это направления работ ДО первого релиза.

Общая дорожная карта, конечно, зависит от конкретного клиента и продукта, но выглядит примерно так:

Обратите внимание – проект внедрения четко разбит по спринтам и в каждом спринте достигает четко прописанных результатов – всё идет по технологии и по стандартам.

Этап 1. MVP продукта в Prod. Этап стабилизации.

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

Именно в этот момент:

1.        Идет самое активное накопление базы знаний. На каждый запрос нового типа специалист техподдержки создаёт how-to запись в базе знаний, как локализовать эту проблему и как ее решить или маршрутизировать дальше.

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

3.       Отрабатывается работа со всеми смежными службами – helpdesk заказчика, контакты и ответственные лица других подрядчиков, с кем интегрирован наш продукт, с лицами, принимающими решения, когда это необходимо сделать «мгновенно» – у нас же есть SLA по отработке заявок, в который мы должны укладываться.

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

Этап 2. Этап тонкой настройки.

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

Мониторингов на самом деле целых 3:

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

·         Бизнес-мониторинг «Здоровье» - система живет, открываются странички, в системе есть пользователи.

·         Бизнес-мониторинг «Эффективность» – тут уже может «проигрываться» основной сценарий, или создаются метрики, которые показывают динамику бизнес-показателей. Например, в авиакомпании – количество проданных билетов, в страховой компании – количество проданных страховок. Мы смотрим за мониторингами, что продукт работает и приносит измеримую бизнес-пользу.

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

Так что на этом этапе идет тонкая настройка.

Этап 3. Штатная работа техподдержки.

На этом этапе продолжается штатная работа и прозрачное информирование клиента.

Как правило, клиенту мы показываем 3 основных области работы техподдержки:

Дополнительно к этому добавляются Плановые работы и Поддержка инфраструктуры и окружения техподдержки. В этих работах задействованы специалисты смежных отделов – DevOps и Администрирования:

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

·         Если мы говорим про инфраструктуру и окружения, то именно на отделе технической поддержки лежит обязанность следить за различными интеграторами TFS, чат-ботов, систем заказчика, разрабатывать и настраивать бизнес-процессы в Camunda.

Всё это называется «заявки на проектах заказчиков». В «спокойный» месяц отрабатывается порядка 700 обращений в техподдержку, а в неспокойный – более тысячи.

Все наши инфраструктурные отделы несут дежурство 24/7, включая праздники. А в длинные праздники или после сложных релизов к ним присоединяются дежурные и в командах разработки. Так что мы всегда и везде за качество и непрерывность сервиса. 

Кроме того:

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

·         Анализируется весь массив заявок и классифицируется по времени отработки. Долгие и длинные – это там, где есть, о чем поразмышлять или что-то надо сделать. Короткие – это часто быстрая стандартная отработка заявки, а значит это, скорее всего, можно автоматизировать или поправить созданием дополнительного инструмента для клиента. Выделяется как класс обращений, прогоняется через комитет и формируется предложение в команду разработки.

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