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

ఈ కోణంలో, అతను పంచుకున్న లియోన్ ఫైర్ అనుభవం DevOpsConf, సరిగ్గా ప్రత్యేకమైనది కాదు, కానీ అతని అనుభవం మరియు 20 సంవత్సరాల వ్యవధిలో అతను ప్రయత్నించిన విభిన్న పాత్రల సంఖ్యతో గుణించడం చాలా ఉపయోగకరంగా ఉంటుంది. కట్ క్రింద 90 రోజులకు పైగా జరిగిన సంఘటనల కాలక్రమం మరియు వేరొకరికి ఎదురైనప్పుడు నవ్వడానికి సరదాగా ఉండే చాలా కథలు ఉన్నాయి, కానీ వ్యక్తిగతంగా ఎదుర్కోవడం అంత సరదాగా ఉండదు.

లియోన్ రష్యన్ భాషలో చాలా కలర్‌ఫుల్‌గా మాట్లాడతాడు, కాబట్టి మీకు 35-40 నిమిషాలు ఉంటే, వీడియో చూడమని నేను సిఫార్సు చేస్తున్నాను. దిగువ సమయాన్ని ఆదా చేయడానికి టెక్స్ట్ వెర్షన్.

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

ఒక నెల ముందు

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

టీచింగ్ స్ట్రాటజీస్ అనేది పుట్టినప్పటి నుండి మూడు సంవత్సరాల వయస్సు వరకు చాలా చిన్న పిల్లలకు పాఠ్యాంశాలలో మార్కెట్ లీడర్. సాంప్రదాయ "పేపర్" కంపెనీకి ఇప్పటికే 40 సంవత్సరాలు, మరియు ప్లాట్‌ఫారమ్ యొక్క డిజిటల్ SaaS వెర్షన్ 10 సంవత్సరాలు. సాపేక్షంగా ఇటీవల, కంపెనీ ప్రమాణాలకు డిజిటల్ టెక్నాలజీని స్వీకరించే ప్రక్రియ ప్రారంభమైంది. "క్రొత్త" వెర్షన్ 2017లో ప్రారంభించబడింది మరియు దాదాపు పాతది లాగా ఉంది, అది మాత్రమే అధ్వాన్నంగా పనిచేసింది.

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

కొంచెం ముందుకు చూస్తే, నేను అత్యధిక వార్షిక ట్రాఫిక్ సమయంలో నా పనిని ప్రారంభించాను, ఇది వివిధ కారణాల వల్ల ఆసక్తికరంగా ఉంటుంది.

కేవలం 2 సంవత్సరాల వయస్సు ఉన్న ప్లాట్‌ఫారమ్‌లో ఒక విచిత్రమైన స్టాక్ ఉంది: 2008 నుండి కోల్డ్‌ఫ్యూజన్ & SQL సర్వర్. కోల్డ్‌ఫ్యూజన్, మీకు తెలియకపోతే మరియు చాలా మటుకు మీకు తెలియకపోతే, 90ల మధ్యలో వచ్చిన ఒక ఎంటర్‌ప్రైజ్ PHP, మరియు అప్పటి నుండి నేను దాని గురించి కూడా వినలేదు. ఇంకా ఉన్నాయి: రూబీ, MySQL, PostgreSQL, Java, Go, Python. కానీ ప్రధాన ఏకశిలా కోల్డ్‌ఫ్యూజన్ మరియు SQL సర్వర్‌లో నడుస్తుంది.

సమస్యలు

నేను కంపెనీ ఉద్యోగులతో పని గురించి మరియు ఎలాంటి సమస్యలు ఎదురయ్యాయి అనే దాని గురించి ఎంత ఎక్కువ మాట్లాడుతున్నానో, సమస్యలు సాంకేతిక స్వభావం మాత్రమే కాదని నేను గ్రహించాను. సరే, సాంకేతికత పాతది - మరియు వారు దానిపై పని చేయలేదు, కానీ బృందంతో మరియు ప్రక్రియలతో సమస్యలు ఉన్నాయి మరియు కంపెనీ దీనిని అర్థం చేసుకోవడం ప్రారంభించింది.

సాంప్రదాయకంగా, వారి టెక్కీలు మూలలో కూర్చుని ఒక రకమైన పని చేసారు. కానీ డిజిటల్ వెర్షన్ ద్వారా మరింత ఎక్కువ వ్యాపారం ప్రారంభమైంది. అందువల్ల, నేను పని చేయడం ప్రారంభించే ముందు చివరి సంవత్సరంలో, కంపెనీలో కొత్తవి కనిపించాయి: బోర్డ్ ఆఫ్ డైరెక్టర్లు, CTO, CPO మరియు QA డైరెక్టర్. అంటే, కంపెనీ టెక్నాలజీ రంగంలో పెట్టుబడులు పెట్టడం ప్రారంభించింది.

