स्टार्टअप विकास के मुद्दे - निगरानी

समय कारक - आदेश, कार्य, समझौतों के निष्पादन की समयबद्धता - व्यापार में महत्वपूर्ण है। ग्राहकों और भागीदारों को उम्मीद है कि समय लेने वाले सहयोग। एक पारंपरिक व्यवसाय में, यह कर्मचारियों के काम, आपूर्तिकर्ताओं के कार्यों, कंपनी की भौगोलिक स्थिति, उपकरणों की स्थिति और बहुत कुछ से प्रभावित होता है। यह सब पता लगाना और नियंत्रित करना एक मुश्किल काम है।

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

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

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

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

इस की गंभीरता को समझना तुरंत नहीं आया। पहले, उपयोगकर्ताओं की संख्या कम थी, सर्वर और चैनल क्षमता प्रचुर मात्रा में थी, और इसलिए "क्रैश" दुर्लभ थे। इसके अलावा, कार्यक्षमता को अक्सर अनुकूलन के लिए पहले परीक्षण और परिष्कृत किया गया था, और डेवलपर स्वयं काम के घंटों के दौरान सेवा से जुड़े सर्वर की निगरानी के लिए जिम्मेदार था। ऑफ-आवर्स के दौरान उपयोगकर्ताओं की संख्या अपेक्षाकृत कम थी - अन्य समय क्षेत्रों के ग्राहक तब व्यावहारिक रूप से अनुपस्थित थे।



धीरे-धीरे, सेवा का मुख्य भाग पूरा हो गया। सुधार छोटे हो गए, और इसलिए डेवलपर्स का मुख्य ध्यान दूसरी परियोजना में बदल गया। सिस्टम नियंत्रण की जिम्मेदारी उनकी अन्य जिम्मेदारियों के अलावा, सिस्टम प्रशासक को सौंपी गई थी। सर्वर क्रैश होने की स्थिति में प्रशासक को ईमेल और एसएमएस के लिए सूचनाएँ भेजी गईं। उस समय इस तरह के उपाय पर्याप्त लग रहे थे।

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

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



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

इसने 24 घंटे की निगरानी की आवश्यकता की समझ को मजबूत किया। सॉफ्टवेयर के दृष्टिकोण से, हमने ज़ैबिक्स को चुना, जिसे सिस्टम प्रशासक द्वारा स्थापित और कॉन्फ़िगर किया जाना था। इसमें लगभग एक सप्ताह का समय लगा - बाकी कार्य कहीं नहीं हुए और सब कुछ समानांतर रूप से हुआ। एक संगठनात्मक सवाल था - कौन वास्तव में निगरानी करेगा?



सबसे पहले, मुझे इस तरह का निर्णय लेना था - मौजूदा कर्मचारियों के काम के घंटों को शिफ्ट करना (जो लोग इसे समझते थे - अर्थात, सिस्टम एडमिनिस्ट्रेटर और डेवलपर) ताकि एक-एक करके किसी ने रात में सर्वर को नियंत्रित किया।
यह एक मजबूर निर्णय था और लंबे समय तक नहीं चला। सबसे पहले, दो लोगों का काम अभी भी चौबीसों घंटे नियंत्रण प्रदान नहीं करता है - ऐसे समय में अंतराल होते हैं जिसमें विफलता भी संभव है। दूसरे, कुछ लोग रात में काम करना पसंद करते हैं, और असंतोष बढ़ता गया, इसके अलावा, प्रोग्रामर की व्याकुलता ने विकास को लगभग रोक दिया। इसलिए, एक हफ्ते के बाद उन्होंने इस विचार को छोड़ दिया और आगे के बारे में सोचना शुरू कर दिया।

निगरानी के लिए अतिरिक्त कर्मचारी किराए पर लेना

बेशक, इस तरह का निर्णय सबसे असंबद्ध है - चयनित लोगों का निरंतर नियंत्रण एक अच्छा परिणाम देता है। लेकिन इस मोड में काम करने के लिए 3 और सिस्टम एडमिनिस्ट्रेटर की तलाश करनी होगी। इसके अलावा, उन्हें समस्याओं को हल करने के लिए पर्याप्त योग्य होना चाहिए, लेकिन उनका अधिकांश समय वैसे भी बर्बाद होगा - कंपनी छोटा है, कुछ सर्वर हैं, और उन पर कब्जा करने के लिए लगभग कुछ भी नहीं होगा। इसके अलावा, इतने सारे लोगों को भी नियंत्रित करने की आवश्यकता है, जो एक अतिरिक्त सिरदर्द होगा।



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

संक्रमण के दौरान, संदेह पैदा हुआ, मुख्य जानकारी की सुरक्षा और गोपनीयता है जो किसी और के लिए उपलब्ध हो जाती है और सेवा की गुणवत्ता, क्या यह इसके विपरीत, बदतर नहीं होगी? लेकिन यह एक जिम्मेदार निष्पादक खोजने और एनडीए पर हस्ताक्षर करने का मामला है।

इसलिए, हम आगे बढ़े, तकनीकी पक्ष से यह मुश्किल नहीं था। एक महीने बाद, हमने यह जांचने का फैसला किया कि कैसे चीजें चल रही थीं - सर्वर पर लॉग की जांच करके। हम परिणामों से संतुष्ट हैं - महीने के दौरान तीन गंभीर विफलताएं थीं जो संभावित रूप से सर्वर को "पुट" कर सकती थीं, लेकिन भागीदारों ने आधे घंटे के भीतर समस्याओं को हल किया। इसके अलावा, सभी विफलताएं सुबह एक से सुबह चार बजे तक अंतराल में हुईं - प्रभावित उत्पाद का क्रमिक भौगोलिक विकास।

हमारे सिस्टम प्रशासक का काम बदल गया है और अधिक आराम हो गया है। निगरानी से विचलित हुए बिना, उन्होंने DevOps पर ध्यान केंद्रित किया। हमने अपने प्रयासों और विकास को गति दी। यह महसूस करने के लिए निकला कि हमारे साथी के लिए लंबे समय तक स्थगित कर दिया गया था।