أمثلة للعبة من أوامر "تعال إلى الإنقاذ" (تحليل لعشرات الحوادث مع أمثلة)

في بعض الأحيان يحدث مثل هذا:

- تعال ، لقد سقطنا. إذا لم ترفعها الآن ، فسيتم عرضها على التلفزيون.

ونحن ذاهبون. في الليل. إلى الجانب الآخر من البلاد.


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

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

كيف يحدث ذلك

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

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

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

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

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

كيف يتم البحث في أقسام الكود هذه؟

بالإضافة إلى الأدوات القياسية (مقالب الخيوط والسجلات والمقاييس و AWR وبيانات من تمثيلات النظام ، وما إلى ذلك) ، نستخدم المزيد من الأدوات المدنية ، بما في ذلك الأدوات التجارية.

مثال 1: سجل المعاملات البطيئة

تم تلقي شكاوى من المستخدمين حول التشغيل البطيء للمجلة (مشكلة معروفة ومتكررة).

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



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



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



مثال 2: العثور على أسباب بطء عمل المستخدم 1

تلقى المستخدم 1 شكاوى حول بطء تشغيل التطبيق. نحن ننظر:



تم تفتيش جميع عمليات المستخدم وفرزها حسب المدة. بعد ذلك ، تم تحليل أبطأ العمليات ، وتم اكتشاف الاستعلامات البطيئة للنظام الخارجي (SAP).



وأشار إلى الفريق المجاور ، إصلاحه.

مثال 3: مستخدم آخر يشكو من بطء تشغيل التطبيق

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



مثال 4: عندما لا يكون هناك ما يكفي من التفاصيل

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



مثال 5: المزيد من الفرامل

اشتكى المستخدم من بطء العمل مع بطاقات العقد.



يتم تحليل عمليات المستخدم البطيئة (المعلمة = 'userlogin = "..."') لمدة أسبوع واحد. كانت معظم المشكلات تتعلق باستعلامات البحث بموجب العقود ، ولكن تم العثور على عمليات باستخدام بطاقة مستندات أيضًا. يقضي معظم الوقت في إنشاء عدد كبير من المهام في المهام. تم العثور على معرفات (عمود قيمة المعلمة في لقطة الشاشة) للمهام المخزنة ووقت حفظها.



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

هذه هي الطريقة البسيطة: تحتاج إلى العثور على عنق الزجاجة - وهذا كل شيء؟

لا.

ومرة أخرى ، لا.

هذا هو كل علاج للأعراض.

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

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

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

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

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

من الواضح أن هذا التحسين لا يحل المشكلة دائمًا. على سبيل المثال ، (عن طريق الهندسة المعمارية) قطاع الطاقة: يطلب العميل معرفة ما هو النظام الذي يتعطل معه. وحدث كل شيء عند التسليم ، ولكن بعد بضع سنوات ، كان هناك المزيد من الوثائق ، وكل شيء كان جيدًا. جلس العميل مع ساعة توقيت في مكان عمل المشغل وقال: هذه العملية تستغرق الآن 31 ثانية ، نريد 3. هذه مدة 40 ثانية ، نريد 2. وهكذا. من الواضح أن قياس هذه الطريقة ليس صحيحًا تمامًا ، ولكن المهمة محددة تمامًا ويمكن تقديمها بسهولة في شكل معايير موضوعية. لم نفعل كل شيء ، لقد استغرق الأمر نحو ستة أشهر "للتنظيف". بالنسبة للجزء الأكبر ، تم نقل المنطق إلى تنفيذ غير متزامن ، تم تغيير بعض قواعد البيانات إلى noSQL ، تم تثبيت محرك البحث الشمسي ، في قسم واحد كان من الضروري اختيار قاعدة البيانات الأكثر سخونة وجعلها في الذاكرة. نتيجة لذلك ، تم إغلاق حوالي 90٪ من الاحتياجات ، لكن في بعض الأماكن لم يتمكنوا من تقليل التأخير. هذا هو عمل مكتبات الطرف الثالث ، والقيود المادية للنظام الأساسي ، وهلم جرا. تمت مراقبة كل هذا من خلال المراقبة وتمكنت من إثبات مكان وأين يبطئ تمامًا.

