Начните готовиться сейчас к следующему сбою облака

Крупные инциденты в облаке, подобные тому, который произошел на этой неделе с AWS, неизбежны. Четыре метода, которые могут помочь вашей компании пережить это.

С учетом бесчисленных часов потерянной производительности, финансовые системы были нарушены для миллионов пользователей, и потенциально сотни миллиардов долларов были потеряны, сбой AWS на этой неделе стал поистине ужасным днем для глобальных команд ИТ. Конечно, это также был худший глобальный сбой облака с последнего…и до следующего.

Независимо от того, используете ли вы AWS, GCP, Azure или любую другую платформу, крупные сбои являются данностью реальности облачного вычисления. Итак, что может сделать ваша компания, чтобы смягчить удар? Ниже я предложу четыре шага, которые ваша команда может предпринять немедленно.

Привнесите свой скептицизм – и сделайте домашнее задание.

Часто команды идут на катастрофу, входя в облачные соглашения, предполагая, что крупные облачные корпорации по своей природе надежны. Безусловно, наиболее заслуживающие доверия компании заслужили свою репутацию по какой-то причине. В то же время каждый облачный и гипермасштабный поставщик предлагает широкий спектр вариантов инфраструктуры – только в Северной Америке AWS имеет 31 зону доступности и 31 местоположение сети Edge – и некоторые варианты намного более надежны, чем другие.

Действительно, регион US-EAST-1 AWS, который стал причиной сбоя на этой неделе, был за крупные сбои в 2020, 2021 и 2023 годах, и было давно известно в определенных ИТ-кругах как наименее надежный регион. Многие компании, вероятно, понимали ситуацию, но приняли рассчитанный риск, учитывая низкую стоимость и обильные предложения региона. Но учитывая масштаб сбоя, невозможно не задуматься, сколько компаний было полностью удивлено – и, безусловно, выбрало бы более надежные регионы, если бы они были осведомлены о компромиссах. Я лично встречал ИТ-руководителей, которые решили перейти в другие регионы AWS только после плохого опыта с US-EAST-1 в прошлом.

Урок здесь заключается в том, чтобы сделать домашнее задание, когда речь идет об облачных вариантах инфраструктуры, независимо от того, какой облачный сервис вы используете. Места для начала включают бесплатные инструменты, такие как cloudprice, Cloudping и исторические представления инцидентов из инструментов Cloud Service Health, предоставляемых гипермасштабными поставщиками.

Выберите портативный вместо облачного.

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

Чтобы избежать дополнительного слоя облачной зависимости, выберите независимые и/или открытые продукты, где это возможно. Некоторые примеры замены включают следующие:

Чтобы быть уверенным, построение большей части вашей облачной стека с нуля означает больше работы для ваших команд. Однако, по моему опыту, как только вы запустите инфраструктуру, между добавлением рабочей нагрузки в устоявшуюся домашнюю инфраструктуру и работой на облачной нет практически никакой разницы. И преимущества в плане устойчивости – не говоря уже о снижении облачного замка – делают независимые варианты очень ценными.

Инженерия для сбоя.

Учитывая, что сбои в облаке будут происходить, обязательно проектируйте свои продукты с учетом сбоя в облаке. Одним из примеров является Datadog: в 2023 году компания внезапно потеряла доступ к более чем половине своих узлов Kubernetes в производстве и полностью переработала свой подход к катастрофам в ответ. Изменения включали удаление архитектурных узких мест и решение технического долга, чтобы частичные сбои не распространялись по системе, улучшение ингестии и хранения данных для большей доступности данных во время сбоев, и построение систем для автоматического восстановления в масштабе. Одним из отличных мест для начала является следование рекомендации Datadog «начать с того, что важно для конечного пользователя», и построить системы безопасности для защиты того, что имеет наибольшее значение.

Запускать на как минимум двух облаках.

Конечно, лучший способ не быть зависимым от сбоев в облаке – это мультиоблачная избыточность. Достижение истинной мультиоблачной гибкости – это огромное начинание для многих компаний, поскольку очень сложно перевести инфраструктуру из одного облака в другое. Но построение инфраструктуры как минимум на двух облаках – это сильное и часто осуществимое место для начала. Критически важным для того, чтобы это сработало, является наличие команды с экспертом в каждом из облаков, на которых вы работаете.

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