د کوډ په توګه زیربنا: د XP په کارولو سره د ستونزو حل کولو څرنګوالی

سلام، حبر! مخکې، ما د کوډ تمثیل په توګه په زیربنا کې د ژوند په اړه شکایت وکړ او د اوسني وضعیت د حل لپاره یې هیڅ وړاندیز نه دی کړی. نن زه بیرته راغلی یم چې تاسو ته ووایم چې کومې لارې او کړنې به تاسو سره مرسته وکړي چې د نا امیدۍ له کندې څخه خلاص شئ او وضعیت سم لوري ته بوځي.

په تیره مقاله کې "د کوډ په توګه زیربنا: لومړی پیژندنه" ما د دې سیمې په اړه خپل تاثیرات شریک کړل، هڅه مې وکړه چې په دې سیمه کې اوسني وضعیت ته انعکاس ورکړم، او حتی وړاندیز یې وکړ چې معیاري کړنې چې ټولو پراختیا کونکو ته پیژندل کیږي مرسته کولی شي. ښایي داسې ښکاري چې د ژوند په اړه ډیری شکایتونه شتون لري، مګر د اوسني وضعیت څخه د وتلو لپاره هیڅ وړاندیز نه و.

موږ څوک یو، چیرته یو او کومې ستونزې لرو

موږ اوس مهال د Sre Onboarding ټیم کې یو، چې شپږ پروګرام کونکي او درې زیربنا انجنیران لري. موږ ټول هڅه کوو چې زیربنا د کوډ (IaC) په توګه ولیکئ. موږ دا کار کوو ځکه چې موږ اساسا پوهیږو چې څنګه کوډ ولیکو او د "اوسط څخه پورته" پراختیا کونکو تاریخ لرو.

• موږ د ګټو یو سیټ لرو: یو ځانګړی شالید، د کړنو پوهه، د کوډ لیکلو وړتیا، د نوي شیانو زده کولو لیوالتیا.
• او د خړوبولو برخه شتون لري، کوم چې یو منفي هم دی: د زیربنا هارډویر په اړه د پوهې نشتوالی.

د ټیکنالوژۍ سټیک چې موږ یې زموږ په IaC کې کاروو.

• د منابعو د جوړولو لپاره Terraform.
• د انځورونو د راټولولو لپاره پیکر. دا د وینډوز، CentOS 7 انځورونه دي.
• Jsonnet په drone.io کې د ځواکمن جوړښت رامینځته کولو لپاره ، په بیله بیا د پیکر json او زموږ د ټرافارم ماډلونو رامینځته کولو لپاره.
• ازور
• د عکسونو چمتو کولو په وخت کې د ځواب وړ.
• Python د مرستندویه خدماتو او چمتو کولو سکریپټونو لپاره.
• او دا ټول په VSCode کې د پلگ انونو سره د ټیم غړو ترمینځ شریک شوي.

زما څخه پایله وروستۍ مقاله په دې ډول وو: ما هڅه وکړه (لومړی په خپل ځان کې) خوشبیني رامینځته کړم، ما غوښتل ووایم چې موږ به په دې برخه کې د ستونزو او پیچلتیاوو سره د مقابلې لپاره موږ ته پیژندل شوي طریقې او عملونه هڅه وکړو.

موږ اوس مهال د لاندې IaC مسلو سره مبارزه کوو:

• د کوډ پراختیا لپاره د وسیلو او وسیلو نیمګړتیا.
• ورو ځای پرځای کول. زیربنا د ریښتینې نړۍ برخه ده، او دا سست کیدی شي.
• د تګلارو او کړنو نشتوالی.
• موږ نوي یو او ډیر نه پوهیږو.

د ژغورنې لپاره خورا لوی پروګرامینګ (XP).

ټول پراختیا کونکي د خورا لوی برنامه کولو (XP) او هغه عملونو سره آشنا دي چې د هغې تر شا ولاړ دي. زموږ څخه ډیری د دې طریقې سره کار کړی، او دا بریالی شوی دی. نو ولې د زیربنایي ننګونو د لرې کولو لپاره دلته ایښودل شوي اصول او کړنې نه کاروئ؟ موږ پریکړه وکړه چې دا طریقه ونیسو او وګورو چې څه پیښیږي.

