Tarmoq muhandisining haqiqati (noodle va ... tuz bilanmi?)
Yaqinda muhandislar bilan turli hodisalarni muhokama qilayotib, men qiziq bir naqshga e'tibor qaratdim.
Ushbu munozaralarda doimo "asosiy sabab" degan savol tug'iladi. Ishonchli kitobxonlar menda borligini bilishsa kerak haqida . Ko'pgina tashkilotlarda hodisalarni tahlil qilish butunlay ushbu kontseptsiyaga asoslanadi. Ular sabab-oqibat munosabatlarini aniqlash uchun turli usullardan foydalanadilar, masalan . Ushbu usullar "voqealarning chiziqliligi" deb ataladigan narsani shubhasiz dogma sifatida qabul qiladi.
Ushbu g'oyaga qarshi chiqsangiz va murakkab tizimlarda chiziqlilik ishonchli tarzda aldamchi ekanligini ta'kidlaganingizda, qiziqarli munozara tug'iladi. Ehtiros bilan ta'kidlashicha, "asosiy sabab" ni bilish bizga nima bo'layotganini tushunishga imkon beradi.
Men qiziqarli naqshga e'tibor qaratdim: ishlab chiquvchilar va devoplar bu g'oyaga boshqacha munosabatda bo'lishadi. Mening tajribamga ko'ra, ishlab chiquvchilar ko'proq asosiy sabab muhim va sabab-oqibat munosabatlari har doim voqealarda o'rnatilishi mumkinligi haqida bahslashadilar. Boshqa tomondan, DevOps ko'pincha murakkab dunyo har doim ham chiziqlilikka bo'ysunmasligiga qo'shiladi.
Men har doim o'ylab qoldim, nega bu? Nima qiladi dasturchilar "asosiy sabab afsonadir" degan fikrni shu kabi tanqid qilish uchunmi? Chet el agentini tan oladigan immunitet tizimi kabi. Nega ular shunday munosabatda bo'lishadi, devoplar esa ancha moyil bu fikrni ko'rib chiqasizmi?
Men to'liq ishonchim komil emas, lekin bu haqda ba'zi fikrlarim bor. Bu ushbu mutaxassislar kundalik ishlarini bajaradigan turli kontekstlarga tegishli.
Ishlab chiquvchilar ko'pincha deterministik vositalar bilan ishlaydi. Albatta, kompilyatorlar, bog'lovchilar, operatsion tizimlar hammasi murakkab tizimlardir, lekin biz ular deterministik natija berishiga o'rganib qolganmiz va biz ularni deterministik deb tasavvur qilamiz: agar biz bir xil kiritilgan ma'lumotlarni taqdim qilsak, biz odatda bir xil chiqishni kutamiz. bu tizimlardan. Va agar chiqish bilan bog'liq muammo bo'lsa ("xato"), unda ishlab chiquvchilar uni kiritilgan ma'lumotlarni tahlil qilish orqali hal qilishadi (foydalanuvchidan yoki ishlab chiqish jarayonida vositalar to'plamidan). Ular "xato" izlaydilar va keyin kiritilgan ma'lumotlarni o'zgartiradilar. Bu "xato" ni tuzatadi.
Dasturiy ta'minotni ishlab chiqishning asosiy taxmini: bir xil kirish ma'lumotlari ishonchli va aniq bir xil natijani beradi.
Aslida, deterministik bo'lmagan natijaning o'zi xato deb hisoblanadi: agar kutilmagan yoki noto'g'ri natija takrorlanmasa, ishlab chiquvchilar tekshiruvni stekning boshqa qismlariga (operatsion tizim, tarmoq va boshqalar) ham ko'proq harakat qiladilar. yoki kamroq deterministik, bir xil kirish ma'lumotlari bilan bir xil natijani ishlab chiqarish ... va agar bunday bo'lmasa, keyin bu hali ham xato deb hisoblanadi. Bu endi operatsion tizim yoki tarmoq xatosi.
Qanday bo'lmasin, determinizm dasturchilarning ko'p ishlari uchun asosiy, deyarli qabul qilingan taxmindir.
Ammo kun davomida uskunani yig'ish yoki bulutli API-ni topish bilan o'tkazgan har qanday devops yigiti uchun butunlay deterministik dunyo g'oyasi (agar barcha ma'lumotlarni xaritada ko'rsatish mumkin bo'lsa ham!) eng yaxshi tarzda o'tkinchi tushunchadir. Agar uni bir chetga surib qo'ysangiz ham , tajribali muhandislar bu dunyodagi eng g'alati narsalarni ko'rgan. Ular buni bilishadi , atrof-muhitdagi millionlab boshqa omillar haqida gapirmasa ham bo'ladi.
Shunday qilib, tajribali muhandislar uchun barcha hodisalarning bir ildiz sababi borligiga shubha qilish osonroq bo'ladi va "Beshta sabab" kabi usullar to'g'ri (va takroran!) bu asosiy sababga olib keladi. Aslida, bu jumboq qismlari amalda unchalik to'g'ri kelmaydigan o'z tajribasiga ziddir. Shuning uchun ular bu fikrni osonroq qabul qilishadi.
Albatta, men ishlab chiquvchilar sodda, ahmoq yoki chiziqlilik qanday aldamchi bo'lishi mumkinligini tushunolmaydilar deb aytmayapman.
Ammo menimcha, ushbu munozaralarda ishlab chiquvchilarning umumiy reaktsiyasi ko'pincha determinizm tushunchasi bilan bog'liq. ularga umuman xizmat qiladi kundalik ishda. Muhandislar o'z infratuzilmasida Shredingerning mushuklarini tutishlari kerak bo'lganidek, ular nodeterminizmga tez-tez duch kelishmaydi.
Bu ishlab chiquvchilarning kuzatilgan reaktsiyalarini to'liq tushuntira olmasligi mumkin, ammo bu bizning reaktsiyalarimiz ko'plab omillarning murakkab aralashmasi ekanligini kuchli eslatib turadi.
Bu murakkablikni eslab qolish muhim, xoh biz bitta hodisa bilan shug‘ullanamiz, xoh dasturiy ta’minotni yetkazib berish bo‘yicha hamkorlik qilamiz, xoh kengroq dunyoni tushunishga harakat qilamiz.
Manba: www.habr.com