Когда сгорает «облако государства»

В Южной Корее случился цифровой апокалипсис: пожар в здании Национальной службы информационных ресурсов уничтожил всю ИТ-инфраструктуру страны.
647 государственных сервисов остановились, 96 из них уничтожены. В огне сгорели и данные, и резервные копии.

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

Мне кажется, что все сильно преувеличено — все-таки уже сейчас удалось восстановить работу 163 сервисов. Но давайте допустим, что все действительно так и подумаем, как можно было бы минимизировать последствия.

Случившееся — следствие неудачных архитектурных и управленческих решений, которые десятилетиями считались «удобными и дешевыми». Какие ошибки были допущены?

Одна площадка = одна точка отказа

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

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

Бэкап не спасение, если он где-то рядом

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

Правильный подход — 3-2-1:
3 копии данных;
2 разных носителя;
1 копия — вне основной площадки.

И всё это с регулярным тестированием восстановления. Если никто ни разу не попробовал поднять систему из бэкапа, то можно считать, что его просто нет. Потому что вообще неизвестно, поднимется ли из него что-то.

Безопасность воспринимается как тормоз, а не как часть продукта

В таком случае инфраструктура превращается в карточный домик. Сценарии аварийного восстановления (DRP), тесты отказоустойчивости, резервные регламенты, дежурные протоколы — все это должно быть не на бумажке для аудита, а реально отработанными практиками.

Отсутствие автоматизации

Система должна быть устроена так, чтобы человеческий фактор не решал, выживет ли инфраструктура. Например, если резервное копирование или переключение на резервный ЦОД зависит от ручного запуска инженером, то это не система, а сценарий надежды.

В зрелой архитектуре такие процессы автоматизированы: при выходе из строя площадки запускается автоматическое переключение на резервную, а бэкапы создаются по расписанию и проверяются независимо от людей.

Так строят инфраструктуру крупные провайдеры и операторы:

отказ площадки не требует героизма дежурной смены;
аварийные сценарии запускаются по заранее протестированным политикам;
ответственность распределена между ролями и системами.

#Оксана_объясни