स्टेटस पेज कसे बनवायचे: घटक, घटना आणि अपटाइम तपासणी

स्टेटस पेज तुमच्या वापरकर्त्यांना एकाच ठिकाणी सांगते की तुमची सेवा चालू आहे की नाही. ते बनवण्यासाठी तुम्हाला घटकांची यादी (वेबसाइट, API, पेमेंट, ईमेल डिलिव्हरी), प्रत्येकाची सध्याची स्थिती, वेळेसह अपडेट असलेल्या घटना, मागील घटनांचा इतिहास आणि ऐच्छिक सबस्क्रिप्शन लागतात, जेणेकरून लोकांना तपासण्याची गरज न पडता समस्यांची माहिती मिळेल. पेज स्वतः सोपे आहे. महत्त्वाचा निर्णय हा आहे की ते कुठे चालते: स्टेटस पेज तुमचे ॲप बंद असतानाही चालू राहिले पाहिजे, म्हणून त्याने ज्या गोष्टीची नोंद करते तिचे होस्टिंग, डेटाबेस किंवा डिप्लॉय पाइपलाइन सामायिक करू नये.

स्टेटस पेज कशासाठी आहे

काही बिघडल्यावर वापरकर्त्यांना तीन गोष्टी जाणून घ्यायच्या असतात: ही समस्या फक्त माझ्यासाठी आहे का, तुम्हाला त्याची जाणीव आहे का, आणि ती कधी दुरुस्त होईल. स्टेटस पेज हे तिन्ही प्रश्न सपोर्ट तिकिटांचा पूर न येता उत्तरित करते. प्रामाणिक स्पष्टीकरणांसह दिसणारा घटना-इतिहास कालांतराने विश्वासही निर्माण करतो, कारण त्यातून दिसते की तुम्ही समस्या कशा हाताळता.

हा बदल-लॉग नाही. नवीन फीचर्स चेंजलॉग पेजवर जातात; आउटेज आणि देखभाल इथे जाते.

पेजला काय लागते

डेटा

घटकांची स्थिती सहसा एका छोट्या ठरलेल्या यादीत असते: कार्यरत, कार्यक्षमता कमी, अंशतः आउटेज, मोठा आउटेज, देखभाल सुरू.

पेजेस

• सार्वजनिक स्टेटस पेज: एकूण बॅनर (“सर्व सिस्टीम कार्यरत” किंवा सर्वात वाईट सध्याची स्थिती), प्रत्येक घटक त्याच्या स्थितीसह, कोणतीही सक्रिय घटना तिच्या अपडेटसह, येणारी देखभाल, आणि तपासणी डेटा असल्यास 90 दिवसांची इतिहास पट्टी.
• घटना पेज: एका घटनेची पूर्ण अपडेट-टाइमलाइन, तिच्या स्वतःच्या URL वर, जेणेकरून सपोर्ट तिची लिंक देऊ शकेल.
• इतिहास: मागील घटना महिन्यानुसार.
• सबस्क्राइब: पुष्टीकरणासह ईमेल नोंदणी आणि प्रति-घटक पसंती.
• ॲडमिन: घटना तयार करा, अपडेट पोस्ट करा, घटकांची स्थिती बदला, देखभाल नियोजित करा.

परवानग्या

प्रकाशित झालेले सर्व काही लोक पाहू शकतात. फक्त तुमची टीम पोस्ट करू शकते. शक्य असल्यास ॲडमिन लॉगिन तुमच्या मुख्य ॲपच्या लॉगिन सिस्टीमपासून वेगळे ठेवा, जेणेकरून तुमच्या ऑथ प्रदात्याचा आउटेज तुम्हाला स्वतःच्या स्टेटस पेजमधून बाहेर काढणार नाही.

मुख्य निर्णय: त्याला स्वतंत्र ठेवा

घरी बनवलेली स्टेटस पेजेस बहुतेकदा इथेच अपयशी ठरतात. जर तुमचे स्टेटस पेज:

• तुमच्या ॲपच्याच सर्व्हरवर किंवा होस्टिंग खात्यावर चालत असेल,
• त्याच डेटाबेसमधून वाचत असेल,
• त्याच डोमेन सेटअप किंवा CDN कॉन्फिगरेशनच्या मागे असेल,
• किंवा त्याच पाइपलाइनने डिप्लॉय होत असेल,

तर अनेक आउटेजमध्ये तेही बंद पडेल, नेमके तेव्हा जेव्हा लोकांना त्याची सर्वाधिक गरज असते. व्यावहारिक पावले:

• वेगळे होस्टिंग. मुख्य ॲपपेक्षा वेगळा प्रकल्प किंवा प्रदाता.
• स्वतःचा सबडोमेन, जसे status.example.com, जो DNS मध्ये वेगळा निर्देशित केलेला असेल. डोमेन आणि DNS कसे काम करतात ते पहा.
• स्वतःचा डेटा. घटना स्टेटस पेजच्या स्वतःच्या स्टोरेजमध्ये राहतात, तुमच्या ॲप डेटाबेसमध्ये नाही.
• स्टॅटिक फॉलबॅक. काही टीम सार्वजनिक पेज स्टॅटिक ठेवतात आणि प्रत्येक अपडेटवर पुन्हा बनवतात, त्यामुळे तुटण्यासारखे जवळजवळ काहीच नसते.

