Cloudflare сделал развёртывание правил маршрутизации тестом на подотчётность и сетевую устойчивость

Кратко

• В публичном разборе инцидента Cloudflare за 17 июля 2020 года описаны изменение сетевой конфигурации в Атланте, 27-минутное основное окно сбоя, падение примерно половины трафика на пике и глобальное влияние на клиентов, из-за которого внутренние механизмы управления трафиком стали вопросом доступности клиентов.
• Вопрос подотчётности — в том, кто контролировал тестирование правил маршрутизации, поэтапное развёртывание, предпочтение маршрутов, защиту от превышения числа префиксов, поведение магистрали при сбое, информирование клиентов о статусе, скорость отката и доказательства того, что безопасность развёртывания изменилась после инцидента.
• Это не типовой сбой облака. Это кейс сетевой устойчивости, потому что пограничные сервисы Cloudflare — DNS, безопасность, доставка приложений и управление трафиком — входят в стек публичных сервисов и обеспечения непрерывности других организаций.
• В статье разбор Cloudflare рассматривается как отчёт о происшествии от самой компании, а материалы по BGP, устойчивости, SRE, NIST, CISA и статусным страницам — как контекст, а не как доказательства о частных маршрутизаторах.
• Долгосрочный урок: поэтапность сетевых изменений нужно доказывать, а не только обещать. Провайдер должен показать, как одно развёртывание правил маршрутизации тестируется, ограничивается, наблюдается, откатывается и не превращается в общий сбой клиентов.

Почему этот случай относится к досье рисков и подотчётности

Cloudflare превратил развёртывание правил маршрутизации в тест на подотчётность в области сетевой устойчивости, потому что инцидент 17 июля 2020 года вскрыл базовое свойство современной облачной зависимости: внутреннее решение провайдера по управлению трафиком может стать публичным событием доступности для клиентов, которые этого изменения не видели. В отчёте Cloudflare об инциденте по ссылкеисточник: blog.cloudflare.comсказано, что изменение конфигурации в Атланте привело к сбросу магистрального трафика, основной инцидент длился с 21:12 до 21:39 UTC, и была затронута существенная доля трафика.

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

Дело не в том, что Cloudflare необычно хрупок. Дело в том, что Cloudflare необычно важен для публичной доступности многих клиентов. Сервисы Cloudflare могут располагаться перед веб-сайтами, API, DNS-записями, фильтрацией безопасности, защитой от DDoS, приложениями Workers, путями доступа Zero Trust и оптимизацией производительности. Когда у сетевого провайдера с такой ролью происходит событие на магистрали или в маршрутизации, многие клиенты воспринимают его как собственный сбой. Это делает контроль развёртывания провайдера частью плана непрерывности клиента, даже если клиент не контролирует маршрутизаторы провайдера.

Страница статуса Cloudflare по ссылкеисточник: cloudflarestatus.comи история статусов по ссылкеисточник: cloudflarestatus.comважны, потому что публичная коммуникация становится частью управления инцидентом. Во время сбоя провайдера клиентам нужно решать, сломан ли их собственный origin, затронут ли DNS, блокируют ли трафик механизмы безопасности, существуют ли альтернативные пути и стоит ли просить пользователей подождать. Страница статуса — не только коммуникационный артефакт. Это операционный сигнал, определяющий дальнейшую сортировку инцидентов.

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

Справочные материалы Cloudflare по BGP по ссылкеисточник: cloudflare.com, RFC 4271 по ссылкеисточник: rfc-editor.orgи NIST SP 800-189 по ссылкеисточник: csrc.nist.govполезны тем, что описывают междоменную маршрутизацию и устойчивый обмен трафиком. Они не являются выводами о маршрутизаторах июля 2020 года. Они помогают читателям понять, почему локальные предпочтения, анонсы маршрутов, управление трафиком и магистрали провайдера — это поверхности контроля, а не абстрактная инфраструктура.

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

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

