सफलता को कैसे मापें। निगरानी की रणनीति और व्यावसायिक समस्याओं के लिए उनका संबंध

प्रश्न का उत्तर देने से पहले "सफलता कैसे मापें?", आपको यह समझने की आवश्यकता है कि आपके लिए "सफलता" का क्या अर्थ है। देव और ऑप्स के लिए, सफलता की परिभाषा अलग है। देव के लिए, एक सफल परियोजना पूरी तरह से परीक्षण की जाती है। ऑपरेशन के लिए - निगरानी। परीक्षण और निगरानी आवश्यक है, लेकिन परीक्षण कभी भी समस्या का 100% कवरेज नहीं देते हैं, और HTTP से 200 की प्रतिक्रिया यह सुनिश्चित करने के लिए पर्याप्त नहीं है कि सिस्टम अच्छी तरह से काम करता है। RIT ++ में लियोन फेयर ने इस दृष्टिकोण का बचाव किया कि DevOps यह सुनिश्चित करने के लिए भुगतान नहीं करता है कि निगरानी में सभी मैट्रिक्स ग्रीन ज़ोन में हैं। वे उपयोगकर्ताओं को खुश करने के लिए भुगतान करते हैं । यदि आप असंतुष्ट हैं - व्यवसाय पैसे खो रहा है, और कोई भी परवाह नहीं करता है कि सब कुछ हरा है।

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

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

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

प्रश्न का उत्तर देने से पहले "सफलता कैसे मापें?", आपको यह समझने की आवश्यकता है कि आपके लिए "सफलता" का क्या अर्थ है। प्रत्येक व्यक्ति के लिए, उत्तर अलग होगा।

यदि आप इस लेख को पढ़ रहे हैं, तो आप सबसे अधिक संभावना DevOps के साथ शामिल हैं। क्या आप ऑप्स से अधिक देव हैं? या, इसके विपरीत, देव से अधिक ऑप्स? देव और ऑप्स के लिए, सफलता की परिभाषा थोड़ी अलग है: देव के लिए, निश्चित रूप से, परीक्षण है।

परीक्षण

मेरे लिए, एक प्रोग्रामर के रूप में, सफल परीक्षण का मतलब है कि सब कुछ क्रम में है, सब कुछ ठीक है, सब कुछ काम करता है - आप इसे उत्पादन में चला सकते हैं। समस्या यह है कि मैं भी एक निंदक हूँ, और इस तरह के परीक्षण का प्रशंसक नहीं हूं। इसलिए नहीं कि यह कठिन है, और इसलिए नहीं कि यह लंबा है - बल्कि इसलिए कि परीक्षण मुझे वह नहीं देता जो मैं चाहता हूं।

मुझे सही ढंग से समझें, परीक्षण एक अनिवार्य प्रक्रिया है , इसे किसी भी परियोजना में शामिल किया जाना चाहिए, लेकिन यह स्पष्ट रूप से सफलता की गारंटी देने के लिए पर्याप्त नहीं है ।

कई अलग-अलग परीक्षण विकल्प हैं:

• प्रदर्शन परीक्षण;
  
• उपयोगकर्ता परीक्षण;
  
• स्वचालित परीक्षण ...
  

1, 2, 3, 5 का आप कितने परीक्षण तरीकों का उपयोग करते हैं? और क्या, आप रात की चेतावनी पर जाग नहीं रहे हैं? क्या उत्पादन में सब कुछ काम करता है?

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

कुछ समस्याएं हैं जिनके कारण परीक्षण पर्याप्त नहीं है। पहला, ज़ाहिर है, एक डेटा समस्या है । तथ्य यह है कि कार्य स्थानीय रूप से काम करता है, लेकिन किसी कारण से उत्पादन में काम नहीं करता है, एक मानक समस्या है।

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

वोल्फ + 585 - दुनिया का सबसे लंबा अंतिम नाम:

