التحقق من المنتج، واستراتيجيات الإصدار، وسير عمل الذكاء الاصطناعي الشامل

المكاسب:

• فهم إستراتيجيات الإصدار للحد من المخاطر (الأزرق والأخضر، والكناري، وعلم الميزة) ونظام التحقق من المنتج (الفحص الصحي، واختبار الدخان، ومراقبة الإشارة الذهبية)
• القدرة على تنفيذ عادة إعداد خطة تراجع واضحة قبل النشر والتحقق من مسارات العمل المهمة بعد النشر
• القدرة على الجمع بين جميع الأجزاء التي تم تعلمها خلال الوحدة في سير عمل شامل مدعوم بالذكاء الاصطناعي وتطبيق مبدأ "الذكاء الاصطناعي ينتج، والبشر يتحققون ويضمنون" في كل خطوة

تدفقت هذه الوحدة بأكملها نحو نقطة واحدة: التسليم الآمن للتعليمات البرمجية والبنية التحتية للإنتاج (البيئة الحية التي يستخدمها العملاء الحقيقيون). نحن الآن عند الحلقة الأكثر أهمية وإرهاقًا في السلسلة: الحصول على التغيير مباشرة والتحقق من أنه يعمل بالفعل هناك. الخطأ هنا ليس مجردًا، فهو يؤثر بشكل مباشر على العميل والإيرادات والسمعة. وهذا هو السبب وراء توجه الفرق الناضجة إلى الإنتاج ليس عن طريق "الأمل" ولكن من خلال إستراتيجيات الإصدار الخاضعة للرقابة والتحقق المنهجي.

في هذه الوحدة النهائية، نجمع بين أمرين: (1) طرق الإصدار التي تقلل المخاطر (الكناري، الأزرق والأخضر، علامة الميزة) ونظام التحقق من المنتج؛ (2) كيف يتم تجميع كل جزء تعلمناه خلال الوحدة - CI/CD، وIaC، والحاوية، والمراقبة، والحادث، والتكلفة، والنص البرمجي، والأمان - معًا في سير عمل واحد شامل مدعوم بالذكاء الاصطناعي. دعونا نكرر الاقتباس الأولي للمرة الأخيرة: يقوم الذكاء الاصطناعي بإنشاء المسودات وتسريعها في كل خطوة؛ لكنك أنت من يضغط على زر "سأقوم ببث هذا البث المباشر" ويضمن النتيجة.

إطلاق الاستراتيجيات التي تقلل المخاطر

إن دفع التغيير إلى جميع المستخدمين في نفس الوقت هو الطريقة الأكثر خطورة. الأساليب الناضجة:

• النشر الأزرق والأخضر: يتم الحفاظ على بيئتين متطابقتين - "الأزرق" (مباشر) و"الأخضر" (الإصدار الجديد). يتم إعداد الإصدار الجديد واختباره باللون الأخضر، ثم يتم تحويل حركة المرور فجأة إلى اللون الأخضر. إذا كانت هناك مشكلة، تعود حركة المرور على الفور إلى اللون الأزرق. التراجع السريع هو أكبر ميزة لها.
• نشر Canary: يتم إصدار الإصدار الجديد لأول مرة لنسبة صغيرة من المستخدمين (على سبيل المثال 5%)؛ إذا كانت المقاييس جيدة، قم بزيادة النسبة تدريجيًا إلى 100%. تؤثر المشكلة على شريحة صغيرة من المستخدم، وليس المستخدم بأكمله.
• علامة الميزة: تقوم الميزة الجديدة بإدخال الرمز ولكن يتم حظرها بواسطة علامة؛ يتم فتحه لبعض المستخدمين عند الطلب. هناك فرق بين النشر و"الإصدار"؛ إذا كانت هناك مشكلة، فسيتم إيقاف تشغيل العلامة دون التراجع عن الرمز.

نصيحة: أسرع شبكة أمان هي أن تكون لديك إمكانية التراجع قبل كل عملية نشر. "إذا حدث خطأ ما، كيف يمكنني العودة إلى الإصدار القديم خلال 60 ثانية؟" إذا لم تكن هناك إجابة واضحة على السؤال، فأنت لست مستعدًا للقيام بهذا النشر.

