مع هذا المقال ، أفتتح دورة قصيرة من مقالتين سأشرح فيها بالتفصيل كيف تمكنا من زيادة استقرار خدمات Citymobil عدة مرات على مدار عدة أشهر. تبدأ المقالة بقصة عن أعمالنا ، وعن المهمة ، وعن سبب ظهور مشكلة زيادة الاستقرار والقيود. Citymobil هو مجمع سيارات الأجرة سريع النمو. في عام 2018 ، زاد عدد الرحلات الناجحة بأكثر من 15 مرة. في بعض الأشهر ، تجاوز النمو 50٪ مقارنة بالشهر السابق.
نمت الأعمال على قدم وساق (وما زالت تنمو): ازداد العبء على الخوادم ، وحجم الفريق ، وتكرار النشرات. جنبا إلى جنب مع هذا ، ظهرت تهديدات جديدة لاستقرار الخدمة. واجهت الشركة المهمة الأكثر أهمية - عدم إيقاف نمو الأعمال لزيادة الاستقرار. سأخبرك في هذه المقالة كيف تمكنا من تحقيق هذه المهمة في وقت قصير.
1. بيان المشكلة: ما الذي نريد تحسينه بالضبط
قبل أن تقوم بتحسين شيء ما ، تحتاج إلى معرفة كيفية قياسه لفهم ما إذا كان هناك تحسن واضح. كلما اقتربت القيمة المقاسة من شروط الأعمال ، كلما كان ذلك أفضل. لأنه كلما زاد احتمال أن نحسن ما تحتاجه الأعمال حقًا. من وجهة نظر نجاحها ، فإن المعلمة الأكثر أهمية بالنسبة لنا هي عدد الرحلات المكتملة بنجاح (فيما يلي باختصار - عدد الرحلات). من خلال هذه المعلمة بالتحديد ، يقوم المستثمرون بتقييمنا عندما يتخذون قرارًا بشأن الاستثمارات. لمزيد من الرحلات ، وأكثر تكلفة الشركة.
بعض الرحلات تحقق ربحًا ، وبعضها - خسارة. لكن جميع الرحلات لها نفس القدر من الأهمية بالنسبة لنا ، حتى وإن كانت غير مربحة ، لأنها تتيح لك زيادة حصتها في السوق (في الواقع ، تعتبر الخسارة في الرحلات بمثابة دفعة لزيادة حصتها في السوق). لذلك ، كل رحلة إضافية يتم تلقيها جيدة ، وكل رحلة مفقودة سيئة. جميع الرحلات متساوية من حيث نجاح الأعمال.
من هنا حصلنا على معيار مفهوم لقياس الاستقرار: عدد الرحلات المفقودة هي الرحلات التي فقدناها بوضوح بسبب مشاكل فنية. مشكلة فنية تعني ، على سبيل المثال ، خطأ في الكود ، خطأ 500 ، تعطل في البنية التحتية ، تكامل مع خدمة شريك (على سبيل المثال ، خرائط جوجل).
2. كيف نحسب الرحلات المفقودة؟
من السهل حساب الرحلات المفقودة في بعض الأحيان وصعبة في بعض الأحيان. على سبيل المثال ، في حالة الحرمان التام من الخدمة ، عندما لا يعمل شيء على الإطلاق (pah-pah-pah) ، من السهل جدًا حساب الرحلات المفقودة. نحن نعرف الرسم البياني لاتجاه عدد الرحلات قبل السقوط ، ونرى اتجاه هذا الرسم البياني بعد السقوط ، ونكمل الخط الفاصل بين النقطة عندما بدأت بسيطة ونقطة انتهائها. منطقة الرسم البياني لعدد الرحلات تحت هذا الخط المكتمل هي رحلات مفقودة.
في الرسم البياني التالي ، يعرض الخط الأسود الرحلات في يوم معين والخط الأخضر يعرض الرحلات قبل أسبوع. المحور العاشر هو الوقت المناسب. على المحور ص ، عدد الرحلات في فترة زمنية معينة حول النقطة X. يتم رؤية قمة واضحة لأسفل في شكل مثلث بزاوية حادة. مجال هذا المثلث هو عدد الرحلات المفقودة. بالطبع ، هذا هو المبلغ التقريبي ، لأنه يتقلب الرسم البياني ، ولكننا نفهم أن دقة 10-20٪ كافية لنا لتقدير حجم الحادث لنشاط تجاري.
إذا لم تكن البساطة كاملة ، ولكنها جزئية (أيضًا ، pah-pah-pah) ، فإن الحساب يكون أكثر تعقيدًا بقليل. على سبيل المثال ، إذا كان هناك خطأ بسبب عدم توزيع 10٪ من الطلبات على الإطلاق بالسيارة ، فإننا نرى عطلًا في جدول السفر ، ثم انتعاشًا (بعد إصلاح الخلل). في حالة مماثلة ، تكون الرحلات المفقودة هي المنطقة المحصورة أعلاه بخط الاتجاه ؛ من أسفل - الجدول الفعلي لعدد الرحلات ، إلى اليسار - الخط العمودي لبداية التعطل ، إلى اليمين - الخط العمودي لنهاية التوقف.
يوضح الرسم البياني أدناه أن الذروة لأسفل ليست واضحة تمامًا ، ولكن وجود رحلات للأسبوع السابق دون هبوط إلى أسفل يساعد في فهم أن الذروة لأسفل هي خسارة. بالإضافة إلى ذلك ، توضح المقارنة بين الرحلات لليوم الحالي ونفس اليوم من الأسبوع إلى الأسبوع السابق أن الذروة الموجودة في أقصى اليمين ليست رحلات مفقودة ، ولكن الفشل المعتاد في هذا الوقت من اليوم ، لأن يرتبط بالأسبوع السابق.
عادة ما يكون من الصعب بناء خط الاتجاه ، لأنه الرسم البياني مسننة. في هذه الحالة ، تساعدنا المقارنة من أسبوع إلى أسبوع. إذا قمت برسم خطين على نفس الرسم البياني - الأسبوع الماضي والخط الحالي - يتضح أن كلا من منحني زائد أو ناقص متشابهان في الشكل ، ولكن تختلف فقط في أن أحدهما فوق الآخر (الأسبوع الحالي الحالي أعلى من السابق) ، على الرغم من وجود الاستثناءات). تعد المقارنة من أسبوع إلى أسبوع مهمة ، لأن كل يوم من أيام الأسبوع ، نظرًا لظروف مختلفة ، له شكل جدول مختلف. بالنظر إلى المخطط الأسبوعي ، يمكنك فهم أين يمكن أن يكون خط الاتجاه لرحلات اليوم.
من الواضح أن الرحلة المفقودة في حد ذاتها مشكلة أكبر بكثير من مجرد رحلة واحدة ضائعة. العميل الذي يرغب في المغادرة بطريقة أو بأخرى سوف يغادر ، على سبيل المثال ، يستخدم خدمة تنافسية وبالتالي قد لا يعود إلينا ، أو لا يعود إلا عندما يخيبه منافس ، وهذا أمر مستبعد ، لأن المنافسون أقوياء جدا. علاوة على ذلك ، حتى لو خسر منافس العميل ، فلن يكون العميل حقيقة أنه سيعود ، لأن كل شيء سيبدو في رأسه بحيث يكون لكل شخص خدمة سيئة ، وليس هناك أي فائدة من القفز على المنافسين.
وهذا يعني أن رحلة واحدة مفقودة بسبب مشاكل فنية تعني ، في الواقع ، عدد قليل من الرحلات المفقودة.
حتى لا يتم الخلط بيننا من حيث الشروط ، فإننا نسمي الرحلات المفقودة مباشرة بسبب مشكلة فنية ،
والرحلات الأساسية المفقودة ، والرحلات المفقودة بسبب مغادرة المنافس ،
والرحلات الثانوية المفقودة .
من الناحية المثالية ، لحساب إجمالي الأضرار التي لحقت بشركة ما نتيجة رحلة واحدة ضائعة ، يجب أن تفهم مقدار ما ولدته من رحلة ضائعة ثانوية. أي من الضروري ضرب عدد الرحلات المفقودة الأولية بمعامل
K معين ، والذي يمكن حسابه على أساس متوسط عدد مرات استخدام الخدمة ومتوسط وقت عودة المستخدم بعد مغادرة المنافس.
في ظل افتراض أن معامل
K لا يتغير كثيرًا بمرور الوقت ، لفهم اتجاه فقدان السفر ، يكفي أن نفكر في الرحلات الأولية المفقودة ومحاولة تقليل عددها ، لأن نسبة الرحلات المفقودة الأولية من فترة إلى أخرى ستكون هي نفسها نسبة الرحلات المفقودة الثانوية من فترة إلى فترة الفترة. مثال: إذا فقدنا 1000 رحلة أولية الشهر الماضي ، فقد فقدنا الرحلات الثانوية 1000 *
K ، وإجمالاً فقدنا 1000 * (1+
K ). إذا ، علاوة على ذلك ، فقدنا في الشهر الحالي 500 رحلة أساسية ، ثم فقدنا رحلات ثانوية 500 *
K ، وخسرنا في المجموع 500 * (1+
K ). في هذه الحالة ، بغض النظر عن قيمة المعامل
K ، بدأنا في خسارة الرحلات 1000 * (1+
K ) / (500 * (1+
K )) = أقل مرتين.
حتى لو تغير المعامل
K بمرور الوقت ، أي هي وظيفة الوقت K (t) ، فنحن لا نزال مهتمين بتقليل عدد الرحلات الضائعة الأساسية. لأنه إذا نمت K (t) بمرور الوقت ، فنحن ملتزمون ببذل المزيد من الجهود لفقد رحلات أولية أقل ، لأن الأضرار الناجمة عن فقدان كل واحد أعلى وأعلى. من ناحية أخرى ، إذا انخفضت K (t) بمرور الوقت ، فهذا يعني أنه لسبب ما ، يكون المستخدمون أكثر ولاءً لنا ، على الرغم من الخدمة السيئة ، مما يعني أنه يجب علينا ببساطة تلبية توقعاتهم!
المجموع: نحن نقاتل من أجل انخفاض مستمر في الرحلات الأساسية المفقودة.
3. حسنا ، نحن نعتبر الرحلات المفقودة. ما التالي؟
مسلحين بأداة مفهومة لقياس الرحلات المفقودة ، ننتقل إلى الجزء الأكثر إثارة للاهتمام - كيفية القيام بذلك من أجل تقليل الخسائر؟ وبينما لا تبطئ النمو الحالي! نظرًا لأننا بدا لنا ذاتيًا أن حصة الأسد من المشكلات الفنية بسبب فقدان الرحلات مرتبطة بالخلفية ، فقد قررنا أولاً الاهتمام بعملية تطوير الواجهة الخلفية. واستشرافًا للمستقبل ، أقول إنه تحول إلى هذا الحد - فقد أصبحت الواجهة الخلفية ساحة المعركة الرئيسية للرحلات المفقودة.
4. كيف تعمل العملية
تحدث المشكلات عادةً نتيجة لف الكود والإجراءات اليدوية الأخرى. الخدمات التي لا تتغير أبدًا ولا تتعرض مطلقًا لها ، تفشل أيضًا في بعض الأحيان ، ولكن هذا الاستثناء ليس سوى قاعدة تأكيد.
أطرف مثل هذا الاستثناء في تجربتي كان الخدمة التالية. عندما عملت في RBC في عام 2006 (الله ، كم عمري!) ، ثم في إحدى خدمات البريد في RBC ، كانت هناك بوابة تمر عبرها كل حركة المرور والتي فحصت عناوين IP لأنها مدرجة في القائمة السوداء. عملت الخدمة على فري ، وأنها عملت بشكل صحيح. ولكن في يوم من الأيام ، توقف عن العمل. خمن السبب؟ انهار قرص على هذا الجهاز (الكتل السيئة المتراكمة والمتراكمة والمتراكمة). انهارت قبل 3 سنوات من رفض الخدمة في الخدمة (!). وعاش كل شيء مع قرص مبعثر. وبعد ذلك ، قرر "الفرخ" ، لأي سبب غير معروف لها بدوافع فرياخوف ، أن يتحول فجأة إلى قرص متداعى ويتجمد في النهاية. أنا متأكد من أن لينكس لن يفعل ذلك. ولكن هذا هو holivar منفصلة.
لتلخيص ما ورد أعلاه ، فإن المشاكل بسبب التدخل اليدوي. ما إن كنت في طفولتي ، في عمر 10-12 عامًا ، في إحدى رحلاتي إلى الغابة ، سمعت من أبي عبارةً تذكرتها طوال حياتي: "حتى لا تخرج النار ، لا تحتاج فقط إلى لمسها". أعتقد أن الكثير منا يتذكر اللحظات التي ألقينا فيها الحطب في نار مشتعلة بالفعل وخرجت لسبب غير معروف.
خلاصة القول: تنشأ المشاكل من خلال الإجراءات اليدوية لشخص ما ، على سبيل المثال ، إلقاء الحطب في النار المشتعلة بالفعل ، والتي تقطع الأكسجين وتطفئ الحريق ، أو عن طريق طرح الكود مع الخلل في الإنتاج. لذلك ، من أجل فهم سبب المشكلات في الخدمات ، يجب أن تفهم تمامًا كيف يحدث النشر وكيف تعمل عملية التطوير.
ركزت العملية بالكامل على التطور السريع وتم تنظيمها على النحو التالي:
- 20-30 إصدارات في اليوم ؛
- المطورين طرح أنفسهم ؛
- اختبار سريع في بيئة اختبار من قبل المطور ؛
- الحد الأدنى الآلي / وحدة الاختبارات ، الحد الأدنى من الاستعراضات.
في الواقع ، فإن المطورين في أصعب الظروف ، دون المساحات الخلفية المغطاة في مواجهة ضمان الجودة ، مع وجود مجموعة كبيرة من المهام والتجارب الإنتاجية المهمة للأعمال ، عملوا بشكل مركّز ومنسق قدر الإمكان ، وحل المشاكل المعقدة بطرق بسيطة ، ولم يسمحوا للشفرة بأن "تنمو" ، وقضايا العمل مفهومة جيدًا ، مسؤولة جدا عن التغييرات ، تراجعت بسرعة الخمول. Citymobil ليست فريدة من نوعها هنا. منذ 8 سنوات في Mail.ru Mail ، عندما جئت للعمل هناك ، كان هناك موقف مشابه. وبدأنا أيضًا Mail.ru Cloud بسرعة وببساطة ، من دون curtsy. وبالفعل تغيرت العمليات في وقت لاحق من أجل تحقيق قدر أكبر من الاستقرار.
من المؤكد أنك لاحظت ذلك بنفسك: عندما لا يغطي أحد ظهرك ، عندما تكون وحدك مع الإنتاج ، عندما يسحق عبء المسؤولية الكبير - أنت تعمل المعجزات. أنا شخصيا واجهت هذه التجربة (حتى أكثر المتشددين). ذات مرة ، في القرن الماضي (التقدير ، كانت الإنترنت بالفعل في القرن الماضي ، وأنا مندهش عندما أتذكر) ، وعملت كمطوّر وحيد لخدمة البريد newmail.ru ، ونشرتها بنفسي ، كما اختبرت الإنتاج بنفسي لنفسك من خلال
if (!strcmp(username, “danikin”)) { … some new code… } :-) لذلك ، هذا الموقف قريب مني.
لم أتفاجأ إذا علمت أنه مع هذا النهج البسيط "على الركب" ، بدأت العديد من الشركات الناشئة ، سواء الناجحة أو غير الناجحة ، ولكن مدفوعة بنفس الشغف - التركيز على النمو السريع للأعمال التجارية والاستحواذ على السوق.
لماذا كانت العملية على وجه التحديد في سيتي موبيل؟ في البداية ، كان هناك عدد قليل من المطورين. لقد عملوا في الشركة لفترة طويلة وكان لديهم فهم جيد للرمز والأعمال. وكانت النشرات عدة مرات في اليوم. كانت الأخطاء نادرة للغاية. عملت العملية بشكل مثالي لتلك الظروف.
5. لماذا تهدد العملية الجيدة الاستقرار؟
مع زيادة الاستثمار في المشروع ، جعلنا خطط منتجاتنا أكثر عدوانية وبدأنا في توظيف العديد من المطورين. زاد عدد النشرات على الإنتاج ، ولكن من المتوقع أن تنخفض جودتها ، لأن اللاعبين الجدد دخلوا في النظام وجوهر العمل التجاري في ظروف القتال. مع زيادة عدد المطورين ، بدأ الاستقرار في الانخفاض لا حتى بشكل خطي ، ولكن من الناحية التربيعية (نما عدد الإصدارات بشكل خطي ، كما انخفضت جودة التدريجي المتوسط خطيًا ؛ "خطيًا" * "خطيًا" == "تربيعيًا").
كان من الواضح أنه كان من المستحيل ترك العملية بهذا الشكل. ببساطة لم يتم سجنهم في ظل ظروف جديدة. ولكن كان من الضروري تغييره دون المساس بوقت السوق ، أي مع الاحتفاظ بـ 20-30 إصدارًا يوميًا (مع زيادة عددهم بما يتناسب مع حجم الفريق). في الواقع ، لقد كان الأمر برمته في عدد كبير من الإصدارات. لقد نمت بسرعة ، وقمنا بإجراء الكثير من التجارب ، وقمنا بسرعة بتقييم نتائجها وأعدنا تجارب جديدة. لقد اختبرنا بسرعة فرضيات المنتج والأعمال ، ودرسناها وطرحنا فرضيات جديدة ، قمنا باختبارها سريعًا مرة أخرى ، وما إلى ذلك. لم نكن نريد خفض هذا المعدل على أي حال. علاوة على ذلك ، أرادوا زيادته ، وزيادة سرعة توظيف المطورين. أي تسببت أفعالنا التي تهدف إلى نمو الأعمال في تهديد للاستقرار ، لكننا لم نرغب في تصحيح هذه الإجراءات بأي شكل من الأشكال.
6. حسنًا ، المهمة واضحة ، والعملية واضحة. ما التالي؟
من ذوي الخبرة في Mail.ru Mail و Mail.ru Cloud ، حيث تم وضع الاستقرار من نقطة ما في المقدمة ، حيث يتم عرض التحديثات مرة واحدة في الأسبوع ، والوظيفة التفصيلية وحالات الاختبار ، كل شيء مغطى باختبارات السيارات والوحدة ، تتم مراجعة الرمز مرة واحدة على الأقل ، وأحيانًا ثلاث مرات ، صادفت حالة جديدة تمامًا.
يبدو أن كل شيء بسيط: كرر العملية في Citymobil كما في Mail أو the Cloud وقم بزيادة ثبات الخدمة. ولكن ، كما هو الحال في هذه النكتة الفاحشة ، توجد فروق دقيقة: أ) يتم تنفيذ النشرات في Mail / Cloud مرة واحدة في الأسبوع ، وليس 30 مرة في اليوم ، وفي Citymobil لم نرغب في التضحية بتكرار الإصدارات ، ب) في Mail / Cloud تمت تغطيته بواسطة اختبارات السيارات / الوحدات ، وفي Citymobil لم يكن لدينا وقت وموارد لهذا الغرض ، تم تكريس جميع قوى تطوير الواجهة الخلفية لاختبار الفرضيات وتحسين المنتجات. في الوقت نفسه ، لم يكن هناك عدد كافٍ من مطوري الواجهة الخلفية ، حتى في سرعات التوظيف العالية (شكر خاص لـ HR Citymobil - فهذه هي أفضل الموارد البشرية في العالم! أعتقد أنه سيكون هناك مقال منفصل حول عملية الموارد البشرية لدينا) ، أي أنه لا توجد طريقة للدخول في اختبارات ضيقة ومراجعات دون إبطاء.
7. عندما لا تعرف ماذا تفعل ، ثم تعلم من الأخطاء
إذن ما الذي فعلناه بطريقة سحرية في سيتي موبيل؟ قررنا أن نتعلم من الأخطاء. طريقة تحسين الخدمة من خلال التعلم من الأخطاء قديمة قدم العالم. إذا كان النظام يعمل بشكل جيد ، فهذا جيد. إذا كان النظام يعمل مع الأخطاء ، فهذا أمر جيد أيضًا ، لأنه يمكنك التعلم من هذه الأخطاء. هذا يبدو سهلا. للقيام ... هو أيضا بسيط. الشيء الرئيسي هو وضع هدف.
كيف درسنا؟ بدأنا بتسجيل المعلومات بدقة عن كل حادث كبير أو ثانوي. بصراحة ، لم أكن أريد في البداية القيام بذلك ، لأنني كنت آمل في حدوث معجزة واعتقدت أن الحوادث ستتوقف من تلقاء نفسها. بالطبع ، لم يتوقف شيء. حقائق جديدة طالبت بقسوة التغيير.
بدأنا تسجيل جميع الحوادث في جدول Google مشترك. لكل حادث ، تم تقديم المعلومات الموجزة التالية:
- التاريخ والوقت والمدة
- السبب الجذري
- ماذا فعلوا لحل المشكلة
- التأثير على النشاط التجاري (عدد الرحلات المفقودة والتأثيرات الأخرى) ؛
- الاستنتاجات.
بالنسبة للحوادث الكبرى ، أنشأنا ملفات كبيرة منفصلة مع أوصاف دقيقة تلو الأخرى ، من اللحظة التي بدأ فيها الحادث إلى لحظة الانتهاء منه: ما الذي فعلناه ، وما هي القرارات التي اتخذناها (عادةً ما يطلق على مثل هذه الأوصاف تحليل ما بعد الوفاة). وفي الجدول العام أضفنا روابط لمثل هذا الوفاة.
كان الغرض من هذا الملف واحدًا: استخلاص استنتاجات ، سيؤدي تنفيذها إلى تقليل خسائر السفر. علاوة على ذلك ، كان من المهم للغاية صياغة "السبب الجذري" بدقة وما هي "الاستنتاجات". هذه الكلمات مفهومة في حد ذاتها. لكن الجميع يفهم بطريقته الخاصة.
8. مثال على خطأ تعلموه
السبب الجذري هو القضاء على الذي سيمنع وقوع حوادث مماثلة في المستقبل. والاستنتاجات هي كيفية القضاء على السبب الجذري (أو تقليل احتمالية حدوثه).
السبب الجذري دائمًا أعمق مما يبدو. الاستنتاجات هي دائما أكثر تعقيدا مما يبدو. من أجل عدم التهدئة وعدم التركيز على ما يبدو ، يجب على المرء أن يكون غير راض دائمًا عن السبب الجذري المفترض وأن يكون غير راض دائمًا عن الاستنتاجات المزعومة. هذا السخط يخلق حماسة لمزيد من التحليل.
اسمح لي أن أعطيك مثالاً: تم طرح الكود - سقط كل شيء ، استعاد - كل شيء يعمل. ما هو السبب الجذري؟
طرح ، كما تقول. لو لم تكن لن يكون هناك أي حادث. فما هو الاستنتاج: لا تطرح؟ استنتاج سيء (ضار لرجال الأعمال ، على وجه الدقة). وهذا هو ، على الأرجح ليس السبب الجذري ، تحتاج إلى حفر أعمق.
طرح مع علة . السبب الجذري؟ دعنا نقول. كيفية اصلاحها؟ عن طريق الاختبارات ، أنت تقول. ما الاختبارات؟ على سبيل المثال ، تراجع كامل لجميع الوظائف. هذا هو الاستنتاج الجيد ، تذكرها. ولكن يجب تحسين الاستقرار هنا والآن ، في حين لا يوجد تراجع كامل. تحتاج إلى حفر أعمق.
قم بالبدء باستخدام خطأ حدث بسبب قيامنا بتصحيح الطباعة في جدول في قاعدة البيانات ، وقمنا بتحميله إلى أبعد من القياس وكسرت قاعدة البيانات تحت التحميل . هذا بالفعل أكثر إثارة للاهتمام. يصبح من الواضح على الفور أنه حتى اختبار الانحدار الكامل لن ينقذك من هذه المشكلة. بعد كل شيء ، لن يكون لقاعدة الاختبار نفس حمل الإنتاج.
ما هو السبب الجذري لهذه المشكلة ، إذا قمت بحفر أعمق؟ لمعرفة ذلك ، تحدثنا مع المطور. اتضح أنه اعتاد على حقيقة أن القاعدة تتواءم مع الأحمال. ولكن في ظل ظروف النمو السريع للمشروع ، تمكنت القاعدة أمس ، ولكن اليوم لم يعد هناك. القليل منا عمل على مشاريع تنمو بنسبة 50٪ من شهر إلى آخر. على سبيل المثال ، بالنسبة لي هذا هو أول مشروع من هذا القبيل. بعد الانغماس في مثل هذا المشروع ، تبدأ في إدراك الحقائق الجديدة. حتى أول مرة تصادف فيها شيئًا ما ، فلن تعرف أبدًا ما يحدث.
اقترح المطور على الفور الحل الصحيح لسبب السقوط: هل قم بتصحيح الطباعة في ملف ، واكتب الملف في وضع عدم الاتصال بالإنترنت بواسطة cron إلى قاعدة البيانات في دفق واحد باستخدام الشرائح. إذا كان هناك الكثير من طباعة التصحيح ، فلن تتوقف قاعدة البيانات ، ستظهر معلومات تصحيح الأخطاء فقط في الوقت المناسب. من الواضح أن هذا المطور قد تعلم بالفعل من خطأه ولن يكرره في المستقبل. لكن المطورين الآخرين بحاجة أيضًا إلى معرفة ذلك. كيف؟ تحتاج أن أقول لهم. كيف نجعلها مسموعة؟ قل لهم القصة بأكملها من البداية إلى النهاية ، وشرحوا ما الذي أدى إلى ذلك واقترحوا على الفور كيفية القيام بذلك ، وكذلك الاستماع إلى أسئلتهم والإجابة عليها.
9. ماذا يمكنك أن تتعلم من هذا الخطأ ، أو تفعل وما لا تفعل
لذلك ، نواصل تحليل هذا الحادث. الشركة تنمو بسرعة ، يأتي موظفون جدد. كيف سيتعلمون من هذا الخطأ؟ أخبر كل موظف جديد؟ من الواضح ، سيكون هناك المزيد والمزيد من الأخطاء - كيف تجعل الجميع يتعلمون منها؟ الجواب واضح تقريبًا: احصل على ملف ما يجب فعله ولا يجب فعله (اقرأ باسم "doos and donts")! في الترجمة المجانية إلى اللغة الروسية ، فإن المصطلح "ما يجب فعله وما يجب" لا يعني "ما هو جيد وما هو سيء". في هذا الملف نكتب كل الاستنتاجات حول موضوع التنمية. نعرض الملف على جميع الموظفين الجدد ، ونعرضه أيضًا في الدردشة العامة للمطورين في كل مرة يتم فيها تحديث الملف ، ونرجو من الجميع قراءته مرة أخرى (لتحديث المعرفة القديمة والجديدة على حد سواء).
ستقول أنه لن يقرأ الجميع بعناية. ستقول إن الكثيرين سوف ينسون فورًا بعد القراءة. وسوف تكون على حق في كلتا الحالتين. لكنك لن تنكر أن شخص ما سوف يكون لديه شيء في رأسه. وهذا جيد بالفعل. وفقًا لتجربة Citymobil ، يأخذ المطورون هذا الملف على محمل الجد ، والحالات التي نسي فيها بعض الدروس كانت نادرة للغاية. بالمناسبة ، يمكن اعتبار حقيقة أن الدرس قد تم نسيانه مشكلة ويمكن استخلاص استنتاج منه ، أي فهم التفاصيل وفهم كيفية تغيير العملية للمستقبل. في كثير من الأحيان ، يؤدي هذا الحفر إلى صياغة أكثر دقة ووضوح في ما يجب عمله وما يجب عليه.
استنتاج من الحادث الموضح أعلاه: قم بإنشاء ملف ما يجب فعله وما يجب عليه ، واكتب ما تعلمته فيه ، وأظهر الملف للفريق بأكمله واطلب من جميع القادمين الجدد دراسته.
من النصيحة العامة التي فهمناها في تحليل الحوادث: لا تستخدم عبارة "العامل البشري". بمجرد أن تقول هذا ، فهم جميعًا على الفور حتى لا يلزم القيام بأي شيء ، ليست هناك حاجة إلى استنتاجات ، والناس كانوا مخطئين ، وخاطئين ، وسوف يكونون على خطأ. لذلك ، بدلاً من نطق هذه العبارة ، من الضروري استخلاص
استنتاج محدد . الخلاصة - هذه خطوة صغيرة على الأقل ، ولكنها خطوة صغيرة في تغيير العملية وتحسين المراقبة وتحسين الأدوات الآلية. من هذه الخطوات الصغيرة يتم خياطة نسيج الخدمة المستقرة!
10. بدلا من خاتمة
في
الجزء الثاني ، سوف أخبركم بأنواع الحوادث وفقًا لتجربة Citymobil وأغوص في تفاصيل كل نوع من أنواع الحوادث ، وسأخبرك أيضًا بما هي الاستنتاجات التي توصلنا إليها من الحوادث ، وكيف غيرنا العملية ، والتي أدخلت الأتمتة. الأكثر إثارة للاهتمام في الجزء الثاني! ترقبوا!