ह्यूबर्ट ब्लेन
Wolfeschlegelsteinhausenbergerdorffwelchevoralternwaren-gewissenhaftschaferswessenschafewarenwohlgepflegeundsorgfaltigkeitbeschutzen-vorangreifendurchihrraubgierigfeindewelchevoralternzwolfhunderttausendjahres-vorandieerscheinenvonderersteerdemenschderraumschiffgenachtmittungsteinund- siebeniridiumelektrischmotorsgebrauchlichtalsseinursprungvonkraftgestartsein-langefahrthinzwischensternartigraumaufdersuchennachbarschaftdersternwelchege-habtbewohnbarplanetenkreisedrehensichundwohinderneuerassevonverstandig-menschlichkeitkonntefortpflanzenundsicherfreuenanlebenslanglichfreudeundruhe-mitnichteinfurchtvorangreifenvorandererintelligentgeschopfsvonhinzwischensternartigraum,
सीनियर

यदि कोई अंतिम रूप में ऐसे किसी अंतिम नाम को दर्ज करता है तो कुछ सिस्टम जीवित रहेंगे। मैं कम से कम 5 अलग-अलग बिंदुओं को जानता हूं जहां पूरी प्रणाली उड़ सकती है।

इसलिए, दूसरी समस्या उपयोगकर्ताओं के साथ समस्या है।

ये ऐसे दिलचस्प लोग हैं जो कुछ भी तोड़ देंगे। अगर कोई उपयोगकर्ता नहीं थे, तो सब कुछ बहुत आसान होगा, ईमानदार होना।

यहां तक ​​कि अगर आपके यूआई में एक बटन है, तब भी वे जो हम कर रहे हैं, उसे तोड़ने के लिए एक विधि मिलेगी।

सबसे अच्छा उदाहरण विश्व Warcraft का है ।

जो लोग नहीं जानते हैं, उनके लिए यह एक ऑनलाइन गेम है जिसे 10 मिलियन लोग खेलते हैं। एक समय में काफी प्रसिद्ध कीड़े थे। दूषित रक्त बग एक आदर्श उदाहरण है कि उपयोगकर्ता कैसे सब कुछ खराब करते हैं।

किसी भी खिलौने के साथ, Warcraft की दुनिया में नई सामग्री, नए विचार, नए मालिक लगातार दिखाई दिए। नए मालिकों में से एक ने समूह के 40 खिलाड़ियों में से एक को शाप दिया था। अभिशाप का सिद्धांत एक टाइम बम की तरह था - इसने धीरे-धीरे सभी के जीवन को दूर कर दिया। यही है, पक्ष की ओर भागना आवश्यक था - एक पूरे यांत्रिकी था। और तब तक सब कुछ ठीक था, किसी समय, खिलाड़ियों में से एक ने लड़ाई के दौरान शहर को टेलीपोर्ट करने का फैसला किया था ...

शहर में सभी स्तरों के हजारों लोग थे, सबसे छोटा भी। इतना ही नहीं, अभी भी गैर-खिलाड़ी पात्र थे जो एक अभिशाप से संक्रमित हो गए थे। दिन के दौरान, सर्वर खाली थे। कहीं भी जाना असंभव था, जहां अन्य खिलाड़ी थे। यह शब्द के ट्रूस्ट अर्थ में एक गेम प्लेग बन गया। मुझे शाप को हटाने और यांत्रिकी को बदलने के लिए सभी सर्वरों का एक दौर पुनरारंभ करना पड़ा। और सभी एक परीक्षक के कारण - मुझे यह भी पता नहीं है कि इसे क्या कहा जाना चाहिए।

तीसरी मुख्य समस्या बाहरी निर्भरता के साथ समस्या है। हम सभी इस पर आए: जिस एपीआई पर आप निर्भर हैं वह अचानक काम करना बंद कर देता है; या आप एपीआई को नियंत्रित करना बंद कर दें।

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

संभवतः सबसे आदर्श उदाहरण हाल ही में, लगभग एक साल पहले था - यह बाएं - पैड है । यह नोड.जेएस पर एक एनपीएम मॉड्यूल है जो स्ट्रिंग (एक पंक्ति की शुरुआत में) से पहले रिक्त स्थान को उजागर करता है। हम चर्चा नहीं करेंगे कि यह मॉड्यूल क्यों बनाया गया था। लेकिन यह पता चला है कि यह बहुत सारे लोकप्रिय मॉड्यूल में शामिल था। कुछ बिंदु पर, लेखक ने फैसला किया कि उसके पास पर्याप्त है, इस मॉड्यूल को एनपीएम से हटा दिया, और नोड में लिखे गए कोड का 70% उड़ गया।

