Gagal Tanpa Jatuh

Posting ini ditulis oleh Adrian Cockcroft, VP of Cloud Architecture Strategy di AWS. Jika Anda ingin mempelajari lebih lanjut, dia akan menjadi pembicara di acara online AWS Chaos Engineering and Resiliency Series , yang berlangsung pada 27-28 Oktober dari pukul 11.00-14.00 di zona waktu AEDT.

Saya telah mengerjakan sistem yang tangguh selama bertahun-tahun. Pada 1990-an sebagai Distinguished Engineer di Sun Microsystems, saya membantu beberapa situs Internet pertama melalui masa pertumbuhan awal mereka dan bergabung dengan eBay pada tahun 2004 dengan judul Distinguished Availability Engineer. Pada tahun 2007 Netflix mempekerjakan saya untuk membantu mereka membangun layanan streaming video yang dapat diskalakan dan tangguh dan pada tahun 2010 saya memimpin transisi mereka ke arsitektur berbasis cloud di AWS. Selama sepuluh tahun terakhir, saya telah membangun dan berbicara tentang Chaos Engineering , arsitektur cloud multi-zona dan multi-region, dan praktik pengembangan modern.

Saat aplikasi bergerak online dan otomatisasi digital meluas untuk mengontrol lebih banyak dunia fisik di sekitar kita, kegagalan perangkat lunak berdampak semakin besar pada hasil bisnis dan keselamatan. Kami perlu mengembangkan sistem yang lebih tangguh, dan itu tidak dapat dibiarkan sebagai masalah operasional. Insinyur perlu merancang ketahanan ke dalam kode aplikasi, dan pengoperasian adalah salah satu atribut terpenting dari sistem yang tangguh. Pengalaman operator harus jelas dan responsif, terutama saat terjadi kegagalan. Kami telah melihat banyak contoh masalah awal kecil yang meningkat, karena kode dan prosedur penanganan kesalahan yang dirancang dan diuji dengan buruk gagal dengan cara yang memperbesar masalah, dan menghilangkan keseluruhan sistem.

Apa yang dapat kita lakukan tentang ini? Sebagai permulaan, adalah tanggung jawab bersama di seluruh tim teknis Anda untuk membangun dan mengoperasikan sistem yang dapat diamati, dikontrol, dan tangguh. Dengan integrasi peran dari praktik DevOps dan otomatisasi yang disediakan oleh penyedia cloud, kami perlu menyesuaikan konsep dan terminologi umum yang sudah ada dalam desain sistem yang tangguh untuk arsitektur cloud-native.

Apa yang harus dilakukan sistem Anda ketika sesuatu yang Anda andalkan gagal? Ada tiga hasil yang umum. Itu bisa berhenti sampai apa pun yang gagal dipulihkan; itu bisa mengatasi kegagalan dan melanjutkan dengan fungsionalitas yang berkurang; atau bisa jatuh dan menyebabkan kegagalan yang lebih besar! Sayangnya, untuk banyak sistem saat ini, hasil ketiga adalah default, baik karena mereka tidak dirancang untuk bertahan hidup atau, yang lebih kritis, mereka tidak diuji secara teratur untuk membuktikan bahwa solusi yang dirancang bekerja sebagaimana mestinya.

Ada banyak jenis kegagalan untuk dipikirkan, tetapi saya akan berkonsentrasi pada apa yang biasanya disebut pemulihan bencana atau kelangsungan bisnis. Banyak organisasi memiliki strategi pusat data cadangan dan rencana untuk mengalihkan ke cadangan jika ada kegagalan di pusat data utama mereka. Namun, ketika saya bertanya kepada orang-orang seberapa sering mereka menggunakan kemampuan aplikasi dari kegagalan, mereka biasanya terlihat malu. Banyak organisasi tidak pernah menguji failover, dan beberapa melakukannya hanya sebagai bagian dari proses audit tahunan yang memakan waktu dan menyakitkan. Pertanyaan saya berikutnya adalah apakah mereka pernah menarik steker di seluruh pusat data sekaligus, jadi semua aplikasi harus gagal bersama-sama. Kebanyakan orang merasa ngeri dengan gagasan untuk mencobanya sebagai ujian. Orang-orang yang menganggap ini serius telah mengalami hal itu ketika bencana yang sebenarnya menyebabkan kegagalan.

