د شبکې انجینر حقیقت (د نوډل او ... مالګې سره؟)
په دې وروستیو کې، د انجینرانو سره د مختلفو پیښو په اړه بحث کولو په وخت کې، ما په زړه پورې نمونه ولیدله.
په دې بحثونو کې، د "اصلي علت" پوښتنه تل راپورته کیږي. باوري لوستونکي شاید پوه شي چې زه یې لرم په . په ډیری سازمانونو کې، د پیښو تحلیل په بشپړه توګه د دې مفهوم پر بنسټ والړ دی. دوی د علت او اغیزې اړیکو پیژندلو لپاره مختلف تخنیکونه کاروي، لکه . دا میتودونه د "پیښو خطاطي" په نوم د یوې بې دلیله عقیدې په توګه ګومان کوي.
کله چې تاسو دا مفکوره ننګوئ او په ګوته کړئ چې خطیتوب په پیچلي سیسټمونو کې په ډاډ سره فریبونکی دی، یو زړه پورې بحث زیږیدلی. منتقدین په لیوالتیا ټینګار کوي چې یوازې د "اصلي لامل" پوهه موږ ته اجازه راکوي چې پوه شو چې څه پیښیږي.
ما یو په زړه پوری نمونه ولیده: پراختیا کونکي او ډیوپس دې نظر ته مختلف عکس العمل ښیې. زما په تجربه کې، پراختیا کونکي ډیر احتمال لري چې استدلال وکړي چې اصلي لامل مسایل دي او د لامل او اغیزې اړیکې تل په پیښو کې رامینځته کیدی شي. له بلې خوا، DevOps اکثرا موافق دي چې یوه پیچلې نړۍ تل د خطاطۍ اطاعت نه کوي.
زه تل حیران وم چې دا ولې؟ څه جوړوي برنامه کونکي په دې نظر نیوکه کوي چې "اصلي لامل افسانه ده" لکه څنګه؟ د معافیت سیسټم په څیر چې بهرني اجنټ پیژني. ولې دوی دا ډول عکس العمل څرګندوي، پداسې حال کې چې دیوپس بلکه متوجه دې نظر ته پام وکړئ؟
زه په بشپړ ډول ډاډه نه یم، مګر زه پدې اړه یو څه فکر لرم. دا په مختلفو شرایطو پورې اړه لري په کوم کې چې دا مسلکیان خپل ورځني کار ترسره کوي.
پراختیا کونکي اکثرا د ټاکونکي وسیلو سره کار کوي. البته، تالیف کونکي، لینکرونه، عملیاتي سیسټمونه - دا ټول پیچلي سیسټمونه دي، مګر موږ د دې حقیقت سره عادت یو چې دوی یو ټاکونکې پایله ورکوي، او موږ یې د ټاکونکي په توګه تصور کوو: که موږ ورته ان پټ ډیټا چمتو کړو، نو موږ معمولا تمه کوو. د دې سیسټمونو څخه ورته محصول او که چیرې د محصول ("بګ") سره ستونزه شتون ولري ، نو پراختیا کونکي یې د ان پټ ډیټا تحلیل کولو سره حل کوي (یا د کارونکي څخه یا د پراختیا پروسې په جریان کې د وسیلو سیټ څخه). دوی د "غلطۍ" په لټه کې دي او بیا د ان پټ ډاټا بدلوي. دا "بګ" حل کوي.
د سافټویر پراختیا بنسټیز انګیرنه: د ورته ان پټ ډیټا په اعتبار سره او په ثابت ډول ورته محصول تولیدوي.
په حقیقت کې، یو غیر متمرکزه پایله پخپله یوه بګ ګڼل کیږي: که چیرې غیر متوقع یا غلط محصول بیا تولید نشي، نو بیا پراختیا کونکي د سټیک نورو برخو (عملیاتي سیسټم، شبکه، او داسې نور) ته د تفتیش غزوي، کوم چې هم چلند کوي. ډیر یا لږ په ټاکلي توګه، د ورته ان پټ ډیټا سره ورته پایلې تولیدوي ... او که داسې نه وي، بیا دا لاهم یو بګ ګڼل کیږي. دا اوس یو عملیاتي سیسټم یا د شبکې بګ دی.
په هر حالت کې، ډیټامینیزم یو بنسټیز، تقریبا د منلو وړ انګیرنه ده چې د ډیری کاري پروګرامرانو لپاره یې ترسره کوي.
مګر د هر هغه ډیوپس هلک لپاره چې ورځ یې د هارډویر په راټولولو یا د کلاوډ API په موندلو کې تیره کړې ، د بشپړ ټاکونکې نړۍ مفکوره (تر هغه چې دا ممکنه وي چې د ټولو آخذونو نقشه جوړه کړئ!) په غوره توګه یو لنډمهاله مفهوم دی. حتی که تاسو یې یو طرف ته واچوئ تجربه لرونکو انجنیرانو په دې نړۍ کې تر ټولو عجیب شیان لیدلي دي. دوی پدې پوهیږي په چاپیریال کې د ملیونونو نورو فکتورونو یادونه نه کول.
نو د تجربه لرونکو انجینرانو لپاره دا اسانه ده چې شک وکړي چې ټولې پیښې یو واحد اصلي لامل لري، او تخنیکونه لکه "پنځه ولې" به په سمه توګه (او په تکرار سره!) د دې اصلي لامل لامل شي. په حقیقت کې، دا د دوی د تجربې سره مخالفت کوي، چیرې چې د معما ټوټې په عمل کې دومره پاکې نه وي. له همدې امله، دوی دا مفکوره په اسانۍ سره مني.
البته، زه دا نه وایم چې پراختیا کونکي بې رحمه، احمق، یا د دې توان نلري چې پوه شي چې څنګه خطاطي فریب کیدی شي.
مګر ماته داسې ښکاري چې په دې بحثونو کې د پراختیا کونکو څخه یو عام عکس العمل اکثرا د دې حقیقت سره تړاو لري چې د تعدیل مفهوم په ټولیزه توګه دوی ته ښه خدمت کوي په ورځني کار کې. دوی د غیر متقابل عمل سره مخ نه دي لکه څنګه چې انجینران باید د دوی زیربنا کې د شروډینګر پیشوګانې ونیسي.
دا کیدای شي په بشپړه توګه د لیدل شوي پراختیا کونکي غبرګونونه تشریح نه کړي، مګر دا یو پیاوړی یادونه ده چې زموږ غبرګونونه د ډیری فکتورونو پیچلي مخلوط دي.
دا مهمه ده چې دا پیچلتیا په یاد ولرئ، ایا موږ د یوې پیښې سره معامله کوو، د سافټویر تحویلي پایپ لاین کې همکاري کوو، یا د پراخې نړۍ احساس کولو هڅه کوو.
سرچینه: www.habr.com