Tinklo inžinieriaus realybė (su makaronais ir... druska?)
Neseniai, aptardamas įvairius incidentus su inžinieriais, pastebėjau įdomų modelį.
Šiose diskusijose visada iškyla „pagrindinės priežasties“ klausimas. Tikrieji skaitytojai tikriausiai žino, kad aš apie . Daugelyje organizacijų incidentų analizė visiškai pagrįsta šia koncepcija. Priežasties ir pasekmės ryšiams nustatyti jie naudoja skirtingus metodus, pvz . Šie metodai reiškia vadinamąjį „įvykių tiesiškumą“ kaip neginčijamą dogmą.
Kai ginčijate šią idėją ir nurodote, kad tiesiškumas yra patikimai apgaulingas sudėtingose sistemose, užgimsta įdomi diskusija. Ginčininkai aistringai tvirtina, kad tik žinojimas apie „pagrindinę priežastį“ leidžia suprasti, kas vyksta.
Pastebėjau įdomų modelį: kūrėjai ir devopai į šią idėją reaguoja skirtingai. Mano patirtis rodo, kad kūrėjai labiau linkę ginčytis, kad pagrindinė priežastis yra svarbi ir kad įvykiuose visada galima nustatyti priežasties ir pasekmės ryšius. Kita vertus, DevOps dažniau sutinka, kad sudėtingas pasaulis ne visada paklūsta tiesiškumui.
Aš visada galvojau, kodėl taip yra? Ką gamina programuotojai taip kritikuoja idėją „pagrindinė priežastis yra mitas“? Kaip imuninė sistema, kuri atpažįsta svetimą agentą. Kodėl jie taip reaguoja, o devops veikiau linkęs apsvarstyti šią idėją?
Nesu visiškai tikras, bet turiu tam tikrų minčių šiuo klausimu. Tai susiję su įvairiais kontekstais, kuriuose šie specialistai atlieka savo kasdienį darbą.
Kūrėjai dažnai dirba su deterministiniais įrankiais. Žinoma, kompiliatoriai, linkeriai, operacinės sistemos – visa tai sudėtingos sistemos, tačiau mes esame įpratę, kad jos duoda deterministinį rezultatą, ir įsivaizduojame juos kaip deterministinius: jei pateikiame tuos pačius įvesties duomenis, tada dažniausiai tikimės ta pati šių sistemų produkcija. O jei kyla problemų dėl išvesties („klaidos“), tai kūrėjai ją išsprendžia analizuodami įvesties duomenis (arba iš vartotojo, arba iš įrankių rinkinio kūrimo proceso metu). Jie ieško „klaidos“ ir tada pakeičia įvesties duomenis. Tai ištaiso „klaidą“.
Pagrindinė programinės įrangos kūrimo prielaida: tie patys įvesties duomenys patikimai ir deterministiškai sukuria tą pačią išvestį.
Tiesą sakant, nedeterministinis rezultatas pats savaime laikomas klaida: jei netikėta ar klaidinga išvestis neatkuriama, kūrėjai linkę išplėsti tyrimą į kitas dėklo dalis (operacinės sistemos, tinklo ir kt.), kurios taip pat elgiasi. daugiau ar mažiau deterministiškai, sukuriant tą patį rezultatą su tais pačiais įvesties duomenimis... ir jei taip nėra, tai vis tiek laikoma klaida. Tai tik dabar operacinės sistemos arba tinklo klaida.
Bet kuriuo atveju determinizmas yra pagrindinė, beveik savaime suprantama prielaida, kurią daro dauguma programuotojų.
Tačiau bet kuriam devops vyrui, kuris visą dieną renkasi aparatinę įrangą ar aiškinasi debesies API, visiškai deterministinio pasaulio idėja (jei net įmanoma susieti visas įvestis!) geriausiu atveju yra trumpalaikė koncepcija. Net jei atidėsi į šalį , patyrę inžinieriai matė keisčiausius dalykus šiame pasaulyje. Jie tai žino , jau nekalbant apie milijonus kitų aplinkos veiksnių.
Taigi patyrusiems inžinieriams lengviau abejoti, ar visi incidentai turi vieną pagrindinę priežastį, o tokie metodai kaip „Penkios priežastys“ teisingai (ir pakartotinai!) sukels tą pagrindinę priežastį. Tiesą sakant, tai prieštarauja jų pačių patirčiai, kai dėlionės detalės praktiškai netelpa taip tvarkingai. Todėl jie lengviau priima šią idėją.
Žinoma, nesakau, kad kūrėjai yra naivūs, kvaili ar nesugeba suprasti, kaip tiesiškumas gali būti apgaulingas.
Tačiau man atrodo, kad dažna kūrėjų reakcija šiose diskusijose dažnai yra susijusi su tuo, kad determinizmo samprata apskritai jiems puikiai tarnauja kasdieniame darbe. Jie nesusiduria su nedeterminizmu taip dažnai, kaip inžinieriai turi gaudyti Schrödingerio kates savo infrastruktūroje.
Tai gali nevisiškai paaiškinti pastebėtas kūrėjo reakcijas, tačiau tai yra galingas priminimas, kad mūsų reakcijos yra sudėtingas daugelio veiksnių mišinys.
Svarbu atsiminti šį sudėtingumą, nesvarbu, ar susiduriame su vienu incidentu, bendradarbiaujame kuriant programinės įrangos tiekimą, ar bandome suprasti platesnį pasaulį.
Šaltinis: www.habr.com