Saya menyebut keadaan ini “teater ketersediaan”. Anda telah melalui gerakannya dan memerankan skenario pemulihan bencana, tetapi meskipun menghabiskan banyak uang untuk produksi, itu tidak nyata. Yang Anda miliki adalah dongeng: “Dahulu kala, secara teori, jika semuanya berjalan dengan sempurna, kami memiliki rencana untuk bertahan dari bencana yang kami pikirkan sebelumnya.” Dalam praktiknya, ini lebih cenderung menjadi mimpi buruk.

Saat failover gagal

Uptime Institute mencatat informasi publik tentang pemadaman. Laporan mereka 2018-19 menyoroti tren: “Pemadaman besar yang direkam secara publik sekarang lebih mungkin disebabkan oleh TI dan masalah jaringan dibandingkan satu atau dua tahun yang lalu, ketika masalah daya adalah penyebab yang lebih besar. ” Cara kami mengembangkan dan mengoperasikan sistem sangat penting, jadi apa yang dapat kami lakukan untuk memperbaiki situasi? Untuk memulai, kita harus belajar dari orang-orang yang telah mempelajari kegagalan dan membangun sistem yang lebih tangguh selama beberapa dekade, mengadopsi terminologi mereka (daripada menciptakan kata-kata baru untuk konsep lama) dan menyesuaikan ide mereka dengan masalah dalam menjaga aplikasi tetap berjalan.

Jika kita melihat jenis “masalah IT dan jaringan…” yang menyebabkan pemadaman, itu adalah kegagalan sistem yang kompleks. Diterbitkan pada tahun 1984, buku Charles Perrow Kecelakaan Normal terinspirasi oleh kecelakaan Pulau Tiga Mil 1979, di mana kehancuran nuklir diakibatkan oleh interaksi tak terduga dari berbagai kegagalan dalam sistem yang kompleks. Peristiwa tersebut merupakan contoh kecelakaan biasa karena itu “ tidak terduga, tidak dapat dipahami, tidak dapat dikendalikan, dan tidak dapat dihindari.

“Bencana dan kematian adalah hal yang berbeda dan bukan bagian dari distribusi kemungkinan hasil yang dianggap dan dicontohkan oleh kebanyakan orang karena hal itu pada dasarnya tidak dapat diterima.”

Mengapa bencana tidak terduga? Buku Todd Conklin tahun 2017, Workplace Fatalities: Failure to Predict , menunjukkan bahwa bencana dan kematian adalah pencilan dan bukan bagian dari distribusi kemungkinan hasil yang dianggap dan diperagakan oleh kebanyakan orang. karena mereka pada dasarnya tidak dapat diterima. Kami memiliki contoh yang sangat topikal saat ini. Saya tidak berpikir banyak organisasi memiliki “pandemi global” dalam rencana bisnis 2020 mereka, jadi itu sesuai dengan polanya — tidak terduga, tidak dapat dipahami, tidak dapat dikendalikan, dan tidak dapat dihindari. Kami juga telah melihat bahwa pemerintah yang memiliki rencana yang teruji dengan baik mengharapkan pandemi, memahaminya dengan lebih baik, mampu mengendalikannya, dan menghindari konsekuensi terburuk.

Konsep penggunaan failover untuk meningkatkan ketahanan adalah bahwa harus ada lebih dari satu cara untuk berhasil dan cara untuk beralih di antara keduanya. Relatif mudah untuk menambahkan redundansi ke sistem, untuk memverifikasi bahwa ada kapasitas ekstra, dan untuk membenarkan biaya tambahan redundansi terhadap biaya kegagalan. Jauh lebih sulit untuk membangun dan menguji kemampuan untuk berhasil gagal. Agar sistem benar-benar tangguh, sakelar failover harus jauh lebih andal daripada alternatif yang digunakannya; jika tidak, kegagalan sakelar itu sendiri mendominasi keandalan sistem secara keseluruhan. Konfigurasi sistem yang menyertakan failover lebih kompleks dan memiliki lebih banyak peluang untuk gagal daripada sistem yang lebih sederhana. Inilah mengapa praktik terbaiknya adalah mencapai tingkat keunggulan operasional yang matang dalam sistem yang lebih sederhana sebelum menambahkan mekanisme failover.

