இந்த பாத்திரத்தை அவர் இரண்டாவது முறை செய்யும்போதுதான் CTOவின் திறமை சோதிக்கப்படுகிறது என்பது அறியப்படுகிறது. ஏனென்றால், ஒரு நிறுவனத்தில் பல வருடங்கள் பணியாற்றுவதும், அதனுடன் பரிணாம வளர்ச்சியடைவதும், அதே கலாச்சார சூழலில் இருப்பதால், படிப்படியாக அதிகப் பொறுப்பைப் பெறுவதும் ஒன்றுதான். மேலும், மரபு சாமான்கள் மற்றும் பல பிரச்சனைகள் நேர்த்தியாக கம்பளத்தின் கீழ் துடைத்தெறியப்பட்ட ஒரு நிறுவனத்தில் தொழில்நுட்ப இயக்குநர் பதவிக்கு நேராக வருவது முற்றிலும் வேறானது.
இந்த அர்த்தத்தில், அவர் பகிர்ந்து கொண்ட லியோன் ஃபயர் அனுபவம் , சரியாக தனித்துவம் இல்லை, ஆனால் அவரது அனுபவம் மற்றும் 20 ஆண்டுகளில் அவர் முயற்சி செய்ய முடிந்த பல்வேறு பாத்திரங்களின் எண்ணிக்கையால் பெருக்கப்பட்டது, இது மிகவும் பயனுள்ளதாக இருக்கும். வெட்டுக்குக் கீழே 90 நாட்களுக்கும் மேலான நிகழ்வுகளின் காலவரிசையும், வேறு யாருக்காவது நடக்கும்போது வேடிக்கையாக இருக்கும், ஆனால் நேரில் எதிர்கொள்ளும் அளவுக்கு வேடிக்கையாக இல்லாத பல கதைகளும் உள்ளன.
லியோன் ரஷ்ய மொழியில் மிகவும் வண்ணமயமாக பேசுகிறார், எனவே உங்களுக்கு 35-40 நிமிடங்கள் இருந்தால், வீடியோவைப் பார்க்க பரிந்துரைக்கிறேன். கீழே நேரத்தைச் சேமிக்க உரைப் பதிப்பு.
அறிக்கையின் முதல் பதிப்பு, பயனுள்ள பரிந்துரைகளைக் கொண்ட நபர்களுடனும் செயல்முறைகளுடனும் பணிபுரிவதற்கான நன்கு கட்டமைக்கப்பட்ட விளக்கமாகும். ஆனால் வழியில் சந்தித்த அனைத்து ஆச்சரியங்களையும் அவள் தெரிவிக்கவில்லை. எனவே, வடிவமைப்பை மாற்றி, புதிய நிறுவனத்தில் ஜாக்-இன்-பாக்ஸ் போல என் முன் தோன்றிய சிக்கல்களையும், அவற்றைத் தீர்க்கும் முறைகளையும் காலவரிசைப்படி வழங்கினேன்.
ஒரு மாதம் முன்பு
பல நல்ல கதைகளைப் போலவே, இதுவும் மதுவுடன் தொடங்கியது. நாங்கள் ஒரு மதுக்கடையில் நண்பர்களுடன் அமர்ந்திருந்தோம், தகவல் தொழில்நுட்ப வல்லுநர்கள் எதிர்பார்த்தது போலவே, அனைவரும் தங்கள் பிரச்சினைகளைப் பற்றி அழுதனர். அவர்களில் ஒருவர் வேலையை மாற்றிவிட்டு, தொழில்நுட்பம், மக்கள் மற்றும் குழுவுடன் தனது பிரச்சினைகளைப் பற்றி பேசிக்கொண்டிருந்தார். நான் எவ்வளவு அதிகமாகக் கேட்கிறேனோ, அவ்வளவு அதிகமாக அவர் என்னை வேலைக்கு அமர்த்த வேண்டும் என்பதை உணர்ந்தேன், ஏனென்றால் இவை கடந்த 15 வருடங்களாக நான் தீர்க்கும் பிரச்சனைகள். நான் அவரிடம் சொன்னேன், அடுத்த நாள் நாங்கள் ஒரு வேலை சூழலில் சந்தித்தோம். நிறுவனம் கற்பித்தல் உத்திகள் என்று அழைக்கப்பட்டது.
கற்பித்தல் உத்திகள், பிறந்தது முதல் மூன்று வயது வரையிலான மிகச் சிறிய குழந்தைகளுக்கான பாடத்திட்டத்தில் சந்தையில் முன்னணியில் உள்ளது. பாரம்பரிய "காகித" நிறுவனம் ஏற்கனவே 40 ஆண்டுகள் பழமையானது, மேலும் தளத்தின் டிஜிட்டல் SaaS பதிப்பு 10 ஆண்டுகள் பழமையானது. ஒப்பீட்டளவில் சமீபத்தில், டிஜிட்டல் தொழில்நுட்பத்தை நிறுவனத்தின் தரத்திற்கு மாற்றியமைக்கும் செயல்முறை தொடங்கியது. "புதிய" பதிப்பு 2017 இல் தொடங்கப்பட்டது மற்றும் கிட்டத்தட்ட பழையதைப் போலவே இருந்தது, அது மோசமாக வேலை செய்தது.
மிகவும் சுவாரஸ்யமான விஷயம் என்னவென்றால், இந்த நிறுவனத்தின் போக்குவரத்து மிகவும் கணிக்கக்கூடியது - நாளுக்கு நாள், ஆண்டுதோறும், எத்தனை பேர், எப்போது வருவார்கள் என்பதை நீங்கள் மிகத் தெளிவாகக் கணிக்க முடியும். உதாரணமாக, மதியம் 13 முதல் 15 மணி வரை மழலையர் பள்ளியில் உள்ள அனைத்து குழந்தைகளும் படுக்கைக்குச் செல்கிறார்கள், ஆசிரியர்கள் தகவலை உள்ளிடத் தொடங்குகிறார்கள். வார இறுதி நாட்களைத் தவிர இது ஒவ்வொரு நாளும் நடக்கும், ஏனென்றால் வார இறுதி நாட்களில் யாரும் வேலை செய்ய மாட்டார்கள்.
சற்று முன்னோக்கிப் பார்க்கும்போது, பல்வேறு காரணங்களுக்காக சுவாரஸ்யமான அதிக வருடாந்திர போக்குவரத்து காலத்தில் எனது வேலையைத் தொடங்கினேன் என்பதை நான் கவனிக்கிறேன்.
2 வருடங்கள் பழமையானதாகத் தோன்றிய இந்த இயங்குதளம், ஒரு விசித்திரமான அடுக்கைக் கொண்டிருந்தது: ColdFusion & SQL Server 2008ல் இருந்து. கோல்ட்ஃப்யூஷன், உங்களுக்குத் தெரியாவிட்டால், பெரும்பாலும் உங்களுக்குத் தெரியாது என்றால், 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 களுக்கு எவ்வளவு பொருந்துகிறது என்பதைப் புரிந்துகொள்ள விரும்புகிறார்கள்.
இயக்குநர்கள் குழு ஒவ்வொரு மாதமும் நிறைய தகவல்களைப் பெறுகிறது: பயனர்களின் எண்ணிக்கை, அவர்களின் வளர்ச்சி, அவர்கள் பயன்படுத்தும் சேவைகள் மற்றும் எப்படி, செயல்திறன் மற்றும் உற்பத்தித்திறன் மற்றும் இறுதியாக, சராசரி பக்க ஏற்றுதல் வேகம்.
ஒரே பிரச்சனை என்னவென்றால், சராசரி சுத்த தீமை என்று நான் நம்புகிறேன். ஆனால் இதை இயக்குநர் குழுவிடம் விளக்குவது மிகவும் கடினம். அவர்கள் ஒருங்கிணைக்கப்பட்ட எண்களுடன் செயல்படப் பழகிவிட்டனர், எடுத்துக்காட்டாக, வினாடிக்கு ஏற்றும் நேரங்களின் பரவல் அல்ல.
இந்த விஷயத்தில் சில சுவாரஸ்யமான விஷயங்கள் இருந்தன. எடுத்துக்காட்டாக, உள்ளடக்கத்தின் வகையைப் பொறுத்து தனித்தனி வலை சேவையகங்களுக்கு இடையில் போக்குவரத்தைப் பிரிக்க வேண்டும் என்று நான் கூறினேன்.
அதாவது, கோல்ட்ஃப்யூஷன் ஜெட்டி மற்றும் nginx வழியாகச் சென்று பக்கங்களைத் தொடங்குகிறது. மற்றும் படங்கள், JS மற்றும் CSS ஆகியவை அவற்றின் சொந்த உள்ளமைவுகளுடன் ஒரு தனி nginx வழியாக செல்கின்றன. இது நான் பேசும் மிகவும் நிலையான நடைமுறை ஓரிரு ஆண்டுகளுக்கு முன்பு. இதன் விளைவாக, படங்கள் மிக வேகமாக ஏற்றப்படுகின்றன, மேலும்... சராசரி ஏற்றுதல் வேகம் 200 எம்எஸ் அதிகரித்துள்ளது.
ஜெட்டியுடன் வரும் தரவுகளின் அடிப்படையில் வரைபடம் உருவாக்கப்பட்டதால் இது நடந்தது. அதாவது, வேகமான உள்ளடக்கம் கணக்கீட்டில் சேர்க்கப்படவில்லை - சராசரி மதிப்பு உயர்ந்துள்ளது. இது எங்களுக்கு தெளிவாக இருந்தது, நாங்கள் சிரித்தோம், ஆனால் நாங்கள் ஏன் ஏதாவது செய்தோம் மற்றும் விஷயங்கள் 12% மோசமாகிவிட்டன என்பதை இயக்குநர்கள் குழுவிற்கு எவ்வாறு விளக்குவது?
எண்பத்தி ஐந்து நாள்
மூன்றாவது மாதத்தின் முடிவில், நான் எண்ணிப் பார்க்காத ஒன்று இருப்பதை உணர்ந்தேன்: நேரம். நான் பேசியது எல்லாம் நேரம் எடுக்கும்.
இது எனது உண்மையான வாராந்திர காலண்டர் - ஒரு வேலை வாரம், மிகவும் பிஸியாக இல்லை. எல்லாவற்றுக்கும் நேரம் போதாது. எனவே, மீண்டும், சிக்கல்களைச் சமாளிக்க உங்களுக்கு உதவும் நபர்களை நீங்கள் நியமிக்க வேண்டும்.
முடிவுக்கு
அதுமட்டுமல்ல. இந்தக் கதையில், தயாரிப்புடன் நாங்கள் எவ்வாறு வேலை செய்தோம் மற்றும் பொதுவான அலைக்கு இசைக்க முயற்சித்தோம், அல்லது தொழில்நுட்ப ஆதரவை எவ்வாறு ஒருங்கிணைத்தோம் அல்லது பிற தொழில்நுட்ப சிக்கல்களை நாங்கள் எவ்வாறு தீர்த்தோம் என்பது கூட எனக்குப் புரியவில்லை. எடுத்துக்காட்டாக, தரவுத்தளத்தில் உள்ள மிகப்பெரிய அட்டவணையில் நாம் பயன்படுத்தாததை நான் தற்செயலாகக் கற்றுக்கொண்டேன் SEQUENCE. எங்களிடம் சுயமாக எழுதப்பட்ட செயல்பாடு உள்ளது nextID, மற்றும் இது ஒரு பரிவர்த்தனையில் பயன்படுத்தப்படாது.
நாங்கள் நீண்ட நேரம் பேசக்கூடிய இன்னும் ஒரு மில்லியன் ஒத்த விஷயங்கள் இருந்தன. ஆனால் இன்னும் சொல்ல வேண்டிய முக்கியமான விஷயம் கலாச்சாரம்.
கலாச்சாரம் அல்லது அதன் பற்றாக்குறை மற்ற எல்லா பிரச்சனைகளுக்கும் வழிவகுக்கிறது. மக்கள் இருக்கும் கலாச்சாரத்தை உருவாக்க நாங்கள் முயற்சிக்கிறோம்:
- தோல்விகளுக்கு பயப்படுவதில்லை;
- தவறுகளிலிருந்து கற்றுக்கொள்ளுங்கள்;
- மற்ற அணிகளுடன் ஒத்துழைக்கவும்;
- முன்முயற்சி எடு;
- பொறுப்பேற்க;
- முடிவை ஒரு இலக்காக வரவேற்கவும்;
- வெற்றியைக் கொண்டாடுகிறது.
இத்துடன் மற்ற அனைத்தும் வரும்.
லியோன் தீ , மற்றும் .
மரபு சம்பந்தமாக இரண்டு உத்திகள் உள்ளன: எல்லா விலையிலும் அதனுடன் வேலை செய்வதைத் தவிர்க்கவும் அல்லது அதனுடன் தொடர்புடைய சிரமங்களை தைரியமாக சமாளிக்கவும். நாங்கள் சி நாங்கள் இரண்டாவது பாதையில் செல்கிறோம், செயல்முறைகள் மற்றும் அணுகுமுறைகளை மாற்றுகிறோம். எங்களுடன் சேருங்கள் , и , மற்றும் ஒன்றாக நாங்கள் DevOps கலாச்சாரத்தை செயல்படுத்துவோம்.
ஆதாரம்: www.habr.com