Отказ правила маршрутизации становится сбоем клиента, когда edge — это общая инфраструктура

Инцидент июля 2020 года полезен тем, что делает видимой внутреннюю границу развёртывания. Для инженера Cloudflare изменение правила маршрутизации или управления трафиком — это сетевая операция. Для клиента это доступность сайта, достижимость API или непрерывность механизмов безопасности. Именно этот перенос и составляет суть облачной зависимости. Клиент может покупать защиту от DDoS, кэширование CDN, DNS, контроль доступа или edge-вычисления, но во время сбоя клиент сталкивается с одним фактом доступности: пользователи не могут стабильно достучаться до сервиса.

Собственная документация Cloudflare по ссылкамисточник: developers.cloudflare.comиисточник: developers.cloudflare.comпоказывает, насколько широкой может быть клиентская поверхность контроля. Документация Workers по ссылкеисточник: developers.cloudflare.comи информация о сетевом взаимодействии по ссылкеисточник: cloudflare.comпоказывают, что Cloudflare — это не просто кэш для сайтов. Это edge-платформа, среда выполнения для разработчиков и участник межсетевого обмена. Эти страницы не являются доказательствами по инциденту. Они объясняют, почему клиенты обоснованно полагаются на внутреннее управление сетевыми изменениями Cloudflare.

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

Это особенно важно для государственных, медицинских, экстренных, финансовых и городских сервисов, которые используют облачных edge-провайдеров как часть публичного доступа.

Инцидент также показывает, почему резервирование на стороне клиента сложно. Клиент может построить мульти-CDN, вторичный DNS, отказоустойчивость origin или аварийный обход, но эти механизмы дороги и могут ослабить безопасность при плохом управлении. Многие клиенты принимают концентрацию у провайдера, потому что его надёжность и безопасность выше того, что клиент может построить сам. Такой обмен рационален, но он переносит бремя доказательства на провайдера.

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

Материалы Google SRE о работе с перегрузкой по ссылкеисточник: sre.googleи управлении критическим состоянием по ссылкеисточник: sre.googleполезны как контекст: они описывают, как распределённые системы отказывают под нагрузкой, при обратной связи и проблемах управления состоянием. Инцидент Cloudflare был событием сетевого управления, а не кейсом Google SRE. Но словарь SRE помогает задавать правильные вопросы: за каким сигналом следили, какой порог был важен, какой автоматический ответ существовал, какое человеческое решение требовалось и как проверялось исправление.

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

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

Поэтапное развёртывание — это контроль подотчётности, а не инженерная прихоть

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

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

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

NIST SP 800-34 Rev. 1 по ссылкеисточник: csrc.nist.govи NIST SP 800-160 Vol. 2 Rev. 1 по ссылкеисточник: csrc.nist.govполезны здесь, потому что определяют концепции планирования непрерывности и киберустойчивости. Это не руководства по маршрутизаторам. Они помогают перевести сетевую инженерию в обязанности устойчивости: предвидеть, выдерживать, восстанавливаться, адаптироваться и проверять. Разбор провайдера должен показывать не только восстановление после одного инцидента, но и адаптацию системы развёртывания, которая допустила инцидент.

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

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

Скорость отката видна только при точной хронологии

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

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

Страницы статуса могут дать часть такой записи. Статусные ресурсы Cloudflare показывают публичную коммуникацию, но публичный статус часто отстаёт от внутреннего обнаружения, потому что провайдер должен проверить факты перед публикацией. Это отставание приемлемо, если оно небольшое и объяснено. Оно становится проблемой подотчётности, если клиенты продолжают отлаживать собственные системы, когда провайдер уже знает о глобальном или региональном событии. Клиентам нужны сигналы статуса достаточно рано, чтобы не тратить критически важное время реагирования на инцидент.

