مساء الخير جميعا!
لذلك لم يتبق شيء (أي ، يوم واحد) قبل بدء
مجموعة دورات
DevOps للممارسات والأدوات ، مما يعني أننا نحتاج إلى وقت لاستكمال بقية المقالة
"لماذا وثائق SRE مهمة" خلال هذا الوقت.
نواصل.
وثائق Onboarding خدمة جديدةتجري SREs PRR (مراجعة جاهزية الإنتاج) للتحقق من أن الخدمة تتوافق مع معايير الجاهزية التشغيلية ، وللتأكد من أن مالكي الخدمة يفهمون كيفية استخدام معرفة SRE لإدارة الأنظمة الكبيرة.
تحتاج الخدمة إلى اجتياز هذا الاختبار قبل إطلاقه في الإنتاج. (قبل الإطلاق ، لا يتم دعمه بواسطة SRE ، ولكن من قِبل فريق التطوير نفسه.) الهدف من PRR في هذه المرحلة هو التأكد من أن الخدمة ستفي بمعايير الموثوقية الدنيا في وقت الإطلاق.
يحدث PRR التالي قبل نقل خدمة SRE ، أي أنه يمكن أن يمر الكثير من الوقت بعد الإطلاق. وعندما يقرر فريق SRE أخذ خدمة جديدة ، يتم إجراء تحليل شامل لحالة الإنتاج وممارسات الخدمة المستخدمة. الهدف هو تبسيط عملية نقل الخدمة من حيث الموثوقية والاستقرار التشغيلي ، وكذلك مساعدة SRE على التعامل معها بشكل أفضل.
من خلال إجراء PRRs قبل تسليم الخدمة ، يمكن لـ SREs طرح المزيد من الأسئلة ووضع معايير أعلى للاعتمادية وسهولة الاستخدام مقارنة عند إجراء PRRs قبل الإطلاق. PRR قبل الإطلاق يمكن أن يكون "لايت" حتى لا تبطئ فريق التطوير.
في قصة Zoe ، لم يكن لدى الفريق عملية موحدة أو قائمة مراجعة PRR ، مما يعني أنه قد يفوتهم مشاكل مهمة جدًا عند نقل الخدمة. وبالتالي ، هناك خطر حدوث تصادم مع عدد كبير من المشكلات التي يمكن توقعها وحلها بسهولة قبل تحمل مسؤولية إدارة الخدمة.
يتطلب نقل PRR / الخدمة إنشاء قوالب PRR ووثائق العملية (وثيقة العملية) التي تصف كيف ستعمل فرق SRE مع الخدمة الجديدة وتستخدم قوالب PRR. يمكن أن تكون الأنماط المستخدمة في عملية النقل أكثر شمولاً من تلك المستخدمة أثناء بدء التشغيل.
يغطي قالب PRR عدة مجالات وهو مطلوب للتحقق من إجابات الأسئلة الحرجة. يوضح الجدول 1 بعض المناطق والقضايا ذات الصلة التي يغطيها القالب.
| المنطقة | أسئلة |
|---|
| العمارة والتبعيات | ما هو مسار الطلب من العميل إلى الواجهة الأمامية ثم الخلفية؟ هل هناك أنواع مختلفة من الطلبات ذات متطلبات الكمون المختلفة؟ |
| تخطيط القدرات | ما هي التوقعات لحجم حركة المرور ومعدلات النمو أثناء وبعد الإطلاق؟ هل لديك القدرة الحاسوبية اللازمة لدعم هذه الحركة؟ |
| أنواع الفشل | هل هناك نقاط واحدة من الفشل في الهندسة المعمارية الخاصة بك؟ كيف يمكنك القضاء على عدم التبعية؟ |
| العمليات والأتمتة | هل هناك أي عمليات يدوية ضرورية لدعم الخدمة؟ |
| التبعيات الخارجية | ما هي بيانات الطرف الثالث أو الكود أو الخدمات أو الأحداث التي تعتمد على الخدمة والتشغيل؟ هل يعتمد أي من شركائك على الخدمة؟ إذا كان الأمر كذلك ، فهل يجب إخطارهم بالإطلاق؟ |
الجدول 1. أمثلة على المناطق لقالب PRRيجب أن تشير وثائق العملية أيضًا إلى المستندات التي يجب على SRE طلبها من فريق تطوير المنتج كشروط مسبقة للنقل. على سبيل المثال ، قد يطلبون من فريق التطوير إنشاء playbook للمشاكل الشائعة.
بالإضافة إلى ذلك ، ستحتاج منظمة SRE إلى إنشاء وثيقة مراجعة تشرح لفترة وجيزة لفريق التطوير دور ومجالات مسؤولية SRE. هذا ضروري لتشكيل توقعات واقعية. يجب أن توضح الوثيقة الأولى ماهية SRE ، وتغطي جميع الموضوعات التي تمت مناقشتها في الجزء السابق وبداية هذه المقالة ، بما في ذلك الوظائف الرئيسية ، ودورة حياة الخدمة ، ومسؤوليات الدعم / الصيانة. الغرض الرئيسي من هذا المستند هو التأكد من أن المطورين لا يخلطون بين SRE وفريق OPS ولا يعتبرون أن ردود الاستدعاء هي الواجب الوحيد لـ SRE. كما هو موضح في القصة الموضحة سابقًا ، إذا لم يكن المطورون يفهمون تمامًا ما كان يفعله SRE في وقت نقل الخدمة ، فإن هذا سيؤدي إلى مشاكل في التواصل وسوء الفهم.
بالإضافة إلى ذلك ، من الضروري إنشاء مستند نموذج ارتباط لتوضيح التوقعات وشرح عملية التفاعل بين فريق SRE وفريق تطوير المنتج أثناء وبعد نقل الخدمة. قد تشمل المواضيع التي تتناولها الوثائق ما يلي:
- معايير نقل الخدمة وعملية PRR.
- عملية مناقشة تقارير أهداف مستوى الخدمة (SLO لفترة وجيزة) وحساب الخطأ.
- معايير الإطلاق الجديدة وبدء سياسة التجميد (إن أمكن).
- محتوى وتواتر تقارير حالة الخدمة من فريق SRE.
- متطلبات الموظفين SRE.
- عملية التخطيط لخريطة طريق الوظائف الجديدة وأولوية الوظيفة التي تزيد من الموثوقية (التي تتطلبها SRE) على الوظيفة الجديدة للمنتج.
وثائق تشغيل الخدمةلدعم الخدمة ، تعتمد فرق SRE في المقام الأول على الوثائق التشغيلية الرئيسية: الوصف العام (مقابلة) للخدمة ، قواعد اللعبة والإجراءات ، بعد الوفاة ، التوجيهات وجيش تحرير السودان. (ملاحظة: كان هذا القسم موجودًا في الفصل "Do Docs Better" في البحث عن SRE.)
مقابلة الخدمةالوصف العام للخدمة أمر بالغ الأهمية لفهم SRE ما هو نوع الخدمة التي يدعمونها. تحتاج SRE إلى معرفة بنية النظام ومكوناته وتبعياته واتصالات الخدمة ومالكيها. الوصف العام للخدمة هو نتيجة العمل المشترك لفريق التطوير وفريق SRE ، تم إنشاؤه لتوجيه مهام SRE وتحديد أولوياتها وتحديد مجالات لمزيد من الدراسة. يتم الحصول على مثل هذه المقابلات عادة نتيجة PRR ويجب تحديثها مع تغيير الخدمة (على سبيل المثال ، في حالة ظهور تبعيات جديدة).
تعطي المقابلة البسيطة معلومات كافية عن SRE لمزيد من استكشاف الخدمة. توفر المقابلة الكاملة وصفًا دقيقًا للخدمة وكيفية تفاعلها مع العالم من حولها ، بالإضافة إلى روابط إلى لوحات المعلومات والمقاييس وجميع المعلومات التي تحتاجها SRE لحل المشكلات غير المتوقعة.
كتاب اللعب
يُطلق عليه أيضًا دفتر التشغيل ، وهو مستند أساسي يسمح للمهندسين بالرد على إخطارات نظام مراقبة الخدمة خلال فترة التحول. على سبيل المثال ، إذا كان لدى فريق Zoey كتاب لعب يشرح معنى التنبيه "Job Ragnarok تراجع" وما الذي يجب عمله في الموقف الذي تم استلامه فيه ، فسيتم حل الحادث في غضون دقائق. قواعد اللعب تقلل من وقت التعافي من الحوادث وتوفر روابط مفيدة لوحدات التحكم والإجراءات.
تحتوي قواعد اللعب على إرشادات لفحص وإلغاء وتصعيد أي إخطار تم إنشاؤه لعمليات مراقبة الشبكة. عادة ما تتزامن أسماء الإعلامات في قواعد اللعبة مع ما ينشئه النظام. تحتوي على أوامر وخطوات تحتاج إلى اختبار للتأكد من دقتها. يجب تحديثها بانتظام عند اكتشاف طرق جديدة لحل المشكلات ، وكذلك عند تحديد أنواع جديدة من الفشل وإضافة التبعيات.
لا يتم إنشاء قواعد اللعب حصريًا للإعلامات. قد تحتوي أيضًا على إجراءات إنتاج لإصدار النشرات والمراقبة واستكشاف الأخطاء وإصلاحها. تشمل الأمثلة الأخرى لإجراءات الإنتاج تشغيل / إيقاف تشغيل الخدمة ، وصيانة الخدمة ، والحادث / التصعيد.
بعد الوفاةتعمل SREs مع أنظمة واسعة النطاق ومعقدة وموزعة ، وكذلك تعمل على تحسين الخدمات بمساعدة وظائف جديدة وإضافة أنظمة جديدة. لذلك ، نظرًا لحجم وسرعة التغيير ، فإن الحوادث والاضطرابات لا مفر منها. يعد التشريح بعد الوفاة أداة هامة لتعليم مخاطر الآفات ، وإضفاء الطابع الرسمي على عملية التعلم من أخطاءنا. في قصة زوي الافتراضية ، لم يكن لدى الفريق إجراء رسمي بعد الوفاة ، لذلك لم تكن هناك عملية رسمية لتسجيل استنتاجات الحادث التي من شأنها منع تكرارها. لذا فإن الفريق محكوم عليه بتكرار نفس الأخطاء مرارًا وتكرارًا.
تحتاج فرق SRE إلى إنشاء قالب موحد بعد الوفاة مع أقسام تحتوي على معلومات مهمة حول الفشل. من الناحية المثالية ، ينبغي هيكلة القالب بحيث يمكن تحليله بسهولة بواسطة أداة تحليل البيانات. يرسل تقارير ديناميكية التعطل باستخدام الوفاة كمصدر للبيانات. يصف كل منشور تم إنشاؤه باستخدام هذا القالب فشل الإنتاج ، بما في ذلك المعلومات التالية (الحد الأدنى):
- التسلسل الزمني للأحداث (الجدول الزمني).
- وصف التأثير على المستخدم.
- السبب الجذري
- نقاط العمل / الدروس المستفادة.
تمت كتابة Postmortem من قبل أحد أعضاء الفريق الذي واجه فشلًا ، مثالي لأولئك الذين شاركوا في إزالته ويمكنهم تحمل مسؤولية التحسينات. بعد الوفاة يجب أن يكتب بطريقة بريئة. يجب أن يحتوي على المعلومات اللازمة لفهم ما حدث ، بالإضافة إلى قائمة بالقرارات التي يجب اتخاذها لتقليل احتمالية التكرار وتقليل العواقب و / أو تبسيط الاسترداد.
التوجيهاتفي وثائق السياسة ، يشار إلى القواعد الفنية وغير الفنية وتوجيهات الإنتاج. قد تنطبق القواعد الفنية ، على سبيل المثال ، على تسجيل التغييرات في الإنتاج ، والحفاظ على السجلات ، وتسمية الخدمات الداخلية (قواعد التسمية التي يجب على المهندسين اتباعها عند تنفيذ الخدمات) ، واستخدام وتوافر بيانات تحديد حالات الطوارئ.
يمكن توجيه التوجيهات أيضًا إلى العمليات. تساعد قواعد التصعيد المهندسين في تصنيف حالات الفشل على أنها حالات طوارئ وغير طارئة وفهم الإجراءات التي يجب اتخاذها في موقف معين ؛ وتصف توجيهات توقعات التحول هيكل الفريق ومجال مسؤولية كل عضو.
اتفاقية مستوى الخدمةاتفاقية مستوى الخدمة (اتفاقية مستوى الخدمة ، باختصار - SLA) - اتفاقية رسمية مع العميل حول العمل المقدم للخدمة والإجراءات المتخذة في حالة عدم الوفاء بالالتزامات. تقوم فرق SRE بتوثيق توفر الخدمة والكمون ، ومراقبة أداء الخدمة المرتبطة باتفاقيات مستوى الخدمة.
إن توثيق ونشر اتفاقيات مستوى الخدمة ، بالإضافة إلى تحليل شامل لتجربة المستخدم ومقارنتها مع اتفاقيات مستوى الخدمة ، يسمح لفرق SRE بالابتكار بشكل أسرع دون فقدان جودة UX. فشل SREs التي تدعم خدمات مع إشعار SLA واضح أسرع وبالتالي إصلاحها بشكل أسرع. يقلل SLA أيضًا من مقدار الاحتكاك بين فرق SRE و SWE (مطوري البرامج) ، مما يسمح للفرق بمناقشة الأهداف والنتائج بموضوعية ، وتجنب الأحكام الشخصية حول المخاطر.
تجدر الإشارة إلى أن وجود اتفاقية خارجية صالحة قانونًا قد لا ينطبق على معظم فرق SRE. في مثل هذه الحالات ، قد تقتصر فرق SRE على أهداف مستوى الخدمة (SLO لفترة قصيرة). SLO - تحديد مستوى الخدمة المطلوب لمقياس معين ، على سبيل المثال ، التوافر أو التأخير.
وثائق المنتجتسعى فرق SRE إلى قضاء 50 بالمائة من وقتهم في العمل في مشروع ما أو تطوير برامج لأتمتة العمل اليدوي أو تحسين موثوقية الخدمة. يصف هذا القسم المستندات المتعلقة بالمنتج والأدوات التي تطورها SRE.
هذه المستندات مهمة لأنها تسمح للمستخدمين بفهم ما إذا كان هذا المنتج مناسبًا لهم ، وكيفية بدء العمل به ، وكيفية الحصول على الدعم. كما أنها توفر تجربة المستخدم المناسبة وتجعل اعتماد المنتج أسهل.
المنتج حول الصفحةتساعد صفحة الوصف مهندسي تطوير المنتجات و SRE على فهم ماهية المنتج أو الأداة وماذا تفعل وكيفية استخدامها.
دليل المفهوميعرّف دليل المفردات أو المسرد جميع المفاهيم الفريدة للمنتج. يسمح تعريف المفاهيم بالحفاظ على الاتساق في الوثائق وعناصر واجهات المستخدم وواجهة برمجة التطبيقات و CLIs (واجهات سطر الأوامر).
دليل البدء
الهدف من دليل البدء هو تحديث المهندسين بسرعة مع الحد الأدنى من التأخير. هذا مفيد للمستخدمين الجدد الذين يرغبون في تجربة المنتج.
Codelabيمكن للمهندسين استخدام هذه الدروس ، والجمع بين التفسير النظري ، وأمثلة الكود والتمارين ، للتعرف بسرعة على المنتج. توفر Codelabs أيضًا نصوص تفصيلية تقود المهندسين خطوة بخطوة عبر سلسلة من المهام. عادة ما تكون هذه البرامج التعليمية أطول من البدء في الأدلة. يمكنهم تغطية أكثر من منتج أو أداة واحدة إذا كانت مرتبطة بشيء ما.
دليل عمليمثل هذا التوجيه ضروري للمستخدمين الذين يرغبون في حل مشكلة محددة. عادة ما تكون هذه الأدلة دليلًا خطوة بخطوة يجب اتباعها.
التعليمات
في صفحة الأسئلة الشائعة ، يمكن للمستخدم الحصول على إجابات عن الأسئلة الأكثر شيوعًا ، والتعرف على الصعوبات والقيود التي يمكن مواجهتها ، والعثور على روابط إلى المستندات والصفحات الأخرى للحصول على معلومات أكثر تفصيلاً.
الدعمفي صفحة الدعم ، يمكن للمهندسين تعلم كيفية حل المشكلة التي يواجهونها. يمكنك أيضًا العثور على خطة تصعيد ومعلومات استكشاف الأخطاء وإصلاحها وارتباطات المجموعة ولوحات المعلومات و SLOs ، بالإضافة إلى معلومات التحويل.
وصف APIيصف هذا الدليل الوظائف والفئات والطرق ، وعادةً ما يكون النص المصاحب هو الحد الأدنى. غالبًا ما يتم إنشاء هذه الوثائق استنادًا إلى التعليقات الموجودة في الكود وغالبًا ما يتم كتابتها بواسطة كتاب تقنيين.
دليل المطورمن هذا الدليل ، يمكن للمطورين تعلم كيفية البرمجة باستخدام واجهة برمجة تطبيقات المنتج. عادةً ما تكون هذه الأدلة ضرورية إذا أنشأت SRE منتجات توفر واجهات برمجة التطبيقات للمطورين ، مما يسمح لك بإنشاء أدوات مختلطة تستدعي واجهات برمجة التطبيقات الخاصة ببعضها البعض لأداء مهام أكثر تعقيدًا.
وثائق للإبلاغ عن حالة الخدمةيصف هذا القسم الوثائق التي ينشئها فريق SRE لوصف حالة الخدمات المدعومة.
مراجعة الخدمة الفصليةيتم تقديم المعلومات حول حالة الخدمة في نسختين: تقرير ربع سنوي وافق عليه زعيم SRE ، والذي يتم توزيعه في جميع أنحاء منظمة SRE ، والعروض التقديمية للريادة في تطوير المنتج والفريق.
يهتم قادة SRE بالتقارير الفصلية ، حيث يقدمون معلومات حول الأمور التالية:
- مشاكل الدعم (التحولات ، تذاكر ، بعد الوفاة). يعرف قادة SRE أنه إذا بدأت مشاكل الدعم في الحصول على أكثر من 50 بالمائة من موارد فريق SRE ، فمن الضروري الاستجابة وتغيير الأولويات. الهدف هو تحديد المشكلة بالفعل في المراحل المبكرة.
- تنفيذ جيش تحرير السودان. يريد قادة SRE معرفة ما إذا كان كل شيء على ما يرام مع جيش تحرير السودان ، ما إذا كانت هناك مكونات غير صحية في النظام البيئي تشكل تهديدًا.
- المخاطر يرغب قادة SLA في معرفة المخاطر المعروفة لـ SRE والتي يمكن أن تتداخل مع أهداف المنتج والأعمال.
تمنح التقارير الفصلية فريق SRE الفرصة ل:
- التأكيد على فوائد SRE لفريق تطوير المنتج ، وكذلك العمل ذاته لفريق SRE.
- اطلب الأولوية لحل المشكلات التي تتداخل مع الأمر SRE (مرونة).
- طلب ردود الفعل على أولويات فريق SRE.
- التأكيد على المساهمة الأوسع للفريق.
نظرة عامة على التقنيات الناجحةتساعد هذه المراجعة على تبني تقنيات ناجحة والتوصل إلى حالة مستقرة تتطلب فيها العمليات الحد الأدنى من الوقت. لإعداد مثل هذه التقارير ، توفر فرق SRE موقعًا وميثاقًا لفريق ، وتفاصيل حالة التحول ، والمشاريع مقابل الانقطاعات ، تخطيط القدرات ، إلخ.
تساعد مراجعة التقنيات الناجحة فريق SRE على مقارنة نفسه مع بقية مؤسسات SRE وتحسين الأداء في المجالات الرئيسية: حالة التحول ، والمشاريع مقابل الانقطاعات ، وتراخيص مستوى الخدمة ، وتخطيط القدرات.
نهاية الجزء الثاني.
اقرأ الجزء التالي.نحن في انتظار أسئلتك والتعليقات كالمعتاد.