Sayangnya, mekanisme peralihan failover dan proses manajemen terkait sering kali merupakan bagian sistem yang paling tidak teruji, itulah sebabnya sistem sering runtuh ketika mencoba gagal. Untuk mengatasinya, kita perlu beralih dari proses pengujian pemulihan bencana tahunan yang dibuat khusus, menyakitkan, ke ketahanan yang otomatis dan terus diuji. Alasan mengapa hal ini mungkin sekarang adalah karena komputasi awan menyediakan otomatisasi yang konsisten, bersama dengan teknik dan alat chaos engineering , yang memungkinkan kita untuk menstandarisasi dan memproduksi kemampuan failover.

Apa itu teknik rekayasa chaos? Didefinisikan secara sederhana mereka adalah e xperiment untuk memastikan bahwa dampak dari kegagalan dapat dikurangi . Anda perlu menjalankan eksperimen yang memperkenalkan kegagalan, untuk menunjukkan bahwa sistem Anda dapat menangani kegagalan tersebut tanpa menyebabkan masalah yang terlihat oleh pengguna.

Saat Anda melihat sistem yang kompleks melalui lensa chaos engineer, Anda dapat menganggapnya sebagai tautan dalam sebuah rantai. Sebuah rantai hanya sekuat tautan terlemah, jadi pemadaman sering kali dipicu oleh satu hal yang Anda abaikan atau belum sempat Anda perbaiki. Cara berpikir lainnya adalah tali dengan banyak untaian, ada yang compang-camping dan ada yang putus. Banyaknya untaian tali membentuk margin kapasitas, tetapi jika Anda tidak memperhatikan jumlah untaian yang putus, Anda akhirnya akan “ melayang ke dalam kegagalan ”seperti yang dibahas Sydney Dekker dalam bukunya yang berjudul sama.

Dengan cara berpikir ini, untaian terakhir yang putus saat kegagalan terjadi bukanlah “penyebab kegagalan”. Pengabaian sistematis kabel yang berjumbai dari waktu ke waktu adalah penyebabnya. Untuk menjadi topikal lagi, sambaran petir dapat memicu kebakaran hutan tertentu, tetapi mencegah satu sambaran petir itu mungkin tidak mencegah api dipicu oleh hal lain. Jika hutan mengering dan penuh dengan pohon mati karena perubahan iklim, maka itu adalah penyebab sistematis kebakaran hutan.

Menerapkan pemikiran ini pada aplikasi yang perlu di-fail over tanpa terjatuh, kita perlu membangun dan mempertahankan beberapa margin keamanan, sehingga kegagalan kecil individu tidak meningkat dan menyebabkan bencana. Konsep “pertahanan mendalam” dan “check and balances” berguna, dan perlu diterapkan ke semua lapisan sistem. Namun, mereka perlu sering diuji untuk memastikan bahwa pengecekan dan margin keamanan ada dan memiliki efek yang diinginkan.

Merancang dunia yang lebih aman

Karakteristik sistem yang tangguh dapat dibagi menjadi empat lapisan:

  1. Staf berpengalaman – Gunakan “hari permainan” untuk memahami bagaimana sistem berperilaku saat mengelola kegagalan, dan mengetahui cara cepat mengamati dan mengontrol masalah.
  2. Aplikasi yang kuat – Telah diuji menggunakan alat injeksi kesalahan dan pengujian chaos.
  3. Fabric switching yang dapat diandalkan – Kerangka aplikasi yang mengkompensasi kesalahan dengan merutekan di sekitarnya
  4. Landasan layanan yang redundan – Layanan otomatis yang berlebihan yang dengan hati-hati menjaga isolasi sehingga terjadi kegagalan independen