Запись об откате должна также различать техническое восстановление и восстановление клиента. Если трафик Cloudflare восстанавливается на сетевом уровне, часть клиентов всё равно может столкнуться с последствиями в кэше, сессиях, DNS, повторных попытках, очередях или поддержке пользователей. Короткий сбой провайдера может создать более длительную работу для клиента. Публичные разборы часто сообщают о восстановлении провайдера, но влияние на клиентов может включать обращения в поддержку, потерянные транзакции, неудачные вызовы API, усталость от алертов, экстренные коммуникации и потерю уверенности.

Статья не утверждает количественную цифру потерь клиентов за июль 2020 года, потому что публичная запись её не подтверждает.

Но она говорит, что хронология провайдера — это только начало подотчётности перед клиентами.

Непрерывность государственного сектора повышает ставки. Материалы CISA об устойчивости критической инфраструктуры по ссылкеисточник: cisa.govполезны, потому что многие государственные и критически важные сервисы зависят от доступности веба, DNS и фильтрации безопасности. Сбой провайдера может затронуть городские информационные сервисы, публичные порталы, коммуникации, связанные с экстренными службами, и базовые онлайн-сервисы, даже если провайдер сам не является государственным органом. Это не означает, что каждый клиент Cloudflare был критической инфраструктурой. Это означает, что процесс контроля провайдера должен быть достаточно сильным для тех клиентов, которые ей являются.

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

Пиринг, транзит и конструкция магистрали — часть доверия клиентов

Инцидент Cloudflare в июле 2020 года находится на границе между внутренней магистральной инженерией и широкой экосистемой интернета. Клиенты редко изучают детали пиринга и транзита, но эти детали формируют достижимость. PeeringDB по ссылкеисточник: peeringdb.comдаёт публичный контекст экосистемы межсетевого обмена. RIPE RIS по ссылкеисточник: ris.ripe.netи RouteViews по ссылкеисточник: routeviews.orgпоказывают, что публичное наблюдение за маршрутизацией существует, даже если оно не может раскрыть каждое частное решение провайдера. Действия операторов MANRS по ссылкеисточник: manrs.orgи RFC 7908 по ссылкеисточник: rfc-editor.orgдают словарь для утечек маршрутов и безопасности маршрутизации, применимый к смежным событиям.

Инцидент июля 2020 года не следует путать с утечкой маршрутов в июне 2019 года, которую Cloudflare анализировал по ссылкеисточник: blog.cloudflare.com. В 2019 году Cloudflare был затронутым провайдером, объяснявшим утечку маршрутов с участием других сетей. В 2020 году собственный разбор Cloudflare описывал внутреннюю проблему сетевой конфигурации. Это различие важно, потому что карта подотчётности разная. При утечке маршрутов исправление может включать валидацию источника, фильтрацию, ответственность транзитных провайдеров и нормы экосистемы.

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

Cloudflare публиковал материалы по RPKI и безопасности маршрутизации, например по ссылкеисточник: blog.cloudflare.comи по ссылкеисточник: blog.cloudflare.com. Эти источники показывают публичную позицию Cloudflare и технический словарь в области безопасности маршрутизации. Они автоматически не доказывают исправление июля 2020 года. Они помогают читателям понять, почему провайдер, глубоко участвующий в безопасности маршрутизации, должен оцениваться и по проверяемой дисциплине сетевых изменений, а не только по публичному просвещению.

Конструкция магистрали — часть доверия клиентов, потому что клиенты покупают результаты, а не топологию. Клиенту может быть всё равно, идёт ли трафик через Атланту, Ашберн, Чикаго, Лондон или Сингапур, пока изменение маршрутизации не сделает географию видимой. В этот момент клиенты обнаруживают, что топология провайдера — это неявная зависимость. Подотчётный провайдер не обязан публиковать всю чувствительную топологию. Он должен объяснить режим отказа на уровне, позволяющем клиентам понять, был ли инцидент локальным, региональным, системным или глобальным по своей конструкции.

