Site Reliability Engineering (SRE) में 20 साल में सीखे गए सबक
YouTube से सीखे गए reliability engineering के सबक
-
जोखिम कम करने वाले उपायों का चयन
- गंभीर त्रुटि होने पर, उस त्रुटि की गंभीरता के अनुपात में जोखिम कम करने वाले उपाय चुनने चाहिए।
- अत्यधिक mitigation उपाय दुष्प्रभाव पैदा कर सकते हैं, इसलिए standard procedure को bypass तभी करना चाहिए जब उसके लिए उचित कारण हो।
-
आपात स्थिति के लिए recovery mechanism का परीक्षण
- recovery mechanism और mitigation उपायों का पहले से पर्याप्त अभ्यास और परीक्षण होना चाहिए, ताकि आपात स्थिति में प्रभावी ढंग से प्रतिक्रिया दी जा सके।
- testing के जरिए भविष्य के risk को कम किया जा सकता है और response capability बेहतर होती है।
-
बदलावों को चरणबद्ध तरीके से लागू करना (canary testing लागू करना)
- किसी बदलाव को पूरी तरह deploy करने से पहले उसे धीरे-धीरे लागू करना चाहिए, ताकि issue आने पर पूरे system पर असर न पड़े।
- YouTube के caching configuration बदलाव के उदाहरण से यह समझ में आया कि छोटे बदलावों के लिए भी systematic rollout महत्वपूर्ण है।
Google Calendar से सीखे गए सबक
-
emergency stop feature का महत्व
- संभावित जोखिम वाले बदलावों के लिए ऐसे feature की ज़रूरत होती है जो "big red button" की तरह तुरंत प्रतिक्रिया दे सके।
- service dependency को ध्यान में रखते हुए emergency stop feature तैयार रखना चाहिए।
-
integration testing की आवश्यकता
- unit testing सीमित दायरे में उपयोगी है, लेकिन integration testing के जरिए वास्तविक environment से जोड़कर system की उपयुक्तता की जाँच करनी चाहिए।
- Google Calendar की त्रुटि के उदाहरण से यह स्पष्ट हुआ कि वास्तविक user path का पालन करने वाली testing कितनी महत्वपूर्ण है।
2017 में Google से मिले सबक
-
आपात स्थिति के लिए communication channel का महत्व
- communication channel और backup channel की पहले से तैयारी होनी चाहिए।
- service outage की स्थिति में, एक-दूसरे पर निर्भर न रहने वाले कई communication माध्यम तैयार रखने चाहिए और उनकी प्रभावशीलता का परीक्षण करना चाहिए।
-
performance degradation के दौरान न्यूनतम functionality बनाए रखना
- system को इस तरह design करना चाहिए कि service पूरी तरह बंद न हो और performance degradation की स्थिति में भी बुनियादी functionality उपलब्ध रहे।
disaster resilience के लिए testing
- disaster resilience और recovery testing
- service या system की resilience का परीक्षण करना चाहिए, ताकि आपदा की स्थिति में भी उसकी निरंतरता सुनिश्चित की जा सके।
- recovery testing के जरिए यह पुष्टि करनी चाहिए कि system outage के बाद फिर से सामान्य स्थिति में लौट सकता है या नहीं।
automated mitigation का महत्व
- mitigation का automation
- कई network failure की स्थिति में manual handling के बजाय automated mitigation के जरिए समस्या समाधान का समय कम करना चाहिए।
deployment के बीच का समय कम करना
-
बार-बार rollout करना
- rollout के बीच लंबा समय अंतराल system safety का आकलन करने में बाधा बनता है।
-
एक ही global hardware version, single point of failure है
- केवल एक खास model पर निर्भर रहने से operations सरल हो सकते हैं, लेकिन उस model में समस्या आने पर महत्वपूर्ण functions रुक सकते हैं।
- कई network backbone का होना पूरे outage को रोकने में मदद करता है और high-priority traffic को अब भी काम कर रहे वैकल्पिक मार्गों पर route किया जा सकता है।
अभी कोई टिप्पणी नहीं है.