Amazon Web Services отключились в прошлый вторник. Это случается не часто, но когда это происходит, это мучительный опыт.

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

Так что же нам делать?

Есть много вариантов:

  • Используйте другой облачный сервис
  • Переходите на мультиоблачную среду
  • Переходите на несколько регионов в AWS
  • Работайте локально (используйте собственный центр обработки данных или цвет)
  • Ничего не делать

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

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

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

Повсеместные отключения AWS случаются не так часто. Каждый год может быть какое-то событие, но оно будет со служением здесь или там. Даже в прошлом EC2 и RDS работали все время. Лаборатория в моей повседневной работе никак не пострадала. Eight One Books никак не пострадал. Dynomantle, активно использующий S3, пострадал только во второй половине сбоя.

Перебои в работе AWS заметны. Это из-за того, как много крупных сервисов их используют. Хотя это не обязательно плохо. AWS не может скрыть свои сбои из-за их размера. Даже если они своевременно не обновляют свою страницу статуса, все знают, когда они выходят из строя.

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

Я определенно сталкивался с тем, что облачный провайдер отключался и притворялся, что это не так (ПРИМЕЧАНИЕ: это был не Google Cloud). Сбой был локализован для нескольких сервисов, и они не были такими большими, как AWS, поэтому они просто незаметно исправили его через некоторое время. Тем не менее, за это время мы с моей командой сошли с ума, пытаясь понять, в чем дело. Мы прочесали все наши конфигурации и код, думая, что это мы, когда это не так.

Я не говорю, что AWS полон святых. Я говорю, что их размер означает, что они не могут спрятаться, даже если бы захотели. Это особенность.

Стратегии с несколькими облаками и несколькими регионами также являются очень действенными стратегиями. Однако это не бесплатные стратегии. Нет флажка, чтобы мгновенно дать вам это. Чтобы сделать это правильно, нужно много времени. В каждом облаке есть затраты на передачу данных. AWS взимает плату за перемещение между регионами. Запуск параллельной инфраструктуры также может стать дорогостоящим.

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

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

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

Стратегия on-prem… ну, у меня есть некоторые личные травмы, поэтому у меня много предубеждений.

Забавная история для тех, кто думает о переходе на локальную версию после сбоя #AWS:

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

- Профессор Бекумс (@PBeekums) 7 декабря 2021 г.

Существует очень мало ситуаций, когда использование on-prem имеет смысл. Dropbox имеет смысл, потому что они предлагают хранилище по более низкой цене, чем S3. Гибридное облако имеет смысл, если у вас есть физический компонент вашего продукта, например склад или лаборатория.

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

Я мог бы начать перечислять все, о чем вам нужно позаботиться, например, космические лучи или убедиться, что внутри помещения не идет дождь. На каждого кто-то скажет: Это легко решить! Чёрт возьми, нуб.

Проблема не в том, что переход на prem ставит перед вами трудные задачи. Проблема заключается в количестве проблем, с которыми вам приходится сталкиваться при переходе на прем. Их буквально так много, что я сомневаюсь, что кто-то может знать их все. Я видел, как люди заявляли, что могут, и результаты были… прямо противоположными впечатляющим.

Вам понадобится команда. Большой. С хорошими оперативниками. За это очень хорошо платят.

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

Вы, конечно, можете попытаться получить удачу и не делать всю эту подготовку. Может быть, вы будете в порядке в течение нескольких лет. Но когда вы видите сбой, и вы увидите сбой, вы вряд ли сможете исправить его за 24–48 часов, как AWS. Вам повезет, если вы сможете исправить это за несколько недель.

Это подводит нас к варианту ничего не делать.

Для тех из нас, кто использует AWS, что мы делали во время этого сбоя?

Во время моего первого простоя AWS я пытался сделать совсем немного. Я лихорадочно пытался получить доступ ко всем нашим системам, но безрезультатно. Я постоянно прокручивал и обновлял страницу состояния AWS. Я не спал все это время, чтобы проверить все наши системы, когда вернется AWS. Это было более 10 лет назад.

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

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

Я никогда не сталкивался с отключением AWS, когда какое-либо из моих действий во время простоя действительно имело значение. Конечно, я проверяю работоспособность систем, но я никогда не видел, чтобы что-то не возвращалось в сеть нормально. Никогда не было потери или повреждения данных. Результатом моих действий было заставить меня чувствовать себя лучше, делая что-то. Хотя мне никогда не нужно ничего делать.

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

Конечно, если вы все время не работаете, вы потеряете клиентов. Но сколько клиентов вы на самом деле потеряете, если упадете на 1–2 дня каждые несколько лет?

Как вы думаете, сколько людей отписались от Netflix из-за сбоя AWS?

Как вы думаете, сколько людей перестанут ходить в McDonald’s из-за сбоя AWS?

Как вы думаете, сколько людей удалили Venmo из-за сбоя AWS?

Раньше World of Warcraft закрывался каждый вторник на техническое обслуживание в первые несколько лет после запуска. Этот продукт имел успех более 15 лет.

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

Увидимся при следующем отключении AWS.

Первоначально опубликовано на https://blog.professorbeekums.com.