हाताने अपडेट की स्वयंचलित तपासणी

हाताने (इथून सुरुवात करा)

तुमची टीम ॲडमिन पेजवरून हाताने घटना पोस्ट करते आणि घटकांची स्थिती बदलते. अनेक स्टेटस पेजेस प्रत्यक्षात असेच चालतात, कारण मानवी निर्णय (“काही कार्ड प्रकारांसाठी पेमेंट संथ आहेत”) स्वयंचलित लाल बिंदूपेक्षा जास्त उपयुक्त असतो.

समस्या लवकर कळण्यासाठी, दर मिनिटाला तुमच्या ॲपची तपासणी करणारा आणि ईमेल, SMS किंवा चॅटद्वारे अलर्ट देणारा बाहेरचा अपटाइम मॉनिटर वापरा. अनेक मॉनिटरिंग सेवांमध्ये मोफत योजना असते.

स्वयंचलित

ऑटोमेशनचा अर्थ असा की कोणीतरी नियमितपणे प्रत्येक घटक तपासतो आणि त्याची स्थिती अपडेट करतो. त्यासाठी तुमच्या मुख्य ॲपच्या पायाभूत सुविधांच्या बाहेरून, वेळापत्रकानुसार चालणारा कोड लागतो. दोन सामान्य पद्धती:

• एक बाहेरील मॉनिटर तुमच्या स्टेटस पेजला कॉल करतो वेबहुक द्वारे, जेव्हा तपासणी अयशस्वी होते किंवा पूर्ववत होते, आणि स्टेटस पेज घटक अपडेट करते.
• स्टेटस पेजच्या स्वतःच्या होस्टिंगमधील शेड्युल्ड जॉब प्रत्येक घटकाला पिंग करतो आणि निकाल नोंदवतो. यावर अवलंबून राहण्यापूर्वी तुमचे होस्टिंग शेड्युल्ड कामे कशी हाताळते ते तपासा; बॅकग्राउंड जॉब चालवण्याबद्दल आमचे मार्गदर्शक पर्याय स्पष्ट करते.

स्वयंचलित बदल संथ नेटवर्कवर डगमगू शकतात (वर, खाली, वर). स्थिती बदलण्यापूर्वी दोन-तीन अयशस्वी तपासण्या आवश्यक ठेवा, आणि मोठा आउटेज जाहीर होण्यापूर्वी एका व्यक्तीने पुष्टी करावी.

घटना अपडेट कसे लिहायचे

• लवकर पोस्ट करा. मिनिटांत “आम्ही लॉगिन अपयशांच्या तक्रारींचा तपास करत आहोत” असे लिहिणे, तास उलटल्यावर परिपूर्ण संदेश देण्यापेक्षा चांगले.
• वापरकर्त्यांना काय जाणवते ते सांगा, आतमध्ये काय बिघडले ते नाही.
• पुढच्या अपडेटची वेळ सांगा, आणि ती पाळा.
• निराकरणानंतर थोडक्यात सारांश द्या: काय झाले, किती वेळ लागला, आणि तुम्ही काय बदलत आहात.

एक पहिला प्रॉम्प्ट जो काम करतो

Parcelio या आमच्या ॲपसाठी एक स्वतंत्र स्टेटस पेज बनवा, जे status.parcelio.com वर वेगळे होस्ट केलेले असेल. घटक: Website, Tracking API, Notifications, Payments, प्रत्येकाची स्थिती Operational, Degraded performance, Partial outage, Major outage किंवा Under maintenance. सार्वजनिक पेजवर सर्वात वाईट सध्याच्या स्थितीनुसार एकूण बॅनर, प्रत्येक घटक त्याच्या स्थितीसह, कोणत्याही सक्रिय घटना वेळेसह अपडेटसह सर्वात नवीन आधी, येणारी देखभाल, आणि महिन्यानुसार मागील घटनांची यादी दाखवा. प्रत्येक घटनेचे स्वतःचे पेज असेल. पासवर्ड-संरक्षित ॲडमिन पेज जोडा, ज्यात घटना तयार करता येतील (शीर्षक, परिणाम, प्रभावित घटक), अपडेट पोस्ट करता येतील (संदेश आणि स्थिती: Investigating, Identified, Monitoring, Resolved), घटकांची स्थिती बदलता येईल आणि देखभाल नियोजित करता येईल. POST /api/check-result हा एंडपॉइंट जोडा, जो बाहेरील मॉनिटरकडून घटकाचे नाव आणि up/down स्वीकारतो, गुप्त टोकनने संरक्षित, आणि घटकाला सलग तीन down नंतरच Degraded चिन्हांकित करतो. सर्वकाही या ॲपच्या स्वतःच्या डेटाबेसमध्ये साठवा. साधी, शांत डिझाइन जी फोनवर पटकन लोड होईल.

