Канадский телекоммуникационный гигант Rogers, по вине которого пятницу 8 июля 2022 года остались без связи миллионы абонентов мобильной и стационарной связи, пообещал инвестировать $7,7 млрд (C$10 млрд) в повышение надёжности систем и принять ряд мер по недопущению подобных сбоев в будущем. Об этом сообщает издание The Register.

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

Источник изображения: mwangi gatheca/unsplash.com

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

Компания уже заключила соглашение о партнёрстве с неназванной «ведущей технологической фирмой» для полного аудита сети. Многомиллиардные инвестиции будут осуществляться в течение трёх ближайших лет. Тем не менее, канадский регулятор Canadian Radio-television and Telecommunications Commission (CRTC) напомнил, что нечто подобное уже случилось с сетью Rogers в апреле 2021 года.

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

Во вторник, 19 июля, в ЦОД Google Cloud Platform (GCP) в Лондоне произошёл сбой в системе охлаждения, в связи с чем несколько сервисов компании временно вышло из строя. В лондонском регионе облака Oracle тоже возникли проблемы с охлаждением оборудования ЦОД. Сбои произошли из-за рекордной жары в Великобритании — температура превысила +40°C. Некоторые операторы дата-центров были вынуждены принять нестандартные меры, начав обрызгивать водой внешние модули систем кондиционирования, установленные на крыше.

Отключение ряда сервисов Google произошло в 18:13 по местному времени (20:13 мск). В журнале статуса оборудования сбой описан как «связанный с охлаждением». Google заявила, что сбой затронул лишь небольшое количество клиентов. В частности, отключение коснулось сервисов Persistent Disk и Autoscaling. Хотя Google утверждает, что сбой продолжался до 22:00 BST (24:00 мск), в означенное время всё ещё поступали жалобы на ошибки в работе Persistent Disk.

Изображение: pixabay.com / Gam-Ol

С подобными проблемами в Лондоне столкнулась и облачная служба Oracle. Проблемы с перегревом у неё начались примерно в 17:00 по местному времени (19:00 мск). Oracle ранее арендовала ресурсы в ЦОД Equinix в лондонском кампусе Слау, но сейчас не раскрывает местонахождение своих мощностей. «В результате несезонных температур в регионе возникла проблема с частью инфраструктуры охлаждения в центре обработки данных на юге Великобритании (в Лондоне), — говорится в сообщении компании. — Это привело к тому, что часть нашей сервисной инфраструктуры пришлось отключить, чтобы предотвратить неконтролируемые сбои оборудования».

Согласно докладу 2022 Outage Analysis Report, представленному Uptime Institute, несмотря на усилия, прилагаемые операторами информационных систем и активные инвестиции в инфраструктуру, число сбоев в IT-системах остаётся приблизительно на том же уровне, что и в прошлые годы.

Хотя инвестиции в облачные технологии и отказоустойчивые системы помогли повысить надёжность на уровне объектов инфраструктуры, попутно увеличилась сложность систем, что оказывает негативное влияние на надёжность. В частности, растёт число инцидентов, связанных с сетями связи, ПО и другими факторами. Авторы доклада подчёркивают, что хотя десятилетия работы над критическими IT-системами сделали их намного надёжнее, число незапланированных отключений за последние годы почти не изменилось.

В 80 % организаций отключения IT-инфраструктуры случались хотя бы раз за последние три года, а каждый пятый опрошенный заявил о «серьёзных» и «тяжёлых» сбоях в тот же период. В первом случае по классификации Uptime Institute речь идёт о перебоях в работе сервисов с возможными финансовыми потерями, во втором — о крупных инцидентах, ведущих к большим финансовым потерям. По статистике Uptime, ежегодно в мире происходит приблизительно серьёзных 20 инцидентов, ведущих к крупным убыткам, репутационным издержкам и массовым проблемам в работе бизнесов и/или клиентов.

Источник изображения: Florian Krumm/pixabay.com

