प्रकाशनानंतर लगेच क्रॅश होणारे ॲप्स पकडणे

२५ सप्टेंबरला तीन प्रकाशने यशस्वी म्हणून चिन्हांकित झाली, तरी ॲपचा API प्रत्येक बूटच्या काही सेकंदांत क्रॅश होत होता. ती यशस्वी ठरल्यामुळे रोलबॅक चालला नाही; काही मिनिटांनंतर एका पार्श्वभूमी तपासणीने ती अयशस्वी ठरवली, आणि संपूर्ण साइट 404 वर गेली. हेल्थ चेक होस्टिंग प्लॅटफॉर्मच्या इव्हेंट यादीत क्रॅश मोजत होता, जी प्रति मशीन फक्त शेवटचे पाच इव्हेंट ठेवते, त्यामुळे क्रॅश-लूप ती यादी भरलेली ठेवतो आणि मोजणी कधीच वाढत नाही. आता ते सर्वात नवीन क्रॅशची वेळ तुलना करते, आणि क्रॅश-लूप होणारे प्रकाशन अयशस्वी होऊन आधीची आवृत्ती पुनर्संचयित करते.

प्रकाशन कशाची वाट पाहते

Mythex वर बॅकएंड असलेला ॲप प्रकाशित करता तेव्हा नवीन आवृत्ती आमच्या होस्टिंग प्लॅटफॉर्मवरील मशीन्सवर रोल आउट होते, आणि हेल्थ चेक ठरवतो की प्रकाशन लाइव्ह झाले की अयशस्वी. अयशस्वी झाले तर रोलबॅक आधीची आवृत्ती परत ठेवतो.

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

1. दोनदा तपासा. मशीन सुरू झाल्याचे दिसल्यावर थोडा वेळ थांबून पुन्हा पाहा. बूटवर होणारा क्रॅश अनेकदा दुसऱ्या तपासणीत अपयशी ठरतो.
2. क्रॅश-लूप पाहा. प्लॅटफॉर्मने सांगितले की मशीन सतत क्रॅश झाले आणि रीस्टार्ट करणे थांबवले, तर अयशस्वी व्हा.
3. प्रकाशन सुरू झाल्यापासूनचे क्रॅश मोजा. दोन “सुरू” तपासण्या रीस्टार्टच्या मधून जाऊ शकतात. त्यामुळे हे प्रकाशन सुरू झाल्यापासून कोणताही क्रॅश झाला असेल, तर तिसऱ्यांदा पाहा; दुसऱ्या तपासणीपेक्षा जास्त क्रॅश असतील, तर ॲप टिकत नाही.

हे तिसरे तपासणे इथे अपयशी ठरले.

मोजणी स्थिर का राहिली

क्रॅशची माहिती प्रत्येक मशीनच्या इव्हेंट यादीतून येते: सुरू होणे, बाहेर पडणे, रीस्टार्ट. प्लॅटफॉर्म प्रति मशीन फक्त शेवटचे पाच इव्हेंट ठेवतो.

एक ॲप कल्पना करा जो प्रत्येक बूटच्या अडीच सेकंदांनी क्रॅश होतो, जसा त्यापैकी एक होत होता. प्रत्येक चक्रात एक क्रॅश आणि एक सुरू होणे जोडले जाते. काही चक्रांनंतर यादी भरते. तिथून पुढे प्रत्येक नवीन इव्हेंट एक जुना बाहेर ढकलतो. यादी पुढे सरकते, पण ती नेहमी साधारण तेच मिश्रण ठेवते: दोन क्रॅश, दोन सुरू होणे.

त्यामुळे “प्रकाशन सुरू झाल्यापासून किती क्रॅश” ही मोजणी प्रत्येक तपासणीत तीच संख्या परत देत असे. दुसऱ्या तपासणीत, समजा, दोन क्रॅश दिसले. तिसऱ्या तपासणीतही दोनच दिसले; वेगवेगळे क्रॅश, पण तीच संख्या. तपासणीने ठरवले की क्रॅश थांबले आहेत, आणि प्रकाशन पास केले.

२५ सप्टेंबरला हे तीन वेळा घडले, दोन ॲप्समध्ये. प्रत्येक वेळी:

• प्रकाशन लाइव्ह म्हणून चिन्हांकित झाले,
• रोलबॅक चालला नाही, कारण काहीच अयशस्वी झाले नव्हते,
• आमचा रीकन्सिलर, नंतर डिप्लॉयमेंट्स तपासणारा पार्श्वभूमी जॉब, काही मिनिटांनी डिप्लॉयमेंट अयशस्वी ठरवला,
• आणि संपूर्ण साइट 404 दाखवू लागली.

