Почніть підготовку зараз до наступної аварії в хмарі

Масштабні аварії в хмарі, як-от ті, що відбулися цього тижня з AWS, є невідворотними. Чотири методи, наведені нижче, можуть допомогти вашій компанії пережити це.

З безліччю годин втраченої продуктивності, фінансові системи були порушені для мільйонів користувачів, і потенційно сотні мільярдів доларів були втрачені, аварія цього тижня в AWS стала безумовно найгіршим днем для глобальних ІТ-команд. Очевидно, що це була також найгірша глобальна аварія в хмарі з останньої аварії…і до наступної.

Незалежно від того, чи працюєте ви з AWS, GCP, Azure або будь-якою іншою платформою, масштабні аварії є даністю реальності хмарних обчислень. Що ж можете зробити ваша компанія, щоб пом’якшити удар? Нижче я пропоную чотири кроки, які ваша команда може зробити негайно.

Принесіть свій скептицизм – і зробіть свою домашню роботу.

Часто команди йдуть на аварію, виходячи з того, що великі хмарні корпорації є внутрішньо надійними. Безумовно, найбільш довірені компанії заслужили свою репутацію за певних підстав. Однак кожна хмара та гіперсเกลер пропонує широкий спектр варіантів інфраструктури – лише в Північній Америці AWS має 31 зону доступності та 31 місце мережі краю – і деякі варіанти значно більш надійні, ніж інші.

Дійсно, регіон US-EAST-1 AWS, який став причиною аварії цього тижня, було причиною масштабних порушень у 2020, 2021 та 2023 роках, і було відомо в певних колах ІТ як найменше надійний регіон. Багато компаній, ймовірно, розуміли ситуацію, але прийняли обчислений ризик через низьку вартість регіону та численні пропозиції. Однак, враховуючи масштаб аварії, неможливо не подумати, скільки компаній були цілком несподівані – і, безумовно, обрали б більш надійні регіони, якби знали про компроміс.

Урок тут полягає в тому, щоб зробити свою домашню роботу щодо варіантів інфраструктури хмари, незалежно від того, з якою хмарою ви працюєте. Місця для початку включають безкоштовні інструменти, такі як cloudprice, Cloudping, і історичні огляди інцидентів з інструментів здоров’я хмари, наданих гіперскалерами.

Оберіть портативність над хмаро-родними.

Коли ви проектуєте конфігурації хмари, простішим шляхом є вибір хмаро-родних рішень. Однак, хоча це зручно вибирати програми, готові до використання та створені вашим постачальником хмари, ці хмаро-родні варіанти залишають вас більш вразливими, якщо ваша хмара виходить з ладу.

Щоб уникнути цього додаткового шару залежності від хмари, виберіть незалежні та/або відкриті продукти, де це можливо. Низка прикладів заміни наведена нижче:

Безумовно, побудова більшої частини вашої хмарної структури з нуля означає більше роботи для вашої команди. Однак, на мою думку, після того, як інфраструктура запущена, мало чи зовсім немає різниці між додаванням робочого навантаження до встановленої домашньої інфраструктури чи роботою на хмаро-родній. І переваги щодо стійкості – не кажучи вже про зменшення залежності від хмари – роблять незалежні варіанти дуже корисними.

Інженерія для відмови.

Ураховуючи, що аварії в хмарі будуть відбуватися, будьте певні, що проектуєте свої продукти з урахуванням аварій в хмарі. Одним з прикладів є Datadog: у 2023 році компанія раптово втратила доступ до більшої половини своїх вузлів Kubernetes у виробництві і повністю переробила свій підхід до аварій. Зміни включали видалення архітектурних瓶окоек та вирішення технічних боргів, щоб часткові відмови не розповсюджувалися через систему, покращення прийому та зберігання даних для підвищення доступності даних під час аварій, а також побудову систем для автоматичного відновлення у масштабі. Одним з чудових місць для початку вашої подорожі є слідування рекомендації Datadog «починати з того, що важливо для кінцевого користувача», і побудувати засоби безпеки для захисту того, що найважливіше.

Запускайте на щонайменше двох хмарах.

Безумовно, найкращим способом не бути залежним від аварій в хмарі є резервування в декількох хмарах. Досягнення справжньої багатократної гнучкості є величезним завданням для багатьох компаній, оскільки це дуже важко перекласти інфраструктуру з однієї хмари в іншу. Однак побудова інфраструктури щонайменше на двох хмарах є сильним – і часто здійсненним – місцем для початку. Критично важливо мати команду з експертами в кожній з хмар, на яких ви працюєте.

Безумовно, нічого не може повністю захистити компанії від впливу масштабної аварії, як-от тієї, яку ми бачили цього тижня. Однак з правильною ретельністю, підходом, портативним для хмари, інженерією для відмови та використанням «двох хмар» як ступеньки до справжньої багатократності, компанії можуть бути значно більш рухливими, коли наступна (і, на жаль, неминуча) велика аварія в хмарі трапиться.