في إحدى مقالاتنا السابقة ، ناقشنا ما هو SRE ، وما يفعلونه ، وبعض المسؤوليات المشتركة التي قد تكون لدى SRE النموذجية ، مثل دعم العمليات ، والتعامل مع تذاكر المتاعب والاستجابة للحوادث ، ومراقبة النظام العام وإمكانية ملاحظته. في هذه المقالة ، سنتعمق أكثر في مختلف مبادئ وإرشادات SRE التي يمارسها مهندس موثوقية الموقع في دوره. مثل DevOps ، تعمل مبادئ SRE هذه كدليل لدفع المواءمة من حيث صلتها بالمواءمة والاجتماع ودعم أهداف المنظمة.
كانت Google أول شركة تقوم بإنشاء واحتضان ووضع الدعم وراء دور هندسة موثوقية الموقع. ومنذ ذلك الوقت، تطور دور SRE مع تغير الصناعة وتحولها من الهياكل المتجانسة التقليدية إلى الشبكات الكبيرة الموزعة على نطاق واسع والخدمات المصغرة. ومع ذلك ، فقد بقي شيء واحد إلى حد كبير كما هو – المبادئ التي تلتزم بها SREs. تركز مبادئ SRE الأساسية هذه على شيء واحد: نظام القيادة وموثوقية الخدمة. دعونا نتعمق أكثر في مبادئ SRE الأساسية هذه.
مبادئ SRE
احتضان وإدارة المخاطر
تبني المخاطر هو الأول من مبادئ SRE ، ولسبب وجيه. من أجل تحسين موثوقية النظام ، من المهم قياس تأثير فشل “ماذا لو”. من المفهوم أنه لا يوجد نظام موثوق به بنسبة 100٪. في مرحلة ما من الزمن ، سيحدث خطأ ما. لسوء الحظ ، لا يعرف المستخدم أو العميل اليومي ، أو يهتم ، أن يكون متفهما للغاية. وهناك تكلفة متأصلة مرتبطة بضمان الموثوقية. سواء كان ذلك يعني أنها تكلفة مالية أو تكلفة زمنية أو ببساطة ثقة العميل في خدماتك.
تتمثل مسؤولية SREs في الميل إلى الفشل والمخاطر من أجل معرفة كيف يمكنهم في نهاية المطاف جعل خدماتهم وأنظمتهم أكثر مرونة. ومع ذلك ، هناك مقايضات تحتاج إلى النظر فيها. على سبيل المثال، قد يأتي ضمان أقصى قدر من الموثوقية على حساب القدرة على نشر الخدمات المستقبلية بسرعة أكبر. أو ربما لا تعني التحسينات الإضافية بالضرورة تحقيق مكاسب كبيرة في الإيرادات؟ الهدف هو إنشاء نظام موثوق به ، ولكن ليس أكثر مما يجب أن يكون عليه ، لأن التكلفة والوقت المرتبطين بالقيام بذلك يفوق الفوائد المحتملة.
أهداف مستوى الخدمة
يرتبط مبدأ تبني المخاطر ارتباطا وثيقا بكائنات مستوى الخدمة ، أو SLOs. للتعمق قليلا ، فإن SLOs هي مجموعة الأهداف الرسمية ضمن اتفاقية مستوى الخدمة (SLA) التي يتم قياسها مقابل مؤشرات مستوى الخدمة ، أو SLIs. SLIs هي مقاييس الأداء الفعلية لخدماتك. على سبيل المثال، إذا كان SLO الخاص بك ينص على أن وقت التشغيل الخاص بك يجب أن يكون 99.9٪، فيجب أن يفي SLI الفعلي بمقياس الأداء هذا أو يتجاوزه من أجل تلبية SLO المحدد. ومؤشرات الأداء الخاصة هي المؤشرات التي سيراقبها نظام SRE باستمرار، بحيث إذا خرج من هذه العتبة، يتم تنبيه الفرق ويمكن حل المشكلة بسرعة. ترتبط SLIs حقا بالمستخدم لتحديد ما هو الأكثر أهمية لتجربتهم من حيث صلتها بالخدمة.
اتفاقيات مستوى الخدمة مقابل SLOs مقابل SLIs
- اتفاقيات مستوى الخدمة. الاتفاقيات المبرمة مع عملائك أو عملائك التي تحدد مستوى الخدمة التي سيتم تقديمها.
- SLOs. اتفاقية داخل اتفاقية مستوى الخدمة تنص على مقياس محدد، مثل وقت التشغيل ووقت الاستجابة والأمان وحل المشكلات وما إلى ذلك.
- SLIs. الأداء الفعلي أو القياسات لمنظمات SLO الخاصة بك التي تحدد مستوى الامتثال.
تستخدم 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 لمدة 30 يوما أو قم بجدولة عرض توضيحي مع أحد مهندسي الأداء لدينا.
