क्लाउडफ्लेअरचा १८ नोव्हेंबरचा प्रमुख आउटेज - एक सारांश

१८ नोव्हेंबर २०२५ रोजी, इंटरनेटचा एक मोठा भाग कोसळला.

जर तुम्ही ChatGPT, X (Twitter), League of Legends, Shopify, Coinbase किंवा असंख्य लहान साइट्स उघडल्या तर तुमचे स्वागत Cloudflare-ब्रँडेड 5xx एरर पेजने झाले—किंवा साइट्स अजिबात लोड होणार नाहीत. सुरुवातीला आणखी एक मोठा "इंटरनेट तुटलेला आहे" असा क्षण दिसला तर तो अधिक सूक्ष्म आणि काही प्रकारे अधिक चिंताजनक ठरला: Cloudflare च्या स्वतःच्या पायाभूत सुविधांमध्ये खोलवर स्वतःहून निर्माण झालेला बग.

कालच्या Cloudflare आउटेजमध्ये (१८ नोव्हेंबर २०२५) काय घडले, ते का घडले, त्याचा कोणावर परिणाम झाला आणि पायाभूत सुविधा संघांनी त्यातून कोणते धडे घेतले पाहिजेत याबद्दल तपशीलवार माहिती खाली दिली आहे.

काल प्रत्यक्षात काय घडले?

मंगळवार, १८ नोव्हेंबर २०२५ रोजी, सकाळी उशिरा UTC च्या सुमारास, Cloudflare ने त्याच्या नेटवर्कमधून जाणाऱ्या ट्रॅफिकसाठी मोठ्या प्रमाणात HTTP 5xx सर्व्हर एरर परत करण्यास सुरुवात केली. अंतिम वापरकर्त्यांसाठी, याचा अर्थ अनेक लोकप्रिय वेबसाइट आणि अॅप्समध्ये प्रवेश करण्याचा प्रयत्न करताना "अंतर्गत सर्व्हर त्रुटी" किंवा "गेटवे त्रुटी" पृष्ठे असा होतो.

क्लाउडफ्लेअरच्या स्वतःच्या पोस्ट-इन्सिडेंट ब्लॉगनुसार, आउटेज:

११:२८ UTC वाजता ग्राहकांच्या HTTP ट्रॅफिकवर परिणाम करण्यास सुरुवात झाली

कोर CDN आणि सुरक्षा सेवांमध्ये व्यापक ५xx त्रुटी आढळल्या

१३:०५–१४:३० UTC च्या सुमारास प्रमुख शमन पावले उचलली

१७:०६ UTC पर्यंत ५xx त्रुटी व्हॉल्यूम बेसलाइनवर परत केला द क्लाउडफ्लेअर ब्लॉग

क्लाउडफ्लेअरने स्वतःच २०१९ नंतरचे त्याचे सर्वात वाईट आउटेज म्हणून वर्णन केले आहे, कारण त्याचा परिणाम फक्त एका वैशिष्ट्यावर किंवा डॅशबोर्डवर झाला नाही - यामुळे कोर प्रॉक्सी लेयरमध्ये व्यत्यय आला जो बहुतेक ग्राहक ट्रॅफिक त्याच्या नेटवर्कद्वारे रूट करतो. द क्लाउडफ्लेअर ब्लॉग

थर्ड-पार्टी मॉनिटरिंगने याचे समर्थन केले. सिस्को थाउजंडआयजमध्ये क्लाउडफ्लेअरवर जागतिक स्तरावर आउटेजचा परिणाम झाला, ज्यामध्ये X, OpenAI (ChatGPT) आणि Anthropic सारख्या सेवांवर टाइमआउट आणि 5xx त्रुटी आढळल्या, तर नेटवर्क पथ स्वतःच निरोगी दिसत होते. हे ISP-स्तरीय किंवा राउटिंग समस्येऐवजी बॅकएंड सेवा अपयशाकडे स्पष्टपणे निर्देशित करते. थाउजंडआयज

कोण प्रभावित झाले?

क्लाउडफ्लेअर इंटरनेटच्या मोठ्या भागासमोर असल्याने (वेबच्या सुमारे 20% साइट्स कामगिरी आणि सुरक्षिततेसाठी क्लाउडफ्लेअरवर अवलंबून असतात), त्यामुळे ब्लास्ट रेडियस प्रचंड होता. AP News+1

प्रभावित म्हणून नोंदवलेल्या सेवांमध्ये:

