Десять лучших разрушений 2022 года

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

Виновники, которые привели к краху крупных инфраструктурных и сервисных провайдеров, также были самыми разными, согласно анализу ThousandEyes, принадлежащей Cisco компании по киберразведке, которая отслеживает интернет- и облачный трафик. Ошибки, связанные с техническим обслуживанием, упоминались неоднократно: Канадский оператор Rogers Communications столкнулся с масштабным общенациональным сбоем, который был связан с обновлением, а ошибка в сценарии обслуживания вызвала проблемы у производителя программного обеспечения Atlassian.

Ошибки конфигурации BGP также появляются в отчетах об отключениях. Протокол Border Gateway Protocol указывает интернет-трафику, по какому маршруту двигаться, но если информация о маршрутизации неверна, то трафик может быть перенаправлен на неправильный маршрут, что и произошло с Twitter. (Подробнее об отключениях в США и по всему миру читайте в нашем еженедельном обзоре состояния Интернета.

Вот 10 самых громких событий года в хронологическом порядке.

British Airways теряет онлайн-систему: 25 февраля

25 февраля онлайн-сервисы авиакомпании British Airways были недоступны в течение нескольких часов, что привело к отмене сотен рейсов и нарушению работы авиакомпании. Авиабилеты нельзя было забронировать, а путешественники не могли пройти электронную регистрацию. По сообщениям, авиакомпания была вынуждена вернуться к бумажному документообороту, когда ее онлайн-системы стали недоступны, и последствия этого ощущались по всему миру. "Наш мониторинг показывает, что сетевой путь к онлайн-сервисам (и серверам) авиакомпании доступен, но ответы сервера и сайта сбиваются по времени", - говорится в анализе сбоя, проведенном компанией ThousandEyes, которая возложила ответственность за сбой на не реагирующий на запросы сервер приложений. - Вместо проблем с сетью - перебои.

"Характер проблемы и реакция авиакомпании на нее позволяют предположить, что первопричиной может быть центральное внутреннее хранилище, на которое опираются многочисленные внешние службы. Если это так, то данный инцидент может послужить основанием для British Airways перестроить или деконструировать свои Catalysts, чтобы избежать единых точек отказа и снизить вероятность повторения. Однако не менее вероятно, что последовательность событий, приведших к сбою, происходит редко и в будущем может быть в значительной степени контролируема. Время покажет", - заявили в Thousand Eyes.

Twitter, захваченный BGP: 28 марта

28 марта российский провайдер интернета и спутниковой связи ОАО "РТКомм.РУ" некорректно объявил один из префиксов Twitter (104.244.42.0/24), что привело к перенаправлению трафика на Twitter для некоторых пользователей и сбоям. Некоторые пользователи не могут пользоваться Twitter. После того как RTComm отозвал BGP-консультацию, пострадавшие пользователи восстановили доступ к сервису Twitter. ThousandEyes отмечает, что неправильная конфигурация BGP может быть использована для целенаправленного блокирования трафика, но не всегда легко определить, является ли ситуация случайной или преднамеренной.

"Мы знаем, что инцидент с Twitter 28 марта был вызван тем, что RTComm объявил себя источником префикса Twitter, а затем отозвал его. Хотя мы не знаем, что привело к этому объявлению, важно понимать, что случайные неправильные конфигурации BGP - не редкость, и, учитывая, что провайдер отозвал этот маршрут, вполне вероятно, что у RTComm не было намерения вызвать глобальный перебой в работе сервиса Twitter. Тем не менее, провайдеры в некоторых регионах используют локальные манипуляции с BGP для обеспечения локальных политик доступа, основанных на блокировке трафика", - говорится в анализе сбоя, проведенном ThousandEyes.

Один из способов борьбы с утечками и перехватами маршрутов - оперативное обнаружение и защита BGP с помощью таких механизмов безопасности, как инфраструктура открытых ключей ресурсов (RPKI) - криптографический механизм безопасности, используемый для авторизации источника маршрута. RPKI эффективен против угона и утечки данных BGP, но его внедрение не является повсеместным. "В то время как ваша компания, возможно, внедрила RPKI для защиты от угроз BGP, ваша телекоммуникационная компания может этого не делать. Это нужно учитывать при выборе провайдера", - говорит ThousandEyes.

Atlassian преувеличивает последствия сбоя: 5 апреля

Утром 5 апреля компания Atlassian сообщила о проблемах с несколькими крупнейшими инструментами разработки, включая Jira, Confluence и OpsGenie. Ошибка в сценарии обслуживания привела к тому, что работа этих сервисов была нарушена на несколько дней, но затронула лишь около 400 клиентов Atlassian.

Анализируя этот случай, ThousandEyes подчеркнула важность страниц состояния поставщиков при сообщении о проблемах: На странице статуса Atlassian было "море оранжевых и красных индикаторов", указывающих на серьезный сбой, и компания заявила, что мобилизует сотни инженеров для устранения инцидента, но для большинства клиентов проблемы не существует.

Страницы со статусом часто недооценивают масштабы отключения, но страницы со статусом могут и преувеличивать его последствия, предупреждает ThousandEyes: "Это очень сложный баланс: скажите слишком мало или слишком поздно, и клиенты будут чувствовать беспокойство по поводу оперативности реагирования; скажите слишком много Слишком много, и будучи слишком прозрачным, вы рискуете излишне обеспокоить большое количество незатронутых клиентов, а также более широкие заинтересованные стороны".

Перебои с электричеством у компании Rogers: 8 июля

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

По данным ThousandEyes, Rogers отозвала свои префиксы из-за внутренних проблем с маршрутизацией, в результате чего провайдеры первого уровня оказались недоступны в Интернете почти на 24 часа. "Этот инцидент, по-видимому, был вызван отзывом большого количества префиксов Rogers, что сделало их сеть недоступной из глобального интернета. Однако поведение, наблюдаемое в их сети в это время, позволяет предположить, что отказ от внешних BGP-маршрутов мог быть вызван внутренними проблемами маршрутизации", - говорится в анализе перебоев, проведенном ThousandEyes.

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

Перебои в работе AWS в восточном регионе США: 8 июля

28 июля в зоне доступности 1 (AZ1) Amazon Web Services (AWS) в регионе Восток 2 США произошел сбой в подаче электроэнергии. "Перебой повлиял на связь с регионом и привел к сбою в работе EC2-экземпляров Amazon, что повлияло на работу таких приложений, как Webex, Okta, Splunk, BambooHR и других", - сообщает ThousandEyes в своем анализе перебоев. Не все пользователи и сервисы пострадали одинаково; например, компоненты Webex, расположенные в дата-центрах Cisco, по-прежнему работают нормально. AWS сообщила, что перебои в работе длились всего 20 минут, но на восстановление сервисов и приложений некоторых клиентов ушло до трех часов.

Важно предусмотреть определенную степень физического резервирования в облачных приложениях и сервисах, пишет ThousandEyes: "Мягкой посадки при отключении центра обработки данных не бывает - когда отключается электричество, это тяжело отражается на зависимых системах. Будь то отключение электросети или смежных систем (в такие времена архитектурная устойчивость и избыточность цифровых сервисов имеют решающее значение.

Google Search, Google Maps устарели: 9 августа

Кратковременное отключение затронуло Google Search и Google Maps, и эти широко используемые сервисы Google были недоступны для пользователей по всему миру около часа. "Попытки получить доступ к этим сервисам приводят к появлению сообщений об ошибках на граничных серверах Google, включая ответы HTTP 500 и 502, которые часто указывают на внутренние проблемы сервера или приложения", - сообщает ThousandEyes.

Согласно сообщениям, первопричиной стало неудачное обновление программного обеспечения. Конечные пользователи не только не могли получить доступ к Google Search и Google Maps, но и приложения, которые зависели от функциональности программного обеспечения Google, также перестали работать во время сбоя.

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

Перебои в работе Zoom нарушают работу виртуальных совещаний: 15 сентября

Во время сбоя 15 сентября пользователи не могли войти в систему или присоединиться к собраниям Zoom в течение примерно часа, что привело к появлению ошибок Bad Gateway (502) у пользователей по всему миру. Пользователи не могли войти в систему или присоединиться к совещаниям, а в некоторых случаях пользователей, уже участвовавших в совещании, выкидывало из него.

Первопричина не установлена, но, судя по всему, она кроется в внутренних системах Zoom, связанных с их способностью разрешать, маршрутизировать или перераспределять трафик", - говорится в анализе сбоя, проведенном ThousandEyes.

Агент Zscaler страдает от потери пакетов 100%: 25 октября

25 октября на некоторых конечных точках прокси-сервера Zscaler произошла потеря пакетов 100%, что повлияло на клиентов, использующих услугу Zscaler Internet Access (ZIA) в своей облачной сети Zscaler Cloud Network 2. Согласно анализу сбоев, проведенному ThousandEyes, наиболее серьезная потеря пакетов продолжалась около 30 минут, хотя некоторые проблемы с доступностью и скачки потери пакетов в определенных местах пользователей сохранялись периодически в течение следующих трех часов.

На странице состояния Zscaler называет эту проблему "проблемой переадресации трафика". Когда виртуальный IP-адрес прокси-устройства недоступен, трафик не может быть переадресован.

Компания ThousandEyes объяснила, как эта ситуация помешала некоторым клиентам, использующим службу безопасности Zscaler, получить доступ к критически важным бизнес-инструментам и SaaS-приложениям: "Это могло повлиять на различные приложения корпоративных клиентов, использующих службу Zscaler, поскольку она находится на границе службы безопасности (типично для реализаций SSE) для проксирования не только веб-трафика, но и других критически важных бизнес-инструментов и SaaS-сервисов, таких как Salesforce.com, ServiceNow и Microsoft Office 365. Таким образом, прокси находится на пути данных пользователя, и когда прокси недоступен, возникает необходимость в доступе к этим инструментам, а для исправления ситуации часто требуется ручное вмешательство, чтобы перенаправить затронутых пользователей на альтернативный шлюз.

WhatsApp прекращает обмен сообщениями: 25 октября

В результате двухчасового сбоя 25 октября пользователи WhatsApp не могли отправлять и получать сообщения на платформе. Бесплатное программное обеспечение, принадлежащее компании MetaWiki, является самым популярным в мире приложением для обмена сообщениями - 31% населения планеты пользуется WhatsApp, согласно данным платформы цифровой аналитики Similarweb за 2022 год.

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

Восточный регион AWS США снова под ударом: 5 декабря

Amazon Web Services (AWS) пережила второй перебой в работе своего региона US East 2 в начале декабря. По данным AWS, перебои длились около 75 минут и привели к проблемам с подключением к Интернету в регионе US East 2 и из него.

Компания ThousandEyes наблюдала потерю пакетов между двумя глобальными точками и регионом США-Восток-2 AWS в течение более часа. Этот инцидент затронул конечных пользователей, которые подключались к сервисам AWS через своих провайдеров. "Эта потеря происходит только между конечными пользователями, подключенными через своих провайдеров, и, похоже, не влияет на связь между инстансами внутри или между регионами", - говорится в анализе сбоя, проведенном ThousandEyes.

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