Любопытно, что основной причиной инцидентов являются перебои электропитания — это главный фактор в 43 % случаев. При этом дело редко обходится без сопутствующих причин. В числе прочих факторов — проблемы с программным обеспечением, сетями и системами охлаждения. Также выяснилось, что за 5 лет облачные операторы, хостинг- и колокейшн-провайдеры чаще всего виноваты в проблемах публичных сервисов, причём в 2021 году этот показатель вырос до 71 %.

Примечательно, что продолжительность сбоев продолжает увеличиваться. Это не может не беспокоить пользователей, поскольку простой тем дороже и разрушительнее, чем он длительнее. В 2021 году число сбоев, длившихся более 48 часов, составляло 16 %, а в 2017 году — 4 %. От 24 до 48 часов — 12 % в сравнении с 4 % в 2017 году. Выросли и убытки. Если в 2019 году 60 % крупных сбоев обходились дешевле $100 тыс., 28 % — от $100 тыс. до $1 млн, то в 2021 году показатели выросли до 39 % и 47 % соответственно. Число сбоев, обошедшихся дороже $1 млн, выросло с 11 до 15 %.

Доступность многих интернет-сервисов на некоторое время пострадала в результате сбоев, начавшихся на Ближнем Востоке и в Азии, а позже распространившихся буквально на весь мир. По данным OVHcloud, сбои наблюдались с 15:24 по 18:00 МСК 7 июня (с 12:24 по 15:00 UTC).

Кабельная система Asia-Africa-Europe-1 (AAE-1) протяжённостью 25 тыс. км соединяет Юго-Восточную Азию с Европой, её фрагмент пролегает по суше на территории Египта, где она, судя по всему, и был повреждена. По данным экспертов, это вызвало перебои с интернетом на востоке Африки, на Ближнем Востоке и в Азии, включая Пакистан, Сомали, Джибути и Саудовскую Аравию. После этого проблемы начались и в других регионах.

Источник: www.aaeone.com

Эксперты утверждают, что инцидент произошёл где-то на территории Египта — если бы был повреждён подводный фрагмент, на ремонт ушли бы дни. Необычность ситуации в том, что параллельно перебои наблюдали и пользователи кабельной системы SEA-ME-WE 5. Последняя, по-видимому, каким-то образом оказалась связана с AAE-1, хотя в теории такого быть не должно.

В итоге проблемы распространились далеко за пределы Ближнего Востока и Азии. Известно, что помимо клиентов Google Cloud пострадали клиенты сервисов AWS и Microsoft и других популярных платформ в Азии, Африке, Австралии, Европе, Северной и Южной Америке. На текущий момент проблемы решены, но эксперты всё ещё разбираются в первопричинах инцидента.

Пользователи суперкомпьютера Киотского университета лишились 77 Тбайт информации из-за сбоя в работе системы резервного копирования, который произошёл по вине японского подразделения HPE. Из-за ошибки было потеряны данные за 1,5 дня работы — более 34 млн файлов. В результате инцидента пострадали данные 14 групп пользователей, для четырёх из которых информация утеряна безвозвратно.

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

Изображение: gizchina.com

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

Суперкомпьютерная группировка Киотского университета. Изображение: monitaana.com

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

Компания Fastly сообщила о сокращении выручки и потере клиентов из-за того, что в июне произошёл крупный сбой в её сети доставки контента (CDN). Fastly использует периферийные точки присутствия для хранения контента с целью сокращения задержек в передаче данных и защиты клиентов от DDoS-атак, что помогает им справляться с пиками трафика. Но 8 июня из-за ошибки в конфигурации вся система вышла из строя.

В числе компаний, пострадавших от сбоя — Amazon, Twitch, Reddit, веб-сайты правительства Великобритании, а также множество других сайтов и сервисов. Сбой привёл к снижению объема трафика. «Мы ожидаем увидеть влияние сбоя на выручку в краткосрочной и среднесрочной перспективе, поскольку мы работаем с нашими клиентами, чтобы вернуть их трафик к нормальному уровню», — написал генеральный директор Fastly Джошуа (Joshua Bixby) Биксби в письме к акционерам.

