रात 2 बजे मानसिक टूटन की anatomy

 (zarar.dev)
1 पॉइंट द्वारा GN⁺ 2024-08-21 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • jumpcomedy.com पर रात करीब 10 बजे से RTK Query के HTTP POST calls सभी fail होने लगे और site की functionality टूट गई; local में सब ठीक था, इसलिए root cause trace करना मुश्किल था
  • customer complaints बढ़ती रहीं, जबकि operator को production support, SRE, senior engineer, manager के बिना अकेले ही outage संभालना पड़ा
  • browser का fetch से जुड़ा TypeError, GET और DELETE के normal होने की स्थिति के साथ मिलकर, कोई सीधा clue नहीं दे पाया
  • Sentry, production DB, Cloudflare, Chrome update, और पुराने version पर rollback जाँचने के बाद भी कोई बदलाव नहीं आया; local में खाली छोड़ी गई PostHog api_key डालने पर issue reproduce हो गया
  • PostHog हटाने के बाद functionality normal हो गई; बाद में PostHog और Redux Toolkit GitHub issues में वही outage confirm हुआ, जिससे यह external tool impact साबित हुआ

outage से बना pressure

  • jumpcomedy.com पर रात करीब 10 बजे से RTK Query based HTTP POST calls सभी fail होने लगे और key features ठीक से काम नहीं कर रहे थे
  • हाल में deploy किए गए changes थे, लेकिन वे cause लगने लायक नहीं थे; local environment में issue reproduce नहीं हो रहा था, जिससे tracing और कठिन हो गई
  • NextJS और Vercel Discord पर मदद मांगी, लेकिन response नहीं मिला; outage response hand over करने के लिए कोई production support organization भी नहीं था
  • customer emails लगातार जमा होती रहीं
    • event price change नहीं कर पाने की query
    • promotion code remove नहीं कर पाने की query
  • छोटे business customers service पर depend करते हैं—इस वजह से operator ने शर्म, दुख, अक्षमता और imposter syndrome महसूस किया

debugging process और cause confirmation

  • browser error एक TypeError था कि fetch पहले से इस्तेमाल हो चुके request object के साथ execute हुआ, लेकिन उसने असली cause नहीं बताया
  • कई console.log() और breakpoints जोड़कर headers, API token length, call order आदि check किए, लेकिन कोई clear cause नहीं मिला
  • Chrome update की possibility पर शक हुआ, लेकिन Firefox और Edge में भी reproduce हुआ, इसलिए यह सिर्फ browser issue नहीं था
  • पुराने version पर लौटाने के बाद भी failure जारी रहा
    • एक महीने पुराने version में भी failure
    • तीन महीने पुराने version में भी failure
    • 1 साल पुराने version में भी failure
  • local और production के differences घटाने के लिए कई candidates check किए गए
    • production से Sentry हटाना: कोई बदलाव नहीं
    • local को production DB से connect करना: कोई बदलाव नहीं
    • Cloudflare disable करना: कोई बदलाव नहीं
  • local में cost बचाने के लिए PostHog api_key खाली छोड़ी गई थी; उसे add करते ही वही issue reproduce हो गया
  • अगले commit में PostHog हटाते ही सभी features normal काम करने लगे
  • बाद में GitHub issues से भी वही समस्या confirm हुई

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