التحقق من المنتج: لا ينتهي العمل عند انتهاء النشر

فقط لأن عملية النشر تبدو "أخضر" لا يعني أنها تعمل. التحقق المنهجي:

1. الفحوصات الصحية: هل الخدمة مفعلة، هل يستجيب /healthz؟
2. اختبارات الدخان: هل تعمل مسارات المستخدم القليلة الأكثر أهمية (تسجيل الدخول، الدفع، البحث) بالفعل؟ تلقائي وسريع.
3. انتبه للإشارات الذهبية: معدل الخطأ بعد النشر، وزمن الوصول، وهل حركة المرور طبيعية؟ (أربع إشارات على الوحدة 6.)
4. التوسيع تدريجيًا: انظر إلى المقاييس في كل خطوة أثناء زيادة النسبة المئوية لـ Canary.
5. نافذة المراقبة: المراقبة عن كثب لفترة من الوقت (على سبيل المثال 30 دقيقة) بعد النشر؛ المشاكل الخبيثة ليست مرئية على الفور.

تحذير: قد ينتج الذكاء الاصطناعي قائمة باختبارات الدخان أو عمليات التحقق، ولكن من واجبك تحديد مسارات المستخدم "الحرجة". يقدم الذكاء الاصطناعي قائمة عامة؛ أنت فقط تعلم أن تدفق الدفع الخاص بك، وهو المسار الأكثر إدرارًا للدخل، يجب أن يتم اختباره.

مقارنة استراتيجيات الإصدار

استراتيجية

الميزة الرئيسية

التكلفة/التعقيد

الأكثر ملاءمة

الأزرق والأخضر

التراجع الفوري

بيئتان = موارد 2x

إذا كان الاسترجاع السريع أمر بالغ الأهمية

كناري

يحد من التأثير على شريحة صغيرة

مطلوب إدارة حركة المرور

قاعدة مستخدمين ضخمة

علامة الميزة

يفصل النشر عن الإصدار

علم إدارة الديون

افتتاح تدريجي / مستهدف

التحديث المتداول

بسيطة وصديقة للموارد

التراجع البطيء

خدمات بسيطة

سير عمل متكامل مدعوم بالذكاء الاصطناعي

الآن دعونا ندمج الوحدة بأكملها في تدفق واحد. لنفترض أنك تنشر خدمة صغيرة جديدة. يُنتج الذكاء الاصطناعي مسودات في كل خطوة؛ تقوم بالتحقق في كل خطوة:

1. الكود والحاوية (الوحدة 4): يقوم الذكاء الاصطناعي بإنتاج ملف Dockerfile محسّن وآمن؛ يمكنك التحقق من عدم السر والحجم.
2. CI/CD (الوحدة 2): كتابة خط أنابيب اختبار وبناء ونشر الذكاء الاصطناعي؛ يمكنك تضييق نطاق الأذونات والتحقق من المراجع السرية.
3. البنية التحتية (الوحدة 3): تحديد الموارد المطلوبة باستخدام AI Terraform؛ تقرأ مخرجات الخطة ولا تبحث عن عمليات الحذف غير المتوقعة.
4. التنسيق (الوحدة 5): يقوم الذكاء الاصطناعي بإنتاج بيانات Kubernetes؛ عليك التحقق من حد الموارد، والتحقيق، وRBAC.
5. الأمان (الوحدة 10): يعطي الأولوية لمخرجات مسح الذكاء الاصطناعي؛ عليك انتزاع تلك القابلة للاستغلال أولا.
6. المراقبة (الوحدة 6): يقوم الذكاء الاصطناعي بإنشاء قواعد الإنذار ولوحة المعلومات؛ يمكنك اختبار الحدود باستخدام بياناتك السابقة.
7. الإصدار والتحقق من الصحة (هذه الوحدة): الخطوط العريضة لاختبار الدخان AI وخطة التراجع؛ تبدأ تشغيل الكناري، وتشاهد المقاييس، وتضغط على الزر.
8. في حالة وقوع حادث (الوحدة 7): يقوم الذكاء الاصطناعي بإنشاء فرضية ورسم تخطيطي لما بعد الوفاة؛ يمكنك التحقق وتعلم الدروس.
9. التكلفة (الوحدة 8): يراقب الذكاء الاصطناعي هدر الموارد الجديدة؛ أنت تتخذ قرارات الحجم الصحيح.

