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

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

كجزء من التحضير ، تحتاج إلى تغيير جميع خدمات الأجهزة والكتلة الفاشلة. المزيد عن هذا في
إحدى مقالاتي السابقة.
أود أن ألفت انتباهك إلى الاعتقاد الخاطئ الشائع التالي: يبدو للكثيرين أن نقل موقع من خوادمه إلى السحابة يمنح الموثوقية على الفور +100. للأسف ، فقط +20.
لزيادة التسامح مع خطأ الخادم الظاهري ، تقوم السحابة التجارية ببساطة بأتمتة وتسريع "استبدال" الأجهزة الساقطة في ثوانٍ ، مع رفع الجهاز الظاهري تلقائيًا على أحد الخوادم الحية. الكلمات المفتاحية - "تسريع" و "حديد ساقط". ستستمر إعادة تشغيل الجهاز الظاهري. عادة لا يتم استخدام VMware Fault Tolerance ونظائرها التي تسمح لك بالهروب من إعادة التشغيل في المحاكاة الافتراضية التجارية بسبب استهلاك الموارد وانخفاض أداء الأجهزة الافتراضية المحمية. ومن هنا الاستنتاج: السحابة التجارية ليست حلاً سحريًا لتحمل الأخطاء ، ومزاياها الرئيسية هي المرونة وقابلية التوسع.
ابحث في تاريخ عدد فترات التعطل التي كان عليك استبدالها أو إصلاح المعدات المادية. بعد الانتقال إلى السحابة ، سينخفض عددهم ، - نعم ، ستصبح الحياة أسهل بالنسبة لك. ليس لديك لتشغيل مستودع أو مخزن لخادم جديد. ولكن الآن ستتم إضافة نكت افتراضية إلى حوادث الحديد.
قد يحدث أن الجهاز أصبح غير متوفر ، ولكن المضيف المادي لا يزال يستجيب. لن ترى السحابة هذه المشكلة. أو العكس تمامًا: المضيف لا يستجيب ، ولكن كل شيء على ما يرام مع الأجهزة الافتراضية. في هذه الحالة ، ستؤدي المحاكاة الافتراضية إلى رفعها في مكان آخر. سيستغرق الأمر بعض الوقت للبدء ، ومرة أخرى ستخرج من الخمول. وتحت الحمل ، يمكن أن تكون قاتلة. لذلك ، حتى في السحابة ، عليك أن تتذكر التكرار. بالمناسبة ، تحذير موفر المحاكاة الافتراضية حول الأجهزة التي تدعم بعضها البعض فكرة رائعة. خلاف ذلك ، قد يحدث أن تنتهي جميع سياراتك على نفس الخادم الفعلي وتموت في نفس الوقت.
- عند إجراء اختبارات الحمل ، من المنطقي التخطيط لاختبار تحمل الخطأ تحت الحمل.
هذا عندما تسقط العقدة في الكتلة مباشرة أثناء اختبار الحمل وترى ما سيحدث. مع
المجموعات التي تم تكوينها بشكل صحيح والموارد المخصصة بشكل صحيح ، لا ينبغي أن يؤثر ذلك سلبًا على نتائج الاختبار ويتسبب في مجموعة من الأخطاء.
يبدو أننا قد انتهينا من "الطبول" النموذجية. قبل قراءة المزيد ، أوصيك بتحديث التفاصيل الفنية الموضحة
في المقالة السابقة . بعد كل شيء ، إذا كان الموقع غير قادر من الناحية الفنية على تحمل الحمل ، فلن توفر لك سرعة التفاعل.
الآن دعونا نفكر في كيفية الاستعداد لما هو غير عادي أو مفاجئ. لا يمكننا منعها عن طريق التعريف ، لذلك يبقى أن نشمر عن سواعدنا ونتعلم كيفية إصلاحها في أسرع وقت ممكن.
خطوات لحل الحادث

