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

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

0. مقدمة

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

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

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

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

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

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

1. الافراج سيئة ، والأخطاء 500

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

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

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

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

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

فيما يلي عملية للتعامل مع الإصدارات السيئة ، وكان علينا تحسينها.

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

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

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

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

وهكذا ، تم تخفيض المرحلة السلبية من 15 دقيقة إلى 3.

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

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

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

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

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

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

1.3. مزيد من الانخفاض في المرحلة النشطة

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

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

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

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

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

لكن دقيقتين من الحادث الكثير. لذلك ، واصلنا تحسين العملية.

1.5. كشف تحطم التلقائي والتراجع

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

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

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

2. الافراج عن سيئة ، رمز الأمثل ، تحميل قاعدة

سأبدأ على الفور بمثال ملموس لحادث من هذا النوع. لقد طرحنا التحسين: لقد أضفنا USE INDEX إلى استعلام SQL ، أثناء اختبار هذه الاستعلامات القصيرة المتسارعة ، كما هو الحال في الإنتاج ، ولكن تباطأت طلبات البحث الطويلة. لوحظ تباطؤ الاستفسارات الطويلة فقط في الإنتاج. نتيجة لذلك ، وضع دفق الطلبات الطويلة القاعدة الرئيسية بالكامل لمدة ساعة واحدة. لقد أدركنا تمامًا كيف يعمل USE INDEX ، ووصفناه في ملف "do & dont" ، وحذرنا المطورين من سوء الاستخدام. قمنا أيضًا بتحليل الاستعلام وأدركنا أنه يقوم بإرجاع البيانات التاريخية بشكل أساسي ، مما يعني أنه يمكن تشغيله على نسخة متماثلة منفصلة للاستعلامات التاريخية. حتى لو كانت هذه النسخة المتماثلة تحت التحميل ، لن يتوقف العمل.

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

• قاعدة رئيسية (لعمليات الكتابة والاستعلامات ذات الأهمية البالغة لتحديث البيانات) ؛
• نسخة متماثلة للإنتاج (للاستعلامات القصيرة الأقل أهمية إلى حد ما في نضارة البيانات) ؛
• نسخة طبق الأصل لحساب نسب السعر ، ما يسمى تسعير الطفرة. يمكن أن تتخلف هذه النسخة المتماثلة عن 30 إلى 60 ثانية - وهذا ليس بالأمر الحاسم ، ولا تتغير المعاملات في كثير من الأحيان ، وإذا انخفضت هذه النسخة ، فلن تتوقف الخدمة ، ولن تتوافق الأسعار تمامًا مع ميزان العرض والطلب ؛
• نسخة طبق الأصل للوحة المشرف من مستخدمي الأعمال ومركز الاتصال (إذا سقطت ، لن يرتفع النشاط التجاري الرئيسي ، ولكن لن ينجح الدعم ولن نتمكن من عرض الإعدادات وتغييرها مؤقتًا) ؛
• العديد من النسخ المتماثلة للتحليلات.
• MPP قاعدة بيانات للتحليلات الثقيلة مع شرائح كاملة وفقا للبيانات التاريخية.

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

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

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

