تأیید صحت محصول، استراتژی‌های انتشار و گردش کار هوش مصنوعی انتها به انتها

سود:

• درک استراتژی های کاهش خطر انتشار (سبز آبی، قناری، پرچم ویژه) و نظم و انضباط تأیید محصول (چک سلامت، تست دود، نظارت بر سیگنال طلایی)
• توانایی اجرای عادت تهیه یک برنامه بازگشت شفاف قبل از استقرار و تأیید مسیرهای تجاری حیاتی پس از استقرار
• توانایی ترکیب تمام بخش‌های آموخته‌شده در طول ماژول در یک گردش کار با پشتیبانی از هوش مصنوعی و اعمال اصل «هوش مصنوعی تولید می‌کند، انسان‌ها تأیید می‌کنند و تضمین می‌کنند» در هر مرحله

کل این ماژول به سمت یک نقطه حرکت کرد: تحویل ایمن کد و زیرساخت به تولید (محیط زنده مورد استفاده توسط مشتریان واقعی). اکنون ما در بحرانی ترین و استرس زاترین حلقه زنجیره هستیم: دریافت تغییر به صورت زنده و تأیید اینکه واقعاً در آنجا کار می کند. یک اشتباه در اینجا انتزاعی نیست - مستقیماً به مشتری، درآمد و شهرت ضربه می زند. به همین دلیل است که تیم های بالغ نه با «امید»، بلکه با استراتژی های انتشار کنترل شده و تأیید سیستماتیک به سمت تولید می روند.

در این بخش نهایی ما دو چیز را با هم ترکیب می‌کنیم: (1) روش‌های آزادسازی که خطر را کاهش می‌دهند (قناری، آبی-سبز، پرچم ویژه) و نظم و انضباط تأیید تولید. (2) چگونه هر قطعه ای که در طول ماژول یاد گرفتیم – CI/CD، IaC، کانتینر، نظارت، حادثه، هزینه، اسکریپت، امنیت – در یک گردش کار سرتاسری با هوش مصنوعی جمع می شود. بیایید نقل قول اولیه را برای آخرین بار تکرار کنیم: هوش مصنوعی در هر مرحله پیش نویس ها را تولید و تسریع می کند. اما این شما هستید که دکمه "I'm take this live" را فشار می دهید و نتیجه را تضمین می کنید.

استراتژی هایی را منتشر کنید که خطر را کاهش می دهد

ایجاد تغییر برای همه کاربران به طور همزمان خطرناک ترین راه است. روش های بالغ:

• استقرار آبی-سبز: دو محیط یکسان حفظ می شود - "آبی" (زنده) و "سبز" (نسخه جدید). نسخه جدید با رنگ سبز آماده و تست می شود، سپس ترافیک به طور ناگهانی به سبز تغییر می کند. اگر مشکلی وجود داشته باشد، ترافیک بلافاصله به آبی باز می گردد. بازگشت سریع بزرگترین مزیت آن است.
• Canary Deployment: نسخه جدید ابتدا برای درصد کمی از کاربران (به عنوان مثال 5٪) منتشر می شود. اگر معیارها خوب هستند، به تدریج به 100٪ افزایش دهید. یک مشکل بر بخش کوچکی از کاربر تأثیر می گذارد، نه کل کاربر.
• پرچم ویژگی: ویژگی جدید کد را وارد می کند اما توسط یک پرچم مسدود می شود. در صورت درخواست برای کاربران خاصی باز می شود. بین استقرار و «رهاسازی» تمایز وجود دارد. اگر مشکلی وجود داشته باشد، پرچم بدون بازگرداندن کد خاموش می شود.

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

راستی‌آزمایی محصول: با پایان استقرار، کار به پایان نمی‌رسد

فقط به این دلیل که یک استقرار "سبز" به نظر می رسد به این معنی نیست که کار می کند. تأیید سیستماتیک:

1. بررسی های بهداشتی: آیا سرویس بالاست، /healthz پاسخ می دهد؟
2. تست دود: آیا چند مسیر حیاتی کاربر (ورود به سیستم، پرداخت، جستجو) واقعا کار می کنند؟ اتوماتیک و سریع.
3. مراقب سیگنال‌های طلایی باشید: میزان خطای پس از استقرار، تأخیر، آیا ترافیک عادی است؟ (چهار سیگنال در واحد 6.)
4. به تدریج گسترش دهید: با افزایش درصد قناری، در هر مرحله به معیارها نگاه کنید.
5. پنجره مشاهده: برای یک دوره زمانی (مثلاً 30 دقیقه) پس از استقرار از نزدیک نظارت کنید. مشکلات موذی بلافاصله قابل مشاهده نیستند.

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

مقایسه استراتژی های انتشار

استراتژی

مزیت اصلی

هزینه/پیچیدگی

مناسب ترین

آبی-سبز

بازگشت فوری

Two environments = 2x resources

اگر بازیابی سریع حیاتی است

قناری

تاثیر را به برش های کوچک محدود می کند

نیاز به مدیریت ترافیک

پایگاه کاربر بزرگ

پرچم ویژه

استقرار را از انتشار جدا می کند

بدهی مدیریت پرچم

باز شدن تدریجی/هدفمند

به روز رسانی در حال چرخش

ساده، منبع پسند

عقبگرد آهسته

خدمات ساده

گردش کار انتها به انتها با هوش مصنوعی

حالا بیایید کل ماژول را در یک جریان واحد ترکیب کنیم. فرض کنید در حال انتشار یک میکروسرویس جدید هستید. هوش مصنوعی در هر مرحله پیش نویس تولید می کند. شما در هر مرحله تأیید می کنید:

1. کد و ظرف (واحد 4): هوش مصنوعی یک Dockerfile بهینه و ایمن تولید می کند. شما عدم محرمانه بودن و اندازه را بررسی می کنید.
2. CI/CD (واحد 2): خط لوله تست-ساخت-استقرار هوش مصنوعی را می نویسد. شما مجوزها را محدود می کنید و مراجع مخفی را بررسی می کنید.
3. زیرساخت (واحد 3): منابع مورد نیاز را با هوش مصنوعی Terraform تعریف می کند. شما خروجی طرح را می خوانید و به دنبال حذف های غیرمنتظره نیستید.
4. ارکستراسیون (واحد 5): هوش مصنوعی مانیفست های Kubernetes را تولید می کند. شما محدودیت منابع، پروب و RBAC را تأیید می کنید.
5. امنیت (واحد 10): خروجی های اسکن هوش مصنوعی را اولویت بندی می کند. شما ابتدا موارد قابل بهره برداری را می گیرید.
6. نظارت (واحد 6): هوش مصنوعی قوانین هشدار و داشبورد را تولید می کند. شما آستانه ها را با داده های گذشته خود آزمایش می کنید.
7. انتشار و اعتبارسنجی (این واحد): طرح آزمایش دود هوش مصنوعی و برنامه بازگشت قناری را شروع می کنید، معیارها را تماشا می کنید، دکمه را فشار می دهید.
8. اگر حادثه رخ دهد (واحد 7): هوش مصنوعی فرضیه و طرح پس از مرگ را ایجاد می کند. شما درس ها را تأیید می کنید و یاد می گیرید.
9. هزینه (واحد 8): هوش مصنوعی اتلاف منابع جدید را نظارت می کند. شما تصمیمات درستی می گیرید.

در هر مرحله، قانون رایج ثابت می ماند: هوش مصنوعی تولید می کند و سرعت می بخشد، انسان تأیید می کند و تضمین می کند. این ماهیت ماژول است.

سه کیف کوچک

مورد 1 - قناری یک فاجعه را به 5٪ محدود کرد. یک تیم نسخه جدید را به 5 درصد از کاربران قناری دادند. داشبوردی که هوش مصنوعی تولید کرد بلافاصله نشان داد که میزان خطا در این بخش به 8 درصد افزایش یافته است. تیم بدون افزایش آن به 100% آن را پس گرفت. این مشکل تنها 5 درصد از کاربران را تحت تأثیر قرار داد و آن هم برای چند دقیقه. اگر یک انفجار بزرگ وجود داشت، همه مشتریان تحت تأثیر قرار می گرفتند.

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