अगर आपको लगता है कि यह एक अलग मामला है, तो आप गलत हैं।

इसमें आई-ऑड मॉड्यूल भी है, जो अब npm में है। यह मॉड्यूल एक समान संख्या को परिभाषित करता है या नहीं।

हम इस तथ्य पर चर्चा नहीं करेंगे कि 3 मिलियन लोग समता / विषमता की जांच करना नहीं जानते हैं। लेकिन 12 और मॉड्यूल हैं जो इसका उपयोग करते हैं! और यह ज्ञात नहीं है कि इनमें से कितने मॉड्यूल अभी भी मॉड्यूल का उपयोग कर रहे हैं। अगर यह आपको लगता है कि इसमें कुछ टूटने वाला नहीं है - 5 संस्करण हैं!

हमारी भेड़ों की ओर लौटते हुए - और भी कई विकल्प हैं:

• लघु - दृष्टि - हम नहीं जानते कि भविष्य में क्या होगा। Y2K एक आदर्श उदाहरण है। किसी ने भी नहीं सोचा था कि 2000 में कोबोल में लिखी गई हर चीज उड़ जाएगी।
  
• परीक्षण विकल्पों की संख्या ।
  

Warcraft की दुनिया के साथ फिर से एक अच्छा उदाहरण है - उनके पास इस विषय पर कई अच्छे उदाहरण हैं।

खेल की रिहाई के छह महीने बाद, अपील के समर्थन में आना शुरू हुआ कि कुछ खिलाड़ी एक गुफा में प्रवेश नहीं कर सकते। यह पता चला कि दौड़ और लिंग का केवल एक संस्करण इस गुफा में प्रवेश नहीं कर सकता है - ये महिला टॉरेन थे।

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

• स्रोत डेटा में बदलें। हम वास्तव में नहीं जानते कि कल क्या होगा।
  

किसी भी मामले में, कुछ परीक्षण हैं। लेकिन परीक्षण 100% कवरेज नहीं देते हैं। इसलिए, परीक्षण सफलता की गारंटी नहीं देता है। यह धीरे-धीरे हमें दूसरे भाग में लाता है - ऑप्स। शोषण के लिए, सफलता निगरानी कर रही है ।

निगरानी

निगरानी की आवश्यकता के कई कारण हैं:

• सही कोड मौजूद नहीं है;
• सिस्टम अधिक जटिल होते जा रहे हैं;
• बढ़ती बाहरी निर्भरता;
• प्रत्याशा -> प्रतिक्रिया;
• ...

निगरानी की जरूरत है क्योंकि सब कुछ बदल रहा है। यह मुख्य कारण है। इसके अलावा, यह उत्पादन में है, सब कुछ लगातार वहां बदलता रहता है और हमें इसका पता लगाने की जरूरत है।

निगरानी कवर क्या होना चाहिए? - यह बात है! यह एक संक्षिप्त उत्तर है, लेकिन इसमें सब कुछ शामिल होना चाहिए।

यह सब थोड़ा सार है। वास्तव में, हम सभी के पास एक चेकलिस्ट है जिसे हम मॉनिटर करते हैं:

• बुनियादी ढांचे;
  
• डेटाबेस;
  
• अनुप्रयोगों;
  
• एकीकरण अंक;
  
• अनुरोध प्रसंस्करण समय;
  
• लोड;
  
• ...
  

एक लाख बातें हो सकती हैं। कई अपने सिस्टम पर सैकड़ों, हज़ारों और दसियों हज़ार मीट्रिक इकट्ठा करते हैं।

हम इसके लिए बहुत सारे मीट्रिक एकत्र करेंगे:

बेशक, मैं अतिशयोक्ति कर रहा हूं, लेकिन ऑप्स के दृष्टिकोण से हम सभी की जरूरत है कि HTTP 200 को वापस करने के लिए है । इसका मतलब है कि साइट के साथ सब कुछ ठीक है। एक बार जब कोई साइट काम करती है, तो इसका मतलब है कि डेटाबेस काम करते हैं, अनुप्रयोग काम करते हैं - सब कुछ क्रम में है। ऑप्स के दृष्टिकोण से, सफलता बिल्कुल यही है: सभी ग्राफिक्स ग्रीन ज़ोन में हैं, सब कुछ सही ढंग से काम कर रहा है - सब कुछ ठीक है!

हर कोई जानता है कि ट्विटर क्या है। वे प्रति दिन 500 मिलियन ट्वीट्स की प्रक्रिया करते हैं - एक पागल संख्या।

लेकिन वे अपनी गलतियों के लिए भी जाने जाते हैं। त्रुटियां उनकी जटिलता या सहजता में प्रसिद्ध हैं - किस तरफ देखना है।

उनसे एक गलती हुई: साइट ने काम किया, ग्राहक एक ट्वीट लिख सकता है, एक बटन पर क्लिक करें, उन्होंने कहा कि धन्यवाद, ट्वीट भेजा गया था - और यह बात है! वह कहीं दिखाई नहीं दिया और बस गायब हो गया, और निगरानी से पता चला कि सब कुछ क्रम में था। साइट 200 अनुरोध लौटाती है - एपीआई काम करता है। लेकिन कोई ट्वीट नहीं कर रहे हैं!

मेरे पास एक ग्राहक से एक पसंदीदा उद्धरण है। मैंने एक घंटे के लिए तीन स्क्रीन पर समस्याओं की मरम्मत की, और वह चिल्लाया कि कुछ भी क्यों नहीं काम करता है। जब मैंने यह बताने की कोशिश की कि मैं क्या समस्याएँ ठीक कर रहा हूँ, एक ऐसा व्यक्ति जो दो उँगलियों से टाइप करता है और यह नहीं समझ पाता कि कंप्यूटर का उपयोग कैसे किया जाता है:

"जब तक मैं पैसा बनाना जारी रखता हूं, यह मेरे लिए *** है कि सर्वर चालू हैं।"

कुछ मायनों में, यह बहुत सही है, और ट्विटर का उदाहरण इस बात की पुष्टि करता है: सभी मैट्रिक्स ने दिखाया कि डेवलपर्स के दृष्टिकोण से सब कुछ क्रम में था, लेकिन व्यवसाय के काम के दृष्टिकोण से, यह बिल्कुल भी नहीं था।

सच कहूं तो हम सभी दोषी हैं। बेशक, निगरानी उत्पादों का उत्पादन करने वाली कंपनियों को मुख्य रूप से दोष देना है। लेकिन हम भी, क्योंकि परंपरागत रूप से हम सिस्टम मेट्रिक्स इकट्ठा करते हैं। हम छोटे सिस्टम के साथ काम करने के आदी हैं - एक, शायद दो सर्वर। यदि वे काम करते हैं, तो सब कुछ क्रम में है।

अब हमारे पास दो या 10 से थोड़ा अधिक सर्वर हैं, और केवल सिस्टम या प्रोग्राम के स्वास्थ्य को मापने के लिए पर्याप्त नहीं है। हमें किसी और चीज के काम को ट्रैक करना चाहिए।

बोली पर लौटते हुए, मैंने भुगतान नहीं किया कि सब कुछ हरा हो। मुझे भुगतान मिलता है ताकि मेरे उपयोगकर्ता या मेरे प्रबंधक संतुष्ट हों - किसी को परिणाम से खुश होना चाहिए । यदि सभी उपयोगकर्ता दुखी हैं, तो कोई भी परवाह नहीं करता है कि सब कुछ हरा है।

व्यवसाय की निगरानी

हमने कहा कि निगरानी की जरूरत है क्योंकि सब कुछ बदल रहा है। लेकिन जब सब कुछ बदल जाता है, तो परिवर्तन व्यवसाय को प्रभावित करते हैं: कुछ टूट गया है - पैसा आना बंद हो गया है, कुछ की मरम्मत की गई है - पैसा फिर से बहना शुरू हो गया है - एक सीधा संबंध। या वे प्रभाव नहीं डालते - लेकिन यदि हम व्यवसाय की निगरानी नहीं करते हैं, तो हम यह नहीं जानते हैं।