• إذا كان استعلام SQL لا يعتمد على المستخدم الحالي (على سبيل المثال ، خريطة طلب للسائقين تشير إلى معدلات الحد الأدنى من الرحلات ومعاملات المضلعات) ، فيجب أن يتم هذا الاستعلام بواسطة cron بتردد معين (في حالتنا ، بمجرد أن تكفي دقيقة واحدة). اكتب النتيجة إلى ذاكرة التخزين المؤقت (Memcached أو Redis) ، والتي يتم استخدامها بالفعل في رمز الإنتاج.
• إذا كان استعلام SQL يعمل مع البيانات التي تراكم الأعمال غير حاسم ، فيجب تخزين نتائجه مؤقتًا مع بعض TTL (على سبيل المثال ، 30 ثانية). ثم في الطلبات اللاحقة قراءة من ذاكرة التخزين المؤقت.
• إذا كنت ترغب في إجراء استعلام SQL في سياق معالجة طلب على الويب (في حالتنا ، في سياق تنفيذ طريقة خادم محددة في PHP) ، فعليك التأكد من أن هذه البيانات "لم تصل" مع أي استعلام SQL آخر (وما إذا كانوا سيأتيون عن طريق الرمز). الأمر نفسه ينطبق على الوصول إلى ذاكرة التخزين المؤقت: يمكن أيضًا إغراقها بالطلبات إذا كنت ترغب في ذلك ، لذلك ، إذا كانت "البيانات" قد وصلت بالفعل من ذاكرة التخزين المؤقت ، فلن تحتاج إلى الانتقال إلى ذاكرة التخزين المؤقت إلى منزلك والاستيلاء عليها ، والتي تم نقلها بالفعل.
• إذا كنت ترغب في استدعاء أي وظيفة في سياق معالجة الاستعلام على شبكة الإنترنت ، فأنت بحاجة إلى التأكد من عدم وجود استعلام SQL إضافي أو وصول إلى ذاكرة التخزين المؤقت في حروفها. إذا كان استدعاء مثل هذه الوظيفة أمرًا لا مفر منه ، فأنت بحاجة إلى التأكد من أنه لا يمكن تعديله أو تقسيم منطقه حتى لا يتم إجراء استعلامات غير ضرورية لقواعد البيانات / ذاكرات التخزين المؤقت.
• إذا كنت لا تزال بحاجة إلى الدخول في SQL ، فأنت بحاجة إلى التأكد من أنه لا يمكنك إضافة الحقول الضرورية أعلى أو أقل في التعليمات البرمجية إلى الاستعلامات الموجودة بالفعل في التعليمات البرمجية.

3. التدخل اليدوي غير الناجح في النظام

أمثلة على مثل هذه الحوادث: ALTER غير ناجح (الذي حمل قاعدة البيانات أو تسبب في تأخر النسخة المتماثلة) أو DROP غير الناجحة (صادف خطأ في MySQL ، حظر قاعدة البيانات عندما تم إسقاط جدول جديد) ؛ طلب ثقيل للسيد عن طريق الخطأ باليد ؛ لقد أجرينا العمل على الخادم قيد التحميل ، على الرغم من أننا اعتقدنا أنه عاطل عن العمل.

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

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

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

4. بيضة عيد الفصح

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

على سبيل المثال: overflow 32 bit auto_increment ؛ عدم الأمثلية في الكود / التكوين ، "اللقطة" بسبب الحمل ؛ تأخر النسخة المتماثلة (عادةً بسبب طلب دون المستوى الأمثل للنسخة المتماثلة التي تم تشغيلها بواسطة نمط استخدام جديد أو تحميل أعلى ، أو بسبب تحديث دون المستوى الأمثل على الرئيسي الذي تم استدعاؤه بواسطة نمط تحميل جديد وتحميل النسخة المتماثلة).

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

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

ومع ذلك ، كان لدينا أيضا بيض عيد الفصح ، لا علاقة للحمل. على سبيل المثال ، auto increment تبلغ 32 بت: بعد تسجيلين وبضعة مليارات من السجلات في الجدول ، يتم إدراج عمليات الإدراج التي يجب تنفيذها. لذلك يجب جعل مجال auto increment في العالم الحديث 64 بت. لقد تعلمنا هذا الدرس جيدًا.

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

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

5. أسباب خارجية

هذه هي الأسباب التي نعتقد أننا نسيطر عليها بشكل سيء. على سبيل المثال:

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

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

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

6. الافراج سيئة ، وظائف مكسورة

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

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

لوصف طريقة التعامل مع هذا النوع من الحوادث ، يكفي أن نتذكر حكاية ملتحية:

عُرض على الرياضيات والفيزياء نفس المهمة: غلي غلاية. يتم توفير الأدوات المساعدة: موقد ، غلاية ، صنبور ماء بالماء ، مباريات. كلاهما بالتناوب صب الماء في الغلاية ، وتشغيل الغاز ، وإضاءة عليه وضبط الغلاية على النار. ثم تم تبسيط المهمة: تم اقتراح غلاية مملوءة بالماء وموقد بالغاز المحترق. الهدف هو نفسه - غلي الماء. الفيزيائي يضع غلاية على النار. عالم الرياضيات يصب الماء من الغلاية ، ويطفئ الغاز ويقول: "لقد تقلصت المهمة إلى سابقتها". anekdotov.net

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

6.1. مثال