مورد 3 - بازگشت آماده در 90 ثانیه ذخیره می شود. تیمی که سبز-آبی را نصب کرده بود، نسخه جدید را به رنگ سبز درآورد. بعد از 2 دقیقه تاخیر دو برابر شد. آنها با برگشتی که از قبل آماده کرده بودند در 90 ثانیه ترافیک را آبی کردند. آنها متوجه شدند که علت اصلی (یک جستجوی کند در نسخه جدید) تحت فشار نیست، سپس با آرامش. The ready rollback path made the interruption almost invisible.

چهار قالب قابل کپی

1) انتخاب استراتژی انتشار:

من خدمات زیر را ارائه خواهم کرد: [SERVICE/CONTEXT: تعداد کاربران، تحمل خاموشی، زیرساخت]. بین پرچم سبز آبی، قناری و پرچم کدام یک را پیشنهاد می کنید؟ مزایا، هزینه ها و سرعت بازگشت هر کدام را در این زمینه مقایسه کنید. پیشنهاد بدید ولی اعلام کنید که تصمیم نهایی رو می گیرم.

2) لیست تست / تایید دود:

یک پیش‌نویس تست دود و فهرست تأیید برای [SERVICE] که پس از استقرار اجرا خواهم کرد، تهیه کنید: بررسی سلامت، حیاتی‌ترین مسیرهای کاربر، کدام معیارها را باید برای چند دقیقه کنترل کنم؟ فرض کنید که مهم ترین مسیرهای تجاری را علامت گذاری می کنم و آن قسمت را خالی می گذارم.

3) طرح بازگشت:

من از [DEPLOY METHOD] استفاده می کنم. یک طرح بازگشت واضح برای من بنویسید: با کدام دستور/مرحله می توانم به نسخه قدیمی برگردم، چقدر طول می کشد، خطرات خود بازگشت چیست (به عنوان مثال مهاجرت پایگاه داده را نمی توان به عقب برگرداند)، چه چیزی را باید قبل از بازگشت بررسی کنم؟

4) چک لیست انتشار انتها به انتها:

چک لیست آماده سازی سرتاسری را برای عرضه به پروژه جدید [SERVICE] تهیه کنید: امنیت کد/تصویر، خط لوله، طرح زیرساخت، نظارت و هشدار، اسکن امنیتی، استراتژی انتشار، بازگشت مجدد و تأیید. هر مورد را با این سوال بررسی کنید "آیا آماده هستم؟" تبدیلش به سوال

اعلان ضعیف / اعلان قوی

ضعیف: "چگونه این را به پرود تبدیل کنم؟"

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

گوچلو: "من یک سرویس پرداخت با 10 میلیون کاربر ارائه خواهم کرد، تحمل من برای خرابی بسیار کم است. آیا قناری یا سبز آبی را توصیه می کنید، چرا؟ کدام مسیرهای حیاتی را باید بعد از استقرار آزمایش کنم، کدام معیارها را باید برای چند دقیقه نظارت کنم و یک برنامه بازگشت 60 ثانیه ای چگونه باید باشد؟ تصمیم نهایی را خواهم گرفت."

تفاوت: اعلان دوم مقیاس، تحمل و انتظار بازگشت را نشان می دهد. نیاز به استراتژی + تأیید + لغو دارد و تصمیم گیری را به عهده انسان می گذارد.

اشتباهات رایج

• استقرار بدون طرح عقبگرد. اگر راهی برای بازگشت وجود نداشته باشد، هر استقرار یک قمار است.
• استقرار بیگ بنگ. دادن یکباره آن به کل کاربر، ریسک را به حداکثر می رساند.
• با فرض «سبز = کار کردن». سرویسی که چک سلامتی را پشت سر گذاشته است ممکن است در مسیر بحرانی شکسته شود.
• فکر می کنید که مسیرهای تجاری مهمی را به هوش مصنوعی واگذار می کنید. باید روش هایی مانند پرداخت را علامت بزنید.
• عدم نظارت پس از استقرار مشکلات موذیانه در دقیقه اول ظاهر نمی شوند. پنجره مشاهده مورد نیاز است.
• تفکر مهاجرت پایگاه داده برگشت پذیر است. برخی از تغییرات به عقب باز نمی گردند. به طور جداگانه برنامه ریزی می شوند.

