પ્રોગ્રામર્સ, ડેવોપ્સ અને શ્રોડિન્જરની બિલાડીઓ

નેટવર્ક એન્જિનિયરની વાસ્તવિકતા (નૂડલ્સ અને... મીઠું સાથે?)

તાજેતરમાં, એન્જિનિયરો સાથે વિવિધ બનાવોની ચર્ચા કરતી વખતે, મેં એક રસપ્રદ પેટર્ન નોંધ્યું.

આ ચર્ચાઓમાં, "મૂળ કારણ" નો પ્રશ્ન હંમેશા આવે છે. વફાદાર વાચકો કદાચ જાણે છે કે મારી પાસે છે કેટલાક વિચારો પર આ લગભગ. ઘણી સંસ્થાઓમાં, ઘટના વિશ્લેષણ સંપૂર્ણપણે આ ખ્યાલ પર આધારિત છે. તેઓ કારણ-અને-અસર સંબંધોને ઓળખવા માટે વિવિધ તકનીકોનો ઉપયોગ કરે છે, જેમ કે "પાંચ શા માટે". આ પદ્ધતિઓ કહેવાતા "ઇવેન્ટ્સની રેખીયતા" ને એક નિર્વિવાદ અંધવિશ્વાસ તરીકે ધારે છે.

જ્યારે તમે આ વિચારને પડકાર આપો છો અને નિર્દેશ કરો છો કે જટિલ પ્રણાલીઓમાં રેખીયતા ખાતરીપૂર્વક ભ્રામક છે, ત્યારે એક રસપ્રદ ચર્ચા જન્મે છે. વિવાદાસ્પદ લોકો જુસ્સાથી આગ્રહ કરે છે કે "મૂળ કારણ" નું જ્ઞાન જ આપણને શું થઈ રહ્યું છે તે સમજવાની મંજૂરી આપે છે.

મેં એક રસપ્રદ પેટર્ન નોંધ્યું: વિકાસકર્તાઓ અને ડેવોપ્સ આ વિચાર પર અલગ રીતે પ્રતિક્રિયા આપે છે. મારા અનુભવમાં, વિકાસકર્તાઓ એવી દલીલ કરે છે કે મૂળ કારણ મહત્વપૂર્ણ છે અને તે કારણ-અને-અસર સંબંધો હંમેશા ઘટનાઓમાં સ્થાપિત થઈ શકે છે. બીજી બાજુ, DevOps વધુ વખત સંમત થાય છે કે જટિલ વિશ્વ હંમેશા રેખીયતાનું પાલન કરતું નથી.

હું હંમેશા વિચારતો હતો કે આવું કેમ છે? શું બનાવે છે પ્રોગ્રામરો "મૂળ કારણ એક પૌરાણિક કથા છે" જેવા વિચારની ટીકા કરે છે? રોગપ્રતિકારક શક્તિની જેમ જે વિદેશી એજન્ટને ઓળખે છે. શા માટે તેઓ આ રીતે પ્રતિક્રિયા કરે છે, જ્યારે ડેવોપ્સ તેના બદલે ઝોક આ વિચારને ધ્યાનમાં લો?

મને સંપૂર્ણ ખાતરી નથી, પરંતુ મને આ અંગે કેટલાક વિચારો છે. તે વિવિધ સંદર્ભો સાથે સંબંધિત છે જેમાં આ વ્યાવસાયિકો તેમના રોજિંદા કાર્યને હાથ ધરે છે.

વિકાસકર્તાઓ ઘણીવાર નિર્ણાયક સાધનો સાથે કામ કરે છે. અલબત્ત, કમ્પાઇલર્સ, લિંકર્સ, ઓપરેટિંગ સિસ્ટમ્સ એ બધી જટિલ સિસ્ટમો છે, પરંતુ અમે એ હકીકતથી ટેવાયેલા છીએ કે તેઓ નિર્ણાયક પરિણામ આપે છે, અને અમે તેમને નિર્ણાયક તરીકે કલ્પના કરીએ છીએ: જો આપણે સમાન ઇનપુટ ડેટા પ્રદાન કરીએ, તો આપણે સામાન્ય રીતે સમાન આઉટપુટની અપેક્ષા રાખીએ છીએ. આ સિસ્ટમોમાંથી અને જો આઉટપુટ ("બગ") માં કોઈ સમસ્યા હોય, તો વિકાસકર્તાઓ ઇનપુટ ડેટા (કાં તો વપરાશકર્તા અથવા વિકાસ પ્રક્રિયા દરમિયાન સાધનોના સમૂહમાંથી) નું વિશ્લેષણ કરીને તેને હલ કરે છે. તેઓ "ભૂલ" શોધે છે અને પછી ઇનપુટ ડેટાને બદલે છે. આ "બગ" ને ઠીક કરે છે.

સૉફ્ટવેર ડેવલપમેન્ટની મૂળભૂત ધારણા: સમાન ઇનપુટ ડેટા વિશ્વસનીય અને નિર્ધારિત રીતે સમાન આઉટપુટ ઉત્પન્ન કરે છે.

