DevOps యొక్క నిర్వచనం చాలా క్లిష్టంగా ఉంటుంది, కాబట్టి మనం ప్రతిసారీ దాని గురించి చర్చను మళ్లీ ప్రారంభించాలి. హబ్రేలో మాత్రమే ఈ అంశంపై వెయ్యి ప్రచురణలు ఉన్నాయి. కానీ మీరు దీన్ని చదువుతున్నట్లయితే, DevOps అంటే ఏమిటో మీకు తెలిసి ఉండవచ్చు. ఎందుకంటే నేను కాదు. నమస్తే నా పేరు అలెగ్జాండర్ టిటోవ్ (@), మరియు మేము కేవలం DevOps గురించి మాట్లాడుతాము మరియు నేను నా అనుభవాన్ని పంచుకుంటాను.
నా కథనాన్ని ఎలా ఉపయోగపడేలా చేయాలనే దాని గురించి నేను చాలా కాలంగా ఆలోచిస్తున్నాను, కాబట్టి ఇక్కడ చాలా ప్రశ్నలు ఉంటాయి - నేను నన్ను అడిగేవి మరియు మా కంపెనీ క్లయింట్‌లను నేను అడిగేవి. ఈ ప్రశ్నలకు సమాధానమివ్వడం ద్వారా, అవగాహన మెరుగుపడుతుంది. నా దృక్కోణం నుండి DevOps ఎందుకు అవసరమో, అది ఏమిటి, మళ్ళీ, నా దృష్టికోణం నుండి మరియు మీరు నా దృష్టికోణం నుండి మళ్ళీ DevOps వైపు వెళ్తున్నారని ఎలా అర్థం చేసుకోవాలో నేను మీకు చెప్తాను. చివరి పాయింట్ ప్రశ్నల ద్వారా ఉంటుంది. వాటికి మీరే సమాధానమివ్వడం ద్వారా, మీ కంపెనీ DevOps వైపు వెళుతోందా లేదా ఏదో ఒక విధంగా సమస్యలు ఉన్నాయా అనేది మీరు అర్థం చేసుకోవచ్చు.
ఒకానొక సమయంలో నేను విలీనాలు మరియు సముపార్జనల తరంగాలను నడుపుతున్నాను. మొదట, నేను క్విక్ అనే చిన్న స్టార్టప్ కోసం పనిచేశాను, దానిని స్కైప్ అనే కొంచెం పెద్ద కంపెనీ కొనుగోలు చేసింది, దానిని మైక్రోసాఫ్ట్ అనే కొంచెం పెద్ద కంపెనీ కొనుగోలు చేసింది. ఆ సమయంలో, వివిధ పరిమాణాల కంపెనీలలో DevOps ఆలోచన ఎలా మారుతుందో నేను చూడటం ప్రారంభించాను. ఆ తర్వాత, నేను DevOpsను మార్కెట్ కోణం నుండి చూడటంలో ఆసక్తిని కనబరిచాను మరియు నా సహచరులు మరియు నేను ఎక్స్‌ప్రెస్ 42 కంపెనీని స్థాపించాము. 6 సంవత్సరాలుగా మేము మార్కెట్ తరంగాల వెంట కదులుతున్నాము.
ఇతర విషయాలతోపాటు, నేను DevOps మాస్కో సంఘం నిర్వాహకులలో ఒకడిని మరియు DevOps-Days 2017 నిర్వాహకుడిని, కానీ నేను 2018ని నిర్వహించలేదు. ఎక్స్‌ప్రెస్ 42 అనేక కంపెనీలతో కలిసి పనిచేస్తుంది. మేము అక్కడ DevOpsని పెంచుతాము, అది ఎలా జరుగుతుందో చూడండి, తీర్మానాలు చేయండి, విశ్లేషించండి, మా తీర్మానాలను అందరికీ తెలియజేయండి మరియు DevOps అభ్యాసాలలో వ్యక్తులకు శిక్షణ ఇస్తాము. సాధారణంగా, ఈ విషయంలో మా అనుభవం మరియు నైపుణ్యాన్ని పెంచుకోవడానికి మేము మా వంతు కృషి చేస్తున్నాము.
ఎందుకు DevOps
అందరినీ ఎప్పుడూ వేధించే మొదటి ప్రశ్న - ఎందుకు? DevOps కేవలం ఆటోమేషన్ లేదా ప్రతి కంపెనీ ఇప్పటికే కలిగి ఉన్న ఇలాంటిదే అని చాలా మంది అనుకుంటారు.
— మేము నిరంతర ఏకీకరణను కలిగి ఉన్నాము - దీని అర్థం మేము ఇప్పటికే DevOpsని కలిగి ఉన్నాము మరియు ఈ అంశాలన్నీ ఎందుకు అవసరం? విదేశాల్లో సరదాగా గడుపుతున్నారు, కానీ మమ్మల్ని పని చేయకుండా ఆపుతున్నారు!
కమ్యూనిటీ మరియు మెథడాలజీ యొక్క 9 సంవత్సరాల అభివృద్ధిలో, ఇది ఇప్పటికీ మార్కెటింగ్ గ్లిట్టర్ కాదని ఇప్పటికే స్పష్టమైంది, అయితే ఇది ఎందుకు అవసరమో ఇప్పటికీ పూర్తిగా స్పష్టంగా తెలియలేదు. ఏదైనా సాధనం మరియు ప్రక్రియ వలె, DevOps అంతిమంగా సాధించే నిర్దిష్ట లక్ష్యాలను కలిగి ఉంటుంది.
ఇదంతా ప్రపంచం మారుతున్న వాస్తవం. మా సెయింట్ పీటర్స్‌బర్గ్ క్లాసిక్ పాడినట్లుగా, ఒక నిర్దిష్ట వ్యూహం ప్రకారం పాయింట్ A నుండి పాయింట్ B వరకు, దీని కోసం నిర్మించబడిన ఒక నిర్దిష్ట నిర్మాణంతో కంపెనీలు నేరుగా కల వైపు వెళ్లినప్పుడు అతను ఎంటర్‌ప్రైజ్ విధానం నుండి దూరంగా ఉంటాడు.
సూత్రప్రాయంగా, IT లో ప్రతిదీ ఈ విధానం ప్రకారం నిర్మించబడాలి. ఇక్కడ IT ప్రక్రియలను ఆటోమేట్ చేయడానికి ప్రత్యేకంగా ఉపయోగించబడుతుంది.
ఆటోమేషన్ తరచుగా మారదు, ఎందుకంటే కంపెనీ బాగా నలిగిపోయినప్పుడు, మార్చడానికి ఏమి ఉంది? ఇది పనిచేస్తుంది - దానిని తాకవద్దు. ఇప్పుడు ప్రపంచంలోని విధానాలు మారుతున్నాయి మరియు ఎజైల్ అని పిలవబడేది ఎండ్ పాయింట్ B వెంటనే కనిపించదని సూచిస్తుంది.
ఒక కంపెనీ మార్కెట్ గుండా వెళుతున్నప్పుడు, క్లయింట్‌తో కలిసి పని చేసినప్పుడు, అది నిరంతరం మార్కెట్‌ను అన్వేషిస్తుంది మరియు ముగింపు బిందువును మారుస్తుంది. అంతేకాకుండా, కంపెనీ తన దిశను ఎంత తరచుగా మారుస్తుంది, చివరికి అది మరింత విజయవంతమవుతుంది, ఎందుకంటే అది మరింత మార్కెట్‌ను ఎంచుకుంటుంది. గూళ్లు.
నేను ఇటీవల నేర్చుకున్న ఒక ఆసక్తికరమైన సంస్థ ద్వారా వ్యూహం ప్రదర్శించబడింది. వన్ బాక్స్ షేవ్ అనేది రేజర్‌లు మరియు బాక్స్‌లోని షేవింగ్ యాక్సెసరీల కోసం సబ్‌స్క్రిప్షన్ డెలివరీ సర్వీస్. వేర్వేరు క్లయింట్‌ల కోసం వారి "బాక్స్"ని ఎలా అనుకూలీకరించాలో వారికి తెలుసు. ఇది ఒక నిర్దిష్ట సాఫ్ట్‌వేర్ ద్వారా చేయబడుతుంది, ఇది వస్తువులను ఉత్పత్తి చేసే కొరియన్ ఫ్యాక్టరీకి ఆర్డర్‌ను పంపుతుంది.
ఈ ఉత్పత్తిని యూనిలీవర్ $1 బిలియన్లకు కొనుగోలు చేసింది. ఇది ఇప్పుడు జిల్లెట్‌తో పోటీపడుతుంది మరియు అమెరికన్ మార్కెట్లో వినియోగదారుల యొక్క గణనీయమైన వాటాను తీసివేసింది. వన్ బాక్స్ షేవ్ ఇలా చెప్పింది:
- 4 బ్లేడ్లు? మీరు తీవ్రంగా ఉన్నారా? మీకు ఇది ఎందుకు అవసరం - ఇది షేవ్ యొక్క నాణ్యతను మెరుగుపరచదు. ప్రత్యేకంగా ఎంచుకున్న క్రీమ్, సువాసన మరియు రెండు బ్లేడ్‌లతో కూడిన అధిక-నాణ్యత రేజర్ ఆ స్టుపిడ్ 4 జిల్లెట్ బ్లేడ్‌ల కంటే చాలా ఎక్కువ సమస్యలను పరిష్కరిస్తుంది! మేము త్వరలో 10కి వస్తామా?
ప్రపంచం ఇలా మారుతుంది. యూనిలీవర్ తమ వద్ద కూల్ ఐటి సిస్టమ్‌ని కలిగి ఉందని, అది మిమ్మల్ని దీన్ని చేయడానికి మిమ్మల్ని అనుమతిస్తుంది. చివరికి ఇది ఒక భావనలా కనిపిస్తుంది మార్కెట్‌కి సమయం, ఇది ఇప్పటికే ఎవరూ మాట్లాడలేదు.
టైమ్-టు-మార్కెట్ యొక్క పాయింట్ మనం ఎంత తరచుగా అమలు చేస్తున్నామో కాదు. మీరు తరచుగా అమలు చేయవచ్చు, కానీ విడుదల చక్రాలు పొడవుగా ఉంటాయి. మూడు-నెలల విడుదల చక్రాలు ఒకదానిపై ఒకటి సూపర్మోస్ చేయబడి, వాటిని ఒక వారం పాటు మార్చినట్లయితే, కంపెనీ వారానికి ఒకసారి అమలు చేస్తున్నట్లుగా మారుతుంది. మరియు ఆలోచన నుండి తుది అమలు వరకు 3 నెలలు పడుతుంది.
టైమ్-టు-మార్కెట్ అనేది ఆలోచన నుండి తుది అమలు వరకు సమయాన్ని తగ్గించడం.
ఈ సందర్భంలో, సాఫ్ట్‌వేర్ మార్కెట్‌తో పరస్పర చర్య చేస్తుంది. ఈ విధంగా One Box Shave వెబ్‌సైట్ క్లయింట్‌తో పరస్పర చర్య చేస్తుంది. వారికి విక్రయదారులు లేరు - సందర్శకులు క్లిక్ చేసి, శుభాకాంక్షలు తెలిపే వెబ్‌సైట్. దీని ప్రకారం, సైట్‌లో కొత్తది నిరంతరం పోస్ట్ చేయబడాలి మరియు కోరికలకు అనుగుణంగా నవీకరించబడాలి. ఉదాహరణకు, దక్షిణ కొరియాలో వారు రష్యాలో కంటే భిన్నంగా షేవ్ చేస్తారు, మరియు వారు పైన్ సువాసనను ఇష్టపడరు, ఉదాహరణకు, క్యారెట్లు మరియు వనిల్లా.
సైట్ యొక్క కంటెంట్‌ను త్వరగా మార్చాల్సిన అవసరం ఉన్నందున, సాఫ్ట్‌వేర్ అభివృద్ధి బాగా మారుతుంది. సాఫ్ట్‌వేర్ ద్వారా మనం క్లయింట్‌కు ఏమి కావాలో తెలుసుకోవాలి. మునుపు, మేము దీన్ని కొన్ని రౌండ్అబౌట్ మార్గాల ద్వారా నేర్చుకున్నాము, ఉదాహరణకు, వ్యాపార నిర్వహణ ద్వారా. అప్పుడు మేము దానిని రూపొందించాము, IT సిస్టమ్‌లో అవసరాలను ఉంచాము మరియు ప్రతిదీ బాగుంది. ఇప్పుడు ఇది భిన్నమైనది - సాఫ్ట్‌వేర్ ఇంజనీర్‌లతో సహా ప్రక్రియలో పాల్గొన్న ప్రతి ఒక్కరిచే రూపొందించబడింది, ఎందుకంటే సాంకేతిక వివరాల ద్వారా వారు మార్కెట్ ఎలా పనిచేస్తుందో తెలుసుకుంటారు మరియు వ్యాపారంతో వారి అంతర్దృష్టులను కూడా పంచుకుంటారు.
ఉదాహరణకు, Qik వద్ద మేము అకస్మాత్తుగా తెలుసుకున్నాము, వ్యక్తులు సంప్రదింపు జాబితాలను సర్వర్‌కి అప్‌లోడ్ చేయడాన్ని నిజంగా ఇష్టపడతారని మరియు వారు మాకు ఒక అప్లికేషన్‌ను అందించారు. మొదట్లో మేము దాని గురించి ఆలోచించలేదు. ఒక క్లాసిక్ కంపెనీలో, ప్రతి ఒక్కరూ ఇది బగ్ అని నిర్ణయించుకుంటారు, ఎందుకంటే ఇది గొప్పగా పని చేయాలని స్పెక్ చెప్పలేదు మరియు సాధారణంగా మోకాలిపై అమలు చేయబడుతుంది, వారు ఫీచర్‌ను ఆపివేసి ఇలా అన్నారు: “ఇది ఎవరికీ అవసరం లేదు, చాలా ముఖ్యమైన విషయం ఏమిటంటే ప్రధాన కార్యాచరణ పనిచేస్తుంది. ” మరియు సాంకేతిక సంస్థ దీనిని ఒక అవకాశంగా చూస్తుంది మరియు దీనికి అనుగుణంగా సాఫ్ట్‌వేర్‌ను మార్చడం ప్రారంభిస్తుంది.
1968లో, మెల్విన్ కాన్వే అనే దూరదృష్టి గల వ్యక్తి ఈ క్రింది ఆలోచనను రూపొందించాడు.
వ్యవస్థను సృష్టించే సంస్థ ఆ సంస్థ యొక్క కమ్యూనికేషన్ నిర్మాణాన్ని ప్రతిబింబించే రూపకల్పన ద్వారా నిర్బంధించబడుతుంది.
మరింత వివరంగా చెప్పాలంటే, వేరే రకం సిస్టమ్‌లను ఉత్పత్తి చేయడానికి, మీరు వేరే రకం కంపెనీలో కమ్యూనికేషన్ నిర్మాణాన్ని కూడా కలిగి ఉండాలి. మీ కమ్యూనికేషన్ నిర్మాణం అగ్ర క్రమానుగతంగా ఉంటే, ఇది చాలా ఎక్కువ టైమ్-టు-మార్కెట్ సూచికను అందించగల సిస్టమ్‌లను సృష్టించడానికి మిమ్మల్ని అనుమతించదు.
చదవండి చెయ్యవచ్చు . DevOps సంస్కృతి లేదా తత్వశాస్త్రాన్ని అర్థం చేసుకోవడం చాలా ముఖ్యం ఎందుకంటే DevOpsలో ప్రాథమికంగా మారే ఏకైక విషయం జట్ల మధ్య కమ్యూనికేషన్ నిర్మాణం.
ప్రక్రియ కోణం నుండి, DevOps కంటే ముందు, అన్ని దశలు: విశ్లేషణలు, అభివృద్ధి, పరీక్ష, ఆపరేషన్, సరళంగా ఉండేవి.
DevOps విషయంలో, ఈ ప్రక్రియలన్నీ ఏకకాలంలో జరుగుతాయి.
టైమ్-టు-మార్కెట్ మాత్రమే దీన్ని చేయగల ఏకైక మార్గం. పాత ప్రక్రియలో పనిచేసిన వ్యక్తుల కోసం, ఇది కొంతవరకు విశ్వరూపంగా కనిపిస్తుంది మరియు సాధారణంగా అలా ఉంటుంది.
కాబట్టి మీకు DevOps ఎందుకు అవసరం?
డిజిటల్ ఉత్పత్తి అభివృద్ధి కోసం. మీ కంపెనీకి డిజిటల్ ఉత్పత్తి లేకపోతే, DevOps అవసరం లేదు - ఇది చాలా ముఖ్యం.
DevOps సీక్వెన్షియల్ సాఫ్ట్‌వేర్ ఉత్పత్తి యొక్క వేగ పరిమితులను అధిగమిస్తుంది. దీనిలో అన్ని ప్రక్రియలు ఏకకాలంలో జరుగుతాయి.
కష్టం పెరుగుతుంది. సాఫ్ట్‌వేర్‌ను విడుదల చేయడం మీకు సులభతరం చేస్తుందని DevOps సువార్తికులు మీకు చెప్పినప్పుడు, ఇది అర్ధంలేనిది.
DevOpsతో, విషయాలు మరింత క్లిష్టంగా మారతాయి.
Avito స్టాండ్‌లో జరిగిన సమావేశంలో, డాకర్ కంటైనర్‌ను అమర్చడం ఎలా ఉంటుందో మీరు చూడవచ్చు - ఇది అవాస్తవ పని. సంక్లిష్టత నిషేధించబడింది; మీరు ఒకే సమయంలో అనేక బంతులను మోసగించవలసి ఉంటుంది.
DevOps సంస్థలో ప్రక్రియ మరియు సంస్థను పూర్తిగా మారుస్తుంది — మరింత ఖచ్చితంగా, ఇది DevOps కాదు, డిజిటల్ ఉత్పత్తి మారుతుంది. DevOpsకి రావడానికి, మీరు ఇప్పటికీ ఈ ప్రక్రియను పూర్తిగా మార్చాలి.
స్పెషలిస్ట్ కోసం ప్రశ్నలు
మీ దగ్గర ఏమి ఉంది? కంపెనీలో పని చేస్తున్నప్పుడు మరియు నిపుణుడిగా అభివృద్ధి చెందుతున్నప్పుడు మిమ్మల్ని మీరు ప్రశ్నించుకోగల ప్రశ్నలు.
డిజిటల్ ఉత్పత్తిని రూపొందించడానికి మీకు వ్యూహం ఉందా? ఉంటే, అది ఇప్పటికే మంచిది. మీ కంపెనీ DevOps వైపు వెళుతోందని దీని అర్థం.
మీ కంపెనీ ఇప్పటికే డిజిటల్ ఉత్పత్తిని సృష్టిస్తోందా? దీనర్థం మీరు మరొక స్థాయిని పెంచుకోవచ్చు మరియు మరింత ఆసక్తికరంగా పనులు చేయవచ్చు - మళ్లీ DevOps దృష్టికోణం నుండి. నేను ఈ కోణం నుండి మాత్రమే మాట్లాడుతున్నాను.
డిజిటల్ ఉత్పత్తి సముచితంలో మీ కంపెనీ మార్కెట్ లీడర్‌లలో ఒకరిగా ఉందా? Spotify, Yandex, Uber ఇప్పుడు సాంకేతిక పురోగతిలో గరిష్ట స్థాయికి చేరుకున్న కంపెనీలు.
ఈ ప్రశ్నలను మీరే అడగండి మరియు అన్ని సమాధానాలు కానట్లయితే, మీరు ఈ కంపెనీలో DevOps చేయకూడదు. DevOps అంశం మీకు నిజంగా ఆసక్తికరంగా ఉంటే, బహుశా... మీరు వేరే కంపెనీకి వెళ్లాలా? మీ కంపెనీ DevOpsలోకి వెళ్లాలనుకుంటే, కానీ మీరు అన్ని ప్రశ్నలకు “లేదు” అని సమాధానం ఇచ్చినట్లయితే, అది ఎప్పటికీ మారని అందమైన ఖడ్గమృగం లాంటిది.
సంస్థ
నేను చెప్పినట్లుగా, కాన్వే యొక్క చట్టం ప్రకారం, సంస్థ యొక్క సంస్థ మారుతుంది. సంస్థాగత దృక్కోణం నుండి కంపెనీ లోపలకి DevOps చొచ్చుకుపోకుండా నిరోధించే దానితో నేను ప్రారంభిస్తాను.
"బావులు" సమస్య
"Silo" అనే ఆంగ్ల పదం ఇక్కడ రష్యన్‌లోకి "బాగా" అని అనువదించబడింది. ఈ సమస్య యొక్క ఉద్దేశ్యం ఏమిటంటే జట్ల మధ్య సమాచార మార్పిడి లేదు. నావిగేట్ చేయడానికి ఒక సాధారణ మ్యాప్‌ను రూపొందించకుండా, ప్రతి బృందం దాని నైపుణ్యాన్ని లోతుగా త్రవ్విస్తుంది.
కొన్ని మార్గాల్లో, ఇది ఇప్పుడే మాస్కోకు వచ్చిన వ్యక్తిని గుర్తు చేస్తుంది మరియు మెట్రో మ్యాప్‌ను ఎలా నావిగేట్ చేయాలో ఇంకా తెలియదు. ముస్కోవైట్‌లకు సాధారణంగా వారి ప్రాంతం బాగా తెలుసు మరియు మాస్కో అంతటా వారు మెట్రో మ్యాప్‌ని ఉపయోగించి నావిగేట్ చేయవచ్చు. మీరు మొదటి సారి మాస్కోకు వచ్చినప్పుడు, మీకు ఈ నైపుణ్యం లేదు, మరియు మీరు కేవలం దిక్కుతోచని స్థితిలో ఉన్నారు.
DevOps ఈ అయోమయ స్థితిని అధిగమించాలని మరియు అన్ని విభాగాలు ఉమ్మడి పరస్పర చర్య మ్యాప్‌ను రూపొందించడానికి కలిసి పనిచేయాలని సూచిస్తున్నాయి.
దీనికి రెండు అంశాలు అడ్డుపడుతున్నాయి.
కార్పొరేట్ నిర్వహణ వ్యవస్థ యొక్క పరిణామం. ఇది ప్రత్యేక క్రమానుగత "బావులు" లో నిర్మించబడింది. ఉదాహరణకు, ఈ సిస్టమ్‌కు మద్దతిచ్చే కంపెనీలలో నిర్దిష్ట KPIలు ఉన్నాయి. మరోవైపు, వారి నైపుణ్యం యొక్క సరిహద్దులను దాటి మొత్తం వ్యవస్థను నావిగేట్ చేయడం కష్టంగా భావించే వ్యక్తి యొక్క మెదళ్ళు దారిలోకి వస్తాయి. ఇది కేవలం అసౌకర్యంగా ఉంది. మీరు బ్యాంకాక్ విమానాశ్రయంలో ఉన్నారని ఊహించుకోండి - మీరు త్వరగా వెళ్లలేరు. DevOps నావిగేట్ చేయడం కూడా కష్టం, అందుకే అక్కడికి చేరుకోవడానికి మీరు గైడ్‌ను కనుగొనాలని వ్యక్తులు అంటున్నారు.
కానీ చాలా ముఖ్యమైన విషయం ఏమిటంటే, DevOps యొక్క స్ఫూర్తితో నిండిన, ఫౌలర్ మరియు ఇతర పుస్తకాలను చదివిన ఇంజనీర్‌కు “బావులు” సమస్య వాస్తవంలో వ్యక్తీకరించబడింది. "బావులు" మిమ్మల్ని "స్పష్టమైన" పనులు చేయడానికి అనుమతించవు. DevOps మాస్కో తర్వాత మేము తరచుగా కలిసి ఉంటాము, ఒకరితో ఒకరు మాట్లాడుకుంటాము మరియు ప్రజలు ఫిర్యాదు చేస్తారు:
— మేము ఇప్పుడే CIని ప్రారంభించాలనుకుంటున్నాము, కానీ నిర్వహణకు ఇది అవసరం లేదని తేలింది.
ఇది ఖచ్చితంగా జరుగుతుంది ఎందుకంటే CI и నిరంతర డెలివరీ ప్రక్రియ అనేక పరీక్షల సరిహద్దులో ఉన్నాయి. సంస్థాగత స్థాయిలో “బావులు” సమస్యను అధిగమించకుండా, మీరు ఏమి చేసినా మరియు ఎంత విచారంగా ఉన్నా మీరు ముందుకు సాగలేరు.
కంపెనీలో ప్రక్రియలో పాల్గొనే ప్రతి వ్యక్తి: బ్యాకెండ్ మరియు ఫ్రంటెండ్ డెవలపర్లు, టెస్టింగ్, DBA, ఆపరేషన్, నెట్‌వర్క్, వారి స్వంత దిశలో తవ్వుతారు మరియు మేనేజర్ తప్ప ఎవరికీ సాధారణ మ్యాప్ లేదు, అతను వాటిని ఎలాగైనా పర్యవేక్షిస్తాడు మరియు “డివైడ్” ఉపయోగించి వాటిని నిర్వహిస్తాడు. మరియు జయించు” పద్ధతి.
కొంతమంది నక్షత్రాలు లేదా జెండాల కోసం ప్రజలు పోరాడుతున్నారు, ప్రతి ఒక్కరూ తమ నైపుణ్యాన్ని తవ్వుతున్నారు.
తత్ఫలితంగా, వీటన్నింటిని కలిపి ఒక సాధారణ పైప్‌లైన్‌ను నిర్మించే పని తలెత్తినప్పుడు మరియు ఇకపై నక్షత్రాలు మరియు జెండాల కోసం పోరాడాల్సిన అవసరం లేనప్పుడు, ప్రశ్న తలెత్తుతుంది - మనం ఏమి చేయాలి? మేము ఏదో ఒక ఒప్పందానికి రావాలి, కానీ పాఠశాలలో దీన్ని ఎలా చేయాలో ఎవరూ మాకు నేర్పించలేదు. మేము పాఠశాల నుండి బోధించాము: ఎనిమిదవ తరగతి - వావ్! - ఏడవ తరగతితో పోలిస్తే! ఇక్కడ కూడా అంతే.
మీ కంపెనీలో కూడా ఇలాగే ఉందా?
దీన్ని తనిఖీ చేయడానికి, మీరు ఈ క్రింది ప్రశ్నలను మీరే అడగవచ్చు.
బృందాలు సాధారణ సాధనాలను ఉపయోగిస్తాయా మరియు ఆ సాధారణ సాధనాల్లో మార్పులకు దోహదం చేస్తాయా?
బృందాలు ఎంత తరచుగా పునర్వ్యవస్థీకరించబడతాయి-కొందరు నిపుణులు ఒక బృందం నుండి మరొక జట్టుకు మారతారు? DevOps వాతావరణంలో ఇది సాధారణం అవుతుంది, ఎందుకంటే కొన్నిసార్లు ఒక వ్యక్తి నైపుణ్యం యొక్క మరొక ప్రాంతం ఏమి చేస్తుందో అర్థం చేసుకోలేరు. అతను మరొక విభాగానికి వెళతాడు, ఈ విభాగంతో తనకు తానుగా ఓరియంటేషన్ మరియు ఇంటరాక్షన్ మ్యాప్‌ను రూపొందించుకోవడానికి రెండు వారాల పాటు అక్కడ పని చేస్తాడు.
మార్పు కమిటీ వేసి పనులు మార్చడం సాధ్యమేనా? లేదా దీనికి అత్యున్నత నిర్వహణ మరియు దిశానిర్దేశం యొక్క బలమైన హస్తం అవసరమా? అంతగా తెలియని బ్యాంక్ ఆర్డర్‌ల ద్వారా సాధనాలను ఎలా అమలు చేస్తుందో నేను ఇటీవల Facebookలో వ్రాసాను: మేము ఒక ఆర్డర్‌ను వ్రాస్తాము, మేము దానిని ఒక సంవత్సరం పాటు అమలు చేస్తాము మరియు ఏమి జరుగుతుందో చూడండి. ఈ, కోర్సు, దీర్ఘ మరియు విచారంగా ఉంది.
కంపెనీ విజయాలను పరిగణనలోకి తీసుకోకుండా వ్యక్తిగత విజయాలను అందుకోవడం నిర్వాహకులకు ఎంత ముఖ్యమైనది?
ఈ ప్రశ్నలకు మీరే సమాధానమిస్తే, మీ కంపెనీలో మీకు అలాంటి సమస్య ఉందా లేదా అనేది స్పష్టమవుతుంది.
కోడ్‌గా మౌలిక సదుపాయాలు
ఈ సమస్య దాటిన తర్వాత, మొదటి ముఖ్యమైన అభ్యాసం, ఇది లేకుండా DevOpsలో మరింత ముందుకు సాగడం కష్టం కోడ్‌గా మౌలిక సదుపాయాలు.
చాలా తరచుగా, అవస్థాపన కోడ్‌గా ఈ క్రింది విధంగా గ్రహించబడుతుంది:
— బాష్‌లో ప్రతిదీ ఆటోమేట్ చేద్దాం, స్క్రిప్ట్‌లతో మనల్ని మనం కవర్ చేసుకోండి, తద్వారా నిర్వాహకులు తక్కువ మాన్యువల్ పనిని కలిగి ఉంటారు!
కానీ అది నిజం కాదు.
కోడ్‌గా ఇన్‌ఫ్రాస్ట్రక్చర్ అంటే మీరు పనిచేసే IT సిస్టమ్‌ని దాని స్థితిని నిరంతరం అర్థం చేసుకోవడానికి కోడ్ రూపంలో వివరించడం.
ఇతర బృందాలతో కలిసి, మీరు ప్రతి ఒక్కరూ అర్థం చేసుకోగలిగే మరియు నావిగేట్ చేయగల మరియు నావిగేట్ చేయగల కోడ్ రూపంలో మ్యాప్‌ను సృష్టించారు. ఇది ఏమి చేసినా పట్టింపు లేదు - చెఫ్, అన్సిబుల్, సాల్ట్ లేదా కుబెర్నెట్స్‌లో YAML ఫైల్‌లను ఉపయోగించడం - తేడా లేదు.
కాన్ఫరెన్స్‌లో, 2GISకి చెందిన ఒక సహోద్యోగి, వ్యక్తిగత వ్యవస్థల నిర్మాణాన్ని వివరించే కుబెర్నెట్స్ కోసం వారి స్వంత అంతర్గత వస్తువును ఎలా తయారు చేశారో చెప్పారు. 500 సిస్టమ్‌లను వివరించడానికి, వారికి ఈ వివరణను రూపొందించే ప్రత్యేక సాధనం అవసరం. ఈ వివరణ ఉన్నప్పుడు, ప్రతి ఒక్కరూ ఒకరితో ఒకరు తనిఖీ చేయవచ్చు, మార్పులను పర్యవేక్షించవచ్చు, దీన్ని ఎలా మార్చాలి మరియు మెరుగుపరచాలి, ఏమి లేదు.
అంగీకరిస్తున్నారు, వ్యక్తిగత బాష్ స్క్రిప్ట్‌లు సాధారణంగా ఈ అవగాహనను అందించవు. నేను పనిచేసిన కంపెనీలలో ఒకదానిలో, "వ్రాయడానికి మాత్రమే" స్క్రిప్ట్‌కు ఒక పేరు కూడా ఉంది - స్క్రిప్ట్ వ్రాసినప్పుడు, కానీ దానిని చదవడం సాధ్యం కాదు. ఇది మీకు కూడా సుపరిచితమేనని అనుకుంటున్నాను.
కోడ్ వలె మౌలిక సదుపాయాలు మౌలిక సదుపాయాల యొక్క ప్రస్తుత స్థితిని వివరించే కోడ్. అనేక ఉత్పత్తి, అవస్థాపన మరియు సేవా బృందాలు ఈ కోడ్‌పై కలిసి పని చేస్తాయి మరియు ముఖ్యంగా, ఈ కోడ్ వాస్తవానికి ఎలా పనిచేస్తుందో వారందరూ అర్థం చేసుకోవాలి.
ఉత్తమ కోడ్ అభ్యాసాల ప్రకారం కోడ్ నిర్వహించబడుతుంది: జాయింట్ డెవలప్‌మెంట్, కోడ్ రివ్యూ, XP-ప్రోగ్రామింగ్, టెస్టింగ్, పుల్ రిక్వెస్ట్‌లు, కోడ్ ఇన్‌ఫ్రాస్ట్రక్చర్‌ల కోసం CI - ఇవన్నీ అనుకూలంగా ఉంటాయి మరియు ఉపయోగించవచ్చు.
ఇంజనీర్లందరికీ కోడ్ ఒక సాధారణ భాష అవుతుంది.
కోడ్‌లో మౌలిక సదుపాయాలను మార్చడానికి ఎక్కువ సమయం పట్టదు. అవును, ఇన్‌ఫ్రాస్ట్రక్చర్ కోడ్ సాంకేతిక రుణాన్ని కూడా కలిగి ఉంటుంది. సాధారణంగా టీమ్‌లు "ఇన్‌ఫ్రాస్ట్రక్చర్‌ను కోడ్‌గా" అమలు చేయడం ప్రారంభించిన ఏడాదిన్నర తర్వాత స్క్రిప్టుల సమూహం లేదా అన్సిబుల్ రూపంలో కూడా వాటిని ఎదుర్కొంటారు, అవి స్పఘెట్టి కోడ్‌గా వ్రాస్తాయి మరియు వారు బాష్ స్క్రిప్ట్‌లను కూడా మిక్స్‌లోకి విసిరారు!
ముఖ్యమైన: మీరు ఇంకా ఈ విషయాన్ని ప్రయత్నించకుంటే, గుర్తుంచుకోండి అన్సిబుల్ బాష్ కాదు! డాక్యుమెంటేషన్‌ను జాగ్రత్తగా చదవండి, వారు దాని గురించి ఏమి వ్రాస్తారో అధ్యయనం చేయండి.
ఇన్‌ఫ్రాస్ట్రక్చర్ కోడ్‌గా ఇన్‌ఫ్రాస్ట్రక్చర్ కోడ్‌ను ప్రత్యేక పొరలుగా విభజించడం.
మా కంపెనీలో, మేము 3 ప్రాథమిక పొరలను వేరు చేస్తాము, అవి చాలా స్పష్టంగా మరియు సరళంగా ఉంటాయి, కానీ వాటిలో ఎక్కువ ఉండవచ్చు. మీరు మీ ఇన్‌ఫ్రాస్ట్రక్చర్ కోడ్‌ని చూసి, మీకు ఈ పరిస్థితి ఉందో లేదో చెప్పవచ్చు. లేయర్‌లు ఏవీ హైలైట్ చేయకపోతే, మీరు కొంత సమయాన్ని వెచ్చించి, కొద్దిగా రీఫాక్టర్ చేయాలి.
బేస్ పొర - ఈ విధంగా OS, బ్యాకప్‌లు మరియు ఇతర తక్కువ-స్థాయి విషయాలు కాన్ఫిగర్ చేయబడతాయి, ఉదాహరణకు, ప్రాథమిక స్థాయిలో Kubernetes ఎలా అమలు చేయబడుతుంది.
సేవా స్థాయి - ఇవి మీరు డెవలపర్‌కు అందించే సేవలు: సేవగా లాగింగ్, సేవగా పర్యవేక్షణ, సేవగా డేటాబేస్, సేవగా బ్యాలెన్సర్, సేవగా క్యూ, నిరంతర డెలివరీ - వ్యక్తిగత బృందాలు చేసే సేవల సమూహం అభివృద్ధికి అందించవచ్చు. ఇవన్నీ మీ కాన్ఫిగరేషన్ మేనేజ్‌మెంట్ సిస్టమ్‌లోని ప్రత్యేక మాడ్యూల్స్‌లో వివరించాలి.
అప్లికేషన్లు చేసిన లేయర్ మరియు మునుపటి రెండు లేయర్‌ల పైన అవి ఎలా విప్పుతాయో వివరిస్తుంది.
పరీక్ష ప్రశ్నలు
మీ కంపెనీకి సాధారణ ఇన్‌ఫ్రాస్ట్రక్చర్ రిపోజిటరీ ఉందా? మీరు మీ మౌలిక సదుపాయాలలో సాంకేతిక రుణాన్ని నిర్వహిస్తున్నారా? మీరు ఇన్‌ఫ్రాస్ట్రక్చర్ రిపోజిటరీలో అభివృద్ధి పద్ధతులను ఉపయోగిస్తున్నారా? మీ మౌలిక సదుపాయాలు పొరలుగా విభజించబడిందా? మీరు బేస్-సర్వీస్-APP రేఖాచిత్రాన్ని తనిఖీ చేయవచ్చు. మార్పు చేయడం ఎంత కష్టం?
మార్పులు చేయడానికి ఒకటిన్నర రోజులు పట్టిందని మీరు అనుభవించినట్లయితే, మీకు సాంకేతిక రుణం ఉందని మరియు దానితో పని చేయాలని అర్థం. మీరు మీ ఇన్‌ఫ్రాస్ట్రక్చర్ కోడ్‌లో సాంకేతిక రుణ రేక్‌లో చిక్కుకున్నారు. కొన్ని CCTLని మార్చడానికి, మీరు ఇన్‌ఫ్రాస్ట్రక్చర్ కోడ్‌లో సగం తిరిగి వ్రాయవలసి వచ్చినప్పుడు నాకు అలాంటి కథలు చాలా గుర్తున్నాయి, ఎందుకంటే సృజనాత్మకత మరియు ప్రతిదీ స్వయంచాలకంగా చేయాలనే కోరిక ప్రతిదీ ప్రతిచోటా తుప్పుపట్టింది, అన్ని హ్యాండిల్స్ తొలగించబడ్డాయి మరియు రీఫ్యాక్టర్ చేయడం అవసరం.
నిరంతర డెలివరీ
డెబిట్‌ని క్రెడిట్‌తో పోల్చి చూద్దాం. మొదట మౌలిక సదుపాయాల వివరణ వస్తుంది, ఇది చాలా ప్రాథమికమైనది. మీరు ప్రతిదీ వివరంగా వివరించాల్సిన అవసరం లేదు, కానీ కొన్ని ప్రాథమిక వివరణ అవసరం కాబట్టి మీరు దానితో పని చేయవచ్చు. లేకపోతే, తదుపరి డెలివరీతో ఏమి చేయాలో స్పష్టంగా లేదు. మీరు DevOpsకి వచ్చినప్పుడు ఈ అభ్యాసాలన్నీ ఏకకాలంలో జరుగుతాయి, అయితే ఇది మీ వద్ద ఏమి ఉంది మరియు దానిని ఎలా నిర్వహించాలో అర్థం చేసుకోవడంతో ప్రారంభమవుతుంది. ఇది ఖచ్చితంగా కోడ్‌గా మౌలిక సదుపాయాల అభ్యాసం.
మీరు దానిని కలిగి ఉన్నారని మరియు దానిని ఎలా నిర్వహించాలో స్పష్టంగా తెలియగానే, డెవలపర్ కోడ్‌ను వీలైనంత త్వరగా ఉత్పత్తికి ఎలా పంపాలో మీరు గుర్తించడం ప్రారంభిస్తారు. నా ఉద్దేశ్యం డెవలపర్‌తో కలిసి - “బావులు” సమస్య గురించి మేము గుర్తుంచుకుంటాము, అంటే, దీనితో ముందుకు వచ్చేది వ్యక్తిగత వ్యక్తులు కాదు, కానీ ఒక బృందం.
మేము తో ఉన్నప్పుడు వన్య ఎవ్తుఖోవిచ్ మొదటి పుస్తకం చూసింది జెజ్ హంబుల్ మరియు రచయితల సమూహాలు "నిరంతర డెలివరీ", ఇది 2009లో విడుదలైంది, దాని శీర్షికను రష్యన్‌లోకి ఎలా అనువదించాలో మేము చాలా కాలంగా ఆలోచించాము. వారు దానిని "నిరంతర బట్వాడా" అని అనువదించాలనుకున్నారు, కానీ, దురదృష్టవశాత్తు, అది "నిరంతర డెలివరీ"గా అనువదించబడింది. మా పేరులో ఏదో రష్యన్ ఉందని నాకు అనిపిస్తుంది, ఒత్తిడితో.
నిరంతరం పంపిణీ అంటే
ఉత్పత్తి రిపోజిటరీలో ఉన్న కోడ్ ఎల్లప్పుడూ ఉత్పత్తికి డౌన్‌లోడ్ చేయబడుతుంది. అతను నిరుత్సాహపడకపోవచ్చు, కానీ అతను ఎల్లప్పుడూ దానికి సిద్ధంగా ఉంటాడు. తదనుగుణంగా, మీరు ఎల్లప్పుడూ మీ టెయిల్‌బోన్ కింద కొంత ఆందోళనతో వివరించడానికి కష్టమైన అనుభూతితో కోడ్‌ను వ్రాస్తారు. మీరు ఇన్‌ఫ్రాస్ట్రక్చర్ కోడ్‌ను రూపొందించినప్పుడు ఇది తరచుగా కనిపిస్తుంది. కొంత ఆందోళన యొక్క ఈ భావన ఉండాలి - ఇది మెదడు ప్రక్రియలను ప్రేరేపిస్తుంది, ఇది కోడ్‌ను కొద్దిగా భిన్నంగా వ్రాయడానికి మిమ్మల్ని అనుమతిస్తుంది. ఇది అభివృద్ధి లోపల నియమాలలో నమోదు చేయబడాలి.
స్థిరంగా డెలివరీ చేయడానికి, మీకు ఇన్‌ఫ్రాస్ట్రక్చర్ ప్లాట్‌ఫారమ్‌లో ఉండే ఆర్టిఫ్యాక్ట్ ఫార్మాట్ అవసరం. మీరు ఇన్‌ఫ్రాస్ట్రక్చర్ ప్లాట్‌ఫారమ్‌లో విభిన్న ఫార్మాట్‌ల "జీవిత వ్యర్థాలను" విసిరితే, అది ఏకీకృతమవుతుంది, నిర్వహించడం కష్టం మరియు సాంకేతిక రుణ సమస్య తలెత్తుతుంది. కళాఖండం యొక్క ఆకృతిని సమలేఖనం చేయాలి - ఇది కూడా ఒక సమిష్టి పని: మనమందరం కలిసి, మన మెదడులను కదిలించి, ఈ ఆకృతితో ముందుకు రావాలి.
డెలివరీ పైప్లైన్ ద్వారా కదులుతున్నప్పుడు కళాఖండం నిరంతరం మెరుగుపరచబడుతుంది మరియు ఉత్పత్తి వాతావరణానికి అనుగుణంగా మారుతుంది. పైప్‌లైన్‌లో ఒక కళాఖండం కదులుతున్నప్పుడు, మీరు ఉత్పత్తిలో ఉంచిన కళాఖండం ఎదుర్కొన్న దానికి సమానమైన కొన్ని అసౌకర్యమైన విషయాలను అది నిరంతరం ఎదుర్కొంటుంది. క్లాసికల్ డెవలప్‌మెంట్‌లో దీన్ని రోల్‌అవుట్ చేసే సిస్టమ్ అడ్మినిస్ట్రేటర్ చేస్తే, DevOps ప్రాసెస్‌లో ఇది అన్ని సమయాలలో జరుగుతుంది: ఇక్కడ వారు దీన్ని కొన్ని పరీక్షలతో పరీక్షించారు, ఇక్కడ వారు దానిని కుబెర్నెటెస్ క్లస్టర్‌లోకి విసిరారు, ఇది ఎక్కువ లేదా తక్కువ సారూప్యతను కలిగి ఉంటుంది. ఉత్పత్తికి, అకస్మాత్తుగా వారు లోడ్ పరీక్షను ప్రారంభించారు.
ఇది కొంతవరకు పాక్-మ్యాన్ గేమ్‌ను గుర్తుకు తెస్తుంది - కళాఖండం ఒక రకమైన కథ ద్వారా వెళుతుంది. అదే సమయంలో, కోడ్ వాస్తవానికి కథ ద్వారా వెళుతుందో లేదో మరియు అది మీ ఉత్పత్తికి సంబంధించినది కాదా అనేది నియంత్రించడం ముఖ్యం. ఉత్పత్తి నుండి కథనాలను నిరంతర డెలివరీ ప్రక్రియలోకి లాగవచ్చు: ఏదైనా పడిపోయినప్పుడు ఇది ఇలా ఉంటుంది, ఇప్పుడు ఈ దృష్టాంతాన్ని సిస్టమ్ లోపల ప్రోగ్రామ్ చేద్దాం. ప్రతిసారీ కోడ్ ఈ దృష్టాంతంలో కూడా వెళుతుంది మరియు మీరు తదుపరిసారి ఈ సమస్యను ఎదుర్కోలేరు. ఇది మీ క్లయింట్‌ను చేరుకోవడానికి చాలా ముందుగానే మీరు దాని గురించి తెలుసుకుంటారు.
వివిధ విస్తరణ వ్యూహాలు. ఉదాహరణకు, మీరు వేర్వేరు క్లయింట్‌లలో కోడ్‌ను విభిన్నంగా పరీక్షించడానికి, కోడ్ ఎలా పని చేస్తుందనే దాని గురించి సమాచారాన్ని పొందడానికి మరియు 100 మిలియన్ల వినియోగదారులకు అందించిన దానికంటే చాలా ముందుగానే AB పరీక్ష లేదా కానరీ విస్తరణలను ఉపయోగిస్తారు.
“స్థిరంగా బట్వాడా” ఇలా కనిపిస్తుంది.
డెలివరీ ప్రక్రియ Dev, CI, Test, PreProd, Prod అనేది ప్రత్యేక వాతావరణం కాదు, ఇవి మీ కళాకృతి దాటిపోయే అగ్నినిరోధక మొత్తాలను కలిగి ఉన్న దశలు లేదా స్టేషన్‌లు.
మీరు బేస్ సర్వీస్ APPగా వివరించబడిన ఇన్‌ఫ్రాస్ట్రక్చర్ కోడ్‌ని కలిగి ఉంటే, అది సహాయపడుతుంది అన్ని స్క్రిప్ట్‌లను మర్చిపోవద్దు, మరియు వాటిని ఈ కళాఖండానికి కోడ్‌గా వ్రాయండి, కళాఖండాన్ని ప్రచారం చేయండి మరియు మీరు వెళ్ళేటప్పుడు దాన్ని మార్చండి.
స్వీయ-పరీక్ష ప్రశ్నలు
ఫీచర్ వివరణ నుండి 95% కేసులలో ఉత్పత్తికి విడుదల చేయడానికి సమయం ఒక వారం కంటే తక్కువ? పైప్లైన్ యొక్క ప్రతి దశలో కళాఖండం యొక్క నాణ్యత మెరుగుపడుతుందా? అది సాగే కథ ఏదైనా ఉందా? మీరు వివిధ విస్తరణ వ్యూహాలను ఉపయోగిస్తున్నారా?
అన్ని సమాధానాలు అవును అయితే, మీరు చాలా బాగుంది! వ్యాఖ్యలలో మీ సమాధానాలను వ్రాయండి - నేను సంతోషిస్తాను).
అభిప్రాయం
ఇది అన్నింటికంటే కష్టతరమైన అభ్యాసం. DevOpsConf కాన్ఫరెన్స్‌లో, Infobip నుండి ఒక సహోద్యోగి, దాని గురించి మాట్లాడుతూ, అతని మాటలలో కొంచెం గందరగోళంగా ఉన్నాడు, ఎందుకంటే మీరు ప్రతిదీ పర్యవేక్షించాల్సిన అవసరం ఉన్నందున ఇది నిజంగా చాలా క్లిష్టమైన అభ్యాసం!
ఉదాహరణకు, చాలా కాలం క్రితం, నేను Qik వద్ద పనిచేసినప్పుడు మరియు మేము ప్రతిదీ పర్యవేక్షించాల్సిన అవసరం ఉందని మేము గ్రహించాము. మేము దీన్ని చేసాము మరియు మేము ఇప్పుడు Zabbixలో 150 అంశాలను కలిగి ఉన్నాము, అవి నిరంతరం పర్యవేక్షించబడతాయి. ఇది భయానకంగా ఉంది, టెక్నికల్ డైరెక్టర్ తన ఆలయం వద్ద తన వేలును తిప్పాడు:
- అబ్బాయిలు, మీరు అస్పష్టంగా ఉన్న సర్వర్‌ను ఎందుకు రేప్ చేస్తున్నారు?
కానీ ఇది నిజంగా చాలా కూల్ స్ట్రాటజీ అని చూపించే సంఘటన జరిగింది.
సేవల్లో ఒకటి నిరంతరం క్రాష్ అవ్వడం ప్రారంభించింది. ప్రారంభంలో, ఇది క్రాష్ కాలేదు, ఇది ఆసక్తికరంగా ఉంది, కోడ్ అక్కడ జోడించబడలేదు, ఎందుకంటే ఇది ప్రాథమిక బ్రోకర్, ఇది ఆచరణాత్మకంగా వ్యాపార కార్యాచరణను కలిగి ఉండదు - ఇది కేవలం వ్యక్తిగత సేవల మధ్య సందేశాలను పంపింది. సేవ 4 నెలలు మారలేదు మరియు అకస్మాత్తుగా "సెగ్మెంటేషన్ ఫాల్ట్" లోపంతో క్రాష్ అవ్వడం ప్రారంభించింది.
మేము షాక్ అయ్యాము, Zabbixలో మా చార్ట్‌లను తెరిచాము మరియు ఈ బ్రోకర్ ఉపయోగించే API సేవలోని అభ్యర్థనల ప్రవర్తన వారంన్నర క్రితం బాగా మారిపోయిందని తేలింది. ఒక నిర్దిష్ట రకమైన సందేశాన్ని పంపే ఫ్రీక్వెన్సీ మారిందని మేము తరువాత చూశాము. ఇవి ఆండ్రాయిడ్ క్లయింట్లు అని తరువాత మేము కనుగొన్నాము. మేము అడిగాము:
— గైస్, మీకు వారంన్నర క్రితం ఏమి జరిగింది?
ప్రతిస్పందనగా, వారు UIని ఎలా రీడిజైన్ చేసారు అనే ఆసక్తికరమైన కథనాన్ని మేము విన్నాము. HTTP లైబ్రరీని మార్చినట్లు ఎవరైనా వెంటనే చెప్పే అవకాశం లేదు. ఆండ్రాయిడ్ క్లయింట్‌ల కోసం, ఇది బాత్రూంలో సబ్బును మార్చడం లాంటిది - వారికి గుర్తుండదు. ఫలితంగా, 40 నిమిషాల సంభాషణ తర్వాత, వారు HTTP లైబ్రరీని మార్చారని మరియు దాని డిఫాల్ట్ సమయాలు మారాయని మేము కనుగొన్నాము. ఇది API సర్వర్‌లో ట్రాఫిక్ ప్రవర్తనను మార్చడానికి దారితీసింది, ఇది బ్రోకర్‌లో రేసును కలిగించే పరిస్థితికి దారితీసింది మరియు అది క్రాష్ అవ్వడం ప్రారంభించింది.
లోతైన పర్యవేక్షణ లేకుండా దీన్ని తెరవడం సాధారణంగా అసాధ్యం. సంస్థ ఇప్పటికీ "బావులు" సమస్యను కలిగి ఉంటే, ప్రతి ఒక్కరూ ఒకరిపై ఒకరు డబ్బు విసిరినప్పుడు, ఇది సంవత్సరాలు జీవించగలదు. మీరు సర్వర్‌ని పునఃప్రారంభించండి ఎందుకంటే సమస్యను పరిష్కరించడం అసాధ్యం. మీరు మీ వద్ద ఉన్న అన్ని ఈవెంట్‌లను పర్యవేక్షించడం, ట్రాక్ చేయడం, ట్రాక్ చేయడం మరియు మానిటరింగ్‌ని టెస్టింగ్‌గా ఉపయోగించడం - కోడ్‌ను వ్రాసి, దానిని ఎలా పర్యవేక్షించాలో వెంటనే సూచించినప్పుడు, కోడ్ రూపంలో కూడా (మేము ఇప్పటికే ఇన్‌ఫ్రాస్ట్రక్చర్‌ని కోడ్‌గా కలిగి ఉన్నాము), ఎలా ప్రతిదీ స్పష్టంగా తెలుస్తుంది అరచేతిలో. అటువంటి సంక్లిష్ట సమస్యలను కూడా సులభంగా ట్రాక్ చేయవచ్చు.
డెలివరీ ప్రక్రియ యొక్క ప్రతి దశలో కళాకృతికి ఏమి జరుగుతుంది అనే దాని గురించి మొత్తం సమాచారాన్ని సేకరించండి - ఉత్పత్తిలో కాదు.
పర్యవేక్షణను CIకి అప్‌లోడ్ చేయండి మరియు కొన్ని ప్రాథమిక విషయాలు ఇప్పటికే అక్కడ కనిపిస్తాయి. తర్వాత మీరు వాటిని టెస్ట్, ప్రిడ్‌ప్రోడ్ మరియు లోడ్ టెస్టింగ్‌లో చూస్తారు. మెట్రిక్‌లు, గణాంకాలు మాత్రమే కాకుండా లాగ్‌లు కూడా అన్ని దశల్లో సమాచారాన్ని సేకరించండి: అప్లికేషన్ ఎలా రూపొందించబడింది, క్రమరాహిత్యాలు - ప్రతిదీ సేకరించండి.
లేకపోతే దాన్ని గుర్తించడం కష్టం. DevOps మరింత క్లిష్టంగా ఉందని నేను ఇప్పటికే చెప్పాను. ఈ సంక్లిష్టతను అధిగమించడానికి, మీరు సాధారణ విశ్లేషణలను కలిగి ఉండాలి.
స్వీయ నియంత్రణ కోసం ప్రశ్నలు
మీ పర్యవేక్షణ మరియు లాగింగ్ మీ కోసం అభివృద్ధి సాధనమా? కోడ్ రాసేటప్పుడు, మీతో సహా మీ డెవలపర్లు దీన్ని ఎలా పర్యవేక్షించాలో ఆలోచిస్తారా?
మీరు కస్టమర్ల నుండి సమస్యల గురించి వింటున్నారా? మీరు పర్యవేక్షణ మరియు లాగింగ్ నుండి క్లయింట్‌ను బాగా అర్థం చేసుకున్నారా? పర్యవేక్షణ మరియు లాగింగ్ నుండి మీరు సిస్టమ్‌ను బాగా అర్థం చేసుకున్నారా? సిస్టమ్‌లో ట్రెండ్ పెరుగుతోందని మరియు మరో 3 వారాల్లో అంతా చనిపోతుందని మీరు అర్థం చేసుకున్నందున మీరు సిస్టమ్‌ను మారుస్తారా?
మీరు ఈ మూడు భాగాలను కలిగి ఉన్న తర్వాత, మీ కంపెనీలో మీకు ఎలాంటి ఇన్‌ఫ్రాస్ట్రక్చర్ ప్లాట్‌ఫారమ్ ఉందో మీరు ఆలోచించవచ్చు.
మౌలిక సదుపాయాల వేదిక
ఇది ప్రతి కంపెనీని కలిగి ఉన్న అసమాన సాధనాల సమితి అని కాదు.
ఇన్‌ఫ్రాస్ట్రక్చర్ ప్లాట్‌ఫారమ్ యొక్క అంశం ఏమిటంటే, అన్ని బృందాలు ఈ సాధనాలను ఉపయోగిస్తాయి మరియు వాటిని కలిసి అభివృద్ధి చేస్తాయి.
ఇన్‌ఫ్రాస్ట్రక్చర్ ప్లాట్‌ఫారమ్ యొక్క వ్యక్తిగత భాగాల అభివృద్ధికి బాధ్యత వహించే ప్రత్యేక బృందాలు ఉన్నాయని స్పష్టంగా తెలుస్తుంది. కానీ అదే సమయంలో, ప్రతి ఇంజనీర్ మౌలిక సదుపాయాల ప్లాట్‌ఫారమ్ అభివృద్ధి, పనితీరు మరియు ప్రమోషన్‌కు బాధ్యత వహిస్తారు. అంతర్గత స్థాయిలో ఇది సాధారణ సాధనంగా మారుతుంది.
అన్ని బృందాలు ఇన్‌ఫ్రాస్ట్రక్చర్ ప్లాట్‌ఫారమ్‌ను అభివృద్ధి చేస్తాయి మరియు దానిని వారి స్వంత IDE వలె జాగ్రత్తగా చూసుకుంటాయి. మీ IDEలో మీరు ప్రతిదీ చక్కగా మరియు వేగంగా చేయడానికి వివిధ ప్లగిన్‌లను ఇన్స్టాల్ చేయండి మరియు హాట్‌కీలను కాన్ఫిగర్ చేయండి. మీరు సబ్‌లైమ్, అటామ్ లేదా విజువల్ స్టూడియో కోడ్‌ని తెరిచినప్పుడు, అక్కడ కోడ్ ఎర్రర్‌లు కనిపిస్తాయి మరియు పని చేయడం అసాధ్యమని మీరు గ్రహిస్తారు, మీరు వెంటనే విచారంగా మరియు మీ IDEని సరిచేయడానికి పరుగెత్తుతారు.
మీ ఇన్‌ఫ్రాస్ట్రక్చర్ ప్లాట్‌ఫారమ్‌ను అదే విధంగా పరిగణించండి. దానిలో ఏదో తప్పు ఉందని మీరు అర్థం చేసుకుంటే, మీరే దాన్ని పరిష్కరించలేకపోతే ఒక అభ్యర్థనను వదిలివేయండి. ఏదైనా సింపుల్ గా ఉంటే మీరే ఎడిట్ చేసి, పుల్ రిక్వెస్ట్ పంపండి, అబ్బాయిలు దానిని పరిశీలించి జోడించుకుంటారు. డెవలపర్ హెడ్‌లోని ఇంజనీరింగ్ సాధనాలకు ఇది కొద్దిగా భిన్నమైన విధానం.
ఇన్‌ఫ్రాస్ట్రక్చర్ ప్లాట్‌ఫారమ్ నాణ్యతలో స్థిరమైన మెరుగుదలతో కళాఖండాన్ని అభివృద్ధి నుండి క్లయింట్‌కు బదిలీ చేయడాన్ని నిర్ధారిస్తుంది.. ఉత్పత్తిలో కోడ్‌కు సంబంధించిన కథనాల సెట్‌తో IP ప్రోగ్రామ్ చేయబడింది. అభివృద్ధి చెందుతున్న సంవత్సరాలలో, ఈ కథనాలు చాలా ఉన్నాయి, వాటిలో కొన్ని ప్రత్యేకమైనవి మరియు మీకు మాత్రమే సంబంధించినవి - వాటిని గూగుల్ చేయడం సాధ్యం కాదు.
ఈ సమయంలో, ఇన్‌ఫ్రాస్ట్రక్చర్ ప్లాట్‌ఫారమ్ మీ పోటీ ప్రయోజనంగా మారుతుంది, ఎందుకంటే పోటీదారు సాధనంలో లేని దానిలో ఏదైనా నిర్మించబడింది. మీ IP ఎంత లోతుగా ఉంటే, టైమ్-టు-మార్కెట్ పరంగా మీ పోటీతత్వ ప్రయోజనం అంత ఎక్కువగా ఉంటుంది. ఇక్కడ కనిపిస్తుంది విక్రేత లాక్ సమస్య: మీరు వేరొకరి ప్లాట్‌ఫారమ్‌ను తీసుకోవచ్చు, కానీ వేరొకరి అనుభవాన్ని ఉపయోగించి, అది మీకు ఎంత సందర్భోచితంగా ఉందో మీరు అర్థం చేసుకోలేరు. అవును, ప్రతి కంపెనీ అమెజాన్ వంటి ప్లాట్‌ఫారమ్‌ను నిర్మించదు. కంపెనీ అనుభవం మార్కెట్లో దాని స్థానానికి సంబంధించినది మరియు మీరు అక్కడ విక్రేత లాక్‌ని ఉపయోగించలేరు. ఇది కూడా ఆలోచించడం ముఖ్యం.
పథకం
ఇది DevOps కంపెనీలో అన్ని అభ్యాసాలు మరియు ప్రక్రియలను సెటప్ చేయడంలో మీకు సహాయపడే ఇన్‌ఫ్రాస్ట్రక్చర్ ప్లాట్‌ఫారమ్ యొక్క ప్రాథమిక రేఖాచిత్రం.
అందులో ఏమి ఉందో చూద్దాం.
రిసోర్స్ ఆర్కెస్ట్రేషన్ సిస్టమ్, ఇది CPU, మెమరీ, అప్లికేషన్లు మరియు ఇతర సేవలకు డిస్క్‌ని అందిస్తుంది. ఈ పైన - తక్కువ స్థాయి సేవలు: పర్యవేక్షణ, లాగింగ్, CI/CD ఇంజిన్, ఆర్టిఫ్యాక్ట్ స్టోరేజ్, సిస్టమ్ కోడ్‌గా మౌలిక సదుపాయాలు.
ఉన్నత స్థాయి సేవలు: డేటాబేస్ ఒక సేవగా, క్యూలు ఒక సేవగా, లోడ్ బ్యాలెన్స్‌ని సేవగా, ఇమేజ్ రీసైజింగ్ సేవగా, బిగ్ డేటా ఫ్యాక్టరీని సేవగా మార్చడం. ఈ పైన - మీ క్లయింట్‌కు నిరంతరం సవరించిన కోడ్‌ను అందించే పైప్లైన్.
క్లయింట్ కోసం మీ సాఫ్ట్‌వేర్ ఎలా పనిచేస్తుందనే దాని గురించి మీరు సమాచారాన్ని స్వీకరిస్తారు, దాన్ని మార్చండి, ఈ కోడ్‌ని మళ్లీ సరఫరా చేయండి, సమాచారాన్ని స్వీకరించండి - తద్వారా మీరు ఇన్‌ఫ్రాస్ట్రక్చర్ ప్లాట్‌ఫారమ్ మరియు మీ సాఫ్ట్‌వేర్ రెండింటినీ నిరంతరం అభివృద్ధి చేస్తారు.
రేఖాచిత్రంలో, డెలివరీ పైప్లైన్ అనేక దశలను కలిగి ఉంటుంది. కానీ ఇది ఒక ఉదాహరణగా ఇవ్వబడిన స్కీమాటిక్ రేఖాచిత్రం - దీన్ని ఒక్కొక్కటిగా పునరావృతం చేయవలసిన అవసరం లేదు. స్టేజీలు సేవలతో పరస్పరం సంకర్షణ చెందుతాయి - ప్లాట్‌ఫారమ్‌లోని ప్రతి ఇటుక దాని స్వంత కథనాన్ని కలిగి ఉంటుంది: వనరులు ఎలా కేటాయించబడతాయి, అప్లికేషన్ ఎలా ప్రారంభించబడింది, వనరులతో పని చేస్తుంది, పర్యవేక్షించబడుతుంది మరియు మార్పులు.
ప్లాట్‌ఫారమ్‌లోని ప్రతి భాగం ఒక కథనాన్ని కలిగి ఉందని అర్థం చేసుకోవడం చాలా ముఖ్యం, మరియు ఈ ఇటుక ఏ కథనాన్ని తీసుకువెళుతుందో మీరే ప్రశ్నించుకోండి, బహుశా దానిని విసిరివేసి, మూడవ పక్ష సేవతో భర్తీ చేయాలి. ఉదాహరణకు, ఒక ఇటుక బదులుగా Okmeter ఇన్స్టాల్ సాధ్యమేనా? బహుశా అబ్బాయిలు ఇప్పటికే ఈ నైపుణ్యాన్ని మన కంటే ఎక్కువగా అభివృద్ధి చేసి ఉండవచ్చు. కానీ కాకపోవచ్చు - బహుశా మనకు ప్రత్యేకమైన నైపుణ్యం ఉండవచ్చు, మేము ప్రోమేథియస్‌ని ఇన్స్టాల్ చేసి దానిని మరింత అభివృద్ధి చేయాలి.
వేదిక యొక్క సృష్టి
ఇది సంక్లిష్టమైన కమ్యూనికేషన్ ప్రక్రియ. మీరు ప్రాథమిక అభ్యాసాలను కలిగి ఉన్నప్పుడు, మీరు అవసరాలు మరియు ప్రమాణాలను అభివృద్ధి చేసే వివిధ ఇంజనీర్లు మరియు నిపుణుల మధ్య కమ్యూనికేషన్‌ను ప్రారంభిస్తారు మరియు వాటిని వివిధ సాధనాలు మరియు విధానాలకు నిరంతరం మారుస్తారు. DevOpsలో మనకు ఉన్న సంస్కృతి ఇక్కడ ముఖ్యమైనది.
సంస్కృతితో ప్రతిదీ చాలా సులభం - ఇది సహకారం మరియు కమ్యూనికేషన్ గురించి, అంటే, ఒకరికొకరు ఉమ్మడి రంగంలో పని చేయాలనే కోరిక, ఒక పరికరాన్ని కలిసి ఉపయోగించాలనే కోరిక. ఇక్కడ రాకెట్ సైన్స్ లేదు - ప్రతిదీ చాలా సులభం, సామాన్యమైనది. ఉదాహరణకు, మనమందరం ప్రవేశ ద్వారంలో నివసిస్తున్నాము మరియు దానిని శుభ్రంగా ఉంచుతాము - అటువంటి స్థాయి సంస్కృతి.
మీ దగ్గర ఏమి ఉంది?
మళ్ళీ, మీరే ప్రశ్నలు అడగవచ్చు.
మౌలిక సదుపాయాల వేదిక అంకితం చేయబడిందా? దాని అభివృద్ధికి ఎవరు బాధ్యత వహిస్తారు? మీ ఇన్‌ఫ్రాస్ట్రక్చర్ ప్లాట్‌ఫారమ్ యొక్క పోటీ ప్రయోజనాలను మీరు అర్థం చేసుకున్నారా?
మీరు నిరంతరం ఈ ప్రశ్నలను మీరే అడగాలి. మూడవ పక్షం సేవలకు ఏదైనా బదిలీ చేయగలిగితే, అది బదిలీ చేయబడాలి; మూడవ పక్ష సేవ మీ కదలికను నిరోధించడం ప్రారంభిస్తే, మీరు మీలో ఒక వ్యవస్థను నిర్మించుకోవాలి.
కాబట్టి, DevOps...
... ఇది సంక్లిష్టమైన వ్యవస్థ, ఇది కలిగి ఉండాలి:
- డిజిటల్ ఉత్పత్తి.
- ఈ డిజిటల్ ఉత్పత్తిని అభివృద్ధి చేసే వ్యాపార మాడ్యూల్స్.
- కోడ్ వ్రాసే ఉత్పత్తి బృందాలు.
- నిరంతర డెలివరీ పద్ధతులు.
- ఒక సేవ వలె వేదికలు.
- ఒక సేవగా మౌలిక సదుపాయాలు.
- కోడ్‌గా మౌలిక సదుపాయాలు.
- విశ్వసనీయతను నిర్వహించడానికి ప్రత్యేక పద్ధతులు, DevOpsలో నిర్మించబడ్డాయి.
- అన్నింటినీ వివరించే ఫీడ్‌బ్యాక్ అభ్యాసం.
మీరు ఈ రేఖాచిత్రాన్ని ఉపయోగించవచ్చు, మీరు మీ కంపెనీలో ఇప్పటికే ఉన్న వాటిని ఏదో ఒక రూపంలో హైలైట్ చేయవచ్చు: ఇది అభివృద్ధి చేయబడిందా లేదా ఇంకా అభివృద్ధి చేయబడాలి.
ఇది రెండు వారాల్లో అయిపోతుంది . RIT++లో భాగంగా. కాన్ఫరెన్స్‌కు రండి, ఇక్కడ మీరు నిరంతర డెలివరీ, కోడ్‌గా మౌలిక సదుపాయాలు మరియు DevOps రూపాంతరం గురించి అనేక అద్భుతమైన నివేదికలను కనుగొంటారు. , చివరి ధర గడువు మే 20
మూలం: www.habr.com