كيفية أتمتة تحليل الأسباب الجذرية لفشل تحديثات AWS باستخدام AWS DevOps Agent

عندما يُبلغ مدير التصحيحات في خدمة AWS Systems Manager عن إخفاقات عبر مئات العقد المدارة التي تمتد عبر حسابات ومناطق متعددة، غالباً ما تواجه فرق العمليات مهمة شاقة تستنزف الوقت. يُضطر المهندسون إلى تسجيل الدخول إلى كل حساب، وربط الأحداث، وتحليل السجلات، وتحديد ما إذا كانت الإخفاقات تشترك في سبب جذري واحد. يمكن لفشل دورة تصحيح واحدة أن يستهلك بسهولة ساعات من وقت الهندسة الثمين.

للقضاء على هذا العناء اليدوي، قدمت شركة AWS حلاً يعتمد على الأحداث يُشغّل تلقائياً تحليل السبب الجذري (Root Cause Analysis) لإخفاقات التصحيح باستخدام وكيل AWS DevOps Agent. عندما تفشل عملية التصحيح، يُصدر النظام حدث تغيير حالة يحتوي على معرّف الأمر، ومعرّف المثيل، وحالة الخطأ. تلتقط خدمة Amazon EventBridge هذا الحدث، وتقوم دالة في خدمة AWS Lambda بإثرائه بالبيانات الوصفية الحيوية، ليُجري وكيل AWS DevOps Agent تحقيقاً مستقلاً يُنتج تقريراً بالسبب الجذري في غضون دقائق.

من خلال نشر هذه البنية المركزية، يمكن لفرق العمليات إنشاء مسار عمل مؤتمت بالكامل يلتقط أحداث فشل التصحيح عبر حسابات ومناطق متعددة. يُثري المسار كل حالة فشل بمخرجات أوامر Systems Manager، ومعدلات الفشل في الأسطول، والبيانات الوصفية للمثيل قبل توجيه وكيل AWS DevOps Agent للتحقيق المستقل في السبب الجذري دون أي تدخل يدوي لربط السجلات.

يعتمد الحل على بنية مركزية حيث تقوم حسابات أعباء العمل بتوجيه أحداث فشل التصحيح إلى حساب أساسي مركزي يحتوي على دالة Lambda ومساحة وكيل AWS DevOps Agent. يتبع تدفق الأحداث تسلسلاً صارماً ومؤتمتاً لضمان التشخيص السريع.

1. تُنفذ خدمة AWS Systems Manager مستند AWS-RunPatchBaseline على العقد المدارة المستهدفة.
2. عند فشل عملية التصحيح، تُصدر خدمة Systems Manager حدث تغيير حالة مباشرة إلى خدمة Amazon EventBridge.
3. تقوم قاعدة EventBridge في حساب عبء العمل بتوجيه الحدث إلى ناقل الأحداث في الحساب الأساسي، مما يدعم التوجيه عبر الحسابات والمناطق.
4. تستدعي قاعدة EventBridge في الحساب الأساسي دالة AWS Lambda لإزالة التكرار، وإثراء البيانات، وتوجيه حالة الفشل للتحقيق.
5. تتحقق دالة Lambda من قاعدة بيانات Amazon DynamoDB بحثاً عن الأحداث المكررة لمنع التحقيقات المتكررة. ثم تفترض دوراً للعودة إلى حساب عبء العمل لإثراء الحدث، وتسترد مفتاح توقيع HMAC من خدمة AWS Secrets Manager (مُشفراً عبر خدمة AWS KMS)، وتُرسل طلباً موثقاً عبر بروتوكول HTTPS إلى نقطة نهاية الويب هوك الخاصة بوكيل AWS DevOps Agent.
6. يُحقق وكيل AWS DevOps Agent في الفشل بشكل مستقل ويُنشئ تقريراً شاملاً بالسبب الجذري.

قبل بناء هذا المسار القائم على الأحداث، تأكد من أن بيئة AWS الخاصة بك تلبي المتطلبات التأسيسية اللازمة. ستحتاج إلى حساب AWS يحتوي على مساحة نشطة لوكيل AWS DevOps Agent، ويجب تسجيل حسابات أعباء العمل الخاصة بك كمصادر ثانوية داخل تلك المساحة.

• حساب واحد أو أكثر من حسابات أعباء العمل التي تحتوي على عقد مدارة عبر خدمة Systems Manager.
• تكوين خدمة AWS Organizations (موصى به بشدة لعمليات النشر متعددة الحسابات)، مما يتطلب معرّف المؤسسة الخاص بك أو قائمة محددة بمعرّفات حسابات أعباء العمل.
• أذونات IAM المناسبة لإنشاء حزم AWS CloudFormation ومجموعات الحزم (StackSets) عبر بيئتك.

