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

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

1. الافراج عن سيئة: علة

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

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

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

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

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

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

1.1. مثال على انقطاع التيار بسبب خلل

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

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

1.2. أمثلة أخرى

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

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

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

كما يمكنك القول ، نحن نستخدم نفس النهج للتعامل مع جميع الحوادث من هذا النوع:

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

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

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

2. كوتان

كان مستوى التشغيل التلقائي للعمليات في ارتفاع ، وقررنا أن الوقت قد حان لإنشاء واجهة ويب تعرض حالة عملية التطوير الحالية. أطلقنا على واجهة الويب هذه "Kotan" (من الكلمة الروسية "roll" ، "to roll" :-)

"Kotan" لديه الوظائف التالية:

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

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

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

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

3. ما الذي تغير في عملية تطوير البرمجيات؟

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

من أجل التأكد من أن كل حادثة لها الوجبات الجاهزة ، فعلنا ما يلي:

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

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

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

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


شكرا للقراءة حتى النهاية. حظا سعيدا لعملك! أتمنى لكم أقل من أوامر المفقودة والمعاملات والمشتريات والرحلات وما هو مهم بالنسبة لك!