ستاسو په صنعت کې د XP تګلارې پلي کولو چک کولدلته د چاپیریال تشریح دی چې XP د دې لپاره مناسب دی، او دا څنګه زموږ سره تړاو لري:

1. په متحرک ډول د سافټویر اړتیاو بدلول. دا موږ ته روښانه وه چې پای هدف څه و. مګر توضیحات توپیر کولی شي. موږ پخپله پریکړه کوو چې چیرې موږ ټیکسي ته اړتیا لرو، نو اړتیاوې په دوره توګه بدلیږي (په عمده توګه پخپله). که موږ د SRE ټیم واخلو، کوم چې پخپله اتومات کوي، او پخپله د کار اړتیاوې او ساحه محدودوي، نو دا ټکی په ښه توګه مناسب دی.

2. د نوي ټیکنالوژۍ په کارولو سره د ټاکل شوي وخت پروژې له امله رامینځته شوي خطرونه. موږ ممکن د خطرونو سره مخ شو کله چې موږ ته نامعلوم شیان وکاروو. او دا زموږ قضیه 100٪ ده. زموږ ټوله پروژه د ټیکنالوژیو کارول وه چې موږ په بشپړ ډول نه پوهیږو. په عموم کې، دا یوه دوامداره ستونزه ده، ځکه چې ... د زیربنا په سکتور کې هر وخت ډیری نوي ټیکنالوژي رامینځته کیږي.

3,4. کوچنی، په ګډه موقعیت کې پراخه پراختیایی ټیم. هغه اتوماتیک ټیکنالوژي چې تاسو یې کاروئ د واحد او فعال ازموینو لپاره اجازه ورکوي. دا دوه ټکي زموږ سره سم ندي. لومړی، موږ همغږي ټیم نه یو، او دوهم، موږ نهه تنه لرو، چې یو لوی ټیم ګڼل کیدی شي. که څه هم، د "لوی" ټیم د ځینو تعریفونو له مخې، ډیری یې 14+ خلک دي.

راځئ چې د XP ځینې کړنې وګورو او دا څنګه د فیډبیک سرعت او کیفیت اغیزه کوي.

د XP فیډبیک لوپ اصول

زما په اند، فیډبیک د پوښتنې ځواب دی، ایا زه سم کار کوم، ایا موږ هلته ځو؟ XP د دې لپاره الهی سکیم لري: د وخت فیډبیک لوپ. په زړه پورې خبره دا ده چې موږ څومره ټیټ یو، په چټکۍ سره موږ د اړینو پوښتنو ځوابونو لپاره OS ترلاسه کوو.

دا د بحث لپاره خورا زړه پورې موضوع ده، چې زموږ د معلوماتي ټکنالوجۍ په صنعت کې دا ممکنه ده چې ژر تر ژره OS ترلاسه کړئ. تصور وکړئ چې د شپږو میاشتو لپاره د یوې پروژې ترسره کول څومره دردناک دي او یوازې بیا معلومه کړئ چې په پیل کې یوه تېروتنه وه. دا په ډیزاین او د پیچلو سیسټمونو په هر ډول جوړښت کې پیښیږي.

زموږ د IaC په قضیه کې، فیډبک زموږ سره مرسته کوي. زه به سمدلاسه پورتني ډیاګرام کې یو کوچنی سمون رامینځته کړم: د خوشې کولو پلان میاشتنۍ دورې نلري ، مګر په ورځ کې څو ځله پیښیږي. د دې OS دورې پورې تړلي ځینې کړنې شتون لري چې موږ به یې په تفصیل سره وګورو.

مهم: فیډبیک کولی شي د پورته ذکر شوي ټولو ستونزو حل وي. د XP تمرینونو سره یوځای، دا کولی شي تاسو د نا امیدۍ څخه وباسي.

