مساء الخير جميعا!
تختلف شدة عمليات الإطلاق لدينا من شهر لآخر. قبل أن ينتهي الطلاب في شهر سبتمبر من الشهر الثاني من الدورة التدريبية
"Devops - Practices and Tools" ،
نفتح الدفق التالي. لذلك نحن مستعدون مرة أخرى لمشاركة مواد مفيدة حول الموضوع معك وننتظر
دروسًا مفتوحة لا تقل فائدة.
سنلقي اليوم نظرة على الجزء الأول من المقالة حول كيف تسمح الوثائق لفرق SRE بإدارة الخدمات الجديدة والحالية.
SRE (هندسة موثوقية الموقع ، مترجمة تقريبًا باسم "ضمان موثوقية أنظمة المعلومات" ، والمتخصصون في هذا المجال يتحملون نفس الاختصار) - تخصص خاص ، وتفكير ومجموعة من الأساليب الفنية التي تهدف إلى ضمان التشغيل السلس لمنتجات وخدمات الويب. SRE على مفترق طرق تطوير البرمجيات وهندسة النظم ، وحل المشاكل التشغيلية وتطوير حلول قابلة للتطوير وموثوقة وفعالة لتصميم وإنشاء وتشغيل الأنظمة الموزعة على نطاق واسع.
الأهداف الرئيسية لـ SRE:
- مراقبة وجمع المقاييس - تحديد السلوك المطلوب للخدمة ودراسة السلوك الفعلي للخدمة وإزالة الاختلافات.
- الاستجابة للحوادث - الكشف والاستجابة الفعالة لفشل الخدمة من أجل الحفاظ على توفر الخدمة متسقًا مع اتفاقية مستوى الخدمة (SLA).
- تخطيط السعة - التنبؤ بالطلب المستقبلي وتوفير الكمية اللازمة من موارد الحوسبة في المواقع المناسبة لتلبية هذا الطلب.
- توسيع نطاق الخدمة - النشر القابل للتنبؤ وإزالة القدرة الحاسوبية للخدمة في مركز البيانات ، غالبًا نتيجة لتخطيط السعة.
- إدارة التغيير - تغيير سلوك الخدمة دون فقدان موثوقيتها.
- الأداء - التصميم والتطوير والهندسة المتعلقة بالتدرج والعزل والكمون والإنتاجية والكفاءة.
ينصب تركيز SRE على دورة حياة الخدمة: من الفكرة والتصميم إلى النشر ، والتشغيل ، وتحسين الأداء ، وفي النهاية ، إيقاف التشغيل.
قبل إطلاق خدمة SRE ، يدعمونها من خلال التشاور في مجال هندسة النظام ، وتطوير منصات البرمجيات ، والأطر وخطط السعة ، وإجراء مراجعة الإطلاق.
عندما تكون الخدمة قيد التشغيل بالفعل ، تدعم SREs ما يلي:
- يقيسون ويراقبون مدى توفر النظام وكمونه وحالته العامة.
- تحقق من تغييرات النظام المخططة.
- يقيسون استقرار النظام باستخدام بعض الآليات ، على سبيل المثال ، الأتمتة.
- تحسين النظام من خلال تعزيز التغييرات التي تهدف إلى زيادة الموثوقية والسرعة.
- إجراء الاستجابة للحوادث و "الأبرياء" بعد الوفاة.
عندما توشك حياة الخدمة على الانتهاء ، ستقوم خدمة SRE بإيقاف تشغيلها بطريقة يمكن التنبؤ بها مع شرح واضح ووثائق كاملة.
فريق SRE الناضج لديه دائمًا وثائق كاملة لكل وظيفة SRE. إذا كنت تدير فريق SRE أو تخطط لتنظيمه ، فستساعدك هذه المقالة على فهم أنواع الوثائق التي يحتاجها فريقك ، والتي ستساعدك على تخطيط وتحديد أولويات العمل على الوثائق بالتوازي مع المهام الأخرى للفريق.
تاريخ SRE
قبل مناقشة الفروق الدقيقة في وثائق SRE ، دعنا نلقي نظرة على يوم في حياة Zoe ، SRE المصنوع حديثًا.
تحول زوي الثاني في دور SRE جار في المشروع الرئيسي لشركة AcmeSale في شركة Acme Inc. بينما تتأقلم فقط مع الفريق ، فهي تراقب عمل زملائها وتدوين الملاحظات. ولكن الآن لا يزال لديها جهاز النداء.
ولحسن الحظ ، يتصل النداء الساعة 2:30 صباحًا. تقول الرسالة "انحدر جوب راجناروك" ، ولا يعرف زوي ما الذي يعنيه ذلك. تتصفح ملاحظاتها وتجد رابطًا إلى صفحة لوحة التحكم الرئيسية. كل شيء يبدو على ما يرام. تحاول العثور على بعض المستندات التي تشير إلى راجناروك على إنترانت Acme ، وبعد بضع دقائق ثمينة تجد مستندًا قديمًا حول بنية الخدمة ، والذي يتحول إلى اعتماد بالغ الأهمية لـ AcmeSale.
لحسن الحظ ، هناك رابط إلى صفحة "Ragnarok Ops" في الديسكو ، والذي وجد رابطًا إلى لوحة معلومات مع رسومات مفيدة. تذكر الصفحة أيضًا نص ragtool ، ربما قادرًا على المساعدة في حل المشكلة ، لكن Zoe تسمع عنه لأول مرة. لذلك ، ترسل طلب مساعدة بيجر إلى SRE آخر مع سنوات عديدة من الخبرة في هذه الخدمة والأدوات. لسوء الحظ ، لا يوجد إجابة. تتحقق زوي من البريد وترى رسالة مفادها أن زميلتها في وضع عدم الاتصال لمدة ساعة بسبب مشاكل صحية. بعد وزن جميع الإيجابيات والسلبيات ، اتصلت بتشيلي ، لكن المكالمة تذهب إلى البريد الصوتي. يشير كل شيء إلى أنه يجب عليك حل هذه المشكلة بنفسك.
بعد قضاء بعض الوقت في البحث عن معلومات حول برنامج ragtool الغامض ، تجد مستندًا مع وصف موجز لمعلمات سطر الأوامر ، وكذلك مكان العثور عليه. أطلقت راجول - إعادة تشغيل وعبر أصابعها على أمل. لا شيء يتغير ، تنخفض حركة المرور أكثر. إنها تنظر بشدة إلى بقية خيارات سطر الأوامر ، لكنها ليست متأكدة من أنها لن تضر أكثر. أخيرًا ، قررت استخدام راجول - إعادة التوازن e - dc = atlanta ، لأن الرسوم البيانية تظهر أن المشكلة ملحوظة بشكل خاص في مركز البيانات في أتلانتا. يبدأ الرسم البياني لحركة المرور في الزحف ببطء ، ويفرح زوي بالنصر. MTTR (متوسط وقت الإصلاح) هو 45 دقيقة.
في اليوم التالي ، تجري زوي مناقشة بعد الوفاة للحادث. هذا لأن المشكلة تبين أنها كبيرة بشكل خاص وأسفرت عن فقدان الدخل ، بالإضافة إلى أن المدير يطلب المزيد من الجلسات بعد الوفاة. تسأل الفريق كيف سيحل بقية المشاركين هذه المشكلة ، وهي تسمع ثلاث طرق مختلفة. اتضح أن عملية واحدة لاستكشاف الأخطاء وإصلاحها ببساطة غير موجودة. يعترف زملاؤها أيضًا أن الإشعار "استند إلى الوراء" ليس أفضل اسم ، وأن الفشل حدث بسبب خطأ معروف لم يكن ببساطة أولوية.
وأخيرًا ، سألت ستيف ، من موقع Techlid الخاص بها ،: "ما إصدار ragtool الذي حصلت عليه؟" ، ثم يلاحظ أن الإصدار المستخدم قديم جدًا. تم إصدار نسخة جديدة قبل أسبوع ، إلى جانب وثائق جديدة تمامًا تصف جميع الميزات وحتى شرح كيفية حل مشكلة "Job Ragnarok leaned back". ستقلل هذه النسخة MTTR إلى خمس دقائق.
إن وجود الإصدار الجديد من ragtool هو مفاجأة لنصف الفريق ، في حين أن النصف الآخر يدرك بشكل أو بآخر الإصدار الجديد والدليل. يكمن أحدث إصدار من النص البرمجي في دليل Steve الرئيسي ، ومن الواضح أنه في سلة / مجلد. تضيف زوي هذا إلى ملاحظاتها للاستخدام المستقبلي ، على أمل تحسين بقية التحول بهدوء. إنها تتساءل عما إذا كانت التكنولوجيا أو أحد أعضاء الفريق سيتعامل مع المشاكل التي تمت مناقشتها بعد الوفاة ، أو ما إذا كان يجب على جميع SREs المستقبلية أن تمر بهذه التجربة المؤلمة.
في وقت لاحق من ذلك اليوم ، تشارك Zoe في اجتماع حيث يتواصل فريق SRE مع فريق التطوير حول نقل الخدمة. يقود ستيف الاجتماع ، ويطرح العديد من الأسئلة التي طُرحت سابقًا حول إجراءات التشغيل والمشكلة الحالية لموثوقية الخدمة ، ويطلب من المطورين إجراء تغييرات قبل أن يتحمل فريق SRE المسؤولية عن الخدمة. وقد شاركت زوي بالفعل في العديد من التجمعات التي عقدها ستيف وغيره من كبار ضباط الشرطة. تدرك أن الأسئلة المطروحة والمهام الموزعة من قبل المطورين مختلفة للغاية ، اعتمادًا على من يعقد الاجتماع والمشكلة التي تعامل معها فريق SRE الأسبوع الماضي.
تحلم زوي سرا بمعايير وإجراءات أكثر اتساقا ، لكنها لا تفهم حتى الآن كيفية الوصول إلى هذا الهدف. في وقت لاحق ، تسمع ضاحكين من المطورين يضحكان على آلة القهوة ، وأن العديد من الأسئلة كانت مرتبطة بشكل فضفاض بالبيجر ، ولا يفهمون بشكل عام من أين أتوا. تريد Zoe من المطورين أن يفهموا أن SRE لا تحمل معهم جهاز النداء فقط. بالعودة إلى مكان العمل ، تجد Zoe العديد من التذاكر التي يجب فرزها ، ولم تعد تفكر في ذلك.
لحسن الحظ ، تتكون جميع الشخصيات والأحداث في هذه القصة. ومع ذلك ، فكر في ما إذا كان هذا مشابهًا لشيء واجهته في الواقع. إن حل مشاكل هذا الفريق الخيالي واضح للغاية ، وفي القسم التالي سنناقشه بمزيد من التفصيل.
أهمية التوثيق
في المراحل الأولى من وجود فريق SRE ، تعتمد المنظمة بشكل كبير على عمل الأفراد المؤهلين تأهيلا عاليا داخل الفريق. يقوم الفريق بتخزين مفاهيم ومبادئ الاستغلال المهمة كجزيئات من "المعرفة القبلية" يتم نقلها شفهياً إلى أعضاء الفريق الجدد. إذا لم تكن هذه المبادئ موحدة وغير موثقة ، فعلى الأرجح ، في مرحلة ما ، يجب تعليمها بشكل مؤلم مرة أخرى عن طريق التجربة والخطأ. في بعض الأحيان ، يقوم أعضاء الفريق بتنفيذ إجراءات تشغيلية كتسلسل صارم من الخطوات التي حددها أسلافهم في الماضي البعيد ، حتى دون فهم علاقات السبب والنتيجة لهذه الخطوات. إذا لم يتم إيقاف ذلك ، تصبح العمليات مجزأة ومتدهورة ، يكلف الفريق فقط البدء في النمو لحل المشكلات الجديدة.
يمكن لفريق SRE منع هذه العملية من خلال إنشاء وثائق عالية الجودة ستكون بمثابة الأساس لنمو هذه الفرق وإدخال نهج منظم لإدارة خدمات جديدة وغير مألوفة. تحافظ هذه الوثائق على المعرفة القبلية بالشكل الذي يسهل العثور عليه والحفاظ عليه والبحث عنه. يتم تدريب أعضاء الفريق الجدد من خلال برنامج منظم ومدروس. هذه هي السمات المميزة لفريق SRE الناضج.
يصف الجزء المتبقي من هذه المقالة الأنواع المختلفة من المستندات التي تنشئها SRE أثناء دورة حياة الخدمة المدعومة.
النهاية
في
الجزء التالي ، سننظر في جميع هذه الأنواع بالتفصيل ، ولكن في الوقت الحالي نحن في انتظار تعليقاتك وسؤالك ، كما ندعوك إلى
درس مفتوح .