భారీ వారసత్వం యొక్క జాడలు వ్యవస్థలలో మాత్రమే లేవు. కంపెనీకి లెగసీ ప్రాసెస్‌లు, లెగసీ పీపుల్, లెగసీ కల్చర్ ఉన్నాయి. ఇదంతా మార్చాల్సి వచ్చింది. ఇది ఖచ్చితంగా విసుగు చెందదని నేను భావించాను మరియు ఒకసారి ప్రయత్నించాలని నిర్ణయించుకున్నాను.

రెండు రోజుల ముందు

కొత్త ఉద్యోగాన్ని ప్రారంభించడానికి రెండు రోజుల ముందు, నేను కార్యాలయానికి చేరుకున్నాను, చివరి పత్రాలను పూరించాను, బృందాన్ని కలుసుకున్నాను మరియు ఆ సమయంలో జట్టు సమస్యతో పోరాడుతున్నట్లు కనుగొన్నాను. ఇది సగటు పేజీ లోడ్ సమయం 4 సెకన్లకు పెరిగింది, అంటే 2 సార్లు.

గ్రాఫ్ ద్వారా నిర్ణయించడం, ఏదో స్పష్టంగా జరిగింది, మరియు అది ఏమిటో స్పష్టంగా లేదు. డేటా సెంటర్‌లో నెట్‌వర్క్ జాప్యం సమస్య అని తేలింది: డేటా సెంటర్‌లో 5 ఎంఎస్ లేటెన్సీ వినియోగదారులకు 2 సెకన్లుగా మారింది. ఇది ఎందుకు జరిగిందో నాకు తెలియదు, కానీ ఏ సందర్భంలోనైనా సమస్య డేటా సెంటర్‌లో ఉందని తెలిసింది.

మొదటి రోజు

రెండు రోజులు గడిచాయి మరియు నా మొదటి రోజు పనిలో సమస్య తగ్గలేదని నేను కనుగొన్నాను.

రెండు రోజుల పాటు, వినియోగదారుల పేజీలు సగటున 4 సెకన్లలో లోడ్ అయ్యాయి. సమస్య ఏమిటో వారు కనుగొన్నారా అని నేను అడుగుతాను.

- అవును, మేము టికెట్ తెరిచాము.
- మరియు?
- సరే, వారు మాకు ఇంకా సమాధానం ఇవ్వలేదు.

అప్పుడు నేను ఇంతకు ముందు చెప్పినవన్నీ నేను పోరాడవలసిన మంచుకొండ యొక్క చిన్న చిట్కా మాత్రమే అని గ్రహించాను.

దీనికి బాగా సరిపోయే మంచి కోట్ ఉంది:

"కొన్నిసార్లు సాంకేతికతను మార్చడానికి మీరు సంస్థను మార్చాలి."

కానీ నేను సంవత్సరంలో అత్యంత రద్దీగా ఉండే సమయంలో పనిని ప్రారంభించాను కాబట్టి, సమస్యను పరిష్కరించడానికి నేను రెండు ఎంపికలను చూడవలసి వచ్చింది: త్వరిత మరియు దీర్ఘకాలిక రెండూ. మరియు ప్రస్తుతం క్లిష్టమైన వాటితో ప్రారంభించండి.

మూడవ రోజు

కాబట్టి, లోడ్ 4 సెకన్లు ఉంటుంది, మరియు 13 నుండి 15 వరకు అతిపెద్ద శిఖరాలు.

ఈ వ్యవధిలో మూడవ రోజు, డౌన్‌లోడ్ వేగం ఇలా ఉంది:

నా దృక్కోణం నుండి, ఏమీ పని చేయలేదు. అందరి దృష్టికోణంలో ఇది సాధారణం కంటే కొంచెం నెమ్మదిగా నడుస్తోంది. కానీ అది అలా జరగదు-ఇది తీవ్రమైన సమస్య.

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

కానీ మీరు సరైన సమాధానం పొందడానికి ముందు, మీరు సరైన ప్రశ్న అడగాలని మనం మర్చిపోకూడదు. నా తదుపరి ప్రశ్న: మనకు ఎన్ని ఫ్రంటెండ్ సర్వర్లు ఉన్నాయి? సమాధానం “నన్ను కొంచెం కలవరపెట్టింది” - మాకు 17 ఫ్రంటెండ్ సర్వర్లు ఉన్నాయి!

— నేను అడగడానికి సిగ్గుపడుతున్నాను, కానీ 150ని 17తో భాగిస్తే 8 వస్తుందా? ప్రతి సర్వర్ సెకనుకు 8 అభ్యర్థనలను అనుమతిస్తుంది మరియు రేపు సెకనుకు 160 అభ్యర్థనలు ఉంటే, మాకు మరో 2 సర్వర్లు అవసరమవుతాయని మీరు చెబుతున్నారా?

వాస్తవానికి, మాకు అదనపు సర్వర్‌లు అవసరం లేదు. పరిష్కారం కోడ్‌లోనే మరియు ఉపరితలంపై ఉంది:

var currentClass = classes.getCurrentClass();
return currentClass;

ఒక ఫంక్షన్ జరిగింది getCurrentClass(), సైట్‌లోని ప్రతిదీ తరగతి సందర్భంలో పని చేస్తుంది కాబట్టి - అది సరైనది. మరియు ప్రతి పేజీలో ఈ ఒక ఫంక్షన్ కోసం ఉన్నాయి 200+ అభ్యర్థనలు.