ضع في اعتبارك ما يشكل وقتًا للقضاء على الحادث:
- سرعة الكشف عن الفشل - مراقبة التأخير ، تلقي رسالة من المستخدم ، إلخ.
- وقت الاستجابة للحادث المكتشف - يجب أن يلاحظ أحد الأشخاص التقرير ويتعامل معه.
- حان الوقت لتأكيد وجود الحادث - هل كان هناك صبي؟
- حان الوقت لتحليل الحادث وإيجاد الحلول.
- حان الوقت لحل الحادث والمشاكل. ليس من الممكن دائمًا إصلاح كل شيء في المرة الأولى ، ويمكن أن يكون لهذه المرحلة عدة تكرارات.
عادةً ما تكون خدمة الدعم مسؤولة عن استكشاف الأخطاء وإصلاحها. إذا كان الفريق كبيرًا ، فيمكن تنفيذ كل من هذه الخطوات من قبل أشخاص مختلفين. والوقت ، كما تعلمون ، هو المال. في حالتنا حرفيا. الجمعة السوداء لها مدة محددة ، والمنافسون في حالة تأهب - يمكن للعملاء قضاء كل شيء معهم. وفقًا لذلك ، من المهم أن يعرف كل موظف منطقة مسؤوليته وأن يتم حل الحوادث بواسطة الناقل.
دعونا نلقي نظرة على كل مرحلة على حدة ، ونحدد نقاط المشكلة ونفكر في طرق لتحسينها بسرعة.
جميع النصائح والتلميحات والتوصيات أدناه ليست وصفة "للحياة الجميلة" ، ولكنها أشياء محددة ستتمكن من تنفيذها في الأشهر الثلاثة إلى الأربعة القادمة المتبقية حتى الجمعة السوداء.
كشف الحادث
في السيناريو الأكثر فشلًا ، يُعلمك العميل بالمشكلات. أي أن المشكلة خطيرة لدرجة أنه
قضى وقته في إعداد التقارير . في هذه الحالة ، سيكتب أو يتصل عميل مخصص جدًا ، وسيغادر مستخدم بسيط مع تجاهل.
بالإضافة إلى ذلك ، غالبًا ما لا يكون لدى العميل وصول مباشر إلى قسم تكنولوجيا المعلومات. لذلك ، إما أنه يكتب إلى بعض info@business.ru ، أو يتصل بالفتيات من مركز الاتصال. عندما تزحف المعلومات إلى تكنولوجيا المعلومات ، سيمر الكثير من الوقت.
لنفترض أن لدينا الكثير من العملاء المخلصين ، ويعتبر كل منهم أنه من واجبه الكتابة عن المشاكل في TP. بينما تصنف الحادثة على أنها كبيرة ، بينما تتصاعد وتقرر ، ستمر ساعات. في الوقت نفسه ، قد يتم فقد مكالمات فردية ، وأحيانًا لا يتم تجميع البريد info@business.ru لأسابيع.
لذلك ، سيكون من المفيد جدًا بدء مراقبة مستقلة لمعلمات الأعمال الرئيسية. على الأقل - عدد المستخدمين على الموقع وعدد عمليات الشراء التي تمت ونسبتها. ستسمح لك هذه البيانات بالاستجابة بسرعة إذا حدث خطأ ما ، وستقلل بشكل كبير من الوقت لتحديد (وحل) مشكلة معينة في الموقع.
لا يوجد مستخدمون؟ نحن بحاجة لمعرفة أين يمكن أن يذهبوا. هناك مستخدمين على الموقع ، ولكن لا يوجد مبيعات؟ هذه إشارة على المشكلة ، وفي وقت متأخر. سيساعدك اختبار السيناريو التلقائي في العثور على
شيء ما حدث في
مكان ما . عادةً ، يتم تشغيل الاختبارات التلقائية بناءً على الإصدارات أو الإصدارات ، ولكنها جيدة للمراقبة. بمساعدتهم ، يمكنك أن ترى انهيار أو تباطؤ بعض العمليات التجارية الهامة من خلال عيون المستخدم.
بالطبع ، إذا لم يكن لديك اختبار سيناريو ، للأشهر القليلة المتبقية حتى الجمعة السوداء ، فلن تغطي جميع الاختبارات الإنتاجية. نعم ، ويمكنهم إعطاء حمولة خطيرة. ولكن مع اختبارات عشرات العمليات الأساسية ، من الممكن أن تكون في الوقت المناسب.
من المفيد أيضًا تتبع متوسط وقت استجابة الخادم. إذا نمت ، يمكنك توقع مشاكل في المبيعات. يجب مراقبة هذه البيانات تلقائيًا بواسطة نظام المراقبة.
كما ترى ، مع المراقبة المختصة ، يمكنك تقليل الوقت المستغرق للكشف عن مشكلة
من ساعات وأيام إلى
بضع دقائق ، وأحيانًا ترى المشكلة قبل أن تصل إلى ارتفاعها الكامل.
وقت الاستجابة للحادث

