🥇Kejuruteraan Kekacauan: Seni Pemusnahan yang Disengajakan

Catatan. terjemah: Kami berbesar hati untuk berkongsi terjemahan bahan yang menarik daripada Penginjil Teknologi Kanan daripada AWS - Adrian Hornsby. Secara ringkas, beliau menerangkan kepentingan percubaan untuk mengurangkan kesan kegagalan dalam sistem IT. Anda mungkin pernah mendengar tentang Chaos Monkey (atau menggunakan penyelesaian yang serupa)? Hari ini, pendekatan untuk mencipta alatan tersebut dan pelaksanaannya dalam konteks yang lebih luas dijalankan dalam rangka kerja aktiviti yang dipanggil chaos engineering. Baca lebih lanjut mengenainya dalam artikel ini.

"Tetapi di sebalik semua keindahan ini terdapat kekacauan dan kegilaan." —Tanner Walling

Pemadam kebakaran. Para profesional terlatih ini mempertaruhkan nyawa mereka setiap hari melawan kebakaran. Adakah anda tahu bahawa anda mesti menghabiskan sekurang-kurangnya 600 jam dalam latihan sebelum menjadi seorang ahli bomba? Dan ini baru permulaan. Menurut laporan, anggota bomba melatih sehingga 80% daripada masa bekerja mereka.

Mengapa?

Apabila seorang anggota bomba sedang memadamkan kebakaran sebenar, dia memerlukan yang sesuai gerak hati. Untuk membangunkannya, anda perlu berlatih jam demi jam, hari demi hari. Seperti yang mereka katakan, amalan membuat keajaiban.

“Mereka seolah-olah menembusi ke dalam intipati api; macam Dr. Phil untuk api.” — Melawan Kebakaran Hutan Dengan Komputer dan Intuisi

Catatan. terjemah: Phillip Calvin "Phil" McGraw ialah ahli psikologi Amerika, penulis, dan pengacara program televisyen popular Dr. Phil, di mana hos menawarkan penyelesaian kepada masalah mereka kepada pesertanya.

Suatu ketika dahulu di Seattle

Awal tahun 2000 Jesse Robbins, yang memegang jawatan di Amazon dengan gelaran rasmi Tuan bencana, mencipta dan mengetuai program GameDay. Ia berdasarkan pengalamannya sebagai anggota bomba. GameDay bertujuan untuk menguji, melatih dan menyediakan pelbagai sistem, perisian dan orang Amazon untuk menghadapi situasi krisis yang berpotensi.

Sama seperti ahli bomba membangunkan gerak hati untuk melawan kebakaran, Jesse mahu membantu pasukannya mengembangkan gerak hati untuk menangani peristiwa bencana berskala besar.

"GameDay: Mencipta Ketahanan Melalui Kemusnahan" - Jesse Robbins

Hari Permainan direka untuk meningkatkan kestabilan tapak runcit Amazon dengan sengaja memperkenalkan ralat ke dalam sistem kritikal.

GameDay bermula dengan satu siri pengumuman kepada seluruh syarikat bahawa latihan telah dirancang - kadangkala agak besar-besaran, contohnya, menutup seluruh pusat data. Butiran minimum diberikan tentang gangguan yang dirancang, dan pasukan diberi beberapa bulan untuk membuat persediaan. Tujuan utama latihan itu adalah untuk menguji sama ada kakitangan boleh menghadapi krisis tempatan dan menyelesaikan dengan cepat akibatnya.

Semasa latihan ini, alat dan proses tertentu telah digunakan, seperti pemantauan, makluman dan panggilan segera, untuk menganalisis dan mengenal pasti ralat dalam prosedur tindak balas insiden. Ternyata, GameDay hebat dalam mengenal pasti masalah seni bina klasik. Kadang-kadang ia juga mungkin untuk mengesan apa yang dipanggil "kecacatan terpendam" - masalah yang menampakkan diri disebabkan oleh perkara khusus kejadian itu. Sebagai contoh, sistem pengurusan insiden yang kritikal kepada proses pemulihan gagal disebabkan oleh kesan sampingan yang tidak dijangka yang disebabkan oleh masalah buatan manusia.