Jika kita mencoba membuat kecelakaan normal kita tidak terlalu “ tidak terduga, tidak dapat dipahami, tidak dapat dikendalikan, dan tidak dapat dihindari ,” maka kita dapat memulai dengan melakukan analisis bahaya. Memahami kemungkinan kecelakaan harus menghasilkan lebih sedikit kecelakaan tak terduga . Kami dapat meningkatkan observabilitas dan khususnya meningkatkan pengalaman pengguna operator selama kecelakaan untuk membuatnya kurang tidak dapat dipahami . Kemudian kita dapat melihat bagaimana membuat sistem lebih dapat dikontrol saat terjadi kecelakaan. Akhirnya, karena kecelakaan tidak dapat dihindari , kemampuan paling umum yang dapat kita kembangkan adalah kecepatan deteksi dan respons untuk meminimalkan dampaknya.

Saya melihat hal ini dimainkan saat saya di Netflix. Kami membangun sistem yang menjadi cukup kuat dari waktu ke waktu, dan sebagian besar masalah normal yang salah ditangani, jadi kami memiliki sangat sedikit insiden yang memengaruhi pelanggan. Sayangnya, insiden yang kami alami belum pernah kami lihat sebelumnya. Kami menyingkirkan insiden yang mudah dan umum dan ditinggalkan dengan insiden yang jarang terjadi yang tidak terduga, tidak dapat dipahami, tidak dapat dikendalikan, dan tidak dapat dihindari.

Untuk memastikan semua orang mempraktikkan apa yang harus dilakukan selama insiden, dan untuk mengatasi masalah dengan cepat, Netflix meningkatkan frekuensi tes kegagalan hari permainan dari sekali seperempat menjadi setiap dua minggu. Dengan cara ini, kami dapat menemukan masalah baru lebih awal, dan memperkuat inti dari sistem tangguh kami, staf berpengalaman , dengan membuat mereka lebih akrab dengan kecelakaan.

Teori Kecelakaan: Pesawat, Kereta, dan Rudal Nuklir

Saat saya mencari cara baru untuk membantu mencegah kegagalan agar tidak jatuh, saya telah menjelajahi Analisis Proses Teori Sistem (STPA), yang merupakan bagian dari serangkaian teknik yang lebih luas yang disebut Model dan Proses Kecelakaan Teoretik Sistem (STAMP ). Ini dijelaskan dalam buku Engineering a Safer World oleh Nancy G. Leveson dari MIT.

Teknik tersebut telah disempurnakan dari banyak proyek analisis bahaya, termasuk sistem yang digunakan untuk sistem pengisian bahan bakar dalam pesawat, kontrol lalu lintas udara AS, dan sistem peluncuran rudal nuklir. STPA didasarkan pada diagram kontrol fungsional sistem, dan batasan keselamatan serta persyaratan untuk setiap komponen dalam desain. Diagram kontrol umum yang dapat kita gunakan untuk sistem TI dibagi menjadi tiga lapisan: bidang data yang merupakan fungsi bisnis itu sendiri, sistem kontrol yang mengelola fungsi bisnis tersebut, dan operator manusia yang mengawasi sistem kontrol.

Fokusnya adalah memahami hubungan antar komponen dan bagaimana mereka dipengaruhi oleh kegagalan. Dalam diagram “kotak dan kabel”, kebanyakan orang fokus pada menentukan kotak dan mode kegagalannya dan kurang tepat tentang informasi yang mengalir di antara kotak. Dengan STPA, ada fokus pada kabel, informasi kontrol apa yang mengalir di atasnya, apa yang terjadi jika arus tersebut terpengaruh, dan model yang mengonsumsi informasi dan mendorong tindakan kontrol.

Ada dua langkah utama yang membentuk daftar periksa yang baik untuk memikirkan desain Anda sendiri. Pertama, identifikasi potensi kontrol yang tidak memadai dari sistem yang dapat menyebabkan keadaan berbahaya. Keadaan ini mungkin diakibatkan oleh kontrol yang tidak memadai atau penegakan batasan keamanan. Untuk langkah kedua, setiap tindakan pengendalian yang berpotensi berbahaya diperiksa untuk melihat bagaimana hal itu bisa terjadi. Mengevaluasi kontrol dan mekanisme mitigasi, mencari konflik dan masalah koordinasi. Pertimbangkan bagaimana kontrol dapat menurun dari waktu ke waktu, menggunakan teknik seperti manajemen perubahan, audit kinerja dan tinjauan insiden untuk memunculkan anomali, dan masalah dengan desain sistem.

