Как выстроить систему саппорта и сохранить миллионы. Опыт Lamoda

Баги и поломки в системе могут стать причиной серьёзных убытков для бизнеса. Особенно, если это e-commerce. По мере роста компании цена таких ошибок увеличивается. Что-то где-то ломается всегда. Но плохая система саппорта отличается от хорошей тем, что она не повторяет прошлых ошибок. То есть каждый эпик (и не очень эпик) фэйл разбирается, а полученные таким образом знания постепенно меняют систему в сторону её большей устойчивости. На конференции TeamLead Conf 2019 Александр Афенов из Lamoda рассказал, как выстроить систему саппорта, чтобы миллионы рублей не вылетали в трубу. Мы написали статью по следам этого выступления.

Александр — тимлид команды Order Processing, в ведении которой находится два проекта. Order Processing — это система, которая автоматизирует жизненный цикл заказа от процесса создания до доставки (или возврата). Проект большой (более 150 тысяч строк кода), поэтому он был разделён на отдельные сервисы. В частности из него был выделен Refund tool. Это второй сервис, которым занимается команда, он отвечает за автоматическое возвращение денег клиенту.

Как же команда Александра разгребает саппорт? Для начала разберёмся в классификации задач для саппорта.

Каждому саппортному тикету даётся оценка по следующим параметрам:

• Критичность для бизнеса. Насколько это важно и насколько ломает бизнес-процесс.
• В течение какого времени необходимо взять проблему в работу и решить её.
• Приоритетность.

Как вы заметили, критичность и приоритетность — это разные термины. Сначала разберёмся с видами приоритетов.

• Blocker – что-то сломало абсолютно всё, остановило бизнес. Не создаются заказы, не уходят в доставку, не принимаются платежи и так далее.
• Major — это что-то менее важное и можно починить в течение более длительного времени, так как есть обходные процессы, альтернативные пути.
• Trivial. Например, кто-то пишет, что кнопки неприятного цвета и их стоит перекрасить. Существует большая вероятность, что такой тикет никогда не будет сделан.

Есть еще Service Level Agreement (SLA), который устанавливается службой поддержки совместно с командой и бизнес-владельцем системы. Они смотрят на то, какое направление бизнеса сломалось в рамках конкретной жалобы. Если, например, перестали создаваться заказы (основной хлеб интернет-магазина), то у этой проблемы будет высокий приоритет Р1. Р1 означает, что команда должна взять проблему в работу в течение получаса и решить её за пару часов максимум. Р2 — это что-то менее значимое, что команда должна взять в работу в течение пары часов и решить в течение дня. Р3-Р4 — это то, что сломалось и не требует срочного ремонта.

Есть приоритетность, которая устанавливается командой. Это может делать техлид, senior, саппорт-инженер — любой, кто занимается проблемой. Допустим, есть 4 задачи с бизнес-приоритетом Major. Человек из команды за счёт своей экспертизы ставит некое числовое значение, которое мы называем detailed priority. На его основе в дальнейшем будут отсортированы задачи саппорта. То есть наверху окажутся самые приоритетные для бизнеса задачи, которые внутри ещё отсортированы по пониманию команды того, насколько это действительно важно и насколько быстро можно сделать.

В теории выглядит красиво и просто. На деле всё немного сложнее, ведь от определения приоритетности зависит, насколько быстро та или иная задача будет сделана. Например, некто поставил задачу и говорит: «Не выгружается ежемесячный отчет. Нам он нужен через неделю, а он не работает. Пожалуйста, почините. Приоритет Р1, нужно решить в течение 2-3 часов». В ответ саппорт-инженер предлагает: «Давайте снизим до Р2, ведь есть неделя, чтобы это исправить».

Порою сотрудники компании думают, что команда Александра не возьмёт задачу, поэтому ставят высокий приоритет. Но бывает и наоборот. Например, не создаются заказы, а приоритет задачи обозначен как P2, хотя стоил бы поставить P1. Полезно уметь торговаться в обе стороны.

И вот когда приоритеты расставлены, возникает вопрос: кто будет этот красиво отсортированный список задач разгребать? В Lamoda этим занимает саппорт-инженер, он берёт и чинит наиболее приоритетные задачи из саппортного списка задач. Так как список красиво отсортирован находится самое важное, срочное и «запекающее».

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

Кажется, это очевидно, но об этом все равно часто забывают. Для того, чтобы всё работало, необходимо, чтобы процессы были поставлены на поток и неукоснительно соблюдались. В Lamoda к регулярным задачам саппорта относятся:

• Просмотр списка задач. Откуда возьмётся красиво отсортированный саппортный список (бэклог), если туда никто не смотрит? Раз в месяц в этом списке закрываются не выполненные задачи со статусом trivial (до которых, скорее всего, руки никогда не дойдут).
• Проставление detailed priority. Это тот самый процесс, где команда оценивает, насколько та или иная задача действительно критична. Detailed priority — гарантия того, то сортировка будет полезной, а саппорт-инженер возьмет сверху правильную задачу.
• Контроль выполнения SLA. Для этого в Lamoda составляются графики, по которым видно, что у команды есть задачи, время на выполнение которых уже скоро истечёт. Имеет смысл брать их в работу в первую очередь.

Быть саппорт-инженером — это довольно депрессивный процесс, поэтому человеку стоит помогать. Как можно облегчить жизнь этому герою?

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

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

Потребность в свежем взгляде

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

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

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

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

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

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

Человеческий фактор. Это так же непредсказуемо, как технический сбой.

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

