मेरी 500 मिलियन डॉलर की Mars rover गलती

 (chrislewicki.com)
1 पॉइंट द्वारा GN⁺ 2023-11-29 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • फ़रवरी 2003 में JPL क्लीनरूम में Spirit Mars Rover को लॉन्च साइट भेजे जाने में 2 हफ़्ते बचे थे, और break-out-box कनेक्शन की एक गलती 500 मिलियन डॉलर के spacecraft को बर्बाद कर सकती थी
  • Spirit और Opportunity NASA का जुड़वाँ Mars rover मिशन थे, जिन पर लगभग 1 बिलियन डॉलर खर्च हुए थे, और शेड्यूल में किसी बड़ी खराबी को ठीक करने की लगभग कोई गुंजाइश नहीं थी
  • मोटर की बजाय spacecraft की ओर बिजली का pulse जाने के तुरंत बाद telemetry बंद हो गई, लेकिन नुकसान हुआ या नहीं और कारण क्या था, यह तुरंत तय नहीं हो सका
  • अगले दिन पुष्टि हुई कि telemetry का नुकसान Fluke 87III multimeter की leads हटाने की वजह से हुआ था, जबकि असली surge का विश्लेषण H-Bridge motor driver channel पर जारी रहा
  • कई हफ़्तों के विश्लेषण के बाद प्रोजेक्ट ने hardware को Use As Is माना, प्रक्रिया ठीक की, वही test जारी रखा, और Mars पर Spirit की वह मोटर सामान्य रूप से चली

लॉन्च से ठीक पहले Spirit पर हुआ test accident

  • फ़रवरी 2003 में, NASA JPL के Building 179 High Bay 1 क्लीनरूम में Spirit Mars Rover को Cape Canaveral भेजे जाने में 2 हफ़्ते बचे थे
  • Spirit और Opportunity जुड़वाँ Mars rover मिशन थे, और उस समय NASA ने इन जटिल spacecraft पर लगभग 1 बिलियन डॉलर निवेश किए थे
  • assembly और test चरण में spacecraft को पृथ्वी पर आख़िरी बार बंद करने से पहले हर system की पूरी जाँच कर उसका सही काम करना सुनिश्चित करना ज़रूरी था
  • दोनों rovers में कुल 62 brushed-type motors लगे थे
    • पहियों की drive और steering
    • robotic arm control
    • camera pointing
    • Earth-pointing antenna direction control
    • landing के बाद unfolding और deployment motions
  • उस रात test का लक्ष्य Spirit की robotic arm के सिरे पर लगे Rock Abrasion Tool(RAT) के अंदर का RAT-Revolve motor था
    • RAT-Revolve motor Mars की चट्टानों पर grinder और brush को घुमाने का काम करता था

electric signal से motor की हालत जाँचने की प्रक्रिया

  • हर environmental test के बाद motor को खोलकर भीतर जाँच करना व्यावहारिक नहीं था
  • इसके बजाय motor को spacecraft से अलग कर बाहरी power supply और strip chart recorder से जोड़कर उसकी electrical performance जाँची जाती थी
  • सामान्य motor में spin-up के दौरान current एक smooth exponential रूप में घटता है, और गड़बड़ी होने पर signal में blip दिखाई देता है
  • test में break-out-box इस्तेमाल होता था, और अगर कनेक्शन ग़लत हो जाए तो भारी current गलत जगह जाकर घातक नुकसान कर सकता था
  • pre-check में connection interface, power supply settings, strip chart settings, और reference motor पर short test pulse — सब सही पाए गए थे

ग़लत दिशा में गया electric pulse

  • जैसे ही RAT-Revolve motor को energy दी गई, strip chart पर ऐसा signal दिखा जो परिचित नहीं था, और वह खराब motor के सामान्य signal जैसा भी नहीं था
  • wiring ट्रेस करने पर पता चला कि break-out-box की गलती की वजह से electric pulse motor की बजाय connector interface की उलटी दिशा में, यानी spacecraft की ओर गया था
  • Spirit को launch-prep shipment में सिर्फ़ 2 हफ़्ते बचे थे, इसलिए अगर बड़ी समस्या आती तो recovery का समय नहीं था
  • accident की सूचना तुरंत test conductor Leo को दी गई, और उसी समय spacecraft से telemetry कटने की प्रतिक्रिया मिली
  • टीम ने तुरंत emergency shutdown procedure चलाया और घटना व नुकसान का आकलन करने के लिए क्लीनरूम से बाहर जाने का निर्देश मिला

telemetry loss और शुरुआती आकलन

  • accident के तुरंत बाद दो बातें साफ़ थीं
    • एक बड़ा electric pulse इच्छित जगह के अलावा कहीं और गया था
    • spacecraft telemetry रुक गई थी
  • दोनों घटनाओं के बीच संबंध तुरंत स्पष्ट नहीं था
  • टीम को लगा कि electrical surge शायद H-Bridge motor driver circuit में गया होगा
    • H-Bridge को electric flow नियंत्रित करने वाले circuit के रूप में संभाला जाता था
    • back-EMF की वजह से rover में अतिरिक्त energy सहने के लिए डिज़ाइन किए गए हिस्सों में यह एक था
  • spacecraft पहले से powered down था, और टीम ने देखा कि क्या power फिर से देने पर समस्या दूर होती है
  • लगभग आधी रात को project manager Pete तक भी घटना की रिपोर्ट पहुँची, और लगभग 1,000 लोगों वाले प्रोजेक्ट की replan संभावना दाँव पर थी

