குறிப்பு. மொழிபெயர்: AWS - Adrian Hornsby இலிருந்து மூத்த தொழில்நுட்ப சுவிசேஷகரின் அற்புதமான உள்ளடக்கத்தின் மொழிபெயர்ப்பைப் பகிர்வதில் நாங்கள் மகிழ்ச்சியடைகிறோம். எளிமையான சொற்களில், IT அமைப்புகளில் ஏற்படும் தோல்விகளின் விளைவுகளைத் தணிக்க பரிசோதனையின் முக்கியத்துவத்தை அவர் விளக்குகிறார். கேயாஸ் குரங்கு பற்றி நீங்கள் ஏற்கனவே கேள்விப்பட்டிருக்கிறீர்களா (அல்லது இதே போன்ற தீர்வுகளைப் பயன்படுத்தியிருக்கலாம்)? இன்று, அத்தகைய கருவிகளை உருவாக்குவதற்கான அணுகுமுறைகள் மற்றும் அவற்றை ஒரு பரந்த சூழலில் செயல்படுத்துவது கேயாஸ் இன்ஜினியரிங் எனப்படும் செயல்பாட்டின் கட்டமைப்பிற்குள் மேற்கொள்ளப்படுகிறது. இந்த கட்டுரையில் அதைப் பற்றி மேலும் படிக்கவும்.
"ஆனால் இந்த அழகுக்கு பின்னால் குழப்பமும் பைத்தியக்காரத்தனமும் உள்ளது." - டேனர் வால்லிங்
தீயணைப்பு வீரர்கள். இந்த உயர் பயிற்சி பெற்ற வல்லுநர்கள் ஒவ்வொரு நாளும் தங்கள் உயிரைப் பணயம் வைத்து தீயை எதிர்த்துப் போராடுகிறார்கள். தீயணைப்பு வீரராக மாறுவதற்கு முன்பு நீங்கள் குறைந்தது 600 மணிநேரம் பயிற்சியில் செலவிட வேண்டும் என்பது உங்களுக்குத் தெரியுமா? மேலும் இது ஆரம்பம் மட்டுமே. அறிக்கைகளின்படி, தீயணைப்பு வீரர்கள் தங்கள் வேலை நேரத்தில் 80% வரை பயிற்சி செய்கிறார்கள்.
Почему?
ஒரு தீயணைப்பு வீரர் உண்மையான தீயை எதிர்த்துப் போராடும்போது, அவருக்கு பொருத்தமானது தேவை உள்ளுணர்வு. அதை உருவாக்க, நீங்கள் ஒரு மணி நேரத்திற்கு ஒரு மணி நேரம் பயிற்சி செய்ய வேண்டும். அவர்கள் சொல்வது போல், பயிற்சி அதிசயங்களைச் செய்கிறது.
“அவர்கள் நெருப்பின் சாராம்சத்திற்குள் ஊடுருவுவது போல் தெரிகிறது; சுடர்களுக்கு டாக்டர் ஃபில் போன்றது." —
குறிப்பு. மொழிபெயர்: பிலிப் கால்வின் "பில்" மெக்ரா ஒரு அமெரிக்க உளவியலாளர், எழுத்தாளர் மற்றும் பிரபல தொலைக்காட்சி நிகழ்ச்சியான Dr. Phil இன் தொகுப்பாளர் ஆவார், இதில் தொகுப்பாளர் தனது பங்கேற்பாளர்களுக்கு அவர்களின் பிரச்சனைகளுக்கு தீர்வுகளை வழங்குகிறார்.
சியாட்டிலில் ஒருமுறை
2000 களின் முற்பகுதி , அமேசானில் அதிகாரப்பூர்வ பட்டத்துடன் பதவி வகித்தவர் பேரிடர் மாஸ்டர்கேம்டே திட்டத்தை உருவாக்கி வழிநடத்தினார். இது அவரது தீயணைப்பு வீரராக இருந்த அனுபவத்தை அடிப்படையாகக் கொண்டது. கேம்டே என்பது அமேசானின் பல்வேறு அமைப்புகள், மென்பொருள்கள் மற்றும் மக்களைச் சாத்தியமான நெருக்கடியான சூழ்நிலைகளுக்குச் சோதித்து, பயிற்றுவிப்பதற்கும், தயார்படுத்துவதற்கும் நோக்கமாக இருந்தது.
தீயணைப்பு வீரர்கள் தீயை எதிர்த்துப் போராடுவதற்கான உள்ளுணர்வை வளர்த்துக் கொள்வது போல, பெரிய அளவிலான பேரழிவு நிகழ்வுகளைச் சமாளிக்க அவரது குழுவிற்கு உள்ளுணர்வை வளர்க்க உதவ ஜெஸ்ஸி விரும்பினார்.
"கேம்டே: அழிவின் மூலம் பின்னடைவை உருவாக்குதல்" - ஜெஸ்ஸி ராபின்ஸ்
அமேசான் சில்லறை விற்பனை தளத்தின் நிலைத்தன்மையை அதிகரிக்க வடிவமைக்கப்பட்டது, வேண்டுமென்றே சிக்கலான அமைப்புகளில் பிழைகளை அறிமுகப்படுத்துகிறது.
கேம்டே ஒரு பயிற்சி திட்டமிடப்பட்டுள்ளது என்று முழு நிறுவனத்திற்கும் தொடர்ச்சியான அறிவிப்புகளுடன் தொடங்கியது - சில நேரங்களில் மிகப் பெரிய அளவில், எடுத்துக்காட்டாக, முழு தரவு மையத்தையும் மூடுவது. திட்டமிடப்பட்ட செயலிழப்பு பற்றிய குறைந்தபட்ச விவரங்கள் வழங்கப்பட்டன, மேலும் குழு தயார் செய்ய பல மாதங்கள் வழங்கப்பட்டது. உள்ளூர் நெருக்கடியை ஊழியர்கள் சமாளிக்க முடியுமா மற்றும் அதன் விளைவுகளை விரைவாக தீர்க்க முடியுமா என்பதை சோதிப்பதே பயிற்சியின் முக்கிய நோக்கம்.
இந்த பயிற்சிகளின் போது, குறிப்பிட்ட கருவிகள் மற்றும் செயல்முறைகள், கண்காணிப்பு, விழிப்பூட்டல்கள் மற்றும் அவசர அழைப்புகள் போன்றவை, சம்பவ மறுமொழி நடைமுறைகளில் உள்ள பிழைகளை பகுப்பாய்வு செய்து அடையாளம் காண பயன்படுத்தப்பட்டன. அது மாறிவிடும், கேம்டே உன்னதமான கட்டடக்கலை சிக்கல்களை அடையாளம் காண்பதில் சிறந்தது. சில நேரங்களில் "மறைந்த குறைபாடுகள்" என்று அழைக்கப்படுவதைக் கண்டறியவும் முடிந்தது - சம்பவத்தின் பிரத்தியேகங்கள் காரணமாக தங்களை வெளிப்படுத்தும் சிக்கல்கள். எடுத்துக்காட்டாக, மனிதனால் உருவாக்கப்பட்ட சிக்கலால் எதிர்பாராத பக்க விளைவுகளால் மீட்பு செயல்முறைக்கு முக்கியமான சம்பவ மேலாண்மை அமைப்புகள் தோல்வியடைந்தன.
நிறுவனம் வளர்ந்தவுடன், கேம்டேயின் தத்துவார்த்த வெடிப்பு ஆரம் விரிவடைந்தது. இறுதியில், இந்த பயிற்சிகள் கைவிடப்பட்டன, ஏனெனில் திட்டமிட்டபடி விஷயங்கள் நடக்கவில்லை என்றால் நிறுவனத்திற்கு ஏற்படக்கூடிய சேதம் மிக அதிகமாகிவிட்டது. அப்போதிருந்து, நெருக்கடி சூழ்நிலைகளில் ஊழியர்களுக்கு பயிற்சி அளிப்பதற்கான வேறுபட்ட, வணிக-பாதிப்பு இல்லாத சோதனைகளின் தொடராக இந்த திட்டம் சிதைந்துள்ளது. இந்தக் கட்டுரையில் உள்ள சோதனைகளைப் பற்றி நான் விரிவாகப் பேசமாட்டேன், ஆனால் எதிர்காலத்தில் அவ்வாறு செய்வேன். இந்த நேரத்தில் நான் கேம்டேயின் அடிப்படையிலான ஒரு முக்கியமான யோசனையைப் பற்றி விவாதிக்க விரும்புகிறேன்: நம்பகத்தன்மை பொறியியல் (எதிர்ப்பு பொறியியல்), கேயாஸ் இன்ஜினியரிங் என்றும் அழைக்கப்படுகிறது ().
குரங்குகளின் எழுச்சி
ஆன்லைன் வீடியோ உள்ளடக்க வழங்குநரான Netflix பற்றி நீங்கள் கேள்விப்பட்டிருக்கலாம். ஆகஸ்ட் 2008 இல் Netflix அதன் சொந்த தரவு மையத்திலிருந்து AWS Cloud க்கு மாறத் தொடங்கியது. டிவிடி ஏற்றுமதிகளை மூன்று நாட்களுக்கு தாமதப்படுத்திய ஒரு தீவிரமான தரவுத்தள ஊழலால் இந்த நடவடிக்கை தூண்டப்பட்டது (ஆம், நெட்ஃபிக்ஸ் நத்தை அஞ்சல் மூலம் திரைப்படங்களை அனுப்பத் தொடங்கியது). அதிக ஸ்ட்ரீமிங் சுமைகளைக் கையாள வேண்டியதன் அவசியத்தாலும், ஒரு ஒற்றைக் கட்டிடக்கலையிலிருந்து விலகி, பயனர்களின் எண்ணிக்கை மற்றும் பொறியியல் குழுவின் அளவைப் பொறுத்து எளிதாக அளவிடக்கூடிய மைக்ரோ சர்வீஸ்களை நோக்கி நகரும் விருப்பத்தாலும் மேகக்கணிக்கான இடம்பெயர்வு உந்தப்பட்டது. ஸ்ட்ரீமிங் சேவையின் நுகர்வோர் தரப்பு முதலில் AWS க்கு மாற்றப்பட்டது, 2010 மற்றும் 2011 க்கு இடையில், அதைத் தொடர்ந்து நிறுவன IT மற்றும் பிற அனைத்து கட்டமைப்புகளும். Netflix இன் சொந்த தரவு மையம் 2016 இல் மூடப்பட்டது. நிறுவனம், ஒரு திரைப்படத்தை வெளியிடுவதற்கான வெற்றிகரமான முயற்சிகளின் எண்ணிக்கையின் விகிதமாக, வேலைநேரம் மற்றும் வேலையில்லா நேரத்தின் எளிய ஒப்பீடு அல்லாமல், மொத்த எண்ணிக்கையில் கிடைப்பதை அளவிடுகிறது, மேலும் காலாண்டு அடிப்படையில் ஒவ்வொரு பிராந்தியத்திலும் 0,9999 என்ற எண்ணிக்கையை அடைய முயற்சிக்கிறது (இது பெரும்பாலும் வெற்றி பெறுகிறது). Netflix இன் உலகளாவிய கட்டிடக்கலை மூன்று AWS பிராந்தியங்களில் பரவியுள்ளது. இவ்வாறு, ஒரு பிராந்தியத்தில் சிக்கல்கள் ஏற்பட்டால், பயனர்களை மற்றவர்களுக்கு திருப்பிவிடும் திறனை நிறுவனம் கொண்டுள்ளது.
எனக்கு பிடித்த மேற்கோள்களில் ஒன்றை மீண்டும் சொல்கிறேன்:
“இடையூறுகள் தவிர்க்க முடியாதவை; இறுதியில் எந்த அமைப்பும் காலப்போக்கில் சரிந்துவிடும்." - வெர்னர் வோகல்ஸ்
உண்மையில், விநியோகிக்கப்பட்ட அமைப்புகளில் தோல்விகள், குறிப்பாக பெரிய அளவிலானவை, கிளவுட்டில் கூட தவிர்க்க முடியாதவை. இருப்பினும், AWS கிளவுட் மற்றும் அதன் பணிநீக்கம் பழமையானது-குறிப்பாக , இது கட்டமைக்கப்பட்டுள்ளது, மிகவும் நம்பகமான சேவைகளை வடிவமைக்க யாரையும் அனுமதிக்கிறது.
பணிநீக்கக் கொள்கைகளைப் பயன்படுத்துதல் (பணிநீக்கம்) மற்றும் செயல்பாட்டில் படிப்படியாக சரிவு (அழகான சீரழிவு), நெட்ஃபிக்ஸ் இறுதி பயனர்களை பாதிக்காமல்.
ஆரம்பத்திலிருந்தே, நெட்ஃபிக்ஸ் கடுமையான கட்டடக்கலை கொள்கைகளை கடைபிடித்து வருகிறது. AWS இல் அவர்கள் பயன்படுத்திய முதல் பயன்பாடுகளில் ஒன்று அவர்களுடையது — தானியங்கு-அளவிடுதல் நிலையற்ற மைக்ரோ சர்வீஸ்களை ஆதரிக்க. வேறு வார்த்தைகளில் கூறுவதானால், எந்தவொரு நிகழ்வையும் நிறுத்தலாம் மற்றும் நிலை இழப்பு இல்லாமல் தானாகவே மாற்றலாம். கேயாஸ் குரங்கு இந்த கொள்கையை யாரும் மீறுவதில்லை என்பதை உறுதி செய்கிறது.
குறிப்பு. மொழிபெயர்: மூலம், குபெர்னெட்டஸுக்கு என்று ஒரு அனலாக் உள்ளது , அதன் வளர்ச்சி இந்த ஆண்டு மார்ச் மாதத்தில் நிறுத்தப்பட்டதாகத் தெரிகிறது.
Netflix ஒவ்வொரு சேவையையும் மூன்று கிடைக்கும் மண்டலங்களில் விநியோகிக்கும் மற்றொரு விதியைக் கொண்டுள்ளது. அவற்றில் இரண்டு மட்டுமே இருந்தால் அது தொடர்ந்து செயல்பட வேண்டும். இந்த விதி பின்பற்றப்படுவதை உறுதிசெய்ய, கிடைக்கும் மண்டலங்களை முடக்குகிறது. மேலும் உலக அளவில் அனைத்து நெட்ஃபிக்ஸ் பயனர்களுக்கும் மூன்று பிராந்தியங்களில் ஏதேனும் இருந்து சேவை வழங்க முடியும் என்பதை உறுதிப்படுத்த முழு AWS பகுதியையும் மூடும் திறன் கொண்டது. உற்பத்தியில் சில வாரங்களுக்கு ஒருமுறை இந்த விரிவான சோதனைகளை அவர்கள் நடத்துகிறார்கள்.
இறுதியாக, நெட்ஃபிக்ஸ் அதிக கவனம் செலுத்தியது மைக்ரோ சர்வீஸ் மற்றும் ஸ்டோரேஜ் ஆர்க்கிடெக்சரில் உள்ள சிக்கல்களை அடையாளம் காண உதவும். கேயாஸ் இன்ஜினியரிங் புத்தகத்தில் இந்த நுட்பங்களைப் பற்றி மேலும் அறியலாம், இந்த தலைப்பில் ஆர்வமுள்ள எவருக்கும் நான் பரிந்துரைக்கிறேன்.
"பிராந்திய செயலிழப்புகளை உருவகப்படுத்தும் வழக்கமான அடிப்படையில் சோதனைகளை மேற்கொள்வதன் மூலம், பல்வேறு கணினி குறைபாடுகளை ஆரம்பத்தில் கண்டறிந்து அவற்றை சரிசெய்ய முடிந்தது." —
இன்று குழப்ப பொறியியலின் கொள்கைகள் ; அவர்களுக்கு பின்வரும் வரையறை கொடுக்கப்பட்டுள்ளது:
"கேயாஸ் இன்ஜினியரிங் என்பது செயல்பாட்டின் போது எழும் பல்வேறு இடையூறுகளைத் தாங்கும் திறனை உறுதி செய்வதற்காக உற்பத்தி அமைப்பில் சோதனைகளை நடத்துவதை உள்ளடக்கிய ஒரு அணுகுமுறையாகும்." —
இருப்பினும், அவனில் குழப்ப பொறியியலுக்கு அர்ப்பணிக்கப்பட்டது, , நெட்ஃபிக்ஸ் கிளவுட் கட்டமைப்பின் முன்னாள் உருவாக்கியவர், நிறுவனம் அனைத்து கிளவுட் உள்கட்டமைப்புக்கு செல்ல உதவியது, கேயாஸ் இன்ஜினியரிங் என்பதற்கு மாற்று வரையறையை வழங்கினார். என் கருத்துப்படி, இது மிகவும் துல்லியமானது மற்றும் நிறுவப்பட்டது:
"கேயாஸ் இன்ஜினியரிங் என்பது தோல்வியின் விளைவுகளைத் தணிக்க வடிவமைக்கப்பட்ட ஒரு பரிசோதனையாகும்."
உண்மையில், தோல்விகள் எல்லா நேரத்திலும் நடக்கும் என்பதை நாம் அறிவோம். சரியாக பதிலளிக்கும் போது, அவை இறுதிப் பயனர்களை பாதிக்கக் கூடாது. கேயாஸ் இன்ஜினியரின் முக்கிய குறிக்கோள், சரியாக கவனிக்கப்படாத பிரச்சனைகளைக் கண்டறிவதாகும்.
குழப்பத்தை உருவாக்க தேவையான நிபந்தனைகள்
நீங்கள் குழப்பமான பொறியியலைத் தொடங்குவதற்கு முன், நிறுவனத்தின் அனைத்து மட்டங்களிலும் நிலைத்தன்மையை உறுதிப்படுத்த தேவையான அனைத்து வேலைகளையும் செய்துள்ளீர்கள் என்பதை உறுதிப்படுத்திக் கொள்ளுங்கள். தவறு-சகிப்பு அமைப்புகளை உருவாக்குவது மென்பொருளைப் பற்றியது மட்டுமல்ல. இது மட்டத்தில் தொடங்குகிறது உள்கட்டமைப்பு, அன்று பரவுகிறது நெட்வொர்க் மற்றும் தரவு, கட்டமைப்பை பாதிக்கிறது பயன்பாடுகள், மற்றும் இறுதியில் உள்ளடக்கியது மக்கள் மற்றும் கலாச்சாரம். பின்னடைவு மாதிரிகள் மற்றும் தோல்விகள் பற்றி நான் கடந்த காலத்தில் விரிவாக எழுதியுள்ளேன் (, , и ) மற்றும் நான் இப்போது இதில் கவனம் செலுத்த மாட்டேன், ஆனால் ஒரு சிறிய நினைவூட்டல் இல்லாமல் என்னால் செய்ய முடியாது.
கணினியில் குழப்பத்தை அறிமுகப்படுத்துவதற்கு முன் தேவையான சில கூறுகள் (பட்டியல் முழுமையானது அல்ல)
குழப்பமான பொறியியலின் நிலைகள்
குழப்பமான பொறியியலின் சாராம்சம் என்பதை புரிந்து கொள்ள வேண்டியது அவசியம் НЕ குரங்குகளை காட்டுக்குள் விடுவித்து, எந்த நோக்கமும் இல்லாமல் அனைத்தையும் அழிக்க விட வேண்டும். இந்த ஒழுங்குமுறையின் முக்கிய அம்சம் என்னவென்றால், உங்கள் பயன்பாடு கொந்தளிப்பான சூழ்நிலைகளைத் தாங்குமா என்பதைப் பார்க்க, நன்கு வடிவமைக்கப்பட்ட சோதனைகள் மூலம் கட்டுப்படுத்தப்பட்ட சூழலில் அமைப்பின் சில கூறுகளை சீர்குலைப்பதாகும்.
இதைச் செய்ய, கீழே உள்ள படத்தில் கோடிட்டுக் காட்டப்பட்டுள்ள தெளிவாக வரையறுக்கப்பட்ட, முறைப்படுத்தப்பட்ட செயல்முறையை நீங்கள் பின்பற்ற வேண்டும். இது உங்கள் கணினியின் நிலையான நிலையைப் புரிந்துகொள்வதில் இருந்து ஒரு கருதுகோளை உருவாக்கி, அதைச் சோதித்து, இறுதியாக பரிசோதனையில் இருந்து பெற்ற அனுபவத்தை பகுப்பாய்வு செய்து கணினியின் நிலைத்தன்மையை மேம்படுத்துவதற்கு உதவும்.
குழப்பமான பொறியியலின் நிலைகள்
1. நிலையான நிலை
கேயாஸ் இன்ஜினியரின் மிக முக்கியமான கூறுகளில் ஒன்று சாதாரண நிலைமைகளின் கீழ் அமைப்பின் நடத்தையைப் புரிந்துகொள்வது.
Почему? இது எளிதானது: ஒரு செயற்கை தோல்வியை அறிமுகப்படுத்திய பிறகு, கணினி நன்கு ஆய்வு செய்யப்பட்ட நிலையான நிலைக்குத் திரும்பியிருப்பதை உறுதி செய்ய வேண்டும், மேலும் சோதனையானது அதன் இயல்பான நடத்தையில் குறுக்கிடாது.
இங்கே முக்கியமானது, உள் அமைப்பு பண்புக்கூறுகள் (செயலி, நினைவகம், முதலியன) மீது கவனம் செலுத்தாமல், பயனர் அனுபவத்துடன் செயல்திறனை இணைக்கும் அளவிடக்கூடிய வெளியீடுகளில் கவனம் செலுத்துவதாகும். இந்த வெளியீடுகள் நிலையான நிலையில் இருக்க, கணினியின் கவனிக்கப்பட்ட நடத்தை கணிக்கக்கூடிய வடிவத்தைக் கொண்டிருக்க வேண்டும், ஆனால் கணினியில் தோல்வி ஏற்படும் போது கணிசமாக மாற வேண்டும்.
மனதில் வைத்து , மேலே அட்ரியன் காக்கிராஃப்ட்டால் முன்மொழியப்பட்டது, இந்த நிலையான நிலை மாறும்போது கட்டுப்பாட்டை மீறிய தடுமாற்றம் எதிர்பாராத சிக்கலை ஏற்படுத்துகிறது மற்றும் குழப்ப சோதனையை நிறுத்த வேண்டும் என்று சமிக்ஞை செய்கிறது.
நிலையான நிலைகளுக்கு உதாரணமாக, அமேசானின் அனுபவத்தை எடுத்துக் கொள்வோம். நிறுவனம் ஆர்டர் அளவை அதன் நிலையான நிலை அளவீடுகளில் ஒன்றாகவும், நல்ல காரணத்திற்காகவும் பயன்படுத்துகிறது. 2007 ஆம் ஆண்டில், அமேசானைச் சேர்ந்த கிரெக் லிண்டன், இந்த முறையைப் பயன்படுத்தி எப்படி ஒரு பரிசோதனையை மேற்கொண்டார் என்பதை விவரித்தார் இணையதளப் பக்கங்களை ஏற்றும் நேரத்தை 100 எம்எஸ் அதிகரிப்பில் குறைக்க முயற்சித்தேன், சிறிய தாமதங்கள் கூட வருவாயில் கடுமையான வீழ்ச்சிக்கு வழிவகுக்கும் என்பதைக் கண்டறிந்தேன். ஏற்றுதல் நேரம் 100 எம்எஸ் அதிகரித்ததால், ஆர்டர்களின் எண்ணிக்கை (அதனால் விற்பனை) 1% குறைந்துள்ளது. இதனால்தான் ஆர்டர்களின் எண்ணிக்கை நிலையான நிலை அளவீடுகளுக்கு சிறந்த தேர்வாக உள்ளது.
நெட்ஃபிக்ஸ் பிளேபேக்கின் தொடக்கத்துடன் தொடர்புடைய சர்வர் பக்க மெட்ரிக்கைப் பயன்படுத்துகிறது - “ப்ளே” பொத்தானின் கிளிக்குகளின் எண்ணிக்கை. SPS (வினாடிக்கு தொடக்கம்) காட்டியின் நடத்தையில் ஒரு முறை மற்றும் கணினி தோல்விகள் ஏற்படும் போது அதன் குறிப்பிடத்தக்க ஏற்ற இறக்கங்களை அவர்கள் கவனித்தனர். மெட்ரிக் "நெட்ஃபிக்ஸ் பல்ஸ்" என்று அழைக்கப்படுகிறது ().
அமேசானின் ஆர்டர் எண்கள் மற்றும் நெட்ஃபிக்ஸ் பல்ஸ் ஆகியவை நிலையான நிலையின் சிறந்த காற்றழுத்தமானிகளாகும், ஏனெனில் அவை பயனர் அனுபவம் மற்றும் செயல்பாட்டு அளவீடுகளை ஒற்றை, அளவிடக்கூடிய மற்றும் மிகவும் கணிக்கக்கூடிய அளவீடுகளாக இணைக்கின்றன.
மீண்டும் அளவிடவும், அளவிடவும் மற்றும் அளவிடவும்
கணினியின் அளவீடுகளை உங்களால் சரியாகப் பிடிக்க முடியாவிட்டால், நிலையான நிலையில் ஏற்படும் மாற்றங்களை உங்களால் கண்காணிக்க முடியாது (அல்லது கண்டறியவும்) முடியாது. நெட்வொர்க், வன்பொருள் முதல் பயன்பாடு மற்றும் நபர்கள் வரை அனைத்து அளவுருக்கள்/குறிகாட்டிகளைப் படிப்பதில் சிறப்பு கவனம் செலுத்துங்கள். இந்த அளவீடுகளின் வரைபடங்களை வரையவும், அவை காலப்போக்கில் மாறாவிட்டாலும் கூட. உங்களுக்குத் தெரியாத தொடர்புகளைக் கண்டறிந்தால் நீங்கள் ஆச்சரியப்படுவீர்கள்.
"பொறியாளர்கள் தாங்கள் கணக்கிடக்கூடிய அல்லது வரைபடத்தை அணுகக்கூடிய தரவை அணுகுவதை முடிந்தவரை எளிதாக்குங்கள்." —
2. கருதுகோள்
நிலையான நிலையைக் கையாள்வதன் மூலம், நீங்கள் ஒரு கருதுகோளை உருவாக்குவதற்கு செல்லலாம்.
- பரிந்துரை இயந்திரம் நின்றால் என்ன செய்வது?
- சுமை பேலன்சர் குறைந்தால் என்ன செய்வது?
- கேச்சிங் தோல்வியடைந்தால் என்ன செய்வது?
- தாமதம் 300ms அதிகரித்தால் என்ன செய்வது?
- முதன்மை தரவுத்தளம் செயலிழந்தால் என்ன செய்வது?
நிச்சயமாக, நீங்கள் ஒரு கருதுகோளை மட்டுமே தேர்வு செய்ய வேண்டும் மற்றும் தேவையில்லாமல் அதை சிக்கலாக்கக்கூடாது. சிறியதாக தொடங்குங்கள். நான் ஊழியர்களின் கருதுகோளுடன் தொடங்க விரும்புகிறேன். பற்றி கேள்விப்பட்டிருக்கிறீர்களா பஸ் காரணி ()? பஸ் காரணி என்பது குழு உறுப்பினர்களிடையே சமமாக விநியோகிக்கப்படும் அறிவு தொடர்பான அபாயத்தின் அளவீடு ஆகும். அதன் பங்கேற்பாளர்களின் குறைந்தபட்ச எண்ணிக்கையைக் கணக்கிட இது உங்களை அனுமதிக்கிறது, திடீர் இழப்புக்குப் பிறகு, அறிவு அல்லது அனுபவமின்மை காரணமாக திட்டம் நிறுத்தப்படும்.
பல நிறுவனங்களில் தொழில்நுட்ப வல்லுனர்கள் உள்ளனர், அவர்கள் திடீரென காணாமல் போவது ("பேருந்தினால் தாக்கப்பட்டது") திட்டம் மற்றும் குழு இரண்டிலும் பேரழிவுகரமான தாக்கத்தை ஏற்படுத்தும். இந்த நபர்களைக் கண்டறிந்து, அவர்கள் மீது குழப்பமான சோதனைகளை நடத்துங்கள்: எடுத்துக்காட்டாக, அவர்களின் கணினிகளை எடுத்துச் சென்று அன்றைய தினம் அவர்களை வீட்டிற்கு அனுப்பவும், பின்னர் (பெரும்பாலும் குழப்பமான) முடிவுகளைக் கவனிக்கவும்.
பிரச்சனையை அனைவருக்கும் பொதுவானதாக்குங்கள்!
ஈர்க்கவும் முழு அணி ஒரு கருதுகோளை உருவாக்க. அனைவரும் மூளைச்சலவையில் பங்கேற்கட்டும்: தயாரிப்பு உரிமையாளர், தொழில்நுட்ப மேலாளர், பின்தளம் மற்றும் முன்தள டெவலப்பர்கள், வடிவமைப்பாளர்கள், கட்டிடக் கலைஞர்கள், முதலியன. தயாரிப்புடன் ஏதோ ஒரு வகையில் இணைந்திருக்கும் அனைவரும்.
முதலில், "என்ன என்றால்...?" என்ற கேள்விக்கு ஒவ்வொருவரும் தங்கள் சொந்த பதிலை எழுதச் சொல்லுங்கள். ஒரு காகிதத்தில். பெரும்பாலான சந்தர்ப்பங்களில் ஒவ்வொருவரும் வெவ்வேறு பதிலைக் கொண்டிருப்பதை நீங்கள் காண்பீர்கள், மேலும் குழுவில் உள்ள சிலர் இப்போது வரை இந்த சிக்கலைப் பற்றி சிந்திக்கவில்லை என்பதை நீங்கள் புரிந்துகொள்வீர்கள்.
இந்த கட்டத்தில் இடைநிறுத்தப்பட்டு, தயாரிப்பு எவ்வாறு செயல்படும் என்பது பற்றி குழு உறுப்பினர்கள் ஏன் வெவ்வேறு யோசனைகளைக் கொண்டுள்ளனர் என்பதைப் பற்றி விவாதிக்கவும். அதன் விவரக்குறிப்புகளுக்குச் சென்று, அடுத்து என்ன நடக்கும் என்பது குறித்து அனைவருக்கும் நல்ல யோசனை இருப்பதை உறுதிசெய்யவும்.
உதாரணமாக, மேற்கூறிய அமேசான் சில்லறை விற்பனைத் தளத்தை எடுத்துக் கொள்ளுங்கள். வகையின்படி கடை முகப்புப் பக்கத்தில் ஏற்றப்படுவதை நிறுத்தினால் என்ன செய்வது?
நான் 404 பிழையை திருப்பி அனுப்ப வேண்டுமா? கீழே உள்ள ஸ்கிரீன்ஷாட்டில் உள்ளதைப் போல காலி இடத்தை விட்டு, பக்கத்தை ஏற்றுவது மதிப்புக்குரியதா?
சில செயல்பாடுகளை தியாகம் செய்வது மதிப்புக்குரியதா, எடுத்துக்காட்டாக, பக்கத்தை விரிவுபடுத்தவும் பிழையை மறைக்கவும் அனுமதிப்பதா?
அது UI பக்கத்தில் தான். பின்தளத்தில் என்ன நடக்க வேண்டும்? எச்சரிக்கைகள் அனுப்பப்பட வேண்டுமா? பயனர் முகப்புப் பக்கத்தை ஏற்றும் ஒவ்வொரு முறையும் தோல்வியுற்ற சேவை தொடர்ந்து கோரிக்கைகளைப் பெற வேண்டுமா அல்லது பின்தளத்தில் அதை முற்றிலுமாக துண்டிக்க வேண்டுமா?
கடைசியாக ஒன்று. தயவு செய்து சிக்கலை ஏற்படுத்தும் என்று உங்களுக்கு முன்கூட்டியே தெரிந்த ஒரு கருதுகோளை உருவாக்க வேண்டாம்! நிலையானது என்று நீங்கள் நினைக்கும் அமைப்பின் சில பகுதிகளுடன் பரிசோதனை செய்யுங்கள் - எல்லாவற்றிற்கும் மேலாக, பரிசோதனையின் முழுப் புள்ளியும் இதுதான்.
3. ஒரு பரிசோதனையை வடிவமைத்து நடத்தவும்
- ஒரு கருதுகோளைத் தேர்ந்தெடுக்கவும்;
- பரிசோதனையின் நோக்கத்தை வரையறுக்கவும்;
- அளவிடப்படும் தொடர்புடைய குறிகாட்டிகளை அடையாளம் காணவும்;
- நிறுவனத்திற்கு தெரிவிக்கவும்.
இன்று பல மக்கள், அதே போல் தளம் , உற்பத்தியில் குழப்பமான பொறியியல் யோசனையை ஊக்குவிக்கவும். இதுவே இறுதி இலக்காக இருக்க வேண்டும் என்றாலும், பெரும்பாலான நிறுவனங்கள் இந்த அணுகுமுறையால் பயமுறுத்தப்படுகின்றன, எனவே இது தொடங்குவதற்கு நல்ல இடம் அல்ல.
என்னைப் பொறுத்தவரை, குழப்ப பொறியியல் என்பது உற்பத்தி அமைப்புகளின் பல்வேறு கூறுகளை அழிப்பது மட்டுமல்ல. இது ஒரு பயணம். அறிவு உலகிற்கு ஒரு பயணம், கட்டுப்படுத்தப்பட்ட சூழலில் உள்ள அமைப்புகளை அழிப்பது போன்ற செயல்பாட்டுடன் பிரிக்கமுடியாத வகையில் இணைக்கப்பட்டுள்ளது - எந்தவொரு சூழலும், அது உள்ளூர் தேவ் சூழல், பீட்டா, ஸ்டேஜிங் அல்லது தயாரிப்பு. கொந்தளிப்பான சூழ்நிலைகளைத் தாங்கும் உங்கள் பயன்பாட்டின் திறனில் நம்பிக்கையை வளர்க்க, நன்கு வடிவமைக்கப்பட்ட சோதனைகள் மூலம் சீர்குலைக்கவும். "நம்பிக்கையை உருவாக்குதல்” என்பது இங்கே ஒரு முக்கிய அம்சமாகும், ஏனெனில் இது உங்கள் நிறுவனத்தில் குழப்பமான பொறியியல் மற்றும் நம்பகத்தன்மை நடைமுறைகளை வெற்றிகரமாக செயல்படுத்த தேவையான கலாச்சார மாற்றங்களுக்கு முன்னோடியாகும்.
நேர்மையாக, பெரும்பாலான அணிகள் தயாரிப்பு இல்லாத சூழலில் கூட விஷயங்களை உடைப்பதில் இருந்து நிறைய கற்றுக் கொள்கின்றன. செய்ய முயற்சி செய்யுங்கள் docker stop database உங்கள் உள்ளூர் சூழலில், விளைவுகள் இல்லாமல் இந்தப் பிரச்சனையை உங்களால் கையாள முடியுமா என்று பார்க்கவும். அது நடக்காமல் இருக்க அதிக வாய்ப்பு உள்ளது.
தரவுத்தளத்தை நிறுத்துதல் - உதாரணம்
சிறியதாகத் தொடங்கி, படிப்படியாக உங்கள் குழுவிலும் நிறுவனத்திலும் நம்பிக்கையை வளர்த்துக் கொள்ளுங்கள். "கணினி நடத்தையை நம்பகத்தன்மையுடன் கைப்பற்றுவதற்கான ஒரே வழி உண்மையான உற்பத்தி போக்குவரத்து" என்று மக்கள் உங்களுக்குச் சொல்வார்கள். கேளுங்கள், புன்னகைத்து, நீங்கள் செய்வதை மெதுவாகச் செய்யுங்கள். நீங்கள் செய்யக்கூடிய மிக மோசமான விஷயம் என்னவென்றால், உற்பத்தியில் குழப்பமான பொறியியலைப் பயன்படுத்துவது மற்றும் மோசமாக தோல்வியடைவது. இதற்குப் பிறகு, யாரும் உங்களை நம்ப மாட்டார்கள், மேலும் "குழப்பமான குரங்குகளை" என்றென்றும் மறக்க வேண்டிய கட்டாயத்தில் இருப்பீர்கள்.
முதலில், நம்பிக்கையைப் பெறுங்கள். நீங்கள் என்ன செய்கிறீர்கள் என்று உங்களுக்குத் தெரியும் என்பதை நிறுவனத்திற்கும் உங்கள் சக ஊழியர்களுக்கும் காட்டுங்கள். ஒரு தீயணைப்பு வீரராகி, நேரடி தீ பயிற்சிக்குச் செல்வதற்கு முன், தீப்பிழம்புகளைப் பற்றி உங்களால் முடிந்தவரை கற்றுக்கொள்ளுங்கள். உங்கள் நம்பகத்தன்மையைப் பெறுங்கள். நினைவில் கொள்ளுங்கள் ஆமை மற்றும் முயல் கதை? மெதுவாகவும் பொறுமையாகவும் எப்போதும் பந்தயத்தில் வெற்றி பெறுவார்.
ஒரு பரிசோதனையின் போது மிக முக்கியமான புள்ளிகளில் ஒன்று திறனைப் புரிந்துகொள்வது சேதம் ஆரம் நீங்கள் அறிமுகப்படுத்திய தோல்வி மற்றும் அதன் குறைப்பு ஆகியவற்றிலிருந்து. பின்வரும் கேள்விகளை நீங்களே கேட்டுக்கொள்ளுங்கள்:
- சோதனையால் எத்தனை வாடிக்கையாளர்கள் பாதிக்கப்படுவார்கள்?
- என்ன செயல்பாடு பாதிக்கப்படும்?
- எந்தெந்த இடங்கள் பாதிக்கப்படும்?
"கொல்ல பொத்தான்" அல்லது பரிசோதனையை உடனடியாக நிறுத்திவிட்டு, கூடிய விரைவில் நிலையான நிலைக்குத் திரும்புவதற்கான வழியைப் பற்றி சிந்தியுங்கள். என்று அழைக்கப்படுவதைப் பயன்படுத்தி சோதனைகளை நடத்த விரும்புகிறேன். "கேனரி" வெளியீடுகள். இந்த நுட்பமானது, ஒரு பயன்பாட்டின் புதிய பதிப்புகளை உற்பத்தியில் தொடங்கும் போது, படிப்படியாக சிறிய அளவிலான பயனர்களுக்கு மாற்றங்களைச் செய்து, பின்னர் அவற்றை முழு உள்கட்டமைப்பு மற்றும் அனைத்து பயனர்களுக்கும் மெதுவாகப் பரப்புவதன் மூலம் தோல்வியின் அபாயத்தைக் குறைக்கிறது. நான் கேனரி ரோல்அவுட்களை விரும்புகிறேன், ஏனெனில் அவை கொள்கையை பூர்த்தி செய்கின்றன , மற்றும் பரிசோதனையை நிறுத்துவது மிகவும் எளிதானது.
கேயாஸ் சோதனைகளுக்கான டிஎன்எஸ் அடிப்படையிலான கேனரி வெளியீடுக்கான எடுத்துக்காட்டு
பயன்பாட்டின் நிலையை (கேச் அல்லது டேட்டாபேஸ்) மாற்றும் சோதனைகள் அல்லது பின்னோக்கிச் செல்ல முடியாத (எளிதாக அல்லது எல்லாவற்றிலும்) கவனமாக இருக்கவும்.
சுவாரஸ்யமாக, அட்ரியன் காக்கிராஃப்ட் என்னிடம் NoSQL தரவுத்தளங்களைப் பயன்படுத்தத் தொடங்கியதற்கு Netflix ஒரு காரணம் என்று கூறினார், ஏனெனில் அவற்றில் மாற்றங்கள் அல்லது திரும்பப் பெறுவதற்கான திட்டம் இல்லை, எனவே தனிப்பட்ட தரவு பதிவுகளை மேம்படுத்துவது அல்லது திருத்துவது மிகவும் எளிதானது (அதாவது அவை குழப்பமான பொறியியலுக்கு மிகவும் நட்பாக இருந்தன) .
4. கவனித்து கற்றுக்கொள்ளுங்கள்
புதிதாக ஒன்றைக் கற்றுக்கொள்ளவும், பரிசோதனையின் முன்னேற்றத்தைக் கண்காணிக்கவும், நீங்கள் கணினி செயல்திறனைக் கண்காணிக்க வேண்டும். முன்னர் குறிப்பிட்டபடி, அனைத்து வகையான அளவீடுகள் மற்றும் அளவுருக்களுக்கு அதிகபட்ச கவனம் செலுத்துங்கள்! பின்னர் முடிவுகளை அளவிடவும் மற்றும் எப்போதும் - எப்போதும்! - ஒரு சிக்கலின் முதல் அறிகுறிகள் தோன்றும் முன் நேரத்தைக் கவனியுங்கள். விழிப்பூட்டல் அமைப்புகள் தோல்வியுற்றது மற்றும் வாடிக்கையாளர்கள் முதலில் சிக்கலைப் பற்றி ட்வீட் செய்வது எனது வரலாற்றில் பலமுறை நடந்துள்ளது... என்னை நம்புங்கள், நீங்கள் அந்த சூழ்நிலையில் வர விரும்பவில்லை, எனவே உங்கள் கண்காணிப்பு மற்றும் எச்சரிக்கை அமைப்புகளை சோதிக்க குழப்ப சோதனைகளைப் பயன்படுத்தவும் நன்றாக.
- கண்டறியும் வரை நேரம்?
- அறிவிப்புக்கு முந்தைய நேரம் மற்றும் செயலில் உள்ள செயல்களின் தொடக்கம்?
- பொது அறிவிப்பு வரை நேரம்?
- செயல்பாட்டின் பகுதி இழப்பு வரை நேரம்?
- சுய-குணப்படுத்தும் காலம் எவ்வளவு காலம் நீடிக்கும்?
- முழுமையாகவோ அல்லது பகுதியாகவோ குணமடையும் வரை நேரம்?
- நெருக்கடி முடிந்து ஒரு நிலையான நிலைக்கு திரும்பும் வரை நேரம்?
தோல்விக்கு தனித்தனியான காரணம் எதுவும் இல்லை என்பதை நினைவில் கொள்ளுங்கள். பெரிய விபத்துக்கள் எப்போதும் பல சிறிய தோல்விகளின் விளைவாகும், அவை குவிந்து பெரிய அளவிலான நெருக்கடிக்கு வழிவகுக்கும்.
ஒவ்வொரு பரிசோதனையின் விரிவான பிரேத பரிசோதனையை மேற்கொள்ளுங்கள்!
AWS இல், கண்டறியப்பட்ட தோல்விகளை பகுப்பாய்வு செய்வதற்கும், அவை எதனால் ஏற்பட்டது என்பதைப் புரிந்துகொள்வதற்கும் நாங்கள் அதிக முக்கியத்துவம் கொடுக்கிறோம், எனவே எதிர்காலத்தில் இதுபோன்ற சிக்கல்களைத் தடுக்கலாம். சோதனையின் அனைத்து முடிவுகளும் முடிவுகளும் சரிசெய்தல்-பிழைகள் (COE) எனப்படும் ஆவணத்தில் சுருக்கப்பட்டுள்ளன. COE ஆனது தொழில்நுட்பம், செயல்முறை அல்லது நிறுவனத்தில் உள்ள குறைபாடுகளாக இருந்தாலும், நமது தவறுகளிலிருந்து கற்றுக்கொள்ள அனுமதிக்கிறது. முறிவுகளின் அடிப்படைக் காரணங்களை அகற்றி, தொடர்ந்து மேம்படுத்த இந்த பொறிமுறையைப் பயன்படுத்துகிறோம்.
இந்த செயல்பாட்டில் வெற்றிக்கான திறவுகோல் திறந்த தன்மை மற்றும் தவறு நடந்ததைப் பற்றிய வெளிப்படைத்தன்மை ஆகும். ஒரு நல்ல COE ஐ எழுதுவதில் மிக முக்கியமான கொள்கைகளில் ஒன்று பாரபட்சமற்றவராகவும் குறிப்பிட்ட நபர்களைக் குறிப்பிடுவதைத் தவிர்க்கவும். இத்தகைய நடத்தை ஊக்கமளிக்கும் மற்றும் தோல்விக்கான சாத்தியத்தை அனுமதிக்காத சூழலில் இது பெரும்பாலும் கடினம். அமேசான் "தலைமைக் கொள்கைகளின்" தொகுப்பைப் பயன்படுத்துகிறது () அத்தகைய நடத்தையை ஊக்குவிக்க - எ.கா. சுயவிமர்சனம், பகுப்பாய்வு அணுகுமுறை, உயர்ந்த தரம் மற்றும் பொறுப்புக்கான அர்ப்பணிப்பு COE செயல்முறையின் முக்கிய கூறுகள் மற்றும் பொதுவாக செயல்பாட்டு சிறப்பம்சங்கள்.
COE அறிக்கையில் ஐந்து முக்கிய பிரிவுகள் உள்ளன:
- என்ன நடந்தது (காலவரிசைப்படி)?
- வாடிக்கையாளர்களுக்கு என்ன பாதிப்பு?
- ஏன் பிழை ஏற்பட்டது? ()
- நாம் என்ன கற்றுக்கொண்டோம்?
- எதிர்காலத்தில் இதை எவ்வாறு தடுப்பது?
இந்த கேள்விகள் முதல் பார்வையில் தோன்றுவதை விட பதிலளிப்பது மிகவும் கடினம், ஏனென்றால் ஒவ்வொரு தெளிவற்ற/தெரியாத புள்ளியும் கவனமாக படிக்கப்படுவதை நீங்கள் உறுதி செய்ய வேண்டும்.
COE பொறிமுறையை முழு அளவிலான செயல்முறையாக மாற்ற, செயல்பாட்டு அளவீடுகளின் கட்டாய பகுப்பாய்வுடன் வாராந்திர சந்திப்புகளின் வடிவத்தில் நாங்கள் தொடர்ந்து மதிப்பாய்வுகளை நடத்துகிறோம். கூடுதலாக, தொழில்நுட்ப முன்னணிகள் முழு AWS ஊழியர்களுடனும் வாராந்திர அளவீட்டு மதிப்பாய்வுகளை நடத்துகின்றன.
5. திருத்தவும் மேம்படுத்தவும்!
இங்கே முக்கிய பாடம் கேயாஸ் சோதனைகளின் போது கண்டறியப்பட்ட சிக்கல்களை முதலில் சரிசெய்து, புதிய அம்சங்களை உருவாக்குவதை விட அவர்களுக்கு அதிக முன்னுரிமை அளிக்கிறது. இந்த செயல்பாட்டில் மூத்த நிர்வாகத்தை ஈடுபடுத்தி, புதிய செயல்பாட்டை உருவாக்குவதை விட தற்போதைய சிக்கல்களை சரிசெய்வது மிகவும் முக்கியமானது என்ற எண்ணத்தை அவர்களுக்குள் விதைக்கவும்.
ஒரு முறை குழப்பமான பரிசோதனையைப் பயன்படுத்தி முக்கியமான நிலைப்புத்தன்மை சிக்கல்களைக் கண்டறிய வாடிக்கையாளருக்கு நான் உதவினேன், ஆனால் விற்பனைக் குழுவின் அழுத்தம் காரணமாக, திருத்தங்கள் நீக்கப்பட்டன, மேலும் அனைத்து முயற்சிகளும் வாடிக்கையாளர்களுக்கு "முக்கியமான" ஒரு புதிய விஷயத்தை அறிமுகப்படுத்துவதில் கவனம் செலுத்தின. இரண்டு வாரங்களுக்குப் பிறகு, 16 மணிநேர வேலையில்லா நேரம், குழப்பமான பரிசோதனையின் போது நாங்கள் கண்டறிந்த அதே சிக்கல்களைத் தீர்க்க நிறுவனத்தை கட்டாயப்படுத்தியது. இழப்புகள் மட்டுமே மிக அதிகமாக இருந்தது.
கேயாஸ் இன்ஜினியரிங் நன்மைகள்
பல நன்மைகள் உள்ளன. என் கருத்துப்படி, மிக முக்கியமான இரண்டை நான் முன்னிலைப்படுத்துகிறேன்:
முதலில், கேயாஸ் இன்ஜினியரிங் ஒரு அமைப்பில் உள்ள அறியப்படாத சிக்கல்களைக் கண்டறிந்து, ஞாயிற்றுக்கிழமை அதிகாலை 3 மணிக்கு உற்பத்தி செயலிழக்கச் செய்யும் முன் அவற்றைச் சரிசெய்ய உதவுகிறது. அதாவது, அவர் தோல்விகளுக்கு எதிர்ப்பை அதிகரிக்கிறது மற்றும் உண்மையில், தூக்கத்தின் தரம்.
இரண்டாவதாக, திறம்பட நடத்தப்படும் குழப்பச் சோதனைகள் எப்போதும் எதிர்பார்த்ததை விட விரிவான மாற்றங்களை (முக்கியமாக கலாச்சாரம்) ஏற்படுத்துகின்றன. ஒருவேளை இவற்றில் மிக முக்கியமானது இயற்கையான பரிணாம வளர்ச்சியாகும் "அப்பாவி" (குற்றம் கூறாதது) கலாச்சாரம், “ஏன் அப்படிச் செய்தாய்?” என்ற கேள்வி எழும்போது. "எதிர்காலத்தில் இதை எப்படி தவிர்க்கலாம்?" இதன் விளைவாக மகிழ்ச்சியான, திறமையான, அதிக ஈடுபாடு கொண்ட மற்றும் வெற்றிகரமான குழு. அதுவும் அருமை!
இத்துடன் முதல் பகுதி முடிகிறது. உங்களுக்கு பிடித்திருந்தது என்று நம்புகிறேன். தயவுசெய்து மதிப்புரைகளை எழுதுங்கள், கருத்துக்களைப் பகிர்ந்து கொள்ளுங்கள் அல்லது கைதட்டவும் . அடுத்த பகுதியில், கணினிகளில் தவறுகளை அறிமுகப்படுத்துவதற்கான கருவிகள் மற்றும் நுட்பங்களைப் பார்ப்போம். வரை!
இரண்டாம் பாகத்தைப் படிக்க ஆவலுடன் இருப்பவர்களுக்காக, ஒஸ்லோவில் உள்ள என்டிசியில் கேயாஸ் இன்ஜினியரிங் என்ற தலைப்பில் எனது உரையை வழங்குகிறேன். அதில் எனக்கு பிடித்த பல கருவிகளைப் பற்றி பேசுகிறேன்:
மொழிபெயர்ப்பாளரிடமிருந்து பி.எஸ்
ஆங்கிலத்தில் கட்டுரையின் இரண்டாம் பகுதி இந்த உள்ளடக்கத்தில் ஹப்ர் வாசகர்களிடமிருந்து போதுமான ஆர்வத்தை நாங்கள் கண்டால் அதை மொழிபெயர்ப்போம் - கட்டுரையில் பொருத்தமான கருத்துகள் வரவேற்கப்படுகின்றன!
எங்கள் வலைப்பதிவிலும் படிக்கவும்:
- «";
- «";
- «".
ஆதாரம்: www.habr.com