• запрос на аналитику,
• запрос на изменение данных,
• ремонт бизнес-процессов,
• «фича Х перестала работать»,
• Major incident

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

Например, Александр не сразу узнал, что большинство данных о заказе в Lamoda хранятся в Oracle-базе отдела аналитики, и всё можно достать оттуда. Теперь такие запросы либо автоматизируются через интерфейсы, либо передаются в отдел аналитики.

Запросы на изменение данных. Здесь ситуации бывают разные и непредсказуемые. Допустим, наш клиент собирался оплачивать свой заказ картой. Когда приехал курьер, он передумал и решил это сделать наличными. Или, например, где-то возникла неавтоматизированная проблема, которую надо изменить руками.

Ремонт бизнес-процессов. Если в базе напрямую возникает потребность что-то править, значит есть глючный бизнес-процесс. Это может произойти либо по причине, связанной с IT, либо в бизнесе что-то идёт не так. И там, и там требуются корректировки. В таком случае нужно идти к бизнес-заказчику и обсуждать, можно ли сделать это по-другому, или запросить разработку для ремонта бизнес-процесса.

Фича Х перестала работать. По мнению Александра это самый понятный тип саппорта. Поломалась какая-то штука, и её нужно пофиксить. Здесь нужно просто выяснить, в каком релизе сломалось и по какой причине. Чините и закрываете тикет. Всё просто.

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

Major Incident. Это когда что-то сломалось в IT-системах настолько сильно, что встал конкретный бизнес-процесс.

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

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

Возможно, вы это узнаете от службы поддержки, которая следит за мониторингами и извещает дежурного по системе. Но самое приятное — узнавать самостоятельно по наличию мониторингов. А многие проблемы можно отловить ещё на подходе, если мониторить определённые тренды.

В Lamoda был такой кейс: инженеры заметили на мониторе, что с утра начал расти расход памяти на кластере Rabbit MQ.

Было понятно, что там осталось всего 16 гигабайт, и с такой динамикой через несколько часов память кончится, и всё упадёт. Заметив эту тенденцию, команда Александра вовремя всполошилась и начала разбираться. Оказалось, что завис один из плагинов, поэтому и растёт расход памяти. Проблема была решена, а major предотвращён.

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

После того, как удалось всё потушить, наступает этап ретроспективы.

Ретроспектива — это встреча, на которой обсуждается инцидент. В Lamoda на этой встрече должны присутствовать ответственные за каждую систему, вовлечённую в инцидент. Если необходимо, то присутствует кто-то от бизнеса, иногда приходит CTO. На встрече составляется описание того, что конкретно произошло, и в какой системе это полыхнуло. Дальше делается анализ последовательности действий. То есть, что команда делала между обнаружением и тушением с точностью до минуты, если это возможно.

На одной из таких ретроспектив выяснилось, что в 13.05 поступила жалоба в колл-центр. Приблизительно к 13.13 стало понятно, что она массовая. И лишь только в 14.50 команда взяла задачу в работу. Перед этим почему-то 1,5 часа был простой, хотя задача была поставлена, а команда оповещена. Кажется, что этот разрыв в 1,5 часа можно было бы сократить и тем самым сэкономить на этом инциденте миллионы рублей.

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

Также видно, что фикс оказался в продакшене в 16.55, что тоже странно, так как до этого прошло уже 40 с лишним минут. Когда вроде все проверено, можно катить, но мы этого не делали. Почему так происходит? В Lamoda очень долго гоняются интеграционные тесты, примерно полчаса. И в этой ситуации нужно принимать решение: либо вы выкатываете поправленную систему и тушите проблему, либо вы ждёте, когда прокрутятся супер-долгие процессы, и релиз уедет в бой. В первом случае может возникнуть новая проблема. Очевидно, что в таком случае надо сокращать время, которое уходит на прогон всех тестов, чтобы команда могла быстрее прогнать тесты и быстрее покатить.

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

Затем происходит формулировка preventive actions. Это важно, потому что вам нужно как-то гарантировать себе, руководству и клиентам, что эта же штука не выстрелит сегодня же вечером или завтра. Для этого мы формулируются preventive actions. То есть, вы расписывается, что вы сделаете, чтобы защититься или предвосхитить подобные проблемы в будущем.

Также необходимо проставить дедлайны/fix versions. А затем проконтролировать выполнение. Планы — это хорошо, но избежание проблемы — намного важнее.

Lamoda была организована несколькими управляющими директорами, один из которых курировал IT. Он смог объяснить другим управляющим директорам, отвечающим за другие части бизнеса, что если мы создаем сервис-провайдер и интернет-магазин со своей автоматизацией и внутренней разработкой, то важно научиться договариваться намного заранее о том, как бизнес взаимодействует с IT-департаментом.

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

Фактически саппорт — это часть продукта. Если в системе что-то ломается слишком часто, и это видно пользователю, то и продукт в целом он будет оценивать хуже, каким бы прекрасным и полезным он для него ни был.

Если вам интересен весь процесс создания IT-продуктов, приглашаем вас на конференцию Product Fest, которая пройдёт 9 декабря в Москве в SAP Digital Space. Мы готовим конференцию, на которую сами хотели бы пойти. Подробнее о концепции и Программном комитете конференции можно узнать здесь.

Если вы по опыту знаете, как создаются IT-продукты и хотите рассказать о своих успехах и провалах, подавайте заявку на доклад (дедлайн до 1 октября). Или присматривайтесь к конференции и покупайте билет.