सिस्टम डिज़ाइन इंटरव्यू: एक सुरक्षित OTA फ्लीट अपडेट प्लेटफ़ॉर्म डिज़ाइन करें

प्रांप्ट और दायरा

यह सिस्टम-डिज़ाइन प्रश्न प्लेटफ़ॉर्म, क्लाउड-इन्फ्रास्ट्रक्चर और एम्बेडेड-सिस्टम भूमिकाओं के लिए लक्षित है। डिवाइस हफ़्तों तक ऑफ़लाइन रह सकते हैं, उनका स्टोरेज सीमित हो सकता है, या वे सेल्युलर बैंडविड्थ के लिए भुगतान कर सकते हैं; एक खराब इमेज पूरे फ्लीट को डिस्कनेक्ट कर सकती है। प्लेटफ़ॉर्म को यह सुनिश्चित करना चाहिए कि केवल संगत डिवाइस ही हस्ताक्षरित (signed) पैकेज इंस्टॉल करें, रोलआउट को रोका जा सके, और कोई डिवाइस रिकवर हो सके या अपने पिछले संस्करण पर वापस लौट सके।

मान लें कि 10 लाख डिवाइस हैं, प्रतिदिन अधिकतम 100,000 डाउनलोड हैं, और 20 MiB का अपडेट है। डिवाइसों को मॉडल, हार्डवेयर रिवीजन, क्षेत्र और वर्तमान संस्करण के आधार पर समूहीकृत (group) करें। उत्तर के लिए AWS की आवश्यकता नहीं है; क्लाउड उत्पाद केवल कंट्रोल-प्लेन और डेटा-प्लेन सीमाओं को ठोस बनाने में मदद करते हैं।

साक्षात्कारकर्ता क्या मूल्यांकन करता है

• क्या आप पैकेज अखंडता (integrity), प्रकाशक प्रमाणीकरण (publisher authentication), डिवाइस प्राधिकरण (device authorization) और अनुकूलता जांच (compatibility checks) को अलग करते हैं।
• क्या आप केवल एक डाउनलोड बकेट बनाने के बजाय एक कंट्रोल-प्लेन और डिवाइस डेटा-प्लेन स्टेट मशीन डिज़ाइन करते हैं।
• क्या आप बैंडविड्थ, कन्करेंसी और अबॉर्ट थ्रेशोल्ड की गणना करते हैं और पॉज़, पुनः प्रयास (retry), रोलबैक और मानव एस्केलेशन की व्याख्या करते हैं।

एक मजबूत उत्तर "सफल रोलआउट" को CDN डाउनलोड पूरा होने के रूप में नहीं, बल्कि डिवाइस सत्यापन, इंस्टॉलेशन, रीबूट और स्वास्थ्य पुष्टि के रूप में परिभाषित करता है।

उत्तर देने से पहले स्पष्टीकरण

1. क्या डिवाइस दो स्लॉट से बूट कर सकते हैं? A/B स्लॉट निष्क्रिय (inactive) स्लॉट पर लिखने और असफल बूट के बाद वापस लौटने की अनुमति देते हैं; सिंगल-स्लॉट डिवाइसों को अधिक रूढ़िवादी बूटलोडर और फ़ील्ड-रिकवरी पथ की आवश्यकता होती है।
2. क्या कोई सुरक्षा या क्षेत्रीय बाधाएं हैं? टारगेटिंग में केवल डिवाइस लेबल ही नहीं, बल्कि मॉडल, हार्डवेयर, क्षेत्र, प्रमाणपत्र स्थिति और वर्तमान संस्करण शामिल होना चाहिए।
3. अपडेट की समय सीमा (deadline) क्या है? समय सीमा बैच के आकार, रखरखाव विंडो (maintenance windows), ऑफ़लाइन पुनः प्रयासों और क्या जबरन इंस्टॉलेशन स्वीकार्य है, इसे बदल देती है।
4. क्या विफलता डिवाइस-स्तरीय है या कोहोर्ट-स्तरीय? एक डिवाइस पुनः प्रयास कर सकता है; किसी एक मॉडल के लिए उच्च विफलता दर होने पर वैश्विक रूप से विस्तार करने के बजाय उस कोहोर्ट को रोक देना चाहिए।

30-सेकंड का उत्तर