څنګه خپل ځان د نا امیدۍ څخه وباسو: درې عملونه

ازموینې

ازموینې د XP فیډبیک لوپ کې دوه ځله ذکر شوي. دا یوازې داسې نه ده. دوی د ټول خورا مهم پروګرام کولو تخنیک لپاره خورا مهم دي.

داسې انګیرل کیږي چې تاسو د واحد او منلو ازموینې لرئ. ځینې ​​تاسو ته په څو دقیقو کې نظر درکوي، نور په څو ورځو کې، نو دوی د لیکلو لپاره ډیر وخت نیسي او لږ ځله بیاکتنه کیږي.

دلته د کلاسیک ازموینې پیرامیډ شتون لري ، کوم چې ښیې چې نور ازموینې باید وي.

دا چوکاټ څنګه موږ ته په IaC پروژه کې پلي کیږي؟ په حقیقت کې ... بالکل نه.

• د واحد ازموینې، سره له دې چې باید ډیری وي، ډیری نشي کیدی. یا دوی په غیر مستقیم ډول یو څه ازموینه کوي. په حقیقت کې، موږ کولی شو ووایو چې موږ دوی په بشپړ ډول نه لیکو. مګر دلته د داسې ازموینو لپاره یو څو غوښتنلیکونه دي چې موږ یې کولی شو:
  1. د jsonnet کوډ ازموینه. دا، د بیلګې په توګه، زموږ د ډرون اسمبلی پایپ لاین دی، کوم چې خورا پیچلی دی. د jsonnet کوډ د ازموینو لخوا ښه پوښل شوی.
     موږ دا کاروو د Jsonnet لپاره د واحد ازموینې چوکاټ.
  2. د سکریپټونو لپاره ازموینې چې اجرا کیږي کله چې سرچینه پیل شي. سکریپټونه په Python کې لیکل شوي، او له همدې امله ازموینې په دوی لیکل کیدی شي.
• دا په احتمالي توګه ممکنه ده چې په ازموینو کې ترتیب چیک کړئ، مګر موږ دا نه کوو. دا هم امکان لري چې له لارې د سرچینو ترتیب کولو قواعد چیک کړئ tflint. په هرصورت، هلته چکونه د ټرافورم لپاره خورا بنسټیز دي، مګر ډیری ازموینې سکریپټونه د AWS لپاره لیکل شوي. او موږ په Azure کې یو، نو دا بیا نه پلي کیږي.
• د اجزاو ادغام ازموینې: دا پدې پورې اړه لري چې تاسو دوی څنګه طبقه بندي کوئ او چیرې یې ځای په ځای کوئ. مګر دوی اساسا کار کوي.

  دا هغه څه دي چې د ادغام ازموینې په څیر ښکاري.

  
  
  دا یو مثال دی کله چې په ډرون CI کې د عکسونو جوړول. دوی ته د رسیدو لپاره ، تاسو باید د پیکر عکس رامینځته کیدو لپاره 30 دقیقې انتظار وکړئ ، بیا د دوی تیریدو لپاره نور 15 دقیقې انتظار وکړئ. مګر دوی شتون لري!

  د انځور تصدیق الګوریتم

  1. پیکر باید لومړی عکس په بشپړ ډول چمتو کړي.
  2. د ازموینې تر څنګ د ځایی دولت سره یو ټرافورم شتون لري ، کوم چې موږ د دې عکس ځای په ځای کولو لپاره کاروو.
  3. کله چې ښکاره شي، نږدې یو کوچنی ماډل کارول کیږي ترڅو د انځور سره کار کول اسانه کړي.
  4. یوځل چې VM له عکس څخه ځای په ځای شي ، چیکونه پیل کیدی شي. په اصل کې، چکونه د موټر په واسطه ترسره کیږي. دا ګوري چې سکریپټونه څنګه په پیل کې کار کوي او ډیمون څنګه کار کوي. د دې کولو لپاره، د ssh یا winrm له لارې موږ نوي پورته شوي ماشین ته ننوځو او د تشکیلاتو حالت وګورئ یا خدمتونه پورته دي.