تتضمن المرحلة الأولى إعداد مساحة العمل المركزية حيث ستُجرى التحقيقات المستقلة. تتطلب هذه المساحة أدوار IAM محددة لاكتشاف موارد AWS والوصول إليها أثناء تحليلها.

1. افتح وحدة تحكم AWS DevOps Agent في حسابك الأساسي واختر إنشاء مساحة الوكيل (Create Agent Space).
2. في حقل اسم مساحة الوكيل (Agent Space Name)، أدخل اسماً وصفياً لبيئتك (على سبيل المثال، patch-rca-production).
3. ضمن قسم الوصول إلى الموارد، حدد الإنشاء التلقائي لدور وكيل AWS DevOps Agent جديد (Auto-create a new AWS DevOps Agent role) لمنح الوكيل الأذونات اللازمة لفحص بنيتك التحتية.
4. فعّل تطبيق الويب عن طريق تحديد الإنشاء التلقائي لدور وكيل AWS DevOps Agent جديد (Auto-create a new AWS DevOps Agent role)، مما يتيح للموظفين التفاعل مع الوكيل ومراجعة التوصيات.
5. اختر إنشاء (Create) لإنهاء إعداد مساحة العمل.

بعد ذلك، قم بتسجيل كل حساب عبء عمل تقوم فيه بتصحيح المثيلات بنشاط. انتقل إلى علامة تبويب القدرات (Capabilities)، وقم بالتمرير إلى قسم السحابة (Cloud)، وضمن المصادر الثانوية (Secondary sources)، اختر إضافة (Add). حدد AWS، وراجع الأذونات، وقدم معرّف حساب AWS للحساب الثانوي، ثم اختر إضافة (Add).

أخيراً، قم بتكوين الويب هوك العام لتلقي الأحداث المُثراة من دالة Lambda الخاصة بك. في علامة تبويب القدرات، قم بالتمرير إلى قسم الويب هوك (Webhooks) وحدد إضافة ويب هوك (Add webhook). تحقق من مخطط البيانات، وأنشئ عنوان URL والمفتاح السري، وقم بتنزيل ملف CSV. يجب عليك حفظ عنوان URL للويب هوك وسر HMAC بشكل آمن، حيث أنهما مطلوبان لخطوة النشر التالية.

مع تكوين مساحة الوكيل، يجب عليك نشر حزمة البنية التحتية الأساسية. توفر هذه الحزمة دالة Lambda، وقاعدة EventBridge، وجدول إزالة التكرار في DynamoDB، والسر في Secrets Manager، ومفتاح التشفير في KMS.

1. قم بتنزيل قوالب CloudFormation من مستودع GitHub الرسمي.
2. افتح وحدة تحكم AWS CloudFormation في حسابك الأساسي واختر إنشاء حزمة (Create stack)، متبوعاً بخيار باستخدام موارد جديدة (With new resources (standard)).
3. قم بتحميل ملف القالب primary-account.yaml واختر التالي (Next).
4. أدخل اسم الحزمة (Stack name) (على سبيل المثال، devops-agent-patch-primary).
5. في قسم المعلمات، أدخل عنوان URL للويب هوك وسر HMAC الذي أنشأته في الخطوة 1.
6. إذا كنت تستخدم خدمة AWS Organizations، فأدخل معرّف المؤسسة الخاص بك (على سبيل المثال، o-abc123) للسماح لحسابات أعباء العمل بتوجيه الأحداث. إذا لم يكن الأمر كذلك، فاتركه فارغاً وقدم معرّفات الحسابات الصريحة في معلمة SecondaryAccountIds.
7. أقر بقدرات IAM واختر إرسال (Submit).

يعتمد النشر على عدة معلمات رئيسية للتحكم في تدفق التحقيق. يمكنك تخصيص هذه القيم بناءً على استراتيجية العلامات والحدود التشغيلية الخاصة بك.

المعلمة	الوصف	القيمة الافتراضية
WebhookUrl	عنوان URL لنقطة نهاية الويب هوك العامة لوكيل AWS DevOps Agent	لا يوجد
WebhookSecret	سر HMAC لمصادقة الويب هوك	لا يوجد
OrganizationId	معرّف مؤسسة AWS للسماح بتوجيه الأحداث	لا يوجد
SecondaryAccountIds	معرّفات حسابات أعباء العمل مفصولة بفواصل (إذا لم تُستخدم المؤسسات)	لا يوجد
InvestigateTagKey	مفتاح العلامة المستخدم لتحديد المثيلات للتحقيق	auto_investigate
InvestigateTagValue	قيمة العلامة التي تُفعّل التحقيق التلقائي	true
DeduplicationWindowMinutes	النافذة الزمنية لإزالة تكرار الإخفاقات من نفس الأمر بالضبط	10
MaxInvestigationsPerCommand	الحد الأقصى لعدد التحقيقات المسموح بها لكل معرّف أمر	5