Публичное досье не должно преувеличивать то, что клиенты могут проверить самостоятельно. Публичные коллекторы маршрутов могут показать часть поведения, видимого в BGP, но не могут показать внутренний сброс трафика, локальные политики маршрутизаторов, детали частной магистрали или влияние на прикладной уровень. Журналы клиентов могут показывать неудачные запросы, но не первопричину. Страницы статуса могут показывать состояние сервиса, но не все частные доказательства. Достоверная статья сохраняет эти границы доказательств видимыми.

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

Непрерывность клиентов зависит от доказательств провайдера, а не от его уверенности

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

Форма 10-K Cloudflare за 2020 год по ссылкеисточник: SECдаёт контекст бизнес-рисков компании, а материалы Cloudflare по доверию и соответствию по ссылкеисточник: cloudflare.com— текущий контекст заверений. Инвесторские документы и страницы доверия не являются доказательствами исправления инцидента. Они показывают, что доступность, безопасность и доверие клиентов существенны для бизнес-модели. Это делает детальную подотчётность по инцидентам коммерчески рациональной, а не только этически желательной.

Покупателям решений для непрерывности стоит задавать конкретные вопросы после инцидента. Ограничил ли провайдер радиус поражения изменений правил маршрутизации? Включает ли развёртывание канареечные или ячеечные раскатки сетевых политик? Какие метрики останавливают раскатку? Автоматизированы ли ограничения максимального числа префиксов и локальных предпочтений? Протестирован ли откат? Привязаны ли сообщения о статусе к внутренним состояниям инцидента? Классифицируются ли клиентские сервисы по критичности? Отслеживаются ли внутренние действия из разбора до завершения?

Могут ли корпоративные клиенты получать более детальные доказательства по инциденту по контракту?

Клиентам также нужно проверить свою сторону. Могут ли они безопасно обойти Cloudflare при необходимости? Не откроет ли обход origin для атак? Настроен ли и протестирован ли вторичный DNS? Устойчивы ли приложения к поведению повторных попыток на edge? Знают ли внутренние команды поддержки, когда полагаться на статус Cloudflare, а не открывать инциденты по origin? Готова ли коммуникация публичных сервисов к сбоям сторонних edge-провайдеров? Сбой провайдера не отменяет ответственность клиента за непрерывность, но ответственность клиента справедлива только тогда, когда провайдер предоставляет полезные доказательства.

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

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

Негативные доказательства — часть полезного сетевого разбора

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

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

Для сбоя Cloudflare в июле 2020 года полезные негативные доказательства включали бы границы по целостности данных, конфигурации клиентов, состоянию политик безопасности, состоянию DNS-записей, сертификатов, кода Workers и доступа к origin. Публичные разборы часто сосредоточены на позитивной цепочке отказа, потому что именно там драма. Клиентам нужны и исключения. Им нужно знать, изменило ли событие с правилами маршрутизации контент, утекли ли приватные данные, была ли обойдена политика безопасности, изменился ли DNS или событие лишь помешало достижимости. Если провайдер не может доказать исключение, он должен так и сказать.

Если может — назвать основание.

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

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

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

Подотчётная практика — называть границу.

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

Инструкции клиентов должны включать решения о сбое на стороне edge-провайдера

Сбой Cloudflare в июле 2020 года также показывает, что клиентам нужны инструкции (runbook) для отказа edge-провайдера, а не только для отказа origin. Многие команды реагирования обучены проверять собственное приложение, базу данных, облачный регион, межсетевой экран, уровень аутентификации и историю развёртываний, когда пользователи сообщают о проблемах с доступом. Если перед сервисом стоит edge-провайдер, инструкция должна также спрашивать, есть ли у провайдера текущий инцидент, безопасен ли альтернативный маршрут или обход, здоров ли origin за провайдером и может ли клиент сообщить пользователям о влиянии, не ослабляя безопасность.