وفي كل خطوة، تظل القاعدة المشتركة ثابتة: الذكاء الاصطناعي ينتج ويسرع، والإنسان يتحقق ويضمن. هذا هو جوهر الوحدة.

ثلاث حالات صغيرة

الحالة 1 - حصر الكناري الكارثة في 5%. أعطى الفريق الإصدار الجديد لـ 5٪ من مستخدمي الكناري. وأظهرت لوحة المعلومات التي أنتجها الذكاء الاصطناعي على الفور أن معدل الخطأ قفز إلى 8% في هذه الشريحة. واستعادها الفريق دون زيادتها إلى 100%؛ أثرت المشكلة على 5% فقط من المستخدمين، وكان ذلك لبضع دقائق. إذا كان هناك انتشار كبير، فسوف يتأثر جميع العملاء.

الحالة 2 - اكتشف اختبار الدخان المسار المفقود. عرض الذكاء الاصطناعي مجموعة اختبار الدخان، لكنه لم يكن لديه تدفق "للدفع". وأضاف المهندس ذلك، مع العلم أن مصدر الإيرادات الأكثر أهمية هو الدفع. تم إجراء اختبار ما بعد النشر مباشرة عند خطوة الخروج - انتهت صلاحية مفتاح الطرف الثالث. اكتشف التحقق خسارة صامتة للإيرادات في غضون دقائق.

الحالة 3 - تم حفظ التراجع الجاهز في 90 ثانية. قام الفريق الذي قام بتثبيت اللون الأزرق والأخضر بتحويل الإصدار الجديد إلى اللون الأخضر؛ بعد دقيقتين تضاعف التأخير. لقد حولوا حركة المرور إلى اللون الأزرق في 90 ثانية مع التراجع الذي أعدوه مسبقًا. لقد وجدوا أن السبب الجذري (استعلام بطيء في الإصدار الجديد) لم يكن تحت الضغط، بل بهدوء. مسار التراجع الجاهز جعل الانقطاع غير مرئي تقريبًا.

أربعة قوالب قابلة للنسخ

1) اختيار استراتيجية الإصدار:

سأقوم بتقديم الخدمة التالية: [الخدمة/السياق: عدد المستخدمين، تحمل الانقطاع، البنية التحتية]. أيهما تنصح به بين الأعلام الزرقاء والخضراء والكناري والأعلام المميزة؟ قارن المزايا والتكاليف وسرعة التراجع لكل منها في هذا السياق. قدم اقتراحًا، لكن اذكر أنني سأتخذ القرار النهائي.

2) اختبار الدخان / قائمة التحقق:

قم بإعداد مسودة اختبار الدخان وقائمة التحقق لـ [الخدمة] التي سأقوم بتشغيلها بعد النشر: الفحص الصحي، ومسارات المستخدم الأكثر أهمية، وما هي المقاييس التي يجب أن أراقبها لمدة كم دقيقة؟ افترض أنني سأضع علامة على مسارات العمل الأكثر أهمية وأترك ​​هذا الحقل فارغًا.

3) خطة التراجع:

أستخدم [طريقة النشر]. اكتب لي خطة واضحة للتراجع: ما هو الأمر/الخطوة التي يمكنني من خلالها الرجوع إلى الإصدار القديم، وكم من الوقت يستغرق ذلك، وما هي مخاطر التراجع نفسه (على سبيل المثال، لا يمكن التراجع عن ترحيل قاعدة البيانات)، وما الذي يجب علي التحقق منه قبل التراجع؟

4) قائمة مراجعة الإصدار الشامل:

قم بإعداد قائمة مرجعية شاملة للإعداد للإصدار إلى مشروع [خدمة] جديد: أمان الكود/الصورة، وخط الأنابيب، وخطة البنية التحتية، والمراقبة والإنذار، والفحص الأمني، واستراتيجية الإصدار، والتراجع والتحقق. حدد كل عنصر بالسؤال "هل أنا مستعد؟" تحويله إلى سؤال.