"मैं प्लेटफ़ॉर्म को एक साइन्ड-पैकेज रिपॉजिटरी, रिलीज़ कंट्रोल प्लेन, डिवाइस एजेंट और टेलीमेट्री में विभाजित करूँगा। रिलीज़ पाइपलाइन मॉडल, हार्डवेयर, संस्करण, निर्भरता और समाप्ति (expiry) के साथ एक मेनिफेस्ट बनाती है, इसे एक नियंत्रित वातावरण में साइन करती है, और इंस्टॉलेशन से पहले डिवाइस से सिग्नेचर, डाइजेस्ट और अनुकूलता को सत्यापित करवाती है। कंट्रोल प्लेन कैनरी, फिक्स्ड-रेट या एक्सपोनेंशियल रोलआउट के साथ कोहोर्ट्स को लक्षित करता है और एक आइडेम्पोटेंट जॉब आईडी के साथ प्रति-डिवाइस स्थिति संग्रहीत करता है। डिवाइस निष्क्रिय स्लॉट में रिज़्यूमेबल रूप से चंक्स डाउनलोड करता है, रीबूट करता है, और स्वास्थ्य जांच पास होने के बाद ही कमिट करता है। विफलताओं, डाउनलोड त्रुटियों, बूट रोलबैक, या सुरक्षा अलर्ट में वृद्धि होने पर कोहोर्ट रुक जाता है और पुराना संस्करण सुरक्षित रहता है। ऑफ़लाइन डिवाइस मेंटेनेंस विंडो में पुनः प्रयास करते हैं, और प्रत्येक क्रिया ऑडिट योग्य और दोबारा चलाने योग्य (replayable) होती है।"

चरण-दर-चरण गहन उत्तर

चरण 1: मुख्य बाधा (bottleneck) का अनुमान लगाएं।

यदि 10 लाख डिवाइस 20 MiB डाउनलोड करते हैं, तो कुल लगभग 20 TiB होता है। प्रतिदिन 100,000 डिवाइस पूरे करना लगभग 2 TiB/दिन, या औसतन 23.7 MiB/s है; पीक समय में कन्करेंसी और पुनः प्रयासों के लिए अतिरिक्त क्षमता (headroom) की आवश्यकता होती है। ऑब्जेक्ट स्टोरेज और CDN पैकेज वितरित करते हैं। कंट्रोल प्लेन डिवाइसों द्वारा एक बड़े डेटाबेस को पोल करने के बजाय मेनिफेस्ट और अल्पकालिक डाउनलोड प्राधिकरण भेजता है।

चरण 2: एक प्रामाणिक पैकेज और मेनिफेस्ट बनाएं।

बिल्ड पाइपलाइन अपरिवर्तनीय बाइट्स, एक डाइजेस्ट और एक मेनिफेस्ट तैयार करती है। साइनिंग कुंजियाँ एक नियंत्रित साइनिंग सेवा में रहती हैं, और रिलीज़ में हस्ताक्षरकर्ता का संस्करण और अनुमोदन दर्ज होता है। डिवाइस में एक ट्रस्ट रूट होता है और यह सिग्नेचर, पैकेज डाइजेस्ट, लक्षित मॉडल, न्यूनतम बूटलोडर, एंटी-रोलबैक काउंटर और समाप्ति को सत्यापित करता है। डाउनलोड URL केवल एक ट्रांसपोर्ट तंत्र है, ट्रस्ट सीमा नहीं।

चरण 3: कंट्रोल और डेटा प्लेन को अलग करें।

कंट्रोल प्लेन रिलीज़ बनाता है, लक्ष्यों को हल करता है, कोहोर्ट्स और डिवाइस जॉब्स बनाता है, और पॉज़ कमांड जारी करता है। डिवाइस डेटा प्लेन CDN से चंक्स डाउनलोड करता है और जॉब एंडपॉइंट को स्थिति रिपोर्ट करता है। प्रत्येक डिवाइस (device_id, job_id) को निष्पक्षता (idempotently) से अपडेट करता है, इसलिए डुप्लिकेट रिपोर्ट स्थिति को गलत तरीके से स्थानांतरित नहीं कर सकती हैं। स्थितियों में QUEUED, DOWNLOADING, VERIFIED, INSTALLING, SUCCEEDED, FAILED, ROLLED_BACK, और REJECTED शामिल हैं।

