सेवाएँ · 05

क्लाउड और डेवऑप्स

सिस्टम चलता रहे, और गड़बड़ हो तो ग्राहकों से पहले आपको पता चले

आपके सिस्टम आपके अपने क्लाउड अकाउंट में, हर बार एक ही तरीक़े से लाइव किए गए, और इतनी बारीक निगरानी में कि कोई ख़राबी ग्राहक तक नहीं, किसी व्यक्ति तक पहुँचे।

बोरिंग होना ही मक़सद है।

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

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

टीम
नाम से तय ज़िम्मेदार लोग, पूरे प्रोजेक्ट के लिए
कहाँ चलता है
आपके अपने अकाउंट में, पहले दिन से
क़ीमत
तय क़ीमत, बिल हर चरण पर; पहली कॉल के बाद मदवार तय कोटेशन

किसके लिए सही

  • ऐसा सिस्टम, जिसे शुक्रवार को लाइव करने की हिम्मत किसी की नहीं होती
  • एक लैपटॉप या एक वेंडर, जिस पर सब कुछ टिका है
  • क्लाउड का बिल, जिसे कोई लाइन-दर-लाइन समझा नहीं सकता

आपको मिलता है

  • हर अकाउंट, डोमेन और एक्सेस की चाबी पहले दिन से आपके अपने नाम पर
  • ऐसी रिलीज़, जिसे आपकी टीम का कोई भी एक ही तरीक़े से चला सके, और वापस भी ले सके
  • ऐसा अलर्ट जो नाम से तय व्यक्ति तक पहुँचे, साथ में लिखा हो कि क्या करना है
  • हर महीने का ख़र्च, जो आपने बनाने से पहले लिखित में देखा
काम कैसे चलता है

चार पड़ाव। हर पड़ाव को आप मंज़ूर करते हैं, तभी अगला शुरू होता है।

वही चार, जो हर प्रोजेक्ट में होते हैं, इस काम के हिसाब से।

जाँच

हम लिखते हैं कि आप क्या चलाते हैं, हर हिस्सा कहाँ है, चाबियाँ किसके पास हैं, और इनमें से कोई एक भी रुक जाए तो क्या होगा। जाँच रिपोर्ट इन ख़तरों को इस क्रम में रखती है कि ठप होने पर आपका कितना नुक़सान होगा, और उन ख़तरों के नाम लेती है जिन्हें एक दिन में ख़त्म किया जा सकता है।

परख

एक सिस्टम को नए तरीक़े से दूसरी जगह ले जाया जाता है या नए सिरे से बनाया जाता है, पूरा सेटअप फ़ाइलों के रूप में लिखकर, और बैकअप को मान नहीं लिया जाता, सच में रीस्टोर करके देखा जाता है। उसे चलाने का ख़र्च असली बिल से मिलाया जाता है, और दोनों आँकड़े लिख लिए जाते हैं।

निर्माण

बाक़ी काम हर दो हफ़्ते, आपके अपने अकाउंट में। रिलीज़ रोज़मर्रा का काम बन जाती है और वापस भी ली जा सकती है, अलर्ट किसी व्यक्ति तक पहुँचने लगते हैं और साथ में लिखा होता है कि क्या करना है, और हर महीने के ख़र्च को उससे मिलाया जाता है जो हमने बताया था।

हैंडओवर

हम फ़ोन पर मौजूद रहते हैं, और आपकी टीम इसे चलाती है: रिलीज़ कैसे करें, वापस कैसे लें, आधी रात को अलर्ट किसके पास जाए और उसे क्या करना चाहिए। समीक्षा बताती है कि अब क्या सुरक्षित है, कौन-सी चीज़ अब भी ऐसी अकेली कड़ी है जिसके टूटते ही सब रुक जाए, और उसे ठीक करने में क्या लगेगा।

केस स्टडी

चालीस साइटें, मरीज़ों का डेटा एक ही बार दर्ज, और हर बदलाव का रिकॉर्ड।

चालीस अस्पताल साइटों पर ट्रायल चलाने वाली एक रिसर्च संस्था। डेटा काग़ज़ पर और ईमेल से आता था, और एक रिकॉर्ड जाँचने के लिए तीन लोगों के पीछे भागना पड़ता था।

समय की बचत · क्लिनिकल रिसर्च · हैदराबाद
11 दिनसे बदलकर2 दिन

क्वेरी उठने से बंद होने तक

मॉनिटर के क्वेरी उठाने से लेकर साइट के उसे सुलझाने तक