كانت هناك شكاوى ضخمة: لا يتم إغلاق الطلبات المدفوعة من خلال Apple Pay. بدأوا في فهم ، وتكررت المشكلة. لقد وجدنا السبب: قمنا بإدخال تحسينات على تنسيق expire date للبطاقات المصرفية عند التفاعل مع عملية الاستحواذ ، ونتيجة لذلك بدأوا في تحويلها على وجه التحديد للمدفوعات عبر Apple Pay بالتنسيق الذي كان متوقعًا من خدمة معالجة الدفع (في الواقع ، يمكن علاجها ، تشويه شيء آخر) ، لذلك بدأت جميع المدفوعات من خلال Apple Pay في الانخفاض. ثابتة بسرعة ، خرجت ، اختفت المشكلة. لكنهم "عاشوا" مع المشكلة لمدة 45 دقيقة.

باتباع آثار هذه المشكلة ، راقبنا عدد الدفعات الفاشلة عبر Apple Pay ، وقمنا أيضًا بتنبيه SMS / IVR مع عتبة غير صفرية (لأن المدفوعات الفاشلة هي المعيار من وجهة نظر الخدمة ، على سبيل المثال ، العميل ليس لديه أموال على البطاقة أو تم حظر البطاقة) . من هذه اللحظة ، عندما يتم تجاوز العتبة ، نتعرف على الفور على المشكلة. إذا كان الإصدار الجديد يمثل أي مشكلة في معالجة Apple Pay ، الأمر الذي سيؤدي إلى عدم تشغيل الخدمة ، ولو جزئيًا ، فسنتعرف على الفور من المراقبة ونعيد إصدار الإصدار في غضون ثلاث دقائق (يصف ما ورد أعلاه كيفية عمل عملية المتداول اليدوية). كان 45 دقيقة من التوقف الجزئي ، أصبح 3 دقائق. الربح.

6.2. أمثلة أخرى

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

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

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

كما ترون ، فإن النهج المتبع في هذا النوع من الحوادث هو نفسه دائمًا:

1. طرح الإصدار.
2. تعرف على المشكلة.
3. إصلاحه.
4. نحدد من خلال ما آثار (في قاعدة البيانات والسجلات و Kiban) يمكنك معرفة علامات المشكلة.
5. نرسم هذه العلامات.
6. نرجعها إلى الماضي وننظر إلى رشقات نارية / شلالات.
7. نختار العتبة الصحيحة للتنبيه.
8. عندما تنشأ مشكلة مرة أخرى ، نتعرف عليها على الفور من خلال تنبيه.

ما هو لطيف في هذه الطريقة: يتم إغلاق فئة كبيرة من المشكلات فورًا مع مخطط واحد وتنبيه (أمثلة على فئات المشكلات: عدم إغلاق الطلبات ، والمكافآت الإضافية ، وعدم الدفع عبر Apple Pay ، وما إلى ذلك).

مع مرور الوقت ، جعلنا تنبيهات البناء ومراقبة كل خطأ كبير جزءًا من ثقافة التنمية. لمنع هذه الثقافة من الضياع ، قمنا بإضفاء الطابع الرسمي عليها قليلاً. لكل حادث ، بدأوا في طلب تقرير من أنفسهم. التقرير عبارة عن نموذج مكتمل يحتوي على إجابات للأسئلة التالية: السبب الجذري ، طريقة الإلغاء ، التأثير على الأعمال التجارية ، الاستنتاجات. جميع البنود مطلوبة. لذلك ، إذا كنت تريد ذلك أم لا ، فستكتب الاستنتاجات. هذا التغيير في العملية ، بالطبع ، تمت كتابته بواسطة do's & dont's.

7. كوتان

, , -, . - ( , ) «». «». :-)

«» :

. — , . , ( ), ( ) , . ( , ).

. , . , : — , — . , « 500- 1 %» — . « 500- 1 %, - , - , - » — . , . ( ). , : , «», , , , . — . ( , ). .

. . , ( , , ), , : , , , .

. , , ( , ).

8. ?

— . . : , . , , . , , , .. — , — ! , . , , ? , , .. , , .

. . ( , ), , : , , , . , , . . . -, , . , , , — : .

9.

, .

?	?
.	.
( ) post-mortem.	.
do's & dont's.	, , .
, 5 .	.
, .	.
.	.
	.
.	.
.	.
SMS/IVR- .	.
( ) .	.
.	- .
( — slow.log).	- « ».
.	.
.	.
.	, , .
«» — .	, .
.	.

, ! , , , , !