Apabila syarikat itu berkembang, jejari letupan teori GameDay berkembang. Akhirnya, latihan ini telah ditinggalkan kerana potensi kerosakan kepada syarikat jika perkara tidak berjalan mengikut rancangan menjadi terlalu besar. Sejak itu, program ini telah merosot menjadi satu siri eksperimen yang berbeza dan tidak memberi kesan kepada perniagaan untuk melatih kakitangan dalam situasi krisis. Saya tidak akan menerangkan secara terperinci tentang eksperimen dalam artikel ini, tetapi saya akan melakukannya pada masa hadapan. Kali ini saya ingin membincangkan idea penting yang mendasari GameDay: kejuruteraan kebolehpercayaan (kejuruteraan ketahanan), juga dikenali sebagai kejuruteraan huru-hara (kejuruteraan huru-hara).

Kebangkitan Monyet

Anda mungkin pernah mendengar tentang Netflix, penyedia kandungan video dalam talian. Netflix mula berpindah dari pusat datanya sendiri ke AWS Cloud pada Ogos 2008. Langkah itu didorong oleh rasuah pangkalan data yang serius yang menangguhkan penghantaran DVD selama tiga hari (ya, Netflix mula menghantar filem melalui mel siput). Penghijrahan ke awan didorong oleh keperluan untuk mengendalikan beban penstriman yang lebih tinggi, serta keinginan untuk beralih daripada seni bina monolitik dan ke arah perkhidmatan mikro yang boleh berskala dengan mudah bergantung pada bilangan pengguna dan saiz pasukan kejuruteraan. Bahagian pengguna perkhidmatan penstriman berpindah ke AWS dahulu, antara 2010 dan 2011, diikuti oleh IT perusahaan dan semua struktur lain. Pusat data Netflix sendiri ditutup pada 2016. Syarikat mengukur ketersediaan sebagai nisbah bilangan percubaan yang berjaya untuk melancarkan filem kepada jumlah bilangan, bukannya sebagai perbandingan mudah masa hidup dan masa henti, dan berusaha untuk mencapai angka 0,9999 di setiap rantau pada asas suku tahunan (ia selalunya berjaya). Seni bina global Netflix merangkumi tiga wilayah AWS. Oleh itu, jika masalah timbul di salah satu wilayah, syarikat itu mempunyai keupayaan untuk mengubah hala pengguna kepada orang lain.

Saya akan mengulangi salah satu petikan kegemaran saya:

“Gangguan tidak dapat dielakkan; akhirnya mana-mana sistem akan runtuh dari semasa ke semasa." — Werner Vogels

Malah, kegagalan dalam sistem teragih, terutamanya yang berskala besar, tidak dapat dielakkan, walaupun dalam awan. Walau bagaimanapun, awan AWS dan primitif redundansinya—khususnya prinsip zon berbilang ketersediaan, di mana ia dibina, membolehkan sesiapa sahaja untuk mereka bentuk perkhidmatan yang sangat dipercayai.

Menggunakan prinsip redundansi (kelebihan) dan penurunan secara beransur-ansur dalam fungsi (degradasi anggun)Netflix berjaya mengharungi kegagalantanpa menjejaskan pengguna akhir.

Sejak awal lagi, Netflix telah mematuhi prinsip seni bina yang paling ketat. Salah satu aplikasi pertama yang mereka gunakan pada AWS ialah aplikasi mereka Monyet huru-hara — untuk menyokong penskalaan automatik perkhidmatan mikro tanpa kewarganegaraan. Dalam erti kata lain, sebarang contoh boleh dihentikan dan diganti secara automatik tanpa kehilangan keadaan. Chaos Monkey memastikan tiada siapa yang melanggar prinsip ini.

Catatan. terjemah: By the way, untuk Kubernetes ada analog yang dipanggil kube-monyet, yang perkembangannya nampaknya terhenti pada Mac tahun ini.

Netflix mempunyai peraturan lain yang mengedarkan setiap perkhidmatan merentas tiga zon ketersediaan. Ia harus terus berfungsi jika hanya dua daripadanya tersedia. Untuk memastikan peraturan ini dipatuhi, Gorila huru-hara melumpuhkan zon ketersediaan. Pada skala yang lebih global huru hara Kong mampu menutup seluruh rantau AWS untuk mengesahkan bahawa semua pengguna Netflix boleh dilayan dari mana-mana tiga wilayah. Dan mereka menjalankan ujian meluas ini setiap beberapa minggu dalam pengeluaran untuk memastikan tiada apa-apa yang tergelincir melalui celah-celahnya.

