التحقيق في انقطاع خدمة GKE باستخدام Antigravity CLI وSRE Extension وإنشاء تقرير Post Mortem رائع

1. مقدمة

856ff52e60953a92.png

تاريخ آخر تعديل: 2026-05-13

التحقيق في انقطاع GKE باستخدام إضافة SRE وإنشاء تقرير Post Mortem مفصّل

مرحبًا بك في ورشة عمل SRE هذه، وهي مخصّصة للمشغّلين الذين يريدون تجربة أدوات SRE على Google Cloud.

سيرشدك هذا الدرس التطبيقي حول الترميز خلال هذه العملية:

  1. ثبِّت مجموعة GKE استنادًا إلى microservices-demo معروف ومفتوح المصدر.
  2. أنشئ انقطاعًا عن طريق تقسيمه بطرق مختلفة (بعضها أكثر وضوحًا، وبعضها أكثر دقة).
  3. ثبِّت Antigravity CLI (أو أداة مشابهة) واستخدِمها + إضافة SRE للجزء التالي.
  4. التحقيق في الانقطاع وإصلاحه
  5. أنشئ تقرير تحليل بعد حدوث الكوارث.
  6. استخدِم مهارات إنشاء الرسومات البيانية لإنشاء رسم بياني مستند إلى بيانات واقعية يتيح للمشاهدين فهم ما حدث ومتى.

في ما يلي البنية المفصّلة للدرس التطبيقي:

مخطّط بنية الدرس التطبيقي حول الترميز

يهدف هذا التدريب إلى:

  1. توضيح إمكانات إضافة SRE وعرض ما يمكن تنفيذه باستخدامها: إعداد OneMCP وSafe Executor والتحقيق وإنشاء تقرير ما بعد الوفاة والرسومات البيانية وملخّصات CSV
  2. تعليمك المهارات اللازمة للتحقيق في سيناريو Google Cloud الخاص بك

المرحلة 1: إعداد البيئة ومحاكاة الانقطاع

الهدف من هذا الإنجاز هو إعداد تطبيق تجريبي على Kubernetes في وضع التشغيل الآلي في GKE، وتثبيت Antigravity CLI، وتفعيل سيناريوهات تعطل مجموعة GKE بشكل مصطنع لمحاكاة الحوادث في مرحلة الإنتاج.

المرحلة 2: التحقيق والتخفيف باستخدام إضافة SRE

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

المرحلة 3: تحليل الأخطاء وإنشاء الرسوم البيانية

بعد حلّ المشكلة، ستنشئ مستندًا منظَّمًا لتحليل أسباب الحادثة، وستستخدم واجهات برمجة تطبيقات GCM (خدمة المراقبة من Google Cloud) لاسترداد بيانات المقاييس الفعلية، وإنشاء رسوم بيانية مرئية لتسجيل وقت حدوث الانقطاع وكيفية حدوثه.

ما ستنشئه

في هذا الدرس التطبيقي حول الترميز، ستتعرّف على كيفية التحقيق في حالات انقطاع GKE وإصلاحها باستخدام إضافة SRE. سيكون عليك إجراء ما يلي:

  • محاكاة انقطاع GKE باستخدام حظر سياسة الشبكة وعمليات نشر Canary التي تتضمّن أخطاء وتحديثات قواعد جدار الحماية
  • تحديد أولويات انقطاع الخدمة في المجموعة باستخدام مساعد سطر الأوامر المستند إلى إضافة SRE
  • تنفيذ خطوات الإصلاح بأمان باستخدام نمط Safe Executor
  • إنشاء مستند شامل بعد انتهاء الحدث
  • إنشاء رسومات بيانية لمقاييس الحوادث باستخدام طلبات البحث عن السلاسل الزمنية في Google Cloud Monitoring

ما ستتعلمه

  • كيفية فحص موارد وسياسات Kubernetes في GKE باستخدام مهارات SRE Extension
  • كيفية الاستفادة من نمط Safe Executor لتنفيذ الأوامر التي يقترحها الوكيل مع إجراء تقييم مناسب للمخاطر
  • كيفية استخدام مهارة monitoring-graphs لإنشاء رسومات بيانية مستندة إلى بيانات المقاييس مباشرةً من GCM
  • كيفية توثيق نتائج الحوادث بتنسيق ما بعد الوفاة المنظَّم