reboot असफल रहा और अगले दिन मिला असली कारण

  • standard spacecraft power-up procedure फिर से चलाया गया, लेकिन electronics और software के ऊपर आने के बाद भी telemetry वापस नहीं आई
  • ground support equipment rack में एक लाल indicator था जो हर clock cycle पर pulse पाकर जलता था, और प्रति सेकंड 8 बार की robotic heartbeat की तरह उपयोग होता था
  • power supply ने परिचित voltage steps और current changes दिखाए, लेकिन indicator नहीं जला और telemetry भी नहीं आई
  • अगले दिन घटनाक्रम फिर से देखने पर Fluke 87III digital multimeter एक अहम सुराग बना
  • पिछले दिन test के लिए ज़रूरी multimeter ढूँढते समय, एक ऐसे multimeter की leads हटा दी गई थीं जो spacecraft के पास bus voltage monitor करता हुआ लग रहा था
    • यह multimeter वास्तव में spacecraft के ground-test telemetry power circuit को पूरा कर रहा था
    • leads हटाते ही telemetry power connection टूट गया

Spirit ज़िंदा था, और hardware को वैसे ही उपयोग किया गया

  • टीम ने multimeter को उसकी मूल भूमिका में वापस लगाया और spacecraft को फिर power दिया
  • telemetry फिर से जीवित हो गई, और पुष्टि हुई कि Spirit मरा नहीं था
  • असली नुकसान सिर्फ़ कुछ घंटों का था, और test फिर शुरू हो गया
  • इसके बाद कई हफ़्तों तक RAT-Revolve motor के H-Bridge channel का विश्लेषण किया गया, और thin-film demetallization की संभावना पर विस्तृत चर्चा चली
  • अंततः प्रोजेक्ट ने उस hardware को Use As Is माना
  • rover की launch preparation जारी रही, और Mars पर पहुँचने के बाद Spirit का RAT-Revolve motor सामान्य रूप से चला

failure experience को संभालने का तरीका

  • इस घटना ने इस विश्वास को मज़बूत किया कि failure experience साझा करना, बोलने वाले और सुनने वाले दोनों के लिए सीख बन सकता है
  • Planetary Resources में hiring process और team culture के दौरान उम्मीदवारों से अपनी failure story साझा करने को कहा जाता था
  • संकट के बीच Ernie ने कहा, “अगली बार जब तुम्हें किसी चीज़ को ठीक मानकर approve करना हो, तो इस एहसास को याद रखना”
  • accident के बाद कुछ लोगों का मानना था कि ऐसे जोखिम भरे test रोक देने चाहिए, लेकिन Mars पर motor सामान्य चलेगी या नहीं यह जाँचने वाले test की अहमियत के कारण test जारी रहा
  • project manager Pete ने उसी व्यक्ति को test lead करते रहने दिया, और उनका आशय था, “हम उसकी training cost चुका चुके हैं, और अब वही व्यक्ति है जिसके इस गलती को दोबारा करने की संभावना सबसे कम है”
  • बाद में वही गलती दोहराई न जाए, इसके लिए procedure सुधारा गया, और वही test कई बार फिर किया गया
  • यह अनुभव बाद में किसी महत्वपूर्ण approval या assurance के समय उस डर और पछतावे को याद दिलाने वाला reference point बन गया

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