به طور خلاصه

رفتن به پرود حیاتی‌ترین حلقه در زنجیره است و نه با «امید»، بلکه با استراتژی‌های کنترل‌شده انجام می‌شود: سبز-آبی بازگشت فوری را فراهم می‌کند، جلوه قناری را به یک تکه کوچک محدود می‌کند و استقرار پرچم ویژگی را از انتشار جدا می‌کند. وقتی استقرار به پایان رسید، کار تمام نمی شود. تأیید سیستماتیک از طریق بررسی سلامت، آزمایش دود و نظارت بر سیگنال طلایی ضروری است. هوش مصنوعی پیش نویس ها را در هر مرحله در کل ماژول تولید و تسریع می کند - از Dockerfile تا Pipeline، از Terraform تا قانون هشدار، از پس از مرگ تا تجزیه و تحلیل هزینه. اما فرد شایسته باقی می ماند که هر مرحله را تأیید می کند، دکمه go live را فشار می دهد و نتیجه را تضمین می کند. این قانون طلایی توسعه دهندگان انتها به انتها با هوش مصنوعی است.

وظیفه کاربردی

یک سرویس (واقعی یا تخیلی) را برای انتشار انتخاب کنید. (1) استراتژی را انتخاب کنید که متناسب با شرایط شما با الگوی "انتخاب استراتژی انتشار" باشد و دلیل آن را بنویسید. (2) یک لیست تأیید ایجاد شده با الگوی "تست دود / لیست تایید" داشته باشید و خودتان حیاتی ترین مسیرهای تجاری را اضافه کنید. (3) یک طرح بازگشت 60 ثانیه ای با الگوی "طرح بازگشت" تهیه کنید و بررسی کنید که آیا مراحل غیرقابل برگشتی در آن وجود دارد یا خیر.

چک لیست

• [ ] من یک استراتژی انتشار (قناری/آبی-سبز/پرچم) را انتخاب کردم که مناسب زمینه من باشد.
• [ ] من یک برنامه بازگشت سریع و واضح قبل از استقرار آماده دارم.
• [ ] من خودم حیاتی ترین مسیرهای تجاری (به عنوان مثال پرداخت) را به تست های دود اضافه کردم.
• [ ] پس از استقرار، سیگنال های طلایی را از طریق یک پنجره مشاهده رصد می کنم.
• [ ] من همچنین مراحل برگشت ناپذیر (مهاجرت پایگاه داده و غیره) را برنامه ریزی کردم.
• [ ] من نقشه هوش مصنوعی را در هر مرحله تأیید کردم. تصمیم گرفتم زنده بروم.

امتحان ماژول

1. کدام یک از موارد زیر بهترین موقعیت یابی DevOps و AI در فضای ابری است؟

• الف) هوش مصنوعی یک ابزار دستیار و پشتیبانی تصمیم است. افراد مسئول تصمیمات حیاتی موثر بر محصول هستند ✔
• ب) هوش مصنوعی می تواند استقرار و چرخش مخفی را بدون تایید انسان نهایی کند
• ج) هوش مصنوعی فقط برای نوشتن مستندات مفید است، ربطی به زیرساخت ندارد
• د) حسابرسی غیر ضروری است زیرا هوش مصنوعی همیشه دستورات قابل اعتمادتری نسبت به مهندس تولید می کند

توضیحات: این یک ابزار دستیار و پشتیبانی تصمیم است که وظایف متن فشرده مانند خط لوله هوش مصنوعی، پیکربندی، اسکریپت و گزارش را تسریع می کند. مسئولیت تصمیمات موثر بر زمان خرابی، پول و امنیت، مانند انتشار تولید، مدیریت مخفی و برنامه نهایی، بر عهده مهندس ذیصلاح است.

