Рэальнасць сеткавага інжынера (з локшынай і… соллю?)
У апошні час, абмяркоўваючы з інжынерамі розныя інцыдэнты, я заўважыў цікавую заканамернасць.
У гэтых абмеркаваннях нязменна ўзнікае пытанне "першапрычыны". Дакладныя чытачы напэўна ведаюць, што ў мяне ёсць па . У многіх арганізацыях аналіз інцыдэнтаў поўнасцю заснаваны на гэтай канцэпцыі. Яны выкарыстоўваюць розныя тэхнікі выяўлення прычынна-выніковых сувязяў, такія як . Гэтыя метады мяркуюць так званую "лінейнасць падзей" як бясспрэчную догму.
Калі вы падвяргаеце сумневу гэтую ідэю і паказваеце на тое, што ў складаных сістэмах лінейнасць заспакаяльна зманлівая, тое нараджаецца займальная дыскусія. Спрэчшчыкі горача настойваюць, што толькі веданне «першапрычыны» дазваляе зразумець тое, што адбываецца.
Я заўважыў цікавую заканамернасць: распрацоўшчыкі і дэвопсы па-рознаму рэагуюць на гэтую ідэю. На маю вопыту, распрацоўшчыкі часцей сцвярджаюць, што першапрычына мае значэнне і што ў падзеях заўсёды можна ўсталяваць прычынна-выніковыя сувязі. З іншага боку, дэвопсы часцей згаджаюцца, што складаны свет не заўсёды падпарадкоўваецца лінейнасці.
Я заўсёды задавалася пытаннем, чаму так? Што прымушае праграмістаў так крытыкаваць ідэю «першапрычына - міф»? Нібы імунную сістэму, якая распазнае іншароднага агента. Чаму яны так рэагуюць, у той час як дэвапсы хутчэй схільныя разгледзець гэтую ідэю?
Я не зусім упэўнены, але ёсць меркаванне на гэты конт. Яно звязана з рознымі кантэкстамі, у якіх гэтыя прафесіяналы выконваюць паўсядзённае працу.
Распрацоўнікі часта працуюць з дэтэрмінаванымі прыладамі. Вядома, кампілятары, кампаноўшчыкі, аперацыёнкі — усё гэта складаныя сістэмы, але мы прывыклі, што яны даюць дэтэрмінаваны вынік, і прадстаўляем іх менавіта дэтэрмінаванымі: калі падаць адны і тыя ж уваходныя дадзеныя, то мы звычайна чакаем ад гэтых сістэм адну і тую ж выдачу . І калі з выдачай праблема («баг»), то распрацоўнікі вырашаюць яе з дапамогай аналізу ўваходных дадзеных (альбо ад карыстача, або ад набору прылад падчас распрацоўкі). Яны шукаюць "памылку", а затым змяняюць уваходныя дадзеныя. Гэта выпраўляе "баг".
Асноўнае дапушчэнне распрацоўкі праграмнага забеспячэння: адны і тыя ж уваходныя дадзеныя надзейна і дэтэрмінавана даюць аднолькавую выдачу
Фактычна, недэтэрмінаваны вынік сам па сабе лічыцца памылкай: калі нечаканая ці памылковая выснова не прайграваецца, то распрацоўнікі імкнуцца пашырыць даследаванне на іншыя часткі стэка (аперацыйная сістэма, сетка і т. д.), якія таксама паводзяць сябе больш ці меней дэтэрмінавана, выдаючы аднолькавы вынік пры аднолькавых уваходных дадзеных… і калі гэта не так, то гэта ўсё роўна лічыцца багам. Проста зараз гэта баг аперацыйнай сістэмы ці сеткі.
У любым выпадку, дэтэрмінізм - гэта базавая, практычна само сабой якое разумеецца здагадка для большай часткі працы, якую робяць праграмісты.
Але для любога дэвопса, які правёў дзень, збіраючы жалеза ў стойкі або разбіраючыся з хмарным API, ідэя цалкам дэтэрмінаванага свету (датуль, пакуль наогул ёсць магчымасць адлюстраваць усе ўваходныя дадзеныя!) - у лепшым выпадку, мімалётнае паняцце. Нават калі адкінуць у бок , вопытныя інжынеры бачылі ў гэтым свеце самыя дзіўныя рэчы. Яны ведаюць, што , не кажучы аб мільёнах іншых фактараў у навакольным асяроддзі.
Так што дасведчаным інжынерам прасцей усумніцца, што ва ўсіх інцыдэнтаў ёсць адзіная першапрычына, а тэхнікі накшталт "Пяць чаму" дакладна (і паўтарана!) прывядуць да гэтай першапрычыны. Па сутнасці, гэта супярэчыць іх уласнаму досведу, калі кавалачкі галаваломкі на практыцы не складаюцца настолькі выразна. Таму яны лягчэй успрымаюць гэтую ідэю.
Вядома, я не кажу, што распрацоўшчыкі наіўныя, дурныя ці няздольныя зразумець, як лінейнасць можа быць зманлівая.
Але мне здаецца, што звычайная рэакцыя ад распрацоўшчыкаў у гэтых спрэчках часта звязана з тым фактам, што канцэпцыя дэтэрмінізму у цэлым добра служыць ім у паўсядзённай працы. Яны сутыкаюцца з недэтэрмінізмам не так часта, як інжынерам даводзіцца лавіць катоў Шрэдынгера на сваёй інфраструктуры.
Можа, гэта не цалкам тлумачыць назіраныя рэакцыі распрацоўнікаў, але гэта магутны напамін, што нашы рэакцыі ўяўляюць сабой складаную сумесь са шматлікіх фактараў.
Важна памятаць аб гэтай складанасці, незалежна ад таго, разбіраны мы адзін інцыдэнт ці супрацоўнічаем на канвееры дастаўкі праграмнага забеспячэння, ці спрабуем асэнсаваць шырэйшы мір.
Крыніца: habr.com