Get best of the week

Rekayasa Ketahanan: Catatan dari Konferensi REDeploy



Sementara konferensi di seluruh dunia mencari format optimal online, saatnya untuk mengingat bagaimana mereka (dan kita semua) hidup di era pra-viral. Pada akhir tahun lalu, saya menghadiri konferensi REDeploy 2019 yang didedikasikan untuk Teknik Ketahanan. Untuk waktu yang sangat lama saya mencoba memahami bagaimana menerjemahkan istilah ini ke dalam bahasa Rusia, sampai saya menemukan bahwa istilah tersebut telah lama digunakan dalam ceruk yang tidak tertulis - seperti "rekayasa ketahanan." Lebih jauh lagi akan diperlukan untuk menulis definisi ketahanan, tetapi sulit untuk melakukan ini dengan satu kalimat sederhana. Ternyata topik yang diangkat enam bulan lalu sangat relevan dengan realitas baru kami.

Pertama-tama, penting untuk memahami bahwa rekayasa ketahanan adalah bidang ilmu lintas disiplin, yang bertujuan untuk penelitian, formalisasi dan pembentukan praktik yang meningkatkan kemampuan sistem sosio-teknis yang kompleks untuk dipersiapkan untuk situasi dan kecelakaan yang tidak biasa, beradaptasi dengan mereka dan meningkatkan kemampuan mereka untuk beradaptasi.

Selama bertahun-tahun, gambaran mekanis dunia berlaku dalam proses pengembangan perangkat lunak - keyakinan bahwa kami dapat mengembangkan perangkat lunak yang akan bekerja tanpa kerusakan, dan jika terjadi kecelakaan, ini akan memiliki beberapa penyebab utama, yang dapat diperbaiki untuk mencegah terulangnya kesalahan semacam itu di masa depan - dan dengan demikian, karena jumlah kesalahan tentu saja, pada akhirnya, perbaiki semua kesalahan yang menyebabkan kecelakaan (lihat artikel yang bagusDev, Ops dan Determinisme tentang itu).

Pendekatan "rekayasa" yang sama juga diterapkan pada cara orang berinteraksi selama kecelakaan: cukup untuk membuat beberapa alat, menggunakan orang yang dapat memperbaiki masalah (tanpa membuat kesalahan).

Tetapi yang menarik adalah bahwa perangkat lunak terus diperbarui, menjadi kompleks, terfragmentasi dan bercabang, dan kecelakaan yang terjadi tidak memiliki satu alasan tunggal (apalagi, mereka bahkan dapat ditemukan di luar sistem), dan orang-orang dalam proses komunikasi untuk memperbaiki kecelakaan ini dapat melakukan kesalahan.

Dengan demikian, tugasnya bukan tidak mungkin untuk menghindari kesalahan dan kecelakaan dalam sistem, tetapi untuk mempersiapkan orang dan sistem sehingga potensi kecelakaan memiliki dampak paling kecil pada sistem, pengguna dan penciptanya.

Pengembangan perangkat lunak untuk waktu yang lama tetap jauh dari disiplin teknik "offline" lainnya, sementara praktik "pengurangan dampak buruk" dari kecelakaan telah digunakan di sana untuk waktu yang lama. Dan praktik-praktik ini lebih cenderung berhubungan dengan orang daripada utilitas dan solusi teknis untuk mencegah kecelakaan.

Pertanyaan yang diajukan oleh ketahanan teknik adalah sebagai berikut:
  1. Apa fitur budaya, sosial dari interaksi orang yang harus dipertimbangkan untuk lebih memahami apa yang bisa dan tidak bisa terjadi dalam komunikasi orang dalam proses kecelakaan? Bagaimana proses adaptasi dan komunikasi dapat ditingkatkan? Dan sebaliknya, bagaimana situasinya dapat diperburuk?
  2. Pengetahuan apa dari disiplin ilmu lain yang dapat kita terapkan untuk membuat sistem lebih fleksibel dan stabil jika terjadi kecelakaan?
  3. Bagaimana seharusnya pelatihan dan interaksi manusia diatur sehingga jika terjadi kecelakaan baik kerusakan dari itu dan stres, bagi mereka yang akan menghilangkannya, adalah yang paling?
  4. Solusi teknis apa, praktik yang dapat diterapkan untuk ini? Bagaimana, melalui tindakan sadar, dapatkah kita meningkatkan stabilitas sistem dan kemampuan beradaptasinya terhadap kecelakaan?


