Ang katotohanan ng isang network engineer (na may pansit at... asin?)
Kamakailan, habang tinatalakay ang iba't ibang mga insidente sa mga inhinyero, napansin ko ang isang kawili-wiling pattern.
Sa mga talakayang ito, ang tanong ng "ugat na sanhi" ay palaging lumalabas. Alam ng mga tapat na mambabasa na mayroon ako sa . Sa maraming organisasyon, ang pagsusuri ng insidente ay ganap na nakabatay sa konseptong ito. Gumagamit sila ng iba't ibang pamamaraan para sa pagtukoy ng mga ugnayang sanhi-at-bunga, gaya ng . Ipinapalagay ng mga pamamaraang ito ang tinatawag na "linearity of events" bilang isang hindi mapag-aalinlanganang dogma.
Kapag hinamon mo ang ideyang ito at itinuro na ang linearity ay nakatitiyak na mapanlinlang sa mga kumplikadong sistema, isang kamangha-manghang talakayan ang mabubuo. Ang mga disputants ay masigasig na iginigiit na ang kaalaman lamang sa "ugat na dahilan" ay nagpapahintulot sa amin na maunawaan kung ano ang nangyayari.
Napansin ko ang isang kawili-wiling pattern: iba ang reaksyon ng mga developer at devops sa ideyang ito. Sa aking karanasan, ang mga developer ay mas malamang na magtaltalan na ang ugat na sanhi ay mahalaga at ang sanhi-at-epekto na mga relasyon ay maaaring palaging maitatag sa mga kaganapan. Sa kabilang banda, mas madalas na sumasang-ayon ang DevOps na ang isang kumplikadong mundo ay hindi palaging sumusunod sa linearity.
Lagi kong iniisip kung bakit ganito? Ano gumagawa programmer na punahin ang ideya na "ang ugat na sanhi ay isang gawa-gawa" tulad na? Parang immune system na kumikilala sa isang dayuhang ahente. Bakit ganito ang reaksyon nila, samantalang ang mga devops medyo hilig isaalang-alang ang ideyang ito?
Hindi ako lubos na sigurado, ngunit mayroon akong ilang mga iniisip tungkol dito. Nauugnay ito sa iba't ibang konteksto kung saan isinasagawa ng mga propesyonal na ito ang kanilang pang-araw-araw na gawain.
Madalas na gumagana ang mga developer sa mga tool na deterministiko. Siyempre, ang mga compiler, linker, operating system ay lahat ng kumplikadong sistema, ngunit nasanay kami sa katotohanan na nagbibigay sila ng isang tiyak na resulta, at iniisip namin ang mga ito bilang deterministiko: kung nagbibigay kami ng parehong data ng pag-input, kadalasan ay inaasahan namin ang parehong output. mula sa mga sistemang ito. At kung may problema sa output ("bug"), pagkatapos ay malulutas ito ng mga developer sa pamamagitan ng pagsusuri sa data ng input (mula man sa user o mula sa isang hanay ng mga tool sa panahon ng proseso ng pag-unlad). Naghahanap sila ng "error" at pagkatapos ay binabago ang data ng input. Inaayos nito ang "bug".
Basic assumption ng software development: ang parehong input data ay mapagkakatiwalaan at deterministikong gumagawa ng parehong output.
Sa katunayan, ang isang hindi tiyak na resulta ay itinuturing na isang bug: kung ang hindi inaasahang o maling output ay hindi muling ginawa, kung gayon ang mga developer ay may posibilidad na palawigin ang pagsisiyasat sa iba pang bahagi ng stack (operating system, network, atbp.) na mas kumikilos din. o hindi gaanong deterministiko, na gumagawa ng parehong resulta na may parehong data ng input... at kung hindi naman, kung gayon ito ay itinuturing pa ring isang bug. Ngayon lang ito isang operating system o network bug.
Sa anumang kaso, ang determinismo ay isang pangunahing, halos kinukuha na pagpapalagay para sa karamihan ng mga gawaing programmer.
Ngunit para sa sinumang taong devops na gumugol ng araw sa pag-rack up ng hardware o pag-iisip ng cloud API, ang ideya ng isang ganap na deterministikong mundo (hangga't posible pang imapa ang lahat ng input!) ay isang panandaliang konsepto sa pinakamahusay. Kahit itabi mo pa , nakita ng mga bihasang inhinyero ang mga kakaibang bagay sa mundong ito. Alam nila yun , hindi banggitin ang milyun-milyong iba pang mga kadahilanan sa kapaligiran.
Kaya mas madaling magduda ang mga may karanasang inhinyero na ang lahat ng insidente ay may iisang ugat na dahilan, at ang mga diskarte tulad ng "Limang Bakit" ay tama (at paulit-ulit!) hahantong sa ugat na iyon. Sa katunayan, ito ay sumasalungat sa kanilang sariling karanasan, kung saan ang mga piraso ng puzzle ay hindi magkasya nang maayos sa pagsasanay. Samakatuwid, mas madali nilang tinatanggap ang ideyang ito.
Siyempre, hindi ko sinasabi na ang mga developer ay walang muwang, hangal, o hindi maintindihan kung paano maaaring maging mapanlinlang ang linearity.
Ngunit tila sa akin ang isang karaniwang reaksyon mula sa mga developer sa mga debateng ito ay kadalasang may kinalaman sa katotohanan na ang konsepto ng determinismo mahusay na nagsisilbi sa kanila sa pangkalahatan sa araw-araw na gawain. Hindi sila nakakaranas ng nondeterminism nang kasingdalas ng mga inhinyero na kailangang hulihin ang mga pusa ni Schrödinger sa kanilang imprastraktura.
Maaaring hindi nito ganap na ipaliwanag ang mga naobserbahang reaksyon ng developer, ngunit isa itong makapangyarihang paalala na ang aming mga reaksyon ay isang kumplikadong pinaghalong maraming salik.
Mahalagang tandaan ang pagiging kumplikadong ito, nakikitungo man tayo sa isang insidente, nakikipagtulungan sa isang pipeline ng paghahatid ng software, o sinusubukang maunawaan ang mas malawak na mundo.
Pinagmulan: www.habr.com