2. دقیق ترین عبارت برای رشته تأیید قبل از اجرای دستور DevOps یا پیکربندی تولید شده توسط هوش مصنوعی کدام است؟

• الف) اگر خروجی صاف و مطمئن به نظر برسد، می توان آن را مستقیماً در پرود اجرا کرد
• ب) خروجی فقط در صورتی ایمن است که خطای نحوی وجود نداشته باشد، نیازی به بررسی بیشتر نیست
• ج) خروجی را به منبع وصل کنید، برنامه ریزی/خشک اجرا کنید و آن را با زمینه سیستم خود فیلتر کنید. سپس اعمال کنید ✔
• د) اولین تلاش را مستقیماً در پرود انجام دهید و نتیجه را تماشا کنید سریعترین تأیید است

توضیح: تأیید سه مرحله‌ای ضروری است: اتصال خروجی به منبع (فرمان/پرچم در واقع در اسناد رسمی است)، اجرای آن به صورت خشک (مشاهده آنچه با پلان/--dry-run اتفاق می‌افتد) و عبور آن از فیلتر سیستم (آیا با زمینه معماری و امنیتی آن مطابقت دارد). تسلط به معنای دقت نیست.

3. هنگام سؤال از هوش مصنوعی در مورد خطا یا مشکل استقرار با یک فایل env که حاوی رمز عبور واقعی پایگاه داده است، رویکرد صحیح چیست؟

• الف) اسرار واقعی را با <PLACEHOLDER> پنهان کنید. فقط خطای پنهان شده و زمینه را به اشتراک بگذارید ✔
• ب) چسباندن کل فایل .env همانطور که هست مشکل را سریعتر حل می کند
• ج) از آنجایی که اسرار در حال حاضر پایه 64 هستند، چسباندن آن بی خطر است
• د) قرار دادن رمز عبور امن است زیرا هوش مصنوعی هرگز آن را ذخیره نمی کند

توضیحات: هیچ راز واقعی در اعلان هوش مصنوعی جای‌گذاری نمی‌شود. مقادیری مانند رمزهای عبور و نشانه ها با <PLACEHOLDER> پوشانده می شوند. فقط پیام خطا و زمینه لازم به اشتراک گذاشته می شود. اگر Secret قبلاً فاش شده باشد، باید فوراً لغو و چرخش شود.

4. مدیریت صحیح اسرار (رمز عبور، رمز) در خط لوله CI/CD کدام یک از موارد زیر است؟

• الف) در مخزن مخفی پلتفرم نگهداری می شود و با مرجع فراخوانی می شود (مثلاً ${{ secrets.X }})، به صورت متن ساده نوشته نمی شود ✔
• ب) برای راحتی در خط لوله YAML به صورت متن ساده نوشته شده است
• ج) با فشردن echo و log در ابتدای هر کار تایید می شود.
• د) در صورت تعریف با گسترده ترین مجوز (write-all)، امنیت افزایش می یابد

توضیح: اسرار به YAML به صورت متن ساده نوشته نمی شوند. در مخزن مخفی پلتفرم نگهداری می شود و با مراجعی مانند ${{ secrets.X }} فراخوانی می شود. علاوه بر این، با اصل حداقل مجوز، مجوزهای رمز محدود شده و گزارش مخفی ثبت نمی شود.

5. در مدیریت زیرساخت با Terraform، مهم ترین گامی که باید قبل از اجرای زنده تغییر انجام داد چیست؟

• الف) اجرای مستقیم «terraform application»؛ این طرح اتلاف وقت است
• ب) پشتیبان گیری از فایل State در یک مخزن عمومی
• ج) 'terraform plan' را اجرا کنید و خطوط تخریب/جایگزینی را در خروجی بررسی کنید، سپس اعمال کنید ✔
• د) نسخه Provider را حذف نصب کنید و مطمئن شوید که جدیدترین نسخه به صورت خودکار ارائه می شود

