Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-03-10

1 <p>Даже если ваш сервис либо система полностью отвечают<a>принципам Cloud Native-приложений</a>, а вы выбрали наиболее подходящего провайдера и выполнили миграцию в облако с учетом всех технических рекомендаций, это еще не значит что теперь сервисам ничего не угрожает. Риски существуют всегда, и эти риски можно условно разделить на 3 группы.</p>

2 <h2>1. Географические риски</h2>

3 <p>Даже самый надежный провайдер не застрахован от разнообразных чрезвычайных ситуаций: стихийных бедствий, аварий техногенного характера, пожаров и наводнений.</p>

4 <p>Достаточно вспомнить пожар в Москве в дата-центре OST в 2019 году (провайдер DataLine) - тогда успели оперативно перевести всех клиентов на резервные площадки. Или же пожар в дата-центре SBG2 (провайдер OVH, Страсбург), что привело к падению множества сервисов во всем мире из-за полного уничтожения одного ЦОДа и вынужденной остановки второго, находившегося рядом и тоже частично поврежденного пожаром.</p>

5 <p>Исходя из вышеописанных случаев, крайне важно для провайдера иметь несколько ЦОДов, причем эти ЦОДы должны быть не только удалены друг от друга, но и питаться от разных электростанций (если они рядом, ЦОДы не страхуют друг друга, а оказываются под угрозой сразу все).</p>

6 <p>Просто обращайте на это внимание при выборе провайдера.</p>

7 <h2>2. Government-риски</h2>

8 <p>Иногда в стране принимаются законодательные и политические решения, которые могут привести к резкой смене провайдера. Например, в 2021 забанили социальную сеть Parler, а Amazon отказал данной платформе в хранении данных -- в итоге приложение стало, по сути, недоступным. Что касается России, то здесь можно вспомнить 152-ФЗ (закон, запрещающий хранить персональные данные за пределами РФ), что по факту ограничивает выбор провайдеров некоторым организациям, относящимся к банковскому сектору, медицине и т. д.</p>

9 <p>Неприятность Government-рисков в том и заключается, что выход таких законопроектов, как и принятие соответствующих политических решений, чаще всего требует оперативной реакции, следовательно, очень важно быть всегда готовым к незапланированной смене своего провайдера.</p>

10 <h2>3. Проблемы на стороне провайдера</h2>

11 <p>Технические сбои возможны и на уровне провайдера, что может быть связано, к примеру, с пресловутым человеческим фактором, неверным обновлением, ошибками в прогнозировании ресурсов и т. д. И такое случается даже у лидирующих мировых провайдеров: Amazon и Google, где тоже периодически отмечаются сбои в сервисах. В том же Google Cloud в год происходит до 100 инцидентов, а в AWS существенные сбои случаются не реже одного раза в год. Достаточно вспомнить крупный сбой у AWS в ноябре 2020 г., в результате чего наблюдались проблемы с работой многих приложений и сайтов, включая Roku, iRobot, Flickr, Adobe Spark.</p>

12 <h2>Вывод</h2>

13 <p>Таким образом, даже наиболее надежные облачные решения не являются полностью и абсолютно защищенными от человеческих ошибок и сбоев. Собственно говоря, никто на свете не может гарантировать 100%-ной доступности сервисов. Также стоит отметить, что любой надежный провайдер обязан обеспечивать заявленный уровень SLA, а также возмещать убытки в случае чего, однако при долгосрочных сбоях это вряд ли компенсирует потерю времени и потенциальных клиентов.</p>

14 <p>Что касается основной темы разговора, то влияние рисков первой группы достаточно легко нивелировать, выбрав провайдера с географически разнесенными ЦОДами. А вот когда мы говорим о рисках из 2-й и 3-й групп, то их минимизировать можно, лишь применяя<strong>Multicloud Native Service-подход</strong>. О нем поговорим в следующий раз.</p>

15 <p><em>По материалам блога https://habr.com/ru/company/vk/blog/.</em></p>