डेवलपर्स

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

डेवलपर्स के लिए ऑब्ज़र्वेबिलिटी क्यों महत्वपूर्ण है

डेवलपर्स कई प्रमुख उद्देश्यों के लिए ऑब्ज़र्वेबिलिटी का उपयोग करते हैं:

• तेज समस्या पहचान और समाधान:
  • ऑब्ज़र्वेबिलिटी डेवलपर्स को समस्याओं की तेजी से पहचान और निदान करने की अनुमति देती है, जिससे समस्याओं को हल करने का समय (MTTR) कम होता है और समग्र सॉफ्टवेयर डिलीवरी प्रदर्शन में सुधार होता है
  • यह डेवलपर्स को समझने में मदद करती है कि उनके सिस्टम प्रोडक्शन में कैसे व्यवहार करते हैं, जिससे वे सूचित निर्णय ले सकें और संचालन में सुधार कर सकें
• ग्राहक अनुभव में सुधार:
  • सिस्टम व्यवहार का एनालिसिस करके, डेवलपर्स प्रदर्शन और विश्वसनीयता को ऑप्टिमाइज कर सकते हैं, जिससे बेहतर ग्राहक अनुभव और बढ़ी हुई उपयोगकर्ता संतुष्टि होती है
  • ऑब्ज़र्वेबिलिटी टूल्स उपयोगकर्ता इंटरैक्शन की मॉनिटरिंग में मदद करते हैं, जिससे डेवलपर्स UI/UX समस्याओं की तुरंत पहचान और समाधान कर सकते हैं
• बेहतर टीम दक्षता और नवाचार:
  • ऑब्ज़र्वेबिलिटी प्लेटफॉर्म ऑपरेशनल डेटा के लिए एक एक स्रोत प्रदान करते हैं, जो क्रॉस-टीम सहयोग को सुविधाजनक बनाते हैं और समस्या निवारण समय को कम करते हैं
  • स्वचालित अंतर्दृष्टि और अलर्ट की बदौलत डेवलपर्स मैन्युअल डीबगिंग पर कम और नवाचार पर अधिक ध्यान केंद्रित कर सकते हैं
• डेटा-ड्रिवन निर्णय लेना:
  • ऑब्ज़र्वेबिलिटी सिस्टम प्रदर्शन में विस्तृत अंतर्दृष्टि प्रदान करती है, जो डेवलपर्स को कोड सुधार और रिसोर्स आवंटन के बारे में डेटा-ड्रिवन निर्णय लेने में सक्षम बनाती है
  • यह ऑर्गनाइज़ेशन्स को सुधार के क्षेत्रों की पहचान करके निवेश को ऑप्टिमाइज करने और बाजार में पहुंचने के समय को तेज करने में मदद करती है
• जटिलता प्रबंधन:
  • ऑब्ज़र्वेबिलिटी सिस्टम अन्योन्याश्रयताओं का व्यापक दृश्य प्रदान करके आधुनिक क्लाउड-नेटिव और मल्टी-क्लाउड एनवायरनमेंट की जटिलता को प्रबंधित करने में मदद करती है
  • यह डेवलपर्स को जटिलता को सरल बनाने और प्रासंगिक डेटा पर ध्यान केंद्रित करने की अनुमति देती है, जो अधिक कुशल डेवलपमेंट प्रक्रियाओं को बढ़ावा देती है

कोड गुणवत्ता के लिए बेस्ट प्रैक्टिसेज़

• Issue Tracking मेट्रिक्स की मॉनिटरिंग करें:

  • JIRA या Trello या अन्य issue tracking प्लेटफॉर्म जैसे टूल्स का उपयोग करके मेट्रिक्स ट्रैक करें जैसे:
    • एक टिकट कितनी बार code review से test review और वापस in progress में जाता है। अधिक संख्या कौशल की कमी, उच्च जटिलता, या अपर्याप्त टूलिंग का संकेत दे सकती है।
    • एक टिकट कितनी बार बाहरी निर्भरताओं के कारण ब्लॉक होता है। अधिक संख्या निर्भरताओं के बीच उच्च कपलिंग और/या उच्च जटिलता का संकेत दे सकती है।
  • अनुशंसाएं:
    • स्वचालित कोड रिव्यू के साथ उत्पादकता और कोड गुणवत्ता बढ़ाने के लिए Amazon Q Developer जैसे टूल का उपयोग करें। Amazon Q Developer सॉफ्टवेयर डेवलपमेंट कार्यों को 80% तक तेज कर सकता है, तेज डेवलपमेंट चक्रों के दौरान मानवीय त्रुटि की संभावना को कम करके उच्च-गुणवत्ता वाले कोड में योगदान करता है।
    • सुधारों की पहचान करने और निरंतर सुधार की मानसिकता को बढ़ावा देने के लिए रेट्रोस्पेक्टिव के हिस्से के रूप में मेट्रिक्स की नियमित समीक्षा शेड्यूल करें

• प्रदर्शन मेट्रिक्स के लिए कोड इंस्ट्रूमेंट करें:

  • अपने कोड को इंस्ट्रूमेंट करें ताकि निम्नलिखित को मापा जा सके जो कोड कार्यान्वयन की प्रदर्शन दक्षता और स्केलेबिलिटी का आकलन करके कोड गुणवत्ता का अप्रत्यक्ष माप प्रदान करते हैं
    • RED Method: माइक्रोसर्विसेज के लिए Requests, Errors, और Duration की मॉनिटरिंग करें। यह सर्विस प्रदर्शन और विश्वसनीयता में अंतर्दृष्टि प्रदान करता है।
    • USE Method: सिस्टम रिसोर्स के लिए Utilization, Saturation, और Errors ट्रैक करें। यह बॉटलनेक और रिसोर्स बाधाओं की पहचान करने में मदद करता है।
  • अनुरोध प्रसंस्करण पथ में सभी बाहरी निर्भरताओं जैसे अन्य सेवाओं, डेटाबेस, कैश आदि के कॉल के आसपास इंस्ट्रूमेंटेशन जोड़ें। यह आपको अनुरोध प्रसंस्करण समय में अचानक परिवर्तनों की जांच करने के लिए आवश्यक जानकारी प्रदान कर सकता है साथ ही समस्या के मूल कारण की तेज पहचान को सक्षम बना सकता है
  • अनुशंसाएं:
    • अनुरोध लेटेंसी और एरर रेट पर एक SLO (Service Level Objective) सेट करें और बेहतर गुणवत्ता और प्रदर्शन के लिए सुधार चलाने के लिए इसका उपयोग करें
    • महत्वपूर्ण डेटा प्रवाह और अनुरोध प्रसंस्करण पथों का अभ्यास करने वाले स्वचालित परीक्षणों में इंस्ट्रूमेंटेशन की मान्यता जोड़ें
    • सिस्टम प्रदर्शन और कोड गुणवत्ता माप का बेसलाइन बनाने के लिए एक स्वचालित लोड टेस्ट कार्य बनाएं
    • सुनिश्चित करें कि इंस्ट्रूमेंटेशन में एक अनुरोध के प्रदर्शन प्रभाव की पहचान करने में सक्षम होने के लिए संदर्भ जोड़ा गया है
    • मैन्युअल कार्य को कम करने के लिए SDK द्वारा प्रदान किए गए ऑटो-इंस्ट्रूमेंटेशन को कॉन्फ़िगर और उपयोग करें

कुशल लॉगिंग और मॉनिटरिंग

• स्ट्रक्चर्ड लॉग फॉर्मेट का उपयोग करें जैसे json। मौजूदा एप्लिकेशन के लिए, अधिक संदर्भ इंजेक्ट करने, फील्ड जोड़ने या हटाने के लिए लॉग ट्रांसफॉर्मेशन सुविधाओं का उपयोग करने पर विचार करें
• सार्थक सिग्नल निकालने और सिग्नलों में क्रॉस कोरिलेशन करने में सक्षम होने के लिए पर्याप्त मेटाडेटा युक्त वाइड इवेंट फॉर्मेट का उपयोग करें।
• OpenTelemetry या ADOT SDK का उपयोग करें जो लॉग्स में अतिरिक्त संदर्भ इंजेक्ट करते हैं जो क्रॉस सिग्नल कोरिलेशन और Mean Time To Identify(MTTI) में कमी को सक्षम बनाते हैं इसलिए Mean Time To Recover(MTTR) को कम करते हैं
• लॉग लेवल का उचित उपयोग करें - ये आपको लॉग्स की मात्रा और इसलिए इंजेशन की लागत को नियंत्रित करने में मदद कर सकते हैं।
  • किसी भी अप्रत्याशित और अपेक्षित एरर स्थितियों के लिए ERROR का उपयोग करें। मूल कारण एनालिसिस को तेज करने में सक्षम होने के लिए अधिक से अधिक अतिरिक्त संदर्भ जोड़ें।
  • सामान्य रन टाइम इवेंट जैसे उपयोगकर्ता लॉगिन के लिए INFO का उपयोग करें, जो संदर्भ प्रदान कर सकते हैं और महत्वपूर्ण हैं
  • एप्लिकेशन के प्रवाह और स्थितियों की गहरी समझ प्राप्त करने के लिए प्रसंस्करण पथ में कॉल को लॉग करने के लिए DEBUG का उपयोग करें।
• किसी भी ऐसे डेटा को लॉग करने से बचें जो संवेदनशील माना जा सकता है जैसे PII या PHI। जहां आवश्यकता मौजूद है, डेटा प्रोटेक्शन पॉलिसी का उपयोग करने या इंजेशन पर डेटा को रिडैक्ट करने पर विचार करें। कच्चे डेटा को कौन देख सकता है इसे नियंत्रित करने के लिए IAM पॉलिसी का उपयोग करें।
• लॉग के भीतर मेट्रिक्स एम्बेड करने के लिए embedded metric format(EMF) का उपयोग करें, जो ऑब्ज़र्वेबिलिटी प्लेटफॉर्म पर API कॉल की संख्या को कम करता है, लागत कम करता है।
  • requestId जैसे उच्च कार्डिनैलिटी डाइमेंशन वाले मेट्रिक्स के लिए EMF का उपयोग करने से बचें
• अलर्ट:
  • अलर्ट के लिए कठोर थ्रेशहोल्ड सेट करने से बचने के लिए एनोमली डिटेक्शन का उपयोग करें। यह सिस्टम उपयोग समय के साथ बदलने पर थ्रेशहोल्ड अपडेट करने के ओवरहेड से बच सकता है और अलर्ट शोर को कम कर सकता है।
  • किसी विशेष विफलता के लिए उत्पन्न व्यक्तिगत अलर्ट की संख्या को कम करने के लिए metric math और combination alerts का उपयोग करें।
  • केवल तब अलर्ट करें जब कोई SLO जोखिम में हो/विफल हो रहा हो। यह आपकी टीम को अनावश्यक रूप से जगाए जाने से बचा सकता है और संज्ञानात्मक और संदर्भ अधिभार को कम कर सकता है
  • केवल तब अलर्ट करें जब कोई विफलता की सूचना पर कार्रवाई कर सके
  • जहां संभव हो अलर्ट का समाधान स्वचालित करें। उदाहरण के लिए, ऑटोस्केलिंग, रेप्लिका या स्टैंडबाय इंस्टेंस में ऑटोमैटिक फेलओवर आदि जैसे नेटिव प्लेटफॉर्म कॉन्फ़िगरेशन का लाभ उठाएं।
  • अलर्ट नोटिफिकेशन में पर्याप्त संदर्भ जोड़ें ताकि सूचित व्यक्ति जल्दी से पहचान सके कि कौन से डैशबोर्ड देखने हैं, कौन सी playbook उपयोग करनी है और कौन सी सेवा प्रभावित है
• डैशबोर्ड:
  • प्रति पर्सोना/स्टेकहोल्डर एक या अधिक डैशबोर्ड बनाएं।
    • एप्लिकेशन डेवलपर्स को समस्याओं का निदान करने, एप्लिकेशन के प्रदर्शन को समझने के लिए पर्याप्त संदर्भ की आवश्यकता होगी
    • प्लेटफॉर्म इंजीनियरों को SLO पर प्रभाव और ध्यान देने योग्य इंफ्रास्ट्रक्चर कंपोनेंट और उनके सेवाओं पर प्रभाव की पहचान करने के संदर्भ वाले डैशबोर्ड की आवश्यकता होगी
    • प्रोडक्ट मैनेजरों को उपयोगकर्ता यात्रा, प्रोडक्ट फीचर उपयोग मेट्रिक्स, अपनाने की दरें, छोड़ने के बिंदु आदि दिखाने वाले डैशबोर्ड की आवश्यकता होगी
    • व्यावसायिक स्टेकहोल्डर उत्पाद अपनाने की दरों, सब्सक्राइबर गिरावट या ऐसी किसी चीज को प्रदर्शित करने वाले विजेट में रुचि रखते होंगे जो व्यावसायिक प्रदर्शन और राजस्व को प्रभावित करने से संबंधित हो सकती है
  • सभी डैशबोर्ड में एक सुसंगत टाइमज़ोन का उपयोग करें जैसे UTC
  • डैशबोर्ड पर सभी विजेट में समान समय सीमा का उपयोग करें
  • डैशबोर्ड में अधिक संदर्भ जोड़ने के लिए एनोटेशन का उपयोग करें
  • सुनिश्चित करें कि केवल वे विजेट जो एरर रिज़ॉल्यूशन में सहायता के लिए संदर्भ जोड़ते हैं, डैशबोर्ड पर हों। बहुत अधिक विजेट शोर और संज्ञानात्मक अधिभार जोड़ सकते हैं, जो उच्च MTTR की ओर ले जाता है
    • अन्य nice to have विजेट को दूसरे डैशबोर्ड पर या डैशबोर्ड के नीचे ले जाएं यदि पहले से बहुत अधिक विजेट नहीं हैं। बहुत अधिक विजेट लोड समय को प्रभावित करेंगे और अधिक तनाव और संज्ञानात्मक अधिभार में परिणत होंगे।
  • सुनिश्चित करें कि पूरा डैशबोर्ड एक ही स्क्रीन पर फिट हो और लैपटॉप के रिज़ॉल्यूशन और स्क्रीन साइज के साथ ट्रेंड दिखाई दें
  • डैशबोर्ड के विवरण और डैशबोर्ड का उपयोग कैसे करें इसके मार्गदर्शन के साथ एक विजेट रखें
  • विजेट पर थ्रेशहोल्ड कॉन्फ़िगर और प्रदर्शित करें
  • एक ही विजेट में अधिक मेट्रिक्स न भरें जो ट्रेंड और स्पाइक को स्मूथ कर सकता है और उद्देश्य को विफल कर सकता है। यह निदान को भी कठिन बनाता है।
  • ट्रेंड और स्पाइक को दृश्यमान बनाने के लिए डायनामिक रूप से समायोजित Y-axis का उपयोग करें
• अनुशंसाएं:
  • लागत नियंत्रित करना:
    • स्टेकहोल्डर की पहचान करें:
      • फीचर प्रदर्शन में रुचि रखने वाले विभिन्न पर्सोना निर्धारित करें, जैसे कार्यक्षमता, उपलब्धता, सुरक्षा, लागत, बिक्री और उत्पाद उपयोग।
      • स्टेकहोल्डर में डेवलपमेंट टीमें, अंतिम ग्राहक, आंतरिक व्यावसायिक स्टेकहोल्डर, प्लेटफॉर्म ऑपरेशंस टीमें, या एप्लिकेशन डेवलपर्स शामिल हो सकते हैं।
    • प्रमुख परिणामों की पहचान करें:
      • प्रत्येक स्टेकहोल्डर के लिए, मात्रात्मक परिणाम परिभाषित करें (जैसे, एरर रेट, अनुरोध प्रसंस्करण अवधि, प्रति मिनट लॉगिन की संख्या, प्रति मिनट खरीदे गए उत्पादों की संख्या, छोड़े गए कार्ट की संख्या, आदि) जो आमतौर पर Service Level Objectives (SLOs) का उपयोग करके मापे जाते हैं।
      • आवश्यक इंस्ट्रूमेंटेशन की पहचान करने के लिए प्रति पर्सोना इन SLO का उपयोग करें
    • सही सिग्नल चुनें:
      • पर्याप्त संदर्भ वाला एक वाइड लॉग मेट्रिक्स और ट्रेस में परिवर्तित किया जा सकता है जो एक सत्य का स्रोत देता है, लागत नियंत्रित करता है और सिग्नल कोरिलेशन को सक्षम बनाता है
      • एप्लिकेशन में इंस्ट्रूमेंट किए जाने वाले सही सिग्नलों की पहचान करने के लिए एक ऑब्ज़र्वेबिलिटी Strategy Workshop चलाएं
  • सही सिग्नल चुनें:
    • लॉग्स और ट्रेस आपको विफलता या अप्रत्याशित व्यवहार के मूल कारण को खोजने में मदद करते हैं। ऐसे लॉग्स जोड़ना सुनिश्चित करें जो "एक विशेष अनुरोध क्यों विफल हुआ?" या "अनुरोध प्रसंस्करण समय के p50 या p99 में वृद्धि होने पर अनुरोध अवधि से संबंधित SLO के लिए मुझे क्या जानना होगा?" जैसे प्रश्नों का उत्तर दे सकें
    • मेट्रिक्स बेसलाइन प्रदर्शन, ट्रेंड और विसंगतियों को समझने के लिए अच्छे हैं। वे आपको सक्रिय रूप से कुछ अपेक्षित रूप से काम न करने का संकेत दे सकते हैं। कस्टम मेट्रिक्स हालांकि महंगे हैं।
  • अलर्ट थकान कम करें:
    • कॉन्फ़िगरेशन के आधार पर, अलर्ट सक्रिय या प्रतिक्रियात्मक रूप से सिस्टम में किसी समस्या को उजागर कर सकते हैं। बहुत अधिक अलर्ट अलर्ट थकान और अक्षम टीमों की ओर ले जा सकते हैं, जिससे खराब कोड गुणवत्ता और उत्पाद डिलीवरी होती है।
  • समय-समय पर समीक्षा और निरंतर सुधार:
    • डैशबोर्ड की मॉनिटरिंग करने और पहचाने गए किसी भी नए ट्रेंड या पैटर्न की रिपोर्ट करने के लिए टीम पर एक सदस्य के लिए समय-समय पर रोस्टर रखें।
    • रेट्रोस्पेक्टिव और रोस्टर अवलोकनों के दौरान पहचाने गए अंतराल के आधार पर सिग्नल में सुधार, अलर्ट थ्रेशहोल्ड और डैशबोर्ड को ट्वीक करने के लिए प्रत्येक रिलीज का एक हिस्सा आवंटित करें
    • हल करने के प्रयास और अलर्ट ट्रिगर होने की संख्या के आधार पर आवर्ती अलर्ट के मूल कारण को ठीक करने को प्राथमिकता दें

प्रोफाइलिंग और प्रदर्शन ऑप्टिमाइज़ेशन

• Real User Monitoring(RUM):
  • वास्तविक उपयोगकर्ता इंटरैक्शन की मॉनिटरिंग और प्रदर्शन बॉटलनेक की पहचान करने के लिए AWS X-Ray या New Relic जैसे टूल्स का उपयोग करें। प्रमुख रूपांतरण बिंदुओं पर ध्यान दें और तकनीकी प्रदर्शन के साथ-साथ व्यावसायिक परिणामों (रूपांतरण दर, छोड़ने के बिंदु) दोनों को मापें।
  • चेकआउट फ्लो और पंजीकरण प्रक्रियाओं जैसे महत्वपूर्ण उपयोगकर्ता पथों की मॉनिटरिंग को प्राथमिकता दें।
  • विसंगतियों और ट्रेंड की तेजी से पहचान करने में सक्षम होने के लिए बेसलाइन प्रदर्शन और उपयोगकर्ता व्यवहार स्थापित करें जो व्यावसायिक परिणामों को प्रभावित कर सकते हैं
• Synthetics:
  • उपयोगकर्ता इंटरैक्शन का अनुकरण करने और विभिन्न परिस्थितियों में एप्लिकेशन प्रदर्शन का परीक्षण करने के लिए Amazon Cloudwatch Synthetics जैसे टूल्स का उपयोग करें। Synthetic canaries उपयोगकर्ता प्रभाव का पता लगने से पहले समस्याओं की पहचान करने में मदद कर सकते हैं।
  • Synthetic canaries के साथ हेल्थ चेक और सिस्टम अपटाइम को मान्य करें।
• प्रोफाइलिंग टूल्स:
  • प्रदर्शन बॉटलनेक की पहचान करने और रिसोर्स उपयोग को ऑप्टिमाइज करने के लिए प्रोफाइलिंग के लिए AWS X-Ray जैसे टूल्स का उपयोग करें
  • डायनामिक सैंपलिंग रेट सेट करें जो ट्रैफिक पैटर्न के आधार पर समायोजित हो और एरर ट्रेस और आउटलायर्स का पर्याप्त रिटेंशन बनाए रखें। यह डेटा वॉल्यूम और लागत को प्रबंधित करते हुए महत्वपूर्ण समस्याओं में व्यापक विजिबिलिटी सुनिश्चित करता है।
  • ट्रेस सैंपल किए जाने वालों में सबसे अधिक मूल्य वाले ट्रेस शामिल हों यह सुनिश्चित करने के लिए एरर स्टेटस, ड्यूरेशन थ्रेशहोल्ड और कस्टम एट्रिब्यूट के आधार पर उच्च-मूल्य ट्रेस को प्राथमिकता देने वाली कई सैंपलिंग पॉलिसी के साथ अपने कलेक्टर को कॉन्फ़िगर करने के लिए tail sampling का उपयोग करें
• OpenTelemetry:
  • प्रदर्शन मेट्रिक्स और ट्रेस के संग्रह को सरल बनाने के लिए ऑटो-इंस्ट्रूमेंटेशन के लिए OpenTelemetry का उपयोग करें। मैन्युअल इंस्ट्रूमेंटेशन जोड़ने से पहले ऑटो इंस्ट्रूमेंटेशन द्वारा प्रदान की गई टेलीमेट्री को मान्य करें और फिर सिग्नल और लागत को नियंत्रित करने के लिए आवश्यकताओं के आधार पर ऑटो इंस्ट्रूमेंटेशन को ट्यून करें।

एरर हैंडलिंग और डीबगिंग तकनीकें

• सामान्य:
  • क्षणिक विफलताओं के लिए exponential backoff के साथ रिट्राई मेकेनिज्म डिज़ाइन करें। बाहरी निर्भरताओं के लिए circuit breakers लागू करें। यह डिस्ट्रीब्यूटेड सिस्टम में विशेष रूप से सहायक है और डाउनस्ट्रीम कंपोनेंट/सेवा पर अत्यधिक लोड को रोकता है। यह सभी परिदृश्यों में लागू नहीं हो सकता है इसलिए इस डिज़ाइन को अपनाने से पहले उचित सावधानी बरतें।
  • महत्वपूर्ण संचालन के लिए फॉलबैक मेकेनिज्म बनाएं और विफल ट्रांजैक्शन के लिए स्पष्ट रोलबैक प्रक्रियाएं बनाए रखें।
  • सभी एंट्री पॉइंट पर इनपुट वैलिडेशन जोड़ें।
  • सुनिश्चित करें कि रिट्राई करने योग्य ऑपरेशन idempotent हैं।
• लॉगिंग:
  • सेव किए गए Cloudwatch Log Insights क्वेरीज का एक रिपॉजिटरी बनाए रखें। क्वेरीज को ग्रुप करने के लिए फोल्डर का उपयोग करें
  • एरर को शांत न करें। हमेशा लॉग करें या उचित रूप से हैंडल करें।
  • किसी भी अन्य प्रासंगिक संदर्भ के अलावा लॉग्स में correlation id या request id जैसी पहचान का एक रूप जोड़ें।
• Playbooks और runbooks:
  • Playbooks लिखते समय, आवश्यक अनुमतियों, टूल्स और अपेक्षित परिणामों के साथ स्पष्ट कार्रवाई योग्य चरण शामिल करें।
  • Playbooks और run books में सत्यापन चरण, रोलबैक प्रक्रियाएं और प्रासंगिक डैशबोर्ड के लिंक शामिल करें।
  • Playbooks को वर्शन करें और सीखे गए पाठों और प्रमुख अंतर्दृष्टि सहित घटनाओं के बाद अपडेट करें।
• सैंपलिंग नियमों को ट्यून करना:
  • सेवा महत्वपूर्णता और ट्रैफिक पैटर्न के आधार पर डायनामिक सैंपलिंग नियम लागू करें।
  • एरर स्थितियों और व्यवसाय-महत्वपूर्ण पथों के लिए उच्च सैंपलिंग दर सेट करें।
  • परिचालन आवश्यकताओं और लागत विचारों के आधार पर नियमित रूप से सैंपलिंग नियमों की समीक्षा और समायोजन करें।

कोड रिव्यू और सहयोग नीतियां

• टिकट विस्तार:
  • फीचर विस्तार प्रक्रिया के हिस्से के रूप में ऑब्ज़र्वेबिलिटी आवश्यकताओं की पहचान करें। इसमें शामिल हो सकते हैं
    • प्रभावित स्टेकहोल्डर और संबंधित SLO
    • आवश्यक टेलीमेट्री/सिग्नल
    • आवश्यक अलर्ट
    • बनाए या अपडेट किए जाने वाले डैशबोर्ड की सूची
• दोषरहित रेट्रोस्पेक्टिव:
  • प्रत्येक घटना के बाद, प्रक्रियाओं में सुधार या स्वचालन जोड़ने के अवसरों की तलाश के लिए एक दोषरहित रेट्रोस्पेक्टिव आयोजित करें। हमेशा परिवर्तन की लागत को ध्यान में रखें और सुनिश्चित करें कि आप प्रत्येक पोस्ट मॉर्टम अभ्यास से कम से कम एक सहमत कार्रवाई योग्य आइटम के साथ बाहर आएं जिसके साथ पूरा करने की समयसीमा भी जुड़ी हो।
• Operational Readiness Reviews:
  • ऑब्ज़र्वेबिलिटी स्थिति में अंतराल की पहचान करने के लिए प्लेटफॉर्म और ऑपरेशंस टीम के साथ operational readiness reviews में भाग लें - यह एक चेकलिस्ट और प्रोडक्शन में डिप्लॉयमेंट से पहले एक अनिवार्य अभ्यास हो सकता है। कई टीमों वाले बड़े ऑर्गनाइज़ेशन्स के लिए, इस प्रक्रिया को बॉटलनेक बनने से बचाने के लिए, प्रत्येक नई फीचर और रिलीज़ केडेंस के लिए समय-समय पर इन्हें आयोजित करें।
• अनुशंसाएं:
  • पोस्ट-इंसिडेंट एनालिसिस के माध्यम से आपका मार्गदर्शन करने में मदद के लिए AWS Systems Manager Incident Manager जैसे टूल का उपयोग करें
  • अपनी operational readiness review चेकलिस्ट या प्रक्रिया में शामिल करने के लिए प्रश्नों की प्रेरणा के लिए Operational Readiness Review देखें।
  • हमेशा रेट्रोस्पेक्टिव, operational readiness reviews से सीखे गए पाठ साझा करें - यह विकी या मेल ग्रुप सब्सक्रिप्शन के माध्यम से हो सकता है

API डिज़ाइन और डॉक्यूमेंटेशन दिशानिर्देश

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