موجه ضعيف / موجه قوي

ضعيف: "كيف يمكنني إدخال هذا في المنتج؟"

النتيجة: لا يوجد سياق؛ يسرد الذكاء الاصطناعي خطوات النشر العامة، لكنه لا يتناول قدرتك على تحمل المخاطر ونطاق المستخدم واحتياجات التراجع.

غوتشلو: "سأقوم بتقديم خدمة دفع تضم 10 ملايين مستخدم، وتحملي لوقت التوقف عن العمل منخفض جدًا. هل توصي باستخدام Canary أو Blue-Green، لماذا؟ ما هي المسارات الحرجة التي يجب أن أختبرها بعد النشر، وما هي المقاييس التي يجب أن أراقبها لعدد الدقائق، وكيف يجب أن تكون خطة التراجع لمدة 60 ثانية؟ سأتخذ القرار النهائي."

الفرق: الموجه الثاني يعطي المقياس والتسامح وتوقع التراجع؛ فهو يتطلب استراتيجية + التحقق + التراجع ويترك القرار للإنسان.

الأخطاء الشائعة

• النشر بدون خطة التراجع. إذا لم يكن هناك طريق للرجوع، فكل عملية نشر هي مقامرة.
• انتشار الانفجار الكبير. إن إعطائها للمستخدم بأكمله مرة واحدة يزيد من المخاطر.
• بافتراض أن "الأخضر = العمل". قد تكون الخدمة التي اجتازت التحقق من السلامة معطلة على المسار الحرج.
• معتقدًا أنك تترك مسارات عمل مهمة للذكاء الاصطناعي. يجب عليك وضع علامة على طرق مثل الدفع.
• عدم المراقبة بعد النشر. المشاكل الخبيثة لا تظهر في الدقيقة الأولى؛ مطلوب نافذة المراقبة.
• التفكير في ترحيل قاعدة البيانات يمكن عكسه. لا يتم التراجع عن بعض التغييرات؛ يتم التخطيط لها بشكل منفصل.

في ملخص

يعد الانتقال إلى الإنتاج هو الرابط الأكثر أهمية في السلسلة ولا يتم ذلك عن طريق "الأمل" ولكن من خلال استراتيجيات خاضعة للرقابة: يوفر اللون الأزرق والأخضر تراجعًا فوريًا، مما يحد من تأثير الكناري على شريحة صغيرة، ويفصل نشر علامة الميزة عن الإصدار. لم ينته العمل عند انتهاء النشر؛ يعد التحقق المنهجي من خلال الفحوصات الصحية واختبارات الدخان ومراقبة الإشارة الذهبية أمرًا ضروريًا. يقوم الذكاء الاصطناعي بإنشاء المسودات وتسريعها في كل خطوة خلال الوحدة بأكملها - بدءًا من Dockerfile وحتى خط الأنابيب، ومن Terraform إلى قاعدة الإنذار، ومن التحليل بعد الوفاة إلى تحليل التكلفة. ولكن يبقى الشخص المختص هو الذي يتحقق من كل خطوة، ويضغط على زر البث المباشر ويضمن النتيجة. هذه هي القاعدة الذهبية لـ DevOps المدعومة بالذكاء الاصطناعي من البداية إلى النهاية.

مهمة التطبيق

اختر خدمة (حقيقية أو خيالية) للنشر عليها. (1) اختر إستراتيجية تناسب سياقك باستخدام قالب "إصدار اختيار الإستراتيجية" واكتب السبب. (2) قم بإنشاء قائمة تحقق باستخدام قالب "اختبار الدخان/قائمة التحقق" وأضف مسارات العمل الأكثر أهمية بنفسك. (3) قم بإعداد خطة تراجع مدتها 60 ثانية باستخدام قالب "خطة التراجع" وتحقق مما إذا كانت هناك أية خطوات لا رجعة فيها.

قائمة مرجعية

