Чужое здание

В начале октября у крупного облачного провайдера за 4 дня одна за другой вышли из строя 3 площадки: пожары, вызванные внешними факторами, остановили 2 дата-центра целиком, третий повредили частично. После первой ночи сам провайдер почти не почувствовал потери — его сервисы ушли в соседние площадки. А десятки его клиентов — банки, операторы связи, ритейл, госсервисы — лежали большую часть дня. К 4-му дню сбои дошли и до сервисов самого провайдера, причём не только в его стране.

Одно облако, одна ночь, два исхода, а через 4 дня — третий. Разница была не в провайдере, а в решениях, которые каждый принял задолго до этих дней. И это та же картина, которую мы видим в разговорах о размещении последние годы: облако, колокейшн и аренда считаются надёжными по умолчанию, потому что «там же Tier III и SLA». В реестрах рисков при этом подробно расписаны наводнения и метеориты, а потеря одного конкретного здания не расписана вовсе.

Зоны доступности

Одна ночь, два исхода

Площадка остановлена целиком, сроков восстановления владелец не называет и не подтверждает, что её вообще удастся вернуть в строй. Основные сервисы самого провайдера продолжили работать. У клиентов, которые жили на этой площадке, сбои тянулись часами.

Почему так? Любое публичное облако делит ресурсы на два типа. Зональные — виртуальная машина и её диск — физически находятся в конкретном здании. Глобальные — облачная сеть, бакеты объектного хранилища — не привязаны к одной зоне, но живут внутри региона. Провайдер прямо пишет в документации: отказоустойчивость появляется, когда приложение развёрнуто сразу в нескольких зонах.

То есть облако даёт зоны, а разнести по ним систему — работа клиента. Провайдер строил свои сервисы с расчётом на потерю площадки и потерял одну из нескольких. Клиент, у которого всё в одной зоне, потерял единственную. В момент аварии облако у обоих было одно и то же. Различались решения, принятые годом или тремя раньше.

Однако через 4 дня картина изменилась. Когда из строя вышла уже третья площадка, сбои начались и у тех, кто был разнесён по зонам, и у самого провайдера. Несколько зон защищают от независимых отказов: пожара в одном здании, аварии на одной подстанции. От угрозы, которая действует на все здания региона сразу, они не защищают — для неё домен отказа уже не здание, а регион и сам провайдер. Это и есть верхние уровни пирамиды, которые принято считать «концом света»: на деле они наступили за 4 дня.

Чужое здание

Что на самом деле арендуется

«Облако» — удобное слово: в нём нет здания. А здание есть. У него есть адрес, крыша, вводы питания, кабельные трассы, соседи и владелец.

Пока всё работает, разницы между «моим» и «чужим» сервером не видно. Она проявляется в тот момент, когда звучит вопрос «когда поднимемся». Если сервер ваш, на вопрос «когда поднимемся» отвечает ваша команда. Если он в чужом здании — пресс-служба партнёра. В ту ночь один из пострадавших сервисов так и написал своим пользователям: «инцидент на объекте инфраструктурного партнёра». Больше ему сказать было нечего — он знал о происходящем ровно столько же, сколько его клиенты.

Если сервер ваш, на вопрос «когда поднимемся» отвечает ваша команда. Если он в чужом здании — пресс-служба партнёра.

В чужом здании вы не знаете, что стоит рядом, какие у площадки реальные вводы и на сколько часов топлива, в каком порядке после аварии будут поднимать клиентов и где в этой очереди вы. И вы не можете туда приехать.

Это не упрёк провайдерам: у хорошего провайдера всё это продумано. Однако продумано для его собственного бизнеса, а не для вашего, и в ночь аварии он в первую очередь спасает именно его. Никакой пункт договора не ускорит ответ на ваш вопрос.

Реестр рисков

Перевёрнутая пирамида

В реестрах рисков нередко тщательно расписаны наводнение — в городе на высоте около 500 метров над уровнем моря, — падение метеорита и катастрофы масштаба региона. Если вода дошла до машзала на такой высоте, клиентам уже не до платежей, и вопрос доступности сервиса теряет смысл вместе с самим бизнесом.