تتضمن مرحلة النشر النهائية طرح قالب secondary-account.yaml على حسابات أعباء العمل الخاصة بك باستخدام مجموعات حزم AWS CloudFormation StackSets. يُنشئ هذا دور IAM المطلوب لإثراء الأحداث عبر الحسابات وقاعدة توجيه EventBridge التي تُرسل إخفاقات التصحيح مرة أخرى إلى حسابك الأساسي.

تُنشئ الحزمة دور DevOpsAgentPatchEnrichmentRole، والذي يمنح دالة Lambda في الحساب الأساسي وصولاً للقراءة فقط إلى البيانات الوصفية لمثيل EC2، ومخرجات أوامر SSM، ومقاييس CloudWatch. تقيد سياسة الثقة الوصول بشكل صارم إلى دور Lambda في حسابك الأساسي.

1. افتح وحدة تحكم AWS CloudFormation في حساب الإدارة أو المسؤول المفوض وانتقل إلى مجموعات الحزم (StackSets).
2. اختر إنشاء مجموعة حزم (Create StackSet) وحدد الأذونات المدارة بواسطة الخدمة (Service-managed permissions).
3. قم بتحميل ملف القالب secondary-account.yaml وانتقل إلى الخطوة التالية.
4. أدخل اسم مجموعة الحزم (StackSet name) (على سبيل المثال، devops-agent-patch-workload).
5. أدخل معرّف حسابك الأساسي والمنطقة الأساسية (على سبيل المثال، us-east-1) في قسم المعلمات.
6. ضمن أهداف النشر، اختر النشر في مؤسستك بأكملها أو حدد معرّفات وحدات تنظيمية (OU) معينة للحد من النطاق.
7. حدد المنطقة التي حددتها كـ PrimaryRegion، وأقر بقدرات IAM، واختر إرسال (Submit).

نظراً لأن أحداث Amazon EventBridge إقليمية، يجب عليك نشر قالب عبء العمل في كل منطقة تقوم فيها بتشغيل مثيلات مصححة. لإضافة مناطق إضافية لاحقاً، قم بتحرير تفاصيل StackSet، واضبط معلمة CreateIAMRoles على false (نظراً لأن دور IAM العالمي موجود بالفعل)، وأضف المناطق الجديدة ضمن خيارات النشر.

قبل بدء التحقيق، تُجري دالة Lambda عمليات تصفية وإثراء حاسمة لضمان تلقي وكيل AWS DevOps Agent بيانات عالية الجودة وقابلة للتنفيذ دون أن تطغى عليها الأخطاء العابرة.

• التحقق من العلامات: تتحقق الدالة من أن المثيلات التي تتطابق مع مفتاح وقيمة العلامة المكونة (مثل auto_investigate=true) هي فقط التي تنتقل إلى التحقيق.
• إزالة التكرار: تمنع قاعدة بيانات Amazon DynamoDB التحقيقات المكررة ضمن نافذة قابلة للتكوين مدتها 10 دقائق، مما يضمن عدم إغراق الوكيل بإخفاقات متطابقة.
• تقييد الأوامر: يحد النظام من التحقيقات لكل معرّف أمر (الافتراضي هو 5) لمنع التكاليف الجامحة أثناء حالات الفشل الجماعي على مستوى الأسطول.
• تصفية الفشل العابر: يتم تخطي الأنماط الحميدة المعروفة تلقائياً، مثل عمليات الخروج القياسية لإعادة التشغيل أو التنافس المؤقت على القفل.

بمجرد التصفية، يتم إثراء الحدث بمعدل فشل الأسطول، والبيانات الوصفية للمثيل (إصدار نظام التشغيل، والمنصة، ودور IAM)، ورسالة خطأ أمر SSM المحددة، وتصنيف الأولوية المستمد من علامات المثيل.

لتأكيد عمل الحل بشكل صحيح، يمكنك تشغيل تنفيذ خط أساس التصحيح يدوياً على المثيلات ذات العلامات ومراقبة وحدة تحكم AWS DevOps Agent للتحقيق الناتج.