ఈ విధంగా పరిష్కారం చాలా సులభం, మీరు దేనినీ తిరిగి వ్రాయవలసిన అవసరం లేదు: అదే సమాచారాన్ని మళ్లీ అడగవద్దు.

if ( !isDefined("REQUEST.currentClass") ) {
    var classes = new api.private.classes.base();
   REQUEST.currentClass = classes.getCurrentClass();
}
return REQUEST.currentClass;

నేను చాలా సంతోషంగా ఉన్నాను ఎందుకంటే మూడవ రోజున నేను ప్రధాన సమస్యను కనుగొన్నాను. నేను అమాయకంగా ఉన్నాను, ఇది చాలా సమస్యలలో ఒకటి.

కానీ ఈ మొదటి సమస్యను పరిష్కరించడం గ్రాఫ్ చాలా తక్కువగా పడిపోయింది.

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

పదో రోజు

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

మళ్లీ ఆసక్తికరమైన విషయం తెలిసింది. ఈ బృందంలో 18 మంది డెవలపర్లు ఉన్నారు; 8 టెస్టర్లు; 3 నిర్వాహకులు; 2 వాస్తుశిల్పులు. మరియు వారందరూ సాధారణ ఆచారాలలో పాల్గొన్నారు, అంటే, ప్రతిరోజూ ఉదయం 30 మందికి పైగా స్టాండ్-అప్ వద్దకు వచ్చి వారు ఏమి చేశారో చెప్పారు. సమావేశానికి 5, 15 నిమిషాల సమయం పట్టలేదని స్పష్టం చేశారు. ప్రతి ఒక్కరూ వేర్వేరు సిస్టమ్‌లలో పనిచేస్తున్నందున ఎవరూ ఎవరి మాట వినలేదు. ఈ రూపంలో, గ్రూమింగ్ సెషన్ కోసం గంటకు 2-3 టిక్కెట్లు ఇప్పటికే మంచి ఫలితం పొందాయి.

మేము చేసిన మొదటి పని జట్టును అనేక ఉత్పత్తి లైన్లుగా విభజించడం. వివిధ విభాగాలు మరియు సిస్టమ్‌ల కోసం, మేము డెవలపర్‌లు, టెస్టర్‌లు, ఉత్పత్తి నిర్వాహకులు మరియు వ్యాపార విశ్లేషకులను కలిగి ఉన్న ప్రత్యేక బృందాలను కేటాయించాము.

ఫలితంగా మేము పొందాము:

• స్టాండ్-అప్‌లు మరియు ర్యాలీలను తగ్గించడం.
• ఉత్పత్తి యొక్క విషయ పరిజ్ఞానం.
• యాజమాన్యం యొక్క భావం. ప్రజలు అన్ని వేళలా సిస్టమ్‌లతో టింకర్‌గా ఉన్నప్పుడు, వారి బగ్‌లతో మరొకరు ఎక్కువగా పని చేయాల్సి ఉంటుందని వారికి తెలుసు, కానీ తాము కాదు.
• సమూహాల మధ్య సహకారం. QA ఇంతకు ముందు ప్రోగ్రామర్‌లతో కమ్యూనికేట్ చేయలేదని ప్రత్యేకంగా చెప్పనవసరం లేదు, ఉత్పత్తి దాని స్వంత పనిని చేసింది. ఇప్పుడు వారికి ఒక సాధారణ బాధ్యత ఉంది.

మేము ప్రధానంగా సమర్థత, ఉత్పాదకత మరియు నాణ్యతపై దృష్టి సారించాము - ఇవి జట్టు యొక్క పరివర్తనతో మేము పరిష్కరించడానికి ప్రయత్నించిన సమస్యలు.

పదకొండవ రోజు

జట్టు నిర్మాణాన్ని మార్చే ప్రక్రియలో, నేను ఎలా లెక్కించాలో కనుగొన్నాను స్టోరీపాయింట్లు. 1 SP ఒక రోజుకు సమానం, మరియు ప్రతి టిక్కెట్‌లో డెవలప్‌మెంట్ మరియు QA రెండింటికీ SP ఉంటుంది, అంటే కనీసం 2 SP.

నేను దీన్ని ఎలా కనుగొన్నాను?

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

దీని తరువాత మేము:

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

ఇరవయ్యవ రోజు

ఎక్కడా మొదటి నెల మధ్యలో, పరిస్థితి కొద్దిగా స్థిరీకరించబడింది, నేను ప్రాథమికంగా ఏమి జరుగుతుందో కనుగొన్నాను మరియు ఇప్పటికే భవిష్యత్తును పరిశీలించడం మరియు దీర్ఘకాలిక పరిష్కారాల గురించి ఆలోచించడం ప్రారంభించాను.

దీర్ఘకాలిక లక్ష్యాలు:

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

గతంలో ఇది తరచుగా చెప్పబడింది: “అన్నీ [భాష/ఫ్రేమ్‌వర్క్]లో తిరిగి వ్రాస్దాం, ప్రతిదీ మెరుగ్గా పని చేస్తుంది!”