Tentang ini adalah konferensi. Dan di bawah ini - apa yang dibicarakan oleh beberapa pembicara.

Beberapa Observasi tentang Ketahanan Tulang dan Rekayasa Ketahanan yang Luar Biasa. Richard Cook


Pertama-tama, harus dikatakan tentang orang pembicara. Richard Cook adalah seorang dokter, ilmuwan, dan salah satu "populariser" utama dari ketekunan TI. Bersama dengan David Woods dan John Olspau (orang yang benar-benar meluncurkan DevOps sebagai rujukan), ia ikut mendirikan Lab Kapasitas Adaptif, sebuah perusahaan yang menerapkan teknik keberlanjutan di organisasi lain.

Perlu dicatat bahwa REDeploy bukan konferensi TI, dan laporan ini adalah contoh nyata dari ini.

Sebagian besar laporan adalah analisis terperinci tentang bagaimana tulang yang patah sembuh, penyembuhan yang merupakan pola dasar ketahanan. Tulang-tulang itu sendiri tidak menyatu dengan baik. Kedokteran mempelajari cara mengobati patah tulang, memahami proses penyembuhan. Bahkan, obat-obatan bahkan tidak mengobati tulang itu sendiri, itu menciptakan proses yang mempromosikan penyembuhan.

Secara umum, riwayat pengobatan dapat dibagi menjadi dua arah:
  • pengobatan sebagai proses yang menciptakan kondisi yang paling menguntungkan untuk penyembuhan tulang (dalam proses perawatan kami menerapkan gipsum sehingga tulang tidak bergerak).
  • pengobatan sebagai proses “meningkatkan” proses penyembuhan (pemahaman - pada tingkat biokimia - bagaimana proses penyembuhan berlangsung, kami menggunakan obat yang mempercepatnya).


Dan di sini tesis utama sebenarnya adalah “terprogram” untuk seluruh disiplin laporan: mengapa kita perlu memahami bagaimana proses sosioteknik terjadi selama kecelakaan?

Memahami bagaimana mekanisme "perawatan" (misalnya, menyelesaikan keadaan darurat) bekerja, kita setidaknya dapat mengatur kondisi yang menguntungkan sehingga kecelakaan menyebabkan kerusakan minimal dan, secara maksimal, mempercepat proses penyelesaian kecelakaan. Kita tidak dapat mencegah kasus ketika seseorang patah tulang, tetapi kita dapat meningkatkan proses penyembuhan.

Seni Merangkul Kegagalan pada Skala. Adrian hornsby


Dan sekarang, sebuah laporan teknis tentang evolusi toleransi kesalahan dalam infrastruktur AWS.
Tanpa membahas fitur teknis (Anda dapat melihatnya di presentasi ), kami akan mempertimbangkan tesis utama dari laporan ini. AWS dalam proses membangun berbagai sistem mengembangkan arsitektur dengan mempertimbangkan fakta bahwa kecelakaan dapat terjadi cepat atau lambat, dan, oleh karena itu, arsitektur sistem harus dirancang sedemikian rupa untuk membatasi "radius ledakan" jika terjadi kecelakaan. Misalnya, basis data klien, penyimpanan dibagi menjadi kelompok "sel", dan beban yang dibuat oleh satu klien hanya memengaruhi pengguna sel ini. Klien dalam replika sel tidak menggandakan sel utama, tetapi dicampur bersama, sehingga membatasi radius dampak menjadi minimum.







Dengan meningkatkan jumlah kombinasi tersebut, kami mengurangi risiko keterlibatan pelanggan jika terjadi dampak.



