هندسة موثوقية المواقع (SRE)

الجهد الروتيني والأتمتة

18 دقيقة الدرس 4 من 29

الجهد الروتيني والأتمتة

قدّم كتاب Google SRE كلمة صدى لدى كل مهندس عمليات قرأها: Toil (الجهد الروتيني). ليس لأنها كانت جديدة — فكل فريق عمليات كان يغرق فيها لسنوات — بل لأن تسميتها أعطت الفرق الإذن بمعالجتها كمشكلة تستحق الحل المنهجي. يُعرّف هذا الدرس الجهد الروتيني بدقة، ويشرح سبب وجود قاعدة 50% عند Google وكيف تُطبَّق، ويعرض الأنماط العملية للأتمتة التي تستخدمها فرق SRE من الدرجة الأولى للقضاء عليه من المنبع.

تعريف الجهد الروتيني: ما هو وما ليس كذلك

الجهد الروتيني ليس مجرد "عمل لا أحبه." له تعريف دقيق وتشغيلي يميزه عن العمل الهندسي ذي القيمة. الجهد الروتيني هو العمل الذي يتصف بما يلي:

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

أمثلة على الجهد الروتيني في بيئة إنتاج ناضجة: إعادة تشغيل الـ pods التي تُقتل بسبب نفاد الذاكرة يدوياً، تدوير بيانات الاعتماد بالنسخ واللصق في مدير الأسرار، توفير قرائن قاعدة البيانات الجديدة عبر واجهة رسومية في كل مرة تطلبها فريق خدمة، الرد على رسائل Slack التي تقول "هل يمكنك التحقق من سبب بطء الخدمة X؟"، تقليص قرص يمتلئ كل ثلاثة أيام بجدول متوقع، ومراجعة جدول انتهاء صلاحية الشهادات كل اثنين.

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

التكلفة المعرفية للجهد الروتيني مقدَّرة بأقل من قيمتها الحقيقية. الجهد الروتيني لا يتعلق فقط بالدقائق التي تُنفق في إعادة تشغيل pod. يتعلق بتكلفة التبديل السياقي: كان المهندس منغمساً في عمل تصميمي عميق، جاء نداء تنبيه، أمضى 12 دقيقة في مهمة يدوية، ثم احتاج 20 دقيقة لاستعادة تركيزه. على نطاق واسع، فريق SRE يتلقى 15 مهمة يدوية يومياً لا يخسر 15 × 12 دقيقة من العمل — بل يخسر معظم طاقته الإبداعية الهندسية في استعادة التركيز.

قاعدة 50%: وقت الهندسة يخص الهندسة

يُلزم نموذج SRE في Google بألا يُنفق أي مهندس SRE أكثر من 50% من وقت عمله في الجهد الروتيني. يجب إنفاق الـ 50% المتبقية في أعمال المشاريع: الأتمتة، تحسينات الموثوقية، أدوات الهندسة، وتخطيط السعة — العمل الذي يُقلّص الجهد الروتيني المستقبلي بصفة دائمة أو يُحسّن صحة الخدمة.

هذا ليس طموحاً مرناً. إنه عقد تشغيلي بين فرق SRE والفرق المنتجة التي تدعمها. إذا تجاوزت فرق SRE باستمرار حد الجهد الروتيني البالغ 50%:

يُصعّد مدير SRE إلى قيادة هندسة المنتج — فريق المنتج يملك الإصلاح.
تتوقف فرق SRE مؤقتاً عن قبول خدمات جديدة في محفظتها حتى تُعالج السبب الجذري.
في الحالات القصوى، تُعيد فرق SRE الخدمة إلى فريق المنتج ليشغلها بنفسه (آلية "الإعادة").

قاعدة 50% موجودة بسبب حقيقة رياضية: إذا نما جهد SRE الروتيني خطياً مع نمو الخدمة وأنفق المهندسون 100% من وقتهم فيه، ستحتاج توظيف مهندس SRE لكل N خادم أو طلب. هذا هو نموذج العمليات الذي كانت Google تحاول الهروب منه. حد الـ 50% يُجبر على الاستثمار في الأتمتة قبل أن يُطغي الجهد الروتيني للخدمة على الفريق.

حين يتجاوز الجهد الروتيني 50% من وقت SRE، تُستهلك الطاقة الهندسية وتتراكم الموثوقية سلبياً. البقاء تحت الحد متطلب هيكلي لا مجرد تفضيل.

قياس الجهد الروتيني: لا يمكنك تقليل ما لا تستطيع إحصاءه

