كيفية أتمتة ترقيات دورة حياة AWS باستخدام DevOps Agent وKiro

تُعد إدارة ترقيات دورة حياة خدمات AWS عبئاً تشغيلياً مستمراً يستنزف ساعات عمل المهندسين ويهدد استقرار بيئات الإنتاج. عندما تقترب إصدارات الخدمات المدارة مثل خدمة Amazon EKS أو خدمة Amazon RDS من نهاية فترة الدعم القياسية، تسارع الفِرق لتحديد الموارد المتأثرة، وتحديث تعريفات البنية التحتية ككود (IaC)، والتحقق من التغييرات قبل انتهاء المهلة. هذه العملية اليدوية عُرضة للأخطاء البشرية، وتتفاقم تعقيداتها بشكل كبير عندما تتطلب خدمات متعددة تحديثات متزامنة.

من خلال دمج وكيل AWS DevOps Agent مع أداة Kiro، يمكن للمؤسسات تحويل هذا الجهد اليدوي إلى مسار عمل مؤتمت بالكامل يعتمد على الأحداث. صُمم هذا الدليل لفِرق هندسة موثوقية المواقع (SRE) ومهندسي السحابة الذين يسعون للانتقال من التنفيذ اليدوي للترقيات الروتينية إلى مجرد مراجعة طلبات دمج التغييرات (Pull Requests) المُدققَة مسبقاً. يضمن تنفيذ هذا المسار التحقيق في الترقيات، وكتابة الأكواد، والتحقق من صحتها بشكل مستقل، مما يقلل بشكل جذري من الجهد التشغيلي.

يعمل مسار الترقية المؤتمت عبر هيكلية تعتمد على الأحداث وتتكون من خمس مراحل أساسية. تبدأ باكتشاف الحدث وتنتهي بطلب دمج تغييرات مدقق وجاهز للمراجعة البشرية.

المرحلة الأولى: الاكتشاف

يبدأ المسار عندما ينشر نظام AWS Health حدثاً من نوع AWS_EKS_PLANNED_LIFECYCLE_EVENT على ناقل خدمة Amazon EventBridge الافتراضي. يشير هذا الحدث إلى أن إصدار الخدمة المدارة يقترب من نهاية فترة الدعم القياسية.

service: EKS
eventTypeCategory: scheduledChange
eventTypeCode: AWS_EKS_PLANNED_LIFECYCLE_EVENT
affectedEntities: <array of cluster ARNs with status: PENDING>
eventRegion: <region of the affected cluster>

تتطابق قاعدة في خدمة Amazon EventBridge تُسمى eks-health-planned-lifecycle مع هذا الحدث تحديداً، وتستدعي وظيفة AWS Lambda المُسماة devops-agent-health-event. تستخرج هذه الوظيفة اسم المجموعة والمنطقة، وتُنشئ حمولة خطاف ويب (Webhook) مع علامة حادث عالي الأولوية، وتُرسلها إلى نقطة نهاية خطاف الويب الخاصة بوكيل AWS DevOps Agent. يوجه هذا الإجراء الوكيل لتنفيذ مهارة eks-upgrade-planning.

المرحلة الثانية: التحقيق

بمجرد تفعيله، يستخدم وكيل AWS DevOps Agent مهارة eks-upgrade-planning لرسم خريطة لهيكلية المجموعة، والتحقق من زيادات الإصدار، وفحص توافق الإضافات، والبحث عن واجهات برمجة التطبيقات (APIs) المهملة. بعد ذلك، يُنشئ مواصفات تغيير مهيكلة خاصة بحزمة تطوير السحابة (AWS CDK).

تتضمن هذه المواصفات نصوص الإصدار المستهدف، وتقييماً لجاهزية التراجع، وحكماً بالجدوى (مثل READY أو BLOCKED)، وتصنيفاً للمخاطر. عند الانتهاء، يُصدر الوكيل حدث Investigation Completed عائداً إلى خدمة Amazon EventBridge.

