Адрес для входа в РФ: exler.wiki
Показательная история с крупнейшим провайдером
29.03.2023 13:00
12710
Комментарии (123)
Я читал про историю с крупнейшим европейским хостинг-провайдером OVHcloud, чей дата-центр SBG2 загорелся в ночь на 10 марта 2021 года, сгорел почти полностью, при этом также сильно пострадал соседний дата-центр SBG1.
В OVHcloud говорили, что пострадало где-то 15 тысяч клиентов, однако компания Data Centre Dynamic утверждала, что пострадало около 65 тысяч клиентов, многие из которых потеряли все свои данные и, соответственно, бизнес.
При этом там сразу начались серьезные скандалы, потому что OVHcloud в качестве компенсаций потерь предлагала только ваучеры на получение их провайдерских услуг на сумму в 900 евро.
А доклад местной пожарной службы, опубликованный через год после происшествия, просто шокировал: в дата-центре были деревянные перекрытия, отсутствовала автоматическая система пожаротушения, отсутствовала возможность централизованного отключения питания, система вентиляции способствовала распространения огня - в общем, сплошная жесть.
Против OVHcloud были поданы коллективные и индивидуальные иски, и вот некоторые результаты. При этом выяснились совершенно удивительные вещи:
Так, компания Bati Courtage, занимающаяся коммерческой недвижимостью, использовала VPS и в результате пожара потеряла веб-сайт, а также данные клиентов, информацию о франшизах и сведения подрядчиках. Всё это было потеряно потому, что оплаченные резервные копии хранились в том же сгоревшем ЦОД. Компания потребовала €6,5 млн, но суд обязал выплатить €100 тыс., поскольку договором предусматривалось, что копии просто будут храниться в помещении, «физически изолированном» от VPS, а не в каком-то другом ЦОД.
В случае с Bluepad, предоставлявшей SaaS-услуги, компания платила за рабочий сервер в SBG1 и резервный в SBG2, но оказалось, что оба на деле находились в SBG2. Более того, OVHcloud буквально уничтожила данные Bluepad трагикомическим образом. Информация сохранилась после пожара, но инженеры OVHcloud включили сервер до его возвращения владельцам и автоматический скрипт, признав данные «устаревшими», удалил их, оставив Bluepad ни с чем. Bluepad потребовала компенсацию в размере €330 тыс.
Гениально, да? Люди платили большие деньги за хранение резервных копий в другом дата-центре - их хранили в одном. И даже когда хранили в другом, тот находился по соседству с первым и пострадал вместе с ним. А уж уничтожение чудом сохранившихся данных скриптом - это совершенно гениально!
Какой вывод? Не храните, граждане, все яйца у одного провайдера! Делайте бэкапы в другие места - так намного надежнее! Даже у самого крупного провайдера могут погореть ваши данные, причем, как показала практика, даже в том случае, если вы специально оплачиваете резервное хранение.
Войдите, чтобы оставить комментарий.
В давние, еще дооблачные времена, у меня в презентациях "самой лучшей в мире СУБД" всегда был слайд о пользе и важности резервных копий (опции тоже надо продавать) с весьма мотивирующим фактом:
"97% компаний, полностью потерявших свою рабочую базу данных, теряют клиентов и разоряются в течении года."
"97% компаний, полностью потерявших свою рабочую базу данных, теряют клиентов и разоряются в течении года."
Используя облака, ты доверяешь свои данные дяде под честное слово. Даже если в договоре прописано всё, включая ядерную войну. Обязательно найдётся умник, который бекапы будет хранить на том же СХД, где и основные данные. А с него какой спрос?
"- Вы уронили бомбардировщик стоимостью 2 миллиарда долларов!
- Да. И я выплачиваю за это по десятке с каждой зарплаты." (с) Hot Shots
"- Вы уронили бомбардировщик стоимостью 2 миллиарда долларов!
- Да. И я выплачиваю за это по десятке с каждой зарплаты." (с) Hot Shots
Облака, белогривые лошадки!
Облака, что вы мчитесь без оглядки?
Не смотрите вы, пожалуйста, свысока,
А по небу прокатите нас, облака!
Облака, что вы мчитесь без оглядки?
Не смотрите вы, пожалуйста, свысока,
А по небу прокатите нас, облака!
Насчет деревянных перекрытий как-то очень сомнительно. ИМХО такие перекрытия могут быть только в очень старых домах или в современных дачах/коттеджах. В зданиях как на фото обычно монолитные железобетонные перекрытия.
может, перегородки имелись в виду?
может, перегородки имелись в виду?
Переоблицованая старая фабрика?
У них в этом датацентре сервера стоят в морских контейнерах с кондиционерами.
Ну, вообще-то, у бизнеса мог бы быть disaster response plan, и не только в отношении своих заводов и пароходов, но и для внешних дата-центров.
A less extreme option: have another coffee.
Бакап Шрёдингера: ты не знаешь, жив он или нет пока не нужно восстановить.
Работал у нас одни админ, которых хранил бэкапы на одном диске с базой.
Свежачок. Пользуемся услугами одной известной компании по сбору логов и предоставлению услуг мониторинга. Произошло некое событие, все правила были определены верно и выполнились - а нотификация пришла только через полтора часа. Ответ саппорта "к сожалению, мы не ведем логов нотификаций и не можем установить причину задержки".
А SLA что говорит?
Суть не в SLA - хотя он явно не "90 минут". Суть в том, что компания по обработке логов и метрик - не пишет (или не хранит) логи своих собственных сервисов.
Как это не в SLA? Суть именно в нём.
Хранят ли они что-то и как – это их внутреннее дело, оно вообще никого не касается, если не оговорено иного (например, впн обещает не хранить логи, а хранит). Всё, что они должны, это обеспечивать выполнение контракта. Ответ саппорта вообще может быть враньём по сотне причин, от не владения вопросом до нежелания выносить неприглядные детали на публику.
Только SLA.
Хранят ли они что-то и как – это их внутреннее дело, оно вообще никого не касается, если не оговорено иного (например, впн обещает не хранить логи, а хранит). Всё, что они должны, это обеспечивать выполнение контракта. Ответ саппорта вообще может быть враньём по сотне причин, от не владения вопросом до нежелания выносить неприглядные детали на публику.
Только SLA.
И как это все реализовать? Шифрование, еще и хранение на двух серваках и кто их знает, купишь облачный хостинг в разных местах, а окажется что они в одном..
Хард драйвы очень дешёвые. Можно локально бэкапить. Сто терабайт будет стоить всего около $1000.
И как это все реализовать? Шифрование, еще и хранение на двух серваках и кто их знает, купишь облачный хостинг в разных местах, а окажется что они в одном..
Хард драйвы очень дешёвые. Можно локально бэкапить. Сто терабайт будет стоить всего около $1000.
А канал для этой всей радости? Ну то есть сам подход верный, но подводные грабли там тоже есть.
Ну, Амазоновский ледник можно использовать -- медленно, зато дёшево и подойдёт для восстановления в таких крайних случаях.
Импорто мать его замещение....
Правда на РБК говорится о 2-х миллиардах прибыли в 2021 году - но всё-таки о прибыли.
РБК
Ну всё же дали в руки! Практически все продукты в Маке давно российские за малым исключением.
Ну как так-то????
Правда на РБК говорится о 2-х миллиардах прибыли в 2021 году - но всё-таки о прибыли.
РБК
Ну всё же дали в руки! Практически все продукты в Маке давно российские за малым исключением.
Ну как так-то????
Фи такими меркантильными категориями мыслить. Главное что показали что могут и без проклятых американцев. А деньги... Ну что им бюджет не компенсирует?
Импорто мать его замещение....Правда на РБК говорится о 2-х миллиардах прибыли в 2021 году - но всё-таки о прибыли.РБКНу всё же дали в руки! Практически все продукты в Маке давно российские за малым исключением.Ну как так-то????
Просто российское пальмовое масло очень дорогое
В Якутии и Архангельске пальмы видать урожай маленький дают
Ожидаемый результат. Сейчас, как это водится в отечественных реалиях, начнут экономить на продуктах, персонале и оборудовании... Убыток будет не 11, а 20. А потом все это тихо сдохнет.
начнут экономить на продуктах, персонале и оборудовании
«Допиздержки» — это название рубрики, видимо? «Р» тогда надо убрать
Ну как так-то????
о масштабах воровства.
А по-моему врожденная криворукость.
Воровство и "да норм все будет, не ссы" рождают вот такие убытки.
Пригожин там свои точки откроет, опыт кейтеринга за плечами.
"да норм все будет, не ссы"
выводят деньги и рисуют убытки
еще со времен юкоса все поняли что управлять нужно долгами
еще со времен юкоса все поняли что управлять нужно долгами
А не надо думать, избыточно это = "15 тысяч клиентов" не могли ошибаться. Просто часть руководства во многих компаниях до сих пор думает о данных по-старинке, дайте нам бэкап на сдачу от доски для конференций.
ХЗ какие у них изначальные расходы были при передаче.
Дали-то в руки тем, кто управлял некоторыми маками. Т.е. надо смотреть на 23-й год.
Дали-то в руки тем, кто управлял некоторыми маками. Т.е. надо смотреть на 23-й год.
А по-моему врожденная криворукость
У воровства таких лимитов нет.
Чет сомневаюсь, есть менее сложные методы, чем поджечь дата-центр с перекрытиями из дерева и без системы пожаротушения, и с вентиляцией разгоняющей огонь по зданию.
Не боишься, что забанят?
Не боишься, что забанят?
В данном случае это пример такого же вопиющего непрофессионализма - как и описанные ситуации с бэкапами.
Как в анекдоте - "Музыка навеяла"
С прибыли ж надо налоги платить, чего они дураки? Чай не глупые пиндосы. Соображают.
Якобы в 2000х все казино в Москве были убыточны.
Якобы в 2000х все казино в Москве были убыточны.
А вы новость-то саму в РБК прочитали? Или чукча он того?
"«Сравнение показателей 2022 года с 2021 годом некорректно, так как предприятия сети не работали с середины марта до июня и постепенно переоткрывались вплоть до конца сентября. Компания много инвестировала в переоткрытие предприятий, кроме того, не сразу были перезапущены все позиции меню и сервисы — к примеру, доставка»
Ну и как бы за проданный бизнес ещё следовало заплатить, хоть и дисконтом.
"Говор рассказал, что корпорация McDonald's платила только зарплату сотрудникам.
«Арендная плата, расплата с поставщиками - это ничего не было уплачено. Я вас уверяю, это огромная сумма, которую я должен ещё внести, это у нас в договоре имеется», - сказал он.
В этом году бизнесмен оценил предстоящие затраты на сеть в 6,5-7 миллиардов рублей. Об этом сообщает "Рамблер". Далее: finance.rambler.ru
"«Сравнение показателей 2022 года с 2021 годом некорректно, так как предприятия сети не работали с середины марта до июня и постепенно переоткрывались вплоть до конца сентября. Компания много инвестировала в переоткрытие предприятий, кроме того, не сразу были перезапущены все позиции меню и сервисы — к примеру, доставка»
Ну и как бы за проданный бизнес ещё следовало заплатить, хоть и дисконтом.
"Говор рассказал, что корпорация McDonald's платила только зарплату сотрудникам.
«Арендная плата, расплата с поставщиками - это ничего не было уплачено. Я вас уверяю, это огромная сумма, которую я должен ещё внести, это у нас в договоре имеется», - сказал он.
В этом году бизнесмен оценил предстоящие затраты на сеть в 6,5-7 миллиардов рублей. Об этом сообщает "Рамблер". Далее: finance.rambler.ru
Казино все были подментованы, как и игровые автоматы ранее. А потом оказалось, что дербанить бюджеты выгодее, чем дербанить клиентов казино.
Просто российское пальмовое масло очень дорогое
Думаешь - украли? А по-моему врожденная криворукость.
А вы новость-то саму в РБК прочитали? Или чукча он того?
Сравнение показателей 2022 года с 2021 годом некорректно
допиздёржки - это не фотошоп?
Потому что в 21 был Макдональдс и пандемия с карантинами
а в 22-м была "... точка" и отсутствие запретов.
Особенно в России, ага-ага. Прям по домам сидели как зайки.
Особенно в России, ага-ага. Прям по домам сидели как зайки.
Гуглить что? Как я жил в РФ в 2021 году)? Меня вроде память пока не настолько подводит. Никто никуда не закрывался в 2021. Даже типа обязательный куар-код от вакцины или 6 месяцев от болезни, спрашивали в 2 из 10 заведений.
Это реклама послезавтрашнего праздника? )
Всемирный день бэкапа
Всемирный день бэкапа
Всемирный день бэкапа
Какой-какой там Tier был, говорите?
А доклад местной пожарной службы, опубликованный через год после происшествия, просто шокировал:
Другие - которые разбирая головешки, обнаруживают, что пожарной безопасности там не было.
Или это одни и те же, просто они играют за две стороны?
Наверное, есть два вида Пожарников.
...Или это одни и те же?
В отечественном пожнадзоре разные. Отдельно инспекторы надзора, отдельно пожарные, которые именно тушат, отдельно дознаватели.
Лапки мохнут, ессно, в основном, у первых. Факапы со Сбером во Владике, Лошадью в Перми, Вишней в Кемерово и их последствия немного ситуацию исправляют (при этом, правда, ещё и с приговорами по душу вторых), но не полностью.
Лапки мохнут, ессно, в основном, у первых. Факапы со Сбером во Владике, Лошадью в Перми, Вишней в Кемерово и их последствия немного ситуацию исправляют (при этом, правда, ещё и с приговорами по душу вторых), но не полностью.
К слову OVH был ультра-дешевым хостингом, меня до этого случая просто удивляли их цены, настолько они были низкие. Но теперь всё ясно стало
Странно, что самые низкие цены по рынку не смутили клиентов. Хотя, - а бэкапы? - вот тебе пяток на водку и пошел отсюда вон, время делать бабки!))
Ну вот нас не смутили. Но у нас и сервера были географически распределены по разным датацентрам, и пожар нас задел, но не напряг - развернули новые машины в других ДЦ, накатили бэкапы, и все нормально. А вот те, кто все еще не делают бэкапы - ССЗБ.
Ой, этот персонаж по-прежнему теме же занимается? Я ж его еще 30 лет назад помню.
Нужен датацентр для бекапов, на Марсе.
И второй, на Венере.
Луну не предлагать.
И второй, на Венере.
Луну не предлагать.
Если завтра взорвется Солнце, то до орбиты Нептуна будет все уничтожено. Так что Марс - ненадежно, тем более - Венера.
Лучше хранить бэкапы не в нашей галактике. А то мало ли что тут случится...
Лучше хранить бэкапы не в нашей галактике. А то мало ли что тут случится...
У меня есть офигенная идея. Надо просто поставить мощный лазер и через него излучать бэкапы в небо, например, на альфу кентавра. Дальше, смотрите: изобретаем варп-двигатель, прыгаем в нужную точку пространства и принимаем нужный пакет. Автоматически - за любую дату, потому что скорость света конечна, просто нужно подобрать правильную остановку. Неба дофига, хватит всем, ну кроме тик-тока, конечно.
Надо просто поставить мощный лазер и через него излучать бэкапы в небо, например, на альфу кентавра.
Ну почему сразу набьют-то )) Может спасибо скажут ))) А может воплощать в жизнь прилетят )))
А лет через несколько прилетят инопланетяне и набьют всему человечеству лицо за бэкапы порнхаба.
А лет через несколько прилетят инопланетяне и набьют всему человечеству лицо за бэкапы порнхаба.
У меня есть офигенная идея. Надо просто поставить мощный лазер и через него излучать бэкапы в небо, например, на альфу кентавра.
К каждому поезду на Транссибе цепляем вагон с хардами и катаем по кругу по маршруту Москва - Владивосток. В Москве заливаем свежие бэкапы...
Можно еще на свою фирму завести уголовное дело, и в рамках этого дела потребовать весь трафик за последнее время, записанный СОРМом
бэкапы порнхаба.
Есть идея проще и реализуема вотпрямщас.
К каждому поезду на Транссибе цепляем вагон с хардами и катаем по кругу по маршруту Москва - Владивосток. В Москве заливаем свежие бэкапы...
К каждому поезду на Транссибе цепляем вагон с хардами и катаем по кругу по маршруту Москва - Владивосток. В Москве заливаем свежие бэкапы...
Уже было - классическая FIDOшная "задачка" про камаз с ЦД болванками
У амазона есть такая фигня, Snow Family, и конкретно вот это - Snow Mobile ((aws.amazon.com так что это даже и не шутка никакая. И в экзаменах на тему "выбрать самое эффективное для трансфера" хватает вопросов.
Ну AWS и Azure предлагают варианты репликации данных в другой географический регион, гугл в меньшей степени, но тоже есть. Надеюсь, не врут. Что конкретно обещал этот OVH надо читать.
Так-то, конечно, все думают, что пожары и землетрясения их не касаются.
Так-то, конечно, все думают, что пожары и землетрясения их не касаются.
У AWS есть такой веселый сервис - Kinesis - от которого зависит работоспособность чуть ли не всех остальных. А еще - он используется для актуализации странички статуса, рассылки оповещений и так далее. Если/когда он падает - у вас ничего не работает и вы об этом не знаете.
Локальные копии должны быть. Должна быть хотя бы пара серверов с накопителями и бекапами в офисе. Но айтишники и эффективные менеджеры говорят, что это все вчерашний день. Ну пусть и дальше хранят данные неизвестно где.
Зачем? Гораздо проще арендовать хранилище у другого облачного провайдера и туда слать копии.
Зачем? Гораздо проще арендовать хранилище у другого облачного провайдера и туда слать копии.
эффективные менеджеры
Легко сказать. С микросервисной облачной архитектурой даже собственно бэкап уже становится несмешной сказкой, а уж с облачными объёмами хранения – вообще без вариантов. Если у нас валит, например, петабайт данных в месяц, это ж какой канал нужен и объём дисков?
Другое дело, что проектов с настоящей бигдатой не так, чтоб и много.
Я склонен считать, что имеем случай "кроилово ведёт к попадалову", потому что дизастер-стратегии штука дорогая, иногда очень дорогая, и если клиент экономит на облаке, то и общая архитектура у него по принципу "бог не выдаст".
Другое дело, что проектов с настоящей бигдатой не так, чтоб и много.
Я склонен считать, что имеем случай "кроилово ведёт к попадалову", потому что дизастер-стратегии штука дорогая, иногда очень дорогая, и если клиент экономит на облаке, то и общая архитектура у него по принципу "бог не выдаст".
"Гораздо проще арендовать хранилище у другого облачного провайдера"... и надеяться, что он в свою очередь не арендует хранилище у первого
Но айтишники и эффективные менеджеры говорят, что это все вчерашний день.
Из этого петабайта реально критических для бизнеса данных заметно меньше. Если вы не крупный контент-проект, конечно.
По расссссово-гендерным квотам.
То ли дело РФ, где нет расово-гендерных квот и всё менеджеры отобраны исключительно по профессиональным качествам.
Из этого петабайта реально критических для бизнеса данных заметно меньше. Если вы не крупный контент-проект, конечно.
Зы У нас, кстати, по этим петабайтам строятся всякие модели и делается аналитика. Не контент, данные с железа – нескольких миллионов датчиков.
Конечно, т-щ майор, так и сделаем
Тоже верно, но я исхожу из общего соображения "раз что-то бэкапят, то это кому-то важно".
Если у нас валит, например, петабайт данных в месяц, это ж какой канал нужен и объём дисков?.
Совершенно верно. Поэтому хорошим правилом считается иметь 3 географически разнесенных копии у 3 разных провайдеров.
правда, остаются политические риски.
Это ты так мягко назвал приход маски-шоу в офис с физическим изъятием локальных серверов с бекапами?
Политические - это когда тебе провайдер обрубит доступ в облако, потому как страна стала нон-грата. Оно, конечно, не моментально и не пожар, но попрыгать придется.
Ага. У большинства проектов такие жирные объёмы - это именно сырые данные для аналитики. Чаще, правда, не с железок, а торговой.
Но (опять же, не про всех говорю, и практически точно не про вас) есть ещё факторы:
- аналитика - всё ж побочная деятельность, если она слетает, бизнес на некоторое время потеряет в марже, но не разлетится в щепки тут же;
- часто история хранится годами, хотя модели учитывают со значимыми весами только свежее, так что бэкапить нужно опять же не всё;
- по той же причине потерянные данные очень быстро заместятся новыми, так что жить без аналитики бизнесу придётся сравнительно недолго.
Но (опять же, не про всех говорю, и практически точно не про вас) есть ещё факторы:
- аналитика - всё ж побочная деятельность, если она слетает, бизнес на некоторое время потеряет в марже, но не разлетится в щепки тут же;
- часто история хранится годами, хотя модели учитывают со значимыми весами только свежее, так что бэкапить нужно опять же не всё;
- по той же причине потерянные данные очень быстро заместятся новыми, так что жить без аналитики бизнесу придётся сравнительно недолго.
А уж уничтожение чудом сохранившихся данных скриптом - это совершенно гениально!
Вообще идея а) хранить только самую новую копию и б) удалять её до получения новых данных настолько странная, что, думаю, это самодеятельность клиента. Что не отменяет, конечно.
Правдоподобным видится мне чтото типа скрипта который удалял данные старее например 60 дней, а сервер был гденить в ангаре разбора оставшегося барахла полгода, и когда до него дошли руки и просто включили проверить работает или нет, он все и стер, никто не ожидал просто что 60 дней сервер будет выключен без доступа к нему.
Тру стори, сам однажды похоже налип с самописным скриптом.
Вообще идея а) хранить только самую новую копию и б) удалять её до получения новых данных настолько странная, что, думаю, это самодеятельность клиента. Что не отменяет, конечно.
В данном случае, вполне вероятно, что к моменту включения сервера прошло сильно больше чем N дней. В итоге скрипт номер один ничего не скопировал, скрипт номер два все удалил.
В нормальном же случае, если бы скрипт номер 1 ничего не скопировал, то прилетел бы алерт и в регламентированное время, бекап бы починили.
Это, к счастью, не типовой сценарий. Ну, точнее, кто удаляет по расписанию без проверки получения-целостности-доступности, ну тот сам себе злобный буратино и профнепригоден. Вообще удивлён, что такая практика до сих пор существовала, это ж самые азы и простой здравый смысл. Даже в 00-е такое уже делали... даже не знаю, кто.
И вот ещё момент: фиг его знает, сколько времени прошло между пожаром и попыткой восстановиться. Если реально дни, то, может, эти данные фирме были и не нужны вовсе?
И вот ещё момент: фиг его знает, сколько времени прошло между пожаром и попыткой восстановиться. Если реально дни, то, может, эти данные фирме были и не нужны вовсе?
Как-бы если падает основная инфра, и потом до бэкапа доходит дело через полгода, то, наверное, эти бэкапы не сильно-то и были кому-то нужны, нет?
Ну, точнее, кто удаляет по расписанию без проверки получения-целостности-доступности, ну тот сам себе злобный буратино и профнепригоден.
В данной ситуации первый скрипт просто, напросто не работал. Потому что ему неначем было. Поэтому никаких алармов не случилось.
Как-бы если падает основная инфра, и потом до бэкапа доходит дело через полгода, то, наверное, эти бэкапы не сильно-то и были кому-то нужны, нет?
Так у вас сервер в состоянии "неизвестно" эти полгода. Датацентр ответа не дает, говорит возможно, что он сгорел. Совсем. Какие у вас варианты?
Потому, что повторюсь - целостность/годность проверяет другой скрипт. Который работает каждый день, а если не работает - то это алярм и его чинят. В данной ситуации первый скрипт просто, напросто не работал. Потому что ему неначем было. Поэтому никаких алармов не случилось.
Хотя, говорят, хостинг помоечный был, может, это и штатное поведение...
Правда тут еще такой момент. Вряд ли скрипт на очистку запустился по факту включения сервера. Они как правило все по расписанию. А это значит что сервер включили, данные увидели и закричали "ура-ура". А проверить что на сервере, который никто полгода не проверял, настроено и банально что там у него в кроне никто не удосужился даже.
Ну кстати если совсем душнить, то очень врядли скрипт бэкапа удаляет данные с перезаписью рандомом, поэтому в принципе если быстро среагировать, то данные вернуть можно довольно просто. Так что мутно тут все.
поэтому в принципе если быстро среагировать, то данные вернуть можно довольно просто.
Сильно сомневаюсь, что там был физический девайс. Облако всё же, хоть и дешманское. Скорее виртуалка, или вообще голый сетевой том. А это значит шара, и её просто так никто не даст руками трогать, потому что мало ли какие там ещё данные.
Кстати, не пора ли выпускать сиквел "Omert@. Руководство по компьютерной безопасности" ?
Много воды утекло и много мобильников поменялось.
Много воды утекло и много мобильников поменялось.
Не храните, граждане, все яйца у одного провайдера! Делайте бэкапы в другие места - так намного надежнее!
Но в целом, отчет выглядит дико. Там же для сертификации ЦОД определенному уровню предъявляется вагон и тележка требований. Вопрос, как же они в принципе были запущены в эксплуатацию при таких адовых нарушениях всего и вся?
А доклад местной пожарной службы, опубликованный через год после происшествия, просто шокировал: в дата-центре были деревянные перекрытия, отсутствовала автоматическая система пожаротушения,
В воздухе витал запах коррупции.
PS я так понял, весь год пожарная служба искала следы деревянных перекрытий после пожара.
В воздухе витал запах коррупции.
PS я так понял, весь год пожарная служба искала следы деревянных перекрытий после пожара.
Там же для сертификации ЦОД определенному уровню предъявляется вагон и тележка требований. Вопрос, как же они в принципе были запущены в эксплуатацию при таких адовых нарушениях всего и вся?
А зачем его сертифицировать?
А зачем его сертифицировать?
Разумеется нет смысла переплачивать за услуги сертифицированного ЦОД для мелкого личного проекта чья копия параллельно есть дома на ноутбуке автора. Сгорит? Ну и черт с ним, подниму максимум через сутки простоя в другом месте.
PS я так понял, весь год пожарная служба искала следы деревянных перекрытий после пожара.
Я вам расскажу, как - разумеется это только фантазии, все совпадения случайны 😉
Компания нанимает консультантов по сертификации, специалистам лень ехать за 100 миль по пробкам - поэтому присылают молодую даму-стажера. Которая не отличает датчик затопления от датчика задымления и вообще - по дороге с обеда ей звонят из яслей и говорят что ребенок чем-то обьелся и его тошнит. Дама пулей улетает за деткой, инженеры клянутся и божатся что проверят все сами - но обнаружив, что присланные стажершей документы это плохой машинный перевод не то с суахили, не то с иврита - просто забивают и идут пить пиво.
Слегка охреневший от таких раскладов ответственный менеджер звонит на прежнюю работу, и ему присылают пакет документов, от 5-летней давности сертификации. Эти документы пересылаются инженерам с пожеланием совместить описанное там строжайшее соблюдение всех требований (включая не относящиеся к деятельности компании и обьективно невыполнимые) с довольно грустной реальностью.
Инженеры, ничтоже сумняшеся, выкидывают половину критериев и кое-как проверяют оставшееся - забывая в куче мест поменять имена, адреса и названия. Попеняв им за это, и радуясь выздоровлению детки, стажерша вечером исправляет все "косяки" - кое-где вставляя какие-то левые данные (видимо, перепутав с другими клиентами) или вообще явную отсебятину. На следующий день инженеры опять исправляют отчет - попутно переформатировав его так, что уже никто не может отследить изменения - и все это отсылается в сертифицирующую организацию.
За пару дней до "дня Д" оттуда спрашивают - сможет ли компания показать все необходимое, если проверяющий не приедет лично - а будет смотреть по Зуму. "Разумеется", отвечают инженеры, и было сделанные планы что-нибудь привести в порядок и где-нибудь прибрать - летят в корзину.
Разумеется, в "день Д" проверяющему быстро надоедает "летать" вместе с камерой ноута кого-то из инженеров по коридорам и закоулкам - и придравшись к каким-то недоисправленным местам в документе, он ставит "пройдено с мелкими замечаниями".
Компания нанимает консультантов по сертификации, специалистам лень ехать за 100 миль по пробкам - поэтому присылают молодую даму-стажера. Которая не отличает датчик затопления от датчика задымления и вообще - по дороге с обеда ей звонят из яслей и говорят что ребенок чем-то обьелся и его тошнит. Дама пулей улетает за деткой, инженеры клянутся и божатся что проверят все сами - но обнаружив, что присланные стажершей документы это плохой машинный перевод не то с суахили, не то с иврита - просто забивают и идут пить пиво.
Слегка охреневший от таких раскладов ответственный менеджер звонит на прежнюю работу, и ему присылают пакет документов, от 5-летней давности сертификации. Эти документы пересылаются инженерам с пожеланием совместить описанное там строжайшее соблюдение всех требований (включая не относящиеся к деятельности компании и обьективно невыполнимые) с довольно грустной реальностью.
Инженеры, ничтоже сумняшеся, выкидывают половину критериев и кое-как проверяют оставшееся - забывая в куче мест поменять имена, адреса и названия. Попеняв им за это, и радуясь выздоровлению детки, стажерша вечером исправляет все "косяки" - кое-где вставляя какие-то левые данные (видимо, перепутав с другими клиентами) или вообще явную отсебятину. На следующий день инженеры опять исправляют отчет - попутно переформатировав его так, что уже никто не может отследить изменения - и все это отсылается в сертифицирующую организацию.
За пару дней до "дня Д" оттуда спрашивают - сможет ли компания показать все необходимое, если проверяющий не приедет лично - а будет смотреть по Зуму. "Разумеется", отвечают инженеры, и было сделанные планы что-нибудь привести в порядок и где-нибудь прибрать - летят в корзину.
Разумеется, в "день Д" проверяющему быстро надоедает "летать" вместе с камерой ноута кого-то из инженеров по коридорам и закоулкам - и придравшись к каким-то недоисправленным местам в документе, он ставит "пройдено с мелкими замечаниями".