చాలా సందర్భాలలో ఇది పని చేయదు, తిరిగి వ్రాయడం అస్సలు పని చేస్తే మంచిది. అందువల్ల, మేము ఒక రోడ్‌మ్యాప్‌ను రూపొందించాల్సిన అవసరం ఉంది - వ్యాపార లక్ష్యాలు ఎలా సాధించబడతాయో (మేము ఏమి చేస్తాము మరియు ఎందుకు) దశలవారీగా వివరించే నిర్దిష్ట వ్యూహం:

• ప్రాజెక్ట్ యొక్క లక్ష్యం మరియు లక్ష్యాలను ప్రతిబింబిస్తుంది;
• ప్రధాన లక్ష్యాలకు ప్రాధాన్యతనిస్తుంది;
• వాటిని సాధించడానికి షెడ్యూల్‌ను కలిగి ఉంటుంది.

దీనికి ముందు, ఎటువంటి మార్పులు చేయాలనే ఉద్దేశ్యం గురించి ఎవరూ జట్టుతో మాట్లాడలేదు. దీనికి సరైన విజయ కొలమానాలు అవసరం. కంపెనీ చరిత్రలో మొట్టమొదటిసారిగా, మేము సాంకేతిక సమూహం కోసం KPIలను సెట్ చేసాము మరియు ఈ సూచికలు సంస్థాగతమైన వాటితో ముడిపడి ఉన్నాయి.

అంటే, సంస్థాగత KPIలు బృందాలచే మద్దతు ఇవ్వబడతాయి మరియు జట్టు KPIలు వ్యక్తిగత KPIలచే మద్దతు ఇవ్వబడతాయి. లేకపోతే, సాంకేతిక KPIలు సంస్థాగతమైన వాటితో ఏకీభవించకపోతే, ప్రతి ఒక్కరూ తమపై దుప్పటిని లాగుతారు.

ఉదాహరణకు, సంస్థాగత KPIలలో ఒకటి కొత్త ఉత్పత్తుల ద్వారా మార్కెట్ వాటాను పెంచుతోంది.

మరిన్ని కొత్త ఉత్పత్తులను కలిగి ఉండాలనే లక్ష్యానికి మీరు ఎలా మద్దతు ఇవ్వగలరు?

• ముందుగా, మేము లోపాలను పరిష్కరించడానికి బదులుగా కొత్త ఉత్పత్తులను అభివృద్ధి చేయడానికి ఎక్కువ సమయం వెచ్చించాలనుకుంటున్నాము. ఇది కొలవడానికి సులభమైన తార్కిక పరిష్కారం.
• రెండవది, మేము లావాదేవీ పరిమాణంలో పెరుగుదలకు మద్దతు ఇవ్వాలనుకుంటున్నాము, ఎందుకంటే ఎక్కువ మార్కెట్ వాటా, ఎక్కువ మంది వినియోగదారులు మరియు తదనుగుణంగా, మరింత ట్రాఫిక్.

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

ఈ విధంగా, కోడ్‌ని తిరిగి వ్రాయడంతో సహా ప్రతి నిర్ణయం, కంపెనీ మన కోసం నిర్దేశించిన నిర్దిష్ట లక్ష్యాలకు (సంస్థ వృద్ధి, కొత్త ఫీచర్లు, నియామకం) మద్దతు ఇవ్వాలి.

ఈ ప్రక్రియలో, ఒక ఆసక్తికరమైన విషయం వెలుగులోకి వచ్చింది, ఇది టెక్కీలకు మాత్రమే కాకుండా, సాధారణంగా కంపెనీలో వార్తగా మారింది: అన్ని టిక్కెట్లు కనీసం ఒక KPI పై దృష్టి పెట్టాలి. అంటే, ఒక ఉత్పత్తి కొత్త ఫీచర్‌ని తయారు చేయాలనుకుంటున్నట్లు చెబితే, మొదటి ప్రశ్న అడగాలి: “ఈ ఫీచర్‌కి KPI ఏ మద్దతు ఇస్తుంది?” కాకపోతే, క్షమించండి - ఇది అనవసరమైన లక్షణంగా అనిపిస్తుంది.

ముప్పై రోజు

నెలాఖరులో, నేను మరొక సూక్ష్మభేదాన్ని కనుగొన్నాను: నా Ops బృందంలోని ఎవరూ మేము క్లయింట్‌లతో చేసే ఒప్పందాలను చూడలేదు. మీరు పరిచయాలను ఎందుకు చూడాలని మీరు అడగవచ్చు.

• ముందుగా, SLAలు ఒప్పందాలలో పేర్కొనబడినందున.
• రెండవది, SLAలు అన్నీ భిన్నంగా ఉంటాయి. ప్రతి క్లయింట్ తన స్వంత అవసరాలతో వచ్చారు మరియు అమ్మకాల విభాగం చూడకుండా సంతకం చేసింది.