Jika kita mengambil model STPA umum dan memetakannya ke aplikasi tertentu, seperti API layanan keuangan yang mengumpulkan permintaan pelanggan dan melakukan tindakan, maka pengontrol manusia memantau throughput sistem untuk memastikannya menyelesaikan tindakan di tingkat yang diharapkan. Pengontrol otomatis dapat menjadi penskala otomatis yang melihat penggunaan CPU dari proses yang dikontrol, menaikkan dan menurunkan jumlah instance yang mendukung lalu lintas untuk mempertahankan pemanfaatan CPU antara tingkat minimum dan maksimum yang tetap.

Jika penggunaan CPU layanan maksimal dan throughput turun tajam, pengontrol manusia diharapkan memperhatikan dan memutuskan apa yang harus dilakukan. Kontrol yang tersedia bagi mereka adalah untuk mengubah batas penskala otomatis, memulai ulang bidang data atau sistem bidang kontrol, atau untuk memutar kembali ke versi kode sebelumnya.

Bahaya dalam situasi ini adalah bahwa pengontrol manusia dapat melakukan sesuatu yang membuatnya lebih buruk, bukan lebih baik. Mereka tidak bisa berbuat apa-apa, karena mereka tidak memperhatikan. Mereka dapat mem-boot ulang semua instance sekaligus, yang akan menghentikan layanan sepenuhnya. Mereka bisa panik setelah terjadi penurunan lalu lintas yang besar yang disebabkan oleh banyak pelanggan yang memutuskan untuk menonton Superbowl di TV dan mengambil tindakan sebelum diperlukan. Mereka dapat melakukan sesuatu yang terlambat, seperti pemberitahuan pada akhirnya setelah sistem mengalami degradasi untuk beberapa saat dan meningkatkan batas maksimum penskala otomatis. Mereka dapat melakukan hal-hal dalam urutan yang salah, seperti reboot atau rollback sebelum meningkatkan autoscaler. Mereka dapat berhenti terlalu cepat, dengan meningkatkan batas penskala otomatis, tetapi tidak cukup jauh untuk membuat sistem berfungsi kembali, dan berhenti dengan anggapan telah diperbaiki. Mereka bisa menghabiskan waktu terlalu lama untuk me-reboot sistem berulang kali. Tim respons insiden dapat berdebat tentang apa yang harus dilakukan, atau beberapa orang dapat membuat perubahan yang berbeda sekaligus. Selain itu, runbook mungkin kedaluwarsa dan berisi informasi yang salah tentang cara menanggapi masalah di sistem saat ini. Saya yakin banyak pembaca telah melihat bahaya ini secara langsung!

Setiap arus informasi dalam sistem juga harus diperiksa untuk melihat bahaya apa yang dapat terjadi. Dalam aliran observasi, bahaya tipikal sedikit berbeda dari aliran kontrol. Dalam hal ini, sensor yang melaporkan throughput dapat berhenti melaporkan dan terhenti pada nilai terakhir yang terlihat. Itu bisa melaporkan throughput nol, meskipun sistem bekerja dengan benar. Nilai yang dilaporkan dapat meluap secara numerik dan melaporkan nilai negatif atau nilai positif yang dibungkus. Data dapat rusak dan melaporkan nilai yang berubah-ubah. Pembacaan bisa tertunda dengan jumlah yang berbeda sehingga terlihat rusak. Laju update dapat disetel terlalu tinggi sehingga sensor atau sistem pengiriman metrik tidak dapat mengikutinya. Pembaruan dapat ditunda sehingga sistem pemantauan menunjukkan status kedaluwarsa, dan efek tindakan kontrol tidak segera terlihat. Hal ini sering menyebabkan koreksi berlebih dan osilasi dalam sistem, yang merupakan salah satu contoh masalah koordinasi. Pembacaan sensor dapat menurun seiring waktu, mungkin karena kebocoran memori atau aktivitas pengumpulan sampah di jalur pengiriman.

