Tīkla inženiera realitāte (ar nūdelēm un... sāli?)
Nesen, pārrunājot dažādus incidentus ar inženieriem, pamanīju interesantu modeli.
Šajās diskusijās vienmēr tiek aktualizēts jautājums par “galveno cēloni”. Uzticīgie lasītāji droši vien zina, ka man ir par . Daudzās organizācijās incidentu analīze pilnībā balstās uz šo koncepciju. Viņi izmanto dažādas metodes, lai noteiktu cēloņu un seku attiecības, piemēram, . Šīs metodes pieņem tā saukto “notikumu linearitāti” kā neapstrīdamu dogmu.
Apstrīdot šo ideju un norādot, ka linearitāte ir pārliecinoši maldinoša sarežģītās sistēmās, rodas aizraujoša diskusija. Strīdnieki kaislīgi uzstāj, ka tikai zināšanas par “galveno cēloni” ļauj saprast notiekošo.
Es pamanīju interesantu modeli: izstrādātāji un devops uz šo ideju reaģē atšķirīgi. Mana pieredze liecina, ka izstrādātāji biežāk apgalvo, ka galvenais cēlonis ir svarīgs un ka cēloņu un seku attiecības vienmēr var izveidot notikumos. No otras puses, DevOps biežāk piekrīt, ka sarežģīta pasaule ne vienmēr pakļaujas linearitātei.
Es vienmēr domāju, kāpēc tas tā ir? Kas padara programmētājiem kritizēt ideju "galvenais iemesls ir mīts"? Tāpat kā imūnsistēma, kas atpazīst svešu aģentu. Kāpēc viņi šādi reaģē, kamēr devops drīzāk sliecas apsvērt šo ideju?
Es neesmu pilnīgi pārliecināts, bet man ir dažas domas par to. Tas attiecas uz dažādiem kontekstiem, kuros šie speciālisti veic savu ikdienas darbu.
Izstrādātāji bieži strādā ar deterministiskiem rīkiem. Protams, kompilatori, linkeri, operētājsistēmas ir sarežģītas sistēmas, taču mēs esam pieraduši pie tā, ka tie dod deterministisku rezultātu, un mēs tos iztēlojamies kā deterministiskus: ja mēs sniedzam vienus un tos pašus ievades datus, tad mēs parasti sagaidām to pašu izvadi. no šīm sistēmām. Un, ja rodas problēma ar izvadi (“kļūda”), izstrādātāji to atrisina, analizējot ievades datus (vai nu no lietotāja, vai no rīku komplekta izstrādes procesa laikā). Viņi meklē "kļūdu" un pēc tam maina ievades datus. Tas novērš "kļūdu".
Programmatūras izstrādes pamatpieņēmums: vieni un tie paši ievades dati droši un deterministiski rada vienu un to pašu izvadi.
Faktiski nedeterministisks rezultāts pats par sevi tiek uzskatīts par kļūdu: ja neparedzētā vai kļūdainā izvade netiek reproducēta, izstrādātājiem ir tendence paplašināt izmeklēšanu uz citām steka daļām (operētājsistēmu, tīklu utt.), kas arī darbojas vairāk. vai mazāk deterministiski, radot to pašu rezultātu ar tiem pašiem ievades datiem... un ja tas tā nav, tad šī joprojām tiek uzskatīta par kļūdu. Tā tikai tagad ir operētājsistēmas vai tīkla kļūda.
Jebkurā gadījumā determinisms ir pamata, gandrīz pašsaprotams pieņēmums lielai daļai programmētāju darba.
Bet ikvienam devops puisim, kurš visu dienu ir pavadījis, vācot aparatūru vai izdomājot mākoņa API, ideja par pilnīgi deterministisku pasauli (ja vien ir iespējams kartēt visas ievades!) labākajā gadījumā ir īslaicīgs jēdziens. Pat ja noliek malā , pieredzējuši inženieri ir redzējuši dīvainākās lietas šajā pasaulē. Viņi to zina , nemaz nerunājot par miljoniem citu vides faktoru.
Tāpēc pieredzējušiem inženieriem ir vieglāk apšaubīt, ka visiem incidentiem ir viens pamatcēlonis, un tādas metodes kā “Pieci iemesli” pareizi (un atkārtoti!) novedīs pie šī pamatcēloņa. Faktiski tas ir pretrunā ar viņu pašu pieredzi, kur puzles gabali praktiski nesader tik glīti. Tāpēc viņi šo ideju pieņem vieglāk.
Protams, es nesaku, ka izstrādātāji ir naivi, stulbi vai nespēj saprast, kā linearitāte var būt maldinoša.
Bet man šķiet, ka izplatītā izstrādātāju reakcija šajās debatēs bieži ir saistīta ar faktu, ka determinisma jēdziens kopumā kalpo viņiem labi ikdienas darbā. Viņi nesastopas ar nedeterminismu tik bieži, kā inženieriem savā infrastruktūrā ir jāķer Šrēdingera kaķi.
Tas var pilnībā neizskaidrot novērotās izstrādātāju reakcijas, taču tas ir spēcīgs atgādinājums, ka mūsu reakcijas ir daudzu faktoru sarežģīts sajaukums.
Ir svarīgi atcerēties šo sarežģītību neatkarīgi no tā, vai mēs saskaramies ar vienu incidentu, sadarbojamies programmatūras piegādes konveijerā vai cenšamies izprast plašāku pasauli.
Avots: www.habr.com