सार्वजनिक सेवाओं के एक क्षेत्रीय पोर्टल के उदाहरण पर हाईलाड अनुप्रयोगों का विकास

“कल 20 तारीख है, जिसका मतलब है कि फिर से तूफान आएगा। इसे रोकना असंभव है, केवल तैयार करना और आशा करना कि इस बार यह झटका होगा, एक चमत्कार होगा, और हमारी झील नौका सागर को जीत लेगी । ” इस तरह के विचारों ने कई साल पहले नगरपालिका सेवाओं के पोर्टल का समर्थन करने में शामिल टीम पर जोर दिया। हम इस स्थिति में कैसे आए और हमने इसका एक तरीका कैसे निकाला, इसका वर्णन नीचे किया जाएगा।

यह सब कैसे शुरू हुआ

1990 के दशक में, आवास और उपयोगिताओं क्षेत्र ने विकास में तेजी का अनुभव किया, नई तकनीकों को पेश किया गया, स्वचालित सूचना प्रणाली और नए उपकरण खरीदे गए। लेकिन कुछ लंबे समय तक व्यावहारिक रूप से अपरिवर्तित रहे, अर्थात्, अपार्टमेंट के लिए भुगतान। हां, अपार्टमेंट के लिए वही रसीदें, भुगतान दस्तावेजों में तब्दील होने के बाद, बारकोड प्राप्त करने, एक विस्तृत डिक्रिप्शन, कागज के टुकड़ों के रूप में बने रहे। आवास और सांप्रदायिक सेवा उद्यम या संसाधन आपूर्ति उद्यम के निपटान केंद्र के काम की विशिष्ट योजना इस प्रकार थी:



धीरे-धीरे, मॉडेम इंटरनेट को ब्रॉडबैंड एक्सेस द्वारा बदल दिया गया, यह विचार उत्पन्न हुआ - इलेक्ट्रॉनिक रूप में ऑनलाइन भुगतान दस्तावेज़ क्यों नहीं प्राप्त होते हैं? उसी समय, आवास और सांप्रदायिक सेवा क्षेत्र एक संगठनात्मक रूप में हिल रहा था, एमपीपी आवास और सांप्रदायिक सेवाओं (आवास और सांप्रदायिक सेवाओं के नगरपालिका उत्पादन उद्यम) को नगरपालिका एकात्मक उद्यमों (नगरपालिका एकात्मक उद्यम), डीईजेड (एकल ग्राहक निदेशालय) द्वारा प्रतिस्थापित किया गया था। सभी परिवर्तनों के परिणामस्वरूप, आवास और सांप्रदायिक सेवा उद्यमों के आईटी विभागों को अलग कर दिया गया था, और विभिन्न निपटान केंद्र उनके आधार पर पैदा हुए थे। निपटान केंद्रों का सार वास्तव में, आबादी के किराए और सूचना समर्थन की गणना था।

ग्रोथ स्टेज, 00s

यह तब था जब पहले सूचना पोर्टलों का जन्म हुआ, जो इलेक्ट्रॉनिक सेवाओं के साथ जनसंख्या प्रदान करते थे। पहले उपयोगकर्ताओं की संख्या दर्जनों में मापी गई थी, हर किसी ने इलेक्ट्रॉनिक भुगतान दस्तावेजों पर भरोसा नहीं किया था, दूसरों ने नवाचारों के बारे में नहीं सुना था, सार्वजनिक सेवाओं के क्षेत्र में मोबाइल एप्लिकेशन दुर्लभ थे। सूचना पोर्टलों का काम परिचित सूचना प्रणालियों के काम से बहुत अलग नहीं था और निश्चित रूप से, कभी भी एक उच्च भार वाली वास्तुकला नहीं थी।