Fastly

Он добавил: «У нас есть несколько клиентов, один из которых входит в Топ-10 заказчиков, которые пока не вернули свой трафик на платформу. У нас также было несколько клиентов, которые отложили запуск новых проектов, что приведёт к задержке времени поступления трафика на нашу платформу».

Fastly отметила, что сбой и эти задержки повлияли на её прогноз на третий квартал и весь год. Стоимость акций компании упала в конечном итоге на 19 %, хотя они показали резкий рост вскоре после инцидента. Несмотря на непредвиденные затраты, связанные со сбоем, выручка компании выросла на 14 % до $85 млн по сравнению с аналогичным периодом прошлого года, что немного ниже прогноза Уолл-стрит, равному в $85,7 млн.

IBM сообщила причины сбоя в работе облачного сервиса IBM Cloud во вторник, длившегося несколько часов и приведшего к обрушению сайтов и систем клиентов компании по всему миру. Слухи о возможной хакерской атаке не подтвердились, хотя компания обвинила в происшедшем инциденте «третью сторону».

В кратком уведомлении на странице состояния облачного сервиса компании было приведено следующее объяснение сбоя: «Подробный анализ первопричин ведётся. Расследование показывает, что провайдер внешней сети превысил нагрузку на сеть IBM Cloud из-за неправильной маршрутизации, что привело к серьезной перегрузке трафика и негативно сказалось на сервисах IBM Cloud и наших центрах обработки данных. Были предприняты меры по устранению проблем, чтобы предотвратить повторение. Анализ первопричин не выявил каких-либо проблем с потерей данных или кибербезопасностью».

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

Можно предположить, что вина на минувшем сбое лежит на Akamai, провайдере платформ доставки контента и приложений, сотрудничающем с IBM. Тем не менее, сама IBM пока не всегда справляется с резкими скачками трафика. Например, при проведении электронной переписи населения в Австралии, компания по ошибке определила поток входящих соединений как (D)DoS-атаку.

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

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

На странице IBM, отражающей статус сервиса, появилось сообщение об ошибке, поэтому было сложно определить, насколько сильным являлся сбой и причину проблемы. «Извините, мы столкнулись с ошибкой с нашей стороны, и наши разработчики работают над её устранением. Пожалуйста, попробуйте перезагрузить страницу», — сообщалось на странице IBM Cloud.

Согласно данным ресурса DownDetector, первые жалобы пользователей на сбои в работе сервиса начали поступать во вторник, примерно в 14:30 PT (в среду в 0:30 мск). В аккаунте IBM Cloud в Twitter сохранялось молчание, но ресурс TechCrunch нашёл страницу подразделения IBM Aspera, размещённую на стороннем сервере, которая подтвердила наличие проблемы с сервисом по всему миру. «Мы были предупреждены о сбое в работе службы, затронувшем IBM AoC Managed Storage. Наши инженеры в настоящее время проводят расследование инцидента и будут предоставлять обновления, когда появится больше информации», — сообщалось на этой странице.

По словам Aspera, AoC Managed Storage столкнулся со «серьёзным сбоем» в Амстердаме, Далласе, Франкфурте, Мельбурне и Торонто. В числе пострадавших были указаны облачные кластеры IBM в Амстердаме, Ченнаи, Далласе, Франкфурте, Гонконге, Лондоне, Мельбурне, Мексике, Милане, Монреале, Осло, Сан-Хосе, Сан-Паулу, Сеуле, Сиднее, Токио, Торонто, Вашингтоне, Париже и Сингапуре.

В конечном итоге сервис IBM Cloud воспользовался Твиттером, чтобы известить пользователей о сбое и о том, что его специалисты занимаются решением проблемы. «Службы IBM Cloud восстанавливаются после того, как сегодня утром было зарегистрировано отключение. Мы нацелены на восстановление полных служб как можно скорее», — сообщалось в аккаунте IBM Cloud в 4:30 мск. А уже в 4:54 мск в Твиттере появилось сообщение о полном возобновлении работы всех служб IBM Cloud.