لماذا قد تكون هناك حاجة إلى مثل هذا الرصد؟

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

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



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

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

ماذا هناك "المقابس" من الجانب التقني؟

بضعة أمثلة أخرى. بنك أجنبي كبير مع مكاتب تمثيلية في روسيا. نحن ندعم Oracle DB و Oracle Weblogic. وقد لوحظ انخفاض تدريجي في الإنتاجية في النظام ، وتم تنفيذ العمليات التجارية بشكل أبطأ ، وأصبح عمل المشغل أقل وأقل فعالية ، وخلال فترات الاستيراد والتزامن مع NSI ، كان كل شيء يتجمد تمامًا. في مثل هذه الحالات ، نستخدم أدوات Java و Oracle القياسية لجمع البيانات: نجمع مقالب سلاسل الرسائل ، ونحللها في خدمات مجانية أو نستخدم أدوات التحليل المكتوبة ذاتيًا ، وننظر إلى AWR ، وتتبع تنفيذ استعلام SQL ، وتحليل الخطط وإحصاءات التنفيذ. ونتيجة لذلك ، بالإضافة إلى الأشياء القياسية ، مثل تحسين تكوين المؤشرات وضبط خطط الاستعلام ، اقترحنا تقديم التقسيم عن طريق تقسيم البيانات. اتضح جزأين: التاريخية (تركهم على HDD) والتشغيلية - وضعت على SSD. قبل ذلك ، كان من الصعب للغاية فهم البيانات المتعلقة بماذا ، لأنه لا يزال يتعين تنازل البيانات التاريخية بانتظام ، سواء في التقارير الطويلة أو في العمليات العادية. نتيجة الفصل الصحيح ، أكثر من 98٪ من العمليات الرئيسية لم تدخل في بيانات تاريخية بطيئة. ما هو مهم ، لم يكن هناك الدخول في رمز النظام. يحدث أن بعض توصياتنا تتطلب تغييرات على رمز التطبيق ، وهو أمر غير مدعوم من قبلنا ، فإننا نتفق عادةً.

المثال الثاني: شركة تصنيع دولية في مجال الصناعة الخفيفة وقطاع سلع استهلاكية بشكل عام. تكاليف توقف الموقع الرئيسي حوالي 20 مليون روبل. متوسط ​​الحمل على القاعدة هو 200 AS (جلسات نشطة) مع قمم تصل إلى 800-1000. ليس من غير المألوف أن يفقد مُحسِّن الاستعلام رأسه ، وتبدأ الخطط في التعويم ليس للأفضل ، وتبدأ المنافسة البرية على ذاكرة التخزين المؤقت المؤقتة. لا أحد في مأمن من هذا ، ولكن يمكنك تقليل الاحتمالية: لمدة شهرين لاحظنا النظام ، وتحليل ملف تعريف الحمل ، وإطفاء الحرائق على طول الطريق ، وضبط مخططات الفهرسة والتقسيم ، منطق معالجة البيانات من جانب كود PL / SQL. هنا يجب أن تفهم أنه في النظام الحي والنامي ، يجب إجراء مثل هذه المراجعة بانتظام ، على الرغم من أن اختبار الضغط يساعد ، ولكن ليس دائمًا. وتجري الشركات عملية تدقيق عن طريق دعوة خبراء في علم الوراثة من أطراف ثالثة ، ولكن نادراً ما يقع أي منهم في مستوى منطق الأعمال ومستعد للتصفح في البيانات والتفاعل مع المطورين. نحن نفعل ذلك.

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

لماذا نحتاج إلى مثل هذه الخدمات مع المطورين المباشرين؟

لأن العمل يحب القرارات وليس العمليات. هذا هو السبب الرئيسي.

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

حسنًا ، إذا كنت مهتمًا بالغطس في التفاصيل ، فعند 1 أكتوبر ، سيكون هناك ندوة عبر الإنترنت حول ما يمكنك القيام به مقدمًا ، قبل سقوط كل شيء. وهنا بريدي للأسئلة - sstrelkov@croc.ru.