Long Tail पढ़ना
Latency एक संख्या पर नहीं, एक वक्र पर रहती है
औसत latency छुपाता है कि उपयोगकर्ता क्या अनुभव करते हैं। वास्तविक सेवाएँ एक वितरण उत्पन्न करती हैं: एक वक्र जो दिखाता है कि कितने अनुरोध कितनी देर लेते हैं।
उस वक्र के तीन बिंदु ज्यादातर संचालन अर्थ रखते हैं:
- p50 (माध्यिका): वितरण के मध्य। आधे अनुरोध तेजी से पूरे होते हैं, आधे धीमे। विशिष्ट अनुभव का वर्णन करता है।
- p99: 99वां प्रतिशतक। केवल 1% अनुरोध इससे अधिक समय लेते हैं। विशिष्ट उपयोगकर्ताओं के लिए सबसे खराब अनुभव का वर्णन करता है।
- p99.9: केवल 0.1% अनुरोध इससे अधिक समय लेते हैं। शक्तिशाली उपयोगकर्ताओं के लिए सबसे खराब अनुभव का वर्णन करता है जो सेवा को बार-बार हिट करते हैं।
ज्यामितीय अंतर्दृष्टि: latency वितरण लगभग हमेशा एक लंबी दाईं पूंछ रखते हैं। वक्र माध्यिका के आसपास तेजी से बढ़ता है, फिर दाईं ओर धीरे-धीरे गिरता है, अक्सर औसत से दूर एक छोटे उभार के साथ। वह उभार सबसे धीमे उपयोगकर्ताओं का प्रतिनिधित्व करता है: जो गुस्से में टिकट लिखते हैं।
औसत क्यों गुमराह करता है: एक सेवा माध्यिका 50 ms के साथ और p99 5,000 ms का मतलब विशिष्ट और पूंछ अनुभव के बीच 100x अंतर है। अंकगणित माध्य 100 ms पर उतर सकता है, पूरी तरह से आपदा छुपा सकता है। अंकगणित माध्य 2D आकार का एक एकल बिंदु प्रक्षेपण है: लगभग सभी आकार की जानकारी गायब हो जाती है।
प्रतिशतक गुणन समस्या: एक अनुरोध जो 10 backend सेवाओं को छूता है, प्रत्येक p99 100 ms के साथ, लगभग 600 ms का p99 रखता है (100 ms नहीं)। धीमी पूंछें गुणा करती हैं। यह है कि SRE पुस्तक क्यों चेतावनी देती है: 'N में सबसे धीमे को सावधानी से देखें'। जैसे-जैसे N बढ़ता है, आपकी पूंछ latency तेजी से खराब होती है।
Tail Latency गणित
सेवा A में एक अनुरोध प्रवाह है जो 5 backend सेवाओं में समानांतर में फैलता है और सभी प्रतिक्रियाओं की प्रतीक्षा करता है। प्रत्येक backend में p99 latency 100 ms है।
बजट क्षरण ढलान के रूप में
समय के ऊपर बजट को प्लॉट करना
2D अक्षों (x पर समय, y पर शेष बजट) पर प्लॉट किया गया error budget एक नज़र में सेवा स्वास्थ्य प्रकट करता है। क्षरण वक्र का आकार वही जानकारी दस डैशबोर्ड व्यक्त करेंगे।
तीन संदर्भ आकार:
- स्वस्थ रैखिक क्षरण: बजट बीतते समय के अनुपात में सीधी रेखा में गिरता है। महीने के 28 दिन में से 14 दिन तक, आधा बजट शेष रहना चाहिए। यह SLO लक्ष्य दृश्यमान है।
- तेजी जलन: एक तीव्र नीचे की ओर ढलान। विश्वसनीयता समस्या को इंगित करता है। यदि ढलान काफी तीव्र है, तो बजट खिड़की रीसेट होने से पहले समाप्त हो जाता है, error budget नीति को ट्रिगर करता है।
- हील किया गया वक्र: एक सपाट या बढ़ता खंड। सेवा अपने SLO से बेहतर प्रदर्शन कर रही है। शेष बजट समय के साथ बढ़ता है, जोखिम भरा लॉन्च के लिए जगह खोलता है।
Burn rate क्षरण लाइन की ढलान है, सामान्यीकृत: 1 की burn rate का अर्थ है समय के साथ बिल्कुल उसी गति से बजट जलना (SLO के साथ पूरी तरह संरेखित)। 10 की burn rate का अर्थ 10 गुना तेजी से जलना: पूरा मासिक बजट इस दर पर 2.8 दिन में समाप्त हो जाएगा।
मल्टी-विंडो मल्टी-बर्न-रेट अलर्टिंग: Google की SRE कार्यपुस्तिका 'पिछले घंटे में burn rate 14.4 से ऊपर AND पिछले 5 मिनट में 14.4 से ऊपर' जैसी संयुक्त स्थितियों पर अलर्ट करने की सिफारिश करती है। ज्यामिति: एक निरंतर तीव्र ढलान, सिर्फ एक संक्षिप्त स्पाइक नहीं। यह आकार क्षणिक झटकों को फ़िल्टर करता है जबकि वास्तविक क्षरण खतरों को पकड़ता है।
एक Burn Rate पढ़ना
आपकी टीम का SLO 28 दिन में 99.9% है। दिन 7 पर, आप पहले से ही अपने error budget का 60% उपयोग कर चुके हैं। पिछले 24 घंटों में वर्तमान burn rate 8 है।
एक निर्देशित ग्राफ के रूप में सेवाएं
उत्पादन एक DAG के रूप में
आधुनिक सेवाएं निर्भरता के ग्राफ के रूप में चलती हैं। प्रत्येक सेवा एक नोड है। सेवा A से सेवा B की प्रत्येक कॉल A से B तक एक निर्देशित किनारा है। पूरी तस्वीर एक निर्देशित ग्राफ बनाती है (कभी-कभी DAG, कभी-कभी async retries के माध्यम से चक्र के साथ)।
महत्वपूर्ण ज्यामितीय गुण:
- Out-degree: एक नोड कितनी सेवाओं पर निर्भर करता है। उच्च out-degree मतलब अधिक upstream विफलता मोड। एक सेवा जो 12 backends पर निर्भर करती है यदि उनमें से कोई भी विफल हो तो विफल हो जाती है।
- In-degree (fan-in): कितनी सेवाएं इस नोड पर निर्भर करती हैं। उच्च in-degree मतलब एक एकल विफलता यहाँ व्यापक रूप से cascades। 30 dependent सेवाओं वाला डेटाबेस सबसे बड़ी blast radius रखता है।
- Betweenness centrality: कितने shortest paths एक नोड के माध्यम से जाते हैं। उच्च-betweenness नोड्स चोक बिंदु हैं। प्रमाणीकरण सेवाएं और core APIs आमतौर पर उच्च स्कोर करती हैं।
- Strongly connected components: सेवाओं के समूह जो चक्र बनाते हैं। यदि A, B को कॉल करता है और B, A को कॉल करता है, आपके पास चक्र है। चक्र विफलता पुनर्प्राप्ति को जटिल बनाते हैं: दोनों सेवाएं शुरू करना दूसरे को पहले से काम करने की आवश्यकता है।
Blast radius वह ज्यामितीय अवधारणा है जो विश्वसनीयता निवेश को संचालित करती है। एक विफलता की blast radius dependent सेवाओं का subgraph है जो यह प्रभावित करता है। विश्वसनीयता इंजीनियरिंग सबसे बड़ी blast radius वाले नोड्स में भारी निवेश करती है। समग्र प्रणाली विश्वसनीयता में सुधार करने का सबसे सस्ता तरीका अक्सर उच्चतम-betweenness नोड्स में redundancy या graceful degradation जोड़ना है।
Blast Radius तर्क
एक consumer सेवा निर्भर करती है: AuthService, UserDB, ProductCatalog, PaymentGateway, RecommendationEngine, EmailService, AnalyticsService। AuthService के 47 अन्य सेवाएं निर्भर करती हैं। EmailService के 3 अन्य सेवाएं निर्भर करती हैं। RecommendationEngine के 2 अन्य सेवाएं निर्भर करती हैं।
एक Dashboard की सूचना ज्यामिति
Pixels वास्तविक संपत्ति हैं
एक dashboard एक 2D सतह है सीमित क्षेत्र के साथ। एक सिग्नल को आवंटित प्रत्येक pixel दूसरे सिग्नल को आवंटित न किया गया एक pixel है। Dashboard डिजाइन एक ज्यामिति समस्या है: सबसे अधिक निर्णय-relevant जानकारी को सबसे छोटे दृश्य क्षेत्र में व्यवस्थित करें जबकि spatial relationships को संरक्षित करें जो recognition में सहायता करते हैं।
पढ़ने के पैटर्न: पश्चिमी पाठक F-आकार में स्कैन करते हैं (ऊपर-बाएँ पहले, फिर पार, फिर नीचे)। सबसे महत्वपूर्ण सिग्नल ऊपर-बाएँ में है। नीचे-दाएँ को कम से कम ध्यान मिलता है।
Gestalt grouping: एक ही सेवा से सिग्नल एक ही दृश्य समूह में हैं। Latency, traffic, errors, और saturation एक सेवा के लिए एक 2x2 ग्रिड में हैं, पूरी स्क्रीन में scattered नहीं। दृश्य proximity तार्किक relationship को encode करता है।
Color encoding: त्रुटियों के लिए लाल, saturation के लिए पीला, स्वस्थ ranges के लिए हरा। Color विकल्प सम्मेलन हैं, यादृच्छिक नहीं। उन्हें उलटना incidents के दौरान हर glance पर cognitive load की लागत करता है।
Y-axis scaling: 0-100% पर scaled एक ग्राफ शांत दिखता है भले ही traffic में दोगुना वृद्धि हो। एक auto-scaled ग्राफ recent values के लिए सामान्य variation के दौरान चिंताजनक दिखता है। दोनों विकल्प उपयुक्त उपयोग हैं; विकल्प geometric है, सौंदर्य संबंधी नहीं।
Information density: बहुत कम सिग्नाल टीम को अंधा छोड़ देते हैं। बहुत अधिक noise में signal को दफन करते हैं। Edward Tufte का data-ink ratio लागू होता है: जो ink information को व्यक्त करता है और ink जो सजाता है के अनुपात को अधिकतम करें। Sparkline-style minimalism एक glance पर cluttered widgets को हराता है।
पहली Glance के लिए डिजाइन करना
आपकी टीम एक सेवा के लिए एक एकल प्राथमिक dashboard डिजाइन कर रही है जिसके पास 4 backend dependencies में 8 critical SLIs हैं। Dashboard on-call engineer के पहले सवाल का जवाब देने चाहिए 3 AM में 5 सेकंड में: 'क्या कुछ आग पर है, & यदि हाँ, तो कहाँ?'
SRE की ज्यामिति: समाप्ति
आकार जो उत्पादन चलाते हैं
आप चार ज्यामितीय संरचनाओं के माध्यम से चलते हैं जो SRE practice के नीचे चलती हैं:
- Latency distributions long-tail वक्र के रूप में जहाँ percentile बिंदु औसत से अधिक truth रखते हैं
- Error budget cones जहाँ depletion की ढलान remaining संख्या से बेहतर service स्वास्थ्य प्रकट करती है
- Service dependency graphs जहाँ blast radius और centrality विश्वसनीयता निवेश को निर्देशित करते हैं
- Dashboard layouts 2D real estate के रूप में जहाँ pixel allocation एक ज्यामिति समस्या है operational परिणामों के साथ
ज्यामितीय सोच वह है जो SRE को generic operations work से अलग करती है। एक ops engineer संख्याएँ पढ़ता है। एक SRE आकार पढ़ता है। आकार जानकारी को encode करते हैं जो कोई भी एकल संख्या नहीं दे सकती: एक burn rate की ढलान, एक tail की fatness, एक नोड की centrality, एक dashboard पैनल का gestalt।
SRE पर companion lesson practices को कवर करता है। यह lesson उनके पीछे की ज्यामिति को कवर करता है। एक साथ वे आधुनिक विश्वसनीयता इंजीनियरिंग का दृश्य और conceptual scaffolding बनाते हैं।