Согласно информации издания Register и публикации в корпоративном блоге компании Cloudflare, в середине апреля 2020 года произошел серьезных инцидент, приведший к прерыванию на четыре с половиной часа сервисов Cloudflare Dashboard и Cloudflare API.
Данный сетевой инцидент 15 апреля 2020 года начался с планового технического обслуживания в одном из основных центров обработки данных компании. В ходе работ инженеру, занимающемуся демонтажем, было дано простое задание от технических специалистов Cloudflare — отключить и убрать все сетевое оборудование в одном из телекоммуникационных шкафов. По информации сетевых инженеров компании, в этом шкафу было установлено устаревшее сетевое и серверное оборудование, которое в сети компании уже не было задействовано, поэтому работы проводились инженером без остановки сервисов и в обычное рабочее время.
Однако, в реальности оказалось, что в этом шкафу был установлен коммутационный оптический кросс, обеспечивающий все внешние подключения к другим дата-центрам Cloudflare. Инженеру понадобилось менее трех минут, чтобы отключить все немаркированные оптические кабели и патч-корды от этого оптического кросса, который был единственной точкой отказа для этого центра обработки данных Cloudflare.
«Начиная с 15:31 UTC и продолжая до 19:52 UTC, сервисы Cloudflare Dashboard и Cloudflare API стали недоступны из-за отключения нескольких избыточных оптоволоконных соединений в одном из наших основных центров обработки данных», — заявил в блоге представитель Cloudflare.
После регистрации инцидента сетевые специалисты компании пытались максимально разобраться в произошедшем, но это заняло у них много время, так как многие оптические кабели как в телекоммуникационном шкафу, где проводились работы, так и в других местах дата-центра, не были правильно промаркированы, из-за чего пришлось выполнять на месте дополнительные проверки соединений с помощью специального оборудования.
Также для решения этой проблемы более двадцати сетевых инженеров работали удаленно, помогая организовать восстановление связи и следили за аварийным восстановлением сервисов после сбоя.
Cloudflare обещает, что не будет наказывать инженера, проводившего регламентные технические работы, закончившиеся аварией. В компании примут дополнительные меры как проектного, так и технического характера, чтобы подобные происшествия не случались в будущем.
Вдобавок в Cloudflare уверили, что информация клиентов не пострадала, просто у них пропал доступ к части сервисов компании, а все конфигурационные данные были сохранены компанией и не изменились во время инцидента.
Во время инцидента продолжали штатно работать: сама сеть Cloudflare, прокси-сайты клиентов и приложения, в том числе Magic Transit, Cloudflare Access, Cloudflare Spectrum, Web Application Firewall. Также полноценно функционировали все системы безопасности компании.
Ранее 22 июля 2019 сервис Cloudflare был недоступен в течение 27 минут, причем одной из причин стало неправильного использования инженером регулярного выражения в правиле для обнаружения XSS с помощью автоматического процесса.
CherryPah
Пользуйтесь облаками, там работают профессионалы, все пятикратно зарезервировано и геораспределено.
Взгляд изнутри облака — синяя изолента и костыли.
Ну и вообще меня немножко удивляет что инженер работающий в цоде хоть немного не в курсе топологии этого цода и закрывают таски не включая голову. Или
корпоративное взаимодействиезапредельный бюрократизм виной? Ну по крайней мере если мне придет задача демонтировать 40 юнит в 5ой стойке, а я вижу что там стоит вводной кросс на всю серверную — это точно будет поводом уточнить у вышестоящих нет ли ошибки и попытаться донести до них ошибочность решения.Akuma
Вы так говорите, как будто не ошибаетесь :)
Все хотя бы раз что-то удаляли, отключали, ломали по запарке. Бывает, что уж.
CherryPah
Но это именно как раз описанная вами ошибка допущенная по запаре. В случае же с CF аналогия у меня возникает как заливка заведомо неверного конфига, потому что такой прислали
sav6622
Вот этим и отличается наш инженер от ихнего… те не думают, как в армии — поставлена задача — выполняю…
Но у этого есть и оборотная сторона (побочка) — наши пытаются починить сами, когда нужно привлекать спецов…
mithdradates
Очередные прохладные истории про «тупых пиндосов» и русскую «смекалочку»?
vanyas
Конечно инженер ДЦ может понятия не иметь про структуру сети и т.д. Его работа делать руками то, что просят. В дц может быть куча кастомеров со своей архитектурой и т.д.
CherryPah
Ну как я понимаю по ремарке что CF наказывать инженера не будет — это был их собственный инженер (а не сторонний сотрудник ДЦ). И значит копался он в своей инфраструктуре, а не чужих кастомеров.
Приказы должны выполняться, а не обсуждаться, ясно. Остается непонятным в чем тогда различия квалификации инженера
FAANG в который берут, как известно, только лучших из лучшихCF и мартышки. Насколько надоненавидетьне интересоваться своей работой чтобы не увидеть ничего предрассудительного в выдергивании всех патчей из единственного кросса.DaemonGloom
Это, кстати, вполне нормальная ситуация. Достаточно часто кросс в шкафу с активным оборудованием даёт соединения именно для этого шкафа. Соответственно, если весь шкаф убирают — все соединения будут отключены. И это было бы странно ожидать, что там окажутся ещё и транзитные внешние соединения без маркировок.
В такой ситуации должен быть, скорее, отдельный набор шкафов только с пассивкой. И вот к нему уже надо ходить аккуратно.
Но, в любом случае, маркировка должна быть, особенно для глобальных соединений.
CherryPah
Ну в общем то так и есть, даже сами шкафы делятся на узкие и глубокие серверные для активного оборудования, и широкие коммутационные — где за счет ширины ставятся
KorDen32
Когда у компании много стоек и много ДЦ, даже если инфраструктура «своя», можно даже быть не первый раз в конкретном ДЦ, но впервые видеть осмысленно конкретную стойку и совершенно не знать что в ней.
А ситуация на практике продемонстрировала (отсутствие) резервирования инфраструктуры конкретного ЦОДа CF.
SakuradaJun
Ростехнадзора на них нет!
Или Роскомнадзора?
tvr
А может это и был засланец оттуда, искал провод по которому телега бегает?
SakuradaJun
Я имел в виду что Ростехнадзор, а возможно и Роскомнадзор тоже, проверяет чтобы были соблюдены СНИПы, ПУЭ, ГОСТы и т.д., в том числе чтобы все кабели были промаркированы.
В этой новости тот самый случай, когда несоблюдение простого элементарного правила привело к аварии.
Ростехнадзора на них нет — потому что Cloudflare не в России, это же очевидно.
RiseOfDeath
Исходя из текста новости к аварии привело не это, а заведемо неверные инструкции (вкупе с безразличием и/или незнанием исполнителя). А вот соблюдение этого правила очень сильно сократило бы срок устранения последствий.
AlexPancho
habr.com/ru/company/ruvds/blog/493852
OleksiyT
Как это не наказывать инженера?
У него же была задача отключить и он прекрасно справился.
Молодец же, как не наказать?
staticmain
Вспоминается история с Баша, про плавающий в ведре роутер как незаменимую точку прохода трафика
C_21
Когда монтажил на местного провайдера произошла похожая ситуация.
Непосредственный начальник дал задание найти на чердаки оптический кабель на 12 жил и обрезать его на двух домах, для последующего демонтажа. После пару часов поиска неподписанного кабеля и получасовой консультации с инженером, я все таки резанул кабель на одном чердаке.
Сказать что упал интернет в одном районе это вообще не чего не сказать. Отвалился весь центр города и пару удаленных районов.
Такого количество мата которое я услышал по телефону, я не слышал даже в фильмах девяностых.
После того как начальник немножко успокоился он дал задание ждать сварщика и сварить оптику обратно.
Но не тут то было. Я ему ответственно заявил — что запаса по кабелю нет и нужно будет делать вставку, мол пусть сварщик две муфты с собой берет и кусок кабеля на 12 жил.
Количество мата в телефоне после моего заявления увеличилось в два раза и меня пообещали распять в конце дня.
По окончанию всех работ и разбора полетов инженер сказал, что вины моей нет, но резать какие либо кабеля запретил и в случае чего отставляет за собой право применить «терморектальный криптоанализатор».
В этой всей истории вывод один — все должно быть задокументировано и подписано, а иначе проблем не избежать.
DarkWolf13
наверняка у каждого есть похожие истории… про не маркированный кабель… и даже есть истории про маркированный неправильно… А так в истории скорее всего ситуация когда сначала соединений немного и маркировка может смотреться даже нелепо, но потом в случае иногда быстрого развития инфраструктуры не обращается внимание на уже существующие соединения и потом повторение ситуации из статьи становиться просто вопросом времени.
Vlad800