మరొక ఆసక్తికరమైన సూక్ష్మభేదం ఏమిటంటే, ప్లాట్‌ఫారమ్ ద్వారా మద్దతిచ్చే అన్ని సాఫ్ట్‌వేర్ వెర్షన్‌లు తప్పనిసరిగా n-1 అయి ఉండాలి, అంటే తాజా వెర్షన్ కాదు, కానీ చివరిది అని అతిపెద్ద క్లయింట్‌లలో ఒకరితో ఒప్పందం పేర్కొంది.

ఫ్లాట్‌ఫారమ్ కోల్డ్‌ఫ్యూజన్ మరియు SQL సర్వర్ 1పై ఆధారపడి ఉంటే n-2008 నుండి మనం ఎంత దూరంలో ఉన్నామో స్పష్టంగా తెలుస్తుంది, దీనికి జూలైలో మద్దతు లేదు.

నలభై అయిదవ రోజు

రెండవ నెల మధ్యలో నేను కూర్చుని చేయడానికి తగినంత సమయం ఉంది విలువస్ట్రీమ్మ్యాపింగ్ మొత్తం ప్రక్రియ కోసం పూర్తిగా. ఉత్పత్తిని సృష్టించడం నుండి వినియోగదారునికి పంపిణీ చేయడం వరకు తీసుకోవలసిన అవసరమైన చర్యలు ఇవి, మరియు వాటిని వీలైనంత వివరంగా వివరించడం అవసరం.

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

నేను దీన్ని చేసినప్పుడు, రెండు విషయాలు నా దృష్టిని ఆకర్షించాయి:

• QA నుండి డెవలపర్‌లకు తిరిగి వచ్చిన టిక్కెట్‌లలో అధిక శాతం;
• పుల్ అభ్యర్థన సమీక్షలు చాలా సమయం పట్టింది.

సమస్య ఏమిటంటే, ఇవి ఇలాంటి తీర్మానాలు: దీనికి చాలా సమయం పట్టేలా ఉంది, కానీ ఎంత సమయం తీసుకుంటుందో మాకు ఖచ్చితంగా తెలియదు.

"మీరు కొలవలేని దాన్ని మీరు మెరుగుపరచలేరు."

సమస్య ఎంత తీవ్రంగా ఉందో ఎలా సమర్థించుకోవాలి? ఇది రోజులు లేదా గంటలు వృధా చేస్తుందా?

దీన్ని కొలవడానికి, మేము జిరా ప్రాసెస్‌కి రెండు దశలను జోడించాము: ప్రతి టికెట్ ఎంతసేపు వేచి ఉంది మరియు నిర్దిష్ట దశకు ఎన్నిసార్లు తిరిగి వస్తుందో కొలవడానికి “దేవ్ కోసం సిద్ధంగా ఉంది” మరియు “QA కోసం సిద్ధంగా ఉంది”.

సమీక్ష కోసం సగటున ఎన్ని టిక్కెట్లు ఉన్నాయో తెలుసుకోవడానికి మేము "సమీక్షలో" కూడా జోడించాము మరియు దీని నుండి మీరు డ్యాన్స్ చేయడం ప్రారంభించవచ్చు. మేము సిస్టమ్ మెట్రిక్‌లను కలిగి ఉన్నాము, ఇప్పుడు మేము కొత్త కొలమానాలను జోడించాము మరియు కొలవడం ప్రారంభించాము:

• ప్రక్రియ సామర్థ్యం: పనితీరు మరియు ప్రణాళిక/బట్వాడా.
• ప్రక్రియ నాణ్యత: లోపాల సంఖ్య, QA నుండి లోపాలు.

ఏది బాగా జరుగుతుందో మరియు ఏది బాగా జరగదు అని అర్థం చేసుకోవడానికి ఇది నిజంగా సహాయపడుతుంది.

యాభైవ రోజు

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

ఇది ఊహించబడింది, కానీ తొలగింపుల స్థాయి ఊహించనిది. ఉదాహరణకు, ఒక వారంలో ఇద్దరు టీమ్ లీడ్స్ ఏకకాలంలో వారి స్వంత స్వేచ్ఛా సంకల్పంతో రాజీనామాలను సమర్పించారు. అందువల్ల, నేను ఇతర సమస్యల గురించి మాత్రమే మరచిపోవలసి వచ్చింది, కానీ దృష్టి పెట్టాలి ఒక బృందాన్ని సృష్టించడం. ఇది పరిష్కరించడానికి సుదీర్ఘమైన మరియు కష్టతరమైన సమస్య, కానీ నేను మిగిలి ఉన్న వ్యక్తులను (లేదా వారిలో ఎక్కువమంది) రక్షించాలనుకున్నందున దీనిని పరిష్కరించాల్సి వచ్చింది. జట్టులో ధైర్యాన్ని కొనసాగించడానికి ప్రజలు వెళ్లిపోయారనే దానిపై ఏదో ఒకవిధంగా స్పందించడం అవసరం.

సిద్ధాంతపరంగా, ఇది మంచిది: కొత్త వ్యక్తి పూర్తిగా కార్టే బ్లాంచ్ కలిగి ఉంటాడు, అతను జట్టు నైపుణ్యాలను అంచనా వేయగలడు మరియు సిబ్బందిని భర్తీ చేయగలడు. నిజానికి, మీరు చాలా కారణాల వల్ల కొత్త వ్యక్తులను తీసుకురాలేరు. సంతులనం ఎల్లప్పుడూ అవసరం.

