Материал 01
Дата-центр — это не адрес, а сумма инженерных решений
Когда выбирают площадку для серверов, чаще всего смотрят на цену и близость к городу. Но надёжность складывается из десятков менее заметных деталей — от схемы электропитания до того, как ведётся журнал инцидентов.
Схема электропитания — первый критерий, который стоит уточнять прямо, а не догадываться по буклету. N+1 означает один резервный узел на группу систем, 2N — полное дублирование каждого элемента вплоть до независимых вводов. Разница ощущается только во время аварии, поэтому продавец редко объясняет её добровольно. Стоит спросить, сколько раз за год отключалось основное питание и как долго держались генераторы.
PUE — отношение общего энергопотребления дата-центра к энергии, которая реально уходит на вычисления; значение ближе к единице говорит об эффективном охлаждении. Типичная ошибка — выбирать плотность стойки, не спросив, справится ли система охлаждения с нагрузкой именно в этом зале. Горячие и холодные коридоры, изоляция потоков воздуха и точки замера температуры — вопросы, которые стоит задать до подписания договора.
Полезно попросить не маркетинговый сертификат, а журнал инцидентов за последний год: сколько было простоев, что стало причиной, сколько заняло восстановление. Независимый аудит инженерной инфраструктуры говорит больше, чем самостоятельно присвоенный уровень надёжности. Если площадка отказывается показывать историю обслуживания — это тоже информация, просто её нужно уметь читать между строк документа.
Коротко о главном- N+1 и 2N — разные уровни резервирования электропитания, и разница видна только при аварии
- PUE и организация воздушных потоков влияют на стабильность стойки не меньше, чем цена аренды
- История инцидентов и независимый аудит информативнее рекламных сертификатов
Материал 02
Почему миллисекунды важнее мегабит
Провайдеры любят говорить о скорости канала, но для реального пользователя решает не пропускная способность, а то, сколько времени пакет идёт до цели и обратно.
Задержка складывается не только из расстояния, но и из числа автономных систем, через которые проходит трафик. Пиринговые соглашения между сетями определяют, пойдёт ли пакет коротким путём или сделает крюк через несколько транзитных операторов. Проверить это можно трассировкой маршрута из разных регионов — если путь выглядит нелогично длинным, стоит спросить провайдера о его пиринговой политике, а не о скорости порта.
Типичная ошибка — сравнивать тарифы по гигабитам в секунду, не учитывая, где физически расположены точки присутствия сети. Anycast и распределённые узлы CDN сокращают задержку за счёт того, что запрос обслуживается ближайшей копией контента, а не центральным сервером. Для сайта с аудиторией в нескольких странах это часто значит больше, чем удвоение полосы пропускания на одном канале.
Прежде чем менять провайдера, полезно снять базовые метрики: задержку, потери пакетов и джиттер в течение недели, а не одного теста в момент низкой нагрузки. Разница между дневными и ночными показателями расскажет об уровне перегрузки сети больше, чем любой график. Такие замеры стоит повторить после смены поставщика, чтобы сравнение было честным, а не основанным на разовом впечатлении.
Коротко о главном- Число транзитных сетей на пути пакета часто влияет на задержку сильнее, чем ширина канала
- Anycast и узлы CDN снижают задержку за счёт географической близости, а не скорости порта
- Замеры задержки и потерь пакетов нужно вести регулярно, а не по одному тесту
Материал 03
Резервная копия, которую никто не пробовал восстановить, — не резервная копия
О бэкапах вспоминают в момент отказа, а не при настройке. Разница между «копия существует» и «копия работает» становится заметна именно тогда, когда откладывать уже нельзя.
RAID защищает от отказа диска, но не от ошибки администратора или шифровальщика, который повредит данные на всех томах одновременно. Правило трёх копий на двух типах носителей с одной копией вне основной площадки остаётся рабочим ориентиром именно потому, что учитывает разные сценарии отказа, а не только поломку железа. Путать резервирование дисков с резервным копированием — распространённая и дорогая ошибка.
Версионность копий важна не меньше их количества: если ошибка обнаружена через две недели, а хранится только последняя версия, восстанавливать уже нечего. Ещё чаще встречается ошибка иного рода — бэкапы настроены и годами запускаются по расписанию, но процедуру восстановления ни разу не проверяли на практике. Именно во время реальной аварии выясняется, что архив повреждён или процесс занимает не часы, а дни.
Стоит завести регулярную процедуру тестового восстановления — не реже раза в квартал — и фиксировать время, которое на это уходит. Полезно также хранить копию конфигурации и документацию по развёртыванию отдельно от данных, потому что восстановленный диск бесполезен, если забыт порядок настройки сервисов. Такой план стоит проверять на новом оборудовании, а не только на исходном сервере.
Коротко о главном- RAID и резервное копирование решают разные задачи и не заменяют друг друга
- Версионность копий важна не меньше их количества и частоты
- Тестовое восстановление раз в квартал — способ узнать, что бэкап действительно рабочий
