குறிப்பு. மொழிபெயர்: இந்தக் கட்டுரை AWS தொழில்நுட்ப சுவிசேஷகர் அட்ரியன் ஹார்ன்ஸ்பியின் சிறந்த தொடர் கட்டுரைகளைத் தொடர்கிறது, அவர் IT அமைப்புகளில் ஏற்படும் தோல்விகளின் விளைவுகளைத் தணிக்க பரிசோதனையின் முக்கியத்துவத்தை எளிமையான மற்றும் தெளிவான முறையில் விளக்குகிறார்.
"நீங்கள் ஒரு திட்டத்தைத் தயாரிக்கத் தவறினால், நீங்கள் தோல்வியடையத் திட்டமிடுகிறீர்கள்." - பெஞ்சமின் பிராங்க்ளின்
В இந்தக் கட்டுரைத் தொடரில், நான் கேயாஸ் இன்ஜினியரிங் என்ற கருத்தை அறிமுகப்படுத்தி, உற்பத்தி தோல்விகளுக்கு வழிவகுக்கும் முன் கணினியில் உள்ள குறைபாடுகளைக் கண்டறிந்து சரிசெய்வது எப்படி என்பதை விளக்கினேன். நிறுவனங்களுக்குள் குழப்பமான பொறியியல் எவ்வாறு நேர்மறையான கலாச்சார மாற்றத்தை ஊக்குவிக்கிறது என்பதையும் இது விவாதித்தது.
முதல் பகுதியின் முடிவில், "சிஸ்டங்களில் தோல்விகளை அறிமுகப்படுத்துவதற்கான கருவிகள் மற்றும் முறைகள்" பற்றி பேசுவதாக உறுதியளித்தேன். ஐயோ, இந்த விஷயத்தில் எனது தலைக்கு அதன் சொந்த திட்டங்கள் இருந்தன, மேலும் இந்த கட்டுரையில் குழப்பமான பொறியியலில் ஈடுபட விரும்பும் மக்களிடையே எழும் மிகவும் பிரபலமான கேள்விக்கு பதிலளிக்க முயற்சிப்பேன்: முதலில் எதை உடைக்க வேண்டும்?
அருமையான கேள்வி! இருப்பினும், அவர் இந்த பாண்டாவால் குறிப்பாக கவலைப்படுவதாக தெரியவில்லை ...
குழப்பம் பாண்டாவை குழப்ப வேண்டாம்!
குறுகிய பதில்: கோரிக்கை பாதையில் முக்கியமான சேவைகளை இலக்கு.
நீண்ட ஆனால் தெளிவான பதில்: குழப்பத்தை எங்கு தொடங்குவது என்பதைப் புரிந்து கொள்ள, மூன்று பகுதிகளுக்கு கவனம் செலுத்துங்கள்:
- பாருங்கள் விபத்து வரலாறு மற்றும் வடிவங்களை அடையாளம் காணவும்;
- முடிவு செய்யுங்கள் முக்கியமான சார்புகள்;
- என்று அழைக்கப்படும் பயன்படுத்தவும் அதிக நம்பிக்கை விளைவு.
இது வேடிக்கையானது, ஆனால் இந்த பகுதியை எளிதாக அழைக்கலாம் "சுய கண்டுபிடிப்பு மற்றும் அறிவொளிக்கான ஒரு பயணம்". அதில் நாம் சில குளிர் கருவிகளுடன் "விளையாட" தொடங்குவோம்.
1. பதில் கடந்த காலத்தில் உள்ளது
உங்களுக்கு நினைவிருந்தால், முதல் பகுதியில் நான் பிழைகள் திருத்தம் (COE) என்ற கருத்தை அறிமுகப்படுத்தினேன் - இது நமது தவறுகளை - தொழில்நுட்பம், செயல்முறை அல்லது அமைப்பில் உள்ள தவறுகளை - அவற்றின் காரணத்தைப் புரிந்துகொள்வதற்கும் தடுப்பதற்கும் பகுப்பாய்வு செய்யும் முறை எதிர்காலத்தில் மீண்டும் நிகழும் . பொதுவாக, இங்கே நீங்கள் தொடங்க வேண்டும்.
"நிகழ்காலத்தைப் புரிந்து கொள்ள, நீங்கள் கடந்த காலத்தை அறிந்து கொள்ள வேண்டும்." - கார்ல் சாகன்
தோல்விகளின் வரலாற்றைப் பார்த்து, அவற்றை COE அல்லது போஸ்ட்மார்ட்டம்களில் குறியிட்டு அவற்றை வகைப்படுத்தவும். அடிக்கடி சிக்கல்களுக்கு வழிவகுக்கும் பொதுவான வடிவங்களை அடையாளம் காணவும், மேலும் ஒவ்வொரு COE க்கும் பின்வரும் கேள்வியை நீங்களே கேட்டுக்கொள்ளுங்கள்:
"இது கணிக்கப்பட்டு, தவறான ஊசி மூலம் தடுக்கப்பட்டிருக்க முடியுமா?"
எனது தொழில் வாழ்க்கையின் ஆரம்பத்தில் ஒரு தோல்வி எனக்கு நினைவிருக்கிறது. ஓரிரு எளிய குழப்பச் சோதனைகளை மேற்கொண்டிருந்தால் இதை எளிதாகத் தடுத்திருக்கலாம்:
சாதாரண நிலைமைகளின் கீழ், பின்தள நிகழ்வுகள் சுகாதார சோதனைகளுக்கு பதிலளிக்கின்றன ) கோரிக்கைகளை ஆரோக்கியமான நிகழ்வுகளுக்கு திருப்பிவிட ELB இந்த காசோலைகளைப் பயன்படுத்துகிறது. ஒரு நிகழ்வு "ஆரோக்கியமற்றது" என்று மாறினால், ELB அதற்கு கோரிக்கைகளை அனுப்புவதை நிறுத்துகிறது. ஒரு நாள், வெற்றிகரமான சந்தைப்படுத்தல் பிரச்சாரத்திற்குப் பிறகு, போக்குவரத்தின் அளவு அதிகரித்தது மற்றும் பின்தளங்கள் வழக்கத்தை விட மெதுவாக சுகாதார சோதனைகளுக்கு பதிலளிக்கத் தொடங்கின. இந்த சுகாதார சோதனைகள் என்று சொல்ல வேண்டும் , அதாவது, சார்புகளின் நிலை சரிபார்க்கப்பட்டது.
இருப்பினும், சிறிது நேரம் எல்லாம் நன்றாக இருந்தது.
பின்னர், ஏற்கனவே மிகவும் அழுத்தமான சூழ்நிலையில், நிகழ்வுகளில் ஒன்று முக்கியமான, வழக்கமான ETL கிரான் பணியை செயல்படுத்தத் தொடங்கியது. அதிக ட்ராஃபிக் மற்றும் க்ரான்ஜாப் ஆகியவற்றின் கலவையானது CPU பயன்பாட்டை கிட்டத்தட்ட 100%க்கு தள்ளியது. CPU ஓவர்லோட் சுகாதார சோதனைகளுக்கான பதில்களை மேலும் மெதுவாக்கியது, அதனால் ELB ஆனது செயல்திறன் சிக்கல்களை எதிர்கொள்கிறது என்று முடிவு செய்தது. எதிர்பார்த்தபடி, பேலன்சர் அதற்கான போக்குவரத்தை விநியோகிப்பதை நிறுத்தியது, இதையொட்டி, குழுவில் மீதமுள்ள நிகழ்வுகளில் சுமை அதிகரிக்க வழிவகுத்தது.
திடீரென்று, மற்ற எல்லா நிகழ்வுகளும் உடல்நலப் பரிசோதனையில் தோல்வியடையத் தொடங்கின.
ஒரு புதிய நிகழ்வைத் தொடங்குவதற்கு, தொகுப்புகளைப் பதிவிறக்கி நிறுவுவது அவசியமானது மற்றும் ஆட்டோஸ்கேலிங் குழுவில் - ஒவ்வொன்றாக - முடக்க ELB எடுத்ததை விட அதிக நேரம் எடுத்தது. விரைவில் முழு செயல்முறையும் ஒரு முக்கியமான கட்டத்தை அடைந்தது மற்றும் பயன்பாடு செயலிழந்தது என்பது தெளிவாகிறது.
பின்வரும் புள்ளிகளை நாங்கள் எப்போதும் புரிந்துகொண்டோம்:
- ஒரு புதிய நிகழ்வை உருவாக்கும் போது மென்பொருளை நிறுவ நீண்ட நேரம் எடுக்கும்; மாறாத அணுகுமுறைக்கு முன்னுரிமை கொடுப்பது நல்லது. .
- சிக்கலான சூழ்நிலைகளில், சுகாதார-சோதனைகள் மற்றும் ELBகளுக்கான பதில்களுக்கு முன்னுரிமை அளிக்கப்பட வேண்டும் - நீங்கள் விரும்பும் கடைசி விஷயம், மீதமுள்ள நிகழ்வுகளுக்கு வாழ்க்கையை சிக்கலாக்குவதாகும்.
- சுகாதார சோதனைகளின் உள்ளூர் கேச்சிங் மிகவும் உதவுகிறது (சில நொடிகள் கூட).
- கடினமான சூழ்நிலையில், கிரான் பணிகள் மற்றும் பிற முக்கியமற்ற செயல்முறைகளை இயக்க வேண்டாம் - மிக முக்கியமான பணிகளுக்கான ஆதாரங்களை சேமிக்கவும்.
- ஆட்டோஸ்கேலிங் போது, சிறிய நிகழ்வுகளைப் பயன்படுத்தவும். 10 பெரிய குழுவை விட 4 சிறிய மாதிரிகள் கொண்ட குழு சிறந்தது; ஒரு நிகழ்வு தோல்வியுற்றால், முதல் வழக்கில் 10% போக்குவரத்து 9 புள்ளிகளுக்கு மேல் விநியோகிக்கப்படும், இரண்டாவது - 25% போக்குவரத்தில் மூன்று புள்ளிகளுக்கு மேல்.
எனவே இதை முன்னறிவித்திருக்கலாம், எனவே சிக்கலை அறிமுகப்படுத்துவதன் மூலம் தடுக்க முடியுமா?
ஆம், மற்றும் பல வழிகளில்.
முதலாவதாக, போன்ற கருவிகளைப் பயன்படுத்தி அதிக CPU பயன்பாட்டை உருவகப்படுத்துவதன் மூலம் அல்லது :
❯ stress-ng --matrix 1 -t 60s
மன அழுத்தம்- ng
இரண்டாவதாக, நிகழ்வை ஓவர்லோட் செய்வதன் மூலம் மற்றும் பிற ஒத்த பயன்பாடுகள்:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
சோதனைகள் ஒப்பீட்டளவில் எளிமையானவை, ஆனால் உண்மையான தோல்வியின் அழுத்தத்தை கடந்து செல்லாமல் சிந்தனைக்கு சில நல்ல உணவை வழங்க முடியும்.
எனினும் அங்கே நிற்காதே. சோதனைச் சூழலில் செயலிழப்பை மீண்டும் உருவாக்க முயற்சிக்கவும் மற்றும் கேள்விக்கான உங்கள் பதிலைச் சரிபார்க்கவும் "இதை முன்னறிவித்து, ஒரு தவறை அறிமுகப்படுத்தி தடுத்திருக்க முடியுமா?" அனுமானங்களைச் சோதிப்பதற்கான குழப்பப் பரிசோதனையில் இது ஒரு சிறு குழப்பப் பரிசோதனையாகும், ஆனால் தோல்வியுடன் தொடங்குகிறது.
இது ஒரு கனவா, அல்லது அது உண்மையில் நடந்ததா?
எனவே தோல்விகளின் வரலாற்றைப் படிக்கவும், பகுப்பாய்வு செய்யவும் EOC, "ஹிட் ரேடியஸ்" அல்லது இன்னும் துல்லியமாக, பாதிக்கப்பட்ட வாடிக்கையாளர்களின் எண்ணிக்கையின்படி அவற்றைக் குறியிட்டு வகைப்படுத்தவும், பின்னர் வடிவங்களைத் தேடவும். சிக்கலை அறிமுகப்படுத்துவதன் மூலம் இதை முன்னறிவித்து தடுத்திருக்க முடியுமா என்று நீங்களே கேட்டுக்கொள்ளுங்கள். உங்கள் பதிலைச் சரிபார்க்கவும்.
பின்னர் மிகப்பெரிய வரம்புடன் மிகவும் பொதுவான வடிவங்களுக்கு மாறவும்.
2. சார்பு வரைபடத்தை உருவாக்கவும்
உங்கள் விண்ணப்பத்தைப் பற்றி சிந்திக்க சிறிது நேரம் ஒதுக்குங்கள். அதன் சார்புகளின் தெளிவான வரைபடம் உள்ளதா? தோல்வி ஏற்பட்டால் என்ன தாக்கத்தை ஏற்படுத்துவார்கள் தெரியுமா?
உங்கள் பயன்பாட்டின் குறியீட்டை நீங்கள் நன்கு அறிந்திருக்கவில்லை என்றால் அல்லது அது மிகப் பெரியதாகிவிட்டால், குறியீடு என்ன செய்கிறது மற்றும் அதன் சார்புகள் என்ன என்பதைப் புரிந்துகொள்வது கடினமாக இருக்கும். இந்த சார்புகள் மற்றும் பயன்பாடு மற்றும் பயனர்கள் மீதான அவற்றின் சாத்தியமான தாக்கத்தைப் புரிந்துகொள்வது குழப்பமான பொறியியலை எங்கிருந்து தொடங்குவது என்பதை அறிவது மிகவும் முக்கியமானது: தொடக்கப் புள்ளியானது மிகப்பெரிய தாக்க ஆரம் கொண்ட கூறு ஆகும்.
சார்புகளைக் கண்டறிந்து ஆவணப்படுத்துவது "சார்பு வரைபடத்தை உருவாக்குதல்» (சார்பு மேப்பிங்). குறியீடு விவரக்குறிப்புக் கருவிகளைப் பயன்படுத்தி பெரிய குறியீட்டு அடிப்படையைக் கொண்ட பயன்பாடுகளுக்கு இது பொதுவாக செய்யப்படுகிறது. (குறியீடு விவரக்குறிப்பு) மற்றும் கருவி (கருவி). நெட்வொர்க் ட்ராஃபிக்கைக் கண்காணிப்பதன் மூலம் வரைபடத்தையும் உருவாக்கலாம்.
இருப்பினும், அனைத்து சார்புகளும் ஒரே மாதிரியானவை அல்ல (இது செயல்முறையை மேலும் சிக்கலாக்குகிறது). சில முக்கியமான, மற்றவை - இரண்டாம் நிலை (குறைந்த பட்சம் கோட்பாட்டளவில், முக்கியமற்றதாகக் கருதப்படும் சார்புகளின் சிக்கல்களால் அடிக்கடி விபத்துகள் ஏற்படுகின்றன).
முக்கியமான சார்புகள் இல்லாமல், சேவை இயங்காது. முக்கியமற்ற சார்புகள்"கூடாது» வீழ்ச்சி ஏற்பட்டால் சேவையை பாதிக்க. சார்புகளைப் புரிந்து கொள்ள, உங்கள் பயன்பாடு பயன்படுத்தும் APIகளைப் பற்றிய தெளிவான புரிதல் உங்களுக்கு இருக்க வேண்டும். இது தோன்றுவதை விட மிகவும் கடினமாக இருக்கலாம் - குறைந்தபட்சம் பெரிய பயன்பாடுகளுக்கு.
அனைத்து API களையும் கடந்து தொடங்கவும். மிகவும் முன்னிலைப்படுத்தவும் குறிப்பிடத்தக்க மற்றும் முக்கியமான. எடுத்துக்கொள் பொறுத்து குறியீடு களஞ்சியத்திலிருந்து, அதைச் சரிபார்க்கவும் இணைப்பு பதிவுகள், பிறகு பார்க்கவும் ஆவணங்கள் (நிச்சயமாக, அது இருந்தால் - இல்லையெனில் உங்களிடம் இன்னும் உள்ளதுоபெரிய பிரச்சனைகள்). கருவிகளைப் பயன்படுத்தவும் விவரக்குறிப்பு மற்றும் தடமறிதல், வெளிப்புற அழைப்புகளை வடிகட்டவும்.
போன்ற நிரல்களைப் பயன்படுத்தலாம் netstat - கணினியில் உள்ள அனைத்து பிணைய இணைப்புகளின் (செயலில் உள்ள சாக்கெட்டுகள்) பட்டியலைக் காண்பிக்கும் கட்டளை வரி பயன்பாடு. எடுத்துக்காட்டாக, தற்போதைய அனைத்து இணைப்புகளையும் பட்டியலிட, தட்டச்சு செய்க:
❯ netstat -a | more
AWS இல் நீங்கள் பயன்படுத்தலாம் (ஓட்டம் பதிவுகள்) VPC என்பது ஒரு VPC இல் உள்ள பிணைய இடைமுகங்களுக்குச் செல்லும் அல்லது அதிலிருந்து IP டிராஃபிக்கைப் பற்றிய தகவல்களைச் சேகரிக்க உங்களை அனுமதிக்கும் ஒரு முறையாகும். இத்தகைய பதிவுகள் மற்ற பணிகளுக்கும் உதவும் - எடுத்துக்காட்டாக, சில ட்ராஃபிக் ஏன் நிகழ்வை அடையவில்லை என்ற கேள்விக்கான பதிலைக் கண்டறிதல்.
நீங்களும் பயன்படுத்தலாம் . எக்ஸ்-ரே நீங்கள் விரிவான, "இறுதி" பெற அனுமதிக்கிறது (முடிவுக்கு) விண்ணப்பத்தின் வழியாக செல்லும்போது கோரிக்கைகளின் கண்ணோட்டம், மேலும் பயன்பாட்டின் அடிப்படைக் கூறுகளின் வரைபடத்தையும் உருவாக்குகிறது. நீங்கள் சார்புகளை அடையாளம் காண வேண்டும் என்றால் மிகவும் வசதியானது.
AWS எக்ஸ்-ரே கன்சோல்
நெட்வொர்க் சார்பு வரைபடம் ஒரு பகுதி தீர்வு மட்டுமே. ஆம், எந்தப் பயன்பாடு எதனுடன் தொடர்பு கொள்கிறது என்பதை இது காட்டுகிறது, ஆனால் பிற சார்புகள் உள்ளன.
பல பயன்பாடுகள் சார்புகளுடன் இணைக்க DNS ஐப் பயன்படுத்துகின்றன, மற்றவை சேவை கண்டுபிடிப்பு அல்லது உள்ளமைவு கோப்புகளில் கடின-குறியிடப்பட்ட IP முகவரிகளைப் பயன்படுத்தலாம் (எ.கா. /etc/hosts).
உதாரணமாக, நீங்கள் உருவாக்கலாம் உதவியுடன் iptables மற்றும் என்ன உடைகிறது என்று பாருங்கள். இதைச் செய்ய, பின்வரும் கட்டளையை உள்ளிடவும்:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
டிஎன்எஸ் கருந்துளை
உள்ளே இருந்தால் /etc/hosts அல்லது பிற உள்ளமைவு கோப்புகள், உங்களுக்கு எதுவும் தெரியாத ஐபி முகவரிகளைக் காண்பீர்கள் (ஆம், துரதிர்ஷ்டவசமாக, இதுவும் நடக்கும்), நீங்கள் மீண்டும் மீட்புக்கு வரலாம் iptables. நீங்கள் கண்டுபிடித்தீர்கள் என்று வைத்துக்கொள்வோம் 8.8.8.8 மேலும் இது Google இன் பொது DNS சேவையக முகவரி என்பது தெரியவில்லை. பயன்படுத்தி iptables பின்வரும் கட்டளைகளைப் பயன்படுத்தி இந்த முகவரிக்கு உள்வரும் மற்றும் வெளிச்செல்லும் போக்குவரத்தைத் தடுக்கலாம்:
❯ iptables -A INPUT -s 8.8.8.8 -j DROP -m comment --comment "Reject from 8.8.8.8"
❯ iptables -A OUTPUT -d 8.8.8.8 -j DROP -m comment --comment "Reject to 8.8.8.8"
அணுகலை மூடுகிறது
முதல் விதி Google இன் பொது DNS இலிருந்து அனைத்து பாக்கெட்டுகளையும் கைவிடுகிறது: ping வேலை செய்கிறது, ஆனால் பாக்கெட்டுகள் திரும்பப் பெறப்படவில்லை. இரண்டாவது விதியானது, உங்கள் கணினியிலிருந்து வரும் அனைத்து பாக்கெட்டுகளையும் கூகுளின் பொது DNS -க்கு பதிலளிக்கும் வகையில் குறைக்கிறது ping நாம் பெறுகிறோம் செயல்பாடு அனுமதிக்கப்படவில்லை.
குறிப்பு: இந்த குறிப்பிட்ட வழக்கில், அதைப் பயன்படுத்துவது நல்லது whois 8.8.8.8, ஆனால் இது ஒரு உதாரணம் மட்டுமே.
நாம் முயல் துளைக்குள் இன்னும் ஆழமாகச் செல்லலாம், ஏனென்றால் TCP மற்றும் UDP ஐப் பயன்படுத்தும் அனைத்தும் உண்மையில் ஐபியையும் சார்ந்துள்ளது. பெரும்பாலான சந்தர்ப்பங்களில், IP ஆனது ARP உடன் இணைக்கப்பட்டுள்ளது. ஃபயர்வால்களைப் பற்றி மறந்துவிடாதீர்கள்.
நீங்கள் சிவப்பு மாத்திரையை எடுத்துக் கொண்டால், நீங்கள் வொண்டர்லேண்டில் இருங்கள், முயல் துளை எவ்வளவு ஆழமாக செல்கிறது என்பதை நான் உங்களுக்குக் காண்பிப்பேன்."
மிகவும் தீவிரமான அணுகுமுறை துண்டிக்க கார்கள் ஒவ்வொன்றாக உடைந்து கிடப்பதைப் பாருங்கள்... "கேஸ் குரங்கு" ஆகுங்கள். நிச்சயமாக, பல உற்பத்தி அமைப்புகள் அத்தகைய முரட்டுத்தனமான தாக்குதலுக்காக வடிவமைக்கப்படவில்லை, ஆனால் குறைந்தபட்சம் அதை ஒரு சோதனை சூழலில் முயற்சி செய்யலாம்.
சார்பு வரைபடத்தை உருவாக்குவது பெரும்பாலும் மிக நீண்ட முயற்சியாகும். நூற்றுக்கணக்கான மைக்ரோ சர்வீஸ்கள் மற்றும் கட்டளைகளுக்கான சார்பு வரைபடங்களை அரை தானாக உருவாக்கும் கருவியை உருவாக்க கிட்டத்தட்ட 2 ஆண்டுகள் செலவழித்த ஒரு கிளையண்டுடன் நான் சமீபத்தில் பேசினேன்.
இருப்பினும், முடிவு மிகவும் சுவாரஸ்யமானது மற்றும் பயனுள்ளது. உங்கள் கணினி, அதன் சார்புகள் மற்றும் செயல்பாடுகள் பற்றி நீங்கள் நிறைய அறிந்து கொள்வீர்கள். மீண்டும், பொறுமையாக இருங்கள்: பயணமே முக்கியமானது.
3. அதீத நம்பிக்கையில் ஜாக்கிரதை
"யார் எதைக் கனவு காண்கிறாரோ, அவர் அதை நம்புகிறார்." - டெமோஸ்தீனஸ்
நீங்கள் எப்போதாவது கேள்விப்பட்டிருக்கிறீர்களா அதிக நம்பிக்கை விளைவு?
விக்கிபீடியாவின் கூற்றுப்படி, அதீத நம்பிக்கை விளைவு என்பது "ஒரு நபரின் செயல்கள் மற்றும் முடிவுகளில் உள்ள நம்பிக்கையானது அந்த தீர்ப்புகளின் புறநிலை துல்லியத்தை விட கணிசமாக அதிகமாக இருக்கும் ஒரு அறிவாற்றல் சார்பு ஆகும், குறிப்பாக நம்பிக்கையின் அளவு ஒப்பீட்டளவில் அதிகமாக இருக்கும் போது."
உள்ளுணர்வு மற்றும் அனுபவத்தின் அடிப்படையில்...
எனது அனுபவத்தில், குழப்பமான பொறியியலை எங்கிருந்து தொடங்குவது என்பதற்கான சிறந்த குறிப்பு இந்த விலகல்.
அதிக தன்னம்பிக்கை கொண்ட ஆபரேட்டரிடம் ஜாக்கிரதை:
சார்லி: "இந்த விஷயம் ஐந்து வருடங்களாக வீழ்ச்சியடையவில்லை, எல்லாம் நன்றாக இருக்கிறது!"
விபத்து: "காத்திருங்கள்... நான் விரைவில் வருவேன்!"
அதீத நம்பிக்கையின் விளைவாக சார்பு என்பது ஒரு நயவஞ்சகமான மற்றும் ஆபத்தான விஷயமாகும், ஏனெனில் அதை பாதிக்கும் பல்வேறு காரணிகள். குழு உறுப்பினர்கள் தங்கள் இதயங்களை ஒரு தொழில்நுட்பத்தில் ஊற்றும்போது அல்லது அதை "சரிசெய்ய" அதிக நேரம் செலவிடும்போது இது குறிப்பாக உண்மை.
சுருக்கமாகக்
குழப்பமான பொறியியலுக்கான தொடக்கப் புள்ளிக்கான தேடல் எப்போதும் எதிர்பார்த்ததை விட அதிக முடிவுகளைத் தருகிறது, மேலும் விஷயங்களை மிக விரைவாக உடைக்கத் தொடங்கும் குழுக்கள் (கேயாஸ்-) இன் உலகளாவிய மற்றும் சுவாரஸ்யமான சாரத்தை இழக்கின்றன.பொறியியல் - படைப்பு பயன்பாடு அறிவியல் முறைகள் и அனுபவ ஆதாரம் (மென்பொருள்) அமைப்புகளின் வடிவமைப்பு, மேம்பாடு, செயல்பாடு, பராமரிப்பு மற்றும் மேம்பாட்டிற்காக.
இத்துடன் இரண்டாம் பாகம் முடிவடைகிறது. தயவுசெய்து மதிப்புரைகளை எழுதுங்கள், கருத்துக்களைப் பகிர்ந்து கொள்ளுங்கள் அல்லது கைதட்டவும் . அடுத்த பகுதியில் ஐ உண்மையில் கணினிகளில் தோல்விகளை அறிமுகப்படுத்துவதற்கான கருவிகள் மற்றும் முறைகளை நான் பரிசீலிப்பேன். வரை!
மொழிபெயர்ப்பாளரிடமிருந்து பி.எஸ்
எங்கள் வலைப்பதிவிலும் படிக்கவும்:
- «";
- «";
- «";
- «".
ஆதாரம்: www.habr.com