قبل أتمتة أي شيء، قِس الجهد الروتيني. تتتبع فرق SRE الجهد الروتيني بمنهجية. كحد أدنى، ضع أدوات قياس في دورة التأهب لالتقاط ثلاث نقاط بيانات لكل تذكرة/نداء تنبيه: الفئة (نوع المهمة)، الوقت المُنفَق (بما في ذلك تكلفة التبديل السياقي)، وهل هي قابلة للأتمتة. تفعل معظم الفرق ذلك بوضع تسمية في نظام التذاكر ومراجعة أسبوعية:

# نموذج استعلام مراجعة الجهد الروتيني الأسبوعية — باستخدام PagerDuty API:
# عدد الحوادث حسب الخدمة ونمط العنوان للأيام الثلاثين الماضية

curl -s --header "Authorization: Token token=YOUR_PD_TOKEN" \
  "https://api.pagerduty.com/incidents?since=2025-05-01&until=2025-06-01&limit=100" \
  | jq '[.incidents[] | {title: .title, service: .service.summary, created: .created_at}]' \
  | jq 'group_by(.title) | map({title: .[0].title, count: length}) | sort_by(-.count) | .[0:15]'

# لأدوات التأهب المدعومة بـ Prometheus، تتبع ساعات الجهد الروتيني بـ gauge:
# oncall_toil_hours_total{team="sre-platform", category="manual-restart", automatable="true"} 8.5
# تنبيه: إذا تجاوز toil_ratio (toil_hours / total_hours) 0.5 خلال نافذة أسبوعين، أرسل تنبيهاً لمدير SRE.

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

أتمتة الجهد الروتيني: الأنماط والأدوات

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

1. تحويل دليل التشغيل إلى بوت. دليل تشغيل يقول "إذا انتهت ذاكرة الخدمة X، اتصل عبر SSH وأعد تشغيل الـ pod" هو بوت ينتظر أن يُكتب. التطور: دليل تشغيل (يدوي كامل) ← سكريبت يُشغّله المهندس المناوب يدوياً ← سكريبت يُشغَّل تلقائياً بواسطة التنبيه ← لا تنبيه أصلاً لأن الحالة تُصلح نفسها. تتوقف معظم الفرق عند الخطوة الثانية. فرق SRE تندفع نحو الخطوة الثالثة أو الرابعة.

2. متحكمات Kubernetes ذاتية الإصلاح. في بيئات Kubernetes، المكان الصحيح لترميز منطق الاسترداد هو متحكم مخصص أو Operator، لا دليل تشغيل المناوب. إذا كان pod يُقتل باستمرار بسبب نفاد الذاكرة عند بصمة ذاكرة متوقعة، فالإصلاح الصحيح هو توصية VPA (Vertical Pod Autoscaler) مُطبَّقة تلقائياً — لا زيادة يدوية أسبوعية. إذا تدهور مجموعة عقد، يجب على Cluster Autoscaler تفريغها واستبدالها دون تدخل بشري.

3. المعالجة التلقائية المدفوعة بالأحداث مع Lambda/Cloud Functions. CloudWatch Alarm ← EventBridge Rule ← Lambda function تستدعي AWS API لاتخاذ إجراء تصحيحي. يُستخدم هذا النمط على نطاق واسع في تجاوز فشل RDS، واسترداد EC2، وإعادة تشغيل مهام ECS. تُسجّل الدالة كل إجراء تتخذه في CloudTrail؛ مسار التدقيق تلقائي.

4. محركات السياسات كمزيلات للجهد الروتيني. قدر مفاجئ من الجهد الروتيني يأتي من البشر الذين يُطبّقون السياسات يدوياً: "تأكد من تفعيل الإصدار في جميع حزم S3"، "تأكد من أن جميع وظائف Lambda الجديدة لها DLQ." هذه قواعد محددة. ادفعها إلى محرك سياسات (AWS Config Rules مع المعالجة التلقائية، OPA/Gatekeeper لـ Kubernetes، HashiCorp Sentinel لـ Terraform) ويصبح التطبيق مستمراً وتلقائياً.

# نمط: إعادة تشغيل خدمة متعطلة باستخدام Kubernetes liveness probe
# (أفضل: استخدام Operator مناسب؛ هذا يوضح المفهوم ببساطة)

# 1. Kubernetes liveness probe — kubelet يعيد تشغيل الحاوية تلقائياً:
# في مواصفات Deployment:
#   livenessProbe:
#     httpGet:
#       path: /healthz
#       port: 8080
#     initialDelaySeconds: 15
#     periodSeconds: 10
#     failureThreshold: 3

