SRE (సైట్ రిలయబిలిటీ ఇంజనీరింగ్) అనేది వెబ్ ప్రాజెక్ట్‌లను యాక్సెస్ చేయడానికి ఒక విధానం. ఇది DevOps కోసం ఫ్రేమ్‌వర్క్‌గా పరిగణించబడుతుంది మరియు DevOps అభ్యాసాల అనువర్తనంలో ఎలా విజయం సాధించాలో చెబుతుంది. ఈ వ్యాసం అనువదిస్తుంది అధ్యాయం 4 సేవా స్థాయి లక్ష్యాలు పుస్తకాలు సైట్ విశ్వసనీయత ఇంజనీరింగ్ Google నుండి. నేనే ఈ అనువాదాన్ని సిద్ధం చేసుకున్నాను మరియు పర్యవేక్షణ ప్రక్రియలను అర్థం చేసుకోవడంలో నా స్వంత అనుభవంపై ఆధారపడి ఉన్నాను. టెలిగ్రామ్ ఛానెల్‌లో పర్యవేక్షణ_అది и హబ్రేలో చివరి పోస్ట్ నేను సేవా స్థాయి లక్ష్యాల గురించి అదే పుస్తకంలోని 6వ అధ్యాయం యొక్క అనువాదాన్ని కూడా ప్రచురించాను.

పిల్లి ద్వారా అనువాదం. చదివి ఆనందించండి!

వాస్తవానికి ఏ సూచికలు ముఖ్యమైనవి మరియు వాటిని ఎలా కొలవాలి మరియు మూల్యాంకనం చేయాలి అనే దానిపై అవగాహన లేనట్లయితే సేవను నిర్వహించడం అసాధ్యం. దీని కోసం, మా వినియోగదారులు మా అంతర్గత APIలలో ఒకదానిని లేదా పబ్లిక్ ఉత్పత్తిని ఉపయోగిస్తున్నారా అనే దానితో సంబంధం లేకుండా మేము వారికి నిర్దిష్ట స్థాయి సేవను నిర్వచించాము మరియు అందిస్తాము.

సేవా స్థాయి సూచికలు (SLIలు), సేవా స్థాయి లక్ష్యాలు (SLOలు) మరియు సేవా స్థాయి ఒప్పందాలు (SLAలు) అర్థం చేసుకోవాలనే వినియోగదారుల కోరికపై మేము మా అంతర్ దృష్టి, అనుభవం మరియు అవగాహనను ఉపయోగిస్తాము. ఈ కొలతలు మేము పర్యవేక్షించాలనుకుంటున్న ప్రధాన కొలమానాలను వివరిస్తాయి మరియు మేము ఆశించిన నాణ్యత సేవను అందించలేకపోతే మేము ప్రతిస్పందిస్తాము. అంతిమంగా, సరైన కొలమానాలను ఎంచుకోవడం ఏదైనా తప్పు జరిగితే సరైన చర్యలకు మార్గనిర్దేశం చేయడంలో సహాయపడుతుంది మరియు సేవ యొక్క ఆరోగ్యంపై SRE బృందానికి విశ్వాసాన్ని కూడా ఇస్తుంది.

మెట్రిక్ మోడలింగ్, మెట్రిక్ ఎంపిక మరియు మెట్రిక్ విశ్లేషణ సమస్యలను ఎదుర్కోవడానికి మేము ఉపయోగించే విధానాన్ని ఈ అధ్యాయం వివరిస్తుంది. చాలా వివరణలు ఉదాహరణలు లేకుండా ఉంటాయి, కాబట్టి మేము ప్రధాన అంశాలను వివరించడానికి దాని అమలు ఉదాహరణలో వివరించిన షేక్స్పియర్ సేవను ఉపయోగిస్తాము (షేక్స్పియర్ రచనల కోసం శోధించండి).

సేవా స్థాయి పరిభాష

చాలా మంది పాఠకులకు SLA భావన గురించి తెలిసి ఉండవచ్చు, అయితే SLI మరియు SLO అనే పదాలు జాగ్రత్తగా నిర్వచించవలసి ఉంటుంది ఎందుకంటే సాధారణంగా SLA అనే ​​పదం ఓవర్‌లోడ్ చేయబడింది మరియు సందర్భాన్ని బట్టి అనేక అర్థాలను కలిగి ఉంటుంది. స్పష్టత కోసం, మేము ఈ విలువలను వేరు చేయాలనుకుంటున్నాము.

సూచికలను

SLI అనేది సేవా స్థాయి సూచిక-అందించిన సేవ స్థాయి యొక్క ఒక అంశం యొక్క జాగ్రత్తగా నిర్వచించబడిన పరిమాణాత్మక కొలత.

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

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

SREలకు ముఖ్యమైన మరొక రకమైన SLI లభ్యత లేదా సేవను ఉపయోగించగల సమయం. తరచుగా విజయవంతమైన అభ్యర్థనల రేటుగా నిర్వచించబడుతుంది, కొన్నిసార్లు దిగుబడి అని పిలుస్తారు. (జీవితకాలం-డేటా ఎక్కువ కాలం నిల్వ చేయబడే అవకాశం-డేటా నిల్వ వ్యవస్థలకు కూడా ముఖ్యమైనది.) 100% లభ్యత సాధ్యం కానప్పటికీ, 100%కి దగ్గరగా లభ్యత తరచుగా సాధించవచ్చు; లభ్యత విలువలు ఇలా వ్యక్తీకరించబడతాయి "తొమ్మిది" సంఖ్య » లభ్యత శాతం. ఉదాహరణకు, 99% మరియు 99,999% లభ్యత "2 తొమ్మిదిలు" మరియు "5 తొమ్మిదిలు"గా లేబుల్ చేయబడవచ్చు. Google కంప్యూట్ ఇంజిన్ యొక్క ప్రస్తుత పేర్కొన్న లభ్యత లక్ష్యం "మూడున్నర తొమ్మిది" లేదా 99,95%.

గోల్స్

SLO అనేది సేవా స్థాయి లక్ష్యం: SLI ద్వారా కొలవబడే సేవా స్థాయి కోసం లక్ష్య విలువ లేదా విలువల పరిధి. SLOకి సాధారణ విలువ “SLI ≤ లక్ష్యం” లేదా “తక్కువ పరిమితి ≤ SLI ≤ ఎగువ పరిమితి”. ఉదాహరణకు, SLOని 100 మిల్లీసెకన్ల కంటే తక్కువ సెర్చ్ క్వెరీ లాటెన్సీకి సెట్ చేయడం ద్వారా షేక్స్‌పియర్ శోధన ఫలితాలను “వేగంగా” అందించాలని మేము నిర్ణయించుకోవచ్చు.

సరైన SLOని ఎంచుకోవడం ఒక క్లిష్టమైన ప్రక్రియ. ముందుగా, మీరు ఎల్లప్పుడూ నిర్దిష్ట విలువను ఎంచుకోలేరు. మీ సేవకు బాహ్య ఇన్‌కమింగ్ HTTP అభ్యర్థనల కోసం, సెకనుకు ప్రశ్న (QPS) మెట్రిక్ ప్రాథమికంగా మీ సేవను సందర్శించాలనే మీ వినియోగదారుల కోరికను బట్టి నిర్ణయించబడుతుంది మరియు మీరు దాని కోసం SLOని సెట్ చేయలేరు.

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

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

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

ఒప్పందాలు

సేవా స్థాయి ఒప్పందం అనేది మీ వినియోగదారులతో వారు కలిగి ఉన్న SLOలను కలవడం (లేదా కలవకపోవడం) యొక్క పరిణామాలను కలిగి ఉన్న స్పష్టమైన లేదా అవ్యక్త ఒప్పందం. పరిణామాలు ఆర్థికంగా ఉన్నప్పుడు చాలా సులభంగా గుర్తించబడతాయి-రాయితీ లేదా జరిమానా-కానీ అవి ఇతర రూపాలను తీసుకోవచ్చు. SLOలు మరియు SLAల మధ్య వ్యత్యాసం గురించి మాట్లాడటానికి సులభమైన మార్గం ఏమిటంటే, "SLOలు కలుసుకోకపోతే ఏమి జరుగుతుంది?" స్పష్టమైన పరిణామాలు లేకుంటే, మీరు దాదాపుగా SLOని చూస్తున్నారు.

SLAలు వ్యాపారం మరియు ఉత్పత్తి నిర్ణయాలతో సన్నిహితంగా ముడిపడి ఉన్నందున SLAలను రూపొందించడంలో SRE సాధారణంగా పాల్గొనదు. SRE, అయితే, విఫలమైన SLOల యొక్క పరిణామాలను తగ్గించడంలో సహాయం చేస్తుంది. వారు SLIని నిర్ణయించడంలో కూడా సహాయపడగలరు: సహజంగానే, ఒప్పందంలో SLOని కొలవడానికి ఒక ఆబ్జెక్టివ్ మార్గం ఉండాలి లేదా అసమ్మతి ఉంటుంది.

పబ్లిక్ SLA లేని ముఖ్యమైన సేవకు Google శోధన ఒక ఉదాహరణ: మేము శోధనను వీలైనంత సమర్థవంతంగా ఉపయోగించాలని మేము కోరుకుంటున్నాము, కానీ మేము ప్రపంచంతో ఒప్పందంపై సంతకం చేయలేదు. అయినప్పటికీ, శోధన అందుబాటులో లేకుంటే పరిణామాలు ఇప్పటికీ ఉన్నాయి - అందుబాటులో లేకపోవడం వల్ల మా ప్రతిష్ట తగ్గుతుంది అలాగే ప్రకటనల ఆదాయం తగ్గుతుంది. పని కోసం Google వంటి అనేక ఇతర Google సేవలు వినియోగదారులతో స్పష్టమైన సేవా స్థాయి ఒప్పందాలను కలిగి ఉన్నాయి. నిర్దిష్ట సేవకు SLA ఉందా లేదా అనే దానితో సంబంధం లేకుండా, SLI మరియు SLOలను నిర్వచించడం మరియు సేవను నిర్వహించడానికి వాటిని ఉపయోగించడం ముఖ్యం.

చాలా సిద్ధాంతం - ఇప్పుడు అనుభవించడానికి.

ఆచరణలో సూచికలు

సేవా స్థాయిని కొలవడానికి తగిన కొలమానాలను ఎంచుకోవడం చాలా ముఖ్యం అని మేము నిర్ధారించినందున, సేవ లేదా సిస్టమ్‌కు సంబంధించి ఏ కొలమానాలు ముఖ్యమైనవో ఇప్పుడు మీకు ఎలా తెలుసు?

మీరు మరియు మీ వినియోగదారులు దేని గురించి శ్రద్ధ వహిస్తారు?

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

సేవలను సాధారణంగా వాటికి సంబంధించిన SLI పరంగా అనేక భాగాలుగా విభజించవచ్చు:

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

సూచికల సేకరణ

బోర్గ్‌మోన్ (క్రింద చూడండి) వంటి పర్యవేక్షణ వ్యవస్థను ఉపయోగించి అనేక సేవా స్థాయి సూచికలు సర్వర్ వైపు సహజంగా సేకరించబడతాయి. చాప్టర్ 10 సమయ శ్రేణి డేటా ఆధారంగా అలర్ట్‌లను ప్రాక్టీస్ చేయండి) లేదా ప్రోమేథియస్, లేదా కాలానుగుణంగా లాగ్‌లను విశ్లేషించడం, స్థితి 500తో HTTP ప్రతిస్పందనలను గుర్తించడం. అయితే, క్లయింట్-వైపు పర్యవేక్షణ లేకపోవడం వల్ల ప్రభావితం చేసే అనేక సమస్యలను కోల్పోయే అవకాశం ఉన్నందున, కొన్ని సిస్టమ్‌లు క్లయింట్ వైపు మెట్రిక్‌ల సేకరణను కలిగి ఉండాలి. వినియోగదారులు, కానీ సర్వర్ వైపు కొలమానాలను ప్రభావితం చేయవద్దు. ఉదాహరణకు, మా షేక్స్‌పియర్ శోధన పరీక్ష అప్లికేషన్ యొక్క బ్యాకెండ్ ప్రతిస్పందన జాప్యంపై దృష్టి సారించడం వలన JavaScript సమస్యల కారణంగా వినియోగదారు వైపు జాప్యం ఏర్పడవచ్చు: ఈ సందర్భంలో, పేజీని ప్రాసెస్ చేయడానికి బ్రౌజర్ ఎంత సమయం తీసుకుంటుందో కొలవడం మంచి మెట్రిక్.

సమూహనం

సరళత మరియు వాడుకలో సౌలభ్యం కోసం, మేము తరచుగా ముడి కొలతలను కలుపుతాము. ఇది జాగ్రత్తగా చేయాలి.

కొన్ని కొలమానాలు సెకనుకు అభ్యర్థనల వలె సరళంగా కనిపిస్తాయి, అయితే ఇది స్పష్టంగా సూటిగా ఉండే కొలత కూడా కాలక్రమేణా డేటాను అవ్యక్తంగా కలుపుతుంది. కొలత సెకనుకు ఒకసారి ప్రత్యేకంగా స్వీకరించబడిందా లేదా నిమిషానికి వచ్చిన అభ్యర్థనల సంఖ్య కంటే కొలత సగటుగా ఉందా? తరువాతి ఎంపిక కొన్ని సెకన్ల పాటు ఉండే చాలా ఎక్కువ తక్షణ అభ్యర్థనలను దాచగలదు. ఒక సెకనుకు 200 అభ్యర్థనలను సరి సంఖ్యలతో మరియు మిగిలిన సమయంలో 0తో అందించే సిస్టమ్‌ను పరిగణించండి. సెకనుకు 100 అభ్యర్థనల సగటు విలువ రూపంలో స్థిరాంకం మరియు తక్షణ లోడ్ రెండుసార్లు ఒకే విషయం కాదు. అదేవిధంగా, సగటు ప్రశ్న లేటెన్సీలు ఆకర్షణీయంగా అనిపించవచ్చు, కానీ ఇది ఒక ముఖ్యమైన వివరాలను దాచిపెడుతుంది: చాలా ప్రశ్నలు వేగంగా ఉండే అవకాశం ఉంది, కానీ చాలా ప్రశ్నలు నెమ్మదిగా ఉంటాయి.

చాలా సూచికలు సగటుల కంటే పంపిణీలుగా బాగా చూడబడతాయి. ఉదాహరణకు, SLI జాప్యం కోసం, కొన్ని అభ్యర్థనలు త్వరగా ప్రాసెస్ చేయబడతాయి, కొన్ని ఎల్లప్పుడూ ఎక్కువ సమయం పడుతుంది, కొన్నిసార్లు ఎక్కువ సమయం పడుతుంది. సాధారణ సగటు ఈ దీర్ఘ ఆలస్యాలను దాచగలదు. బొమ్మ ఒక ఉదాహరణను చూపుతుంది: ఒక సాధారణ అభ్యర్థన సర్వ్ చేయడానికి సుమారు 50 ms పడుతుంది, అయితే 5% అభ్యర్థనలు 20 రెట్లు నెమ్మదిగా ఉంటాయి! సగటు జాప్యం ఆధారంగా మాత్రమే పర్యవేక్షించడం మరియు హెచ్చరిక చేయడం రోజంతా ప్రవర్తనలో మార్పులను చూపదు, వాస్తవానికి కొన్ని అభ్యర్థనల ప్రాసెసింగ్ సమయంలో (అత్యున్నత పంక్తి) గుర్తించదగిన మార్పులు ఉన్నాయి.

50, 85, 95, మరియు 99 పర్సంటైల్ సిస్టమ్ జాప్యం. Y అక్షం లాగరిథమిక్ ఆకృతిలో ఉంది.

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

గణాంక లోపాలపై గమనిక

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

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

సూచికలను ప్రామాణికం చేయండి

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

• అగ్రిగేషన్ విరామాలు: “సగటున 1 నిమిషం కంటే ఎక్కువ”
• అగ్రిగేషన్ ప్రాంతాలు: “క్లస్టర్‌లోని అన్ని టాస్క్‌లు”
• ఎంత తరచుగా కొలతలు తీసుకోబడతాయి: "ప్రతి 10 సెకన్లు"
• ఏ అభ్యర్థనలు చేర్చబడ్డాయి: "HTTP బ్లాక్ బాక్స్ పర్యవేక్షణ ఉద్యోగాల నుండి పొందండి"
• డేటా ఎలా పొందబడుతుంది: "సర్వర్‌లో కొలవబడిన మా పర్యవేక్షణకు ధన్యవాదాలు"
• డేటా యాక్సెస్ జాప్యం: "చివరి బైట్‌కి సమయం"

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

ఆచరణలో లక్ష్యాలు

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

లక్ష్యాలను నిర్వచించండి

గరిష్ట స్పష్టత కోసం, SLOలను ఎలా కొలుస్తారు మరియు అవి చెల్లుబాటు అయ్యే పరిస్థితులను నిర్వచించాలి. ఉదాహరణకు, మేము ఈ క్రింది వాటిని చెప్పగలము (రెండవ పంక్తి మొదటిది వలె ఉంటుంది, కానీ SLI డిఫాల్ట్‌లను ఉపయోగిస్తుంది):

• గెట్ RPC కాల్‌లలో 99% (సగటున 1 నిమిషం) 100ms కంటే తక్కువ వ్యవధిలో పూర్తవుతుంది (అన్ని బ్యాకెండ్ సర్వర్‌లలో కొలుస్తారు).
• 99% Get RPC కాల్‌లు 100ms కంటే తక్కువ వ్యవధిలో పూర్తవుతాయి.

పనితీరు వక్రరేఖల ఆకృతి ముఖ్యమైనది అయితే, మీరు బహుళ SLOలను పేర్కొనవచ్చు:

• 90% గెట్ RPC కాల్‌లు 1 ms కంటే తక్కువ వ్యవధిలో పూర్తయ్యాయి.
• 99% గెట్ RPC కాల్‌లు 10 ms కంటే తక్కువ వ్యవధిలో పూర్తయ్యాయి.
• 99.9% గెట్ RPC కాల్‌లు 100 ms కంటే తక్కువ వ్యవధిలో పూర్తయ్యాయి.

మీ వినియోగదారులు భిన్నమైన పనిభారాన్ని సృష్టిస్తే: బల్క్ ప్రాసెసింగ్ (దీని కోసం నిర్గమాంశ ముఖ్యమైనది) మరియు ఇంటరాక్టివ్ ప్రాసెసింగ్ (దీని కోసం జాప్యం ముఖ్యం), ప్రతి లోడ్ తరగతికి ప్రత్యేక లక్ష్యాలను నిర్వచించడం విలువైనదే కావచ్చు:

• 95% కస్టమర్ అభ్యర్థనలకు నిర్గమాంశ అవసరం. <1 సె.కి అమలు చేయబడిన RPC కాల్‌ల గణనను సెట్ చేయండి.
• 99% క్లయింట్లు జాప్యం గురించి శ్రద్ధ వహిస్తారు. ట్రాఫిక్ <1 KB మరియు నడుస్తున్న <10 msతో RPC కాల్‌ల గణనను సెట్ చేయండి.

SLOలు 100% సమయానికి చేరుకుంటాయని పట్టుబట్టడం అవాస్తవికం మరియు అవాంఛనీయమైనది: ఇది కొత్త కార్యాచరణ మరియు విస్తరణను పరిచయం చేసే వేగాన్ని తగ్గిస్తుంది మరియు ఖరీదైన పరిష్కారాలు అవసరం. బదులుగా, ఎర్రర్ బడ్జెట్‌ను అనుమతించడం ఉత్తమం - సిస్టమ్ డౌన్‌టైమ్ శాతం అనుమతించబడింది - మరియు ఈ విలువను ప్రతిరోజూ లేదా వారానికొకసారి పర్యవేక్షించండి. సీనియర్ మేనేజ్‌మెంట్ నెలవారీ లేదా త్రైమాసిక మూల్యాంకనాలను కోరుకోవచ్చు. (ఎర్రర్ బడ్జెట్ అనేది మరొక SLOతో పోల్చడానికి ఒక SLO మాత్రమే.)

SLO ఉల్లంఘనల శాతాన్ని ఎర్రర్ బడ్జెట్‌తో పోల్చవచ్చు (చాప్టర్ 3 మరియు విభాగం చూడండి "ఎర్రర్ బడ్జెట్‌ల కోసం ప్రేరణ"), కొత్త విడుదలలను ఎప్పుడు అమలు చేయాలో నిర్ణయించే ప్రక్రియకు ఇన్‌పుట్‌గా ఉపయోగించే వ్యత్యాస విలువతో.

లక్ష్య విలువలను ఎంచుకోవడం

ఎంచుకున్న SLIలు, SLOలు (మరియు బహుశా SLAలు)లో తప్పనిసరిగా ప్రతిబింబించే ఉత్పత్తి మరియు వ్యాపార ఆసక్తుల కారణంగా ప్రణాళికా విలువలను (SLOలు) ఎంచుకోవడం పూర్తిగా సాంకేతిక కార్యకలాపం కాదు. అదేవిధంగా, సిబ్బంది, మార్కెట్‌కు సమయం, పరికరాల లభ్యత మరియు ఫైనాన్సింగ్‌కు సంబంధించిన సమస్యలకు సంబంధించి సమాచారాన్ని మార్పిడి చేయాల్సి ఉంటుంది. SRE ఈ సంభాషణలో భాగంగా ఉండాలి మరియు విభిన్న ఎంపికల యొక్క నష్టాలు మరియు సాధ్యతను అర్థం చేసుకోవడంలో సహాయపడాలి. మేము మరింత ఉత్పాదక చర్చను నిర్ధారించడంలో సహాయపడే కొన్ని ప్రశ్నలతో ముందుకు వచ్చాము:

ప్రస్తుత పనితీరు ఆధారంగా లక్ష్యాన్ని ఎంచుకోవద్దు.
సిస్టమ్ యొక్క బలాలు మరియు పరిమితులను అర్థం చేసుకోవడం ముఖ్యమైనది అయితే, తార్కికం లేకుండా కొలమానాలను స్వీకరించడం వ్యవస్థను నిర్వహించకుండా మిమ్మల్ని నిరోధించవచ్చు: గణనీయమైన పునఃరూపకల్పన లేకుండా సాధించలేని లక్ష్యాలను సాధించడానికి వీరోచిత ప్రయత్నాలు అవసరం.

సరళంగా ఉంచండి
సంక్లిష్టమైన SLI లెక్కలు సిస్టమ్ పనితీరులో మార్పులను దాచవచ్చు మరియు సమస్య యొక్క కారణాన్ని కనుగొనడం కష్టతరం చేస్తుంది.

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

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

పరిపూర్ణతను వెంబడించవద్దు
లోడ్‌లో ఉన్న సిస్టమ్ ప్రవర్తన గురించి మీరు మరింత తెలుసుకున్నప్పుడు మీరు SLOల నిర్వచనాలు మరియు లక్ష్యాలను ఎప్పటికప్పుడు మెరుగుపరచవచ్చు. మీరు సాధించలేనిదిగా భావించినప్పుడు రిలాక్స్‌గా ఉండాల్సిన మితిమీరిన కఠినమైన లక్ష్యాన్ని ఎంచుకోవడం కంటే కాలక్రమేణా మీరు మెరుగుపరిచే తేలియాడే లక్ష్యంతో ప్రారంభించడం ఉత్తమం.

SLOలు SREలు మరియు ఉత్పత్తి డెవలపర్‌ల కోసం పనికి ప్రాధాన్యత ఇవ్వడంలో కీలకమైన డ్రైవర్‌గా ఉండగలవు ఎందుకంటే అవి వినియోగదారులకు సంబంధించిన ఆందోళనను ప్రతిబింబిస్తాయి. అభివృద్ధి బృందానికి మంచి SLO ఒక ఉపయోగకరమైన అమలు సాధనం. కానీ అతిగా దూకుడుగా ఉండే SLOని సాధించడానికి టీమ్ వీరోచిత ప్రయత్నాలు చేసినట్లయితే, లేదా SLO చాలా తక్కువగా ఉన్నట్లయితే పేలవమైన ఉత్పత్తిని సాధించడానికి పేలవంగా రూపొందించబడిన SLO వ్యర్థమైన పనికి దారి తీస్తుంది. SLO ఒక శక్తివంతమైన లివర్, దానిని తెలివిగా ఉపయోగించండి.

మీ కొలతలను నియంత్రించండి

SLI మరియు SLO వ్యవస్థలను నిర్వహించడానికి ఉపయోగించే కీలక అంశాలు:

• SLI వ్యవస్థలను పర్యవేక్షించండి మరియు కొలవండి.
• SLIని SLOకి సరిపోల్చండి మరియు చర్య అవసరమా అని నిర్ణయించుకోండి.
• చర్య అవసరమైతే, లక్ష్యాన్ని సాధించడానికి ఏమి జరగాలో గుర్తించండి.
• ఈ చర్యను పూర్తి చేయండి.

ఉదాహరణకు, దశ 2 అభ్యర్థన సమయం ముగిసిందని మరియు ఏమీ చేయకపోతే కొన్ని గంటల్లో SLO విచ్ఛిన్నం అవుతుందని చూపితే, దశ 3 సర్వర్‌లు CPU కట్టుబడి ఉన్నాయని మరియు మరిన్ని సర్వర్‌లను జోడించడం వలన లోడ్ పంపిణీ చేయబడుతుందనే పరికల్పనను పరీక్షించడం ఉండవచ్చు. SLO లేకుండా, చర్య తీసుకోవాలో (లేదా ఎప్పుడు) మీకు తెలియదు.

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

మీ వినియోగదారుల కోసం వాస్తవిక అంచనాలను సెట్ చేయడానికి, కింది వ్యూహాలలో ఒకటి లేదా రెండింటిని ఉపయోగించండి:

• భద్రత యొక్క మార్జిన్‌ను నిర్వహించండి. వినియోగదారులకు ప్రచారం చేయబడిన దాని కంటే కఠినమైన అంతర్గత SLOని ఉపయోగించండి. సమస్యలు బాహ్యంగా కనిపించే ముందు వాటిపై స్పందించడానికి ఇది మీకు అవకాశాన్ని ఇస్తుంది. SLO బఫర్ సిస్టమ్ పనితీరును ప్రభావితం చేసే విడుదలలను ఇన్‌స్టాల్ చేస్తున్నప్పుడు భద్రతా మార్జిన్‌ను కలిగి ఉండటానికి మిమ్మల్ని అనుమతిస్తుంది మరియు డౌన్‌టైమ్‌తో వినియోగదారులను నిరాశపరచకుండా సిస్టమ్ నిర్వహించడం సులభం అని నిర్ధారించుకోండి.
• వినియోగదారు అంచనాలను మించవద్దు. వినియోగదారులు మీరు అందించే వాటిపై ఆధారపడి ఉంటారు, మీరు చెప్పేదానిపై కాదు. మీ సేవ యొక్క వాస్తవ పనితీరు పేర్కొన్న SLO కంటే మెరుగ్గా ఉంటే, వినియోగదారులు ప్రస్తుత పనితీరుపై ఆధారపడతారు. మీరు సిస్టమ్‌ను ఉద్దేశపూర్వకంగా మూసివేయడం లేదా తేలికపాటి లోడ్‌ల క్రింద పనితీరును పరిమితం చేయడం ద్వారా అధిక ఆధారపడటాన్ని నివారించవచ్చు.

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

ఆచరణలో ఒప్పందాలు

SLAని సృష్టించడానికి వ్యాపార మరియు చట్టపరమైన బృందాలు దానిని ఉల్లంఘించినందుకు పరిణామాలు మరియు జరిమానాలను నిర్వచించడం అవసరం. SLAలో ఉన్న SLOలను కలుసుకోవడంలో సంభావ్య సవాళ్లను అర్థం చేసుకోవడంలో వారికి సహాయం చేయడం SRE పాత్ర. SLOలను సృష్టించడానికి చాలా సిఫార్సులు SLAలకు కూడా వర్తిస్తాయి. మీరు వినియోగదారులకు వాగ్దానం చేసే విషయంలో సంప్రదాయబద్ధంగా ఉండటం తెలివైన పని, ఎందుకంటే మీ వద్ద ఎంత ఎక్కువ ఉంటే, అసమంజసంగా లేదా కలవడం కష్టంగా అనిపించే SLAలను మార్చడం లేదా తీసివేయడం కష్టం.

అనువాదాన్ని చివరి వరకు చదివినందుకు ధన్యవాదాలు. పర్యవేక్షణ గురించి నా టెలిగ్రామ్ ఛానెల్‌కు సభ్యత్వాన్ని పొందండి పర్యవేక్షణ_అది и మీడియంలో బ్లాగ్.

మూలం: www.habr.com