مرحبا بالجميع! اسمي ألكسندر أفينوف وأنا قائد فريق فريق معالجة الطلبات في لامودا. اليوم أريد أن أخبركم عن كيفية حشد الدعم.
أولاً ، دعنا نتحدث عن كيفية دمجها في عملياتنا وكيف نخطط بشكل عام لعملنا وتكراراتنا وتكراراتنا.
بعد ذلك سوف أخبرك من أين يمكن أن يأتي الدعم وأنواعه.
سأشارك تجربة كيفية تعاملنا داخل الفريق مع كل نوع من أنواع الدعم.
في النهاية ، نحن نعتبر إيجابيات وسلبيات الممارسات التي نستخدمها ونلخصها.
لدى فريقي الآن نظامان. الأول هو شيء كبير ومخيف يسمى
معالجة الطلب . هذا هو النظام الذي يقوم بأتمتة دورة حياة الطلب من عملية الإنشاء إلى التسليم (أو الإرجاع).
تدور الخدمة على PHP 7 ، ملفوفة في Docker وتُدار من قِبل Kubernetes ، ولكن في الوقت نفسه يتم تنفيذها على إطار Zend1 وقطع Symfony 2. ربما أولئك الذين قاموا بالبرنامج على PHP الآن قد ارتجفوا. بالنسبة للباقي ، سأشرح أن Zend1 هو إطار انتهى عمره عام ونصف العام. لم يعد مدعومًا ولا يحتوي على تصحيحات أمان.
المشروع كبير (أكثر من 150 ألف سطر من الكود) ، وهو لا يقوم بعمله كثيرًا. على سبيل المثال ، لا يقوم فقط بمعالجة الطلبات ، ولكن لسبب ما يرسل البريد والرسائل القصيرة ويدفع وينقل البيانات إلى أنظمة أخرى. لذلك ، نحن نقطعها إلى خدمات ميكروية منفصلة.
أول ما قدمناه من المتراصة هو ما يسمى
أداة استرداد . إنه الخدمة الثانية التي يديرها فريقي وهو المسؤول عن إعادة الأموال تلقائيًا إلى العميل
(المزيد في تقرير زميلي) .
على الرغم من أن أداة استرداد الأموال لديها كومة تكنولوجية حديثة ، إلا أنها لا تزال تولد مجموعة من الدعم بسبب إرث معالجة الطلبات.
يحدث هذا بسبب حقيقة أننا اتخذنا عملية تجارية معينة ، والتي كانت مبنية على الكثير من ملفات excel ، ونقلها إلى نظام جديد يعمل من خلال Kafka ، ويتفاعل أيضًا مع نظامين. بالطبع ، عند تقديم نظام جديد وتغيير العملية التجارية ، حصلنا على الدعم. وعلى مدى سنوات عديدة من العمل مع هذا ، اكتسبنا بعض الخبرة.
أعتقد أن الناس ينقسمون إلى فئتين: أولئك الذين لديهم نظام إنتاج يولد الدعم ويلعن الكذابين. لذلك ، سأشارك الخبرات التي قد تكون مفيدة في تحسين عملياتك. إذا كانت الحلول المقترحة (مجتمعة أو بشكل منفصل) مناسبة لك ، فسوف يظهر المزيد من الوقت لتطوير وظائف نظامك ، وتحليل الأعمال المتراكمة ، وليس للعمل مع الدعم.
سيتطلب الحديث عن الأدوات المستخدمة سياقًا ، لذلك سنتحدث أولاً عن الأشياء الأساسية.

العمليات والأدوار
كيف نعمل بدعم وما هو المكان الذي يستغرقه سباقنا السريع؟
الدلاء المتناسبة هي ما أسميه دلاء لدينا .

