யாரையும் காத்திருக்க வைக்காமல் பெரிய பணியிடங்களுக்கு மாறுதல்

ஒவ்வொரு Mythex திட்டத்திற்கும் ஒரு தனிப்பட்ட பணியிடம் கிடைக்கும்: முகவர் குறியீட்டை எழுதும், உங்கள் ஆப்பின் முன்னோட்டம் இயங்கும் ஒரு சிறிய கிளவுட் கணினி. புதிய பணியிடங்களின் நினைவகத்தை 1 GB-இலிருந்து 2 GB-க்கு உயர்த்தியிருந்தோம்; ஆனால் பழையவை 1 GB-இலேயே இருந்தன — நாங்கள் சரிபார்த்த நாளில், அவற்றில் கால் பகுதி. எங்கள் முதல் திருத்தம், ஒரு திட்டம் அடுத்த முறை திறக்கப்படும்போது ஒரு பெரிய பணியிடத்திற்கு நகர்த்தியது. உற்பத்தியில் அதன் முதல் நாளிலேயே, அது ஒருவரை ஏழு நிமிடங்கள் காத்திருக்க வைத்தது. அதற்கு ஒரு கடுமையான நேர வரம்பு வைத்தோம், பின்னர் திட்டத்தைத் திறப்பதிலிருந்தே அந்த நகர்வை அகற்றினோம்.

பழைய பணியிடங்கள் ஏன் சிறியவையாக இருந்தன

எங்கள் sandbox வழங்குநர் ஒரு பணியிடத்தின் அளவை அது உருவாக்கப்படும்போதே அமைக்கிறார்; ஒவ்வொரு இடைநிறுத்தம் மற்றும் மீண்டும் தொடக்கத்தின் வழியாகவும் அதைத் தக்கவைக்கிறார். டெம்ப்ளேட்டை — புதிய பணியிடங்கள் கட்டப்படும் செய்முறையை — மாற்றினால், அது மாற்றத்திற்குப் பின் உருவாக்கப்பட்ட பணியிடங்களுக்கு மட்டுமே பொருந்தும். ஏற்கனவே இருக்கும் பணியிடங்களின் அளவை எதுவும் மாற்றாது.

அது முக்கியமாக இருந்தது. சிறிய பணியிடங்களில் ஒன்று, அதன் முன்னோட்டம் தொடங்கிக்கொண்டிருந்தபோது git push நேரத்தில் நினைவகம் தீர்ந்து 11 நிமிடங்களுக்குப் பதிலளிக்காமல் நின்றது. அதனால் ஒரு வெளியீடு தோல்வியடைந்தது.

முதல் முயற்சி: எழுந்திருக்கும்போது திட்டத்தை நகர்த்துவது

பணியிடங்கள் யாரும் பயன்படுத்தாதபோது இடைநிறுத்தப்படுகின்றன, திட்டம் திறக்கப்படும்போது விழித்தெழுகின்றன. விழிப்பதே திட்டத்தை நகர்த்த சரியான தருணமாகத் தோன்றியது, ஏனெனில் அதில் இன்னும் யாரும் வேலை செய்யவில்லை.

நகர்வு இவ்வாறு வேலை செய்தது:

1. அளவைச் சரிபார்க்கவும். பணியிடம் 2 GB-க்குக் குறைவாக இருந்தால், நகர்த்துங்கள். அதன் அளவு தெரியாவிட்டால், எதுவும் செய்யாதீர்கள்.
2. வெளியீட்டைத் தொந்தரவு செய்யாதீர்கள். வெளியீடு பணியிடத்தின் கோப்புகளைப் படிக்கும்; அதனால் ஒன்று இயங்கிக்கொண்டிருந்தால், நகர்வைத் தவிர்க்கவும்.
3. திட்டத்தைத் தொகுக்கவும். திட்டத்திலுள்ள அனைத்தையும் archive செய்யவும் — அதன் git வரலாறும் உட்பட, அதாவது அந்தத் திட்டத்திற்கு இருக்கும் ஒவ்வொரு checkpoint-உம், மற்றும் உரிமையாளருக்குச் சொந்தமான ஆப்பின் .env கோப்பும். ஆனால் நிறுவப்பட்ட dependencies (node_modules) விட்டுவிடவும்; அவற்றை மீண்டும் நிறுவ முடியும்.
4. நேரடியாகக் குறுக்கே நகலெடுக்கவும். பழைய பணியிடத்திலிருந்து புதிய 2 GB ஒன்றுக்கு archive-ஐ ஸ்ட்ரீம் செய்யவும்; அதனால் அது எங்கள் சொந்த சர்வரின் நினைவகத்தில் ஒருபோதும் பொருந்த வேண்டியதில்லை.
5. மாறுவதற்கு முன் ஒப்பிடவும். இரண்டு பணியிடங்களிலும் கோப்புகளின் எண்ணிக்கையை எண்ணவும், சமீபத்திய checkpoint-ஐப் படிக்கவும், checkpoint-களின் எண்ணிக்கையை எண்ணவும். மூன்றும் பொருந்தினால் மட்டுமே மாறவும்.
6. எந்தத் தோல்விக்கும் பழையதை வைத்திருங்கள். எந்தப் பிழை அல்லது பொருந்தாமை வந்தாலும், புதிய பணியிடம் நிராகரிக்கப்படும்; திட்டம் முன்புபோலவே பழைய பணியிடத்தில் திறக்கும்.

