Realiti seorang jurutera rangkaian (dengan mi dan... garam?)
Baru-baru ini, semasa membincangkan pelbagai insiden dengan jurutera, saya melihat satu corak yang menarik.
Dalam perbincangan ini, persoalan "akar punca" selalu timbul. Pembaca yang setia mungkin tahu bahawa saya ada pada . Dalam banyak organisasi, analisis insiden adalah berdasarkan sepenuhnya pada konsep ini. Mereka menggunakan teknik yang berbeza untuk mengenal pasti hubungan sebab dan akibat, seperti . Kaedah ini menganggap apa yang dipanggil "lineariti peristiwa" sebagai dogma yang tidak dapat dipertikaikan.
Apabila anda mencabar idea ini dan menunjukkan bahawa kelinearan adalah menipu dalam sistem yang kompleks, perbincangan yang menarik akan lahir. Pihak yang bersengketa dengan penuh semangat menegaskan bahawa hanya pengetahuan tentang "punca utama" membolehkan kita memahami apa yang sedang berlaku.
Saya perhatikan corak yang menarik: pembangun dan devops bertindak balas secara berbeza terhadap idea ini. Dalam pengalaman saya, pembangun lebih cenderung untuk berhujah bahawa punca penting dan hubungan sebab-akibat sentiasa boleh diwujudkan dalam peristiwa. Sebaliknya, DevOps lebih kerap bersetuju bahawa dunia yang kompleks tidak selalu mematuhi lineariti.
Saya selalu tertanya-tanya mengapa ini? Apa membuat pengaturcara untuk mengkritik idea "punca utama adalah mitos" seperti itu? Seperti sistem imun yang mengenali agen asing. Mengapa mereka bertindak seperti ini, sedangkan devops agak condong pertimbangkan idea ini?
Saya tidak pasti sepenuhnya, tetapi saya mempunyai beberapa pemikiran tentang ini. Ia berkaitan dengan konteks yang berbeza di mana profesional ini menjalankan kerja harian mereka.
Pembangun sering bekerja dengan alat penentu. Sudah tentu, penyusun, penghubung, sistem pengendalian - semua ini adalah sistem yang kompleks, tetapi kami terbiasa dengan fakta bahawa mereka memberikan hasil yang menentukan, dan kami membayangkannya sebagai deterministik: jika kami menyediakan data input yang sama, maka kami biasanya mengharapkan output yang sama daripada sistem ini. Dan jika terdapat masalah dengan output ("bug"), maka pembangun menyelesaikannya dengan menganalisis data input (sama ada dari pengguna atau dari satu set alat semasa proses pembangunan). Mereka mencari "ralat" dan kemudian menukar data input. Ini membetulkan "pepijat".
Andaian asas pembangunan perisian: data input yang sama boleh dipercayai dan secara deterministik menghasilkan output yang sama.
Malah, hasil bukan penentu itu sendiri dianggap sebagai pepijat: jika output yang tidak dijangka atau salah tidak dihasilkan semula, maka pembangun cenderung untuk melanjutkan penyiasatan ke bahagian lain tindanan (sistem pengendalian, rangkaian, dll.), yang juga berkelakuan lebih kurang secara deterministik, menghasilkan hasil yang sama dengan data input yang sama... dan jika tidak begitu, maka ini masih dianggap pepijat. Ia baru sahaja sistem pengendalian atau pepijat rangkaian.
Walau apa pun, determinisme adalah andaian asas, hampir diambil mudah untuk kebanyakan pengaturcara kerja lakukan.
Tetapi bagi mana-mana lelaki devops yang menghabiskan masa seharian mengumpul perkakasan atau memikirkan API awan, idea tentang dunia yang benar-benar deterministik (selagi mungkin untuk memetakan semua input!) adalah konsep yang sekejap sahaja. Walaupun anda meletakkannya di tepi , jurutera berpengalaman telah melihat perkara yang paling pelik di dunia ini. Mereka tahu itu , apatah lagi berjuta-juta faktor lain dalam persekitaran.
Jadi lebih mudah bagi jurutera berpengalaman untuk meragui bahawa semua insiden mempunyai punca tunggal, dan teknik seperti "Lima Mengapa" akan dengan betul (dan berulang!) membawa kepada punca itu. Malah, ini bercanggah dengan pengalaman mereka sendiri, di mana kepingan teka-teki tidak sesuai dengan begitu kemas dalam amalan. Oleh itu, mereka menerima idea ini dengan lebih mudah.
Sudah tentu, saya tidak mengatakan bahawa pembangun adalah naif, bodoh, atau tidak dapat memahami bagaimana lineariti boleh menipu.
Tetapi nampaknya saya reaksi biasa daripada pemaju dalam perbahasan ini selalunya berkaitan dengan fakta bahawa konsep determinisme melayani mereka dengan baik secara keseluruhan dalam kerja seharian. Mereka tidak menghadapi ketidakpastian sekerap jurutera terpaksa menangkap kucing Schrödinger pada infrastruktur mereka.
Ini mungkin tidak menjelaskan sepenuhnya tindak balas pembangun yang diperhatikan, tetapi ia adalah peringatan yang kuat bahawa tindak balas kami adalah gabungan kompleks daripada banyak faktor.
Adalah penting untuk mengingati kerumitan ini, sama ada kita berurusan dengan satu kejadian, bekerjasama dalam saluran penghantaran perisian atau cuba memahami dunia yang lebih luas.
Sumber: www.habr.com