• పాత మరియు కొత్త. మిషన్‌ను మార్చగల మరియు మద్దతు ఇవ్వగల వృద్ధులను మనం ఉంచాలి. కానీ అదే సమయంలో, మేము కొత్త రక్తాన్ని తీసుకురావాలి, మేము దాని గురించి కొంచెం తరువాత మాట్లాడుతాము.
• అనుభవం. మాతో కలిసి పనిచేయాలని ఆసక్తి ఉన్న మంచి జూనియర్‌లతో చాలా మాట్లాడాను. కానీ జూనియర్‌లను సపోర్ట్ చేయడానికి, వారికి మెంటార్‌గా వ్యవహరించడానికి తగినంత మంది సీనియర్లు లేనందున నేను వారిని తీసుకోలేకపోయాను. ముందుగా అగ్రస్థానంలో ఉన్నవారిని, ఆ తర్వాతే యువతను నియమించుకోవాల్సిన అవసరం ఏర్పడింది.
• క్యారెట్ మరియు కర్ర.

సరైన బ్యాలెన్స్ ఏమిటి, దానిని ఎలా నిర్వహించాలి, ఎంత మందిని ఉంచాలి, ఎంత నెట్టాలి అనే ప్రశ్నలకు నా దగ్గర సరైన సమాధానం లేదు. ఇది పూర్తిగా వ్యక్తిగత ప్రక్రియ.

యాభై ఒకటో రోజు

నేను ఎవరిని కలిగి ఉన్నానో అర్థం చేసుకోవడానికి నేను జట్టును దగ్గరగా చూడటం ప్రారంభించాను మరియు మరోసారి నేను గుర్తుచేసుకున్నాను:

"చాలా సమస్యలు ప్రజల సమస్యలే."

దేవ్ మరియు ఆప్స్ రెండింటిలోనూ - టీమ్‌లో మూడు పెద్ద సమస్యలు ఉన్నాయని నేను కనుగొన్నాను:

• ప్రస్తుత పరిస్థితుల పట్ల సంతృప్తి.
• బాధ్యత లేకపోవడం - ఎందుకంటే వ్యాపారాన్ని ప్రభావితం చేయడానికి ప్రదర్శకుల పని ఫలితాలను ఎవరూ తీసుకురాలేదు.
• మార్పు భయం.

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

కానీ మీరు దేనినీ మార్చకుండా మెరుగుపడలేరు.

నేను ఒక ఉద్యోగితో పూర్తిగా అసంబద్ధ సంభాషణ చేసాను, ఆప్టిమైజేషన్ కోసం నా ఆలోచనలను నేను అతనికి చెప్పాను, దానికి అతను నాకు చెప్పాడు:
- ఓహ్, గత సంవత్సరం మా వద్ద ఉన్న వాటిని మీరు చూడలేదు!
- ఐతే ఏంటి?
"ఇప్పుడు ఇది మునుపటి కంటే చాలా బాగుంది."
- కాబట్టి, ఇది మెరుగుపడలేదా?
- దేని కోసం?

మంచి ప్రశ్న - ఎందుకు? ఇది ఇప్పుడు ఉన్నదానికంటే మెరుగ్గా ఉంటే, అప్పుడు ప్రతిదీ బాగానే ఉంటే సరిపోతుంది. ఇది బాధ్యత లేకపోవటానికి దారితీస్తుంది, ఇది సూత్రప్రాయంగా పూర్తిగా సాధారణమైనది. నేను చెప్పినట్లు, టెక్నికల్ గ్రూప్ కాస్త పక్కకు తప్పుకుంది. కంపెనీ వారు ఉనికిలో ఉండాలని విశ్వసించారు, కానీ ఎవరూ ఎప్పుడూ ప్రమాణాలు సెట్ చేయలేదు. సాంకేతిక మద్దతు SLAని ఎప్పుడూ చూడలేదు, కనుక ఇది సమూహానికి చాలా "ఆమోదయోగ్యమైనది" (మరియు ఇది నన్ను ఎక్కువగా తాకింది):

• 12 సెకన్లు లోడ్ అవుతోంది;
• ప్రతి విడుదలకు 5-10 నిమిషాల పనికిరాని సమయం;
• క్లిష్టమైన సమస్యల పరిష్కారానికి రోజులు మరియు వారాలు పడుతుంది;
• డ్యూటీ సిబ్బంది లేకపోవడం 24x7 / ఆన్-కాల్.

మనం దీన్ని ఎందుకు బాగా చేయకూడదు అని ఎవరూ అడగడానికి ప్రయత్నించలేదు మరియు ఇది ఇలా ఉండవలసిన అవసరం లేదని ఎవరూ గ్రహించలేదు.

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

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

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