• [ ] لقد اخترت استراتيجية الإصدار (الكناري/الأزرق والأخضر/العلم) التي تناسب السياق الخاص بي.
• [ ] لدي خطة تراجع واضحة وسريعة وجاهزة قبل النشر.
• [ ] لقد أضفت مسارات العمل الأكثر أهمية (مثل الدفع) إلى اختبارات Smoke الخاصة بي بنفسي.
• [ ] بعد النشر، أقوم بمراقبة الإشارات الذهبية من خلال نافذة المراقبة.
• [ ] لقد خططت أيضًا لخطوات لا رجعة فيها (ترحيل قاعدة البيانات، وما إلى ذلك).
• [ ] لقد قمت بالتحقق من مخطط الذكاء الاصطناعي في كل خطوة؛ لقد اتخذت قرارًا بالذهاب للعيش.

امتحان الوحدة

1. أي مما يلي هو أفضل وضع لـ DevOps وAI في السحابة؟

• أ) الذكاء الاصطناعي هو أداة مساعدة ودعم القرار؛ الأشخاص مسؤولون عن القرارات الحاسمة التي تؤثر على المنتج ✔
• ب) يمكن للذكاء الاصطناعي إنهاء عمليات نشر المنتجات والتناوب السري دون موافقة الإنسان
• ج) الذكاء الاصطناعي مفيد فقط لكتابة الوثائق، ولا علاقة له بالبنية التحتية
• د) التدقيق غير ضروري لأن الذكاء الاصطناعي ينتج دائمًا أوامر أكثر موثوقية من المهندس

الوصف: إنها أداة مساعدة ودعم اتخاذ القرار تعمل على تسريع المهام التي تتطلب نصوصًا مكثفة مثل خطوط أنابيب الذكاء الاصطناعي والتكوين والبرنامج النصي والسجل. وتظل مسؤولية القرارات التي تؤثر على التوقف والمال والأمن، مثل إصدار الإنتاج والإدارة السرية والتطبيق النهائي، على عاتق المهندس المختص.

2. ما هو التعبير الأكثر دقة لمجال التحقق قبل تنفيذ أمر DevOps أو التكوين الذي ينتجه الذكاء الاصطناعي؟

• أ) إذا كان الإخراج يبدو سلسًا وواثقًا، فيمكن تشغيله مباشرة في النخز
• ب) يكون الإخراج آمنًا فقط في حالة عدم وجود أخطاء في بناء الجملة، ولا يلزم إجراء المزيد من عمليات التحقق
• ج) قم بتوصيل الإخراج بالمصدر، والتخطيط/التشغيل الجاف، وتصفيته مع سياق النظام الخاص بك؛ ثم قم بالتطبيق ✔
• د) إن إجراء المحاولة الأولى مباشرة في المنتج ومشاهدة النتيجة هو أسرع عملية تحقق

Explanation: التحقق من ثلاث خطوات ضروري: توصيل المخرجات بالمصدر (هو الأمر/العلامة الموجودة بالفعل في المستندات الرسمية)، وتشغيلها جافة (رؤية ما يحدث مع الخطة/--التشغيل الجاف)، وتمريرها عبر مرشح النظام (هل تتناسب مع سياقها المعماري والأمني). الطلاقة لا تعني الدقة.

3. ما هو النهج الصحيح عند سؤال الذكاء الاصطناعي عن خطأ أو مشكلة نشر لملف .env الذي يحتوي على كلمة مرور حقيقية لقاعدة البيانات؟

• أ) إخفاء الأسرار الحقيقية باستخدام <PLACEHOLDER>؛ مشاركة الخطأ والسياق المقنع فقط ✔
• ب) يؤدي لصق ملف .env بأكمله كما هو إلى حل المشكلة بشكل أسرع
• ج) بما أن الأسرار موجودة بالفعل في قاعدة 64، فمن الآمن لصقها بشكل عادي
• د) لصق كلمة المرور آمن لأن الذكاء الاصطناعي لا يخزنها أبدًا

الوصف: لا يتم لصق أي أسرار حقيقية في موجه الذكاء الاصطناعي. يتم إخفاء القيم مثل كلمات المرور والرموز المميزة بـ <PLACEHOLDER>؛ تتم مشاركة رسالة الخطأ والسياق الضروري فقط. إذا تم تسريب السر بالفعل، فيجب إلغاؤه وتدويره على الفور.

4. أي مما يلي يمثل الإدارة الصحيحة للأسرار (كلمة المرور، الرمز المميز) في مسار CI/CD؟

