إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
وكيلك يشخص المشاكل ويصلحها. يعيد تشغيل الخدمات، ويوسع الموارد، ويشد إعدادات الأمان، ويجمع التشخيصات، وكل ذلك بمستوى التحكم الذي تختاره.
نصيحة
- اطلب من وكيلك إصلاح مشكلة. يقترح حلا، توافق عليه، وينفذ الإصلاح.
- سجل تدقيق كامل: من تسبب في ذلك، ما الذي تغير، وهل نجح.
- اختر مستوى الثقة الذي تعرفه: وضع المراجعة (الموافقة على كل إجراء) أو وضع الاستقلال (الوكيل يتولى الأمر).
المشكلة: التشخيص دون اتخاذ إجراء يضيع الوقت
لقد حددت المشكلة. ماذا الآن؟ تذهب إلى بوابة Azure، تجد الشفرة الصحيحة، تؤكد المصدر، تختار عبر حوارات التأكيد، تنتظر انتهاء العملية، ثم تتحقق من أنها عملت. استغرق التحقيق خمس دقائق. الإصلاح يستغرق عشر سنوات أخرى.
هذا الاحتكاك موجود عبر سير العمل التشغيلي لديك:
- العمليات اليومية: قم بتوسيع الموارد حسب الحمل المتوقع، وإعادة تشغيل الخدمات خلال فترات الصيانة.
- فحوصات الامتثال: تشديد إعدادات الأمان عبر عشرات حسابات التخزين.
- الاستجابة عند الطلب: نفذ الإصلاحات المعروفة بسرعة حتى يتمكن المهندسون من العودة إلى وضع السكون.
- تحسين استباقي: قم بتعديل وحدات التخزين بناء على أنماط الاستخدام قبل حدوث المشاكل.
كيف يغلق وكيلك الحلقة
عندما يحدد وكيلك مشكلة، لا يتوقف الأمر عند إخبارك بما هو خطأ. يقترح إجراء معالجة محدد، وحسب وضع التشغيل لديك، إما ينتظر موافقتك أو ينفذ الإجراء فورا.
يتبع الوكيل نمطا ثابتا: تشخيص → تحديد الإجراء → التحقق من الأصوات → تنفيذ (أو اقتراح) → التحقق من نجاح الإصلاح. كل فعل يسجل بمن تسبب في ذلك، وما الذي تغير، ولماذا، وهل نجح.
بعد التحقيق، يمكن لوكيلك اتخاذ إجراء مباشر، أو إنشاء عناصر تتبع، أو إبلاغ فريقك.
ما الذي يجعل هذا النهج مختلفا عن النصوص
النصوص صارمة. يشغلون نفس الإجراء بغض النظر عن السياق. وكيلك يفكر في الوضع أولا. يأخذ في الاعتبار ما وجده أثناء التحقيق، وما يتذكره من الحوادث السابقة، وما توصي به مهاراتكوقاعدة معرفتك . قد يؤدي نفس العرض إلى إعادة تشغيل في حالة وزيادة في حالة أخرى، لأن العامل يتكيف بناء على الأدلة.
أوضاع الجري تمنحك ثقة متدرجة. ابدأ في وضع المراجعة حيث يقترح الوكيل وأنت توافق. انتقل إلى الوضع المستقل عندما تشعر بالثقة في النمط. استخدم ReadOnly للوكلاء الذين يراقبون فقط ولا يتخذ أي إجراء.
ما يمكن لوكيلك فعله
يمكن لوكيلك تنفيذ أي إجراء Azure من خلال أوامر Azure CLI. إذا استطعت تشغيله az، يمكن لوكيلك تشغيله أيضا. تشمل هذه القدرة إدارة أي نوع من الموارد، تعديل التكوينات، إنشاء الموارد، وتشغيل أي عملية Azure.
| نوع الأوامر | ما الذي يمكن له |
|---|---|
| أوامر القراءة | استعلام أي مورد Azure - az webapp list, az containerapp show, az vm list, az network vnet show. يعمل فورا، لا حاجة للموافقة. |
| أوامر الكتابة | تعديل أي مورد Azure: az webapp restart, az containerapp update, az vm resize, az role assignment create. يتطلب الموافقة في وضع المراجعة. |
تقيد أفعال الوكيل فقط بالأذونات المخصصة لهويته المدارة. إذا منحت مساهما على مجموعة موارد، يمكن لوكيلك إدارة كل شيء في تلك المجموعة. إذا منحت دورا مخصصا بإجراءات محددة، فإن وكيلك سيكون محدودا بتلك الإجراءات.
حواجز السلامة
يفرض العميل قيود السلامة على مستوى القيادة.
-
حذف العمليات المحجوبة: الوكيل لا يشغل
deleteأبدا الأوامرremove. يعرض خطأ يوجه المستخدمين إلى بوابة Azure للحذف. -
أوامر خزنة المفاتيح محجوبة: يقوم الوكيل بحجب جميع
az keyvaultالأوامر لمنع كشف بيانات الاعتماد. - احترام أقفال الإدارة: قبل تعديل أي مورد، يقوم الوكيل بالتحقق من أقفال إدارة Azure. الموارد التي تحتوي على أقفال للقراءة فقط لا يمكن تعديلها.
- التحقق من صحة الاشتراك: يقوم الوكيل بالتحقق من معرفات الاشتراك في أوامر لتنسيق GUID الصحيح قبل التنفيذ.
قبل وبعد
يقارن الجدول التالي عملية التخفيف اليدوي مع النهج المدعوم من الوكيل.
| قبل | بعد | |
|---|---|---|
| إصلاح التنفيذ | انتقل إلى بوابة Azure، ابحث عن مورد، اختر من خلال الشفرات | اسأل الوكيل، وافق، وانتهى |
| التحقق | تحقق يدويا إذا كان الحل قد نجح | الوكيل يتحقق ويبلغ عن النتائج |
| تدقيق | آمل أن يكون هناك من وثق ما فعلوه | مسار التدقيق الكامل في Application Insights |
| عهد | مهندس واحد يعرف الحل | الوكيل يطبق الأنماط المكتسبة باستمرار |
متطلبات الإذن
بشكل افتراضي، لدى الوكلاء وصول إلى القارئ ولا يمكنهم اتخاذ إجراءات. أنت تمنح صلاحيات كتابة صراحة عن طريق تعيين أدوار لهوية وكيلك المدارة.
| النطاق | ما يمكن للوكيل أن يتصرف بناء عليه | موصى به ل |
|---|---|---|
| Resource | مورد واحد فقط | أقصى قيود. ابدأ من هنا. |
| مجموعة الموارد | جميع الموارد في مجموعة واحدة | أحمال عمل الإنتاج |
| اشتراك |
أي مورد في الاشتراك | التطوير والاختبار فقط |
التحذير
يقوم الوكيل بفحص أقفال إدارة Azure قبل تعديل أي مورد. لا يمكنك تعديل الموارد باستخدام أقفال ReadOnly Locks، بغض النظر عن الأذونات أو وضع التشغيل. عمليات الحذف والإزالة محجوبة تماما. يمكنك استخدام بوابة Azure للحذف.
مسارات استجابة بديلة
التخفيف المباشر ليس الخيار الوحيد. تفضل العديد من الفرق توجيه النتائج إلى عناصر العمل أو أنظمة التذاكر بدلا من تنفيذ الإجراءات مباشرة. تكون عناصر العمل مفيدة بشكل خاص عندما تكون هناك حاجة لمراجعة بشرية أو عندما يتم تطبيق عمليات إدارة التغيير.
| مسار الاستجابة | طريقة العمل | مناسب لـ |
|---|---|---|
| التخفيف المباشر | يقوم الوكيل بتنفيذ إعادة التشغيل، التكبير، أو التصعيد | أنماط موثوقة، عدم الإنتاج |
| إنشاء عنصر عمل | الوكيل يخلق مشكلة في GitHub أو عنصر عمل Azure DevOps | إنسان في الحلقة، إدارة التغيير |
| إرسال إشعار | الوكيل ينشر في Teams أو يرسل بريدا إلكترونيا | الوعي بدون فعل |
| سير عمل المشغلات | يقوم الوكيل بإرسال إجراءات GitHub أو تطبيقات المنطق | تكامل CI/CD، العمليات متعددة الخطوات |
قم بتكوين إنشاء عناصر العمل والإشعارات عبر الموصلات. على سبيل المثال، قم بتوصيل خادم MCP في GitHub للسماح لوكيلك بإنشاء المشاكل، أو قم بتوصيل Azure DevOps لإنشاء عناصر العمل تلقائيا.
لمزيد من المعلومات، راجع إرسال الإشعاراتوأتمتة سير العمل لربط هذه الأنواع معا.
مثال: التخفيف الناتج عن الحوادث
المثال التالي يوضح كيف يتعامل وكيلك مع حادثة ذكرى في الساعة 3:47 صباحا أثناء نومك.
3:47 صباحا: يرسل PagerDuty تنبيها: "ذاكرة عالية على واجهة الإنتاج"
وكيلك (في وضع المراجعة) يتولى كل شيء:
يعترف بالحادث: PagerDuty يظهر "تم الاعتراف به من قبل وكيل SRE."
يحقق تلقائيا:
- استفسارات التطبيق: الذاكرة عند 94%، ويتجه للارتفاع خلال ساعتين.
- يتحقق من تاريخ النشر: لا توجد عمليات نشر حديثة.
- يتذكر من الذاكرة: "آخر مرة حدث هذا، تم حل المشكلة من إعادة التشغيل."
يقترح حلا: المشاركات في موضوع الحادث:
Memory at 94% on prod-api (App Service). Recommended action: Restart the App Service. Evidence: - Memory climbing since 1:30 AM - No recent deployments - Past incident: restart resolved similar issue on 2026-01-15 [Approve] [Deny]توافق (أو في وضع الاستقلال، يقوم الوكيل بالتنفيذ فورا).
يقوم الوكيل بتنفيذ والتحقق من:
✓ Restarted prod-api ✓ Memory now at 42% ✓ Incident resolved
ما حدث: اخترت الموافقة وكان الوكيل مسؤولا عن التحقيق، والإجراءات، والتحقق.
سجل المراجعة
يسجل النظام كل إجراء تخفيفي مع السياق الكامل.
| الحقل | المعلومات التي تم الاستيلاء عليها |
|---|---|
| Identity | الوكيل والهوية المدارة |
| العمل | العملية التي أجريت بالضبط |
| Timestamp | عند تنفيذ العملية |
| المشغِّل | التشخيص أو الحالة التي أدت إلى الفعل |
| النتيجة | النجاح أو الفشل، مع التحقق بعد اتخاذ الإجراءات |
يمكنك الاستعلام عن مسار التدقيق في Application Insights من خلال سجلات المراقبة > في بوابة الوكيل. يقوم النظام بتسجيل كل az أمر كحدث AgentAzCliExecution مخصص. لمزيد من المعلومات، راجع إجراءات وكلاء التدقيق.
الشروع في العمل
تعمل التخفيف تلقائيا مع أداة Azure CLI المدمجة. تحكم في مدى استقلالية وكيلك خلال أوضاع التشغيل.
| مورد | ما ستتعلمه |
|---|---|
| ضع خطة استجابة | تكوين خطط الاستجابة التي تتضمن التخفيف الآلي |
| أوضاع التشغيل | تكوين مستويات القراءة فقط، المراجعة، أو التنفيذ التلقائي |