source: aws.aidevops
detail-type: Investigation Completed
detail.metadata.agent_space_id: <the agent space ID>
detail.metadata.task_id: <the backlog task ID>
detail.metadata.execution_id: <the execution ID>
detail.data.status: <investigation result status>

المرحلة الثالثة: كتابة الكود والتحقق

تلتقط قاعدة ثانوية في خدمة Amazon EventBridge تُسمى devops-agent-investigation-events حدث الاكتمال هذا، وتستدعي وظيفة AWS Lambda المُسماة devops-agent-trigger-upgrade. تسترد هذه الوظيفة سجل التحقيق، وتتحقق من وجود مواصفات تغيير CDK صالحة، وتُطلق مسار عمل عبر خدمة GitHub Actions باستخدام رمز الوصول الشخصي لمنصة GitHub (PAT) المُخزن في خدمة AWS Secrets Manager.

يفرض مسار عمل GitHub Actions تحققاً صارماً. حيث يمسح الحمولة بحثاً عن كتل الأكواد المحاطة بعلامات والتي تحتوي على CLUSTER_VERSION، ويتأكد من عدم بقاء أي علامات نائبة. إذا كان تقييم الجدوى الخاص بالوكيل يحمل علامة BLOCKED، يتوقف المسار فوراً. بمجرد التحقق، يُثبّت المسار واجهة سطر الأوامر (CLI) الخاصة بأداة Kiro ويُشغلها في الوضع غير المرئي (Headless Mode).

kiro-cli chat --no-interactive --trust-tools=read,write,glob,grep \
"Read kiro-cdk-instructions.md for context on the CDK patterns. Then read /tmp/cdk-change-spec.txt  -  it contains the validated CDK Change Spec extracted from the DevOps Agent investigation. Apply those values exactly. Modify lib/iteration3-stack.ts ONLY. Do NOT derive or guess version numbers  -  use only the values from the spec file. Make only the file edits  -  do not run any build or shell commands, and do not commit."

تقتصر صلاحيات أداة Kiro عمداً على أدوات الملفات فقط (read، write، glob، grep)، وتُوجّه صراحةً بعدم استنتاج أرقام الإصدارات بشكل مستقل. بعد أن تُعدّل أداة Kiro ملف lib/iteration3-stack.ts، يُجري المسار فحصاً للاحتواء لضمان عدم تعديل أي ملفات أخرى، ويُحدّث تبعية طبقة kubectl، ويُشغل عملية تجميع CDK كاملة لضمان نجاح بناء الكود.

المرحلة الرابعة: المراجعة والنشر

بعد خروج أداة Kiro بنجاح، يفتح مسار العمل طلب دمج تغييرات (Pull Request) على منصة GitHub في فرع ترقية مخصص. يتضمن نص الطلب تحذيراً بشأن نافذة التراجع، وقائمة تحقق للمراجع، وكتلة investigation-context قابلة للقراءة آلياً تحتوي على معرف مساحة الوكيل.

يتوقف المسار المؤتمت عند هذه النقطة. يُراجع فريق هندسة موثوقية المواقع (SRE) التغييرات باستخدام عملية الموافقة القياسية الخاصة بهم. بعد الدمج، ينشر الفريق التحديث باستخدام مسار CI/CD الحالي لديهم، مع ضمان علامات السياق لإمكانية التتبع.

المرحلة الخامسة: اكتشاف الفشل والتخفيف المؤتمت

إذا فشلت ترقية تم نشرها، تُصدر خدمة CloudFormation حدث تغيير حالة المكدس (مثل ROLLBACK_FAILED) إلى خدمة Amazon EventBridge. يؤدي هذا إلى تشغيل وظيفة AWS Lambda الخاصة بالفشل، والتي تفتح تحقيقاً جديداً باستخدام مهارة eks-failure-root-cause.

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

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

