مذبحة سيليكون بالمنشار

يعد الواجب مكونًا مهمًا لمعظم المنظمات الحديثة. بعد كل شيء ، غالبًا ما يحدث أن تصل المشكلة الساعة 3 صباحًا. ولكن من يجب أن يكون في الخدمة؟ وكيف تنظم هذه العملية بحيث تكون منطقية؟

انظر تحت القطة ، هناك باروخ Sadogursky ( jbaruch ) و Leonid Igolnik ( ligolnik ) يرويان قصة رعب عن ضابط واجب غير محظوظ. تذكر فاسيا ، الذي كان عليه دائمًا إصلاح الأخطاء في الثالثة صباحًا؟ هذه هي البداية فقط.



تم إعداد المادة بناءً على خطاب باروخ وليونيد في مؤتمر DevOops 2017 للخريف.



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

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

Vasya في الخدمة وحدها للمشروع بأكمله ، سيكون عليه القيام بذلك. يوقظه مهندس الدعم الفني ويحاول شرح المشكلة بكلمات بسيطة للغاية: "هناك شيء ما لا يعمل هناك ، هناك خطأ ما."

يستمع Vasya إلى زميله ، ويفكر في ما حدث ويتخذ القرار الصحيح الوحيد ...



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

في السجلات ، تبين أن كل شيء بعيد عن البساطة. أولاً ، كان Vasya يبحث عن شخص يمكنه الوصول إلى السجل الصحيح لمدة 15 دقيقة. وجدها وحصل على سجل. لكن كيف؟ إلى البريد بتنسيق doc. بالطبع. Vasya هي المسؤولة والصغيرة ويقرأ تسجيل الدخول في Word: لا شيء يفهم على الإطلاق. ولكن هناك كلمات رئيسية يمكنك البحث عنها في قاعدة المعارف. تعلق Vasya على أشياء مثيرة للاهتمام لمدة 20 دقيقة ، وتتعلم الكثير من كل شيء مثير للاهتمام ، ولكن لا شيء مطلوب في الوقت الحالي.

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



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

بطبيعة الحال ، لا يمكنك الانتشار في الإنتاج ، ليس هناك جذر. لذلك الخيار الوحيد هو إرسال ملف جرة مع فئتين وفقرة من التفسيرات عن طريق البريد الإلكتروني. سوف يدخل هؤلاء الرجال في الإنتاج عبر ssh وهناك سيضعون ملف jar هذا في WebSphere في الدليل الصحيح. والآن ، في الساعة 6-7 صباحًا ، يمكنك أخيرًا الذهاب إلى الفراش بشعور بالإنجاز.



يوم الاثنين ، يأتي Vasya للعمل ويرى صورة غير عادية. كان الرئيس التنفيذي يصرخ في VP of Engineering لأن العميل كان يصرخ في الرئيس التنفيذي لأن الرئيس التنفيذي له كان يصرخ عليه. اتضح أنه لم يكن من الممكن حل المشكلة.

لدى السلطات أربعة أسئلة: "ماذا حدث يوم الجمعة؟" ؛ "لماذا سمعت عن هذا من رئيس يوم الاثنين؟" ؛ "لماذا استغرق الإصلاح ست ساعات؟" و "على من يقع اللوم؟" يتم استدعاء العمليات في الغرفة ، الذين يقولون إن هذه ليست مشكلتهم. يتم استدعاء Vasya والخادمة الأخرى إلى الغرفة ، والتي تقول أيضًا ، "لا شيء يعمل". تستمر لعبة البطاطس بأكملها حتى الغداء.

نظرًا لأن الوقت قد حان لتناول العشاء ، فإن القرار "حسنًا ، لقد تم كسره في حد ذاته ، ولا أحد يلوم". نهاية القصة.



دعنا نرتب استخلاصًا صغيرًا: دعنا نذهب في هذا الكابوس ونحاول تقديم إجابات على جميع الأسئلة.

من يجب أن يكون في الخدمة

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



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

هناك سببان لعدم رغبة الناس في أداء واجبهم. الأول عندما يكون ذلك:



لا أحد يريد أن يكون في الخدمة عندما يكون كل شيء سيئًا. حل هذه المشكلة بسيط للغاية:



تحتاج إلى كتابة كود جيد ، كل شيء بسيط. ولكن يجب تعلم ذلك أيضًا. يطرح سؤال جديد: "كيف تتعلم؟". تحتاج إلى وضع أصابعك في المقبس - #Painisinstructional. الألم يساعد.



يعمل الواجب في حد ذاته على تحسين جودة التعليمات البرمجية. من المرجح أن نفس Vasya يوم الاثنين ستصحح أخطائه حتى لا يجلس ليلة أخرى بحثًا عن الأخطاء.

الحواجز في الخدمة

عندما تكون في الخدمة ، هناك بعض الحواجز التي لا ينبغي أن تكون هناك. دعونا نذهب من خلال إخفاق فاسيا يوم الجمعة. هل تتذكر كيف قرأ السجلات في مستند Word؟