المتطلبات

  • مشروع Google Cloud تم تفعيل الفوترة فيه
  • أدوات سطر الأوامر: gcloud وkubectl وterraform
  • Antigravity CLI مثبَّتة على الجهاز أو في Cloud Shell.
  • بيئة تطوير متكاملة (IDE) (مثل vscode أو IntelliJ أو RubyMine أو Vim)

لماذا SRE Extension + Agentic CLI؟

تتسم الانقطاعات في بيئة الإنتاج بالسرعة وتتطلّب ربطًا بين أنظمة فرعية متعددة (موارد Kubernetes وشبكات السحابة الخاصة الافتراضية ومقاييس Cloud Monitoring وأذونات إدارة الهوية وإمكانية الوصول). يتيح "ملحق هندسة موثوقية الموقع" لمساعدي واجهة سطر الأوامر المستقلين (مثل Antigravity CLI) العمل كطيارين مساعدين مستقلين، وتنفيذ كتيبات التشغيل المُجمَّعة مسبقًا، وطلب بيانات من رسومات المراقبة، واقتراح عمليات إصلاح آمنة مع إبقاء المشغّل البشري على علم بكل خطوة.

2. الإعداد

اختَر أحد الخيارات التالية: إعداد بيئة ذاتية السرعة إذا كنت تريد تنفيذ هذا الإجراء

الدرس التطبيقي حول الترميز على جهازك، أو ابدأ Cloud Shell إذا أردت تنفيذ هذا الدرس التطبيقي حول الترميز بالكامل على السحابة الإلكترونية.

إعداد البيئة بالسرعة التي تناسبك

  1. سجِّل الدخول إلى Google Cloud Console وأنشِئ مشروعًا جديدًا أو أعِد استخدام مشروع حالي. إذا لم يكن لديك حساب على Gmail أو Google Workspace، عليك إنشاء حساب.

295004821bab6a87.png

37d264871000675d.png

96d86d3d5655cdbe.png

  • اسم المشروع هو الاسم المعروض للمشاركين في هذا المشروع. وهي سلسلة أحرف لا تستخدمها Google APIs. ويمكنك تعديلها في أي وقت.
  • رقم تعريف المشروع هو معرّف فريد في جميع مشاريع Google Cloud ولا يمكن تغييره (لا يمكن تغييره بعد ضبطه). تنشئ Cloud Console تلقائيًا سلسلة فريدة، ولا يهمّك عادةً ما هي. في معظم دروس البرمجة، عليك الرجوع إلى رقم تعريف مشروعك (يُشار إليه عادةً باسم PROJECT_ID). إذا لم يعجبك رقم التعريف الذي تم إنشاؤه، يمكنك إنشاء رقم تعريف عشوائي آخر. يمكنك بدلاً من ذلك تجربة اسم مستخدم من اختيارك ومعرفة ما إذا كان متاحًا. لا يمكن تغيير هذا الخيار بعد هذه الخطوة ويظل ساريًا طوال مدة المشروع.
  • للعلم، هناك قيمة ثالثة، وهي رقم المشروع، وتستخدمها بعض واجهات برمجة التطبيقات. يمكنك الاطّلاع على مزيد من المعلومات عن هذه القيم الثلاث في المستندات.
  1. بعد ذلك، عليك تفعيل الفوترة في Cloud Console لاستخدام موارد/واجهات برمجة تطبيقات Cloud. لن تكلفك تجربة هذا الدرس البرمجي الكثير، إن وُجدت أي تكلفة. لإيقاف الموارد وتجنُّب تكبُّد رسوم فوترة تتجاوز هذا البرنامج التعليمي، يمكنك حذف الموارد التي أنشأتها أو حذف المشروع. يمكن لمستخدمي Google Cloud الجدد الاستفادة من برنامج الفترة التجريبية المجانية بقيمة 300 دولار أمريكي.

بدء Cloud Shell