• أ) يتم الاحتفاظ بها في المستودع السري للمنصة ويتم استدعاؤها حسب المرجع (على سبيل المثال ${{ Secrets.X }})، وليست مكتوبة بنص عادي ✔
• ب) مكتوب بنص عادي لخط الأنابيب YAML للراحة
• ج) يتم التحقق من ذلك بالضغط على echo وlog في بداية كل مهمة.
• د) إذا تم تحديدها بأقصى إذن (كتابة الكل)، يزداد الأمان

توضيح: لا تتم كتابة الأسرار إلى YAML بنص عادي؛ يتم الاحتفاظ به في المستودع السري للنظام الأساسي ويتم استدعاؤه بمراجع مثل ${{ Secrets.X }}. بالإضافة إلى ذلك، مع مبدأ السلطة الأقل، يتم تضييق أذونات الرمز المميز ولا يتم تسجيل السجل السري.

5. في إدارة البنية التحتية باستخدام Terraform، ما هي الخطوة الأكثر أهمية التي يجب اتخاذها قبل تنفيذ التغيير المباشر؟

• أ) تشغيل "تطبيق Terraform" مباشرةً؛ الخطة مضيعة للوقت
• ب) النسخ الاحتياطي لملف الحالة إلى مستودع عام
• ج) قم بتشغيل "خطة Terraform" وتحقق من خطوط التدمير/الاستبدال في المخرجات، ثم قم بتطبيق ✔
• د) قم بإلغاء تثبيت إصدار الموفر وتأكد من وصول الإصدار الأحدث تلقائيًا

توضيح: يجب تشغيل "خطة Terraform" قبل "تطبيق Terraform". توضح الخطة ما يجب إضافته، وما يجب تغييره، وخاصة ما يجب حذفه (تدميره)، دون القيام بأي شيء. إذا تم رؤية خط إتلاف أو استبدال غير متوقع، فيجب عدم تطبيق تطبيق.

6. ماذا يعني وماذا يجب فعله إذا ظهر السطر "-/+ استبدال" لقاعدة بيانات الإنتاج في مخرجات خطة Terraform؟

• أ) سيتم تحديث المصدر في الموقع فقط، ولا توجد أي مخاطر
• ب) سيتم حذف المورد وإعادة إنشائه؛ هناك خطر فقدان البيانات، يجب إيقاف التطبيق إذا لم يكن متوقعًا ✔
• ج) إضافة مورد جديد، لا تتأثر قاعدة البيانات الموجودة
• د) هذا مجرد تحذير، ويمكن تجاهله بأمان

توضيح: '-/+ استبدال' يعني أنه سيتم حذف المورد وإعادة إنشائه؛ بالنسبة لقاعدة البيانات، هذا يعني فقدان البيانات. إذا لم يكن ذلك متوقعًا، فيجب إيقاف التطبيق، ويجب تحويل التغيير إلى طريقة آمنة، أو يجب ترك الحقل غير القابل للتغيير دون تغيير.

7. أي مما يلي ينطبق على ملف Dockerfile ليكون جاهزًا للإنتاج من حيث الأمان والحجم؟

• أ) للراحة، قم بتضمين السر في الصورة باستخدام ENV وتشغيله كجذر
• ب) استخدم دائمًا علامة ":latest" واحتفظ بالصورة الأساسية بأكبر حجم ممكن
• ج) البناء بمرحلة واحدة وترك جميع أدوات البناء في الصورة النهائية
• د) عدم تضمين السر، والعمل مع مستخدم غير مصرح به، واستخدام صورة أساسية صغيرة وثابتة وبناء متعدد المراحل ✔

الوصف: صورة جاهزة للإنتاج: لا تتضمن السر (تقوم بإدخاله في وقت التشغيل)، وتعمل مع مستخدم غير مصرح به بدلاً من الجذر، وتستخدم صورة أساسية صغيرة ونسخة (رفيعة/جبال الألب، وليست الأحدث)، ويتم تصغيرها باستخدام بناء متعدد المراحل. ويتم فحصه أيضًا بحثًا عن نقاط الضعف قبل النشر.

8. ما هو الخطر الأكثر أهمية لعدم تحديد حدود الموارد للنشر في Kubernetes؟