ஒப்பீட்டில் ஒரு விவரம் நினைத்ததைவிட முக்கியமாக இருந்தது. அந்தச் சரிபார்ப்பு நிர்வாக கணக்காக இயங்குகிறது, மேலும் வேறு பயனருக்குச் சொந்தமான repository-ஐ git படிக்க மறுக்கும். இரண்டு பக்கங்களிலும் அது எதையும் அச்சிடவில்லை — “எதுவும் இல்லை” என்பது “எதுவும் இல்லை”யுடன் பொருந்தியது, அதனால் எந்த வரலாற்றையும் ஒப்பிடாமலேயே சரிபார்ப்பு வென்றது. அந்த directory-ஐ நம்புமாறு git-க்குச் சொன்னோம், அது மீண்டும் நிகழாமல் இருக்க ஒரு சோதனையையும் சேர்த்தோம்.

முதல் நாளில் என்ன தவறானது

உற்பத்தியில் அதன் முதல் நாளில், ஒரு திட்டத்தைத் தொகுத்தபோது, விழிப்பின் உள்ளேயே ஐந்து நிமிட கட்டளை நேர வரம்பை எட்டியது. உரிமையாளர் தனது பணியிடம் திறக்கக் காத்திருந்தது ஏழு நிமிடங்கள். நகர்வு தோல்வியடைந்ததால், திட்டம் இன்னும் சிறியதாகவே இருந்தது; அடுத்த முறை திறக்கும்போது அது மீண்டும் முயன்று அவர்களை மீண்டும் காத்திருக்க வைத்திருக்கும்.

ஒருவர் தனது சொந்தத் திட்டத்தைத் திறக்கும்போது அவரைக் காத்திருக்க வைக்கும் மைக்ரேஷன் ஒரு மோசமான பரிமாற்றம். விழிப்பில் அதை இயக்குவதன் முழுப் புள்ளியே யாரும் கவனிக்காமல் இருக்க வேண்டும் என்பதுதான்.

இரண்டாவது முயற்சி: கடுமையான பட்ஜெட்

அதே நாளில் நான்கு விஷயங்களை மாற்றினோம்:

• முழு நகர்வுக்கும் ஒரு நிமிடம். ஒவ்வொரு படியும் — அளவைச் சரிபார்த்தல், தொகுத்தல், புதிய பணியிடம் உருவாக்குதல், நகலெடுத்தல், பிரித்தெடுத்தல், ஒப்பிடுதல் — ஒரே 60 வினாடி பட்ஜெட்டைப் பகிர்ந்துகொள்கின்றன. அது தீர்ந்ததும், திட்டம் பழைய பணியிடத்தில் திறக்கும்.
• வேலையை நிறுத்துங்கள், காத்திருப்பை மட்டும் அல்ல. நம் பக்கத்தில் கைவிடுவது போதாது, உரிமையாளர் பயன்படுத்தப்போகும் பணியிடத்திற்குள் archive செய்தல் இன்னும் ஓடிக்கொண்டிருந்தால். ஒவ்வொரு archive கட்டளையும் இப்போது பட்ஜெட் முடிவதற்குச் சற்று முன் பணியிடத்திற்குள்ளேயே கொல்லப்படுகிறது. புதிய பணியிடம் நாங்கள் கைவிட்ட பிறகு வந்தால், அது நிராகரிக்கப்படும்.
• உரிமையாளரைச் சுத்தம் செய்வதற்காகக் காத்திருக்க வைக்காதீர்கள். தற்காலிக archive-ஐ நீக்குவது இப்போது பின்னணியில் நடக்கிறது.
• ஒவ்வொரு திறப்பிலும் மீண்டும் முயற்சிக்காதீர்கள். நகர்த்த முடியாத ஒரு திட்டம் 24 மணி நேரம் தனியாக விடப்படுகிறது; அதனால் ஒரு தோல்வி ஒரு நாளைக்கு அதிகபட்சம் ஒரு தாமதத்தைத் தருகிறது, ஒவ்வொரு திறப்புக்கும் ஒன்று அல்ல.

