الأسئلة المتداولة: هل أحتاج إلى معرفة كيفية التعليمات البرمجية للانخراط في SRE؟

عندما يفكر الأفراد في المشاركة في SRE وتفكر الفرق في جلب ممارسات SRE، فإن السؤال الشائع الذي يظهر هو "هل تحتاج إلى معرفة كيفية التعليمات البرمجية؟"

الجواب المختصر: نعم.

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

السيناريو 1: إزالة الكتم من خلال الأتمتة

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

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

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

خبرة الترميز: تتطلب الأتمتة بعض الخبرة في الترميز، ولكنها لا تحتاج إلى مهارات هندسة برامج كاملة. إذا كان يمكنك كتابة برامج نصية صغيرة (ربما في PowerShell أو Bourne shell) أو حتى إذا قمت بإنشاء تطبيق منطق Azure مع أي تعليمة برمجية بالكاد، فلا يزال بإمكان هذا التطبيق المساعدة في التخلص من الكد.

السيناريو 2: التحكم من خلال واجهات برمجة التطبيقات/لغات محددة بالمجال (DSLs)/قوالب

على الرغم من أنه ليس ضروريا تماما لعمل SRE، فإن القدرة على التحكم في البيئات من خلال واجهات برمجة التطبيقات وعناوين DSLs والقوالب (خاصة البيئات السحابية) تسمح ل SREs بتوسيع نطاق عملها. تصبح البنية الأساسية للتزويد/إلغاء التوفير وتكوين المراقبة ودمج العديد من الخدمات أكثر كفاءة من خلال الترميز.

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

السيناريو 3: إصلاح التعليمات البرمجية

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

خبرة الترميز: غالبا ما تكون الخبرة الكاملة في هندسة البرمجيات مطلوبة في هذا السيناريو.

الخطوات التالية

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