Akhirnya, Netflix juga telah membangunkan lebih fokus Alat Ujian Kekacauan untuk membantu mengenal pasti masalah dengan perkhidmatan mikro dan seni bina storan. Anda boleh mengetahui lebih lanjut mengenai teknik ini dalam buku Chaos Engineering, yang saya cadangkan kepada sesiapa yang berminat dalam topik ini.

"Dengan menjalankan eksperimen secara tetap yang mensimulasikan gangguan serantau, kami dapat mengenal pasti pelbagai kekurangan sistem pada awal dan membetulkannya." — blog Netflix

Hari ini prinsip kejuruteraan huru-hara diformalkan; mereka diberi definisi berikut:

"Kejuruteraan huru-hara ialah pendekatan yang melibatkan menjalankan eksperimen pada sistem pengeluaran untuk memastikan keupayaannya untuk menahan pelbagai gangguan yang timbul semasa operasi." — principlesofchaos.org

Namun, dalam dia bercakap di AWS re:Invent-2018khusus untuk kejuruteraan huru-hara, Adrian Cockcroft, bekas pencipta seni bina awan Netflix yang membantu syarikat beralih ke infrastruktur semua awan, membentangkan definisi alternatif kejuruteraan huru-hara. Pada pendapat saya, ia lebih tepat dan mantap:

"Kejuruteraan huru-hara ialah percubaan yang direka untuk mengurangkan kesan kegagalan."

Malah, kita tahu bahawa kegagalan berlaku sepanjang masa. Apabila dibalas dengan betul, mereka tidak seharusnya memberi kesan kepada pengguna akhir. Matlamat utama kejuruteraan huru-hara adalah untuk menemui masalah yang tidak ditangani dengan betul.

Syarat yang diperlukan untuk mewujudkan huru-hara

Sebelum anda memulakan kejuruteraan huru-hara, pastikan anda telah melakukan semua kerja yang diperlukan untuk memastikan kemampanan di semua peringkat organisasi. Mencipta sistem toleransi kesalahan bukan hanya mengenai perisian. Ia bermula pada tahap infrastruktur, merebak pada rangkaian dan data, menjejaskan struktur aplikasi, dan akhirnya meliputi manusia dan budaya. Saya telah menulis secara meluas pada masa lalu tentang model dan kegagalan daya tahan (di sini, di sini, di sini и di sini) dan saya tidak akan menumpukan pada perkara ini sekarang, tetapi saya tidak boleh melakukannya tanpa sedikit peringatan.

Beberapa elemen yang diperlukan sebelum memperkenalkan huru-hara ke dalam sistem (senarainya tidak lengkap)

Peringkat kejuruteraan huru-hara

Adalah penting untuk memahami bahawa intipati kejuruteraan huru-hara TIDAK adalah untuk melepaskan monyet ke dalam hutan dan membiarkan mereka memusnahkan segala-galanya, tanpa sebarang tujuan. Tujuan disiplin ini adalah untuk mengganggu beberapa elemen sistem dalam persekitaran terkawal melalui eksperimen yang direka dengan baik untuk melihat sama ada aplikasi anda boleh menahan keadaan bergelora.

Untuk melakukan ini, anda mesti mengikuti proses formal yang ditakrifkan dengan jelas yang digariskan dalam rajah di bawah. Ia boleh membantu anda beralih daripada memahami keadaan mantap sistem anda kepada merumuskan hipotesis, mengujinya, dan akhirnya menganalisis pengalaman yang diperoleh daripada percubaan dan meningkatkan kestabilan sistem itu sendiri.

Peringkat kejuruteraan huru-hara

1. Keadaan stabil

Salah satu elemen terpenting dalam kejuruteraan huru-hara ialah memahami tingkah laku sistem dalam keadaan biasa.

Mengapa? Mudah sahaja: selepas memperkenalkan kegagalan buatan, anda mesti memastikan bahawa sistem telah kembali ke keadaan stabil yang dikaji dengan baik dan percubaan tidak lagi mengganggu kelakuan normalnya.

Perkara utama di sini adalah untuk memfokuskan bukan pada atribut sistem dalaman (pemproses, memori, dll.) tetapi pada output boleh diukur yang menghubungkan prestasi dengan pengalaman pengguna. Untuk output ini berada dalam keadaan stabil, gelagat sistem yang diperhatikan mesti mempunyai corak yang boleh diramal, tetapi berubah dengan ketara apabila kegagalan berlaku dalam sistem.

