Кратко

  • Версии сервиса Fastly позволяют ясно указать прежнюю конфигурацию для повторной активации, однако активная версия в API описывает состояние control plane, а не доказывает, что все обслуживающие запросы edge-площадки уже сошлись на ней.
  • Приёмка отката должна фиксировать последний ответ под управлением отозванной версии для каждой наблюдаемой POP, восстановленную версию, точную проверку вредного поведения и отдельное состояние purge либо поколения кэша.

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

Модель конфигурации Fastly даёт оператору полезный объект управления. Версия сервиса — определённый экземпляр конфигурации, который можно клонировать, заблокировать, активировать или деактивировать. Одновременно активна только одна версия; прежнюю неактивную версию можно вновь сделать активной. Возврат получает точный адрес. Вместе с этим появляется соблазн поставить отметку «завершено» в момент, когда запрос на активацию принят и панель показывает желаемый номер.

Во вводном руководстве Fastly указано, что распространение изменений конфигурации может занять пару минут. Это не признак неисправности: распределённой системе требуется время, чтобы донести состояние. Но отсюда следует важное разграничение. Центральное подтверждение и фактическое поведение запросов по сети — разные наблюдения. Определив откат через первое, оператор ещё не измерил второе.

POP — это исполняющая популяция, а не точка на карте

Fastly описывает точку присутствия как кластер кэширующих серверов. Из-за clustering и shielding запрос на пути к origin может встретить несколько площадок или POP. Место обслуживания можно записать с помощью server.datacenter в VCL и FASTLY_POP в Compute; для edge-кода доступно и значение версии сервиса. Из этих идентификаторов складывается журнал отката на уровне запроса: какая версия приняла решение, в какой популяции, когда и для какого конкретного теста.

Обычной проверки health недостаточно. Canary должен проходить именно по отзываемому поведению: переписыванию пути, правилу доступа, выбору origin, политике заголовков, ключу кэша, ветви Compute или решению безопасности. Зелёный ответ от не связанного с проблемой кода доказывает лишь то, что сеть способна отвечать.

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

Логи дают свидетельства, но не всеведение

Fastly поддерживает потоковую передачу логов почти в реальном времени и позволяет записывать обслуживший запрос дата-центр. Это сильное положительное свидетельство: запись может показать, что конкретная POP исполнила версию или вернула результат. Одновременно Fastly предупреждает, что доставка таких логов работает по принципу best effort, не гарантируется и может терять записи, когда распределённая система защищает производительность и устойчивость.

Следствие несимметрично. Увиденная после срока отозванная версия доказывает провал отката. Её отсутствие в негарантированном потоке само по себе не доказывает глобального отсутствия. Надёжный акт приёмки объединяет активные пробы, маркеры POP и версии в запросе, телеметрию платформы или сведения поддержки и явный перечень ненаблюдаемых популяций. Молчание системы наблюдения — пробел в охвате, а не уверенность.

Anycast усложняет задачу: клиент не всегда может направить пробу через выбранную POP, поскольку маршрутизация выбирает сетево близкую площадку. Ответом не должно быть выдуманное полное покрытие. Нужны распределённые пробы, реальный пользовательский трафик, региональные тестовые клиенты и сведения Fastly; в отчёте указывается фактически наблюдаемый знаменатель. Если высокорисковый сервис не получает достаточного охвата, владелец решения продлевает окно проверки, ограничивает трафик либо явно принимает остаточную неопределённость.

Конфигурация и кэш — разные поверхности отката

Восстановление версии сервиса не отвечает на все вопросы о кэше. В документации Fastly описаны разные механизмы и сроки purge. Полная очистка может занимать до двух минут. Purge по URL или surrogate key распространяется через распределённый механизм примерно за 150 миллисекунд. Очистка cache key, вызванная edge-кодом, по умолчанию локальна для POP, если явно не выбран глобальный scope. Soft purge намеренно сохраняет возможность отдавать устаревший объект в некоторых условиях.

Fastly также описывает гонку, при которой shield может вернуть edge содержимое, существовавшее до purge, и старый объект снова останется в кэше. Для полной очистки платформа раскрывает поколение кэша в VCL и Compute и рекомендует сопоставлять поколения shield и edge. Поэтому доказательство отката нельзя свести к номеру версии. Конфигурация может быть восстановлена, а кэшированный контент, ключи, динамические данные или состояние origin останутся независимо неверными.

Оператор должен определить, где живёт вредный результат: в исполняемой конфигурации, в кэшированных объектах, в обоих слоях или вне Fastly. Если требуется purge, план восстановления обязан защитить origin от волны повторного наполнения. Технически завершённая очистка, перегрузившая origin, не является восстановлением бизнеса.

Что даёт инцидент 2021 года

Fastly сообщила, что глобальное нарушение 8 июня 2021 года возникло из-за ранее не обнаруженной программной ошибки, которую активировало допустимое изменение конфигурации клиента. Публичная хронология отмечает начало в 09:47 UTC, обнаружение конфигурации-триггера в 10:27, начало восстановления в 10:36, восстановление большей части сервисов к 11:00, завершение мер по снижению воздействия в 12:35 и начало развёртывания постоянного исправления в 17:25.

Инцидент показывает, что допустимая конфигурация может взаимодействовать с программным обеспечением платформы в глобальном масштабе, а восстановление имеет несколько стадий. Он не утверждает, что какая-либо определённая POP продолжала исполнять отозванное правило; такого вывода делать нельзя. Более узкий урок для закупки состоит в том, что откат — измеримая возможность со своим временем устранения и отдельным доказательством наблюдаемого завершения.

Журнал доказательств отката

Для каждого изменения с высоким воздействием записывайте идентификатор сервиса, отозванную и восстанавливаемую версии; центральный запрос и ответ; версию, увиденную в запросах по POP; регион, путь через shield и trace ID; canary, который воспроизводит именно вредное решение; поколение кэша или идентификатор purge; первый восстановленный и последний отозванный ответы; охват популяций и пробелы в логах; имя лица, уполномоченного закрыть инцидент.

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

Вывод для совета директоров не в том, что Fastly обязана устранить время распространения. Покупатель не должен превращать ответ API в смысловое доказательство. Откат завершён, когда старое решение перестало наблюдаться в согласованном охвате, а оставшиеся неизвестные получили владельца, — не когда кнопка поменяла цвет.

Источники