مهنة SRE: العمل الروتيني وSLO ومعدّل استهلاك ميزانية الأخطاء

الهدف

فهم ما تنتظره الشركات من مهندس SRE (Site Reliability Engineering، هندسة موثوقية المواقع)، وقياس العمل الروتيني (toil، أي العمل اليدوي الذي لا ينتهي أبدًا)، وقيادة قرارات النشر بـ معدّل استهلاك ميزانية الأخطاء (burn rate)، بما يتجاوز الحساب البسيط للميزانية الذي رأيناه في دورة المراقبة (Supervision).

أهم النقاط

• يطبّق الـ SRE أساليب هندسة البرمجيات على التشغيل: فهو يقيس الموثوقية، ويؤتمتها، ويتفاوض بشأنها مع فرق المنتج.
• العمل الروتيني (toil) هو العمل اليدوي، المتكرر، القابل للأتمتة، الخالي من قيمة دائمة، والذي يكبر مع حجم الحركة (الترافيك). نقيسه ونضع له سقفًا (غالبًا 50 % من الوقت).
• ميزانية الأخطاء لا فائدة منها إن لم تكن مرتبطة بـ سياسة مكتوبة: من يقرّر التجميد، وانطلاقًا من أي عتبة، ومع أي استثناءات.
• معدّل الاستهلاك (burn rate) يبيّن بأي سرعة نحرق الميزانية: 1 = سننتهي منها بالضبط في آخر النافذة الزمنية؛ 14.4 = سنحرقها كلها في 50 ساعة.
• ننبّه على أساس الـ burn rate باستعمال نافذتين (طويلة لليقين، وقصيرة لمعرفة أن المشكلة ما زالت مستمرة)، لا على مجرد معدّل أخطاء لحظي.

1. ما يفعله الـ SRE يوميًا

في شركة خدمات رقمية (ESN) أو شركة تقنية كبيرة، يغطي المسمّى « SRE » غالبًا المهامّ نفسها:

الـ SRE ليس « المسؤول الذي يفعل كل شيء »: فهو يقضي جزءًا مهمًا من وقته في البرمجة (سكربتات، أدوات، أتمتة) حتى لا يكبر عبء التشغيل بالوتيرة نفسها التي تكبر بها الخدمة.

SRE وDevOps ومدير الأنظمة

• DevOps ثقافة: فرق التطوير والتشغيل تتقاسم الأهداف والأدوات.
• SRE طريقة ملموسة لتطبيقها، بالأرقام (SLO، الميزانية، العمل الروتيني).
• مدير الأنظمة يبقى لا غنى عنه؛ والـ SRE يحتفظ بمهاراته (Linux، الشبكات، التخزين) ويضيف إليها القياس والبرمجة.

2. العمل الروتيني: نقيسه لنتخلص منه

تُعدّ المهمة عملًا روتينيًا إذا استوفت أغلب هذه الشروط:

• يدوية: شخص ما يكتب الأوامر؛
• متكررة: سبق إنجازها الأسبوع الماضي؛
• قابلة للأتمتة: يمكن لآلة أن تنجزها؛
• تفاعلية: يطلقها تنبيه أو تذكرة (ticket)، لا مشروع؛
• بلا قيمة دائمة: بعد إنجازها، لا تصبح الخدمة أفضل مما كانت عليه؛
• متناسبة مع الحركة: ضعف عدد الزبائن يعني ضعف العمل.

ليست عملًا روتينيًا: كتابة post-mortem، تصميم تنبيه، أتمتة مهمة، اجتماعات التخطيط (هذه تكاليف عامة، تُراقَب بطريقة أخرى).

القياس

نسجّل الوقت المستغرق خلال أسبوع أو أسبوعين، ثم نحسب:

# categorie;nature;minutes
awk -F';' 'NR>1 {total+=$3} NR>1 && $2=="toil" {labeur+=$3}
           END {printf "Labeur : %d min sur %d (%.0f %%)\n", labeur, total, 100*labeur/total}' semaine.csv

# الفئات الأكثر كلفة: هي الأولى التي تجب أتمتتها
awk -F';' '$2=="toil" {m[$1]+=$3} END {for (c in m) print m[c], c}' semaine.csv | sort -rn | head -3

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

