Как правильно реагировать на инциденты (основано на реальных событиях)

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

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

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

Но, несмотря на то что горького опыта работы со сбоями у нас много, наш сервис остаётся одним из самых популярных на российском рынке SEO-сервисов, а CSAT нашей службы поддержки не падает ниже 90%. Как так получилось? Об этом и пойдёт речь в статье. А ещё я разберу по шагам, как правильно реагировать на инциденты, чтобы репутация бизнеса не пострадала. Сначала вкратце:

А теперь полностью.

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

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

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

Тут важно то, что это надо сделать быстро. Нет, не так. ВОТПРЯМЩАС. Правда в том, что делать надо это было, скорее всего, ещё час назад, и вы по умолчанию опоздали. А сейчас надо уже чинить, и у вас начинается паника.

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

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

У меня уже давно отсутствует стыд показаться глупой: что я провела недостаточный анализ, что посмотрела не тот лог и всё такое. Окей, потом разберемся, что, где и как я не то посмотрела. Починить можно? К ошибкам тоже можно относиться продуктово!

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

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

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

Люди часто стесняются кого-то потеребить, особенно программистов; боятся, что они что-то не так посмотрели, и им за это надают по шапке. Легко сказать: «Постройте культуру, где можно ошибаться», особенно в таких моментах, но на самом деле это действительно нужно делать. А ещё пропишите инструкции по анализу разного рода ошибок и учите людей сохранять холодную голову в любой ситуации.

Бывает так, что проблему нашли и сразу начали исправлять, а что она найдена, не сообщили. От лица пользователя, который попадал в такую ситуацию, говорю: «Мы проверяем, в чем дело» и «Мы нашли проблему, исправляем ее» — это два кардинально разных статуса.

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

Однако даже если в проблеме виноваты не вы, попробуйте сделать что-нибудь, чтобы решить её уже сейчас. Как однажды было у нас: оказалось, что мы упёрлись в дневной лимит от партнерского API, и сразу связались с ними, чтобы они нам его увеличили. Но параллельно пустили проверки по обходному алгоритму. И хотя лимит нам увеличили в тот же день, мы справились ещё быстрее и разгребли всю накопившуюся очередь задолго до этого.

Напишите, что вы делаете для исправления проблемы. Не бойтесь поспамить в тикет. Некоторые диалоги у нас выглядят как сообщение пользователя и 2-3 сообщения админов. Это нормально! Действуйте проактивно и не ждите, пока люди начнут беситься. В нашем случае моно... диалог выглядел как-то так:

Когда всё успокоилось, проведите анализ того, что случилось и почему, и подумайте, как не допустить такого в дальнейшем. Можно выписать по минутам, когда случился сбой, когда его заметили и так далее, но мы пока такое не практикуем.

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

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

А чтобы больше узнать об управлении цифровыми продуктами, читайте мой канал Продакт тётя Юля. В нём я без прикрас пишу о процессах в Топвизоре.