• وضعیت د ټرافورم لپاره ماډلونو کې د ادغام ازموینې سره ورته دی. دلته یو لنډ جدول دی چې د دې ډول ازموینو ځانګړتیاوې تشریح کوي.

  
  
  په پایپ لاین کې فیډبیک شاوخوا 40 دقیقې دی. هرڅه د اوږدې مودې لپاره پیښیږي. دا د رجعت لپاره کارول کیدی شي، مګر د نوي پرمختګ لپاره دا عموما غیر واقعیت دی. که تاسو د دې لپاره ډیر چمتو یاست، د چلولو سکریپټونه چمتو کړئ، نو تاسو کولی شئ دا 10 دقیقو ته راټیټ کړئ. مګر دا لاهم د واحد ازموینې ندي ، کوم چې په 5 ثانیو کې 100 ټوټې کوي.

د یونټ ازموینو نشتوالی کله چې د عکسونو یا ټیرفارم ماډلونو راټولول د کار جلا کولو خدماتو ته لیږدول هڅوي چې په ساده ډول د REST یا Python سکریپټونو له لارې پرمخ وړل کیدی شي.

د مثال په توګه، موږ اړتیا درلوده چې ډاډ ترلاسه کړو چې کله مجازی ماشین پیل شي، دا ځان په خدمت کې راجستر کوي ScaleFT، او کله چې مجازی ماشین ویجاړ شو ، دا پخپله حذف شو.

څرنګه چې موږ ScaleFT د خدمت په توګه لرو، موږ مجبور یو چې د API له لارې ورسره کار وکړو. هلته یو ریپر لیکل شوی و چې تاسو کولی شئ راوباسئ او ووایاست: "ننور لاړ شئ او دا او هغه حذف کړئ." دا ټول اړین ترتیبات او لاسرسی ذخیره کوي.

موږ دمخه د دې لپاره عادي ازموینې لیکلی شو ، ځکه چې دا د عادي سافټویر څخه توپیر نلري: یو ډول اپیها مسخره کیږي ، تاسو یې راوباسئ ، او وګورئ چې څه پیښیږي.

د ازموینو پایلې: د واحد ازموینه، چې باید په یوه دقیقه کې OS ورکړي، دا نه ورکوي. او په پیرامیډ کې د لوړې ازموینې ډولونه اغیزمن دي ، مګر یوازې د ستونزو برخه پوښي.

جوړه پروګرامونه

ازموینې، البته، ښه دي. تاسو کولی شئ ډیری یې ولیکئ، دوی کولی شي مختلف ډولونه وي. دوی به په خپلو کچو کار وکړي او موږ ته به نظر راکړي. مګر د خراب واحد ازموینې ستونزه ، کوم چې ترټولو ګړندی OS ورکوي ، پاتې دی. په ورته وخت کې، زه لاهم یو ګړندی OS غواړم چې د کار کولو لپاره اسانه او خوندور وي. د پایله شوي حل کیفیت یادونه مه کوئ. خوشبختانه ، داسې تخنیکونه شتون لري چې کولی شي د واحد ازموینې په پرتله حتی ګړندي فیډبیک چمتو کړي. دا جوړه پروګرامینګ دی.

کله چې کوډ لیکل، تاسو غواړئ ژر تر ژره د دې کیفیت په اړه فیډبیک ترلاسه کړئ. هو ، تاسو کولی شئ هرڅه په فیچر څانګه کې ولیکئ (د دې لپاره چې د هیچا لپاره هیڅ شی مات نه کړئ) ، په ګیتوب کې د پلټ غوښتنه وکړئ ، هغه چا ته وټاکئ چې نظر یې وزن لري ، او ځواب ته انتظار وکړئ.

مګر تاسو کولی شئ ډیر وخت انتظار وکړئ. خلک ټول بوخت دي، او ځواب، حتی که یو هم وي، ممکن د لوړ کیفیت نه وي. فرض کړئ چې ځواب سمدستي راغی، بیاکتونکی سمدستي په ټوله مفکوره پوه شو، مګر ځواب لاهم ناوخته راځي، د حقیقت وروسته. کاش چې مخکې وای. دا هغه څه دي چې د جوړې برنامې هدف دی - سمدلاسه ، د لیکلو په وخت کې.

