كن مثل مونش ، أو بضع كلمات حول الواجب الفني

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



لمدة 8 سنوات ، نمت فريق Dodo Pizza IT من مطورين يخدمان دولة واحدة إلى 80 شخصًا يخدمون 12 دولة. قبل ثلاث سنوات ، انضممت إلى Dodo Pizza في منصب كبير موظفي Agile وبدأت في مساعدة الفرق على إنشاء عمليات وتنفيذ الممارسات الهندسية. في كثير من الأحيان كانت هذه التطبيقات بطيئة للغاية. بالإضافة إلى ذلك ، تبيَّن أنه عندما تعمل عدة فرق على نفس المنتج ، يكون من الصعب حملهم على الاحتفاظ برمز عالي الجودة.

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

خلفية

دودو بيتزا هي شركة سايبورغ تبيع البيتزا . يعتمد عملنا على منصة Dodo IS ، التي تدير جميع العمليات التجارية: تلقي الطلبات ، وصنع البيتزا ، وإدارة المخزون ، وإدارة الأفراد (الإدارة) وأكثر من ذلك بكثير. في غضون 8 سنوات فقط ، تطورنا من مطورين يقدمان بيتزا واحدة إلى 80 مطورًا يخدمان 498 بيتزا في 12 دولة.

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

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

القرف يحدث

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

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

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

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

قصة السقوط والصعود

الحالة الأولية: العمارة متجانسة

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

قصة حقيقية

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

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

الانهيار المبكر في عام 2017

14 فبراير. لمحبي التهنئة في 14 فبراير ، نصنع البيتزا الخاصة - Pepperoni في شكل قلب. سأتذكر دائمًا 14 فبراير 2017 ، لأنه في هذا اليوم ، عندما كانت جميع البيتزا تعمل بكامل طاقتها ، بدأ Dodo IS في الانخفاض. تحتوي كل بيتزا على 4-5 أقراص لإدارة الإنتاج: لأي ترتيب يقوم صانع البيتزا بتدوين العجينة أو وضع المكونات أو الخبز أو إرسالها للتسليم. في ذلك الوقت ، بلغ عدد مطاعم البيتزا 150+ ، تم تحديث كل قرص عدة مرات في الدقيقة. خلقت كل هذه الاستعلامات حملاً هائلاً على قاعدة البيانات توقفت عن الصمود وبدأت في الفشل. توفي دودو IS خلال ذروة المبيعات. ولكن كان هناك موسم عطلة مزدحم: 23 فبراير ، 8 مارس ، 1 و 9 مايو. خلال هذه الأعياد ، توقعنا نموًا أكبر في الطلبات.

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

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

بعض التحسينات بعد عام

على مدار العام ، نمت بشكل ملحوظ:

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

يبدو أننا يمكن أن نفخر بأنفسنا. لكن أمامنا كان خيبة أمل كبيرة.

فشل أثناء الحملة الإعلانية الفيدرالية. أزمة الثقة الثانية

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

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

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



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

الدروس المستفادة

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

• تراكم منتج واحد
• تماما عبر الأوامر الوظيفية وعبر مكونات الأوامر
• البرمجة الزوجية والغوغائية
• True Continuous Integration (CI) - تكامل الكود مع 12 فريق في فرع واحد
• عمل مبسط مع فروع (تطوير يعتمد على الجذع)
• النشرات المتكررة: النشر المستمر للخدمات الميكروية ، والإصدار اليومي للوحيد
• رفض فريق ضمان الجودة المنفصل ، يعد خبراء ضمان الجودة جزءًا من فريق التطوير

6 ممارسات اخترناها بعد الأزمة:

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

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

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

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


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

4. لا الانحدار اليدوي. وضعنا هدفًا للتخلص من الانحدارات اليدوية. استغرقنا 1.5 سنة للوصول إليه. لكن وجود هدف طموح طويل الأجل يجعلك تفكر في الخطوات المؤدية إلى الهدف.


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

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



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

النتائج

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

نتيجة لهذه التجارب خلال العام الماضي ، قمنا بتحسين جودة واستقرار Dodo IS بشكل كبير. إذا لم تتمكن مطاعم البيتزا لدينا خلال عطلة ربيع 2018 من العمل بسبب Dodo IS ، ثم في عام 2019 ، مع زيادة من 300 إلى 498 مطعم بيتزا ، فإن Dodo IS يعمل بلا عيب. لقد نجا بهدوء من ذروة المبيعات في العام الجديد ، خلال الحملة التسويقية الثانية وعطلة الربيع.

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

نتائج الأعمال

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

نتائج الفرق

نستخدم اليوم مجموعة واسعة من الأساليب الهندسية:

1. تماما عبر الأوامر الوظيفية وعبر مكونات الأوامر
2. زوج / الغوغاء البرمجة
3. التكامل المستمر - التكامل المستمر من 12 أوامر في فرع واحد
4. موضوع خبير كفريق واحد
5. لا يوجد فريق ضمان الجودة منفصل ، خبراء ضمان الجودة هم جزء من فرق التطوير
6. استبدال الانحدار اليدوي مع autotests
7. لا توجد سياسة خطأ (#Zerobugspolicy)
8. وقف الخط كسائق لتسريع عملية النشر

ماذا تعلمنا

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

1. الممارسات الهندسية تحمي الأعمال من الأزمة
2. لا تتراكم الديون التقنية. يمكن أن يفوت الأوان ويكلف الكثير
3. التغييرات التطورية تستغرق عدة مرات أطول من الثورية
4. الأزمة ليست دائما شيء سيء. استخدام الأزمة لإحداث ثورة في العمليات
5. ومع ذلك ، التدريب التطوري المطول مطلوب مقدما.
6. لا تطبق عمياء جميع الأساليب التي تريدها. بعض الطرق تنتظر في الأجنحة ، وعندما يصل ، ستستخدمها الفرق دون مقاومة. انتظر اللحظة المناسبة
7. مع مرور الوقت ، تبدأ الفرق نفسها في اتخاذ القرارات المهمة وتنفيذها. امنحهم بيئة مواتية للمحاولة ، ودعهم يفشلوا ويتعلموا من الأخطاء

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

---

شكر

أود أن أتوجه بالشكر الجزيل لجميع الأشخاص الذين ساعدوني في رحلتي من الأزمة إلى تحول LeSS. أشعر باستمرار دعمكم.

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

شكرا جزيلا لديمتري بافلوف ، مالك المنتج لدينا ، صديقي القديم ومدرب مشارك.

بفضل ألكساندر أندرونوف وأندريه موريفسكي لدعمهم.

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

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