इंजीनियरिंग की कहानियाँ,
सिर्फ प्रोजेक्ट के नाम नहीं।

मेरा बनाया ऐप। ऐप में एक्सरसाइज़ चुनें और ट्रेनिंग की तारीख के साथ हर सेट का वज़न और रेप्स दर्ज करें। सहेजे गए सेशन से इतिहास, वॉल्यूम की गणना और प्रगति के ग्राफ़ बनते हैं। पब्लिक Kraftwerk पेज इसी ट्रेनिंग इतिहास का केवल देखने योग्य रूप है। पढ़ें कि Kraftwerk की शुरुआत कैसे हुई →

आँकड़े, सही संदर्भ के साथ। सेशन के मेट्रिक, कुल वॉल्यूम, कदम और समयावधि के विकल्प से हर वर्कआउट को हफ़्तों और महीनों के रुझान में समझा जा सकता है।

आगे बढ़ने की गुंजाइश। CSV और हेल्थ डेटा इंपोर्ट से पुरानी जानकारी को दूसरी जगह ले जाना आसान रहता है। वहीं प्रस्तुति में नए मेट्रिक जोड़े जा सकते हैं, बिना मूल रिकॉर्ड दोबारा लिखे।

KRAFTWERK / सफ़र का लॉग

कागज़ से प्रगति तक।

मेरी अपनी ट्रेनिंग के लिए बने ऐप की कहानी, चार पड़ावों में।

01नोटबुक02डिजिटल रूप में03मेरा अपना ऐप04आज की प्रगति

पड़ाव 1 / 4

शुरुआत एक नोटबुक से हुई।

मुझे अपनी ज़रूरत का ट्रेनिंग ऐप नहीं मिला। इसलिए तारीखें और रेप्स हाथ से लिखने लगा। यह पुश-अप्स वाला मेरा असली पन्ना है।

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

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

एक जाना-पहचाना उदाहरण: TLS सर्टिफ़िकेट की मियाद खत्म होना। 2000 में सर्टिफ़िकेट अपने-आप रिन्यू करने की आज जैसी सुविधा नहीं थी। Let’s Encrypt बहुत बाद में, 2015 में आया। कनेक्शन टूटने से पहले हमें नज़दीक आती एक्सपायरी पर नज़र रखनी थी। सर्टिफ़िकेट की ज़रूरतें और जारी करने वाले अलग हो सकते हैं; अपने-आप होने वाले रिन्यूअल की भी मॉनिटरिंग ज़रूरी है।

पता लगाएँ, सूचना दें और सबूत सहेजें। हमने पहले Nagios और Zabbix चुने। ऐसे चेक चाहिए थे जो समस्या पकड़ें और सूचना ऐसे व्यक्ति तक पहुँचाएँ जो कार्रवाई कर सके। खास तौर पर सूचनाएँ 24/7 ऑन-कॉल रिस्पॉन्डर टीम तक जाती थीं, ताकि किसी भी समय कदम उठाया जा सके। तब लागत की सीमाओं के कारण वेबसाइट का आर्किटेक्चर हाई-अवेलेबिलिटी वाला नहीं था। इसलिए भरोसेमंद पहचान और तेज़ प्रतिक्रिया, जितनी अच्छी सेवा संभव थी उसे बनाए रखने के लिए बहुत अहम थीं; मॉनिटरिंग खुद डाउनटाइम का जोखिम खत्म नहीं करती थी। वर्षों में SMS, WhatsApp और PagerDuty जैसे चैनल जुड़े। ये बाद के बदलाव थे, यह दावा नहीं कि 2000 में सब एक साथ इस्तेमाल हो रहे थे।

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

वह सीख जो साथ रही। मॉनिटरिंग सिर्फ डैशबोर्ड का संग्रह नहीं है। इससे टीम को मौका मिलना चाहिए कि किसी और के समस्या बताने से पहले वह कार्रवाई कर सके।

ऐतिहासिक संदर्भ: Let’s Encrypt के पहले पब्लिक सर्टिफ़िकेट की घोषणा (2015)।