Get best of the week

قصة طائر الدودو من جنس العنقاء. سقوط دودو العظيم

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




تاريخ الخريف العظيم


يوم 1. الحادث الذي كلفنا ملايين الروبل


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



شهدنا في ذلك اليوم واحدة من أخطر شلالات دودو IS. أسوأ ما في الأمر أنه في اليوم الذي سبق إطلاقنا أول حملة إعلانية تلفزيونية فيدرالية بميزانية قدرها 100 مليون روبل. لقد كان حدثًا رائعًا لـ Dodo Pizza. كما كان فريق تكنولوجيا المعلومات على استعداد جيد للحملة. قمنا بتبسيط النشر وتبسيطه - الآن بمساعدة زر واحد في TeamCity يمكننا نشر مجموعة متجانسة في 12 دولة. لم نفعل كل شيء ممكن ، وبالتالي أخطأنا.

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



لم يكن لدينا خيار سوى أن نشمر عن سواعدنا ونجلس لتصحيح الوضع. منذ يوم الأحد (22 أبريل) ، عملنا في وضع صعب ، ولم يكن لدينا الحق في ارتكاب خطأ.

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

فشلان أدىان إلى إطلاق تأثير الدومينو


من الجدير البدء بكيفية بدء كل شيء وأين أخطأنا.



في يوم السبت 04/21/2018 حوالي الساعة الخامسة مساءً ، لاحظنا أن عدد الأقفال في قاعدة البيانات بدأ ينمو - نذيرًا بالمشاكل. كان لدينا دليل تشغيل جاهز للحل ، كما فهمنا من أين تأتي هذه الأقفال.

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

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

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

يوم 2. القضاء على الحوادث


كانت استجابة الفريق كاشفة للغاية. كتب مركز خدمتنا منشورًا على Slack ، وجاء الجميع في اليوم التالي - في 22 أبريل ، بدأ العمل في الساعة 8:30 صباحًا. لا يحتاج أحد إلى الإقناع أو يُطلب منه الحضور يوم إجازته. فهم الجميع كل شيء: ما يحتاج إلى دعم ومساعدة بيديه ورأسه في الاختبار وتحسين الاستعلام والبنية التحتية. حتى أن بعضهم جاء مع العائلة بأكملها! جاء الرجال من الفرق المجاورة ، غير المرتبطة بتكنولوجيا المعلومات ، إلى المكتب مع الطعام ، وجلب مركز الاتصال قوات إضافية فقط في حالة. اتحدت جميع الفرق في هدف واحد - الصعود!



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

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

  1. تنفيذ المخطط بأمر جديد في تطبيق الهاتف المحمول.
  2. تحسين عملية إنشاء الطلب.

من خلال تنفيذ هذه الأمور ، يمكننا التأكد من أن Dodo IS لن يسقط.

نحدد جبهة العمل والعمل


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

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

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

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

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

في حوالي الساعة 15:00 ، تم نشر التحديث إلى نصف الشبكة (هذا هو حوالي 200 بيتزا). في الساعة 15:30 ، تأكدنا من أن كل شيء يعمل بشكل جيد وتشغيل الشبكة بالكامل. ساعدت ميزات التبديل ، والنشر السريع ، والانحدار المتقطع إلى أجزاء و API الثابت على القيام بكل ذلك.

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

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

نظم العملية


في الصباح ، كان لدينا المزامنة الوحيدة لليوم ، اقتحمنا الفرق وتركنا للعمل.

في البداية ، احتفظنا بسجل التغييرات والمهام بالكامل مباشرة في Slack ، لأنه في البداية لم يكن هناك الكثير من المهام. لكن عددهم كان ينمو ، لذلك انتقلنا بسرعة إلى Trello. تم إعلام التكامل المدمج بين Slack و Trello بأي تغيير في الحالة في اللغز.

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

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

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

