Сбои в облачной инфре. На кого валить?

Недавний (очередной) сбой в Яндекс.Облаке намекнул мне на эту тему, в которой попробуем определить зоны ответственности и способы обезопасить себя.

🧨 Аварии случаются, не важно, облако это или сервер в датацентре. Произойти может что угодно: пожар, наводнение, прилет БПЛА, противоправные действия и т.д. Как говорит народная мудрость: There is no cloud, it is just someone's else computer.

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

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

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

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

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

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