Ցանցային ինժեների իրականությունը (արիշտա ու... աղո՞վ)
Վերջերս ինժեներների հետ տարբեր միջադեպեր քննարկելիս մի հետաքրքիր օրինաչափություն նկատեցի.
Այս քննարկումներում անընդհատ առաջանում է «հիմնական պատճառի» հարցը: Հավատարիմ ընթերցողները հավանաբար գիտեն, որ ես գիտեմ մասին . Շատ կազմակերպություններում միջադեպերի վերլուծությունն ամբողջությամբ հիմնված է այս հայեցակարգի վրա: Նրանք օգտագործում են տարբեր մեթոդներ՝ պատճառահետևանքային հարաբերությունները բացահայտելու համար, ինչպիսիք են . Այս մեթոդները ենթադրում են այսպես կոչված «իրադարձությունների գծայինությունը» որպես անվիճելի դոգմա։
Երբ դուք վիճարկում եք այս գաղափարը և նշում, որ գծայինությունը վստահաբար խաբուսիկ է բարդ համակարգերում, սկսվում է հետաքրքրաշարժ քննարկում: Վիճաբանողները կրքոտ պնդում են, որ միայն «հիմնական պատճառի» իմացությունը թույլ է տալիս հասկանալ, թե ինչ է կատարվում:
Ես նկատեցի մի հետաքրքիր օրինաչափություն. ծրագրավորողները և մշակողները տարբեր կերպ են արձագանքում այս գաղափարին: Իմ փորձից ելնելով, ծրագրավորողները ավելի հավանական է պնդում, որ հիմնական պատճառը կարևոր է, և որ պատճառահետևանքային հարաբերությունները միշտ կարող են հաստատվել իրադարձությունների ժամանակ: Մյուս կողմից, DevOps-ները ավելի հաճախ համաձայնում են, որ բարդ աշխարհը միշտ չէ, որ ենթարկվում է գծայինությանը:
Ես միշտ մտածում էի, թե ինչու է սա: Ինչ կազմում է ծրագրավորողները նման կերպ քննադատե՞ն «հիմնական պատճառը առասպելն է» գաղափարը: Ինչպես իմունային համակարգը, որը ճանաչում է օտար գործակալին: Ինչո՞ւ են նրանք այսպես արձագանքում, մինչդեռ դեվոպս բավականին հակված հաշվի առնել այս գաղափարը.
Ես լիովին վստահ չեմ, բայց ես որոշ մտքեր ունեմ այս մասին: Այն վերաբերում է տարբեր համատեքստերին, որոնցում այս մասնագետներն իրականացնում են իրենց ամենօրյա աշխատանքը:
Մշակողները հաճախ աշխատում են դետերմինիստական գործիքներով: Իհարկե, կոմպիլյատորներ, կապողներ, օպերացիոն համակարգեր՝ այս ամենը բարդ համակարգեր են, բայց մենք սովոր ենք, որ դրանք տալիս են դետերմինիստական արդյունք, և մենք դրանք պատկերացնում ենք որպես դետերմինիստական. եթե մենք տրամադրում ենք նույն մուտքային տվյալները, ապա սովորաբար ակնկալում ենք. նույն ելքը այս համակարգերից: Իսկ եթե ելքի հետ կապված խնդիր կա («bug»), ապա մշակողները լուծում են այն՝ վերլուծելով մուտքագրված տվյալները (կամ օգտատիրոջից, կամ մշակման գործընթացի ընթացքում մի շարք գործիքներից)։ Նրանք փնտրում են «սխալ», իսկ հետո փոխում են մուտքագրված տվյալները: Սա ուղղում է «սխալը»:
Ծրագրային ապահովման մշակման հիմնական ենթադրությունը. միևնույն մուտքային տվյալները հուսալիորեն և վճռականորեն տալիս են նույն արդյունքը:
Իրականում, ոչ դետերմինիստական արդյունքն ինքնին համարվում է վրիպակ. եթե անսպասելի կամ սխալ արդյունքը չի վերարտադրվում, ապա մշակողները հակված են հետաքննությունը ընդլայնել փաթեթի այլ մասերի վրա (օպերացիոն համակարգ, ցանց և այլն), որոնք նույնպես վարվում են: քիչ թե շատ դետերմինիստականորեն՝ նույն ներածական տվյալներով նույն արդյունքը արտադրելով... և եթե դա չէ, ապա սա դեռ համարվում է սխալ: Դա հենց հիմա օպերացիոն համակարգի կամ ցանցի վրիպակ է:
Ամեն դեպքում, դետերմինիզմը հիմնական, գրեթե ընդունված ենթադրություն է ծրագրավորողների մեծ մասի աշխատանքի համար:
Բայց ցանկացած զարգացող տղայի համար, ով օրն անցկացրել է սարքավորում հավաքելու կամ ամպային API պարզելու վրա, լիովին դետերմինիստական աշխարհի գաղափարը (քանի դեռ հնարավոր է նույնիսկ քարտեզագրել բոլոր մուտքերը) լավագույն դեպքում անցողիկ հասկացություն է: Նույնիսկ եթե մի կողմ դնես , փորձառու ինժեներները տեսել են այս աշխարհի ամենատարօրինակ բաները։ Նրանք դա գիտեն , էլ չեմ խոսում շրջակա միջավայրի միլիոնավոր այլ գործոնների մասին։
Այսպիսով, փորձառու ինժեներների համար ավելի հեշտ է կասկածել, որ բոլոր միջադեպերն ունեն մեկ հիմնական պատճառ, և «Հինգ ինչու»-ի նման տեխնիկան ճիշտ (և կրկնվող!) կհանգեցնի այդ հիմնական պատճառին: Իրականում դա հակասում է նրանց սեփական փորձին, որտեղ փազլի կտորները գործնականում այնքան էլ կոկիկ չեն տեղավորվում: Ուստի նրանք ավելի հեշտ են ընդունում այս միտքը։
Իհարկե, ես չեմ ասում, որ մշակողները միամիտ են, հիմար են կամ չեն կարողանում հասկանալ, թե ինչպես կարող է գծայինությունը խաբուսիկ լինել:
Բայց ինձ թվում է, որ այս բանավեճերում մշակողների ընդհանուր արձագանքը հաճախ կապված է այն փաստի հետ, որ դետերմինիզմ հասկացությունը ընդհանուր առմամբ լավ է ծառայում նրանց առօրյա աշխատանքում. Նրանք այնքան հաճախ չեն հանդիպում ոչ դետերմինիզմի, քանի որ ինժեներները ստիպված են լինում բռնել Շրյոդինգերի կատուներին իրենց ենթակառուցվածքում:
Սա կարող է լիովին չբացատրել դիտարկվող մշակողների ռեակցիաները, բայց դա հզոր հիշեցում է, որ մեր ռեակցիաները բազմաթիվ գործոնների բարդ խառնուրդ են:
Կարևոր է հիշել այս բարդությունը՝ անկախ նրանից՝ գործ ունենք մեկ դեպքի հետ, համագործակցում ենք ծրագրային ապահովման մատակարարման խողովակաշարի վրա, թե փորձում ենք հասկանալ ավելի լայն աշխարհը:
Source: www.habr.com