दुर्घटनाओं को कम करने के लिए कैसे परिनियोजित तैनाती की सुरक्षा के लिए?

Question

हाल ही में अमेज़ॅन S3 का us-East-1 क्षेत्र में एक प्रमुख आउटेज था। ऐसा लगता है कि यह एक स्पेलिंग त्रुटि के कारण संभव था जब एक विश्वसनीय या एक समान उपकरण में एक रखरखाव प्लेबुक चला रहा था। आप देखने के लिए ansible-playbook के चारों ओर एक शेल स्क्रिप्ट आवरण रख सकते हैं:

#!/bin/bash
/usr/bin/ansible-playbook "$@" --list-hosts --list-tasks
read -p "Are you sure? (y/n) " answer
test "$answer" = "y" || exit 0
exec /usr/bin/ansible-playbook "$@"

लेकिन सुरक्षा में सुधार करने और अपनी कंपनी के लिए एक बड़ी रुकावट के कारण त्रुटि को कम करने के लिए आपके द्वारा उपयोग किए जाने वाले कुछ अन्य तरीके क्या हैं।

Comments

मैं इस प्रश्न को ऑफ-टॉपिक के रूप में बंद करने के लिए मतदान कर रहा हूं क्योंकि यह unix.stackexchange.com या superuser.com

— रोमियो

कोड के रूप में इन्फ्रास्ट्रक्चर, एक दिन में सैकड़ों तैनाती पाने के लिए प्रमुख घटकों में से एक है। उन उपकरणों को सुरक्षित करने में सक्षम होना जो इस गति को संचालन में प्रमुख आउटेज बनाने से प्रदान करते हैं, मुझे एक प्रासंगिक विषय की तरह लगता है। बेशक मेरे द्वारा गलती हो सकती है। मैं हालांकि आपके विचार की सराहना करता हूं। क्या आप मेटा में विषय संबंधी प्रश्नों के बारे में इस चर्चा में शामिल होना चाहेंगे?

— जिरी क्लौडा

उदाहरण के लिए इस प्रश्न को विषय के रूप में स्वीकार किया जाता है: devops.stackexchange.com/questions/98/…

— Jiri Klouda

गिरि, क्या आप अपने और आपके द्वारा उल्लेखित अन्य प्रश्न के बीच अंतर करते हैं?

— रोमियो निनोव

यदि इस प्रकार के प्रश्न सुपरसुबर के लिए उपयुक्त होंगे, तो devops.se की कोई आवश्यकता नहीं होगी। यह निश्चित रूप से यहाँ विषय पर है। मानव त्रुटि के संचालन और शमन में DevOps के मूल में हैं।

— एवगेनी

Answer 1

हम तैनाती को ट्रिगर करने के लिए जेनकींस में नौकरियों का उपयोग कर रहे हैं। यह सुनिश्चित करता है कि कोई भी व्यक्ति जो तैनाती नहीं करता है, जो चलाए जाने वाले ansible कमांड होगा वही होगा। एक अच्छा बोनस बिल्ड लॉग्स रिकॉर्ड है जब तैनाती शुरू की गई थी, जिन्होंने उन्हें ट्रिगर किया और तैनाती के दौरान वास्तव में क्या हुआ।

यह निश्चित रूप से मूर्खतापूर्ण नहीं है, लेकिन यह हाथ से खेली जाने वाली प्लेबुक चलाने पर एक अच्छा सुधार है।

बड़े / जोखिम भरे परिवर्तनों के लिए इसे आदर्श रूप से परिवर्तन प्रबंधन के साथ जोड़ा जाना चाहिए ताकि किसी अन्य व्यक्ति / टीम द्वारा परिवर्तन की समीक्षा और संभावित मुद्दों को जल्दी से हल करने में मदद करने के लिए परिवर्तन हो।

इसके अतिरिक्त यह कभी नहीं होता है कि एक टीममेट हो जो आपके द्वारा किए जा रहे बदलाव को समझता है और जब आप बड़े बदलाव करते हैं तो देखते हैं ताकि वे बदलाव के निष्पादन में गलतियों को रोकने में मदद कर सकें।

Answer 2

त्रुटियों की श्रेणियाँ

मानवीय कारकों को देखने के दो तरीके हैं जो समस्याओं और दुर्घटनाओं को जन्म देते हैं:

1. आप मानवीय त्रुटि को हादसे के कारण के रूप में देख सकते हैं। इस मामले में "मानव त्रुटि", जो भी लेबल के तहत- स्थिति जागरूकता, प्रक्रियात्मक उल्लंघन, नियामक कमियों, प्रबंधकीय कमियों का नुकसान आपकी जांच का निष्कर्ष है।
2. आप मानवीय त्रुटि को गहरी परेशानी के लक्षण के रूप में देख सकते हैं। इस मामले में, आपकी जांच के लिए मानव त्रुटि प्रारंभिक बिंदु है। आप जांच करेंगे कि मानवीय त्रुटि लोगों के उपकरणों, कार्यों और परिचालन / संगठनात्मक वातावरण की सुविधाओं से कैसे जुड़ी है।

पहला मानव दृष्टिकोण कहलाता है , और दूसरा सिस्टम दृष्टिकोण के रूप में ।

मानवीय दृष्टिकोण का उपयोग करते हुए विफलता की व्याख्या करने के लिए, आप विफलता की तलाश करेंगे और लोगों के गलत आकलन, गलत निर्णय या बुरे निर्णय पाएंगे।

सिस्टम दृष्टिकोण का उपयोग करके विफलता की व्याख्या करने के लिए, आप यह खोजने की कोशिश नहीं कर रहे हैं कि लोग कहां गलत हो गए। इसके बजाय, यह जानिए कि लोगों के आकलन और कार्यों ने उस समय कैसे काम किया, जो परिस्थितियों ने उन्हें घेर लिया।

उदाहरण के लिए, इंस्टीट्यूट फॉर हेल्थकेयर इंप्रूवमेंट (IHI) के डोनाल्ड बेर्विक्स का तर्क है कि रोगी की सुरक्षा में सुधार के लिए सिस्टम के डिजाइन में बदलाव की आवश्यकता है :

... हम इंसान हैं, और इंसान गलत हैं। नाराजगी के बावजूद, दुःख के बावजूद, अनुभव के बावजूद, अपने सर्वोत्तम प्रयासों के बावजूद, अपनी गहरी इच्छाओं के बावजूद, हम पतनशील पैदा होते हैं और आगे भी बने रहेंगे। सावधान रहना मदद करता है, लेकिन यह हमें पूर्णता के पास कहीं नहीं लाता है ... उपाय काम के बदलते सिस्टम में है। उपाय डिजाइन में है। लक्ष्य चरम सुरक्षा होना चाहिए। मेरा मानना ​​है कि हमें अपने अस्पतालों में उतना ही सुरक्षित होना चाहिए जितना हम अपने घरों में हैं। लेकिन हम उस लक्ष्य तक पहुँच नहीं सकते हैं, जो पहले से ही है। हम इसे बदलने की प्रतिबद्धता से ही पहुंच सकते हैं, ताकि सामान्य, मानवीय त्रुटियों को परिणाम के लिए अप्रासंगिक बना दिया जा सके, लगातार पाया गया, और कुशलता से कम किया गया।

डोनाल्ड एम बेरविक। फिर से नहीं! बीएमजे 2001

---

सिस्टम से गलतियों को दूर करना

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

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

प्रभावी नियंत्रण के उपाय

जब कोई त्रुटि होती है तो प्रक्रिया को रोकने के लिए प्रभावी नियंत्रण उपायों को रखें। यह गलती करने वाला है। प्रभावी नियंत्रण उपाय डिज़ाइन परिवर्तन हैं जो प्रक्रियाओं को जारी रखने से रोकते हैं या रोकते हैं जब एक प्रक्रिया विफलता की शुरुआत करके त्रुटि हुई है

उदाहरण:

1896 में, साकिची तोयोदा ने जापान की पहली पावर लूम का आविष्कार किया, जिसे "टॉयोडा स्टीम पावर लूम" कहा गया। इस विकास ने उत्पादकता में बीस गुना वृद्धि की, और वस्त्रों की गुणवत्ता में सुधार हुआ और जापान में कपड़ा उद्योग में क्रांति हुई। लेकिन यहाँ सूक्ष्म लेकिन बहुत महत्वपूर्ण खोज और सिद्धांत है:

जब सुई टूट गई, तो मशीन बंद हो गई

साकिची तोयोदा ने लूम के लिए एक नवाचार बनाया जो बाद में टोयोटा प्रोडक्शन सिस्टम (लीन) में स्तंभों में से एक बन जाएगा। उस स्तंभ को अब हम जिडोका कहते हैं, जिसे कभी-कभी "मानव स्पर्श के साथ स्मार्ट स्वचालन" या "स्वायत्तता" कहा जाता है।