అందుకే డెవలపర్లు అంచనాలను పెంచారు. అదే వృత్తాంతం, వారు ఒక నిర్దిష్ట పని గురించి చర్చిస్తున్నప్పుడు, వారు నాకు అలాంటి బొమ్మను ఇచ్చారు, నేను చాలా ఆశ్చర్యపోయాను. డెవలపర్ అంచనాలలో, డెవలపర్ QA నుండి టిక్కెట్‌ను తిరిగి పొందే సమయాన్ని కలిగి ఉంటారని నాకు చెప్పబడింది, ఎందుకంటే వారు అక్కడ లోపాలను కనుగొంటారు మరియు PR తీసుకునే సమయం మరియు వ్యక్తులు సమీక్షించాల్సిన సమయం ఇది బిజీగా ఉంటుంది - అంటే, ప్రతిదీ , సాధ్యమయ్యేది.

రెండవది, అసమర్థంగా కనిపించడానికి భయపడే వ్యక్తులు అతిగా విశ్లేషించండి. సరిగ్గా ఏమి చేయాలో మీరు చెప్పినప్పుడు, అది మొదలవుతుంది: "లేదు, మనం దాని గురించి ఇక్కడ ఆలోచిస్తే ఏమి చేయాలి?" ఈ కోణంలో, మా కంపెనీ ప్రత్యేకమైనది కాదు; ఇది యువతకు ప్రామాణిక సమస్య.

ప్రతిస్పందనగా, నేను ఈ క్రింది పద్ధతులను పరిచయం చేసాను:

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

అరవైవ రోజు

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

క్లౌడ్ సేవల బిల్లు ప్రత్యేక ఆసక్తిని కలిగి ఉంది. అధిక క్లౌడ్ బిల్లుకు ప్రధాన కారణం తమ జీవితంలో మొదటిసారిగా సర్వర్‌లకు అపరిమిత ప్రాప్యతను కలిగి ఉన్న డెవలపర్‌లు అని నేను నమ్ముతున్నాను. వారు అడగవలసిన అవసరం లేదు: "దయచేసి నాకు టెస్ట్ సర్వర్ ఇవ్వండి," వారు దానిని స్వయంగా తీసుకోవచ్చు. అదనంగా, డెవలపర్‌లు ఎల్లప్పుడూ ఫేస్‌బుక్ మరియు నెట్‌ఫ్లిక్స్‌లు అసూయపడేలా చల్లని వ్యవస్థను నిర్మించాలని కోరుకుంటారు.

కానీ డెవలపర్‌లకు సర్వర్‌లను కొనుగోలు చేయడంలో అనుభవం మరియు సర్వర్‌ల అవసరమైన పరిమాణాన్ని నిర్ణయించే నైపుణ్యం లేదు, ఎందుకంటే వారికి ఇది ముందు అవసరం లేదు. మరియు వారు సాధారణంగా స్కేలబిలిటీ మరియు పనితీరు మధ్య వ్యత్యాసాన్ని అర్థం చేసుకోలేరు.

ఇన్వెంటరీ ఫలితాలు:

• మేము అదే డేటా సెంటర్ నుండి బయలుదేరాము.
• మేము 3 లాగ్ సేవలతో ఒప్పందాన్ని ముగించాము. ఎందుకంటే మా వద్ద వాటిలో 5 ఉన్నాయి - ఏదో ఒకదానితో ఆడటం ప్రారంభించిన ప్రతి డెవలపర్ కొత్తదాన్ని తీసుకున్నాడు.
• 7 AWS సిస్టమ్‌లు మూసివేయబడ్డాయి. మళ్ళీ, చనిపోయిన ప్రాజెక్టులను ఎవరూ ఆపలేదు; అవన్నీ పని చేస్తూనే ఉన్నాయి.
• సాఫ్ట్‌వేర్ ఖర్చులు 6 రెట్లు తగ్గాయి.

డెబ్బై అయిదవ రోజు

సమయం గడిచిపోయింది, మరియు రెండున్నర నెలల్లో నేను డైరెక్టర్ల బోర్డుని కలవవలసి వచ్చింది. మా డైరెక్టర్ల బోర్డు ఇతరుల కంటే మెరుగైనది లేదా అధ్వాన్నమైనది కాదు; అన్ని డైరెక్టర్ల బోర్డుల వలె, ఇది ప్రతిదీ తెలుసుకోవాలనుకుంటుంది. ప్రజలు డబ్బును పెట్టుబడి పెడతారు మరియు మేము చేసేది సెట్ KPIలకు ఎంతవరకు సరిపోతుందో అర్థం చేసుకోవాలనుకుంటున్నారు.

డైరెక్టర్ల బోర్డు ప్రతి నెలా చాలా సమాచారాన్ని అందుకుంటుంది: వినియోగదారుల సంఖ్య, వారి పెరుగుదల, వారు ఏ సేవలను ఉపయోగిస్తున్నారు మరియు ఎలా, పనితీరు మరియు ఉత్పాదకత మరియు చివరకు, సగటు పేజీ లోడింగ్ వేగం.

