Realitas seorang insinyur jaringan (dengan mie dan... garam?)
Baru-baru ini, ketika mendiskusikan berbagai insiden dengan para insinyur, saya melihat sebuah pola yang menarik.
Dalam diskusi-diskusi ini, pertanyaan tentang “akar permasalahan” selalu muncul. Pembaca setia mungkin tahu bahwa saya pernah pada . Di banyak organisasi, analisis insiden didasarkan sepenuhnya pada konsep ini. Mereka menggunakan teknik berbeda untuk mengidentifikasi hubungan sebab-akibat, seperti . Metode-metode ini mengasumsikan apa yang disebut “linearitas peristiwa” sebagai dogma yang tidak dapat disangkal.
Ketika Anda menantang gagasan ini dan menunjukkan bahwa linearitas sangat menipu dalam sistem yang kompleks, sebuah diskusi menarik akan muncul. Para pihak yang berselisih dengan penuh semangat menegaskan bahwa hanya pengetahuan tentang “akar permasalahan” yang memungkinkan kita memahami apa yang sedang terjadi.
Saya memperhatikan pola yang menarik: pengembang dan pengembang bereaksi berbeda terhadap gagasan ini. Menurut pengalaman saya, pengembang lebih cenderung berargumentasi bahwa akar permasalahan itu penting dan bahwa hubungan sebab-akibat selalu dapat dibangun dalam suatu peristiwa. Di sisi lain, DevOps lebih sering sepakat bahwa dunia yang kompleks tidak selalu mengikuti linearitas.
Saya selalu bertanya-tanya mengapa ini terjadi? Apa membuat programmer mengkritik gagasan “akar permasalahan adalah mitos” seperti itu? Seperti sistem kekebalan yang mengenali agen asing. Mengapa mereka bereaksi seperti ini, sedangkan para devops agak cenderung mempertimbangkan ide ini?
Saya tidak sepenuhnya yakin, tapi saya punya beberapa pemikiran mengenai hal ini. Hal ini berkaitan dengan konteks berbeda di mana para profesional ini melaksanakan pekerjaan mereka sehari-hari.
Pengembang sering kali bekerja dengan alat deterministik. Tentu saja, kompiler, penghubung, sistem operasi - semua ini adalah sistem yang kompleks, tetapi kita terbiasa dengan kenyataan bahwa mereka memberikan hasil yang deterministik, dan kita membayangkannya sebagai deterministik: jika kita memberikan data masukan yang sama, maka kita biasanya mengharapkan hasil yang deterministik. output yang sama dari sistem ini. Dan jika ada masalah pada keluarannya (“bug”), maka pengembang menyelesaikannya dengan menganalisis data masukan (baik dari pengguna atau dari seperangkat alat selama proses pengembangan). Mereka mencari "kesalahan" dan kemudian mengubah data masukan. Ini memperbaiki "bug".
Asumsi dasar pengembangan perangkat lunak: data masukan yang sama secara andal dan deterministik menghasilkan keluaran yang sama.
Faktanya, hasil non-deterministik itu sendiri dianggap sebagai bug: jika keluaran yang tidak diharapkan atau salah tidak direproduksi, maka pengembang cenderung memperluas penyelidikan ke bagian lain dari tumpukan (sistem operasi, jaringan, dll.), yang juga berperilaku kurang lebih secara deterministik, menghasilkan hasil yang sama dengan data masukan yang sama... dan jika bukan itu masalahnya, maka ini masih dianggap bug. Hanya saja sekarang ada bug sistem operasi atau jaringan.
Bagaimanapun, determinisme adalah asumsi dasar yang hampir dianggap remeh dalam sebagian besar pekerjaan yang dilakukan programmer.
Namun bagi para pengembang yang menghabiskan waktu seharian untuk menyiapkan perangkat keras atau memikirkan API cloud, gagasan tentang dunia yang sepenuhnya deterministik (selama memungkinkan untuk memetakan semua masukan!) adalah konsep yang paling cepat berlalu. Bahkan jika kamu mengesampingkannya , insinyur berpengalaman telah melihat hal-hal teraneh di dunia ini. Mereka tahu itu , belum lagi jutaan faktor lingkungan lainnya.
Jadi, lebih mudah bagi teknisi berpengalaman untuk meragukan bahwa semua insiden mempunyai satu akar permasalahan, dan teknik seperti “Lima Mengapa” akan secara tepat (dan berulang!) mengarah pada akar permasalahan tersebut. Faktanya, hal ini bertentangan dengan pengalaman mereka sendiri, di mana potongan puzzle tersebut tidak begitu cocok dalam praktiknya. Oleh karena itu, mereka lebih mudah menerima gagasan ini.
Tentu saja, saya tidak mengatakan bahwa pengembang itu naif, bodoh, atau tidak mampu memahami bagaimana linearitas bisa menipu.
Namun menurut saya, reaksi umum dari para pengembang dalam perdebatan ini sering kali berkaitan dengan fakta bahwa konsep determinisme melayani mereka dengan baik secara keseluruhan dalam pekerjaan sehari-hari. Mereka tidak menghadapi nondeterminisme sesering para insinyur harus menangkap kucing Schrödinger di infrastruktur mereka.
Hal ini mungkin tidak sepenuhnya menjelaskan reaksi pengembang yang diamati, namun ini merupakan pengingat yang kuat bahwa reaksi kita merupakan campuran kompleks dari banyak faktor.
Penting untuk mengingat kompleksitas ini, apakah kita sedang menangani satu insiden, berkolaborasi dalam alur pengiriman perangkat lunak, atau mencoba memahami dunia yang lebih luas.
Sumber: www.habr.com