لاندې د جوړې برنامې سټایلونه او په IaC کې کار کولو کې د دوی تطبیق دي:

1. کلاسیک، تجربه لرونکی + تجربه لرونکی، د ټیمر په واسطه بدلول. دوه رولونه - چلوونکی او نیویګیټر. دوه کسان. دوی په ورته کوډ کار کوي او د یوې ټاکلې ټاکل شوې مودې وروسته رولونه بدلوي.

راځئ چې د سټایل سره زموږ د ستونزو مطابقت په پام کې ونیسو:

• ستونزه: د کوډ پراختیا لپاره د وسیلو او وسیلو نیمګړتیا.
  منفي اغیزه: وده کول ډیر وخت نیسي، موږ ورو کوو، د کار سرعت / تال له لاسه ورکوي.
  موږ څنګه مبارزه کوو: موږ مختلف اوزار کاروو، یو عام IDE او همدارنګه شارټ کټ زده کوو.
• ستونزه: ورو ځای پرځای کول.
  منفي اغیزه: د کوډ کاري برخې رامینځته کولو لپاره وخت زیاتوي. موږ د انتظار په وخت کې ستړي کیږو، زموږ لاسونه د انتظار په وخت کې د بل څه کولو لپاره لاس ته راځي.
  موږ څنګه مبارزه کوو: موږ په دې بریالي نه شو.
• ستونزه: د تګلارو او کړنو نشتوالی.
  منفي اغیزه: پدې اړه هیڅ پوهه نشته چې څنګه یې ښه ترسره کړئ او څنګه یې په خراب ډول ترسره کړئ. د فیډبیک رسید اوږدوي.
  موږ څنګه مبارزه کوو: د نظرونو دوه اړخیز تبادله او په جوړه کار کې عمل تقریبا ستونزه حل کوي.

په IaC کې د دې سټایل کارولو اصلي ستونزه د کار غیر مساوي سرعت دی. د دودیز سافټویر پراختیا کې، تاسو خورا یونیفورم حرکت لرئ. تاسو کولی شئ پنځه دقیقې مصرف کړئ او N ولیکئ. 10 دقیقې مصرف کړئ او 2N ، 15 دقیقې - 3N ولیکئ. دلته تاسو کولی شئ پنځه دقیقې مصرف کړئ او N ولیکئ ، او بیا نور 30 ​​دقیقې مصرف کړئ او د N لسمه برخه ولیکئ. څیړنه وخت نیسي او پخپله د پروګرام کولو څخه ډډه کوي.

پایله: په خالص شکل کې دا زموږ لپاره مناسب نه دی.

2. پینګ پونګ. پدې طریقه کې یو کس شامل دی چې ازموینه لیکي او بل یې پلي کوي. د دې حقیقت په پام کې نیولو سره چې هرڅه د واحد ازموینو سره پیچلي دي ، او تاسو باید د ادغام ازموینه ولیکئ چې برنامه کولو کې ډیر وخت نیسي ، د پینګ پونګ ټولې اسانتیا له مینځه ځي.

زه کولی شم ووایم چې موږ د ازموینې سکریپټ ډیزاین کولو او د دې لپاره کوډ پلي کولو لپاره د مسؤلیتونو جلا کولو هڅه کړې. یو ګډونوال د سکریپټ سره راغی، د کار په دې برخه کې هغه مسؤلیت درلود، هغه وروستی کلمه درلوده. او بل یې د تطبیق مسولیت په غاړه درلود. دا ښه کار وکړ. د دې طریقې سره د سکریپټ کیفیت لوړیږي.

پایله: افسوس، د کار سرعت په IaC کې د جوړې پروګرام کولو تمرین په توګه د پینګ پونګ کارولو ته اجازه نه ورکوي.