ChatGPT / OpenAI

X (पूर्वी ट्विटर)

Canva, Shopify, Dropbox, Coinbase

लीग ऑफ लीजेंड्स आणि इतर गेमिंग प्लॅटफॉर्म

न्यू जर्सी ट्रान्झिट आणि फ्रान्सच्या SNCF रेल्वे डिजिटल सिस्टमसह विविध सार्वजनिक वाहतूक आणि सरकारी साइट्स AP News+1

डाउनडिटेक्टर सारख्या आउटेज ट्रॅकर्सनी शिखरावर हजारो समवर्ती समस्या अहवाल नोंदवले. रॉयटर्सने एका वेळी फक्त X साठी सुमारे ५,००० प्रभावित वापरकर्त्यांची नोंद केली होती, परंतु सुधारणा सुरू झाल्यामुळे गणना कमी झाली. रॉयटर्स

वापरकर्त्याच्या दृष्टिकोनातून, हे असे दिसून येते:

साइट्स अजिबात लोड होत नाहीत

लॉगिन प्रवाह लटकत आहेत किंवा अयशस्वी होत आहेत (विशेषतः जिथे क्लाउडफ्लेअर अॅक्सेस किंवा टर्नस्टाइलचा समावेश होता)

API मधूनमधून किंवा ५xx त्रुटींसह प्रतिसाद देत आहेत

डॅशबोर्ड आणि अॅडमिन पॅनेलची वेळ संपली

दुसऱ्या शब्दांत: इंटरनेटचा मोठा भाग "खाली जाणवला", जरी मूळ कारण एकाच प्रदात्याच्या अंतर्गत सिस्टममध्ये केंद्रित होते.

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

क्लाउडफ्लेअर रिव्हर्स प्रॉक्सी CDN आणि सुरक्षा स्तर म्हणून कार्य करते:

तुमचा ब्राउझर किंवा अॅप थेट मूळ साइटशी कनेक्ट होण्याऐवजी क्लाउडफ्लेअरशी कनेक्ट होतो.

क्लाउडफ्लेअर त्याच्या काठावर TLS आणि HTTP बंद करते.

क्लाउडफ्लेअरच्या FL ("फ्रंटलाइन") नावाच्या कोर प्रॉक्सी सिस्टममध्ये आणि त्याच्या नवीन पिढीच्या FL2 मध्ये विनंत्या येतात.

ते कोर प्रॉक्सी:

WAF (वेब ​​अॅप्लिकेशन फायरवॉल) नियम लागू करते

बॉट मॅनेजमेंट मॉडेल चालवते

DDoS संरक्षण, कॅशिंग, मूळकडे जाणे हाताळते

वर्कर्स, R2, अॅक्सेस इत्यादी इतर अंतर्गत उत्पादनांकडे ट्रॅफिकचे मार्ग दाखवते. क्लाउडफ्लेअर ब्लॉग

सामान्य ऑपरेशनमध्ये हे आर्किटेक्चर अत्यंत लवचिक असते: जर एका डेटा सेंटरमध्ये समस्या असेल तर ट्रॅफिक इतरांमधून राउट केला जातो; कॉन्फिगरेशन बदल काळजीपूर्वक रोल आउट केले जातात; वैयक्तिक वैशिष्ट्ये मर्यादित मार्गांनी अयशस्वी व्हावीत.

कालचा आउटेज अगदी वाईट होता कारण बिघाड सामान्य प्रॉक्सी मार्गातच होता आणि तो कॉन्फिगरेशन फाइलशी घट्ट जोडला गेला होता जो जगभरात वारंवार आणि स्वयंचलितपणे ढकलला जातो.

मूळ कारण: बॉट-व्यवस्थापन वैशिष्ट्य फाइल खराब झाली
क्लाउडफ्लेअरचे अधिकृत स्पष्टीकरण एका प्रमुख गुन्हेगाराकडे निर्देश करते:

त्यांच्या बॉट व्यवस्थापन प्रणालीद्वारे वापरलेली एक वैशिष्ट्य कॉन्फिगरेशन फाइल. क्लाउडफ्लेअर ब्लॉग

सोप्या भाषेत इव्हेंट्सची साखळी येथे आहे:

बॉट मॅनेजमेंट "फीचर फाइल" वापरते

क्लाउडफ्लेअरचे बॉट-डिटेक्शन मॉडेल "फीचर्स" च्या संचावर अवलंबून असते - प्रत्येक विनंतीबद्दल सिग्नल जे मानवी आहे की बॉट हे ठरवण्यासाठी वापरले जातात.

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