साइट पर भरा जा रहा वाइटल साइन का फ़ॉर्म, जिसमें वैल्यू डालते ही जाँच के सवाल उठते हैं: अपेक्षित सीमा से बाहर का ब्लड प्रेशर, ऐसी तारीख़ जो विज़िट की तारीख़ के बाद नहीं आ सकती, और एक ज़रूरी जवाब जो ख़ाली छोड़ा गया; बगल में खुली क्वेरी की गिनती, और किसने क्या कब बदला, इसकी ऑडिट ट्रेल।
यहाँ बताई गई स्क्रीन का एक चित्र। स्क्रीनशॉट नहीं।
और क्या नापना तय हुआ
  • हर 100 भरे गए फ़ील्ड पर उठी डेटा क्वेरीऐसे फ़ील्ड, जिन्हें मॉनिटर ने सुधार के लिए साइट को वापस भेजा
  • ऑडिट ट्रेल में कमी वाले रिकॉर्डऐसा बदलाव, जिसमें न बदलने वाले का नाम दर्ज था, न वजह, न पहले की वैल्यू
पूरी कहानी पढ़ें: चालीस साइटें, मरीज़ों का डेटा एक ही बार दर्ज, और हर बदलाव का रिकॉर्ड।
मालिक क्या पूछते हैं

कॉल करने से पहले मालिक क्या पूछते हैं।

हमारे सिस्टम असल में कहाँ चलने चाहिए?

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

हमारा क्लाउड बिल बढ़ता जा रहा है और कोई इसकी वजह नहीं बता पाता। क्या यह आम बात है?

आम है, और ठीक हो सकती है। बिल तब बढ़ते हैं जब किसी चीज़ पर लेबल नहीं होता, जब टेस्ट वाले सिस्टम चलते छोड़ दिए जाते हैं, जब स्टोरेज कभी साफ़ नहीं होता, और जब कोई चीज़ ऐसे लॉन्च के हिसाब से बड़ी रखी गई थी जो कभी हुआ ही नहीं। पहला क़दम है बिल की हर लाइन को किसी सिस्टम और उसके ज़िम्मेदार तक जोड़ना, और आम तौर पर पहली ही बार में इससे बिल का एक दिखने लायक हिस्सा कम हो जाता है। उसके बाद हर महीने ख़र्च को उससे मिलाया जाता है जो हमने बताया था, और अचानक उछाल आने पर साल के आख़िर में हैरानी नहीं होती, उसी समय अलर्ट आता है।

अगर आधी रात को कोई सिस्टम बंद हो जाए, तो क्या होता है?

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

हमें कैसे पता चले कि बैकअप सच में काम करते हैं?

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

क्या आप किसी और का बनाया सिस्टम सँभाल सकते हैं?

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

क्या हमें अपने सर्वर चाहिए, या किराये पर लेना काफ़ी है?

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

आपके तकनीकी सलाहकार के लिए

इन्फ़्रास्ट्रक्चर ऐज़ कोड, दोबारा हूबहू बनाए जा सकने वाले एनवायरनमेंट, CI/CD, ऑब्ज़र्वेबिलिटी, और ऐसे बैकअप रीस्टोर जो सच में टेस्ट किए गए हों। कारोबार के आकार के हिसाब से: क्लस्टर से पहले मैनेज्ड सर्विसेज़, और जब तक लोड उसकी माँग न करे, कोई Kubernetes नहीं।

  • आपकी रिपॉज़िटरी में इन्फ़्रास्ट्रक्चर ऐज़ कोड, कोई सिर्फ़-कंसोल वाला रिसोर्स नहीं
  • रोलबैक वाली CI/CD पाइपलाइन, जिनकी मालिक आपकी टीम हो
  • डैशबोर्ड, अलर्ट रूटिंग और ऑन-कॉल रनबुक
  • रीस्टोर ड्रिल के नतीजे और लिखित रिकवरी लक्ष्य

टेक स्टैक Terraform · Docker · GitHub Actions · AWS · Azure · GCP · Grafana · OpenTelemetry

आगे पढ़ें

चलाने के ख़र्च का हिसाब भी हम सौंपते हैं

किसी सिस्टम को चलाते रहने का ख़र्च उसे बनाने से पहले क्यों तय होता है, बाद में क्यों नहीं।

शुरुआत

एक पैराग्राफ़ लिखें। एक कामकाजी दिन के भीतर संस्थापकों में से एक जवाब देते हैं।

इसके बाद दोनों संस्थापकों के साथ 30 मिनट की कॉल होती है। न कोई प्रेज़ेंटेशन, न प्रस्ताव का बना-बनाया ढाँचा; बस एक पहली राय कि इस समस्या के लिए हम सही हैं या नहीं।

या ईमेल, फ़ोन या WhatsApp पर: hello@netogrit.com · +91 94330 54299 · WhatsApp (नए टैब में खुलता है)