Cобираем 3U-сервер в 19” стойку из обычного десктопного железа1
Иногда мои клиенты звонят мне с запросом: "Нам нужен сервер в стойку под бэкапы 1С/CRM/логов (нужное подчеркнуть). Но денег на новый Dell или HPE у нас нет. И на б/у с Авито тоже нет".
Вот тут то нам на помощь и придет "самосборный" сервер из нового десктопного железа в 19" корпусе. Правда тут же упираемся в классический затык десктопных материнок: нет ECC, KVM, iDRAC, IPMI и прочих прелестей жизни. Если наш самосборный сервер зависнет на каком-нибудь предупреждении в BIOS - придется ехать к клиенту, чего нам ой как не хочется.
Корпус 3U в серверную стойку
Корпус взяли от ExeGate 3U400-07.Ожидали какой-нибудь "фольги из китая", которая гнется от любого дуновения ветра. По фактку оказалась вполне вменяемая железка: миллиметровая сталь, в нижней части корпуса и по бокам согнутая в два слоя - честные 2 мм. Ничего не болтается, не прогибается, в стойке будет стоять надежно. Доработка болгаркой или дрелью так же не понадобилась, что не могло не порадовать.
Внутри красиво, все как мы любим: блок питания встает рядом с материнкой, а перед корзиной с дисками уже встроены два шумных и быстрых вентилятора на сквозной обдув. Для обычных десктопных дисков форм фактора 3,5" в таком корпусе это спасение, иначе они придут в негодность очень быстро.




Корпус ExeGate 3U400-07 собственной персоной
По железу собрали максимально дешевый конфиг:
CPU: Intel Core i3-14100 (4 ядра / 8 потоков, базовый TPD 60W, встроенное видеоядро UHD Graphics 730).
Материнская плата: MSI PRO H610M-E DDR4.
ОЗУ: 16 GB DDR4 (2 × 8 GB 2666 MHz).
Storage: Seagate SkyHawk 6 TB (надежный диск с перпендикулярной записью CMR под непрерывную потоковую нагрузку).
БП: Montech Gamma II 550W (CWT-платформа, сертификат 80 PLUS Gold, плоские кабели).


Начинка для самосборного сервера в 19" стойку
Главный "чит-код": устанавливаем Nano KVM в PCI-Express
Чтобы не ехать к клиенту для подключения монитора с клавиатурой при каждой ошибке загрузки, поставим плату PCI-e Nano KVM, заказанную у наших рисовых братьев на одном популярном сайте.
По сути это автономный микрокомпьютер на планке, которая подключается в PCI-e слот. Этому микрокомпьютеру абсолютно без разницы, закрузилась ОС или нет.
Чем порадовал сей девайс:
Полноценная картинка с экрана, клавиатура, мышь, BIOS и меню загрузки прямо через веб-интерфейс.
Возможность нажимать на кнопки питания/перезагрузки так же через веб-интерфейс.
На задней планке у нее есть мелкий LCD-экранчик. Подключаем патч-корд и сразу видим IP-адрес, полученный по DHCP от роутера.




Nano KVM в PCI-Express слот
Кабель-менеджмент и сборка
Тут все банально и просто, в дополнительных пояснениях не нуждается. Устанавливаем материнскую плату с задней панелькой, прикручиваем блок питания, ставим жесткий диск в корзину.
KVM-модуль вставляем в слот PCI-e, соединяем все провода по схеме, подключаем пины с лицевой панели материнской платы. Для передачи видео и эмуляции USB-HID соединяем HDMI выход материнки с входом KVM коротеньким HDMI-кабелем (идет в комплекте), а управление подключаем обычным кабелем USB - Type-C, который так же идет в комплекте с KVM.
При укладке проводов не ленимся: все лишние хвосты от блока питания и прочие провода стягиваем пластиковыми хомутами.



Сборка 3U сервера из настольных комплектующих. Кабель-менеджмент.
Что по итогу?
Собрали, запустили, протестировали. Веб-морда KVM работает шустро, ничего не тормозит, сервер моментально перезагружается по виртуальной кнопке прямо из браузера.
Получилась холодная, не совсем тихая и полностью управляемая железка в стойку за адекватные деньги, собранная из обычных домашних комплектующих.





