DevOps మరియు SRE గురించి మరోసారి

చాట్ చర్చ ఆధారంగా AWS మిన్స్క్ కమ్యూనిటీ

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

పూర్వచరిత్ర

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

DevOps అభ్యాసాల పుట్టుక

అప్పుడు సీరియస్ అబ్బాయిలు వచ్చి చెప్పారు - ఇది పరిశ్రమ కాదు, మీరు అలా పని చేయలేరు. మరియు వారు జీవిత చక్ర నమూనాలను తీసుకువచ్చారు. ఇక్కడ, ఉదాహరణకు, V- మోడల్.

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

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

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

మళ్ళీ అంతా బాగాలేదు, దేవునికి ధన్యవాదాలు

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

Google ద్వారా SRE

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

DevOps ఆలోచనల అభివృద్ధి

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

SRE Googleలో లేదు

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

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

మూలం: www.habr.com

ఒక వ్యాఖ్యను జోడించండి