1 टिप्पणियां

 
GN⁺ 2023-11-29
Hacker News की रायें

  • लेख वाकई बहुत अच्छी तरह लिखा गया है
    एक software engineer के तौर पर करियर की शुरुआत में मेरे साथ हुई मिलती-जुलती घटना आज भी याद आती है। करीब 10 साल पहले मैं जिस client company के लिए consulting कर रहा था, उसकी web service का नया version कई महीनों तक बनाया और launch वाले दिन deployment की जिम्मेदारी मेरे पास थी। उस समय development और deployment process लगभग पूरी तरह manual था। जिन हिस्सों को संभव था, उन्हें scripts और SQL से automate किया था, और deploy से ठीक पहले आखिरी test करने के लिए जैसे ही Enter दबाया, उसी पल एहसास हुआ कि अभी-अभी मैंने production credentials पर switch किया हुआ था
    Errors जमा होने लगे और service ने response देना बंद कर दिया, तो मुझे पूरा यकीन हो गया कि मैंने database उड़ा दिया है। लेकिन कुछ घंटे पहले ही किसी ने launch की तैयारी में backup पूरा कर लिया था, इसलिए अधिकतर चीजें restore हो गईं। उसके बाद से databases और production systems संभालते समय सावधानी शब्द भी कम पड़ने लगा, और मैंने ठान लिया कि ऐसा फिर कभी नहीं होगा

    • हमारे यहां भी event sourcing architecture है, इसलिए production database को सीधे access करना दुर्लभ है। जब जरूरत होती है, तो shell script से bastion host के जरिए tunnel खोलते हैं और Postgres client configuration के लिए standard environment variables expose करते हैं
      Test suite चलते समय tables को delete करके फिर से create करता है या खाली करता है। एक दिन lead developer ने production DB पर bug fix explore करने के बाद make test चला दिया। Test code ने environment variables को ज्यों का त्यों follow किया और Docker के बजाय production से connect हो गया, और तुरंत उन production tables को दर्जनों बार delete और recreate कर दिया
    • करीब 10 साल पहले जहां मैं consulting कर रहा था, वहां किसी दूसरे product के responsible internal employee ने अलग-अलग windows में dev DB और production DB, दोनों में login कर रखा था और गलती से production database delete कर दिया। Restore करने गए तो पता चला कि backups महीनों से fail हो रहे थे, और यह साफ हो गया कि नए product में मदद के लिए consultants क्यों hire किए गए थे
      खुशकिस्मती से हर customer site पर एक local DB था जो central DB से sync होता था, इसलिए connection टूटने पर भी product चलता रहा। उसने 3–4 दिन तक लंबी shifts में काम करके पुराने backups और customer data को जोड़कर master DB को फिर से बनाया
    • Visual Studio के अंदर production database पर migration चला चुका हूं। पीछे मुड़कर देखें तो यह recover हो सकने वाली चीज थी, लेकिन VS tree view में सारे tables गायब होने लगने का वह पल ऐसा था जैसे दिल रुक गया हो
      1 second बाद वे फिर दिखाई देने लगे; असल में सिर्फ view refresh हुआ था। सच में बेहद खराब UI था
    • करीब 15 साल पहले, एक लंबे weekend से पहले मैं निकलने की तैयारी कर रहा था, तभी एक करीबी marketing colleague ने customer site पर जल्दी सा बदलाव करने को कहा। कंपनी छोटी थी, करीब 15 लोग, और customers हमारी क्षमता से कहीं ज्यादा थे, इसलिए मेरे पास वह production database access था जो होना नहीं चाहिए था
      Product marketing copy बदलने के लिए मैंने एक छोटी UPDATE query लिखी, लेकिन जैसे ही वह तुरंत खत्म नहीं हुई, मुझे समझ आ गया कि गड़बड़ हो गई है। बिना condition के पूरी चीज update हो गई और हजारों product descriptions बदल गए। Backup access वाला DB admin किसी और time zone में था और जा चुका था; एक घंटे से ज्यादा फोन करने के बाद हम restore कर पाए
      निकलते-निकलते किया जाने वाला छोटा बदलाव कई घंटों की damage control में बदल गया। Marketing वाला दोस्त लगातार माफी मांगता रहा, लेकिन गलती मेरी थी। Customers की तरफ से ज्यादा कुछ नहीं आया, शायद इसलिए कि वह public holiday weekend का Friday शाम 5 बजे था
    • करीब 20 साल पहले जहां मैं काम करता था, वहां policy थी कि sudo command चलाते समय Enter दबाने से पहले किसी दूसरे व्यक्ति को command verify करनी होती थी। Production में किए जाने वाले हर काम पर भी ऐसी ही policy या practice लागू की जा सकती है

  • यह वाक्य याद आता है: अगर intern ने production database delete किया, तो वह खराब intern नहीं, खराब process है
    यह process की समस्या है या व्यक्ति की, यह आसानी से तय करना मुश्किल है, क्योंकि full-time employees से expectations ज्यादा होती हैं। लेकिन उसकी जगह खुद को रखकर पढ़ते हुए, जिस पल उसे समझ आया होगा कि क्या हुआ है, उस डर और दर्द ने मुझे भावुक कर दिया। इसमें वह एहसास भी शामिल है जब उम्मीद की किरण बुझने के बाद फिर जिंदा होती है। मैंने कभी ऐसा project नहीं संभाला जिस पर इतने लोग निर्भर हों
    मेरे हिसाब से वे सभी heroes हैं

    • एक बड़े brokerage firm में test script गलती से production तक पहुंच गई और लाखों dollars के fake FX test trades बना दिए
      Postmortem call में पहली बात यह थी: “हम उस व्यक्ति को blame नहीं करेंगे जिसने ये trades बनाए। यह एक honest mistake थी। इसके बजाय बात करते हैं कि developer बिना authentication के production trading API को hit कैसे कर पाया”
    • ऐसी organizational failures में व्यक्ति को दोष नहीं देना चाहिए। Process की दो समस्याएं दिखती हैं: अगर plug को उल्टा connect किया जा सकता था, तो या तो शुरुआत से ही उसे असंभव बनाना चाहिए था, या risk identify करके दो या ज्यादा लोगों से दिशा confirm करानी चाहिए थी; और इस्तेमाल हो रहे multimeter जैसे tools को कभी अलग नहीं किया जाना चाहिए
      व्यक्ति को blame करने से सिर्फ वही इंसान निकलेगा और पूरी organization कमजोर हो जाएगी। यानी आपने वह इकलौता व्यक्ति निकाल दिया जिसने महंगा सबक सीखा था। किसी व्यक्ति को जिम्मेदार ठहराने का समय केवल तब है जब नुकसान पहुंचाने का इरादा हो, और उस स्थिति में कानून शामिल हो सकता है
    • School छोड़ने के बाद अपनी पहली web development नौकरी में, पहले ही दिन मैंने production website down कर दी। दसियों हजार visitors प्रभावित हुए और सारे sales leads रुक गए, लेकिन कुछ ही minutes में site वापस आ गई, और पूरी team व बगल वाले कमरे के CEO के सामने वह कठिन पल पार किया
      कुछ साल बाद जब मैंने job छोड़ी, तब तक उस fragile और unstable site को automatic tests, backup के कई स्तरों, कई data centers में failover system, और नए developers के training व onboarding वाले system में बदल दिया था। वह AWS के शुरुआती दिनों का समय था, जब production site one-click deploy नहीं होती थी
      उसी अनुभव की वजह से मैंने proper version control, development environments, Redis, sharding और clustering, VMs, Postgres और MySQL replication, wiki, monit, DNS, load balancers, reverse proxies वगैरह सीखे। क्योंकि मैं site को दोबारा down नहीं करना चाहता था
      वह एक छोटी company थी जिसने WordPress का थोड़ा अनुभव रखने वाले high-school dropout को $15 प्रति घंटा देकर production website सौंप दी थी। लेकिन गलती के बाद भी उन्होंने मुझे निकाला नहीं, बल्कि मौके पर सीखते हुए system बेहतर बनाने की आजादी और भरोसा दिया, जिसके लिए मैं आज भी आभारी हूं
    • यह मामला अलग है। यह अपने नाम का पहला custom single rover था, और पहले से तरह-तरह की processes थीं, लेकिन हर चीज का अनुमान नहीं लगाया जा सकता। शायद बाद में उन्होंने process सुधारी होगी, लेकिन याद रखना चाहिए कि यह उनके लिए भी पहला अनुभव था
      ज्यादा नियम और बेहतर processes हमेशा अच्छा ही हों, ऐसा नहीं है। कभी-कभी bureaucracy पहले से धीमे NASA को और धीमा बना देती है। अपने प्रकार की पहली mission में कभी-कभी process के बजाय लोगों पर निर्भर होना और जोखिम उठाना पड़ता है
    • अगर rover सचमुच नष्ट हो गया होता तो क्या होता, यह सोचे बिना नहीं रहा जाता। उसे बचा लेना पूरी तरह किस्मत जैसा लगता है, और शायद वह किसी और गलत lead से भी connect हो सकता था जिसमें protection circuit न हो
      यानी कुछ हिस्सा लेखक की क्षमता से बाहर तय हुआ था, और उतनी ही संभावना थी कि, जैसा वह डर रहा था, वह हमेशा rover खराब करने वाले व्यक्ति के रूप में याद रखा जाता

  • यह मेरे अपने अनुभव से भी काफी मेल खाता है। एक बड़ी airline में मैं अक्सर सबसे मुश्किल और जोखिम भरे projects चुनकर लेता था, और उनमें से एक वेबसाइट के लिए नया payment provider जल्दी implement करना था। वह site हर दिन लाखों euro के tickets बेचती थी
    deployment के कुछ ही सेकंड बाद मैंने test environment और production environment के फर्क को मिस कर दिया, और पता चला कि production में एक critical variable खाली है। अगर मैंने docs और पढ़कर तैयारी की होती तो यह अंदाजा लगाया जा सकता था, इसलिए sales पूरी तरह रुक गईं और मेरा दिल बैठ गया। लंबे rollback process के बाद कई घंटों तक sales बंद रहीं, नाराज customers की बाढ़ आ गई और लाखों euro का नुकसान हुआ
    मैंने elevator में CEO को रोककर कहा कि यह पूरी तरह मेरी गलती है और firing समेत हर नतीजा स्वीकार करूंगा। वह हंसकर कुछ इस तरह बोले, “हम आपको क्यों निकालेंगे? हमने अभी-अभी आपको train करने पर लाखों खर्च किए हैं। आप कल से बेहतर काम करेंगे।” यह अनुभव सच्ची leadership समेत कई मायनों में मेरे लिए formative रहा, और इसके बाद मैंने कई high-risk projects सफलतापूर्वक पूरे किए

    • वाक्य बहुत ही साधारण लगते हैं, और सीधे CEO के पास जाने वाली बात या “top performer” और “company ने लाखों गंवाए” जैसी details साथ में आने से कहानी थोड़ी अविश्वसनीय लगती है; ऐसा लगता है कि इसे LLM ने लिखा है या कम-से-कम गढ़ा गया है
    • airline ticket booking pages के बारे में अक्सर लगता है कि वे आधे से ज्यादा समय कहीं न कहीं broken रहते हैं। पूरी तरह blank screen न भी हो, तो भी ticket booking न हो पाने की हद तक अक्सर खराब रहते हैं, और मेरे हिसाब से blank screen ही बेहतर है। कम-से-कम 30 मिनट बर्बाद नहीं होते
      Internet कुल मिलाकर भी अक्सर broken रहता है। Black Friday के दौरान payment करते समय Nike webshop error देता है, और helpdesk का solution होता है “app इस्तेमाल करें”
    • नुकसान शायद उतना बड़ा नहीं था जितना लगता है। कुछ घंटों तक कोई tickets नहीं खरीद सका, इसलिए theory में उस समय की revenue के लाखों गंवा दिए, लेकिन इसमें यह assumption है कि लोग बाद में फिर कोशिश नहीं करेंगे
      असल में मुझे नहीं लगता कि downtime सीधे-सीधे loss में बदल जाता है। शुरुआती Twitter अपनी popularity और architecture की वजह से अक्सर down रहता था, लेकिन लोगों ने Twitter इस्तेमाल करना बंद नहीं किया
      online service में outage हमेशा disaster या company का अंत नहीं होता। Space equipment या ऐसी high-frequency trading software की बात अलग है जिससे company bankrupt हो सकती है, और इसलिए वहां ज्यादा सख्त safeguards होने चाहिए। Theory में तो ऐसा है, लेकिन असल में कभी-कभी space और high-frequency trading industries से सीखी गई best practices से बनी ढीली-ढाली CRUD web service से भी खराब हालत होती है
    • अगर मैं airline का responsible person होता, तो चाहता कि प्रतिक्रिया air accident postmortem की भावना के ज्यादा करीब हो। यानी system-level causes खोजकर उन्हें ठीक करने का तरीका
      production deployment के लिए co-pilot की तरह साथ में check करने और rollout रोकने का अधिकार रखने वाला कोई व्यक्ति जरूरी हो सकता है, साथ में आम DevOps safeguards भी होने चाहिए
    • पुराना joke याद आता है जो “क्यों निकालें? अभी तो आपको train करने पर लाखों खर्च किए हैं!” पर खत्म होता है
      high-risk projects संभालने वाले लोग अक्सर underestimated होते हैं। कई managers ऐसे employees को पसंद करते हैं जो स्थिर रूप से कोई value नहीं देते, बजाय उन employees के जिनकी expected value positive है लेकिन variance है

  • मैं TV industry में काम करता हूं। 30 साल पहले एक छोटे local TV station में अपनी पहली नौकरी में मुझे newscast का tape operator बनने की training मिली थी। Broadcast tapes का बड़ा ढेर लगा रहता था और playback VTR चार थे। मेरा काम हर tape डालकर उसे 1-second preroll point पर set करना था
    जब किसी tape का playback खत्म होकर उसे निकालने का समय आता, तो अभी-अभी खत्म हुए VTR की बजाय currently on-air VTR का eject button दबा देना बहुत आसान था। मुझे train करने वाला व्यक्ति जब भी मुझे eject button की तरफ हाथ बढ़ाते देखता, तो दांत भींचकर सांस खींचने जैसी बड़ी warning sound निकालता, और उस आवाज की वजह से मैं रुककर दो-तीन बार check करता और फिर tape निकालता
    वह सच में irritate करता था, लेकिन सावधान रहने की conditioning के लिए असरदार था। Station policy थी कि live broadcast के दौरान पहली बार tape निकालने पर बिना pay के एक दिन की छुट्टी, दूसरी बार probation, और तीसरी बार firing। कुछ colleagues ने chronic carelessness की वजह से नौकरियां गंवाईं और newscasts बिगाड़ दिए। उस irritating trainer की वजह से मैंने check और re-check करने की आदत सीखी, और मैंने कभी broadcast के दौरान tape eject नहीं किया

    • इससे समझ आता है कि 80s की शुरुआत में TV पर popular पुराने broadcast blooper reels वैसे क्यों होते थे। Reporter कुछ बोल रहा होता था और background footage में बिल्कुल unrelated scene चल रहा होता था

  • इस बात से सहमत हूँ कि ऐसी गलती करने वाला व्यक्ति वही गलती दोबारा नहीं करेगा। इसलिए तकनीकी तौर पर गलती कर चुके और साफ़ तौर पर परेशान व्यक्ति को निकालना आम तौर पर खराब विकल्प है
    लेकिन मुझे नहीं लगता कि “असली” सबक यही है। लागत और जोखिम को देखते हुए, जिन हिस्सों को बड़े power surge से टेस्ट किया जाता है, उन्हें धुआँ निकलने की आशंका वाले हिस्सों से compatible न होने वाले dedicated test connectors मिलने चाहिए—यही सबक है
    यह कोई छोटा breadboard project नहीं, बल्कि सरकारी एजेंसी का बहुत बड़ा project है, जिसे बहुत से लोगों ने बनाया है, जहाँ formal procedures के कारण समय और पैसा बहुत लगता है और कभी-कभी मज़ाक भी उड़ता है। “28 साल के व्यक्ति को 500 मिलियन डॉलर का robot सौंप दें, जो ज़रा-सी चूक पर फट सकता है” वाला तर्क बहुत अजीब लगता है

    • यह सही है कि इसे इस तरह design किया जाना चाहिए कि गलत तरीके से plug in किया ही न जा सके। मुझे लगता है असल में ज़्यादातर चीज़ें ऐसी ही design की गई होंगी, लेकिन design phase में जिन गलत configurations पर विचार नहीं हुआ, वे फिर भी हो सकती हैं
      खासकर testing के दौरान “normal configuration” से अलग custom cables, connectors और circuits से काम लेना अक्सर पड़ता है। मेरे हिसाब से सबक यह है कि महत्वपूर्ण कामों में जहाँ तक संभव हो 4-eyes principle अपनाया जाए। एक व्यक्ति काम करे और दूसरा व्यक्ति हर step verify करके आगे बढ़ने दे—यह लेख जैसी “बेतुकी गलतियों” को पकड़ने में बहुत असरदार होता है
      हालांकि schedule pressure वगैरह के कारण हमेशा दो लोग एक ही test नहीं देख सकते, इसलिए वास्तविक दुनिया में ऐसी गलतियाँ हो जाती हैं। पूरे system को robust बनाना होगा
    • मैंने भी शुरुआत में यही सोचा था। लेकिन अगर यह one-off equipment हो, जो सिर्फ एक बार के test cycle से गुजरता है, तो ऐसा निर्णय कठिन हो जाता है
      computing में भी production database या router configuration पर upgrade/migration के हिस्से के रूप में सिर्फ एक बार किए जाने वाले ऐसे काम बहुत होते हैं। कभी-कभी safeguards बनाने की लागत शुरुआत से ही सावधानी बरतने से ज़्यादा होती है। हम हमेशा पूरी तरह सावधान नहीं रह पाते, लेकिन safeguards भी हमेशा perfect नहीं बना पाते, और defective safeguards पर भरोसा करके वैसी ही गलतियाँ कर बैठते हैं
      कहानी वाली स्थिति में, hardware वाली pair programming की तरह, लेखक के हर काम के सही होने की verification ही जिसका काम हो, ऐसा partner होना चाहिए था। Mary की तरह role बाँटकर मदद करने वाला assistant नहीं, बल्कि साथ-साथ follow करके check करना ही जिसका एकमात्र काम हो, ऐसा व्यक्ति होना चाहिए था
    • ध्यान से पढ़ें तो power H-bridge के power output leads में गई थी, और H-bridge मजबूत electronic circuit है, इसलिए आखिरकार कुछ भी damage नहीं हुआ। shutdown का इससे कोई संबंध नहीं था
      अगर यह motor controller की data lines में गई होती, तो कुछ जल जाने की संभावना बहुत ज़्यादा थी। connector type अलग थे या नहीं, इसे नकारा नहीं जा सकता, लेकिन जिन दो connectors को गलत तरीके से जोड़ा गया था, उन्हें सचमुच same type के रूप में assign किया गया था
    • जब मानवता ने पहली बार चंद्रमा पर landing की थी, तब Mission Control engineers की average age 28 साल थी
    • इस industry में काम करने की वजह से मैं बता सकता हूँ कि ऐसी चीज़ कैसे हो जाती है। महंगे projects में भी हर जगह unique connector अनिवार्य नहीं किया जा सकता, क्योंकि requirements आपस में compete करती हैं
      खासकर connectors के लिए पहले से certified products, specific derating, pin spacing, grounded backshell जैसी कई conservative requirements होती हैं। अंत में इस्तेमाल और stock में रखी जाने वाली connector series कुछ ही रह जाती हैं, और किसी भी cost पर उन्हें पूरी तरह non-overlapping बनाना realistic नहीं है। आम तौर पर या तो same signals को standardize किया जाता है, या overlap न हो इसलिए उन्हें unique बनाने की कोशिश की जाती है
      उदाहरण के लिए, spacecraft के external connectors में handling के दौरान short circuit रोकने के लिए socket-type connector चाहिए, और intermediate harness कभी हटाया नहीं जाता, इसलिए pin-type connector symmetrically लग सकता है। फिर जब testing के लिए breakout box चाहिए होता है, तो box को उल्टा plug करने का मौका बन जाता है
      या breakout box के एक तरफ 100-pin connector हो सकता है और दूसरी तरफ उसे 25 test instruments से जोड़ना पड़ सकता है। चुनने के लिए 25 अलग connectors भी नहीं हैं, और सभी test instruments पर custom requirements थोपना भी संभव नहीं है
      spacecraft धीरे-धीरे local microcontrollers और local diagnostics की ओर जा रहे हैं, इसलिए सभी analog signals के लिए ऐसे test equipment घट रहे हैं। आजकल motor भी शायद brushless होता, और ऐसे breakout box के बजाय testing और flight के दौरान motor driver की telemetry पर भरोसा किया जाता
      aerospace connectors भी दूसरी industries की तरह order के समय अधिक configurable होते जा रहे हैं, और keys जोड़कर “same” connectors के 10 units होने पर भी उन्हें सिर्फ अपनी जगह plug होने लायक बनाया जा सकता है। फिर भी सभी test equipment को इसी तरह configure करने की मांग करना अब भी unrealistic है

  • रिकॉर्ड के लिए, अपनी कहानी भी जोड़ता हूँ। University से graduation के बाद मेरी पहली job एक content marketing startup में थी, जो PHP और PerconaDB(MySQL) इस्तेमाल करता था। PHP का experience ज़्यादा नहीं था, लेकिन junior होने वाला बेवजह आत्मविश्वास था। graduation के बाद 6 महीने तक नौकरी नहीं मिली थी, इसलिए अच्छा impression बनाना भी बहुत चाहता था
    मुझे feature flag update करने का काम मिला था ताकि नया feature सभी customers के लिए on हो, सिवाय उन customers के जिन्होंने स्पष्ट रूप से off करने को कहा था। flags database में integer 4 और 5 के रूप में string array के अंदर stored थे
    ज़रूरी काम करने के लिए मैंने PHP function array_reverse इस्तेमाल किया, लेकिन documentation नहीं पढ़ी, इसलिए मुझे पता नहीं था कि दूसरा argument न हो तो यह keys नहीं, बल्कि सिर्फ values reverse करता है। नतीजतन database ठीक उसके उलट खराब हो गया जिसकी जरूरत थी, और अजीब बात यह कि QA भी pass हो गया
    कुछ घंटों बाद इसका पता चला, और उस समय मेरा one-way commute लगभग 3 घंटे का था, इसलिए तब तक management तक मामला पहुँच चुका था। reverse script से इसे आसानी से ठीक किया जा सकता था, लेकिन QA और DB backup failure जैसी कई समस्याएँ सामने आईं
    अगले दिन lead architect आए और कहा कि यह PHP के साथ काम करने की rite of passage जैसी गलती है और उन्होंने खुद भी career की शुरुआत में यह किया था—यह बात मुझे आज भी याद है और मैं उसका आभारी हूँ। आखिरकार मुझे निकाल दिया गया, और इससे engineer के रूप में बढ़ने में मदद मिली, लेकिन उस पल और उसके बाद के कुछ हफ्तों में हौसला ज़रूर टूट गया था

    • उस array_reverse वाली गलती के कारण निकाल दिया?

  • कहानी बहुत खींच लेने वाली तरह से लिखी गई थी, लेकिन थोड़ी उलझाने वाली भी थी
    ऐसा लगता है कि इस टीम ने एक गलती नहीं, बल्कि कई गलतियां कीं। यह साफ नहीं है कि इसका नतीजा spacecraft को असल नुकसान पहुंचा सकता था, या फिर spacecraft क्यों चालू नहीं हो रहा था, इस पर सिर्फ समय और भ्रम ही बर्बाद हुआ
    पहली गलती यह थी कि उन्हें पता नहीं था कि multimeter सिर्फ माप नहीं रहा था, बल्कि circuit को complete कर रहा था। यह वाकई खराब design जैसा लगता है, और अगर ऐसा करना ही जरूरी था तो उस multimeter को कभी छूना नहीं चाहिए था। यह किसी एक व्यक्ति की गलती नहीं, बल्कि कम-से-कम दो लोगों, उन्हें manage करने वाले व्यक्ति, और ऐसी system को अनुमति देने वाले जिम्मेदार व्यक्ति तक जुड़ा मामला है
    दूसरी गलती breakout box की तरफ थी। उन्होंने माना कि power गलती से spacecraft की तरफ भेज दी गई, और जब spacecraft चालू नहीं हुआ तो निष्कर्ष निकाला कि power surge ने spacecraft को नुकसान पहुंचाया है; लेकिन उन्हें पक्का नहीं था कि वह असल में कहां बहा और क्या damage हुआ, और आखिर में वे गलत निकले
    spacecraft के चालू न होने की वजह यह थी कि हादसे से पहले multimeter को circuit से निकाल दिया गया था। RAT-Revolve motor H-bridge channel पर कई हफ्तों के analysis और thin-film demetallization की संभावना पर चर्चा वाली पंक्ति अब भी उलझाती है—क्या उसका मतलब था कि उन्होंने आंका था कि गलत power surge उस channel से होकर गया होगा और उसे damage कर सकता था?

    • यह बात भी छूट गई कि telemetry के प्रभारी Leo ने storyteller को उसकी गलती बताने तक telemetry loss की सूचना नहीं दी। क्या telemetry वापस आने तक सभी tests cancel नहीं कर देने चाहिए थे?
    • spacecraft खुद तो ठीक से चालू हो गया था। multimeter telemetry circuit को जोड़ रहा था, इसलिए उस circuit को restore करने तक उन्हें जानकारी नहीं मिली
      power सच में उस circuit में गई थी, और स्थिति यह थी कि वे तय करने की कोशिश कर रहे थे कि वह damage हुआ है या नहीं। लेकिन motor driver को motor से वापस आने वाली power झेलने में सक्षम होना चाहिए, इसलिए शायद उन्होंने माना कि वह damage नहीं हुआ होगा

  • एक mechanical और aerospace engineer के तौर पर, काश मेरी सबसे डरावनी कहानियां बस इतनी ही होतीं कि बिना crew वाला 500 million dollar rover का main computer लगभग brick होने वाला था
    मैं उन चीजों के लिए safety-critical approvals देने वाला senior था जिनमें लोगों की जानें सवार होती हैं। crash accident के बाद टूटे हुए parts की तस्वीरें देखते हुए “अगर मेरी calculation गलत थी तो?”, “अगर मेरा joint slip कर गया था तो?”, “अगर accelerated fatigue life prediction या stress corrosion cracking से जुड़ी खराब test procedure के कारण हुआ तो?”, “अगर production में डालने की जल्दी में shipment से पहले पकड़ नहीं पाए तो?” जैसी भावना सहनी पड़ती थी
    मिलते-जुलते fields की failure stories पढ़ना दिलचस्प है, लेकिन HN पर openly share की जाने वाली कहानियां मुझे यह सोचने पर मजबूर करती हैं कि workplace-induced PTSD कोई competition नहीं है। कुछ लोगों के लिए बस therapy का खर्च ज्यादा होता है

    • पसंदीदा लेखक के उपन्यास की एक पंक्ति याद आती है। welding instructor forged safety inspections से जुड़े एक काफी literally postmortem किस्से के बाद यह कहता है

      He gathered his breath. “This is the most important thing I will ever say to you. The human mind is the ultimate testing device. You can take all the notes you want on the technical data, anything you forget you can look up again, but this must be engraved on your hearts in letters of fire.

      “There is nothing, nothing, nothing more important to me in the men and women I train than their absolute personal integrity. Whether you function as welders or inspectors, the laws of physics are implacable lie-detectors. You may fool men. You will never fool the metal. That’s all.”

      He let his breath out, and regained his good humor, looking around. The quaddie students were taking it with proper seriousness, good, no class cut-ups making sick jokes in the back row. In fact, they were looking rather shocked, staring at him with terrified awe.
      -- Lois McMaster Bujold, Falling Free

    • आखिरी paragraph के बारे में मैंने भी यही सोचा। original में जहां लिखा था “मैं तुरंत उसी पल में लौट जाता हूं — कमरा, रोशनी, जिस chair पर बैठा था, table, पेट बैठ जाने का एहसास…” वह trauma response जैसा लगा
      अच्छा है कि वे उस energy को बेहतर बनने की दिशा में इस्तेमाल कर पाए, लेकिन हर कोई trauma पर एक ही तरह से react नहीं करता, और ऐसी reactions की तुलना करना भी आसान नहीं। उदाहरण के लिए, मुझे लगता है कि hiring question के तौर पर इसमें बहुत सारे social variables हैं
    • “crash accident के बाद टूटे parts की तस्वीरें देखते हुए ‘अगर मेरी calculation गलत थी तो?’ जैसा महसूस करना पड़ा” वाले हिस्से पर मुझे जिज्ञासा है कि क्या यह अंततः किसी न किसी व्यक्ति पर अनिवार्य रूप से लौटता ही है
      भले ही वह ऐसी detail रही हो जिसे procedures पकड़ नहीं सकते थे, अच्छी procedures बनाने का जिम्मेदार कोई न कोई होता है। कई factors हो सकते हैं, लेकिन आखिरकार ऐसा लगता है कि कोई व्यक्ति काफी सीधे तौर पर जिम्मेदार बन जाता है
      software engineering या समाज में broadly उन contexts के बारे में सोचें जहां individual mistake collective के नाम पर चली जाती है, तो यह दिलचस्प है
    • सच में चाहता हूं कि aerospace industry में आपके जैसे लोग ज्यादा हों, और Boeing 737 MAX के MCAS को conceive, implement और approve करने वाले लोग कम हों
    • हैरानी है कि engineers के लिए group counselling नहीं है, और अगर है भी तो उसे ढूंढना मुश्किल है। मैं high-risk field में काम नहीं करता, लेकिन aviation या railway side के लोगों की बातें अक्सर सुनने की स्थिति में रहा हूं
      अगर आपमें empathy है और आप “rocket ऊपर जाने के बाद कहां गिरता है, यह मेरे department का काम नहीं” वाला attitude नहीं अपनाते, तो यह काफी भारी पड़ सकता है। safety-critical systems बनाने वाले या उनके fallout से निपटने वाले लोगों के लिए peer support groups हों तो अच्छा होगा। company हमेशा अच्छी counselling नहीं देती
      engineering associations या chartered engineer organizations membership fees से ऐसी services दे सकते हैं, लेकिन लोग license या professional accreditation खोने के डर से उनका इस्तेमाल करने से हिचक सकते हैं। पहले शायद लोग colleagues के साथ pub में पीकर मन हल्का करते होंगे, लेकिन alcohol dependence या अगले दिन काम पर असर अच्छा नहीं है, और pub culture भी पहले जैसा नहीं रहा

  • NOAA-N Prime सैटेलाइट के साथ हुई घटना याद आती है, जब test stand पर उसे固定 करने के लिए पर्याप्त bolts नहीं थे और वह गिर गया था
    मूल कारण, अगर मैं गलत नहीं हूं तो सुधार दें, यह था कि सैटेलाइट को सुरक्षित करने के लिए इस्तेमाल होने वाले X-ray inspection bolts बहुत महंगे थे, इसलिए उन्हें किसी दूसरे project को “उधार” दे दिया गया था और वापस नहीं रखा गया था। जब सैटेलाइट को horizontal स्थिति में पलटा जा रहा था, वह जमीन पर गिर गया, और repair cost 135 million dollars थी
    https://en.m.wikipedia.org/wiki/NOAA-19

    • अगर पलटने की procedure के errata या appendix में “bolts check करें” जोड़ दिया जाए, तो क्या थोड़ी-सी व्यंग्यात्मक टिप्पणी मंजूर होगी?

  • यह दिलचस्प है कि शुरुआत से ही chronological sorting बेहतर की होती तो चिंता से बचा जा सकता था। अगर test readings के timestamps की तुलना telemetry system के last timestamp से की जाती, तो पता चल जाता कि test run से पहले ही telemetry fail हो चुकी थी
    “लगता है अभी-अभी spacecraft telemetry पूरी तरह बंद हो गई है” जैसी अस्पष्ट wording के बजाय सटीक timestamps का इस्तेमाल न करना भी वजह का हिस्सा था। इससे सीख मिलती है कि incident के दौरान events वास्तव में कैसे जुड़े थे, इसे ठीक से verify करना चाहिए। दो अलग-अलग signals देखकर किसी खास direction में causality मान लेना आसान है, लेकिन असलियत में उल्टा भी हो सकता है