क्लिकहाऊस क्वेरी वर्तनात बदल

क्लिकहाऊस डेटाबेस विरुद्ध क्वेरीद्वारे फीचर फाइल तयार केली जाते.

क्लाउडफ्लेअरने वितरित क्वेरींसाठी सुरक्षा आणि परवानग्या सुधारण्यासाठी सुमारे ११:०५ UTC मध्ये बदल केला - allo

वापरकर्त्यांना केवळ डीफॉल्ट स्कीमामधूनच नव्हे तर अंतर्निहित r0 टेबल्समधून देखील मेटाडेटा पाहण्याची परवानगी देते. क्लाउडफ्लेअर ब्लॉग

फीचर लिस्ट बनवणारी क्वेरी डेटाबेस नावाने फिल्टर केली जात नव्हती; अचानक त्याला डीफॉल्ट आणि r0 दोन्हीकडून डुप्लिकेट कॉलम मिळू लागले, ज्यामुळे फीचर रोची संख्या प्रभावीपणे दुप्पट झाली.

फीचर फाइलचा आकार स्फोट झाला

बॉट मॅनेजमेंट मॉड्यूलमध्ये किती फीचर्स स्वीकारल्या जातील याची कठोर मर्यादा आहे (200 वर सेट केली आहे, सामान्यतः वापरात असलेल्या ~60 पेक्षा खूप जास्त).

जेव्हा नवीन जनरेट केलेल्या फाइलने ती मर्यादा ओलांडली, तेव्हा मॉड्यूल कॅपवर आदळला आणि घाबरला, कारण रस्ट कोडमध्ये एका न हाताळलेल्या त्रुटीमुळे ज्याने त्रुटी मूल्यावर Result::unwrap() वापरले. क्लाउडफ्लेअर ब्लॉग

कोर प्रॉक्सी सेवांनी 5xx त्रुटी परत करण्यास सुरुवात केली

बॉट मॅनेजमेंट कोर प्रॉक्सी मार्गात एकत्रित केल्यामुळे, त्या मॉड्यूलवर अवलंबून असलेल्या कोणत्याही ट्रॅफिकसाठी HTTP 5xx प्रतिसाद म्हणून पॅनिक दिसून आला.

नवीन FL2 इंजिनवर, ग्राहकांना स्पष्ट 5xx त्रुटी दिसल्या.

जुन्या FL इंजिनवर, बॉट स्कोअर शांतपणे शून्यावर गेले, ज्यामुळे बॉट-ब्लॉकिंग नियमांमध्ये खोटे पॉझिटिव्ह येऊ शकतात. क्लाउडफ्लेअर ब्लॉग

खरोखरच वाईट भाग: फाइल "चांगली" आणि "वाईट" मध्ये फ्लिप होत राहिली

क्लिकहाऊस क्लस्टर हळूहळू अपडेट केले जात होते आणि फीचर फाइल दर पाच मिनिटांनी पुन्हा निर्माण केली जात होती.

कधीकधी क्वेरी अपडेट केलेल्या नोड्सवर चालत असे (खराब फाइल तयार करत असे), तर कधी अपडेट न केलेल्या नोड्सवर (चांगली फाइल तयार करत असे).

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

या दोलायमानतेमुळे परिस्थिती अंतर्गतदृष्ट्या अत्यंत गोंधळात टाकणारी होती. सुरुवातीला, क्लाउडफ्लेअरच्या टीमना मोठ्या प्रमाणात DDoS हल्ल्याचा संशय होता कारण त्रुटीचा नमुना साध्या सॉफ्टवेअर क्रॅशसारखा दिसत नव्हता. क्लाउडफ्लेअर स्टेटस पेज, जे त्यांच्या स्वतःच्या पायाभूत सुविधांबाहेर होस्ट केले जाते, त्यानेही थोडक्यात त्रुटी दाखवल्या - हा योगायोग आहे ज्यामुळे बाह्य हल्ल्याचा संशय आणखी वाढला. क्लाउडफ्लेअर ब्लॉग+१

बॉट फीचर फाइल हा सामान्य घटक आहे हे लक्षात आल्यानंतरच चित्र स्पष्ट झाले.

