tgoop.com/dsinsights/283
Last Update:
Как поймать прод, если он падает?
Я уже писал о том, как подготовиться к инцидентам на проде, чтобы, если это вдруг произошло, не терять время и разрешить быстро.
Сегодня разберем, что делать, когда инцидент уже просходит, и, например,
- у сервиса отпал регион
- трафик на платформу клиент перестал фильтроваться
- произошел резкий скачек QPS входных запросов, ваш кластер машин не вывозит
- latency резко увеличился и не хочет уменьшаться etc.
1️⃣ Для начала, сразу после того, как вам пришло уведомление, или вас пинганул менеджер, оцените ущерб (или по-модному blast radius). Для таких целей у вас должен быть доступ в аналитическую БД, куда аггрегируются ивенты (по аукционам, пользователям, минутам, регионам), и где вы можете, написав SQL запрос, оценить, на каком регионе, клиентской DSP, сегменте пользователей имеет место инцидент. А еще лучше для таких целей иметь уже готовый дашборд с основными аггрегатами и группами.
2️⃣ После того, как оценили ущерб, определяем состояние сервиса:
- operational: работает, возможно с небольшой долей ошибок
- degraded performance: значительная доля ошибок, ухудшен пользовательский опыт, ухудшено качество ML моделей, но основные сценарии работают или резервные (fallback) модели подхватили трафик
- partial outage: часть функционала отпала, отпал регион, полностью не отправляются запросы на конкретные DSP
- major outage: все полегло
После того, как оценили состояние, эскалируем инцидент своему менеджеру и команде инфры
3️⃣ Локализуйте проблему. Постарайтесь определить, из какого сервиса происходит причина инцидента. Если причина на сервисе, куда вы ранее не контрибьютили, пингуйте соответствующие команды, чтобы они подключились и проверили свои зоны ответственности.
4⃣️️️️️️ Пока ищется причина инцидента сфокусируйтесь на том, чтобы оживить прод (по-модному stop bleeding) - проверьте, какие были крайние коммиты, связанные с ошибками, и откатите их.
Если проблема в новых артефактах, которые кеширует сервис, то зачистите кеш (если у вас есть доступ) и перезалейте рабочие или fallback артефакты.
Если проблема в повышенном использованием CPU/ RAM от выброса трафика, upscal'ите машины на кластере
Детально исследовать, что именно привело к инциденту можно уже после - когда проблема решена.
5️⃣ Если все разрешилось - продолжайте мониторить и составьте postmortem. В нем укажите
- Оцененный ущерб
- Проанализируйте причину, почему так произошло
- Укажите ваши действия, и в какие сроки вы их предприняли
Что делают в это время менеджеры и аналитики?
- помогают связаться со стейкхолдерами (чтобы те были в курсе происходящего и могли со своей стороны что-то сделать - например, включить fallback) или нужными командами разработки
- смотрят на метрики и помогают оценить ущерб и в целом состояние приложения
- помогают эскалировать в нужную команду
Также рекомендую хорошую статью, как поднимают упавший прод на Ozon'е
BY ML Advertising
Share with your friend now:
tgoop.com/dsinsights/283