बिल्ड स्टेप्स

1. सार्वजनिक पेज आणि हाताने घटनांसाठी ॲडमिन. एवढेच आधीच एक कार्यरत स्टेटस पेज आहे.
2. ते वेगळे होस्ट करा आणि सबडोमेन त्याकडे निर्देशित करा.
3. घटना पेजेस आणि इतिहास.
4. देखभाल कालावधी.
5. सबस्क्रिप्शन. डबल ऑप्ट-इन ईमेल नोंदणी आणि नवीन घटना व अपडेटवरील सूचना. ईमेलसाठी प्रदाता लागतो; तुमच्या ॲपवरून ईमेल कसे पाठवायचे ते पहा.
6. मॉनिटर वेबहुक, जर स्वयंचलित स्थिती बदल हवे असतील.
7. ड्रिल चालवा. एक बनावट घटना तयार करा, अपडेट पोस्ट करा, निराकरण करा, ईमेल तपासा, आणि मग ती हटवा.

सामान्य चुका

• ॲपसोबत होस्ट करणे. सर्वात सामान्य आणि सर्वात गंभीर चूक.
• सतत “सर्व सिस्टीम कार्यरत” म्हणणारे पेज. जर ते कधीच समस्या दाखवत नसेल, तर वापरकर्ते त्यावर विश्वास ठेवणे थांबवतात.
• वेळ किंवा टाइम झोन नसणे. वेळ नेहमी झोनसह दाखवा.
• ॲडमिन पेजसाठी मुख्य ॲपच्या लॉगिनवर अवलंबून राहणे.
• अपडेटमधील शांतता. “कोणताही बदल नाही, अजून काम सुरू आहे” हा वैध अपडेट आहे.
• स्वयंचलित स्थितींचे डगमगणे. बदलापूर्वी वारंवार अपयश आवश्यक ठेवा.

जेव्हा तयार स्टेटस पेज सेवा अधिक चांगला पर्याय असते

तयार स्टेटस पेज सेवा स्वतंत्रता समस्येभोवती बांधलेल्या असतात: त्या वेगळ्या पायाभूत सुविधांवर चालतात, ईमेल आणि SMS द्वारे सबस्क्रायबर सूचना हाताळतात, आणि अनेकदा मॉनिटरिंग व घटना साधनांशी एकत्रीकरण देतात. जर अपटाइम हा ग्राहक पैसे देतात त्या गोष्टीचा भाग असेल, किंवा घटनांची नोंद करण्याची करारात्मक जबाबदारी असेल, तर समर्पित सेवा सहसा फायदेशीर असते. अनेकांमध्ये लहान टीमसाठी मोफत किंवा कमी किमतीच्या योजना असतात, त्यामुळे बनवण्यापूर्वी तपासा.

तुम्हाला डिझाइन आणि शब्दरचनेवर पूर्ण नियंत्रण हवे असेल, तुमच्या गरजा साध्या असतील (मोजकेच घटक, हाताने अपडेट), किंवा इतरांसाठी तयार करत असलेल्या उत्पादनाचा भाग म्हणून स्टेटस पेज असेल, तर स्वतः बनवा.

Mythex सह बनवणे

Mythex वर तुम्ही स्टेटस पेज स्वतंत्र प्रकल्प म्हणून बनवू शकता, तुमच्या मुख्य ॲपपासून वेगळे, ज्याला वेगळे होस्टिंग आणि स्वतःचा डेटाबेस मिळतो. चॅटमध्ये वर्णन करा, लाइव्ह प्रिव्ह्यूमध्ये तपासा, मग प्रकाशित करा आणि status.yourdomain.com सारखा सबडोमेन जोडा (कस्टम डोमेन Pro मध्ये आहेत). लक्षात ठेवा की प्रकाशित Mythex ॲप्स आणि त्यांचे डेटाबेस निष्क्रिय असताना झोपतात आणि पुढच्या भेटीवर जागे होतात, त्यामुळे शांत कालावधीनंतरची पहिली लोडिंग थोडी संथ असू शकते; एक साधे, हलके पेज मदत करते.

Mythex स्वयंचलित जॉबसाठी दस्तऐवजीकरण करत नाही, म्हणून स्वयंचलित तपासणीसाठी बाहेरील अपटाइम मॉनिटर वापरा जो तुमच्या स्टेटस पेजवरील वेबहुक एंडपॉइंटला कॉल करतो (पहा वेबहुक रेसिपी). सबस्क्रायबरना जाणारे ईमेल अलर्ट तुमच्या स्वतःच्या प्रदात्यामार्फत जातात, आणि की प्रोजेक्ट सिक्रेट म्हणून साठवलेली असते (ईमेल पाठवण्याची रेसिपी).

प्रश्न