Banki.ru போர்ட்டலின் செயல்பாட்டு இயக்குனர் Andrey Nikolsky கடந்த ஆண்டு மாநாட்டில் பேசினார் அனாதை சேவைகள் பற்றி: உள்கட்டமைப்பில் ஒரு அனாதையை எவ்வாறு அடையாளம் காண்பது, ஏன் அனாதை சேவைகள் மோசமாக உள்ளன, அவற்றை என்ன செய்வது, எதுவும் உதவவில்லை என்றால் என்ன செய்வது.
வெட்டுக்கு கீழே அறிக்கையின் உரை பதிப்பு உள்ளது.
வணக்கம் சக ஊழியர்களே! எனது பெயர் ஆண்ட்ரே, நான் Banki.ru இல் செயல்படுகிறேன்.
எங்களிடம் பெரிய சேவைகள் உள்ளன, இவை ஒரே மாதிரியான சேவைகள், மிகவும் கிளாசிக்கல் அர்த்தத்தில் சேவைகள் உள்ளன, மேலும் மிகச் சிறியவை உள்ளன. எனது தொழிலாளி-விவசாயி சொற்களில், ஒரு சேவை எளிமையானது மற்றும் சிறியது என்றால், அது மைக்ரோ என்றும், அது மிகவும் எளிமையானது மற்றும் சிறியது இல்லையென்றால், அது ஒரு சேவை மட்டுமே என்று நான் கூறுகிறேன்.
சேவைகளின் நன்மைகள்
சேவைகளின் நன்மைகளை நான் விரைவாகப் பார்ப்பேன்.
முதலாவது அளவிடுதல். நீங்கள் சேவையில் விரைவாக ஏதாவது செய்து உற்பத்தியைத் தொடங்கலாம். நீங்கள் ட்ராஃபிக்கைப் பெற்றுள்ளீர்கள், சேவையை குளோன் செய்துள்ளீர்கள். உங்களிடம் அதிக போக்குவரத்து உள்ளது, நீங்கள் அதை குளோன் செய்து அதனுடன் வாழ்கிறீர்கள். இது ஒரு நல்ல போனஸ், கொள்கையளவில், நாங்கள் தொடங்கியபோது, இது எங்களுக்கு மிக முக்கியமான விஷயமாக கருதப்பட்டது, ஏன் இதையெல்லாம் செய்கிறோம்.
இரண்டாவதாக, தனிமைப்படுத்தப்பட்ட மேம்பாடு, உங்களிடம் பல மேம்பாட்டுக் குழுக்கள் இருக்கும்போது, ஒவ்வொரு அணியிலும் பல்வேறு டெவலப்பர்கள், ஒவ்வொரு குழுவும் அதன் சொந்த சேவையை உருவாக்குகிறது.
அணிகளுடன் ஒரு நுணுக்கம் உள்ளது. டெவலப்பர்கள் வேறு. மற்றும் உள்ளன, எடுத்துக்காட்டாக, . நான் இதை முதலில் மாக்சிம் டோரோஃபீவ் உடன் பார்த்தேன். சில நேரங்களில் ஸ்னோஃப்ளேக் மக்கள் சில அணிகளில் இருப்பார்கள், மற்றவர்கள் அல்ல. இது நிறுவனம் முழுவதும் பயன்படுத்தப்படும் பல்வேறு சேவைகளை சற்று சீரற்றதாக்குகிறது.
படத்தைப் பாருங்கள்: இது ஒரு நல்ல டெவலப்பர், அவருக்கு பெரிய கைகள் உள்ளன, அவர் நிறைய செய்ய முடியும். இந்தக் கைகள் எங்கிருந்து வருகின்றன என்பதுதான் முக்கிய பிரச்சனை.
சேவைகள் வெவ்வேறு பணிகளுக்கு மிகவும் பொருத்தமான வெவ்வேறு நிரலாக்க மொழிகளைப் பயன்படுத்துவதை சாத்தியமாக்குகின்றன. சில சேவைகள் கோவில் உள்ளன, சில எர்லாங்கில் உள்ளன, சில ரூபியில் உள்ளன, ஏதோ ஒன்று PHP இல் உள்ளது, ஏதோ பைத்தானில் உள்ளது. பொதுவாக, நீங்கள் மிகவும் பரவலாக விரிவாக்க முடியும். இங்கேயும் நுணுக்கங்கள் உள்ளன.
சேவை சார்ந்த கட்டிடக்கலை முதன்மையாக devops பற்றியது. அதாவது, உங்களிடம் ஆட்டோமேஷன் இல்லையென்றால், வரிசைப்படுத்தல் செயல்முறை இல்லை, நீங்கள் அதை கைமுறையாக உள்ளமைத்தால், உங்கள் உள்ளமைவுகள் சேவை நிகழ்விலிருந்து நிகழ்வுக்கு மாறலாம், மேலும் நீங்கள் ஏதாவது செய்ய அங்கு செல்ல வேண்டும், பின்னர் நீங்கள் நரகத்தில் இருக்கிறீர்கள்.
எடுத்துக்காட்டாக, உங்களிடம் 20 சேவைகள் உள்ளன, மேலும் நீங்கள் கைமுறையாக பயன்படுத்த வேண்டும், உங்களிடம் 20 கன்சோல்கள் உள்ளன, மேலும் ஒரே நேரத்தில் நிஞ்ஜாவைப் போல "Enter" ஐ அழுத்தவும். இது மிகவும் நன்றாக இல்லை.
சோதனைக்குப் பிறகு உங்களிடம் ஒரு சேவை இருந்தால் (நிச்சயமாக சோதனை இருந்தால்), மற்றும் அதை இன்னும் ஒரு கோப்புடன் முடிக்க வேண்டும், அதனால் அது தயாரிப்பில் வேலை செய்கிறது, உங்களுக்காக மோசமான செய்தியும் என்னிடம் உள்ளது.
நீங்கள் குறிப்பிட்ட அமேசான் சேவைகளை நம்பி ரஷ்யாவில் பணிபுரிந்தால், இரண்டு மாதங்களுக்கு முன்பு நீங்கள் "அனைத்தும் எரிகிறது, நான் நன்றாக இருக்கிறேன், எல்லாம் அருமையாக உள்ளது."
வரிசைப்படுத்தலை தானியக்கமாக்குவதற்கு அன்சிபிள், ஒன்றிணைவதற்கான பப்பட், வரிசைப்படுத்தலை தானியக்கமாக்க மூங்கில் மற்றும் அனைத்தையும் எப்படியாவது விவரிக்க கன்ஃப்ளூயன்ஸ் ஆகியவற்றைப் பயன்படுத்துகிறோம்.
நான் இதைப் பற்றி விரிவாகக் கூறமாட்டேன், ஏனென்றால் அறிக்கையானது தொடர்பு நடைமுறைகளைப் பற்றியது, தொழில்நுட்ப செயலாக்கத்தைப் பற்றியது அல்ல.
எடுத்துக்காட்டாக, சர்வரில் உள்ள பப்பட் ரூபி 2 உடன் செயல்படுவதில் எங்களுக்கு சிக்கல்கள் உள்ளன, ஆனால் சில பயன்பாடுகள் ரூபி 1.8 க்காக எழுதப்பட்டுள்ளது, மேலும் அவை ஒன்றாக வேலை செய்யாது. அங்கே ஏதோ தவறு நடக்கிறது. நீங்கள் ஒரு கணினியில் ரூபியின் பல பதிப்புகளை இயக்க வேண்டியிருக்கும் போது, பொதுவாக உங்களுக்கு சிக்கல்கள் ஏற்படத் தொடங்கும்.
எடுத்துக்காட்டாக, ஒவ்வொரு டெவலப்பருக்கும் ஒரு தளத்தை வழங்குகிறோம், அதில் நம்மிடம் உள்ள அனைத்தும், உருவாக்கக்கூடிய அனைத்து சேவைகளும் உள்ளன, இதனால் அவருக்கு தனிமைப்படுத்தப்பட்ட சூழல் உள்ளது, அவர் அதை உடைத்து அவர் விரும்பியபடி உருவாக்க முடியும்.
நீங்கள் அங்கு ஏதாவது ஆதரவுடன் சில சிறப்பாக தொகுக்கப்பட்ட தொகுப்பு தேவை என்று நடக்கும். இது மிகவும் கடினமானது. டோக்கர் படம் 45 ஜிபி எடையுள்ள ஒரு அறிக்கையைக் கேட்டேன். லினக்ஸில், நிச்சயமாக, இது எளிமையானது, அங்கு எல்லாம் சிறியது, ஆனால் இன்னும், போதுமான இடம் இருக்காது.
சரி, முரண்பட்ட சார்புகள் உள்ளன, திட்டத்தின் ஒரு பகுதி ஒரு பதிப்பின் நூலகத்தைச் சார்ந்தது, திட்டத்தின் மற்றொரு பகுதி மற்றொரு பதிப்பைச் சார்ந்தது, மேலும் நூலகங்கள் ஒன்றாக நிறுவப்படவில்லை.
எங்களிடம் PHP 5.6 இல் தளங்கள் மற்றும் சேவைகள் உள்ளன, அவற்றைப் பற்றி நாங்கள் வெட்கப்படுகிறோம், ஆனால் நாங்கள் என்ன செய்ய முடியும்? இது எங்களின் ஒரே தளம். PHP 7 இல் தளங்கள் மற்றும் சேவைகள் உள்ளன, அவற்றில் அதிகமானவை உள்ளன, அவற்றைப் பற்றி நாங்கள் வெட்கப்படவில்லை. ஒவ்வொரு டெவலப்பருக்கும் தனது சொந்த தளம் உள்ளது, அங்கு அவர் மகிழ்ச்சியுடன் பார்த்தார்.
நீங்கள் ஒரு நிறுவனத்தில் ஒரு மொழியில் எழுதினால், ஒரு டெவலப்பருக்கு மூன்று மெய்நிகர் இயந்திரங்கள் இயல்பானதாக இருக்கும். உங்களிடம் வெவ்வேறு நிரலாக்க மொழிகள் இருந்தால், நிலைமை மோசமாகிவிடும்.
உங்களிடம் தளங்களும் சேவைகளும் உள்ளன, இதில், Go விற்கு மற்றொரு தளம், ரூபிக்கு ஒரு தளம் மற்றும் பக்கத்தில் வேறு சில Redis. இதன் விளைவாக, இவை அனைத்தும் ஆதரவுக்கான ஒரு பெரிய புலமாக மாறும், மேலும் சில நேரங்களில் அது உடைந்து போகலாம்.
எனவே, நிரலாக்க மொழியின் நன்மைகளை வெவ்வேறு கட்டமைப்புகளைப் பயன்படுத்தி மாற்றினோம், ஏனெனில் PHP கட்டமைப்புகள் முற்றிலும் வேறுபட்டவை, அவை வெவ்வேறு திறன்கள், வெவ்வேறு சமூகங்கள் மற்றும் வெவ்வேறு ஆதரவைக் கொண்டுள்ளன. நீங்கள் ஒரு சேவையை எழுதலாம், அதனால் நீங்கள் ஏற்கனவே ஏதாவது தயாராக இருக்க வேண்டும்.
ஒவ்வொரு சேவைக்கும் அதன் சொந்த குழு உள்ளது
எங்கள் முக்கிய நன்மை, பல ஆண்டுகளாக படிகமாக உள்ளது, ஒவ்வொரு சேவைக்கும் அதன் சொந்த குழு உள்ளது. இது ஒரு பெரிய திட்டத்திற்கு வசதியானது, நீங்கள் ஆவணங்களில் நேரத்தை மிச்சப்படுத்தலாம், மேலாளர்கள் தங்கள் திட்டத்தை நன்கு அறிவார்கள்.
ஆதரவிலிருந்து பணிகளை எளிதாகச் சமர்ப்பிக்கலாம். உதாரணமாக, காப்பீட்டு சேவை முறிந்தது. உடனடியாக காப்பீட்டைக் கையாளும் குழு அதை சரிசெய்ய செல்கிறது.
புதிய அம்சங்கள் விரைவாக உருவாக்கப்படுகின்றன, ஏனென்றால் உங்களிடம் ஒரு அணு சேவை இருக்கும்போது, அதில் ஏதாவது ஒன்றை விரைவாக திருகலாம்.
உங்கள் சேவையை நீங்கள் உடைக்கும்போது, இது தவிர்க்க முடியாமல் நிகழும்போது, நீங்கள் மற்றவர்களின் சேவைகளைப் பாதிக்கவில்லை, மற்ற குழுக்களைச் சேர்ந்த டெவலப்பர்கள் உங்களிடம் பிட்களுடன் ஓடி வந்து: "ஐயோ, அதைச் செய்யாதே" என்று கூற மாட்டார்கள்.
எப்போதும் போல, நுணுக்கங்கள் உள்ளன. எங்களிடம் நிலையான அணிகள் உள்ளன, மேலாளர்கள் அணியில் இணைக்கப்பட்டுள்ளனர். தெளிவான ஆவணங்கள் உள்ளன, மேலாளர்கள் எல்லாவற்றையும் உன்னிப்பாகக் கண்காணிக்கிறார்கள். மேலாளரைக் கொண்ட ஒவ்வொரு அணிக்கும் பல சேவைகள் உள்ளன, மேலும் ஒரு குறிப்பிட்ட திறன் உள்ளது.
அணிகள் மிதந்தால் (நாங்களும் சில நேரங்களில் இதைப் பயன்படுத்துகிறோம்), "நட்சத்திர வரைபடம்" என்று அழைக்கப்படும் ஒரு நல்ல முறை உள்ளது.
உங்களிடம் சேவைகள் மற்றும் நபர்களின் பட்டியல் உள்ளது. ஒரு நட்சத்திரம் என்றால் நபர் இந்த சேவையில் நிபுணத்துவம் பெற்றவர், புத்தகம் என்றால் அந்த நபர் இந்த சேவையைப் படிக்கிறார். நபரின் பணி புத்தகத்தை ஒரு நட்சத்திரத்திற்கு மாற்றுவதாகும். சேவையின் முன் எதுவும் எழுதப்படவில்லை என்றால், சிக்கல்கள் தொடங்குகின்றன, அதைப் பற்றி நான் மேலும் பேசுவேன்.
அனாதை சேவைகள் எவ்வாறு தோன்றும்?
முதல் பிரச்சனை, உங்கள் உள்கட்டமைப்பில் ஒரு அனாதை சேவையைப் பெறுவதற்கான முதல் வழி மக்களை நீக்குவது. பணிகள் மதிப்பிடப்படுவதற்கு முன், வணிக சந்திப்புக்கான காலக்கெடுவை யாராவது எப்போதாவது வைத்திருந்தார்களா? சில நேரங்களில் காலக்கெடு இறுக்கமாக உள்ளது மற்றும் ஆவணங்களுக்கு போதுமான நேரம் இல்லை. "நாங்கள் சேவையை உற்பத்திக்கு ஒப்படைக்க வேண்டும், பின்னர் அதைச் சேர்ப்போம்."
குழு சிறியதாக இருந்தால், எல்லாவற்றையும் எழுதும் ஒரு டெவலப்பர் இருக்கிறார், மீதமுள்ளவர்கள் இறக்கைகளில் உள்ளனர். "நான் அடிப்படைக் கட்டமைப்பை எழுதினேன், இடைமுகங்களைச் சேர்ப்போம்." பின்னர் ஒரு கட்டத்தில் மேலாளர், எடுத்துக்காட்டாக, வெளியேறுகிறார். இந்த காலகட்டத்தில், மேலாளர் வெளியேறி, புதியவர் இன்னும் நியமிக்கப்படாத நிலையில், சேவை எங்கு செல்கிறது, அங்கு என்ன நடக்கிறது என்பதை டெவலப்பர்களே தீர்மானிக்கிறார்கள். நமக்குத் தெரிந்தபடி (சில ஸ்லைடுகளுக்குத் திரும்புவோம்), சில அணிகளில் ஸ்னோஃப்ளேக் நபர்கள் உள்ளனர், சில சமயங்களில் ஸ்னோஃப்ளேக் குழு முன்னணி. பின்னர் அவர் வெளியேறினார், நாங்கள் ஒரு அனாதை சேவையைப் பெறுகிறோம்.
அதே நேரத்தில், ஆதரவிலிருந்தும் வணிகத்திலிருந்தும் பணிகள் மறைந்துவிடாது; அவை பின்னடைவில் முடிவடையும். சேவையின் வளர்ச்சியின் போது ஏதேனும் வாஸ்து பிழைகள் இருந்தால், அவை பின்னடைவில் முடிவடையும். சேவை மெதுவாக மோசமடைந்து வருகிறது.
ஒரு அனாதையை எவ்வாறு அடையாளம் காண்பது?
இந்த பட்டியல் நிலைமையை நன்றாக விவரிக்கிறது. அவர்களின் உள்கட்டமைப்பு பற்றி யார் எதையும் கற்றுக்கொண்டார்கள்?
ஆவணப்படுத்தப்பட்ட வேலைகளைப் பற்றி: ஒரு சேவை உள்ளது, பொதுவாக, அது வேலை செய்கிறது, அதனுடன் எவ்வாறு வேலை செய்வது என்பது குறித்த இரண்டு பக்க கையேட்டைக் கொண்டுள்ளது, ஆனால் அது உள்ளே எவ்வாறு செயல்படுகிறது என்பது யாருக்கும் தெரியாது.
அல்லது, எடுத்துக்காட்டாக, சில வகையான இணைப்பு சுருக்கி உள்ளது. எடுத்துக்காட்டாக, வெவ்வேறு சேவைகளில் வெவ்வேறு நோக்கங்களுக்காக தற்போது மூன்று இணைப்பு சுருக்கிகள் பயன்பாட்டில் உள்ளன. இவை தான் விளைவுகள்.
இப்போது நான் வெளிப்படையான கேப்டனாக இருப்பேன். என்ன செய்ய வேண்டும்? முதலில், சேவையை மற்றொரு மேலாளர், மற்றொரு குழுவிற்கு மாற்ற வேண்டும். உங்கள் டீம் லீட் இன்னும் வெளியேறவில்லை என்றால், இந்த மற்ற அணியில், சேவை ஒரு அனாதை போன்றது என்பதை நீங்கள் புரிந்து கொள்ளும்போது, அதைப் பற்றி ஏதாவது புரிந்து கொண்ட ஒருவரை நீங்கள் சேர்க்க வேண்டும்.
முக்கிய விஷயம்: இரத்தத்தில் எழுதப்பட்ட பரிமாற்ற நடைமுறைகள் உங்களிடம் இருக்க வேண்டும். எங்கள் விஷயத்தில், நான் இதை வழக்கமாகக் கண்காணிக்கிறேன், ஏனென்றால் எனக்கு இது வேலை செய்ய வேண்டும். மேலாளர்களுக்கு இது விரைவாக வழங்கப்பட வேண்டும், பின்னர் அது என்ன ஆனது என்பது அவர்களுக்கு முக்கியமல்ல.
ஒரு அனாதையை உருவாக்குவதற்கான அடுத்த வழி "நாங்கள் அதை அவுட்சோர்ஸ் செய்வோம், அது வேகமாக இருக்கும், பின்னர் நாங்கள் அதை குழுவிடம் ஒப்படைப்போம்." அனைவருக்கும் அணியில் சில திட்டங்கள் உள்ளன என்பது தெளிவாகிறது. பெரும்பாலும் ஒரு வணிக வாடிக்கையாளர் நிறுவனம் வைத்திருக்கும் தொழில்நுட்பத் துறையைப் போலவே அவுட்சோர்ஸரும் செய்வார் என்று நினைக்கிறார்கள். அவர்களின் தூண்டுதல்கள் வேறுபட்டவை என்றாலும். அவுட்சோர்சிங்கில் விசித்திரமான தொழில்நுட்ப தீர்வுகள் மற்றும் விசித்திரமான அல்காரிதம் தீர்வுகள் உள்ளன.
எடுத்துக்காட்டாக, நாங்கள் எதிர்பாராத பல்வேறு இடங்களில் Sphinx சேவையைக் கொண்டிருந்தோம். நான் என்ன செய்ய வேண்டும் என்று பிறகு சொல்கிறேன்.
அவுட்சோர்ஸர்களுக்கு சுயமாக எழுதப்பட்ட கட்டமைப்புகள் உள்ளன. இது முந்தைய ப்ராஜெக்டில் இருந்து நகல்-பேஸ்ட் செய்யப்பட்ட வெறும் PHP ஆகும், அங்கு நீங்கள் எல்லா வகையான விஷயங்களையும் காணலாம். சில கோப்பில் பல வரிகளை மாற்ற சில சிக்கலான பாஷ் ஸ்கிரிப்ட்களைப் பயன்படுத்த வேண்டியிருக்கும் போது, வரிசைப்படுத்தல் ஸ்கிரிப்ட்கள் ஒரு பெரிய குறைபாடு ஆகும், மேலும் இந்த வரிசைப்படுத்தல் ஸ்கிரிப்ட்கள் சில மூன்றாம் ஸ்கிரிப்ட் மூலம் அழைக்கப்படுகின்றன. இதன் விளைவாக, நீங்கள் வரிசைப்படுத்தல் அமைப்பை மாற்றுகிறீர்கள், வேறு ஏதாவது ஒன்றைத் தேர்வு செய்கிறீர்கள், ஹாப், ஆனால் உங்கள் சேவை வேலை செய்யாது. ஏனென்றால் வெவ்வேறு கோப்புறைகளுக்கு இடையில் மேலும் 8 இணைப்புகளை வைக்க வேண்டியிருந்தது. அல்லது ஆயிரம் பதிவுகள் வேலை செய்யும், ஆனால் நூறு ஆயிரம் இனி வேலை செய்யாது.
நான் தொடர்ந்து கேப்டனாக இருப்பேன். அவுட்சோர்ஸ் சேவையை ஏற்றுக்கொள்வது ஒரு கட்டாய நடைமுறை. யாரேனும் அவுட்சோர்ஸ் சேவை வந்து எங்கும் ஏற்றுக்கொள்ளப்படவில்லையா? இது ஒரு அனாதை சேவையாக பிரபலமாக இல்லை, ஆனால் இன்னும்.
சேவை சரிபார்க்கப்பட வேண்டும், சேவையை மதிப்பாய்வு செய்ய வேண்டும், கடவுச்சொற்களை மாற்ற வேண்டும். அவர்கள் எங்களுக்கு ஒரு சேவையை வழங்கியபோது எங்களுக்கு ஒரு வழக்கு இருந்தது, "உள்நுழைந்தால் == 'நிர்வாகம்' && கடவுச்சொல் == 'நிர்வாகம்'..." என்ற நிர்வாகி குழு உள்ளது, அது குறியீட்டில் சரியாக எழுதப்பட்டுள்ளது. நாங்கள் உட்கார்ந்து சிந்திக்கிறோம், மக்கள் இதை 2018 இல் எழுதுகிறார்கள்?
சேமிப்பு திறனை சோதிப்பதும் அவசியமான ஒன்று. இந்தச் சேவையை எங்காவது தயாரிப்பதற்கு முன்பே, நூறு ஆயிரம் பதிவுகளில் என்ன நடக்கும் என்பதை நீங்கள் பார்க்க வேண்டும்.
முன்னேற்றத்திற்காக ஒரு சேவையை அனுப்புவதில் அவமானம் இருக்கக்கூடாது. நீங்கள் கூறும்போது: "நாங்கள் இந்த சேவையை ஏற்க மாட்டோம், எங்களிடம் 20 பணிகள் உள்ளன, அவற்றைச் செய்யுங்கள், பின்னர் நாங்கள் ஏற்றுக்கொள்வோம்," இது சாதாரணமானது. நீங்கள் ஒரு மேலாளரை அமைப்பதாலோ அல்லது வணிகம் பணத்தை வீணடிப்பதாலோ உங்கள் மனசாட்சி புண்படக்கூடாது. வியாபாரத்தில் அதிக செலவு ஏற்படும்.
ஒரு பைலட் திட்டத்தை அவுட்சோர்ஸ் செய்ய முடிவு செய்தபோது எங்களுக்கு ஒரு வழக்கு இருந்தது.
இது சரியான நேரத்தில் வழங்கப்பட்டது, இது மட்டுமே தர அளவுகோலாகும். அதனால்தான் நாங்கள் மற்றொரு பைலட் திட்டத்தை உருவாக்கினோம், அது உண்மையில் ஒரு பைலட் கூட இல்லை. இந்த சேவைகள் ஏற்றுக்கொள்ளப்பட்டன, மேலும் நிர்வாக வழிமுறைகள் மூலம், இதோ உங்கள் குறியீடு, இதோ குழு, இதோ உங்கள் மேலாளர் என்று சொன்னார்கள். சேவைகள் ஏற்கனவே லாபம் ஈட்டத் தொடங்கியுள்ளன. அதே நேரத்தில், உண்மையில், அவர்கள் இன்னும் அனாதைகளாக இருக்கிறார்கள், அவர்கள் எப்படி வேலை செய்கிறார்கள் என்பது யாருக்கும் புரியவில்லை, மேலாளர்கள் தங்கள் பணிகளை நிராகரிக்க தங்களால் முடிந்த அனைத்தையும் செய்கிறார்கள்.
மற்றொரு சிறந்த கருத்து உள்ளது - கொரில்லா வளர்ச்சி. சில துறைகள், பொதுவாக மார்க்கெட்டிங் துறை, ஒரு கருதுகோளைச் சோதிக்க விரும்பி, முழு சேவையையும் அவுட்சோர்ஸ் செய்ய வேண்டும். போக்குவரத்து அதில் கொட்டத் தொடங்குகிறது, அவர்கள் ஆவணங்களை மூடி, ஒப்பந்தக்காரருடன் ஆவணங்களில் கையொப்பமிட்டு, செயல்பாட்டுக்கு வந்து கூறுகிறார்கள்: "நண்பர்களே, எங்களிடம் ஒரு சேவை உள்ளது, அதில் ஏற்கனவே போக்குவரத்து உள்ளது, அது எங்களுக்கு பணத்தைக் கொண்டுவருகிறது, அதை ஏற்றுக்கொள்வோம்." நாங்கள், "அப்பா, அது எப்படி இருக்கும்" என்று இருந்தோம்.
அனாதை சேவையைப் பெறுவதற்கான மற்றொரு வழி: சில குழு திடீரென ஏற்றப்பட்டதைக் கண்டால், நிர்வாகம் கூறுகிறது: "இந்த அணியின் சேவையை மற்றொரு குழுவிற்கு மாற்றுவோம், அதில் சிறிய சுமை உள்ளது." பின்னர் நாங்கள் அதை மூன்றாவது அணிக்கு மாற்றி மேலாளரை மாற்றுவோம். இறுதியில் எங்களுக்கு மீண்டும் ஒரு அனாதை உள்ளது.
அனாதைகளுக்கு என்ன பிரச்சனை?
யாருக்குத் தெரியாது, இது ஸ்வீடனில் எழுப்பப்பட்ட வாசா போர்க்கப்பல், ஏவப்பட்ட 5 நிமிடங்களுக்குப் பிறகு மூழ்கியது. ஸ்வீடன் மன்னர், இதற்காக யாரையும் தூக்கிலிடவில்லை. அத்தகைய கப்பல்களை எவ்வாறு உருவாக்குவது என்று தெரியாத இரண்டு தலைமுறை பொறியாளர்களால் இது கட்டப்பட்டது. இயற்கை விளைவு.
எடுத்துக்காட்டாக, ராஜா ஏற்கனவே எங்காவது ஒரு புயலில் சவாரி செய்து கொண்டிருந்தபோது, கப்பல் மிகவும் மோசமான வழியில் மூழ்கியிருக்கலாம். எனவே, அவர் உடனடியாக மூழ்கிவிட்டார், அஜிலின் கூற்றுப்படி, ஆரம்பத்தில் தோல்வியடைவது நல்லது.
நாம் ஆரம்பத்தில் தோல்வியுற்றால், பொதுவாக எந்த பிரச்சனையும் இல்லை. எடுத்துக்காட்டாக, ஏற்றுக்கொள்ளும் போது அது மறுபரிசீலனைக்கு அனுப்பப்பட்டது. ஆனால் நாம் ஏற்கனவே உற்பத்தியில் தோல்வியடைந்தால், பணத்தை முதலீடு செய்யும் போது, சிக்கல்கள் இருக்கலாம். விளைவுகள், அவை வணிகத்தில் அழைக்கப்படுகின்றன.
அனாதை சேவைகள் ஏன் ஆபத்தானவை:
- சேவை திடீரென உடைந்து போகலாம்.
- சேவை பழுதுபார்க்க நீண்ட நேரம் எடுக்கும் அல்லது பழுதுபார்க்கப்படவில்லை.
- பாதுகாப்பு பிரச்சனைகள்.
- மேம்பாடுகள் மற்றும் புதுப்பிப்புகளில் சிக்கல்கள்.
- ஒரு முக்கியமான சேவை செயலிழந்தால், நிறுவனத்தின் நற்பெயர் பாதிக்கப்படுகிறது.
அனாதை சேவைகளை என்ன செய்வது?
என்ன செய்ய வேண்டும் என்பதை மீண்டும் சொல்கிறேன். முதலில், ஆவணங்கள் இருக்க வேண்டும். 7 ஆண்டுகள் Banki.ru இல் சோதனையாளர்கள் டெவலப்பர்களின் வார்த்தையை எடுக்கக்கூடாது, செயல்பாடுகள் அனைவரின் வார்த்தையையும் எடுக்கக்கூடாது என்று எனக்குக் கற்றுக் கொடுத்தது. நாம் சரிபார்க்க வேண்டும்.
இரண்டாவதாக, தொடர்பு வரைபடங்களை எழுதுவது அவசியம், ஏனென்றால் அதிக வரவேற்பைப் பெறாத சேவைகள் யாரும் சொல்லாத சார்புகளைக் கொண்டிருக்கின்றன. எடுத்துக்காட்டாக, டெவலப்பர்கள் தங்கள் சில Yandex.Maps அல்லது Dadata விசையில் சேவையை நிறுவியுள்ளனர். நீங்கள் இலவச வரம்பை முடித்துவிட்டீர்கள், அனைத்தும் உடைந்துவிட்டன, என்ன நடந்தது என்று உங்களுக்குத் தெரியாது. அத்தகைய அனைத்து ரேக்குகளும் விவரிக்கப்பட வேண்டும்: சேவையானது தாடாட்டா, எஸ்எம்எஸ், வேறு ஏதாவது ஒன்றைப் பயன்படுத்துகிறது.
மூன்றாவதாக, தொழில்நுட்ப கடனுடன் பணிபுரிதல். நீங்கள் சில வகையான ஊன்றுகோல்களைச் செய்யும்போது அல்லது ஒரு சேவையை ஏற்றுக்கொண்டு ஏதாவது செய்ய வேண்டும் என்று கூறும்போது, அது முடிந்ததா என்பதை உறுதிப்படுத்திக் கொள்ள வேண்டும். ஏனென்றால், சிறிய துளை அவ்வளவு சிறியதல்ல, நீங்கள் அதன் வழியாக விழுவீர்கள்.
கட்டடக்கலைப் பணிகளுடன், ஸ்பிங்க்ஸைப் பற்றிய ஒரு கதை எங்களிடம் இருந்தது. சேவைகளில் ஒன்று பட்டியல்களை உள்ளிட Sphinx ஐப் பயன்படுத்தியது. ஒரு பக்கப் பட்டியல், ஆனால் அது ஒவ்வொரு இரவும் மீண்டும் அட்டவணைப்படுத்தப்பட்டது. இது இரண்டு குறியீடுகளிலிருந்து கூடியது: ஒரு பெரிய ஒன்று ஒவ்வொரு இரவும் குறியிடப்பட்டது, மேலும் அதில் ஒரு சிறிய குறியீடு திருகப்பட்டது. ஒவ்வொரு நாளும், 50% நிகழ்தகவு குண்டுவீச்சு அல்லது இல்லாவிட்டாலும், கணக்கீட்டின் போது குறியீடு செயலிழந்தது, மேலும் எங்கள் செய்திகள் பிரதான பக்கத்தில் புதுப்பிப்பதை நிறுத்தியது. முதலில் குறியீட்டு எண் மீண்டும் அட்டவணைப்படுத்த 5 நிமிடங்கள் ஆனது, பின்னர் குறியீட்டெண் வளர்ந்தது, ஒரு கட்டத்தில் மீண்டும் குறியீட்டுக்கு 40 நிமிடங்கள் எடுக்கத் தொடங்கியது. இதைத் துண்டித்தபோது, நாங்கள் நிம்மதிப் பெருமூச்சு விட்டோம், ஏனென்றால் இன்னும் சிறிது நேரம் கடந்து, எங்கள் குறியீட்டு முழு நேரமும் மீண்டும் அட்டவணைப்படுத்தப்படும் என்பது தெளிவாகத் தெரிந்தது. இது எங்கள் போர்ட்டலுக்கு தோல்வியடையும், எட்டு மணிநேரத்திற்கு எந்த செய்தியும் இல்லை - அவ்வளவுதான், வணிகம் நிறுத்தப்பட்டது.
அனாதை சேவையுடன் பணிபுரியும் திட்டம்
உண்மையில், இதைச் செய்வது மிகவும் கடினம், ஏனென்றால் டெவொப்ஸ் என்பது தகவல்தொடர்பு பற்றியது. உங்கள் சகாக்களுடன் நீங்கள் நல்ல உறவில் இருக்க விரும்புகிறீர்கள், மேலும் உங்கள் சகாக்கள் மற்றும் மேலாளர்களை விதிமுறைகளால் தலையில் அடிக்கும்போது, அவர்கள் இதைச் செய்பவர்களிடம் முரண்பட்ட உணர்வுகளைக் கொண்டிருக்கலாம்.
இந்த எல்லா புள்ளிகளுக்கும் கூடுதலாக, மற்றொரு முக்கியமான விஷயம் உள்ளது: குறிப்பிட்ட நபர்கள் ஒவ்வொரு குறிப்பிட்ட சேவைக்கும், வரிசைப்படுத்தல் நடைமுறையின் ஒவ்வொரு குறிப்பிட்ட பகுதிக்கும் பொறுப்பாக இருக்க வேண்டும். ஆட்கள் இல்லாதபோது, இந்த விஷயத்தை முழுவதுமாகப் படிக்க வேறு சிலரை ஈர்க்க வேண்டியிருக்கும் போது, அது கடினமாகிவிடும்.
இவை அனைத்தும் உதவவில்லை என்றால், உங்கள் அனாதை சேவை இன்னும் அனாதையாக இருந்தால், யாரும் அதை எடுக்க விரும்பவில்லை, ஆவணங்கள் எழுதப்படவில்லை, இந்த சேவையில் அழைக்கப்பட்ட குழு எதையும் செய்ய மறுக்கிறது, ஒரு எளிய வழி உள்ளது - மீண்டும் செய்ய எல்லாம் .
அதாவது, சேவைக்கான தேவைகளை புதிதாக எடுத்துக்கொண்டு, புதிய சேவையை, சிறப்பாக, சிறந்த தளத்தில், விசித்திரமான தொழில்நுட்ப தீர்வுகள் இல்லாமல் எழுதுகிறீர்கள். நீங்கள் போரில் அதற்கு இடம்பெயர்கிறீர்கள்.
நாங்கள் Yii 1 இல் ஒரு சேவையை எடுத்தபோது, அதை மேலும் மேம்படுத்த முடியாது என்பதை உணர்ந்தோம், ஏனெனில் Yii 1 இல் நன்றாக எழுதக்கூடிய டெவலப்பர்கள் எங்களிடம் இல்லை. எல்லா டெவலப்பர்களும் Symfony XNUMX இல் நன்றாக எழுதுகிறார்கள். என்ன செய்ய? நாங்கள் நேரத்தை ஒதுக்கினோம், ஒரு குழுவை ஒதுக்கினோம், ஒரு மேலாளரை ஒதுக்கினோம், திட்டத்தை மீண்டும் எழுதினோம் மற்றும் அதற்கு போக்குவரத்தை சீராக மாற்றினோம்.
இதற்குப் பிறகு, பழைய சேவையை நீக்கலாம். உள்ளமைவு மேலாண்மை அமைப்பிலிருந்து சில சேவைகளை எடுத்து சுத்தம் செய்ய வேண்டியிருக்கும் போது இது எனக்கு மிகவும் பிடித்த செயல்முறையாகும். களஞ்சியம் Git இல் உள்ளது.
இதைப் பற்றி நான் பேச விரும்பினேன், விவாதிக்க நான் தயாராக இருக்கிறேன், தலைப்பு ஹோலிவர், பலர் அதில் நீந்தியுள்ளனர்.
நீங்கள் மொழிகளை ஒருங்கிணைத்தீர்கள் என்று ஸ்லைடுகள் கூறுகின்றன. ஒரு உதாரணம் படங்களின் மறுஅளவை. அதை ஒரு மொழிக்கு கண்டிப்பாக கட்டுப்படுத்துவது உண்மையில் அவசியமா? ஏனெனில் PHP இல் படத்தின் மறுஅளவை, உண்மையில் கோலாங்கில் செய்ய முடியும்.
உண்மையில், இது எல்லா நடைமுறைகளையும் போலவே விருப்பமானது. ஒருவேளை, சில சந்தர்ப்பங்களில், அது கூட விரும்பத்தகாதது. ஆனால் 50 பேர் கொண்ட நிறுவனத்தில் டெக்னிக்கல் துறை இருந்தால், அவர்களில் 45 பேர் PHP நிபுணர்கள், மேலும் 3 பேர் பைதான், அன்சிபிள், பப்பட் போன்றவற்றை அறிந்த டெவொப்கள், அவர்களில் ஒருவர் மட்டுமே சிலவற்றில் எழுதுகிறார் என்பதை நீங்கள் புரிந்து கொள்ள வேண்டும். ஒரு வகையான மொழி. சில Go படத்தின் அளவை மாற்றும் சேவை, பின்னர் அது வெளியேறும் போது, நிபுணத்துவம் அதனுடன் செல்கிறது. அதே நேரத்தில், இந்த மொழியை அறிந்த ஒரு சந்தை-குறிப்பிட்ட டெவலப்பரை நீங்கள் தேட வேண்டும், குறிப்பாக இது அரிதாக இருந்தால். அதாவது, நிறுவனக் கண்ணோட்டத்தில், இது சிக்கலானது. டெவொப்ஸ் பார்வையில், நீங்கள் சேவைகளை வரிசைப்படுத்தப் பயன்படுத்தும் சில ஆயத்தமான பிளேபுக்குகளை குளோன் செய்ய வேண்டியதில்லை, ஆனால் நீங்கள் அவற்றை மீண்டும் எழுத வேண்டும்.
நாங்கள் தற்போது Node.js இல் ஒரு சேவையை உருவாக்கி வருகிறோம், மேலும் இது ஒவ்வொரு டெவலப்பருக்கும் தனி மொழியுடன் அருகிலுள்ள ஒரு தளமாக இருக்கும். ஆனால் நாங்கள் உட்கார்ந்து, விளையாட்டு மெழுகுவர்த்திக்கு மதிப்புள்ளது என்று நினைத்தோம். அதாவது, நீங்கள் உட்கார்ந்து சிந்திக்க வேண்டிய கேள்வி இது.
உங்கள் சேவைகளை எவ்வாறு கண்காணிக்கிறீர்கள்? பதிவுகளை எவ்வாறு சேகரித்து கண்காணிப்பது?
எலாஸ்டிக் தேடலில் பதிவுகளைச் சேகரித்து கிபானாவில் வைக்கிறோம், அது உற்பத்தியா அல்லது சோதனைச் சூழலா என்பதைப் பொறுத்து, வெவ்வேறு சேகரிப்பான்கள் அங்கு பயன்படுத்தப்படுகின்றன. எங்கோ லம்பர்ஜாக், வேறு எங்கோ, எனக்கு நினைவில் இல்லை. சில சேவைகளில் இன்னும் சில இடங்களில் டெலிகிராஃப் நிறுவி, வேறு எங்காவது தனித்தனியாக படமெடுக்கிறோம்.
ஒரே சூழலில் பப்பட் மற்றும் அன்சிபிள் உடன் வாழ்வது எப்படி?
உண்மையில், இப்போது இரண்டு சூழல்கள் உள்ளன, ஒன்று பப்பட், மற்றொன்று அன்சிபிள். அவற்றை கலப்பினமாக்கும் பணியில் ஈடுபட்டுள்ளோம். அன்சிபிள் ஆரம்ப அமைப்பிற்கான ஒரு நல்ல கட்டமைப்பாகும், பப்பட் ஆரம்ப அமைப்பிற்கான ஒரு மோசமான கட்டமைப்பாகும், ஏனெனில் அதற்கு நேரடியாக மேடையில் வேலை செய்ய வேண்டும், மேலும் பப்பட் உள்ளமைவு ஒருங்கிணைப்பை உறுதி செய்கிறது. இதன் பொருள், இயங்குதளம் புதுப்பித்த நிலையில் தன்னைப் பராமரித்து வருகிறது, மேலும் இணைக்கப்பட்ட இயந்திரம் புதுப்பித்த நிலையில் இருக்க, நீங்கள் பிளேபுக்குகளை சில அதிர்வெண்களுடன் எப்போதும் இயக்க வேண்டும். அதுதான் வித்தியாசம்.
நீங்கள் எவ்வாறு இணக்கத்தை பராமரிக்கிறீர்கள்? உங்களிடம் அன்சிபிள் மற்றும் பப்பட் இரண்டிலும் கட்டமைப்புகள் உள்ளதா?
இது எங்கள் பெரிய வலி, நாங்கள் எங்கள் கைகளுடன் இணக்கத்தை பராமரிக்கிறோம், இப்போது எங்காவது இதிலிருந்து எப்படி முன்னேறுவது என்று யோசிக்கிறோம். பப்பட் தொகுப்புகளை வெளியிடுகிறது மற்றும் சில இணைப்புகளை பராமரிக்கிறது மற்றும் அன்சிபிள், எடுத்துக்காட்டாக, குறியீட்டை வெளியிடுகிறது மற்றும் சமீபத்திய பயன்பாட்டு கட்டமைப்புகளை சரிசெய்கிறது.
விளக்கக்காட்சி ரூபியின் வெவ்வேறு பதிப்புகளைப் பற்றியது. என்ன தீர்வு?
இதை நாங்கள் ஒரே இடத்தில் சந்தித்தோம், அதை எப்போதும் நம் தலையில் வைத்திருக்க வேண்டும். விண்ணப்பங்களுடன் பொருந்தாத ரூபியில் இயங்கும் பகுதியை வெறுமனே அணைத்து தனியாக வைத்திருந்தோம்.
இந்த ஆண்டு மாநாடு டெக்னோபோலிஸில் டிசம்பர் 7 ஆம் தேதி நடைபெறும். நவம்பர் 11 வரை அறிக்கைகளுக்கான விண்ணப்பங்களை ஏற்றுக்கொள்கிறோம். நீங்கள் பேச விரும்பினால் எங்களை.
பங்கேற்பாளர்களுக்கான பதிவு திறக்கப்பட்டுள்ளது, எங்களுடன் சேருங்கள்!
ஆதாரம்: www.habr.com