# 2. AWS Lambda للمعالجة التلقائية عبر EventBridge (كود Python توضيحي):
# المشغّل: CloudWatch Alarm "ECS task count < desired"
import boto3

def handler(event, context):
    ecs = boto3.client('ecs')
    cluster = event['detail']['clusterArn']
    service = event['detail']['serviceArn']
    # إجبار نشر جديد لاستبدال المهام غير الصحية
    ecs.update_service(
        cluster=cluster,
        service=service,
        forceNewDeployment=True
    )
    print(f"Forced redeployment: {service}")

# 3. AWS Config للمعالجة التلقائية — تطبيق إصدار S3:
# aws configservice put-remediation-configurations \
#   --remediation-configurations '[{
#     "ConfigRuleName": "s3-bucket-versioning-enabled",
#     "TargetType": "SSM_DOCUMENT",
#     "TargetId": "AWS-ConfigureS3BucketVersioning",
#     "Parameters": {
#       "BucketName": {"ResourceValue": {"Value": "RESOURCE_ID"}},
#       "VersioningState": {"StaticValue": {"Values": ["Enabled"]}}
#     },
#     "Automatic": true,
#     "MaximumAutomaticAttempts": 3,
#     "RetryAttemptSeconds": 60
#   }]'

فخ الأتمتة: حين تُولّد الأتمتة جهداً روتينياً جديداً

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

يجب أن تمتلك الأتمتة وضع التشغيل الجاف (dry-run). كل بوت معالجة يجب أن يدعم علامة --dry-run تسجّل ما ستفعله دون تنفيذ إجراء. يسمح هذا بالاختبار الآمن قبل تفعيل التنفيذ المباشر. البوتات المنشورة بدون وضع التشغيل الجاف تدمر الإنتاج.
يجب أن تكون الأتمتة مستقلة عن الحالة (idempotent). إذا أُطلقت المعالجة ثلاث مرات متتالية بسبب تنبيه متذبذب، يجب أن تكون الحالة النهائية ذاتها كما لو أُطلقت مرة واحدة. الأتمتة غير المستقلة (مثل الإضافة إلى ملف تكوين في كل تشغيل) أسوأ من الجهد الروتيني الذي حلت محله.
كل إجراء آلي يجب أن يكون مُسجَّلاً وقابلاً للتدقيق. حين يلمس نظام آلي الإنتاج، يجب أن يكون مسار التدقيق كاملاً كما لو فعله إنسان. سجّل الإجراء والمشغّل والطابع الزمني والنتيجة في CloudTrail أو مستقبل سجلات منظم أو كليهما.

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

قياس تقليص الجهد الروتيني: إغلاق الحلقة

استثمارات الأتمتة تحتاج إلى تبرير والتحقق من صحتها. بعد نشر أتمتة، قِس: كم تدخلاً يدوياً أسبوعياً أزالت هذه الأتمتة؟ ما ساعات الهندسة المُوفَّرة فصلياً؟ هل تحسّنت نسبة الجهد الروتيني إلى الهندسة؟ هذه الأرقام تدخل في المراجعة الفصلية لفريق SRE وتُبرر مزيداً من الاستثمار.

نمط عملي لمقاييس Prometheus لتتبع فاعلية الأتمتة:

# مقاييس Prometheus لتتبع تقليص الجهد الروتيني عبر الزمن.
# اعرض هذه المقاييس من بوتات المعالجة / أدوات التأهب.

# عداد: عدد المرات التي اتخذت فيها الأتمتة إجراءً (يحل محل مهمة يدوية)
# oncall_automation_actions_total{action="pod_restart", service="payments", result="success"} 47
# oncall_automation_actions_total{action="pod_restart", service="payments", result="failure"} 2

# Gauge: نسبة الجهد الروتيني الحالية (تُحدَّث أسبوعياً من بيانات التدقيق)
# oncall_toil_ratio{team="sre-platform"} 0.38

# Histogram: الوقت المُوفَّر لكل إجراء آلي (بالدقائق)
# oncall_toil_minutes_saved_total{action="pod_restart"} 564

# PromQL: تنبيه إذا تجاوزت نسبة الجهد الروتيني 50% خلال نافذة أسبوعين
# ALERT ToilCapExceeded
#   IF avg_over_time(oncall_toil_ratio[14d]) > 0.50
#   FOR 0m
#   LABELS { severity="warning" }
#   ANNOTATIONS { summary="SRE team {{ $labels.team }} toil ratio {{ $value | humanizePercentage }} exceeds 50% cap" }

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