أتمتة المعالجة بعد تحقيق AWS DevOps Agent

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

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

نظرة عامة على الحل

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

يوضح المخطط التالي بنية الحل.

الشكل 1: سير عمل معالجة تلقائية يمتد من تحقيق يقوم به AWS DevOps Agent عبر Amazon EventBridge وAWS Lambda وAmazon Bedrock، مع اعتماد بشري اختياري قبل وصول التغييرات إلى البنية التحتية

تتكون سير العمل من الخطوات التالية:

1. يكمل AWS DevOps Agent التحقيق في الحادث ويُصدر حدثًا يحتوي على الأعراض والنتائج وتحليل السبب الجذري.
2. تستقبل خدمة Amazon EventBridge حدث اكتمال التحقيق وتُفعّل devops-agent-trigger تتعامل مع محتوى التحقيق.
3. تقوم دالة Lambda بتغليف ملخص التحقيق واستدعاء devops-agent-remediation-durable دالة دائمة.
4. ترسل الدالة المتينة سياق التحقيق إلى Amazon Bedrock، الذي يحلل النتائج ويبحث عن المعالجات الممكنة.
5. يحدد Amazon Bedrock ويسرد أدوات المعالجة المتاحة من قائمة سماح منسّقة من دوال Lambda المعتمدة: devops-agent-lambda-tool.
6. تقترح Amazon Bedrock إجراءات معالجة محددة بناءً على نتائج التحقيق والأدوات المتاحة.
7. بالنسبة لإجراءات القراءة فقط، تعمل الدالة الدائمة بأدوات المعالجة تلقائيًا. أما بالنسبة لتغييرات البنية التحتية، فيتوقف سير العمل وينتظر موافقة بشرية قبل المتابعة.
8. بعد الموافقة، تُطبّق الدالة الدائمة إجراءات المعالجة على البنية التحتية باستخدام الأدوات المحددة.

تعمل الدالة الدائمة كـ حلقة وكيلة (agentic loop)، إذ تستدعي Amazon Bedrock بشكل تكراري، وتنفّذ الأدوات المعتمدة، وتُعيد نتائجها إلى المحادثة حتى يكتمل الإصلاح. ولضمان أمان الإجراءات الآلية وقابلية تدقيقها، يفرض المُنسّق قائمة سماح مُنتقاة من أدوات الإصلاح. كل أداة هي دالة Lambda مبنية لغرض محدد تُنفّذ إجراءً بعينه محدود النطاق، مثل قراءة تكوين دالة Lambda أو تحديث عبارة سياسة في AWS Identity and Access Management (IAM). لا يمكن لـ Amazon Bedrock إلا اختيار الأدوات واستدعاؤها من هذه المجموعة المعتمدة، مما يُبقي نطاق الإجراءات الآلية تحت السيطرة. كما يميّز سير العمل بين العمليات للقراءة فقط والعمليات المُعدِّلة. تعمل أدوات القراءة فقط بشكل مستقل دون تدخل بشري. أما إجراءات التغيير التي من شأنها تعديل حالة البنية التحتية فتتسبب في تعليق تنفيذ الدالة الدائمة وانتظار موافقة بشرية. وهنا تقدّم AWS Lambda Durable Functions ميزة رئيسية؛ إذ تُسجّل الدالة نقاط تفتيش (checkpoints) لتقدّمها وتتوقف مؤقتًا لدقائق أو ساعات أو حتى أيام دون استهلاك موارد حوسبة، ثم تستأنف تمامًا من حيث توقفت بعد استقبال إشارة الموافقة. وعندما يتدخل مهندس المناوبة، يكون النظام قد جمع بالفعل التكوينات ذات الصلة، وربط السبب الجذري بإجراءات الإصلاح المتاحة، وأعدّ مجموعة من التغييرات المُتحقَّق منها مسبقًا جاهزة للموافقة بنقرة واحدة. يستخدم التطبيق الحالي إشارة موافقة أو رفض. ولأن الاستدعاء الرجعي يقبل حمولة JSON عشوائية، يمكنك توسيع نطاق الموافقة لتشمل تجاوزات للمعاملات أو ملاحظات المراجع. ويمكن إدخال هذه في محادثة Bedrock لتحسين الإصلاح المقترح قبل التنفيذ.

في الأقسام التالية، نستعرض تفاصيل التنفيذ، بما في ذلك تكوين قاعدة Amazon EventBridge ومنطق تنسيق الدالة الدائمة. ثم ننشر الحل باستخدام AWS Cloud Development Kit (AWS CDK).