Mengingati definisi kejuruteraan huru-hara, yang dicadangkan di atas oleh Adrian Cockcroft, keadaan stabil ini berubah apabila gangguan luar kawalan menyebabkan masalah yang tidak dijangka dan memberi isyarat bahawa percubaan huru-hara harus dibatalkan.

Sebagai contoh keadaan stabil, mari kita ambil pengalaman Amazon. Syarikat menggunakan volum pesanan sebagai salah satu metrik keadaan mantapnya, dan untuk alasan yang baik. Pada tahun 2007, Greg Linden, sebelum ini dari Amazon, menerangkan bagaimana eksperimen menggunakan kaedah tersebut Ujian A/B Saya cuba memperlahankan masa memuatkan halaman tapak web dalam kenaikan 100 ms dan mendapati bahawa walaupun kelewatan kecil membawa kepada penurunan hasil yang serius. Dengan peningkatan dalam masa pemuatan sebanyak 100 ms, bilangan pesanan (dan oleh itu jualan) menurun sebanyak 1%. Inilah sebabnya mengapa bilangan pesanan adalah calon yang sangat baik untuk metrik keadaan mantap.

Netflix menggunakan metrik sebelah pelayan yang dikaitkan dengan permulaan main balik - bilangan klik pada butang "main". Mereka melihat corak dalam kelakuan penunjuk SPS (permulaan-per-saat) dan turun naiknya yang ketara apabila kegagalan sistem berlaku. Metrik ini dipanggil "Nadi Netflix" (Denyutan Netflix).

Nombor pesanan Amazon dan Pulse Netflix ialah barometer keadaan mantap yang sangat baik kerana ia menggabungkan pengalaman pengguna dan metrik operasi menjadi satu metrik tunggal, boleh diukur dan sangat boleh diramal.

Ukur, ukur dan ukur semula

Sudah semestinya jika anda tidak dapat menangkap metrik sistem dengan betul, anda tidak akan dapat memantau (atau mengesan) perubahan dalam keadaan mantap. Beri perhatian khusus untuk membaca semua parameter/penunjuk, daripada rangkaian, perkakasan kepada aplikasi dan orang. Lukis graf bagi ukuran ini, walaupun ia tidak berubah dari semasa ke semasa. Anda akan terkejut apabila menemui korelasi yang anda tidak tahu wujud.

"Jadikan semudah mungkin untuk jurutera mengakses data yang mereka boleh kira atau graf." — Ian Malpass

2. Hipotesis

Setelah menangani keadaan stabil, anda boleh meneruskan untuk merumuskan hipotesis.

Bagaimana jika enjin cadangan berhenti?
Bagaimana jika pengimbang beban turun?
Bagaimana jika caching gagal?
Bagaimana jika kependaman meningkat sebanyak 300ms?
Bagaimana jika pangkalan data induk ranap?

Sudah tentu, anda hanya perlu memilih satu hipotesis dan tidak perlu merumitkannya secara tidak perlu. Mulakan dari kecil. Saya suka bermula dengan hipotesis kakitangan. Pernahkah anda mendengar tentang faktor bas (faktor bas)? Faktor bas adalah ukuran risiko yang berkaitan dengan pengetahuan yang diagihkan secara tidak sekata di kalangan ahli pasukan. Ia membolehkan anda mengira bilangan minimum pesertanya, selepas kehilangan secara tiba-tiba projek itu akan berhenti kerana kekurangan pengetahuan atau pengalaman.

Banyak syarikat mempunyai pakar teknikal yang kehilangan mengejut (“dilanggar bas”) akan memberi kesan buruk kepada kedua-dua projek dan pasukan. Kenal pasti orang ini dan jalankan eksperimen huru-hara ke atas mereka: contohnya, ambil komputer mereka dan hantar mereka ke rumah untuk hari itu, kemudian perhatikan keputusan (yang selalunya huru-hara).

Jadikan masalah biasa kepada semua orang!

Tertarik seluruh pasukan untuk membangunkan hipotesis. Benarkan semua orang mengambil bahagian dalam sumbang saran: pemilik produk, pengurus teknikal, pembangun bahagian belakang dan bahagian hadapan, pereka bentuk, arkitek, dsb. Setiap orang yang dalam satu cara atau yang lain berhubung dengan produk.