على الرغم من إمكانية تشغيل Google Cloud عن بُعد من الكمبيوتر المحمول، ستستخدم في هذا الدرس التطبيقي حول الترميز Google Cloud Shell، وهي بيئة سطر أوامر تعمل في السحابة الإلكترونية.

من Google Cloud Console، انقر على رمز Cloud Shell في شريط الأدوات أعلى يسار الصفحة:

تفعيل Cloud Shell

لن يستغرق توفير البيئة والاتصال بها سوى بضع لحظات. عند الانتهاء، من المفترض أن يظهر لك ما يلي:

لقطة شاشة لواجهة سطر الأوامر في Google Cloud Shell توضّح أنّه تم ربط البيئة

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

3- المتطلبات الأساسية (التثبيت)

لإكمال هذا البرنامج التعليمي، عليك تثبيت ما يلي:

1. Python وuv

python وuv (أداة إدارة الحِزم للغة Python) تأكَّد من تثبيت uv:

$ curl -LsSf https://astral.sh/uv/install.sh | sh

لماذا الأشعة فوق البنفسجية؟ على الرغم من أنّه يمكنك استخدام أي مدير Python تفضّله، سيضمن استخدام uv إعداد ENV/PATH للغة Python بشكل متساوٍ لك ولأداة Antigravity CLI، وبالتالي ستكون تجربة الصدفة لديك مشابهة إلى حد كبير لتجربة Antigravity CLI. إذا كنت تستخدم virtualenv ، على سبيل المثال، سيتم إجبار Antigravity CLI على تنفيذ إجراءات مثل "source .env/venv/bin/activate && my-original-command" لمحاكاة بيئتك.

2. Antigravity CLI (agy)

لتثبيت Antigravity CLI الرسمية (الأمر agy)، افتح الوحدة الطرفية ونفِّذ أداة التثبيت التمهيدية:

في أجهزة macOS وLinux:

$ curl -fsSL https://antigravity.google/cli/install.sh | bash

على أجهزة Windows (PowerShell):

irm https://antigravity.google/cli/install.ps1 | iex

سيكتشف هذا النص البرمجي نظام التشغيل والبنية بشكل ديناميكي، وسينزّل أحدث إصدار مجمّع من

agy

الثنائي، واضبط PATH. أعِد تشغيل نافذة الأوامر أو أعِد تحميل إعدادات shell لكي تصبح التغييرات سارية.

efade99623113f1.png

المصادقة

يجب أن يكون لديك مفتاح واجهة برمجة تطبيقات Google AI Studio.

تصدير مفتاح واجهة برمجة التطبيقات:

export GEMINI_API_KEY="your-api-key"

المصادقة باستخدام gcloud:

export GOOGLE_CLOUD_PROJECT="YOUR_PROJECT_ID"
export GOOGLE_CLOUD_LOCATION="YOUR_PROJECT_LOCATION"
gcloud auth application-default login

إعداد بيئة العمل ونشر تطبيق العرض التوضيحي للخدمات المصغّرة

لنستنسخ تطبيق microservices-demo وننشر البنية التحتية والتطبيق من خلال Terraform

يمكنك الآن فتح بيئة التطوير المتكاملة (Visual Studio Code أو IntelliJ أو RubyMine أو غيرها) وفتح المجلد.

# 1. Find an empty directory, and download this repo.
git clone https://github.com/GoogleCloudPlatform/microservices-demo.git
cd microservices-demo/terraform

# 2. Update project ID to your gcloud project ID
sed -i 's/<project_id_here>/YOUR_ACTUAL_PROJECT_ID/g' terraform.tfvars

# 3. Deploy the microservices-demo application in GKE autopilot
# If there is a prompt answer yes and continue. This step can take up to 10 mins for provision gke autopilot cluster and deploy microservices-demo application
terraform init
terraform plan
terraform apply

# 4. Verify the IP address of frontend-service to access the online-boutique application
kubectl get service frontend-external | awk '{print $4}'

# 5. Find an empty directory , and download this repo.
git clone https://github.com/palladius/sre-testing-suite.git
cd sre-testing-suite/test-scenarios/microservices-demo-gke/breakage-scenarios

