#цод — Public Fediverse posts

Что общего у ЦОДов Яндекса, концерта Канье и Cloudflare: как проджекту работать с катастрофами

Новости о дата-центрах Яндекса заставили многих разбираться с отказоустойчивостью прямо во время аварии. При мне в Алматы случился блэкаут, после которого концерт Канье перестал идти по первоначальному плану. Выступление 14 августа 2026 года перенесли на следующий день: среди причин называли перебои электричества и непогоду. А один из сбоев Cloudflare пришелся прямо перед демо моего OSS-проекта . Я не приравниваю перенесенный концерт и сорванное демо к последствиям повреждения инфраструктуры. Общее здесь управленческое: проект теряет критическую опору, которую его команда не может немедленно вернуть. Если ты недавно работаешь проджектом, в такой момент легко решить, что сейчас от тебя требуется стать одновременно CTO, спасателем и человеком с ответами на все вопросы. Я бы предложил другую задачу: помочь команде разобраться в происходящем, получить нужные решения и сохранить связь с людьми, которые зависят от проекта.

https://habr.com/ru/articles/1092838/

#яндекс #катастрофа #рискменеджмент #цод #antigravity #кризисменеджмент #opus #codex #claude #deepseek

Площадка недоступна, сроков восстановления нет: как спроектировать DR, который переживёт потерю ключевого ЦОДа

В ночь на 8 октября в Yandex Cloud потеряла электропитание зона доступности ru-central1-b — один из ключевых дата-центров облака. К утру компания сообщила, что работа дата-центра полностью остановлена. Жалобы на сбои начали поступать от пользователей самых разных сервисов: сайтов объявлений вроде «Авито» и «ЦИАН», банков, транспортных порталов, ритейла и других. Утром 9 октября были полностью выведены из строя несколько модулей ещё одного дата-центра Яндекса, в Калуге. На момент подготовки статьи срок восстановления оборудования не назван. Для инженеров это повод ответить на неудобный вопрос: что будет, если площадка, где расположен прод, внезапно выйдет из строя на неопределённое время? Под катом разберём сценарии отказов инфраструктуры, архитектуру восстановления на независимой площадке и посчитаем RPO и RTO на модельном примере из 40 ВМ. Кат

https://habr.com/ru/companies/hstx/articles/1092602/

#резервное_копирование #цод #отказоустойчивость #disaster_recovery #rto #rpo #облачная_инфраструктура #yandex_cloud #репликация_данных #hystax_acura

Следующим была #Калуга

> Дата-центр #Яндекс в Калуге атакован беспилотниками.

> Несколько модулей полностью выведены из строя.

> На этот #ЦОД приходится более 3800 серверных стоек, каждая с расчётной нагрузкой 15 кВт.

Из свежего материала про рост бюджета на #Чебурнет
> #ГРЧЦ может получить (в случае одобрения этого бюджета) субсидию на создание еще одного #ЦОД для мониторинга и управления сетью связи общего пользования». 1,0 млрд рублей, только в 2027 году. В бюджете на 2026-2028 годы такой строки пока нет.

> Эту систему обслуживает ЦМУ ССОП. По приказу Роскомнадзора, при «угрозах устойчивости, безопасности и целостности» интернета центр передает указания для централизованного управления сетью и контролирует их исполнение, а данные хранит в «информационной системе мониторинга и управления сетью общего пользования». По данным Sostav, ЦМУ ССОП также организует управление ТСПУ и строит систему мониторинга маршрутов трафика.

> Зачем ещё один ЦОД ГРЧЦ в бюджете не написано. Есть две гипотезы

> Резерв для режима централизованного управления сетью... вплоть до изоляции российского Интернета..
> Расширение управления #ТСПУ.

https://te-st.org/2026/10/08/budget202729/
#Роскомпозор

DRP, который никто не проверял: почему план восстановления может не сработать в самый нужный момент

Привет, Хабр! Меня зовут Илья. Долгое время я работал в финтехах и у облачного провайдера. Занимался сопровождением информационных систем, причём не как инфраструктурщик, а как специалист по поддержке целых автоматизированных систем. То есть смотрел на ИТ не с уровня отдельного сервера, а с уровня «работает ли сервис для бизнеса и клиента». И сразу, пока вы не пролистали до конца, вопрос к вам. Друзья айтишники, вспомните момент, когда DRP действительно понадобился. Что пошло не так? Бэкап, который не восстановился? Резервная площадка, на которой «забыли» один сервис? Регламент, который лежал на той самой упавшей файловой шаре? Напишите в комментариях свои фэйлы. Чужие ошибки учат лучше любых методичек, а для кого-то ваш комментарий станет поводом проверить свой план до аварии, а не после. А теперь поговорим о том, как строятся планы DRP и почему наличие документа ещё не означает, что вы восстановитесь.

https://habr.com/ru/articles/1092138/

#яндекс #авария #стабильность #бизнеспроцессы #цод #itil #бпла #sre #drp #надёжность_хранения_данных