Citymobil - دليل لتحسين التوافر وسط نمو الأعمال للشركات الناشئة. الجزء 2

هذا مقال ثانٍ من سلسلة "Citymobil - دليل لتحسين التوافر وسط نمو الأعمال التجارية للشركات الناشئة". يمكنك قراءة الجزء الأول هنا . دعنا نواصل الحديث عن الطريقة التي تمكنا بها من تحسين توفر خدمات Citymobil. في المقالة الأولى ، تعلمنا كيفية حساب الرحلات المفقودة. حسنا ، نحن نحسبهم. ماذا الان؟ الآن وقد تم تزويدنا بأداة مفهومة لقياس الرحلات المفقودة ، يمكننا الانتقال إلى الجزء الأكثر إثارة للاهتمام - كيف يمكننا تقليل الخسائر؟ دون إبطاء نمونا الحالي! نظرًا لأنه يبدو لنا أن حصة الأسد من المشكلات الفنية التي تسببت في فقد الرحلات كانت لها علاقة بالخلفية ، فقد قررنا توجيه انتباهنا إلى عملية تطوير الواجهة الخلفية أولاً. وأقفز أمامي ، سأقول إننا كنا على صواب - أصبحت الخلفية هي الموقع الرئيسي للمعركة من أجل الرحلات المفقودة.

1. كيف تعمل عملية التطوير

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

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

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

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

في Citymobil ، كانت العملية سريعة التطور وموجهة بالكامل على النحو التالي:

• 20-30 إصدارات في اليوم الواحد.
  
• المطورين أداء النشر من تلقاء أنفسهم.
  
• اختبار سريع في بيئة الاختبار من قبل المطور.
  
• الحد الأدنى الآلي / وحدة الاختبارات ، الحد الأدنى للمراجعة.
  

عملت المطورين في ظروف قاسية دون دعم ضمان الجودة ، مع تدفق هائل من المهام الهامة جدا من فريق المنتج والتجارب ؛ لقد عملوا بحزم وثبات قدر استطاعتهم ، حلوا المهام الصعبة بطريقة بسيطة ، وتأكدوا من أن الكود لم يتحول إلى معكرونة ، فهموا مشاكل العمل ، وعاملوا التغييرات بمسؤولية وسرعان ما تراجعوا عن ما لم ينجح. لا يوجد شيء جديد هنا. كان هناك موقف مماثل في خدمة Mail.Ru منذ 8 سنوات عندما بدأت العمل هناك. بدأنا Mail.ru سحابة بسرعة وسهولة ، لا مقدمة. سنقوم بتغيير عمليتنا على الطريق لتحقيق توفر أفضل.

أراهن أنك قد لاحظت ذلك بنفسك: عندما لا يكون هناك أي قيود ، وعندما تكون أنت والإنتاج وحدك ، عندما تتحمل عبء ثقيل من المسؤولية - فأنت تفعل العجائب. لقد واجهت تجربة من هذا القبيل. منذ وقت طويل كنت المطور الوحيد في خدمة Newmail.Ru webmail (تم الحصول عليها منذ فترة ثم تم إنزالها) ؛ أجريت عملية النشر بنفسي وأجريت اختبارات الإنتاج أيضًا على نفسي عبر if (!strcmp(username, "danikin")) { … some code… } . لذلك ، كنت على دراية بهذا الوضع.

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

لماذا Citymobil لديها مثل هذه العملية؟ كان هناك عدد قليل جدا من المطورين لتبدأ. كانوا يعملون لدى الشركة لفترة من الوقت ويعرفون الكود والعمل جيدًا. عملت العملية بشكل مثالي في ظل هذه الظروف.

2. لماذا يأتي توافر التهديد جنبا إلى جنب؟

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

من الواضح ، لم نتمكن من الاستمرار بهذه الطريقة. لم يتم بناء العملية فقط لهذه الشروط الجديدة. ومع ذلك ، اضطررنا إلى تعديله دون التنازل عن الوقت للسوق ؛ أي الاحتفاظ بـ 20-30 إصدارًا يوميًا (بالنظر إلى أن عددهم سينمو مع نمو الفريق). كنا ننمو بسرعة ، أجرينا العديد من التجارب ، وقمنا على الفور بتقييم النتائج وأجرينا تجارب جديدة. لقد اختبرنا بسرعة فرضيات المنتج والأعمال ، وتعلمنا منها وصنعنا فرضيات جديدة قمنا باختبارها مرة أخرى بسرعة وهكذا دواليك. تحت أي ظرف من الظروف سوف تبطئ. علاوة على ذلك ، أردنا تسريع وتوظيف المطورين بشكل أسرع. لذا ، فإن تصرفاتنا التي تهدف إلى نمو الأعمال قد أوجدت تهديداً للتوافر ، لكننا لم نعتزم إطلاقًا تعديل هذه الإجراءات.

3. حسنا ، تم تعيين المهمة ، والعملية واضحة. ما التالي؟

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

كنت تعتقد أن كل شيء كان بسيطًا للغاية: يمكننا تكرار عملية البريد الإلكتروني / السحاب Mail.Ru في Citymobil وبالتالي زيادة توفر الخدمة. ومع ذلك ، كما يقولون - الشيطان هو في التفاصيل:

1. تتم عمليات النشر في Mail.Ru البريد الإلكتروني / السحابة مرة واحدة في الأسبوع ، وليس 30 مرة في اليوم ؛ في Citymobil لم نكن نريد التضحية بكمية الإصدارات ؛
   
2. في Mail.Ru البريد الإلكتروني / سحابة يتم تغطية رمز اختبار السيارات / وحدة ولم يكن لدينا وقت أو موارد لذلك في Citymobil. ألقينا كل جهدنا لتطوير الخلفية في الفرضيات واختبار تحسين المنتج.
   

ومع ذلك ، فقد كنا قليلي اليد من حيث مطوري الواجهة الخلفية ، على الرغم من أنهم تم تعيينهم على وجه السرعة (شكر خاص لمجندي Citymobil - أفضل شركات التوظيف في العالم! أعتقد أنه سيكون هناك مقال منفصل حول عملية التوظيف لدينا) ، لذلك لم تكن هناك طريقة تمكننا من معالجة مشكلات الاختبار والمراجعة دون التباطؤ.

4. عندما لا تعرف ماذا تفعل ، تعلم من الأخطاء

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

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

بدأنا تسجيل جميع الانقطاعات في جدول مستندات Google. لكل انقطاع كان هناك المعلومات القصيرة التالية:

• التاريخ والوقت والمدة
  
• السبب الجذري
  
• ما الذي تم عمله لحل المشكلة ؛
  
• تأثير العمل (عدد الرحلات المفقودة ، والنتائج الأخرى) ؛
  
• الوجبات السريعة.
  

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

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

5. مثال على انقطاع في تعلمنا منه

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

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

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

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

6. ماذا يمكن أن نتعلم من هذا الخطأ أو "ما يجب عمله وما يجب".

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

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

الوجبات الجاهزة من انقطاع المذكورة أعلاه: إنشاء ملف المهام وما يترك ؛ اكتب كل ما تعلمناه فيه ، وأظهر الملف للفريق بأكمله ، واطلب من كل وافد جديد أن يدرسه ويشجع الناس على طرح الأسئلة.

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

7. بدلا من خاتمة

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