На фоне большого числа действительно серьезных новостей, осталось практически без освещения одно примечательное событие, пока продолжающее происходить на Южной Корейщине. На него стоило бы обратить внимание многим, ибо пример показательный, и шансы его повторить у нас - весьма велики.
Касается сие событие структуры под названием Kakao Corp. Для несведущих – это такой южнокорейский Яндекс. Тоже «полный фарш» в области высокотехнологичных услуг: и мессенджер, и банк, и платежная система, и служба такси, и игровая платформа, и т.д. И всё это – на первых позициях среди пользователей той самой Южной Кореи.
И, поскольку, позиции – первые, то основатель сей шарашки (некто Ким Бом Су) заслуженно возглавляет список 50 самых богатых людей Кореи. Ну, то есть – не хухры-мухры какое-то это самое КАКАО, а что ни на есть – серьезнейшая контора. В южнокорейском смысле.
К событию
Началось оно в прошедшую субботу, 15 октября, в 15.30 по местному времени в здании, находящемся в Pangyo Techno Valley в городе под названием Pangyo где-то в Южной Корее. Что это за долина – в целом не важно. А вот здание – оно замечательное. Ибо оно является (или уже являлось?) частью построенного компаниями IBM и SK Group центра обработки данных, общей площадью 66 900 кв.м. Ну, то есть – точно не мало.
Так вот, в субботу в здании случился пожар. Охвативший своим влиянием ни много, ни мало – а порядка 32 тысяч (ТЫСЯЧ, КАРЛ!!) серверов.
Пожар тушили более 8 часов. В течение которых сервисы, имеющие в названии слово КАКАО, а также многие не имеющие такой части названия, но тоже связанные с этой компанией, тупо не работали. Платежи, связь, такси… Ничего. Точнее – банк работал. Одному господу известно, по каким причинам его хостят в другом ЦОДе (имени LG), и как так случилось, что он – сам по себе.
Как говорят, всеобщность краха сервисов обеспечило приложение KakaoTalk – их местный мессенджер, которым активно используется от 43 до 47 миллионов из 51-миллионного населения страны. Если убрать младенцев и прочих недееспособных – то имеем практически полный охват страны. Для большинства других услуг Kakao требуется идентификатор KakaoTalk ID в качестве входа в систему. Соответственно, не работает Talk – не работают и остальные.
Восстановить большинство сервисов смогли лишь к 17 октября, и то – не в полном объеме по многим сервисам.
Также пожар (точнее – связанные с ним отключения энергии и нарушения в работе ЦОД) повлияли на второго крупного арендатора – компанию NAVER. Про нее шума поменьше, хотя она по выручке и покрупнее будет, чем КАКАО. Видать, там не столь критично всё обвалилось.
Первичная политическая оценка
Поскольку сия восточная страна славна своими традициями поиска и преследования подозреваемых до тех пор, пока не упрячет их в каталажку (история всех президентов Южной Кореи – тому наинагляднейший пример), грамотные виновные стремятся не затягивать процедуру. Ибо, как говорил один наш известный киногерой: «раньше сядешь – раньше выйдешь». В общем, один из двух генеральных директоров КАКАО (ДВУХ ГЕНЕРАЛЬНЫХ ДИРЕКТОРОВ!!! ???) признал свою вину и подал в отставку. Оставив второго генерального директора в гордом одиночестве разгребать результаты.
Но правительству этого показалось мало. И они решили инициировать антимонопольное расследование: дескать уж не является ли на самом деле КАКАО монополистом? Ну, то есть информации о стопроцентном охвате всего населения сервисами КАКАО – им для понимания не достаточно. Они хотят проверить. Ну-ну…
Сами по себе позиции президента и отдельных правительственных чинуш настолько примечательны, что необходимо привести их для ознакомления.
В заявлении президента Юн Сук Ёля в воскресенье говорится: «Я чувствую большую ответственность за неудобства и ущерб, с которыми сталкиваются люди». Он приказал министру науки и информационных технологий взять на себя управление кризисом в связи с крахом Какао при содействии других государственных ведомств.
«Нам нужно не только выяснить точную причину, а также ущерб, но нам нужно придумать систему, которая справится с такой ситуацией, а также принять превентивные меры», — сказал Юн, сообщает одна из газет.
Министр науки и ИКТ Ли Чон Хо посетил место происшествия и сказал: «Правительство серьезно относится к ситуации, поскольку отключение вызвало обеспокоенность по поводу возможности паралича нашего общества и экономики».
В другом заявлении он сказал: «Как ответственный министр (ИКТ) я выражаю искренние сожаления по поводу больших неудобств, причиненных людям из-за этого пожара. Правительство очень серьезно относится к перебоям в обслуживании и рассмотрит системные меры поддержки в в случае таких сбоев службы».
Две основные политические партии Южной Кореи, правящая Партия народной власти (ПНП) и основная оппозиционная Демократическая партия Кореи (ДПК), совместно призвали к встрече с лидерами трех компаний, председателем SK Group Чей Тэ-Воном, основателем Kakao Кимом Бом-Су и основатель Naver Ли Хэ-Джин. Помимо основателей, были вызваны три генеральных директора Пак Сон-ха из SK, Хон Ын-Тэк из Kakaoa и Чхве Су-Ён из Naver.
Как сообщает The Korea Times, лидеры обеих партий назвали Какао «халатностью» и пригрозили принять законы, регулирующие деятельность Какао
Ну, то есть до них всех наконец то дошло, что игра в мессенджеры и удобные ИТ-приблуды может привести к существенному воздействию и даже – к краху ВСЕЙ ЭКОНОМИКИ.
Технические причины
В этой части цирк только начинается. Ибо в качестве причины возгорания пока обозначают – тадам! – использование литий-ионных аккумуляторов. А цирк – потому как сии аккумуляторы произвела та самая компания SK, которой и принадлежит ЦОД. Точнее – некоторая ее дочерняя структура, но это в целом – и не важно.
Так вот, корейские компетентные структуры решили активно погрузиться в тематику батарей, и делятся откровениями с общественностью. Откуда и нам стало известно, что, оказывается, литий-ионные батареи подвержены возгоранию, вызванному « тепловым разгоном », и такие возгорания могут иметь серьезные последствия, поэтому литий-ионные батареи обычно оснащены системами управления батареями (BMS) для контроля температуры и производительности и предупреждения о любых неизбежных последствиях.
Местная пресса уже успела заявить, что соответствующая BMS подавала предупреждение о пожаре за два часа до того, как вспыхнул настоящий пожар, и рабочий дважды осмотрел место. Само собой, SK Group опровергла претензии и опубликовала копию фактических графиков мощности и напряжения из BMS, которые показывают нормальную работу.
«График, показывающий состояние предположительно загоревшейся литий-ионной батареи, оставался стабильным до момента аварии в 15:19. BMS отправляет предупреждения только в случае существенных колебаний графика. Поэтому наш работник, не посещал здание для проверки объекта», — говорится в опубликованном пресс-релизе SK Group.
К слову, в предыдущем крупном пожаре в ЦОДе (пожар в 2021 года, уничтоживший весь дата-центр OVHcloud SBG2 в Страсбурге) неофициальной причиной тоже называют возгорание литий-ионных аккумуляторов (хотя OVHcloud до сих пор это и не хочет озвучить).
Организационные причины
Несколько источников раскритиковали подготовку Kakao к аварийному восстановлению: «Если бы Kakao защитила свои данные с помощью горячего сайта или резервного сайта, перебои в обслуживании были бы быстро устранены», — сказал местный ИТ-эксперт, которого цитирует The Korea Times . За последние несколько лет у KakaoTalk было несколько сбоев.
Чиновники Kakao заявили, что пытались осуществить восстановление данных, но не смогли завершить его, потому что не ожидали, что власти примут меры предосторожности и отключат электричество в горящем здании.
«Мы начали процесс репликации данных после пожара, но нам помешало неожиданное отключение питания», — сказал представитель Kakao, сообщает The Korea Times. «Все наши данные реплицируются, но это занимает много времени, потому что у нас так много данных».
Вице-президент Kakao Ян Хён-Сео признал, что компания не была готова, согласно Korea JoongAng Daily : «Мы не были достаточно готовы к сбою всей серверной системы из-за пожара. Есть некоторая сложность, так как впервые в истории ИТ было отключено 32 000 серверов, — сказал он после посещения сайта. — Переброска трафика на дополнительные серверы занимает много времени».
В субботнем заявлении совместных генеральных директоров Kakao Намкуна Вона и Хон Ын-Тэка обещаны быстрые действия и заявлено, что у компании действительно есть система резервного копирования на случай чрезвычайных ситуаций, а данные разделены между центрами обработки данных в компании.
В воскресенье в пресс-релизе Kakao было объявлено о создании «комитета экстренного реагирования» во главе с Хон Ын Тхэком, главой общественного центра Kakao. Он будет состоять из трех подгрупп, занимающихся расследованием причин, мерами противодействия стихийным бедствиям и (вероятно спорный вопрос) компенсацией. Комитет будет консультироваться с внешними экспертами.
Ну, то есть – если уж совсем кратко – а они вообще и не думали, что будет пожар. Ибо «начали процесс репликации данных после пожара». ПОСЛЕ ПОЖАРА, КАРЛ!
А мы то тут причем?
Уж не знаю, кого стоит благодарить, но пока про русский след никто ничего не говорит. Так что вроде бы – и не при чем. Но это лишь в части причин события.
А вот что качается последствий – тут, на мой взгляд, нам всем (и нашему правительству – в частности) стоит глубоко задуматься. И обозначить несколько важных вопросов, например:
1. Насколько разумно строить единую и при этом, - единственную для большого числа сервисов, точку авторизации?
2. Каким образом должны быть построены системы для исключения критичного влияния отдельного события (пожара, наводнения, теракта) на работоспособность многих критичных сервисов?
3. Следует ли применять в критичных инфраструктурах потенциально опасные технологии (например, литий-ионные батареи)?
4. Каким образом следует формировать и отрабатывать планы восстановления после аварий?
5. Какую меру ответственности следует предусмотреть в отношении лиц, ответственных за организацию работоспособности значимых сервисов в случае нарушений?
Для специалистов – ответы очевидны.
Но, к сожалению, большинство власть предержащих, специалистами как раз и не являются. И их внимание к проблемам следует постоянно и настойчиво привлекать, ибо в противном случае – будет у нас иметь место аналогичное южнокорейское КАКАО с аналогичными (или - худшими) последствиями. А не хотелось бы…
Демократия - зло.
Коммент дня от Key Z:
Звучит странно. Вот рядом живой пример: 3 географически разделённые стойки, в каждой по 8 железок, в каждой железке 4 процессора, в каждом процессоре 32 физ. ядра. Итого 3072 проца. Всё это - вмварьный фэйловер кластер, соединенный локально файберченел, глобально езернетом 40G. На этом работает около 150 виртуальных серверов. Чтобы потерять функционал этой конструкции надо сжечь все 3 локации. Чтобы потерять данные, которые резервированы локально и синхронизируются по 40Г в 4ю локацию надо сжечь и её. Причем если раньше такая конструкция стоила как космический корабль, сейчас можно собрать лямов за 8 зеленых.
Корейцы полные сынки папаши Мюллера в общем. Кстати где он?
Комментарии
Не поняла, у этих деятелей не было резервного отдельного ЦОДа в другом здании? Молодцы корейцы, экономные ребята.
В материалах информации нет.
Судя по идиотским ответам - что-то там было, но данные надо было актуализировать и/или перекачать в другой ЦОД.
судя по статейке на хабре, в которой какой-то стартапер хвалится как "быстро" они с нуля восстановили порушенное уходом OVH "в облака",
РК у них был в том же ЦОДе. а в данном случае тоже проглядывает такое же головотяпство. ибо сливать данные в другое физически местоположение надо если не постоянно и синхронно (это очень дорого, сложно и грузит сеть), то хотя бы периодически и раз в сутки, минимум.
Насчёт "очень дорого и сложно" чушхня. Решения есть и давно известны. Дорого, да, но не дороже денег. Оптоволокно ваще стоит недорого.
В некоей известной мне конторе цоды разнесены на тысячи км, а почти все сервера в виртуалках и могут выполняться на любых реальных серверах. И ничто, не разорились пока от расходов таких.
> Насчёт "очень дорого и сложно" чушхня
Речь шла про "синхрон". И не уровня DRBD.
Я как бы в курсе сколько стоит синхронная репликация и разницы по стоимости с обычной асинхронной. В т.ч. из-за сильно повышенных требований и к конечной аппаратуре и к ширине и качеству канал. К тому же синхронную вы на другом конце земного шара да даже из Мск в Спб не сделаете. В силу физических ограничений, скорость света конечна, например.
Поэтому за тысячи км вы могли видеть только асинхронную репликацию. Что есть несколько другое пальто.
Что-то мне подсказывает, что в конкретной ситуации из материала - достаточно было обеспечить синхронизацию базенки порядка 100 Гбайт. К тому же - не очень часто меняемой. (50 млн записей по 2 кб на одну). Этого бы для поддержки ID должно было бы хватить. А на таких объемах, к тому же - с некритичным временем отклика - оно должно стоить ну не очень много.
Это если к архитектуре семейства сервисов и поддерживающей инфраструктуры подходит по уму.
это же модная фича управления крупными и сложными проектами.
"Главное запустить прототип как можно раньше по срокам, остальное доделать потом"
Проистекает это из общего падения уровня образования, на которое наложилось кратное усложнение информационных систем. Так как надо бюджеты пилить, капусту рвать, то на знамени крупными буквами выведено:
.уйли думать, трясти надо !!!
То есть все было запланировано в бюджет, потом из бюджета вышли - нет ничего более постоянного, чем временные схемы.
При Сталине РП - под расстрел, прочее начальство на лесоповал, исполнителей в шарагу - исправлять содеянное.
Вот СССР и рванул в космос.
резервный ЦОД уровня TIER III должен быть не просто в другом здании а на расстоянии десятков километров. Есть даже специальный термин Катастрофоустойчивость (Disaster Recovery). Сложно поверить что у крупнейшей корейской ИТ компании это не было реализовано.
Что-то мне кажется у вас в тексте понамешано много чего. В виде каши.
ТИР - он не про много ЦОДов, а про один конкретный. Так что ни о каких десятках километров и ни о каких резервных там вообще речи нет.
Disaster Recovery - это не про катастрофоустойчивость, а про порядок восстановления сервисов после тех или иных катаклизмов. Примитивный вариант такого плана может звучать так: "если копьютеры не работают - считаем на счетах по вот такому алгоритму".
Касательно было или не было реализовано - сам факт многодневного отключения говорит за себя: то что было - не сработало. Значит если и было - то было фигнёй, не соответствующей реальным рискам.
Грамотный комментарий.
А местным "я все на расте за неделю перепишу печатая китайскими палочками с завязанными глазами": такие ситуации совершенно стандартны по своему типу, но не по размаху. Зная от коллег культуру разработки в самсунге, я не удивлюсь, если начальство через одного синекуры. Отвечать, конечно, должен один из C*O, потому как такие темы для обычных инженеров и начальников отделов неподъемны.
+100500 лошары
В реальном мире никто не использует один ключ для почтового ящика, для входа в квартиру, для автомобиля, для прохода на рабочее место, для сейфа на работе и так далее.
Все мы понимаем, что утрата единого ключа - это потеря всего, что есть.
Но в компьютерном мире - иные взгляды.
ключевое слово "точка", один замок. один ключ - не проблема, использовалось ещё до ИТ.
Каждое приложение проверяет права доступа. Если некто получил доступ к какому-то некритичному приложению, он получил доступ ко всему.
это совсем не так, даже не близко. пойми разницу между авторизацией и аутентификацией.
Вы согласны, что в каждом приложении должен быть механизм проверки доступа? И да, я знаком с X.800
так он и есть. ты аутентифицируешься и потом со своим "токеном" ходишь по сервисам. где разрешено - тебя пускают, где нет - там не пускают. так-то схема простая, со времён NIS+ & Kerberos4.
И если такой механизм проверки есть в каждом приложении, то вполне возможно найти некритичное приложение, за которым нет контроля, и вскрыть этот механизм (аналог - подбор ключа к почтовому ящику в подъезде, где нет ни консьержки, ни камер)
не надо креатива, всё уже сделано, давно. приложение ничего не видит, кроме токена, а там нет критичной инфы. в 21 веке вообще zero trust рекомендуют.
"Все изобретено, ничего не работает"
Во-во, умные дядьки все уже давно проработали но продуманные коммерсы всё обгадили через оптимизацию расходов, а манагеры чтоб удовлетворить хотелкам кухарок всё потом ещё и упростили, пример:
Чтоб деньги не смог стырить какой-то мудень подглядевший через программного жучка пароль от банка, банк дополнительно запрашивает код, который каждый раз новый и высылается смс-кой, всё было замечательно пока на сайт банка заходили через комп а пароль приходил на телефон, двойная верификация через разные устройства обламывала всяких жучков на компе, всё накрылось когда банки стали выпускать приложения для смарта, в результате пароль вводится на том же устройстве где и приходит смс-ка, получил кулхацкер доступ к смарту с помощью жучка и всё, двойная верификация превратилась в тыкву, зато удобно чё.
Так и есть. Банки оценивают СВОИ риски и, если стоимость внедрения дополнительной защиты выше оценки потерь банка, то ничего делать не надо.
Как банки оценивают свои риски? Например, так - пусть за все отвечает клиент. Увели деньги с карты? Сам виноват. Транзакция через Занзибар? Докажи, что не был там. Не был? Докажи, что не отдал карту другу из Занзибара.
Меня напрягает попытка воткнуть это в ВК.
Госуслуги - еще куда не шло. Там пусть топорно, но более ответственно.
Есть очень простая оценка рисков.
Например, для нефтяной компании разлив ведра бензина на заправке имеет очень высокую вероятность, но очень низкую стоимость (штраф, стоимость бензина). Несвоевременное предоставление отчётной документации - крайне редкое событие, но весьма дорогостоящее.
Сравните цену инфы на ВК и на ГосУслугах.
Изначально неверная аналогия. Ключ от квартиры у вас один. А в квартире у вас все "услуги" - и ванная с туалетом, и дуроскоп, и едальня и прочее. Под одним ключом...
Это - концепция надстроенной безопасности.
Но сейф в квартире имеет свой ключ. - Это - встроенная безопасность.
Так себе аналогия. Ибо паспорт у вас по прежнему один.
Паспорт может быть старым и новым, внутренним и заграничным, или даже паспортом моряка. Или военный билет. Или водительские права.
Может. Но попробуйте какое-нибудь действие, где требуется паспорт (операция купли-продажи например) выполнить с предъявлением водительских прав
Вы забавно строите фразу: "Там где требуется паспорт - без паспорта".
Для начала - не у всех граждан РФ есть паспорт - по закону.
Если только ключ - не вы сами.
Это я про биометрию.
Биометрия закономерно переводит угрозы в иную плоскость.
Если говорить о репликации биометрии, то, например, силиконовые отпечатки пальцев временно отсутствующего товарища, в РФ, уже года 3 как, массово успешно используют простые конечные пользователи....
Да, это так. Но я имел ввиду угрозы против личности.
Это не в компьтерном мире, а мире гражданского интернета.
Когда вояки амеровские стали создавать интернет, то там было множественное резервирование и центры обработки были разнесены на сотни/тысяци км. Доходило до того, что о повреждении какого ьибо канала передачи данных узнавали об этом случайно, потому-что система могла использовать и другие каналы.
Пришли в эту сферу гражданские и все похерили.
Проблемы безопасности распределённых систем заключаются в распределеннной безопасности
только сегодня про это говорил. ответ миньджерофф (СЕО/СТО) - у нас нет денег на ваши хотелки, стратегия - экономить.
Дайте почитать первоисточник. Пусть думают.
В Корее - наверняка кого-нибудь закроют по итогам.
про OVH пояснил. не зашло. другие цели у бродяг, 3 года, бонус, новая должность. главное 3 года на "хорошем счету" и парашют из денежег.
Ну тогда стоит сильно не возражать на закупку стоечных ИБП на базе лития :-)
стандартное проведение в такой ситуации - регистрируешь риск и вешаешь его на босса, который, например, за кибербезопасность отвечает (как вариант - за ИТ инфраструктуру). А его уже потом будут сношать люди, ответственные за контроль и устранение рисков. Если такой системы в вашей компании нет, то у меня для вас плохая новость...
Лошары, чо.
Ну как бы резервный ЦОД на 32000 серверов - это еще одна чашка такого же КАКАО. Еще одна небольшая электростанция.
не всё надо резервировать, только ключевые компоненты.
На самом деле - в примере плохо всё.
- мутные аккумуляторы в ЦОДе ("возгорание литий-иона")
- нет нормального резервирования систем ("начали копировать после пожара")
- нет резервного питания объекта ("власти отключили питание")
- нет нормального плана действий
- поганая архитектура ("все системы зависят от одной, которая имеет единую точку отказа")
... можно продолжать.
Если загорелиь аккумуляторы, то понятно, куда именно делось резевное питание. Хотя, конечно, дизель-генератор должен быть.
аргоновое заполнение какбэ, для ДЦ. и резервное питание, да.
Любишь кататься, люби и саночки возить
Как я понял эти аккумуляторы в виде ибп и буфера работали. Но почему они были в одном здании с серверами? Даже если здание одно, то для выделяется особое помещение с особыми условиями пожарной безопасности. Но судя по количеству серверов, там вообще должно быть отдельное здание для э.снабжения.
В общем, полный бардак уже на стадии проектирования. Либо ещё веселее, земля дорогая, сэкономили. Всё в одном.
IBM + SK не могут делать неправильно!
Или уже могут? :-)
Страницы