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

1. مقدمة

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

• التسعير. يتعامل فريق التسعير لدينا مع مشكلة أفضل سعر للركوب في كل نقطة وفي كل لحظة. يتم تحديد السعر من خلال التنبؤ بميزان العرض والطلب بناءً على الإحصاءات وبعض البيانات الأخرى. يتم كل ذلك من خلال خدمة معقدة ومتطورة باستمرار تعتمد على التعلم الآلي. كما يتعامل فريق التسعير مع تطبيق طرق الدفع المختلفة ، ورسوم إضافية عند الانتهاء من الرحلة ، والمبالغ المستردة ، والفواتير ، والتفاعل مع الشركاء والسائقين.
  
• أوامر إيفاد. أي سيارة تكمل طلب العميل؟ على سبيل المثال ، خيار اختيار أقرب سيارة ليس هو الأفضل من حيث تعظيم عدد الرحلات. الخيار الأفضل هو مطابقة السيارات والعملاء بحيث يتم زيادة عدد الرحلات مع مراعاة احتمال قيام هذا العميل المحدد بإلغاء طلبه في ظل هذه الظروف المحددة (لأن الانتظار طويل جدًا) واحتمال قيام هذا السائق المحدد بإلغاء أو تخريب الطلب ( على سبيل المثال لأن المسافة كبيرة جدًا أو أن السعر صغير جدًا).
  
• الجغرافية. كل شيء عن البحث عن العناوين والاقتراح ونقاط الالتقاط والتعديلات في الوقت المقدر للوصول (لا يزودنا شركاء تزويد الخريطة لدينا دائمًا بمعلومات ETA دقيقة مع السماح بحركة المرور) ، وزيادة دقة الترميز الجغرافي المباشر والعكس ، وزيادة دقة نقطة وصول السيارة. هناك الكثير من البيانات ، والكثير من التحليلات ، والكثير من الخدمات القائمة على التعلم الآلي.
  
• مكافحة الاحتيال. إن الاختلاف في تكلفة الرحلة للراكب والسائق (على سبيل المثال ، في الرحلات القصيرة) يخلق حافزًا اقتصاديًا للمتطفلين الذين يحاولون سرقة أموالنا. يشبه التعامل مع الاحتيال نوعًا ما التعامل مع البريد العشوائي - فالدقة والاسترجاع مهمان جدًا. نحتاج إلى حظر أقصى عدد من عمليات الاحتيال (الاستدعاء) ، ولكن في نفس الوقت لا يمكننا أن نأخذ مستخدمين صالحين لعمليات الاحتيال (الدقة).
  
• يشرف فريق حوافز السائقين على تطوير كل ما يمكن أن يزيد من استخدام منصتنا من قبل السائقين ولاء السائقين بسبب أنواع مختلفة من الحوافز. على سبيل المثال ، أكمل رحلات X واحصل على أموال إضافية من Y. أو شراء التحول ل Z والتجول دون عمولة.
  
• الخلفية سائق التطبيق. قائمة الطلبات ، وخريطة الطلب (تُظهر للسائق أين تذهب لزيادة أرباحها إلى الحد الأقصى) ، وتغيير الحالة ، ونظام التواصل مع السائقين والكثير من الأشياء الأخرى.
  
• الواجهة الخلفية لتطبيق العميل (ربما يكون هذا هو الجزء الأكثر وضوحًا وهذا ما يسميه الأشخاص عادةً "تاكسي الخلفية"): ترتيب الطلبات ، معلومات عن حالة الطلب ، توفير حركة السيارات الصغيرة على الخريطة ، نصائح الخلفية ، إلخ.
  

هذا هو مجرد غيض من فيض. هناك الكثير من الوظائف. هناك جزء ضخم تحت الماء من جبل الجليد خلف ما يبدو أنه واجهة بسيطة للغاية.

والآن دعنا نعود للحوادث. ستة أشهر من تاريخ سجل الحوادث نتج عنه التصنيف التالي:

• إصدار غير صحيح: 500 أخطاء خادم داخلي ؛
• الافراج سيئة: الزائد قاعدة البيانات.
• مؤسف التفاعل نظام التشغيل اليدوي.
• بيض عيد الفصح
• أسباب خارجية
• الافراج سيئة: وظيفة مكسورة.

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

2. سوء الإصدار: 500 أخطاء خادم داخلي

الخلفية مكتوبة في الغالب في PHP - لغة مترجمة ضعيفة. سنصدر رمزًا تعطل بسبب الخطأ في اسم الفئة أو الوظيفة. وهذا مثال واحد فقط عندما يحدث 500 خطأ. ويمكن أيضا أن يكون سبب خطأ منطقي في الكود ؛ فرع خاطئ صدر تم حذف المجلد برمز عن طريق الخطأ؛ تم ترك التحف المؤقتة اللازمة للاختبار في الكود ؛ لم يتم تغيير بنية الجداول وفقًا للرمز ؛ البرامج النصية cron اللازمة لم يتم إعادة تشغيلها أو إيقافها.

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

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

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

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

