زیرساخت به عنوان کد: نحوه غلبه بر مشکلات با استفاده از XP

سلام، هابر! قبلاً از زندگی در زیرساخت به عنوان پارادایم کد گله داشتم و چیزی برای حل وضعیت فعلی ارائه نکردم. امروز برگشتم تا به شما بگویم چه رویکردها و شیوه‌هایی به شما کمک می‌کند از ورطه ناامیدی فرار کنید و وضعیت را در مسیر درست هدایت کنید.

در مقاله قبلی "زیرساخت به عنوان کد: اولین آشنایی" من برداشت های خود را از این منطقه به اشتراک گذاشتم، سعی کردم وضعیت فعلی در این زمینه را بازتاب دهم و حتی پیشنهاد کردم که روش های استاندارد شناخته شده برای همه توسعه دهندگان می تواند کمک کند. ممکن است به نظر برسد که شکایت های زیادی از زندگی وجود دارد، اما هیچ پیشنهادی برای خروج از وضعیت فعلی وجود ندارد.

ما کی هستیم، کجا هستیم و چه مشکلاتی داریم

ما در حال حاضر در تیم Sre Onboarding هستیم که از شش برنامه نویس و سه مهندس زیرساخت تشکیل شده است. همه ما در تلاش هستیم تا Infrastructure را به صورت کد (IaC) بنویسیم. ما این کار را انجام می دهیم زیرا اساساً می دانیم چگونه کد بنویسیم و سابقه توسعه دهندگان "بالاتر از میانگین" را داریم.

• ما مجموعه ای از مزایا داریم: پیشینه خاصی، دانش شیوه ها، توانایی نوشتن کد، تمایل به یادگیری چیزهای جدید.
• و یک بخش افتادگی وجود دارد، که آن نیز منفی است: عدم دانش در مورد سخت افزار زیرساخت.

پشته فناوری که در IaC خود استفاده می کنیم.

• Terraform برای ایجاد منابع.
• بسته بندی برای مونتاژ تصاویر. اینها تصاویر ویندوز، CentOS 7 هستند.
• Jsonnet برای ساختن یک ساخت قدرتمند در drone.io، و همچنین تولید بسته‌کننده json و ماژول‌های terraform ما.
• لاجوردی
• هنگام تهیه تصاویر قابل پاسخگویی است.
• پایتون برای خدمات کمکی و تهیه اسکریپت ها.
• و همه اینها در VSCode با افزونه های به اشتراک گذاشته شده بین اعضای تیم.

نتیجه گیری از من آخرین مقاله به این صورت بود: سعی کردم (اول از همه در خودم) خوش بینی را القا کنم، می خواستم بگویم برای مقابله با مشکلات و پیچیدگی هایی که در این زمینه وجود دارد، رویکردها و شیوه های شناخته شده خود را امتحان خواهیم کرد.

ما در حال حاضر با مشکلات IaC زیر دست و پنجه نرم می کنیم:

• نقص ابزارها و ابزارهای توسعه کد.
• استقرار آهسته زیرساخت بخشی از دنیای واقعی است و می تواند کند باشد.
• فقدان رویکردها و شیوه ها.
• ما جدید هستیم و چیز زیادی نمی دانیم.

برنامه نویسی شدید (XP) برای نجات

همه توسعه دهندگان با برنامه نویسی افراطی (XP) و شیوه هایی که پشت آن قرار دارند آشنا هستند. بسیاری از ما با این رویکرد کار کرده ایم و موفقیت آمیز بوده است. پس چرا از اصول و شیوه های ذکر شده در آنجا برای غلبه بر چالش های زیرساخت استفاده نمی کنیم؟ تصمیم گرفتیم این رویکرد را در پیش بگیریم و ببینیم چه اتفاقی می افتد.

بررسی کاربردی بودن رویکرد XP در صنعت شمادر اینجا شرحی از محیطی که XP برای آن مناسب است و نحوه ارتباط آن با ما آورده شده است:

