Когда зависимый сервис деградирует, отчет об ошибке попадает к вам

Немного позже полуночи 27 августа 2026 года температура в главном помещении дата-центра Proton во Франкфурте поднялась с 21,8 °C до 51,9 °C менее чем за тридцать минут. Система охлаждения вышла из строя, и сетевое оборудование, которое достигло 105 °C, перешло в режим защиты, который отключил его до холодного перезапуска. Proton был недоступен около двух часов.

Стоит читать не то, что это произошло - в конечном итоге инфраструктура всех выходит из строя - но отчет об инциденте, который опубликовала Proton впоследствии, который отличается конкретностью, которой обычно не хватает. Он называет причину: замену воздушного фильтра на резервных воздушных компрессорах, проведенную оператором дата-центра «в полночь, без предварительного уведомления», который «также не сообщил об отказе охлаждения, когда это произошло». Он объясняет, почему восстановление было медленным, а не мгновенным - команда решила сохранить оборудование, а не быстро восстановить услугу, потому что заменить его сложно «в условиях текущего бума искусственного интеллекта», который напрягает поставки. Такой конкретный постмортем - одолжение для всех, кто что-то запускает, и стоит об этом сказать.

Но есть еще одна вещь в этом, которая стоит внимания всех, кто получает отчеты об ошибках, и ее легко пропустить. Симптом, видимый пользователю, был не сообщение со словами «Proton недоступен». Это было вот это, в их словах: «Писем не было потеряно, но доставка электронной почты в обе стороны была задержана».

Отказ, который не объявляет о себе

Полный отказ - это простой случай. Сайт возвращает 503, страница не загружается, все понимают в течение минуты, что проблема не в них.

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

Поэтому отчет, который вы получаете, не говорит «мой провайдер испытывает инцидент с охлаждением». Он говорит «ваше приложение медленное», или «оно не отправило», или «это работало утром, а теперь не работает» - и вы тратите первый час на поиск в единственном месте, где проблемы точно нет, потому что это то место, на которое указал человек.

Определение их отказа от вашей ошибки, пока это происходит

Различие обычно видно в течение минут, если вы знаете, на что смотреть, и вот примерный порядок.

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

Какова форма отказа? 504 Gateway Timeout - это сервер перед другим сервером, который никогда не ответил - специфический отпечаток входящего сервиса, который работает, но не отвечает, что в точности то, как выглядит деградация снаружи. Запрос, который зависает, а затем истекает по времени, в отличие от запроса, который возвращает ошибку, созданную вашим кодом, указывает в ту же сторону.

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

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

Полная версия этого - обоснование для каждой проверки и как это выполнить под давлением - в Это ваша ошибка или их отказ.

Что захватить, чтобы не спорить об этом позже

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

Поэтому пока это происходит, захватите доказательство, которое связывает симптом с внешним источником: не работающие запросы с их кодами состояния и временем, временные метки, ответ, который входящий сервис фактически вернул. Это разница между «мы думаем, что это был наш провайдер» и отчетом с 504s и задержками доставки рядом с временной шкалой инцидента самого провайдера. Один это спор, другой это решение.

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