توضیح: "طرح terraform" باید قبل از "terraform application" اجرا شود. این طرح نشان می دهد که بدون انجام کاری، چه چیزی را باید اضافه کرد، چه چیزی را تغییر داد، و به خصوص چه چیزی را حذف کرد (نابود کرد). اگر خط تخریب یا جایگزینی غیرمنتظره مشاهده شد، App نباید اعمال شود.

6. اگر خط '-/+ جایگزین' برای پایگاه داده تولید در خروجی طرح Terraform ظاهر شود به چه معناست و چه باید کرد؟

• الف) منبع فقط در محل به روز می شود، هیچ خطری وجود ندارد
• ب) منبع حذف و دوباره ایجاد می شود. خطر از دست دادن داده ها وجود دارد، در صورت عدم انتظار، اعمال باید متوقف شود ✔
• ج) افزودن یک منبع جدید، پایگاه داده موجود تحت تأثیر قرار نمی گیرد
• د) این فقط یک هشدار است، می توان با خیال راحت نادیده گرفت

توضیح: '-/+ جایگزین' به این معنی است که منبع حذف و دوباره ایجاد می شود. برای پایگاه داده، این به معنای از دست دادن داده است. اگر انتظار نمی رود، اعمال باید متوقف شود، تغییر باید به روش ایمن تبدیل شود، یا فیلد تغییرناپذیر باید دست نخورده باقی بماند.

7. کدام یک از موارد زیر برای آماده بودن Dockerfile از نظر امنیت و اندازه صحیح است؟

• الف) برای راحتی، رمز را در تصویر با ENV جاسازی کنید و آن را به عنوان روت اجرا کنید
• ب) همیشه از تگ ':latest' استفاده کنید و تصویر پایه را تا حد امکان بزرگ نگه دارید
• ج) ساخت تک مرحله ای و گذاشتن تمامی ابزارهای ساخت در تصویر نهایی
• د) عدم تعبیه Secret، کار با USER غیرمجاز، استفاده از تصویر پایه کوچک و پایدار و ساخت چند مرحله ای✔

توضیحات: یک تصویر آماده تولید: راز را جاسازی نمی کند (آن را در زمان اجرا تزریق می کند)، به جای root با یک USER غیرمجاز اجرا می شود، از یک تصویر پایه کوچک و نسخه شده (باریک/آلپاین، نه : آخرین) استفاده می کند و با ساخت چند مرحله ای کوچک می شود. همچنین قبل از انتشار از نظر آسیب پذیری اسکن می شود.

8. مهمترین خطر عدم تعریف محدودیت منابع برای استقرار در Kubernetes چیست؟

• الف) پاد هرگز شروع نمی شود زیرا محدودیت یک فیلد ضروری است
• ب) فقط یک اخطار روی برد مانیتورینگ ظاهر می شود، عملکرد تحت تأثیر قرار نمی گیرد
• ج) Kubernetes به طور خودکار محدودیت های پیش فرض ایمن را اعمال می کند، بدون خطر
• د) غلاف می تواند به طور نامحدود رشد کند و منابع گره را مصرف کند، در نتیجه سرویس های همسایه را خراب می کند.

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

9. چگونه از "خستگی هشدار" در نظارت و تنظیم زنگ جلوگیری کنیم؟

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

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

10. بهترین ترتیب اولویت در طول یک حادثه تولید چیست؟

• الف) ابتدا علت اصلی را پیدا کنید و تنها زمانی که علت مشخص شد آن را کاهش دهید.
• ب) ابتدا گزارش پس از مرگ را بنویسید سپس سرویس را لمس کنید
• ج) ابتدا کاهش دهید (سرویس بازیابی/بازیابی) و تجزیه و تحلیل علت اصلی را برای بعد بگذارید ✔
• د) ابتدا مسئول حادثه را بیابید و گزارش دهید

توضیح: قانون طلایی «اول کم کن بعد تحقیق کن». هدف این است که ابتدا سرویس را بازیابی کنید یا آن را به یک نسخه شناخته شده خوب برگردانید (تقلیل). تجزیه و تحلیل علت ریشه ای پس از کاهش فشار با آرامش انجام می شود. انتظار برای یافتن علت ریشه ای دقیق زمان بهبودی (MTTR) را افزایش می دهد.