1. تغییر پویا نیازمندی های نرم افزار. برای ما مشخص بود که هدف نهایی چیست. اما جزئیات می تواند متفاوت باشد. ما خودمان تصمیم می گیریم که کجا باید تاکسی کنیم، بنابراین شرایط به طور دوره ای تغییر می کند (عمدتا توسط خودمان). اگر تیم SRE را در نظر بگیریم که خود اتوماسیون را انجام می دهد و خود الزامات و دامنه کار را محدود می کند، این نکته به خوبی مطابقت دارد.

2. خطرات ناشی از پروژه های زمان ثابت با استفاده از فناوری جدید. ممکن است هنگام استفاده از چیزهایی که برایمان ناشناخته است، با خطراتی مواجه شویم. و این 100% مورد ماست. کل پروژه ما استفاده از فناوری هایی بود که به طور کامل با آنها آشنایی نداشتیم. به طور کلی، این یک مشکل دائمی است، زیرا ... بسیاری از فناوری‌های جدید همواره در بخش زیرساخت در حال ظهور هستند.

3,4. تیم توسعه توسعه یافته کوچک با هم قرار گرفتن. فناوری خودکاری که استفاده می‌کنید امکان تست‌های واحد و عملکردی را فراهم می‌کند. این دو نکته چندان به درد ما نمی خورد. اولا ما تیم هماهنگی نیستیم و دوم اینکه 14 نفر هستیم که می توان آن ها را تیم بزرگی دانست. اگرچه، طبق برخی از تعاریف تیم "بزرگ"، تعداد زیادی XNUMX+ نفر است.

بیایید به برخی از روش های XP و چگونگی تأثیر آنها بر سرعت و کیفیت بازخورد نگاه کنیم.

اصل حلقه بازخورد XP

در درک من، بازخورد پاسخ این سوال است که آیا کار درستی انجام می دهم، آیا ما به آنجا می رویم؟ XP یک طرح الهی برای این دارد: یک حلقه بازخورد زمانی. نکته جالب این است که هرچه پایین‌تر باشیم، سریع‌تر می‌توانیم سیستم‌عامل را برای پاسخگویی به سوالات ضروری آماده کنیم.

این یک موضوع نسبتاً جالب برای بحث است، اینکه در صنعت فناوری اطلاعات ما امکان دریافت سریع یک سیستم عامل وجود دارد. تصور کنید چقدر دردناک است که یک پروژه را به مدت شش ماه انجام دهید و تنها پس از آن متوجه شوید که در همان ابتدا اشتباهی وجود داشته است. این در طراحی و در هر ساخت و ساز سیستم های پیچیده اتفاق می افتد.

در مورد IaC ما، بازخورد به ما کمک می کند. من بلافاصله یک تنظیم کوچک در نمودار بالا انجام می دهم: برنامه انتشار یک چرخه ماهانه ندارد، اما چندین بار در روز رخ می دهد. برخی از اقدامات مرتبط با این چرخه سیستم عامل وجود دارد که ما با جزئیات بیشتر به آنها خواهیم پرداخت.

مهم: بازخورد می تواند راه حلی برای تمام مشکلات ذکر شده در بالا باشد. همراه با روش های XP، می تواند شما را از ورطه ناامیدی بیرون بکشد.

چگونه خود را از ورطه ناامیدی بیرون بکشیم: سه ​​تمرین

تستها

تست ها دو بار در حلقه بازخورد XP ذکر شده اند. فقط اینطور نیست. آنها برای کل تکنیک Extreme Programming بسیار مهم هستند.

فرض بر این است که شما آزمون های واحد و پذیرش دارید. برخی در عرض چند دقیقه به شما بازخورد می دهند، برخی دیگر در چند روز، بنابراین نوشتن آنها بیشتر طول می کشد و کمتر مرور می شوند.

یک هرم آزمایش کلاسیک وجود دارد که نشان می دهد باید آزمایش های بیشتری وجود داشته باشد.

چگونه این چارچوب برای ما در پروژه IaC اعمال می شود؟ در واقع... نه اصلا.