• أ) لا يبدأ الكبسولة أبدًا لأن الحد حقل مطلوب
• ب) يظهر تحذير فقط على لوحة المراقبة، ولا يتأثر التشغيل
• ج) يفرض Kubernetes تلقائيًا حدودًا افتراضية آمنة، دون أي مخاطر
• د) يمكن أن تنمو الكبسولة بشكل غير محدود وتستهلك موارد العقدة، وبالتالي تعطل الخدمات المجاورة ✔

Explanation: يمكن أن تنمو الكبسولة التي ليس لها حد للموارد بشكل غير محدود، وتستهلك جميع موارد العقدة التي تعمل عليها، وتتعطل الخدمات المجاورة، على سبيل المثال، مع تسرب الذاكرة. ولهذا السبب فإن تحديد الطلبات/الحدود هو أساس المتانة.

9. كيف يمكن تجنب "إجهاد التنبيه" أثناء المراقبة وإعداد الإنذار؟

• أ) قم بضبط التنبيهات على أكبر عدد ممكن من المقاييس وقم بإنشاء تنبيهات مع كل تقلب.
• ب) ضبط جميع الإنذارات على أعلى مستوى خطورة
• ج) إطلاق الإنذارات بقيم لحظية دون تحديد وقت (ل)
• د) إبقاء الإنذارات موجهة نحو العمل وبالضرورة المناسبة، واختبار الحدود مع البيانات التاريخية، ودمج البيانات غير الضرورية ✔

الوصف: يجب أن يكون كل إنذار قابلاً للتنفيذ وذو أهمية ملحة؛ يتم عرض المعلومات التي لا تتطلب اتخاذ إجراء على السبورة، ولا توقظ أي شخص. يتم اختبار حدود الإنذار مقابل البيانات التاريخية للنظام ويتم دمج الإنذارات غير الضرورية/المتكررة. بهذه الطريقة لن يضيع المنبه الحقيقي وسط الضوضاء.

10. ما هو أفضل ترتيب للأولوية أثناء حادث الإنتاج؟

• أ) قم أولاً بالعثور على السبب الجذري الدقيق وتقليله فقط عندما يكون السبب واضحًا.
• ب) قم أولاً بكتابة تقرير التشريح، ثم المس الخدمة
• ج) تقليل أولاً (استعادة/استعادة الخدمة)، وترك تحليل السبب الجذري لوقت لاحق ✔
• د) أولا العثور على الشخص المسؤول عن الحادث والإبلاغ عنه

توضيح: القاعدة الذهبية هي "التقليل أولاً، والتحقيق لاحقًا". الهدف هو استعادة الخدمة أولاً أو إعادتها إلى إصدار معروف جيدًا (التخفيف)؛ ويتم تحليل السبب الجذري بهدوء بعد أن يهدأ الضغط. يؤدي الانتظار للعثور على السبب الجذري الدقيق إلى زيادة وقت الاسترداد (MTTR).

11. ما هو الهدف الرئيسي لثقافة ما بعد الوفاة الخالية من اللوم؟

• أ) تحديد هوية المخطئ وتحميل المسؤولية عليه
• ب) التركيز على الأنظمة والعمليات وتشجيع التعلم. ✔ تعلم الدروس التي تمنع التكرار بدلاً من اللوم
• ج) عدم الإبلاغ عن الحادثة والتأكد من نسيانها
• د) كتابة التفاصيل الفنية فقط وعدم إضافة عناصر قابلة للتنفيذ

الشرح: يركز فحص الأبرياء بعد الوفاة على سؤال "ما هو النظام والعملية التي سمحت بهذا الخطأ"، وليس "من ارتكب هذا الخطأ". يتقاسم الناس الخطأ علانية إذا علموا أنهم لن يعاقبوا؛ ويتكرر الخطأ الخفي. التقرير ليس تقرير اتهام، بل هو وثيقة تعليمية مليئة بالعناصر ذات التوجه العملي.

12. في تحسين التكلفة السحابية (FinOps)، ما هي الخطوة الأكثر منطقية التي يجب اتخاذها قبل الانتقال إلى الخصومات الملتزم بها (خطة المحجوزة/التوفير)؟

