Анна Таранина
Руководитель группы в направлении обеспечения надежности и доступности оплат Leroy Merlin
Кризисы очень любят происходить во внеурочное время: рано утром, поздно вечером, в выходные и на праздники
Процесс оплаты в ритейле критически важен: любой сбой ведет к упущенной выручке. Все решают такие проблемы по‑разному. В компании Leroy Merlin, которая в прошлом году прошла через серию громких ddos‑атак, есть специальная команда, отвечающая за надежность и доступность платежей. Мы, в Эвоторе, обеспечиваем Leroy Merlin облачными кассами и вместе следим за тем, чтобы все продажи закрывались чеками без перебоев. С Анной Тараниной, руководителем группы в направлении обеспечения надежности и доступности оплат Leroy Merlin, собрали гайд о том, как выстроить работу с инцидентами.
Напомним: Leroy Merlin ― сеть магазинов стройматериалов, которая работает в разных странах. В России и Кахахстане представлена 112 магазинами в 66 городах и интернет‑магазином. В компании работает более 45 000 сотрудников, 2 000 поставщиков и мерчантов, 390 000 товаров в ассортименте.
1. Разбираем старые завалы
Первый шаг, кажется, самый банальный и очевидный, но без него никуда. Нужно начинать с разбора текущих и предыдущих инцидентов, собрать и проанализировать все артефакты инцидентов и проработать план действий на случай повтора. Отсортировать и приоритезировать список накопленных проблем.
В Leroy Merlin все крупные сбои фиксируются в виде postmortems, в которых необходимо детально описать и проанализировать как прошел сам сбой, из‑за чего он случился, что было предпринято в ходе кризиса и что нужно сделать еще, какие уроки мы вынесли из произошедшего и где мы станем лучше.
В команде Анны уделяется также внимание работе с проблемами, выявленными в ходе анализа обращений и мониторингов. Проводятся RCA (Root Cause Analysis, анализ первопричин), по которым они оценивают, можно ли полностью убрать или минимизировать потери с помощью организационных, технических, технологических, процессных изменений ― за счет пересмотра архитектуры, устранения дефектов, изменения договоров, обязательств.
2. Определяем, что такое кризис
В Leroy Merlin выделяют разные типы инцидентов: «внешние от пользователей, внутренние от коллег, технические, которые выявляются на основе мониторингов». Для всех типов определен SLA (Service level agreement), за какое время нужно решить обращение на основании принятых приоритетов.
Для проактивной реакции поддержки мы активно используем технические инциденты. Мы стараемся не ждать, когда к нам придет пользователь, и скажет «вот, вы все сломали, ничего не работает». Например, у нас зафиксировано, сколько должна обрабатываться та или иная транзакция, проверка на формирование очереди в Kafka, возврат ошибок на запрос, контроль аномалий. Если фиксируется нарушение, автоматически формируется технический инцидент с определенной классификацией и передаётся в наш ITSM Tool BPM, далее с ним работает команда поддержки или продукта. Технические инциденты, как правило, идут с достаточно высокой критичностью, потому что наша задача быстро починить, пока пользователь еще не узнал о том, что вообще проблемы были.
Самый высокий уровень ― кризисный инцидент, с большими потенциальными финансовыми и/или репутационными потерями. Команда должна прорабатать сценарии таких кризисов. В Leroy Merlin, по словам Анны, кризис может «поднять» по сути любой сотрудник, который может осознать, что случился кризис и нужно срочно бить тревогу. Вот тогда начинается автоматический обзвон, собирается команда, которая подтверждает кризис и начинает решать проблему. Причем в команду могут быть назначены как коллеги, так и внешние подрядчики.
Допустим, если у нас не работает оплата банковской карты в магазине, но мы можем принимать у клиента наличку. В этом случае нужно перекрыть КСО, которая работает только с банковским картами, клиентов надо пускать по другому пути, плюс дать примерные сроки решения проблемы сотрудникам. Одновременно в это время нужно определить причину проблемы и как ее решить.
Для меня ключевое ― это четкое понимание, что такое кризис и определение момента, когда он происходит. Причем у всех, кто работает с продуктом, сервисом. Изначально очень важно вовремя кризис поднять. У команды должно быть понимание зоны ее ответственности, и мы договариваемся с командами о том, что ребята должно быть доступными. Для этого составляется график. При этом мне не важно внешний подрядчик это, внутренний разработчик или аутстаф. Для меня важно, что это моя команда, с которой я работаю, которая может решить проблему. Не должно быть такого: «Я вообще тут спал, у меня выходные, чего вы меня подключили». К сожалению, кризисы очень любят происходить во внеурочное время: рано утром, поздно вечером, в выходные, на праздники. К нам как‑то пришёл новый продуктовый лидер в команду 1 мая и в первый же день ее работы произошел жесткий кризис. Что называется: «мир, ТРУД, май!».
3. Настраиваем мониторинги
Все критические процессы должны быть покрыты мониторингами, не должно быть фичей и кусков продукта без мониторинга. Но главное в том, чтобы был настроен алертинг и эти алерты кто‑то обрабатывал. Команда Анны как раз и занимается настройкой мониторингов по всем важным процессам в ее домене.
Конечно у нас были такие прекрасные решения, как Dynatrace, но, во‑первых, они сейчас не доступны, а во‑ вторых, с ними тоже все не так однозначно. Например, с Dynatrace у нас было несколько не очень приятных ситуаций из‑за его ML‑механизмов (machine learning, машинное обучение). Один раз он просто полностью остановил один из важнейших бизнес‑процессов, посчитав его угрожающими. Сейчас для мониторингов мы используем open source решения, такие как Prometheus, Consul, для построения дашбордов Grafana. Для операционного контроля все складываем в Prometheus, а в качестве долговременное хранилище используем VictoriaMetrics.
Настройка мониторингов ― тонкая, можно сказать, ювелирная работа. Каждый раз после кризисной ситуации нужно оценить, как сработали мониторинги, узнали ли мы о проблеме вовремя или позже, чем могли бы узнать потенциально. Например, слишком высоко поставили трэшхолты (threshold), чтобы не спамило, а в итоге пропустили какую‑то критичную историю.
Каждый раз это живой процесс по выравниванию, допиливанию, дотачиванию. Сейчас мы формируем определенные стандарты, в том числе и c точки зрения SRE и DevOps‑практик.
4. Обновляемся ― во всеоружии
Большое количество инцидентов зачастую возникает после обновлений. И здесь простого тестирования новой фичи недостаточно, нужно полностью задокументировать обновление и информировать другие подразделения, причем не просто знать, но и быть готовыми работать с ним и поддерживать его. Проработать потенциальные риски.
В самом начале нашей работы с этим периметром у нас были 2 особенности установки обновлений.
В одной системе у нас они не откатывались, а в другой ― откатывались в течение 30 минут, но при этом изначально ставились на всю сеть. Перед каждой установкой мы с продуктовой командой долго и нудно разбирали все возможные риски и что мы будем делать при каждом.
В компании есть процесс управления установками, который реализован через согласование RFC. Команда, желающая осуществить изменение, подает заявку в релиз по определенной форме. Как согласующее лицо я проверяю что помимо самой разработки провести необходимые тесты (функциональные, регрессионные, интеграционные, e2e тесты) и они успешны. Понятны критерии оценки успешности и команда знает/умеет откатить релиз.
У нас у команд есть Tech Radar, скоуп технологии (scope ― часть продукта, закрепленная за отдельной командой), архкомы (архитектурный комитет). Команда должна все артефакты предоставить, когда работает над продуктом, и подготовить всю документацию для Request4Change. Мы работаем по Agile, который предусматривает, чтобы должна быть документация. И даже минимальные доработки должны пройти все необходимые стадии, быть протестированы, согласованы и иметь всю необходимую документацию.
5. Делаем премортемы на все
Важный шаг ― проанализировать текущие бизнес‑процессы на предмет «узких мест», чтобы подготовить по ним премортемы. Это значит, по словам Анны, что мы исходим из принципа «всё ломается» и нам надо заранее определить «хрупкие места», выработать обходные решения, например, написать и протестировать скрипты для массовой и безопасной переотправки данных, чтобы потом можно было просто достать их «из кармана» и применить в случае внештатной ситуации.
Для критичных ситуаций стоит заранее проработать возможные варианты «костылей», которые могут дать время, чтобы решить проблему. Также мы проводим учения как себя вести команде в случае сбоя с учетом ролей и влияний на результат. Это помогает командам уверенней себя чувствовать в случае реальной аварии.
Самый большой успех ― это подготовить премортемы (pre‑mortem), очень важно реально отрабатывать экшен‑план, которые мы формируем совместно с командами. Самое главное, что должно выйти из постмортема ― это не повторение ситуации либо четкое понимание, а что мы делаем для того, чтобы эта ситуация минимально по нам ударила?
И благодаря этой проработке, то, что 2 года назад было для нас огромным ужасом, на текущий момент понятная ситуация, с которой справляется второй уровень поддержки, не подключая команду продукта. Есть скрипты, есть понимание, как починить, есть время починить. Больше всего времени по опыту тратится на диагностику кризиса и на сбор команды, поэтому подготовка очень важна. Когда ты поднял кризис и собрал команду, как правило, дальше дело техники.
6. Измеряем
Естественно, в Компании контролируются результаты нашей работы путем метрик. Для контроля уровня сервиса по обращениям — это SLA (% обращений, решенных своевременно) и «Удовлетворенность пользователей» (средняя оценка удовлетворенности пользователей, инициировавших обращение). В рамках измерения влияния сбоев и объема обращений — стоимость потерь и попадание в «бюджет потерь». Для понимания уровня доступности и надежности — замер SLO (availability, latency, error budget).
Факапы и форс‑мажоры случаются со всеми, вопрос в том, насколько вы к ним готовы и как действуете. Что, на ваш взгляд, мы забыли и за какие механики Leroy Merlin можно похвалить?