لقد قمنا بعمل رائع وبفضل المراقبة ، اكتشفنا على الفور فشلًا. تحتاج الآن إلى بدء الحادث ، وتعيين الأولوية ، والمسار وتعيين الشخص المسؤول عن المزيد من المعالجة.
شيئان مهمان هنا:
- تلقي إشعار بوجود مشكلة في أقرب وقت ممكن ؛
- كن على استعداد لمعالجة الإخطار على الفور.
العديد من متخصصي تكنولوجيا المعلومات ليسوا معتادين على الرد السريع على الرسائل حتى إذا كان لديهم عميل على هواتفهم الذكية. لذلك لا ينبغي إرسال إخطارات مهمة عن طريق البريد الإلكتروني.
استخدم SMS لتنبيهات الحوادث. والأفضل من ذلك ، قم بتطبيق برنامج اتصال للبوت في الحالات الأكثر خطورة. أنا شخصياً لم أر أي تطبيقات عملية لمثل هذه الروبوتات ، ولكن إذا سمحت الموارد بذلك ، فلم لا؟ كملاذ أخير ، استخدم WhatsApp / Viber / Jabber. للأسف ، لا يمكن أن تكون Telegram في أراضي الاتحاد الروسي لأسباب عديدة مفهومة قناة موثوقة لإشعارات الطوارئ.
قد يكون من المفيد أيضًا تصعيد الحادث تلقائيًا إذا لم يكن هناك تأكيد. بمعنى ، ستقوم المراقبة بإعلام التالي في السطر إذا لم يستجب المستلم الأساسي للإعلام. سيؤمن لك هذا النظام
إذا حدث خطأ ما (أو حدث شخص ما).
لنتحدث الآن عن كيفية تقديم استجابة سريعة لرسائل الفشل. أولاً ، يجب أن يكون الشخص مستعدًا ليكون مسؤولاً عن التعامل مع التنبيهات. التنبيهات للفريق بأكمله مفيدة ، ولكن فقط لإبقاء الناس على اطلاع.
إن المسؤولية الجماعية أمر غير موثوق به عندما تكون السرعة مطلوبة.
إذا لم تقم بتعيين الساعة على جدول واضح طوال مدة الإجراء ، فقد تواجه أنه أثناء القوة القاهرة سينام شخص ما ، ولن يتمكن شخص ما من الوصول من المنزل. شخص ما سيكون على الطريق. وفي الواقع ، لا يوجد أحد لمعالجة المشكلة في الساعة القادمة. بالطبع ، يمكنك تعيين ضابط عمل تشغيلي على مدار الساعة ، ولكن هناك فارق بسيط هنا. لن تجبر المتخصصين الجيدين على العمل باستمرار في المناوبات ، مما يعني أنه عندما تحتاج إليها ، لا يزال عليك البحث عنها وإيقاظها. وأولئك الذين لا يزالون يعملون في نوبات ، يقعون خارج السياق العام لحياة الفريق. هذا له الأثر الأكثر فتكًا على فعاليتهم في المهام المخططة.
ما ينقذنا هو أننا في معظم المشاريع نحتاج إلى الاستجابة السريعة للرسائل ، وفهم ما حدث ، ونحتاج بشكل عاجل إلى الإصلاح
حوالي 18 ساعة في اليوم. عادةً ، من 6-8 صباحًا حتى 1-2 صباحًا في اليوم التالي ، حتى 90٪ من حركة المرور والمبيعات.
لتجنب التراكبات ، يكفي تحويل جدول العمل لمن هم في الخدمة إلى صيغ مثل:
- 6: 00-15: 00 و 17: 00-02: 00 - واجب "من المنزل" ؛
- 15: 00-17: 00 - تغطية من في المكتب ؛
- 02: 00-06: 00 - حركة مرور قليلة. ومع ذلك ، قم بتعيين شخص ليس نائمًا تمامًا.
لا تنس عطلة نهاية الأسبوع. يمكن حل هذه المشكلة بنفس الطريقة.
إذا تم توزيع نشاط المستخدم اليومي بشكل مختلف ، فاختر جدولًا مشابهًا لن يمر فيه موقع وقت الذروة دون مراقبة.
كونك في الخدمة يعني أن تكون مسؤولاً عن معالجة أحداث المراقبة والمكالمات من الخطوط السابقة (دعم العملاء) ومراقبة النظام ككل. ولكن في حين أن كل شيء هادئ ، فإن الضابط المناوب يشارك في عمله الرئيسي.
تأكد من البدء في الخدمة قبل بضعة أيام من بدء الحمل. أولاً ، سيتأكد هذا مرة أخرى من أن كل شخص لديه كل الوصول. ثانيًا ، التغيير في وضع التشغيل هو الإجهاد ، وسيحتاج الكثيرون إلى "الاستقرار". وسيكون من الأفضل إذا لم تتزامن فترة الإدمان مع الحرارة الرئيسية.
رائع ، تأتي التنبيهات ، ويجب أن يستجيب لها هؤلاء الأشخاص. لكن وقت استجابة الأشخاص المناوبين يتأثر إلى حد كبير بوجود تنبيهات غير ضرورية وغير معالجة ، بالإضافة إلى الإخطارات ، التي لا تنطوي من حيث المبدأ على أي إجراء.
من المهم جدًا عدم ترك تنبيهات غير معالجة. إذا حدثت العديد من الأحداث المماثلة بشكل منتظم ، فتحقق من السبب وأصلحه. يجب ألا يكون هناك إنذار نشط في نظام المراقبة
على الإطلاق .
من التجربة ، إذا كان هناك شيء لا يمكن إصلاحه بسرعة أو إذا لم يكن بحاجة إلى الإصلاح ، ولكنه لا يزال "يومض" ، فمن الأفضل منع الإعلام وإنشاء مهمة للتطوير. يصبح التنبيه الوامض باستمرار مألوفًا عاجلاً أم آجلاً ويتوقف عن جذب الانتباه. تكمن المشكلة في أنه عندما تنشأ مشكلة حقيقية ، يمكن للناس أن يخلطوا بين المصباح الكهربائي ويتجاهلون حدثًا مهمًا حقًا.
التكوين المناسب وتحديد أولويات الأحداث في نظام المراقبة لا يزال مهمًا للغاية. يجب أن يخطرك النظام بالتحديد ما يجب إصلاحه. حول حالات فشل معينة أو خطر حدوثها. لن تقوم بإصلاح استخدام CPU بنسبة 100٪؟ ستقوم بإلغاء زمن الوصول المرتفع على خادم WEB ، لأن استخدام CPU هو معلومات لتصحيح الأخطاء ، وليست مشكلة. إذا تم تحميل المعالج يوم الجمعة السوداء بنسبة 100٪ عند الحمل المستهدف وسرعة الاستجابة ومراعاة المخزون - هذا يعني أنك قمت بحساب كل شيء بشكل صحيح.
يجب التحكم في استخدام موارد النظام ، ولكن هذه مهمة مختلفة قليلاً ، وهي مهمة لتخطيط الموارد وتحديد مجالات تأثير الحادث.قمنا بإعداد الأحداث ، والآن من المهم تحديد أولويات ما سنقوم بتصحيحه بشكل صحيح في المقام الأول. للقيام بذلك ، سنكتشف الفروق بين مستويات التنبيهات الحرجة والتحذيرية. دعوني أقدم لكم بعض الأمثلة المبالغ فيها ، ولكن المفهومة.
حرج - هذا عندما تذهب إلى جدة في مترو الأنفاق ، احصل على تنبيه وتذهب إلى أقرب محطة. تأخذ جهاز كمبيوتر محمول ، وتجلس على مقعد صغير وتبدأ في العمل - كان هناك توقف في المبيعات أو ظهرت خسائر فادحة. أي أن "الأهمية الحاسمة" لها تأثير مباشر ، وإن كان له تأثير كبير على المستخدمين.
تحذير - هذا عندما لا تترك العمل حتى تقوم بإصلاحه. ليس من الضروري رمي كل شيء والركض للمساعدة من أجل التحذير. يمكنك الانتهاء / الانتهاء واتخاذ قرار. على سبيل المثال ، كان هناك خطر واضح من وجود مشاكل خطيرة مثل الخادم الذي تم إسقاطه من زوج HA ، وسقطت الأخطاء في السجلات وما شابه. إذا كنت لا تدق وتصلح بفاعلية مثل هذه الأحداث (بالإضافة إلى البحث في الأسباب والقيام بأعمال لمنعها) ، فسيكون هناك عدد قليل جدًا منها.
شيء آخر غالبًا ما ينسى. لا رمي على واجب المسؤولين فقط. تأكد من جذب المطورين من خلال تشكيل أزواج عمل لكل نوبة عمل. سيكون هذا مفيدًا لنا في الخطوات التالية.إذا كان المشروع معقدًا من الناحية الوظيفية ، فمن المنطقي إرسال الاستشاريين والمحللين والمختبرين وجميع الآخرين الذين قد يكونون مفيدين في الخدمة. تأكد من توفرها على الأقل عن طريق الاتصال. سيتعين على الأخصائي تأكيد المشكلة (أو العكس) والمساعدة في التوطين الوظيفي - عندما تضطر إلى تربية شخص للإصلاح ، سيوفر هذا وقتك. سأناقش هذه المشكلة بمزيد من التفصيل في القسم التالي.
وآخر نقطة مهمة. يجب على كل ضابط واجب أن يعرف جيدًا جهات الاتصال ومجالات المسؤولية لجميع زملائه في حالات الطوارئ. إذا لم يتمكن من حل المشكلة بمفرده وفي حالة من الذعر يبدأ بالبحث عن رجال الإنقاذ المتوفرين ، ستأتي الفوضى ، والتي ستخسر الكثير من الوقت بسببها.
سيساعد الامتثال لهذه القواعد البسيطة على تجنب المشكلات بسبب عدم تلقي الإشعارات والضمانات: عندما تأتي حالة الطوارئ (اقرأ "الجمعة السوداء" و "حادث الطوارئ") ، سيتمكن الأشخاص من حل المشكلات على الفور.
تأكيد الحادث
الخطوة التالية بعد تلقي الإشعار هي فهم الخطأ الذي حدث بالضبط وما إذا كانت هناك مشكلة من حيث المبدأ: تحديد الشخص الصحيح أو المستخدم أو النظام على الفور ليس أمرًا سهلاً دائمًا. والحقيقة هي أنه يمكن تفسير نفس التنبيه بشكل مختلف اعتمادًا على زاوية الرؤية.
على سبيل المثال ، سيذهب المشرف النموذجي الذي تلقى معلومات حول الأخطاء في محرك البحث (البضائع مفقودة) للتحقق من خادم البحث وقراءة السجلات. سوف يقضي الكثير من الوقت ويتأكد من أن البحث يعمل. ثم سيصعد أعمق في محاولة لفهم ما هو مكسور. نتيجة لذلك ، اتضح أن السلع "المفقودة" كانت مخفية بشكل خاص ولم تكن هناك مشكلة ، فقط المستخدم لم يكن على علم.أو سيذهب المسؤول إلى ذهول ، ثم يغلق التذكرة بسبب عدم وجود جسم. حسنًا ، ما هي المنتجات الأخرى التي تبدو رائعة! ولكن في الواقع ، قام شخص ما عن طريق الخطأ بحذف البضائع من الصفحة المقصودة من قاعدة البيانات ، وتحولت الحملة الإعلانية بأكملها إلى حملة "استفزازية".في الحالة الأولى ، أمضى المسؤول وقتًا في توطين مشكلة غير موجودة بسبب عدم اكتمال المعلومات. والثاني هو "إلقاء اللوم" على وجه التحديد زاوية رؤيته. سوف يبحث المسؤولمشكلة فنية ، بينما يكتشف المحلل بسرعة المنطقية ويعيد البضائع.هناك حل واحد فقط - إذا تلقيت إشعارًا تلقائيًا ، يجب أن تعرف بوضوح معناه وكيفية التحقق منه. ويفضل أن يكون ذلك في شكل تعليمات مكتوبة. إذا كنا نتحدث عن رسائل من المستخدمين ، أولاً وقبل كل شيء ، فيجب ألا يتم التعامل معها كثيرًا من قبل فني مثل أخصائي وظيفي مع خلفية فنية. سيكون هو الذي سيواجه مشكلة مزعجة أخرى - الرسائل المربكة المألوفة لك تمامًا مثل "كل شيء معلق بالنسبة لي" و "موقعك معطّل" و "أنا أضغط ، لكنه لا يريد ذلك".قبل النظر إلى أبعد من ذلك ، تحتاج إلى فهم ما حدث بالضبط في شخص والتأكد من أن المشكلة "حقيقية". للقيام بذلك ، يجب على المتخصصين المهذبين وذوي الخبرة الجلوس في الدعم الفني ، حيث يبلغ المستخدم عن المشكلات. وتتمثل مهمتهم في استخلاص أكبر قدر ممكن من المعلومات وفهم ما لا يعمل ، وفقًا للزائر ، بهذه الطريقة . استنادًا إلى هذه المعلومات ، يمكنك تحديد: هل هذه مشكلة فنية في الموقع أو ، لنقل ، لم تكن الواجهة بديهية بما يكفي.نترجم الفشل
رائع ، لقد تلقينا تنبيهًا. تأكد من وجود مشكلة. بعد ذلك ، تحتاج إلى فهم جوهرها الفني وتحديد منطقة نفوذها. يجب أن نرى ما الذي لا يعمل بالضبط ، ولماذا وكيفية إصلاحه. في هذه المرحلة ، عدونا الرئيسي هو نفسه كما كان من قبل: نقص المعلومات.تساعد المراقبة والتسجيل الجيدان على تجديدها. أولاً ، يجب عرض المعلمات الرئيسية للنظام التي تحدثنا عنها في الفقرة الأولى - المبيعات ، الزوار ، سرعة إنشاء الصفحة ، الأخطاء الفنية في استجابات الخادم ، في شكل رسوم بيانية على شاشة كبيرة (كلما كان ذلك أفضل) في غرفة الخدمة الدعم.
جميع البيانات المهمة دائمًايجب أن يكون أمام فريق الدعم الخاص بك. خلال حالة الطوارئ أو أي إجراء آخر ، سيسمح لهم ذلك بالاستجابة بسرعة للتغييرات في المؤشرات ومنع حدوث مشكلة.لتوطين مكون فاشل ، ستحتاج إلى رسم تخطيطي للموقع يحتوي على بيانات حول تفاعل المكونات وعلاقاتها. لاكتشاف نقاط المشكلة بسرعة ، تحتاج إلى تتبع البيانات ديناميكيًا لكل تدفق تفاعل.على سبيل المثال ، يصل تطبيق إلى قاعدة بيانات. هذا يعني أنه لكل خادم قاعدة بيانات من كل من الخادم والعميل ، يجب أن نرى ما يلي:- عدد الطلبات في الثانية ؛
- عدد الاستجابات
- وقت توليد الاستجابة ؛
- حجم الردود المرسلة ؛
- الأخطاء الفنية لهذا التفاعل (التفويض ، الاتصالات ، إلخ).
بعد أن تتم ترجمة مكون المشكلة ، يمكنك الانتقال إلى السجلات ومعرفة ما هو الخطأ فيه ، أيها السيء. من الرائع تسريع هذه العملية باستخدام جامع سجلات مركزي. على سبيل المثال ، على ELK .أيضًا ، كما كتبت في مقال سابق ، يتم تحقيق توفير كبير في الوقت بسبب سهولة البحث عبر سجلات نظام المجموعة والقدرة على تتبع معالجة الطلبات على طول السلسلة بأكملها.إصلاح الأعطال
في هذه المرحلة ، نقوم في النهاية بإصلاح ما تم كسره ، ومعرفة كيفية تسريع هذه العملية.من الواضح أن أفضل مساعد لدينا هو تعليمات استكشاف الأخطاء وإصلاحها. لسوء الحظ ، لن نحصل عليه إلا إذا واجهنا بالفعل هذا الموقف من قبل. حسنًا ، لم ينسوا كتابة حل عملي. إذا لم يكن هناك تعليمات ، فسيتعين عليك الذهاب بالطريقة الصعبة للتجربة والخطأ.عندما تضطر إلى إصلاح شيء جديد في المنتج ، فأنت بحاجة إلى تقييم سلامة العمل والحاجة إلى التدخل المبكر. إن التحقق من التصحيح في بيئة الاختبار من جهة يقلل المخاطر ، ومن ناحية أخرى ، يؤخر حل المشكلة.أحاول الاسترشاد بالقاعدة التالية: إذا كنت متأكدًا تمامًا من أنها لن تسوء ، أو أنه من المستحيل إعادة إنتاج المشكلة في بيئة اختبار ، يمكنك محاولة إصلاحها على الفور في المنتج. لكن هذه الطريقة مبررة فقط إذا تزامنت 3 عوامل في وقت واحد:- كل شيء يكمن.
- الدواء لن يؤثر على البيانات القيمة.
- هناك نسخ احتياطية.
في حالات أخرى ، يجدر إعادة إظهار المشكلة في الاختبار والتحقق المزدوج من كل شيء قبل نقلها إلى المنتج. سيساعد العمل عالي الجودة في المراحل السابقة (الوعي بالمشكلة وتوطينها) على تجنب التكرارات من أجل التصحيح المتكرر. كقاعدة ، لا يعمل على إصلاحه في المرة الأولى إذا قمنا بإصلاح شيء لم يتم كسره ، أو إذا لم يتم أخذ شيء ما في الاعتبار.وهنا مرة أخرى ، يأتي اختبار الحمل لإنقاذ. نقوم بمحاكاة عمل المنتجين ونبدأ في كسرها بشكل خاص. هذا ضروري لفهم كيفية عمله ، وما تأثير بعض المشاكل عليه. بالإضافة إلى ذلك ، هذه طريقة رائعة لتعلم كيفية إصلاح التطبيق ، وفي الوقت نفسه - اكتب تعليمات لإصلاحه.بعد ذلك ، سيكون من الممكن إجراء تمارين تكتيكية لتوطين وإزالة المشاكل في منطقة الاختبار. على سبيل المثال ، عندما يكسر أحد كبار الخبراء شيئًا ما بذكاء ، ربما لا حتى في مكان واحد ، ويرسل شخصًا ما لحله وإصلاحه بمفرده. لفترة من الوقت. ممارسة جيدة للغاية. و اعتاد على العمل في وضع مرهق ، و أنت تدرس النظام و تصقل مهاراتك ، و يولد البحر تعليمات جديدة.في ختام برنامجنا التعليمي المنهجي الصغير ، أود أن ألفت انتباهكم إلى أهمية التعليمات الحالية والجداول الرسمية وغيرها من الأشياء اللاورقية التي لا يحبها الكثير من الناس. نعم ، إنها تلتهم نصيب الأسد من الوقت والطاقة. لكن الوقت الذي ستقضيه سوف يعاد لك مئة ضعف عندما يضرب الرعد ، ويمكنك إصلاحه "على قطعة ورق" دون أي أعصاب إضافية.العملية جيش تحرير السودان. وجيش تحرير السودان يتعلق بمراعاة التوقيت ككل ، وبشكل منفصل ، في كل مرحلة. للتحكم في تنفيذ اتفاقيات مستوى الخدمة وهذه المواعيد ذاتها ، تحتاج إلى معرفة الحدود الزمنية لكل مرحلة. خلاف ذلك ، حتى تتجاوز إطار العمل ، لن تدرك أنك تأخرت بالفعل في مكان ما. وبدون تحديد خوارزميات العمل والإجراءات المحددة في كل مرحلة ، من المستحيل تقييم أو ضمان مدة هذه المراحل.الإبداع مثير للاهتمام للغاية ، ولكن لا يمكن التنبؤ به تمامًا. افعل ذلك من أجل الروح ، واختبر وتنفيذ الحلول الأكثر نجاحًا ، ولكن ليس أثناء التحضير للجمعة السوداء أو عرض ترويجي آخر. سوف يشكرك العمل على ذلك.
حتى الآن ، هذا كل ما أود أن أقوله عن هذا الموضوع. سأكون سعيدًا إذا كانت نصيحتي ، التي تم تحويلها إلى حقائق عملك ، تسمح لي بالبقاء على قيد الحياة بهدوء وراحة.إذا كنت تريد نصيحة حول كيفية التصرف في وضعك ، فأنا أدعوك إلى ندوتي الجمعة السوداء. أسرار البقاء. " في شكل السؤال والجواب ، سنتحدث عن إعداد الموقع للنمو المروري ومناقشة كل من التفاصيل الفنية والتنظيمية لهذه العملية.وستعقد الندوة يوم 16 أغسطس في موسكو. نظرًا لأن الحدث سيكون بالغرفة تمامًا (بحد أقصى 25 شخصًا) ، يلزم تحديد موعد. وأنا في انتظار بقية المناقشة في التعليقات. :)