لاختبار الإعداد، يمكنك الانتقال إلى http://[IP ADDRESS] وتحميل تطبيق online-boutique.

إعداد بيئة العمل لـ sre-antigravity-cli-extension

# 1. Install the SRE Extension plugin globally
git clone https://github.com/gemini-cli-extensions/sre.git ~/.gemini/config/plugins/sre-extension

# 2. Launch the Antigravity CLI (agy)
agy  # This runs the CLI under your current breakage-scenarios folder.
# Login with your corporate or personal account when prompted.

# 3. Within the agy agent prompt, configure your MCP servers and GCP project
Use the gcp-mcp-setup skill to setup my GCP project "<gcp_project_id>" with email jane-doe-sre@credible-company.com

4. الخطوة 1: محاكاة الانقطاع (سيناريوهات الأعطال)

في هذه الخطوة، سنعطّل مجموعة GKE التي تم نشرها عمدًا لمحاكاة مشكلة إنتاجية في العالم الحقيقي. يمكنك الاختيار من بين ثلاثة سيناريوهات (أو تجربة جميع السيناريوهات الثلاثة بالتسلسل):

السيناريو 1: حظر شبكة خدمة الدفع (الوضع العادي/القيادة الذاتية)

يحاكي هذا السيناريو انقطاع الاتصال بين الواجهة الأمامية وخدمة الدفع من خلال تطبيق NetworkPolicy في Kubernetes يعمل كـ "ثقب أسود" للزيارات.

  1. انتقِل إلى مجلد السيناريو: 
    cd breakage1-checkout
  2. تفعيل عملية التجزئة: 
    ./break.sh
    يؤدي ذلك إلى إنشاء NetworkPolicy باسم update-checkout-from-frontend في مساحة الاسم default التي ترفض حركة المرور الواردة إلى checkoutservice ما لم تأتِ من وحدة pod تحمل التصنيف app: frontend-checkout-test (غير المتوفّر).
  3. حاوِل شراء سلع من واجهة Online Boutique الأمامية. ستتوقف صفحة الدفع أو ستعرض الخطأ HTTP 500.

السيناريو 2: طرح إصدار Canary يتضمّن أخطاء (التشغيل التلقائي مع Istio)

يحاكي هذا السيناريو عملية نشر غير صحيحة يتم فيها طرح إصدار يتضمّن أخطاء في الواجهة الأمامية من خلال عملية نشر Canary في Kubernetes.

  1. انتقِل إلى مجلد السيناريو: 
    cd ../breakage2-canary
  2. تفعيل عملية التجزئة: 
    ./break.sh
    يؤدي هذا إلى نشر عملية نشر تجريبية frontend-canary تتضمّن خطأ إملائيًا في متغيّرات البيئة: تم ضبط PRODUCT_CATALOG_SERVICE_ADDR على productcatalogservices:3550 بدلاً من productcatalogservice:3550.
  3. تحميل الصفحة الرئيسية لواجهة المستخدم سيتعذّر ذلك أحيانًا (حسب أوزان التوجيه) لأنّ خدمة الإصدار التجريبي لا يمكنها حلّ مشكلة كتالوج المنتجات.

السيناريو 3: حظر مجموعة جدار الحماية في السحابة الخاصة الافتراضية (VPC)

يحاكي هذا السيناريو خطأً في إعداد جدار حماية شبكة VPC يحظر جميع حركة البيانات الواردة إلى مجموعة GKE.

  1. انتقِل إلى مجلد السيناريو: 
    cd ../breakage3-firewall
  2. تفعيل عملية التجزئة: 
    ./break.sh
    يؤدي ذلك إلى إنشاء قاعدة جدار حماية على مستوى شبكة VPC باسم frontend-ingress-v2 مع priority=1 والإجراء DENY الذي يستهدف الزيارات الواردة إلى المنافذ 80 و443 و8080.
  3. سيتعذّر الوصول إلى الموقع الإلكتروني Online Boutique تمامًا، وستنتهي مهلة الطلبات.

5- الخطوة 2: التحقيق في الانقطاع باستخدام إضافة SRE