1 टिप्पणियां

 
GN⁺ 2024-08-21
Hacker News की राय

  • एक बड़ी global company में 1 साल तक SRE के तौर पर काम करते हुए, मैं लेख में बताए गए “panic” mode से बाहर निकल पाया
    Business के नजरिए से हर समस्या दुनिया खत्म होने जैसी घटना लगती है, और उस स्थिति में panic में जाना आसान होता है, लेकिन असल में हालात शायद ही इतने खराब होते हैं, और अगर खराब भी हों तो आम तौर पर हम सही-सलामत निकल आते हैं
    ऐसी स्थिति में तुरंत ठीक करने के लिए हाथ लगाने से पहले 5–10 मिनट रुकना और स्थिति की जितनी साफ तस्वीर बन सके, बनाना ही key है। डर तार्किक फैसले में बाधा डालता है, और panic में बटन अंधाधुंध दबाने से समस्या और उलझ सकती है। चेहरे और हाथों पर बहुत ठंडा पानी डालकर fear circuit को तोड़ना मेरा तरीका है
    ऐसी चीजें कुछ बार झेल लेने के बाद समझ आता है कि जितना सोचा था उतना बुरा नहीं है, और यह confidence आता है कि पहले भी खराब हालात संभाले हैं, इसलिए मदद मांगने के लिए कोई न भी हो तो भी संभाला जा सकता है

    • जब कुछ “टूट” जाता है तो company हंगामा कर सकती है, लेकिन याद रखना चाहिए कि उससे भी ज्यादा महत्वपूर्ण हो सकने वाली समस्याओं पर वह बिल्कुल नहीं घबराती
      खरीदा हुआ software staffing या configuration failure की वजह से कुछ भी न कर पाए, employees खराब user experience और बेकार requirements के कारण हर साल हजारों घंटे गंवाएं, कोई capability बिना किसी काम के पड़ी रहे, बेकार meetings रोज समय बर्बाद करें, audit requirements पूरी करने के लिए सिर्फ मौजूद रहने वाली features हों, या executives लगातार company का पैसा बर्बाद करते रहें—ऐसी चीजें
      Downtime इन समस्याओं से ज्यादा बुरा नहीं लगता, लेकिन यह कहीं ज्यादा attention और panic खींचता है। यह आतंकवाद और heart disease के contrast जैसा महसूस होता है। Company आपकी नींद या mental health की परवाह नहीं करती, और जितना हो सके उतना push करती है। इसका मतलब यह नहीं कि वह malicious है, लेकिन इस मामले में bully की तरह, आप जितना पीछे हटते हैं, वह उतना और push करती है
    • असली incidents के दौरान मैंने जो सबसे खराब गलतियां देखीं, वे आम तौर पर overreaction से आईं
      मेरे programming mottos में से एक है “black magic नहीं”। अगर आप नहीं समझते कि यह क्यों काम करता है, तो काम खत्म नहीं हुआ
      Incident response को भी मैं इसी तरह देखता हूं। अगर किसी के suggestion से असर क्यों पड़ेगा, यह coherently explain नहीं किया जा सकता, तो मुझे लगता है उसे execute नहीं करना चाहिए। कभी ऐसा वक्त आ सकता है जब बस trigger दबाना पड़े, लेकिन पीछे मुड़कर देखने पर लगता है कि आखिर में ऐसा कभी हुआ ही नहीं
      आम तौर पर बहुत शांत रहने वाले senior executives को incident के बीच arbitrary fix candidates फेंकना शुरू करते देखना काफी shock देने वाला था
    • इसके उलट jumpcomedy.com पर रात 2 बजे, करीब ±2 time zones में event की prices बदलने वाले लोग बहुत निराश हुए होंगे। उनमें से कुछ शायद मर भी गए होंगे
      कल्पना कीजिए, अगर किसी ने इस solo developer को “fetch को trend बनाने की कोशिश मत करो” कहकर रोक दिया होता, तो नुकसान कितना ज्यादा होता
    • मेरे जानने वाले सबसे शानदार VPs में से एक अक्सर कहते थे, “धीमा ही smooth है, और smooth ही तेज है”
      यह बात सही है कि डर तार्किक फैसले में बाधा डालता है, और मैं यह भी जोड़ना चाहूंगा कि डर बहुत infectious होता है। Practitioners जब leaders, managers या colleagues को panic में देखते हैं, तो वे भी अक्सर panic में आ जाते हैं। सौभाग्य से मेरे VP हमेशा शांत रहते थे, और action से पहले clarity को प्राथमिकता देते थे
    • आखिरकार वह risk आप नहीं उठा रहे होते। वह आपकी company नहीं है, और company आपको किसी भी समय काट सकती है और सच में करेगी भी। हां, अगर company आपकी है तो बात अलग है

  • मुझे नहीं पता कि यह सच में mental breakdown है या नहीं, और यह technical stress से वास्तविक breakdown झेलने वालों को गलत impression भी दे सकता है
    मेरे साथ ऐसा सिर्फ एक बार हुआ, और वह anxiety attack था। मैं बहुत lucky था कि मेरी पत्नी साथ थी, उसने स्थिति समझाई और मुझे यह समझने में मदद की कि मैं क्या झेल रहा हूं। उसे कई बार हुआ था, लेकिन मेरे लिए वह पहली और शुक्र है आखिरी बार था
    ऐसी चीज इंसान के साथ हो सकती है, और अपने आप में इसमें कुछ गलत नहीं है। यह मतलब नहीं कि आप defective या weak हैं—इस बात को भीतर तक स्वीकार करना सच में बहुत जरूरी है
    मेरे मामले में अंततः जिसने इसे रोका वह Xanax था, और क्योंकि मैं सो पाया, इसलिए इसे पहुंच में रखना मुझे मूल्यवान लगता है
    कहना यह है कि intrusive thoughts और anxiety attack या panic attack जैसी ऐसी स्थितियां अलग हैं जिन्हें वास्तव में control नहीं किया जा सकता और जो function करने की क्षमता को पंगु बना देती हैं। ऐसा हो तो आप काम नहीं कर पाएंगे, और यह ठीक है

    • https://www.webmd.com/mental-health/signs-nervous-breakdown
      हर breakdown panic या anxiety attack के रूप में नहीं आता। वह ऐसे दिख सकता है, लेकिन यही एकमात्र तरीका नहीं है। Stress हर व्यक्ति में, और यहां तक कि हर stressor के हिसाब से, बहुत अलग तरह से दिखता है
      उस व्यक्ति के दिमाग में असल में क्या हुआ, यह हम नहीं जान सकते, इसलिए बाहर से “diagnose” करना लगभग असंभव है। भले ही वह पूर्ण panic attack न रहा हो, लेकिन यह कुछ घंटों तक functional paralysis जैसा जरूर सुनाई देता है
    • “Xanax पास रखना अच्छा है” वाली बात पर सावधानी चाहिए
      Online खोजने पर लगता है कि Xanax addictive हो सकता है
      https://www.drugs.com/xanax.html
      यह ऐसी चीज नहीं लगती जिसे casually लिया जाए
    • हमेशा आधे-अधूरे release होने वाले features, बिना सोचे push किए गए changes, और उनसे आने वाले रात 3 बजे के PagerDuty alerts संभालने के लिए मुझे दवा नहीं खानी चाहिए
      2000s के मध्य में tech industry में आए बड़े समूह को stress-related illnesses से मरते देखने की संभावना बड़ी है
    • Enterprise tech company में काम करते हुए जिन चीजों की मुझे उम्मीद नहीं थी, उनमें से एक यह थी कि नियमित रूप से Xanax लेने वाले colleagues कितने ज्यादा हैं
      जिंदगी भर severe anxiety झेलने वाले व्यक्ति के तौर पर, यह विचार ही डरावना है कि एक addictive pill यह सब खत्म कर सकती है। मुझे लगता है मैं जिंदगी भर उसी से चिपका रह जाऊंगा
    • सच कहूं तो यह साधारण dependency debugging की कहानी निकली, इसलिए निराशा हुई। पहले भी मुझे कुछ बार breakdown के करीब पहुंचने जैसा लगा है, इसलिए उम्मीद थी कि लेख उससे ज्यादा relatable होगा

  • इस व्यक्ति का stress PostHog के code की एक line के कारण पैदा हुआ। Revert किया गया commit यह है: https://github.com/PostHog/posthog-js/pull/1371/commits/7598...
    यहां मुझे दो lessons दिखते हैं। पहला, अगर आपने deploy किया है, तो वह आपकी ownership है। इसलिए जितना कम deploy करें उतना अच्छा, और dependencies कम से कम रखनी चाहिए। दूसरा, जो जरूरी नहीं है उसे critical path से बाहर रखना चाहिए। Air conditioner compressor खराब हो जाए तो engine बंद नहीं होना चाहिए। Browser में इसे हासिल करना बहुत मुश्किल है, लेकिन कोशिश करने लायक है

  • इससे भी बुरा यह कि PostHog ऐसा लगता है जैसे वह अपने कोड के कुछ हिस्सों को रनटाइम पर dynamically update करता है, और build time पर bundle नहीं करता
    docs में सभी dependencies को build में शामिल करने का एक advanced option है। वे ऐसा क्यों करते हैं, यह समझ आता है, और हो सकता है मैंने गलत समझा हो, लेकिन user के नज़रिए से उम्मीद होती है कि execution code lazy loading default नहीं बल्कि optimization option होना चाहिए। मेरे हिसाब से इसे सिर्फ तब इस्तेमाल करना चाहिए जब complete bundling से delivery में गंभीर delay हो

    • ये सीखें निश्चित रूप से valuable हैं, लेकिन उसके बाद marketing team का कोई व्यक्ति आएगा और site में PostHog या कोई दूसरा tracking script डालने की मांग करेगा, और मना करने को स्वीकार नहीं करेगा

  • bug शायद monkey-patch किए गए window.fetch के अंदर था
    https://github.com/PostHog/posthog-js/blob/759829c67fcb8720f...
    यहां सबसे बड़ी सीख यह है कि अगर आप एक लोकप्रिय library बनाते हुए global function monkey-patch कर रहे हैं, तो tests वाकई बहुत अच्छे होने चाहिए
    “सावधानी के लिए PostHog call को try/catch में डाल दें” और “PostHog की वजह से सचमुच fetch() से POST request भेजी ही नहीं जा सकती” — ये दोनों बिल्कुल अलग बातें हैं

    • यह देखने के लिए मैंने जांचा कि test में यह क्यों नहीं पकड़ा गया, और पता चला कि एक सामान्य fetch call से भी error आ सकता था। fetch का इस्तेमाल करने के अलग-अलग तरीकों के लिए test coverage कम है, और लगता है बहुत ज्यादा mocking ने भी भूमिका निभाई: https://github.com/PostHog/posthog-js/blob/main/src/_tests...
      fetch और XHR functions पूरे के पूरे mock कर दिए गए हैं ताकि वे कुछ करें ही नहीं, तो जाहिर है कि नीचे native या दूसरी libraries के साथ interaction में आने वाली समस्याएं नहीं पकड़ी जाएंगी। Cypress भी configured है, फिर browser API को mock क्यों करना चाहते हैं, समझ नहीं आता
    • यह point उठाने के लिए धन्यवाद। मैंने article ध्यान से नहीं पढ़ा था, लेकिन सोच रहा था कि monitoring library पूरी application को कैसे down कर सकती है
      अगर integration reasonable होता, तो worst case में भी बस monitoring event handling fail होना चाहिए था, ऐसा मुझे लगा था
      PostHog एक बेहद अहम global function को patch करता है — यह feature अच्छी तरह documented होना चाहिए। ताकि users इसे जानते हों और बाहर से समझाना मुश्किल लगने वाली problems debug करते समय इसे reasonable तौर पर ध्यान में रख सकें
    • लगता है यह definition के हिसाब से ही काम कर रहा था। क्या उसने POST request को hog नहीं कर लिया?
    • ऐसी analytics toolkits में यह आम बात है। ऐसी core API को छूते हुए हर चीज को असल में कैसे test किया जा सकता है, मुझे समझ नहीं आता
      उदाहरण के लिए Heap Analytics अभी भी, इस महीने तक, Hotwire के internals में कुछ छेड़ देता है, जिससे Hotwire random तरीके से पूरी तरह टूट जाता है और हर click full page load बन जाता है। मेरे अनुभव में यह page loads के 30–60% को प्रभावित करता है। इसे fix किया जा सकता है, लेकिन Heap को सभी Hotwire JavaScript के बाद load करवाने तक मुझे 50 घंटे से ज्यादा debugging करनी पड़ी

  • जैसा दूसरों ने कहा, इस देर रात वाले stress तक ले जाने वाला bug PostHog library में एक-line change था[0]
    मेरे लिए यह variables को सही नाम देने की अहमियत की याद दिलाने जैसा है
    res = await originalFetch(url, init) code काफी harmless दिखता है। लेकिन TypeScript declaration दिखाता है कि url parameter जरूरी नहीं कि URL हो: url: URL | RequestInfo
    जब वह URL नहीं बल्कि RequestInfo object हो, तो समस्या होती है। function implementation की शुरुआत में Request object बनाते समय वह पहले ही “consume” हो चुका था, और यहां उसे फिर से इस्तेमाल नहीं किया जा सकता
    अगर parameter का नाम urlOrRequestInfo जैसा ज्यादा accurate होता, तो इस change में problem छूट जाना और मुश्किल होता
    और भी ज्यादा speculative विचार यह है कि linear logic से निकले linear types value के “consume” होने को formalize कर सकते हैं, इसलिए सही type system शायद इस तरह के bugs रोक भी सकता है
    [0] https://github.com/PostHog/posthog-js/pull/1351/commits/2497...

    • linear/affine type system की समस्या यह है कि entry barrier बहुत ऊंचा होता है
      Rust जैसी languages की ownership semantics ही देख लें। यह कोई अभेद्य दीवार नहीं है, और खासकर experience बढ़ने पर बेहतर हो जाता है, लेकिन learners सबसे ज्यादा जिस बात की शिकायत करते हैं, वह यही बोझ है

  • article stressful था, लेकिन funny भी। हालांकि self-blame वाला हिस्सा बहुत परिचित लगा
    मैं एक काफी successful iOS/macOS app चलाता हूं, और एक बार release push करके 3.5 लाख से ज्यादा installs पूरी तरह खराब कर दिए थे। यह पूरी तरह मेरी गलती नहीं थी, लेकिन product मेरा था, तो फर्क ज्यादा नहीं था
    उस समय ठंडे पसीने और शर्मिंदगी की feeling बहुत intense थी। ऊपर से App Store था, इसलिए fix को भी review process से गुजरना था, जिससे समय बढ़ गया। सौभाग्य से submit करने के 30 मिनट बाद review शुरू हो गया और कुछ ही मिनटों में approve हो गया

    • developer के रूप में मेरी पहली job में, मुझे customers की चीजें कम उम्र में तोड़ने की “इजाजत” इसलिए मिली क्योंकि मैं smart नहीं बल्कि incompetent था
      career बढ़ने और leadership में आने के बाद समझ आया कि वह बहुत valuable experience था। पहले शायद stress होता था, लेकिन अब वह याद इतनी दूर चली गई है कि असर ही नहीं करती। अब तो निश्चित रूप से stress नहीं होता
      यह विवादास्पद हो सकता है, लेकिन मैं कभी-कभी early-career team member को production environment तोड़ने देता हूं। जब मुझे पहले से दिख रहा हो और भरोसा हो कि हम जल्दी recover कर सकते हैं
      fail करने की जगह देना जरूरी है, यह common sense है, लेकिन कई leaders असली customers को प्रभावित करने वाली failure पर line खींच देते हैं। अगर आप ऐसी बहुत common और fortunate situation में हैं जहां आप airplane land कराने वाला software जैसी critical चीज नहीं बना रहे, तो Washington State के Spokane में कोई व्यक्ति कुछ मिनटों के लिए product न इस्तेमाल कर पाए — इसकी कीमत पर भी team को production outage का experience मिलना चाहिए

  • ऐसा article लिखने के लिए धन्यवाद। खासकर pressure में, आम तौर पर रात भर जागकर, लोग ऐसी challenges को कैसे पार करते हैं, यह पढ़ना मुझे पसंद है
    सिर्फ technical postmortem ही नहीं, बल्कि वह human perspective भी सुनने को मिला जो अक्सर ऐसी कहानियों से हटा दिया जाता है, इसलिए यह और बेहतर लगा। ऐसी technical narratives शायद वही छोटी/solo developer या founder स्वतंत्रता से साझा कर सकते हैं

  • समस्या को ट्रेस करने का तरीका देखकर ही पहले यह दिखता है कि वे प्रोग्रामर हैं। वे अपने code की तरफ गए, logs की तरफ गए। दोनों reasonable थे और दोनों कारण हो सकते थे, लेकिन उनके पास मौजूद सबसे अहम clue—“localhost पर यह काम कर रहा था”—छूट गया
    SRE, DevOps, platform engineer, या उस दिन जो भी title लगा हो, मैं काम कर रहे system और न काम कर रहे system के फर्क पर ध्यान देता। फर्कों को एक-एक करके जोड़ता और हटाता, या हटाकर फिर जोड़ता, जब तक कुछ काम न करने लगे
    मुझे दो बातें दिखती हैं। 1) एक environment है जो काम करता है। 2) जो environment fail हो रहा है, वह भी मूल रूप से काम कर रहा था और फिर fail होना शुरू हुआ
    इसका मतलब यह नहीं कि मेरा तरीका बेहतर है। बस समस्या को देखने के तरीके का फर्क दिखाना है। दोनों अपने-अपने ज्ञान के आधार पर दायरा छोटा करते हैं। मैं system जानता हूँ, आप code जानते हैं

    • बहुत पहले जब मैं electronics technician था, service से हटाए गए Perkin Elmer 7/32 के processor boards का ढेर था। वे खराब boards थे, कई revisions में थे, और हर board के लिए सिर्फ एक revision का schematic था
      मुझे लगा कोई उम्मीद नहीं, लेकिन एक उम्रदराज और ज्यादा समझदार technician ने मुझे तरीका सिखाया
      अच्छे board को extender में लगाओ, और fail होने वाले diagnostic program को loop में चलाओ। oscilloscope से connector के हर pin को देखो और record करो। फिर खराब board से बदलकर दोहराओ
      कौन-सा signal अलग है? उस signal को पीछे तक trace करो। अगर schematic सही नहीं है, तो voltmeter और अपनी आँखों से actual wiring को दर्शाने वाला schematic बनाओ
      वे इसे “good card - bad card” कहते थे, और यह सच में काम करता था। मैं यह दावा नहीं करूँगा कि यह cost-effective था, लेकिन हमने सारे boards ठीक कर लिए, और digital electronics circuit troubleshooting की मेरी क्षमता काफी बढ़ गई
      यह एक तरह का “firefighter” वाला काम था। काम ही systems के खराब होने का इंतजार करना था, इसलिए अगर 2 technicians एक circuit board पर 1 हफ्ता भी लगा दें तो कोई फर्क नहीं पड़ता था

  • “चलो एक महीने पहले वाले version पर वापस चलते हैं। नहीं हुआ। तीन महीने पहले? नहीं हुआ। अभी भी fail। एक साल पहले? बिल्कुल नहीं।”
    क्या वे सिर्फ अपना code ही rollback कर रहे थे, और उसी दिन टूटे PostHog update का इस्तेमाल जारी रख रहे थे? मेरे लिए सबक यह है कि dependencies सहित सब कुछ rollback करने लायक होना चाहिए

    • लगता है PostHog अपने कुछ हिस्सों का latest version हमेशा load करता है
      https://github.com/PostHog/posthog/issues/24471#issuecomment...
      खुद bundle करने का विकल्प भी है
      https://github.com/PostHog/posthog/issues/24471#issuecomment...
    • यही मुख्य सबक है। अगर आप application के किसी हिस्से को किसी दूसरे CDN से link कर रहे हैं, तो आपकी अपनी deployment का कोई मतलब नहीं रह जाता
      मूल लेखक ने इसे अच्छी तरह handle किया। ऐसी outages का positive पक्ष यह है कि उनसे बहुत सारे valuable lessons निकलते हैं

  • यह एक अच्छा लेख है जो service के पीछे मौजूद लोगों की फिर याद दिलाता है, और debugging process को भी अच्छी तरह दिखाता है
    व्यवहार में pressure समस्या को जल्दी debug कराने में मदद नहीं करता। आमतौर पर यह सोचने में बाधा डालता है। नतीजों को जितना हो सके ignore करके, जितना संभव हो शांत रहना चाहिए
    हम में से ज्यादातर लोगों ने अलग-अलग स्तरों पर ऐसी ही स्थितियाँ झेली होंगी। बेशक अपनी company चलाने का stress खास तौर पर बहुत बड़ा होता है