المتطلبات الأساسية

قبل نشر هذا الحل، تحقّق من توافر المتطلبات الأساسية التالية:

• تثبيت واجهة سطر أوامر AWS (AWS CLI) وتهيئتها.
• Python 3.14 أو أحدث.
• تثبيت AWS CDK .
• مساحة AWS DevOps Agent نشطة.
• (اختياري) Kiro مع Agent Toolkit for AWS. يمنح Agent Toolkit خدمة Kiro وصولاً آمنًا إلى واجهات برمجة تطبيقات AWS عبر خادم MCP مُدار مع ضوابط وصول قائمة على IAM. إذا كنت تستخدم Kiro، فيمكن إكمال خطوات محاكاة الحادث والنشر والتنظيف في هذه المقالة باستخدام مطالبات بلغة طبيعية بدلاً من تشغيل أوامر CLI يدويًا. ولإعداده، أضف خادم AWS MCP إلى ~/.kiro/settings/mcp.json (تعليمات الإعداد). يتضمن المستودع ملف قواعد ووكلاء لـ Kiro يمنحه سياق المشروع وتسلسل النشر وممارسات السلامة تلقائيًا.

محاكاة الحادث

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

ولإبقاء التركيز على حل الإصلاح نفسه، حُفظت خطوات إنشاء هذه الدالة التجريبية واستدعائها في المستودع. يتضمن المستودع دالة جاهزة للاستخدام devops-agent-timeout وتعليمات خطوة بخطوة لنشرها واستدعائها والتأكد من خطأ المهلة في Amazon CloudWatch Logs. للاطلاع على الشرح الكامل، راجع قسم "محاكاة الحادث" في ملف README.

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

انشر الحل باستخدام AWS CDK

أكمل الخطوات التالية لنشر موارد الحل المتبقية:

كيرو: إذا كان لديك Kiro مع Agent Toolkit for AWS مُعدًّا (انظر المتطلبات الأساسية)، فافتح المستودع المستنسخ في Kiro واسأل: “قم بإعداد بيئة Python ونشر حزمة CDK. أرني الموارد التي سيتم إنشاؤها قبل النشر."يقرأ Kiro قواعد المشروع من المستودع، وينشئ البيئة الافتراضية، ويثبّت التبعيات، ويعرض لك الموارد المخطط لها قبل النشر. وهو يؤكد كل تغيير في البنية التحتية قبل تنفيذه، باتباع نفس نمط التدخل البشري في الحلقة الذي تستخدمه أداة المعالجة ذاتها. وللنشر يدويًا، اتبع هذه الخطوات.

1. استنسخ كود AWS CDK المستضاف على GitHub:

   $ git clone https://github.com/aws-samples/sample-automate-remediation-post-devops-agent-investigation.git

2. انتقل إلى المجلد sample-automate-remediation-post-devops-agent-investigation:

   $ cd sample-automate-remediation-post-devops-agent-investigation

3. تهيئة AWS CDK. هذه الخطوة مطلوبة عند استخدام AWS CDK لأول مرة في بيئة AWS معينة (مزيج من حساب AWS ومنطقة AWS).

   $ cdk bootstrap

4. نشر الحزمة (stack):

   $ cdk deploy

يقوم AWS CDK تلقائياً بتوفير وتكوين الموارد التالية:

• ثلاث دوال Lambda:
  • devops-agent-trigger.
  • devops-agent-remediation-durable.
  • devops-agent-lambda-tool.
• قاعدة Amazon EventBridge.

يتعامل AWS CDK تلقائياً مع أذونات IAM باستخدام مبادئ الحد الأدنى من الامتيازات وأفضل ممارسات أمان AWS. على سبيل المثال، يتم منح Amazon EventBridge lambda:InvokeFunction الأذونات الخاصة بـ devops-agent-trigger function. تمنح الحزمة الإذن aidevops:ListJournalRecords للدالة devops-agent-trigger حتى تتمكن من جلب ملخصات التحقيق من سجل AWS DevOps Agent. كما تمنح الإذن bedrock:InvokeModel للدالة devops-agent-remediation-durable حتى تتمكن من استدعاء Amazon Bedrock.

التحقق من صحة الحل

مع نشر حزمة المعالجة وفشل الدالة devops-agent-timeout بأخطاء انتهاء المهلة، يمكننا الآن الاستعراض عبر سير العمل الكامل من البداية إلى النهاية.

بدء تحقيق باستخدام AWS DevOps Agent

افتح وحدة تحكم AWS DevOps Agent، انتقل إلى مساحة الوكيل الخاصة بك، واسأل: «ما الذي يحدث مع الدالة devops-agent-timeout؟”

