Даже у опытных разработчиков случаются сбои в работе платформ: не заметили ошибку в коде, отвалилась сеть у Amazon, резко выросла нагрузка и сервер стал долго отвечать.
Я десятки раз участвовал в восстановлении наших приложений после критических сбоев. Сначала как разработчик, а потом как руководитель команды. Не всегда эффективно.
В этой заметке — что делать тимлиду разработки чтобы сберечь свои нервы и помочь бизнесу восстановить работоспособность после сбоя приложений.
Дисклеймер: моя команда разрабатывает торговые платформы (брокер дает возможность купить-продать валюту/акции, следит за тем, чтобы торговля была по правилам). Поэтому все примеры из фин-тека.
Уменьшить давление на команду
Сервера упали. Трейдеры не могут покупать/продавать. Брокер недополучает прибыть, несет убытки, выплачивая компенсации. Давление на инженеров огромное:
- Менеджеры закидывают сообщениями в чатах выясняя что происходит
- Клиент закидывает вопросами: пытается исправить последствия проблемы. Докладывает о новых проблемах, часто не связанными с текущей. Приходится отвечать, отвлекаясь от основной проблемы.
- Часто факапы случаются, когда у команды ночь. Техподдержка звонит по телефону, выдергивает из сна. Тяжело соображать когда тебя подняли посреди ночи.
Как уменьшить давление и дать команде сфокусироваться на решение проблемы:
- Поддержать морально: выяснить настроения в команде, обозначить, что вы онлайн и к вам можно обратиться с вопросами. Если кто-то плохо себя чувствует, то по возможности подготовить ему замену — привлечь кого-то другого из команды, например
- Уменьшить переключения между задачами: не закидывать команду вопросами, договориться, что все сами отписываются о статусе “каждые 10 минут”
- Говорить “нет” некритичным задачам: договариваемся отложить решение проблем или последствий сбоя, которыми можно заняться в более спокойной обстановке
Взять под контроль рискованные исправления
Каким бы критичным ни был сбой, всегда можно сделать ситуацию еще хуже.
Например, не работал один из серверов, 10% трейдеров не могут подключиться. На скорую руку сделали патч, доставили. Теперь система недоступна для всех.
Чтобы не усугубить проблему, принимать решение о применении того или иного плана исправлений должен один человек.
Тимлид собирает мнение команды, составляет план того, что делать если что-то пойдет не так.
Он же согласует важные шаги с проектным менеджером или клиентом: “Мы собираемся доставить патч в течение 10 минут.
Последствия: будет перезапущена часть серверов, клиенты из Европы не смогут пользоваться сервисом в течение 10-30 минут.
Возможный риск: если патч окажется неправильным, то нам придется перезапустить сервера снова и сервис будет недоступен в Европе еще на 10-30 минут. Вот как мы можем снизить риск…”
Тимлид дает сигнал когда мы уже дошли до точки “залить изменения кода в работающий сервер”, “изменить данные прямо в базе данных”.
Фокусировать команду
Сначал восстанавливаем работу бизнеса. И тольео потом обсуждаем глубинные причины проблемы, строим план как не вляпаться в это еще раз.
Представим: техподдержка делает плановую проверку за пару часов до открытия рынка. Обнаруживают, что торговые заявки не исполняются, а просто зависают. Звонят разработчикам чтобы разобраться в чем причина.
Разработчик видит ошибки в логах серверов: оказывается сервера нормально не запустились — перезапускали базу во время прогрева кэшей.
Dev: — Сервера не запустились. Зачем перезапускали базу данных?
Sup: — База не выдержала нагрузки.
Dev: — Ну раз проблема с базой, то давайте привлекать DBA
приходит DBA
DBA: — Сервера запрашивают слишком много данных. Уже 3 месяца нагрузка постоянно растет.
Dev — Почему раньше не сказали?
Потом выясняют проблемы:
- Почему не оптимизировали запрос? ПМ не принял задачу в бэклог
- Почему нормальный мониторинг нагрузки на сервер не сделали? “21 век, а у нет оповещений о растущей нагрузке на базу”
- Почему год назад по рекомендации DBA не купили диски побыстрее под базу?
- Почему техподдержка проигнорировала ошибку в логах?
- Почему разрабочики не написали нормальную инструкцию как обрабатывать подобные ошибки в логах?
- Почему разработчики написали такие приложения, которые на старте не переносят кратковременное отключение базы?
Пока инженеры обсуждают проблемы, которые уже случились и сокрушаются о неидеальности процессов (такой прием называется “атака в прошлое”), бизнес несет убытки.
Руководителю важно записать проблемы, обязательно запланировать время на их обсуждение и задать вопрос “что мы сейчас можем сделать чтобы восстановить работоспособность бизнеса?”
Подготовиться к “дню после факапа”
Для менеджеров самое тяжёлое время — это не когда все в аврале чинят сервера после поломки, а на следующий день, когда начинается разбор полётов. Нужно собрать воедино всю информацию, понять что еще нужно сделать, проанализировать ошибки, ответить на все вопросы клиента.
Годы назад я считал, что как «настоящий» тимлид должен быть на передовой вместе с другими инженерами до окончательного решения проблемы. На следующий день невыспавшийся выходил на работу и не успевал нормально подготовиться к встречам с менеджерами и клиентом — разобраться что мы уже сделали чтобы починить, что осталось починить, какие есть риски для бизнеса. Вдобавок продалбывал уже намеченные встречи по другим проектам на день. Хуже если и на следующий день случалась какая-то беда на этом же или другом проекте — из за усталости я уже не мог помочь команде.
Лучше оставить работу, которую могут сделать и без тебя, и сфокусироваться на “своей работе”. Не геройствовать и отдохнуть.
Утром со свежими силами провести переговоры с клиентами, собрать для проектного менеджера всю нужную информацию. Дать отдохнуть тем, кто активно участвовал в восстановлении работы платформы, передать оставшиеся задачи остальным членам команды.