بعد ذلك اليوم ، كان من الضروري الخروج مع الشعور بأننا فعلنا كل ما في وسعنا. وحتى اكثر. وفعلنا ذلك! في الساعة 15:30 ، تم طرح مخطط جديد لتلقي الطلب لتطبيقات الهاتف المحمول عبر الشبكة. وضع Hackathon ، أقل من 20 عملية نشر لكل إنتاج يوميًا!

كانت مساء 22 أبريل هادئة وواضحة. لا يقع ولا تلميح واحد هو أن النظام قد يكون سيئا.

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

إعادة الولادة


كان أسبوع 23 أبريل جهنم. بعد ذلك ، قلنا لأنفسنا أننا بذلنا قصارى جهدنا بنسبة 200٪ وفعلنا كل ما في وسعنا.

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

  • الإنعاش - عندما تحتاج إلى إنقاذ مريض يموت.
  • العلاج - عندما تكون هناك أعراض ، لكن المريض لا يزال على قيد الحياة.




الإنعاش


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

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

علاج او معاملة


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

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

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

أسابيع الجحيم: عملية التنظيم


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



ثلاث مرات في اليوم كان هناك التزامن ، والوقوف المشترك ، كما هو الحال في scrum الكلاسيكية. لـ 40 شخص. مرتين فقط في ثلاثة أسابيع (لما يقرب من 90 مزامنة) لم نلتقي لمدة 30 دقيقة. استمرت أطول مزامنة 57 دقيقة. على الرغم من أنها عادة ما تستغرق 20-30 دقيقة.

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

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



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

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

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

في اليوم التالي X: اختبار القوة


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

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

سقوط الخريف العظيم و 6 ممارسات


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



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



ونتيجة لذلك ، كانت هناك 6 ممارسات مهمة أود التحدث عنها بمزيد من التفصيل.

  1. Top N . , . Product Owners , , , . . , . , , , . , . N – Lead Time .
  2. . . -, , . , , , . .
  3. . , « » . , . , , . , - . Dodo IS. .
  4. Pull Request. , Pull Request, - . . , , , , - . , . , . 15 .
  5. Performance- — . performance- . , . Performance- . baseline , PR . , .
  6. Performance . — . , , -, , , . . , .



1.

21.04.2018 – Dodo IS. ?


(Site Reliability Engineering): . , .

(Site Reliability Engineering, Product Owner Dodo IS): . , , .

auth’, . . , .

, () :



. , .

. , . . -. , , . - , , . , -, , .

. redis, . . - , . .

Dodo IS . . , . , , , , . , — .

. « ». « , » .

- ?


:

– . . . , . . .

:

. , . ( ), - . .

. :

  1. .
  2. .
  3. , .

?



:

, , , .

:

, , . , .

? ?



: , – .

:

  1. — . - - .

    , . 2018 , PerformanceLab, .
  2. , . Less-.
  3. . 2018 -, . , . - 2018 .
  4. async . , 21.04.2018 . , . async.
  5. . , SaveOrder async-await. , . : , LF, 20 . , . , . !

    , , , .

    , , . — -. .
  6. . , (, ). , . «» . nginx , - , .

    : innodb_lock_wait_timeout = 5; innodb_rollback_on_timeout = ON. . , , , , .

, ?


:

  1. , , , . , .
  2. , .
  3. , , , . – .

:

  1. .
  2. . , , -. .
  3. . , - , .

, ?


:

«» , «». , , . .

:

, . , , . .

2. , (Dodo IS Architect)
— , . , — .

, , . , (, , ) .

IT-. Dodo IS, . …

X , . . Dodo IS , , , . , , , . . 146%, . , Dodo IS ?

, . , , . , . , !

, . « »: 11- , , 2 . «» . 3-4 , . , . .

, , . . Dodo IS , « ». ! ( ).

, Dodo IS , . Dodo IS . « », , . ( ), loadtest, , .

More articles:


All Articles