«Ашан» и Ensi. Эволюция модели SLA

SLA (Service Level Agreement или Соглашение об уровне сервиса) обеспечивает беспрерывную поддержку приложения в рабочем состоянии. Главная задача SLA в екоме: быстро устранять препятствующие продажам инциденты. Зон локализации две: ошибки в коде и инфраструктура.

Инциденты разделяются по приоритетам в соответствии с масштабом:

Команда Ensi начала обеспечивать SLA «Ашану» в 2020-м вместе с запуском интернет-магазина на  Ensi Platform. Начальные условия были обозначены на тендере:

В таком режиме поддержка продержалась недолго. Уже к концу года накопился целый ряд сложностей, накладывающихся друг на друга:

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

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

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

Функции — это участки программного кода, отвечающие за какое-либо действие: добавление в корзину, нажатие на кнопку, импорт фидов и другое. Каждая функция находится в конкретном сервисе (PIM, OMS, CMS…), имеет оценку критичности и зоны влияния: один пользователь, все или еком в целом. По сочетанию параметров назначается приоритет инцидентам этой функции.

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

Библиотека функций и сейчас продолжает развиваться:

• Появляются новые функции — их все нужно документировать;
• Структура и описания становятся удобнее и понятнее: повышается эффективность работы.

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

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

Всего в структуре уведомлений можно выделить три уровня:

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

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

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

Так, ежемесячное количество инцидентов снизилось с пикового значения 100 с частыми авариями до 3−4 низкоприоритетных. Повлияла совокупность причин:

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

К 2022-му году «Ашан» стал значительно меньше тратить на SLA, а мы — получать. Для Ensi поддержка оставалась дополнительной услугой. Вскоре весь процесс полностью перешел под управление клиента.

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

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

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