वेळेवर अयशस्वी होणारे प्रकाशन पुनर्प्राप्त करता येते: रोलबॅक आधीची आवृत्ती परत ठेवतो. यशस्वी घोषित झाल्यावर काही मिनिटांनी अयशस्वी होणारे प्रकाशन मात्र आपला रोलबॅक आधीच वगळलेले असते.

आम्ही हे कसे शोधले

आम्ही स्थानिक पातळीवर पुनरुत्पादन केले: एक काम करणारा API घेतला, त्याला झोपू दिले, मग एका बदलासह रीपब्लिश केला जो बूटवर क्रॅश होत होता. हेल्थ चेकने तो लाइव्ह म्हणून चिन्हांकित केला.

ते प्रॉडक्शनशी जुळले: तिन्ही प्रकाशनांमध्ये ॲप प्रत्येक बूटच्या काही सेकंदांत मरत होता, तरीही दोन तपासण्यांमधील क्रॅशची मोजणी तुलना केलेल्या दोन्ही वेळी वाढली नाही.

उपाय: मोजणी नव्हे, सर्वात नवीन क्रॅशची तुलना

क्रॅशची मोजणी करण्याऐवजी, आता तपासणी प्रकाशन सुरू झाल्यापासूनच्या सर्वात अलीकडील क्रॅशची वेळ पाहते.

दुसऱ्या तपासणीत प्रकाशन सुरू झाल्यापासून कोणताही क्रॅश दिसला, तर तपासणी थांबून तिसऱ्यांदा पाहते. तिसऱ्या तपासणीतील सर्वात नवीन क्रॅश दुसऱ्यातील सर्वात नवीन क्रॅशपेक्षा नंतरचा असेल, तर त्या दरम्यान मशीन पुन्हा क्रॅश झाले. ते टिकत नाही, आणि प्रकाशन अयशस्वी होते; संदेश सांगतो की प्रकाशनानंतर मशीन वारंवार क्रॅश झाले आहे आणि अजूनही रीस्टार्ट होत आहे.

यादी किती लहान आहे याने फरक पडत नाही. पाच इव्हेंटच्या सरकत्या खिडकीत किती क्रॅश झाले ते लपू शकते, पण नुकताच एक नवीन क्रॅश झाला हे लपू शकत नाही: सर्वात नवीन इव्हेंट नेहमी ठेवला जातो.

ही बदल केल्यावर स्थानिक पुनरुत्पादन योग्यरीत्या वागते: प्रकाशन अयशस्वी होते आणि आधीची इमेज पुनर्संचयित होते. प्लॅटफॉर्मच्या वर्तनाचे अनुकरण करणारी एक चाचणी देखील आहे — प्रत्येक तपासणी एक क्रॅश आणि एक सुरू होणे जोडते आणि यादी पाचावर छाटते — आणि निकाल अपयश आहे, पास नाही, हे ती तपासते.

आम्ही यातून काय शिकलो

• तुम्ही मोजत असलेल्या डेटाचा आकार जाणून घ्या. मर्यादित यादीवरील मोजणी यादी भरली की अर्थ गमावते. ती मर्यादा लपलेली नव्हती; आम्ही तपासणी त्या मर्यादेभोवती डिझाइन केली नव्हती.
• “एकूण किती झाले?” ऐवजी “काहीतरी नवीन झाले का?” हा प्रश्न विचारा. सर्वात नवीन टाइमस्टॅम्प छाटणीनंतरही टिकतो. एकूण टिकत नाही.
• उशीरा अपयश लवकर अपयशापेक्षा वाईट असते. तोच सदोष बिल्ड अयशस्वी होऊन रोलबॅक झाला तर निरुपद्रवी आहे, आणि आधी यशस्वी घोषित झाला तर साइट बंद पाडतो.
• खऱ्या परिस्थितीत पुनरुत्पादन करा. या बगसाठी एक मशीन हवे होते ज्याने आधीच पुरेसे क्रॅश करून इव्हेंट यादी भरली असेल. चाचणीत एक द्रुत क्रॅश तो दाखवू शकला नसता.

ही सुधारणा त्याच दिवशीच्या दुसऱ्या सुधारणेशी जोडलेली आहे, जी रोलबॅकने जुनी आवृत्ती परत ठेवली, ती हटवली नाही याची खात्री करते: अयशस्वी रीपब्लिशमुळे कार्यरत बॅकएंड कधीच हटवला जात नाही. तुमचा स्वतःचा ॲप सुरू होताना क्रॅश झाल्यामुळे प्रकाशित होत नसेल, तर प्रकाशन समस्यानिवारण डॉक्स आणि AI ने बनवलेल्या ॲपचे डीबगिंग मार्गदर्शक ही चांगली सुरुवात आहे.