एक जीवित उदाहरण के रूप में, कैश पढ़ने का ग्राफ हर किसी के लिए परिचित है।

90% समय, सब कुछ क्रम में है, लगभग सभी अनुरोध कैश पर जाते हैं। और अचानक कुछ हुआ - और बहुत गंभीर। यह एक ऐसी समस्या है जो सुबह 3 बजे उठनी चाहिए जो इसे हल करेगी। लेकिन, अगर उपयोगकर्ताओं के लिए डाउनलोड की गति नहीं बदलती है, तो क्या यह वास्तव में एक समस्या है?

अंग्रेजी में ऑब्जर्वबिलिटी - ऑब्जर्वेबिलिटी शब्द है। ये हैं: निगरानी करना, प्रवेश करना, सतर्क करना। इसलिए, निगरानी शब्द थोड़ा है। हम हर चीज का निरीक्षण करना चाहते हैं - यदि आवश्यक हो तो प्रत्येक नोड पर सिस्टम मेट्रिक्स इकट्ठा करें। लेकिन हम व्यवसाय की निगरानी करना चाहते हैं, क्योंकि यह सभी को उत्साहित करता है। यह सफलता का सूचक है।

ऐसा करने के लिए, हमें चाहिए:

1. समस्या को समझें - हमें वास्तव में निगरानी की क्या आवश्यकता है।

2. आधार रेखा निर्धारित करें - अर्थात क्या यह पर्याप्त है कि उपयोगकर्ता की डाउनलोड गति में बदलाव नहीं हुआ है ताकि कैश से पढ़ने के दौरान रात के मध्य में कोई भी जाग न जाए।

3. सहसंबंधी डेटा सबसे महत्वपूर्ण कारकों में से एक है। यदि विपणन आय पर डेटा एकत्र करता है, और आप सर्वर पर डेटा एकत्र करते हैं और इन दो टिप्पणियों की तुलना नहीं कर सकते हैं, तो उनके पास बहुत कम अर्थ हैं।

मैं आमतौर पर बहुत सारे उदाहरण देता हूं। कोई फर्क नहीं पड़ता कि वे कितने बेतुके दिखते हैं, वे सभी मेरे जीवन से हैं, और मैंने उन पर बहुत सारी नसों को खर्च किया।

उदाहरण: मेरे पास 100 मिलियन उपयोगकर्ताओं के साथ एक ग्राहक था। यह एक इंटरनेट मार्केटिंग कंपनी थी जिसने बहुत सारे ईमेल भेजे और ए / बी परीक्षण का इस्तेमाल किया। उनके लिए, हमने 6 हज़ार मीट्रिक एकत्र किए।

सब कुछ, हमेशा की तरह, एक कॉल के साथ शुरू हुआ। फोन की घंटी बजती है - इसका मतलब है कि कुछ हुआ है।

" हमें एक समस्या है।" कुछ काम नहीं कर रहा है।

- ठीक है, वास्तव में क्या काम नहीं करता है? इसमें क्या व्यक्त किया गया है?

- हमें कम आय प्राप्त होने लगी।

- और?

- कुछ सिस्टम में काम नहीं करता है।

- मुझे नहीं मिला। कम आय होने पर अपनी बिक्री टीम से बात करें। मुझे क्यों बुला रहे हो?

- नहीं, मुझे यकीन है कि सिस्टम में कुछ काम नहीं करता है!

- ठीक है, देखते हैं।

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

ठीक है, मुझे देखना होगा। सबसे पहले, मैं डाउनलोड गति की जांच करता हूं - सामान्य।

हमने डेटाबेस पर लोड को देखा - सब कुछ उचित सीमा के भीतर है, ऐसा लगता है कि कुछ भी नहीं बदला है। फिर हम कैश नोड्स में, अलग-अलग नोड्स में, कैश में देखने लगे।