Menjadi Nyaman Dengan Menjadi Bawah Air. Ronnie chen


Laporan dari manajer Twitter yang berpengalaman dalam penyelaman laut dalam teknis tentang fitur keselamatan selama menyelam.

Team deep diving adalah pekerjaan berisiko tinggi. Dan jika organisasi penyelaman semacam itu berlangsung dari kemungkinan penyelaman hanya dalam kasus perataan risiko yang lengkap - tidak akan ada penyelaman laut dalam sama sekali. Dengan satu atau lain cara, masalah dapat terjadi, dan ini normal - pembicara secara keseluruhan membandingkan pengambilan risiko secara sadar sebagai metode pengembangan potensi manusia. Jika kita mengurangi risiko, ini akan membatasi potensi kita. Tugasnya, sekali lagi, adalah mengatur penyelesaian situasi yang paling mudah seandainya risiko-risiko ini direalisasikan.

Bagaimana Anda bisa mencoba hidup dengan tekanan yang ada pada tim jika ada kegiatan berisiko?

Contoh aturan interaksi tim penyelam:
  • Komunikasi yang andal dan konstan antara peserta dan keamanan psikologis maksimum: setiap anggota tim harus merasa aman, setiap peserta selam dapat berhenti menyelam kapan saja (dan biaya dilarang).
  • Penerimaan kesalahan. Siapa pun dapat membuat kesalahan, dan kesalahan tidak bisa dihindari dalam proses kerja; menyalahkan kesalahan juga tidak bisa diterima.
  • Tim dapat mendefinisikan kembali tujuan proyek dan menentukan keberhasilan proyek dalam proses penyelaman tergantung pada perubahan kondisi.
  • , .
  • — . , , .
  • ( ) , root cause ( ), , .


The Practice of Practice: Teamwork in Complexity. Matt Davis


Dalam hal terjadi kecelakaan, para insinyur sebagian besar intuitif, dan intuisi dalam laporan tersebut dibandingkan dengan improvisasi musik. Improvisasi adalah proses memainkan musik yang intuitif, tetapi intuisi ini dibangun berdasarkan pengalaman - pengetahuan tentang skala musik, pengalaman improvisasi sebelumnya, kerja tim. Selain itu, ini adalah proses dua arah: intuisi dibangun berdasarkan pengalaman, dan proses dibangun berdasarkan analisis tindakan intuitif (dalam musik - catatan komposisi yang ditulis, dalam teknologi - proses mengoreksi kecelakaan dijelaskan).

Dua cara mengajar / membentuk intuisi:
- Post-mortem bukan sebagai sarana untuk menyalahkan atau mencegah masalah di masa depan, tetapi sebagai sarana pelatihan dan cara untuk berbagi pengalaman. Secara teratur bagikan pengalaman Anda dalam menyelesaikan kecelakaan dalam bentuk laporan post-mortem / kecelakaan untuk berbagi pengalaman Anda dalam menyelesaikan masalah dengan orang lain.
- Chaos Engineering sebagai cara untuk menghasilkan pengalaman dalam lingkungan yang terkendali. Dengan secara buatan menciptakan kecelakaan dalam sistem yang perlu diselesaikan, kami membentuk pengalaman intuisi dengan para insinyur yang akan menangani solusinya. Pada saat yang sama, kita dapat menentukan tumpukan yang diperlukan di mana kita ingin mengembangkan kompetensi dengan membatasi radius dampak dalam sistem.

Berikut adalah laporan yang paling berkesan bagi saya. Tampak bagi saya bahwa ini adalah hal-hal yang sangat berguna saat ini, ketika kelihatannya secara umum semua kenyataan telah hancur, “bawa yang lain”. Mungkin beberapa poin akan membantu Anda melihat kenyataan dan kecelakaan dari sudut pandang baru.

Dan saya sedikit lebih biasa daripada blog di sini, saya menyimpan saluran telegram saya , berlangganan :-)

More articles:


All Articles