साल बीतते गए, पोर्टल्स में सुधार हुआ, पैमाइश करने वाले उपकरणों की रीडिंग लेने, सर्टिफिकेट तैयार करने आदि के अवसर मिले। यह इस समय था कि पहला "बादल" क्षितिज पर दिखाई दिया, अधिक से अधिक उपयोगकर्ताओं ने पोर्टल्स पर पंजीकरण करना शुरू किया और डेटा का अनुरोध किया। दूरी में, लोडिंग के निकट पहली लहर दिखाई दी।

टीम (बाद में टीम 1 के रूप में संदर्भित) ने निम्नलिखित अनुकूलन उपाय किए:

• पीडीएफ में एक भुगतान दस्तावेज का आकार बदलना 0.5MB से 0.2MB तक
• भुगतान दस्तावेजों के निर्माण के लिए एक कतार बनाना
• बार-बार अनुरोध के लिए उत्पन्न भुगतान दस्तावेजों का भंडारण
• केवल पोर्टल की जरूरतों के लिए मुख्य डेटाबेस की प्रतिकृति बनाना

कई वर्षों के लिए, स्थिति स्थिर लग रही थी, व्यक्तिगत पोर्टलों के उपयोगकर्ताओं की संख्या हजारों में मापा गया था, यह अभी तक तूफानी नहीं था, लेकिन यह काफी हिल गया, समाशोधन केंद्रों के विकेंद्रीकरण ने डेवलपर्स के हाथों में खेला।

बिग जम्प स्टेज

इतिहास में एक नया मील का पत्थर क्षेत्रीय स्तर पर एक नगरपालिका सेवा पोर्टल का विकास था। गणतंत्र के किसी भी निवासी के लिए एक एकल प्रवेश बिंदु का समावेश एक आकर्षक विचार था, इसके अलावा, यह राज्य की साइट को सर्वश्रेष्ठ वाणिज्यिक या बैंकिंग साइटों के स्तर तक बढ़ाएगा, जहां क्षेत्र के प्रत्येक निवासी को कई अलग-अलग प्रकार की सेवाएं प्राप्त होंगी। सबसे लोकप्रिय में से एक आवास और सांप्रदायिक सेवाओं का भुगतान और मीटर रीडिंग का समावेश हो सकता है।

इस प्रकार, अगला कदम भुगतान दस्तावेजों में प्रदर्शित सूचना से निपटान केंद्रों की परिचालन जानकारी को अलग करना था। इसके लिए, एक साधारण डेटा ट्रांसफर प्रारूप और भंडारण जानकारी के लिए एक डेटाबेस विकसित किया गया था, और 5 साल के संचालन के लिए भंडारण के लिए आवश्यक स्थान की गणना की गई थी।

इस स्तर पर किए गए प्रमुख निर्णय:

• परिचालन डेटाबेस के सूचना भाग का विभाग;
• इस प्रारूप को संग्रहीत करने के लिए एक डेटाबेस का विकास;
• क्षेत्रों के निपटान केंद्रों के डेटा को एक ही डेटाबेस में संयोजित करना;
• पोर्टल प्रक्रियाओं, सेवाओं के विकास के साथ एकीकरण।

इस स्तर पर, समाधान एक पूर्ण-बैकडेज से एक बैकएंड में बदल गया, क्योंकि पोर्टल ने उपयोगकर्ताओं को एकल इंटरफ़ेस प्रदान किया था। पोर्टल की अपनी टीम थी, जिसने निपटान केंद्रों के वर्तमान समाधान की परवाह किए बिना इसे विकसित किया। हमारे इतिहास में, दूसरी टीम प्रकट होती है (बाद में टीम 2 के रूप में संदर्भित) और एक नया विक्रेता। जैसा कि हम बाद में देखेंगे, इसने विकास और समस्याओं के समाधान को महत्वपूर्ण रूप से प्रभावित किया है। डिजाइन समाधान का सार इस प्रकार था:



डेटाबेस डिजाइन करते समय, डेटाबेस के लिए प्रारूप का एक सरल मानचित्रण स्वीकार किया गया था, PostgreSQL 9.3 को DBMS के रूप में चुना गया था (उस समय यह एक बहुत ही वर्तमान संस्करण था)। प्रारूप में 9 फ्लैट फाइलें शामिल थीं, जिनमें से प्रत्येक को पोर्टल डेटाबेस के एक विशिष्ट निपटान केंद्र (प्रत्येक निपटान केंद्र का अपना पंजीकरण नंबर था) के कई तालिकाओं में COPY कमांड (हमने बहुत जल्दी - जल्दी पढ़ा) के साथ लोड किया गया था। कुछ निपटान केंद्रों में, भुगतान दस्तावेजों के गठन के लिए आवश्यक रिकॉर्डों की संख्या 1,000,000 तक पहुंच गई। एक साल में यह राशि 12,000,000, 5 साल से अधिक -60,000,000 तक पहुंच गई। इस डेटाबेस के अनुरोधों की संख्या जिला पोर्टलों और सभी उपयोगकर्ताओं के योग तक बढ़ गई। हजारों का बना। सोचने के लिए कुछ था।

ऐसा कोई अनुभव नहीं होने पर, टीम 1 ने संभावित भार को कम करने के लिए निम्नलिखित कदम उठाए:

• टेबल निपटान केंद्रों और विभाजन के महीनों से विभाजित थे;
• विभिन्न बिलिंग केंद्रों के लिए डेटा लोड करने की प्रक्रिया समय-समय पर होती है।

बहुत तेजी से विकास को चुनौती

पोर्टल लॉन्च किया गया था, और तैयार योजनाओं का वास्तविकता से सामना किया गया था:

• उपयोगकर्ताओं की संख्या बहुत जल्दी अनुमान से अधिक हो गई।
• प्रश्न मास्टर तालिका में गए, लेकिन DBMS ने अभी भी सभी तालिकाओं को प्रदूषित किया है
• डेटाबेस सर्वर पर गंभीर भार। इस सर्वर पर अन्य, अतुलनीय रूप से बड़े डेटाबेस थे, जिसमें जानकारी यादृच्छिक क्षणों में आती थी, इसे लोड करने से सभी उपलब्ध संसाधन मिलते थे
• अयोग्य कार्यान्वयन के कारण भुगतान दस्तावेज़ बनाने की सेवा धीमी हो गई थी
• उपयोगकर्ताओं से लोड महीने भर में समान रूप से वितरित नहीं किया गया था, लेकिन दो अवधियों में केंद्रित था:
  
  

इस क्षण का वर्णन पोस्ट की शुरुआत में किया गया है। समस्या का निदान करना मुश्किल था, क्योंकि समस्याओं को एक ही बार में सभी स्थानों पर लग रहा था। टीम 1 और टीम 2, समान रूप से उनके नेतृत्व से प्यार करती थी, स्थिति से बाहर निकलने के लिए कदम उठाए, लेकिन व्यावहारिक रूप से आपस में कोई संवाद नहीं था:



टीम 2 , ऐसा लगता है, एक तार्किक और उपयोगी कदम उठाया: उपयोगकर्ता द्वारा सिस्टम में प्रवेश करने के तुरंत बाद एक भुगतान दस्तावेज का निर्माण शुरू किया जाना चाहिए, इस उम्मीद में कि जब वह पृष्ठों के पन्नों तक पहुंच गया, तो एपी पहले ही बन गया था, और समाप्त दस्तावेज को जल्दी से खींचा जा सकता था।

इस समय, टीम 1 ने हर महीने प्रति माह एक समस्या का समाधान किया, हर बार ग्राहक को आश्वस्त किया कि यह वहां था कि समस्या की जड़ छिप रही थी:

• अनुकूलित SQL (कई बार प्रदर्शन में वृद्धि हुई);
• डेटाबेस के बाकी हिस्सों से पोर्टल के लिए अलग डेटाबेस सर्वर;
• हमने एक अलग आवेदन में एक भुगतान दस्तावेज़ के गठन को अंजाम दिया और इसे अनुकूलित भी किया;
• हमने मास्टर टेबल पर अपील को संशोधित किया, पोस्टग्रेक्यूएल के संस्करण को बदल दिया;
• एक बार फिर, हमने अपील को संशोधित किया (अब मास्टर टेबल से केवल 1 विशेष विभाजन का अनुरोध किया गया था - यहां तक ​​कि कई बार त्वरण भी)।

टीमों के वीर प्रयासों से स्थानीय सफलताएँ मिलीं (2-3 महीनों तक ऐसा लगा कि समस्या हल हो गई)। लेकिन वास्तविकता ने हर समय नए परिचयात्मक नोटों को फेंक दिया:

• डेटाबेस में पहले से ही कई साल निहित हैं और 1 टीबी से अधिक हो गया है;
• उपयोगकर्ताओं की संख्या पहले से ही हजारों की संख्या में थी।

जब संघर्ष चल रहा था, टीम 2 ने एक स्वचालित सेवा परीक्षण की स्थापना की, ताकि कोई भी प्रदर्शन समस्या मिनटों में ज्ञात हो जाए और समस्या ई-मेल के माध्यम से स्वचालित रूप से उच्चतम स्तर के नियंत्रण तक पहुंच गई।

इस समय टीम 1 में :

• डेटाबेस संग्रह समय अनुमेय सीमा से अधिक होने लगा (सेवा अनुपलब्ध हो गई);
• सेवा में एक कॉल ने तुरंत कई महीनों को प्रभावित किया, क्रमशः कई अनुरोध उत्पन्न किए;
• तालिका (विभाजन) की संख्या में वृद्धि के कारण DBMS प्रश्नों को पूरा करने में बदतर हो गया है;
• जो उपयोगकर्ता केवल इंस्ट्रूमेंट रीडिंग करना चाहते थे, वे अभी भी भुगतान दस्तावेजों के गठन का अनुरोध करते हैं (टीम 2 के निर्णय को याद करते हैं)।

यह स्पष्ट हो गया कि, तकनीकी दृष्टिकोण से, समाधान अपनी सीमा तक पहुंच गया था और प्रक्रियाओं या मौलिक परिवर्तन तकनीकों का अनुकूलन करने के लिए उपयोगकर्ता के व्यवहार का विश्लेषण शुरू करने का समय था।

विश्लेषण के परिणामस्वरूप (यहां एक अलग लेख के लिए विषय है), निम्नलिखित क्रियाएं की गईं:

• पिछले 3 वर्षों तक डेटा काट दिया गया था, क्योंकि पिछली अवधि में कॉल नहीं थे; तब से पुरानी अवधि को वार्षिक रूप से काट दिया गया है;
• हम सीधे एक विशेष विभाजन (DBMS पर लोड को कम करने) का उल्लेख करने के लिए मास्टर टेबल पर अपील को फिर से करते हैं।

वर्तमान

अब प्रणाली काफी स्थिर है, विनियामक समय सीमा के भीतर और गैर-कार्यात्मक विशेषताओं के लिए आवश्यकताओं पर फिट बैठता है, लेकिन क्षितिज पर फिर से बादल दिखाई देते हैं:

• उपयोगकर्ताओं की संख्या में और वृद्धि;
• परोसे गए घरों की संख्या में वृद्धि;
• प्रदान की गई सेवाओं की जटिलता में वृद्धि;
• उपयोगकर्ताओं के लिए उपलब्ध डेटा की बढ़ती हुई ग्रैन्युलैरिटी।

इसलिए, एक योजना तैयार की गई है और निम्नलिखित उपायों का कार्यान्वयन तैयार किया जा रहा है:

• उपयोगकर्ता के व्यवहार का विश्लेषण: उनमें से कितने वास्तव में भुगतान दस्तावेज देख रहे हैं, और कितने बस एक सेल फोन के लिए राशि का भुगतान करते हैं;
• उन उपयोगकर्ताओं के लिए भुगतान दस्तावेजों का प्रारंभिक गठन जो आमतौर पर कम से कम लोड के समय भुगतान दस्तावेजों को देखते हैं;
• वैकल्पिक प्रौद्योगिकियों के लिए संक्रमण (हाँ, इस बिंदु पर आने वाले कई लोगों के पास बहुत अधिक उन्नत समाधान हैं जो मोबाइल फोन के संसाधनों पर शुरू में सभी समस्याओं को हल करते हैं)।

ऐसा लगता है कि यह एक बड़ा आशावादी बिंदु लगा सकता है। सभी अच्छी तरह से किए गए: जिन्होंने किया और जो तुरंत बेहतर किया है। लेकिन कल नई हाईलोड परियोजनाएं होंगी, नई अपरिचित समस्याएं। अब उनके लिए कैसे तैयार किया जाए, जब कोई डेटा अभी तक नहीं है तो क्या परिकल्पित किया जा सकता है?

समस्याओं को हल करने के लिए एक व्यवस्थित दृष्टिकोण

क्या हम हाईलोड परियोजनाओं में समस्याओं के लिए एक कार्यप्रणाली में अनुभव को बदल सकते हैं? अजीब तरह से पर्याप्त है, जवाब हां है, सब कुछ पहले से ही हमारे लिए आविष्कार किया गया है और सिद्धांत के सिद्धांत के ढांचे के भीतर है। केवल 5 सरल चरण:

1. सिस्टम की सीमाएं खोजें।
2. तय करें कि सिस्टम की अधिकतम सीमा को कैसे बनाया जाए।
3. इस निर्णय के लिए सब कुछ अधीनस्थ करें।
4. सिस्टम के प्रतिबंधों का विस्तार करें।
5. चेतावनी! यदि पिछले 4 चरणों में प्रतिबंध हटा दिया गया है, तो चरण 1 पर वापस लौटें, लेकिन जड़ता को सिस्टम प्रतिबंध का कारण नहीं बनने देंगे।

इस सिद्धांत का वर्णन और चरणों का सार लेख के अंत में साहित्य में काफी अच्छी तरह से वर्णित है, लेकिन मैं वर्तमान प्रक्रिया के ढांचे में अपनी दृष्टि लिखूंगा:

1. प्रतिबंध: भुगतान दस्तावेज़ के गठन का समय।
2. समाधान: डेटा डाउनलोड करते समय अग्रिम में सभी भुगतान दस्तावेज़ उत्पन्न करें।
3. निर्णय के अधीनस्थ: उपयोगकर्ता से संपर्क करते समय, एक तैयार दस्तावेज जारी करें।
4. प्रतिबंध बढ़ाएँ: भुगतान दस्तावेज़ के गठन के लिए समय का अनुकूलन करें।
5. सभी घरों के लिए पूर्व-गठन प्रणाली का त्याग करें, एक नए प्रतिबंध को परिभाषित करें।

इस तरह के दृष्टिकोण से प्रोग्रामर के लिए न्यूनतम श्रम लागत के साथ कई वर्षों तक समाधान समय कम हो जाएगा। पोस्ट उन सभी समस्याओं से दूर है जो उत्पन्न हुई हैं और समाधान के कुछ विवरण नहीं हैं, क्योंकि वे प्रस्तावित दृष्टिकोण में इतने महत्वपूर्ण नहीं हैं।

विषय पर क्या पढ़ें:

1. “लक्ष्य। सतत सुधार प्रक्रिया, “ एलियाहू गोल्डरैट
2. “बाधाओं का सिद्धांत। बुनियादी दृष्टिकोण, उपकरण और समाधान ” , दिमित्री ईगोरोव
3. “गोल्डट्रैट की बाधाओं का सिद्धांत। एक प्रणाली निरंतर सुधार के लिए दृष्टिकोण, " विलियम डेटर