При этом в тех же реестрах колокейшн и облако по умолчанию считаются сверхнадёжными. Сценарий «здание провайдера перестало существовать» не рассматривается: риск передан провайдеру, у провайдера SLA, у SLA много девяток. Резервную копию в другой регион того же облака при этом не делают, а про DR речь не заходит вовсе.

Однако сколько бы страниц ни занимало SLA и сколько бы девяток в нём ни было, само по себе оно ничего не решает. Если ЦОД сгорел, простаивает и теряет клиентов ваш бизнес — прямо сейчас. Бизнес оператора к этому моменту уже пострадал, и ему есть чем заняться помимо ваших претензий. Получите ли вы что-то по SLA, а через суд — неустойку, это вопрос месяцев, а то и лет. И даже тогда компенсация считается в процентах от месячной платы за услугу и никак не связана ни с вашей выручкой, ни со штрафами регулятора, ни с репутацией. То есть риск не передан: передано право когда-нибудь получить небольшую часть его стоимости.

И ещё один сценарий, которого в реестрах не встречается совсем: оператор ЦОДа мог ошибиться сам. Ошибиться в расчёте дизелей — мощности, запуска, работы под реальной нагрузкой. Ошибиться в расчёте живучести без внешнего питания — запаса топлива, подвоза, охлаждения на автономном режиме. Ошибиться в расчёте общей устойчивости площадки к катастрофическим воздействиям — пожару, повреждению конструкций, разнесению вводов и трасс. Эти расчёты принимаются на веру по сертификату Tier, хотя сертификат подтверждает проект и построенный объект, а не поведение площадки в аварии, которую при проектировании никто не рассматривал.

Нижние уровни пирамиды закрыты техникой, верхние — расписаны в документах. Выпадает середина: ошибка в расчётах оператора, потеря одного конкретного здания и потеря доступа к нему. А это ровно тот уровень, где у организации ещё есть бизнес, клиенты и обязательства и где архитектура решает, будет простой длиться минуты или недели.

Облако, колокейшн, аренда, свой ЦОД

Разумная пирамида: четыре модели размещения

Если разложить риски по частоте и посмотреть, кто закрывает каждый уровень, картина для четырёх моделей размещения выглядит так, как на рисунке 3.

Публичное облако. Здание, железо, гипервизор и сеть внутри площадки — на провайдере. На вас — распределение по зонам, копии, ключи, адреса и план выхода. Парадокс в том, что второе здание в облаке ближе всего — в той же консоли, — и именно в облаке им пользуются реже всего.

Колокейшн. Здание, питание, охлаждение и охрана — на операторе. Железо, ЗИП, ПО и каналы — ваши. Оборудование ваше и его можно вывезти, но доступ на площадку — по правилам оператора.

Аренда bare metal. Чужое железо в чужом здании. Замена неисправного — по SLA арендодателя, поколение — то, что у него на складе. Лицензии, данные и архитектура — ваши. По рискам это колокейшн, где вывезти нечего.

Собственный ЦОД. Всё ваше, включая инженерные системы и людей, которые их обслуживают. Однако одна своя площадка — тот же единый домен отказа, что и одна зона в облаке.

Три уровня остаются на вас при любой модели. Первый — ошибка, неудачное изменение и шифровальщик: от них защищают копии и регламенты, а не здание. Второй и третий — потеря здания и потеря города: от них защищает только другое здание, вопрос лишь в том, как далеко оно стоит. Модель размещения решает, кто будет чинить диски и кондиционеры. Кто будет поднимать систему в другом месте — решаете вы.

Модель размещения решает, кто будет чинить диски и кондиционеры. Кто будет поднимать систему в другом месте — решаете вы.

Разумная пирамида для конкретной организации строится по пяти правилам:

• уровни идут снизу вверх по частоте, а не по зрелищности: отказ диска в большом парке — рутина, ошибка или шифровальщик — вопрос нескольких лет, потеря здания — событие редкое, но на горизонте десятилетия уже не теоретическое;
• для каждого уровня записано, кто его закрывает, — по договору, а не по ощущению;
• расчёты оператора — дизели, автономность, устойчивость площадки — проверяются, а не принимаются на веру по сертификату;
• у уровней, где закрывающий — вы, есть владелец, бюджет и проверка;
• уровни выше потери города не планируются, а фиксируются одной строкой как принятый риск.

Если в реестре потеря чужого здания отмечена как «передано провайдеру», стоит открыть договор. Как правило, там будет компенсация в процентах от месячного счёта — через месяцы, а не в ту ночь, когда стоит ваш бизнес.

Инвентаризация сервисов

Сначала — карта

Всё, о чём шла речь выше, упирается в то, что обычно пропускают: инвентаризацию. Не список серверов из таблицы закупок, а карту того, что на самом деле работает и от чего зависит. Пирамиду рисков не построить для парка, который никто не может перечислить.

Минимальный состав такой карты:

• оборудование и ресурсы — где стоит, чьё, в каком здании и зоне, до какого числа на поддержке;
• сервисы — не системы, а то, чем пользуется клиент или сотрудник: оплата, вход в приложение, выдача кредита, отчётность;
• связи — какие базы, очереди, внешние API, DNS, сертификаты и чужие облака нужны каждому сервису, чтобы он работал;
• домены отказа — для каждого сервиса отдельно: какое здание, какая зона, какой кластер и какой канал его кладут;
• внутренний SLA — сколько сервис может стоять и сколько данных можно потерять, RTO и RPO, согласованные с бизнесом, а не взятые по умолчанию;
• влияние на клиента — насколько простой именно этого сервиса бьёт по NPS и оттоку.

Последний столбец обычно пустует, хотя расставляет приоритеты именно он. Час простоя мобильного приложения и час простоя внутреннего портала стоят несопоставимо, а в реестре рисков они нередко записаны одной строкой «ИТ-инфраструктура». Если влияние каждого сервиса на клиента известно, видно, где вторая зона окупается за одну аварию, а где хватит копии и суток на восстановление.

Чаще всего встречается такая картина: внутренний SLA есть на уровне «всё 99.9%», зависимостей никто не рисовал, а домен отказа сервиса совпадает с доменом отказа самой слабой его зависимости. То есть сервис в трёх зонах, который ходит за авторизацией в одну зону, живёт в одной зоне.

Карта устаревает с каждым релизом и каждым новым подрядчиком, поэтому сверять её стоит при каждом изменении архитектуры и перед каждой учебной тревогой с переключением.

Сценарии потери площадки

Что может случиться со зданием

Хрестоматийный пример из телекома. Мобильный оператор, биллинг построен на совесть. Абоненты не лежат в одной базе — они разнесены по 7 базам первого уровня, онлайн-тарификации, и 5 базам второго уровня, где живут подключения и отключения услуг и периодические списания. Расчёт голосового и интернет-трафика вынесен в отдельные слои — по 2 десятка ВМ на 2 десятках хостов виртуализации. У каждой физической базы своя СХД.

То есть домены отказа нарезаны так, что любая проблема с железом задевает только часть абонентов. Так и было годами: что-то у кого-то не работало, но сказать, что сервис «отвалился» для значительной части абонентов, было нельзя.

Пока в один день не пришла беда с электропитанием всего здания. Питание упало, через минуту упало ещё раз — и всё. Осталось освещение, а серверной энергии не было.

Распределённая система, у которой все части в одном здании, поднимается не как распределённая, а как одна большая. Холодный старт десятков баз, массивов и сотен ВМ — это порядок запуска, проверки целостности и сверка между уровнями, и никакая распределённость его не ускоряет. Поэтапный возврат в работу до уровня около 70% занял больше 12 часов, оставшиеся 30% — ещё 2 дня. Плюс досчёт трафика задним числом.

Ошибки проектирования в привычном смысле здесь нет. Каждый уровень пирамиды ниже здания был закрыт образцово. Не было уровня выше — второго здания. Вся устойчивость оказалась внутри одного домена отказа, и в тот день он был один на всех.