• تست های واحد، علیرغم اینکه تعداد آنها باید زیاد باشد، نمی تواند خیلی زیاد باشد. یا خیلی غیر مستقیم چیزی را آزمایش می کنند. در واقع می توان گفت که اصلا آنها را نمی نویسیم. اما در اینجا چند برنامه کاربردی برای چنین آزمایشاتی وجود دارد که ما توانستیم انجام دهیم:
  1. تست کد jsonnet برای مثال، این خط لوله مونتاژ پهپاد ما است که بسیار پیچیده است. کد jsonnet به خوبی توسط تست ها پوشش داده شده است.
     ما از این استفاده می کنیم چارچوب تست واحد برای Jsonnet.
  2. تست اسکریپت هایی که با شروع منبع اجرا می شوند. اسکریپت ها به زبان پایتون نوشته می شوند و بنابراین می توان تست هایی را روی آنها نوشت.
• به طور بالقوه امکان بررسی پیکربندی در آزمایش ها وجود دارد، اما ما این کار را انجام نمی دهیم. همچنین پیکربندی چک کردن قوانین پیکربندی منابع از طریق امکان پذیر است فلینت. با این حال، بررسی‌های موجود در آنجا برای terraform بسیار ابتدایی هستند، اما بسیاری از اسکریپت‌های تست برای AWS نوشته شده‌اند. و ما در Azure هستیم، بنابراین این دوباره اعمال نمی شود.
• تست های یکپارچه سازی مولفه ها: بستگی به نحوه طبقه بندی آنها و محل قرار دادن آنها دارد. اما آنها اساسا کار می کنند.

  این همان چیزی است که تست های یکپارچه سازی به نظر می رسد.

  
  
  این یک مثال در هنگام ساخت تصاویر در Drone CI است. برای رسیدن به آنها، باید 30 دقیقه صبر کنید تا تصویر Packer شکل بگیرد، سپس 15 دقیقه دیگر صبر کنید تا آنها بگذرند. اما آنها وجود دارند!

  الگوریتم تایید تصویر

  1. پکر ابتدا باید تصویر را به طور کامل آماده کند.
  2. در کنار تست یک terraform با حالت محلی وجود دارد که ما از آن برای استقرار این تصویر استفاده می کنیم.
  3. هنگام باز کردن، از یک ماژول کوچک در نزدیکی آن استفاده می‌شود تا کار با تصویر را آسان‌تر کند.
  4. هنگامی که VM از تصویر مستقر شد، بررسی ها می توانند شروع شوند. اصولاً بررسی ها با ماشین انجام می شود. بررسی می‌کند که اسکریپت‌ها در راه‌اندازی چگونه کار می‌کنند و شیاطین چگونه کار می‌کنند. برای انجام این کار، از طریق ssh یا winrm وارد ماشین جدید شده و وضعیت پیکربندی یا بالا بودن سرویس ها را بررسی می کنیم.

• وضعیت مشابه با تست های ادغام در ماژول ها برای terraform است. در اینجا جدول کوتاهی ارائه شده است که ویژگی های چنین آزمون هایی را توضیح می دهد.

  
  
  بازخورد در مورد خط لوله حدود 40 دقیقه است. همه چیز برای مدت بسیار طولانی اتفاق می افتد. می توان از آن برای رگرسیون استفاده کرد، اما برای توسعه جدید به طور کلی غیر واقعی است. اگر برای این کار بسیار بسیار آماده هستید، اسکریپت های در حال اجرا را آماده کنید، سپس می توانید آن را به 10 دقیقه کاهش دهید. اما اینها هنوز تست های واحد نیستند که 5 قطعه را در 100 ثانیه انجام می دهند.

عدم وجود تست‌های واحد هنگام مونتاژ تصاویر یا ماژول‌های زمینی، انتقال کار به سرویس‌های جداگانه‌ای را که می‌توانند به سادگی از طریق REST یا اسکریپت‌های پایتون اجرا شوند، تشویق می‌کند.

به عنوان مثال، ما باید مطمئن می شدیم که وقتی ماشین مجازی راه اندازی می شود، خودش را در سرویس ثبت می کند ScaleFTو هنگامی که ماشین مجازی از بین رفت، خود را حذف کرد.

از آنجایی که ما ScaleFT را به عنوان یک سرویس داریم، مجبوریم از طریق API با آن کار کنیم. لفافی نوشته بود که می‌توانی آن را بکشی و بگویی: برو داخل و این و آن را پاک کن. تمام تنظیمات و دسترسی های لازم را ذخیره می کند.

