டெவலப்பர்கள்

Observability டெவலப்பர்களுக்கு முக்கியமானது, ஏனெனில் இது உற்பத்தித்திறனை மேம்படுத்துகிறது, பயன்பாட்டு செயல்திறனை மேம்படுத்துகிறது, மற்றும் சிறந்த முடிவெடுத்தல் மற்றும் விரைவான சிக்கல் தீர்வு மூலம் வணிக வெற்றியை உந்துகிறது. இந்த வழிகாட்டி observability-ஐ பயனுள்ள முறையில் பயன்படுத்துவதற்கான சிறந்த நடைமுறைகள் மற்றும் பரிந்துரைகளை வழங்குகிறது.

டெவலப்பர்களுக்கு Observability ஏன் முக்கியமானது

டெவலப்பர்கள் பல முக்கிய நோக்கங்களுக்காக observability-ஐ பயன்படுத்துகின்றனர்:

• விரைவான சிக்கல் அடையாளம் மற்றும் தீர்வு:
  • Observability டெவலப்பர்களுக்கு சிக்கல்களை விரைவாக அடையாளம் கண்டு கண்டறிய அனுமதிக்கிறது, சிக்கல்களை தீர்க்கும் நேரத்தை (MTTR) குறைக்கிறது மற்றும் ஒட்டுமொத்த மென்பொருள் விநியோக செயல்திறனை மேம்படுத்துகிறது
  • தங்கள் கணினிகள் production-இல் எவ்வாறு நடந்துகொள்கின்றன என்பதைப் புரிந்துகொள்ள இது டெவலப்பர்களுக்கு உதவுகிறது, தகவலறிந்த முடிவுகளை எடுக்கவும் செயல்பாடுகளை மேம்படுத்தவும் அனுமதிக்கிறது
• வாடிக்கையாளர் அனுபவத்தை மேம்படுத்துதல்:
  • கணினி நடத்தையை பகுப்பாய்வு செய்வதன் மூலம், டெவலப்பர்கள் செயல்திறன் மற்றும் நம்பகத்தன்மையை மேம்படுத்தலாம், சிறந்த வாடிக்கையாளர் அனுபவங்கள் மற்றும் அதிகரித்த பயனர் திருப்திக்கு வழிவகுக்கிறது
  • Observability கருவிகள் பயனர் ஊடாடல்களை கண்காணிக்க உதவுகின்றன, UI/UX சிக்கல்களை உடனடியாக அடையாளம் கண்டு நிவர்த்தி செய்ய டெவலப்பர்களை அனுமதிக்கிறது
• மேம்படுத்தப்பட்ட குழு திறன் மற்றும் புதுமை:
  • Observability தளங்கள் செயல்பாட்டுத் தரவுக்கான ஒற்றை உண்மை ஆதாரத்தை வழங்குகின்றன, குழுக்களுக்கு இடையிலான ஒத்துழைப்பை எளிதாக்குகின்றன மற்றும் சிக்கல்தீர்ப்பு நேரத்தை குறைக்கின்றன
  • தானியங்கு நுண்ணறிவுகள் மற்றும் எச்சரிக்கைகளுக்கு நன்றி, டெவலப்பர்கள் கைமுறை பிழைத்திருத்தத்தில் குறைவாகவும் புதுமையில் அதிகமாகவும் கவனம் செலுத்தலாம்
• தரவு சார்ந்த முடிவெடுத்தல்:
  • Observability கணினி செயல்திறனில் விரிவான நுண்ணறிவுகளை வழங்குகிறது, குறியீடு மேம்பாடுகள் மற்றும் வள ஒதுக்கீடு பற்றிய தரவு சார்ந்த முடிவுகளை எடுக்க டெவலப்பர்களை இயலுமாக்குகிறது
  • மேம்பாட்டிற்கான பகுதிகளை அடையாளம் காண்பதன் மூலம் முதலீடுகளை மேம்படுத்தவும் சந்தைக்கான நேரத்தை விரைவுபடுத்தவும் அமைப்புகளுக்கு இது உதவுகிறது
• சிக்கலான தன்மை மேலாண்மை:
  • நவீன cloud-native மற்றும் multi-cloud சூழல்களின் சிக்கலான தன்மையை நிர்வகிக்க கணினி ஊடாடல்களின் விரிவான காட்சியை வழங்குவதன் மூலம் observability உதவுகிறது
  • சிக்கலான தன்மையை வடிகட்டி தொடர்புடைய தரவில் கவனம் செலுத்த இது டெவலப்பர்களை அனுமதிக்கிறது, அதிக திறமையான மேம்பாட்டு செயல்முறைகளை ஊக்குவிக்கிறது

குறியீடு தரத்திற்கான சிறந்த நடைமுறைகள்

• சிக்கல் கண்காணிப்பு மெட்ரிக்குகளை கண்காணிக்கவும்:

  • JIRA அல்லது Trello அல்லது பிற சிக்கல் கண்காணிப்பு தளங்கள் போன்ற கருவிகளைப் பயன்படுத்தி பின்வரும் மெட்ரிக்குகளைக் கண்காணிக்கவும்:
    • ஒரு ticket code review-இலிருந்து test review-க்கும் மீண்டும் in progress-க்கும் எத்தனை முறை நகர்கிறது. அதிக எண்ணிக்கை திறன் குறைபாடு, அதிக சிக்கலான தன்மை அல்லது போதுமான கருவிகள் இல்லாததைக் குறிக்கலாம்.
    • வெளிப்புற சார்புகளால் ஒரு ticket எத்தனை முறை தடுக்கப்படுகிறது. அதிக எண்ணிக்கை சார்புகளுக்கு இடையிலான அதிக இணைப்பு மற்றும்/அல்லது அதிக சிக்கலான தன்மையைக் குறிக்கலாம்.
  • பரிந்துரைகள்:
    • தானியங்கு code reviews மூலம் உற்பத்தித்திறன் மற்றும் குறியீடு தரத்தை உயர்த்த Amazon Q Developer போன்ற கருவியைப் பயன்படுத்தவும். Amazon Q Developer மென்பொருள் மேம்பாட்டு பணிகளை 80% வரை விரைவுபடுத்தலாம், விரைவான மேம்பாட்டு சுழற்சிகளின் போது மனித பிழையின் சாத்தியத்தை குறைப்பதன் மூலம் உயர்-தர குறியீட்டிற்கு பங்களிக்கிறது.
    • மேம்பாடுகளை அடையாளம் காணவும் தொடர்ச்சியான மேம்பாட்டின் மனநிலையை வளர்க்கவும் retrospectives-இன் ஒரு பகுதியாக மெட்ரிக்குகளின் வழக்கமான மதிப்பாய்வுகளை திட்டமிடுங்கள்

• செயல்திறன் மெட்ரிக்குகளுக்காக குறியீட்டை இன்ஸ்ட்ரூமெண்ட் செய்யுங்கள்:

  • குறியீடு செயல்படுத்தலின் செயல்திறன் திறன் மற்றும் அளவிடுதல் திறனை மதிப்பிடுவதன் மூலம் குறியீடு தரத்தின் மறைமுக அளவீட்டை வழங்கும் பின்வருவனவற்றை அளவிட உங்கள் குறியீட்டை இன்ஸ்ட்ரூமெண்ட் செய்யுங்கள்
    • RED Method: மைக்ரோசர்வீஸ்களுக்கான Requests, Errors மற்றும் Duration-ஐ கண்காணிக்கவும். இது சேவை செயல்திறன் மற்றும் நம்பகத்தன்மையில் நுண்ணறிவுகளை வழங்குகிறது.
    • USE Method: கணினி வளங்களுக்கான Utilization, Saturation மற்றும் Errors-ஐ கண்காணிக்கவும். இது தடைகள் மற்றும் வள கட்டுப்பாடுகளை அடையாளம் காண உதவுகிறது.
  • கோரிக்கை செயலாக்க பாதையில் உள்ள அனைத்து வெளிப்புற சார்புகளுக்கான அழைப்புகளைச் சுற்றி இன்ஸ்ட்ரூமெண்டேஷன் சேர்க்கவும், பிற சேவைகள், தரவுத்தளம், cache போன்றவை. இது கோரிக்கை செயலாக்க நேரத்தில் திடீர் மாற்றங்களை ஆராயவும் சிக்கலின் மூல காரணத்தை விரைவாக அடையாளம் காணவும் தேவையான தகவல்களை வழங்கலாம்
  • பரிந்துரைகள்:
    • கோரிக்கை தாமதம் மற்றும் பிழை விகிதத்தில் SLO(Service Level Objective)-ஐ அமைத்து சிறந்த தரம் மற்றும் செயல்திறனுக்கான மேம்பாடுகளை உந்த அதைப் பயன்படுத்தவும்
    • முக்கியமான தரவு ஓட்டம் மற்றும் கோரிக்கை செயலாக்க பாதைகளை செயல்படுத்தும் தானியங்கு சோதனைகளுக்கு இன்ஸ்ட்ரூமெண்டேஷன் validation-ஐ சேர்க்கவும்
    • கணினி செயல்திறன் மற்றும் குறியீடு தர அளவீட்டின் அடிப்படையை உருவாக்க தானியங்கு load test பணியை கட்டியெழுப்புங்கள்
    • ஒற்றை கோரிக்கையின் செயல்திறன் தாக்கத்தை அடையாளம் காண இன்ஸ்ட்ரூமெண்டேஷனில் context சேர்க்கப்பட்டிருப்பதை உறுதிப்படுத்தவும்
    • இன்ஸ்ட்ரூமெண்டேஷன் சேர்ப்பதில் உள்ள கைமுறை வேலையை குறைக்க SDKs வழங்கும் auto-instrumentation-ஐ கட்டமைத்து பயன்படுத்தவும்

திறமையான logging மற்றும் கண்காணிப்பு

• json போன்ற structured log formats பயன்படுத்தவும். ஏற்கனவே உள்ள பயன்பாடுகளுக்கு, மேலும் context செலுத்தவும், fields சேர்க்கவும் அல்லது நீக்கவும் log transformation features-ஐ பயன்படுத்துவதை கருத்தில் கொள்ளுங்கள்
• அர்த்தமுள்ள சிக்னல்களைப் பெறவும் சிக்னல்கள் முழுவதும் cross correlate செய்யவும் போதுமான metadata கொண்ட wide event format பயன்படுத்தவும்.
• Cross signal correlation மற்றும் Mean Time To Identify(MTTI) குறைப்பை இயக்கும் logs-இல் கூடுதல் context-ஐ செலுத்தும் OpenTelemetry அல்லது ADOT SDKs பயன்படுத்தவும், இதன் மூலம் Mean Time To Recover(MTTR)-ஐ குறைக்கவும்
• Log levels-ஐ சரியாக பயன்படுத்தவும் - இவை logs-இன் அளவையும் எனவே ingestion செலவையும் கட்டுப்படுத்த உதவும்.
  • எந்த எதிர்பாராத மற்றும் எதிர்பார்க்கப்பட்ட பிழை நிலைமைகளுக்கும் ERROR பயன்படுத்தவும். மூல காரண பகுப்பாய்வை விரைவுபடுத்த முடிந்தவரை கூடுதல் context சேர்க்கவும்.
  • பயனர் login போன்ற பொதுவான run time events-க்கு INFO பயன்படுத்தவும், இவை context வழங்கக்கூடியவை மற்றும் முக்கியமானவை
  • பயன்பாட்டின் ஓட்டம் மற்றும் நிலைகளைப் பற்றிய ஆழமான புரிதலைப் பெற செயலாக்க பாதையில் உள்ள அழைப்புகளை logging செய்ய DEBUG பயன்படுத்தவும்.
• PII அல்லது PHI போன்ற முக்கியமானதாக கருதப்படும் தரவை logging செய்வதைத் தவிர்க்கவும். தேவை இருக்கும் இடத்தில், data protection policy பயன்படுத்துவதை அல்லது ingestion-இல் தரவை redact செய்வதை கருத்தில் கொள்ளுங்கள். raw தரவை யார் பார்க்கலாம் என்பதை கட்டுப்படுத்த IAM policies பயன்படுத்தவும்.
• Logs-க்குள் மெட்ரிக்குகளை உட்பொதிக்க embedded metric format(EMF) பயன்படுத்தவும், Observability தளத்திற்கான API calls எண்ணிக்கையை குறைக்கவும், செலவைக் குறைக்கவும்.
  • requestId போன்ற அதிக கார்டினாலிட்டி dimensions கொண்ட மெட்ரிக்குகளுக்கு EMF பயன்படுத்துவதைத் தவிர்க்கவும்
• எச்சரிக்கைகள்:
  • எச்சரிக்கைகளுக்கான கடினமான thresholds அமைப்பதைத் தவிர்க்க anomaly detection பயன்படுத்தவும். இது காலப்போக்கில் கணினி பயன்பாடு மாறும்போது thresholds-ஐ புதுப்பிக்கும் overhead-ஐ தவிர்க்கலாம் மற்றும் எச்சரிக்கை இரைச்சலைக் குறைக்கலாம்.
  • ஒரு குறிப்பிட்ட தோல்விக்காக உருவாக்கப்படும் தனிப்பட்ட எச்சரிக்கைகளின் எண்ணிக்கையை குறைக்க metric math மற்றும் combination alerts பயன்படுத்தவும்.
  • SLO ஆபத்தில் இருக்கும்போது/தோல்வியடையும்போது மட்டுமே எச்சரிக்கை செய்யுங்கள். இது உங்கள் குழுவை தேவையின்றி எழுப்புவதைத் தவிர்க்கலாம் மற்றும் cognitive மற்றும் context overload-ஐ குறைக்கலாம்
  • தோல்வி அறிவிப்பின் மீது யாரேனும் நடவடிக்கை எடுக்க முடிந்தால் மட்டுமே எச்சரிக்கை செய்யுங்கள்
  • சாத்தியமான இடங்களில் எச்சரிக்கையின் தீர்வை தானியங்குபடுத்துங்கள். உதாரணமாக, autoscaling, replica அல்லது standby instance-க்கு automatic failover போன்ற native platform configuration-ஐ பயன்படுத்துங்கள்.
  • அறிவிக்கப்படும் நபர் பார்க்க வேண்டிய dashboards, பயன்படுத்த வேண்டிய playbook மற்றும் பாதிக்கப்பட்ட சேவையை விரைவாக அடையாளம் காண எச்சரிக்கை notification-க்கு போதுமான context சேர்க்கவும்
• டாஷ்போர்டுகள்:
  • ஒவ்வொரு persona/stakeholder-க்கும் ஒன்று அல்லது அதற்கு மேற்பட்ட டாஷ்போர்டுகளை உருவாக்கவும்.
    • Application developers சிக்கல்களைக் கண்டறியவும், பயன்பாட்டின் செயல்திறனைப் புரிந்துகொள்ளவும் போதுமான context தேவை
    • Platform engineers SLOs-இல் தாக்கத்தையும் கவனம் தேவைப்படும் உள்கட்டமைப்பு கூறுகளையும் அவற்றின் சேவைகள் மீதான தாக்கத்தையும் அடையாளம் காண context கொண்ட டாஷ்போர்டுகள் தேவை
    • Product managers பயனர் பயணம், தயாரிப்பு அம்ச பயன்பாட்டு மெட்ரிக்குகள், adoption rates, abandonment points போன்றவற்றைக் காட்டும் டாஷ்போர்டுகள் தேவை
    • Business stakeholders தயாரிப்பு adoption rates, subscriber fall off அல்லது வணிக செயல்திறன் மற்றும் வருவாயை பாதிக்கும் எதையும் நிரூபிக்கும் widgets-இல் ஆர்வமாக இருப்பார்கள்
  • அனைத்து டாஷ்போர்டுகளிலும் ஒரே நேர மண்டலத்தைப் பயன்படுத்தவும் உதா. UTC
  • டாஷ்போர்டில் உள்ள அனைத்து widgets-இலும் ஒரே நேர வரம்பைப் பயன்படுத்தவும்
  • டாஷ்போர்டுகளுக்கு மேலும் context சேர்க்க annotations பயன்படுத்தவும்
  • பிழை தீர்வுகளுக்கு context சேர்க்கும் widgets மட்டுமே டாஷ்போர்டில் இருப்பதை உறுதிப்படுத்தவும். அதிகமான widgets இரைச்சல் மற்றும் cognitive overload-ஐ சேர்க்கலாம், இது அதிக MTTR-க்கு வழிவகுக்கிறது
    • பிற நல்லதாக இருக்கும் widgets-ஐ மற்றொரு டாஷ்போர்டுக்கு அல்லது ஏற்கனவே அதிக widgets இல்லையென்றால் டாஷ்போர்டின் அடிப்பகுதிக்கு நகர்த்தவும். அதிகமான widgets load time-ஐ பாதிக்கும் மற்றும் அதிக stress மற்றும் cognitive overload-ஐ விளைவிக்கும்.
  • முழு டாஷ்போர்டும் ஒரே screen-இல் பொருந்துவதையும் laptop-இன் resolution மற்றும் screen size-உடன் trends காணக்கூடியதாக இருப்பதையும் உறுதிப்படுத்தவும்
  • டாஷ்போர்டின் விளக்கம் மற்றும் டாஷ்போர்டை எவ்வாறு பயன்படுத்துவது என்பதற்கான வழிகாட்டுதலுடன் ஒரு widget வைக்கவும்
  • Widgets-இல் thresholds-ஐ கட்டமைத்து காண்பிக்கவும்
  • ஒரே widget-இல் அதிக மெட்ரிக்குகளை திணிக்க வேண்டாம், இது trends மற்றும் spikes-ஐ smooth செய்து நோக்கத்தை தோற்கடிக்கும். இது diagnosis-ஐயும் கடினமாக்குகிறது.
  • Trends மற்றும் spikes காணக்கூடியதாக இருக்க dynamically adjusted Y-axis பயன்படுத்தவும்
• பரிந்துரைகள்:
  • செலவைக் கட்டுப்படுத்துதல்:
    • Stakeholders-ஐ அடையாளம் காணுங்கள்:
      • செயல்பாடு, கிடைக்கும் தன்மை, பாதுகாப்பு, செலவு, விற்பனை மற்றும் தயாரிப்பு பயன்பாடு போன்ற அம்ச செயல்திறனில் ஆர்வமுள்ள வெவ்வேறு personas-ஐ தீர்மானிக்கவும்.
      • Stakeholders-இல் development teams, இறுதி வாடிக்கையாளர்கள், உள் business stakeholders, platform operations teams அல்லது application developers அடங்கலாம்.
    • முக்கிய விளைவுகளை அடையாளம் காணுங்கள்:
      • ஒவ்வொரு stakeholder-க்கும், பொதுவாக Service Level Objectives (SLOs) பயன்படுத்தி அளவிடப்படும் அளவிடக்கூடிய விளைவுகளை வரையறுக்கவும் (உதா., பிழை விகிதங்கள், கோரிக்கை செயலாக்க காலம், நிமிடத்திற்கான logins எண்ணிக்கை, நிமிடத்திற்கு வாங்கப்பட்ட தயாரிப்புகள் எண்ணிக்கை, abandoned carts எண்ணிக்கை, முதலியன).
      • தேவையான instrumentation-ஐ அடையாளம் காண ஒவ்வொரு persona-க்கான இந்த SLOs-ஐ பயன்படுத்தவும்
    • சரியான சிக்னலைத் தேர்ந்தெடுக்கவும்:
      • போதுமான context கொண்ட wide log மெட்ரிக்குகள் மற்றும் traces-ஆக மாற்றலாம், ஒரே உண்மை ஆதாரத்தை வழங்குகிறது, செலவைக் கட்டுப்படுத்துகிறது மற்றும் signal correlation-ஐ இயக்குகிறது
      • பயன்பாட்டில் instrumented செய்யப்பட வேண்டிய சரியான signals-ஐ அடையாளம் காண ஒரு Observability Strategy Workshop-ஐ இயக்கவும்
  • சரியான சிக்னலைத் தேர்ந்தெடுக்கவும்:
    • Logs மற்றும் traces ஒரு தோல்வி அல்லது எதிர்பாராத நடத்தையின் மூல காரணத்தைக் கண்டறிய உதவுகின்றன. "ஒரு குறிப்பிட்ட கோரிக்கை ஏன் தோல்வியடைந்தது?" அல்லது "கோரிக்கை செயலாக்க நேரத்தின் p50 அல்லது p99-இல் அதிகரிப்பு இருந்தால், கோரிக்கை காலம் தொடர்பான SLO-க்கு என்ன தெரிந்திருக்க வேண்டும்?" போன்ற கேள்விகளுக்கு பதிலளிக்க உதவும் logs-ஐ சேர்க்கவும்
    • Metrics baseline செயல்திறனைப் புரிந்துகொள்ளவும், trends மற்றும் anomalies-ஐ கணிக்கவும் நல்லது. அவை எதிர்பார்த்தபடி செயல்படாத ஒன்றின் குறிப்பை முன்கூட்டியே தரலாம். Custom metrics இருப்பினும் விலை அதிகம்.
  • எச்சரிக்கை சோர்வை குறைக்கவும்:
    • கட்டமைப்பைப் பொறுத்து, எச்சரிக்கைகள் கணினியில் ஒரு சிக்கலை முன்கூட்டியே அல்லது எதிர்வினையாக முன்னிலைப்படுத்தலாம். அதிகமான எச்சரிக்கைகள் எச்சரிக்கை சோர்வு மற்றும் திறமையற்ற குழுக்களுக்கு வழிவகுக்கலாம், மோசமான குறியீடு தரம் மற்றும் தயாரிப்பு விநியோகத்திற்கு வழிவகுக்கும்.
  • அவ்வப்போது மதிப்பாய்வுகள் மற்றும் தொடர்ச்சியான மேம்பாடு:
    • டாஷ்போர்டுகளை கண்காணிக்கவும் அடையாளம் காணப்பட்ட புதிய trends அல்லது patterns-ஐ அறிக்கையிடவும் குழுவில் ஒரு உறுப்பினருக்கான அவ்வப்போது roster வைக்கவும்.
    • Retrospectives மற்றும் roster observations-இல் அடையாளம் காணப்பட்ட gaps-ஐ அடிப்படையாகக் கொண்டு signals-ஐ மேம்படுத்தவும், alert thresholds மற்றும் dashboards-ஐ சரிசெய்யவும் ஒவ்வொரு release-இன் ஒரு பகுதியை ஒதுக்குங்கள்
    • தீர்க்கும் முயற்சி மற்றும் எச்சரிக்கை triggers-ஆகும் முறைகளின் அடிப்படையில் மீண்டும் மீண்டும் வரும் எச்சரிக்கையின் மூல காரணத்தை சரிசெய்வதை முன்னுரிமைப்படுத்துங்கள்

Profiling மற்றும் செயல்திறன் மேம்படுத்தல்

• Real User Monitoring(RUM):
  • உண்மையான பயனர் ஊடாடல்களை கண்காணிக்கவும் செயல்திறன் தடைகளை அடையாளம் காணவும் AWS X-Ray அல்லது New Relic போன்ற கருவிகளைப் பயன்படுத்தவும். முக்கிய conversion points-இல் கவனம் செலுத்தி தொழில்நுட்ப செயல்திறன் மற்றும் வணிக விளைவுகள் (conversion rates, abandonment points) இரண்டையும் அளவிடுங்கள்.
  • Checkout flows மற்றும் registration processes போன்ற முக்கியமான பயனர் பாதைகளின் கண்காணிப்பை முன்னுரிமைப்படுத்தவும்.
  • வணிக விளைவுகளை பாதிக்கக்கூடிய anomalies மற்றும் trends-ஐ விரைவாக அடையாளம் காண baseline செயல்திறன் மற்றும் பயனர் நடத்தையை நிறுவுங்கள்
• Synthetics:
  • பல்வேறு நிலைமைகளில் பயன்பாட்டு செயல்திறனை சோதிக்கவும் பயனர் ஊடாடல்களை simulate செய்யவும் Amazon Cloudwatch Synthetics போன்ற கருவிகளைப் பயன்படுத்தவும். Synthetic canaries பயனர் தாக்கம் கண்டறியப்படுவதற்கு முன் சிக்கல்களை அடையாளம் காண உதவும்.
  • Synthetic canaries-உடன் health checks மற்றும் system uptime-ஐ validate செய்யுங்கள்.
• Profiling கருவிகள்:
  • செயல்திறன் தடைகளை அடையாளம் காணவும் வள பயன்பாட்டை மேம்படுத்தவும் AWS X-Ray போன்ற profiling கருவிகளைப் பயன்படுத்தவும்
  • Traffic patterns-ஐ அடிப்படையாகக் கொண்டு சரிசெய்யப்படும் dynamic sampling rates-ஐ அமைத்து error traces மற்றும் outliers-இன் போதுமான retention-ஐ பராமரிக்கவும். இது data volume மற்றும் costs-ஐ நிர்வகிக்கும் அதே நேரத்தில் முக்கியமான சிக்கல்களில் விரிவான தெரிவுநிலையை உறுதி செய்கிறது.
  • Error status, duration thresholds மற்றும் custom attributes-ஐ அடிப்படையாகக் கொண்டு high-value traces-ஐ முன்னுரிமைப்படுத்தும் பல sampling policies-உடன் உங்கள் collector-ஐ கட்டமைக்க tail sampling பயன்படுத்தவும். இது sampled traces-இல் அதிக மதிப்புள்ளவை அடங்கியிருப்பதை உறுதி செய்யும்
• OpenTelemetry:
  • செயல்திறன் மெட்ரிக்குகள் மற்றும் traces-ஐ சேகரிப்பதை எளிமையாக்க auto-instrumentation-க்கு OpenTelemetry-ஐ பயன்படுத்தவும். Manual instrumentation சேர்ப்பதற்கு முன் auto instrumentation வழங்கும் telemetry-ஐ validate செய்து, பின்னர் signals மற்றும் cost-ஐ கட்டுப்படுத்த தேவைகளின் அடிப்படையில் auto instrumentation-ஐ tune செய்யுங்கள்.

பிழை கையாள்வது மற்றும் debugging நுட்பங்கள்

• பொதுவானவை:
  • Transient failures-க்கு exponential backoff-உடன் retry mechanisms-ஐ வடிவமைக்கவும். வெளிப்புற சார்புகளுக்கு circuit breakers-ஐ செயல்படுத்தவும். இது விநியோகிக்கப்பட்ட கணினிகளில் குறிப்பாக உதவிகரமானது மற்றும் downstream component/service-இல் அதிகப்படியான load-ஐ தடுக்கிறது. இது அனைத்து சூழ்நிலைகளிலும் பொருந்தாமல் போகலாம், எனவே இந்த வடிவமைப்பை ஏற்றுக்கொள்வதற்கு முன் due diligence செய்யுங்கள்.
  • முக்கியமான செயல்பாடுகளுக்கு fallback mechanisms-ஐ உருவாக்கி தோல்வியடைந்த transactions-க்கு தெளிவான rollback procedures-ஐ பராமரிக்கவும்.
  • அனைத்து entry points-இலும் input validation சேர்க்கவும்.
  • Retry செய்யக்கூடிய செயல்பாடுகள் idempotent என்பதை உறுதிப்படுத்தவும்.
• Logging:
  • சேமிக்கப்பட்ட Cloudwatch Log Insights queries-இன் repository-ஐ பராமரிக்கவும். Queries-ஐ குழுவாக்க folders பயன்படுத்தவும்
  • Errors-ஐ அமைதிப்படுத்த வேண்டாம். எப்போதும் log செய்யுங்கள் அல்லது சரியாக handle செய்யுங்கள்.
  • பிற தொடர்புடைய context-க்கு கூடுதலாக logs-க்கு correlation id அல்லது request id போன்ற அடையாளம் வடிவத்தை சேர்க்கவும்.
• Playbooks மற்றும் runbooks:
  • Playbooks எழுதும்போது, தேவையான permissions, கருவிகள் மற்றும் எதிர்பார்க்கப்படும் விளைவுகளுடன் தெளிவான செயல்படக்கூடிய படிகளை உள்ளடக்குங்கள்.
  • Playbooks மற்றும் run books-இல் verification steps, rollback procedures மற்றும் தொடர்புடைய dashboards-க்கான links-ஐ உள்ளடக்குங்கள்.
  • Playbooks-ஐ version செய்து கற்றல்கள் மற்றும் முக்கிய நுண்ணறிவுகள் உள்ளிட்ட சம்பவங்களுக்குப் பிறகு அவற்றை புதுப்பிக்கவும்.
• Sampling rules tune செய்தல்:
  • சேவை முக்கியத்துவம் மற்றும் traffic patterns-ஐ அடிப்படையாகக் கொண்டு dynamic sampling rules-ஐ செயல்படுத்தவும்.
  • Error conditions மற்றும் business-critical paths-க்கு அதிக sampling rates-ஐ அமைக்கவும்.
  • செயல்பாட்டு தேவைகள் மற்றும் செலவு கருத்தில்களின் அடிப்படையில் sampling rules-ஐ வழக்கமாக மதிப்பாய்வு செய்து சரிசெய்யுங்கள்.

Code reviews மற்றும் ஒத்துழைப்பு உத்திகள்

• Ticket elaboration:
  • Feature elaboration செயல்முறையின் ஒரு பகுதியாக Observability தேவைகளை அடையாளம் காணுங்கள். இதில் அடங்கலாம்
    • பாதிக்கப்பட்ட Stakeholders மற்றும் தொடர்புடைய SLOs
    • தேவையான telemetry/signals
    • தேவையான alerts
    • உருவாக்க அல்லது புதுப்பிக்க வேண்டிய dashboards பட்டியல்
• குற்றமற்ற retrospectives:
  • ஒவ்வொரு சம்பவத்திற்கும் பிறகு, செயல்முறைகளை மேம்படுத்த அல்லது automation சேர்க்க வாய்ப்புகளைத் தேடும் குற்றமற்ற retrospective நடத்துங்கள். எப்போதும் மாற்றத்தின் செலவை கருத்தில் கொண்டு ஒவ்வொரு post mortem exercise-ஐயும் குறைந்தபட்சம் ஒரு ஒப்புக்கொள்ளப்பட்ட செயல்படக்கூடிய பொருளுடன் விடுங்கள், அதற்கு completion-க்கான timeline-ம் இணைக்கப்பட்டிருக்க வேண்டும்.
• Operational Readiness Reviews:
  • Observability posture-இல் உள்ள gaps-ஐ அடையாளம் காண platform மற்றும் operations team-உடன் operational readiness reviews-இல் பங்கேற்கவும் - இது ஒரு checklist ஆகவும் production-க்கு deployments-க்கு முன் கட்டாய exercise ஆகவும் இருக்கலாம். பல குழுக்கள் கொண்ட பெரிய அமைப்புகளுக்கு, இந்த செயல்முறை தடையாக மாறுவதைத் தவிர்க்க, அவ்வப்போது, புதிய feature மற்றும் release cadence-க்கு ஒருமுறை இவற்றை நடத்துங்கள்.
• பரிந்துரைகள்:
  • Post-incident analysis மூலம் உங்களை வழிநடத்த AWS Systems Manager Incident Manager போன்ற கருவியைப் பயன்படுத்தவும்
  • உங்கள் operational readiness review checklist அல்லது process-இல் உள்ளடக்க வேண்டிய கேள்விகளுக்கான உத்வேகத்திற்கு Operational Readiness Review-ஐ பார்க்கவும்.
  • Retrospectives, operational readiness reviews-இலிருந்தான கற்றல்களை எப்போதும் பகிருங்கள் - இது wiki அல்லது mail group subscriptions மூலம் இருக்கலாம்

API வடிவமைப்பு மற்றும் ஆவணப்படுத்தல் வழிகாட்டுதல்கள்

• Versioning:
  • APIs version செய்யப்பட்டிருப்பதையும் version ஒவ்வொரு செயலாக்கப்படும் கோரிக்கைக்கும் context-ஆக சேர்க்கப்பட்டிருப்பதையும் உறுதிப்படுத்தவும்
  • Custom metrics அனுப்பும்போது, பொருந்தினால் version-இல் ஒரு dimension சேர்க்கவும்
  • ஒரு version-இலிருந்து மற்றொன்றுக்கான cutover-ஐ தெளிவாக வேறுபடுத்த dashboards-இல் annotation அல்லது identifier சேர்க்கவும்
  • ஒவ்வொரு version-க்கான கோரிக்கைகளையும் versions-இன் பயன்பாட்டை காட்சிப்படுத்தும் widget-ஐயும் கண்காணிப்பதை உறுதிப்படுத்தவும். இது கோரிக்கைகள் எதிர்பார்த்தபடி route செய்யப்படுகின்றன என்பதை உறுதிப்படுத்தவும் மூல காரணத்தை அடையாளம் காணும் நேரத்தை குறைக்கவும் உதவுகிறது. பழைய version-ஐ deprecated செய்து நீக்கும்போது அதிக confidence-ஐ வழங்கலாம்
• Backwards Compatibility:
  • பழைய API version-க்கான code paths-ஐ நீக்குவதற்கு முன் பழைய versions-க்கு கோரிக்கைகள் இல்லை என்பதை உறுதிப்படுத்தவும்
• Batch APIs:
  • ஒவ்வொரு தனிப்பட்ட கோரிக்கையின் நிலை மற்றும் ஒட்டுமொத்த batch கோரிக்கைக்கான signals-ஐ வெளியிடுங்கள்
  • Batch request id மற்றும் தனிப்பட்ட கோரிக்கையை அடையாளம் காணும் context logs-க்கு சேர்க்கப்பட்டிருப்பதை உறுதிப்படுத்தவும்