2008 నుండి, మా కంపెనీ ప్రాథమికంగా మౌలిక సదుపాయాల నిర్వహణ మరియు వెబ్ ప్రాజెక్ట్‌ల కోసం రౌండ్-ది-క్లాక్ సాంకేతిక మద్దతులో నిమగ్నమై ఉంది: మాకు 400 కంటే ఎక్కువ క్లయింట్లు ఉన్నారు, ఇది రష్యన్ ఇ-కామర్స్‌లో 15%. దీని ప్రకారం, చాలా వైవిధ్యమైన నిర్మాణం మద్దతు ఉంది. ఏదైనా పడిపోతే, 15 నిమిషాల్లో దాన్ని సరిచేయడానికి మేము బాధ్యత వహిస్తాము. కానీ ప్రమాదం జరిగిందని అర్థం చేసుకోవడానికి, మీరు ప్రాజెక్ట్ను పర్యవేక్షించాలి మరియు సంఘటనలకు ప్రతిస్పందించాలి. దీన్ని ఎలా చేయాలి?
సరైన పర్యవేక్షణ వ్యవస్థను నిర్వహించడంలో సమస్య ఉందని నేను నమ్ముతున్నాను. ఇబ్బంది లేకుండా ఉంటే, నా ప్రసంగంలో ఒక థీసిస్ ఉంటుంది: "దయచేసి ప్రోమేతియస్ + గ్రాఫానా మరియు ప్లగిన్‌లు 1, 2, 3ని ఇన్స్టాల్ చేయండి." దురదృష్టవశాత్తు, ఇది ఇకపై ఆ విధంగా పని చేయదు. మరియు ప్రధాన సమస్య ఏమిటంటే, సాఫ్ట్‌వేర్ భాగాల పరంగా ప్రతి ఒక్కరూ 2008లో ఉనికిలో ఉన్న దానిని విశ్వసిస్తూనే ఉన్నారు.
పర్యవేక్షణ వ్యవస్థ యొక్క సంస్థ గురించి, నేను చెప్పే సాహసం చేస్తాను... సమర్థ పర్యవేక్షణ ఉన్న ప్రాజెక్టులు ఉనికిలో లేవు. మరియు పరిస్థితి చాలా చెడ్డది, ఏదైనా పడిపోతే, అది గుర్తించబడకుండా పోయే ప్రమాదం ఉంది - అన్నింటికంటే, "ప్రతిదీ పర్యవేక్షించబడుతుందని" ప్రతి ఒక్కరూ ఖచ్చితంగా అనుకుంటున్నారు.
బహుశా ప్రతిదీ పర్యవేక్షించబడుతోంది. కానీ ఎలా?
మనమందరం ఈ క్రింది కథనాన్ని ఎదుర్కొన్నాము: ఒక నిర్దిష్ట devops, ఒక నిర్దిష్ట నిర్వాహకుడు పని చేస్తున్నాడు, ఒక డెవలప్‌మెంట్ బృందం వారి వద్దకు వచ్చి ఇలా చెప్పింది - “మేము విడుదల అయ్యాము, ఇప్పుడు పర్యవేక్షించండి.” దేనిని పర్యవేక్షించండి? అది ఎలా పని చేస్తుంది?
అలాగే. పాత పద్ధతినే పర్యవేక్షిస్తాం. మరియు ఇది ఇప్పటికే మారుతోంది మరియు మీరు సేవ Aని పర్యవేక్షించారని, అది సర్వీస్ Bగా మారిందని, ఇది సర్వీస్ Cతో పరస్పర చర్య చేస్తుందని తేలింది. కానీ డెవలప్‌మెంట్ బృందం మీకు ఇలా చెబుతుంది: “సాఫ్ట్‌వేర్‌ను ఇన్స్టాల్ చేయండి, ఇది ప్రతిదీ పర్యవేక్షించాలి!”
కాబట్టి ఏమి మారింది? - అంతా మారిపోయింది!
2008 అంతా బాగానే ఉంది
డెవలపర్లు ఒక జంట, ఒక సర్వర్, ఒక డేటాబేస్ సర్వర్ ఉన్నాయి. ఇదంతా ఇక్కడి నుంచే సాగుతుంది. మాకు కొంత సమాచారం ఉంది, మేము zabbix, Nagios, cactiని ఇన్స్టాల్ చేస్తాము. ఆపై మేము CPUలో, డిస్క్ ఆపరేషన్‌లో మరియు డిస్క్ స్థలంలో స్పష్టమైన హెచ్చరికలను సెట్ చేస్తాము. సైట్ ప్రతిస్పందిస్తుందని మరియు డేటాబేస్‌లోకి ఆర్డర్లు వస్తున్నాయని నిర్ధారించుకోవడానికి మేము రెండు మాన్యువల్ తనిఖీలను కూడా చేస్తాము. మరియు అంతే - మేము ఎక్కువ లేదా తక్కువ రక్షించబడ్డాము.
పర్యవేక్షణను అందించడానికి నిర్వాహకుడు చేసిన పనిని మేము పోల్చినట్లయితే, దానిలో 98% ఆటోమేటిక్‌గా ఉంటుంది: పర్యవేక్షణ చేసే వ్యక్తి Zabbixని ఎలా ఇన్స్టాల్ చేయాలి, దాన్ని ఎలా కాన్ఫిగర్ చేయాలి మరియు హెచ్చరికలను కాన్ఫిగర్ చేయాలి. మరియు 2% - బాహ్య తనిఖీల కోసం: సైట్ ప్రతిస్పందిస్తుంది మరియు డేటాబేస్కు అభ్యర్థన చేస్తుంది, కొత్త ఆర్డర్లు వచ్చాయి.
2010 భారం పెరుగుతోంది
మేము శోధన ఇంజిన్‌ని జోడిస్తూ వెబ్‌ని స్కేల్ చేయడం ప్రారంభించాము. ఉత్పత్తి కేటలాగ్‌లో అన్ని ఉత్పత్తులు ఉన్నాయని మేము నిర్ధారించుకోవాలనుకుంటున్నాము. మరియు ఆ ఉత్పత్తి శోధన పనిచేస్తుంది. డేటాబేస్ పని చేస్తుందని, ఆర్డర్లు చేయబడుతున్నాయని, సైట్ బాహ్యంగా ప్రతిస్పందిస్తుందని మరియు రెండు సర్వర్‌ల నుండి ప్రతిస్పందిస్తుందని మరియు మరొక సర్వర్‌కి రీబ్యాలెన్స్ చేయబడినప్పుడు వినియోగదారు సైట్ నుండి తొలగించబడలేదని మొదలైనవి. మరిన్ని సంస్థలు ఉన్నాయి.
అంతేకాకుండా, ఇన్‌ఫ్రాస్ట్రక్చర్‌తో అనుబంధించబడిన ఎంటిటీ ఇప్పటికీ మేనేజర్ హెడ్‌లో అతిపెద్దది. మానిటరింగ్ చేస్తున్న వ్యక్తి zabbixని ఇన్స్టాల్ చేసి దానిని కాన్ఫిగర్ చేయగల వ్యక్తి అని నా తలలో ఇప్పటికీ ఒక ఆలోచన ఉంది.
కానీ అదే సమయంలో, బాహ్య తనిఖీలను నిర్వహించడం, శోధన సూచిక ప్రశ్న స్క్రిప్ట్‌ల సమితిని సృష్టించడం, ఇండెక్సింగ్ ప్రక్రియలో శోధన మారుతుందో లేదో తనిఖీ చేయడానికి స్క్రిప్ట్‌ల సమితి, వస్తువులు బదిలీ చేయబడాయో లేదో తనిఖీ చేసే స్క్రిప్ట్‌ల సమితి వంటి పని కనిపిస్తుంది. డెలివరీ సేవ, మొదలైనవి. మరియు అందువలన న.
గమనిక: నేను "స్క్రిప్ట్‌ల సమితి"ని 3 సార్లు వ్రాసాను. అంటే, పర్యవేక్షణకు బాధ్యత వహించే వ్యక్తి ఇకపై కేవలం zabbixని ఇన్స్టాల్ చేసే వ్యక్తి కాదు. ఇది కోడింగ్ ప్రారంభించే వ్యక్తి. కానీ జట్టు ఆలోచనల్లో ఇంకా మార్పు రాలేదు.
కానీ ప్రపంచం మారుతోంది, మరింత సంక్లిష్టంగా మారుతుంది. వర్చువలైజేషన్ లేయర్ మరియు అనేక కొత్త సిస్టమ్‌లు జోడించబడ్డాయి. వారు ఒకరితో ఒకరు సంభాషించడం ప్రారంభిస్తారు. "మైక్రో సర్వీసెస్ లాగా ఉంటుంది" అని ఎవరు చెప్పారు? కానీ ఇప్పటికీ ఒక్కో సర్వీస్ ఒక్కో వెబ్‌సైట్‌లా కనిపిస్తుంది. మేము దానిని ఆశ్రయించవచ్చు మరియు అది అవసరమైన సమాచారాన్ని అందిస్తుంది మరియు దాని స్వంతదానిపై పని చేస్తుందని అర్థం చేసుకోవచ్చు. మరియు మీరు 5-7-10 సంవత్సరాలుగా అభివృద్ధి చెందుతున్న ప్రాజెక్ట్‌లో నిరంతరం పాల్గొంటున్న నిర్వాహకులైతే, ఈ జ్ఞానం పేరుకుపోతుంది: కొత్త స్థాయి కనిపిస్తుంది - మీరు దానిని గ్రహించారు, మరొక స్థాయి కనిపిస్తుంది - మీరు దానిని గ్రహించారు ...
కానీ చాలా అరుదుగా ఎవరైనా 10 సంవత్సరాల పాటు ప్రాజెక్ట్‌తో పాటు ఉంటారు.
మానిటరింగ్‌మ్యాన్ రెజ్యూమ్
మీరు వెంటనే 20 మంది డెవలపర్‌లను నియమించుకున్న కొత్త స్టార్టప్‌కి వచ్చారని అనుకుందాం, 15 మైక్రోసర్వీస్‌లను వ్రాసారు మరియు మీరు ఇలా చెప్పబడిన నిర్వాహకులు: “CI/CDని రూపొందించండి. దయచేసి." మీరు CI/CDని నిర్మించారు మరియు అకస్మాత్తుగా మీరు ఇలా విన్నారు: “అప్లికేషన్ ఎలా పని చేస్తుందో అర్థం చేసుకోకుండా, “క్యూబ్”లో ఉత్పత్తితో పని చేయడం మాకు కష్టం. అదే "క్యూబ్"లో మమ్మల్ని శాండ్‌బాక్స్‌గా చేయండి.
మీరు ఈ క్యూబ్‌లో శాండ్‌బాక్స్‌ను తయారు చేస్తారు. వారు వెంటనే మీకు ఇలా చెబుతారు: "ప్రొడక్షన్ నుండి ప్రతిరోజూ అప్‌డేట్ అయ్యే స్టేజ్ డేటాబేస్ మాకు కావాలి, తద్వారా ఇది డేటాబేస్‌లో పనిచేస్తుందని మేము అర్థం చేసుకున్నాము, కానీ అదే సమయంలో ప్రొడక్షన్ డేటాబేస్‌ను పాడు చేయకూడదు."
మీరు వీటన్నింటిలో నివసిస్తున్నారు. విడుదలకు 2 వారాలు మిగిలి ఉన్నాయి, వారు మీకు చెప్తారు: "ఇప్పుడు వీటన్నింటినీ పర్యవేక్షిద్దాం ..." అంటే. క్లస్టర్ ఇన్‌ఫ్రాస్ట్రక్చర్‌ను పర్యవేక్షించండి, మైక్రోసర్వీస్ ఆర్కిటెక్చర్‌ను పర్యవేక్షించండి, బాహ్య సేవలతో పనిని పర్యవేక్షించండి...
మరియు నా సహోద్యోగులు తమ తలల నుండి సాధారణ పథకాన్ని తీసివేసి ఇలా అంటారు: “సరే, ఇక్కడ ప్రతిదీ స్పష్టంగా ఉంది! వీటన్నింటినీ పర్యవేక్షించే ప్రోగ్రామ్‌ను ఇన్స్టాల్ చేయండి. అవును, అవును: ప్రోమేతియస్ + గ్రాఫానా + ప్లగిన్‌లు.
మరియు వారు ఇలా జోడించారు: "మీకు రెండు వారాలు ఉన్నాయి, ప్రతిదీ సురక్షితంగా ఉందని నిర్ధారించుకోండి."
మనం చూసే చాలా ప్రాజెక్ట్‌లలో పర్యవేక్షణ కోసం ఒకరిని కేటాయించారు. మేము 2 వారాల పాటు పర్యవేక్షణ చేయడానికి ఒక వ్యక్తిని నియమించాలనుకుంటున్నాము మరియు మేము అతని కోసం ఒక పునఃప్రారంభం వ్రాస్తాము. మేము ఇప్పటివరకు చెప్పిన ప్రతిదాన్ని బట్టి ఈ వ్యక్తికి ఎలాంటి నైపుణ్యాలు ఉండాలి?
- అతను ఇనుము అవస్థాపన యొక్క ఆపరేషన్ యొక్క పర్యవేక్షణ మరియు ప్రత్యేకతలను అర్థం చేసుకోవాలి.
- అతను కుబెర్నెట్‌లను పర్యవేక్షించడం యొక్క ప్రత్యేకతలను అర్థం చేసుకోవాలి (మరియు ప్రతి ఒక్కరూ “క్యూబ్” కి వెళ్లాలని కోరుకుంటారు, ఎందుకంటే మీరు ప్రతిదాని నుండి సంగ్రహించవచ్చు, దాచవచ్చు, ఎందుకంటే అడ్మిన్ మిగిలిన వాటితో వ్యవహరిస్తారు) - స్వయంగా, దాని మౌలిక సదుపాయాలు మరియు అనువర్తనాలను ఎలా పర్యవేక్షించాలో అర్థం చేసుకోవాలి. లోపల.
- సేవలు ఒకదానితో ఒకటి ప్రత్యేక మార్గాల్లో కమ్యూనికేట్ చేసుకుంటాయని అతను అర్థం చేసుకోవాలి మరియు సేవలు ఒకదానితో ఒకటి ఎలా సంకర్షణ చెందుతాయి అనే ప్రత్యేకతలను తెలుసుకోవాలి. కొన్ని సేవలు సమకాలీనంగా కమ్యూనికేట్ చేసే ప్రాజెక్ట్ను చూడటం చాలా సాధ్యమే, ఎందుకంటే వేరే మార్గం లేదు. ఉదాహరణకు, బ్యాకెండ్ REST ద్వారా, gRPC ద్వారా కేటలాగ్ సేవకు వెళుతుంది, ఉత్పత్తుల జాబితాను అందుకుంటుంది మరియు దానిని తిరిగి అందిస్తుంది. మీరు ఇక్కడ వేచి ఉండలేరు. మరియు ఇతర సేవలతో ఇది అసమకాలికంగా పనిచేస్తుంది. ఆర్డర్‌ను డెలివరీ సేవకు బదిలీ చేయండి, లేఖ పంపండి మొదలైనవి.
మీరు బహుశా ఇప్పటికే వీటన్నింటి నుండి ఈదుకున్నారా? దీంతో దీన్ని పర్యవేక్షించాల్సిన నిర్వాహకుడు మరింత గందరగోళానికి గురయ్యాడు. - అతను ఖచ్చితంగా ప్లాన్ మరియు ప్లాన్ చేయగలగాలి - పని మరింత ఎక్కువగా ఉంటుంది.
- అందువల్ల అతను సృష్టించిన సేవను ప్రత్యేకంగా ఎలా పర్యవేక్షించాలో అర్థం చేసుకోవడానికి దాని నుండి ఒక వ్యూహాన్ని రూపొందించాలి. అతనికి ప్రాజెక్ట్ నిర్మాణం మరియు దాని అభివృద్ధి + అభివృద్ధిలో ఉపయోగించే సాంకేతికతలపై అవగాహన అవసరం.
ఖచ్చితంగా సాధారణ సందర్భాన్ని గుర్తుంచుకోండి: కొన్ని సేవలు PHPలో ఉన్నాయి, కొన్ని సేవలు గోలో ఉన్నాయి, కొన్ని సేవలు JSలో ఉన్నాయి. వారు ఏదో ఒకదానితో ఒకటి పని చేస్తారు. "మైక్రోసర్వీస్" అనే పదం ఇక్కడ నుండి వచ్చింది: డెవలపర్లు ప్రాజెక్ట్ మొత్తాన్ని అర్థం చేసుకోలేని అనేక వ్యక్తిగత వ్యవస్థలు ఉన్నాయి. బృందంలోని ఒక భాగం JSలో తమ స్వంతంగా పని చేసే సేవలను వ్రాస్తారు మరియు మిగిలిన సిస్టమ్ ఎలా పనిచేస్తుందో తెలియదు. ఇతర భాగం పైథాన్‌లో సేవలను వ్రాస్తుంది మరియు ఇతర సేవలు ఎలా పని చేస్తాయో దానిలో జోక్యం చేసుకోదు; అవి వారి స్వంత ప్రాంతంలో ఒంటరిగా ఉంటాయి. మూడవది PHP లేదా మరేదైనా సేవలను వ్రాయడం.
ఈ 20 మందిని 15 సర్వీసులుగా విభజించారు, వీటన్నింటిని అర్థం చేసుకోవలసిన అడ్మిన్ ఒక్కరే. ఆపు! మేము సిస్టమ్‌ను 15 మైక్రోసర్వీస్‌లుగా విభజించాము ఎందుకంటే 20 మంది వ్యక్తులు మొత్తం సిస్టమ్‌ను అర్థం చేసుకోలేరు.
కానీ అది ఏదో ఒకవిధంగా పర్యవేక్షించబడాలి ...
ఫలితం ఏమిటి? ఫలితంగా, డెవలపర్‌ల బృందం మొత్తం అర్థం చేసుకోలేని ప్రతిదానితో ముందుకు వచ్చే ఒక వ్యక్తి ఉన్నాడు మరియు అదే సమయంలో మనం పైన సూచించిన వాటిని కూడా అతను తెలుసుకోవాలి మరియు చేయగలగాలి - హార్డ్‌వేర్ ఇన్‌ఫ్రాస్ట్రక్చర్, కుబెర్నెట్స్ ఇన్‌ఫ్రాస్ట్రక్చర్ మొదలైనవి.
నేను ఏమి చెప్పగలను... హ్యూస్టన్, మాకు సమస్యలు ఉన్నాయి.
ఆధునిక సాఫ్ట్‌వేర్ ప్రాజెక్ట్ను పర్యవేక్షించడం అనేది ఒక సాఫ్ట్‌వేర్ ప్రాజెక్ట్
పర్యవేక్షణ సాఫ్ట్‌వేర్ అనే తప్పుడు నమ్మకం నుండి, మేము అద్భుతాలపై నమ్మకాన్ని పెంచుకుంటాము. కానీ అద్భుతాలు, అయ్యో, జరగవు. మీరు zabbixని ఇన్స్టాల్ చేయలేరు మరియు ప్రతిదీ పని చేస్తుందని ఆశించలేరు. గ్రాఫానాను ఇన్స్టాల్ చేసి, అంతా సవ్యంగా జరుగుతుందని ఆశించడంలో ప్రయోజనం లేదు. బాహ్య వ్యవస్థలు ఎలా పని చేస్తాయో తనిఖీ చేయడం, సేవల ఆపరేషన్ మరియు ఒకదానితో ఒకటి పరస్పర చర్య యొక్క తనిఖీలను నిర్వహించడానికి ఎక్కువ సమయం వెచ్చిస్తారు. వాస్తవానికి, 90% సమయం స్క్రిప్ట్‌లు రాయడానికి కాదు, సాఫ్ట్‌వేర్‌ను అభివృద్ధి చేయడానికి ఖర్చు చేయబడుతుంది. మరియు అది ప్రాజెక్ట్ యొక్క పనిని అర్థం చేసుకునే బృందంచే నిర్వహించబడాలి.
ఈ పరిస్థితిలో ఒక వ్యక్తి పర్యవేక్షణలో పడినట్లయితే, అప్పుడు విపత్తు జరుగుతుంది. ప్రతిచోటా జరిగేదే.
ఉదాహరణకు, కాఫ్కా ద్వారా పరస్పరం సంభాషించుకునే అనేక సేవలు ఉన్నాయి. ఆర్డర్ వచ్చింది, మేము కాఫ్కాకు ఆర్డర్ గురించి సందేశం పంపాము. ఆర్డర్ గురించి సమాచారాన్ని వినే మరియు వస్తువులను రవాణా చేసే సేవ ఉంది. ఆర్డర్ గురించి సమాచారాన్ని వినే మరియు వినియోగదారుకు లేఖను పంపే సేవ ఉంది. ఆపై మరిన్ని సేవలు కనిపిస్తాయి మరియు మేము గందరగోళం చెందడం ప్రారంభిస్తాము.
మరియు విడుదలకు కొద్ది సమయం మిగిలి ఉన్న దశలో మీరు దీన్ని నిర్వాహకులు మరియు డెవలపర్‌లకు కూడా ఇస్తే, వ్యక్తి ఈ మొత్తం ప్రోటోకాల్‌ను అర్థం చేసుకోవాలి. ఆ. ఈ స్కేల్ యొక్క ప్రాజెక్ట్ గణనీయమైన సమయాన్ని తీసుకుంటుంది మరియు ఇది సిస్టమ్ అభివృద్ధికి కారకంగా ఉండాలి.
కానీ చాలా తరచుగా, ముఖ్యంగా స్టార్టప్‌లలో, పర్యవేక్షణ తర్వాత వరకు ఎలా వాయిదా వేయబడుతుందో మనం చూస్తాము. “ఇప్పుడు మేము కాన్సెప్ట్ యొక్క ప్రూఫ్ చేస్తాము, మేము దానితో ప్రారంభిస్తాము, అది పడనివ్వండి - మేము త్యాగం చేయడానికి సిద్ధంగా ఉన్నాము. ఆపై మేము అన్నింటినీ పర్యవేక్షిస్తాము. ” ప్రాజెక్ట్ డబ్బు సంపాదించడం ప్రారంభించినప్పుడు (లేదా ఉంటే), వ్యాపారం ఇంకా మరిన్ని ఫీచర్లను జోడించాలనుకుంటోంది - ఎందుకంటే ఇది పని చేయడం ప్రారంభించింది, కనుక ఇది మరింతగా రూపొందించబడాలి! మరియు మీరు మొదట మునుపటి ప్రతిదాన్ని పర్యవేక్షించాల్సిన దశలో ఉన్నారు, దీనికి 1% సమయం పట్టదు, కానీ చాలా ఎక్కువ. అలాగే, పర్యవేక్షణ కోసం డెవలపర్లు అవసరమవుతాయి మరియు కొత్త ఫీచర్‌లపై పని చేయడానికి వారిని అనుమతించడం సులభం. ఫలితంగా, కొత్త ఫీచర్‌లు వ్రాయబడ్డాయి, ప్రతిదీ చిక్కుకుపోతుంది మరియు మీరు అంతులేని ప్రతిష్టంభనలో ఉన్నారు.
కాబట్టి ప్రాజెక్ట్ను ప్రారంభం నుండి ఎలా పర్యవేక్షించాలి మరియు మీరు పర్యవేక్షించాల్సిన ప్రాజెక్ట్ను పొందినట్లయితే ఏమి చేయాలి, కానీ ఎక్కడ ప్రారంభించాలో మీకు తెలియదా?
ముందుగా, మీరు ప్లాన్ చేయాలి.
లిరికల్ డైగ్రెషన్: చాలా తరచుగా అవి మౌలిక సదుపాయాల పర్యవేక్షణతో ప్రారంభమవుతాయి. ఉదాహరణకు, మాకు కుబెర్నెట్స్ ఉన్నారు. గ్రాఫానాతో ప్రోమేతియస్‌ని ఇన్స్టాల్ చేయడం, “క్యూబ్”ని పర్యవేక్షించడం కోసం ప్లగిన్‌లను ఇన్స్టాల్ చేయడం ద్వారా ప్రారంభిద్దాం. డెవలపర్లు మాత్రమే కాకుండా, నిర్వాహకులు కూడా దీని దురదృష్టకర అభ్యాసాన్ని కలిగి ఉన్నారు: "మేము ఈ ప్లగ్‌ఇన్‌ను ఇన్స్టాల్ చేస్తాము, కానీ ప్లగ్ఇన్‌కి దీన్ని ఎలా చేయాలో బహుశా తెలుసు." వ్యక్తులు ముఖ్యమైన చర్యలతో కాకుండా సరళంగా మరియు సూటిగా ప్రారంభించాలని ఇష్టపడతారు. మరియు మౌలిక సదుపాయాల పర్యవేక్షణ సులభం.
మొదట, మీరు ఏమి మరియు ఎలా పర్యవేక్షించాలనుకుంటున్నారో నిర్ణయించుకోండి, ఆపై ఒక సాధనాన్ని ఎంచుకోండి, ఎందుకంటే ఇతర వ్యక్తులు మీ కోసం ఆలోచించలేరు. మరియు వారు చేయాలి? ఇతర వ్యక్తులు సార్వత్రిక వ్యవస్థ గురించి తమలో తాము అనుకున్నారు - లేదా ఈ ప్లగ్ఇన్ వ్రాయబడినప్పుడు అస్సలు ఆలోచించలేదు. మరియు ఈ ప్లగ్‌ఇన్‌కు 5 వేల మంది వినియోగదారులు ఉన్నందున దాని వల్ల ఉపయోగం లేదని కాదు. ఇంతకు ముందు అక్కడ 5001 మంది ఉన్నందున బహుశా మీరు 5000వ స్థానంలో ఉంటారు.
మీరు ఇన్‌ఫ్రాస్ట్రక్చర్‌ను పర్యవేక్షించడం ప్రారంభించినట్లయితే మరియు మీ అప్లికేషన్ యొక్క బ్యాకెండ్ ప్రతిస్పందించడం ఆపివేస్తే, వినియోగదారులందరూ మొబైల్ అప్లికేషన్‌తో కనెక్షన్‌ను కోల్పోతారు. ఒక లోపం కనిపిస్తుంది. వారు మీ వద్దకు వచ్చి "అప్లికేషన్ పని చేయడం లేదు, మీరు ఇక్కడ ఏమి చేస్తున్నారు?" - "మేము పర్యవేక్షిస్తున్నాము." — “అప్లికేషన్ పని చేయడం లేదని మీరు చూడకపోతే మీరు ఎలా పర్యవేక్షిస్తారు?!”
- మీరు యూజర్ యొక్క ఎంట్రీ పాయింట్ నుండి ఖచ్చితంగా పర్యవేక్షణను ప్రారంభించాలని నేను నమ్ముతున్నాను. అప్లికేషన్ పని చేస్తుందని వినియోగదారు చూడకపోతే, అంతే, ఇది వైఫల్యం. మరియు పర్యవేక్షణ వ్యవస్థ మొదట దీని గురించి హెచ్చరించాలి.
- మరియు అప్పుడు మాత్రమే మేము మౌలిక సదుపాయాలను పర్యవేక్షించగలము. లేదా సమాంతరంగా చేయండి. అవస్థాపనతో ఇది సులభం - ఇక్కడ మనం చివరకు zabbixని ఇన్స్టాల్ చేయవచ్చు.
- మరియు ఇప్పుడు మీరు ఎక్కడ పని చేయడం లేదని అర్థం చేసుకోవడానికి అప్లికేషన్ యొక్క మూలాలకు వెళ్లాలి.
అభివృద్ధి ప్రక్రియకు సమాంతరంగా పర్యవేక్షణ జరగాలనేది నా ప్రధాన ఆలోచన. మీరు ఇతర పనుల కోసం (CI/CD, శాండ్‌బాక్సింగ్, ఇన్‌ఫ్రాస్ట్రక్చర్ పునర్వ్యవస్థీకరణను సృష్టించడం) కోసం మానిటరింగ్ టీమ్‌ని దృష్టి మరల్చినట్లయితే, పర్యవేక్షణ ఆలస్యంగా ప్రారంభమవుతుంది మరియు మీరు అభివృద్ధిని ఎప్పటికీ పొందలేరు (లేదా త్వరలో లేదా తర్వాత మీరు దానిని ఆపవలసి ఉంటుంది).
స్థాయిల వారీగా ప్రతిదీ
పర్యవేక్షణ వ్యవస్థ యొక్క సంస్థను నేను ఈ విధంగా చూస్తాను.
1) అప్లికేషన్ స్థాయి:
- అప్లికేషన్ వ్యాపార లాజిక్ పర్యవేక్షణ;
- సేవల ఆరోగ్య కొలమానాలను పర్యవేక్షించడం;
- ఏకీకరణ పర్యవేక్షణ.
2) మౌలిక సదుపాయాల స్థాయి:
- ఆర్కెస్ట్రేషన్ స్థాయి పర్యవేక్షణ;
- సిస్టమ్ సాఫ్ట్‌వేర్ పర్యవేక్షణ;
- ఇనుము స్థాయి పర్యవేక్షణ.
3) మళ్లీ అప్లికేషన్ స్థాయి - కానీ ఇంజనీరింగ్ ఉత్పత్తిగా:
- అప్లికేషన్ లాగ్‌లను సేకరించడం మరియు పర్యవేక్షించడం;
- APM;
- ట్రేసింగ్.
4) హెచ్చరిక:
- హెచ్చరిక వ్యవస్థ యొక్క సంస్థ;
- విధి వ్యవస్థ యొక్క సంస్థ;
- "నాలెడ్జ్ బేస్" యొక్క సంస్థ మరియు సంఘటన ప్రాసెసింగ్ కోసం వర్క్‌ఫ్లో.
ముఖ్యమైన: మేము హెచ్చరిక తర్వాత కాదు, కానీ వెంటనే! పర్యవేక్షణను ప్రారంభించాల్సిన అవసరం లేదు మరియు "ఏదో ఒకవిధంగా తర్వాత" ఎవరు హెచ్చరికలను స్వీకరిస్తారో గుర్తించండి. అన్నింటికంటే, పర్యవేక్షణ యొక్క పని ఏమిటి: సిస్టమ్‌లో ఎక్కడ తప్పు పని చేస్తుందో అర్థం చేసుకోవడం మరియు దాని గురించి సరైన వ్యక్తులకు తెలియజేయడం. మీరు దీన్ని చివరి వరకు వదిలివేస్తే, “మాకు ఏమీ పని చేయడం లేదు” అని పిలవడం ద్వారా మాత్రమే ఏదో తప్పు జరుగుతోందని సరైన వ్యక్తులు తెలుసుకుంటారు.
అప్లికేషన్ లేయర్ - బిజినెస్ లాజిక్ మానిటరింగ్
అప్లికేషన్ వినియోగదారు కోసం పనిచేస్తుందనే వాస్తవాన్ని తనిఖీ చేయడం గురించి ఇక్కడ మేము మాట్లాడుతున్నాము.
అభివృద్ధి దశలో ఈ స్థాయిని చేయాలి. ఉదాహరణకు, మనకు షరతులతో కూడిన ప్రోమేతియస్ ఉంది: ఇది తనిఖీలు చేసే సర్వర్‌కి వెళ్లి, ఎండ్‌పాయింట్‌ని లాగుతుంది మరియు ఎండ్‌పాయింట్ వెళ్లి APIని తనిఖీ చేస్తుంది.
సైట్ పని చేస్తుందని నిర్ధారించుకోవడానికి హోమ్ పేజీని పర్యవేక్షించమని తరచుగా అడిగినప్పుడు, ప్రోగ్రామర్లు API పని చేస్తుందో లేదో నిర్ధారించుకోవడానికి అవసరమైన ప్రతిసారీ లాగగలిగే హ్యాండిల్‌ను అందిస్తారు. మరియు ఈ సమయంలో ప్రోగ్రామర్లు ఇప్పటికీ /api/test/helloworld తీసుకొని వ్రాస్తారు
ప్రతిదీ పని చేస్తుందని నిర్ధారించుకోవడానికి ఏకైక మార్గం? - లేదు!
- అటువంటి తనిఖీలను రూపొందించడం డెవలపర్‌ల విధి. కోడ్ రాసే ప్రోగ్రామర్లే యూనిట్ పరీక్షలు రాయాలి. ఎందుకంటే మీరు దానిని అడ్మిన్‌కి లీక్ చేస్తే, “డ్యూడ్, ఇక్కడ మొత్తం 25 ఫంక్షన్‌ల కోసం API ప్రోటోకాల్‌ల జాబితా ఉంది, దయచేసి అన్నింటినీ పర్యవేక్షించండి!” - ఏదీ పని చేయదు.
- మీరు “హలో వరల్డ్” అని ప్రింట్ చేస్తే, API పని చేస్తుందని మరియు పని చేస్తుందని ఎవరికీ తెలియదు. ప్రతి API మార్పు తప్పనిసరిగా చెక్‌లలో మార్పుకు దారి తీస్తుంది.
- మీకు ఇప్పటికే అలాంటి సమస్య ఉంటే, ఫీచర్లను ఆపివేసి, ఈ చెక్‌లను వ్రాసే డెవలపర్‌లను కేటాయించండి లేదా నష్టాలను అంగీకరించండి, ఏదీ తనిఖీ చేయబడలేదని మరియు విఫలమవుతుందని అంగీకరించండి.
సాంకేతిక చిట్కాలు:
- తనిఖీలను నిర్వహించడానికి బాహ్య సర్వర్‌ని నిర్వహించాలని నిర్ధారించుకోండి - మీ ప్రాజెక్ట్ బయటి ప్రపంచానికి అందుబాటులో ఉందని మీరు నిర్ధారించుకోవాలి.
- వ్యక్తిగత ముగింపు పాయింట్‌లకే కాకుండా మొత్తం API ప్రోటోకాల్‌లో తనిఖీలను నిర్వహించండి.
- పరీక్ష ఫలితాలతో ప్రోమేథియస్-ఎండ్ పాయింట్‌ని సృష్టించండి.
అప్లికేషన్ లేయర్ - హెల్త్ మెట్రిక్స్ మానిటరింగ్
ఇప్పుడు మేము సేవల యొక్క బాహ్య ఆరోగ్య కొలమానాల గురించి మాట్లాడుతున్నాము.
మేము బాహ్య పర్యవేక్షణ వ్యవస్థ నుండి పిలిచే బాహ్య తనిఖీలను ఉపయోగించి అప్లికేషన్ యొక్క అన్ని "హ్యాండిల్స్"ని పర్యవేక్షించాలని మేము నిర్ణయించుకున్నాము. కానీ ఇవి వినియోగదారు "చూసే" "హ్యాండిల్స్". మా సేవలు తాము పని చేస్తున్నాయని మేము నిర్ధారించుకోవాలనుకుంటున్నాము. ఇక్కడ ఒక మంచి కథనం ఉంది: K8s ఆరోగ్య తనిఖీలను కలిగి ఉంది, తద్వారా కనీసం “క్యూబ్” కూడా సేవ పనిచేస్తోందని ఒప్పించవచ్చు. కానీ నేను చూసిన చెక్కులలో సగం అదే ప్రింట్ “హలో వరల్డ్”. ఆ. కాబట్టి అతను విస్తరణ తర్వాత ఒకసారి లాగాడు, ప్రతిదీ బాగానే ఉందని అతను సమాధానం ఇచ్చాడు - అంతే. మరియు సేవ, దాని స్వంత APIని అందించినట్లయితే, అదే API కోసం భారీ సంఖ్యలో ఎంట్రీ పాయింట్లను కలిగి ఉంటుంది, ఇది కూడా పర్యవేక్షించబడాలి, ఎందుకంటే ఇది పని చేస్తుందని మేము తెలుసుకోవాలనుకుంటున్నాము. మరియు మేము దీన్ని ఇప్పటికే లోపల పర్యవేక్షిస్తున్నాము.
దీన్ని సాంకేతికంగా సరిగ్గా అమలు చేయడం ఎలా: ప్రతి సేవ దాని ప్రస్తుత పనితీరు గురించి ముగింపు బిందువును బహిర్గతం చేస్తుంది మరియు గ్రాఫానా (లేదా ఏదైనా ఇతర అప్లికేషన్) గ్రాఫ్‌లలో మేము అన్ని సేవల స్థితిని చూస్తాము.
- ప్రతి API మార్పు తప్పనిసరిగా చెక్‌లలో మార్పుకు దారి తీస్తుంది.
- హెల్త్ మెట్రిక్‌లతో వెంటనే కొత్త సేవను సృష్టించండి.
- ఒక నిర్వాహకుడు డెవలపర్‌ల వద్దకు వచ్చి "నాకు కొన్ని ఫీచర్లను జోడించు, తద్వారా నేను ప్రతిదీ అర్థం చేసుకుంటాను మరియు నా పర్యవేక్షణ సిస్టమ్‌కి దీని గురించిన సమాచారాన్ని జోడించు" అని అడగవచ్చు. కానీ డెవలపర్లు సాధారణంగా ఇలా సమాధానమిస్తారు, "మేము విడుదలకు రెండు వారాల ముందు ఏమీ జోడించము."
ఇలాంటి నష్టాలు ఉంటాయని డెవలప్‌మెంట్ మేనేజర్‌లకు తెలియజేయండి, డెవలప్‌మెంట్ మేనేజర్ల నిర్వహణకు కూడా తెలియజేయండి. ఎందుకంటే ప్రతిదీ పడిపోయినప్పుడు, ఎవరైనా ఇప్పటికీ కాల్ చేస్తారు మరియు "నిరంతరంగా పడిపోతున్న సేవ" (సి)ని పర్యవేక్షించమని డిమాండ్ చేస్తారు - మార్గం ద్వారా, గ్రాఫానా కోసం ప్లగిన్‌లను వ్రాయడానికి డెవలపర్‌లను కేటాయించండి - ఇది నిర్వాహకులకు మంచి సహాయం అవుతుంది.
అప్లికేషన్ లేయర్ - ఇంటిగ్రేషన్ మానిటరింగ్
ఇంటిగ్రేషన్ పర్యవేక్షణ వ్యాపార-క్లిష్టమైన సిస్టమ్‌ల మధ్య కమ్యూనికేషన్‌లను పర్యవేక్షించడంపై దృష్టి పెడుతుంది.
ఉదాహరణకు, ఒకదానితో ఒకటి సంభాషించుకునే 15 సేవలు ఉన్నాయి. ఇవి ఇకపై ప్రత్యేక సైట్‌లు కావు. ఆ. మేము సేవను స్వతహాగా లాగలేము, /హెల్లోవరల్డ్ పొందలేము మరియు సేవ నడుస్తోందని అర్థం చేసుకోలేము. ఎందుకంటే ఆర్డరింగ్ వెబ్ సర్వీస్ తప్పనిసరిగా ఆర్డర్ గురించిన సమాచారాన్ని బస్సుకు పంపాలి - బస్సు నుండి, గిడ్డంగి సేవ తప్పనిసరిగా ఈ సందేశాన్ని అందుకోవాలి మరియు దానితో మరింత పని చేయాలి. మరియు ఇమెయిల్ పంపిణీ సేవ దీన్ని ఏదో ఒకవిధంగా ప్రాసెస్ చేయాలి, మొదలైనవి.
తదనుగుణంగా, మేము అర్థం చేసుకోలేము, ప్రతి వ్యక్తి సేవలో పోకింగ్, ఇది అన్ని పని చేస్తుంది. ఎందుకంటే మనకు ఒక నిర్దిష్ట బస్సు ఉంది, దాని ద్వారా ప్రతిదీ కమ్యూనికేట్ చేస్తుంది మరియు పరస్పర చర్య చేస్తుంది.
కాబట్టి, ఈ దశ ఇతర సేవలతో పరస్పర చర్య కోసం పరీక్ష సేవల దశను గుర్తించాలి. సందేశ బ్రోకర్‌ను పర్యవేక్షించడం ద్వారా కమ్యూనికేషన్ పర్యవేక్షణను నిర్వహించడం అసాధ్యం. డేటాను జారీ చేసే సేవ మరియు దానిని స్వీకరించే సేవ ఉన్నట్లయితే, బ్రోకర్‌ను పర్యవేక్షిస్తున్నప్పుడు మేము ప్రక్క నుండి ప్రక్కకు ఎగురుతున్న డేటాను మాత్రమే చూస్తాము. మేము ఈ డేటా యొక్క పరస్పర చర్యను అంతర్గతంగా పర్యవేక్షించగలిగినప్పటికీ - ఒక నిర్దిష్ట నిర్మాత డేటాను పోస్ట్ చేస్తారు, ఎవరైనా దానిని చదువుతారు, ఈ ప్రవాహం కాఫ్కాకు కొనసాగుతుంది - ఒక సేవ ఒక సంస్కరణలో సందేశాన్ని పంపినట్లయితే ఇది ఇప్పటికీ మాకు సమాచారాన్ని అందించదు. , కానీ ఇతర సేవ ఈ సంస్కరణను ఊహించలేదు మరియు దాటవేయబడింది. దీని గురించి మాకు తెలియదు, ఎందుకంటే ప్రతిదీ పని చేస్తుందని సేవలు మాకు తెలియజేస్తాయి.
నేను ఏమి చేయాలని సిఫార్సు చేస్తున్నాను:
- సింక్రోనస్ కమ్యూనికేషన్ కోసం: ఎండ్ పాయింట్ సంబంధిత సేవలకు అభ్యర్థనలు చేస్తుంది. ఆ. మేము ఈ ఎండ్‌పాయింట్‌ని తీసుకుంటాము, సేవ లోపల స్క్రిప్ట్‌ను లాగండి, అది అన్ని పాయింట్‌లకు వెళ్లి “నేను అక్కడికి లాగగలను మరియు అక్కడకు లాగగలను, నేను అక్కడికి లాగగలను...” అని చెబుతుంది.
- అసమకాలిక కమ్యూనికేషన్ కోసం: ఇన్‌కమింగ్ సందేశాలు - పరీక్ష సందేశాల కోసం ఎండ్‌పాయింట్ బస్సును తనిఖీ చేస్తుంది మరియు ప్రాసెసింగ్ స్థితిని ప్రదర్శిస్తుంది.
- అసమకాలిక కమ్యూనికేషన్ కోసం: అవుట్‌గోయింగ్ సందేశాలు - ఎండ్‌పాయింట్ పరీక్ష సందేశాలను బస్సుకు పంపుతుంది.
సాధారణంగా జరిగే విధంగా: బస్సులోకి డేటాను పంపే సేవ మా వద్ద ఉంది. మేము ఈ సేవకు వచ్చి దాని ఇంటిగ్రేషన్ హెల్త్ గురించి మాకు చెప్పమని మిమ్మల్ని అడుగుతున్నాము. మరియు సేవ ఎక్కడైనా సందేశాన్ని ఉత్పత్తి చేయవలసి వస్తే (WebApp), అప్పుడు అది ఈ పరీక్ష సందేశాన్ని ఉత్పత్తి చేస్తుంది. మరియు మేము ఆర్డర్‌ప్రాసెసింగ్ వైపు సేవను నడుపుతుంటే, అది మొదట స్వతంత్రంగా పోస్ట్ చేయగల దానిని పోస్ట్ చేస్తుంది మరియు కొన్ని ఆధారపడిన విషయాలు ఉంటే, అది బస్సు నుండి పరీక్ష సందేశాల సమితిని చదివి, వాటిని ప్రాసెస్ చేయగలదని అర్థం చేసుకుని, నివేదించండి మరియు , అవసరమైతే, వాటిని మరింత పోస్ట్ చేయండి మరియు దీని గురించి అతను చెప్పాడు - అంతా బాగానే ఉంది, నేను సజీవంగా ఉన్నాను.
చాలా తరచుగా మనం "పోరాట డేటాలో దీన్ని ఎలా పరీక్షించగలం?" అనే ప్రశ్నను వింటాము. ఉదాహరణకు, మేము అదే ఆర్డరింగ్ సేవ గురించి మాట్లాడుతున్నాము. ఆర్డర్ వస్తువులు వ్రాయబడిన గిడ్డంగికి సందేశాలను పంపుతుంది: మేము దీనిని పోరాట డేటాపై పరీక్షించలేము, ఎందుకంటే "నా వస్తువులు వ్రాయబడతాయి!" పరిష్కారం: ఈ మొత్తం పరీక్షను ప్రారంభంలోనే ప్లాన్ చేయండి. మీరు వెక్కిరించే యూనిట్ పరీక్షలను కూడా కలిగి ఉన్నారు. కాబట్టి, వ్యాపారం యొక్క ఆపరేషన్‌కు హాని కలిగించని కమ్యూనికేషన్ ఛానెల్‌ని కలిగి ఉన్న లోతైన స్థాయిలో దీన్ని చేయండి.
మౌలిక సదుపాయాల స్థాయి
ఇన్‌ఫ్రాస్ట్రక్చర్ మానిటరింగ్ అనేది చాలా కాలంగా పర్యవేక్షణగా పరిగణించబడుతున్న విషయం.
- అవస్థాపన పర్యవేక్షణ ప్రత్యేక ప్రక్రియగా ప్రారంభించవచ్చు మరియు ప్రారంభించబడాలి.
- మీరు నిజంగా కోరుకున్నప్పటికీ, నడుస్తున్న ప్రాజెక్ట్‌లో మౌలిక సదుపాయాల పర్యవేక్షణతో మీరు ప్రారంభించకూడదు. ఇది అన్ని డెవోప్‌లకు బాధ. "మొదట నేను క్లస్టర్‌ను పర్యవేక్షిస్తాను, నేను మౌలిక సదుపాయాలను పర్యవేక్షిస్తాను" - అనగా. మొదట, ఇది క్రింద ఉన్న వాటిని పర్యవేక్షిస్తుంది, కానీ అప్లికేషన్‌లోకి వెళ్లదు. ఎందుకంటే అప్లికేషన్ డెవొప్స్‌కి అర్థంకాని విషయం. ఇది అతనికి లీక్ చేయబడింది మరియు ఇది ఎలా పనిచేస్తుందో అతనికి అర్థం కాలేదు. కానీ అతను మౌలిక సదుపాయాలను అర్థం చేసుకున్నాడు మరియు దానితో ప్రారంభించాడు. కానీ లేదు - మీరు ఎల్లప్పుడూ ముందుగా అప్లికేషన్‌ను పర్యవేక్షించాలి.
- హెచ్చరికల సంఖ్యతో అతిగా వెళ్లవద్దు. ఆధునిక వ్యవస్థల సంక్లిష్టతను పరిగణనలోకి తీసుకుంటే, హెచ్చరికలు నిరంతరం ఎగురుతూ ఉంటాయి మరియు మీరు ఈ హెచ్చరికల సమూహంతో ఎలాగైనా జీవించాలి. మరియు ఆన్-కాల్ వ్యక్తి, తదుపరి వందల హెచ్చరికలను చూసిన తర్వాత, "నేను దాని గురించి ఆలోచించడం ఇష్టం లేదు" అని నిర్ణయిస్తారు. హెచ్చరికలు క్లిష్టమైన విషయాల గురించి మాత్రమే తెలియజేయాలి.
వ్యాపార యూనిట్‌గా అప్లికేషన్ స్థాయి
ముఖ్య అంశాలు:
- ELK. ఇది పరిశ్రమ ప్రమాణం. కొన్ని కారణాల వల్ల మీరు లాగ్‌లను సమగ్రపరచనట్లయితే, వెంటనే చేయడం ప్రారంభించండి.
- APM. అప్లికేషన్ మానిటరింగ్‌ని త్వరగా మూసివేయడానికి బాహ్య APMలు (NewRelic, BlackFire, Datadog). మీతో ఏమి జరుగుతుందో కనీసం ఏదో ఒకవిధంగా అర్థం చేసుకోవడానికి మీరు ఈ విషయాన్ని తాత్కాలికంగా ఇన్స్టాల్ చేయవచ్చు.
- ట్రేసింగ్. డజన్ల కొద్దీ మైక్రోసర్వీస్‌లలో, మీరు అన్నింటినీ ట్రేస్ చేయవలసి ఉంటుంది, ఎందుకంటే అభ్యర్థన దాని స్వంతదానిపై ఉండదు. తరువాత జోడించడం చాలా కష్టం, కాబట్టి అభివృద్ధిలో ట్రేసింగ్‌ను వెంటనే షెడ్యూల్ చేయడం మంచిది - ఇది డెవలపర్‌ల పని మరియు ప్రయోజనం. మీరు ఇంకా అమలు చేయకుంటే, అమలు చేయండి! జేగర్/జిప్కిన్ చూడండి
అప్రమత్తం చేస్తోంది
- నోటిఫికేషన్ సిస్టమ్ యొక్క ఆర్గనైజేషన్: కొన్ని విషయాలను పర్యవేక్షించే పరిస్థితులలో, నోటిఫికేషన్‌లను పంపడానికి ఏకీకృత వ్యవస్థ ఉండాలి. మీరు గ్రాఫానాలో చేయవచ్చు. పాశ్చాత్య దేశాలలో, ప్రతి ఒక్కరూ పేజర్‌డ్యూటీని ఉపయోగిస్తున్నారు. హెచ్చరికలు స్పష్టంగా ఉండాలి (ఉదా. అవి ఎక్కడి నుండి వచ్చాయి...). మరియు నోటిఫికేషన్‌లు అందకుండా నియంత్రించడం మంచిది
- విధి వ్యవస్థ యొక్క సంస్థ: హెచ్చరికలను అందరికీ పంపకూడదు (ప్రతి ఒక్కరూ గుంపులో ప్రతిస్పందిస్తారు లేదా ఎవరూ స్పందించరు). డెవలపర్లు కూడా ఆన్‌కాల్‌గా ఉండాలి: బాధ్యతాయుతమైన ప్రాంతాలను నిర్వచించండి, స్పష్టమైన సూచనలు చేయండి మరియు సోమవారం మరియు బుధవారం ఎవరికి ఖచ్చితంగా కాల్ చేయాలో మరియు మంగళవారం మరియు శుక్రవారం ఎవరికి కాల్ చేయాలో వ్రాయండి (లేకపోతే వారు ఎవరికీ కాల్ చేయరు. పెద్ద సమస్య వచ్చినప్పుడు - వారు మిమ్మల్ని నిద్రలేపడానికి లేదా భంగపరచడానికి భయపడతారు: ప్రజలు సాధారణంగా ఇతర వ్యక్తులకు కాల్ చేయడానికి మరియు మేల్కొలపడానికి ఇష్టపడరు, ముఖ్యంగా రాత్రి). మరియు సహాయం కోసం అడగడం అసమర్థతకు సూచిక కాదని వివరించండి (“నేను సహాయం కోసం అడుగుతాను, అంటే నేను చెడ్డ పనివాడిని”), సహాయం కోసం అభ్యర్థనలను ప్రోత్సహించండి.
- సంఘటన ప్రాసెసింగ్ కోసం "నాలెడ్జ్ బేస్" యొక్క సంస్థ మరియు వర్క్‌ఫ్లో: ప్రతి తీవ్రమైన సంఘటన కోసం, పోస్ట్‌మార్టం ప్లాన్ చేయాలి మరియు తాత్కాలిక చర్యగా, సంఘటనను పరిష్కరించే చర్యలను రికార్డ్ చేయాలి. మరియు పదేపదే హెచ్చరికలు పాపం అని అలవాటు చేసుకోండి; వాటిని కోడ్ లేదా ఇన్‌ఫ్రాస్ట్రక్చర్ వర్క్‌లో పరిష్కరించాలి.
టెక్నాలజీ స్టాక్
మన స్టాక్ ఈ క్రింది విధంగా ఉందని ఊహించుకుందాం:
- డేటా సేకరణ - ప్రోమేతియస్ + గ్రాఫానా;
- లాగ్ విశ్లేషణ - ELK;
- APM లేదా ట్రేసింగ్ కోసం - జేగర్ (జిప్కిన్).
ఎంపికల ఎంపిక క్లిష్టమైనది కాదు. ఎందుకంటే ప్రారంభంలో మీరు సిస్టమ్‌ను ఎలా పర్యవేక్షించాలో అర్థం చేసుకుని, ప్రణాళికను వ్రాసినట్లయితే, మీరు మీ అవసరాలకు తగిన సాధనాలను ఎంచుకోవడం ప్రారంభిస్తారు. మీరు మొదటి స్థానంలో పర్యవేక్షించడానికి ఎంచుకున్నది ప్రశ్న. ఎందుకంటే మీరు ప్రారంభంలో ఎంచుకున్న సాధనం మీ అవసరాలకు సరిపోకపోవచ్చు.
నేను ఇటీవల ప్రతిచోటా చూసే కొన్ని సాంకేతిక అంశాలు:
ప్రోమేతియస్‌ని కుబెర్నెటెస్‌లోకి నెట్టబడుతోంది - దీనితో ఎవరు వచ్చారు?! మీ క్లస్టర్ క్రాష్ అయితే, మీరు ఏమి చేస్తారు? మీరు లోపల సంక్లిష్టమైన క్లస్టర్‌ని కలిగి ఉంటే, క్లస్టర్ లోపల కొన్ని రకాల పర్యవేక్షణ వ్యవస్థ ఉండాలి మరియు క్లస్టర్ లోపల నుండి డేటాను సేకరిస్తుంది.
క్లస్టర్ లోపల మేము లాగ్‌లను మరియు మిగతావన్నీ సేకరిస్తాము. కానీ పర్యవేక్షణ వ్యవస్థ బయట ఉండాలి. చాలా తరచుగా, Promtheus అంతర్గతంగా ఇన్స్టాల్ చేయబడిన క్లస్టర్లో, సైట్ యొక్క ఆపరేషన్ యొక్క బాహ్య తనిఖీలను నిర్వహించే వ్యవస్థలు కూడా ఉన్నాయి. బయటి ప్రపంచానికి మీ కనెక్షన్లు పడిపోయి, అప్లికేషన్ పని చేయకపోతే ఏమి చేయాలి? లోపల ప్రతిదీ బాగానే ఉందని తేలింది, కానీ ఇది వినియోగదారులకు విషయాలను సులభతరం చేయదు.
కనుగొన్న
- మానిటరింగ్ డెవలప్‌మెంట్ అనేది యుటిలిటీల ఇన్‌స్టాలేషన్ కాదు, సాఫ్ట్‌వేర్ ఉత్పత్తి అభివృద్ధి. నేటి పర్యవేక్షణలో 98% కోడింగ్. సేవల్లో కోడింగ్, బాహ్య తనిఖీలను కోడింగ్ చేయడం, బాహ్య సేవలను తనిఖీ చేయడం మరియు అంతే.
- పర్యవేక్షణలో మీ డెవలపర్‌ల సమయాన్ని వృథా చేయవద్దు: ఇది వారి పనిలో 30% వరకు పట్టవచ్చు, కానీ అది విలువైనది.
- Devops, మీరు ఏదైనా పర్యవేక్షించలేరని చింతించకండి, ఎందుకంటే కొన్ని విషయాలు పూర్తిగా భిన్నమైన ఆలోచనా విధానం. మీరు ప్రోగ్రామర్ కాదు మరియు పర్యవేక్షణ పని ఖచ్చితంగా వారి పని.
- ప్రాజెక్ట్ ఇప్పటికే అమలులో ఉంటే మరియు పర్యవేక్షించబడకపోతే (మరియు మీరు మేనేజర్ అయితే), పర్యవేక్షణ కోసం వనరులను కేటాయించండి.
- ఉత్పత్తి ఇప్పటికే ఉత్పత్తిలో ఉంటే మరియు మీరు "మానిటరింగ్‌ని సెటప్ చేయమని" చెప్పబడిన డెవొప్‌లైతే - నేను వీటన్నింటి గురించి వ్రాసిన దాని గురించి నిర్వహణకు వివరించడానికి ప్రయత్నించండి.
ఇది సెయింట్ హైలోడ్++ కాన్ఫరెన్స్‌లో నివేదిక యొక్క పొడిగించిన సంస్కరణ.
మీరు నా ఆలోచనలు మరియు ఆలోచనలు మరియు సంబంధిత అంశాలపై ఆసక్తి కలిగి ఉంటే, ఇక్కడ మీరు చేయవచ్చు 🙂
మూలం: www.habr.com