3.Strong سټایل. ستونزمن تمرین. نظر دا دی چې یو ګډون کوونکی د لارښود نیویګیټر کیږي، او دویم د اعدام چلوونکي رول لوبوي. په دې حالت کې، د پریکړې کولو حق یوازې د نیویګیټر سره دی. چلوونکی یوازې چاپ کوي او کولی شي د یوې کلمې سره څه پیښیږي اغیزه وکړي. رولونه د اوږدې مودې لپاره نه بدلیږي.

د زده کړې لپاره ښه، مګر قوي نرم مهارتونو ته اړتیا لري. دا هغه ځای دی چې موږ یې له مینځه یوسو. تخنیک ستونزمن و. او دا د زیربنا په اړه هم نه ده.

پایله: دا په بالقوه توګه کارول کیدی شي، موږ هڅه نه پریږدو.

4. حرکت کول، غولیدل او ټول پیژندل شوي مګر لیست شوي سټایلونه ندي موږ دې ته پام نه کوو، ځکه موږ دا هڅه نه ده کړې او زموږ د کار په شرایطو کې د دې په اړه خبرې کول ناممکن دي.

د جوړې برنامې کارولو عمومي پایلې:

• موږ د کار غیر مساوي سرعت لرو، کوم چې ګډوډ دی.
• موږ په کافي اندازه ښه نرم مهارتونو ته مخه کړه. او د موضوع ساحه زموږ د دې نیمګړتیاوو په لرې کولو کې مرسته نه کوي.
• اوږدې ازموینې او د وسیلو سره ستونزې د جوړه وده ستونزمن کوي.

5. سره له دې، بریالیتوبونه شتون لري. موږ د خپل طریقې سره راغلو "کنورژن - انحراف". زه به په لنډه توګه تشریح کړم چې دا څنګه کار کوي.

موږ د څو ورځو لپاره دایمي ملګري لرو (له یوې اونۍ څخه لږ). موږ په ګډه یو کار کوو. موږ د یو څه وخت لپاره سره ناست یو: یو لیکي، بل ناست دی او د ملاتړ ټیم ګوري. بیا موږ د یو څه وخت لپاره توزیع کوو، هر یو یو څه خپلواک شیان ترسره کوي، بیا موږ یوځل بیا یوځای کیږو، په چټکۍ سره همغږي کوو، یو څه سره یوځای کوو او بیا منحل کوو.

پلان جوړونه او ارتباط

د تمرینونو وروستی بلاک چې له لارې د OS ستونزې حل کیږي پخپله د دندو سره د کار تنظیم دی. پدې کې د تجربې تبادله هم شامله ده چې د جوړه کار څخه بهر وي. راځئ چې درې عملونه وګورو:

1. د هدف ونې له لارې موخې. موږ د پروژې عمومي مدیریت د یوې ونې له لارې تنظیم کړ چې په راتلونکي کې په نه ختمیدونکي ډول تیریږي. په تخنیکي توګه، تعقیب په میرو کې ترسره کیږي. یو کار شتون لري - دا یو منځنی هدف دی. له دې څخه یا کوچني اهداف یا د دندو ګروپونه ځي. دندې پخپله د دوی څخه راځي. ټول کارونه په دې بورډ کې جوړ او ساتل کیږي.

دا سکیم فیډبیک هم وړاندې کوي، کوم چې په ورځ کې یو ځل واقع کیږي کله چې موږ په لاریونونو کې همغږي کوو. د هرچا په وړاندې د ګډ پلان درلودل، مګر جوړښت او په بشپړه توګه خلاص، هرڅوک ته اجازه ورکوي چې پوه شي چې څه پیښیږي او موږ څومره پرمختګ کړی دی.

د دندو د لید لید ګټې:

• لامل. هر کار یو نړیوال هدف ته رسوي. دندې په کوچنیو اهدافو ویشل شوي دي. د زیربنا ډومین پخپله خورا تخنیکي دی. دا تل سمدلاسه روښانه نده چې کوم ځانګړي اغیزه لري، د بیلګې په توګه، بل نګینکس ته د مهاجرت په اړه د کتاب لیکل په سوداګرۍ باندې لري. نږدې د هدف کارت درلودل دا روښانه کوي.
  
  علت د ستونزو یو مهم ملکیت دی. دا مستقیم پوښتنې ته ځواب ورکوي: "ایا زه سم کار کوم؟"
