Риски при работе с облаком
Даже если ваш сервис либо система полностью отвечают принципам Cloud Native-приложений, а вы выбрали наиболее подходящего провайдера и выполнили миграцию в облако с учетом всех технических рекомендаций, это еще не значит что теперь сервисам ничего не угрожает. Риски существуют всегда, и эти риски можно условно разделить на 3 группы.
1. Географические риски
Даже самый надежный провайдер не застрахован от разнообразных чрезвычайных ситуаций: стихийных бедствий, аварий техногенного характера, пожаров и наводнений.
Достаточно вспомнить пожар в Москве в дата-центре OST в 2019 году (провайдер DataLine) — тогда успели оперативно перевести всех клиентов на резервные площадки. Или же пожар в дата-центре SBG2 (провайдер OVH, Страсбург), что привело к падению множества сервисов во всем мире из-за полного уничтожения одного ЦОДа и вынужденной остановки второго, находившегося рядом и тоже частично поврежденного пожаром.
Исходя из вышеописанных случаев, крайне важно для провайдера иметь несколько ЦОДов, причем эти ЦОДы должны быть не только удалены друг от друга, но и питаться от разных электростанций (если они рядом, ЦОДы не страхуют друг друга, а оказываются под угрозой сразу все).
Просто обращайте на это внимание при выборе провайдера.
2. Government-риски
Иногда в стране принимаются законодательные и политические решения, которые могут привести к резкой смене провайдера. Например, в 2021 забанили социальную сеть Parler, а Amazon отказал данной платформе в хранении данных -- в итоге приложение стало, по сути, недоступным. Что касается России, то здесь можно вспомнить 152-ФЗ (закон, запрещающий хранить персональные данные за пределами РФ), что по факту ограничивает выбор провайдеров некоторым организациям, относящимся к банковскому сектору, медицине и т. д.
Неприятность Government-рисков в том и заключается, что выход таких законопроектов, как и принятие соответствующих политических решений, чаще всего требует оперативной реакции, следовательно, очень важно быть всегда готовым к незапланированной смене своего провайдера.
3. Проблемы на стороне провайдера
Технические сбои возможны и на уровне провайдера, что может быть связано, к примеру, с пресловутым человеческим фактором, неверным обновлением, ошибками в прогнозировании ресурсов и т. д. И такое случается даже у лидирующих мировых провайдеров: Amazon и Google, где тоже периодически отмечаются сбои в сервисах. В том же Google Cloud в год происходит до 100 инцидентов, а в AWS существенные сбои случаются не реже одного раза в год. Достаточно вспомнить крупный сбой у AWS в ноябре 2020 г., в результате чего наблюдались проблемы с работой многих приложений и сайтов, включая Roku, iRobot, Flickr, Adobe Spark.
Вывод
Таким образом, даже наиболее надежные облачные решения не являются полностью и абсолютно защищенными от человеческих ошибок и сбоев. Собственно говоря, никто на свете не может гарантировать 100%-ной доступности сервисов. Также стоит отметить, что любой надежный провайдер обязан обеспечивать заявленный уровень SLA, а также возмещать убытки в случае чего, однако при долгосрочных сбоях это вряд ли компенсирует потерю времени и потенциальных клиентов.
Что касается основной темы разговора, то влияние рисков первой группы достаточно легко нивелировать, выбрав провайдера с географически разнесенными ЦОДами. А вот когда мы говорим о рисках из 2-й и 3-й групп, то их минимизировать можно, лишь применяя Multicloud Native Service-подход. О нем поговорим в следующий раз.
По материалам блога https://habr.com/ru/company/vk/blog/.