«Ростелеком» объявил о крупном сбое, который затронул несколько регионов России. Устранить неполадки планируется не раньше субботы.

«Произошла массовая авария, которая затронула сразу несколько регионов. Ведутся восстановительные работы. Ориентировочный срок решения 17.08 в течение дня», — сообщил оператор в Twitter-блоге.

Какие именно регионы были затронуты, в сообщении не уточняется. Согласно данным сервиса Downdetector, который отслеживает неполадки на различных сайтах, а также жалобы пользователей в социальных сетях, на сбои в работе оператора жалуются пользователи из Иркутска, Читы, Владивостока, Хабаровска и некоторых других городов.

Большинство абонентов (91 %), которых коснулась проблема, говорят, что не могут подключиться к Интернету. Ещё 6 % пожаловались на сбой в работе всех сервисов, 2 % пользователей указали на проблемы с телевидением.

Судя по статистике на Downdetector, массовые сбои начались около 9:00 по московскому времени. Они достигли пика в районе 14:00, когда было получено 460 отчетов о неполадках.

В Telegram-канале «ЗаТелеком» появилось сообщение о том, что причиной масштабного сбоя у «Ростелекома» стал обрыв на магистрали в районе посёлка Емельяново, недалеко от Красноярска. Точка обрыва находится на линии от Красноярска до Хабаровска, протяжённость которой составляет порядка 3 тыс. км.

Команда разработчиков «Яндекса» раскрыла детали инцидента, произошедшего 16 мая и повлёкшего негативные последствия для ряда пользователей cloud-платформы «Яндекс.Облако», лишившихся доступа к своим виртуальным машинам (ВМ) и данным.

«16 мая были запланированы регулярные технические работы по остановке и удалению виртуальных машин в облаках пользователей, заблокированных из-за неоплаты или нарушения правил использования сервисов "Яндекс.Облака". Это стандартная процедура по высвобождению ресурсов платформы, — говорится в заявлении компании. — В 16:35 (MSK) была запущена команда по удалению ВМ согласно сформированному списку. В 16:51 была обнаружена ошибка, и в 16:56 выполнение команды было остановлено в срочном порядке. Выяснилось, что при формировании списка был применён неверный принцип фильтрации, и в список попали активные виртуальные машины. Сейчас мы в процессе расследования ситуации и выяснения деталей».

Сообщается, что в результате инцидента были удалены 0,77% от общего числа виртуальных машин и boot-дисков. При этом были затронуты виртуальные машины только в зоне ru-central1-c. «Дополнительно созданные диски остались в сохранности. Пользователи, у которых были сделаны снимки дисков, смогли восстановить свои данные», — уточняют в «Яндексе».

Как бы то ни было, ситуация не из приятных. Для предотвращения подобных инцидентов в будущем в компании обещают принять ряд технических и организационных мер, а также призывают пользователей регулярно создавать резервные копии критически важных данных. «Мы хотим принести извинения каждому, кого затронул технический сбой в работе "Облака", — говорят в Яндексе. — На данный момент наша техническая поддержка работает в формате горячей линии, и мы оперативно помогаем каждому пользователю. В качестве компенсации всем, кого затронул инцидент, будут начислены гранты. Размер гранта будет определен индивидуально для каждого пользователя. Гранты станут доступны в личном кабинете в консоли "Облака" в течение трёх рабочих дней. Кроме того, для пострадавших пользователей снимки дисков не будут тарифицироваться в течение 90 дней (нулевая тарификация вступит в силу также в течение трёх рабочих дней)».

Материалы по теме:

• Платформа «Яндекс.Облако» стала доступна для всех пользователей в России;
• К 2021 году почти все рабочие нагрузки перенесут в облако;
• Услуги облачной платформы «Яндекс.Облако» обойдутся дешевле, чем у конкурентов.

Источник:

• cloud.yandex.ru