الشكل 2: بدء تحقيق من وحدة تحكم AWS DevOps Agent

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

الشكل 3: AWS DevOps Agent يربط الإشارات أثناء التحقيق

بعد اكتمال التحقيق، يقدم AWS DevOps Agent تحليل السبب الجذري، محدداً أن مهلة الدالة غير كافية لحجم العمل.

الشكل 4: تحليل السبب الجذري الذي يحدد أن مهلة الدالة غير كافية

التحقق من تنفيذ Lambda الخاص بالمشغّل

يصدر اكتمال التحقيق حدث Investigation Completed إلى Amazon EventBridge.

تُفعّل القاعدة الدالة devops-agent-trigger دالة Lambda، التي تجلب ملخص التحقيق من مجلة AWS DevOps Agent. في ال /aws/lambda/devops-agent-trigger مجموعة سجلات CloudWatch، يمكنك رؤية الملخص المُحلَّل الذي يُرسَل إلى devops-agent-remediation-durable دالة مستدامة، بما في ذلك الأعراض والأسباب الجذرية والأسباب المساهمة والفجوات في التحقيق.

الشكل 5: ملخص التحقيق المُحلَّل في مجموعة سجلات CloudWatch الخاصة بدالة المشغّل

مراقبة تنفيذ الدالة الدائمة

انتقل إلى وحدة تحكم Lambda، افتح devops-agent-remediation-durable الوظيفة، ثم اختر الـ التنفيذات الدائمة tab. اختر التنفيذ الجديد لفحص خطواته المحفوظة عند نقاط التحقق.

الشكل 6: تنفيذ الدالة الدائمة وخطواتها المحفوظة بنقاط التحقق في وحدة تحكم Lambda

يبدأ المنسّق الدائم حلقة الوكيل الخاصة به عن طريق إرسال سياق التحقيق إلى Amazon Bedrock. في أول استدعاء لـ Bedrock، يقوم النموذج بتحليل ملخص التحقيق ويحدد أنه يحتاج إلى فحص تكوين الدالة الحالي قبل اقتراح إصلاح. وهو يختار ال lambda_get_function_configuration أداة من قائمة السماح. ولأن هذه عملية للقراءة فقط، فإنها تعمل تلقائيًا دون الحاجة إلى موافقة بشرية. وتُظهر نتيجة الخطوة التهيئة الحالية لـ devops-agent-timeout function، ما يؤكد قيمة مهلة انتظار قدرها 3 ثوانٍ.

الشكل 7: استدعاء الأداة للقراءة فقط الذي يعيد تكوين مهلة الانتظار الحالية البالغة 3 ثوانٍ

تقترح Amazon Bedrock الإجراء التصحيحي

بعد التأكد من التكوين الحالي، تنتقل Amazon Bedrock إلى التكرار التالي. تستنتج أن مهلة الانتظار البالغة 3 ثوانٍ هي السبب الجذري للإخفاقات، وتقترح زيادتها إلى 30 ثانية. يحتوي رد Amazon Bedrock على كلاً من التعليل واستدعاء الأداة:

{
  ....
  },
  "output": {
    "message": {
      "role": "assistant",
      "content": [
        {
          "text": "Now I can see the current configuration confirms the issue - the function has a 3-second timeout. Given that this appears to be a test function for timeout scenarios (based on the name \"devops-agent-timeout\" and its association with \"DevOps Agent Test Infrastructure\"), I'll increase the timeout to a reasonable value that should allow the function to complete successfully. I'll set it to 30 seconds, which is a common timeout for Lambda functions that need more execution time."
        },
        {
          "toolUse": {
            "toolUseId": "tooluse_lcGHbWDxng5HiLpmhWagDS",
            "name": "lambda_update_function_configuration",
            "input": {
              "FunctionName": "devops-agent-timeout",
              "Timeout": 30
            },
            "type": "tool_use"
          }
        }
        ...
      }

لأن lambda_update_function_configuration إجراءً من نوع التعديل (mutating)، فإن الدالة الدائمة (durable function) توقف التنفيذ وتنتظر موافقة بشرية.

الشكل 8: مخرجات cloudwatch logs للدالة الدائمة Lambda الخاصة بطلب الموافقة

مهم: الـ investigation_summary المُرسل إلى Amazon Bedrock، والإجراء التصحيحي الذي يقترحه، مُولَّدان بالذكاء الاصطناعي ويجب دائماً مراجعتهما قبل الموافقة. بوابة الموافقة البشرية هي عنصر التحكم الأمني: يجب على المُوافِق فحص كامل معاملات الأداة (على سبيل المثال، الـ FunctionName التحديد والـ Timeout في استدعاء lambda_update_function_configuration والتأكد من صحة التغيير.

باستخدام واجهة سطر أوامر AWS CLI:

$ aws lambda send-durable-execution-callback-success \
    --callback-id <callback-id> \
    --cli-binary-format raw-in-base64-out \
    --result '{"approved": true}'

باستخدام وحدة تحكم AWS Console:

انتقل إلى التنفيذ الدائم (durable execution)، وحدد معاودة الاتصال المعلقة (pending callback)، واختر Send success للتأكيد:

الشكل 9: الموافقة على الإصلاح عن طريق اختيار Send success في وحدة تحكم Lambda

في حقل الإدخال، أدخل {'approved': true} وأكد العملية.

الشكل 10: إدخال حمولة الموافقة لتأكيد معاودة الاتصال

التحقق من الإصلاح

بعد الموافقة، تستأنف الدالة الدائمة عملها، وتستدعي أداة Lambda لتحديث الإعدادات، ويؤكد Amazon Bedrock اكتمال الإصلاح. تُظهر الدالة devops-agent-timeout المحدّثة الآن قيمة المهلة الجديدة:

الشكل 11: إعدادات الدالة devops-agent-timeout محدّثة إلى مهلة مدتها 30 ثانية

تؤكد نتيجة الخطوة الأخيرة (bedrock-call-4) نجاح عملية الإصلاح:

{
  "EventType": "StepSucceeded",
  "Name": "bedrock-call-4",
  ....
  },
  "output": {
    "message": {
      "role": "assistant",
      "content": [
        {
          "text": "## Remediation Complete
          **Issue Identified:** The Lambda function `devops-agent-timeout` in eu-west-1 was configured with a 3-second timeout that was insufficient for its execution time, causing timeout errors at exactly 3000ms.
          **Action Taken:** Successfully updated the Lambda function configuration to increase the timeout from 3 seconds to 30 seconds.
          **Verification:** Confirmed the configuration change was applied successfully. The function now has:
          - **Timeout:** 30 seconds (increased from 3 seconds)
          - **Status:** Successful update completion
          - **LastModified:** 2026-05-22T11:11:28.000+0000
          This remediation should resolve the timeout errors by providing the function with adequate time to complete its execution. The 30-second timeout provides a 10x increase from the original 3-second limit, which should be sufficient for most operations while still maintaining reasonable execution bounds for a Lambda function."
        }
      ]
    }
  },
  "stopReason": "end_turn",
  ...
}

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

تنظيف الموارد

نظّف الموارد التي أنشأتها عن طريق إكمال الخطوات التالية:

Kiro: إذا كنت تستخدم Kiro مع Agent Toolkit for AWS، فاطلب: “نظّف جميع الموارد من عرض توضيحي لإصلاح DevOps Agent: احذف حزمة CDK، واحذف دالة الاختبار devops-agent-timeout ودور IAM الخاص بها ومجموعة سجلات CloudWatch الخاصة بها.” يزيل Kiro الموارد بالترتيب الصحيح، مؤكداً كل إجراء تدميري قبل المتابعة. للتنظيف يدوياً، اتبع هذه الخطوات.

1. احذف موارد AWS CDK:

   $ cdk destroy

2. احذف يدوياً دالة devops-agent-timeout التي تحاكي الحادث:

   $ aws lambda delete-function --function-name devops-agent-timeout

3. احذف يدوياً دور IAM ومجموعة سجلات CloudWatch الخاصة بالدالة devops-agent-timeout :

   $ aws iam detach-role-policy \
       --role-name devops-agent-timeout-role \
       --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
   $ aws iam delete-role --role-name devops-agent-timeout-role
   $ aws logs delete-log-group --log-group-name /aws/lambda/devops-agent-timeout

الخلاصة

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

للبدء في استخدام هذا الحل، نزّل قالب AWS CDK الكامل من مستودع GitHubواتبع الخطوات في هذا المقال لنشر الحل في بيئتك.

يسعدنا أن نسمع منكم. شاركوا تجربتكم في تطبيق هذا الحل، أو اطرحوا أسئلتكم، أو اقترحوا تحسينات في التعليقات. يمكنك أيضًا الانضمام إلى AWS Community Builders للتواصل مع منشئين آخرين ومشاركة أنماط البنية الخالية من الخوادم الخاصة بك.

نبذة عن المؤلف