الأمل ليس إستراتيجية: 7 مبادئ لهندسة موثوقية الموقع (SRE)

هندسة موثوقية الموقع، أو SRE، هو نهج يتعامل مع مشكلات العمليات كما لو كانت مشكلات برمجية. أطلق عليه هذا الاسم وشرحه Ben Treynor Sloss، وهو مهندس في شركة Google، في عام 2003. بصفته تخصصًا، تهدف هندسة موثوقية الموقع (SRE) إلى الحفاظ على توافر نظام معين وأدائه وكفاءته.

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

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

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

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

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

تتضمن المبادئ السبعة لهندسة موثوقية الموقع ما يلي:    

• احتواء المخاطر
• أهداف مستوى الخدمة
• التخلص من الأعمال الشاقة
• المراقبة
• الأتمتة
• هندسة الإصدارات
• البساطة

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

في هندسة موثوقية الموقع، تُفهم المخاطر في شكل سلسلة متصلة، حيث يصبح الحد من المخاطر أكثر صعوبة وتكلفة بشكل كبير كلما اقتربنا من الموثوقية التامة بنسبة 100%. وتُعد محاولة الانتقال من نسبة 99.99% إلى 99.999% في الموثوقية أكثر صعوبة من الانتقال من 80% إلى 99%. تقلل الموارد اللازمة للاقتراب من نسبة 100% من قدرة فريق التطوير على أداء مهام أخرى، مثل ابتكار مزايا وتحديثات جديدة. وبدلاً من ذلك، يكون لدى الفريق ميزانيات للأخطاء لتمثيل الكميات المقبولة من الفشل.

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

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

يجب أن يعمل فريق هندسة موثوقية الموقع على تقييم كل خدمة وتحديد المستوى المقبول من عدم الموثوقية. ما فترة التعطل المسموح بها؟ هل لأنواع الأعطال المختلفة، الناشئة عن الأسباب الأساسية المختلفة، تأثيرات مختلفة في تجربة المستخدم؟ كم ستكون تكلفة تجاوز ذلك (من حيث العمالة والأموال)؟ أين التوازن؟

يُعد تحديد الأهداف وقياس مدى فعالية تحقيق هذه الأهداف وسبب تحقيقها أمرًا مهمًا لفريق هندسة موثوقية الموقع. هدف مستوى الخدمة، أو SLO، هو هدف محدد وقابل للقياس يمثل مستوى الجودة الذي حدده فريق هندسة موثوقية الموقع كهدف. يمكن أن تتخذ أهداف مستوى الخدمة هذه شكل مقاييس مختلفة، ولكن التوافر ومعدل الاستعلام ومعدل الخطأ ووقت الاستجابة هي الأكثر شيوعًا.

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

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

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

يؤكد مبتكرو هندسة موثوقية الموقع على نقطة أن تعريف "العمل الشاق" هو نوع من المهام يتداخل مع العمل، ولكنه مختلف عنه. فالعمل الشاق هو مهام العمل اليدوية التي تتزايد بشكل خطي، والتي عادةً ما تكون يدوية ومتكررة، والتي غالبًا ما يمكن إنجازها عن طريق الأتمتة.

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

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

أحد أهم أجزاء هندسة موثوقية الموقع هو المراقبة: استخدام أدوات لتقييم المزايا الأساسية وأداء النظام وتحليلهم وتحسينهم باستمرار. وغالبًا ما تتضمن هذه المزايا الأساسية ما يشار إليه باسم "الإشارات الذهبية الأربع" للمراقبة، وهي ما يلي:

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

حركة المرور: ما مقدار الضغط أو الطلب على الخدمة؟ ستختلف الوحدات المحددة؛ ربما تكون عدد مرات زيارة الصفحات، وربما عدد المعاملات، وربما عدد طلبات HTTP.

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

التشبع: في الأساس، التشبع هو مقياس لمدى قرب الخدمة من بلوغ السعة القصوى. يُعد فهم التشبع أمرًا مهمًا لأن بعض الخدمات ستبدأ بالفشل، أو ستبدأ في التباطؤ أو إنتاج المزيد من الأخطاء، عندما تقترب من التشبع بنسبة 100%.

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

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

يمكن أن تكون الأتمتة ذات قيمة خاصة في تحقيق الأهداف التالية:

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

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

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

وبالطبع، توجد أيضًا مخاطر كامنة في أي عملية أتمتة. ويشمل ذلك ما يلي:

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

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

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

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

تتضمن هندسة الإصدارات، كتخصص، العديد من المبادئ الأساسية. ويشمل ذلك ما يلي:

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

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

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

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

يركز جزء كبير من هندسة موثوقية الموقع على البساطة. وصف Max Luebbe من شركة Google البرمجيات بأنها "ديناميكية وغير مستقرة بطبيعتها". ومع أخذ ذلك في الحسبان، تُعد البساطة هي المفتاح لتقليل المشكلات المحتملة ومحاولة السيطرة على عدم الاستقرار المتأصل.

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

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