Когда ваш провайдер падает
Последнее обновление:
Страница статуса провайдера — это публичная панель, которую провайдер облака, хостинга, кода или платежей поддерживает, чтобы заявлять о собственном здоровье: один общий индикатор, список компонентов и хроника инцидентов, написанная самим провайдером, пока эти инциденты ещё разворачиваются. Читать её хорошо — операторское умение, потому что заголовок — это сводка, а правда живёт под ней: в том, какой компонент затронут, в каком регионе, с каким объявленным воздействием и как далеко инцидент продвинулся в собственном рабочем процессе провайдера. Эта статья учит такому чтению и заканчивается тем, что делать в первые десять минут, когда провайдер, о котором идёт речь, — один из тех, от кого вы зависите. Начните с доски статуса провайдеров, которая собирает страницы крупных провайдеров в одном снимке, и держите в уме на протяжении всего текста вопрос из это оно лежит, или только вы?: два инструмента отвечают на противоположные половины одного сомнения.
Две разные вещи: индикатор и состояние инцидента
Каждая зрелая страница статуса несёт два отдельных сигнала, которые читатели постоянно путают. Первый — общий индикатор: одно суммарное состояние для всего сервиса, обычно одно из none, minor, major, critical или maintenance в машиночитаемой ленте за страницей — модель, задокументированная в документации для разработчиков Statuspage, которую большинство крупных провайдеров либо использует напрямую, либо близко имитирует. Индикатор намеренно груб. Он существует, чтобы занятой читатель — или машина, как наша доска статуса, — мог за одну секунду ответить на вопрос, не случилось ли там что-то, и он вычисляется из наиболее пострадавшего компонента, собственного суждения провайдера или из обоих.
Второй сигнал — сам инцидент, и у него есть собственный жизненный цикл, который индикатор уплощает. Инцидент открывается с названием, объявленным воздействием и состоянием, взятым из рабочего процесса: расследуется (мы видим симптомы и ещё не знаем причину), идентифицирован (мы знаем причину и работаем над ней), под наблюдением (исправление выпущено, и мы смотрим, удержится ли оно) и решён (мы считаем, что он закончился, с оговоркой о постмортеме). Эти состояния несут информацию, которую индикатор нести не может. Критический инцидент, два часа находящийся под наблюдением, обычно заканчивается; minor-инцидент, вошедший в расследование четыре минуты назад, ещё может стать чем угодно.
Читайте оба, в этом порядке, и читайте обновления между ними. Хроника коротких обновлений под инцидентом — это место, где провайдер говорит вам то, чего заголовок не скажет никогда: какая подсистема отказала, какой обходной путь существует, затронуты ли данные или только доступность, и обещано ли следующее обновление через двадцать минут или через два часа. Инцидент, чьи обновления перестают приходить, сам по себе сигнал — либо команда перегружена, что коррелирует с более долгим сбоем, либо инцидент тихо сложили в больший. Операторы, которые фотографируют заголовок и перестают читать, рутинно действуют по наименее информативному предложению на странице.
Почему «все системы работают» всё равно может означать, что вы лежите
Индикатор суммирует весь сервис, а современные сервисы — не одна вещь. Провайдер может быть честно зелёным глобально, пока регион, в котором вы развёртываете, единственная поверхность продукта, которую вы вызываете, унаследованная версия API, к которой вы привязаны, или плоскость управления, нужная вам для развёртывания, отказывает для каждого клиента, который её касается. Списки компонентов существуют именно поэтому: страница вроде страницы статуса GitHub раскладывает сервис на операции Git, запросы API, Actions, Pages и другое, и любой из них может быть ухудшен, пока общий баннер остаётся успокаивающим — или наоборот, с красным баннером за компонент, которым вы никогда не пользовались.
Есть также три более тихих разрыва. Первый — задержка объявления: провайдер объявляет инцидент, когда подтвердил его, а не когда произошла первая ошибка, поэтому первые минуты многих сбоев показывают зелёную страницу и горящую социальную ленту; страница не лжёт, она просто отстаёт. Второй — пороги: провайдер может считать двухпроцентную частоту ошибок на одном уровне нормальным фоном и никогда ничего не объявлять, пока эти два процента концентрируются ровно на вашем паттерне трафика. Третий — охват: страницы статуса описывают сторону провода провайдера. Отказ DNS, проблема маршрутизации или заблокированный путь между вашими пользователями и здоровым провайдером производит полный сбой для вас под зелёным индикатором — и поэтому сопутствующий вопрос, лежит ли оно или только вы, должен решаться с независимых точек обзора, а не с собственной страницы провайдера.
Рабочее правило — относиться к зелёному как к «нет объявленного инцидента», никогда как к «доказанно здорово». Когда ваш собственный мониторинг говорит, что пользователи терпят неудачу, а провайдер говорит «работает», верьте своему мониторингу в том, что касается ваших пользователей, и используйте страницу статуса для другой работы: проверять, появится ли позже объявление, которое ретроспективно подтверждает причину, и имеет ли компонент, от которого вы зависите, историю инцидентов, по форме похожих на тот, что вы переживаете.
Подписывайтесь на компоненты, а не на страницы
Большинство операторов подписываются на страницу статуса так, как подписываются на рассылку: одна подписка, каждый инцидент, навсегда — а затем, предсказуемо, начинают игнорировать почту, потому что глобальная лента крупного провайдера производит ровную капель инцидентов о компонентах, которыми они не пользуются, в регионах, которые они не обслуживают. Усталость от оповещений — не недостаток характера; это корректный ответ на плохо очерченный сигнал. Исправление механическое и доступно почти на каждой зрелой странице статуса: подписывайтесь на уровне компонента. Та же модель Statuspage, что определяет индикаторы, позволяет подписчикам и фильтровать по компоненту, а провайдеры, крутящие собственные системы, как страница статуса Cloudflare, предлагают тот же выбор через свои собственные потоки подписки.
Ограничивайте каждую подписку тем, что действительно изменило бы ваше поведение в 3 часа ночи. Компоненты, которые вызывает ваш производственный трафик, принадлежат громкому каналу — тому, что звонит, шлёт сообщения или по крайней мере помечает то, что вы увидите в течение минут. Компоненты, которые вы используете только для сборок, аналитики или внутренних инструментов, принадлежат тихому каналу, который вы просматриваете в рабочие часы. Компоненты, которыми вы не пользуетесь, не принадлежат никуда: каждое уведомление, которое вы корректно игнорируете, делает следующее легче игнорируемым, включая то, которое имеет значение. Пересматривайте список всякий раз, когда меняется стек, потому что подписки гниют в обе стороны — новые зависимости, на которые никто не подписался, и мёртвые, всё ещё звонящие в канал, который никто не смотрит.
Предпочитайте машиночитаемые ленты, где можете. Электронная почта — самый медленный и самый игнорируемый канал, который предлагает страница статуса; вебхуки и ленты могут питать вашу собственную панель, открывать внутренний тикет или переворачивать подготовленную страницу ожидания вашей команды поддержки до того, как придёт первая жалоба пользователя. Даже лёгкая версия окупается: снимок на нашей доске статуса провайдеров построен именно из этих публичных лент, что доказывает: данные там для того, чтобы их потребляли программно, а не любовались ими во вкладке браузера, которую нужно не забыть открыть.
Постройте свой собственный инвентарь зависимостей
Ни один из советов выше не работает без списка, и большинство команд обнаруживает во время сбоя, что у них его нет. Инвентарь зависимостей — это просто письменный ответ на вопрос, который звучит тривиально и таковым не является: какие внешние сервисы, если они остановятся сегодня ночью, остановят нас — а какие лишь поставят нас в неловкое положение? Стройте его в спокойную погоду. Пройдите свою архитектуру поверхность за поверхностью — хостинг, DNS, хостинг кода и CI, провайдеров базы данных и хранения, платёжного обработчика, отправителей почты и SMS, провайдера идентичности, трекер ошибок, аналитический тег, шрифты и скрипты, которые ваши страницы грузят с чужого CDN, — и запишите для каждого: провайдера, компонент, который вы реально потребляете, где живёт его страница статуса и что испытывают ваши пользователи, когда он отказывает.
Ранжируйте каждую запись по форме её отказа, а не по тому, насколько вам нравится продавец. Некоторые зависимости жёсткие: остановятся они — остановитесь вы, и единственная доступная работа — коммуникация и ожидание. Некоторые мягкие: сайт работает без них, ухудшенно — без аналитики, без виджета чата, без персонализации, — и для них инвентарь должен говорить, кому позволено их выключать и как. А некоторые скрытые: транзитивные зависимости, которые вы не выбирали, вроде состояния облачного региона, в котором крутится ваша собственная SaaS-база, или инфраструктуры сертификатов и DNS подо всем. Скрытые зависимости — те, что производят сбой «всё лежит, и ничего из того, за что мы платим, нет в списке», и вы находите их, спрашивая каждого продавца один раз, от чего зависит он.
Держите инвентарь там, где инцидент может до него дотянуться: в ранбуке, рядом со списком эскалации, а не на вики-странице, которую никто не сможет открыть, когда провайдер идентичности — именно то, что лежит. Одной страницы достаточно. Его работа во время сбоя — превращать «что-то не так» в контрольный список — по каждой жёсткой зависимости, вверх или вниз, за тридцать секунд, — а его работа после — быть исправленным, потому что каждый настоящий инцидент учит вас чему-то о зависимости, которую вы оценили неправильно. Инвентарь, который никогда не исправляют, — исторический документ, а не оперативный.
Первые десять минут сбоя провайдера
С нулевой по вторую минуту: подтвердите и локализуйте. Проверьте свой собственный мониторинг, чтобы убедиться, что отказ настоящий и объявлять его вам, а затем откройте доску статуса и страницу подозреваемого провайдера. Вы отвечаете на один вопрос: есть ли объявленный инцидент, пересекающийся с тем, что вы используете, — компонент, регион, продукт? Если да, у вас есть причина и первое сообщение. Если нет, расширьте проверку: другой провайдер из вашего инвентаря, ваше собственное последнее развёртывание, ваш DNS. Большинство ложных драм умирает в эти две минуты, и большинство настоящих обретает здесь свою форму.
Со второй по пятую минуту: сообщайте, ясно и рано. Скажите своим пользователям в каналах, которые они реально читают, что у названного вышестоящего провайдера инцидент, что это значит для них в практических терминах — что не работает, что ещё работает, в безопасности ли их данные, — и когда вы обновите их снова. Честное удерживающее сообщение, отправленное на четвёртой минуте, бьёт точное объяснение, отправленное на сороковой, потому что молчание — это то, что пользователи заполняют своими худшими догадками и именами ваших конкурентов. Внутри откройте один поток инцидента, назначьте одного человека говорить и помечайте всё временем; вы поблагодарите себя на постмортеме, и команда поддержки провайдера тоже, если они вам понадобятся.
С пятой по десятую минуту: перестаньте делать хуже и подготовьте мягкие посадки. Заморозьте развёртывания — изменение, сделанное внутрь активного вышестоящего инцидента, нельзя оценить, и его, возможно, нельзя даже откатить. Выключите агрессивные повторы и несущественные задания, молотющие отказавшего провайдера; восстановление измеримо медленнее, когда десять тысяч клиентов повторяют в ногу, и некоторые провайдеры ограничат вас до второго, уже самопричинённого сбоя. Выключите или ухудшите мягкие зависимости, которые ваш инвентарь пометил как сбрасываемые, выставьте страницу ожидания, если она у вас есть, а затем устройтесь в ритме, который диктует инцидент: следите за обновлениями провайдера, обновляйте пользователей в обещанные времена, есть новости или нет, и не меняйте ничего другого, если не изменились факты. Сбой закончится по расписанию провайдера, а не по вашему; ваши десять минут решают, запомнят ли ваши пользователи его как плохой день их провайдера или как ваш.