6 डरावनी आउटेज कहानियाँ

 (thenewstack.io)
7 पॉइंट द्वारा before30 2020-12-28 | 6 टिप्पणियां | WhatsApp पर शेयर करें

1. Charity Majors, CTO of Honeycomb

  • एक खास क्षेत्र (पूर्वी यूरोप) के यूज़र्स तक push noti नहीं पहुँच रही थी

  • ASG size बदलने के ठीक बाद से यह समस्या शुरू हुई

  • Round Robin DNS record का आकार UDP packet size से बड़ा हो गया था, इसी वजह से समस्या हुई

2. Matthew Fornaciari, CTO of Gremlin

  • डिस्क भर जाने के कारण logs लिखे नहीं जा सके और आउटेज हुआ

  • log rotation फीचर विकसित किया

  • disk usage alert सेट किया

  • Gremlin के जरिए test किया जा सके, ऐसा जोड़ा गया (chaos engineering)

3. Lirran Haimovitch, CTO of Rookout

"हर दिन एक तय समय पर server down हो जाता है — ऐसी एक urban legend थी,

कई हफ्तों की जाँच के बाद security camera में कारण मिला,

सफाई कर्मचारी ने vacuum cleaner लगाने के लिए server का कनेक्शन निकाल दिया था"

4. Daniel "Spoons" Spoonhower, CTO of Lightstep

  • app load नहीं हो रहा था

  • उस दिन कोई deploy या infra change नहीं हुआ था

  • यह पुष्टि हुई कि सिर्फ internal users के लिए ही समस्या हो रही थी

  • app load API की जाँच के दौरान पता चला कि internal users के मामले में extra data return हो रहा था

  • पिछले कुछ हफ्तों में payload धीरे-धीरे बढ़ता रहा और उसी दिन दोपहर में maximum payload size पार होने पर app load fail हो गया

5. Lee liu, CTO of LogDNA

6. Ting Huang, CTO of Transpoit

  • Twitter mobile पर पढ़ा नहीं जा सकता था

  • नई library में session cookie parse न कर पाने की समस्या मिली

संबंधित पढ़ाई

6 टिप्पणियां

 
kunggom 2020-12-29

जिन 5 मामलों का सारांश नहीं दिया गया है, वे प्रमाणपत्र की अवधि समाप्त होने से जुड़े लगते हैं.

सोचा गया था कि प्रमाणपत्र तय समय पर समाप्त हो जाए तो भी कोई समस्या नहीं होगी, लेकिन वह बात सिर्फ़ नए विकसित किए गए सिस्टम पर लागू होती थी, और अब भी इस्तेमाल हो रहे legacy सिस्टम में समस्या पैदा हो गई—यही इसकी कहानी है. संयोग से इस्तेमाल किए जा रहे CI/CD solution में भी वही समस्या आ गई, जिससे काम और ज़्यादा जटिल हो गया.
 
kbumsik 2020-12-29

"सफाईकर्मी ने vacuum cleaner जोड़ने के लिए server का कनेक्शन काट दिया"

अरे बाप रे...
 
kunggom 2020-12-29

मूल लेख पढ़ने पर लगा कि वह हिस्सा सिर्फ भूमिका बाँधने के लिए था, और असली आउटेज यह था कि क्लाइंट कंपनी की तरफ़ का एडमिन मीटिंग के समय या कभी-कभार चलाने वाली क्वेरी पूरी टेबल को लॉक कर देती थी, इसलिए हर बार backend service की latency बिना किसी सीमा के बढ़ जाती थी। शक वाली क्वेरी को optimize किया गया, लेकिन वह गलत दिशा में प्रयास निकला, इसलिए जब भी क्लाइंट कंपनी की तरफ़ से लोग पेज बहुत धीमा होने पर बार-बार refresh करते थे, वही स्थिति लगातार फिर से होती रहती थी।
 
kunggom 2020-12-29

अगर मिलती-जुलती बात कहूँ, तो एक निजी अनुभव है। यह उस समय की बात है जब मैंने फ्रीलांसर के तौर पर जल्दबाज़ी में आए एक shopping mall-संबंधित काम को लिया था.

तड़के shopping mall में एक बड़ा काम (solution का बड़े पैमाने पर version upgrade) किया गया, और product payment जैसी मुख्य सुविधाओं में कोई समस्या नहीं है यह confirm करने के बाद इसे फिर से खोला गया। लेकिन दोपहर होते-होते अचानक shopping mall वेबसाइट बहुत धीमी हो गई, और आखिरकार लगभग रुकने की स्थिति में पहुँच गई। बाद में पता चला कि वजह shopping mall से अलग से जुड़ा seller page था। shopping mall solution के साथ custom development से बना seller management page जोड़कर चलाया जा रहा था, और उसमें प्रवेश करते ही बहुत भारी query चलती थी। shopping mall के दोबारा खुलने के बाद जब-जब individual sellers बिक्री की स्थिति देखने के लिए access करते, MySQL पर load बढ़ता जाता, और आखिरकार पूरा shopping mall ही धीमा हो गया। देखा तो संबंधित table पर किसी कारण से index सही तरह से लगा ही नहीं था। आखिर में index सही तरह से लगाकर और कुछ parameters tune करके पूरे shopping mall के धीमा पड़ने की समस्या को हल किया जा सका.
 
kbumsik 2020-12-31

ओह, अनुभव साझा करने के लिए धन्यवाद.

वैसे admin या business निर्णय के लिए इस्तेमाल होने वाले डेटा में aggregation का उपयोग होता है, इसलिए उस पर लोड काफ़ी ज़्यादा पड़ता होगा। मैं web developer नहीं हूँ, इसलिए बहुत अच्छी तरह नहीं जानता, लेकिन आजकल ऐसा लगता है कि data engineering के नाम पर डेटा को अलग से इकट्ठा करके रखा जाता है।
 
kunggom 2021-01-02

जैसा आपने कहा, ऐसे डेटा को अलग से विभाजित करके प्रोसेस करना ही सही तरीका होता, लेकिन जिस शॉपिंग मॉल पर मैंने काम किया था वह काफ़ी हद तक अव्यवहारिक legacy सिस्टमों वाला स्थान था, इसलिए architecture स्तर की ऐसी कोई भी सोच बिल्कुल नहीं की गई थी। MySQL का बहुत पुराना version (InnoDB नहीं बल्कि MyISAM default engine हुआ करता था, उस दौर का version) उसी VM instance के भीतर, Apache web server के भी पुराने version के साथ चल रहा था। शॉपिंग मॉल चलाने के लिए इस्तेमाल किया जाने वाला solution भी पहले से ही legacy की श्रेणी में जा चुका था और उस स्थिति में केवल patches ही आ रहे थे। काम करते समय मुझे solution में जो structural समस्याएँ महसूस हुईं, लगता है कि शुरू से नए सिरे से विकसित किए गए नए version में उन्हें हल कर लिया गया था, लेकिन legacy version को छू रहे मेरे लिए उस बात का कोई असर नहीं था। वह तो अब पिछले साल की बात हो गई।