चरण 4: सुरक्षित इंस्टॉलेशन और रोलबैक डिज़ाइन करें।

पैकेज को निष्क्रिय स्लॉट में लिखें, प्रत्येक चंक और अंतिम मेनिफेस्ट को सत्यापित करें, फिर बूट स्लॉट बदलें। बूटलोडर प्रयासों और बूट-पुष्टि समय सीमा को रिकॉर्ड करता है। एप्लिकेशन स्वास्थ्य जांच, महत्वपूर्ण सेंसर और संचार के ठीक होने के बाद ही पुष्टि करता है। बार-बार विफलता होने पर पुराना स्लॉट चुना जाता है और कारण की रिपोर्ट की जाती है। सिंगल-स्लॉट डिवाइस को रिकवरी इमेज या फ़ील्ड सेवा की आवश्यकता होती है; इसे स्वचालित रूप से A/B परमाण्विकता (atomicity) नहीं मिलती।

चरण 5: रोलआउट को नियंत्रित करें।

आंतरिक डिवाइसों और एक छोटे कैनरी के साथ शुरुआत करें, फिर मॉडल और क्षेत्र के अनुसार विस्तार करें। फिक्स्ड या एक्सपोनेंशियल दरें दोनों मान्य हैं, लेकिन प्रत्येक कोहोर्ट को अधिकतम कन्करेंसी, एक मेंटेनेंस विंडो और अबॉर्ट मानदंडों की आवश्यकता होती है। प्रति कोहोर्ट थ्रेशोल्ड को मापें और डाउनलोड विफलता, सिग्नेचर अस्वीकृति, इंस्टॉलेशन विफलता, बूट रोलबैक और स्वास्थ्य-जांच टाइमआउट को अलग-अलग वर्गीकृत करें।

चरण 6: ऑफ़लाइन डिवाइस, पुनः प्रयास और ऑडिट को संभालें।

जब कोई डिवाइस फिर से कनेक्ट होता है, तो वह एक गैर-समाप्त जॉब का दावा करता है। चंक्ड डाउनलोड रिज़्यूम और एक्सपोनेंशियल बैकऑफ़ का उपयोग करते हैं; पुनः प्रयास उसी जॉब और पैकेज संस्करण का पुन: उपयोग करते हैं। अपनी समय सीमा पार कर चुका डिवाइस सफल चिह्नित होने के बजाय एक सुधार (remediation) कतार में प्रवेश करता है। कंट्रोल प्लेन रीप्ले और अनुपालन के लिए अनुमोदन, मेनिफेस्ट, लक्ष्य स्नैपशॉट, स्थिति संक्रमण, कर्ता (actor), और पॉज़ कारण को बनाए रखता है।

उच्च-गुणवत्ता वाला नमूना उत्तर

"मैं कंट्रोल प्लेन, पैकेज रिपॉजिटरी/CDN, डिवाइस एजेंट और टेलीमेट्री को अलग करूँगा। रिलीज़ पाइपलाइन अपरिवर्तनीय बाइट्स और लक्षित मॉडल, हार्डवेयर रिवीजन, न्यूनतम बूटलोडर, संस्करण काउंटर और डाइजेस्ट से युक्त एक मेनिफेस्ट बनाती है; एक नियंत्रित साइनिंग सेवा इस पर हस्ताक्षर करती है, और डिवाइस इसे एक एम्बेडेड ट्रस्ट रूट के साथ सत्यापित करता है। डाउनलोड URL केवल बाइट्स का परिवहन करता है।

10 लाख डिवाइसों के साथ, 20 MiB का पैकेज लगभग 20 TiB होता है, इसलिए CDN वितरण को संभालता है जबकि कंट्रोल प्लेन रिलीज़ और प्रति-डिवाइस जॉब स्थिति को संग्रहीत करता है। डिवाइस चंक्स को निष्क्रिय स्लॉट में डाउनलोड करते हैं, डाइजेस्ट को सत्यापित करते हैं, रीबूट करते हैं, और स्वास्थ्य पुष्टि के बाद ही कमिट करते हैं; विफलताएं पुराने स्लॉट का चयन करती हैं और कारण रिपोर्ट करती हैं। मैं एक कैनरी के साथ शुरुआत करता हूँ, फिर मॉडल और क्षेत्र के अनुसार विस्तार करता हूँ। प्रत्येक कोहोर्ट में कन्करेंसी, विफलता-दर और रोलबैक-दर थ्रेशोल्ड होते हैं; किसी एक के पार होने पर खराब इमेज को फैलाने के बजाय रोलआउट रुक जाता है। ऑफ़लाइन डिवाइस मेंटेनेंस विंडो में उसी जॉब का दावा करते हैं, पुनः प्रयास फिर से शुरू होते हैं, और अनुमोदन, स्थितियाँ और संस्करण ऑडिट योग्य बने रहते हैं।"