વાસ્તવમાં, બિન-નિર્ધારિત પરિણામ પોતે જ બગ તરીકે ગણવામાં આવે છે: જો અણધારી અથવા ભૂલભરેલું આઉટપુટ પુનઃઉત્પાદિત ન થાય, તો વિકાસકર્તાઓ તપાસને સ્ટેકના અન્ય ભાગો (ઓપરેટિંગ સિસ્ટમ, નેટવર્ક, વગેરે) સુધી લંબાવવાનું વલણ ધરાવે છે જે વધુ વર્તે છે. અથવા ઓછા નિર્ધારિત રીતે, સમાન ઇનપુટ ડેટા સાથે સમાન પરિણામ ઉત્પન્ન કરે છે... અને જો તે કેસ નથી, તો પછી આને હજુ પણ બગ ગણવામાં આવે છે. તે હમણાં જ ઓપરેટિંગ સિસ્ટમ અથવા નેટવર્ક બગ છે.

કોઈ પણ સંજોગોમાં, નિશ્ચયવાદ એ મૂળભૂત છે, જે મોટાભાગના પ્રોગ્રામરો કરે છે તે માટે લગભગ સ્વીકાર્ય ધારણા છે.

પરંતુ કોઈપણ ડેવૉપ્સ વ્યક્તિ માટે કે જેણે હાર્ડવેરને રેક કરવામાં અથવા ક્લાઉડ API શોધવામાં દિવસ પસાર કર્યો હોય, સંપૂર્ણ રીતે નિર્ધારિત વિશ્વનો વિચાર (જ્યાં સુધી તે તમામ ઇનપુટ્સને મેપ કરવાનું પણ શક્ય હોય ત્યાં સુધી!) શ્રેષ્ઠ રીતે ક્ષણિક ખ્યાલ છે. ભલે તમે તેને બાજુએ મૂકી દો BOHF સૂર્યના સ્થળો વિશે જોક્સ, અનુભવી એન્જિનિયરોએ આ દુનિયાની સૌથી વિચિત્ર વસ્તુઓ જોઈ છે. તેઓ તે જાણે છે માનવ ચીસો પણ સર્વરને ધીમું કરી શકે છે, પર્યાવરણમાં લાખો અન્ય પરિબળોનો ઉલ્લેખ ન કરવો.

તેથી અનુભવી ઇજનેરો માટે શંકા કરવી સહેલી છે કે બધી ઘટનાઓનું એક જ મૂળ કારણ છે, અને "ફાઇવ વાયઝ" જેવી તકનીકો યોગ્ય રીતે (અને વારંવાર!) તે મૂળ કારણ તરફ દોરી જશે. હકીકતમાં, આ તેમના પોતાના અનુભવનો વિરોધાભાસ કરે છે, જ્યાં કોયડાના ટુકડા વ્યવહારમાં એટલી સરસ રીતે ફિટ થતા નથી. તેથી, તેઓ આ વિચારને વધુ સરળતાથી સ્વીકારે છે.

અલબત્ત, હું એમ નથી કહેતો કે વિકાસકર્તાઓ નિષ્કપટ, મૂર્ખ અથવા સમજવામાં અસમર્થ છે કે કેવી રીતે રેખીયતા ભ્રામક હોઈ શકે છે. અનુભવી પ્રોગ્રામરોએ કદાચ તેમના સમયમાં ઘણા બધા બિન-નિર્ધારણવાદ જોયા હશે.

પરંતુ મને લાગે છે કે આ ચર્ચાઓમાં વિકાસકર્તાઓની સામાન્ય પ્રતિક્રિયા ઘણીવાર એ હકીકત સાથે સંકળાયેલી હોય છે કે નિશ્ચયવાદની વિભાવના તેમને એકંદરે સારી રીતે સેવા આપે છે રોજિંદા કામમાં. ઇજનેરોએ તેમના ઇન્ફ્રાસ્ટ્રક્ચર પર શ્રોડિન્જરની બિલાડીઓને પકડવી પડે છે તેટલી વાર તેઓ બિન-નિર્ધારણવાદનો સામનો કરતા નથી.

આ અવલોકન કરેલ વિકાસકર્તા પ્રતિક્રિયાઓને સંપૂર્ણ રીતે સમજાવી શકશે નહીં, પરંતુ તે એક શક્તિશાળી રીમાઇન્ડર છે કે અમારી પ્રતિક્રિયાઓ ઘણા પરિબળોનું જટિલ મિશ્રણ છે.

આ જટિલતાને યાદ રાખવું અગત્યનું છે, પછી ભલે આપણે એક જ ઘટના સાથે કામ કરી રહ્યા હોઈએ, સોફ્ટવેર ડિલિવરી પાઈપલાઈન પર સહયોગ કરી રહ્યા હોઈએ અથવા વ્યાપક વિશ્વને સમજવાનો પ્રયાસ કરીએ.

સોર્સ: www.habr.com