ما قبلاً می توانیم آزمایش های عادی را برای این کار بنویسیم، زیرا هیچ تفاوتی با نرم افزار معمولی ندارد: نوعی apiha مورد تمسخر قرار می گیرد، شما آن را بکشید و ببینید چه اتفاقی می افتد.

نتایج تست ها: تست واحد که باید در یک دقیقه سیستم عامل را بدهد، آن را نمی دهد. و انواع تست های بالاتر در هرم موثر هستند، اما تنها بخشی از مشکلات را پوشش می دهند.

برنامه نویسی جفت

تست ها البته خوب هستند. شما می توانید تعداد زیادی از آنها را بنویسید، آنها می توانند انواع مختلفی داشته باشند. آنها در سطوح خود کار خواهند کرد و به ما بازخورد خواهند داد. اما مشکل تست‌های Unit بد، که سریع‌ترین سیستم‌عامل را ارائه می‌دهند، همچنان پابرجاست. در عین حال، من هنوز یک سیستم عامل سریع می خواهم که کار با آن آسان و دلپذیر باشد. ناگفته نماند کیفیت محلول حاصله. خوشبختانه، تکنیک‌هایی وجود دارند که می‌توانند بازخورد سریع‌تری نسبت به تست‌های واحد ارائه دهند. این برنامه نویسی جفتی است.

هنگام نوشتن کد، می خواهید در اسرع وقت در مورد کیفیت آن بازخورد دریافت کنید. بله، شما می توانید همه چیز را در یک شاخه ویژگی بنویسید (به طوری که چیزی برای کسی شکسته نشود)، در Github درخواست کشش بدهید، آن را به فردی که نظرش وزن دارد اختصاص دهید و منتظر پاسخ باشید.

اما می توانید مدت زیادی صبر کنید. مردم همه مشغول هستند و پاسخ، حتی اگر پاسخی باشد، ممکن است از بالاترین کیفیت برخوردار نباشد. فرض کنید که پاسخ فوراً آمده است، بازبین فوراً کل ایده را درک کرده است، اما پاسخ همچنان دیر، پس از واقعیت است. کاش زودتر بود این همان چیزی است که برنامه‌نویسی جفتی به آن هدف می‌شود - بلافاصله، در زمان نوشتن.

در زیر سبک های برنامه نویسی زوج و کاربرد آنها در کار بر روی IaC آورده شده است:

1. کلاسیک، با تجربه + با تجربه، تغییر با تایمر. دو نقش - راننده و ناوبر. دو نفر. آن‌ها روی همان کد کار می‌کنند و پس از یک دوره از پیش تعیین‌شده، نقش‌ها را تغییر می‌دهند.

بیایید سازگاری مشکلات خود را با سبک در نظر بگیریم:

• مشکل: نقص ابزارها و ابزارهای توسعه کد.
  تأثیر منفی: توسعه آن بیشتر طول می‌کشد، سرعت ما کاهش می‌یابد، سرعت/ریتم کار از بین می‌رود.
  نحوه مبارزه: ما از ابزار متفاوت، یک IDE مشترک استفاده می کنیم و همچنین میانبرها را یاد می گیریم.
• مشکل: استقرار آهسته
  تأثیر منفی: زمان لازم برای ایجاد یک قطعه کد کار را افزایش می دهد. حوصله‌مان سر می‌رود، در حالی که منتظریم دست‌هایمان برای انجام کار دیگری دراز می‌شود.
  نحوه مبارزه: ما بر آن غلبه نکردیم.
• مشکل: فقدان رویکردها و شیوه ها.
  تأثیر منفی: هیچ دانشی در مورد چگونگی انجام آن به خوبی و نحوه انجام آن ضعیف وجود ندارد. دریافت بازخورد را طولانی تر می کند.
  چگونه می جنگیم: تبادل نظرات و شیوه های متقابل در کار زوجی تقریباً مشکل را حل می کند.

مشکل اصلی استفاده از این سبک در IaC سرعت ناهموار کار است. در توسعه نرم افزار سنتی، شما حرکت بسیار یکنواختی دارید. می توانید پنج دقیقه وقت بگذارید و N بنویسید. 10 دقیقه بگذرانید و 2N بنویسید، 15 دقیقه - 3N. در اینجا می توانید پنج دقیقه وقت بگذارید و N بنویسید، و سپس 30 دقیقه دیگر وقت بگذارید و یک دهم N بنویسید. اینجا چیزی نمی دانید، گیر کرده اید، احمق. بررسی زمان می برد و حواس خود را از برنامه نویسی منحرف می کند.