Полная потеря питания и пожар — самые наглядные сценарии, но не единственные. Площадку можно потерять, даже если она физически цела.

• Пожар и тушение. Даже локальное возгорание приводит к обесточиванию зала. Газовое пожаротушение и последующее проветривание — это часы, вода от соседних помещений — ещё хуже.
• Питание всего объекта. Tier описывает инженерную систему внутри площадки. Он ничего не говорит о том, что будет, если площадка потеряет все вводы на сутки, а топлива, договоров на подвоз и мощности дизелей окажется меньше, чем рассчитывал оператор.
• Трассы. Площадка может работать, но быть отрезанной: несколько оптических линий до столицы нередко идут по одному коридору.
• Изъятие и владелец. Зал останавливают по делу соседа; площадку продают, оператор уходит с рынка — здание стоит, свет горит, но через 90 дней нужно съехать.

Tier III, на который часто ссылаются в коммерческих предложениях, — хороший уровень, но это свойство одного здания. Ни Tier III, ни Tier IV не обещают, что здание переживёт потерю самого себя: устойчивость на уровне здания даёт только второе здание.

Резервные копии и DR

Копия в той же зоне

После аварии чаще всего звучит вопрос: «А бэкапы где?» Ответ нередко неприятный: в той же зоне.

Лестница защиты в облаке та же, что на своих площадках (подробно — в выпуске 13 «Autosave mode=ON»), только каждая ступень включается и оплачивается отдельно, поэтому её легко пропустить. Что переживает каждая ступень — на рисунке 5.

Из того, что мы видим, большинство останавливается на второй ступени. Копию в другой регион не делают даже те, кто аккуратно копирует каждую ночь.

А копия — ещё не DR. Чтобы подняться в другом месте, кроме данных нужны:

• вычислительные ресурсы и квота на них — которую в день массовой аварии одновременно попросят все клиенты погасшей зоны;
• сеть, адреса и маршруты;
• секреты и ключи шифрования, которые не лежат в той же зоне;
• порядок запуска и человек, который его знает;
• проверка, что всё это работает, проведённая хотя бы раз.

Копия в другом регионе без всего остального — это восстановление за недели, а не за часы, и не то, что подразумевают, когда пишут в реестре «риск закрыт резервным копированием».

Внешние компоненты

Зависимости, которых нет на схеме

В ту ночь легли и те, у кого в погасшей зоне не было ни одной своей машины.

Современная страница или приложение собирается из десятков внешних кусков: скрипты аналитики, авторизация через внешнего провайдера, платёжные виджеты, карты, капча, библиотеки с внешних CDN, DNS у внешнего оператора. Если такой кусок подгружается синхронно и без таймаута, страница ждёт его до бесконечности.

На схемах эти зависимости обычно не рисуют, но для пользователя разницы нет: если главная страница не открылась, не работает весь сервис. Сюда же относятся партнёры, которые сами живут в облаке: платёжный шлюз, сервис рассылок, внешний скоринг. Вы могли разнести свои системы по трём площадкам, а ваш партнёр — нет.

Отдельный урок тех дней — граница между локализацией данных и локализацией сервиса. В соседней стране сервисы провайдера работали с ошибками, и пользователям объяснили: персональные данные хранятся в стране, но распределённая инфраструктура включает компоненты в разных странах, и сбой одного из них влияет на доступность сразу в нескольких. То есть требование хранить данные локально выполнено, а домен отказа всё равно лежит в чужом здании за границей. Если вашему регулятору важна локализация, стоит спросить и о ней: где живут не только данные, но и всё, без чего сервис не работает.

Что с этим делать: инвентаризировать внешние вызовы на критичном пути, ставить на каждый таймаут и деградацию («карта не загрузилась» вместо «страница не открылась») и спрашивать ключевых партнёров, где и как они размещены, ещё при заключении договора.

Аренда против покупки

Аренда «под ключ»: что остаётся на вас

Отдельная ветка того же вопроса — аренда серверов в коммерческом ЦОДе вместо покупки.