تُشغّل قاعدة في خدمة Amazon EventBridge وظيفة AWS Lambda خاصة بمراجعة المهارات يومياً، والتي تجلب جميع ملفات المهارات وتنشرها في مساحة الوكيل. يُشغّل الوكيل مهارة eks-skill-review للتحقق من الادعاءات مقابل المصادر الرسمية لشركة AWS. إذا تم العثور على فجوات، يستخدم مسار عمل GitHub Actions أداة Kiro لتطبيق التعديلات على ملفات المهارات ويفتح طلب دمج تغييرات ليقوم الفريق بمراجعته.

تحمل ترقيات خدمة Amazon EKS مخاطر كامنة تتطلب فحوصات أمان مؤتمتة صارمة. يفرض المسار عدة قيود غير قابلة للتفاوض.

• ترقيات الإصدارات الفرعية الفردية: لا تدعم خدمة EKS تخطي إصدارات Kubernetes. يتحقق الوكيل من ذلك ويتوقف إذا اكتشف تخطياً للإصدار.
• نافذة التراجع لمدة 7 أيام: يمكن التراجع عن ترقيات مستوى التحكم في غضون سبعة أيام، شريطة اجتياز فحوصات جاهزية التراجع. يوثق نص طلب الدمج هذه النافذة بوضوح.
• ترتيب تحديث VPC CNI: يجب تحديث إضافة Amazon VPC CNI قبل أي تحديث لمجموعة العقد لمنع فقدان الاتصال بالشبكة. يفرض مكدس CDK ذلك عبر إعلان DependsOn في خدمة CloudFormation.
• منع التغييرات المدمرة: يعني إجراء 'استبدال' (Replace) في خدمة EKS تدمير المجموعة بالكامل. يمنع المسار ذلك من خلال بوابات متعددة الطبقات، بما في ذلك وصول أداة Kiro المقيد للملفات، والمراجعة الإلزامية لأمر cdk diff بواسطة عنصر بشري قبل النشر.

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

• حساب AWS مع تهيئة حزمة تطوير السحابة (AWS CDK) وتكوين واجهة سطر الأوامر (AWS CLI) بالإصدار الثاني.
• تثبيت بيئة Node.js بإصدار 20.x أو أحدث مع مدير الحزم npm.
• رمز الوصول الشخصي لمنصة GitHub (PAT) مع صلاحيات القراءة والكتابة للإجراءات والمحتويات وطلبات الدمج.
• مفتاح واجهة برمجة التطبيقات (API Key) لأداة Kiro (يتطلب اشتراك Pro أو Pro+ أو Power).

1. استنسخ المستودع النموذجي إلى جهازك المحلي. يوفر هذا نصوص التمهيد الأساسية وأكواد البنية التحتية لنشر المسار.

git clone https://github.com/aws-samples/sample-automate-planned-lifecycle-upgrades-with-aws-devops-agent-and-kiro.git
cd sample-automate-planned-lifecycle-upgrades-with-aws-devops-agent-and-kiro

2. نفّذ نص التمهيد البرمجي لتجهيز موارد AWS الأساسية. ينشر هذا النص مجموعة Amazon EKS، ومساحة وكيل AWS DevOps Agent، ووظائف AWS Lambda، وقواعد خدمة Amazon EventBridge المطلوبة للهيكلية القائمة على الأحداث.

./bootstrap.sh

3. كوّن بيانات اعتماد خطاف الويب، ورمز PAT لمنصة GitHub، ومفتاح API لأداة Kiro في خدمة AWS Secrets Manager. يضمن هذا تخزين بيانات الاعتماد الحساسة بأمان والوصول إليها فقط بواسطة وظائف AWS Lambda المصرح لها في وقت التشغيل.
4. شغّل تطبيق الويب الخاص بمساحة وكيل AWS DevOps Agent من وحدة تحكم AWS. تتيح هذه الواجهة لفِرق العمليات إدارة التعليمات ورفع المهارات المخصصة.
5. ألصق التعليمات العامة في قسم المعرفة > التعليمات > جميع الوكلاء (Knowledge > Instructions > All agents). تفرض هذه التعليمات حدود عزل صارمة بين تخطيط الترقية وتحليل السبب الجذري للفشل.
6. اضغط مجلدات المهارات المخصصة الموجودة في المستودع. يُعد ضغط هذه الملفات مطلوباً قبل رفعها إلى تطبيق الويب الخاص بوكيل AWS DevOps Agent.