نتیجه گیری: در شکل خالص آن برای ما مناسب نیست.

2. پینگ پنگ. این رویکرد شامل نوشتن آزمون یک نفر و انجام پیاده سازی برای آن است. با در نظر گرفتن این واقعیت که همه چیز با تست های Unit پیچیده است و باید یک تست یکپارچه سازی بنویسید که برنامه ریزی آن زمان زیادی می برد، تمام راحتی پینگ پنگ از بین می رود.

می‌توانم بگویم که سعی کردیم مسئولیت‌ها را برای طراحی یک اسکریپت تست و پیاده‌سازی کد برای آن تفکیک کنیم. یکی از شرکت کنندگان فیلمنامه را ارائه کرد، در این قسمت از کار او مسئولیت داشت، حرف آخر را می زد. و دیگری مسئول اجرا بود. خوب کار کرد. کیفیت فیلمنامه با این رویکرد افزایش می یابد.

نتیجه گیری: افسوس که سرعت کار اجازه استفاده از پینگ پنگ را به عنوان یک تمرین برنامه نویسی جفت در IaC نمی دهد.

3. سبک قوی. تمرین دشوار. ایده این است که یک شرکت‌کننده هدایت‌گر دستورالعمل می‌شود و دومی نقش راننده اجرا را بر عهده می‌گیرد. در این مورد، حق تصمیم گیری منحصراً بر عهده ناوبر است. درایور فقط چاپ می کند و می تواند با یک کلمه بر آنچه اتفاق می افتد تأثیر بگذارد. نقش ها برای مدت طولانی تغییر نمی کنند.

برای یادگیری خوب است، اما به مهارت های نرم قوی نیاز دارد. اینجاست که ما لنگ زدیم. تکنیک مشکل بود. و حتی در مورد زیرساخت ها نیست.

نتیجه گیری: به طور بالقوه می توان از آن استفاده کرد، ما از تلاش دست نمی کشیم.

4. موبینگ، ازدحام و همه سبک های شناخته شده اما نامشخص ما آن را در نظر نمی گیریم، زیرا ما آن را امتحان نکرده‌ایم و نمی‌توان در مورد آن در چارچوب کارمان صحبت کرد.

نتایج کلی در استفاده از برنامه نویسی زوجی:

• سرعت کار ناهمواری داریم که گیج کننده است.
• ما به مهارت های نرم ناکافی خوب برخورد کردیم. و حوزه موضوعی کمکی به غلبه بر این کاستی های ما نمی کند.
• آزمایش های طولانی و مشکلات ابزارها، توسعه جفتی را دشوار می کند.

5. با وجود این، موفقیت هایی وجود داشت. ما به روش خودمان "همگرایی - واگرایی" رسیدیم. من به طور خلاصه نحوه عملکرد آن را شرح خواهم داد.

برای چند روز (کمتر از یک هفته) شرکای دائمی داریم. ما یک کار را با هم انجام می دهیم. مدتی کنار هم می نشینیم: یکی می نویسد، دیگری می نشیند و تیم پشتیبانی را تماشا می کند. بعد مدتی پراکنده می شویم، هر کدام کارهای مستقلی انجام می دهند، بعد دوباره دور هم جمع می شویم، خیلی سریع همگام می شویم، کاری را با هم انجام می دهیم و دوباره پراکنده می شویم.

برنامه ریزی و ارتباط

آخرین بلوک روش ها که از طریق آن مشکلات سیستم عامل حل می شود، سازماندهی کار با خود وظایف است. این همچنین شامل تبادل تجربه است که خارج از کار زوجی است. بیایید به سه تمرین نگاه کنیم:

1. اهداف از طریق درخت هدف. ما مدیریت کلی پروژه را از طریق درختی سازماندهی کردیم که بی پایان به آینده می رود. از نظر فنی ردیابی در میرو انجام می شود. یک وظیفه وجود دارد - این یک هدف میانی است. از آن اهداف کوچکتر یا گروهی از وظایف. وظایف خود از آنها ناشی می شود. تمام وظایف در این برد ایجاد و نگهداری می شوند.