Mula-mula, minta semua orang menulis jawapan mereka sendiri kepada soalan "Bagaimana jika...?" pada sehelai kertas. Anda akan melihat bahawa dalam kebanyakan kes setiap orang akan mempunyai jawapan yang berbeza, dan anda akan menyedari bahawa sesetengah pasukan tidak memikirkan masalah ini sama sekali sehingga sekarang.

Jeda pada ketika ini dan bincangkan mengapa ahli pasukan mempunyai idea yang berbeza tentang cara produk akan bertindak dalam "Bagaimana jika...?" Kembali kepada spesifikasinya dan pastikan semua orang mempunyai idea yang baik tentang apa yang akan berlaku seterusnya.

Ambil, sebagai contoh, tapak runcit Amazon yang disebutkan di atas. Bagaimana jika Beli mengikut Kategori berhenti memuatkan pada halaman utama?

Sekiranya saya mengembalikan ralat 404? Adakah ia berbaloi untuk memuatkan halaman, meninggalkan ruang kosong seperti dalam tangkapan skrin di bawah?

Adakah patut mengorbankan beberapa fungsi dan, sebagai contoh, membenarkan halaman berkembang dan menyembunyikan ralat?

Dan itu hanya pada bahagian UI. Apa yang perlu berlaku di bahagian belakang? Perlukah makluman dihantar? Sekiranya perkhidmatan yang gagal terus menerima permintaan setiap kali pengguna memuatkan halaman utama, atau adakah bahagian belakang harus memotongnya sepenuhnya?

Dan satu perkara terakhir. Tolong jangan rumuskan hipotesis yang anda tahu lebih awal akan menyebabkan masalah! Eksperimen dengan bahagian sistem yang anda fikir stabil—lagipun, itulah intipati percubaan.

3. Mereka bentuk dan menjalankan eksperimen

Pilih satu hipotesis;
Tentukan skop eksperimen;
Kenal pasti penunjuk berkaitan yang akan diukur;
Maklumkan kepada organisasi.

Hari ini ramai orang, serta laman web principlesofchaos, mempromosikan idea kejuruteraan huru-hara dalam pengeluaran. Walaupun ini sepatutnya menjadi matlamat akhir, kebanyakan organisasi takut dengan pendekatan ini, jadi ia bukan tempat yang baik untuk bermula.

Bagi saya, kejuruteraan huru-hara bukan sahaja kemusnahan pelbagai elemen sistem pengeluaran. Ini adalah satu perjalanan. Perjalanan ke dunia pengetahuan, berkait rapat dengan aktiviti seperti pemusnahan sistem dalam persekitaran terkawal - mana-mana persekitaran, sama ada persekitaran pembangun tempatan, beta, pementasan atau prod. Ganggu melalui percubaan yang direka bentuk dengan baik untuk membina keyakinan terhadap keupayaan aplikasi anda untuk menahan keadaan bergelora. "Membina Keyakinan” ialah perkara utama di sini kerana ia merupakan pelopor kepada perubahan budaya yang diperlukan untuk berjaya melaksanakan kejuruteraan huru-hara dan amalan kebolehpercayaan dalam syarikat anda.

Secara jujur, kebanyakan pasukan belajar banyak daripada memecahkan perkara, walaupun dalam persekitaran bukan pengeluaran. Cuba lakukan sahaja docker stop database dalam persekitaran tempatan anda dan lihat jika anda boleh menangani masalah ini tanpa akibat. Terdapat kemungkinan besar ia tidak akan berlaku.

Menghentikan Pangkalan Data - Contoh

Mulakan secara kecil-kecilan dan secara beransur-ansur membina keyakinan dalam pasukan dan organisasi anda. Orang akan memberitahu anda bahawa "trafik pengeluaran sebenar ialah satu-satunya cara untuk menangkap gelagat sistem dengan pasti." Dengar, senyum dan teruskan perlahan-lahan melakukan apa yang anda lakukan. Perkara paling buruk yang boleh anda lakukan ialah menggunakan kejuruteraan huru-hara pada pengeluaran dan gagal dengan teruk. Selepas ini, tiada siapa yang akan mempercayai anda, dan anda akan terpaksa melupakan "monyet huru-hara" selama-lamanya.