بعد أن تعذّر الوصول إلى التطبيق، لنبدأ التحقيق باستخدام مساعد واجهة سطر الأوامر (Antigravity CLI).

  1. ارجع إلى مجلد سيناريوهات الأعطال الرئيسية وشغِّل أداة CLI المساعدة: 
    cd ..
agy
  2. اطلب من المساعد إجراء عملية رصد للبنية الأساسية وفحص تشخيصي: 
    Investigate my GKE cluster for outages. Are all services healthy?
  3. الإجراءات التي يتّخذها الوكيل:
    • يؤدي ذلك إلى تفعيل مهارتَي investigation-entrypoint وgcp-playbooks.
    • تعرض هذه الأداة وحدات Kubernetes pods وعمليات النشر والخدمات لتحديد الأهداف التي تعذّر الوصول إليها.
    • يفحص هذا البرنامج سياسات الشبكة (في السيناريو 1) أو إعدادات النشر (في السيناريو 2) أو قواعد جدار الحماية (في السيناريو 3).
  4. بالنسبة إلى السيناريو 1، يجب أن يبلّغ الوكيل عن: 🔴 تم تحديد المشكلة: تعمل وحدة NetworkPolicy باسم update-checkout-from-frontend على عزل وحدات checkoutservice.
  5. في السيناريو 2، يجب أن يبلّغ الوكيل عن: 🔴 تم تحديد المشكلة: تم إعداد عملية النشر frontend-canary باستخدام نقطة نهاية خدمة غير صالحة productcatalogservices:3550 بدلاً من productcatalogservice:3550.
  6. بالنسبة إلى السيناريو 3، يجب أن يبلّغ البرنامج عن: 🔴 تم تحديد المشكلة: ترفض قاعدة جدار حماية في شبكة VPC frontend-ingress-v2 الزيارات الواردة على المنافذ 80 و443 و8080.

6. الخطوة 3: التخفيف من تأثير الانقطاع وإصلاحه

لنستخدِم نمط Safe Executor في واجهة سطر الأوامر لمعالجة الانقطاع.

  1. اطلب من مساعد واجهة سطر الأوامر اقتراح حلّ وتطبيقه: 
    Propose a fix for the outage and apply it.
  2. مثال على استخدام Safe Executor:
    • قبل تنفيذ اقتراحات الأوامر، تجري إضافة SRE Extension تدقيقًا للأمان باستخدام مهارة safe-sre-investigator.
    • سيُظهر لك الأمر الدقيق الذي ينوي تنفيذه ويقيّم مستوى الخطورة (مثل منخفض أو متوسط أو مرتفع).
    • بالنسبة إلى السيناريو 1، سيقترح ما يلي: 
      kubectl delete networkpolicy update-checkout-from-frontend
    • بالنسبة إلى السيناريو 2، سيتم اقتراح ما يلي: 
      kubectl delete deployment frontend-canary
    • بالنسبة إلى السيناريو 3، سيقترح ما يلي: 
      gcloud compute firewall-rules delete frontend-ingress-v2 --quiet
  3. أكِّد تنفيذ الأمر عندما يطلب منك ذلك واجهة سطر الأوامر.
  4. تأكَّد من أنّ الموقع الإلكتروني عاد إلى العمل ويعمل بشكل كامل من خلال إعادة تحميل الصفحة الرئيسية لمتجر Online Boutique.
  5. في shell، يمكنك تنفيذ النص البرمجي المناسب للتحقّق من السيناريو للتأكّد من سلامة النظام: 
    ./breakage1-checkout/check.sh
# or ./breakage2-canary/check.sh
# or ./breakage3-firewall/check.sh

7. الخطوة 4: إنشاء تقرير ما بعد الوفاة عن الحادث

