"డెవొప్స్‌ను ఎలా అమలు చేయాలి" అనే ప్రశ్న చాలా సంవత్సరాలుగా ఉంది, కానీ చాలా మంచి మెటీరియల్‌లు లేవు. కొన్నిసార్లు మీరు తమ సమయాన్ని ఎలా అమ్ముకోవాల్సిన అంత తెలివైన కన్సల్టెంట్‌ల ప్రకటనల బారిన పడతారు. కొన్నిసార్లు ఇవి అస్పష్టమైన, మెగాకార్పొరేషన్ల నౌకలు విశ్వం యొక్క విస్తరణలను ఎలా దున్నుతున్నాయనే దాని గురించి చాలా సాధారణ పదాలు. ప్రశ్న తలెత్తుతుంది: ఇది మనకు ఏది ముఖ్యమైనది? ప్రియమైన రచయిత, మీరు మీ ఆలోచనలను జాబితాలో స్పష్టంగా రూపొందించగలరా?
సంస్థ యొక్క సంస్కృతి యొక్క పరివర్తనల ఫలితం గురించి చాలా నిజమైన అభ్యాసం మరియు అవగాహన పేరుకుపోలేదు అనే వాస్తవం నుండి ఇదంతా వచ్చింది. సంస్కృతిలో మార్పులు దీర్ఘకాలిక విషయాలు, దీని ఫలితాలు ఒక వారం లేదా ఒక నెలలో కనిపించవు. సంవత్సరాలుగా కంపెనీలు ఎలా నిర్మించబడ్డాయి మరియు విఫలమయ్యాయో చూసేంత వయస్సు గల వ్యక్తి మనకు కావాలి.
జాన్ విల్లీస్ - DevOps యొక్క తండ్రులలో ఒకరు. జాన్‌కు భారీ సంఖ్యలో కంపెనీలతో పనిచేసిన దశాబ్దాల అనుభవం ఉంది. ఇటీవల, జాన్ ప్రతి ఒక్కరితో పనిచేసేటప్పుడు జరిగే నిర్దిష్ట నమూనాలను గమనించడం ప్రారంభించాడు. ఈ ఆర్కిటైప్‌లను ఉపయోగించి, DevOps పరివర్తన యొక్క నిజమైన మార్గంలో జాన్ కంపెనీలకు మార్గనిర్దేశం చేస్తాడు. DevOops 2018 కాన్ఫరెన్స్ నుండి అతని నివేదిక యొక్క అనువాదంలో ఈ ఆర్కిటైప్‌ల గురించి మరింత చదవండి.
స్పీకర్ గురించి:
ఐటి నిర్వహణలో 35 సంవత్సరాలకు పైగా, కానానికల్‌లో ఓపెన్‌క్లౌడ్ యొక్క పూర్వీకుల సృష్టిలో పాల్గొన్నారు, 10 స్టార్టప్‌లలో పాల్గొన్నారు, వాటిలో రెండు డెల్ మరియు డాకర్‌కు విక్రయించబడ్డాయి. ప్రస్తుతం అతను SJ టెక్నాలజీస్‌లో DevOps మరియు డిజిటల్ ప్రాక్టీసెస్ వైస్ ప్రెసిడెంట్.
తదుపరిది జాన్ దృష్టికోణం నుండి కథ.
నా పేరు జాన్ విల్లీస్ మరియు నన్ను కనుగొనడానికి సులభమైన ప్రదేశం Twitter, . నాకు Gmail మరియు GitHubలో అదే మారుపేరు ఉంది. ఎ మీరు నా నివేదికల వీడియో రికార్డింగ్‌లు మరియు వాటి కోసం ప్రెజెంటేషన్‌లను కనుగొనవచ్చు.
నేను వివిధ పెద్ద కంపెనీల CIOలతో చాలా సమావేశాలను కలిగి ఉన్నాను. DevOps అంటే ఏమిటో తమకు అర్థం కావడం లేదని వారు చాలా తరచుగా ఫిర్యాదు చేస్తారు మరియు వారికి వివరించడానికి ప్రయత్నించే ప్రతి ఒక్కరూ భిన్నమైన దాని గురించి మాట్లాడుతున్నారు. మరో సాధారణ ఫిర్యాదు ఏమిటంటే, DevOps పని చేయదు, అయినప్పటికీ డైరెక్టర్లు వారికి వివరించినట్లుగా ప్రతిదీ చేస్తున్నట్లు అనిపిస్తుంది. మేము వంద సంవత్సరాల కంటే ఎక్కువ వయస్సు ఉన్న పెద్ద కంపెనీల గురించి మాట్లాడుతున్నాము. వారితో మాట్లాడిన తర్వాత, చాలా సమస్యలకు, ఇది అత్యంత అనుకూలమైన సాంకేతికత కాదు, సాపేక్షంగా తక్కువ-టెక్ పరిష్కారాలు అని నేను నిర్ధారణకు వచ్చాను. వారాల తరబడి నేను వివిధ విభాగాల వ్యక్తులతో మాట్లాడాను. పోస్ట్‌లోని మొదటి చిత్రంలో మీరు చూసేది నా చివరి ప్రాజెక్ట్, ఇది మూడు రోజుల పని తర్వాత గది ఎలా ఉంది.
DevOps అంటే ఏమిటి?
నిజానికి, మీరు 10 మంది వ్యక్తులను అడిగితే, వారు 10 వేర్వేరు సమాధానాలు ఇస్తారు. అయితే ఇక్కడ ఆసక్తికరమైన విషయం ఏమిటంటే: ఈ పది సమాధానాలూ సరైనవే. ఇక్కడ తప్పు సమాధానం లేదు. నేను దాదాపు 10 సంవత్సరాల పాటు DevOpsలో చాలా లోతుగా ఉన్నాను మరియు మొదటి DevOpsDayలో మొదటి అమెరికన్‌ని. DevOpsలో పాల్గొన్న ప్రతి ఒక్కరి కంటే నేను తెలివైనవాడినని చెప్పను, కానీ దాని కోసం ఎక్కువ కృషి చేసిన వారు ఎవరూ లేరు. మానవ మూలధనం మరియు సాంకేతికత కలిసి వచ్చినప్పుడు DevOps ఏర్పడుతుందని నేను నమ్ముతున్నాను. మేము అన్ని రకాల సంస్కృతుల గురించి చాలా మాట్లాడినప్పటికీ, మనం తరచుగా మానవ కోణాన్ని మరచిపోతాము.
ఇప్పుడు మనకు చాలా డేటా ఉంది, ఐదు సంవత్సరాల విద్యా పరిశోధన, పారిశ్రామిక స్థాయిలో సిద్ధాంతాలను పరీక్షించడం. ఈ అధ్యయనాలు మాకు చెప్పేది ఏమిటంటే, మీరు సంస్థాగత సంస్కృతిలో కొన్ని ప్రవర్తనా విధానాలను మిళితం చేస్తే, మీరు 2000x వేగాన్ని సాధించవచ్చు. ఈ త్వరణం స్థిరత్వంలో సమానమైన మెరుగుదలతో సరిపోలింది. ఇది DevOps ఏ కంపెనీకైనా తీసుకురాగల ప్రయోజనం యొక్క పరిమాణాత్మక కొలత. కొన్ని సంవత్సరాల క్రితం, నేను ఫార్చ్యూన్ 5000 కంపెనీ CEO తో DevOps గురించి మాట్లాడుతున్నాను. నేను ప్రెజెంటేషన్‌కు సిద్ధమవుతున్నప్పుడు, నా సంవత్సరాల అనుభవాన్ని 5 నిమిషాల్లో క్లుప్తీకరించవలసి వచ్చినందున నేను చాలా భయపడ్డాను.
చివరికి నేను ఈ క్రింది విధంగా ఇచ్చాను DevOps నిర్వచనం: ఇది మానవ మూలధనాన్ని అధిక-పనితీరు గల సంస్థాగత మూలధనంగా మార్చడానికి వీలు కల్పించే అభ్యాసాలు మరియు నమూనాల సమితి. గత 50 లేదా 60 సంవత్సరాలుగా టయోటా పనిచేస్తున్న తీరు ఒక ఉదాహరణ.
(ఇకపై, అటువంటి రేఖాచిత్రాలు రిఫరెన్స్ మెటీరియల్‌గా కాకుండా, దృష్టాంతాలుగా అందించబడ్డాయి. ప్రతి కొత్త కంపెనీకి వాటి కంటెంట్ భిన్నంగా ఉంటుంది. అయితే, చిత్రాన్ని విడిగా చూడవచ్చు మరియు విస్తరించవచ్చు
అటువంటి అత్యంత విజయవంతమైన అభ్యాసాలలో ఒకటి విలువ స్ట్రీమ్ మ్యాపింగ్. దీని గురించి అనేక మంచి పుస్తకాలు వ్రాయబడ్డాయి, వాటిలో అత్యంత విజయవంతమైనవి కరెన్ మార్టిన్. కానీ గత సంవత్సరంలో, ఈ విధానం కూడా చాలా హైటెక్ అని నేను నిర్ధారణకు వచ్చాను. ఇది ఖచ్చితంగా చాలా ప్రయోజనాలను కలిగి ఉంది మరియు నేను దీన్ని చాలా ఉపయోగించాను. కానీ CEO తన కంపెనీ కొత్త పట్టాలకు ఎందుకు మారదు అని మిమ్మల్ని అడిగినప్పుడు, వాల్యూ స్ట్రీమ్ మ్యాపింగ్ గురించి మాట్లాడటం చాలా తొందరగా ఉంది. ఇంకా చాలా ప్రాథమిక ప్రశ్నలు ఉన్నాయి, అవి మొదట సమాధానం ఇవ్వాలి.
నా సహోద్యోగులలో చాలామంది చేసే పొరపాటు ఏమిటంటే వారు కంపెనీకి ఐదు-పాయింట్ గైడ్‌ని అందించి, ఆరు నెలల తర్వాత తిరిగి వచ్చి ఏమి జరిగిందో చూడటం. వాల్యూ స్ట్రీమ్ మ్యాపింగ్ వంటి మంచి పథకం కూడా బ్లైండ్ స్పాట్‌లను కలిగి ఉంటుంది. వివిధ కంపెనీల డైరెక్టర్లతో వందలాది ఇంటర్వ్యూల తర్వాత, నేను సమస్యను దాని భాగాలుగా విభజించడానికి అనుమతించే ఒక నిర్దిష్ట నమూనాను అభివృద్ధి చేసాను మరియు ఇప్పుడు మేము ఈ భాగాలలో ప్రతిదానిని క్రమంలో చర్చిస్తాము. ఏదైనా సాంకేతిక పరిష్కారాలను వర్తించే ముందు, నేను ఈ నమూనాను ఉపయోగిస్తాను మరియు ఫలితంగా, నా గోడలన్నీ రేఖాచిత్రాలతో కప్పబడి ఉంటాయి. ఇటీవల నేను మ్యూచువల్ ఫండ్‌తో పని చేస్తున్నాను మరియు నేను అలాంటి 100-150 పథకాలతో ముగించాను.
చెడు సంస్కృతి అల్పాహారం కోసం మంచి విధానాలను తింటుంది
ప్రధాన ఆలోచన ఇది: సంస్థ యొక్క సంస్కృతి చెడ్డది అయితే లీన్, ఎజైల్, SAFE మరియు DevOps సహాయం చేయవు. ఇది స్కూబా గేర్ లేకుండా లోతులకు డైవింగ్ చేయడం లేదా ఎక్స్-రే లేకుండా ఆపరేట్ చేయడం లాంటిది. మరో మాటలో చెప్పాలంటే, డ్రక్కర్ మరియు డెమింగ్‌లను పారాఫ్రేజ్ చేయడానికి: చెడు సంస్థాగత సంస్కృతి ఏదైనా మంచి వ్యవస్థను ఉక్కిరిబిక్కిరి చేయకుండా మింగేస్తుంది.
ఈ ప్రధాన సమస్యను పరిష్కరించడానికి, మీరు ఈ క్రింది దశలను తీసుకోవాలి:
- అన్ని పనులను కనిపించేలా చేయండి: మీరు అన్ని పనిని కనిపించేలా చేయాలి. ఇది తప్పనిసరిగా ఏదో ఒక స్క్రీన్‌పై ప్రదర్శించబడాలి అనే కోణంలో కాదు, కానీ అది గమనించదగినదిగా ఉండాలి.
- ఏకీకృత పని నిర్వహణ వ్యవస్థలు: నిర్వహణ వ్యవస్థలను ఏకీకృతం చేయాలి. "గిరిజన" జ్ఞానం మరియు సంస్థాగత జ్ఞానం యొక్క సమస్యలో, 9 కేసులలో 10 సందర్భాలలో ప్రజలు అడ్డంకిగా ఉన్నారు. పుస్తకంలో బ్రెంట్ అనే ఒకే వ్యక్తితో సమస్య ఏర్పడింది, అతను ప్రాజెక్ట్ షెడ్యూల్ కంటే మూడు సంవత్సరాలు వెనుకబడి ఉండటానికి కారణమైంది. మరియు నేను ప్రతిచోటా ఈ "బ్రెంట్స్"లోకి ప్రవేశిస్తాను. ఈ అడ్డంకులను పరిష్కరించడానికి, నేను మా జాబితాలోని తదుపరి రెండు అంశాలను ఉపయోగిస్తాను.
- పరిమితుల పద్దతి యొక్క సిద్ధాంతం: పరిమితుల సిద్ధాంతం.
- సహకార హక్స్: సహకార హక్స్.
- టయోటా కటా (): నేను టయోటా కాటా గురించి ఎక్కువగా మాట్లాడను. ఆసక్తి ఉంటే, నా గితుబ్‌లో ఈ అంశాలలో దాదాపు ప్రతి ఒక్కదానిపై.
- మార్కెట్ ఓరియెంటెడ్ ఆర్గనైజేషన్: మార్కెట్ ఆధారిత సంస్థ.
- షిఫ్ట్-లెఫ్ట్ ఆడిటర్లు: చక్రం యొక్క ప్రారంభ దశలలో ఆడిట్.
నేను చాలా సరళంగా సంస్థతో పనిచేయడం ప్రారంభిస్తాను: నేను కంపెనీకి వెళ్లి ఉద్యోగులతో మాట్లాడతాను. మీరు గమనిస్తే, అధిక సాంకేతికత లేదు. మీకు కావలసిందల్లా రాయడానికి. నేను ఒకే గదిలో అనేక బృందాలను సేకరించి, నా 7 ఆర్కిటైప్‌ల కోణం నుండి వారు నాకు చెప్పే వాటిని విశ్లేషిస్తాను. ఆపై నేను వారికి స్వయంగా ఒక మార్కర్ ఇస్తాను మరియు వారు ఇప్పటివరకు బిగ్గరగా చెప్పినవన్నీ బోర్డుపై వ్రాయమని అడుగుతాను. సాధారణంగా ఈ రకమైన సమావేశాలలో ప్రతిదీ వ్రాసే ఒక వ్యక్తి ఉంటాడు మరియు ఉత్తమంగా అతను చర్చలో 10% వ్రాయగలడు. నా పద్ధతితో, ఈ సంఖ్యను దాదాపు 40%కి పెంచవచ్చు.
(ఈ దృష్టాంతాన్ని విడిగా చూడవచ్చు )
నా విధానం విలియం ష్నైడర్ యొక్క పనిపై ఆధారపడింది. ) ఏ సంస్థనైనా నాలుగు చతురస్రాలుగా విభజించాలనే ఆలోచనపై ఈ విధానం ఆధారపడి ఉంటుంది. నా కోసం ఈ పథకం సాధారణంగా ఒక సంస్థను విశ్లేషించేటప్పుడు ఉత్పన్నమయ్యే వందలాది ఇతర పథకాలతో కలిసి పని చేయడం వల్ల వస్తుంది. మనకు అధిక స్థాయి నియంత్రణ ఉన్న, తక్కువ సామర్థ్యం ఉన్న సంస్థ ఉందని అనుకుందాం. ఇది చాలా అవాంఛనీయమైన ఎంపిక: ప్రతి ఒక్కరూ లైన్‌లో ఉన్నప్పుడు, కానీ ఏమి చేయాలో ఎవరికీ తెలియదు.
కొంచెం మెరుగైన ఎంపిక అనేది అధిక స్థాయి నియంత్రణ మరియు యోగ్యత రెండింటినీ కలిగి ఉంటుంది. అటువంటి కంపెనీ లాభదాయకంగా ఉంటే, బహుశా దానికి DevOps అవసరం లేదు. అధిక స్థాయి నియంత్రణ, తక్కువ సామర్థ్యం మరియు సహకారం ఉన్న సంస్థతో కలిసి పనిచేయడం చాలా ఆసక్తికరంగా ఉంటుంది, కానీ అదే సమయంలో అధిక స్థాయి సంస్కృతి (సాగు). అంటే కంపెనీలో పని చేయడానికి ఇష్టపడే వారు చాలా మంది ఉన్నారు మరియు లేబర్ టర్నోవర్ తక్కువగా ఉంటుంది.
(ఈ దృష్టాంతాన్ని విడిగా చూడవచ్చు )
కఠినమైన మార్గదర్శకాలతో కూడిన పద్ధతులు సత్యాన్ని సాధించే మార్గంలో ముగుస్తాయని నాకు అనిపిస్తోంది. ముఖ్యంగా వాల్యూ స్ట్రీమ్ మ్యాపింగ్‌లో, సమాచారాన్ని ఎలా నిర్మించాలనే దాని గురించి అనేక నియమాలు ఉన్నాయి. పని యొక్క ప్రారంభ దశలలో, నేను ఇప్పుడు మాట్లాడుతున్నాను, ఎవరికీ ఈ నియమాలు అవసరం లేదు. తన చేతుల్లో మార్కర్ ఉన్న వ్యక్తి బోర్డులో కంపెనీలో వాస్తవ పరిస్థితిని వివరిస్తే, వ్యవహారాల స్థితిని అర్థం చేసుకోవడానికి ఇది ఉత్తమ మార్గం. అలాంటి సమాచారం దర్శకులకు చేరదు. ఈ సమయంలో, వ్యక్తికి అంతరాయం కలిగించడం మరియు అతను ఒక రకమైన బాణం తప్పుగా గీసాడని చెప్పడం మూర్ఖత్వం. ఈ దశలో, సరళమైన నియమాలను ఉపయోగించడం ఉత్తమం, ఉదాహరణకు: బహుళ-స్థాయి సంగ్రహణను బహుళ-రంగు గుర్తులను ఉపయోగించడం ద్వారా సృష్టించవచ్చు.
నేను పునరావృతం చేస్తున్నాను, అధిక సాంకేతికత లేదు. బ్లాక్ మార్కర్ ప్రతిదీ ఎలా పని చేస్తుందో ఆబ్జెక్టివ్ రియాలిటీని వర్ణిస్తుంది. రెడ్ మార్కర్‌తో, ప్రజలు ప్రస్తుత పరిస్థితులలో తమకు నచ్చని వాటిని గుర్తు పెడతారు. ఇది వాళ్లు రాయడం ముఖ్యం, నేను కాదు. నేను సమావేశం తర్వాత CIO వద్దకు వెళ్లినప్పుడు, పరిష్కరించాల్సిన 10 విషయాల జాబితాను నేను అందించను. కంపెనీలోని వ్యక్తులు ఏమి చెబుతున్నారో మరియు ఇప్పటికే ఉన్న నిరూపితమైన నమూనాల మధ్య కనెక్షన్‌లను కనుగొనడానికి నేను ప్రయత్నిస్తాను. చివరగా, నీలిరంగు మార్కర్ సమస్యకు సాధ్యమైన పరిష్కారాలను సూచిస్తుంది.
(ఈ దృష్టాంతాన్ని విడిగా చూడవచ్చు )
ఈ విధానం యొక్క ఉదాహరణ ఇప్పుడు పైన చిత్రీకరించబడింది. ఈ సంవత్సరం ప్రారంభంలో నేను ఒక బ్యాంకులో పనిచేశాను. డిజైన్ మరియు అవసరాల సమీక్షలకు వారు రాకూడదని అక్కడ ఉన్న సెక్యూరిటీ వ్యక్తులు ఒప్పించారు.
(ఈ దృష్టాంతాన్ని విడిగా చూడవచ్చు )
ఆపై మేము ఇతర విభాగాల వ్యక్తులతో మాట్లాడాము మరియు సుమారు 8 సంవత్సరాల క్రితం, సాఫ్ట్‌వేర్ డెవలపర్లు పనిని మందగిస్తున్నందున భద్రతా సిబ్బందిని తొలగించారని తేలింది. ఆపై అది నిషేధంగా మారింది, ఇది మంజూరు కోసం తీసుకోబడింది. వాస్తవానికి నిషేధం లేనప్పటికీ.
మా సమావేశం చాలా గందరగోళంగా సాగింది: సుమారు మూడు గంటల పాటు, కోడ్ మరియు అసెంబ్లీ మధ్య ఏమి జరుగుతుందో ఐదు వేర్వేరు బృందాలు నాకు వివరించలేకపోయాయి. మరియు ఇది సరళమైన విషయం అనిపిస్తుంది. చాలా మంది DevOps కన్సల్టెంట్‌లు ప్రతి ఒక్కరికి ఇది ఇప్పటికే తెలుసని ముందే ఊహించారు.
ఆ తర్వాత నాలుగు గంటలపాటు మౌనంగా ఉన్న ఐటీ గవర్నెన్స్‌ ఇన్‌ఛార్జ్‌గా ఉన్న వ్యక్తి టాపిక్‌కి వచ్చేసరికి ఒక్కసారిగా ప్రాణం మీదకు వచ్చి చాలా సేపు మమ్మల్ని ఆక్రమించారు. ముగింపులో నేను అతనిని మీటింగ్ గురించి ఏమనుకుంటున్నారో అడిగాను మరియు అతని సమాధానం నేను ఎప్పటికీ మర్చిపోలేను. అతను ఇలా అన్నాడు: "సాఫ్ట్‌వేర్‌ను డెలివరీ చేయడానికి మా బ్యాంక్‌కి కేవలం రెండు మార్గాలు మాత్రమే ఉన్నాయని నేను అనుకున్నాను, కానీ ఇప్పుడు వాటిలో ఐదు ఉన్నాయని నాకు తెలుసు మరియు మూడు గురించి కూడా నాకు తెలియదు."
(ఈ దృష్టాంతాన్ని విడిగా చూడవచ్చు )
ఈ బ్యాంక్‌లో చివరి సమావేశం పెట్టుబడి సాఫ్ట్‌వేర్ బృందంతో జరిగింది. కాగితపు షీట్‌పై మార్కర్‌తో రేఖాచిత్రాలు రాయడం బోర్డు కంటే మెరుగైనదని మరియు స్మార్ట్‌బోర్డ్‌లో కంటే కూడా మంచిదని ఆమెతోనే తేలింది.
మా సమావేశం జరిగిన నాలుగో రోజున హోటల్ కాన్ఫరెన్స్ రూమ్ ఎలా ఉందో మీరు చూసే ఫోటోలు. మరియు మేము నమూనాల కోసం శోధించడానికి ఈ స్కీమ్‌లను ఉపయోగించాము, అంటే ఆర్కిటైప్‌లు.
కాబట్టి, నేను కార్మికులను ప్రశ్నలు అడుగుతాను, వారు సమాధానాలను మూడు రంగుల (నలుపు, ఎరుపు మరియు నీలం) గుర్తులతో వ్రాస్తారు. నేను ఆర్కిటైప్‌ల కోసం వారి సమాధానాలను విశ్లేషిస్తాను. ఇప్పుడు అన్ని ఆర్కిటైప్‌లను క్రమంలో చర్చిద్దాం.
1. అన్ని పనులను కనిపించేలా చేయండి: పనిని కనిపించేలా చేయండి
నేను పనిచేసే చాలా కంపెనీలలో తెలియని పని శాతం చాలా ఎక్కువ. ఉదాహరణకు, ఒక ఉద్యోగి మరొకరి వద్దకు వచ్చి ఏదైనా చేయమని కోరినప్పుడు ఇది జరుగుతుంది. పెద్ద సంస్థలలో, 60% ప్రణాళిక లేని పని ఉండవచ్చు. మరియు 40% వరకు పని ఏ విధంగానూ డాక్యుమెంట్ చేయబడదు. అది బోయింగ్ అయితే, నేను నా జీవితంలో మళ్లీ వారి విమానం ఎక్కను. పనిలో సగం మాత్రమే డాక్యుమెంట్ చేయబడితే, ఈ పని సరిగ్గా జరుగుతుందో లేదో తెలియదు. అన్ని ఇతర పద్ధతులు పనికిరానివిగా మారతాయి - ఏదైనా ఆటోమేట్ చేయడానికి ప్రయత్నించడంలో అర్థం లేదు, ఎందుకంటే తెలిసిన 50% పనిలో అత్యంత పొందికైన మరియు స్పష్టమైన భాగం కావచ్చు, దీని యొక్క ఆటోమేషన్ గొప్ప ఫలితాలను ఇవ్వదు మరియు అన్ని చెత్తగా ఉంటుంది విషయాలు అదృశ్య సగంలో ఉన్నాయి. డాక్యుమెంటేషన్ లేనప్పుడు, అన్ని రకాల హక్స్ మరియు దాచిన పనిని కనుగొనడం అసాధ్యం, అడ్డంకులను కనుగొనడం కాదు, నేను ఇప్పటికే మాట్లాడిన “బ్రెంట్స్”. డొమినికా డిగ్రాండిస్ రాసిన అద్భుతమైన పుస్తకం ఉంది . ఆమె వెల్లడిస్తుంది ఐదు వేర్వేరు "సమయం లీక్‌లు" (సమయం దొంగలు):
- చాలా ఎక్కువ పని ప్రక్రియలో ఉంది (WIP)
- తెలియని డిపెండెన్సీలు
- ప్రణాళిక లేని పని
- వైరుధ్య ప్రాధాన్యతలు
- నిర్లక్ష్యం చేసిన పని
ఇది చాలా విలువైన విశ్లేషణ మరియు పుస్తకం చాలా బాగుంది, కానీ 50% డేటా మాత్రమే కనిపిస్తే ఈ సలహా అంతా పనికిరాదు. 90% కంటే ఎక్కువ ఖచ్చితత్వాన్ని సాధించినట్లయితే డొమినికా ప్రతిపాదించిన పద్ధతులను ఉపయోగించవచ్చు. నేను ఒక బాస్ సబార్డినేట్‌కి 15 నిమిషాల పనిని ఇచ్చే పరిస్థితుల గురించి మాట్లాడుతున్నాను, కానీ అతనికి మూడు రోజులు పడుతుంది; అయితే ఈ సబార్డినేట్ మరో నలుగురైదుగురు వ్యక్తులపై ఆధారపడుతున్నాడని బాస్‌కి నిజంగా తెలియదు.
ఫీనిక్స్ ప్రాజెక్ట్ మూడు సంవత్సరాలు ఆలస్యం అయిన ప్రాజెక్ట్ గురించి అద్భుతమైన కథ. ఈ కారణంగా ఒక పాత్ర తొలగింపును ఎదుర్కొంటుంది మరియు అతను ఒక రకమైన సోక్రటీస్‌గా ప్రదర్శించబడిన మరొక పాత్రను కలుస్తాడు. సరిగ్గా ఏమి జరిగిందో గుర్తించడంలో అతను సహాయం చేస్తాడు. కంపెనీకి ఒక సిస్టమ్ అడ్మినిస్ట్రేటర్ ఉన్నారని, దీని పేరు బ్రెంట్ అని తేలింది మరియు అన్ని పనులు అతని ద్వారానే జరుగుతాయి. సమావేశాలలో ఒకదానిలో, సబార్డినేట్‌లలో ఒకరిని అడుగుతారు: ప్రతి అరగంట పనికి వారం ఎందుకు పడుతుంది? సమాధానం క్యూయింగ్ సిద్ధాంతం మరియు లిటిల్ చట్టం యొక్క చాలా సరళీకృత ప్రదర్శన, మరియు ఈ ప్రదర్శనలో 90% ఆక్యుపెన్సీ వద్ద, ప్రతి గంట పని 9 గంటలు పడుతుంది. ప్రతి పనిని మరో ఏడుగురికి పంపాలి, ఆ గంట 63 గంటలు, 7 సార్లు 9 అవుతుంది. నేను చెప్పేదేమిటంటే, లిటిల్ లా లేదా ఏదైనా సంక్లిష్టమైన క్యూయింగ్ థియరీని ఉపయోగించాలంటే, మీరు కనీసం డేటాను కలిగి ఉండాలి.
కాబట్టి నేను విజిబిలిటీ గురించి మాట్లాడేటప్పుడు, ప్రతిదీ స్క్రీన్‌పై ఉందని నా ఉద్దేశ్యం కాదు, కానీ మీకు కనీసం డేటా అయినా ఉందని. వారు చేసినప్పుడు, చాలా పెద్ద మొత్తంలో ప్రణాళిక లేని పని ఉందని, దాని అవసరం లేనప్పుడు బ్రెంట్‌కి పంపబడుతుందని తరచుగా తేలింది. మరియు బ్రెంట్ గొప్ప వ్యక్తి, అతను ఎప్పటికీ నో చెప్పడు, కానీ అతను తన పనిని ఎలా చేస్తాడో ఎవరికీ చెప్పడు.
పని కనిపించినప్పుడు, డేటాను చక్కగా వర్గీకరించవచ్చు (ఫోటోలో డొమినికా చేస్తున్నది అదే), ఐదు సార్లు లీక్‌ల యొక్క సంగ్రహణను వర్తింపజేయవచ్చు మరియు ఆటోమేషన్ వర్తించవచ్చు.
2. వర్క్ మేనేజ్‌మెంట్ సిస్టమ్‌లను ఏకీకృతం చేయండి: టాస్క్ మేనేజ్‌మెంట్
నేను మాట్లాడుతున్న ఆర్కిటైప్‌లు ఒక రకమైన పిరమిడ్. మొదటిది సరిగ్గా జరిగితే, రెండవది ఇప్పటికే ఒక రకమైన యాడ్-ఆన్. వీటిలో చాలా స్టార్టప్‌ల కోసం పని చేయవు, ఫార్చ్యూన్ 5000 వంటి పెద్ద కంపెనీల కోసం వీటిని గుర్తుంచుకోవాలి. నేను చివరిగా పనిచేసిన కంపెనీ 10 టికెటింగ్ సిస్టమ్‌లను కలిగి ఉంది. ఒక టీమ్ రెమెడీని కలిగి ఉంది, మరొకటి దాని స్వంత సిస్టమ్‌ను వ్రాసింది, మూడవది జిరాను ఉపయోగించింది మరియు కొందరు ఇమెయిల్‌తో చేసారు. కంపెనీకి 30 వేర్వేరు పైప్‌లైన్‌లు ఉంటే అదే సమస్య తలెత్తుతుంది, అయితే అలాంటి కేసులన్నింటినీ చర్చించడానికి నాకు సమయం లేదు.
టిక్కెట్లు ఎలా సృష్టించబడతాయో, వారికి తర్వాత ఏమి జరుగుతుందో మరియు వాటిని ఎలా తప్పించుకుంటారో నేను వ్యక్తులతో చర్చిస్తాను. అత్యంత ఆసక్తికరమైన విషయమేమిటంటే, మన సమావేశాలలో ప్రజలు చాలా నిజాయితీగా మాట్లాడతారు. అసలు "మేజర్ ఇంపాక్ట్" ఇవ్వాల్సిన టిక్కెట్లపై ఎంత మంది "మైనర్ / నో ఇంపాక్ట్" పెట్టారని నేను అడిగాను. దాదాపు ప్రతి ఒక్కరూ దీన్ని చేస్తారని తేలింది. నేను ఖండించడంలో పాల్గొనను మరియు వ్యక్తులను గుర్తించకుండా ఉండటానికి సాధ్యమైన ప్రతి విధంగా ప్రయత్నిస్తాను. వారు హృదయపూర్వకంగా నాతో ఏదైనా ఒప్పుకున్నప్పుడు, నేను వ్యక్తిని విడిచిపెట్టను. కానీ దాదాపు ప్రతి ఒక్కరూ సిస్టమ్‌ను దాటవేసినప్పుడు, అన్ని భద్రత తప్పనిసరిగా విండో డ్రెస్సింగ్ అని అర్థం. అందువల్ల, ఈ సిస్టమ్ యొక్క డేటా నుండి ఎటువంటి ముగింపులు తీసుకోబడవు.
టికెట్ సమస్యను పరిష్కరించడానికి, మీరు ఒక ప్రధాన వ్యవస్థను ఎంచుకోవాలి. మీరు జిరాను ఉపయోగిస్తే, దానిని జిరాగా ఉంచండి. ఏదైనా ప్రత్యామ్నాయం ఉంటే, అది ఒక్కటే ఉండనివ్వండి. బాటమ్ లైన్ ఏమిటంటే, టిక్కెట్లను అభివృద్ధి ప్రక్రియలో మరొక దశగా చూడాలి. ప్రతి చర్యకు తప్పనిసరిగా టికెట్ ఉండాలి, ఇది అభివృద్ధి కార్యక్రమం ద్వారా ప్రవహించాలి. టిక్కెట్లు బృందానికి పంపబడతాయి, వారు వాటిని స్టోరీబోర్డ్‌లో పోస్ట్ చేసి, ఆపై వాటికి బాధ్యత వహిస్తారు.
ఇది మౌలిక సదుపాయాలు మరియు కార్యకలాపాలతో సహా అన్ని విభాగాలకు వర్తిస్తుంది. ఈ సందర్భంలో, వ్యవహారాల స్థితి గురించి కనీసం కొంత ఆమోదయోగ్యమైన ఆలోచనను రూపొందించడం సాధ్యమవుతుంది. ఈ ప్రక్రియ స్థాపించబడిన తర్వాత, ప్రతి అప్లికేషన్‌కు ఎవరు బాధ్యత వహిస్తారో గుర్తించడం అకస్మాత్తుగా సులభం అవుతుంది. ఎందుకంటే ఇప్పుడు మనకు 50% కాదు, 98% కొత్త సేవలు అందుతున్నాయి. ఈ ప్రధాన ప్రక్రియ పనిచేస్తే, సిస్టమ్ అంతటా ఖచ్చితత్వం మెరుగుపడుతుంది.
సేవల పైప్‌లైన్
ఇది మళ్లీ పెద్ద సంస్థలకు మాత్రమే వర్తిస్తుంది. మీరు కొత్త రంగంలో కొత్త కంపెనీ అయితే, మీ స్లీవ్‌లను చుట్టండి మరియు మీ ట్రావిస్ CI లేదా సర్కిల్‌సీఐతో పని చేయండి. ఫార్చ్యూన్ 5000 కంపెనీల విషయానికి వస్తే, నేను పనిచేసిన బ్యాంకులో జరిగిన ఒక ఉదాహరణ. Google వారి వద్దకు వచ్చింది మరియు వారికి పాత IBM సిస్టమ్‌ల రేఖాచిత్రాలు చూపించబడ్డాయి. Google నుండి వచ్చిన అబ్బాయిలు గందరగోళంగా అడిగారు - దీనికి సోర్స్ కోడ్ ఎక్కడ ఉంది? కానీ సోర్స్ కోడ్ లేదు, GUI కూడా లేదు. పెద్ద సంస్థలు ఎదుర్కోవాల్సిన వాస్తవికత ఇది: పురాతన మెయిన్‌ఫ్రేమ్‌లో 40 ఏళ్ల బ్యాంక్ రికార్డులు. నా క్లయింట్‌లలో ఒకరు సర్క్యూట్ బ్రేకర్ ప్యాటర్న్‌లతో కూడిన కుబెర్నెటెస్ కంటైనర్‌లను, ప్లస్ కేయోస్ మంకీని, అన్నీ కీబ్యాంక్ అప్లికేషన్ కోసం ఉపయోగిస్తున్నారు. కానీ ఈ కంటైనర్లు చివరికి COBOL అప్లికేషన్‌కు కనెక్ట్ అవుతాయి.
Google నుండి వచ్చిన అబ్బాయిలు నా క్లయింట్ యొక్క అన్ని సమస్యలను పరిష్కరిస్తారని పూర్తిగా నమ్మకంగా ఉన్నారు, ఆపై వారు ప్రశ్నలు అడగడం ప్రారంభించారు: IBM డేటాపైప్ అంటే ఏమిటి? వారికి చెప్పబడింది: ఇది ఒక కనెక్టర్. ఇది దేనికి కనెక్ట్ చేస్తుంది? స్పెర్రీ వ్యవస్థకు. మరియు అది ఏమిటి? మరియు అందువలన న. మొదటి చూపులో ఇది కనిపిస్తుంది: ఎలాంటి DevOps ఉండవచ్చు? కానీ నిజానికి, ఇది సాధ్యమే. వర్క్‌ఫ్లోను డెలివరీ బృందాలకు అప్పగించడానికి మిమ్మల్ని అనుమతించే డెలివరీ సిస్టమ్‌లు ఉన్నాయి.
3. పరిమితుల సిద్ధాంతం: పరిమితుల సిద్ధాంతం
మూడవ ఆర్కిటైప్‌కు వెళ్దాం: సంస్థాగత/"గిరిజన" జ్ఞానం. నియమం ప్రకారం, ఏదైనా సంస్థలో ప్రతిదీ తెలిసిన మరియు ప్రతిదీ నిర్వహించే చాలా మంది వ్యక్తులు ఉన్నారు. ఈ సంస్థలో ఎక్కువ కాలం పనిచేసిన వారు మరియు అన్ని పరిష్కారాలు తెలిసిన వారు.
ఇది రేఖాచిత్రంలో వచ్చినప్పుడు, నేను ప్రత్యేకంగా అలాంటి వ్యక్తులను మార్కర్‌తో సర్కిల్ చేస్తాను: ఉదాహరణకు, అన్ని సమావేశాలలో ఒక నిర్దిష్ట లౌ ఉన్నట్లు తేలింది. మరియు ఇది నాకు స్పష్టంగా ఉంది: ఇది స్థానిక బ్రెంట్. CIO నా మధ్య టీ-షర్ట్ మరియు స్నీకర్స్ మరియు సూట్‌లో IBM నుండి వ్యక్తిని ఎంచుకున్నప్పుడు, నేను ఎంపికయ్యాను ఎందుకంటే అవతలి వ్యక్తి చెప్పని మరియు దర్శకుడు వినడానికి ఇష్టపడని విషయాలను నేను దర్శకుడికి చెప్పగలను. . వారి కంపెనీలో అడ్డంకి ఫ్రెడ్ మరియు లౌ అనే వ్యక్తి అని నేను వారికి చెప్తాను. ఈ అడ్డంకిని విడదీయాలి, వారి జ్ఞానాన్ని వారి నుండి ఏదో ఒక విధంగా పొందాలి.
ఈ రకమైన సమస్యను పరిష్కరించడానికి, నేను, ఉదాహరణకు, స్లాక్‌ని ఉపయోగించమని సూచించగలను. తెలివైన దర్శకుడు అడుగుతాడు - ఎందుకు? సాధారణంగా, అటువంటి సందర్భాలలో, DevOps కన్సల్టెంట్స్ సమాధానం ఇస్తారు: ఎందుకంటే ప్రతి ఒక్కరూ దీన్ని చేస్తున్నారు. దర్శకుడు నిజంగా తెలివైనవాడైతే, అతను ఇలా చెబుతాడు: సో వాట్. మరియు ఇక్కడ డైలాగ్ ముగుస్తుంది. మరియు దీనికి నా సమాధానం: ఎందుకంటే కంపెనీలో నాలుగు అడ్డంకులు ఉన్నాయి, ఫ్రెడ్, లౌ, సూసీ మరియు జేన్. వారి జ్ఞానాన్ని సంస్థాగతీకరించడానికి, ముందుగా స్లాక్‌ను పరిచయం చేయాలి. మీ వికీలన్నీ పూర్తిగా అర్ధంలేనివి ఎందుకంటే వాటి ఉనికి గురించి ఎవరికీ తెలియదు. ఇంజినీరింగ్ బృందం ఫ్రంట్-ఎండ్ మరియు బ్యాక్-ఎండ్ డెవలప్‌మెంట్‌లో పాల్గొంటే మరియు వారు ఫ్రంట్-ఎండ్ డెవలప్‌మెంట్ టీమ్ లేదా ఇన్‌ఫ్రాస్ట్రక్చర్ టీమ్‌ను ప్రశ్నలతో సంప్రదించవచ్చని ప్రతి ఒక్కరూ తెలుసుకోవాలి. అప్పుడే లౌ లేదా ఫ్రెడ్ వికీలో చేరడానికి బహుశా సమయం ఉంటుంది. ఆపై స్లాక్‌లో ఎవరైనా ఎందుకు అడుగు 5వ దశ పని చేయడం లేదని అడగవచ్చు. ఆపై లౌ లేదా ఫ్రెడ్ వికీలోని సూచనలను సరిచేస్తారు. మీరు ఈ ప్రక్రియను ఏర్పాటు చేస్తే, చాలా విషయాలు వాటి స్వంత స్థానంలోకి వస్తాయి.
ఇది నా ప్రధాన విషయం: ఏదైనా అధిక సాంకేతికతలను సిఫార్సు చేయడానికి, మీరు మొదట వాటి కోసం పునాదిని క్రమంలో ఉంచాలి మరియు ఇది ఇప్పుడే వివరించిన తక్కువ-టెక్ పరిష్కారాలతో చేయవచ్చు. మీరు అధిక సాంకేతికతలతో ప్రారంభించి, అవి ఎందుకు అవసరమో వివరించకపోతే, ఒక నియమం వలె, ఇది బాగా ముగియదు. మా క్లయింట్‌లలో ఒకరు అజూర్ MLని ఉపయోగిస్తున్నారు, ఇది చాలా చౌకైన మరియు సులభమైన పరిష్కారం. వారి 30% ప్రశ్నలకు స్వీయ-అభ్యాస యంత్రం ద్వారానే సమాధానాలు లభించాయి. మరియు ఈ విషయం డేటా సైన్స్, స్టాటిస్టిక్స్ లేదా మ్యాథమెటిక్స్‌లో పాల్గొనని ఆపరేటర్లచే వ్రాయబడింది. ఇది ముఖ్యమైనది. అటువంటి పరిష్కారం యొక్క ధర తక్కువగా ఉంటుంది.
4. సహకార హక్స్: సహకార హక్స్
నాల్గవ ఆర్కిటైప్ ఒంటరిగా పోరాడవలసిన అవసరం. చాలా మందికి ఇది ఇప్పటికే తెలుసు: ఒంటరితనం శత్రుత్వాన్ని పెంచుతుంది. ప్రతి విభాగం దాని స్వంత అంతస్తులో ఉంటే, మరియు ప్రజలు ఎలివేటర్‌లో తప్ప, ఏ విధంగానూ ఒకరితో ఒకరు కలుస్తాయి, అప్పుడు వారి మధ్య శత్రుత్వం చాలా సులభంగా పుడుతుంది. కానీ, దీనికి విరుద్ధంగా, ప్రజలు ఒకరితో ఒకరు ఒకే గదిలో ఉంటే, ఆమె వెంటనే వెళ్లిపోతుంది. ఎవరైనా కొన్ని సాధారణ ఆరోపణలను విసిరినప్పుడు, ఉదాహరణకు, అటువంటి ఇంటర్‌ఫేస్ ఎప్పుడూ పనిచేయదు, అటువంటి ఆరోపణను పునర్నిర్మించడం అంత తేలికైనది ఏమీ లేదు. ఇంటర్‌ఫేస్‌ను వ్రాసిన ప్రోగ్రామర్లు నిర్దిష్ట ప్రశ్నలను అడగడం ప్రారంభించాలి మరియు ఉదాహరణకు, వినియోగదారు సాధనాన్ని తప్పుగా ఉపయోగిస్తున్నారని త్వరలో స్పష్టమవుతుంది.
ఒంటరితనాన్ని అధిగమించడానికి అనేక మార్గాలు ఉన్నాయి. ఒకసారి ఆస్ట్రేలియాలో బ్యాంకు కోసం సంప్రదించమని నన్ను అడిగారు, కానీ నాకు ఇద్దరు పిల్లలు మరియు భార్య ఉన్నందున నేను దానిని చేయడానికి నిరాకరించాను. వారికి సహాయం చేయడానికి నేను చేయగలిగింది గ్రాఫికల్ స్టోరీటెల్లింగ్‌ని సిఫార్సు చేయడం. ఇది పని చేస్తుందని నిరూపించబడిన విషయం. మరొక ఆసక్తికరమైన మార్గం లీన్ కాఫీ సమావేశాలు. పెద్ద సంస్థలో, జ్ఞానాన్ని వ్యాప్తి చేయడానికి ఇది ఒక అద్భుతమైన ఎంపిక. అదనంగా, మీరు అంతర్గత devopsdays, hackathons మొదలైనవాటిని నిర్వహించవచ్చు.
5. కోచింగ్ కాటా
నేను చాలా ప్రారంభంలో హెచ్చరించినట్లు, నేను ఈ రోజు దీని గురించి మాట్లాడను. మీకు ఆసక్తి ఉంటే, మీరు పరిశీలించవచ్చు .
మైక్ రోథర్ నుండి ఈ అంశంపై మంచి చర్చ కూడా ఉంది:
6. మార్కెట్ ఓరియెంటెడ్: మార్కెట్ ఆధారిత సంస్థ
ఇక్కడ వివిధ సమస్యలు ఉన్నాయి. ఉదాహరణకు, "నేను" వ్యక్తులు, "T" వ్యక్తులు మరియు "E" వ్యక్తులు. "నేను" వ్యక్తులు ఒకే ఒక పని చేసే వారు. సాధారణంగా అవి వివిక్త విభాగాలతో కూడిన సంస్థలలో ఉంటాయి. "T" అంటే ఒక వ్యక్తి ఒక విషయంలో మంచివాడు అయితే కొన్ని ఇతర విషయాలలో కూడా మంచివాడు. ఒక వ్యక్తి అనేక నైపుణ్యాలను కలిగి ఉన్నప్పుడు "E" లేదా "దువ్వెన" కూడా.
కాన్వే చట్టం ఇక్కడ పనిచేస్తుంది (), ఇది చాలా సరళీకృత రూపంలో ఈ క్రింది విధంగా పేర్కొనవచ్చు: కంపైలర్‌పై మూడు బృందాలు పని చేస్తే, ఫలితం మూడు భాగాల కంపైలర్ అవుతుంది. అందువల్ల, ఒక సంస్థలో అధిక స్థాయి ఐసోలేషన్ ఉంటే, ఈ సంస్థలోని కుబెర్నెట్స్, సర్క్యూట్ బ్రేకర్, API ఎక్స్‌టెన్సిబిలిటీ మరియు ఇతర ఫ్యాన్సీ విషయాలు కూడా సంస్థ మాదిరిగానే ఏర్పాటు చేయబడతాయి. కాన్వే ప్రకారం ఖచ్చితంగా మరియు మీ అందరి యువ గీక్‌లను ద్వేషించండి.
ఈ సమస్యకు పరిష్కారం చాలాసార్లు వివరించబడింది. ఉదాహరణకు, ఫెర్నాండో ఫెర్నాండెజ్ వివరించిన సంస్థాగత ఆర్కిటైప్‌లు ఉన్నాయి. ఐసోలేషన్‌తో నేను ఇప్పుడే మాట్లాడిన సమస్యాత్మక ఆర్కిటెక్చర్ ఫంక్షన్-ఓరియెంటెడ్ ఆర్కిటెక్చర్. రెండవ రకం చెత్త, మ్యాట్రిక్స్ ఆర్కిటెక్చర్, మిగిలిన రెండింటిలో గందరగోళం. మూడవది చాలా స్టార్టప్‌లలో కనిపిస్తుంది మరియు పెద్ద కంపెనీలు కూడా ఈ రకంతో సరిపోలడానికి ప్రయత్నిస్తున్నాయి. ఇది మార్కెట్ ఆధారిత సంస్థ. కస్టమర్ అభ్యర్థనలకు అత్యంత వేగవంతమైన ప్రతిస్పందనను సాధించడానికి మేము ఇక్కడ ఆప్టిమైజ్ చేస్తాము. దీనిని కొన్నిసార్లు ఫ్లాట్ ఆర్గనైజేషన్ అని పిలుస్తారు.
చాలా మంది ఈ నిర్మాణాన్ని వివిధ మార్గాల్లో వివరిస్తారు, నేను పదాలను ఇష్టపడుతున్నాను బృందాలను నిర్మించండి/నడపండి, Amazonలో వారు దీనిని పిలుస్తారు రెండు పిజ్జా బృందాలు. ఈ నిర్మాణంలో, అన్ని రకాల “I” వ్యక్తులు ఒక సేవ చుట్టూ సమూహం చేయబడతారు మరియు క్రమంగా వారు “T” టైప్‌కు దగ్గరగా ఉంటారు మరియు సరైన నిర్వహణ ఉంటే, వారు “E” కూడా కావచ్చు. ఇక్కడ మొదటి ప్రతివాదం ఏమిటంటే, అటువంటి నిర్మాణంలో అనవసరమైన అంశాలు ఉన్నాయి. మీరు టెస్టర్ల ప్రత్యేక విభాగాన్ని కలిగి ఉంటే, ప్రతి విభాగంలో మీకు టెస్టర్ ఎందుకు అవసరం? దీనికి నేను సమాధానం ఇస్తున్నాను: ఈ సందర్భంలో అదనపు ఖర్చులు మొత్తం సంస్థ భవిష్యత్తులో "E" రకంగా మారడానికి ధర. ఈ నిర్మాణంలో, టెస్టర్ క్రమంగా నెట్‌వర్క్‌లు, ఆర్కిటెక్చర్, డిజైన్ మొదలైన వాటి గురించి నేర్చుకుంటాడు. ఫలితంగా, సంస్థలో పాల్గొనే ప్రతి ఒక్కరికి సంస్థలో జరిగే ప్రతిదాని గురించి పూర్తిగా తెలుసు. పరిశ్రమలో ఈ పథకం ఎలా పనిచేస్తుందో తెలుసుకోవాలంటే, చదవండి .
7. షిఫ్ట్-లెఫ్ట్ ఆడిటర్లు: చక్రం ప్రారంభంలో ఆడిట్. ప్రదర్శనలో భద్రతా నియమాలకు అనుగుణంగా
మీ చర్యలు వాసన పరీక్షలో ఉత్తీర్ణత సాధించనప్పుడు ఇది జరుగుతుంది. నీ దగ్గర పనిచేసేవాళ్ళు తెలివితక్కువవారు కాదు. పై ఉదాహరణలో వలె, వారు ప్రతిచోటా మైనర్/ఎటువంటి ప్రభావం చూపలేదు, ఇది మూడు సంవత్సరాలు కొనసాగింది మరియు ఎవరూ ఏమీ గమనించకపోతే, సిస్టమ్ పని చేయదని అందరికీ బాగా తెలుసు. లేదా మరొక ఉదాహరణ - మార్పు సలహా మండలి, ఇక్కడ నివేదికలు ప్రతి సమర్పించాల్సిన అవసరం ఉంది, చెప్పండి, బుధవారం. అక్కడ పని చేసే వ్యక్తుల సమూహం ఉంది (చాలా బాగా చెల్లించబడదు, మార్గం ద్వారా), వారు సిద్ధాంతపరంగా, మొత్తం వ్యవస్థ ఎలా పనిచేస్తుందో తెలుసుకోవాలి. మరియు గత ఐదు సంవత్సరాలుగా, మా సిస్టమ్‌లు చాలా క్లిష్టంగా ఉన్నాయని మీరు బహుశా గమనించి ఉండవచ్చు. మరియు ఐదు లేదా ఆరుగురు వ్యక్తులు తాము చేయని మరియు వారికి ఏమీ తెలియని మార్పు గురించి నిర్ణయం తీసుకోవాలి.
వాస్తవానికి, ఈ విధానం పనిచేయదు. ఇంతమంది వ్యవస్థను రక్షించడం లేదు కాబట్టి నేను అలాంటి వాటిని వదిలించుకోవాలి. జట్టు స్వయంగా నిర్ణయం తీసుకోవాలి, ఎందుకంటే దానికి జట్టు బాధ్యత వహించాలి. లేకపోతే, తన జీవితంలో ఎప్పుడూ కోడ్ రాయని మేనేజర్ ప్రోగ్రామర్‌కి కోడ్ రాయడానికి ఎంత సమయం పడుతుందో చెప్పినప్పుడు విరుద్ధమైన పరిస్థితి తలెత్తుతుంది. నేను పనిచేసిన ఒక కంపెనీకి ఆర్కిటెక్చర్ బోర్డ్, ప్రోడక్ట్ బోర్డ్ మొదలైన వాటితో సహా ప్రతి మార్పును సమీక్షించే 7 వేర్వేరు బోర్డులు ఉన్నాయి. తప్పనిసరి వెయిటింగ్ పీరియడ్ కూడా ఉంది, అయితే పదేళ్ల పనిలో, ఈ తప్పనిసరి వ్యవధిలో ఈ వ్యక్తి చేసిన మార్పును ఎవరూ తిరస్కరించలేదని ఒక ఉద్యోగి నాకు చెప్పారు.
మాతో చేరడానికి ఆడిటర్‌లను ఆహ్వానించాలి మరియు వారిని వదిలించుకోకూడదు. మీరు మార్పులేని బైనరీ కంటైనర్‌లను వ్రాస్తారని వారికి చెప్పండి, వారు అన్ని పరీక్షలలో ఉత్తీర్ణులైతే, ఎప్పటికీ మారకుండా ఉంటారు. మీరు కోడ్‌గా పైప్‌లైన్‌ని కలిగి ఉన్నారని మరియు దాని అర్థం ఏమిటో వివరించండి. వారికి క్రింది స్కీమ్‌ను చూపండి: అన్ని దుర్బలత్వ పరీక్షలలో ఉత్తీర్ణులైన కంటైనర్‌లో మార్పులేని రీడ్-ఓన్లీ బైనరీ; ఆపై దానిని ఎవరూ తాకకపోవడమే కాదు, పైప్‌లైన్‌ను సృష్టించే వ్యవస్థను కూడా వారు తాకరు, ఎందుకంటే ఇది డైనమిక్‌గా కూడా సృష్టించబడింది. నాకు క్యాపిటల్ వన్ అనే క్లయింట్లు ఉన్నారు, వారు బ్లాక్‌చెయిన్ వంటి వాటిని సృష్టించడానికి వాల్ట్‌ని ఉపయోగిస్తున్నారు. ఆడిటర్ చెఫ్ నుండి “వంటకాలను” చూపించాల్సిన అవసరం లేదు; బ్లాక్‌చెయిన్‌ను చూపించడానికి సరిపోతుంది, దాని నుండి ఉత్పత్తిలో జిరా టిక్కెట్‌కు ఏమి జరిగిందో మరియు దానికి ఎవరు బాధ్యత వహిస్తారో స్పష్టంగా తెలుస్తుంది.
ప్రకారం , Sonatype ద్వారా 2018లో సృష్టించబడింది, 2017లో 87 బిలియన్ల OSS డౌన్‌లోడ్ అభ్యర్థనలు వచ్చాయి.
దుర్బలత్వాల వల్ల కలిగే నష్టాలు చాలా ఎక్కువ. అంతేకాకుండా, మీరు ఇప్పుడు పైన చూస్తున్న గణాంకాలు అవకాశ ఖర్చులను కలిగి ఉండవు. క్లుప్తంగా DevSecOps అంటే ఏమిటి? ఈ పేరు ఎంత విజయవంతమైందో మాట్లాడటానికి నాకు ఆసక్తి లేదని వెంటనే చెప్పనివ్వండి. విషయం ఏమిటంటే, DevOps చాలా విజయవంతమైంది కాబట్టి, మేము ఆ పైప్‌లైన్‌కు భద్రతను జోడించడానికి ప్రయత్నించాలి.
ఈ క్రమానికి ఉదాహరణ:
ఇది నిర్దిష్ట ఉత్పత్తులకు సిఫార్సు కాదు, అయినప్పటికీ నేను అవన్నీ ఇష్టపడతాను. మొదట్లో పరిశ్రమలోని సంస్థాగత నమూనాపై ఆధారపడిన DevOps, ఉత్పత్తిపై పని యొక్క ప్రతి దశను ఆటోమేట్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది అని చూపించడానికి నేను వాటిని ఒక ఉదాహరణగా ఉదహరించాను.
మరియు మేము భద్రత విషయంలో అదే విధానాన్ని ఎందుకు తీసుకోలేము అనే దానికి ఎటువంటి కారణం లేదు.
ఫలితం
ముగింపుగా, నేను DevSecOps కోసం కొన్ని చిట్కాలను ఇస్తాను. మీరు మీ సిస్టమ్‌లను రూపొందించే ప్రక్రియలో ఆడిటర్‌లను చేర్చాలి మరియు వారికి అవగాహన కల్పించడానికి సమయాన్ని వెచ్చించాలి. మీరు ఆడిటర్లకు సహకరించాలి. తరువాత, మీరు తప్పుడు పాజిటివ్‌లకు వ్యతిరేకంగా ఖచ్చితంగా క్రూరమైన పోరాటం చేయాలి. అత్యంత ఖరీదైన వల్నరబిలిటీ స్కానింగ్ సాధనంతో కూడా, మీ సిగ్నల్-టు-నాయిస్ నిష్పత్తి ఏమిటో మీకు తెలియకపోతే, మీరు మీ డెవలపర్‌లలో చాలా చెడు అలవాట్లను సృష్టించవచ్చు. డెవలపర్లు ఈవెంట్‌లతో మునిగిపోతారు మరియు వాటిని తొలగిస్తారు. మీరు ఈక్విఫాక్స్ కథనం గురించి విన్నట్లయితే, అత్యధిక హెచ్చరిక స్థాయిని విస్మరించబడిన చోట చాలా చక్కని సంఘటన జరిగింది. అదనంగా, హానిలు వ్యాపారాన్ని ఎలా ప్రభావితం చేస్తాయో స్పష్టంగా వివరించే విధంగా వివరించాలి. ఉదాహరణకు, ఈక్విఫాక్స్ కథనంలో ఉన్న అదే దుర్బలత్వం అని మీరు చెప్పవచ్చు. భద్రతా దుర్బలత్వాలను ఇతర సాఫ్ట్‌వేర్ సమస్యల మాదిరిగానే పరిగణించాలి, అంటే వాటిని మొత్తం DevOps ప్రక్రియలో చేర్చాలి. మీరు వారితో జిరా, కాన్బన్ మొదలైన వాటి ద్వారా పని చేయాలి. డెవలపర్లు ఎవరైనా దీన్ని చేస్తారని భావించకూడదు - దీనికి విరుద్ధంగా, ప్రతి ఒక్కరూ దీన్ని చేయాలి. చివరగా, మీరు శిక్షణ ప్రజలకు శక్తిని ఖర్చు చేయాలి.
ఉపయోగకరమైన లింకులు
DevOops కాన్ఫరెన్స్ నుండి మీకు ఉపయోగకరంగా ఉండే కొన్ని చర్చలు ఇక్కడ ఉన్నాయి:
- సెర్గీ బెర్డ్నికోవ్, ఆర్టియోమ్ కలిచ్కిన్ - సక్సెస్ స్టోరీ, లేదా “Dev+DevOps+Ops” (, )
- బరూచ్ సడోగుర్స్కీ, లియోనిడ్ ఇగోల్నిక్ - DevOps ఆన్ ఎ స్కేల్: మూడు చర్యలలో ఒక గ్రీకు విషాదం (, )
- అలెగ్జాండర్ టిటోవ్, కిరిల్ టోల్కాచెవ్ -
- తిమోతి లిస్టర్ -
పరిశీలించండి Devoops 2020 మాస్కో - అక్కడ చాలా ఆసక్తికరమైన విషయాలు కూడా ఉన్నాయి.
మూలం: www.habr.com