نحن نأخذ 10 ٪ من الأعمال المتراكمة التقنية حتى لا تتركل ولا تتراكم إلى أجل غير مسمى.
يتم أخذ ما يقرب من 20 ٪ من العدو لوضع بعض المخاطر. على سبيل المثال ، كان شخص ما يقوم بمهمة ، لكن هذا الشخص "اصطدم بالحافلة". سيكون على الشخص التالي إعادة فحص السياق. نتيجة لذلك ، لن ندخل في التقييم ، وسيكون كل شيء سيئًا.
بعد ذلك ، نضع الدعم المخطط. وهذا هو ، ونحن نعلم بالفعل أن هناك شيئا خطأ. هذا شيء لا يحترق كثيرًا ، وسوف نقوم بإصلاحه.
ولكن الشيء الأكثر إثارة للاهتمام هو دعم غير مخطط له. أي أننا نفترض أن شيئًا ما يمكن أن ينكسر خلال فترة التكرار ، وسنقضي وقتًا في عمليات الإصلاح.
ال 30 ٪ المتبقية هي المشاريع.
ربما لاحظت أنه تبين أن أكثر من 100 ٪. هذا يرجع إلى حقيقة أننا نحاول دائما أن نفعل أكثر مما نستطيع حقا. أحيانًا ننجح ، وأحيانًا لا ننجح.
معلمات الدعم الرئيسية
نعطي كل تذكرة دعم تقييمًا وفقًا للمعايير التالية:
- الحرجه لرجال الاعمال. ما مدى أهمية هذا بالنسبة إليهم وإلى أي مدى يؤدي هذا إلى كسر العملية التجارية؟
- جيش تحرير السودان. كم من الوقت يجب أن نأخذ المشكلة في العمل وحلها؟
- الأولوية.
إذا حدث خطأ ما مع مستخدمي أنظمتنا ، فإنهم يقومون بالإبلاغ عن ذلك إلى خدمة الدعم ويوضحون أن إحدى الحوادث تمنع عملية الأعمال جزئيًا أو كليًا. الدعم يجلب على الفور تذكرة جديدة للنظام المسؤول ويضعها على رأس
الأولويات .
الحرجية والأولوية مصطلحات مختلفة.
أنواع الأولويةمانع - شيء كسر كل شيء تماما ، توقفت عن العمل. لا يتم إنشاء الطلبات ، ولا يتم تسليمها ، ولا يتم قبول المدفوعات وما إلى ذلك.
يعد
الميجور شيئًا أقل أهمية ويمكن إصلاحه لفترة أطول ، نظرًا لوجود حلول بديلة ومسارات بديلة.
تافهة. على سبيل المثال ، يكتب شخص ما أن أزرارنا بلون غير سارة ويجب إعادة طلاءها. هناك احتمال كبير أن هذه التذاكر لن يتم تقديمها أبدًا.
يوجد أيضًا شيء مثل
اتفاقية مستوى الخدمة ، والتي يتم تأسيسها بواسطة خدمة الدعم مع الفريق ومالك الأعمال في النظام. إنهم ينظرون إلى نوع العمل الذي انهار كجزء من شكوى محددة. على سبيل المثال ، إذا توقف إنشاء الطلبات (الخبز الرئيسي للمتجر عبر الإنترنت) ، فستكون لهذه المشكلة أولوية عالية ، والتي نسميها P1. P هي الأولوية ، الوحدة هي الأكثر أهمية.
P1 هو نوع من اتفاقية مستوى الخدمة ، مما يعني أنه يجب علينا معالجة المشكلة في غضون نصف ساعة وحلها في غضون ساعتين على الأكثر.
P2 شيء أقل أهمية يجب أن نأخذه خلال ساعتين ونقرر خلال اليوم.
P3-P4 شيء انهار ولا يحتاج إلى إصلاحات عاجلة. يمكنك القيام بذلك يوما ما ، خذها إلى التكرار التالي.
وهنا نأتي إلى الأولوية التي حددها الفريق. يمكن أن يكون هذا خبيرًا تقنيًا وكبير مهندسي الدعم - أي شخص يتعامل مع المشكلة.
افترض أن لدينا حاليًا 4 مهام ذات أولوية تجارية رئيسية. يضع شخص من الفريق ، بسبب خبرته ، قيمة عددية معينة ، والتي نسميها
أولوية مفصلة . بناءً عليه ، سيتم فرز لوحة الدعم في المستقبل. أي أنه في الجزء العلوي ، ستكون هناك مهام ذات أولوية قصوى للشركة ، والتي ما زالت مرتبة داخلها من خلال فهم الفريق لمدى أهمية ذلك ومدى سرعة إنجازه.
من بين المعلمات الرئيسية ، يبدو أن واحدة من أهم مفقود -
وصف طبيعي . في كثير من الأحيان ، لدينا مهام الدعم بدأت من نظام ترقب ، حيث تقع الأخطاء ، والاستثناءات ، وما إلى ذلك. شخص يرى أن هناك مشكلة صغيرة ، ويخلق لغزًا في جيرا. نظرًا لأن أنظمتنا مدمجة مع بعضها البعض ، تظهر مهمة في تعقب المهام ، وفي وصفها يوجد رابط لـ Sentry فقط ، وفي العنوان يوجد نص خطأ. هذا كل شيء.
كيف ينبغي للشخص الذي يحصل على هذه المهمة العمل مع هذا؟ غير واضح جدا إذا أضفت وصفًا جيدًا لهذه المهمة ، فستساعد كثيرًا في توفير الوقت.
الذي سوف أشعل النار كل شيء؟
وعندما يتم كل هذا ، فإن السؤال الذي يطرح نفسه هو: من الذي سوف يشعل هذه الأعمال المتراكمة المصنفة بشكل جميل؟ الجواب هو: مهندس الدعم.
يمكنك الاستماع بمزيد من التفاصيل حول من هو مهندس الدعم وماذا يفعل في حديثي "الرهن العقاري الفني: ماذا ومع من يجب أن يقود الفريق" مع TeamLeadConf 2018.
مهندس الدعم هو الرجل الذي يأخذ ويصلح المهام ذات الأولوية العليا من تراكم الدعم. نظرًا لأن كل شيء يتم فرزه بشكل جميل ، فإننا نعتقد أنه في الأعلى هو الأكثر أهمية وإلحاحًا و "الخبز". إذا لم تكن هناك مهام ، فيمكنه القيام بالتراكم التقني.
ماذا يفعل؟
1.
يحاول عزل السبب الجذري والقضاء عليه ، أي السبب الجذري للدعم. عندما تتلقى بانتظام تذاكر من نفس النوع بانتظام ، فإن الأمر يستحق النظر في سبب حدوث ذلك. على الأرجح ، هناك مشكلة يمكن حلها في مكان ما ، وبالتالي إيقاف تدفق المهام المماثلة.
2.
يحدد مهام التصحيح والمراقبة .
إذا لم يتمكن مهندس الدعم من حل المشكلة خلال يوم أو يومين على الأكثر ، فحينئذٍ يقوم بإنشاء مهمة منفصلة لها ، والتي تدخل في عملية التطوير المتراكمة. ثم يتم تقييمه بواسطة الفريق ويدخل في التكرار كدعم مخطط له.
الرصد يلعب دورا هاما بالنسبة لنا. نحن نعلق المراقبة ليس فقط على المقاييس التي اعتدنا عليها للمراقبة بشكل مستمر ، ولكن أيضًا إضافتها لتوطين المشكلات الأطول عمراً. في رأيي ، سيكون من الأفضل لو كان لدينا مراقبة غير ضرورية ، والتي شربناها بعد ذلك من أن المشكلة ستتكرر باستمرار في شكل المزيد والمزيد من التذاكر.
3.
تبحث عن أسباب الأتمتة .
على سبيل المثال : نقوم بنقل البيانات إلى نظامنا ، والذي يعمل على أتمتة عمل خدمة التسليم. في بعض الأحيان اتضح أنه حتى مع استخدام قناة الحروف الميتة وإعادة التوجيه ، لا يمكننا تسليم المعلومات هناك. نتيجة لذلك ، تتوقف هذه الأوامر في مكان ما ، ويجب أن تشعر بالاستياء.
هذا دعم نموذجي يحدث عدة مرات كل أسبوع. لحل هذه المشكلة ، قررنا إنشاء صفحة منفصلة مع زر "إعادة إرسال قائمة الطلب". لم يعد لدينا هذا الدعم. وهذا هو ، كما اعتقدوا ، الآلي ، أعطاها لخدمة الدعم.
يتم نقل دور مهندس الدعم كل أسبوع إلى شخص آخر - وهذا شرط أساسي. إن القيام بمثل هذا العمل لفترة أطول هو الإجهاد ، وإلغاء النشاط ، والانحطاط ، لأنك تقوم بإصلاح شيء باستمرار ولا تجلب أي شيء جديد إلى النظام.
انتظام كمصدر للنعمة
يبدو واضحًا ، لكن غالبًا ما يتم نسيانه على أي حال. من أجل أن يعمل كل شيء ، من الضروري أن يتم تشغيل عملياتنا ومراقبتها بانتظام.
التفتيش المتراكمأين سنحصل على دعم متراكم بشكل جميل إذا لم يبحث أحد هناك؟
بطريقة جيدة ، تحتاج إلى تشغيلها مرة واحدة في الشهر وإغلاق المهام ذات الحالة التافهة (والتي من المرجح أنك لن تحصل عليها أبدًا). كن صادقا مع نفسك والعميل. إذا كانت الأعمال المتراكمة بسبب هذه المهام ستنمو إلى ما لا نهاية ، فحينئذٍ سيتعين عليك الذعر لمحاولة إغلاقها. هذا ليس جيد جدا
الأولوية التفصيليةهذه هي العملية ذاتها التي نقيم بها مدى أهمية المهمة. سيكون الترتيب الصحيح بعد ذلك ، وسيتولى مهندس الدعم المهمة الصحيحة من أعلى.
معركة من أجل الأولويةعلى سبيل المثال ، قاموا بتعيين مهمة لك ويقولون: "الرجال ، لا يتم تحميل التقرير الشهري. نحن بحاجة إلى الحصول عليها في غضون أسبوع ، لكنها لا تعمل. يرجى إصلاحه. الأولوية P1. عليك أن تقرر في غضون 2-3 ساعات. "
وتسأل: "على محمل الجد؟ ما الذي تتحدث عنه يا رفاق؟ بعد كل شيء ، هناك أسبوع لإصلاحها. دعنا نرجع إلى P2 ، وسنواجه بضعة أيام. "
في بعض الأحيان يظن الناس أننا لن نأخذ المهمة ، لذلك يضعون أولوية عالية خاصة. لكن هذا يحدث والعكس صحيح. على سبيل المثال ، يكتبون إلينا أنه لم يتم إنشاء أوامر ووضع أولوية P2. هذه المشكلة أكثر خطورة بكثير ، لذلك يجدر رفع الأولوية إلى P1. من المفيد أن يتم التفاوض عن قصد في كلا الاتجاهين.
إنشاء مهام جديدةفي وقت سابق ، ذكرت نظام ترقب ، والذي يتضمن المهام التي يتم بالفعل الحريق من قبل العملاء. ومع ذلك ، نحن أنفسنا نتوقع المشاكل التي تنشأ وتلقي المهام في هذا العمل المتراكم بأنفسنا.
SLA مراقبة الأداءللقيام بذلك ، لدينا جداول تبين أن لدينا مهام ، والوقت الذي ستنتهي صلاحيته قريبًا. يبدو أن هذه الألغاز منطقية في المقام الأول.
دعم المهندس الدعم
كونك مهندس دعم عملية محبطة إلى حد ما ، لذلك ينبغي أن يساعد الشخص. كيف يمكننا أن نجعل حياته أسهل؟
نقل الدور إلى الفريق التالينحتاج إلى الاحتفاظ بجدول زمني لمن سيقوم بهذا الأسبوع المقبل. ومع ذلك ، تحدث لحظات الحدود. على سبيل المثال ، قام شخص بمهمة يوم الجمعة ولم يكن لديه وقت لإنهائها. قد يقضي بعض الوقت في الأسبوع المقبل ، لكن من الأفضل تسليم المهمة إلى مهندس دعم جديد. إذا قمت بالسحب على العمل المتراكم لمدة أسبوعين ، فمن المحتمل أن يكون الشخص قد خُفّض إلى حد كبير. سترى هذا في الاجتماع الشخصي القادم :)
مساعدة في العثور على مصدر المشكلةيحب الأشخاص مجرد تشغيل المهام ، لكنهم لا يركزون على العثور على السبب الجذري. يجدر طرح السؤال: "إذا قمت بإغلاق المهمة ، فلماذا تنشأ المشكلة في البداية؟". ستساعد هذه الممارسة في العثور على السبب والقضاء عليه ، وربما التخلص من تدفق هذا الدعم في المستقبل.
الحاجة إلى "نظرة جديدة"إذا لم يتمكن شخص ما لفترة زمنية معينة من تحقيق نتيجة واضحة ، فينبغي نقل هذه المهمة إلى شخص آخر. سيتمكن شخص آخر من النظر إلى المشكلة من الجانب الآخر ، مما قد يؤدي إلى حل المشكلة بطريقة مختلفة.
لكن مثل هذا النهج قد يخفي بعض الجوانب النفسية المثيرة للاهتمام. هذا يعني أن القيام بمهمة من شخص وإسنادها إلى شخص آخر ، قد تخاطر بقول أنه يعرف أفضل ، لذلك سيتأقلم مع الأمر. من الأفضل تقديم مثل هذه الأشياء بطريقة مختلفة. ركز على حقيقة
أننا جميعًا بحاجة إلى حل مشاكل النظام ، وليس إثبات لبعضنا البعض منا أكثر برودة.تطوير أدوات التشغيل الآليأولئك الذين يدعمون المهندسين غالبًا يفهمون أنهم "يخبزون" بالفعل من أداء نفس المهام النموذجية. في الآونة الأخيرة ، حصل أحد المطورين لدينا على إطار عمل صغير خاص به على Go. يذهب إلى قواعد بيانات مختلفة ، وجمع البيانات ، ودفع شيء في كافكا. وبالتالي ، كان قادرا على أتمتة هذه المهمة قدر الإمكان وجعل الحياة أسهل للآخرين.

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

