كيفية بناء مسارات عمل تشغيلية مخصصة باستخدام وكلاء SRE في AWS DevOps Agent

تعاني الفِرَق الهندسية غالباً من ضياع المعايير التشغيلية الدقيقة - مثل ضمان ألا تتأخر نسخة القراءة المطابقة (Read replica) لأكثر من خمس ثوانٍ، أو التحقق من أن مهمة استخراج وتحويل وتحميل البيانات (ETL job) الليلية تتوقف تماماً بحلول الفجر - وهي تفاصيل تعجز أدوات المراقبة العامة عن تتبعها. وعندما تظل هذه المعايير المخصصة حبيسة أدلة التشغيل الثابتة أو الذاكرة المؤسسية، فإنها تُنسى حتماً وسط ضغوط عمليات النشر. لكن إطلاق وكلاء SRE المخصصين في خدمة AWS DevOps Agent يغيّر هذه المعادلة جذرياً، حيث يتيح للفِرَق تحديد مسارات عمل تشغيلية دقيقة ومدركة لطبيعة أعباء العمل بلغة طبيعية، مع فرضها تلقائياً.

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

ونظراً لأن هؤلاء الوكلاء يتم تكوينهم وتنفيذهم مباشرة داخل بيئة AWS DevOps Agent، فإنهم يجلبون سياقاً غنياً من ذكاء الإنتاج. يشمل ذلك اكتشاف الهيكلية عبر الحسابات المتكاملة، والوصول إلى واجهة برمجة التطبيقات (API) لخدمات AWS عبر أدوات معتمدة، وإنشاء عناصر (Artifacts) للتقارير، والتكامل مع سجل العمليات. الميزة الحقيقية هنا ليست مجرد كتابة الهدف بلغة طبيعية، بل تنفيذه في المكان الذي يتواجد فيه السياق والأدوات والاتصالات بالأنظمة الحالية بالفعل.

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

يوفر وكلاء SRE المخصصين طريقة متسقة لربط تلك الخطوات المجزأة. يمكن للوكيل المخصص فحص موارد AWS، أو إنشاء تقرير، أو فتح تذكرة، أو إرسال إشعار، أو قراءة قائمة استثناءات من خدمة Amazon S3، أو تسليم النتائج إلى وكيل متخصص آخر. وتخدم هذه الإمكانية دورين متميزين: أتمتة المهام المخصصة لأعباء عمل محددة، وتوسيع قدرات المنصة نفسها، مما يحول النوايا التشغيلية إلى إجراءات قابلة للتكرار.

يُعد اكتشاف الانحراف (Drift detection) حالة استخدام مثالية لأن كل فريق يعرّف "الانحراف" بطريقة مختلفة. بالنسبة لأحد أعباء العمل، قد يعني ذلك غياب التشفير في مخزن البيانات؛ وبالنسبة لآخر، قد يكون مساراً عاماً مفتوحاً لقاعدة بيانات، أو متطلبات مراقبة لم تعد تتطابق مع معايير الإنتاج. ينفذ وكيل اكتشاف الانحراف نفس الخطوات الأربع التي يقوم بها مهندس متمرس: تحميل سياسات الفريق، واكتشاف هيكلية الإنتاج، وفحص كل مورد ذي صلة عبر واجهة برمجة تطبيقات AWS، ومقارنة الحالة الحالية بالحالة المتوقعة.

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

---
  name: core-policies
  description: Defines infrastructure and data policies, best practices, and sensitive data handling requirements. Use when auditing resources for compliance, reviewing code changes for policy violations, or determining if a resource handles sensitive data.
  ---
  # Core Policies
  This skill defines the organization's infrastructure standards, security policies, and best practices that all cloud resources and applications must follow.
  
  ## Infrastructure & Data Policies
  **No exceptions.** Block code changes that violate these policies and immediately flag infrastructure discovered to have violations.
  
  | Policy | Requirement |
  |--------|-------------|
  | Encryption at rest | All customer data must be encrypted at rest |
  | Encryption in transit | All customer data must be encrypted in transit |
  | Database network isolation | There can be no direct network route to databases from public internet ingress |
  | Resource tagging | All cloud resources must have the `sensitive_data` tag with a `true` or `false` value |
  | No credentials in code | There are no credentials in the code repository |
  
  ## Best Practices
  **Warn but do not block** code changes that violate these standards.
  
  | Practice | Requirement |
  |----------|-------------|
  | Logging | All applications should log to Splunk |
  | Observability | All applications should send traces and metrics to Datadog |
  
  ## Sensitive Data Classification
  Sensitive data can include customer data, intellectual property, or any other data deemed to require higher security measures to protect from exfiltration.
  
  A resource or application requires sensitive data handling if **any** of the following apply:
  1. Classified as `sensitive` in the `DATA_CLASSIFICATION.md` file in the code repository
  2. Tagged with `sensitive_data: true` in AWS or Azure Cloud

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

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