11. هدف اصلی فرهنگ پس از مرگ بی تقصیر چیست؟

• الف) شناسایی شخص مرتکب خطا و سپردن مسئولیت به عهده او
• ب) تمرکز بر سیستم ها و فرآیندها و تشویق به یادگیری. ✔ آموختن درس هایی که مانع از تکرار می شود به جای سرزنش
• ج) هرگز حادثه را گزارش ندهید و از فراموشی آن اطمینان حاصل کنید
• د) فقط نوشتن جزئیات فنی و عدم افزودن موارد قابل اجرا

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

12. در بهینه‌سازی هزینه‌های ابری (FinOps)، منطقی‌ترین قدم قبل از حرکت به سمت تخفیف‌های متعهد (طرح رزرو شده/پس‌انداز) چیست؟

• الف) ابتدا طولانی ترین تعهد ممکن را انجام دهید، بعداً به اتلاف فکر کنید
• ب) ابتدا زباله ها را تمیز کنید (بسته شدن در حالت بیکار، اندازه مناسب)، سپس متعهد به استفاده متعهد شوید ✔
• ج) بلافاصله تمام منابع را به ظرفیت Spot منتقل کنید
• د) حذف گرانترین کالا بدون بررسی اطلاعات فاکتور

توضیح: ابتدا زباله ها باید پاکسازی شوند (بستن منابع بیکار، کاهش منابع بزرگ). در غیر این صورت، مصرف اتلاف شده را با قیمت تخفیفی برای 1-3 سال قفل خواهید کرد. تمیز کردن با اندازه مناسب و بدون کار نیازی به تعهد ندارد و تقریباً بدون خطر است.

13. اگر اسکریپت پیشنهادی هوش مصنوعی دارای خط 'rm -rf "$DIR"/' باشد، مهمترین اقدام امنیتی چیست؟

• الف) اجرای اسکریپت به طور مستقیم در پرود بدون خواندن آن سرعت بیشتری خواهد داشت
• ب) set -euo pipefail و کنترل متغیر خالی را اضافه کنید و ابتدا با اجرای خشک امتحان کنید ✔
• ج) کوتاه کردن نام متغیر کافی است
• د) استفاده از rm -rf --force به جای rm مشکل را حل می کند

توضیح: اگر $DIR خالی باشد، این عبارت ممکن است سعی کند دایرکتوری ریشه را حذف کند. توقف روی متغیر تعریف نشده با 'set -u' و بررسی خالی نبودن متغیر قبل از حذف آن (به عنوان مثال [ -n "$DIR" ] || خروج 1) از فاجعه جلوگیری می کند. بعلاوه، ابتدا باید عملیات مخرب را با حالت خشک امتحان کرد.

14. اگر یک کلید دسترسی ابری به طور تصادفی به یک مخزن عمومی نشت کند، اولین کاری که باید انجام دهید چیست؟

• الف) بلافاصله کلید را لغو و تجدید (چرخش) کنید. ✔ حذف به تنهایی کافی نیست
• ب) فقط فایل را از حافظه حذف کنید و کلید امن است
• ج) انجام ندادن کاری چون کسی آن را ندیده است
• د) خصوصی کردن ذخیره سازی نیاز به چرخاندن کلید را از بین می برد

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

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

• الف) دادن نسخه جدید به همه کاربران به طور همزمان (بیگ بنگ) و عدم تهیه برنامه بازگشت
• ب) با در نظر گرفتن پایان یافتن استقرار به محض ظاهر شدن "سبز"، عدم انجام تاییدیه اضافی
• ج) استفاده از یک استراتژی کنترل شده مانند پرچم قناری/آبی-سبز/پرچم ویژه، طرح بازگشت آماده و تست دود + نظارت متریک پس از استقرار ✔
• د) آزمایش مسیرهای حیاتی کسب و کار را به طور کامل به هوش مصنوعی بسپارید و اصلاً آن ها را تعیین نکنید.

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