• أ) خذ أطول التزام ممكن أولاً، ثم فكر في الهدر لاحقًا
• ب) أولاً، قم بتنظيف النفايات (الإغلاق الخامل، الحجم الصحيح)، ثم الالتزام بالاستخدام الملتزم ✔
• ج) انقل جميع الموارد إلى سعة Spot على الفور
• د) حذف أغلى صنف دون مراجعة بيانات الفاتورة

توضيح: يجب تنظيف النفايات أولاً (إغلاق الموارد الخاملة، وتقليل الموارد كبيرة الحجم). وإلا، فسوف تقوم بتأمين الاستخدام المهدر بسعر مخفض لمدة 1-3 سنوات. لا يتطلب الحجم الصحيح والتنظيف الخامل أي التزام ويكاد يكون خاليًا من المخاطر.

13. ما هو الإجراء الأمني ​​الأكثر أهمية إذا كان البرنامج النصي المقترح بواسطة الذكاء الاصطناعي يحتوي على السطر 'rm -rf "$DIR"/'؟

• أ) سيؤدي تشغيل البرنامج النصي مباشرة في المنتج دون قراءته إلى تسريع الأمر
• ب) أضف set -euo Pipefail وتحكم متغير فارغ وحاول التشغيل الجاف أولاً ✔
• ج) اختصار اسم المتغير يكفي
• د) استخدام rm -rf --force بدلاً من rm يحل المشكلة

Explanation: اذا كان $DIR فارغا، فقد يحاول هذا البيان حذف الدليل الجذر. التوقف عند المتغير غير المحدد باستخدام 'set -u' والتحقق من أن المتغير ليس فارغًا قبل حذفه (على سبيل المثال، [ -n "$DIR" ] || مخرج 1) يتجنب حدوث كارثة. بالإضافة إلى ذلك، يجب تجربة العمليات التدميرية مع التشغيل الجاف أولاً.

14. ما هو أول شيء يجب فعله إذا تسرب مفتاح الوصول إلى السحابة عن طريق الخطأ إلى مستودع عام؟

• أ) إلغاء وتجديد (تدوير) المفتاح على الفور؛ الحذف وحده لا يكفي✔
• ب) ما عليك سوى حذف الملف من وحدة التخزين ويكون المفتاح آمنًا
• ج) عدم القيام بأي شيء لأنه لم يره أحد
• د) إن جعل مساحة التخزين خاصة يلغي الحاجة إلى تدوير المفتاح

توضيح: يجب إلغاء السر المتسرب وتدويره فوراً. مجرد حذف الملف لا يكفي لأن السر يبقى في سجل Git ويتم فحص المستودعات العامة بواسطة الروبوتات في غضون ثوانٍ. بعد الإلغاء/الإرجاع، يتم تقييم التأثير وإضافة ماسح ضوئي سري لمنع تكراره.

15. أي من الأساليب التالية يقلل المخاطر عند إصدار نسخة جديدة من Prod؟

• أ) إعطاء الإصدار الجديد لجميع المستخدمين في نفس الوقت (الانفجار الكبير) وعدم إعداد خطة التراجع
• ب) اعتبار النشر قد انتهى بمجرد ظهوره باللون "الأخضر"، وعدم إجراء تحقق إضافي
• ج) استخدام إستراتيجية يمكن التحكم فيها مثل علم الكناري/الأزرق والأخضر/الميزة وخطة التراجع الجاهزة واختبار الدخان + المراقبة المترية بعد النشر ✔
• د) ترك اختبار مسارات الأعمال الحيوية بالكامل للذكاء الاصطناعي وعدم تحديدها على الإطلاق.

Explanation: استراتيجيات الإصدار الخاضعة للرقابة (تبدأ بنسبة صغيرة باستخدام الكناري، والتراجع الفوري باللون الأزرق والأخضر، وفصل النشر عن الإصدار باستخدام علامة الميزة) تحد من المخاطر. بالإضافة إلى ذلك، من الضروري وجود خطة تراجع واضحة قبل النشر ومراقبة الإشارة الذهبية مع اختبار الدخان بعد النشر؛ "المظهر الأخضر" لا يعني أنه يعمل.