Area fokus ketiga adalah memikirkan model yang menyusun sistem, mengingat pepatah “Semua model salah, beberapa model berguna”. Penskala otomatis berisi model sederhana yang memutuskan tindakan kontrol apa yang diperlukan berdasarkan penggunaan yang dilaporkan. Ini adalah pandangan dunia yang sangat sederhana, dan berfungsi dengan baik selama penggunaan CPU menjadi penghambat utama. Misalnya, anggaplah kode berjalan pada sistem dengan empat CPU dan pembaruan perangkat lunak didorong keluar yang berisi perubahan pada algoritma penguncian yang membuat kode serial sehingga hanya dapat menggunakan satu CPU. Instance tidak boleh sibuk lebih dari 25%, jadi penskala otomatis akan menurunkan ke jumlah minimum instance, tetapi sistem akan benar-benar kelebihan beban dengan throughput yang buruk. Di sini, penskala otomatis gagal karena modelnya tidak memperhitungkan situasi yang coba dikontrol.

Model penting lainnya yang perlu dipertimbangkan adalah model mental internal siapa pun yang mengoperasikan sistem. Model itu dibuat dengan pelatihan dan pengalaman dengan sistem. Operator mendapat peringatan dan melihat throughput dan pemanfaatan dan mungkin akan bingung. Salah satu perbaikannya adalah dengan meningkatkan jumlah minimum instance. Jika mereka juga dapat melihat kapan perangkat lunak baru dikeluarkan dan ini berkorelasi dengan dimulainya masalah, mereka juga dapat memutar kembali ke rilis sebelumnya sebagai tindakan kontrol korektif.

Beberapa pertanyaan yang dapat kami tanyakan: apakah model proses terkontrol melihat metrik yang tepat dan berperilaku aman? Berapa konstanta waktu dan faktor redaman untuk algoritme kontrol? Apakah akan berosilasi, berdering, atau membutuhkan waktu terlalu lama untuk merespons masukan? Bagaimana pengontrol manusia diharapkan mengembangkan model mereka sendiri dari proses terkontrol dan otomatisasi, lalu memahami apa yang diharapkan ketika mereka membuat input kontrol? Bagaimana pengalaman pengguna dirancang agar pengontrol manusia diberi tahu dengan cepat dan akurat dengan informasi yang cukup untuk merespons dengan benar, tetapi tanpa terlalu banyak data untuk disebarkan atau terlalu banyak alarm palsu?

Failover tanpa runtuh dalam praktiknya

Contoh penskala otomatis memberikan pengenalan konsep yang mudah, tetapi fokus cerita ini adalah bagaimana gagal tanpa jatuh, dan kita juga dapat menerapkan STPA pada situasi tersebut. Pertama-tama kita harus mempertimbangkan dua pola failover yang umum pada arsitektur cloud, lintas zona dan lintas wilayah.

Availability zone mirip dengan situasi failover pusat data di mana kedua lokasi cukup berdekatan sehingga data dapat direplikasi secara sinkron melalui jaringan latensi yang cukup rendah. AWS membatasi jarak antara zona ketersediaan hingga di bawah 100 kilometer, dengan latensi beberapa milidetik. Namun, untuk mempertahankan mode kegagalan independen, zona ketersediaan setidaknya terpisah sepuluh kilometer, di zona banjir yang berbeda, dengan jaringan dan sambungan daya terpisah. Data yang ditulis di satu lokasi secara otomatis diperbarui di semua zona, dan proses failover biasanya otomatis, sehingga aplikasi yang berjalan di tiga zona harus dapat tetap berjalan di dua zona tanpa masukan operator. Ini menjaga ketersediaan aplikasi hanya dengan beberapa gangguan dan percobaan ulang untuk beberapa pelanggan dan tidak ada data yang hilang.

Pola lainnya adalah lintas wilayah. Region umumnya cukup jauh sehingga latensi terlalu tinggi untuk mendukung update sinkron. Kegagalan biasanya dimulai secara manual dan membutuhkan waktu cukup lama sehingga sering terlihat oleh pelanggan.

Aplikasi dan konfigurasi layanan pendukung berbeda dalam kedua kasus, tetapi perbedaan mendasar dari sudut pandang analisis bahaya adalah hal yang ingin saya fokuskan. Saya akan berasumsi bahwa failover zona dipicu secara otomatis oleh bidang kontrol, dan failover wilayah dipicu secara manual oleh operator.