Pertama, dapatkan kepercayaan. Tunjukkan kepada organisasi dan rakan sekerja anda bahawa anda tahu apa yang anda lakukan. Jadilah ahli bomba dan pelajari seberapa banyak yang anda boleh tentang api sebelum meneruskan latihan kebakaran secara langsung. Dapatkan kredibiliti anda. Ingat kisah kura-kura dan arnab? Perlahan dan sabar sentiasa memenangi perlumbaan.

Salah satu perkara yang paling penting semasa eksperimen ialah memahami potensi jejari kerosakan daripada kegagalan yang anda perkenalkan dan pengurangannya. Tanya diri anda soalan berikut:

Berapakah bilangan pelanggan yang akan terjejas oleh eksperimen?
Apakah fungsi yang akan terjejas?
Tempat mana yang akan terjejas?

Fikirkan "butang bunuh" atau cara untuk segera membatalkan percubaan dan kembali ke keadaan stabil secepat mungkin. Saya suka menjalankan eksperimen menggunakan apa yang dipanggil. pelancaran "kanari". Teknik ini membolehkan anda mengurangkan risiko kegagalan apabila melancarkan versi baharu aplikasi dalam pengeluaran dengan melancarkan perubahan secara beransur-ansur kepada subset kecil pengguna dan kemudian menyebarkannya secara perlahan ke seluruh infrastruktur dan semua pengguna. Saya suka pelancaran kenari semata-mata kerana ia memenuhi prinsip infrastruktur yang tidak berubah, dan percubaan itu sendiri agak mudah untuk dihentikan.

Contoh pelancaran kenari berasaskan DNS untuk eksperimen huru-hara

Berhati-hati dengan eksperimen yang mengubah keadaan aplikasi (cache atau pangkalan data) atau yang tidak boleh digulung semula (dengan mudah atau sama sekali).

Menariknya, Adrian Cockcroft memberitahu saya bahawa salah satu sebab Netflix mula menggunakan pangkalan data NoSQL adalah kerana mereka tidak mempunyai skema untuk perubahan atau rollback, jadi lebih mudah untuk mengemas kini secara berperingkat atau membetulkan rekod data individu (iaitu mereka lebih mesra kepada kejuruteraan huru-hara) .

4. Memerhati dan belajar

Untuk mempelajari sesuatu yang baharu dan memantau kemajuan percubaan, anda perlu dapat memantau prestasi sistem. Seperti yang dinyatakan sebelum ini, beri perhatian maksimum kepada semua jenis metrik dan parameter! Kemudian ukur hasilnya dan sentiasa - sentiasa! — perhatikan masa sebelum tanda-tanda pertama masalah muncul. Ia telah berlaku banyak kali dalam sejarah saya bahawa sistem amaran telah gagal dan pelanggan tweet tentang masalah itu terlebih dahulu... percayalah, anda tidak mahu berakhir dalam situasi itu, jadi gunakan eksperimen huru-hara untuk menguji sistem pemantauan dan amaran anda sebagai baiklah.

Masa sehingga pengesanan?
Masa sebelum pemberitahuan dan permulaan tindakan aktif?
Masa sehingga pemberitahuan umum?
Masa sehingga kehilangan fungsi separa?
Berapa lama tempoh penyembuhan diri berlangsung?
Masa sehingga pemulihan penuh atau separa?
Masa sehingga akhir krisis dan kembali ke keadaan stabil?

Ingat bahawa tidak ada punca kegagalan yang terpencil. Kemalangan besar sentiasa berpunca daripada beberapa kegagalan kecil yang terkumpul dan membawa kepada krisis berskala besar.

Jalankan analisis postmortem terperinci bagi setiap eksperimen!

Di AWS, kami memberi penekanan yang besar pada menganalisis kegagalan yang dikesan dan memahami punca kegagalan tersebut supaya kami dapat mengelakkan masalah yang serupa pada masa hadapan. Semua kesimpulan dan keputusan eksperimen diringkaskan dalam dokumen yang dipanggil Correction-of-Errors (COE). COE membolehkan kita belajar daripada kesilapan kita, sama ada kecacatan dalam teknologi, proses, mahupun organisasi. Kami menggunakan mekanisme ini untuk menghapuskan punca kerosakan dan menambah baik secara berterusan.

