Желілік инженердің шындығы (кеспе және... тұзбен?)
Жақында инженерлермен түрлі оқиғаларды талқылағанда мен бір қызық заңды байқадым.
Бұл талқылауларда «түбірлік себеп» мәселесі үнемі көтеріледі. Сенімді оқырмандар менде бар екенін білетін шығар туралы . Көптеген ұйымдарда оқиғаларды талдау толығымен осы тұжырымдамаға негізделген. Олар себеп-салдар байланыстарын анықтау үшін әртүрлі әдістерді пайдаланады, мысалы . Бұл әдістер даусыз догма ретінде «оқиғалардың сызықтылығы» деп аталады.
Сіз бұл идеяға қарсы шығып, күрделі жүйелерде сызықтылықтың сенімді түрде алдамшы екенін көрсеткенде, қызықты пікірталас туады. Дауласушылар тек «түбірлік себеп» туралы білу бізге не болып жатқанын түсінуге мүмкіндік береді деп ынтық айтады.
Мен қызықты үлгіні байқадым: әзірлеушілер мен әзірлеушілер бұл идеяға әртүрлі әрекет етеді. Менің тәжірибемде әзірлеушілер түпкі себеп маңызды екенін және оқиғаларда себеп-салдар байланыстары әрқашан орнатылуы мүмкін екенін дәлелдейді. Екінші жағынан, DevOps күрделі әлем әрқашан сызықтыққа бағынбайтынымен жиі келіседі.
Мен әрқашан неге бұлай деп ойладым? Не жасайды бағдарламашылар «негізгі себеп - миф» идеясын сынай ма? Шетелдік агентті танитын иммундық жүйе сияқты. Неліктен олар бұлай әрекет етеді, ал девоптар біршама бейім бұл идеяны қарастырыңыз ба?
Мен толық сенімді емеспін, бірақ менде бұл туралы кейбір ойлар бар. Бұл кәсіпқойлар күнделікті жұмысын орындайтын әртүрлі контексттерге қатысты.
Әзірлеушілер детерминирленген құралдармен жиі жұмыс істейді. Әрине, компиляторлар, сілтемелер, операциялық жүйелер - барлығы күрделі жүйелер, бірақ біз олардың детерминирленген нәтиже беретініне үйреніп қалғанбыз және біз оларды детерминирленген деп елестетеміз: егер біз бірдей кіріс деректерін берсек, онда біз әдетте бірдей нәтижені күтеміз. осы жүйелерден. Ал егер шығаруға қатысты мәселе («қате») болса, әзірлеушілер оны кіріс деректерін талдау арқылы шешеді (пайдаланушыдан немесе әзірлеу барысындағы құралдар жиынтығынан). Олар «қате» іздейді, содан кейін кіріс деректерін өзгертеді. Бұл «қатені» түзетеді.
Бағдарламалық жасақтаманы әзірлеудің негізгі болжамы: бірдей кіріс деректері сенімді және детерминирленген түрде бірдей нәтиже береді.
Шын мәнінде, детерминирленген емес нәтиженің өзі қате болып саналады: егер күтпеген немесе қате нәтиже шығарылмаса, әзірлеушілер зерттеуді стектің басқа бөліктеріне (операциялық жүйе, желі және т.б.) кеңейтуге бейім, олар да көбірек әрекет етеді. немесе азырақ детерминирленген, бірдей кіріс деректерімен бірдей нәтижені шығару... және егер олай болмаса, онда бұл әлі де қате болып саналады. Бұл енді ғана операциялық жүйе немесе желі қатесі.
Қалай болғанда да, детерминизм - бұл бағдарламашылардың көпшілігі үшін негізгі, дерлік қабылданған болжам.
Бірақ күні бойы аппараттық құралдарды жинақтаумен немесе бұлтты API құрумен айналысқан кез келген девопс жігіті үшін толығымен детерминирленген әлем идеясы (барлық кірістерді картаға түсіру мүмкін болғанша!) ең жақсы жағдайда тез өтетін тұжырымдама. Бір жағына қойсаңыз да , тәжірибелі инженерлер бұл әлемдегі ең оғаш нәрселерді көрді. Олар мұны біледі , қоршаған ортадағы миллиондаған басқа факторларды айтпағанда.
Сондықтан тәжірибелі инженерлерге барлық оқиғалардың бір түп себебі бар екеніне күмәндану оңайырақ және «Бес неліктен» сияқты әдістер сол негізгі себепке дұрыс (және қайталанатын!) әкеледі. Шын мәнінде, бұл басқатырғыш бөліктері іс жүзінде соншалықты ұқыпты сәйкес келмейтін өздерінің тәжірибесіне қайшы келеді. Сондықтан олар бұл идеяны оңайырақ қабылдайды.
Әрине, мен әзірлеушілер аңғал, ақымақ немесе сызықтылықтың алдамшы болуы мүмкін екенін түсінбейді деп айтпаймын.
Бірақ менің ойымша, бұл пікірталастарда әзірлеушілердің ортақ реакциясы көбінесе детерминизм тұжырымдамасына байланысты. оларға жалпы жақсы қызмет етеді күнделікті жұмыста. Инженерлер өз инфрақұрылымында Шредингердің мысықтарын ұстауға тура келетіндей, олар детерминизммен жиі кездеспейді.
Бұл әзірлеушілердің байқалған реакцияларын толық түсіндірмеуі мүмкін, бірақ бұл біздің реакцияларымыз көптеген факторлардың күрделі қоспасы екенін еске салады.
Бұл күрделілікті есте сақтау маңызды, мейлі біз бір оқиғамен айналысамыз ба, бағдарламалық қамтамасыз етуді жеткізу құбырында бірлесіп жұмыс жасаймыз ба немесе кеңірек әлемді түсінуге тырысамыз.
Ақпарат көзі: www.habr.com