Dalam situasi failover lintas zona otomatis, apa yang mungkin terjadi? Arus lalu lintas tambahan yang terburu-buru dari zona gagal dan pekerjaan ekstra dari badai permintaan-coba lagi lintas zona menyebabkan zona yang tersisa kesulitan dan memicu kegagalan total aplikasi. Sementara itu, layanan perutean yang mengirimkan lalu lintas ke zona dan bertindak sebagai sakelar failover juga mengalami badai percobaan ulang dan terpengaruh. Pengendali manusia yang bingung tidak setuju di antara mereka sendiri tentang apakah mereka perlu melakukan sesuatu atau tidak, dengan banjir kesalahan, menampilkan kenyataan yang terlambat beberapa menit, dan runbook yang kedaluwarsa. Bidang kontrol perutean tidak memberi tahu manusia dengan jelas apakah semuanya sudah diurus, dan zona offline menunda serta merusak metrik lain dengan banjir kesalahan.

Dalam failover lintas zona, pengontrol manusia tidak perlu melakukan apa pun! Namun, karena bingung dan bekerja secara terpisah, mereka mencoba memperbaiki masalah yang berbeda. Beberapa alat mereka tidak sering digunakan dan rusak atau salah konfigurasi untuk melakukan hal yang salah. Mereka akhirnya menyadari bahwa sistem telah runtuh. Beberapa kali pertama Anda mencoba ini dalam hari permainan, inilah yang Anda harapkan akan terjadi. Setelah memperbaiki masalah observabilitas, mengabaikan badai percobaan ulang, menerapkan pelingkupan permintaan yang dikategorikan untuk menghindari panggilan lintas zona yang tidak penting, dan menyiapkan alat korelasi peringatan, Anda akhirnya dapat duduk dan menonton otomatisasi melakukan hal yang benar tanpa ada orang lain yang memperhatikan.

Jika Anda tidak memiliki keunggulan operasional untuk mengoperasikan hari-hari permainan zona kegagalan yang sering berhasil, Anda tidak boleh mencoba menerapkan failover multi-region. Ini jauh lebih kompleks, ada lebih banyak peluang untuk gagal, dan Anda akan membangun sistem yang kurang dapat diandalkan.

Apa yang mungkin terjadi selama fail-over lintas wilayah? Wilayah yang gagal menimbulkan banyak kesalahan dan peringatan, penundaan ini merusak metrik lainnya, dan bidang kontrol perutean lintas wilayah tidak dengan jelas memberi tahu manusia bahwa suatu wilayah tidak dapat digunakan. Pengontrol manusia harus memulai failover! Seperti yang dinyatakan di atas untuk failover tingkat zona, mereka bingung, dan tidak setuju di antara mereka sendiri. Faktanya, masalahnya lebih buruk karena mereka harus memutuskan apakah ini kegagalan tingkat zona atau kegagalan tingkat wilayah, dan merespons dengan tepat.

Operator kemudian memutuskan untuk memulai failover tetapi mereka mengalihkan lalu lintas terlalu cepat, pekerjaan tambahan dari badai permintaan-coba lagi lintas wilayah menyebabkan wilayah lain kesulitan, dan memicu kegagalan total aplikasi. Sementara itu, layanan perutean juga mengalami retry storm dan terpengaruh, sehingga operator kehilangan kendali atas proses failover. Kedengarannya familiar? Beberapa pembaca mungkin mengalami kilas balik PTSD pada saat ini. Sekali lagi, satu-satunya cara untuk memastikan bahwa failover akan berfungsi saat Anda membutuhkannya adalah dengan menjalankan game cukup sering sehingga operator tahu apa yang harus dilakukan. Pastikan retry storms diminimalkan, peringatan banjir dicegah dan dikorelasikan, dan sistem observasi dan kontrol diuji dengan baik dalam situasi failover.