सामान्य गलतियाँ

• केवल HTTPS की जाँच करना → ट्रांसपोर्ट सुरक्षा पैकेज या उसके बाइट्स को प्रमाणित नहीं करती है → डिवाइस पर मेनिफेस्ट सिग्नेचर और पैकेज डाइजेस्ट को सत्यापित करें।
• डाउनलोड के बाद सफलता चिह्नित करना → इंस्टॉलेशन, बूट और स्वास्थ्य जांच अभी भी विफल हो सकती हैं → बूट पुष्टि को अंतिम सफलता की शर्त बनाएं।
• पूरे फ्लीट पर एक साथ लॉन्च करना → एक अनुकूलता दोष सभी को प्रभावित कर सकता है → कैनरी, कोहोर्ट्स, दरों और अबॉर्ट मानदंडों का उपयोग करें।
• प्रत्येक पुनः प्रयास पर एक नया जॉब बनाना → स्थिति और ऑडिट इतिहास खंडित हो जाता है → एक idempotent (device_id, job_id) स्थिति का पुनः उपयोग करें।
• मनमाने डाउनग्रेड की अनुमति देना → एक हमलावर कमजोर (vulnerable) इमेज को रीप्ले कर सकता है → साइन्ड संस्करण काउंटर, एंटी-रोलबैक नीति और एक नियंत्रित अपवाद सूची का उपयोग करें।

फॉलो-अप और प्रतिक्रियाएं

फॉलो-अप 1: 2% रोलआउट पर, एक मॉडल 4% बूट-रोलबैक दर तक पहुँच जाता है। आप क्या करेंगे?

सफल डिवाइसों के अवलोकन को जारी रखते हुए उस मॉडल और पैकेज संस्करण को तुरंत रोक दें। अनुकूलता सीमा खोजने के लिए हार्डवेयर रिवीजन, बूटलोडर, क्षेत्र और बिल्ड के अनुसार विभाजित (slice) करें; यदि आवश्यक हो, तो एक सत्यापित पुराना संस्करण या पुनर्प्राप्ति कमांड तैनात करें। सिर्फ इसलिए जारी न रखें क्योंकि फ्लीट-व्यापी औसत कम है।

फॉलो-अप 2: 80% डाउनलोड पर किसी डिवाइस की पावर चली जाती है। अगला प्रयास शुरुआत से शुरू होने से कैसे बचता है?

निष्क्रिय स्लॉट में चंक्स लिखें और पैकेज संस्करण, चंक डाइजेस्ट, पुष्टि किए गए ऑफ़सेट और समग्र मेनिफेस्ट डाइजेस्ट को सुरक्षित (persist) रखें। रीबूट के बाद, स्थानीय चंक्स और मेनिफेस्ट को सत्यापित करें, फिर अंतिम निरंतर विश्वसनीय चंक से एक रेंज का अनुरोध करें। यदि पैकेज या सिग्नेचर बदल जाता है, तो दो संस्करणों को संयोजित करने के बजाय अस्थायी स्लॉट को त्याग दें।

फॉलो-अप 3: आप किसी हमलावर को वैध पुराने पैकेज को दोबारा रीप्ले करने से कैसे रोकते हैं?

मेनिफेस्ट में एक मोनोटोनिक संस्करण काउंटर या सुरक्षा संस्करण डालें और डिवाइस पर उच्चतम स्वीकृत मान को बनाए रखें; बूटलोडर कम मानों को अस्वीकार कर देता है। आपातकालीन रोलबैक के लिए एक नियंत्रित हस्ताक्षर, स्पष्ट कोहोर्ट, और ऑडिट में दर्ज समय-सीमित प्राधिकरण की आवश्यकता होती है, ताकि एक सामान्य डाउनलोड एंडपॉइंट एंटी-रोलबैक को बायपास न कर सके।