घटनेची टाइमलाइन
क्लाउडफ्लेअरच्या पोस्टमॉर्टम आणि थर्ड-पार्टी रिपोर्ट्सच्या आधारे, आपण १८ नोव्हेंबर २०२५ साठी एक अंदाजे टाइमलाइन एकत्र करू शकतो: क्लाउडफ्लेअर ब्लॉग+२थाउसँडआयज+२

११:०५ यूटीसी - क्लिकहाऊसमध्ये डेटाबेस अॅक्सेस कंट्रोल बदल तैनात केला जातो.

११:२०–११:३० यूटीसी - बॉट मॅनेजमेंट फीचर फाइलच्या वाईट आवृत्त्या तयार आणि प्रसारित होऊ लागतात.

११:२८ यूटीसी - पहिला ग्राहक प्रभाव: ग्राहकांच्या रहदारीवर वाढलेला HTTP ५xx त्रुटी दिसल्या.

११:३०–११:३२ यूटीसी - बाह्य देखरेख साधने आणि स्वयंचलित चाचण्या अधूनमधून अपयश शोधण्यास सुरुवात करतात.

११:३५ यूटीसी - क्लाउडफ्लेअर अंतर्गत घटना कॉल उघडतो; तपास सुरू होतो.

~११:४८ UTC – क्लाउडफ्लेअरने घटनेची पुष्टी करणारे स्टेटस अपडेट प्रकाशित केले. पुन्हा पाठवा

११:३०–१३:०५ UTC – टीम्स कामगारांच्या KV वर्तनात काय बिघाड आहे यावर लक्ष केंद्रित करतात आणि अनेक संभाव्य कारणे (हल्ला परिस्थितीसह) तपासतात.

१३:०५ UTC – मुख्य शमन: कामगार KV आणि क्लाउडफ्लेअर प्रवेश कोर प्रॉक्सी बायपास करण्यासाठी हलविला जातो; प्रभाव कमी होतो. क्लाउडफ्लेअर ब्लॉग

१४:३० UTC – मूळ कारण ओळखले जाते; खराब वैशिष्ट्य फायलींची निर्मिती आणि प्रसार थांबविला जातो. एक ज्ञात-चांगली कॉन्फिगरेशन फाइल मॅन्युअली घातली जाते आणि कोर प्रॉक्सी रीस्टार्ट केली जाते. बहुतेक कोर ट्रॅफिक सामान्य स्थितीत परत येतो. क्लाउडफ्लेअर ब्लॉग

१४:४०–१५:३० UTC – टर्नस्टाइल आणि प्रमाणीकरण प्रयत्नांचा बॅकलॉग दुय्यम लोड स्पाइक तयार करत असल्याने डॅशबोर्ड आणि लॉगिन समस्या रेंगाळतात. क्लाउडफ्लेअर ब्लॉग

१७:०६ UTC – त्रुटी दर बेसलाइनवर परत येतात; क्लाउडफ्लेअर सिस्टम पूर्णपणे सामान्य घोषित करते. क्लाउडफ्लेअर ब्लॉग

वापरकर्त्याच्या दृष्टिकोनातून, सकाळी उशिरा ते दुपारी लवकर UTC दरम्यान आउटेज सर्वात वाईट वाटले, जरी अचूक प्रभाव विंडो प्रदेशानुसार आणि प्रत्येक सेवा कोणत्या क्लाउडफ्लेअर उत्पादनांवर अवलंबून होती त्यानुसार बदलत होत्या.

हे आउटेज इतके महत्त्वाचे का आहे
केंद्रीकरण धोका
क्लाउडफ्लेअर हे प्रमुख क्लाउड प्लॅटफॉर्म (AWS, Azure, GCP) आणि इतर मोठ्या CDN सोबत केंद्रीय इंटरनेट पायाभूत सुविधा प्रदात्यांच्या एका लहान संचाचा भाग आहे. जेव्हा यापैकी एक खेळाडू अयशस्वी होतो, तेव्हा त्याचा परिणाम व्यापक असतो आणि बहुतेकदा स्पष्ट नसतो.

हे आउटेज:

BGP राउटिंग अपघात किंवा ISP केबल कटमुळे आले नाही.

दुर्भावनापूर्ण हल्ल्यामुळे आले नाही (सुरुवातीच्या संशय असूनही).

एकाच कॉन्फिगरेशनमधून आले आहे आणि अंतर्गत घटकातील बग मर्यादित करते.