Один пример из Средней Азии. У заказчика две собственные площадки и основная мощность на гиперконвергентной платформе. На обсуждении у руководства прозвучало предложение: вместо закупки нового поколения арендовать серверы в коммерческом ЦОДе.

Предложение арендодателя на первый взгляд было аккуратным: сервер с большим объёмом памяти, площадка Tier III, поддержка 24/7. Однако при разборе заметная часть расходов в цену аренды не вошла.

• Лицензии остаются на вас. Модель BYOL: ОС, платформу виртуализации и всё остальное приносит клиент. Арендуемый сервер был на предыдущем поколении и с меньшим числом ядер, поэтому на каждый свой сервер требовалось от 1.3 до 2 арендованных. Лицензии, которые считаются по физическим ядрам, растут вместе с этим числом (подробно — в выпуске 08 «Строки и ядра»).
• Хранилище — отдельной строкой. В спецификации были только загрузочные диски, ни одного под данные.
• Канал — отдельно. В услугу входил внешний доступ ограниченной полосы. Репликация между своими площадками и арендованной требует собственного канала, и в предложение он не входит.
• Совместимость — ваша забота. Проверять сервер по списку совместимости платформы заказчику пришлось самому.
• Гибкость условная. Минимальный срок — 12 месяцев, предоплата за 6, развёртывание — от 5 рабочих дней при наличии оборудования на складе до 35 при его отсутствии. По сути это лизинг чужого оборудования, а не облако с оплатой по факту.
• Выход стоит денег. Перенос данных обратно, двойная работа в переходный период, переконфигурация сети.

И главное: аренда в одном коммерческом ЦОДе ничего не меняет в пирамиде. Это по-прежнему одно здание, только чужое.

Аренда не всегда хуже покупки: в выпуске 07 «Четыре контура» разобраны случаи, где она оправдана, — временная нагрузка, пилоты, вторая площадка под холодный резерв. Но сравнивать нужно полную стоимость на горизонте 3 лет, а не цену сервера в месяц.

Адреса, маршрут, люди

Кто управляет переездом

Если площадка потеряна, всё решает, насколько быстро вы окажетесь в другом месте.

Показательно, что уже на второй день провайдер договорился с несколькими другими облачными операторами об ускоренном переезде своих пострадавших клиентов. Это правильный шаг и лучший ответ на вопрос, нужна ли копия у другого провайдера. Только переезжать будут все сразу, и первым поедет тот, у кого копия уже там.

• Адреса. Если публичные адреса ваших сервисов принадлежат провайдеру, переезд означает смену адресов, DNS, сертификатов и настроек у всех внешних партнёров. Собственная PI-адресация и BGP позволяют увести трафик на другую площадку, не меняя адресов.
• Маршрут. Канал до резервной площадки должен существовать до аварии, а не заказываться после неё. В день массовой аварии операторы связи перенаправляют магистральный трафик, и оставшиеся узлы перегружаются у всех одновременно.
• Ёмкость. Подняться в другой зоне по требованию в тот же час захотят все клиенты погасшей зоны.
• Люди и порядок. Кто принимает решение о переключении, в каком порядке поднимаются системы, кто проверяет результат. Если этого нет на бумаге, это будут решать ночью в мессенджере.

Чек-лист

Что проверить у себя

Итог

Вместо вывода

Ни один из клиентов, лежавших в те дни, не выбирал «пусть у нас всё ляжет». Выбирали одну зону — дешевле, копии рядом — быстрее, адреса провайдера — так было из коробки. Вместе это долг из выпуска 12 «Долг и дефолт», и в те дни его предъявили к оплате сразу десяткам организаций.

Это не аргумент против облака и не за собственный ЦОД. Вопрос не в том, своё или чужое, и не в подробности SLA, а в том, сколько у вас зданий и сколько часов займёт переезд: в ночь аварии стоит ваш бизнес, а компенсация придёт потом — если придёт.

Ваш сервер — действительно ваш, если на вопросы из чек-листа вы отвечаете без звонка партнёру. Если нет — давайте разложим вашу пирамиду вместе.