أنواع الدعم
طلب تحليلاتعندما يسألون بانتظام عن حالة شيء ما في قاعدة البيانات ، يطلبون تحميل ، وجمع تقرير لفترة معينة ، وهلم جرا. هذا أمر مزعج بعض الشيء ، لذلك لديك سبب وجيه للتفكير في التشغيل الآلي وتوفير واجهة مستخدم أو دراسة هيكل الشركة.
على سبيل المثال ، لم أجد على الفور أن معظم بيانات الطلبات التي لدينا قد تم تخزينها في قاعدة بيانات Oracle التابعة لقسم D&A ، ويمكن الحصول على كل شيء من هناك.
هذا الدعم إما آليًا عبر واجهات أو يتم نقله إلى قسم التحليلات.
طلبات تغيير البياناتالمواقف مختلفة ولا يمكن التنبؤ بها. لنفترض أن عميلنا كان سيدفع ثمن طلبه ببطاقة. عندما وصل الحقيبة ، غير رأيه وقرر القيام بذلك نقدًا. أو ، على سبيل المثال ، حدثت مشكلة آلية في مكان ما يجب تغييرها يدويًا ، ونحن بحاجة إلى تصحيح هذه البيانات.
للقيام بذلك ، نحاول إنشاء مقابض API جديدة وإنشاء واجهات وإلى أقصى حد إسقاط هذه المهام من التطوير ومن فريق العمليات لدينا.
هذه ممارسة خطيرة ، ونتخلص منها عبر الواجهة وتحسينات واجهة برمجة التطبيقات.إصلاح العمليات التجاريةإذا كانت هناك حاجة مباشرة لتحرير شيء ما في قاعدة البيانات ، فهناك عملية تجارية عربات التي تجرها الدواب. قد يحدث هذا إما بسبب سبب يتعلق بتكنولوجيا المعلومات أو حدوث خطأ ما في العمل. سواء هناك وهناك التعديلات المطلوبة.
في هذه الحالة ، تحتاج إلى الذهاب إلى عميل العمل ومناقشة ما إذا كان يمكن القيام به بطريقة مختلفة ، أو طلب التطوير لإصلاح العملية التجارية.
توقفت الميزة X عن العملهذا هو نوع الدعم المفضل لدي ، لأنه الأكثر قابلية للفهم. وهذا هو ، كان لدينا نوع من الشيء في همز ، لكنها كسرت وتحتاج إلى إصلاح. معرفة أي إصدار توفي ولأي سبب. إصلاح وإغلاق التذكرة. كل شيء بسيط.
ولكن هناك دعم آخر -
الميزة X لا تعمل . قد يبدو مثل الشيء نفسه ، لكنه قال بكلمات أخرى. ومع ذلك ، هذا ليس كذلك.
في هذه الحالة ، يأتون إليك ويقولون إن هذا الشيء لا يعمل. تقضي يومًا أو يومين في الفرز. فقط في وقت لاحق
لم تدرك أن
هذا لم ينجح هنا . انها ليست فقط في نظامك.
بطريقة أخرى ، أسمي هذا النوع من الدعم "fox" عندما يريد شخص ماكر أن ينزلق طلب ميزة تحت ستار مهمة الدعم. هذه قصة عادية مؤلمة للغاية. إذا لم تتوقف عن مثل هذه اللحظات ، اتضح أن مهندس الدعم الخاص بك أو أنت بنفسك يقدم وظائف جديدة ، وأن المشاكل الحقيقية الناتجة عن تراكم الدعم تظل دون حل.
حادث كبير
هذه مجرد قصة التابوت ونيران الخث ، عندما اندلع شيء ما في أنظمة تكنولوجيا المعلومات بشكل سيء لدرجة أن عملية تجارية محددة قد نشأت.دراسة حالة من ممارستنا: نظرًا لوجود خطأ في التعليمات البرمجية واختبارات السيارات غير الكاملة ، بدأنا في إرسال ملاحظة معينة حول حالة الطلب إلى خدمة البريد السريع الخارجية ، بسبب عدم تمكن الأشخاص من استلام طلباتهم عند نقطة الالتقاط. لقد أثرت على الآلاف من العملاء. كان علينا أن نعيد جميع الطلبات وننفق المال عليها. لم نتمكن من بيعها ، وفقد ولاء العملاء. هذا هو الحادث الكبير الذي أضر الأعمال.الأمر يستحق العمل مع مثل هذه الأشياء بطريقة خاصة ، وسأخبرك كيف نفعل ذلك.كيف تعرف أن شيئًا ما يحدث؟خيار الصناعة الأكثر شيوعًا هو التعلم من المستخدمين. هو ، بالطبع ، الأسوأ ، لأنه يعني أنهم "يخبزون" بالفعل. يرون أن لا شيء يناسبك ، وهم بحاجة ماسة إلى الإصلاح.ربما ستكتشف ذلك من خدمة الدعم ، التي تراقب المراقبة وتخطر الشخص المسؤول في النظام.ولكن الجزء الأفضل هو معرفة مستقلة من خلال وجود المراقبة . وهذا يعني أنه يمكنك استخدام نظام يتتبع الديناميات بواسطة المقاييس. على سبيل المثال ، إذا تحول شيء ما إلى اللون الأحمر على جهاز تلفزيون مع وقف التنفيذ ، فلنقل ، مثلاً ، وفاة الأرنب.إنه رائع ، لكن يبدو أن هذا لا يكفي. يمكن اكتشاف العديد من المشاكل حتى أثناء السير في الطريق ، إذا كنت تراقب اتجاهات معينة.. كان لدينا مثل هذه الحالة عندما لاحظنا على الشاشة أنه في الصباح بدأ استهلاك الذاكرة على نظام مجموعة Mbit الخاص بـ Rabbit في النمو. لقد فهمنا أنه لا يوجد لدينا سوى 16 غيغابايت ، وبهذه الديناميات في غضون ساعات قليلة ستنتهي الذاكرة وستسقط كل شيء.
منذ رأينا مثل هذا الاتجاه ، شعرنا بالقلق في الوقت المناسب. اتضح أن لدينا معلق مجرفة ، والذاكرة تتدفق. تم حل المشكلة ، في حين تم تجنب الكبرى.إذا حدث شيء ما بالفعل ، وتعرفت عليه ، فأنت بحاجة إلى توطين وإخماد بطريقة ما . بالطبع ، بناءً على حجم الفريق وما يفعله ، يمكنك القيام بأشياء مختلفة. لكنني أعتقد أن التعبئة مهمة للغاية .افترض أن لديك 5 أشخاص في الفريق. قام أحدهم بتحليل سبب عدم عمل أي شيء الآن ، بينما يواصل الأربعة الباقون تقليص ميزاتهم. نتيجة لذلك ، لديك أنظمة مكسورة ومجموعة من الميزات الجديدة. إنه أمر رائع ، لكن في بعض الأحيان ، يستحق الأمر تنظيم وتعبئة العصف الذهني. فحص كل عضو في الفريق يمكن أن يقلل من الوقت الذي لا يعمل فيه شيء.وبعد أن نجحوا في إخماد كل شيء ، تبدأ المرحلة بأثر رجعي.
متطلع الى الوراء
في Lamoda ، في هذا الاجتماع ، لدينا شخص مسؤول عن كل نظام مشارك في الحادث. إذا لزم الأمر ، يوجد شخص ما من الشركة ، وأحيانًا يأتي CTO. وفي هذا الاجتماع ، نقدم وصفًا لما حدث بالضبط وفي أي نظام اشتعلت فيه النيران.ثم تأتي اللحظة الأكثر متعة - تحليل تسلسل الإجراءات. وهذا هو ، ما فعلناه بين الكشف والإطفاء إلى أقرب دقيقة ، إن أمكن.
نرى أنه في الساعة 13.05 ، تم تلقي شكوى في مركز الاتصال. حوالي 13.13 أصبح من الواضح أنه كان ضخما. وفقط في 14.50 ، تولى الفريق مهمة العمل. قبل ذلك ، لسبب ما ، كانت ساعة ونصف بسيطة ، على الرغم من أن المهمة قد تم تعيينها ، وتم إخطار الفريق. يبدو أنه يمكن تقليل هذه الفجوة في 1.5 ساعة وبالتالي توفير ملايين روبل في هذا الحادث.لماذا هذه المشكلة تنشأ؟نهض الرجال وذهبوا لتناول العشاء دون أخذ أجهزة الكمبيوتر المحمولة والهواتف ، لذلك لم تكن متوفرة. يبدو أن هناك شيئًا ما يستحق الإصلاح في هذه اللحظة. على سبيل المثال ، اصطحب معك أجهزة الكمبيوتر المحمولة ، اترك ضابط الخدمة في حالة وجود إصدار كبير.يمكنك أيضًا رؤية أن الإصلاح كان قيد الإنتاج عند 16.55 ، وهو أمر غريب أيضًا ، لأنه قبل مرور أكثر من 40 دقيقة. عندما يبدو أنه تم فحص كل شيء ، يمكنك التمرير ، لكننا لم نفعل ذلك.لماذا يحدث هذا؟لقد تم إجراء اختبارات التكامل لفترة طويلة جدًا ، حوالي نصف ساعة. وفي هذه الحالة اتضح أنك تحتاج إلى اتخاذ قرار. أو يمكنك طرح النظام الذي تم تصحيحه وطرح المشكلة ، أو ربما إنشاء نظام جديد. أو أنت في انتظار عمليات CI / CD فائقة الطول للتمرير وسيبدأ الإصدار في المعركة. من الواضح ، في حالتنا ، نحن بحاجة إلى تقليل الوقت الذي يستغرقه إجراء جميع الاختبارات حتى نتمكن من إجراء الاختبارات بشكل أسرع ولفافة أسرع ، عندما يتم فحص كل شيء.النقطة التالية هي تقييم التأثير.. التأثير هو تأثير هذا الحادث على العمل. وهي ، كم خسرت الشركة في الطلبات ، بالروبل ، في الببغاوات - لا يهم. هذا هو الشكل الذي يمكنك من خلاله الذهاب إلى العمل وإظهار ما يحدث إذا لم يعط تكنولوجيا المعلومات وقتًا لتحقيق الاستقرار وأتمتة الاختبار وما شابه ذلك.ثم صياغة الإجراءات الوقائية . هذا أمر مهم لأنك تحتاج إلى أن تضمن لنفسك بطريقة ما ، للإدارة وأي شخص آخر ، أن هذا الشيء نفسه لن يطلق النار الليلة ، غدًا وما إلى ذلك. هذا هو ، لا تحتاج إلى تكرار نفس الحادث. للقيام بذلك ، نقوم بصياغة الإجراءات الوقائية. هذا هو ، كيف ستحقق ذلك ، وكيف تحمي نفسك منه أو تتوقعه.من الضروري أيضًا وضع إصدارات المواعيد النهائية / الإصلاح .وبعد ذلكالسيطرة على التنفيذ. الخطط جيدة ، لكن تجنب المشكلة أكثر أهمية بكثير.في رأيي ، من المهم أيضًا أن نتذكر أن الدعم المعتاد ليس أسوأ من حادث كبير. يمكنك أن تأخذ خللًا خطيرًا كنت تثير اهتمامه يومًا أو أكثر ، وتمشي على طول السهوب نفسها وتفهم سبب حدوثها ، ولماذا استغرق الأمر وقتًا طويلاً لتقرير كيفية تجنبه في المستقبل. باستخدام نفس النمط ، يمكنك رفع مستوى الدعم بشكل أكثر فاعلية ، والذي لا ينطبق على الحوادث الكبرى.إيجابيات وسلبيات تحت الماء
يؤثر وجود الدعم بشكل مفهوم على سير العمل . إنه يصرف ويغضب ، لأنه ، كقاعدة عامة ، يريد الجميع قطع ميزات جديدة. ومع ذلك ، بدلاً من ذلك ، عليك أن تحصل على أطنان لا نهاية لها من الدعم ، هذه اسطبلات Augean.من ناحية أخرى ، عندما ينخرط شخص ما في الدعم المنتظم ، يستطيع أن يشعر بمختلف أجزاء النظام ، لأن الدعم منظم حسب الأهمية ، وليس من خلال العمليات التجارية. هذا يسمح لك بزيادة الخبرة بسرعة في النظام .أين تحصل عليه في كل وقت؟الجواب الأولي هو - ليس من الواضح أين. وهذا صحيح ، لأنه يعتمد إلى حد كبير على كل عمل محدد.نظمت Lamoda من قبل العديد من المديرين الإداريين ، واحد منهم أشرف على تكنولوجيا المعلومات. لقد كان قادرًا على أن يشرح لمديرين إداريين آخرين مسؤولين عن أجزاء أخرى من العمل أنه إذا أنشأنا مزود خدمة ومتجرًا عبر الإنترنت باستخدام الأتمتة والتطوير الداخلي لدينا ، فمن المهم معرفة كيفية التفاوض كثيرًا مقدمًا حول كيفية تفاعل الأعمال مع قسم تكنولوجيا المعلومات. وقد نجح أيضًا في التعبير عن أنه لا ينبغي له محاولة ملء الاختراقات بميزات جديدة بنسبة 80٪ ، دون ترك أي وقت للاستقرار ، أو دعم المشاكل. كان قادرا على القيام بذلك وتحقيق نتيجة.ومع ذلك ، أنا أفهم أنه ليس كل شخص لديه هذا الحد. لهذا السبب أعتقد أنه إذا قمت بتطبيق نهج استعادي على الدعم الجاد ، فيمكنك أن توضح للأعمال مقدار الأموال التي تذهب إلى الأنبوب ببساطة لأن تكنولوجيا المعلومات لا تملك موارد ووقت كافيين لحل المشكلات الداخلية وحشد الدعم.
بقعة حلوة
أعتقد أنه إذا قمت بتطبيق هذه الأساليب ، فسيكون من الأسهل توقع ظهور المشكلات والقضاء على أسبابها الجذرية ، وبشكل عام ، التوقف عن الدخول في نفس المشكلة ، ثم تحقيق حالة مثيرة للاهتمام للغاية. هذا هو الشرط الذي سيكون فيه كل نوع جديد من الدعم الجديد لك. قد يبدو هذا سخرية أو مضحكة أو أي شيء آخر ، ولكن في الواقع الأمر يستحق الكثير لأنك ستفهم أنك لا تحل نفس المشكلة مرارًا وتكرارًا. وآمل أن تنجح.