يُعدّ توثيق الحادث جزءًا أساسيًا من دورة حياة هندسة موثوقية الموقع (SRE) لكي يتمكّن الفريق من الاستفادة من التجربة. لنعمل على أتمتة هذه العملية باستخدام مهارة postmortem-create.

  1. في مساعد واجهة سطر الأوامر، اطلب كتابة مستند التحليل بعد الوفاة: 
    Create a postmortem for the checkout service network policy outage.
  2. سيجمع موظّف الدعم تفاصيل حول ما يلي:
    • وقت بدء الحادث (تم استرداده من سجلّ/سجلّات أوامر واجهة سطر الأوامر).
    • السبب الجذري (سياسة NetworkPolicy التي تحظر الوصول)
    • الإجراءات المتّخذة للحدّ من تأثيرها
  3. سيكتب ملف Markdown جديدًا باسم postmortem.md في مساحة عملك.
  4. افتح postmortem.md لمراجعة التفاصيل. ستظهر لك أقسام مثل:
    • ملخّص الحادث
    • الجدول الزمني للأحداث
    • تحليل السبب الجذري (RCA)
    • الإجراءات المطلوبة / التدابير الوقائية

8. الخطوة 5: إضافة رسومات بيانية للمقاييس المستندة إلى بيانات واقعية

لإعداد تقرير احترافي عن الحادثة، نحتاج إلى دليل مرئي على وقوعها. سنستخدم مهارة monitoring-graphs لجلب بيانات السلسلة الزمنية من Google Cloud Monitoring (GCM) وإنشاء رسم بياني بتنسيق PNG يعرض الارتفاع المفاجئ في عدد الأخطاء.

  1. اطلب من أداة CLI المساعدة إنشاء الرسم البياني وإضافته إلى تقرير ما بعد الوفاة: 
    Query GCM for frontend HTTP request error rates over the last 1 hour, generate a line chart, and embed it into postmortem.md.
  2. نظرة من الداخل:
    • يستدعي الوكيل نص monitoring-graphs Python البرمجي لطلب البحث في Cloud Monitoring.
    • يستردّ هذا الإجراء المقاييس (مثل kubernetes.io/container/restart_count أو loadbalancing.googleapis.com/https/request_count).
    • يرسم الرسم البياني باستخدام matplotlib ويحفظه باسم incident_metrics.png.
    • يعدّل هذا الإجراء ملف postmortem.md من خلال إدراج رابط صورة: 
      ![Incident Metric Graph](incident_metrics.png)
  3. افتح ملف incident_metrics.png الذي تم إنشاؤه للاطّلاع على الرسم البياني الذي يوضّح اللحظات الدقيقة التي توقفت فيها المجموعة عن العمل والوقت الذي عادت فيه الزيارات إلى معدّلها الطبيعي.

9- الخطوة 6: التنظيف

لضمان عدم تحمّل حسابك على Google Cloud رسومًا غير ضرورية، لننظّف البنية الأساسية التي تم نشرها.

  1. انتقِل إلى مجلد Terraform: 
    cd ../../microservices-demo/terraform
  2. نفِّذ أمر الإلغاء: 
    terraform destroy -auto-approve
  3. تأكَّد من حذف جميع موارد Google Cloud Platform GKE بنجاح.

10. تهانينا!

لقد أكملت Codelab حول التحقيق في حالات تعذُّر توفّر مجموعة GKE وتعطّلها.

المواضيع التي تم تناولها:

  • تم نشر العرض التوضيحي لخدمة Online Boutique المصغّرة المكوّنة من 10 مستويات على GKE.
  • محاكاة ثلاث حالات انقطاع لخدمة SRE في العالم الحقيقي (رفض سياسة الشبكة، وطرح إصدار تجريبي غير مستقر، ورفض قاعدة جدار الحماية في شبكة VPC)
  • استخدمت "إضافة هندسة موثوقية الموقع" (SRE) في Antigravity CLI لاكتشاف حالات الانقطاع وتشخيصها.
  • استخدام نمط Safe Executor لمراجعة أوامر الإصلاح وتنفيذها
  • أنشأتُ تقريرًا احترافيًا بعد الوفاة بتنسيق Markdown.
  • تم الاستعلام عن مقاييس Cloud Monitoring لإنشاء رسم بياني للحادثة مستند إلى بيانات واقعية وتضمينه تلقائيًا.

لمزيد من التفاصيل حول توسيع نطاق وكيل واجهة سطر الأوامر، يُرجى الاطّلاع على صفحة SRE Extension على GitHub.