सब कुछ क्रम में था। जब तक हम ई-मेल न्यूज़लेटर के मैट्रिक्स के पास नहीं पहुंचे। बड़े प्रदाताओं में से एक ने गलती से अपने डोमेन को काली सूची में डाल दिया। उनके ई-मेल मार्केटिंग का प्रतिशत उपयोगकर्ताओं तक पहुंचना बंद हो गया है, जिसका अर्थ है कि कम लोग: प्राप्त पत्र, बटन पर क्लिक किया गया, साइट पर गए और कुछ खरीदा।

यहाँ इस तरह एक सहसंबंध है!

हम भाग्यशाली हैं कि हमारे पास ये मीट्रिक थे। यदि हमारे पास नहीं है, तो हम उन्हें जोड़ देंगे - यह एक बहुत ही सरल उत्तर है।

लोगों की सबसे बड़ी गलती यह मानना ​​है कि परियोजना के अंत में निगरानी रखी जा सकती है। यह एक सुविधा की तरह है: अपनी खुद की परियोजना बनाने के लिए, निगरानी रखना - और वह सब, हम तैयार हैं!

इंस्ट्रूमेंटेशन कभी खत्म नहीं हो सकता। हमेशा ऐसी समस्याएं होती हैं जो शुरू से ही अज्ञात हैं। परीक्षण के साथ, आप परीक्षण नहीं लिख सकते हैं और सब कुछ कवर कर सकते हैं, क्योंकि आप नहीं जानते कि "सब कुछ" क्या है। हम नहीं जानते कि भविष्य की भविष्यवाणी कैसे करें और हम नहीं जानते कि किसी व्यवसाय की भविष्यवाणी कैसे करें, इसलिए हम यह नहीं जानते कि "सब कुछ" क्या है।

मैं क्या बात कर रहा हूँ के लिए एक बिल्कुल समान उदाहरण। यह सीईओ था, जो सुबह पेरिस में एक सम्मेलन में उठता था, कॉफी पीता था, उसके मेल और आय स्टेटमेंट को देखता था और मुझे उसी समस्या से बुलाता था: आय गिर गई।

मुझे यह अच्छी तरह से याद है, क्योंकि उसके पास सुबह 9 बजे थे, और मेरे पास 6 घंटे पहले, शनिवार को भी था। मुझे सिर्फ जन्मदिन की पार्टी से घर पहुंचाया गया है - लेकिन इससे कोई फर्क नहीं पड़ता। इसलिए, सुबह 3 बजे मैं कंप्यूटर पर बैठ जाता हूं, और हम उसी चरणों पर जाने लगते हैं। यही है, हम सिस्टम पर लोड को देखते हैं, पंजीकरण संख्या पर, बिल्कुल।

आदर्श से एकमात्र विचलन जो हमें मिला वह सफल प्राधिकरणों का कम प्रतिशत है। यही है, राशि समान है, लेकिन प्रतिशत थोड़ा कम है। मुझे पता है कि यह स्पैम हो सकता है, आदि। लेकिन अन्य सभी तकनीकी मेट्रिक्स बिल्कुल सामान्य हैं। और हम उस बिंदु पर पहुंच गए जहां हम लगभग डेटाबेस में लाइनों के साथ चल रहे थे और यह जांचने की कोशिश कर रहे थे कि क्या कुछ ऐसा है जिसे आंख से पकड़ा जा सकता है। बिल्कुल कुछ नहीं!

हम आधे रविवार को बैठे, सोमवार को भी जारी रहे, लेकिन पहले से ही सुनिश्चित थे कि समस्या तकनीकी नहीं थी। उन्हें खुद इसे तय करने दें। और यहां सोमवार को मैं काम पर बैठता हूं और उनके लेखा विभाग का एक कर्मचारी मुझे फोन करता है:

- सुनो, क्या तुम मेरी जल्दी से मदद कर सकते हो?

- आपको क्या चाहिए?

- क्या आप साइट से अमेरिकन एक्सप्रेस बैज निकाल सकते हैं?

- बेशक मैं कर सकता हूँ! अचानक क्यों?

- आप जानते हैं, हम यहां उनके साथ बहस करते हैं, और जब तक हम अमेरिकी को स्वीकार नहीं करते
सामान्य रूप से व्यक्त करें।

