هيلو، حبر! اڳي، مون انفراسٹرڪچر ۾ زندگي جي باري ۾ شڪايت ڪئي ڪوڊ پيراڊم ۽ موجوده صورتحال کي حل ڪرڻ لاء ڪجھ به پيش نه ڪيو. اڄ آئون توهان کي ٻڌائڻ لاءِ واپس آيو آهيان ته ڪهڙا طريقا ۽ طريقا توهان کي نااميدي جي اونهائي مان نڪرڻ ۽ صورتحال کي صحيح طرف هلائڻ ۾ مدد ڏين ٿا.
پوئين مضمون ۾ مون هن علائقي بابت پنهنجا تاثرات شيئر ڪيا، هن علائقي جي موجوده صورتحال تي ڌيان ڏيڻ جي ڪوشش ڪئي، ۽ اهو به تجويز ڪيو ته معياري عمل جيڪي سڀني ڊولپرز لاءِ سڃاتل آهن مدد ڪري سگهن ٿا. اهو لڳي سگھي ٿو ته زندگي بابت ڪيتريون ئي شڪايتون هيون، پر موجوده صورتحال مان نڪرڻ لاء ڪو به تجويز نه هو.
اسان ڪير آهيون، ڪٿي آهيون ۽ اسان کي ڪهڙا مسئلا آهن
اسان هن وقت Sre Onboarding ٽيم ۾ آهيون، جنهن ۾ ڇهه پروگرامر ۽ ٽي انفراسٽرڪچر انجنيئر شامل آهن. اسان سڀ ڪوشش ڪري رهيا آهيون انفراسٽرڪچر کي ڪوڊ (IaC) طور لکڻ جي. اسان اهو ڪريون ٿا ڇاڪاڻ ته اسان بنيادي طور تي ڄاڻون ٿا ته ڪوڊ ڪيئن لکجي ۽ "اوسط کان مٿي" ڊولپرز ٿيڻ جي تاريخ آهي.
- اسان وٽ فائدن جو هڪ سيٽ آهي: هڪ خاص پس منظر، عمل جي ڄاڻ، ڪوڊ لکڻ جي صلاحيت، نئين شيون سکڻ جي خواهش.
- ۽ اتي ھڪڙو ڇڪڻ وارو حصو آھي، جيڪو پڻ ھڪڙو مائنس آھي: انفراسٹرڪچر جي هارڊويئر بابت ڄاڻ جي کوٽ.
ٽيڪنالاجي اسٽيڪ جيڪا اسان استعمال ڪندا آهيون اسان جي IaC ۾.
- وسيلن ٺاهڻ لاء Terraform.
- تصويرن کي گڏ ڪرڻ لاء پيڪر. اهي ونڊوز، CentOS 7 تصويرون آهن.
- Jsonnet drone.io ۾ هڪ طاقتور تعمير ڪرڻ لاء، انهي سان گڏ پيڪر json ۽ اسان جي ٽيرافارم ماڊلز ٺاهڻ لاء.
- Azure.
- جواب ڏيڻ وقت تصويرون تيار ڪرڻ.
- Python معاون خدمتون ۽ ترتيب ڏيڻ واري اسڪرپٽ لاءِ.
- ۽ اهو سڀ ڪجهه VSCode ۾ پلگ ان سان گڏ ٽيم جي ميمبرن جي وچ ۾ شيئر ڪيو ويو.
منهنجو نتيجو هن طرح هو: مون ڪوشش ڪئي ته (سڀ کان پهرين پاڻ ۾) پراميد، مان اهو چوڻ چاهيان ٿو ته اسان هن علائقي ۾ موجود مشڪلاتن ۽ پيچيدگين کي منهن ڏيڻ لاءِ اسان کي معلوم طريقن ۽ طريقن جي ڪوشش ڪنداسين.
اسان هن وقت هيٺ ڏنل IaC مسئلن سان جدوجهد ڪري رهيا آهيون:
- ڪوڊ ڊولپمينٽ لاءِ اوزار ۽ وسيلا جي خرابي.
- سست لڳائڻ. انفراسٹرڪچر حقيقي دنيا جو حصو آهي، ۽ اهو سست ٿي سگهي ٿو.
- طريقن ۽ طريقن جي کوٽ.
- اسان نوان آهيون ۽ گهڻو ڪجهه نٿا ڄاڻون.
بچاء لاء انتهائي پروگرامنگ (XP).
سڀ ڊولپرز Extreme Programming (XP) کان واقف آهن ۽ اهي طريقا جيڪي ان جي پويان بيٺل آهن. اسان مان ڪيترن ئي هن طريقي سان ڪم ڪيو آهي، ۽ اهو ڪامياب ٿي چڪو آهي. پوءِ ڇو نه بنيادي ڍانچي جي چئلينجن کي منهن ڏيڻ لاءِ اتي موجود اصولن ۽ عملن کي استعمال ڪيو وڃي؟ اسان اهو طريقو اختيار ڪرڻ جو فيصلو ڪيو ۽ ڏسو ته ڇا ٿئي.
توهان جي صنعت تي XP طريقي جي قابل اطلاق جي جانچ ڪنديهتي ماحول جي وضاحت آهي ته XP مناسب آهي، ۽ اهو اسان سان ڪيئن تعلق رکي ٿو:
1. متحرڪ طور تبديل ٿيندڙ سافٽ ويئر گهرجن. اهو اسان لاء واضح هو ته آخر مقصد ڇا هو. پر تفصيل مختلف ٿي سگهن ٿا. اسان پاڻ فيصلو ڪريون ٿا جتي اسان کي ٽيڪسي جي ضرورت آهي، تنهن ڪري گهرجون وقتي طور تي تبديل ٿينديون آهن (خاص طور تي پاڻ طرفان). جيڪڏهن اسان وٺون ٿا SRE ٽيم، جيڪا پاڻ آٽوميشن ڪري ٿي، ۽ پاڻ ئي ڪم جي گهرج ۽ دائري کي محدود ڪري ٿي، ته پوءِ اهو نقطو چڱيءَ ريت ٺهي ٿو.
2. نئين ٽيڪنالاجي استعمال ڪندي مقرر وقت جي منصوبن جي ڪري پيدا ٿيندڙ خطرات. اسان خطرن کي منهن ڏئي سگهون ٿا جڏهن اسان کي اڻڄاتل شيون استعمال ڪندي. ۽ اهو 100٪ اسان جو ڪيس آهي. اسان جو سڄو منصوبو ٽيڪنالاجي جو استعمال هو جنهن سان اسان مڪمل طور تي واقف نه هئاسين. عام طور تي، اهو هڪ مسلسل مسئلو آهي، ڇاڪاڻ ته ... هر وقت انفراسٽرڪچر شعبي ۾ ڪيتريون ئي نيون ٽيڪنالاجيون اڀري رهيون آهن.
3,4. ننڍو، گڏيل طور تي وڌايو ويو ترقياتي ٽيم. خودڪار ٽيڪنالاجي جيڪا توهان استعمال ڪري رهيا آهيو يونٽ ۽ فنڪشنل ٽيسٽ جي اجازت ڏئي ٿي. اهي ٻه نقطا اسان کي بلڪل مناسب نه آهن. پهرين، اسان هڪ هموار ٿيل ٽيم ناهيون، ۽ ٻيو، اسان مان نو آهن، جن کي هڪ وڏي ٽيم سمجهي سگهجي ٿو. جيتوڻيڪ، "وڏي" ٽيم جي ڪجهه وصفن مطابق، تمام گهڻو آهي 14+ ماڻهو.
اچو ته ڪجهه XP عملن تي نظر رکون ۽ ڪيئن اهي تاثرات جي رفتار ۽ معيار کي متاثر ڪن ٿا.
XP راءِ لوپ اصول
منهنجي سمجهه ۾، راءِ سوال جو جواب آهي، ڇا مان صحيح ڪم ڪري رهيو آهيان، ڇا اسان اتي وڃي رهيا آهيون؟ XP وٽ هن لاءِ هڪ خدائي اسڪيم آهي: هڪ وقت جي موٽ وارو لوپ. دلچسپ ڳالهه اها آهي ته اسان گهٽ آهيون، تيزيء سان اسان ضروري سوالن جا جواب ڏيڻ لاء OS حاصل ڪرڻ جي قابل آهيون.
اهو بحث لاءِ هڪ بلڪه دلچسپ موضوع آهي، ته اسان جي آئي ٽي انڊسٽري ۾ اهو ممڪن آهي ته جلدي هڪ او ايس حاصل ڪرڻ. تصور ڪريو ته ڇهن مهينن تائين هڪ پروجيڪٽ ڪرڻ ڪيترو ڏکوئيندڙ آهي ۽ پوءِ ئي معلوم ٿيو ته شروعات ۾ ئي ڪا غلطي هئي. اهو ڊزائن ۾ ٿئي ٿو ۽ پيچيده سسٽم جي ڪنهن به تعمير ۾.
اسان جي IaC جي صورت ۾، موٽ اسان جي مدد ڪري ٿي. مان فوري طور تي مٿي ڏنل ڊراگرام ۾ هڪ ننڍڙي ترتيب ڏيندس: رليز پلان کي مهيني چڪر نه آهي، پر ڏينهن ۾ ڪيترائي ڀيرا ٿئي ٿو. ھن او ايس چڪر سان ڳنڍيل ڪجھ طريقا آھن جن کي اسين وڌيڪ تفصيل سان ڏسنداسين.
اھم: راءِ مٿي بيان ڪيل سڀني مسئلن جو حل ٿي سگھي ٿو. XP عملن سان گڏ، اهو توهان کي نااميديءَ جي اونهائي مان ڪڍي سگهي ٿو.
ڪيئن پاڻ کي نااميديء جي اونهاري مان ٻاهر ڪڍيو: ٽي طريقا
ٽيسٽ
XP موٽڻ واري لوپ ۾ ٽيسٽ جو ذڪر ٻه ڀيرا ڪيو ويو آهي. بس ائين ئي ناهي. اهي انتهائي اهم آهن پوري پروگرامنگ ٽيڪنڪ لاءِ.
اهو فرض ڪيو ويو آهي ته توهان وٽ يونٽ ۽ قبوليت جا امتحان آهن. ڪجهه توهان کي ڪجهه منٽن ۾ موٽ ڏين ٿا، ٻيا ڪجهه ڏينهن ۾، تنهن ڪري اهي لکڻ ۾ گهڻي وقت وٺن ٿا ۽ گهٽ ۾ گهٽ جائزو وٺندا آهن.
اتي ھڪڙو کلاسک جاچ پڙتال آھي، جيڪو ڏيکاري ٿو ته اتي وڌيڪ ٽيسٽ ٿيڻ گھرجي.
اهو فريم ورڪ اسان تي IaC پروجيڪٽ ۾ ڪيئن لاڳو ٿئي ٿو؟ حقيقت ۾ ... بلڪل نه.
- يونٽ ٽيسٽ، ان حقيقت جي باوجود ته انهن مان تمام گهڻو هجڻ گهرجي، تمام گهڻو نه ٿي سگهي. يا اهي ڪجهه اڻ سڌي طرح جاچ ڪري رهيا آهن. حقيقت ۾، اسان اهو چئي سگهون ٿا ته اسان انهن کي هرگز نه لکندا آهيون. پر ھتي ڪجھ ايپليڪيشنون آھن انھن ٽيسٽن لاءِ جيڪي اسان ڪري سگھندا ھئاسين:
- جاچ jsonnet ڪوڊ. هي، مثال طور، اسان جي ڊرون اسيمبلي پائيپ لائين آهي، جيڪا ڪافي پيچيده آهي. jsonnet ڪوڊ چڱي طرح ڍڪيل آھي ٽيسٽن سان.
اسان هي استعمال ڪندا آهيون . - اسڪرپٽ لاءِ ٽيسٽون جيڪي عمل ۾ اچن ٿيون جڏهن وسيلو شروع ٿئي ٿو. اسڪرپٽ Python ۾ لکيل آهن، تنهنڪري انهن تي ٽيسٽ لکي سگهجي ٿو.
- جاچ jsonnet ڪوڊ. هي، مثال طور، اسان جي ڊرون اسيمبلي پائيپ لائين آهي، جيڪا ڪافي پيچيده آهي. jsonnet ڪوڊ چڱي طرح ڍڪيل آھي ٽيسٽن سان.
- اهو ممڪن آهي ته ٽيسٽ ۾ ترتيب جي جانچ ڪرڻ ممڪن آهي، پر اسان اهو نٿا ڪريون. اهو پڻ ممڪن آهي ته وسيلن جي ترتيب جي ضابطن جي چڪاس جي ذريعي ترتيب ڏيو . جڏهن ته، اتي موجود چيڪ صرف ٽرافارم لاءِ بنيادي آهن، پر ڪيتريون ئي ٽيسٽ اسڪرپٽ AWS لاءِ لکيل آهن. ۽ اسان Azure تي آهيون، تنهنڪري اهو ٻيهر لاڳو نٿو ٿئي.
- اجزاء جي انضمام جا امتحان: اهو ان تي منحصر آهي ته توهان انهن کي ڪيئن درجه بندي ڪيو ۽ توهان انهن کي ڪٿي رکيو. پر اهي بنيادي طور تي ڪم ڪن ٿا.
اهو آهي جيڪو انضمام ٽيسٽ وانگر نظر اچي ٿو.
اهو هڪ مثال آهي جڏهن ڊرون CI ۾ تصويرون ٺاهي رهيا آهن. انھن تائين پھچڻ لاءِ، توھان کي انتظار ڪرڻو پوندو 30 منٽن لاءِ پيڪر جي تصوير ٺاھڻ لاءِ، پوءِ انتظار ڪرڻو پوندو 15 منٽن لاءِ انھن جي گذرڻ لاءِ. پر اهي موجود آهن!تصويري تصديق الورورٿم
- پيڪر کي پهرين تصوير کي مڪمل طور تي تيار ڪرڻ گهرجي.
- امتحان جي اڳيان هڪ مقامي رياست سان گڏ هڪ ٽيرافارم آهي، جنهن کي اسين هن تصوير کي ترتيب ڏيڻ لاء استعمال ڪندا آهيون.
- جڏهن ظاهر ٿئي ٿي، هڪ ننڍڙو ماڊل ويجھي بيٺل استعمال ڪيو ويندو آهي ان کي تصوير سان ڪم ڪرڻ آسان بڻائي.
- هڪ دفعو تصوير مان VM ترتيب ڏني وئي آهي، چيڪ شروع ڪري سگھن ٿا. بنيادي طور تي، چيڪ ڪار ذريعي ڪيا ويندا آهن. اهو چيڪ ڪري ٿو ته اسڪرپٽ شروع ٿيڻ تي ڪيئن ڪم ڪيو ۽ ڊيمن ڪيئن ڪم ڪيو. ائين ڪرڻ لاءِ، ssh يا winrm ذريعي اسان نئين اٿلايل مشين ۾ لاگ ان ڪريون ٿا ۽ چيڪ ڪريون ٿا ڪنفيگريشن اسٽيٽس يا خدمتون مٿي آهن.
- صورتحال ساڳي آهي ٽيرافارم لاءِ ماڊلز ۾ انضمام ٽيسٽ سان. هتي هڪ مختصر جدول آهي جنهن ۾ اهڙن تجربن جي خاصيتن جي وضاحت ڪئي وئي آهي.
پائپ لائن تي موٽ تقريبا 40 منٽ آهي. اهو سڀ ڪجهه گهڻو وقت تائين ٿئي ٿو. اهو رجعت لاء استعمال ٿي سگهي ٿو، پر نئين ترقي لاء اهو عام طور تي غير حقيقي آهي. جيڪڏھن توھان ان لاءِ تمام گھڻو تيار آھيو، ھلندڙ اسڪرپٽ تيار ڪريو، پوءِ توھان ان کي 10 منٽن تائين گھٽائي سگھو ٿا. پر اهي اڃا تائين يونٽ ٽيسٽ نه آهن، جيڪي 5 سيڪنڊن ۾ 100 ٽڪرا ڪندا آهن.
يونٽ ٽيسٽ جي غير موجودگي جڏهن تصويرون يا ٽيرافارم ماڊلز گڏ ڪرڻ ڪم کي الڳ خدمتن ڏانهن منتقل ڪرڻ جي حوصلا افزائي ڪري ٿو جيڪا صرف REST ذريعي هلائي سگهجي ٿي، يا Python اسڪرپٽ ڏانهن.
مثال طور، اسان کي پڪ ڪرڻ جي ضرورت آهي ته جڏهن مجازي مشين شروع ٿئي ٿي، اهو پاڻ کي خدمت ۾ رجسٽر ڪري ٿو ، ۽ جڏهن مجازي مشين تباهه ٿي وئي، اهو پاڻ کي ختم ڪري ڇڏيو.
جيئن ته اسان وٽ ScaleFT هڪ خدمت آهي، اسان ان سان گڏ API ذريعي ڪم ڪرڻ تي مجبور آهيون. اتي هڪ لفافي لکيل هو جنهن کي توهان ڇڪي سگهو ٿا ۽ چئي سگهو ٿا: "اندر وڃو ۽ هن کي حذف ڪريو." اهو تمام ضروري سيٽنگون ۽ رسائي محفوظ ڪري ٿو.
اسان اڳ ۾ ئي ان لاءِ عام ٽيسٽ لکي سگهون ٿا، ڇاڪاڻ ته اهو عام سافٽ ويئر کان مختلف ناهي: ڪنهن قسم جي اپيها کي ٺٺوليون ڪيو ويو آهي، توهان ان کي ڇڪيو، ۽ ڏسو ته ڇا ٿئي ٿو.
ٽيسٽ جا نتيجا: يونٽ جي جاچ، جيڪو او ايس کي هڪ منٽ ۾ ڏيڻ گهرجي، اهو نٿو ڏئي. ۽ پرامڊ ۾ وڌيڪ جاچ جا قسم اثرائتو آهن، پر صرف مسئلن جو حصو ڍڪيندا آهن.
جوڙو پروگرامنگ
ٽيسٽ، يقينا، سٺا آهن. توهان انهن مان تمام گهڻو لکي سگهو ٿا، اهي مختلف قسمن جا ٿي سگهن ٿا. اهي پنهنجي سطح تي ڪم ڪندا ۽ اسان کي راء ڏيو. پر خراب يونٽ ٽيسٽ سان مسئلو، جيڪو تيز ترين او ايس ڏئي ٿو، باقي رهي ٿو. ساڳئي وقت، مان اڃا تائين هڪ تيز او ايس چاهيان ٿو جيڪو ڪم ڪرڻ آسان ۽ خوشگوار آهي. نتيجو حل جي معيار جو ذڪر نه ڪرڻ. خوشقسمتيء سان، اتي ٽيڪنڪ آهن جيڪي مهيا ڪري سگھن ٿيون اڃا به تيز موٽ ڏيو يونٽ ٽيسٽ کان. هي جوڙو پروگرامنگ آهي.
جڏهن ڪوڊ لکڻ، توهان ان جي معيار تي جلد کان جلد موٽ حاصل ڪرڻ چاهيو ٿا. ها، توهان هڪ فيچر برانچ ۾ سڀ ڪجهه لکي سگهو ٿا (جيئن ته ڪنهن جي لاءِ ڪجهه به نه ٽوڙيو)، گٿب ۾ پلڻ جي درخواست ڪريو، ان کي ڪنهن کي تفويض ڪريو جنهن جي راء ۾ وزن آهي، ۽ جواب جو انتظار ڪريو.
پر توهان هڪ ڊگهو وقت انتظار ڪري سگهو ٿا. ماڻهو تمام مصروف آهن، ۽ جواب، جيتوڻيڪ اتي هڪ آهي، شايد اعلي معيار جو نه هجي. فرض ڪريو ته جواب فوري طور تي آيو، نظرثاني ڪندڙ فوري طور تي سڄو خيال سمجهي، پر جواب اڃا دير سان اچي ٿو، حقيقت کان پوء. مان چاهيان ٿو ته اهو اڳ هو. اهو ئي آهي جيڪو جوڙي پروگرامنگ جو مقصد آهي - صحيح طور تي، لکڻ جي وقت تي.
هيٺ ڏنل جوڙو پروگرامنگ انداز ۽ IaC تي ڪم ڪرڻ ۾ انهن جي قابل اطلاق آهن:
1. ڪلاسيڪل، تجربيڪار + تجربيڪار، ٽائمر ذريعي شفٽ. ٻه ڪردار - ڊرائيور ۽ نيويگيٽر. ٻه ماڻهو. اهي هڪ ئي ڪوڊ تي ڪم ڪن ٿا ۽ هڪ خاص مقرر وقت کان پوءِ ڪردار تبديل ڪن ٿا.
اچو ته انداز سان اسان جي مسئلن جي مطابقت تي غور ڪريو:
- مسئلو: ڪوڊ ڊولپمينٽ لاءِ اوزارن ۽ اوزارن جي خرابي.
ناڪاري اثر: ان کي ترقي ڪرڻ ۾ گهڻي وقت لڳندي آهي، اسان سست ٿي ويندا آهيون، ڪم جي رفتار/ تال گم ٿي ويندو آهي.
اسان ڪيئن وڙهون ٿا: اسان هڪ مختلف ٽولنگ استعمال ڪريون ٿا، هڪ عام IDE ۽ پڻ شارٽ ڪٽ سکو. - مسئلو: سست لڳائڻ.
ناڪاري اثر: ڪوڊ جو ڪم ڪندڙ ٽڪرو ٺاهڻ لاءِ وقت وڌائي ٿو. اسان انتظار ڪندي بيزار ٿي وڃون ٿا، انتظار ڪندي اسان جا هٿ ڪجهه ٻيو ڪرڻ لاءِ پهچن ٿا.
اسان ڪيئن وڙهندا آهيون: اسان ان تي غالب نه ڪيو. - مسئلو: طريقن ۽ عملن جو فقدان.
ناڪاري اثر: ڪا به ڄاڻ نه آهي ته اهو ڪيئن ڪجي ۽ خراب طريقي سان ڪيئن ڪجي. موٽ جي رسيد کي ڊگهو ڪري ٿو.
اسان ڪيئن وڙهندا آهيون: راءن جي باهمي مٽا سٽا ۽ گڏيل ڪم ۾ عمل لڳ ڀڳ مسئلو حل ڪري ٿو.
IaC ۾ هن انداز کي استعمال ڪرڻ سان بنيادي مسئلو ڪم جي اڻ برابر رفتار آهي. روايتي سافٽ ويئر ڊولپمينٽ ۾، توهان وٽ هڪ تمام يونيفارم تحريڪ آهي. توهان پنج منٽ خرچ ڪري سگهو ٿا ۽ N لکي سگهو ٿا. خرچ 10 منٽ ۽ لکو 2N، 15 منٽ - 3N. هتي توهان پنج منٽ خرچ ڪري سگهو ٿا ۽ ن لکي سگهو ٿا، ۽ پوءِ ٻيا 30 منٽ خرچ ڪري سگهو ٿا ۽ ن لکو. هتي توهان کي ڪا به خبر ناهي، توهان بيوقوف آهيو، بيوقوف آهيو. تحقيق وقت وٺندو آهي ۽ پاڻ کي پروگرامنگ کان پريشان ڪري ٿو.
نتيجو: ان جي خالص صورت ۾ ان کي اسان لاء مناسب نه آهي.
2. پنگ پانگ. هن طريقي ۾ شامل آهي هڪ شخص ٽيسٽ لکڻ ۽ ٻيو ان لاءِ عمل درآمد ڪري رهيو آهي. انهي حقيقت کي نظر ۾ رکندي ته سڀ ڪجهه پيچيدو آهي يونٽ ٽيسٽ سان، ۽ توهان کي هڪ انٽيگريشن ٽيسٽ لکڻو پوندو جيڪو پروگرام ڪرڻ ۾ گهڻو وقت وٺندو آهي، پنگ پانگ جي تمام آسانيءَ کان پري ٿي ويندي آهي.
مان چئي سگهان ٿو ته اسان ٽيسٽ اسڪرپٽ ڊزائين ڪرڻ ۽ ان لاءِ ڪوڊ لاڳو ڪرڻ جي ذميوارين کي الڳ ڪرڻ جي ڪوشش ڪئي. ھڪڙو حصو وٺندڙ اسڪرپٽ کڻي آيو، ڪم جي ھن حصي ۾ اھو ذميوار ھو، اھو آخري لفظ ھو. ۽ ٻئي تي عمل ڪرڻ جي ذميواري هئي. اهو سٺو ڪم ڪيو. ان طريقي سان لکت جو معيار وڌي ٿو.
نتيجو: افسوس، ڪم جي رفتار IaC ۾ هڪ جوڙي پروگرامنگ مشق جي طور تي پنگ-پانگ جي استعمال جي اجازت نٿو ڏئي.
3.Strong انداز. . خيال اهو آهي ته هڪ شرڪت ڪندڙ هدايتڪار نيويگيٽر بڻجي ويندو آهي، ۽ ٻيو عملدار ڊرائيور جو ڪردار وٺندو آهي. انهي حالت ۾، فيصلا ڪرڻ جو حق خاص طور تي نيويگيٽر سان آهي. ڊرائيور صرف پرنٽ ڪري ٿو ۽ اثر انداز ڪري سگھي ٿو جيڪو لفظ سان ٿي رهيو آهي. ڪردار هڪ ڊگهي وقت تائين تبديل نه ڪندا آھن.
سکڻ لاء سٺو، پر مضبوط نرم صلاحيتن جي ضرورت آهي. هي اهو آهي جتي اسان ڀڄي ويا آهيون. ٽيڪنڪ مشڪل هئي. ۽ اهو پڻ انفراسٹرڪچر بابت ناهي.
نتيجو: اهو ممڪن طور تي استعمال ڪري سگهجي ٿو، اسان ڪوشش ڪرڻ نه ڇڏينداسين.
4. موبنگ، swarming ۽ سڀ ڄاتل سڃاتل پر درج ٿيل انداز نه اسان ان تي غور نه ڪندا آھن، ڇاڪاڻ ته اسان ان جي ڪوشش نه ڪئي آهي ۽ اسان جي ڪم جي حوالي سان ان بابت ڳالهائڻ ناممڪن آهي.
جوڙي پروگرامنگ استعمال ڪرڻ تي عام نتيجا:
- اسان وٽ ڪم جي اڻ برابري رفتار آهي، جيڪا مونجهارو آهي.
- اسان ڪافي سٺي نرم صلاحيتن ۾ ڀڄي ويا. ۽ موضوع وارو علائقو اسان جي انهن خامين کي دور ڪرڻ ۾ مدد نٿو ڪري.
- ڊگھيون ٽيسٽون ۽ مسئلا اوزارن سان ٺھيل ترقي کي مشڪل بڻائيندا آھن.
5. ان جي باوجود، اتي ڪاميابيون هيون. اسان اسان جي پنهنجي طريقي سان آيا آهيون "ڪنورجنسي - Divergence". مان مختصر طور تي بيان ڪندس ته اهو ڪيئن ڪم ڪري ٿو.
اسان وٽ ڪجهه ڏينهن لاءِ مستقل ڀائيوار آهن (هفتي کان گهٽ). اسان گڏجي هڪ ڪم ڪندا آهيون. اسان ڪجهه دير لاءِ گڏ ويٺا آهيون: هڪ لکندو آهي، ٻيو ويهندو آهي ۽ سپورٽ ٽيم کي ڏسندو آهي. پوءِ اسان ڪجهه وقت لاءِ منتشر ٿي وڃون ٿا، هر هڪ ڪجهه الڳ الڳ ڪم ڪري ٿو، پوءِ اسين ٻيهر گڏ ٿيون ٿا، تمام جلدي هم وقت سازي ڪريون ٿا، ڪجهه گڏجي ڪري ٻيهر منتشر ٿيون.
منصوبابندي ۽ مواصلات
عملن جو آخري بلاڪ جنهن جي ذريعي OS مسئلا حل ڪيا ويا آهن انهن جي ڪمن سان گڏ ڪم جي تنظيم آهي. ھن ۾ تجربو جو تبادلو پڻ شامل آھي جيڪو جوڙي جي ڪم کان ٻاھر آھي. اچو ته ٽي مشقون ڏسو:
1. گول وڻ ذريعي مقصد. اسان ھڪڙي وڻ جي ذريعي منصوبي جي مجموعي انتظام کي منظم ڪيو آھي جيڪو مستقبل ۾ ختم ٿي ويندو آھي. ٽيڪنيڪل طور تي، ٽريڪنگ ميرو ۾ ڪيو ويندو آهي. اتي ھڪڙو ڪم آھي - اھو ھڪڙو وچولي مقصد آھي. ان مان يا ته ننڍا مقصد يا ڪمن جا گروپ وڃو. ڪم پاڻ وٽان ايندا آهن. سڀئي ڪم هن بورڊ تي ٺاهيا ۽ برقرار رکيا ويا آهن.
اها اسڪيم پڻ راءِ ڏئي ٿي، جيڪا ڏينهن ۾ هڪ ڀيرو ٿيندي آهي جڏهن اسان ريلين ۾ هم وقت سازي ڪندا آهيون. سڀني جي سامهون هڪ گڏيل منصوبو هجڻ، پر منظم ۽ مڪمل طور تي کليل، هر ڪنهن کي اها خبر رکڻ جي اجازت ڏئي ٿي ته ڇا ٿي رهيو آهي ۽ اسان ڪيتري حد تائين ترقي ڪئي آهي.
ڪمن جي بصري وژن جا فائدا:
- ڪارڻ. هر ڪم ڪنهن نه ڪنهن عالمي مقصد تائين پهچندو آهي. ڪم ننڍن مقصدن ۾ ورهايل آهن. انفراسٽرڪچر ڊومين پاڻ ڪافي ٽيڪنيڪل آهي. اهو هميشه فوري طور تي واضح ناهي ته ڪهڙو خاص اثر، مثال طور، هڪ رن بڪ لکڻ جو هڪ ٻئي نينڪس ڏانهن لڏپلاڻ تي ڪاروبار تي آهي. ھدف ڪارڊ ويجھي ھجڻ ان کي صاف ڪري ٿو.
Causality مسئلن جي هڪ اهم ملڪيت آهي. اهو سڌو سنئون سوال جو جواب ڏئي ٿو: "ڇا مان صحيح ڪم ڪري رهيو آهيان؟" - متوازيت. اسان مان نو آهن، ۽ اهو صرف جسماني طور تي ناممڪن آهي ته هر ڪنهن کي هڪ ڪم تي اڇلائي. هڪ علائقي مان ڪم هميشه ڪافي نه هوندا. اسان ننڍن ڪم ڪندڙ گروپن جي وچ ۾ ڪم کي برابر ڪرڻ تي مجبور آهيون. ساڳئي وقت، گروهه ڪجهه وقت لاء پنهنجي ڪم تي ويٺا آهن، انهن کي ڪنهن ٻئي طرفان مضبوط ڪري سگهجي ٿو. ڪڏهن ڪڏهن ماڻهو هن ڪم ڪندڙ گروپ کان پري ٿي ويندا آهن. ڪو موڪلن تي وڃي ٿو، ڪو ڊي او پيز ڪانفرنس لاءِ رپورٽ ڪري ٿو، ڪو حبر تي مضمون لکي ٿو. اهو ڄاڻڻ ضروري آهي ته ڪهڙا مقصد ۽ ڪم هڪجهڙائي ۾ ٿي سگهن ٿا.
2. صبح جي گڏجاڻين جي بدلي پيش ڪندڙ. اسٽينڊ اپ تي اسان وٽ اهو مسئلو آهي - ماڻهو متوازي ۾ ڪيترائي ڪم ڪن ٿا. ڪڏهن ڪڏهن ڪم آساني سان ڳنڍيل هوندا آهن ۽ سمجهه ۾ نه ايندي آهي ته ڪير ڇا ڪري رهيو آهي. ۽ ٻي ٽيم جي ميمبر جي راء تمام ضروري آهي. هي اضافي معلومات آهي جيڪا مسئلي کي حل ڪرڻ جو رخ تبديل ڪري سگهي ٿي. يقينن، عام طور تي ڪو ماڻهو توهان سان گڏ آهي، پر مشورو ۽ صلاحون هميشه ڪارائتو آهن.
ھن صورتحال کي بھتر ڪرڻ لاءِ، اسان استعمال ڪيو ”چينجنگ دي ليڊنگ اسٽينڊ اپ“ ٽيڪنڪ. ھاڻي اھي ھڪڙي خاص فهرست جي مطابق گھميل آھن، ۽ اھو ان جو اثر آھي. جڏھن اھو توھان جو موڙ آھي، توھان کي مجبور ڪيو ويو آھي اندر ۾ ۽ سمجھو ته ڇا ٿي رھيو آھي ھڪڙي سٺي اسڪرم ميٽنگ کي هلائڻ لاءِ.
3. اندروني ڊيمو. جوڑوں جي پروگرامنگ مان مسئلو حل ڪرڻ ۾ مدد، مسئلي جي وڻ تي تصوير ۽ صبح جو اسڪرم ميٽنگن ۾ مدد سٺيون آھن، پر مثالي نه آھن. هڪ جوڙي جي حيثيت ۾، توهان صرف پنهنجي ڄاڻ تائين محدود آهيو. ٽاسڪ وڻ عالمي سطح تي سمجهڻ ۾ مدد ڪري ٿو ته ڪير ڇا ڪري رهيو آهي. ۽ صبح جي گڏجاڻي ۾ پيش ڪندڙ ۽ ساٿي توهان جي مسئلن ۾ گهيرو نه ڪندا. اهي يقيناً ڪجهه وڃائي سگهن ٿا.
ان جو حل هڪ ٻئي کي ڪيل ڪم ڏيکارڻ ۽ پوءِ بحث ڪرڻ ۾ مليو. اسان هفتي ۾ هڪ ڀيرو هڪ ڪلاڪ لاءِ ملن ٿا ۽ انهن ڪمن جي حل جا تفصيل ڏيکاريون جيڪي اسان گذريل هفتي دوران ڪيا آهن.
مظاهري دوران، اهو ضروري آهي ته ڪم جي تفصيل کي ظاهر ڪرڻ ۽ ان جي عمل کي ظاهر ڪرڻ جي پڪ ڪرڻ لاء.
رپورٽ هڪ چيڪ لسٽ استعمال ڪندي منظم ڪري سگهجي ٿو.1. حوالي ۾ داخل ڪريو. اهو ڪم ڪٿان آيو، ڇو ضروري هو؟
2. مسئلو ڪيئن حل ڪيو ويو اڳ؟ مثال طور، وڏي مائوس تي ڪلڪ ڪرڻ جي ضرورت هئي، يا اهو سڀ ڪجهه ڪرڻ ناممڪن هو.
3. اسان ان کي ڪيئن بهتر بڻايون. مثال طور: "ڏس، ھاڻي ھتي اسڪرپٽ آھي، ھتي آھي ريڊمي."
4. ڏيکاريو ته اهو ڪيئن ڪم ڪري ٿو. اهو مشورو ڏنو ويو آهي ته سڌي طرح ڪجهه استعمال ڪندڙ منظرنامي تي عمل ڪرڻ. مان چاهيان ٿو ايڪس، مان ڪريان ٿو Y، مان ڏسان ٿو Y (يا Z). مثال طور، مان NGINX کي ترتيب ڏيو، يو آر ايل کي تماڪ ڪريو، ۽ 200 ٺيڪ ڪريو. جيڪڏهن عمل ڊگهو آهي، ان کي اڳ ۾ تيار ڪريو ته جيئن توهان ان کي بعد ۾ ڏيکاري سگهو ٿا. اهو مشورو ڏنو ويو آهي ته ڊيم کان هڪ ڪلاڪ اڳ ان کي تمام گهڻو نه ٽوڙيو، جيڪڏهن اهو نازڪ آهي.
5. وضاحت ڪريو ته مسئلو ڪيئن ڪاميابي سان حل ڪيو ويو، ڪهڙيون مشڪلاتون باقي آهن، ڇا مڪمل نه ٿيو، مستقبل ۾ ڪهڙيون بهتري ممڪن آهي. مثال طور، هاڻي CLI، پوء اتي CI ۾ مڪمل خودڪار ٿي ويندي.
اهو هر اسپيڪر لاء مشورو آهي ته ان کي 5-10 منٽن تائين رکڻ لاء. جيڪڏهن توهان جي تقرير واضح طور تي اهم آهي ۽ گهڻي وقت وٺندي، انهي کي ترتيب ڏيو اڳ ۾ sre-takeover چينل ۾.
منهن ڏيڻ واري حصي کان پوءِ موضوع ۾ هميشه بحث ٿيندو آهي. اھو اھو آھي جتي اسان جي ڪمن تي موٽ جي ضرورت آھي.
نتيجي طور، هڪ سروي ڪئي وئي آهي ته ڇا ٿي رهيو آهي ان جي افاديت کي طئي ڪرڻ لاء. هي تقرير جي جوهر ۽ ڪم جي اهميت تي راءِ آهي.
ڊگهو نتيجو ۽ اڳتي ڇا آهي
اهو لڳي سگهي ٿو ته مضمون جو ڍنگ ڪجهه مايوسي آهي. هي غلط آهي. موٽ جا ٻه هيٺين سطح، يعني ٽيسٽ ۽ جوئر پروگرامنگ، ڪم. روايتي ترقيءَ ۾ جيترو پورو ناهي، پر ان مان مثبت اثر ضرور آهي.
ٽيسٽ، انهن جي موجوده شڪل ۾، صرف جزوي ڪوڊ ڪوريج مهيا ڪن ٿا. ڪيتريون ئي ترتيبن جا ڪم ختم ٿي ويا آهن اڻ آزمائشي. انهن جو اثر اصل ڪم تي آهي جڏهن لکڻ جو ڪوڊ گهٽ آهي. تنهن هوندي، انضمام ٽيسٽ مان هڪ اثر آهي، ۽ اهي توهان کي اجازت ڏين ٿا ته بي خوفي سان ريفڪٽرنگ کي انجام ڏيو. اها هڪ وڏي ڪاميابي آهي. انهي سان گڏ، اعلي سطحي ٻولين ۾ ترقي ڏانهن ڌيان جي ڦيرڦار سان (اسان وٽ پيٿون، وڃو)، مسئلو دور ٿي ويندو آهي. ۽ توهان کي ”گلو“ لاءِ گهڻين چيڪن جي ضرورت ناهي؛ هڪ عام انضمام چيڪ ڪافي آهي.
جوڑوں ۾ ڪم ڪرڻ خاص ماڻهن تي وڌيڪ منحصر آهي. اتي آهي ٽاسڪ فيڪٽر ۽ اسان جون نرم صلاحيتون. ڪجهه ماڻهن سان اهو تمام سٺو ڪم ڪري ٿو، ٻين سان اهو خراب ڪم ڪري ٿو. ان مان ضرور فائدا آهن. اهو واضح آهي ته جيتوڻيڪ جوڙيل ڪم جي ضابطن جو ڪافي مشاهدو نه ڪيو ويو آهي، انهن ڪمن کي انجام ڏيڻ جي حقيقت جي نتيجي جي معيار تي مثبت اثر آهي. ذاتي طور تي، مون کي جوڑوں ۾ ڪم ڪرڻ آسان ۽ وڌيڪ مزيدار آهي.
OS تي اثر انداز ڪرڻ جا اعليٰ سطحي طريقا - منصوبابندي ۽ ڪمن سان ڪم ڪرڻ صحيح طور تي اثر پيدا ڪن ٿا: اعليٰ معيار جي علم جي مٽا سٽا ۽ ترقي جي معيار کي بهتر.
هڪ قطار ۾ مختصر نتيجا
- HR عمل ڪندڙ IaC ۾ ڪم ڪن ٿا، پر گھٽ ڪارڪردگيءَ سان.
- مضبوط ڪريو جيڪو ڪم ڪري ٿو.
- اچو توهان جي پنهنجي معاوضي واري ميڪانيزم ۽ عملن سان.
جو ذريعو: www.habr.com