• موازي. زموږ څخه نهه شتون لري، او دا په ساده ډول په فزیکي توګه ناممکن دی چې هرڅوک په یوه دنده کې وغورځوي. د یوې سیمې څخه دندې ممکن تل کافي نه وي. موږ مجبور یو چې د کوچنیو کاري ډلو ترمنځ موازي کار وکړو. په ورته وخت کې، ډلې د یو څه وخت لپاره په خپله دنده کې ناست وي، دوی د بل چا لخوا پیاوړي کیدی شي. کله کله خلک له دې کاري ډلې څخه غورځېږي. یو څوک په رخصتۍ ځي، یو څوک د DevOps conf لپاره راپور جوړوي، څوک د هابر په اړه مقاله لیکي. پدې پوهیدل چې کوم اهداف او دندې په موازي ډول ترسره کیدی شي خورا مهم کیږي.

2. د سهار د غونډو بدلیدونکي وړاندیز کونکي. په سټنډ اپ کې موږ دا ستونزه لرو - خلک په موازي ډول ډیری دندې ترسره کوي. ځینې ​​​​وختونه دندې په نرمۍ سره تړلې وي او هیڅ پوهه نه وي چې څوک څه کوي. او د ټیم د بل غړي نظر خورا مهم دی. دا اضافي معلومات دي چې کولی شي د ستونزې حل کولو کورس بدل کړي. البته، معمولا یو څوک ستاسو سره وي، مګر مشورې او لارښوونې تل ګټورې وي.

د دې وضعیت د ښه کولو لپاره، موږ د "د مخکښ موقف بدلولو" تخنیک کارولی. اوس دوی د یو ځانګړي لیست سره سم ګرځیدلي، او دا د هغې اغیز لري. کله چې ستاسو وار وي، تاسو مجبور یاست چې ډوب شئ او پوه شئ چې د ښه سکرم ناستې د چلولو لپاره څه تیریږي.

3. داخلي ډیمو. د جوړه پروګرام کولو څخه د ستونزې په حل کې مرسته، د ستونزې په ونې کې لیدل او په سهار کې د سکرم غونډو کې مرسته ښه دي، مګر مثالی ندي. د یوې جوړې په توګه، تاسو یوازې د خپلې پوهې له مخې محدود یاست. د کاري ونې سره مرسته کوي چې په نړیواله کچه پوه شي چې څوک څه کوي. او د سهار په ناسته کې وړاندې کوونکی او همکاران به ستاسو ستونزو ته ژور نه ګوري. دوی شاید یو څه له لاسه ورکړي.

د حل لاره یو بل ته د ترسره شوي کار په ښودلو او بیا بحث کولو کې وموندل شوه. موږ په اونۍ کې یو ځل د یو ساعت لپاره سره ګورو او د هغو دندو د حل توضیحات ښیې چې موږ په تیره اونۍ کې ترسره کړي دي.

د مظاهرې په جریان کې، دا اړینه ده چې د دندې توضیحات ښکاره کړئ او ډاډ ترلاسه کړئ چې د هغې عملیات وښيي.

راپور د چک لیست په کارولو سره ترسره کیدی شي.1. په شرایطو کې داخل کړئ. دا کار له کوم ځای څخه راغلی، ولې اړتیا وه؟

2. پخوا ستونزه څنګه حل شوه؟ د مثال په توګه، د موږک لوی کلیک کولو ته اړتیا وه، یا دا ناممکن وه چې هیڅ شی ترسره نشي.

3. موږ دا څنګه ښه کوو. د مثال په توګه: "وګورئ، اوس سکریپټوسک شتون لري، دلته ریډم دی."