बड़े हिस्से में, एंडॉन (पहले दोष पर रोक) और पोका-योक (गलती का प्रमाण देना) बाद के घटनाक्रम हैं जो लूम से अपना प्रभाव पाते हैं।

सिंगल-पॉइंट कमजोरियों को दूर करना

शब्द एकल-बिंदु कमजोरी प्रणाली विश्वसनीयता में सुधार के दृष्टिकोण के रूप में प्रणाली में अतिरेक के निर्माण को संदर्भित करता है। अतिरेक प्रक्रिया में शामिल प्रणालियों या व्यक्तियों की संख्या में वृद्धि करके बनाया गया है। अधिक बैकअप सिस्टम या अधिक चेक (डबल, ट्रिपल या अधिक) होने से यह संभावना बढ़ जाती है कि प्रक्रिया सही ढंग से आगे बढ़ेगी।

इसके लिए एक महान उदाहरण "चार आंखों वाला सिद्धांत" है, जिसका अर्थ है कि "सभी व्यावसायिक निर्णयों और लेनदेन को सीईओ और सीएफओ से अनुमोदन की आवश्यकता है। चूंकि सीएफओ सीईओ को रिपोर्ट नहीं कर रहा है, इसलिए एक स्वतंत्र नियंत्रण तंत्र है" ।

^{स्रोत: https://en.wikipedia.org/wiki/Two-man_rule}

खतरों को स्पष्ट करें

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

---

कुछ महान किताबें विषय के बारे में बात कर रही हैं, और यह उनका उल्लेख किए बिना एक अच्छा जवाब नहीं होगा:

• सिडनी डेकर द्वारा 'मानव त्रुटि' को समझने के लिए फील्ड गाइड
• साइट विश्वसनीयता इंजीनियरिंग: Google कैसे उत्पादन प्रणाली चलाता है
• शून्य गुणवत्ता नियंत्रण: स्रोत निरीक्षण और शिगो शिंगो द्वारा पोका-योक सिस्टम

Comments

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

— माइकल ले बारबियर ग्रुएनवाल्ड

मैं उस SPW सिद्धांत में जोड़ दूँगा।

— इवगेनी

त्रुटियों के बारे में महान चर्चा है, लेकिन यह नहीं कहता है कि आकस्मिक तैनाती के खिलाफ सुरक्षा कैसे करें।

— अलेक्जेंड्रे

प्रश्न विशेष रूप से Ansible के बारे में पूछता है। यह उत्तर बहुत गहन और शोधपूर्ण है लेकिन यह वास्तविक दुनिया की समस्या से एक कदम दूर है।

— वुडलैंड हंटर

@Evgeny जब मैंने आपके AWS लाम्बा के प्रदर्शन के सवाल का जवाब दिया, तो सबसे पहले मैंने यह नहीं कहा कि मैं आपके परीक्षण कैसे चलाऊं और आपने बताया। आप सही थे, और मैंने अपना उत्तर समायोजित कर लिया। मैं उन लोगों को समझता हूं जो नीचे अपना जवाब दे रहे हैं। आपका उत्तर "हमारे कार्यस्थल में त्रुटियों को कैसे प्राप्त करें और कम करें?" के बारे में एक प्रश्न के लिए अच्छा होगा। यहाँ, ओपी के पास अन्सिबल के बारे में एक प्रश्न है और आप इसका उल्लेख भी नहीं करते हैं। इससे भी बदतर, ओपी इस बात का संकेत देता है कि वह किस तरह के समाधान की तलाश में है और आप दूसरे रास्ते पर जा रहे हैं। आपका उत्तर बहुत अच्छा है (वास्तव में), लेकिन इस प्रश्न के लिए नहीं।

— अलेक्जेंड्रे

Answer 3

जैसा कि @bradim ने अपने CI / CD टूल का उपयोग करके हाथ पर आधारित आदेशों के बजाय परिनियोजन शुरू करने के लिए आमतौर पर अच्छा कदम आगे बढ़ाया है, जैसा कि आपकी पाइपलाइन में परीक्षण जोड़ रहा है जो वास्तव में आपके मंचन (या हौसले से निर्मित) वातावरण पर आपकी तैनाती लिपियों का परीक्षण करता है, जहां आप पहले कीड़े उठा सकते हैं।

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