هذه هي عملية التعامل مع الإصدارات السيئة التي تم إعدادها لتحسينها.

المرحلة السلبية: 20 دقيقة.
المرحلة النشطة: 10 دقائق.

3. الحد من المرحلة السلبي

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

ستبدو العملية في أوقات الحادث كما يلي:

1. مهندس ينشر الإفراج.
2. إطلاق يؤدي إلى حادث (كمية هائلة من 500s).
3. تلقي رسالة نصية.
4. المهندسين و devops البدء في النظر في ذلك. في بعض الأحيان ليس على الفور ولكن في غضون 2-3 دقائق: قد تتأخر الرسائل النصية ، قد تكون أصوات الهاتف مغلقة ؛ وبالطبع ، لا يمكن تكوين عادة رد الفعل الفوري عند تلقي هذا النص بين عشية وضحاها.
5. تبدأ المرحلة النشطة للحادث وتستمر لمدة 10 دقائق كما كان من قبل.

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

النتيجة:

المرحلة السلبية: 3 دقائق.
المرحلة النشطة: 10 دقائق.

4. مزيد من الحد من المرحلة السلبية

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

لتقليل المرحلة السلبية ، قررنا التضحية بثلاث دقائق من وقت مهندسينا بعد كل إصدار. كانت الفكرة بسيطة للغاية: لقد نشرنا الشفرة ولمدة ثلاث دقائق بعد ذلك ، كنا نبحث عن 500 خطأ في New Relic و Sentry و Kibana. بمجرد أن رأينا مشكلة هناك ، كنا نفترض أنها مرتبطة بالكود وبدأنا في استكشاف الأخطاء وإصلاحها.

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

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

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

النتيجة:

المرحلة السلبية: 1 دقيقة.
المرحلة النشطة: 5 دقائق.

5. مزيد من الحد من مرحلة نشطة

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

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

النتيجة:

المرحلة السلبية: 1 دقيقة.
المرحلة النشطة: 3 دقائق.

6. تخفيض أكبر من مرحلة نشطة

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

لذلك ، بدأت عمليتنا تبدو كما يلي: ينشر مهندس إصدارًا ، ويراقب الرسوم البيانية لمدة ثلاث دقائق ، وبعد ذلك لا يمكن لأحد نشر أي شيء لمدة دقيقتين أخريين. في حالة حدوث مشكلة ، يقوم المهندس بإعادة الإصدار مرة أخرى. هذه القاعدة مبسطة بشكل كبير استكشاف الأخطاء وإصلاحها ، والمدة الإجمالية للمراحل النشطة والسلبي خفضت من 3 + 1 = 4 دقائق إلى 1 + 1 = 2 دقيقة.

ولكن حتى حادث مدته دقيقتان كان أكثر من اللازم. لهذا السبب واصلنا العمل على تحسين عملياتنا.

النتيجة:

المرحلة السلبية: دقيقة واحدة.
المرحلة النشطة: 1 دقيقة.

7. التلقائي تحديد الحادث والتراجع

كنا نفكر لفترة من الوقت في كيفية تقليل مدة الحوادث الناجمة عن الإصدارات السيئة. لقد حاولنا إجبار أنفسنا على البحث في tail -f error_log | grep 500 tail -f error_log | grep 500 . لكن في النهاية ، اخترنا حلاً تلقائيًا جذريًا.

باختصار ، إنه تراجع تلقائي. لدينا خادم ويب منفصل وقمنا بتحميله عبر موازن 10 مرات أقل من بقية خوادم الويب لدينا. سيتم نشر كل إصدار تلقائيًا بواسطة أنظمة CI / CD على هذا الخادم المنفصل (أطلقنا عليه اسم preprod ، لكن على الرغم من اسمه ، فإنه سيتلقى حمولة حقيقية من المستخدمين الحقيقيين). ثم سينفذ البرنامج النصي tail -f error_log | grep 500 tail -f error_log | grep 500 . إذا لم يكن هناك خطأ في غضون دقيقة واحدة ، فسيقوم CI / CD بنشر الإصدار الجديد في الإنتاج على خوادم الويب الأخرى. في حالة وجود أخطاء ، قام النظام بإعادته بالكامل. على مستوى الموازن ، سيتم إعادة إرسال جميع الطلبات الناتجة عن 500 خطأ على ما قبل الطباعة على أحد خوادم الويب الخاصة بالإنتاج.

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

النتيجة:

المرحلة السلبية: 0 دقيقة.
المرحلة النشطة: 0 دقيقة.

---

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