గమనిక. అనువాదం.: ఈ కథనం 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"
DNS బ్లాక్ హోల్
ఉంటే /etc/hosts లేదా ఇతర కాన్ఫిగరేషన్ ఫైల్‌లు, మీకు ఏమీ తెలియని IP చిరునామాలను మీరు కనుగొంటారు (అవును, దురదృష్టవశాత్తు, ఇది కూడా జరుగుతుంది), మీరు మళ్లీ రక్షించడానికి రావచ్చు 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 పనిచేస్తుంది, కానీ ప్యాకెట్లు తిరిగి ఇవ్వబడవు. రెండవ నియమం మీ సిస్టమ్ నుండి ఉత్పన్నమయ్యే అన్ని ప్యాకెట్లను Google పబ్లిక్ DNS వైపుకు తగ్గిస్తుంది - దీనికి ప్రతిస్పందనగా ping మాకు దొరికింది చర్య అనుమతింపబడదు.
గమనిక: ఈ ప్రత్యేక సందర్భంలో ఉపయోగించడం మంచిది whois 8.8.8.8, అయితే ఇది ఒక ఉదాహరణ మాత్రమే.
మేము కుందేలు రంధ్రం నుండి మరింత లోతుగా వెళ్ళవచ్చు, ఎందుకంటే TCP మరియు UDPని ఉపయోగించే ప్రతిదీ వాస్తవానికి IPపై ఆధారపడి ఉంటుంది. చాలా సందర్భాలలో, IP ARPతో ముడిపడి ఉంటుంది. ఫైర్‌వాల్స్ గురించి మర్చిపోవద్దు...
మీరు రెడ్ పిల్ తీసుకుంటే, మీరు వండర్‌ల్యాండ్‌లో ఉంటారు, కుందేలు రంధ్రం ఎంత లోతుకు వెళ్తుందో నేను మీకు చూపిస్తాను."
మరింత తీవ్రమైన విధానం డిస్కనెక్ట్ కార్లు ఒక్కొక్కటిగా విరిగిపోయినవి చూడండి... "గందరగోళ కోతి"గా మారండి. వాస్తవానికి, అనేక ఉత్పత్తి వ్యవస్థలు అటువంటి బ్రూట్ ఫోర్స్ దాడి కోసం రూపొందించబడలేదు, కానీ కనీసం దీనిని పరీక్ష వాతావరణంలో ప్రయత్నించవచ్చు.
డిపెండెన్సీ మ్యాప్‌ను రూపొందించడం అనేది చాలా సుదీర్ఘమైన పని. వందలాది మైక్రోసర్వీస్‌లు మరియు కమాండ్‌ల కోసం డిపెండెన్సీ మ్యాప్‌లను సెమీ ఆటోమేటిక్‌గా రూపొందించే సాధనాన్ని అభివృద్ధి చేయడానికి దాదాపు 2 సంవత్సరాలు గడిపిన క్లయింట్‌తో నేను ఇటీవల మాట్లాడాను.
అయితే, ఫలితం చాలా ఆసక్తికరంగా మరియు ఉపయోగకరంగా ఉంటుంది. మీరు మీ సిస్టమ్, దాని డిపెండెన్సీలు మరియు కార్యకలాపాల గురించి చాలా నేర్చుకుంటారు. మళ్ళీ, ఓపికపట్టండి: ప్రయాణం చాలా ముఖ్యమైనది.
3. అతి విశ్వాసంతో జాగ్రత్త వహించండి
"ఎవరైతే దేని గురించి కలలు కంటున్నాడో, దానిని నమ్ముతాడు." - డెమోస్తనీస్
మీరు ఎప్పుడైనా విన్నారా అతి విశ్వాస ప్రభావం?
వికీపీడియా ప్రకారం, మితిమీరిన ఆత్మవిశ్వాసం ప్రభావం అనేది "ఒక వ్యక్తికి వారి చర్యలు మరియు నిర్ణయాలపై విశ్వాసం ఆ తీర్పుల యొక్క లక్ష్య ఖచ్చితత్వం కంటే గణనీయంగా ఎక్కువగా ఉండే అభిజ్ఞా పక్షపాతం, ప్రత్యేకించి విశ్వాసం స్థాయి సాపేక్షంగా ఎక్కువగా ఉన్నప్పుడు."
ప్రవృత్తి మరియు అనుభవం ఆధారంగా...
నా అనుభవంలో, గందరగోళ ఇంజనీరింగ్‌తో ఎక్కడ ప్రారంభించాలో ఈ వక్రీకరణ గొప్ప సూచన.
ఓవర్ కాన్ఫిడెంట్ ఆపరేటర్ పట్ల జాగ్రత్త వహించండి:
చార్లీ: "ఐదేళ్లుగా ఈ విషయం తగ్గలేదు, అంతా బాగానే ఉంది!"
క్రాష్: "ఆగండి... నేను త్వరలో వస్తాను!"
మితిమీరిన ఆత్మవిశ్వాసం యొక్క పర్యవసానంగా పక్షపాతం అనేది ఒక కృత్రిమ మరియు ప్రమాదకరమైన విషయం, దానిని ప్రభావితం చేసే వివిధ అంశాల కారణంగా. బృంద సభ్యులు తమ హృదయాలను సాంకేతికతలో నింపినప్పుడు లేదా దానిని "ఫిక్సింగ్" చేయడానికి ఎక్కువ సమయం గడిపినప్పుడు ఇది ప్రత్యేకంగా వర్తిస్తుంది.
సంక్షిప్తం
గందరగోళ ఇంజనీరింగ్ కోసం ప్రారంభ స్థానం కోసం అన్వేషణ ఎల్లప్పుడూ ఊహించిన దాని కంటే ఎక్కువ ఫలితాలను తెస్తుంది మరియు చాలా త్వరగా విషయాలను విచ్ఛిన్నం చేయడం ప్రారంభించిన బృందాలు (గందరగోళం-) యొక్క మరింత గ్లోబల్ మరియు ఆసక్తికరమైన సారాంశాన్ని కోల్పోతాయి.ఇంజనీరింగ్ - సృజనాత్మక ఉపయోగం శాస్త్రీయ పద్ధతులు и అనుభావిక సాక్ష్యం (సాఫ్ట్‌వేర్) సిస్టమ్‌ల రూపకల్పన, అభివృద్ధి, ఆపరేషన్, నిర్వహణ మరియు మెరుగుదల కోసం.
ఇది రెండవ భాగాన్ని ముగించింది. దయచేసి సమీక్షలు వ్రాయండి, అభిప్రాయాలను పంచుకోండి లేదా మీ చేతులు చప్పట్లు కొట్టండి . తదుపరి భాగంలో ఐ నిజంగా సిస్టమ్‌లలో వైఫల్యాలను ప్రవేశపెట్టడానికి సాధనాలు మరియు పద్ధతులను నేను పరిశీలిస్తాను. వరకు!
అనువాదకుని నుండి PS
మా బ్లాగులో కూడా చదవండి:
- «";
- «";
- «";
- «".
మూలం: www.habr.com