"मैं पूछने के लिए माफी माँगता हूँ, आपने उन्हें कब लेना बंद किया?"

- सप्ताहांत से पहले, मेरी राय में - शुक्रवार या शनिवार को ।

उनके सही दिमाग में कोई भी कभी भी एक निश्चित प्रकार के क्रेडिट कार्ड से प्राधिकरणों के प्रतिशत पर मीट्रिक संग्रह नहीं करेगा! इस घटना के बाद, निश्चित रूप से, हम सेट करते हैं।

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

व्यापार के लिए सफलता

एक व्यवसाय के लिए, सफलता अलग हो सकती है, यह लक्ष्यों पर निर्भर करता है। सबसे महत्वपूर्ण बात, यह कैसे मापा जा सकता है? परंपरागत रूप से, हम सिस्टम प्रदर्शन को मापते हैं, कभी-कभी इंजीनियरों के रूप में, यह भूल जाते हैं कि आप कुछ भी माप सकते हैं।

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

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

संयोग से, हमें इसके लिए एक और आवेदन मिला।

ग्राफ कई दिनों और सप्ताहांत में बीयर की खपत दिखाता है। सप्ताहांत तक, शराब की खपत आमतौर पर घट जाती है, लगभग गायब हो जाती है। एक दिन हम सोमवार को आते हैं, शेड्यूल को देखते हैं और देखते हैं कि शनिवार को किसी ने एक चौथाई बैरल बीयर पी ली। ग्राफ़ आधे घंटे के भीतर सटीक समय दिखाता है। यह पता चला कि शनिवार को आने वाले सफाईकर्मियों को हैंगओवर था, इसलिए उन्हें भूख लगी थी।

एक मजाक, लेकिन अंत में उन्हें गंभीर समस्याएं हुईं, क्योंकि काम पर पीना आम तौर पर बुरा होता है, और किसी और की बीयर भी!

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

आमतौर पर, किसी व्यवसाय की सफलता का मापदंड कुछ ऐसा होता है जिसमें अंततः पैसा शामिल होता है:

• लाभ;
  
• आय;
  
• खर्चों;
  
• दक्षता।
  

व्यापार मीट्रिक:

• पंजीकरण;
  
• खरीदारी;
  
• विज्ञापन दृश्य
• रूपांतरण;
• वापसी प्रतिशत;
• बियर के नशे में राशि

यह सब एक मौद्रिक समकक्ष है।वैसे, सबसे अधिक संभावना है, ये सभी मैट्रिक्स आपकी कंपनी में पहले से ही एकत्र किए गए हैं - या तो बिक्री से या विपणन द्वारा। तो आपको एक पहिया का आविष्कार करने की आवश्यकता नहीं है, आप बस मौजूदा मैट्रिक्स को अपने सिस्टम में ले सकते हैं।

सब कुछ व्यापार के संदर्भ में विचार किया जाना चाहिए। हमने व्यापार के लिए विशेष मैट्रिक्स के बारे में बात की। अन्य, अर्थात् तकनीकी मैट्रिक्स, को भी इस संदर्भ में माना जा सकता है।

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

यदि आप एक ही शेड्यूल लेते हैं और प्रभावित हुए उपयोगकर्ताओं की संख्या को देखते हैं, तो समस्या तुरंत अलग दिखती है।

, . , , , . , .

. , . . . , 3 , .

— . , , , , .

.

: , , , - .

, . , , , 50 % « », , .

1 ?

1-2 . . 10 000 , . , 10 000 , - .

1 . 600-700 . , 600 — , . , , . 800 , , — .

, , . 0 , - , ! .

, - . — , .

99- 50- , . , .

, — , DevOps — .

, , .

Value stream mapping — . , . , , , , , . , , .

:

1. MTTD (mean time to discovery) — , .
2. MTTR (mean time to recovery) — , .
3. , .
4. / .

, , , , . : « — . , , ».

, , . , .

. , — , , . , . .

— , , . , , , . — .

1 2 , DevOpsConf Russia .

DevOps, , , . , , .

, , .