ఇప్పుడు DevOps అంశం హైప్‌లో ఉంది. నిరంతర ఇంటిగ్రేషన్ మరియు డెలివరీ పైప్‌లైన్ CI/CD అందరూ దానిని అమలు చేస్తున్నారు. అయితే CI/CD పైప్‌లైన్‌లోని వివిధ దశల్లో సమాచార వ్యవస్థల విశ్వసనీయతను నిర్ధారించడానికి చాలా మంది ఎల్లప్పుడూ తగిన శ్రద్ధ చూపరు. ఈ వ్యాసంలో నేను సాఫ్ట్‌వేర్ నాణ్యత తనిఖీలను ఆటోమేట్ చేయడంలో మరియు దాని "స్వీయ-స్వస్థత" కోసం సాధ్యమయ్యే దృశ్యాలను అమలు చేయడంలో నా అనుభవం గురించి మాట్లాడాలనుకుంటున్నాను.

మూలం

నేను ఒక కంపెనీలో ఐటీ సర్వీస్ మేనేజ్‌మెంట్ విభాగంలో ఇంజనీర్‌గా పనిచేస్తున్నాను "LANIT-ఇంటిగ్రేషన్". వివిధ అప్లికేషన్ పనితీరు మరియు లభ్యత పర్యవేక్షణ వ్యవస్థలను అమలు చేయడం నా నైపుణ్యం యొక్క ప్రధాన ప్రాంతం. వారి IT సేవల నాణ్యతను పర్యవేక్షించడానికి సంబంధించి ప్రస్తుత సమస్యలకు సంబంధించి వివిధ మార్కెట్ విభాగాల నుండి IT కస్టమర్‌లతో నేను తరచుగా కమ్యూనికేట్ చేస్తాను. విడుదల చక్రం సమయాన్ని తగ్గించడం మరియు విడుదలల ఫ్రీక్వెన్సీని పెంచడం ప్రధాన లక్ష్యం. ఇది, వాస్తవానికి, మంచిది: మరిన్ని విడుదలలు - మరిన్ని కొత్త ఫీచర్లు - మరింత సంతృప్తి చెందిన వినియోగదారులు - మరింత లాభం. కానీ వాస్తవానికి, విషయాలు ఎల్లప్పుడూ సరిగ్గా పని చేయవు. చాలా ఎక్కువ డిప్లాయ్‌మెంట్ రేట్‌లతో, మా విడుదలల నాణ్యత గురించి వెంటనే ప్రశ్న తలెత్తుతుంది. పూర్తి ఆటోమేటెడ్ పైప్‌లైన్‌తో కూడా, అప్లికేషన్ సమయ మరియు వినియోగదారు అనుభవాన్ని ప్రభావితం చేయకుండా టెస్టింగ్ నుండి ఉత్పత్తికి సేవలను తరలించడం అతిపెద్ద సవాళ్లలో ఒకటి.

కస్టమర్‌లతో అనేక సంభాషణల ఫలితాల ఆధారంగా, CI యొక్క వివిధ దశలలో విడుదల నాణ్యత నియంత్రణ, అప్లికేషన్ విశ్వసనీయత మరియు దాని “స్వీయ-స్వస్థత” (ఉదాహరణకు, స్థిరమైన సంస్కరణకు తిరిగి వెళ్లడం) యొక్క అవకాశం గురించి నేను చెప్పగలను. /CD పైప్‌లైన్ అత్యంత ఉత్తేజకరమైన మరియు సంబంధిత అంశాలలో ఒకటి.

ఇటీవల, నేను కస్టమర్ వైపు పని చేసాను - ఆన్‌లైన్ బ్యాంకింగ్ అప్లికేషన్ సాఫ్ట్‌వేర్ సపోర్ట్ సర్వీస్‌లో. మా అప్లికేషన్ యొక్క ఆర్కిటెక్చర్ స్వీయ-వ్రాత మైక్రోసర్వీస్‌లను పెద్ద సంఖ్యలో ఉపయోగించింది. విచారకరమైన విషయం ఏమిటంటే, డెవలపర్‌లందరూ అభివృద్ధి యొక్క అధిక వేగాన్ని ఎదుర్కోలేరు; కొన్ని మైక్రోసర్వీస్‌ల నాణ్యత దెబ్బతింది, ఇది వారికి మరియు వాటి సృష్టికర్తలకు ఫన్నీ మారుపేర్లకు దారితీసింది. ఈ ఉత్పత్తులను ఏ పదార్థాలతో తయారు చేశారనే దాని గురించి కథనాలు ఉన్నాయి.

"సమస్య యొక్క సూత్రీకరణ"

విడుదలల యొక్క అధిక పౌనఃపున్యం మరియు అధిక సంఖ్యలో మైక్రోసర్వీస్‌లు పరీక్ష దశలో మరియు కార్యాచరణ దశలో మొత్తం అప్లికేషన్ యొక్క ఆపరేషన్‌ను అర్థం చేసుకోవడం కష్టతరం చేస్తాయి. మార్పులు నిరంతరం జరుగుతాయి మరియు మంచి పర్యవేక్షణ సాధనాలు లేకుండా వాటిని నియంత్రించడం చాలా కష్టం. తరచుగా, ఉదయం రాత్రి విడుదలైన తర్వాత, డెవలపర్‌లు పౌడర్ కెగ్‌లో కూర్చుని ఏమీ విచ్ఛిన్నం కాకుండా వేచి ఉంటారు, అయినప్పటికీ పరీక్ష దశలో అన్ని తనిఖీలు విజయవంతమయ్యాయి.

ఇంకొక పాయింట్ ఉంది. పరీక్ష దశలో, సాఫ్ట్‌వేర్ యొక్క కార్యాచరణ తనిఖీ చేయబడుతుంది: అప్లికేషన్ యొక్క ప్రధాన విధుల అమలు మరియు లోపాలు లేకపోవడం. గుణాత్మక పనితీరు అంచనాలు లేవు లేదా అప్లికేషన్ మరియు ఇంటిగ్రేషన్ లేయర్ యొక్క అన్ని అంశాలను పరిగణనలోకి తీసుకోవద్దు. కొన్ని కొలమానాలు అస్సలు తనిఖీ చేయబడకపోవచ్చు. ఫలితంగా, ఉత్పత్తి వాతావరణంలో విచ్ఛిన్నం సంభవించినప్పుడు, నిజమైన వినియోగదారులు ఫిర్యాదు చేయడం ప్రారంభించినప్పుడు మాత్రమే సాంకేతిక మద్దతు విభాగం దాని గురించి తెలుసుకుంటుంది. నేను తుది వినియోగదారులపై తక్కువ-నాణ్యత సాఫ్ట్‌వేర్ ప్రభావాన్ని తగ్గించాలనుకుంటున్నాను.

CI/CD పైప్‌లైన్ యొక్క వివిధ దశలలో సాఫ్ట్‌వేర్ నాణ్యతను తనిఖీ చేసే ప్రక్రియలను అమలు చేయడం మరియు అత్యవసర పరిస్థితుల్లో సిస్టమ్‌ను పునరుద్ధరించడానికి వివిధ దృశ్యాలను జోడించడం పరిష్కారాలలో ఒకటి. మాకు DevOps ఉన్నాయని కూడా గుర్తుంచుకుంటాము. వ్యాపారాలు వీలైనంత త్వరగా కొత్త ఉత్పత్తిని అందుకోవాలని ఆశిస్తున్నాయి. కాబట్టి, మా చెక్‌లు మరియు స్క్రిప్ట్‌లు అన్నీ ఆటోమేటెడ్ అయి ఉండాలి.

పని రెండు భాగాలుగా విభజించబడింది:

• పరీక్ష దశలో సమావేశాల నాణ్యత నియంత్రణ (తక్కువ-నాణ్యత గల సమావేశాలను పట్టుకునే ప్రక్రియను ఆటోమేట్ చేయడానికి);
• ఉత్పత్తి వాతావరణంలో సాఫ్ట్‌వేర్ నాణ్యత నియంత్రణ (సమస్యలను స్వయంచాలకంగా గుర్తించే యంత్రాంగాలు మరియు వారి స్వీయ-స్వస్థత కోసం సాధ్యమయ్యే దృశ్యాలు).

కొలమానాలను పర్యవేక్షించడం మరియు సేకరించడం కోసం సాధనం

నిర్దేశిత లక్ష్యాలను సాధించడానికి, CI/CD పైప్‌లైన్‌లోని వివిధ దశల్లో సమస్యలను గుర్తించి వాటిని ఆటోమేషన్ సిస్టమ్‌లకు బదిలీ చేయగల పర్యవేక్షణ వ్యవస్థ అవసరం. ఈ వ్యవస్థ వివిధ బృందాలకు ఉపయోగకరమైన కొలమానాలను అందిస్తే అది కూడా సానుకూల విషయం అవుతుంది: అభివృద్ధి, పరీక్ష, ఆపరేషన్. మరియు ఇది వ్యాపారం కోసం కూడా ఉంటే అది ఖచ్చితంగా అద్భుతమైనది.

కొలమానాలను సేకరించడానికి, మీరు వివిధ సిస్టమ్‌ల సమితిని ఉపయోగించవచ్చు (ప్రోమేతియస్, ELK స్టాక్, Zabbix, మొదలైనవి), కానీ, నా అభిప్రాయం ప్రకారం, APM-తరగతి పరిష్కారాలు ఈ పనులకు బాగా సరిపోతాయి (అప్లికేషన్ పనితీరు పర్యవేక్షణ), ఇది మీ జీవితాన్ని చాలా సులభతరం చేస్తుంది.

సపోర్ట్ సర్వీస్‌లో నా పనిలో భాగంగా, నేను Dynatrace నుండి APM క్లాస్ సొల్యూషన్‌ని ఉపయోగించి ఇలాంటి ప్రాజెక్ట్‌ని చేయడం ప్రారంభించాను. ఇప్పుడు, ఇంటిగ్రేటర్ కోసం పనిచేస్తున్నాను, నాకు మానిటరింగ్ సిస్టమ్స్ మార్కెట్ గురించి బాగా తెలుసు. నా ఆత్మాశ్రయ అభిప్రాయం: అటువంటి సమస్యలను పరిష్కరించడానికి డైనట్రేస్ ఉత్తమంగా సరిపోతుంది.
డైనాట్రేస్ ప్రతి వినియోగదారు ఆపరేషన్ యొక్క క్షితిజ సమాంతర వీక్షణను గ్రాన్యులర్ స్థాయిలో కోడ్ అమలు స్థాయి వరకు అందిస్తుంది. మీరు వివిధ సమాచార సేవల మధ్య పరస్పర చర్య యొక్క మొత్తం గొలుసును ట్రాక్ చేయవచ్చు: వెబ్ మరియు మొబైల్ అప్లికేషన్‌ల ఫ్రంట్-ఎండ్ స్థాయిలు, బ్యాక్-ఎండ్ అప్లికేషన్ సర్వర్లు, ఇంటిగ్రేషన్ బస్ నుండి డేటాబేస్కు నిర్దిష్ట కాల్ వరకు.

మూలం. సిస్టమ్ భాగాల మధ్య అన్ని డిపెండెన్సీల స్వయంచాలక నిర్మాణం

మూలం. సేవా ఆపరేషన్ మార్గం యొక్క స్వయంచాలక గుర్తింపు మరియు నిర్మాణం

మేము వివిధ ఆటోమేషన్ టూల్స్‌తో కలిసిపోవాలని కూడా గుర్తుంచుకోవాలి. ఇక్కడ పరిష్కారం అనుకూలమైన APIని కలిగి ఉంది, ఇది వివిధ కొలమానాలు మరియు ఈవెంట్‌లను పంపడానికి మరియు స్వీకరించడానికి మిమ్మల్ని అనుమతిస్తుంది.

తరువాత, డైనాట్రేస్ సిస్టమ్‌ను ఉపయోగించి ఈ సమస్యలను ఎలా పరిష్కరించాలో మరింత వివరంగా చూద్దాం.

టాస్క్ 1. పరీక్ష దశలో సమావేశాల నాణ్యత నియంత్రణ యొక్క ఆటోమేషన్

అప్లికేషన్ డెలివరీ పైప్‌లైన్‌లో వీలైనంత త్వరగా సమస్యలను కనుగొనడం మొదటి సవాలు. "మంచి" కోడ్ బిల్డ్‌లు మాత్రమే ఉత్పత్తిని చేరుకోవాలి. దీన్ని చేయడానికి, పరీక్ష దశలో మీ పైప్‌లైన్ మీ సేవల నాణ్యతను తనిఖీ చేయడానికి అదనపు మానిటర్‌లను కలిగి ఉండాలి.

దీన్ని ఎలా అమలు చేయాలి మరియు ఈ ప్రక్రియను ఆటోమేట్ చేయడం ఎలాగో దశల వారీగా చూద్దాం:

మూలం

ఆటోమేటెడ్ సాఫ్ట్‌వేర్ నాణ్యత పరీక్ష దశల ప్రవాహాన్ని బొమ్మ చూపిస్తుంది:

1. పర్యవేక్షణ వ్యవస్థ యొక్క విస్తరణ (ఏజెంట్ల సంస్థాపన);
2. మీ సాఫ్ట్‌వేర్ నాణ్యతను అంచనా వేయడానికి ఈవెంట్‌లను గుర్తించడం (కొలమానాలు మరియు థ్రెషోల్డ్ విలువలు) మరియు వాటిని పర్యవేక్షణ వ్యవస్థకు బదిలీ చేయడం;
3. లోడ్ మరియు పనితీరు పరీక్షల తరం;
4. పర్యవేక్షణ వ్యవస్థలో పనితీరు మరియు లభ్యత డేటాను సేకరించడం;
5. మానిటరింగ్ సిస్టమ్ నుండి CI/CD సిస్టమ్‌కు సాఫ్ట్‌వేర్ నాణ్యత అంచనా ఈవెంట్‌ల ఆధారంగా పరీక్ష డేటా బదిలీ. అసెంబ్లీల స్వయంచాలక విశ్లేషణ.

దశ 1. పర్యవేక్షణ వ్యవస్థ యొక్క విస్తరణ

ముందుగా మీరు మీ పరీక్ష వాతావరణంలో ఏజెంట్లను ఇన్‌స్టాల్ చేయాలి. అదే సమయంలో, Dynatrace సొల్యూషన్ ఒక మంచి ఫీచర్‌ని కలిగి ఉంది - ఇది OS ఇన్‌స్టాన్స్‌లో (Windows, Linux, AIX) ఇన్‌స్టాల్ చేయబడిన యూనివర్సల్ ఏజెంట్ OneAgentని ఉపయోగిస్తుంది, మీ సేవలను స్వయంచాలకంగా గుర్తించి, వాటిపై పర్యవేక్షణ డేటాను సేకరించడం ప్రారంభిస్తుంది. మీరు ప్రతి ప్రక్రియ కోసం ప్రత్యేక ఏజెంట్‌ను కాన్ఫిగర్ చేయవలసిన అవసరం లేదు. క్లౌడ్ మరియు కంటైనర్ ప్లాట్‌ఫారమ్‌ల పరిస్థితి కూడా ఇదే విధంగా ఉంటుంది. అదే సమయంలో, మీరు ఏజెంట్ ఇన్‌స్టాలేషన్ ప్రక్రియను కూడా ఆటోమేట్ చేయవచ్చు. డైనాట్రేస్ "ఇన్‌ఫ్రాస్ట్రక్చర్ యాజ్ కోడ్" కాన్సెప్ట్‌కి సరిగ్గా సరిపోతుంది (కోడ్ లేదా IaC వంటి మౌలిక సదుపాయాలు): అన్ని ప్రముఖ ప్లాట్‌ఫారమ్‌ల కోసం రెడీమేడ్ స్క్రిప్ట్‌లు మరియు సూచనలు ఉన్నాయి. మీరు మీ సేవ యొక్క కాన్ఫిగరేషన్‌లో ఏజెంట్‌ను పొందుపరిచారు మరియు మీరు దానిని అమలు చేసినప్పుడు, మీరు ఇప్పటికే పని చేస్తున్న ఏజెంట్‌తో వెంటనే కొత్త సేవను అందుకుంటారు.

దశ 2: మీ సాఫ్ట్‌వేర్ నాణ్యత ఈవెంట్‌లను నిర్వచించండి

ఇప్పుడు మీరు సేవలు మరియు వ్యాపార కార్యకలాపాల జాబితాను నిర్ణయించుకోవాలి. మీ సేవకు వ్యాపార కీలకమైన వినియోగదారు కార్యకలాపాలను ఖచ్చితంగా పరిగణనలోకి తీసుకోవడం చాలా ముఖ్యం. ఇక్కడ నేను వ్యాపార మరియు సిస్టమ్స్ విశ్లేషకులతో సంప్రదించాలని సిఫార్సు చేస్తున్నాను.

తర్వాత, మీరు ప్రతి స్థాయికి సంబంధించిన సమీక్షలో ఏ కొలమానాలను చేర్చాలనుకుంటున్నారో మీరు గుర్తించాలి. ఉదాహరణకు, ఇది అమలు సమయం (సగటు, మధ్యస్థ, పర్సంటైల్‌లు మొదలైనవిగా విభజించబడింది), లోపాలు (లాజికల్, సర్వీస్, ఇన్‌ఫ్రాస్ట్రక్చర్, మొదలైనవి) మరియు వివిధ అవస్థాపన కొలమానాలు (మెమరీ హీప్, గార్బేజ్ కలెక్టర్, థ్రెడ్ కౌంట్, మొదలైనవి) కావచ్చు.

DevOps బృందం ఆటోమేషన్ మరియు సౌలభ్యం కోసం, "కోడ్ వలె మానిటరింగ్" అనే భావన కనిపిస్తుంది. నా ఉద్దేశ్యం ఏమిటంటే, డెవలపర్/టెస్టర్ సాఫ్ట్‌వేర్ నాణ్యత హామీ కొలమానాలను నిర్వచించే సాధారణ JSON ఫైల్‌ను వ్రాయగలడు.

అటువంటి JSON ఫైల్ యొక్క ఉదాహరణను చూద్దాం. Dynatrace API నుండి వస్తువులు కీ/విలువ జతలుగా ఉపయోగించబడతాయి (API వివరణ ఇక్కడ చూడవచ్చు డైనాట్రేస్ API).

{
    "timeseries": [
    {
      "timeseriesId": "service.ResponseTime",
      "aggregation": "avg",
      "tags": "Frontend",
      "severe": 250000,
      "warning": 1000000
    },
    {
      "timeseriesId": "service.ResponseTime ",
      "aggregation": "avg",
      "tags": "Backend",
      "severe": 4000000,
      "warning": 8000000
    },
    {
      "timeseriesId": "docker.Container.Cpu",
      "aggregation": "avg",
      "severe": 50,
      "warning": 70
    }
  ]
}

ఫైల్ అనేది సమయ శ్రేణి నిర్వచనాల శ్రేణి:

• timeeriesId - మెట్రిక్ తనిఖీ చేయబడుతోంది, ఉదాహరణకు, ప్రతిస్పందన సమయం, ఎర్రర్ కౌంట్, ఉపయోగించిన మెమరీ మొదలైనవి;  
• అగ్రిగేషన్ - కొలమానాల అగ్రిగేషన్ స్థాయి, మా విషయంలో సగటు, కానీ మీరు మీకు అవసరమైన దేనినైనా ఉపయోగించవచ్చు (సగటు, నిమి, గరిష్టం, మొత్తం, కౌంట్, పర్సంటైల్);
• ట్యాగ్‌లు - పర్యవేక్షణ వ్యవస్థలో ఆబ్జెక్ట్ ట్యాగ్, లేదా మీరు నిర్దిష్ట ఆబ్జెక్ట్ ఐడెంటిఫైయర్‌ను పేర్కొనవచ్చు;
• తీవ్రమైన మరియు హెచ్చరిక - ఈ సూచికలు మా కొలమానాల యొక్క థ్రెషోల్డ్ విలువలను నియంత్రిస్తాయి; పరీక్ష విలువ తీవ్రమైన థ్రెషోల్డ్‌ను మించి ఉంటే, మా బిల్డ్ విజయవంతం కాదని గుర్తు పెట్టబడుతుంది.

కింది బొమ్మ అటువంటి పరిమితుల ఉపయోగం యొక్క ఉదాహరణను చూపుతుంది.

మూలం

దశ 3: లోడ్ జనరేషన్

మేము మా సేవ యొక్క నాణ్యత స్థాయిలను నిర్ణయించిన తర్వాత, మేము పరీక్ష లోడ్‌ను రూపొందించాలి. మీరు Jmeter, Selenium, Neotys, Gatling మొదలైన ఏవైనా టెస్టింగ్ సాధనాలను ఉపయోగించవచ్చు.

Dynatrace యొక్క మానిటరింగ్ సిస్టమ్ మీ పరీక్షల నుండి వివిధ మెటాడేటాను క్యాప్చర్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది మరియు ఏ పరీక్షలు ఏ విడుదల చక్రానికి మరియు ఏ సేవకు చెందినవో గుర్తించడానికి మిమ్మల్ని అనుమతిస్తుంది. HTTP పరీక్ష అభ్యర్థనలకు అదనపు శీర్షికలను జోడించమని సిఫార్సు చేయబడింది.

అదనపు హెడర్ X-Dynatrace-Testని ఉపయోగించి, ఈ పరీక్ష కార్ట్‌కు ఐటెమ్‌ని జోడించే ఆపరేషన్‌ని పరీక్షించడానికి సంబంధించినదని మేము సూచిస్తున్న ఉదాహరణను క్రింది బొమ్మ చూపుతుంది.

మూలం

మీరు ప్రతి లోడ్ పరీక్షను అమలు చేసినప్పుడు, మీరు CI/CD సర్వర్ నుండి ఈవెంట్ APIని ఉపయోగించి Dynatraceకి అదనపు సందర్భోచిత సమాచారాన్ని పంపుతారు. ఈ విధంగా, సిస్టమ్ వివిధ పరీక్షల మధ్య తేడాను గుర్తించగలదు.

మూలం. లోడ్ పరీక్ష ప్రారంభం గురించి పర్యవేక్షణ వ్యవస్థలో ఈవెంట్

దశ 4-5. పనితీరు డేటాను సేకరించి, CI/CD సిస్టమ్‌కు డేటాను బదిలీ చేయండి

ఉత్పత్తి చేయబడిన పరీక్షతో పాటు, సేవా నాణ్యత సూచికలను తనిఖీ చేయడంలో డేటాను సేకరించాల్సిన అవసరం గురించి పర్యవేక్షణ వ్యవస్థకు ఒక ఈవెంట్ ప్రసారం చేయబడుతుంది. ఇది కీ మెట్రిక్‌లను నిర్వచించే మా JSON ఫైల్‌ను కూడా నిర్దేశిస్తుంది.

మానిటరింగ్ సిస్టమ్‌కు పంపడం కోసం CI/CD సర్వర్‌లో రూపొందించబడిన సాఫ్ట్‌వేర్ నాణ్యతను తనిఖీ చేయవలసిన అవసరం గురించి ఈవెంట్

మా ఉదాహరణలో, నాణ్యత తనిఖీ ఈవెంట్ అంటారు perfSigDynatraceReport (పనితీరు_సంతకం) - ఇది సిద్ధంగా ఉంది ప్లగ్ఇన్ T-Systems మల్టీమీడియా సొల్యూషన్స్ నుండి అబ్బాయిలు అభివృద్ధి చేసిన జెంకిన్స్‌తో ఏకీకరణ కోసం. ప్రతి టెస్ట్ లాంచ్ ఈవెంట్ సేవ, బిల్డ్ నంబర్ మరియు టెస్టింగ్ సమయం గురించి సమాచారాన్ని కలిగి ఉంటుంది. ప్లగ్ఇన్ నిర్మాణ సమయంలో పనితీరు విలువలను సేకరిస్తుంది, వాటిని మూల్యాంకనం చేస్తుంది మరియు ఫలితాన్ని మునుపటి బిల్డ్‌లు మరియు నాన్-ఫంక్షనల్ అవసరాలతో పోల్చి చూస్తుంది.

నిర్మాణ నాణ్యత తనిఖీ ప్రారంభం గురించి పర్యవేక్షణ వ్యవస్థలో ఈవెంట్. మూలం

పరీక్ష పూర్తయిన తర్వాత, సాఫ్ట్‌వేర్ నాణ్యతను అంచనా వేయడానికి అన్ని కొలమానాలు తిరిగి నిరంతర ఏకీకరణ వ్యవస్థకు బదిలీ చేయబడతాయి, ఉదాహరణకు, ఫలితాలపై నివేదికను రూపొందించే జెంకిన్స్.

CI/CD సర్వర్‌లో అసెంబ్లీలపై గణాంకాల ఫలితం. మూలం

ప్రతి వ్యక్తి బిల్డ్ కోసం, మేము మొత్తం పరీక్షలో సెట్ చేసిన ప్రతి మెట్రిక్‌కు సంబంధించిన గణాంకాలను చూస్తాము. నిర్దిష్ట థ్రెషోల్డ్ విలువలలో (హెచ్చరిక మరియు తీవ్రమైన త్రాష్‌హోల్డ్‌లు) ఉల్లంఘనలు జరిగినా కూడా మేము చూస్తాము. మొత్తం మెట్రిక్‌ల ఆధారంగా, మొత్తం బిల్డ్ స్థిరంగా, అస్థిరంగా లేదా విఫలమైందిగా గుర్తించబడింది. అలాగే, సౌలభ్యం కోసం, మీరు ప్రస్తుత నిర్మాణాన్ని మునుపటి దానితో పోల్చి నివేదికకు సూచికలను జోడించవచ్చు.

CI/CD సర్వర్‌లో అసెంబ్లీలపై వివరణాత్మక గణాంకాలను వీక్షించండి. మూలం

రెండు అసెంబ్లీల వివరణాత్మక పోలిక

అవసరమైతే, మీరు డైనాట్రేస్ ఇంటర్‌ఫేస్‌కి వెళ్లవచ్చు మరియు అక్కడ మీరు మీ ప్రతి బిల్డ్‌ల గణాంకాలను మరింత వివరంగా వీక్షించవచ్చు మరియు వాటిని ఒకదానితో ఒకటి సరిపోల్చవచ్చు.

డైనట్రేస్‌లో బిల్డ్ గణాంకాల పోలిక. మూలం
 
కనుగొన్న

ఫలితంగా, మేము నిరంతర ఏకీకరణ పైప్‌లైన్‌లో ఆటోమేటెడ్ “ఒక సేవగా మానిటరింగ్” సేవను పొందుతాము. డెవలపర్ లేదా టెస్టర్ JSON ఫైల్‌లోని కొలమానాల జాబితాను మాత్రమే నిర్వచించాలి మరియు మిగతావన్నీ స్వయంచాలకంగా జరుగుతాయి. మేము విడుదలల యొక్క పారదర్శక నాణ్యత నియంత్రణను అందుకుంటాము: పనితీరు, వనరుల వినియోగం లేదా ఆర్కిటెక్చరల్ రిగ్రెషన్‌ల గురించిన అన్ని నోటిఫికేషన్‌లు.

టాస్క్ 2. ఉత్పత్తి వాతావరణంలో సాఫ్ట్‌వేర్ నాణ్యత నియంత్రణ యొక్క ఆటోమేషన్

కాబట్టి, పైప్‌లైన్‌లో పరీక్ష దశలో పర్యవేక్షణ ప్రక్రియను ఆటోమేట్ చేయడం ఎలా అనే సమస్యను మేము పరిష్కరించాము. ఈ విధంగా మేము ఉత్పత్తి వాతావరణానికి చేరుకునే తక్కువ-నాణ్యత గల సమావేశాల శాతాన్ని తగ్గిస్తాము.

కానీ చెడు సాఫ్ట్‌వేర్ విక్రయించబడితే లేదా ఏదైనా విచ్ఛిన్నమైతే ఏమి చేయాలి. ఆదర్శధామం కోసం, మేము మెకానిజమ్‌లను స్వయంచాలకంగా సమస్యలను గుర్తించాలని మరియు వీలైతే, కనీసం రాత్రి సమయంలో సిస్టమ్ దాని కార్యాచరణను పునరుద్ధరించాలని కోరుకున్నాము.

దీన్ని చేయడానికి, మునుపటి విభాగంతో సారూప్యతతో, ఉత్పత్తి వాతావరణంలో ఆటోమేటిక్ సాఫ్ట్‌వేర్ నాణ్యత తనిఖీలను అందించడం మరియు సిస్టమ్ స్వీయ-స్వస్థత కోసం దృశ్యాలపై వాటిని ఆధారం చేయడం అవసరం.

కోడ్ వలె స్వీయ దిద్దుబాటు

చాలా కంపెనీలు ఇప్పటికే వివిధ రకాల సాధారణ సమస్యలకు సంబంధించిన నాలెడ్జ్ బేస్ మరియు వాటిని పరిష్కరించడానికి చర్యల జాబితాను కలిగి ఉన్నాయి, ఉదాహరణకు, ప్రక్రియలను పునఃప్రారంభించడం, వనరులను శుభ్రపరచడం, సంస్కరణలను తిరిగి మార్చడం, చెల్లని కాన్ఫిగరేషన్ మార్పులను పునరుద్ధరించడం, భాగాల సంఖ్యను పెంచడం లేదా తగ్గించడం క్లస్టర్, నీలం లేదా ఆకుపచ్చ రూపురేఖలను మార్చడం మరియు మొదలైనవి.

నేను మాట్లాడే అనేక బృందాల ద్వారా ఈ వినియోగ కేసులు సంవత్సరాలుగా తెలిసినప్పటికీ, కొందరు వాటిని ఆటోమేట్ చేయడం గురించి ఆలోచించారు లేదా పెట్టుబడి పెట్టారు.

మీరు దాని గురించి ఆలోచిస్తే, స్వీయ-స్వస్థత అప్లికేషన్ పనితీరు కోసం ప్రక్రియలను అమలు చేయడంలో మితిమీరిన సంక్లిష్టంగా ఏమీ లేదు; మీరు మీ నిర్వాహకుల యొక్క ఇప్పటికే తెలిసిన పని దృశ్యాలను కోడ్ స్క్రిప్ట్‌ల రూపంలో ప్రదర్శించాలి ("కోడ్ వలె ఆటో-ఫిక్స్" భావన) , మీరు ప్రతి నిర్దిష్ట కేసు కోసం ముందుగానే వ్రాసారు. ఆటోమేటిక్ రిపేర్ స్క్రిప్ట్‌లు సమస్య యొక్క మూల కారణాన్ని తొలగించే లక్ష్యంతో ఉండాలి. ఒక సంఘటనకు ప్రతిస్పందించడానికి సరైన చర్యలను మీరే నిర్ణయిస్తారు.

మీ మానిటరింగ్ సిస్టమ్ నుండి ఏదైనా మెట్రిక్ స్క్రిప్ట్‌ను ప్రారంభించడానికి ట్రిగ్గర్‌గా పని చేస్తుంది, ప్రధాన విషయం ఏమిటంటే, ఈ కొలమానాలు ప్రతిదీ చెడ్డవని ఖచ్చితంగా నిర్ధారిస్తాయి, ఎందుకంటే మీరు ఉత్పాదక వాతావరణంలో తప్పుడు పాజిటివ్‌లను పొందకూడదు.

మీరు ఏదైనా సిస్టమ్ లేదా సిస్టమ్‌ల సెట్‌ని ఉపయోగించవచ్చు: ప్రోమేతియస్, ELK స్టాక్, జబ్బిక్స్, మొదలైనవి. కానీ నేను APM సొల్యూషన్ ఆధారంగా కొన్ని ఉదాహరణలను ఇస్తాను (డైనట్రేస్ మళ్లీ ఒక ఉదాహరణగా ఉంటుంది) అది మీ జీవితాన్ని సులభతరం చేయడంలో కూడా సహాయపడుతుంది.

ముందుగా, అప్లికేషన్ ఆపరేషన్ పరంగా పనితీరుకు సంబంధించిన ప్రతిదీ ఉంది. పరిష్కారం మీరు ట్రిగ్గర్‌లుగా ఉపయోగించగల వివిధ స్థాయిలలో వందలాది కొలమానాలను అందిస్తుంది:

• వినియోగదారు స్థాయి (బ్రౌజర్‌లు, మొబైల్ అప్లికేషన్‌లు, IoT పరికరాలు, వినియోగదారు ప్రవర్తన, మార్పిడి మొదలైనవి);
• సేవ మరియు కార్యకలాపాల స్థాయి (పనితీరు, లభ్యత, లోపాలు మొదలైనవి);
• అప్లికేషన్ ఇన్‌ఫ్రాస్ట్రక్చర్ స్థాయి (హోస్ట్ OS మెట్రిక్స్, JMX, MQ, వెబ్-సర్వర్ మొదలైనవి);
• ప్లాట్‌ఫారమ్ స్థాయి (వర్చువలైజేషన్, క్లౌడ్, కంటైనర్ మొదలైనవి).

డైనట్రేస్‌లో పర్యవేక్షణ స్థాయిలు. మూలం

రెండవది, నేను ఇంతకు ముందు చెప్పినట్లుగా, Dynatrace ఓపెన్ APIని కలిగి ఉంది, ఇది వివిధ థర్డ్-పార్టీ సిస్టమ్‌లతో కలిసిపోవడాన్ని చాలా సులభం చేస్తుంది. ఉదాహరణకు, నియంత్రణ పారామితులను అధిగమించినప్పుడు ఆటోమేషన్ సిస్టమ్‌కు నోటిఫికేషన్ పంపడం.

అన్సిబుల్‌తో పరస్పర చర్య చేయడానికి దిగువ ఉదాహరణ.

మూలం

ఏ విధమైన ఆటోమేషన్ చేయవచ్చో క్రింద నేను కొన్ని ఉదాహరణలు ఇస్తాను. ఇది కేసుల్లో ఒక భాగం మాత్రమే; మీ వాతావరణంలో వారి జాబితా మీ ఊహ మరియు మీ పర్యవేక్షణ సాధనాల సామర్థ్యాల ద్వారా మాత్రమే పరిమితం చేయబడుతుంది.

1. బాడ్ డిప్లాయ్ - వెర్షన్ రోల్‌బ్యాక్

మేము పరీక్ష వాతావరణంలో ప్రతిదానిని బాగా పరీక్షించినప్పటికీ, కొత్త విడుదల ఉత్పత్తి వాతావరణంలో మీ అప్లికేషన్‌ను నాశనం చేసే అవకాశం ఇప్పటికీ ఉంది. అదే మానవ కారకం రద్దు చేయబడలేదు.

కింది చిత్రంలో మేము సేవలో కార్యకలాపాల అమలు సమయంలో ఒక పదునైన జంప్ ఉన్నట్లు చూస్తాము. ఈ జంప్ యొక్క ప్రారంభం అప్లికేషన్‌కు విస్తరణ సమయంతో సమానంగా ఉంటుంది. మేము ఈ సమాచారం మొత్తాన్ని ఆటోమేషన్ సిస్టమ్‌కు ఈవెంట్‌లుగా ప్రసారం చేస్తాము. మేము సెట్ చేసిన సమయం తర్వాత సేవ యొక్క పనితీరు సాధారణ స్థితికి రాకపోతే, స్క్రిప్ట్ స్వయంచాలకంగా పిలువబడుతుంది, అది వెర్షన్‌ను పాతదానికి రోల్ చేస్తుంది.

విస్తరణ తర్వాత కార్యకలాపాల పనితీరు క్షీణించడం. మూలం

2. రిసోర్స్ లోడింగ్ 100% - రూటింగ్‌కి నోడ్‌ని జోడించండి

కింది ఉదాహరణలో, మానిటరింగ్ సిస్టమ్ కాంపోనెంట్‌లలో ఒకటి 100% CPU లోడ్‌ను అనుభవిస్తున్నట్లు నిర్ధారిస్తుంది.

CPU లోడ్ 100%
 
ఈ ఈవెంట్ కోసం అనేక విభిన్న దృశ్యాలు సాధ్యమే. ఉదాహరణకు, మానిటరింగ్ సిస్టమ్ అదనంగా వనరుల కొరత సేవపై లోడ్ పెరుగుదలతో సంబంధం కలిగి ఉందో లేదో తనిఖీ చేస్తుంది. అలా అయితే, ఒక స్క్రిప్ట్ అమలు చేయబడుతుంది, అది స్వయంచాలకంగా రూటింగ్‌కు నోడ్‌ను జోడిస్తుంది, తద్వారా మొత్తం సిస్టమ్ యొక్క కార్యాచరణను పునరుద్ధరిస్తుంది.

ఒక సంఘటన తర్వాత స్కేలింగ్

3. హార్డ్ డ్రైవ్‌లో స్థలం లేకపోవడం - డిస్క్ క్లీనింగ్

చాలా మంది ఇప్పటికే ఈ ప్రక్రియలను ఆటోమేట్ చేశారని నేను భావిస్తున్నాను. APMని ఉపయోగించి, మీరు డిస్క్ సబ్‌సిస్టమ్‌లో ఖాళీ స్థలాన్ని కూడా పర్యవేక్షించవచ్చు. ఖాళీ లేకుంటే లేదా డిస్క్ నెమ్మదిగా నడుస్తుంటే, దానిని శుభ్రం చేయడానికి లేదా ఖాళీని జోడించడానికి మేము స్క్రిప్ట్‌ని పిలుస్తాము.

డిస్క్ లోడ్ 100%
 
4. తక్కువ వినియోగదారు కార్యాచరణ లేదా తక్కువ మార్పిడి - నీలం మరియు ఆకుపచ్చ శాఖల మధ్య మారడం

ఉత్పత్తి వాతావరణంలో అప్లికేషన్ల కోసం కస్టమర్‌లు రెండు లూప్‌లను (బ్లూ-గ్రీన్ డిప్లాయ్) ఉపయోగించడం నేను తరచుగా చూస్తాను. కొత్త విడుదలలను బట్వాడా చేసేటప్పుడు శాఖల మధ్య త్వరగా మారడానికి ఇది మిమ్మల్ని అనుమతిస్తుంది. తరచుగా, విస్తరణ తర్వాత, వెంటనే గుర్తించబడని నాటకీయ మార్పులు సంభవించవచ్చు. ఈ సందర్భంలో, పనితీరు మరియు లభ్యతలో క్షీణత గమనించబడకపోవచ్చు. అటువంటి మార్పులకు త్వరగా ప్రతిస్పందించడానికి, వినియోగదారు ప్రవర్తనను ప్రతిబింబించే వివిధ కొలమానాలను ఉపయోగించడం మంచిది (సెషన్ల సంఖ్య మరియు వినియోగదారు చర్యలు, మార్పిడి, బౌన్స్ రేటు). మార్పిడి రేట్లు తగ్గినప్పుడు, సాఫ్ట్‌వేర్ శాఖల మధ్య మారడం జరిగే ఉదాహరణను క్రింది బొమ్మ చూపుతుంది.

సాఫ్ట్‌వేర్ శాఖల మధ్య మారిన తర్వాత మార్పిడి రేటు పడిపోతుంది. మూలం

ఆటోమేటిక్ సమస్య గుర్తింపు కోసం మెకానిజమ్స్

చివరగా, నేను డైనాట్రేస్‌ను ఎందుకు ఎక్కువగా ఇష్టపడుతున్నాను అనేదానికి మరో ఉదాహరణ ఇస్తాను.

పరీక్షా వాతావరణంలో అసెంబ్లీల నాణ్యత తనిఖీలను ఆటోమేట్ చేయడం గురించి నా కథనంలో భాగంగా, మేము అన్ని థ్రెషోల్డ్ విలువలను మాన్యువల్‌గా నిర్ణయించాము. పరీక్ష వాతావరణంలో ఇది సాధారణం; లోడ్‌ను బట్టి ప్రతి పరీక్షకు ముందు టెస్టర్ స్వయంగా సూచికలను నిర్ణయిస్తాడు. ఉత్పత్తి వాతావరణంలో, వివిధ బేస్‌లైన్ మెకానిజమ్‌లను పరిగణనలోకి తీసుకుని, సమస్యలు స్వయంచాలకంగా గుర్తించబడటం మంచిది.

డైనాట్రేస్ ఆసక్తికరమైన అంతర్నిర్మిత కృత్రిమ మేధస్సు సాధనాలను కలిగి ఉంది, ఇవి క్రమరహిత కొలమానాలను (బేస్‌లైనింగ్) నిర్ణయించడం మరియు అన్ని భాగాల మధ్య పరస్పర చర్య యొక్క మ్యాప్‌ను రూపొందించడం, ఈవెంట్‌లను ఒకదానితో ఒకటి పోల్చడం మరియు పరస్పర సంబంధం కలిగి ఉండటం, మీ సేవ యొక్క ఆపరేషన్‌లో క్రమరాహిత్యాలను గుర్తించడం మరియు వివరంగా అందించడం వంటి వాటిపై ఆధారపడి ఉంటాయి. ప్రతి సమస్య మరియు మూల కారణంపై సమాచారం.

కాంపోనెంట్‌ల మధ్య డిపెండెన్సీలను స్వయంచాలకంగా విశ్లేషించడం ద్వారా, సమస్యాత్మక సేవ మూలకారణమా కాదా అని మాత్రమే కాకుండా, ఇతర సేవలపై ఆధారపడటాన్ని కూడా డైనట్రేస్ నిర్ణయిస్తుంది. దిగువ ఉదాహరణలో, Dynatrace లావాదేవీ అమలులో ప్రతి సేవ యొక్క ఆరోగ్యాన్ని స్వయంచాలకంగా పర్యవేక్షిస్తుంది మరియు మూల్యాంకనం చేస్తుంది, గోలాంగ్ సేవను మూలకారణంగా గుర్తిస్తుంది.

వైఫల్యం యొక్క మూల కారణాన్ని నిర్ణయించే ఉదాహరణ. మూలం

సంఘటన ప్రారంభం నుండి మీ అప్లికేషన్‌తో సమస్యలను పర్యవేక్షించే ప్రక్రియను క్రింది బొమ్మ చూపుతుంది.

వాటిపై అన్ని భాగాలు మరియు ఈవెంట్‌ల ప్రదర్శనతో ఉద్భవిస్తున్న సమస్య యొక్క విజువలైజేషన్

పర్యవేక్షణ వ్యవస్థ తలెత్తిన సమస్యకు సంబంధించిన సంఘటనల పూర్తి కాలక్రమాన్ని సేకరించింది. టైమ్‌లైన్ దిగువన ఉన్న విండోలో మేము ప్రతి భాగాలపై అన్ని ముఖ్య ఈవెంట్‌లను చూస్తాము. ఈ ఈవెంట్‌ల ఆధారంగా, మీరు కోడ్ స్క్రిప్ట్‌ల రూపంలో ఆటోమేటిక్ కరెక్షన్ కోసం విధానాలను సెట్ చేయవచ్చు.

అదనంగా, సర్వీస్ డెస్క్ లేదా బగ్ ట్రాకర్‌తో మానిటరింగ్ సిస్టమ్‌ను ఏకీకృతం చేయమని నేను మీకు సలహా ఇస్తున్నాను. సమస్య సంభవించినప్పుడు, డెవలపర్లు ఉత్పత్తి వాతావరణంలో కోడ్ స్థాయిలో విశ్లేషించడానికి పూర్తి సమాచారాన్ని త్వరగా స్వీకరిస్తారు.

తీర్మానం

ఫలితంగా, మేము పైప్‌లైన్‌లో అంతర్నిర్మిత ఆటోమేటెడ్ సాఫ్ట్‌వేర్ నాణ్యత తనిఖీలతో CI/CD పైప్‌లైన్‌తో ముగించాము. మేము తక్కువ-నాణ్యత గల సమావేశాల సంఖ్యను తగ్గించాము, మొత్తం సిస్టమ్ యొక్క విశ్వసనీయతను పెంచుతాము మరియు మా సిస్టమ్ ఇప్పటికీ విఫలమైతే, దాన్ని పునరుద్ధరించడానికి మేము మెకానిజమ్‌లను ప్రారంభిస్తాము.

సాఫ్ట్‌వేర్ నాణ్యత పర్యవేక్షణను ఆటోమేట్ చేయడంలో పెట్టుబడి పెట్టడం ఖచ్చితంగా విలువైనదే; ఇది ఎల్లప్పుడూ శీఘ్ర ప్రక్రియ కాదు, కానీ కాలక్రమేణా అది ఫలిస్తుంది. ఉత్పాదక వాతావరణంలో కొత్త సంఘటనను పరిష్కరించిన తర్వాత, ఉత్పత్తిలోకి రాకుండా చెడు నిర్మాణాన్ని నివారించడానికి పరీక్ష వాతావరణంలో తనిఖీల కోసం ఏ మానిటర్‌లను జోడించాలో మీరు వెంటనే ఆలోచించాలని నేను సిఫార్సు చేస్తున్నాను మరియు ఈ సమస్యలను స్వయంచాలకంగా సరిదిద్దడానికి స్క్రిప్ట్‌ను కూడా రూపొందించండి.

మీ ప్రయత్నాలలో నా ఉదాహరణలు మీకు సహాయపడతాయని నేను ఆశిస్తున్నాను. స్వీయ-స్వస్థత వ్యవస్థలను అమలు చేయడానికి ఉపయోగించే కొలమానాల యొక్క మీ ఉదాహరణలను చూడటానికి కూడా నేను ఆసక్తిగా ఉంటాను.

మూలం

మూలం: www.habr.com