Сложность в том, что обход может быть опасен. Клиент, использующий Cloudflare для защиты от DDoS, веб-приложенческого файрвола, терминации TLS, борьбы с ботами, контроля доступа или скрытия origin, может не иметь возможности обойти провайдера, не открыв origin для атак или ошибок конфигурации. Аварийный обход, который работает для одного низкорискового статического сайта, может быть неприемлем для высокорискового API или государственного сервиса. Поэтому планирование сбоя edge-провайдера должно вестись до сбоя.

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

Та же логика применима к вторичному DNS и мульти-CDN. Резервирование снижает зависимость, но добавляет сложность конфигурации и может создать новые пути отказа. Если вторичный провайдер не зеркалирует правила безопасности, поведение кэша, конфигурацию TLS, аутентификацию origin и журналирование, путь перехода может быть менее безопасным, чем сбой. Подотчётность провайдера и непрерывность клиента поэтому взаимодействуют. Cloudflare должен делать свои механизмы контроля сильными; клиенты должны решать, какие сервисы оправдывают стоимость и сложность независимого резерва.

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

Страница статуса провайдера становится входом в этот процесс управления.

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

После инцидента клиенты должны зафиксировать, что видел их собственный мониторинг. Совпадали ли синтетические проверки по времени со статусом провайдера? Было ли влияние хуже у пользователей в определённых регионах? Диагностировали ли команды поддержки сбой origin по ошибке? Затопили ли алерты реагирующих? Усилило ли поведение повторных попыток нагрузку на origin? Сработала ли экстренная коммуникация? Эта клиентская запись не заменяет разбор Cloudflare. Это вторая половина досье подотчётности. Вместе доказательства провайдера и клиента показывают, достаточно ли хорошо понята зависимость, чтобы сохранить её, или архитектуру нужно менять.

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

Такой пакет доказательств позволяет клиенту закрыть собственную заявку о вендорском риске фактами, а не общими заверениями.

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

Поэтому инцидент Cloudflare в июле 2020 года следует читать как проектный импульс для обмена доказательствами между провайдером и клиентами. Публичный блог провайдера может объяснить основной путь отказа. Страница статуса может отслеживать текущие условия. Пакет доказательств для клиента может поддержать закрытие вопросов управления. Телеметрия клиента может показать локальное влияние. Все четыре записи нужны, потому что ни одна из них не отвечает на все вопросы подотчётности.

Провайдер владеет доказательством внутреннего контроля; клиент владеет локальными решениями о непрерывности; публика владеет ожиданием, что сбои общей инфраструктуры описываются так, чтобы затронутые сервисы восстанавливались без догадок.

Такой обмен даёт будущим рецензентам базовую линию для сравнения следующего сбоя с обещанным изменением контроля, вместо того чтобы рассматривать каждый инцидент как изолированную историю.

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

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

Долгосрочный урок: сделать безопасность сетевых изменений наблюдаемой

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

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

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

Более широкие материалы Cloudflare по маршрутизации и надёжности, включаяисточник: cloudflare.com,источник: blog.cloudflare.comиисточник: blog.cloudflare.com, показывают, что компания понимает публичную маршрутизацию как область подотчётности. Кейс июля 2020 года применяет тот же стандарт внутрь. Публичная защита маршрутизации наиболее сильна, когда внутренние механизмы контроля сетевых изменений столь же проверяемы. Клиенты не воспринимают разницу между междоменными и внутридоменными причинами так же чисто, как инженеры. Они воспринимают достижимость.

Инцидент также подсказывает общий вопрос покупателя ко всем edge- и облачным провайдерам: какой класс внутренних изменений может привести к сбою клиента и как этот класс ограничен? Провайдер должен уметь ответить для изменений DNS, маршрутизации, правил межсетевого экрана, сертификатов, политик идентификации, политик кэша, инструментов развёртывания и миграций баз данных. Ответ должен включать и предотвращение, и восстановление. «У нас есть эксперты» — это не контроль. «Мы развёртываем поэтапно, с автоматическими условиями остановки и протестированным откатом» — ближе к контролю. «Мы публикуем разборы с отслеживанием действий» — ещё ближе.

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

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

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