كلنا نحب منتجات Microsoft ، ولكن لا يمكنك فعل ذلك في العالم الحديث. هناك أشياء واضحة حول السجلات التي يجب على الجميع فهمها. النقطة الرئيسية هي عدد الأدوات التي تحل هذه المشاكل: Logstash ، Loggly ، Sumo logic ، Kibana. يجب استخدامها.

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

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

من يحدد أهمية المشكلة

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

علاوة على ذلك ، تعمل اليوم جميع الشركات تقريبًا على مبدأ "التسليم المستمر" ، لذلك يتلقى جميع العملاء جميع الميزات في نفس الوقت (وفي نفس الوقت الأخطاء). لنفترض أن هناك خطأ يبدو للعميل "شيء ما لا يعمل هناك ، فلا بأس." في الوقت نفسه ، يرى الدعم مئات التنبيهات حول المشكلة ، ومن الواضح أن هذا أمر خطير.

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

يحتاج العملاء إلى إعطاء الفرصة لإظهار الأهمية لأن الشركة المصنعة للمنتج لا تفهم دائمًا سياق المشكلة.

اتفاقية مستوى الخدمة - ضمان الاستجابة والحلول في غضون يوم واحد ، ولكن يمكن أن تكون أسرع. هذا ، مرة أخرى ، يعتمد على السياق.

التحديات التنظيمية

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

هناك صعوبة أخرى تؤثر على الصورة العامة: يجب العثور على Vasya. كيف يعرف الدعم أن Vasya في الخدمة اليوم؟ ماذا لو أنه لا يعرف Vasya سواء. من المهم أن تجد الشخص المناسب. الحل هو Virtual Extension مع بادئات مختلفة للمهندس والإنتاج وما إلى ذلك. حسنًا ، أو أنظمة أخرى أكثر تعقيدًا. باستخدام هذا الحل ، ليس عليك تخمين مكان الاتصال في منتصف الليل ؛ فكل شيء يتحول تلقائيًا.

والأكثر ملاءمة هو Escalation Chat في Slack و Telegram و Skype في أي مكان. عنوان المحادثة هو رقم التذكرة نفسها. جميع الاتصالات على هذه التذكرة بين الأشخاص المناسبين تذهب في غرفة الدردشة هذه. واحدة من أكثر الميزات المفيدة لمثل هذا chatik هو أنك لا تحتاج إلى إخبار أي شيء لأولئك الذين ينضمون إلى العمل بعد فترة. يمكنك ببساطة قراءة القرارات التي تم اتخاذها بالفعل.

حسنًا ، جسر هاتف افتراضي ، يمكن مقارنته بمكان التجمع في حالة نشوب حريق: يعرف الجميع إلى أين يذهبون في حالة حدوث مشاكل. بالمناسبة ، في الأنظمة الحديثة مثل Zoom أو Bluejeans ، كل الوظائف الضرورية مضمنة بالفعل.

مسار التصعيد

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



هناك اتصالات يجب أن تأتي من الرئيس التنفيذي. يجب أن يكون على بينة من القضايا الحرجة.

مدير Errand

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

الوصول إلى الإنتاج

هل يجب أن أعطي Vasya الوصول إلى الإنتاج؟ بعد كل شيء ، ليس كلهم ​​مهندسون متميزون ، وهناك أشياء معينة لا أرغب في التعلم منها ، سيهين العملاء. يتم حل هذا باستخدام عملية النشر. إذا تم تكوين العملية بشكل صحيح ، فيمكن لـ Vasya النقر على الزر ، ونتيجة لذلك ، سيتم تعطيل رمز الإنتاج الخاص به. إذا كان لديك خط أنابيب توصيل عادي مستمر ، فمن المحتمل أن يتم ذلك تلقائيًا (ستنتهي جميع الاختبارات). إذا لم يكن الأمر كذلك ، في العديد من الشركات يتم اتخاذ القرار من قبل مهندس أو مدير كبير. يراجع ويقيم خطر المدونة ويتخذ القرار.

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

تغيير الواجب

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

مشاكل أخرى

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

كيف تترجم؟

ولكن كيف يمكن جلب كل هذا إلى الشركة؟ عليك أن تفهم أن هذا سيستغرق بعض الوقت.



نحتاج أن نبدأ مع كبار السن في الخدمة. لديهم خبرة ومعرفة ما وكيفية إصلاحه. يعاني الرب من مشاكل أقل: هناك إمكانية الوصول إلى السجلات ، إلخ.

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

الاستنتاجات

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

ملاحظة

نريد أن نوصي بكتاب يسمى Drive. هذا كتاب عن دوافع الأشخاص الذين يعملون في مهن مثل مهنتنا. يتكون هذا الدافع من ثلاثة مكونات رئيسية و (المفسد) لا أحد منهم هو المال.

بالفعل هذا الأحد ، سيقدم باروخ وليونيد تقريرًا بعنوان "#DataDrivenDevOps" في DevOops 2018 في سان بطرسبرج. تعال ، سيكون هناك الكثير من الأشياء المثيرة للاهتمام: إليك التقارير ، وهنا جون ويليس ، وهنا حفلة مع BoFs والكاريوكي . في انتظارك!