این طرح همچنین بازخوردی را ارائه می دهد، که یک بار در روز هنگام همگام سازی در رالی ها رخ می دهد. داشتن یک برنامه مشترک در مقابل همه، اما ساختارمند و کاملاً باز، به همه این امکان را می دهد که از آنچه در حال رخ دادن است و تا چه حد پیشرفت کرده ایم آگاه باشند.

مزایای دید بصری وظایف:

• علیت. هر کار به یک هدف جهانی منجر می شود. وظایف به اهداف کوچکتر دسته بندی می شوند. حوزه زیرساخت خود کاملاً فنی است. همیشه بلافاصله مشخص نیست که مثلاً نوشتن یک runbook در مهاجرت به یک nginx دیگر چه تأثیر خاصی بر تجارت دارد. داشتن کارت هدف در نزدیکی آن، این موضوع را واضح تر می کند.
  
  علیت یک ویژگی مهم مشکلات است. مستقیماً به این سؤال پاسخ می دهد: "آیا کارم را درست انجام می دهم؟"
• موازی سازی. ما XNUMX نفر هستیم، و از نظر فیزیکی غیرممکن است که همه را در یک کار پرتاب کنیم. وظایف یک منطقه نیز ممکن است همیشه کافی نباشد. ما مجبوریم کار را بین گروه های کوچک موازی کنیم. در عین حال، گروه ها برای مدتی روی وظیفه خود می نشینند، می توانند توسط شخص دیگری تقویت شوند. گاهی افراد از این کارگروه دور می شوند. شخصی به تعطیلات می رود، شخصی برای conf DevOps گزارش می دهد، کسی مقاله ای در Habr می نویسد. دانستن اینکه چه اهداف و وظایفی را می توان به طور موازی انجام داد بسیار مهم می شود.

2. جایگزین مجریان جلسات صبحگاهی. در استند آپ ها ما این مشکل را داریم - افراد بسیاری از وظایف را به صورت موازی انجام می دهند. گاهی اوقات وظایف به طور ضعیفی به هم مرتبط هستند و هیچ درک درستی از اینکه چه کسی چه کاری را انجام می دهد وجود ندارد. و نظر یکی دیگر از اعضای تیم بسیار مهم است. این اطلاعات اضافی است که می تواند مسیر حل مشکل را تغییر دهد. البته معمولاً یک نفر همراه شماست، اما توصیه و راهنمایی همیشه مفید است.

برای بهبود این وضعیت، از تکنیک "تغییر ایستادن پیشرو" استفاده کردیم. حالا آنها طبق یک لیست مشخص می چرخند و این تأثیر خود را دارد. وقتی نوبت شما می‌شود، مجبور می‌شوید برای برگزاری یک جلسه اسکرام خوب، غوطه‌ور شوید و بفهمید که چه خبر است.

3. نسخه ی نمایشی داخلی. کمک در حل مشکل از برنامه‌نویسی زوجی، تجسم روی درخت مشکل و کمک در جلسات اسکرام در صبح خوب است، اما ایده‌آل نیست. به عنوان یک زوج، شما فقط با دانش خود محدود هستید. درخت وظیفه به درک جهانی کمک می کند که چه کسی چه کاری انجام می دهد. و مجری و همکاران در جلسه صبح عمیقاً در مشکلات شما فرو نخواهند رفت. مطمئناً ممکن است چیزی را از دست بدهند.

راه حل در نشان دادن کارهای انجام شده به یکدیگر و سپس بحث در مورد آن یافت شد. ما هفته‌ای یک‌بار به مدت یک ساعت ملاقات می‌کنیم و جزئیات راه‌حل‌های کارهایی را که در هفته گذشته انجام داده‌ایم نشان می‌دهیم.

در طول نمایش، لازم است جزئیات کار آشکار شود و مطمئن شوید که عملکرد آن را نشان می دهد.

گزارش را می توان با استفاده از چک لیست انجام داد.1. وارد متن شوید. تکلیف از کجا آمد، اصلاً چرا لازم بود؟

