"غدا هو العشرين ، مما يعني أنه ستكون هناك عاصفة مرة أخرى. من المستحيل إيقافها ، فقط الاستعداد والأمل في أن تنفجر هذه المرة ، ستحدث معجزة ، وسوف تغزو عبارة البحيرة لدينا المحيط .
" هذه الأفكار تغلبت على الفريق المعني بدعم بوابة الخدمات البلدية منذ عدة سنوات. كيف وصلنا إلى هذا الموقف وكيف وجدنا طريقة للخروج منه سيتم وصفها أدناه.
كيف بدأ كل شيء
في التسعينات البعيدة ، شهد قطاع الإسكان والمرافق طفرة في التطوير ، وتم إدخال تقنيات جديدة ، ونظم معلومات آلية ، وتم شراء معدات جديدة. ولكن بقي شيء لفترة طويلة دون تغيير عملي ، وهو مدفوعات الشقة. نعم ، ظلت تلك الإيصالات نفسها لشقة ، بعد أن تحولت إلى مستندات الدفع ، واكتسبت الباركود ، وفك التشفير التفصيلي ، كقطعة من الورق. كان مخطط العمل النموذجي لمركز تسوية مؤسسة الإسكان والخدمات المجتمعية أو مؤسسة توفير الموارد على النحو التالي:
تدريجيا ، تم استبدال الإنترنت المودم عن طريق الوصول إلى النطاق العريض ، نشأت الفكرة - لماذا لا تتلقى وثائق الدفع عبر الإنترنت في شكل إلكتروني؟ في الوقت نفسه ، كان قطاع الإسكان والخدمات المجتمعية يهتز في شكل تنظيمي ، واستعيض عن الإسكان والخدمات المجتمعية MPP (مؤسسة الإنتاج البلدي للإسكان والخدمات المجتمعية) بمؤسسات بلدية وحدوية (مؤسسات وحدوية بلدية) ، DEZs (مديريات عميل واحد). نتيجة لجميع التحولات ، تم عزل إدارات تكنولوجيا المعلومات في شركات الإسكان والخدمات المجتمعية ، ولدت مراكز تسوية مختلفة على أساسها. كان جوهر مراكز التوطين ، في الواقع ، حساب الإيجار ودعم المعلومات للسكان.
مرحلة النمو ، 00s
عندئذ ولدت بوابات المعلومات الأولى التي وفرت للسكان الخدمات الإلكترونية. عدد المستخدمين الأوائل الذين تم قياسهم بعشرات ، لا يثق الجميع في مستندات الدفع الإلكتروني ، والبعض الآخر لم يسمع بالابتكارات ، وكانت تطبيقات الهاتف المحمول في مجال الخدمات العامة نادرة. لا يختلف عمل بوابات المعلومات كثيرًا عن عمل أنظمة المعلومات المألوفة ، وبالطبع لم يكن أبدًا بنية عالية.
مرت السنوات ، تحسنت البوابات ، وبدا أن الفرص تأخذ قراءات أجهزة القياس ، وتنتج الشهادات ، إلخ. في هذا الوقت ، ظهرت "السحب" الأولى في الأفق ، وبدأ عدد متزايد من المستخدمين بالتسجيل في البوابات وطلب البيانات. في المسافة ، ظهرت الموجة الأولى من الاقتراب من الأحمال.
اتخذ الفريق (المشار إليه فيما يلي باسم الفريق 1) تدابير التحسين التالية:
- تغيير حجم مستند الدفع في PDF من 0.5 ميغابايت إلى 0.2 ميجابايت
- إنشاء قائمة انتظار لتشكيل مستندات الدفع
- تخزين مستندات الدفع التي تم إنشاؤها للطلب المتكرر
- إنشاء نسخة متماثلة من قاعدة البيانات الرئيسية ، فقط لاحتياجات البوابة
لعدة سنوات ، بدا الوضع مستقرًا ، حيث تم قياس عدد مستخدمي البوابات الفردية بالآلاف ، ولم يكن الأمر عاصفًا بعد ، لكنه هز بشكل كبير ، وتمركز مراكز المقاصة في أيدي المطورين.
قفزة كبيرة المرحلة
كان معلم جديد في التاريخ هو تطوير بوابة للخدمات البلدية على المستوى الإقليمي. كان إدراج نقطة دخول واحدة لأي مقيم في الجمهورية فكرة مغرية ؛ وبالإضافة إلى ذلك ، فإن هذا سيزيد من تصنيف موقع الدولة إلى مستوى أفضل المواقع التجارية أو المصرفية ، حيث سيتلقى كل مقيم في المنطقة العديد من أنواع الخدمات المختلفة. واحدة من أكثرها شعبية يمكن أن يكون دفع الإسكان والخدمات المجتمعية وإدراج قراءات العدادات.
وبالتالي ، كانت الخطوة التالية هي فصل المعلومات التشغيلية لمراكز التسوية عن المعلومات المعروضة في مستند الدفع. لهذا الغرض ، تم تطوير تنسيق بسيط لنقل البيانات وقاعدة بيانات لتخزين المعلومات ، وتم تنفيذ حساب المساحة المطلوبة للتخزين لمدة 5 سنوات من التشغيل.
القرارات الرئيسية المتخذة في هذه المرحلة:
- قسم المعلومات جزء من قاعدة البيانات التشغيلية ؛
- تطوير قاعدة بيانات لتخزين هذا التنسيق ؛
- دمج بيانات مراكز التوطين في المناطق في قاعدة بيانات واحدة ؛
- التكامل مع عمليات البوابة ، وتطوير الخدمات.
في هذه المرحلة ، تحول الحل من واجهة كاملة إلى واجهة خلفية ، لأن البوابة زودت المستخدمين بواجهة واحدة. كان للبوابة فريقها الخاص الذي طورها بصرف النظر عن الحل الحالي لمراكز الاستيطان. في تاريخنا ، يظهر
الفريق الثاني (يشار إليه فيما يلي باسم الفريق 2) وبائع جديد. كما سنرى لاحقًا ، فقد أثر هذا بشكل كبير على تطور المشكلات وحلها. كان جوهر حل التصميم كما يلي:
عند تصميم قاعدة البيانات ، تم قبول تعيين بسيط للتنسيق إلى قاعدة البيانات ، وتم اختيار PostgreSQL 9.3 كـ DBMS (في ذلك الوقت كان إصدارًا حاليًا للغاية). يتكون التنسيق من 9 ملفات مسطحة ، تم تحميل كل منها بواسطة أمر COPY (نقرأ بسرعة كبيرة) في الجداول الكثيرة لمركز تسوية محدد (كان لكل مركز تسوية رقم التسجيل الخاص به) من قاعدة بيانات البوابة. في بعض مراكز التسوية ، وصل عدد السجلات المطلوبة لتشكيل مستندات الدفع إلى 1.000.000. وفي عام ، بلغ هذا العدد 12،000،000 ، ما يزيد عن 5 سنوات - 60،000،000. وقد زاد عدد الطلبات إلى قاعدة البيانات هذه إلى مجموع مستخدمي بوابات المناطق ويمكن يشكلون عشرات الآلاف. كان هناك شيء للتفكير فيه.
نظرًا لعدم وجود خبرة من هذا القبيل ، اتخذ
الفريق 1 الخطوات التالية لتقليل الحمل المحتمل:
- تم تقسيم الجداول حسب مراكز الاستيطان وشهور الفصل.
- تتباعد عملية تحميل البيانات مع الوقت بالنسبة لمراكز إعداد الفواتير المختلفة.
التحديات بسرعة كبيرة
تم إطلاق البوابة ، وواجهت الخطط المعدة حقيقة:
- تجاوز عدد المستخدمين التقدير بسرعة كبيرة.
- تم نقل الاستعلامات إلى الجدول الرئيسي ، لكن لا يزال يتم استقصاء قواعد البيانات (DBMS) لكافة الجداول
- تحميل زائف على خادم قاعدة البيانات. على هذا الخادم ، كانت هناك قواعد بيانات أخرى كبيرة لا تضاهى ، والمعلومات التي جاءت في لحظات عشوائية ، حيث استغرق تحميلها جميع الموارد المتاحة
- تم إبطاء خدمة تكوين مستند الدفع بسبب عدم التنفيذ الفعال
- لم يتم توزيع الحمل من المستخدمين بالتساوي على مدار الشهر ، ولكن تم التركيز في فترتين:
يتم وصف هذه اللحظة في بداية المنشور. كان من الصعب تشخيص المشكلة ، لأن المشاكل ظهرت في جميع الأماكن في وقت واحد. اتخذ الفريق 1 والفريق 2 ، المحبوبان بنفس القدر من قيادتهما ، خطوات للخروج من الموقف ، ولكن لم يكن هناك أي اتصال عملي بينهما:
يبدو أن
الفريق 2 قد اتخذ خطوة منطقية ومفيدة: لقد تم طلب إعداد مستند الدفع فور دخول المستخدم إلى النظام ، مع توقع أنه بينما وصل إلى الصفحات الموجودة في الصفحات ، تم بالفعل تكوين AP ، ويمكن سحب المستند النهائي بسرعة.
في هذا الوقت ، قام
الفريق الأول بحل مشكلة كل شهر بطوليًا كل شهر ، وفي كل مرة أقنع العميل بأن جذر المشكلة كان مختبئًا هناك:
- مزود محسن (تلقى زيادة في الأداء في بعض الأحيان) ؛
- فصل خادم قاعدة البيانات للمدخل عن بقية قواعد البيانات ؛
- لقد قمنا بتكوين مستند دفع في تطبيق منفصل وقمنا بتحسينه أيضًا ؛
- قمنا بمراجعة النداء إلى الجدول الرئيسي ، وقمنا بتغيير إصدار PostgreSQL ؛
- مرة أخرى ، قمنا بمراجعة الاستئناف (الآن تم طلب قسم معين واحد فقط من الجدول الرئيسي - حتى التسارع في بعض الأحيان).
أدت الجهود البطولية التي بذلتها الفرق إلى نجاحات محلية (لمدة 2-3 أشهر على ما يبدو ، تم حل المشكلة). لكن الواقع ألقى ملاحظات تمهيدية جديدة طوال الوقت:
- تحتوي قاعدة البيانات بالفعل على عدة سنوات ونمت أكثر من 1 تيرابايت ؛
- كان عدد المستخدمين بالفعل مئات الآلاف.
أثناء الصراع ، بدأ
Team 2 في اختبار خدمة تلقائي ، بحيث أصبحت أي مشكلة في الأداء معروفة في غضون دقائق ، وتصاعدت المشكلة إلى أعلى مستويات التحكم تلقائيًا عبر البريد الإلكتروني.
في هذا الوقت في
الفريق 1 :
- بدأ وقت أرشفة قاعدة البيانات في تجاوز الحدود المسموح بها (أصبحت الخدمة غير متوفرة) ؛
- مكالمة واحدة إلى الخدمة تتأثر على الفور عدة أشهر ، على التوالي ، ولدت العديد من الطلبات ؛
- أصبح نظام إدارة قواعد البيانات (DBMS) أسوأ في تنفيذ الاستعلامات بسبب زيادة عدد الجداول (الأقسام) ؛
- لا يزال المستخدمون الذين يريدون فقط إجراء قراءات للأدوات يطلبون تكوين مستندات الدفع (تذكر قرار الفريق 2).
أصبح من الواضح أن الحل قد وصل إلى الحد الأقصى من وجهة نظر تقنية وأن الوقت قد حان لبدء تحليل سلوك المستخدم من أجل تحسين العمليات أو تغيير التقنيات جذريًا.
نتيجة التحليل (هنا هو موضوع لمقال منفصل) ، اتخذت الإجراءات التالية:
- تم قطع البيانات حتى آخر 3 سنوات ، نظرًا لعدم وجود مكالمات في الفترة السابقة ؛ منذ ذلك الحين تم قطع الفترة القديمة سنويا ؛
- قمنا بإعادة توجيه النداء الموجه إلى الجدول الرئيسي للإشارة إلى قسم معين مباشرةً (قلل الحمل الموجود على نظام إدارة قواعد البيانات).
حاضر
أصبح النظام الآن مستقرًا تمامًا ، ويتوافق مع الإطار الزمني التنظيمي ومتطلبات الخصائص غير الوظيفية ، ولكن ظهرت السحب مرة أخرى في الأفق:
- زيادة أخرى في عدد المستخدمين ؛
- النمو في عدد الأسر التي تخدمها ؛
- زيادة تعقيد الخدمات المقدمة ؛
- زيادة دقة البيانات المتاحة للمستخدمين.
لذلك ، يتم وضع خطة وتنفيذ الإجراءات التالية قيد الإعداد:
- تحليل سلوك المستخدم: كم منهم يشاهدون بالفعل مستند الدفع ، وكم منهم يدفعون المبلغ ، مثل الهاتف الخلوي ؛
- التشكيل الأولي لمستندات الدفع لأولئك المستخدمين الذين عادةً ما يعرضون مستندات الدفع في وقت أقل حمولة ؛
- الانتقال إلى التقنيات البديلة (نعم ، العديد من أولئك الذين وصلوا إلى هذه النقطة لديهم حلول أكثر تطوراً والتي تحل جميع المشاكل في البداية ، على موارد الهاتف المحمول).
يبدو أن هذا يمكن أن يضع نقطة تفاؤل كبيرة. أحسنت: من فعلوا وأولئك الذين كانوا سيحسنون على الفور. لكن غداً سيكون هناك مشاريع تحميل عالي ، مشاكل جديدة غير مألوفة. كيف تستعد لهم الآن ، ما الذي يمكن تصوره عند عدم وجود بيانات حتى الآن؟
منهجية منهجية لحل المشاكل
هل يمكننا تحويل الخبرة إلى منهجية لمعالجة المشكلات في مشاريع Highload؟ الغريب أن الإجابة هي نعم ، لقد تم بالفعل اختراع كل شيء لنا وهو في إطار
نظرية القيود المفروضة على جدول المحتويات . فقط 5 خطوات بسيطة:
- العثور على قيود (ق) من النظام.
- حدد كيفية الاستفادة القصوى من قيود (قيود) النظام.
- تبعية كل شيء آخر لهذا القرار.
- توسيع قيود (قيود) النظام.
- تحذير! إذا تمت إزالة التقييد في الخطوات الأربع السابقة ، ارجع إلى الخطوة 1 ، ولكن لا تسمح للقصور الذاتي بالتسبب في تقييد النظام.
تم وصف وصف هذه النظرية وجوهر الخطوات جيدًا في الأدبيات في نهاية المقالة ، لكنني سأكتب رؤيتي في إطار العملية الحالية:
- تقييد: وقت تشكيل وثيقة الدفع.
- الحل: قم بإنشاء جميع مستندات الدفع مقدمًا ، عند تنزيل البيانات.
- تابع للقرار: عند الاتصال بالمستخدم ، قم بإصدار وثيقة منتهية.
- تمديد القيود: تحسين الوقت اللازم لتكوين وثيقة الدفع.
- التخلي عن نظام ما قبل التكوين لجميع الأسر ، وتحديد قيود جديدة.
مثل هذا النهج من شأنه أن يقلل من وقت الحل لعدة سنوات ، مع الحد الأدنى من تكاليف العمالة للمبرمجين. يشير المنشور بعيدًا عن جميع المشكلات التي نشأت وليس هناك بعض التفاصيل عن الحلول ، حيث إنها ليست مهمة في النهج المقترح.
ماذا تقرأ عن الموضوع:
- "الهدف. عملية التحسين المستمر ، " إلياهو جولدرات
- "نظرية القيود. النهج الأساسية والأدوات والحلول " ، ديمتري إيجوروف
- "نظرية القيود لدى جولدرات. نهج الأنظمة للتحسين المستمر ، " ويليام ديمر