اختيار ما نؤتمته

المرشّح الجيد يجمع بين التكرار والمدة والخطر:

gain mensuel ≈ fréquence par mois × minutes par exécution
             + coût d'une erreur humaine × probabilité de se tromper

أي: الربح الشهري ≈ عدد المرات في الشهر × الدقائق لكل تنفيذ + كلفة الخطأ البشري × احتمال الوقوع فيه.

إعادة تشغيل الـ API يدويًا 12 مرة في الشهر (30 دقيقة في كل مرة، في الثالثة صباحًا) تستحق فعلًا يومين من التطوير. أما نسخ شهادة مرة واحدة في السنة، فأقل بكثير.

3. SLO: الذهاب أبعد من حساب الميزانية

وضعت دورة المراقبة الأسس: SLI وSLO وSLA وميزانية الأخطاء بالدقائق. ومهنة الـ SRE هي استعمالها لاتخاذ القرار.

اختيار SLI جيد

يجب أن يعكس الـ SLI ما يعيشه المستخدم. بعض الاختيارات الشائعة:

القياس عند موزّع الحِمل يرى الأخطاء التي لا يسجّلها التطبيق أصلًا (عملية متوقفة، انتهاء مهلة الانتظار). والقياس بـ مجسّ اصطناعي (زبون وهمي يمرّر طلبية كل دقيقة) يرى الأعطال حتى عندما لا يشتري أحد.

سياسة ميزانية الأخطاء

ميزانية بلا قاعدة مكتوبة تُثير الخلافات عند كل حادث. والسياسة تكفيها صفحة واحدة:

Service : API de paiement      SLO : 99,9 % de requêtes non 5xx, 30 jours glissants
Si le budget consommé dépasse 100 % :
  - gel des nouvelles fonctionnalités jusqu'à revenir sous le SLO
  - seules partent en production les corrections de bugs et de fiabilité
  - le prochain sprint comporte au moins un chantier de fiabilité
Si un seul incident consomme plus de 20 % du budget : post-mortem obligatoire
Exception : correctif de sécurité urgent (décision du responsable technique)
Arbitrage en cas de désaccord : direction technique

بعبارة واضحة: إذا تجاوزت الميزانية المستهلَكة 100 %، تُجمَّد الميزات الجديدة إلى أن تعود الخدمة تحت الـ SLO، ولا يُنشَر في الإنتاج إلا إصلاح الأعطال وتحسينات الموثوقية، ويتضمن الـ sprint التالي ورشة موثوقية واحدة على الأقل؛ وكل حادث واحد يستهلك أكثر من 20 % من الميزانية يستوجب post-mortem؛ والاستثناء هو التصحيح الأمني العاجل (بقرار من المسؤول التقني)؛ وعند الخلاف تحكم الإدارة التقنية.

تُوقَّع هذه السياسة بهدوء من طرف فريقَي المنتج والتقنية، ولا يُتفاوَض بشأنها في خضمّ عطل.

4. معدّل الاستهلاك (burn rate)

الميزانية على 30 يومًا تقول كم استهلكنا. والـ burn rate يقول بأي سرعة.

burn rate = taux d'erreur observé / taux d'erreur autorisé par le SLO

SLO 99,9 %  →  taux autorisé = 0,1 % = 0,001
Dernière heure : 1 728 erreurs sur 120 000 requêtes = 1,44 %
burn rate = 0,0144 / 0,001 = 14,4

أي: burn rate = معدّل الأخطاء الملاحَظ / معدّل الأخطاء المسموح به في الـ SLO. مع SLO قدره 99.9 %، المعدّل المسموح به هو 0.001؛ و1 728 خطأً من أصل 120 000 طلب تساوي 1.44 %، إذن الـ burn rate يساوي 14.4.

الوقت المتبقي قبل استنفاد ميزانية جديدة: 720 h / burn rate.

التنبيه على الـ burn rate بنافذتين