2. مشکل قبلا چگونه حل شد؟ به عنوان مثال، کلیک گسترده ماوس مورد نیاز بود، یا اصلاً انجام کاری غیرممکن بود.

3. چگونه آن را بهبود بخشیم. به عنوان مثال: "ببین، اکنون scriptosik وجود دارد، اینجا readme است."

4. نشان دهید که چگونه کار می کند. توصیه می شود به طور مستقیم برخی از سناریوهای کاربر را پیاده سازی کنید. من X را می خواهم، Y را انجام می دهم، Y (یا Z) را می بینم. برای مثال، من NGINX را مستقر می‌کنم، آدرس اینترنتی را دود می‌کنم و 200 اوکی می‌گیرم. اگر اکشن طولانی است، آن را از قبل آماده کنید تا بتوانید بعداً آن را نشان دهید. اگر شکننده است، توصیه می‌شود یک ساعت قبل از دمو آن را بیش از حد نشکنید.

5. توضیح دهید که مشکل با چه موفقیتی حل شد، چه مشکلاتی باقی مانده است، چه چیزی تکمیل نشده است، چه پیشرفت هایی در آینده امکان پذیر است. به عنوان مثال، اکنون CLI، سپس اتوماسیون کامل در CI وجود خواهد داشت.

برای هر سخنران توصیه می شود آن را 5-10 دقیقه نگه دارد. اگر واضح است که سخنرانی شما مهم است و بیشتر طول می کشد، این را از قبل در کانال sre-takeover هماهنگ کنید.

بعد از قسمت حضوری همیشه در تاپیک بحث وجود دارد. اینجاست که بازخوردی که در مورد وظایف خود نیاز داریم ظاهر می شود.

در نتیجه، یک نظرسنجی برای تعیین سودمندی آنچه اتفاق می افتد انجام می شود. این بازخورد در مورد ماهیت سخنرانی و اهمیت کار است.

نتیجه گیری های طولانی و آینده

ممکن است به نظر برسد که لحن مقاله تا حدودی بدبینانه است. این اشتباه است. دو سطح پایین‌تر بازخورد، یعنی تست‌ها و برنامه‌نویسی زوجی، کار می‌کنند. به اندازه توسعه سنتی کامل نیست، اما تأثیر مثبتی از آن وجود دارد.

آزمایش‌ها، در شکل فعلی‌شان، تنها پوشش کد جزئی را ارائه می‌کنند. بسیاری از توابع پیکربندی در نهایت آزمایش نشده اند. تأثیر آنها بر روی کار واقعی هنگام نوشتن کد کم است. با این حال، آزمایش‌های یکپارچه‌سازی اثری دارند و به شما امکان می‌دهند بدون ترس دوباره‌سازی‌ها را انجام دهید. این یک دستاورد بزرگ است. همچنین، با تغییر تمرکز به توسعه در زبان های سطح بالا (ما پایتون، برو)، مشکل برطرف می شود. و برای "چسب" به بررسی های زیادی نیاز ندارید؛ یک بررسی ادغام کلی کافی است.

کار به صورت جفت بیشتر به افراد خاصی بستگی دارد. عامل وظیفه و مهارت های نرم ما وجود دارد. با بعضی از افراد خیلی خوب جواب می دهد، در بعضی دیگر بدتر. این قطعاً مزایایی دارد. واضح است که حتی اگر قواعد کار زوجی به اندازه کافی رعایت نشود، خود انجام کارها با هم تأثیر مثبتی بر کیفیت نتیجه دارد. من شخصاً کار کردن به صورت جفت را آسان تر و لذت بخش تر می دانم.

روش‌های سطح بالاتر برای تأثیرگذاری بر سیستم‌عامل - برنامه‌ریزی و کار با وظایف دقیقاً تأثیراتی را ایجاد می‌کند: تبادل دانش با کیفیت بالا و کیفیت توسعه بهبود یافته.

نتیجه گیری کوتاه در یک خط

• متخصصان منابع انسانی در IaC کار می کنند، اما با کارایی کمتر.
• آنچه را که کار می کند تقویت کنید.
• با مکانیسم ها و شیوه های جبرانی خود بیایید.

منبع: www.habr.com