ते महत्त्वाचे आहे कारण ते दर्शविते की बाह्य हस्तक्षेपाशिवाय देखील किती जटिल, घट्ट जोडलेल्या प्रणाली आपत्तीजनकपणे अपयशी ठरू शकतात. जेव्हा अनेक संस्था एकाच प्रदात्यावर बांधतात, तेव्हा तो प्रदाता इंटरनेटचा एक वास्तविक प्रणालीगतदृष्ट्या महत्त्वाचा भाग बनतो.

"सॉफ्ट" अवलंबित्वांमुळे देखील नुकसान होते
काही प्रभावित सेवा केवळ क्लाउडफ्लेअरचा वापर मूर्ख CDN म्हणून करत नव्हत्या. त्या होत्या:

प्रमाणीकरण आणि शून्य-विश्वास प्रवेशासाठी क्लाउडफ्लेअर प्रवेश वापरणे.

अंतर्गत नियंत्रण विमानांचा भाग म्हणून कामगार केव्ही वापरणे.

बॉट-प्रतिरोधक लॉगिनसाठी टर्नस्टाइलवर अवलंबून राहणे. क्लाउडफ्लेअर ब्लॉग+१

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

घटना टूलिंग किंवा अ‍ॅडमिन UI देखील अयशस्वी झालेल्या प्रदात्यावर अवलंबून असू शकते.

क्लाउडफ्लेअर काय म्हणतो ते बदलेल
क्लाउडफ्लेअरचा ब्लॉग अशाच प्रकारच्या पुनरावृत्तीचा धोका कमी करण्यासाठी कंपनी आधीच घेत असलेल्या अनेक उपाय चरणांची रूपरेषा देतो: क्लाउडफ्लेअर ब्लॉग

स्वयंचलितरित्या तयार केलेल्या कॉन्फिगरेशन फाइल्सचे कठोर सेवन
वापरकर्त्याने पुरवलेल्या इनपुटप्रमाणेच संशय आणि प्रमाणीकरणासह अंतर्गत तयार केलेल्या कॉन्फिग्सवर उपचार करा, ज्यामध्ये रोलआउट करण्यापूर्वी कठोर स्कीमा आणि आकार तपासणी समाविष्ट आहे.

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

त्रुटी वादळांपासून सिस्टम संसाधनांचे संरक्षण करा
कोर डंप, डीबग मेटाडेटा आणि निरीक्षणक्षमता टूलिंग CPU आणि मेमरीला ओझे करू शकत नाहीत याची खात्री करा जेव्हा त्रुटी वाढू लागतात.

कोर प्रॉक्सी मॉड्यूल्समधील अपयश मोड्सचे पुनरावलोकन करा
अनपेक्षित इनपुट किंवा कॉन्फिगरेशन अंतर्गत प्रत्येक अंतर्गत मॉड्यूल कसे वागते ते पद्धतशीरपणे ऑडिट करा आणि जागतिक अपयशाऐवजी सुंदर क्षय सुनिश्चित करा.

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

त्यांनी या घटनेला त्यांच्या लवचिकतेच्या अपेक्षांचे पूर्णपणे अपयश म्हणून देखील मांडले, ते "अस्वीकार्य" म्हटले आणि त्यामुळे ग्राहक आणि सामान्य इंटरनेट वापरकर्त्यांना झालेल्या वेदना स्पष्टपणे मान्य केल्या. क्लाउडफ्लेअर ब्लॉग

पायाभूत सुविधा आणि एसआरई टीमसाठी धडे
जरी तुम्ही क्लाउडफ्लेअरसारखे मोठे काहीतरी चालवत नसलात तरीही, या आउटेजमध्ये काही अतिशय व्यावहारिक डिझाइन आणि ऑपरेशनल धडे आहेत:

अंतर्गत कॉन्फिगरेशनला अविश्वसनीय इनपुटसारखे हाताळा
"आपले स्वतःचे" जनरेट केलेले कॉन्फिगरेशन नेहमीच बरोबर असते असे गृहीत धरणे सोपे आहे. काल ते धोकादायक का आहे ते दर्शविते:

कॉन्फिगरेशन फाइल्स लागू करण्यापूर्वी त्यांचा आकार, आकार आणि मर्यादा नेहमीच सत्यापित करा.

विसंगतींवर स्वयंचलित रोलबॅकसह, ट्रॅफिक किंवा नोड्सच्या लहान उपसमूहावर प्रथम कॉन्फिगरेशनचा कॅनरी अनुप्रयोग विचारात घ्या.

वैशिष्ट्यांची संख्या, मेमरी प्रीलोकेशन आणि सीपीयू वापर यांच्याभोवती कडक वरच्या सीमा आणि सर्किट ब्रेकर ठेवा.