4. وښایاست چې دا څنګه کار کوي. دا مشوره ورکول کیږي چې په مستقیم ډول د ځینې کاروونکي سناریو پلي کړئ. زه X غواړم، زه Y کوم، زه Y (یا Z) وینم. د مثال په توګه، زه NGINX ځای پرځای کوم، یو آر ایل سګرټ، او 200 OK ترلاسه کړم. که عمل اوږد وي، مخکې یې چمتو کړئ نو تاسو کولی شئ وروسته یې وښایئ. دا مشوره ورکول کیږي چې د ډیمو څخه یو ساعت دمخه یې مات نه کړئ، که دا نازک وي.

5. تشریح کړئ چې ستونزه څومره په بریالیتوب سره حل شوې، کوم مشکلات پاتې دي، کوم بشپړ شوي ندي، په راتلونکي کې کوم پرمختګونه ممکن دي. د مثال په توګه، اوس CLI، بیا به په CI کې بشپړ اتومات وي.

دا د هر سپیکر لپاره مشوره ورکول کیږي چې دا د 5-10 دقیقو لپاره وساتئ. که ستاسو وینا په ښکاره ډول مهمه وي او ډیر وخت ونیسي، دا دمخه د sre-takeover چینل کې همغږي کړئ.

د مخامخ برخې څخه وروسته په موضوع کې تل بحث وي. دا هغه ځای دی چې زموږ د دندو په اړه موږ ورته اړتیا لرو.

د پایلې په توګه، یوه سروې ترسره کیږي ترڅو معلومه کړي چې څه پیښیږي. دا د وینا د جوهر او د دندې اهمیت په اړه نظر دی.

اوږده پایلې او نور څه دي

ښایي داسې بریښي چې د مقالې سر یو څه نا امیدي دی. دا غلط دی. د فیډبیک دوه ټیټې کچې ، د بیلګې په توګه ازموینې او جوړه برنامې ، کار. د دودیز پرمختګ په څیر کامل ندی، مګر د هغې څخه مثبت اغیزه شتون لري.

ازموینې، په اوسني بڼه کې، یوازې د جزوی کوډ پوښښ چمتو کوي. د تشکیلاتو ډیری دندې بې ازموینې پای ته رسیږي. په ریښتیني کار باندې د دوی نفوذ کله چې کوډ لیکل کم وي. په هرصورت، د ادغام ازموینو اغیزه شتون لري، او دوی تاسو ته اجازه درکوي چې په بې رحمۍ سره د بیا رغونې کار ترسره کړئ. دا یوه لویه لاسته راوړنه ده. همدارنګه، د لوړې کچې ژبو پراختیا ته د تمرکز بدلون سره (موږ پیتون لرو، لاړ شو)، ستونزه له منځه ځي. او تاسو د "ګلو" لپاره ډیرو چکونو ته اړتیا نلرئ؛ د عمومي ادغام چک کافی دی.

په جوړه کې کار کول په ځانګړي خلکو پورې اړه لري. دلته د کار فکتور او زموږ نرم مهارتونه شتون لري. د ځینو خلکو سره دا خورا ښه کار کوي، د نورو سره دا بد کار کوي. له دې څخه یقینا ګټې شتون لري. دا روښانه ده چې حتی که د جوړه کار قواعد په کافي اندازه نه وي مشاهده شوي، په ګډه د دندو ترسره کولو حقیقت د پایلې په کیفیت مثبت اغیزه لري. په شخصي توګه، زه په جوړو کې کار کول اسانه او ډیر خوندور وموم.

په OS باندې د نفوذ کولو لوړې کچې لارې - د دندو سره پلان کول او کار کول دقیقا اغیزې رامینځته کوي: د لوړ کیفیت پوهه تبادله او د پراختیا کیفیت ښه شوی.

په یوه کرښه کې لنډې پایلې

• د بشري حقونو متخصصین په IaC کې کار کوي، مګر د لږ موثریت سره.
• هغه څه چې کار کوي پیاوړي کړئ.
• د خپل تاوان ورکولو میکانیزمونو او عملونو سره راشئ.

سرچینه: www.habr.com