Владельцев ЦОДов могут обязать отключать неприоритетных клиентов для создания резерва под работу сервисов из белых списков. Отключение будет считаться форс-мажором. За неисполнение будет грозить введения временного управления Владельцев ЦОДов могут обязать отключать неприоритетных клиентов, если это потребуется для предоставления резервных мощностей сервисам из белых списков, рассказали три источника РБК в IT-отрасли. Отключения для освобождения резерва планируют признать форс-мажором, а неисполнение требований может стать основанием для введения временного управления. Такой механизм обсуждался на совещании в Минцифры 6 ноября на случай утраты части инфраструктуры и необходимости перераспределить оставшиеся ресурсы. Представитель Минцифры сказал, что в настоящий момент меры по реализации указа президента «находятся в проработке». Указ президента предусматривает резервирование 10% площадей и мощностей дата-центров. После решения специальной подкомиссии предоставить их потребуется в течение суток: если свободных ресурсов не окажется, операторам придется отключать действующих клиентов. Резерв разрешат формировать суммарно по площадкам оператора или холдинга, самостоятельно выбирая конкретный ЦОД.
По словам источников РБК, требования распространятся на коммерческие дата-центры независимо от формы собственности, включая площадки, которые одновременно обслуживают внешних клиентов и собственные системы. Корпоративные ЦОДы исключительно для внутренних нужд и пострадавшие дата-центры под требования не подпадут. Платить за само резервирование не планируется — только за фактически затребованное размещение по установленным подкомиссией тарифам. Участники рынка предупреждают, что освободить мощности и перенести информационные системы за сутки без заранее подготовленного резерва крайне сложно. Юристы также отмечают, что форс-мажор не означает безусловного освобождения оператора от ответственности и не компенсирует потери клиентов. Поэтому порядок отключения, уведомления, переноса данных и перерасчета рекомендуют заранее закрепить в договорах.
Интересно, кто виноват: рыночная экономика", которой по многим признакам нет, или административный ресурс, который постепенно заполняет собой все сферы нашей жизни?
Размещено через приложение ЯПлакалъ
А кто и как будет решать кто в приоритете? По сумме ежемесячной оплаты? По количеству CPU/GPU/RAM? Круто что сказать. Потрать время на разработку, поддержку, поиск клиентов. А потом тебя ррраз и за борт. И объясни клиенту, что у него не проходят оплаты, отчеты, записи да что угодно, потому что ты попал в немилость.
Забавно смотреть как новость обсуждают те, кто крайне хреново представляет "что такое дата-центр в физическом его виде" и особенно "что именно хотят резервировать".
По факту - для львиной доли дата-центров данная мера влияет... НИКАК. Просто в случае "прилётов" будет понятный план по стоечным раскладам. Не более.
Тут главное владельцам ЦОД коммерческих не заниматься хернёй и нормально управлять стоечными мощностями. По факту у нас щас процентах в 20-25 коммерческих не особо крупных ЦОД полный бардак. В относительно крупных и так всегда есть от 15% резерва. Просто из них 10% запишут как "резерв под белые списки". И всё. На уровне железа ни хрена делать не надо. Бумажки только нарисовать.
Другой вопрос, если в управлении ЦОД бардак и управление стоечным ресурсом идёт "хз как". Вот там беда будет.
За неисполнение будет грозить введения временного управления ... Платить за само резервирование не планируется — только за фактически затребованное размещение по установленным подкомиссией тарифам. Участники рынка предупреждают, что освободить мощности и перенести информационные системы за сутки без заранее подготовленного резерва крайне сложно. Юристы также отмечают, что форс-мажор не означает безусловного освобождения оператора от ответственности и не компенсирует потери клиентов. Поэтому порядок отключения, уведомления, переноса данных и перерасчета рекомендуют заранее закрепить в договорах.
Приехал мужик в ЮАР (давно еще). Решил в театр сходить. Пришел в кассу: - Дайте, плз, билет! - Ты что, первый раз в ЮАР? - Да, а как вы узнали? - Да в кассе у нас только негры билеты берут, а белые у администратора. Мужик к администратору: - Дайте, плз, билет в партер! - Ты что, первый раз в ЮАР? - Hу, а как вы узнали? - Да в партер у нас одни негры берут билеты, а белые в бельетаже, в ложах. Взял мужик в бельетаж. Сел, смотрит зрелище. Захотелось ему поссать. Терпеть уж мочи нет. Он к служителю: - А где тут у вас туалет? - Ты что, первый раз в ЮАР? - Да, а как вы узнали? - Да в туалет у нас ссать только негры ходят, а белые ссут прямо в партер, там ведь одни негры. Hу, встал мужик, стал ссать в партер. Вдруг из партера недовольный голос: - Ты что, первый раз в ЮАР ? - Да, а как вы узнали ? - Дык ты чего ж только на одного все время ссышь? Ты разбрызгивай, разбрызгивай!
Это сообщение отредактировал maxel - 10 ноя 2026 в 16:45
Владельцев ЦОДов могут обязать отключать неприоритетных клиентов для создания резерва под работу сервисов из белых списков.
После чего всё сдохнет еще во много раз быстрее, ибо в современном крупном бизнесе любая система связана с сотнями других, и внезапные отказы в десятке связанных систем, которые предполагались работать 24/7, практически гарантированно приведут к падению.
К примеру, если в кластере работает система А из белого списка и система B не из белого списка, и A лезет к B за чем угодно, то выключение системы B без как минимум перенастройки системы А (и скорее всего ее доработки) не уменьшит загрузку кластера, оно может кратно увеличиить. Потому что система вместо привычного получения ответа за 5 наносекунд будет получать таймауты за 5 минут, вынужденно запускать больше процессов, далее все свалится.
В общем, придумавшие это клинические дебилы не понимают, что с таким подходом они уронят вообще всё, и оставят украинских хакеров без премии, ибо все и так сломали без их помощи.
По факту у нас щас процентах в 20-25 коммерческих не особо крупных ЦОД полный бардак.
Коллега, Вы где-то видели, не полный бардак? За почти 30 лет в IT я не совсем полный бардак видел пару раз, и то были не Российские ЦОД.
А рандомное отключение части клиентов без предварительного тестирования возможных последствий просто кратно добавит уровень бардака.
Что можно было бы сделать - это заставить авторов белых списков прилюдно распечатать и сожрать те белые списки, и попросить нормальных специалистов, админов облака совместно с клиентами, соорудить систему приоритетов ресурсов внутри облака и их взаимозависимостей, с обязательным предварительным тестированием на тестовом стенде возможности отключения тех или иных систем без поломки всего остального.
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии. Авторизуйтесь, пожалуйста, или зарегистрируйтесь, если не зарегистрированы.
8 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей)