వెబ్‌నార్ యొక్క లిప్యంతరీకరణ "SRE - హైప్ లేదా భవిష్యత్తు?"

వెబ్‌నార్‌లో పేలవమైన ఆడియో ఉంది, కాబట్టి మేము దానిని లిప్యంతరీకరించాము.

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

ముందుగా, SRE అంటే ఏమిటి - సైట్ రిలయబిలిటీ ఇంజనీరింగ్ గురించి మాట్లాడుకుందాం. మరియు అది ఒక ప్రత్యేక స్థానంగా, ప్రత్యేక దిశగా ఎలా కనిపించింది. సాంప్రదాయ డెవలప్‌మెంట్ సర్కిల్‌లలో, Dev మరియు Ops రెండు పూర్తిగా భిన్నమైన టీమ్‌లు, సాధారణంగా రెండు పూర్తిగా భిన్నమైన లక్ష్యాలతో ఉంటాయి. అభివృద్ధి బృందం యొక్క లక్ష్యం కొత్త ఫీచర్‌లను రూపొందించడం మరియు వ్యాపార అవసరాలను తీర్చడం. Ops బృందం యొక్క లక్ష్యం ప్రతిదీ పని చేస్తుందని మరియు ఏమీ విచ్ఛిన్నం కాకుండా చూసుకోవడం. సహజంగానే, ఈ లక్ష్యాలు ఒకదానికొకటి నేరుగా విరుద్ధంగా ఉంటాయి: ప్రతిదీ పని చేయడానికి మరియు ఏమీ విచ్ఛిన్నం కాకుండా, కొత్త లక్షణాలను వీలైనంత తక్కువగా రూపొందించండి. దీని కారణంగా, ఇప్పుడు DevOps అని పిలువబడే పద్దతి పరిష్కరించడానికి ప్రయత్నిస్తున్న అనేక అంతర్గత వైరుధ్యాలు ఉన్నాయి.

సమస్య ఏమిటంటే, మాకు DevOps యొక్క స్పష్టమైన నిర్వచనం మరియు DevOps యొక్క స్పష్టమైన అమలు లేదు. నేను 2 సంవత్సరాల క్రితం యెకాటెరిన్‌బర్గ్‌లో జరిగిన ఒక సమావేశంలో మాట్లాడాను మరియు ఇప్పటి వరకు DevOps విభాగం “DevOps అంటే ఏమిటి” అనే నివేదికతో ప్రారంభమైంది. 2017లో, డెవొప్స్‌కి దాదాపు 10 ఏళ్లు నిండాయి, అయితే అది ఏమిటో మేము ఇంకా వాదిస్తున్నాము. మరియు ఇది చాలా విచిత్రమైన పరిస్థితి, ఇది కొన్ని సంవత్సరాల క్రితం Google పరిష్కరించడానికి ప్రయత్నించింది.

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

నిర్మాణ సమస్యలను పరిష్కరించే SRE ఇంజనీర్లు ఉన్నారనే వాస్తవం ద్వారా SRE బృందాలలో DevOps నమూనా అమలు చేయబడుతుందని తేలింది. ఇదిగో, Dev మరియు Ops మధ్య 8 సంవత్సరాలుగా ప్రజలు మాట్లాడుకుంటున్న అదే కనెక్షన్. SRE యొక్క పాత్ర ఒక వాస్తుశిల్పి వలె ఉంటుంది, ఇందులో కొత్తవారు SREలు కాలేరు. వారి కెరీర్ ప్రారంభంలో ఉన్న వ్యక్తులకు ఇంకా ఎటువంటి అనుభవం లేదు, అవసరమైన జ్ఞానం యొక్క వెడల్పు లేదు. ఎందుకంటే SREకి ఖచ్చితంగా ఏమి మరియు ఎప్పుడు తప్పు జరుగుతుందనే దాని గురించి చాలా సూక్ష్మమైన జ్ఞానం అవసరం. అందువల్ల, కంపెనీ లోపల మరియు వెలుపల ఒక నియమం వలె ఇక్కడ కొంత అనుభవం అవసరం.

SRE మరియు devops మధ్య వ్యత్యాసం వివరించబడుతుందా అని వారు అడుగుతారు. ఆమె ఇప్పుడే వివరించబడింది. సంస్థలో SRE స్థానం గురించి మనం మాట్లాడవచ్చు. ఈ క్లాసిక్ DevOps విధానం వలె కాకుండా, Ops ఇప్పటికీ ప్రత్యేక విభాగంగా ఉంది, SRE అభివృద్ధి బృందంలో భాగం. వారు ఉత్పత్తి అభివృద్ధిలో పాల్గొంటారు. SRE అనేది ఒక డెవలపర్ నుండి మరొక డెవలపర్‌కు బదిలీ అయ్యే ఒక విధానం కూడా ఉంది. వారు కోడ్ సమీక్షలలో అదే విధంగా పాల్గొంటారు, ఉదాహరణకు, UX డిజైనర్లు, డెవలపర్లు, కొన్నిసార్లు ఉత్పత్తి నిర్వాహకులు. SREలు అదే స్థాయిలో పని చేస్తాయి. మేము వాటిని ఆమోదించాలి, మేము వాటిని సమీక్షించాలి, తద్వారా ప్రతి విస్తరణ కోసం SRE ఇలా చెబుతుంది: “సరే, ఈ విస్తరణ, ఈ ఉత్పత్తి విశ్వసనీయతను ప్రతికూలంగా ప్రభావితం చేయదు. మరియు అది జరిగితే, కొన్ని ఆమోదయోగ్యమైన పరిమితుల్లో. దీని గురించి కూడా మాట్లాడతాం.

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

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

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

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

ఇప్పుడు SRE యొక్క ఆపరేషన్ కోసం ప్రమాణాల గురించి మాట్లాడుదాం. మరియు విశ్వసనీయత గురించి అన్నింటిలో మొదటిది. చిన్న కంపెనీలలో, స్టార్టప్‌లలో, సేవను బాగా వ్రాసినట్లయితే, ఉత్పత్తి బాగా మరియు సరిగ్గా వ్రాసినట్లయితే, అది పని చేస్తుందని, అది విచ్ఛిన్నం కాదని ప్రజలు భావించడం తరచుగా జరుగుతుంది. అంతే, మేము మంచి కోడ్ వ్రాస్తాము, కాబట్టి విచ్ఛిన్నం చేయడానికి ఏమీ లేదు. కోడ్ చాలా సులభం, విచ్ఛిన్నం చేయడానికి ఏమీ లేదు. మాకు పరీక్షలు అవసరం లేదని చెప్పే వ్యక్తుల గురించి ఇవి ఉన్నాయి, ఎందుకంటే, చూడండి, ఇవి మూడు VPI పద్ధతులు, ఇక్కడ ఎందుకు విచ్ఛిన్నం చేయాలి.

ఇదంతా తప్పు, వాస్తవానికి. మరియు ఈ వ్యక్తులు చాలా తరచుగా ఆచరణలో ఇటువంటి కోడ్ ద్వారా కరిచారు, ఎందుకంటే విషయాలు విరిగిపోతాయి. చాలా అనూహ్యమైన మార్గాల్లో కొన్నిసార్లు విషయాలు విరిగిపోతాయి. కొన్నిసార్లు ప్రజలు వద్దు అని అంటారు, ఇది ఎప్పటికీ జరగదు. మరియు ఇది అన్ని సమయాలలో జరుగుతుంది. ఇది తగినంత తరచుగా జరుగుతుంది. మరియు అందుకే ఎవరూ 100% లభ్యత కోసం ప్రయత్నించరు, ఎందుకంటే 100% లభ్యత ఎప్పుడూ జరగదు. ఇది కట్టుబాటు. అందువల్ల, మేము సేవ యొక్క లభ్యత గురించి మాట్లాడేటప్పుడు, మేము ఎల్లప్పుడూ తొమ్మిది గురించి మాట్లాడుతాము. 2 తొమ్మిది, 3 తొమ్మిది, 4 తొమ్మిది, 5 తొమ్మిది. మేము దీన్ని డౌన్‌టైమ్‌గా అనువదిస్తే, ఉదాహరణకు, 5 తొమ్మిది, అప్పుడు ఇది సంవత్సరానికి 5 నిమిషాల కంటే కొంచెం ఎక్కువ పనికిరాని సమయం, 2 తొమ్మిది అంటే 3,5 రోజుల పనికిరాని సమయం.

కానీ ఏదో ఒక సమయంలో POI, పెట్టుబడిపై రాబడి తగ్గడం స్పష్టంగా కనిపిస్తుంది. రెండు తొమ్మిది నుండి మూడు తొమ్మిదికి వెళ్లడం అంటే 3 రోజుల కంటే తక్కువ సమయ వ్యవధి. నాలుగు తొమ్మిది నుండి ఐదుకి వెళ్లడం వల్ల సంవత్సరానికి 47 నిమిషాలు డౌన్‌టైమ్ తగ్గుతుంది. మరియు వ్యాపారం కోసం ఇది క్లిష్టమైనది కాకపోవచ్చు. మరియు సాధారణంగా, అవసరమైన విశ్వసనీయత సాంకేతిక సమస్య కాదు, అన్నింటిలో మొదటిది, ఇది వ్యాపార సమస్య, ఇది ఉత్పత్తి సమస్య. ఉత్పత్తి యొక్క వినియోగదారులకు ఏ స్థాయి డౌన్‌టైమ్ ఆమోదయోగ్యమైనది, వారు ఏమి ఆశించారు, వారు ఎంత చెల్లిస్తారు, ఉదాహరణకు, వారు ఎంత డబ్బు కోల్పోతారు, సిస్టమ్ ఎంత డబ్బు కోల్పోతుంది.

ఇక్కడ ఒక ముఖ్యమైన ప్రశ్న ఏమిటంటే మిగిలిన భాగాల విశ్వసనీయత ఏమిటి. ఎందుకంటే 4 నైన్ల విశ్వసనీయత ఉన్న స్మార్ట్‌ఫోన్‌లో 5 మరియు 2 తొమ్మిదిల మధ్య వ్యత్యాసం కనిపించదు. స్థూలంగా చెప్పాలంటే, మీ సేవలోని స్మార్ట్‌ఫోన్‌లో సంవత్సరానికి 10 సార్లు ఏదైనా విచ్ఛిన్నమైతే, OS వైపు 8 సార్లు బ్రేక్‌డౌన్ సంభవించవచ్చు. వినియోగదారు దీనికి అలవాటు పడ్డారు మరియు సంవత్సరానికి మరొకసారి శ్రద్ధ చూపరు. పెరుగుతున్న విశ్వసనీయత మరియు లాభాలను పెంచే ధరను పరస్పరం అనుసంధానించడం అవసరం.
కేవలం SRE పుస్తకంలో 4 తొమ్మిది నుండి 3 తొమ్మిదికి పెంచడానికి మంచి ఉదాహరణ ఉంది. లభ్యత పెరుగుదల 0,1% కంటే కొంచెం తక్కువగా ఉందని తేలింది. మరియు సేవ యొక్క ఆదాయం సంవత్సరానికి $1 మిలియన్ అయితే, ఆదాయంలో పెరుగుదల $900. స్థోమతను తొమ్మిదికి పెంచడానికి సంవత్సరానికి $900 కంటే తక్కువ ఖర్చు చేస్తే, పెరుగుదల ఆర్థికంగా అర్థవంతంగా ఉంటుంది. ఇది సంవత్సరానికి 900 డాలర్ల కంటే ఎక్కువ ఖర్చు చేస్తే, అది ఇకపై అర్ధవంతం కాదు, ఎందుకంటే ఆదాయంలో పెరుగుదల కేవలం కార్మిక వ్యయాలు, వనరుల ఖర్చులను భర్తీ చేయదు. మరియు 3 తొమ్మిది మాకు సరిపోతాయి.

ఇది అన్ని అభ్యర్థనలు సమానంగా ఉండే సరళీకృత ఉదాహరణ. మరియు 3 తొమ్మిది నుండి 4 తొమ్మిదికి వెళ్లడం చాలా సులభం, కానీ అదే సమయంలో, ఉదాహరణకు, 2 తొమ్మిది నుండి 3కి వెళ్లడం, ఇది ఇప్పటికే 9 వేల డాలర్ల పొదుపు, ఇది ఆర్థికంగా అర్థం చేసుకోవచ్చు. సహజంగానే, వాస్తవానికి, రిజిస్ట్రేషన్ అభ్యర్థన యొక్క వైఫల్యం పేజీని ప్రదర్శించడంలో వైఫల్యం కంటే ఘోరంగా ఉంటుంది, అభ్యర్థనలు వేర్వేరు బరువులను కలిగి ఉంటాయి. వారు వ్యాపార దృక్కోణం నుండి పూర్తిగా భిన్నమైన ప్రమాణాన్ని కలిగి ఉండవచ్చు, కానీ ఏమైనప్పటికీ, ఒక నియమం వలె, మేము కొన్ని నిర్దిష్ట సేవల గురించి మాట్లాడకపోతే, ఇది చాలా నమ్మదగిన ఉజ్జాయింపు.
సేవ కోసం ఆర్కిటెక్చరల్ సొల్యూషన్‌ను ఎంచుకునేటప్పుడు SRE కోఆర్డినేటర్‌లలో ఒకరా అనే ప్రశ్న మాకు అందింది. దాని స్థిరత్వంలో నష్టం జరగకుండా, ఇప్పటికే ఉన్న మౌలిక సదుపాయాలలో ఏకీకరణ పరంగా చెప్పండి. అవును, SREలు, అదే విధంగా పుల్ రిక్వెస్ట్‌లు, కమిట్‌లు, రిలీజ్‌లు ఆర్కిటెక్చర్‌ను ప్రభావితం చేస్తాయి, కొత్త సేవల పరిచయం, మైక్రోసర్వీస్‌లు, కొత్త సొల్యూషన్స్ అమలు. అనుభవం కావాలి, అర్హతలు కావాలి అని ముందే ఎందుకు చెప్పాను. వాస్తవానికి, ఏదైనా నిర్మాణ మరియు సాఫ్ట్‌వేర్ పరిష్కారంలో నిరోధించే స్వరాలలో SRE ఒకటి. దీని ప్రకారం, ఒక ఇంజనీర్‌గా SRE, మొదటగా, కొన్ని నిర్దిష్ట నిర్ణయాలు విశ్వసనీయత, స్థిరత్వాన్ని ఎలా ప్రభావితం చేస్తాయో అర్థం చేసుకోవడమే కాకుండా, వ్యాపార అవసరాలకు ఎలా సంబంధం కలిగి ఉందో అర్థం చేసుకోవాలి మరియు ఏ కోణం నుండి ఇది ఆమోదయోగ్యమైనది మరియు ఏది కాదు.

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

SLA ఇలా ఉండవచ్చని అనుకుందాం. ఈ సేవ ఏడాది పొడవునా 99,95% అందుబాటులో ఉంటుంది. లేదా ప్రతి త్రైమాసికానికి 99 గంటలలోపు 3 క్లిష్టమైన మద్దతు టిక్కెట్‌లు మూసివేయబడతాయి. లేదా 85% ప్రశ్నలు ప్రతి నెలా 1,5 సెకన్లలోపు ప్రతిస్పందనలను పొందుతాయి. అంటే, లోపాలు మరియు వైఫల్యాలు చాలా సాధారణమైనవి అని మనం క్రమంగా అర్థం చేసుకుంటాము. ఇది ఆమోదయోగ్యమైన పరిస్థితి, మేము దానిని ప్లాన్ చేస్తున్నాము, మేము దానిని కొంత వరకు లెక్కించాము. అంటే, SRE తప్పులు చేయగల వ్యవస్థలను నిర్మిస్తుంది, ఇది తప్పులకు సాధారణంగా ప్రతిస్పందించాలి, వాటిని పరిగణనలోకి తీసుకోవాలి. మరియు సాధ్యమైనప్పుడల్లా, వారు లోపాలను వినియోగదారు గుర్తించని విధంగా లేదా గమనించే విధంగా నిర్వహించాలి, కానీ ఒక రకమైన ప్రత్యామ్నాయం ఉంది, దీనికి ధన్యవాదాలు ప్రతిదీ పూర్తిగా పడదు.

ఉదాహరణకు, మీరు YouTubeకి వీడియోను అప్‌లోడ్ చేసి, YouTube దాన్ని వెంటనే మార్చలేకపోతే, వీడియో చాలా పెద్దదిగా ఉంటే, ఫార్మాట్ సరైనది కానట్లయితే, అభ్యర్థన సహజంగా గడువు ముగిసినప్పుడు విఫలం కాదు, YouTube 502 లోపాన్ని ఇవ్వదు. , YouTube ఇలా చెబుతుంది: “మేము ప్రతిదీ సృష్టించాము, మీ వీడియో ప్రాసెస్ చేయబడుతోంది. ఇది దాదాపు 10 నిమిషాల్లో సిద్ధంగా ఉంటుంది." ఇది గ్రేస్ఫుల్ డిగ్రేడేషన్ సూత్రం, ఇది సుపరిచితం, ఉదాహరణకు, ఫ్రంట్-ఎండ్ డెవలప్‌మెంట్ నుండి, మీరు ఎప్పుడైనా దీన్ని చేసి ఉంటే.

మేము మాట్లాడే తదుపరి నిబంధనలు, విశ్వసనీయతతో, లోపాలతో, అంచనాలతో పనిచేయడానికి చాలా ముఖ్యమైనవి, MTBF మరియు MTTR. MTBF అనేది వైఫల్యాల మధ్య సగటు సమయం. MTTR కోలుకోవడానికి సగటు సమయం, రికవరీకి సగటు సమయం. అంటే, లోపం కనుగొనబడిన క్షణం నుండి ఎంత సమయం గడిచిపోయింది, లోపం కనిపించిన క్షణం నుండి సేవ పూర్తి సాధారణ ఆపరేషన్‌కు పునరుద్ధరించబడే వరకు. MTBF ప్రధానంగా కోడ్ నాణ్యతపై పని చేయడం ద్వారా పరిష్కరించబడింది. అంటే, SREలు "లేదు" అని చెప్పగల వాస్తవం. మరియు SRE "నో" అని చెప్పినప్పుడు, అతను హానికరమైనవాడు కాబట్టి కాదు, అతను చెడ్డవాడు కాబట్టి కాదు, లేకపోతే అందరూ బాధపడతారు కాబట్టి మొత్తం టీమ్ గురించి మీకు అవగాహన అవసరం.

మళ్ళీ, నేను తరచుగా ప్రస్తావించే పుస్తకంలో చాలా కథనాలు, చాలా పద్ధతులు, చాలా మార్గాలు ఉన్నాయి, ఇతర డెవలపర్లు SREని ద్వేషించడం ప్రారంభించకుండా ఎలా చూసుకోవాలి. MTTR, మరోవైపు, మీ SLOలపై పని చేయడం (సేవా స్థాయి లక్ష్యం). మరియు ఇది ఎక్కువగా ఆటోమేషన్. ఎందుకంటే, ఉదాహరణకు, మా SLO అనేది త్రైమాసికానికి 4 తొమ్మిదిల సమయ వ్యవధి. అంటే 3 నెలల్లో మనం 13 నిమిషాల పనికిరాని సమయాన్ని అనుమతించగలము. మరియు MTTR 13 నిమిషాల కంటే ఎక్కువ ఉండదని తేలింది. మేము 13 నిమిషాల్లో కనీసం 1 పనికిరాని సమయానికి ప్రతిస్పందిస్తే, మేము ఇప్పటికే త్రైమాసికానికి సంబంధించిన మొత్తం బడ్జెట్‌ను పూర్తి చేశామని దీని అర్థం. మేము SLOని విచ్ఛిన్నం చేస్తున్నాము. క్రాష్‌ను ప్రతిస్పందించడానికి మరియు పరిష్కరించడానికి 13 నిమిషాలు యంత్రానికి చాలా ఎక్కువ, కానీ మనిషికి చాలా తక్కువ. ఎందుకంటే ఒక వ్యక్తికి హెచ్చరిక వచ్చే వరకు, అతను స్పందించే వరకు, అతను లోపాన్ని అర్థం చేసుకునే వరకు, ఇది ఇప్పటికే చాలా నిమిషాలు. ఒక వ్యక్తి దానిని ఎలా పరిష్కరించాలో, సరిగ్గా ఏమి పరిష్కరించాలో, ఏమి చేయాలో అర్థం చేసుకునే వరకు, ఇది మరికొన్ని నిమిషాలు. మరియు వాస్తవానికి, మీరు సర్వర్‌ను పునఃప్రారంభించాల్సిన అవసరం ఉన్నప్పటికీ, అది మారినప్పుడు లేదా కొత్త నోడ్‌ను పెంచండి, అప్పుడు మానవీయంగా MTTR ఇప్పటికే 7-8 నిమిషాలు. ప్రక్రియను ఆటోమేట్ చేస్తున్నప్పుడు, MTTR చాలా తరచుగా రెండవ, కొన్నిసార్లు మిల్లీసెకన్లకు చేరుకుంటుంది. Google సాధారణంగా మిల్లీసెకన్ల గురించి మాట్లాడుతుంది, కానీ వాస్తవానికి, ప్రతిదీ అంత మంచిది కాదు.

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

నన్ను వివిరించనివ్వండి. త్రైమాసికానికి SLO సమయం మించిపోయినట్లయితే, పనికిరాని సమయం 13 నిమిషాలు కాకపోతే, 15 అయితే, దీనికి ఎవరు నిందించాలి? వాస్తవానికి, SRE నిందకు కారణం కావచ్చు, ఎందుకంటే అతను ఒక రకమైన చెడు నిబద్ధత లేదా విస్తరణను స్పష్టంగా చేశాడు. డేటా సెంటర్ అడ్మినిస్ట్రేటర్ దీనికి కారణం కావచ్చు, ఎందుకంటే అతను ఒకరకమైన షెడ్యూల్ చేయని నిర్వహణను నిర్వహించి ఉండవచ్చు. డేటా సెంటర్ అడ్మినిస్ట్రేటర్ దీనికి కారణమైతే, Ops నుండి వచ్చిన వ్యక్తి దీనికి కారణమని చెప్పవచ్చు, అతను SLOని సమన్వయం చేసినప్పుడు నిర్వహణను లెక్కించలేదు. మేనేజర్, టెక్నికల్ డైరెక్టర్ లేదా డేటా సెంటర్ కాంట్రాక్ట్‌పై సంతకం చేసిన మరియు డేటా సెంటర్ యొక్క SLA అవసరమైన డౌన్‌టైమ్ కోసం రూపొందించబడలేదనే దానిపై శ్రద్ధ చూపని వ్యక్తి దీనికి కారణమని చెప్పవచ్చు. తదనుగుణంగా, ఈ పరిస్థితిలో కొద్దికొద్దిగా నిందిస్తారు. మరియు ఈ పరిస్థితిలో ఎవరిపైనైనా నిందలు వేయడంలో అర్థం లేదని అర్థం. కానీ వాస్తవానికి అది సరిదిద్దాలి. అందుకే పోస్టుమార్టమ్‌లు ఉన్నాయి. మరియు మీరు చదివితే, ఉదాహరణకు, GitHub పోస్ట్‌మార్టమ్‌లు, మరియు ఇది ఎల్లప్పుడూ ప్రతి సందర్భంలో చాలా ఆసక్తికరమైన, చిన్న మరియు ఊహించని కథనంగా ఉంటే, ఈ నిర్దిష్ట వ్యక్తిని నిందించాడని ఎవరూ చెప్పలేదని మీరు భర్తీ చేయవచ్చు. నింద ఎల్లప్పుడూ నిర్దిష్ట అసంపూర్ణ ప్రక్రియలపై ఉంచబడుతుంది.

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

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

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

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

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

ఉత్పత్తిలో ప్రయోగాలు పెద్ద జట్లలో SREలో చాలా ముఖ్యమైనవి మరియు దాదాపు అంతర్భాగంగా ఉన్నాయని తేలింది. మరియు దీనిని సాధారణంగా ఖోస్ ఇంజనీరింగ్ అని పిలుస్తారు, ఇది Netflixలోని బృందం నుండి వచ్చింది, ఇది ఖోస్ మంకీ అనే యుటిలిటీని విడుదల చేసింది.
ఖోస్ మంకీ CI/CD పైప్‌లైన్‌కి కనెక్ట్ అవుతుంది మరియు ఉత్పత్తిలో ఉన్న సర్వర్‌ను యాదృచ్ఛికంగా క్రాష్ చేస్తుంది. మళ్ళీ, SRE నిర్మాణంలో, డౌన్డ్ సర్వర్ దానికదే చెడ్డది కాదు, అది ఊహించిన వాస్తవం గురించి మాట్లాడుతున్నాము. మరియు అది బడ్జెట్‌లో ఉంటే, అది ఆమోదయోగ్యమైనది మరియు వ్యాపారానికి హాని కలిగించదు. వాస్తవానికి, నెట్‌ఫ్లిక్స్‌లో తగినంత రిడెండెంట్ సర్వర్‌లు, తగినంత ప్రతిరూపణ ఉన్నాయి, తద్వారా ఇవన్నీ పరిష్కరించబడతాయి మరియు వినియోగదారు మొత్తంగా కూడా గమనించలేరు మరియు అంతకంటే ఎక్కువ ఎవరూ ఏ బడ్జెట్ కోసం ఒక సర్వర్‌ను వదిలివేయరు.

నెట్‌ఫ్లిక్స్ కొంతకాలం అలాంటి యుటిలిటీల మొత్తం సూట్‌ను కలిగి ఉంది, అందులో ఒకటి, ఖోస్ గొరిల్లా, అమెజాన్ యొక్క లభ్యత జోన్‌లలో ఒకదాన్ని పూర్తిగా మూసివేస్తుంది. ఏది ప్రభావితం చేస్తుందో, దేనిపై ఆధారపడి ఉంటుందో పూర్తిగా స్పష్టంగా తెలియనప్పుడు, మొదటగా, దాచిన డిపెండెన్సీలను బహిర్గతం చేయడానికి అలాంటి విషయాలు సహాయపడతాయి. మరియు ఇది, మీరు మైక్రోసర్వీస్‌తో పని చేస్తుంటే మరియు డాక్యుమెంటేషన్ సరిగ్గా లేకుంటే, ఇది మీకు తెలిసి ఉండవచ్చు. మరలా, మీరు స్టేజింగ్‌లో పట్టుకోలేని కోడ్‌లో లోపాలను పట్టుకోవడానికి ఇది చాలా సహాయపడుతుంది, ఎందుకంటే ఏదైనా స్టేజింగ్ ఖచ్చితమైన అనుకరణ కాదు, లోడ్ స్కేల్ భిన్నంగా ఉంటుంది, లోడ్ నమూనా భిన్నంగా ఉంటుంది, పరికరాలు కూడా, చాలా మటుకు, ఇతర. పీక్ లోడ్లు కూడా ఊహించనివి మరియు అనూహ్యమైనవి. మరియు అటువంటి పరీక్ష, మళ్ళీ బడ్జెట్‌కు మించినది కాదు, స్టేజింగ్, ఆటోటెస్ట్‌లు, CI / CD పైప్‌లైన్ ఎప్పటికీ పట్టుకోలేని మౌలిక సదుపాయాలలో లోపాలను పట్టుకోవడానికి బాగా సహాయపడుతుంది. మరియు మీ బడ్జెట్‌లో ఇవన్నీ చేర్చబడినంత కాలం, మీ సేవ అక్కడ తగ్గిపోయినప్పటికీ పర్వాలేదు, ఇది చాలా భయానకంగా అనిపించినప్పటికీ, సర్వర్ డౌన్ అయ్యింది, ఏమి పీడకల. లేదు, ఇది సాధారణం, ఇది మంచిది, ఇది దోషాలను పట్టుకోవడంలో సహాయపడుతుంది. మీకు బడ్జెట్ ఉంటే, మీరు దానిని ఖర్చు చేయవచ్చు.

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

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

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

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

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

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

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

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

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

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

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

SRE సాధనాల గురించి ఒక ప్రశ్న ఉంది. అంటే, ప్రతి ఒక్కరూ ఉపయోగించని SREలు ప్రత్యేకంగా ఏదైనా ఉపయోగించగలరా. వాస్తవానికి, కొన్ని అత్యంత ప్రత్యేకమైన యుటిలిటీలు ఉన్నాయి, ఉదాహరణకు, లోడ్‌లను అనుకరించే లేదా కానరీ A / B పరీక్షలో నిమగ్నమైన సాఫ్ట్‌వేర్ రకం ఉంది. కానీ ప్రాథమికంగా SRE టూల్‌కిట్ మీ డెవలపర్‌లు ఇప్పటికే ఉపయోగిస్తున్నారు. ఎందుకంటే SRE డెవలప్‌మెంట్ టీమ్‌తో నేరుగా ఇంటరాక్ట్ అవుతుంది. మరియు మీకు విభిన్న సాధనాలు ఉంటే, సమకాలీకరించడానికి సమయం పడుతుందని తేలింది. ప్రత్యేకించి SRE లు పెద్ద టీమ్‌లలో పనిచేస్తే, పెద్ద కంపెనీలలో అనేక జట్లు ఉంటే, కంపెనీ వ్యాప్త స్టాండర్డైజేషన్ ఇక్కడ చాలా సహాయపడుతుంది, ఎందుకంటే 50 టీమ్‌లలో 50 విభిన్న యుటిలిటీలను ఉపయోగించినట్లయితే, SRE తప్పనిసరిగా వాటిని తెలుసుకోవాలి. అన్ని. మరియు వాస్తవానికి ఇది ఎప్పటికీ జరగదు. మరియు పని నాణ్యత, కనీసం కొన్ని జట్ల నియంత్రణ నాణ్యత గణనీయంగా తగ్గుతుంది.

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

స్లర్మ్ SRE అనేది మూడు రోజుల ఇంటెన్సివ్ కోర్సు, ఇది నేను ఇప్పుడు మాట్లాడుతున్న దాని గురించి మాట్లాడుతుంది, కానీ చాలా లోతుగా, నిజమైన కేసులతో, అభ్యాసంతో, మొత్తం ఇంటెన్సివ్ ఆచరణాత్మక పనిని లక్ష్యంగా చేసుకుంటుంది. ప్రజలు జట్లుగా విభజించబడతారు. మీరందరూ నిజమైన కేసులపై పని చేస్తారు. దీని ప్రకారం, మాకు Booking.com బోధకులు ఇవాన్ క్రుగ్లోవ్ మరియు బెన్ టైలర్ ఉన్నారు. మేము శాన్ ఫ్రాన్సిస్కో నుండి Google నుండి అద్భుతమైన యూజీన్ బరబ్బాస్‌ని కలిగి ఉన్నాము. మరియు నేను మీకు కూడా ఒక విషయం చెబుతాను. కాబట్టి మమ్మల్ని తప్పకుండా సందర్శించండి.
కాబట్టి, గ్రంథ పట్టిక. SREలో సూచనలు ఉన్నాయి. మొదటిది అదే పుస్తకంలో, లేదా Google రాసిన SRE గురించి 2 పుస్తకాలపై. మరొకటి SLA, SLI, SLO పై చిన్న కథనం, ఇక్కడ నిబంధనలు మరియు వాటి అప్లికేషన్ కొంచెం వివరంగా ఉంటాయి. తదుపరి 3 వివిధ కంపెనీలలో SRE గురించి నివేదికలు. ప్రధమ - SREకి కీలు, ఇది Google యొక్క బెన్ ట్రైనర్ నుండి ఒక కీనోట్. రెండవ - డ్రాప్‌బాక్స్‌లో SRE. మూడవది మళ్ళీ Googleకి SRE. నుండి నాల్గవ నివేదిక Netflixలో SRE, ఇది 5 దేశాలలో కేవలం 190 కీలక SRE ఉద్యోగులను కలిగి ఉంది. వీటన్నింటిని చూడటం చాలా ఆసక్తికరంగా ఉంది, ఎందుకంటే DevOps అంటే వివిధ కంపెనీలకు మరియు విభిన్న బృందాలకు కూడా చాలా భిన్నమైన విషయాలను సూచిస్తుంది, SREకి ఒకే విధమైన పరిమాణాల కంపెనీలలో కూడా చాలా భిన్నమైన బాధ్యతలు ఉంటాయి.

గందరగోళ ఇంజనీరింగ్ సూత్రాలపై మరో 2 లింక్‌లు: (1), (2). మరియు ముగింపులో అద్భుతమైన జాబితాల సిరీస్ నుండి 3 జాబితాలు ఉన్నాయి గందరగోళ ఇంజనీరింగ్, గురించి SRE మరియు గురించి SRE టూల్‌కిట్. SREలో జాబితా చాలా పెద్దది, ఇది అన్నింటిని చూడవలసిన అవసరం లేదు, సుమారు 200 కథనాలు ఉన్నాయి. కెపాసిటీ ప్లానింగ్ గురించి మరియు దోషరహిత పోస్ట్‌మార్టం గురించి కథనాలను నేను బాగా సిఫార్సు చేస్తున్నాను.

ఆసక్తికరమైన వ్యాసం: జీవిత ఎంపికగా SRE

ఈ సమయంలో నా మాట విన్నందుకు ధన్యవాదాలు. మీరు ఏదో నేర్చుకున్నారని ఆశిస్తున్నాను. ఇంకా ఎక్కువ తెలుసుకోవడానికి మీ వద్ద తగినంత మెటీరియల్ ఉందని ఆశిస్తున్నాను. మరి కలుద్దాం. ఫిబ్రవరిలో ఆశిస్తున్నాము.
వెబ్‌నార్‌ను ఎడ్వర్డ్ మెద్వెదేవ్ హోస్ట్ చేశారు.

PS: చదవడానికి ఇష్టపడే వారి కోసం, ఎడ్వర్డ్ సూచనల జాబితాను ఇచ్చారు. ఆచరణలో అర్థం చేసుకోవడానికి ఇష్టపడే వారికి స్వాగతం స్లర్మే SRE.

మూలం: www.habr.com