التنبيه على « معدّل أخطاء > 0.1 % لمدة 5 دقائق » يوقظ المداوم من أجل ذروات لا أهمية لها. والممارسة المجرَّبة تجمع بين نافذة طويلة (الاستهلاك معتبَر) ونافذة قصيرة (ما زال مستمرًا، وإلا فإن التنبيه ينتهي بسرعة):

في PromQL (دورة المراقبة)، يُكتب السطر الأول بشرطين مربوطين بـ and: نسبة الأخطاء على [1h] و على [5m] تتجاوز كلتاهما 14.4 * 0.001. المهم هنا هو طريقة التفكير، لا الصياغة.

الحساب يدويًا أثناء حادث

أثناء الحادث، لا تتوفر دائمًا لوحة القيادة: يكفي سجلّ الوصول (access log).

# سجلّ موزّع الحِمل: الحقل التاسع هو رمز HTTP
total=$(wc -l < acces.log)
erreurs=$(awk '$9 ~ /^5/' acces.log | wc -l)
awk -v e="$erreurs" -v t="$total" 'BEGIN {printf "taux=%.4f burn=%.1f\n", e/t, (e/t)/0.001}'

5. حالة واقعية: متجر MasterLinux خلال فترة التخفيضات

الجمعة، العاشرة صباحًا. تُظهر لوحة القيادة أن 60 % من الميزانية الشهرية قد استُهلكت. لا أحد يقلق: يتبقى 40 %. في العاشرة والنصف، يرتفع الـ burn rate على ساعة إلى 14.4، وعلى 5 دقائق إلى 16: ينطلق التنبيه. يكتشف المداوم أن وسيلة دفع جديدة تُرجع أخطاء 503 لزبون من كل سبعين. بهذه الوتيرة، ستذهب الـ 40 % المتبقية في 20 ساعة، قبل نهاية التخفيضات. يتم الرجوع إلى النسخة السابقة في العاشرة وخمسين دقيقة. ويوم الاثنين، تُطبَّق السياسة: ميزانية مستهلَكة بنسبة 104 %، تجميد الميزات الجديدة، ويُخصَّص الأسبوع لاختبارات الحِمل على وسيلة الدفع.

لولا الـ burn rate، لرأى الفريق « 60 % مستهلَكة، كل شيء على ما يرام » إلى أن ينكسر الـ SLO.

أخطاء متكررة

• تقدير العمل الروتيني « بالإحساس »: دون تسجيل للوقت، يستهين كل واحد بمهامه اليدوية. قِس لمدة أسبوعين قبل أن تقرّر.
• SLO بنسبة 100 %: مستحيل الالتزام به ومُشِلّ (لا يعود أي تغيير مسموحًا). استهدف ما يلاحظه المستخدمون فعلًا.
• الخلط بين الميزانية المستهلَكة والـ burn rate: 60 % مستهلَكة مع burn rate قدره 0.5 وضع هادئ؛ و10 % مستهلَكة مع burn rate قدره 50 عطل جارٍ.
• سياسة تجميد لا تُطبَّق أبدًا: إذا رُفع التجميد دائمًا « استثنائيًا »، لم يعد للـ SLO أي معنى.

التطبيق العملي (Lab)

على Ubuntu 24.04، داخل /root/sre، ستقوم بما يلي:

1. حساب نسبة العمل الروتيني للفريق على أسبوع؛
2. تحديد فئة العمل الروتيني التي يجب أتمتتها أولًا؛
3. حساب الـ burn rate للساعة الأخيرة؛
4. استنتاج الوقت المتبقي قبل استنفاد ميزانية جديدة؛
5. تطبيق سياسة ميزانية الأخطاء على نافذة 30 يومًا.

اختبار قصير

1. اذكر أربع خصائص للعمل الروتيني.
2. لماذا نضع سقفًا للعمل الروتيني في حدود 50 % من وقت الـ SRE؟
3. SLO قدره 99.9 % و0.6 % من الأخطاء خلال الساعة الأخيرة: كم يساوي الـ burn rate؟
4. لماذا يستعمل تنبيه الـ burn rate نافذة طويلة و نافذة قصيرة؟
5. من يجب أن يوقّع سياسة ميزانية الأخطاء، ومتى؟