Operator Anda harus terus memelihara model mental sistem mereka. Model ini dibuat berdasarkan pengalaman mengoperasikan sistem dan didukung oleh dokumentasi dan pelatihan. Namun, dengan pengiriman berkelanjutan dan tingkat perubahan yang tinggi dalam aplikasi, dokumentasi dan pelatihan tidak akan diperbarui. Ketika failover lintas zona dan lintas wilayah ditambahkan ke model operasi, itu menjadi jauh lebih kompleks. Salah satu cara untuk mengurangi kompleksitas adalah dengan mempertahankan pola yang konsisten yang menegakkan simetri dalam arsitektur. Apa pun yang membuat zona atau wilayah tertentu berbeda adalah masalah, jadi terapkan semuanya secara otomatis dan identik di setiap zona dan wilayah. Jika ada sesuatu yang tidak sama di semua tempat, buat perbedaan itu sedetail mungkin. Arsitektur multi-wilayah Netflix yang kami terapkan pada tahun 2013 berisi total sembilan salinan lengkap dari semua data dan layanan (tiga zona dengan tiga wilayah), dan dengan menutup zona dan wilayah secara teratur, apa pun yang merusak simetri akan ditemukan dan diperbaiki .

Failover menjadi lebih mudah dengan layanan umum yang disediakan AWS, tetapi menjadi jauh lebih kompleks jika setiap aplikasi memiliki arsitektur failover yang unik, dan ada sedikit kesamaan di seluruh basis pelanggan AWS. Pilar Keandalan AWS Well Architected Guide berisi banyak saran yang berguna, dan juga mendukung praktik umum dan bahasa di seluruh akun dan pelanggan, yang mensosialisasikan model yang lebih konsisten di lebih banyak pengontrol manusia. Standarisasi layanan yang mendasari dan model operator manusia oleh AWS ini sangat membantu dalam membangun keyakinan bahwa akan mungkin terjadi kegagalan tanpa jatuh.

Di mana Anda harus memulai? Saya pikir langkah pertama yang paling efektif adalah memulai rangkaian latihan hari permainan secara teratur. Latih orang-orang Anda untuk bekerja sama dalam panggilan insiden, kumpulkan dasbor dan kontrol yang ada bersama-sama, dan Anda akan memiliki respons yang jauh lebih cepat dan lebih terkoordinasi untuk insiden berikutnya. Buat diagram kendali Anda sendiri, dan pikirkan daftar bahaya yang ditentukan oleh STPA. Secara bertahap mulai dari hari-hari permainan menggunakan latihan simulasi, untuk menguji lingkungan, hingga aplikasi produksi yang diperkuat untuk memperbaiki berbagai hal saat Anda pergi.

Jika Anda ingin mempelajari lebih lanjut tentang topik ini, saya adalah pembicara pembuka di Acara online AWS Chaos Engineering and Resiliency Series , berlangsung pada 27-28 Oktober dari pukul 11.00-14.00 di zona waktu AEDT. Salam hangat, dan saya harap lain kali Anda harus gagal, Anda tidak juga jatuh!

Referensi

Makalah: Membangun Aplikasi Layanan Keuangan Penting Misi di AWS

Oleh Pawan Agnihotri dengan kontribusi oleh Adrian Cockcroft

Panduan Arsitek Baik – Pilar Keandalan:

https://docs.aws.amazon.com/wellarchitected /latest/reliability-pillar/welcome.html

Posting blog terkait oleh @adrianco

https://medium.com/@adrianco / mode-kegagalan-dan-ketahanan-berkelanjutan-6553078caad5

Variasi waktu respons: https: // dev .to / aws / why-are-services-slow-terkadang-mn3

Percobaan ulang dan waktu tunggu: https: // dev.to/aws/if-at-first-you-don-t-get-an-answer-3e85

Sumber untuk berbagai dek slide di: https://github.com/adrianco/slides

Rekomendasi buku, daftar bacaan di: http://a.co/79CGMfB

Blog Stack Overflow berkomitmen untuk menerbitkan artikel menarik oleh pengembang, untuk pengembang. Dari waktu ke waktu itu berarti bekerja dengan perusahaan yang juga klien Stack Overflow melalui bisnis periklanan, bakat, atau tim kami. Saat kami memublikasikan karya dari klien, kami akan mengidentifikasinya sebagai Konten Mitra dengan tag dan dengan menyertakan penafian ini di bagian bawah.

Tag: , , ,

Read More

RELATED ARTICLES

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Most Popular

Recent Comments