Програмисти, devops и котките на Шрьодингер

Реалността на мрежовия инженер (с юфка и... сол?)

Наскоро, докато обсъждах различни инциденти с инженери, забелязах интересен модел.

В тези дискусии неизменно възниква въпросът за „първопричината“. Верните читатели вероятно знаят, че имам малко мисли на това на. В много организации анализът на инциденти се основава изцяло на тази концепция. Те използват различни техники за идентифициране на причинно-следствени връзки, като напр "Пет защо". Тези методи приемат така наречената „линейност на събитията” като неоспорима догма.

Когато оспорите тази идея и посочите, че линейността е успокоително измамна в сложни системи, се ражда завладяваща дискусия. Спорниците страстно настояват, че само познаването на „първопричината“ ни позволява да разберем какво се случва.

Забелязах интересен модел: разработчиците и devops реагират различно на тази идея. Според моя опит разработчиците са по-склонни да твърдят, че основната причина има значение и че причинно-следствените връзки винаги могат да бъдат установени в събитията. От друга страна, DevOps по-често се съгласяват, че сложният свят не винаги се подчинява на линейността.

Винаги съм се чудил защо е така? Какво марки програмисти да критикуват идеята „първопричината е мит“ така? Като имунна система, която разпознава чужд агент. Защо те реагират по този начин, докато devops по-скоро наклонен обмислете тази идея?

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

Разработчиците често работят с детерминистични инструменти. Разбира се, компилатори, линкери, операционни системи - всичко това са сложни системи, но ние сме свикнали с факта, че те дават детерминиран резултат и си ги представяме като детерминирани: ако предоставим едни и същи входни данни, тогава обикновено очакваме същия изход от тези системи. И ако има проблем с изхода („бъг“), тогава разработчиците го решават чрез анализиране на входните данни (или от потребителя, или от набор от инструменти по време на процеса на разработка). Те търсят "грешка" и след това променят входните данни. Това коригира "бъга".

Основно допускане на разработката на софтуер: едни и същи входни данни надеждно и детерминистично произвеждат същия изход.

Всъщност недетерминистичният резултат сам по себе си се счита за грешка: ако неочакваният или грешен изход не бъде възпроизведен, тогава разработчиците са склонни да разширят разследването към други части на стека (операционна система, мрежа и т.н.), които също се държат повече или по-малко детерминистично, произвеждайки същия резултат със същите входни данни... и ако това не е така, тогава това все още се счита за грешка. Просто сега е грешка в операционната система или мрежата.

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

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

Така че за опитните инженери е по-лесно да се съмняват, че всички инциденти имат една единствена първопричина и техники като „Петте защо“ правилно (и многократно!) ще доведат до тази основна причина. Всъщност това противоречи на техния собствен опит, където парчетата на пъзела не пасват толкова добре на практика. Затова те приемат тази идея по-лесно.

Разбира се, не казвам, че разработчиците са наивни, глупави или неспособни да разберат как линейността може да бъде измамна. Опитните програмисти вероятно също са виждали много недетерминизъм в своето време.

Но ми се струва, че общата реакция на разработчиците в тези дебати често е свързана с факта, че концепцията за детерминизма като цяло ги обслужва добре в ежедневната работа. Те не срещат недетерминизъм толкова често, колкото инженерите трябва да хващат котките на Шрьодингер в тяхната инфраструктура.

Това може да не обясни напълно наблюдаваните реакции на разработчиците, но е силно напомняне, че нашите реакции са сложна смес от много фактори.

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

Източник: www.habr.com