في إحدى مقالاتنا السابقة ، ناقشنا ما هو SRE ، وما يفعلونه ، وبعض المسؤوليات المشتركة التي قد تكون لدى SRE النموذجية ، مثل دعم العمليات ، والتعامل مع تذاكر المتاعب والاستجابة للحوادث ، ومراقبة النظام العام وإمكانية ملاحظته. في هذه المقالة ، سنتعمق أكثر في مختلف مبادئ وإرشادات SRE التي يمارسها مهندس موثوقية الموقع في دوره. مثل DevOps ، تعمل مبادئ SRE هذه كدليل لدفع المواءمة من حيث صلتها بالمواءمة والاجتماع ودعم أهداف المنظمة.
كانت Google أول شركة تقوم بإنشاء واحتضان ووضع الدعم وراء دور هندسة موثوقية الموقع. ومنذ ذلك الوقت، تطور دور SRE مع تغير الصناعة وتحولها من الهياكل المتجانسة التقليدية إلى الشبكات الكبيرة الموزعة على نطاق واسع والخدمات المصغرة. ومع ذلك ، فقد بقي شيء واحد إلى حد كبير كما هو – المبادئ التي تلتزم بها SREs. تركز مبادئ SRE الأساسية هذه على شيء واحد: نظام القيادة وموثوقية الخدمة. دعونا نتعمق أكثر في مبادئ SRE الأساسية هذه.
مبادئ SRE
احتضان وإدارة المخاطر
إن تبني المخاطر هو في الواقع أحد المبادئ الأساسية ل SRE ، ومن السهل معرفة السبب. لجعل النظام أكثر موثوقية ، عليك التفكير في سيناريوهات “ماذا لو” والتعلم من حالات الفشل المحتملة. لا يوجد نظام موثوق به بنسبة 100٪ ، وفي مرحلة ما ، لا بد أن يحدث خطأ ما. لسوء الحظ ، لا يعرف معظم المستخدمين (أو يهتمون بشكل خاص) بهذا الواقع. إنهم يريدون فقط أن تعمل الأشياء ، وهناك دائما تكلفة لتحقيق هذه الموثوقية ، سواء في المال أو الوقت أو حتى في الحفاظ على ثقة العملاء.
بالنسبة ل SREs ، يعد الميل إلى المخاطر والتعلم من الفشل أمرا ضروريا لبناء أنظمة مرنة. ولكن هناك دائما مقايضات للوزن. قد يعني تعظيم الموثوقية إبطاء وتيرة الميزات الجديدة ، أو قد يؤدي إلى المزيد من التكاليف دون زيادة كبيرة في الإيرادات. الفكرة ليست جعل النظام أكثر موثوقية مما يجب أن يكون عليه بالفعل. بعد كل شيء ، إذا لم تضف الجهود والموارد الإضافية قيمة ذات مغزى ، فمن الأفضل إنفاقها في مكان آخر. في SRE ، يتعلق الأمر كله بإيجاد مستوى الموثوقية “المناسب تماما” الذي يوازن بين التكلفة والسرعة والقيمة.
أهداف مستوى الخدمة
يرتبط مبدأ احتضان المخاطر ارتباطا وثيقا بأهداف مستوى الخدمة (SLOs). لتقسيمها ، تعد SLOs أهداف أداء محددة ضمن اتفاقية مستوى الخدمة (SLA) والتي يتم قياسها مقابل مؤشرات مستوى الخدمة (SLIs) ، وهي المقاييس الفعلية التي تتعقب أداء خدمتك. على سبيل المثال ، إذا كان SLO الخاص بك ينص على أن وقت التشغيل يجب أن يكون 99.9٪ ، فإن SLI يقيس ما إذا كنت تصل إلى هذه العلامة. تتم مراقبة SLIs هذه باستمرار بواسطة SREs ، لذلك إذا انخفض الأداء إلى ما دون الحد المتفق عليه ، يتم تنبيه الفريق ويمكنه الاستجابة بسرعة. تدور معرفات SLIs في النهاية حول ما يهم المستخدمين أكثر ، مما يساعد الفرق على تحديد أولويات جوانب الخدمة التي تؤثر بشكل مباشر على تجربة المستخدم.
فيما يلي تفصيل سريع لهذه المصطلحات:
- اتفاقيات مستوى الخدمة: الاتفاقيات الشاملة مع العملاء أو العملاء حول مستوى الخدمة التي سيتم تقديمها.
- SLOs: أهداف أداء محددة داخل اتفاقية مستوى الخدمة ، مثل وقت التشغيل أو وقت الاستجابة أو معايير الأمان.
- SLIs: قياسات الأداء الفعلية التي تتعقب الامتثال ل SLOs.
في جوهرها ، تسمح SLOs للفرق بقياس الأداء الحقيقي مقابل اتفاقية مستوى الخدمة ، وتحديد توقعات واضحة حول جودة الخدمة. يعزز هذا الهيكل أن هناك تسامحا متفقا عليه مع المخاطر ، ويحدد مقدار التباين أو وقت التوقف الذي يمكن أن تتحمله الخدمة مع الاستمرار في تلبية احتياجات المستخدم وأهداف العمل.
اقرأ: تعرف على المزيد حول إدارة الامتثال لاتفاقية مستوى الخدمة داخل مؤسستك.
القضاء على الكدح
الكدح ، كما هو محدد في نطاق دور SRE ، هو مقدار العمل اليدوي المطلوب لضمان تشغيل الخدمات. أحد الأهداف الرئيسية ل SRE هو أتمتة أكبر قدر ممكن من العمل. وهذا يسمح ل SREs بفتح المزيد من الوقت لمهام أكثر أهمية. وعندما تفكر في الأمر ، يجب أن يكون الحد من الكدح جزءا من وظيفة أي شخص. يضمن الوقت الأقل اللازم للمهام الزائدة عن الحاجة إنتاجية أفضل على المدى الطويل. في أي وقت يجب على مهندس موثوقية الموقع الانخراط في أنشطة يدوية متكررة ، من حيث صلتها بإدارة خدمة الإنتاج ، يمكن وصف ذلك بأنه كدح.
في كثير من الحالات ، قد تكون هناك مناسبات يتعين فيها على SRE القيام بأنشطة يدوية تستغرق وقتا طويلا ، ولكن لا ينبغي تعريفها جميعا على أنها كدح. ومع ذلك ، من المهم تحديد الأنشطة داخل فريق SRE التي تستهلك معظم الوقت. من هناك ، حدد أين يمكن إجراء تحسينات لتقليل كمية الكدح لتحسين توازن العمل. عندما قدمت Google لأول مرة دور SRE ، حددت هدفا يتمثل في أن نصف وقت SREs يجب أن يركز على تقليل العمل التشغيلي المستقبلي أو إضافة ميزات الخدمة. يرتبط تطوير ميزات جديدة بتحسين مقاييس مثل الموثوقية والأداء ، مما يقلل في النهاية من الكدح المحتمل أسفل الخط.
رصد
في Dotcom-Monitor ، نحن جميعا نهدف إلى مراقبة الحلول لتتبع وقت التشغيل والتوافر والوظائف والأداء الشامل للخوادم ومواقع الويب والخدمات والتطبيقات. الرصد هو واحد من أهم مبادئ SRE داخل الدور. تضمن المراقبة المستمرة أن الخدمات تعمل على النحو المنشود ويمكن أن تساعد في تحديد لحظة ظهور المشكلات حتى يمكن إصلاحها على الفور. كما ذكرنا في القسم السابق ، فإن تلبية هذه SLOs هي مفتاح اتفاقيات مستوى الخدمة المحددة للأعمال ، وفي النهاية ، المستخدمين. يمكن أن يوفر الرصد لفرق العمل والفرق اتجاها تاريخيا للأداء ويمكن أن يوفر نظرة ثاقبة لما هو قضية لمرة واحدة مقابل مشكلة نظامية أوسع. وفقا لما حددته مبادرة Google SRE ، تتضمن الإشارات الذهبية الأربع للمراقبة المقاييس التالية:
- الكمون. زمن الوصول هو مقدار الوقت أو التأخير الذي تستغرقه الخدمة للرد على الطلب. من الواضح أن أوقات الاستجابة البطيئة ستؤثر على تجربة المستخدم المتصورة. يمكن أن توفر المراقبة طريقة للتمييز بين
- حركة المرور. تشير حركة المرور إلى مقدار طلب المستخدم أو الحمل الموجود على النظام. يمكن قياس ذلك من خلال طلبات HTTP في الثانية أو اعتمادا على الخدمة الفعلية
- الأخطاء. تشير الأخطاء إلى معدل فشل طلبات الخدمة. ومع ذلك ، من المهم لفرق SRE التمييز بين حالات الفشل الثابت ، مثل أخطاء الخادم 500 ، والفشل الناعم ، مثل استجابة 200 OK التي انتهت مهلتها بسبب تعيين عتبة أداء محددة. من المهم النظر في كيفية مراقبة هذه السيناريوهات المختلفة بشكل مناسب مثل هذه.
- التشبع. التشبع هو حول قياس مقدار موارد النظام التي تمتلكها خدمة معينة. وحتى نقطة معينة، ستشهد معظم الخدمات تدهورا في الأداء. يمكن أن يساعد فهم مكان حدوث ذلك في تحديد أهداف وغايات المراقبة بشكل صحيح ، بحيث يمكن تنفيذ الإجراءات التصحيحية.
اتمته
أتمتة ، أتمتة ، أتمتة. وقد تطرقنا إلى هذا المبدأ في وقت سابق عندما ناقشنا الحد من الكدح، ولكن لا يمكن التقليل من شأنه. طبيعة دور SRE متنوعة بقدر ما يمكن أن يكون الدور. من أجل تقليل إمكانية التدخل اليدوي عبر جميع جوانب مسؤولياتهم ، فإن أتمتة المهام هي مفتاح نجاح الأعمال. ومع توسع نطاق الخدمات وزيادة توزيعها، يصبح من الصعب إدارتها أكثر صعوبة. أتمتة المهام المتكررة في جميع المجالات، سواء كان ذلك الاختبار، أو نشر البرامج، أو الاستجابة للحوادث، أو ببساطة التواصل بين الفرق، توفر الأتمتة فوائد فورية وكفاءات، والأهم من ذلك، الاتساق. منذ الوقت الذي تم فيه تصميم دور SRE ، كان هناك تحول في كيفية تعاون فرق التطوير وضمان الجودة والعمليات. لدعم بيئة وممارسات DevOps الجديدة هذه ، تم تطوير العديد من المنصات والأدوات.
اقرأ: أفضل 13 أداة لموثوقية الموقع (SRE).
هندسة الإصدار
هندسة الإصدار. يبدو وكأنه موضوع معقد ، ولكن في الواقع ، إنها مجرد طريقة بسيطة لتحديد كيفية بناء البرامج وتسليمها. في حين أن هندسة الإصدار في حد ذاتها هي عنوانها ودورها الخاص ، ضمن مفهوم SRE ، فإن هذا يعني تقديم خدمات مستقرة ومتسقة وبالطبع قابلة للتكرار. يعود هذا إلى القسم السابق حول الأتمتة. إذا كنت ستفعل شيئا ما ، فافعل ذلك بشكل صحيح وكن قادرا على تكرار ذلك مرة أخرى ، بطريقة متسقة ، حسب الضرورة. إن بناء مجموعة من الخدمات لمرة واحدة يستغرق وقتا طويلا ويخلق كدحا لا لزوم له.
إذا عدنا إلى تاريخ منصب SRE في Google ، فقد كان لديهم مهندسو إصدار مخصصون عملوا مباشرة مع SREs. عادة ما يتم تكليف مهندسي الإصدار بتحديد أفضل الممارسات من حيث صلتها بتطوير خدمات البرامج ونشر التحديثات والاختبار المستمر ومعالجة مشكلات البرامج ، بالإضافة إلى العديد من المسؤوليات الأخرى. يصبح هذا الدور أكثر أهمية عندما تفكر في كيفية توسيع نطاق الخدمات ونشرها بسرعة. إن وجود مجموعة من أفضل الممارسات والأدوات (وإنفاذها) أمر ضروري للتمكن من تلبية هذه المطالب ويمنح راحة البال لفرق SRE بمجرد وضع هذا البناء في الإنتاج.
البساطه
مع موقف لا نهاية له على ما يبدو لعدد المسؤوليات والتوقعات مثل دور SRE ، فإن المبدأ الأخير ، من المفارقات ، هو البساطة. ربما يكون قول هذا المبدأ أسهل من فعله في الممارسة العملية ، ويركز على فكرة تطوير نظام أو خدمة معقدة بقدر الضرورة. في حين أن هذا قد يبدو غير بديهي في البداية ، إلا أنه يتلخص حقا في الرغبة في نظام موثوق به ومتسق ويمكن التنبؤ به. قد يبدو ذلك مملا ، ولكن بالنسبة ل SRE ، يعد هذا أحد الأهداف النهائية النهائية.
تسعى SREs جاهدة للحصول على نظام أو خدمة ليست معقدة أو يصعب إدارتها. تريد SREs واحدة تقوم ببساطة بالمهمة التي تم تصميمها للقيام بها. ومع ذلك ، من وجهة نظر المستخدم ، فإن الخدمة التي توفر الكثير من الميزات قد توفر أيضا الكثير من الفوائد ، ولكن بالنسبة ل SRE ، فإن هذا يعني فقط المزيد من الصداع المحتمل. ومع ذلك ، فإن التغيير أمر لا مفر منه دائما إذا كنت ترغب في إضافة ميزات جديدة إلى خدمة ويب ، فقم بذلك بعناية. التغييرات الأصغر والإضافية أسهل (وأبسط) في الإدارة من بناء وشحن الكثير من الميزات في وقت واحد. يجب على SREs أيضا النظر في احتياجات وأهداف العمل أيضا.
مبادئ SRE: القواعد الأساسية 7 – الأفكار النهائية
يركز دور SRE على بناء وتقديم والحفاظ على أنظمة وخدمات موثوقة على نطاق واسع. تساعد هذه المبادئ الأساسية السبعة في تحديد ممارسات SREs التي تساعد على دفع المواءمة داخل ممارسات DevOps ودعم أهداف الأعمال. إنه دور معقد يسعى إلى تحقيق التوازن بين الموثوقية وإصدارات الميزات ، كل ذلك مع الحفاظ على مستويات استثنائية من الجودة.
توفر منصة Dotcom-Monitor ل SREs جميع ميزات المراقبة التي تحتاجها لضمان استمرارية خدماتها. من التنبيهات والتقارير القابلة للتكوين إلى لوحات المعلومات والتقارير في الوقت الفعلي ، توفر المنصة الأدوات الأساسية اللازمة لإدارة أداء جميع خدماتها على المدى الطويل. على سبيل المثال، قم بإنشاء برامج نصية لتطبيقات الويب استنادا إلى سلوك المستخدم وإجراءاته ومساراته وإعداد مهام المراقبة الاصطناعية لضمان تجربة متسقة بمرور الوقت. بغض النظر عن مستوى المراقبة الذي يتطلبه فريقك ، هناك حل لتلبية احتياجاتك.
ابدأ مجانا مع الإصدار التجريبي المجاني من Dotcom-Monitor أو حدد موعدا لعرض توضيحي مع أحد مهندسي الأداء لدينا.