மூன்றாவது முயற்சி: விழிப்பிலிருந்தே நீக்குவது

அது மோசமான நிலையை ஒரு நிமிடமாகக் குறைத்தது. ஆனால் ஒரு நிமிடமும் ஒரு நிமிடமே, மேலும் அந்த நகர்வுக்கு யாருடைய பாதையிலும் இடம் தேவையில்லை என்பதை உணர்ந்தோம்.

இப்போது 1 GB-இல் எந்தப் பணியிடமும் உருவாக்கப்படுவதில்லை. அதனால் இது தொடர்ச்சியான செயல்முறை அல்ல; நிலையான பணியிடப் பட்டியலைக் கொண்ட ஒரு முறை வேலை. அதை விழிப்புக்குள் வைத்திருந்ததால், ஒவ்வொரு மெதுவான நகர்வையும் ஒரு உண்மையான மனிதர் செலுத்தினார்; ஒரு பணியிடம் நகராது என்பதை அறிந்த ஒரே வழி, ஒருவர் அதற்காகக் காத்திருந்ததுதான்.

அதனால் விழிப்பிலிருந்து நகர்வையே முழுவதுமாக அகற்றினோம். ஒரு திட்டத்தைத் திறப்பது முன்புபோலவே செய்கிறது. எஞ்சியுள்ள சிறிய பணியிடங்கள் ஒரு மேற்பார்வையிடப்பட்ட தொகுப்பாகக் கையாளப்படுகின்றன: யாரும் அதற்காகக் காத்திருக்கவில்லை, நகராத பணியிடம் தொகுப்பின் அறிக்கையில் தோன்றும்; அங்கே நாங்கள் அதைப் பார்க்கலாம், அதன் உரிமையாளருக்கு முன்னால் அல்ல.

இதிலிருந்து நாங்கள் கற்றது

• அளவை மாற்றுவது எப்போதும் சாத்தியமல்ல. ஒரு தளம் உருவாக்கத்தின்போது அளவை நிலைநிறுத்தினால், இயல்புநிலையை உயர்த்துவது புதியவற்றுக்கு மட்டுமே உதவும். பழையவற்றுக்குத் திட்டமிடுங்கள்.
• “இன்னும் யாரும் பயன்படுத்தவில்லை” என்பது இன்னும் யாரோ காத்திருக்கிறார்கள் என்றுதான் பொருள். ஒரு தயாரிப்புக்குள் நுழையும் வழியில் செய்யும் வேலையை ஒரு மனிதர் கவனிக்கிறார்.
• பயனரின் பாதையில் உள்ள எதற்கும் ஒரு பட்ஜெட் வையுங்கள், பட்ஜெட் தீர்ந்ததும் வேலையை நிறுத்துங்கள். நம் பக்கத்தில் நேரம் முடிந்தாலும் வேறெங்கோ ஒரு கட்டளை ஓடிக்கொண்டிருந்தால், பிரச்சினை வேறு இடத்திற்கு நகர்கிறது.
• ஒரு முறை மைக்ரேஷன் ஒரு முறை வேலையில் இருக்க வேண்டும். அதை அன்றாடச் செயல்களுக்குள் மறைத்து வைப்பது எழுதுவதை மலிவாக்குகிறது, ஆனால் இயக்குவதை விலையுயர்ந்ததாக்குகிறது.
• உங்கள் பாதுகாப்புச் சோதனைகளைச் சோதியுங்கள். எதையும் ஒப்பிடாத ஒப்பீடு, வெற்றி பெற்ற ஒப்பீடு போலவே தோன்றும்.

நீங்கள் Mythex-இல் கட்டினால், எதுவும் செய்ய வேண்டியதில்லை: நோக்கம் நினைவகம் தீர்ந்துபோகும் பணியிடங்களைக் குறைப்பதே, திட்டத்தைத் திறப்பது முன்பைப் போலவே வேகமாக இருக்கும். பணியிடங்கள் எப்படி இடைநிறுத்தப்பட்டு விழிக்கின்றன என்பது தனிப்பட்ட பணியிடம் ஆவணங்களில் உள்ளது. இன்னொரு நினைவகத் தீர்ந்துபோகும் கதைக்கு, ஒரு முன்னேற்றக் குறியீட்டில் மறைந்திருந்த நினைவக கசிவு பார்க்கவும்.