Kunci kejayaan dalam proses ini ialah keterbukaan dan ketelusan tentang perkara yang salah. Salah satu prinsip terpenting dalam menulis COE yang baik ialah bersikap saksama dan elakkan menyebut orang tertentu. Ini selalunya sukar dalam persekitaran yang tidak menggalakkan tingkah laku sedemikian dan tidak membenarkan kemungkinan kegagalan. Amazon menggunakan koleksi "prinsip kepimpinan" (Prinsip Kepimpinan) untuk menggalakkan tingkah laku sedemikian - cth. kritikan kendiri, pendekatan analitikal, komitmen terhadap standard dan tanggungjawab tertinggi adalah komponen utama proses COE dan kecemerlangan operasi secara amnya.

Laporan COE mempunyai lima bahagian utama:

Apa yang berlaku (urutan kronologi)?
Apakah kesan kepada pelanggan?
Mengapakah ralat itu berlaku? (Lima "mengapa")
Apa yang telah kita pelajari?
Bagaimana untuk mengelakkan ini pada masa hadapan?

Soalan-soalan ini lebih sukar untuk dijawab daripada yang kelihatan pada pandangan pertama, kerana anda perlu memastikan bahawa setiap perkara yang tidak jelas/tidak diketahui dikaji dengan teliti.

Untuk menjadikan mekanisme COE sebagai proses yang lengkap, kami sentiasa menjalankan semakan dalam bentuk mesyuarat mingguan dengan analisis mandatori metrik operasi. Selain itu, petunjuk teknikal menjalankan semakan metrik mingguan dengan seluruh kakitangan AWS.

5. Betulkan dan perbaiki!

Pengajaran utama di sini ialah selesaikan masalah yang dikenal pasti semasa eksperimen huru-hara dahulu, memberi mereka keutamaan yang lebih tinggi daripada membangunkan ciri baharu. Libatkan pengurusan kanan dalam proses ini dan tanamkan dalam mereka idea bahawa menyelesaikan masalah semasa adalah lebih penting daripada membangunkan fungsi baharu.

Saya pernah membantu pelanggan mengenal pasti isu kestabilan kritikal menggunakan percubaan huru-hara, tetapi disebabkan tekanan daripada pasukan jualan, pembaikan telah dikurangkan keutamaan dan semua usaha ditumpukan pada memperkenalkan perkara baharu yang "sangat penting" kepada pelanggan. Dua minggu kemudian, masa henti selama 16 jam memaksa syarikat untuk menangani masalah yang sama yang kami kenal pasti semasa percubaan huru-hara. Hanya kerugian ternyata lebih tinggi.

Faedah Kejuruteraan Chaos

Terdapat banyak kelebihan. Saya akan menyerlahkan dua, pada pendapat saya, yang paling penting:

Pertama, kejuruteraan huru-hara membantu mendedahkan masalah yang tidak diketahui dalam sistem dan membetulkannya sebelum ia menyebabkan pengeluaran ranap, katakan, pada pukul 3 pagi pada hari Ahad. Iaitu, dia meningkatkan daya tahan terhadap kegagalan dan, sebenarnya, kualiti tidur.

Kedua, eksperimen huru-hara yang dijalankan dengan berkesan sentiasa menyebabkan perubahan yang lebih meluas (terutamanya budaya) daripada yang dijangkakan. Mungkin yang paling penting ialah evolusi semula jadi kepada "tidak bersalah" (tidak menyalahkan) budaya, apabila soalan "Mengapa anda berbuat demikian?" menjadi "Bagaimana kita boleh mengelakkan perkara ini pada masa hadapan?" Hasilnya ialah pasukan yang lebih gembira, lebih cekap, lebih terlibat dan lebih berjaya. Dan itu hebat!

Ini menyimpulkan bahagian pertama. Saya harap anda menyukainya. Sila tulis ulasan, berkongsi pendapat atau hanya bertepuk tangan sederhana. Dalam bahagian seterusnya, saya akan melihat alat dan teknik untuk memperkenalkan kerosakan ke dalam sistem. Sampai!

Bagi mereka yang tidak sabar-sabar membaca bahagian kedua, saya menawarkan ucapan saya mengenai topik kejuruteraan huru-hara di NDC di Oslo. Di dalamnya saya bercakap tentang banyak alat kegemaran saya:

PS daripada penterjemah

Bahagian kedua artikel dalam bahasa Inggeris telah pun muncul dan kami juga akan menterjemahkannya jika kami melihat minat yang mencukupi daripada pembaca Habr dalam bahan ini - ulasan yang sesuai pada artikel itu dialu-alukan!