cd skills
zip -r eks-upgrade-planning.zip eks-upgrade-planning
zip -r eks-failure-root-cause.zip eks-failure-root-cause
zip -r eks-investigation-triage-rules.zip eks-investigation-triage-rules
zip -r eks-skill-review.zip eks-skill-review

7. ارفع كل ملف مهارة مضغوط عبر قائمة الإعدادات > المهارات > المهارات المخصصة (Settings > Skills > Custom Skills). تأكد من تحديد نطاق كل مهارة لنوع الوكيل الصحيح (مثل Incident RCA أو Incident Triage) حتى يتم تفعيلها في السياق المناسب.
8. اشترك ببريدك الإلكتروني المخصص للمناوبات في موضوعات خدمة Amazon SNS المُسماة eks-upgrade-failure-mitigation وeks-skill-update-notifications. يضمن هذا تلقي فريقك تنبيهات فورية لخطط التخفيف ونتائج مراجعة المهارات اليومية.

يُطبق هذا الحل تدابير أمنية قوية لحماية بنيتك التحتية أثناء العمليات المؤتمتة.

• إدارة الأسرار: تُخزن بيانات اعتماد HMAC لخطاف الويب ورمز PAT لمنصة GitHub في خدمة AWS Secrets Manager، ولا يتم تضمينها كأكواد ثابتة أبداً.
• صلاحيات الوصول الأقل (Least-Privilege IAM): تعمل كل وظيفة AWS Lambda بدور IAM مخصص يمنح فقط الحد الأدنى من الصلاحيات المطلوبة.
• مصادقة خطاف الويب: تستخدم الاتصالات بين وظائف AWS Lambda ووكيل AWS DevOps Agent حمولات موقعة بتشفير HMAC-SHA256.
• أدوات الوكيل المقيدة: تقتصر أداة Kiro على أدوات الملفات فقط، مما يمنع تنفيذ أوامر الصدفة (Shell) العشوائية أثناء مرحلة كتابة الكود.

لإزالة الموارد المنشورة وتجنب الرسوم المستمرة، قم بتشغيل نص التنظيف البرمجي المرفق.

./cleanup.sh

يُمثل دمج وكيل AWS DevOps Agent مع أداة Kiro تحولاً جذرياً من الإدارة التقليدية للبنية التحتية ككود (IaC) إلى مسارات عمل تعتمد حقاً على الوكلاء الذكاء الاصطناعي. في حين أن أتمتة "المسار السلس" لترقية خدمة EKS تُعد قيمة بحد ذاتها، فإن الاختراق الحقيقي هنا يكمن في حلقة التخفيف المغلقة للفشل. تفشل معظم مسارات الأتمتة بأمان لكنها تترك الفوضى الناتجة للمهندسين البشريين لفك طلاسمها تحت الضغط.

من خلال هندسة نظام يكتشف تراجع خدمة CloudFormation، ويبدأ تلقائياً في تحليل السبب الجذري (Root-Cause Analysis)، ويُنشئ طلب دمج تغييرات للتخفيف، تُثبت شركة AWS كيف يمكن لوكلاء الذكاء الاصطناعي التعامل مع عمليات اليوم الثاني (Day 2 Operations). لا يكتفي هذا المسار بتنفيذ الأوامر فحسب؛ بل يحترم حدود الأمان الصارمة، ويتحقق من تبعياته الخاصة، بل ويُدقق مهاراته الخاصة يومياً. بالنسبة لفِرق هندسة موثوقية المواقع (SRE)، يعني هذا الانتقال من دور رجال الإطفاء التفاعليين إلى مراجعين استراتيجيين، مما يغير بشكل جذري اقتصاديات إدارة البنية التحتية السحابية على نطاق واسع.