1. افتح وحدة تحكم AWS Systems Manager في حساب عبء العمل وانتقل إلى تشغيل أمر (Run Command).
2. حدد مستند AWS-RunPatchBaseline.
3. ضمن تحديد الهدف، اختر تحديد علامات المثيل (Specify instance tags) وأدخل مفتاح وقيمة العلامة المكونة (مثل auto_investigate و true).
4. اضبط معلمة العملية (Operation) على تثبيت (Install) واختر تشغيل (Run).

إذا فشل أي مثيل يحمل علامة، فسيظهر تحقيق جديد في وحدة تحكم AWS DevOps Agent في غضون 60 ثانية. يربط الوكيل بذكاء التحقيقات ذات الصلة عندما تفشل مثيلات متعددة في نفس النافذة الزمنية، مما يوفر رؤية موحدة للمشكلات على مستوى الأسطول. بدلاً من افتراض أن جميع الإخفاقات تشترك في نفس السبب الجذري، يفحص الوكيل كل فشل بشكل مستقل، ويُنتج نتائج مميزة لسلاسل سببية مختلفة - مثل استنفاد وحدة التخزين الجذرية مقابل أخطاء تحليل DNS.

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

• إدارة التكاليف: يستخدم الحل مكونات بدون خادم تدفع حسب الاستخدام. تُدفع تكاليف الحالة المستقرة بشكل أساسي بواسطة مفتاح AWS KMS وسر Secrets Manager. يُعد تقييد الأوامر أمراً بالغ الأهمية لمنع التكاليف الجامحة أثناء أحداث الفشل الجماعي.
• القياس عن بُعد المُحسّن: تتحسن جودة التحقيق بشكل كبير عندما تُرسل المثيلات سجلات نظام التشغيل إلى خدمة Amazon CloudWatch Logs وتُكوّن عمليات التصحيح مع تسجيل مخرجات Amazon S3. يقرأ الوكيل مخرجات الأمر الكاملة وغير المقتطعة مباشرة من S3.
• بيئات VPC الخاصة: بالنسبة للمثيلات التي تفتقر إلى الوصول المباشر إلى الإنترنت، يجب عليك تمكين سجلات تدفق Amazon VPC وأحداث بيانات CloudTrail S3. هذه مطلوبة للوكيل لتشخيص إخفاقات الاتصال بالشبكة، مثل نقاط نهاية VPC المكونة بشكل خاطئ.
• التعلم المستمر: يساهم كل تحقيق يتم تشغيله في قاعدة معرفة مساحة الوكيل. بمرور الوقت، يستخرج وكيل AWS DevOps Agent تلقائياً أنماط الأسباب الجذرية المتكررة، مع إعطاء الأولوية للتحقق من الصحة على التشخيص الاستكشافي لتقليل متوسط وقت الحل.

لتجنب تكبد رسوم مستقبلية عند اكتمال الاختبار، يجب عليك حذف الموارد. ابدأ بحذف الحزم من StackSet في حسابات أعباء العمل، متبوعاً بحذف الحزمة الأساسية في وحدة تحكم AWS CloudFormation. أخيراً، احذف مساحة الوكيل من وحدة تحكم AWS DevOps Agent.

يُمثل دمج وكيل AWS DevOps Agent في مسارات عمل Systems Manager الروتينية تحولاً جذرياً في كيفية عمل العمليات السحابية للمؤسسات. لسنوات، كان المعيار الصناعي هو التنبيه التفاعلي: يفشل التصحيح، وينطلق إنذار، ويبدأ المهندس البشري العملية الشاقة لسحب السجلات، والتحقق من المقاييس، والاستعلام عن قواعد البيانات للعثور على الإبرة في كومة القش. من خلال تحويل عبء الفرز والربط الأولي إلى وكيل مستقل، تُحول شركة AWS فعلياً دعم المستوى الأول إلى عملية تقودها الآلة.

ما يجعل هذه البنية المحددة قوية هو طبيعتها القائمة على الأحداث مقترنة بإزالة التكرار الصارمة. في أسطول يضم 10,000 مثيل، يمكن أن يؤدي تصحيح سيء إلى آلاف الإخفاقات المتزامنة. بدون طبقة إزالة التكرار في DynamoDB والتقييد لكل أمر المدمج في دالة Lambda، يمكن لأداة تحليل السبب الجذري المؤتمتة أن تُحدث بسهولة ارتفاعاً هائلاً في استدعاءات واجهة برمجة التطبيقات، مما يؤدي إلى التقييد وتكاليف غير متوقعة للخدمات بدون خادم. من خلال إثراء البيانات بالسياق على مستوى الأسطول قبل استدعاء الوكيل، يضمن النظام أن الذكاء الاصطناعي لديه النطاق الدقيق لنصف قطر الانفجار قبل أن يبدأ في الاستدلال.

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