You are a drift detection agent specializing in identifying deviations from operational standards.
  
  ## Goal
  
  Review provisioned AWS resources in the production environment for drift from defined standards and best practices, and create recommendations for any improvements needed. Additionally, identify opportunities to codify your standards as AWS Config rules for automated enforcement.
  
  ## Approach
  
  1. Load the `core-policies` skill to understand the defined standards and best practices.
  2. Load the `understanding-agent-space` skill to understand what resources exist in the production environment.
  3. Identify resources that should be checked against policies (e.g., Lambda functions, RDS instances, S3 buckets, security groups).
  4. Use `use_aws` to make API calls and inspect the actual configuration state of each relevant resource.
  5. Compare each resource's current configuration against the defined policies.
  6. For each deviation found, create a recommendation in the improvements backlog.
  7. Use `use_aws` to list existing AWS Config rules and their configurations.
  8. Compare your defined policies from `core-policies` against existing Config rules to identify coverage gaps  -  standards that could reasonably be enforced via AWS Config but aren't yet.
  
  ## Constraints
  
  - Read-only access to infrastructure  -  do not make changes directly.
  - Only flag deviations that clearly violate defined policies.
  - Focus on provisioned resources, not code or deployment pipelines.
  
  ## Output
  
  Produce a single artifact titled "Drift Detection Report  -  [date]" containing:
  - A summary of resources scanned and deviations found
  - A table listing each drift item: resource ARN, policy violated, current vs. expected state, and suggested remediation
  - A section titled "Config Rule Coverage Gaps" with:
    - Policies from core-policies that could be codified as AWS Config rules but aren't currently
    - For each gap: the policy, why it's a good fit for Config, and a suggested rule approach (managed rule if available, or custom rule outline)
  
  If a drift detection report artifact already exists, update it with the latest findings instead of creating a new one.
  
  Additionally, for each drift item found, create a recommendation with:
  - A clear title describing the deviation
  - The specific policy being violated
  - The resource ARN and current configuration state vs. expected state
  - Suggested remediation steps
  
  Before creating a new recommendation, list existing recommendations and update an existing one if the same drift is already tracked.

بمجرد التنفيذ، يُنتج الوكيل مخرجات دائمة. وتشمل هذه تقارير منظمة (Artifacts) تحتوي على جداول ومخططات هيكلية، وعناصر قابلة للتنفيذ في سجل التحسينات (Improvements backlog)، وإجراءات أدوات بروتوكول سياق النموذج (MCP) التي يمكنها تشغيل عمليات لاحقة مثل إنشاء تذاكر Jira أو إشعارات Slack.

في اختبار عملي، فحص الوكيل 14 وظيفة Lambda، وحوالي 20 حاوية Amazon S3 رئيسية، وجدول DynamoDB عبر منطقة us-east-1. كانت النتائج دقيقة للغاية: فقد وجد ستة عناصر انحراف مميزة. كانت جميع وظائف Lambda الـ 14 وجدول حالة DynamoDB تفتقر إلى العلامة الإلزامية sensitive_data. علاوة على ذلك، كانت العديد من حاويات S3 غير مميزة بعلامات، وكانت وظيفتان من وظائف Lambda لا تزالان تعملان على بيئات تشغيل Node.js منتهية الصلاحية (nodejs12.x و nodejs14.x).

والأهم من ذلك، اكتشف الوكيل أيضاً أنه لم يتم نشر أي قواعد AWS Config، مما يعني أنه لم يتم فرض أي من السياسات الأساسية تلقائياً على مستوى البنية التحتية. ومع ذلك، فقد تحقق من أن التشفير في حالة السكون (AES256) كان مكوّناً بشكل صحيح في جميع الحاويات التي تم فحصها. تم تحويل كل من هذه النتائج تلقائياً إلى توصية في سجل التحسينات، مما يمنع تكرار التذاكر عن طريق تحديث الإدخالات الحالية.

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

تدعم خدمة AWS DevOps Agent تعبيرات الجدولة الزمنية (cron) والمعدل المتوافقة مع خدمة EventBridge. على سبيل المثال، سيؤدي تعيين المشغل إلى cron(0 6? * MON *) إلى تنفيذ الوكيل كل يوم اثنين في الساعة 6:00 صباحاً بالتوقيت العالمي المنسق، وهو توقيت مثالي قبل المراجعة التشغيلية الأسبوعية. يمكنك تكوين ذلك بالانتقال إلى الوكيل المخصص، وتحديد علامة التبويب Triggers، وإدخال تعبير الجدول الزمني.

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

• وكيل SLO: يتحقق مما إذا كانت خدمة معينة تنحرف عن أهداف زمن الاستجابة أو التوافر الخاصة بها.
• وكيل مخاطر النشر: يراجع تغييرات الإنتاج مقابل إشارات المخاطر الخاصة بعبء العمل قبل إطلاقها.
• وكيل وضع المرونة: يتحقق مما إذا كان مسار العمل الحرج لا يزال يلبي افتراضات الاسترداد الأصلية الخاصة به.
• وكيل التسليم التشغيلي: يحول عناصر السجل تلقائياً إلى تذاكر Jira أو إشعارات موجهة للفريق.
• وكيل تحسين التكلفة: يراجع استخدام الموارد وفق جدول يومي ويوصي بتعديل الحجم أو التنظيف.
• وكيل تقارير زمن الاستجابة: يُنشئ ملخصاً يومياً لـ p50/p95/p99 عبر جميع نقاط الاتصال المواجهة للعملاء.

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

يمثل إطلاق وكلاء SRE المخصصين في خدمة AWS DevOps Agent تحولاً جذرياً في كيفية إدارة البنية التحتية السحابية. لسنوات، اعتمدت الفِرَق على أدوات حتمية مثل AWS Config لفرض قواعد عامة. ومع ذلك، فإن أداة AWS Config ثنائية بطبيعتها - فهي تتحقق مما إذا كان المورد يطابق حالة محددة مسبقاً. وتواجه صعوبة في التقييمات الاستدلالية الثقيلة بالسياق، مثل تحديد ما إذا كانت مجموعة معينة من العلامات، ومسارات الشبكة، وتصنيفات البيانات تنتهك سياسة عمل دقيقة.

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

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