Nano KVM в веб-браузере, собранный сервер.
Оригинал статьи и больше фото комплектующих/процесса сборки выложил на it-foundation.ru. Вопросы по сборке пишите в комментах, всем отвечу.
13 миллионов захваченных гексов положили сервер моей GPS-игры
Спойлер: сейчас в GeoConquest захвачено уже 24,6 миллиона гексов (или примерно 8107 км²).
Но в сентябре игра была под угрозой отключения. Две недели я потратил на оптимизации сервера и снизил нагрузку на RAM в 44 раза, значительно ускорил захваты и также снизил нагрузку на CPU.
Однажды я выкатил небольшое обновление и стал ждать обычного редеплоя. Но GeoConquest не поднялась: сервер пытался загрузить в память уже накопленные территории и не справился. К тому моменту игроки захватили больше 13 миллионов гексов.
Важно: никто не захватил 13 миллионов одним махом. Это был общий результат игры, который серверу предстояло восстановить после перезапуска. Данные не пропали, у меня были резервные копии, но игра оказалась недоступна — и я не знал, когда удастся вернуть её в строй.
Я тогда временно поднял лимит heap, чтобы сервер хотя бы запустился. Но мысль «добавить ещё памяти» не могла быть решением навсегда. Позже даже попытка поднять лимит с 4 до 5 ГБ не помогла. А в голове крутилась совсем простая мысль: что будет, когда игроки захватят ещё миллион гексов? Неужели придётся покупать сервер подороже?
Незадолго до этого игра уже пережила захват примерно 3,23 миллиона нейтральных гексов. Результат появился меньше чем через девять минут, сервер продолжал работать. Тогда это выглядело хорошим испытанием. Но оказалось, что обработать большое изменение и заново загрузить в память весь уже накопленный мир — две разные задачи. Проблема проявилась не во время того захвата, а после обычного обновления.
Две разные нагрузки
Когда игра ожила, я стал смотреть на масштабирование шире. Если я хочу дальше развивать игру и приводить новых игроков, недостаточно просто надеяться, что текущий сервер как-нибудь справится.
У GeoConquest оказалось две отдельные проблемы роста. Первая — сам мир: игроки захватывают всё больше гексов, и их нужно хранить и показывать на карте. Вторая — количество одновременных действий: игроки двигаются, оставляют следы, запрашивают карту. Оптимизация одной нагрузки не решает другую.
И ещё третья проблема - скорость расчёта захватов стала уже неприлично долгой.
Я отдельно занялся частыми запросами, следами и отображением игроков. По графику загрузки процессорных ядер стало видно, что среднее напряжение немного снизилось и пиков стало меньше. Но вопрос оставался: что будет, если кто-то захватит ещё миллион гексов — или даже сто миллионов?
А одна из первых попыток разобраться с памятью дала обратный результат: прогрев сервера занял аж 4 минуты 40 секунд, а расход RAM вырос ещё примерно на 0,8 ГБ. Тут уже стало понятно, что нужно менять сам подход к данным.
Карта перестала помещаться в одну копию
Сначала я занялся обзорной картой. До этого сервер при запуске строил для неё большую копию в оперативной памяти. Я начал сохранять готовые фрагменты карты в базе данных, чтобы сервер мог доставать их по мере необходимости, а не держать целый мир в памяти, ещё и на разных масштабах.
Переход пришлось разделить на этапы. Для проверки нужно было подготовить почти 50 тысяч фрагментов карты на основе примерно 14 миллионов занятых гексов. На первичное заполнение базы ушло около трёх часов: всплывали ошибки, приходилось исправлять их и запускать процесс заново. Это был неприятный простой, но он помог подтвердить, что новая схема сохраняет и обновляет данные корректно.
После переключения карта стала загружаться из базы, а в памяти оставались только недавно просмотренные фрагменты. Потребление памяти основным процессом снизилось примерно с 3,7 до 1,86 ГБ. Перезапуск, который раньше занимал до 170 секунд, на этом этапе сократился примерно до 72. При ручной проверке карты около 84% запросов обслуживались из памяти, среднее время ответа было около 45 миллисекунд.
Но это была проверка прокруткой карты, почти без одновременных захватов. Она не доказывала, что игра уже выдержит тысячи игроков. Зато стало ясно, что у нас появился запас для следующего шага. Я смог выдохнуть и уже не бояться нависающей угрозы.
Миллионы гексов — сотни тысяч записей
Следующая идея была в том, чтобы не хранить каждый маленький гекс отдельно, если большая территория целиком принадлежит одному владельцу. В H3 есть вложенные друг в друга уровни шестиугольников: однородную область можно представить ячейкой покрупнее, а там, где владельцы различаются, снова разбить её на более мелкие.
Перевод шёл постепенно, в фоне и со сверкой данных. Это было важно: речь шла о реальных территориях игроков, и ошибка могла стоить им захватов.
В итоге 15,64 миллиона игровых гексов удалось представить примерно 354 тысячами укрупнённых записей — примерно в 44 раза меньше. На одном из промежуточных этапов все территории занимали около 36,5 МБ RAM. После финального этапа весь игровой процесс использовал около 645 МБ оперативной памяти; собственно JavaScript heap — около 292 МБ.
Для моего сервера с 8 ГБ RAM запас более чем достаточный.
Тогда же перезапуск удалось сократить до 18–20 секунд. Но это улучшение оказалось не вполне устойчивым: после следующего выката один из перезапусков снова занял около 170 секунд. Так что я не хочу выдавать промежуточную цифру за гарантированную скорость после всех изменений.
Последний шаг был уже про ожидание захвата. В локальной эмуляции тяжёлого реалистичного примера расчёт сократился с 9,36 до 1,45 секунды — примерно в 6,5 раза. На проде к расчёту добавляется запись результата, поэтому это не обещание, что каждый захват теперь занимает ровно столько же. Но это хороший признак: расчёт наконец тоже начал ускоряться, а не только занимать меньше памяти. В реальности скорость захватов увеличилась в десятки раз, потому что записывать в БД владельцев гексов теперь тоже быстрее (из-за сворачивания через h3).
В течение 2 недель я боялся, что следующий большой мир просто не даст серверу запуститься. В тот момент оптимизация не добавила на карту новой кнопки или красивого эффекта. Зато её результат игроки должны почувствовать в обычных вещах: меньше ждать загрузки, перезапуска и расчёт гигантских захватов за секунды. Теперь я могу спокойно развивать проект дальше, уже выпустил и клиентскую оптимизацию, и приложение на Google Play, и множество других улучшений и фичей.
Попробуйте GeoConquest в Google Play или через браузер.
Селф-хост в 2026. Часть 2. Железо
По следам первого поста серии- продолжаю, как и обещал, постом про железо.
Сразу обмолвлюсь о том, что и так написал в первом посте серии- сейчас накопители стоят ОЧЕНЬ ДОРОГО, поэтому цельная система, если у вас нет особых условий (а это или наличие железа вида "по полкам валяется", или же если сервисы, которые вас интересуют- на зависят сильно от накопителей. ) - тоже будет дорогой.
Плюс целиком покрыть огромный рынок БУ, даже тематического- просто нереально, поэтому тут я не буду рассматривать совсем "гиковские" варианты типа "Зион с Алиэкспресс". Это не делает эти конфигурации плохими, просто иначе пост выйдет километровым.
В целом системы для селф-хоста можно разделить на следующие категории:
1) "Особые" случаи- как правило это SBC (Single Board Computer, одноплатный компьютер) вроде различного рода * Pi (Raspberry Pi, она же "Малинка" , Banana\Orange\.... Pi), или же немного изврата с адаптацией железа с других платформ под нужды селф-хоста. В первом посте я описал, что минимальной планкой для селф-хоста сейчас ставлю 6 т.р. + накопители, и описал, что за эти деньги можно ожидать ТВ-бокса китайских небольших компаний, прошиваемого на Линукс. И я все ещё считаю, что для ультра-бюджетного "Вкатывания" в селф-хост это один из лучших вариантов. Почему? Об чуть позже.
2) Неттопы\Мини-ПК\ноутбуки. Всё это -вполне подходящие варианты, хоть и с рядом условностей. Они, как правило, сильно дороже (если речь идёт о хотя бы отдалённо свежем железе) , но при этом это компактное решение, которое потянет бОльшую часть вычислительной нагрузки вне ИИ-среды.
3) Полноценные ПК , самосбор. Вариант более чем рабочий, но с рядом ощутимых оговорок.
4) NAS (Network Access Storage) или ему подобные "Коробочные" решения. Плюс - как правило- работает из коробки, и часто обладает функциями, которые в других вариантах категорий 1-2 из коробки не найти- RAID\зеркалированием, например. Минус- обычно дороже , часто- вендор-лок, и доступный софт может , в зависимости от платформы, быть ограничен.
Это -основные категории. Они могут спокойно пересекаться от модели к модели по производительности, по стоимости, по фичам. Категория в данном случае определяет скорее форм-фактор устройства.
Далее я рассмотрю основные, на мой взгляд, варианты в каждой категории, распишу примерные ценники , плюсы и минусы.
Вариант А:
ТВ-бокс на Android, прошитый на Linux.
В чём преимущество?
Всё просто:
Обычно ценник на них чуть выше (3.5-5 т.р.) , но это всё ещё хорошее предложение.
Плюсы- за эти деньги получается полностью готовая к подключению накопителя коробочка, которая сразу обладает и WiFi\BT, и аппаратным декодированием H264\H265, и гигабитным LAN-портом, ест ~10 ватт , при желании помещается в карман, и может работать полностью пассивно, без шума вентиляторов.
При этом на борт ставится вполне полноценный Linux (обычно Armbian) ,и такой бокс запросто держит десяток не самых требовательных приложений.
Минусы- нужно очень тщательно выбирать модель (уровень поддержки может разниться от "Всё сразу заработало" до "Ни вайфая, ни сетевой, только консоль в зелёной гамме"), ограничен выбор дистрибутивов Linux (базово обычно Armbian, изредка встречаются Arch-based сборки типа той же Manjaro. Процесс запуска Linux может быть не самым очевидным, а установка "полноценно" в память самого бокса- хлопотной.
Производительность таких ТВ-боксов находится где-то на уровне флагманских телефонов начала десятых годов, или даже ниже. Казалось бы- этого очень, ОЧЕНЬ мало, но на практике- этого достаточно в разумных пределах . Тяжелые сетапы вроде Nextcloud+ Immich+ Homeassistant + Jellyfin такая коробочка не потянет ,но по одному-два эти сервисы вполне можно использовать. Или же пяток-десяток сервисов , не сильно требовательных к железу.
В целом- это вполне рабочий вариант, если селф-хост пробовать впервые. Если даже "не зайдёт" - коробок прошивается на Android и служит просто ТВ-приставкой, или же прошивается в ретроигровую консоль, или... Не шумит, много не ест, в зависимости от модели и поддержки- может требовать изредка перезагрузки.
Общий минус что категории приставок, что мини-ПК - это отсутствие возможности зеркалирования дисков или создания RAID-массивов нативно.
Вариант Б:
Неттоп\Мини-ПК.
Это решение уже классом выше . Даже условный Intel N150 даст в конечном итоге сильно бОльше свободы в плане запуска сервисов, а Ryzen 3000\5000\6000\7000 -вообще может потянуть даже простенькую ИИ-нагрузку.
Ценник, разумеется, тоже улетает вверх, но тут по-разному. Новый фирменный мини-ПК может варьироваться от ~15 т.р. за сетап на условном N150\Ryzen 3***U и с 8 ГБ оперативной памяти, постепенно повышаясь до ~ 25-30 т.р. за сетапы на Ryzen 5500u и ближайших к нему (в сборке с накопителем и оперативной памятью), и уходя дальше- к сборкам на Ryzen 255, и совсем навороченным машинам на Ryzen 3** AI\HX за 200+ тысяч рублей. Для домашней серверной нагрузки это избыточно, за исключением локальных нейросетей.
Плюсы:
Всё ещё легче, меньше, тише , чем полноценный сборный ПК. В отличии от тв-боксов- уже довольно легко апгрейдится (не всегда, есть модели с распаянной памятью, особенно в области "инженерных" чипов). Сетапы на N100\N150\N200 могут работать пассивно (за счёт массивного корпуса, выступающего радиатором), Райзены - как правило с ноутбучной "Турбиной" . Это уже не полная тишина, но в комнате с таким всё ещё можно спокойно спать.
Зато это полноценный X86\64 , т.е. выбирать дистрибутивы можно спокойно, вплоть до "специфичных", мощности уже хватит для полноценной нагрузки полным набором софта вне ИИ-среды, плюс N*** у Интела обладают отличным встроенным декодером\энкодером видео , а Ryzen - кодируют видео на iGPU (VAAPI).
Практически всегда- опять же "Batteries Included", т.е. на борту уже будет Wi-Fi\BT приёмник, но портов USB сильно больше, могут быть дополнительные фичи.
Минусы- ценник взлетает быстро, тишина, опять же, уже не полная (модели с "турбиной" могут основательно реветь во время активной нагрузки), у некоторых моделей всё ещё присутствуют костыли в плане совместимости драйверов с Linux (в основном Wi-Fi\BT модулей или Ethernet-адаптеров). Всё ещё в большинстве случаев нет поддержки RAID.
В целом- модели нижнего и среднего ценового- вполне пользуются популярностью в виде "домашних серверов", хотя и не без конкуренции со стороны БУ -рынка.
Вариант В: SOC, также известный как одноплатник.
По сути- это решение где-то между ТВ-боксом и мини-ПК. Как правило- в основе всё ещё ARM-чипы, от всё того же S905X* до RK3588 и выше. В эту категорию попадают различные * Pi (Raspberry Pi\Banana Pi\ Orange Pi \ Rock * и т.д. ). В отличии от ТВ-боксов- у таких плат, как правило, есть полноценные выходы GPIO, SATA\NVME M2, иногда - несколько Ethernet разъемов и готовые сборки Linux под конкретную плату.
Плюсы- всё ещё тихо, холодно , но гораздо производительнее.
Минусы- дорого (ДОРОГО) относительно прямой производительности, нуждается в докупке "аксессуаров" (корпуса, БП , "шапки" , т.е. платы расширения, адаптеры Wi-Fi и BT для большинства моделей (на скриншоте выше- чисто плата. Вообще без "обвеса". За него можно смело добавлять 10-15 тысяч к стоимости.). Увы , но этот вариант из селф-хоста всё чаще выпадает, просто потому, что полноценный "сервер" на RK3588 выходит в сумму, сравнимую с полноценным мини-ПК , при этом разница в производительности будет колоссальной. GPIO- однозначно полезны, но реально нужны только совсем небольшому кругу энтузиастов, в сфере селф-хоста- редко. По сфере SOC\SBC кризис памяти ударил больнее всего, фактически сегмент убит.
Вариант Г: Самосбор на основе полноценного ПК.
То, что обычно представляют при словах "Домашний сервер" .
Тут всё просто- берём обычный компьютер, ставим "серверную" ОС. Места под жесткие диски- уйма. Запас по питанию- огромный (если БП позволяет) . Процессор\ОЗУ\ГП - можно варьировать как угодно.
Плюсы- модульность полноценная, апгрейд- прост как три копейки. Любой необходимый набор интерфейсов . Полноценный RAID при наличии достаточного количества дисков .
Минусы- попытки сэкономить где только можно рискуют породить монстра. Сосуществование с огромным гудящим 24\7 гробом в одной комнате может быть довольно неприятным. А собрать такой ПК маленьким, тихим и сбалансированным- может быть или дорого, или довольно нетривиально. В "народной" нынче платформе AM4 материнских плат формата Mini-ITX не слишком много, корпус- ещё можно найти, но в целом- это относительно хлопотно. Плюс основной нюанс селф-хоста - "сам управляешь- сам несёшь ответственность" тут работает в два конца- самостоятельно собранный ПК - это принятие ответственности за сборку.
Разумеется, что сборка навроде AM5 Ryzen 7***X + 32 GB DDR5 + какой бы то ни было GPU, на в Mini-ITX корпусе объемом в несколько литров, да с тихоньким кулером- это прямо мечта от мира домашних серверов. Но :а) ДОРОГО. б) Сборка такого ПК уже требует опыта от сборщика, т.к. часто там процесс сборки отличается от "обычного" , в) имеет смысл только в случае полноценных станций для локального ИИ- для всего остального это слишком большая вычислительная мощь, ещё и выливающаяся в неплохой жор электроэнергии.
Вариант Д: БУ-рынок ПК\неттопов, Авито, списанный энтерпрайз.
Это рынок, уже требующий определенного опыта. На площадках типа Реддита, обычно, когда заходит речь об "оптимальном" железе - часто звучит что-то наподобие "ThinkCentre с Ebay за 100-200$" ,и в зависимости от обстоятельств- это вполне может быть актуальным выбором. Часто за те же деньги, которые обойдётся мини-пк с маркетплейсов , можно взять БУ ноутбук на той же платформе,или даже мощнее. Нужно ли- вопрос, но возможно.
Но стоит понимать, что Авито- это в принципе мир в себе.
Поэтому покрыть рынок БУ ПК одним постом- в принципе, на мой взгляд, практически нереально.
Вариант Е: NAS.
Тут всё просто- это решение, которое работает "Из коробки". Оно уже рассчитано на какое-то количество дисков, как правило- поддерживает NAS, обладает операционной системой, специально заточенной на селф-хост с поддержкой каких-то базовых сервисов.
Аппаратно они делятся на два крупных вида:
X86-64 . Тут всё просто -это, по сути, просто неттоп\мини-пк, к которому производитель сразу приделал RAID-контроллер и распланировал корпус под N дисков. Обычно это оборачивается ощутимым повышением ценника, что может вывести аналог неттопа за 20 т.р. в ценовой диапазон ближе к 40-50.
ARM- как правило, остро заточены под задуманный производителем сет программ. Может варьироваться от "Просто диск с доступом по сети через приложение" до полноценной поддержки Docker и настроенного производителем "магазина приложений". Стоит понимать, что подобные штуки, хоть и хорошо выглядят "из коробки" -могут быть проблемными в тонкой настройке .
Важно- всё больше NAS отказывается от поддержки 2.5\3.5 HDD, переходя на NVME-only хранилище. Перед покупкой обязательно стоит проверить поддерживаемые конфигурации дисков.
По сути- по мощности, по функционалу и по ценнику, эти категории могут легко пересекаться, а могут и прямо находиться на разных углах. Те же NAS часто могут обладать железом даже слабее, чем дешёвый TV-бокс, но закрывать основную его слабость- отсутствие гибкости в подключении и выборе накопителей.
Но в целом- это основные категории, в которых имеет смысл смотреть. Это недёшево, но тут остаётся только пожать плечами. Именно подорожание комплектующих, по сути, сейчас вышибает селф-хост в "нишевое" хобби.
Мини-ПК, служащий мне сейчас "сервером" , взятый когда-то за ~ 20 т.р. - сейчас даже на БУ-рынке приближается к 25-30 в стоимости . Жесткий диск, взятый года полтора -два назад за 7 т.р., сейчас в том же магазине приближается к 25 т.р. . И т.д.
В целом, несмотря на то, что я начал эту серию постов- я не могу однозначно порекомендовать сейчас влезать в селф-хост. Повторю вывод из первого поста- хорошо, если у вас есть "ненужное" железо или накопители. В противном случае- слишком дорого.
Итоговая лестница производительности:
TV-Box (S905X*) => ARM NAS => High-Tier SBC (одноплатник на 3588 или Amlogic S92*) => N150\ Ryzen 3*** => Ryzen 5***\6***\7*** => Десктопный Intel\Ryzen свежих поколений => Флагманские "мобильные" чипы => флагманские десктопные сборки.
X86-64 NAS просто ложатся в категорию по чипу, а не в отдельный слот.
В следующем посте я рассмотрю "сопутствующие траты" и подобные моменты (Роутер , и его роль в "домашнем сервере" , различного рода "адаптеры" для нестандартных протоколов, ИБП, и т.д.), а затем- перейду уже к чисто программной части - ОС (их целая россыпь!) , основным механизмам (Натив\VM\Контейнеры, доменные имена -DNS-DDNS, реверс-прокси, порт-форвардинг и т.д.) , и затем уже - полноценно побежим по софту, от крупных платформ (Jellyfin\HomeAssistant\Nextcloud\*arr) к более тематическим программам.
Когда падают облака: почему держать корпоративную почту у себя — это всё ещё хорошая идея
Недавние масштабные сбои у крупных почтовых провайдеров в очередной раз напомнили старую ИТ-мудрость: «Облако — это просто чей-то чужой компьютер». Когда внешний сервис ложится отдохнуть, работа встает у всего офиса. Договоры не отправляются, клиенты ждут, бухгалтерия паникует, а руководство смотрит на сисадмина так, будто это он лично перегрыз кабель.
Своя почта внутри периметра организации — это гарантия того, что ваши данные и переписки зависят только от вас. И чтобы не собирать почтовик на коленке, настраивая конфиги ночами, хотим напомнить про наш продукт.
В составе интернет-шлюза NGFW ИКС уже есть полноценный встроенный Почтовый сервер. Разворачивается внутри вашей инфраструктуры и остается под вашим полным контролем.
Что под капотом (и почему за него не стыдно):
Полный контроль над ящиками: есть мастер-аккаунт для доступа ко всей почте, делегирование прав и удобные общие адресные книги.
Порядок с местом на дисках: можно смотреть общий объем почты по всему домену (удобно для оценки), настраивать квоты (с уведомлениями отправителю, если ящик забит) и автоматически удалять старые письма по дате.
Безопасность: передача писем идет строго по зашифрованному каналу, а для исходящих сообщений настроена проверка и автоматическое добавление DKIM-подписи (чтобы ваши письма не улетали в спам у партнеров).
Удобная миграция: есть встроенный сборщик почты.
Поле «Описание»: мелочь, а приятно — доступно для всех доменов и конкретных ящиков, чтобы не путаться, кто есть кто.
Отдельная история — защита от спама Мы понимаем, как раздражают письма с предложениями «увеличить продажи» и фишинговые рассылки. Поэтому вкрутили многоуровневую систему очистки:
Движки на выбор: Kaspersky Anti-Spam, проверенный SpamAssassin и быстрый Rspamd.
Поддержка серых списков (GreyListing) — отлично отсекает примитивных спам-ботов.
Черные списки DNSBL.
Ручная настройка блэк- и вайт-листов по email, IP-адресам и даже отдельным фразам.
Вместо заключения
Мы знаем, что любой нормальный админ не поверит красивым текстам, пока не пощупает всё сам. Поэтому ИКС не нужно покупать вслепую. Вы можете развернуть его в своей инфраструктуре и полноценно протестировать.
Если тема актуальна и хочется спать спокойно, не завися от настроения крупных ИТ-гигантов — заходите на наш сайт, оставляйте заявку на тест и возвращайте контроль над почтой в свои руки.
Селф-хост на волне происходящих событий. Пост №1. Мета
Всем привет. Словами многих блогеров, которым сейчас уже практически не верят- "Я очень не хотел делать этот пост". Это , отчасти, правда. Но в свете последних событий с ЦОДами Яндекса- несколько клиентов пришли с благодарностью, заодно дав понять, что тема селф-хоста, несмотря на ценовой скачок железа, всё ещё остаётся актуальной, хоть и стала более нишевой.
Поэтому я решил начать на Пикабу серию постов, посвященных тематике селф-хоста. Начиная от "Меты" , т.е. общих понятий, принципов, и механизмов, заканчивая обзорами на крупные или малоизвестные софтины в этом направлении. Серия будет длинной, т.к. вопрос очень, ОЧЕНЬ объёмный- я надеюсь хотя бы раз-два в неделю расписывать короткие обзоры на софт, но ничего, увы, обещать не могу. Первое время постов будет много, т.к. я буду излагать основы, затем- как пойдёт. От плюсов-минусов моё желание расписывать свой опыт зависит мало, поэтому даже если уйду в отрицательный рейтинг- да и шут с ним.
Этот пост будет довольно рваным, т.к. какой-то единой темы и идеи у него нет, просто формирую общую идею будущей серии.
На данный момент я занимаюсь настройкой "homelab" под ключ. Не скажу, что услуга пользуется огромным спросом, но он есть. Сразу обмолвлюсь- во избежание обвинений в предвзятости- на Пикабу, и в других источниках, если я буду их заводить- я НЕ буду оставлять никаких данных о контактах и рекламу собственных услуг. Для меня это принципиально. Я здесь не для рекламы, а для того, чтобы, возможно, подарить хобби хотя бы небольшому количеству людей. Хобби, которое в данный момент стало нишевым, но всё ещё позволяет относительно бюджетно стартовать, и приносит плюшки то тут, то там в повседневной жизни.
ВАЖНО: я НЕ сторонник "отказа от корпораций". Селф-хост в моих глазах- это не про "ОНИ НЕ ПОХИТЯТ МОИ ДАННЫЕ" , и не про корпорации добра, зла, и прочие. Я просто хочу получить систему, которую смогу подстраивать под себя более гибко, чем имеющиеся сервисы- аналоги, и которая будет закрывать мои потребности, которые не закрывают имеющиеся на рынке сервисы. Это не акт борьбы, революции против бигтеха, это просто "своё хочу".
Итак, начинаем.
Пост 1. Мета.
Что такое этот ваш "Селф-хост"?
Селф-хост (Self-host) - это процесс, при котором человек (или группа людей) необходимые им сервисы заводит на собственных вычислительных мощностях. В принципе- это всё определение, да. Что это будут за мощности- дело запускающего. Они могут быть в том числе арендованы "В облаке", но обычно всё сводится в том или ином виде к концепции "домашнего сервера" - какой-то железяки, которая лежит дома, 24\7 подключённая к питанию и Интернету, и на которой запущен некоторый набор программ.
А зачем оно вообще?
В последние ~10 лет селф-хост стал набирать популярность. Практически все нынешние крупные проекты в этом направлении появились где-то в начале-середине десятых годов, а сейчас имеют крупные сформировавшиеся сообщества.
Причина, по которой это произошло за границей- в основном сводится к паре столпов:
а) Ужесточение анти-пиратского законодательства. Блокировки пиратских CDN и изъятие серверов, "подсадные" юристы в P2P сетях, из-за которых скачивание торрента в какой-нибудь Германии запросто оборачивается многотысячным штрафом.
б) Постепенное увеличение подписочной нагрузки. Западное общество, особенно в США- довольно сильно закредитовано. Подписки на контент в этом случае ложатся примерно в ту же корзину, что и платежи по кредиткам- это "текущая нагрузка". Когда практически единственным сервисом был Нетфликс- это работало даже на уменьшение пиратства как такового- геморрой с поиском контента не стоит пары баксов за "расшаренную" подписку. Но с тех пор контент распочковался по десятку-двум платформ, каждая- с эксклюзивами, каждая с отдельной оплатой, и при этом - ещё и дорожающей.
в) Общее отторжение принимаемых в пределах технологического сектора решений. Постепенно идея того, что хранимые на серверах корпораций данные- не твои, они могут быть не просто отобраны у тебя, но и использованы тебе во вред. Через что-то подобное средний пользователь прошёл ещё в нулевых на взлетё условных фейсбуков и ВКонтакте- тогда на волне восторга от концепции там могли спокойно оставить номер телефона на всеобщее обозрение, а то и вовсе фото, которые не предполагали кому-то показывать. Постепенно рядовой пользователь приучился разделять свои данные на "свои" и "публичные" . Сейчас подобное происходит несколько глобальнее. Инициативы типа Stop Killing Games в том числе поднимают и этот вопрос, т.к. предмет обсуждения хоть и отличается, но лежит в одной плоскости.
В случае с РФ добавляется ещё пара моментов, ставших актуальными за последние года:
а) Массовый отзыв лицензий на контент с отечественных стримингов , плюс борьба зарубежных сервисов с пользователями под VPN, и разворот в сторону геоблока в целом.
б) Общее нагнетание атмосферы "интернет не нужОн" - постоянные разговоры о белых списках, платном международном трафике, и т.д.
в) Прилёты по ЦОДам открывают новый слой во всей этой ситуации, да.
Ну и остаётся то самое "убеждение". "Всё своё ношу с собой" и прочая идеология.
В чём сейчас плюсы?
Ровно в том же, что и за рубежом- твой контент остаётся с тобой. Твои фото- твои, доступны тебе в любое время, не будут удалены из-за того, что нейросеть при заливе обнаружила там что-то нехорошее, не будут принудительно сжаты для сокращения издержек, тебя не будут шантажировать тем, что если ты перестанешь платить на месяц-два - фото просто удалят.
Плюс номер два- селф-хост системы могут быть гораздо более гибкими, чем их "сервисные" аналоги. Возможно и обратное, да. Но из того же Nextcloud можно собрать не просто облако, а "твоё" облако- с нужным тебе функционалом, вмещающее не только файлы и документы, но и штуки, которые интересны именно тебе- книгу рецептов, журнал КБЖУ, или хранилище моделей для 3D-печати с предпросмотром.
Плюс номер три- прямой доступ из локальной сети в отсутствие связи. Если провайдер уронил доступ к интернету , но ты сидишь дома, и сервер у тебя под кроватью- данные доступны. Это не без нюансов (при схеме "провайдер уронил интернет" - не будет доступа извне, или же нужен резервный канал), но это остаётся верным в большинстве ситуаций. Исключение- белые списки. Но БС это в принципе штука, которая практически любую логику связи ломает напрочь.
В чём минусы?
Основных минусов на данный момент четыре. И два из них взаимосвязаны.
Первый- довольно большие затраты в момент старта. В будущих постах я распишу совершенно разные сетапы и по стоимости, и по мощности. Но факт остаётся фактом- если у вас нет железа на руках , то это немаленький чек на старте. Перебивает ли это подписки- вопрос, на который каждый отвечает себе сам.
Второй - сейчас ОЧЕНЬ, ОЧЕНЬ плохая ситуация с ценами на накопители. Если у вас есть , условно, "завалявшийся" жесткий диск или SSD- это очень круто. Но ценник на классические HDD улетел в космос. Модель, которую я года полтора назад брал за 7 т.р. (4ТБ HDD) , сейчас еле-еле можно найти за 25. Терабайтный HDD фактически ушёл по стоимости выше, чем терабайтный SSD из бюджеток. Это ОЧЕНЬ ДОРОГО. И увы, но пока не начнёт сдуваться (именно сдуваться) ИИ-пузырь - улучшения вряд ли будут. Будет дороже. Будет сложнее.
Третий- данные твои. Ответственность за них- тоже твоя . Умер диск, и данные не зеркалировались- попрощайся с ними. По незананию сделал rm -rf /? Попрощайся с ними. Ты решил переустановить систему, а потом понял, что сервис шифрует данные ,а ключ ты не сохранил? Исход понятен. И так далее. Нет волшебного Яндекса, который хотя бы попытается восстановить твои данные, если у них откажет ЦОД (пока отказов не станет слишком много). Ответственность целиком на тебе. Это ВАЖНО, и именно это ломает розовые очки большинству селф-хостеров в момент первой поломки. Ломает с хрустом, после чего, как правило, многие просто уходят из селф-хоста и больше не оглядываются.
Когда селф-хост имеет смысл? Когда смысла нет?
Тут чисто моё мнение, т.к. объективно- вопрос сложный.
Селф-хост имеет смысл, если:
1) У вас есть "ненужное" железо. Сейчас, повторюсь, селф-хост это ДОРОГО.
Старый ПК, который вы уже пообновляли. Жесткие диски, которые лежат ещё с прошлых железяк типа ноутбуков. В таком сетапе можно как минимум начать вообще без боли. Понравится- окей. Не понравится - железяки просто вернутся на полку.
2) У вас есть не самые большие деньги и накопитель, но вопрос интересен и попробовать хочется.
Для себя минимальную планку я установил примерно в 6 т.р. и терабайтный накопитель сверху. О железе как таковом будет следующий пост, где я распишу разные ценовые категории серверов и то, что на них получится\не получится запустить. Но если не брать откровенно рандомные ПК с Авито- то 6 т.р. это минимальная планка, представляют которую , внезапно, даже не ПК, а прошиваемые на Linux ТВ-боксы на китайских платформах. Vontar X3 я испытывал в течении сервера примерно год-полтора, и хотя не без проблем- но с ним вполне можно окунуться в эту среду. К тому же в случае чего такие штуки довольно просто прошиваются обратно на исходную, и остаются рабочим ТВ-боксом.
3) У вас есть деньги, и хочется хобби.
Тут всё просто - селф-хост это буквально цифровая версия ,условно, жигулей в гараже. На доведение селф-хост сетапа под себя можно запросто убить год-два веселых посиделок по вечерам, и при этом какую-то отдачу в быту ты будешь от этого чувствовать. Это весело. Ну и навыки в ИТ понемногу, но качает.
4) У вас есть интерес к "умному дому", или ваши потребности в плане сервисов лежат НЕ в плоскости ИИ и киношко-музыкальной мультимедии.
Селф-хост - не обязательно про огромные количества данных. Умный дом- вполне себе вариант селф-хоста, и при этом наличие домашнего сервера сильно расширяет возможности и свободу выбора в плане железяк умного дома.
Кроме кино,музыки и фото, которые занимают на накопителях подавляющее большинство места -есть ещё десятки программ и проектов, которые не сильно требовательны к накопителям, но успешно интегрируются в повседневную жизнь. И хотя в основном, говоря про селф-хост, вспоминают именно Plex\Jellyfin и *arr -ими всё далеко не ограничивается.
Смысла лезть в селф-хост НЕТ, если :
1) Вас полностью устраивает текущее состояние подписок и прочего, за которые вы платите, а риски, связанные с недавними событиями или блокировками- вы считаете приемлемыми.
2) У вас очень небольшой бюджет, и нет свободных накопителей. Слишком дорого сейчас. Увы. Плюс сервер под кроватью- это хоть и не самые большие, но затраты на розетку.
3) Вы не готовы к тому, что софт будет время от времени отказывать, сервер надо иногда перезагружать , обновлять и в принципе периодически уделять ему время.
4) Вы предпочитаете "под ключ" решения, даже если они дороже или менее функциональны. Это нормально.
Более детально определить, привлекает ли вас идея селф-хоста, можно будет по ходу серии постов.
В принципе- на этом первый пост, наверно, и закончу. Следующий пост в ближайшие пару дней будет по "железу" - распишу основные конфигурации от ультра-бюджетных до ультра-дорогих, рассмотрю "коробочные" решения и их плюсы и минусы, распишу не-серверные затраты на селф-хост. Постараюсь уделить больше времени оформлению поста, иллюстрациям и прочему.
Комментарии буду по возможности читать, на вопросы охотно отвечу. Сразу замечу- я попытаюсь излагать вещи так, чтобы они были понятны, условно, человеку "не в теме". Это может приводить к тому, что достаточно сложные вопросы я буду упрощать до более примитивных , а это, как правило, порождает неточности.
У Яндекса атаковали три дата-центра. Насколько мы близки к «всё, рунета больше нет»?
После атак на дата-центры Яндекса начались разговоры о том, что ещё немного и Рунет закончится. Когда одновременно не вызывается такси, не проходит оплата и не открывается рабочая почта, поверить в это довольно легко. Особенно если рядом уже объясняют, сколько серверов осталось до цифрового средневековья.
Я решил разобраться, что действительно произошло, сколько у Яндекса дата-центров и почему наличие резервных копий не спасает от всех неприятностей. Получилась история серьёзнее, чем «ничего страшного, сейчас перезагрузят», но оснований объявлять скорые похороны всего рунета я тоже не нашёл.
Начнём с того, что подтверждено. В ночь с 7 на 8 октября был повреждён дата-центр в Сасово, его работу полностью остановили. 9 октября пострадала площадка в Калуге, где вышла из строя часть инфраструктуры. 11 октября Яндекс сообщил об остановке дата-центра во Владимире после новой атаки. По сообщениям компании, сотрудники этих площадок не пострадали.
Здесь уже есть существенная поправка к пересказам: три атакованные площадки не означают три полностью уничтоженных дата-центра. Работа может остановиться из-за повреждения электроснабжения, охлаждения или связи, даже если часть серверов сохранилась. И наоборот, внешне целое здание ещё ничего не говорит о работоспособности оборудования внутри. Полной публичной картины повреждений пока нет.
При этом последствия вполне реальные. Yandex Cloud, облачная платформа компании, прямо назвала режим работы аварийным и рекомендовала клиентам задействовать альтернативные площадки для восстановления. В опубликованных 13 октября рекомендациях компания всё ещё не называла сроки полного восстановления сервисов. Так что рассказывать, будто всё происходящее существует только в панических заголовках, тоже было бы странно.
Почему проблемы одной компании ощущаются как проблемы всего интернета? Потому что Яндекс давно обслуживает гораздо больше, чем собственный поиск.
Дата-центр представляет собой комплекс с серверами, системами хранения, электропитанием, охлаждением и связью. На этих серверах работают программы, которые принимают ваши заказы, показывают документы, рассчитывают маршруты и проводят другие операции. Часть оборудования Яндекс использует для своих сервисов, а часть предоставляет другим компаниям через Yandex Cloud. Бизнес арендует вычислительные ресурсы вместо того, чтобы покупать и обслуживать собственные серверы.
По итогам первого полугодия 2026 года у Yandex Cloud было около 64 тысяч клиентов. Это не значит, что все они одновременно перестали работать. Но масштаб зависимости становится понятнее: проблемы облака могут затронуть множество компаний, на вывесках которых вообще нет слова «Яндекс».
Допустим, интернет-магазин хранит в таком облаке базу заказов. Его главная страница может открываться, фотографии товаров могут загружаться, а оформить покупку уже не получится. У другого сервиса работает всё, кроме входа через стороннюю систему авторизации. Третий не может обратиться к нужному хранилищу. Пользователь видит несколько сломавшихся приложений подряд и вполне естественно говорит: «Что-то интернет сегодня не работает».
Технически связь при этом может сохраняться. Провайдер продолжает передавать данные, другие сайты доступны, сообщения доходят. Но человеку, который не может получить заказ или воспользоваться рабочим сервисом, от этого разграничения не сильно легче.
А сколько у Яндекса вообще дата-центров? Здесь даже с подсчётом есть нюанс. В новостях часто встречается цифра пять. Она действительно фигурирует в публичных описаниях инфраструктуры компании. Однако в марте 2026 года Яндекс объявил о вводе новой зоны доступности на базе ещё одного полноценного дата-центра. Если учитывать этот комплекс отдельно от прежних пяти, по опубликованным сообщениям получается шесть.
При этом количество дата-центров всей компании и количество зон её облачной платформы считать одним и тем же нельзя. Зона доступности описывает отдельную часть облачной инфраструктуры, в которой клиент размещает свои ресурсы. Это не универсальная единица измерения всего хозяйства Яндекса.
Но даже точная цифра не позволит посчитать ущерб простым делением. Шесть дата-центров не обязательно дают шесть одинаковых долей мощности. У площадок могут различаться размер, оборудование, фактическая загрузка и задачи. Потерять половину зданий не обязательно означает потерять половину вычислений. А сохранение половины вычислений ещё не гарантирует, что на них можно немедленно запустить всё остальное.
Удобная арифметика «три из пяти, значит, осталось 40% Яндекса» заканчивается примерно там, где начинается устройство настоящей системы.
Но ведь у них должны быть резервы. Почему тогда вообще что-то падает? Резервирование всегда рассчитывают на определённые неисправности. Сервер может пережить отказ диска, приложение может пережить отказ сервера, а распределённая система может пережить недоступность целой площадки. Это разные уровни защиты.
Яндекс публично рассказывал о принципе «минус один дата-центр»: собственные сервисы распределяют так, чтобы они сохраняли работоспособность при потере одной площадки. Для проверки проводят учения с отключением дата-центров от внешнего мира. Но способность пережить одну такую аварию не означает возможность без последствий пережить несколько подряд.
Вот условный пример, который не описывает реальные мощности Яндекса. Есть три одинаковые площадки, каждая загружена на 60%. Одна отключилась, её работу поровну распределили между двумя оставшимися. Теперь они загружены примерно на 90%. Система продолжает работать, но свободного места почти не осталось. Если до восстановления первой площадки отключается ещё одна, последней достаётся нагрузка на 180% её возможностей. Отправить её туда технически можно. Убедить оборудование обработать её целиком уже сложнее.
Именно поэтому после первого сбоя система может выглядеть почти здоровой, хотя запас прочности уже потрачен. Следующая авария происходит в гораздо менее благоприятных условиях.
Есть ещё одна тонкость. Некоторые распределённые базы данных должны согласовывать изменения между несколькими копиями. Если доступных участников становится недостаточно, система может остановить запись, чтобы не получить противоречивые данные. Поэтому ситуация «информация сохранилась, но пользоваться сервисом полностью нельзя» вполне возможна.
Например, увидеть остаток на счёте и безопасно провести новую операцию для программы представляют собой разные задачи. Наличие читаемой копии ещё не решает вторую.
А резервная копия почему не помогает всё быстро включить? Она помогает восстановиться, но сама по себе работающим сервисом не является.
Полезно различать три вещи. Реплика хранит актуальную копию данных и получает изменения по мере работы системы. Бэкап сохраняет состояние на определённый момент, к которому можно вернуться после повреждения или удаления информации. А запас вычислительной мощности позволяет где-то запустить программы, которые будут с этими данными работать.
Можно иметь хорошую резервную копию и не иметь свободного сервера нужного размера. Можно иметь сервер, но ещё несколько часов переносить на него данные. Можно перенести данные и обнаружить, что для запуска приложения нужны дополнительные настройки, доступы и другие сервисы. А после запуска ещё требуется проверить, что система работает правильно.
К тому же реплика и бэкап защищают от разных неприятностей. Если программа ошибочно удалила записи, реплика может послушно повторить удаление. Тогда пригодится сохранённая версия до ошибки. Если пропала площадка, полезна доступная копия в другом месте. Слово «резервирование» одно, а задач под ним довольно много.
Поэтому фраза «ну у них же есть бэкап» примерно так же описывает восстановление бизнеса, как «у меня есть чемодан» описывает готовность к переезду. Важная часть действительно имеется. Остальное ещё предстоит организовать.
Что в такой ситуации делают инженеры? Восстановление идёт одновременно по нескольким направлениям.
На повреждённой площадке сначала нужно обеспечить безопасность, оценить состояние инженерных систем и оборудования. Подать питание обратно недостаточно: необходимо понимать, что его можно подавать, что охлаждение работает и что повторное включение не создаст новых проблем.
Параллельно команды сервисов используют сохранившиеся ресурсы. Где-то переключают работу на готовые копии, где-то разворачивают системы из резервных данных. Проверяют согласованность информации, восстанавливают связи между компонентами и постепенно возвращают нагрузку. Часть функций при этом может временно оставаться отключённой.
Это объясняет, почему сервисы возвращаются не одновременно. Один уже открывается, другой позволяет только посмотреть данные, третий работает медленно, четвёртый пока недоступен. Даже у одного приложения разные действия могут восстанавливаться в разное время.
В текущей ситуации Yandex Cloud ограничивала выделение дополнительных ресурсов и рекомендовала использовать внешние площадки. В рекомендациях есть способы переноса данных и восстановления систем. Это хороший пример того, что «облачные мощности» в конце концов упираются в вполне физические компьютеры. Кнопка создания сервера не производит процессоры.
Причём возвращение приложения в строй и восстановление повреждённого дата-центра могут происходить в совершенно разные сроки. Сервис можно запустить на другой площадке раньше окончания ремонта. А потом ещё потребуется вернуть ему нормальную производительность и резервирование. Сообщение «всё снова открывается» не обязательно означает, что система уже вернулась к прежней устойчивости.
Можно ли из всего этого сделать вывод, что пользовательские данные потеряны? Нет, по одной недоступности сервиса такой вывод сделать нельзя. Но и обещать сохранность абсолютно всей информации всех клиентов без результатов проверок было бы нечестно.
Для разных данных используются разные способы хранения и защиты. Например, 11 октября руководство финтех-направления Яндекса сообщило, что записи о счетах хранятся в нескольких копиях на разных площадках, их целостность проверили и потерь записей не обнаружили. Это заявление относится к конкретным данным конкретного направления. Автоматически распространять его на каждый файл, каждую базу и каждый клиентский проект нельзя.
У клиентов облака многое зависит ещё и от того, как они построили свои системы. Если компания разместила приложение только в одной зоне и не подготовила восстановление, сам факт аренды ресурсов у крупного провайдера не создаёт ей автоматически вторую работающую копию бизнеса.
Теперь к главному: сколько дата-центров должно отключиться, чтобы «лёг Рунет»? Такого универсального числа нет.
Рунет не хранится целиком у Яндекса. Интернет состоит из множества соединённых сетей разных операторов. Поверх них работают сайты, приложения и облачные платформы. Поэтому серьёзный сбой одного провайдера вычислений может нарушить работу огромного количества сервисов, но из этого не следует автоматическое отключение всех остальных сетей и ресурсов.
Для оценки действительно масштабной потери связи важны работа операторов, доступность маршрутов передачи данных, электроснабжение, системы доменных имён и наличие альтернативных соединений. Массовые перебои возможны из-за крупных аварий, ошибок программного обеспечения, неправильных настроек или административных ограничений. Считать их вероятность по числу повреждённых серверных зданий бессмысленно.
У нас уже был наглядный пример. 30 января 2024 года множество пользователей столкнулось с недоступностью сайтов в зоне .ru. Координационный центр связал произошедшее со сбоем в механизме DNSSEC, который защищает систему доменных имён. Если совсем просто, возникла проблема с проверкой адресов сайтов. Для столь заметного сбоя не потребовалось физического уничтожения дата-центров.
Обратная ситуация тоже возможна: связь между сетями сохраняется, но многие привычные сервисы недоступны из-за проблем с их вычислительной инфраструктурой. В повседневной речи обе ситуации назовут «интернет упал», хотя причины, последствия и способы восстановления будут разными.
Распределённость интернета помогает переживать неисправности. Но она не делает его неуязвимым. Если много компаний пользуется одной и той же платформой, её проблемы расходятся далеко за пределы её собственного приложения. Чем больше таких общих зависимостей, тем заметнее последствия одного крупного инцидента.
Поэтому я бы не подписывался ни под «Рунету конец», ни под «обычный сбой, чего вы переживаете». Для Яндекса и части его клиентов это серьёзный кризис: потеря доступных мощностей, простой, расходы на восстановление и работа с уменьшенным резервом. Для людей за этим стоят вполне конкретные сорванные заказы, недоступные документы и остановившиеся рабочие процессы.
А вот прогноз о скором исчезновении всего российского интернета требует совсем других доказательств. Их нельзя заменить подсчётом дата-центров.
Больше разборов про технологии и то, как они влияют на нашу жизнь, в «Пост Завтра». Подписывайтесь пожааалуйста
Источники и подробности
«Коммерсантъ»: что известно об атаке на дата-центр во Владимире. Хронология событий, сообщения компании и последствия для сервисов.
РБК: постепенное восстановление сервисов Яндекса. Какие функции возвращались к работе и почему ограничения сохранялись.
«Коммерсантъ»: последствия атак для облачного рынка. Нехватка вычислительных мощностей, перенос клиентских систем и сложности восстановления.
РБК: последствия сбоев для бизнеса и самозанятых. Пример того, как проблемы инфраструктуры затрагивают сторонние рабочие процессы.
РБК: причина массового сбоя Рунета 30 января 2024 года. Тот самый случай с DNSSEC, когда массовая недоступность сайтов возникла без уничтожения дата-центров.