ఒకే సమస్య ఏమిటంటే, సగటు స్వచ్ఛమైన చెడు అని నేను నమ్ముతున్నాను. అయితే ఈ విషయాన్ని డైరెక్టర్ల బోర్డుకు వివరించడం చాలా కష్టం. వారు సమగ్ర సంఖ్యలతో పనిచేయడానికి అలవాటు పడ్డారు, మరియు ఉదాహరణకు, సెకనుకు లోడ్ అయ్యే సమయాల వ్యాప్తి కాదు.

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

అంటే, ColdFusion Jetty మరియు nginx గుండా వెళ్లి పేజీలను ప్రారంభిస్తుంది. మరియు చిత్రాలు, JS మరియు CSS వారి స్వంత కాన్ఫిగరేషన్‌లతో ప్రత్యేక nginx ద్వారా వెళ్తాయి. ఇది నేను చెప్పేది చాలా ప్రామాణికమైన అభ్యాసం నేను వ్రాసిన కొన్ని సంవత్సరాల క్రితం. ఫలితంగా, చిత్రాలు చాలా వేగంగా లోడ్ అవుతాయి మరియు... సగటు లోడింగ్ వేగం 200 ms పెరిగింది.

జెట్టీతో వచ్చే డేటా ఆధారంగా గ్రాఫ్ నిర్మించబడినందున ఇది జరిగింది. అంటే, వేగవంతమైన కంటెంట్ గణనలో చేర్చబడలేదు - సగటు విలువ పెరిగింది. ఇది మాకు స్పష్టంగా ఉంది, మేము నవ్వుకున్నాము, కానీ మేము ఎందుకు ఏదో చేసాము మరియు విషయాలు 12% అధ్వాన్నంగా మారాయని మేము డైరెక్టర్ల బోర్డుకి ఎలా వివరించగలము?

ఎనభై ఐదు రోజు

మూడవ నెల చివరిలో, నేను అస్సలు లెక్కించని విషయం ఒకటి ఉందని నేను గ్రహించాను: సమయం. నేను మాట్లాడిన ప్రతిదానికీ సమయం పడుతుంది.

ఇది నా నిజమైన వారపు క్యాలెండర్ - కేవలం పని వారం, చాలా బిజీగా లేదు. ప్రతిదానికీ సమయం సరిపోదు. అందువల్ల, మళ్ళీ, మీరు సమస్యలను ఎదుర్కోవడంలో సహాయపడే వ్యక్తులను నియమించుకోవాలి.

తీర్మానం

అంతే కాదు. ఈ కథనంలో, మేము ఉత్పత్తితో ఎలా పని చేసాము మరియు సాధారణ వేవ్‌కి ట్యూన్ చేయడానికి ప్రయత్నించాము, లేదా మేము సాంకేతిక మద్దతును ఎలా సమీకృతం చేసాము లేదా ఇతర సాంకేతిక సమస్యలను ఎలా పరిష్కరించాము అనే విషయాలను కూడా నేను అర్థం చేసుకోలేదు. ఉదాహరణకు, డేటాబేస్‌లోని అతిపెద్ద పట్టికలలో మనం ఉపయోగించకూడదని నేను చాలా ప్రమాదవశాత్తు తెలుసుకున్నాను SEQUENCE. మాకు స్వీయ-వ్రాతపూర్వక ఫంక్షన్ ఉంది nextID, మరియు ఇది లావాదేవీలో ఉపయోగించబడదు.

మేము చాలా కాలం పాటు మాట్లాడుకోగలిగే ఒక మిలియన్ ఇలాంటి విషయాలు ఉన్నాయి. కానీ ఇప్పటికీ చెప్పవలసిన ముఖ్యమైన విషయం సంస్కృతి.

ఇది సంస్కృతి లేదా దాని లేకపోవడం అన్ని ఇతర సమస్యలకు దారితీస్తుంది. ప్రజలు ఇక్కడ సంస్కృతిని నిర్మించడానికి మేము ప్రయత్నిస్తున్నాము:

• వైఫల్యాలకు భయపడరు;
• తప్పుల నుండి నేర్చుకోండి;
• ఇతర జట్లతో సహకరించండి;
• చొరవ తీసుకోండి;
• బాధ్యత వహించు;
• ఫలితాన్ని లక్ష్యంగా స్వాగతించండి;
• విజయాన్ని జరుపుకుంటున్నారు.

దీంతో మిగతావన్నీ వస్తాయి.

లియోన్ ఫైర్ ట్విట్టర్‌లో, ఫేస్బుక్ మరియు న మీడియం.

లెగసీకి సంబంధించి రెండు వ్యూహాలు ఉన్నాయి: అన్ని ఖర్చులతో దానితో పని చేయకుండా ఉండండి లేదా సంబంధిత ఇబ్బందులను ధైర్యంగా అధిగమించండి. మేము చూస్తున్నాము DevOpsConf మేము రెండవ మార్గాన్ని తీసుకుంటాము, ప్రక్రియలు మరియు విధానాలను మారుస్తున్నాము. మాతో చేరండి YouTube, మెయిలింగ్ జాబితా и టెలిగ్రామ్, మరియు కలిసి మేము DevOps సంస్కృతిని అమలు చేస్తాము.

మూలం: www.habr.com