Как подготовиться к часу, когда ваш поставщик лежит

Что здесь есть и чего здесь нет

Что-то, от чего вы зависите, будет недоступно в течение часа. Не навсегда, не катастрофически — просто исчезнет на срок, достаточный, чтобы ваш продукт как-то себя вёл, пока его нет. Работа, которую стоит делать, почти целиком делается заранее, потому что в течение этого часа никто ничего не проектирует: люди выбирают из вариантов, которые уже существуют.

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

Решайте по функциям: отказать, подождать или деградировать

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

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

Говорите об этом в интерфейсе, а не в тексте ошибки

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

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

Отделите то, что может подождать, от того, что не может

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

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

Решите, кому позволено выключать

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

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

Напишите сообщение клиентам до того, как оно понадобится

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

Запланируйте час после часа

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

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

Отрепетируйте самый маленький вариант

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

Поймите, какие зависимости заслуживают этой работы

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