Програмери, devops и мачки на Шредингер

Реалноста на мрежен инженер (со тестенини и... сол?)

Неодамна, додека разговарав за разни инциденти со инженерите, забележав интересна шема.

Во овие дискусии, секогаш се поставува прашањето за „основната причина“. Верните читатели веројатно знаат дека имам некои мисли на оваа за. Во многу организации, анализата на инциденти целосно се заснова на овој концепт. Тие користат различни техники за идентификување на причинско-последичните врски, како на пр „Пет зошто“. Овие методи ја претпоставуваат таканаречената „линеарност на настаните“ како неоспорна догма.

Кога ќе ја оспорите оваа идеја и ќе истакнете дека линеарноста е смирувачки измамничка во сложените системи, се раѓа фасцинантна дискусија. Споровите страсно инсистираат дека само знаењето за „основната причина“ ни овозможува да разбереме што се случува.

Забележав интересна шема: развивачите и развивачите реагираат поинаку на оваа идеја. Според моето искуство, програмерите се со поголема веројатност да тврдат дека основната причина е важна и дека причинско-последичните односи секогаш може да се воспостават во настани. Од друга страна, DevOps почесто се согласуваат дека сложениот свет не секогаш се покорува на линеарноста.

Секогаш се прашував зошто е тоа? Што прави програмерите да ја критикуваат идејата „основната причина е мит“ вака? Како имунолошки систем кој препознава странски агент. Зошто реагираат вака, додека девопс прилично наклонет размислете за оваа идеја?

Не сум сосема сигурен, но имам некои размислувања за ова. Тоа се однесува на различните контексти во кои овие професионалци ја извршуваат својата секојдневна работа.

Програмерите често работат со детерминистички алатки. Се разбира, компајлери, поврзувачи, оперативни системи се сите сложени системи, но ние сме навикнати на фактот дека тие даваат детерминистички резултат и ги замислуваме како детерминистички: ако ги обезбедиме истите влезни податоци, тогаш обично очекуваме ист излез од овие системи. И ако има проблем со излезот („бубачки“), тогаш програмерите го решаваат со анализа на влезните податоци (или од корисникот или од збир на алатки за време на процесот на развој). Бараат „грешка“ и потоа ги менуваат влезните податоци. Ова ја поправа „бубачката“.

Основна претпоставка за развој на софтвер: истите влезни податоци веродостојно и детерминистички го произведуваат истиот излез.

Всушност, недетерминистичкиот резултат сам по себе се смета за грешка: ако неочекуваниот или погрешниот излез не се репродуцира, тогаш програмерите имаат тенденција да ја прошират истрагата на други делови од стекот (оперативен систем, мрежа итн.) кои исто така се однесуваат повеќе или помалку детерминистички, произведувајќи ист резултат со исти влезни податоци... и ако не е, тогаш ова сè уште се смета за бубачка. Само сега е грешка во оперативниот систем или мрежата.

Во секој случај, детерминизмот е основна, речиси земена здраво за готово претпоставка за голем дел од работата што ја прават програмерите.

Но, за секој девоп кој го поминал денот собирајќи хардвер или смислувајќи облак API, идејата за целосно детерминистички свет (се додека е можно дури и да се мапираат сите влезови!) во најдобар случај е минлив концепт. Дури и ако го оставите настрана BOHF се шегува за сончевите дамки, искусни инженери ги виделе најчудните работи на овој свет. Тие го знаат тоа дури и човечки крик може да го забави серверот, да не зборуваме за милиони други фактори во животната средина.

Така, на искусните инженери им е полесно да се сомневаат дека сите инциденти имаат една основна причина, а техниките како „Петте зошто“ правилно (и постојано!) ќе доведат до таа основна причина. Всушност, ова е во спротивност со нивното сопствено искуство, каде што парчињата од сложувалката не се вклопуваат толку уредно во пракса. Затоа, тие полесно ја прифаќаат оваа идеја.

Се разбира, не велам дека програмерите се наивни, глупави или не можат да разберат како линеарноста може да биде измамничка. Искусните програмери веројатно исто така виделе многу недетерминизам во своето време.

Но, ми се чини дека вообичаената реакција на програмерите во овие дебати често е поврзана со фактот дека концептот на детерминизам добро им служи во целина во секојдневната работа. Тие не се среќаваат со недетерминизам толку често колку што инженерите мораат да ги фатат мачките на Шредингер на нивната инфраструктура.

Ова можеби нема целосно да ги објасни набљудуваните реакции на развивачите, но е моќен потсетник дека нашите реакции се сложена мешавина од многу фактори.

Важно е да се запамети оваа сложеност, без разлика дали се занимаваме со еден инцидент, соработуваме на цевка за испорака на софтвер или се обидуваме да го разбереме поширокиот свет.

Извор: www.habr.com