आकर्षक आंशिक अपयशासाठी डिझाइन
बॉट मॅनेजमेंट मॉड्यूलमधील एक बग संपूर्ण प्रॉक्सी मार्गाला घाबरवू शकत नाही:

पर्यायी पूर्ण आउटेज झाल्यावर सुरक्षेच्या काही स्तरांमध्ये डीफॉल्ट फेल-ओपन विरुद्ध फेल-क्लोज.

नॉन-कोर वैशिष्ट्यांसाठी स्पष्ट, चाचणी केलेले किल स्विच तयार करा.

गंभीर उप-प्रणाली (ऑथ, स्टेटस पेज, इव्हिडंट टूलिंग) डिग्रेडेड मोडमध्ये किंवा पर्यायी मार्गांद्वारे ऑपरेट करू शकतात याची खात्री करा.

योग्य सिग्नलचे निरीक्षण करा
दर पाच मिनिटांनी "चांगले कॉन्फिगरेशन" आणि "खराब कॉन्फिगरेशन" मधील दोलन सिग्नलला हल्ला ट्रॅफिक किंवा गोंगाटयुक्त बाह्य वर्तनासारखे दिसू लागले:

तुमच्या निरीक्षणक्षमता पाइपलाइनमध्ये प्रति-आवृत्ती किंवा प्रति-कॉन्फिगरेशन सहसंबंध असल्याची खात्री करा.

डॅशबोर्ड तयार करा जे त्रुटी आलेखांच्या वर कॉन्फिगरेशन बदल दृश्यमानपणे स्पष्ट करतात.

बाह्य व्हॅंटेज पॉइंटवरून मजबूत सिंथेटिक चाचण्या समाविष्ट करा, जेणेकरून तुम्ही नेटवर्क/पथ समस्यांपासून अंतर्गत अपयश पटकन वेगळे करू शकाल.

तुमचे सर्व प्रयत्न एकाच इन्फ्रा बास्केटमध्ये ठेवू नका
क्लाउडफ्लेअर वापरणाऱ्या संस्थांसाठी:

खरोखरच मिशन-क्रिटिकल प्रॉपर्टीजसाठी मल्टी-सीडीएन सेटअपचा विचार करा.

तुमचे स्टेटस पेज पूर्णपणे तुमच्या प्रायमरी स्टॅकच्या त्याच प्रोव्हायडरवर अवलंबून ठेवण्यापासून टाळा (क्लाउडफ्लेअर हे करते, परंतु काल त्यांच्या स्टेटस पेज होस्टमध्ये योगायोगाने समस्या आली ज्यामुळे गोष्टी आणखी गोंधळल्या). क्लाउडफ्लेअर ब्लॉग+१

फॉलबॅक मार्गांशिवाय तुमचे ऑथेंटिकेशन, एपीआय कंट्रोल प्लेन आणि फ्रंटएंड डिलिव्हरी एकाच विक्रेत्याला घट्ट जोडण्यापूर्वी दोनदा विचार करा.

मोठे चित्र
गेल्या काही महिन्यांतच, आम्ही मायक्रोसॉफ्ट अझ्युर, अमेझॉन वेब सर्व्हिसेस आणि आता क्लाउडफ्लेअरमध्ये मोठे आउटेज पाहिले आहेत, या सर्वांमुळे ग्राहक आणि एंटरप्राइझ सेवांचा मोठा भाग तात्पुरता ऑफलाइन झाला आहे. एपी न्यूज+२द वॉशिंग्टन पोस्ट+२

पॅटर्न स्पष्ट आहे:

इंटरनेट काही मोठ्या पायाभूत सुविधा प्रदात्यांवर अवलंबून आहे.

आउटेज बहुतेकदा स्वतःहून होतात, बाह्य हल्ल्यांऐवजी जटिल अंतर्गत बदलांमुळे येतात.

जागतिक दर्जाच्या SRE पद्धती असलेल्या प्रदात्यांमध्येही कॉन्फिगरेशन, डेटाबेस वर्तन आणि हार्ड-कोडेड मर्यादांमधील अनपेक्षित परस्परसंवादांमुळे अडचणी येऊ शकतात.

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

वापरकर्त्यांसाठी, ही घटना बहुतेकदा "त्या सकाळी जेव्हा X आणि ChatGPT लोड होणार नाही" म्हणून लक्षात ठेवली जाईल.

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