Pemrogram Schrodinger, devops dan kucing

Kenyataan seorang insinyur jaringan (dengan mie dan ... garam?)

Baru-baru ini, membahas berbagai insiden dengan para insinyur, saya perhatikan pola yang menarik.

Dalam diskusi ini, pertanyaan tentang "akar penyebab" selalu muncul. Pembaca yang setia mungkin akan tahu bahwa saya memiliki beberapa pemikiran tentang ini . Di banyak organisasi, analisis insiden didasarkan sepenuhnya pada konsep ini. Mereka menggunakan teknik berbeda untuk mengidentifikasi hubungan sebab-akibat, seperti Five Why . Metode-metode ini menyarankan apa yang disebut "linearitas peristiwa" sebagai dogma yang tidak dapat disangkal.

Ketika Anda mempertanyakan ide ini dan menunjukkan bahwa dalam sistem yang kompleks, linearitas meyakinkan menipu, lahirlah diskusi yang menarik. Para pendebat dengan penuh semangat bersikeras bahwa hanya pengetahuan tentang "akar penyebab" yang memungkinkan kita untuk memahami apa yang sedang terjadi.

Saya perhatikan pola yang menarik: pengembang dan pengembang bereaksi berbeda terhadap ide ini. Dalam pengalaman saya, pengembang lebih sering berdebat bahwa akar penyebab itu penting dan bahwa hubungan sebab-akibat selalu bisa terjalin dalam peristiwa. Di sisi lain, devops lebih sering setuju bahwa dunia yang kompleks tidak selalu tunduk pada linearitas.

Saya selalu bertanya-tanya mengapa demikian? Apa yang membuat programmer mengkritik gagasan "akar penyebab - mitos"? Seperti sistem kekebalan yang mengenali agen asing. Mengapa mereka bereaksi seperti ini sementara para devos lebih cenderung mempertimbangkan ide ini?

Saya tidak begitu yakin, tetapi ada pertimbangan dalam hal ini. Ini terkait dengan berbagai konteks di mana para profesional ini melakukan pekerjaan sehari-hari.

Pengembang sering bekerja dengan alat deterministik. Tentu saja, kompiler, penghubung, OS adalah semua sistem yang kompleks, tetapi kami terbiasa memberikan hasil deterministik, dan kami menyajikannya sebagai deterministik: jika kami memberikan input data yang sama, maka kami biasanya mengharapkan output yang sama dari sistem ini . Dan jika ada masalah ("bug"), maka pengembang menyelesaikannya dengan menganalisis data input (baik dari pengguna atau dari seperangkat alat dalam proses pengembangan). Mereka mencari "kesalahan" dan kemudian memodifikasi input. Ini memperbaiki bug.


Asumsi utama pengembangan perangkat lunak: input data yang sama andal dan deterministik memberikan output yang sama

Bahkan, hasil non-deterministik dengan sendirinya dianggap sebagai kesalahan: jika kesimpulan yang tidak terduga atau salah tidak direproduksi, maka pengembang berusaha untuk memperluas studi ke bagian lain dari tumpukan (sistem operasi, jaringan, dll.) Yang juga berperilaku lebih atau kurang deterministik, memberikan hasil yang sama. hasil dengan input yang sama ... dan jika tidak , maka itu masih dianggap bug. Hanya saja ini sekarang bug dari sistem operasi atau jaringan.

Dalam kasus apa pun, determinisme adalah dasar, hampir diterima sebagai asumsi yang diberikan untuk sebagian besar pekerjaan yang dilakukan oleh programmer.

Tetapi bagi para devopa yang menghabiskan hari itu mengumpulkan besi di rak-rak atau berurusan dengan cloud API, gagasan tentang dunia yang sepenuhnya deterministik (selama ada peluang untuk menampilkan semua data input!), Paling banter, adalah sebuah konsep singkat. Bahkan mengesampingkan lelucon BOHF tentang bintik-bintik matahari , insinyur yang berpengalaman melihat hal-hal aneh di dunia ini. Mereka tahu bahwa bahkan jeritan manusia dapat memperlambat server , belum lagi jutaan faktor lingkungan lainnya.

Jadi, lebih mudah bagi insinyur yang berpengalaman untuk meragukan bahwa semua insiden memiliki akar penyebab tunggal, dan teknik seperti "Lima Alasan" dengan benar (dan dapat diulang!) Mengarah ke akar penyebab itu. Bahkan, ini bertentangan dengan pengalaman mereka sendiri, ketika potongan-potongan puzzle dalam praktek tidak bertambah dengan jelas. Karena itu, mereka lebih mudah memahami ide ini.

Tentu saja, saya tidak mengatakan bahwa pengembang naif, bodoh, atau tidak dapat memahami bagaimana linearitas dapat menipu. Pemrogram berpengalaman mungkin juga melihat banyak non-determinisme dalam hidup mereka.

Tetapi bagi saya tampaknya reaksi yang biasa dari para pengembang dalam perselisihan ini seringkali terkait dengan fakta bahwa konsep determinisme secara keseluruhan membantu mereka dalam pekerjaan sehari-hari. Mereka tidak menemukan non-determinisme sesering insinyur harus menangkap kucing Schrodinger di infrastruktur mereka.

Mungkin ini tidak sepenuhnya menjelaskan reaksi yang diamati dari pengembang, tetapi ini adalah pengingat yang kuat bahwa reaksi kami adalah campuran kompleks dari banyak faktor.

Penting untuk mengingat kompleksitas ini, terlepas dari apakah kami sedang menyelidiki satu insiden atau bekerja sama pada jalur pengiriman perangkat lunak, atau mencoba memahami dunia yang lebih luas.