నెట్వర్క్ ఇంజనీర్ యొక్క వాస్తవికత (నూడుల్స్ మరియు... ఉప్పుతో?)
ఇటీవల, ఇంజనీర్లతో వివిధ సంఘటనలను చర్చిస్తున్నప్పుడు, నేను ఒక ఆసక్తికరమైన నమూనాను గమనించాను.
ఈ చర్చలలో, "మూల కారణం" అనే ప్రశ్న స్థిరంగా వస్తుంది. నమ్మకమైన పాఠకులకు బహుశా నా దగ్గర ఉందని తెలుసు
మీరు ఈ ఆలోచనను సవాలు చేసినప్పుడు మరియు సంక్లిష్ట వ్యవస్థలలో సరళత మోసపూరితంగా ఉందని ఎత్తి చూపినప్పుడు, మనోహరమైన చర్చ పుడుతుంది. "మూల కారణం" యొక్క జ్ఞానం మాత్రమే ఏమి జరుగుతుందో అర్థం చేసుకోవడానికి మాకు అనుమతిస్తుందని వివాదాలు ఉద్రేకంతో నొక్కి చెబుతున్నాయి.
నేను ఒక ఆసక్తికరమైన నమూనాను గమనించాను: డెవలపర్లు మరియు డెవొప్లు ఈ ఆలోచనకు భిన్నంగా స్పందిస్తారు. నా అనుభవంలో, డెవలపర్లు మూలకారణం ముఖ్యమని వాదించే అవకాశం ఉంది మరియు ఈవెంట్లలో కారణం-మరియు-ప్రభావ సంబంధాలు ఎల్లప్పుడూ ఏర్పరచబడవచ్చు. మరోవైపు, సంక్లిష్ట ప్రపంచం ఎల్లప్పుడూ సరళతకు కట్టుబడి ఉండదని DevOps తరచుగా అంగీకరిస్తుంది.
ఇది ఎందుకు అని నేను ఎప్పుడూ ఆలోచిస్తున్నాను? ఏమిటి తయారీలను ప్రోగ్రామర్లు "మూల కారణం ఒక పురాణం" అనే ఆలోచనను విమర్శిస్తారా? విదేశీ ఏజెంట్ను గుర్తించే రోగనిరోధక వ్యవస్థ వలె. devops అయితే వారు ఈ విధంగా ఎందుకు స్పందిస్తారు కాకుండా వొంపు ఈ ఆలోచనను పరిగణించాలా?
నాకు పూర్తిగా తెలియదు, కానీ దీని గురించి నాకు కొన్ని ఆలోచనలు ఉన్నాయి. ఇది ఈ నిపుణులు వారి రోజువారీ పనిని నిర్వహించే విభిన్న సందర్భాలకు సంబంధించినది.
డెవలపర్లు తరచుగా నిర్ణయాత్మక సాధనాలతో పని చేస్తారు. వాస్తవానికి, కంపైలర్లు, లింకర్లు, ఆపరేటింగ్ సిస్టమ్లు - ఇవన్నీ సంక్లిష్టమైన వ్యవస్థలు, కానీ అవి నిర్ణయాత్మక ఫలితాన్ని ఇస్తాయని మేము అలవాటు పడ్డాము మరియు మేము వాటిని నిర్ణయాత్మకంగా ఊహించుకుంటాము: మేము అదే ఇన్పుట్ డేటాను అందిస్తే, మేము సాధారణంగా ఈ సిస్టమ్స్ నుండి అదే అవుట్పుట్. మరియు అవుట్పుట్ ("బగ్")తో సమస్య ఉంటే, డెవలపర్లు ఇన్పుట్ డేటాను విశ్లేషించడం ద్వారా దాన్ని పరిష్కరిస్తారు (అభివృద్ధి ప్రక్రియలో వినియోగదారు నుండి లేదా సాధనాల సమితి నుండి). వారు "ఎర్రర్" కోసం వెతుకుతారు మరియు ఇన్పుట్ డేటాను మారుస్తారు. ఇది "బగ్"ని పరిష్కరిస్తుంది.
సాఫ్ట్వేర్ అభివృద్ధి యొక్క ప్రాథమిక ఊహ: అదే ఇన్పుట్ డేటా విశ్వసనీయంగా మరియు నిర్ణయాత్మకంగా అదే అవుట్పుట్ను ఉత్పత్తి చేస్తుంది.
వాస్తవానికి, నిర్ణయాత్మకం కాని ఫలితం బగ్గా పరిగణించబడుతుంది: ఊహించని లేదా తప్పుడు అవుట్పుట్ పునరుత్పత్తి కాకపోతే, డెవలపర్లు స్టాక్లోని ఇతర భాగాలకు (ఆపరేటింగ్ సిస్టమ్, నెట్వర్క్, మొదలైనవి) విచారణను విస్తరించడానికి మొగ్గు చూపుతారు. ఎక్కువ లేదా తక్కువ నిర్ణయాత్మకంగా, అదే ఇన్పుట్ డేటాతో అదే ఫలితాన్ని ఉత్పత్తి చేస్తుంది... మరియు అది కాకపోతే, ఇది ఇప్పటికీ బగ్గా పరిగణించబడుతుంది. ఇది ఇప్పుడే ఆపరేటింగ్ సిస్టమ్ లేదా నెట్వర్క్ బగ్.
ఏది ఏమైనప్పటికీ, నిర్ణయాత్మకత అనేది చాలా మంది ప్రోగ్రామర్లు చేసే ప్రాథమిక, దాదాపుగా స్వీకరించబడిన ఊహ.
కానీ హార్డ్వేర్ని ర్యాకింగ్ చేయడం లేదా క్లౌడ్ APIని గుర్తించడం కోసం రోజంతా గడిపిన ఏ డెవొప్స్ వ్యక్తికైనా, పూర్తిగా నిర్ణయాత్మక ప్రపంచం (అన్ని ఇన్పుట్లను మ్యాప్ చేయడం కూడా సాధ్యమయ్యేంత వరకు!) అనేది ఒక నశ్వరమైన భావన. పక్కన పెడితే కూడా
కాబట్టి అనుభవజ్ఞులైన ఇంజనీర్లకు అన్ని సంఘటనలకు ఒకే మూల కారణం ఉందని అనుమానించడం సులభం, మరియు "ఫైవ్ వైస్" వంటి పద్ధతులు సరిగ్గా (మరియు పునరావృతం!) ఆ మూల కారణానికి దారితీస్తాయి. వాస్తవానికి, ఇది వారి స్వంత అనుభవానికి విరుద్ధంగా ఉంది, ఇక్కడ పజిల్ ముక్కలు ఆచరణలో అంత చక్కగా సరిపోవు. అందువల్ల, వారు ఈ ఆలోచనను మరింత సులభంగా అంగీకరిస్తారు.
అయితే, డెవలపర్లు అమాయకులు, తెలివితక్కువవారు లేదా సరళత ఎలా మోసపూరితంగా ఉంటుందో అర్థం చేసుకోలేకపోతున్నారని నేను చెప్పడం లేదు.
కానీ ఈ చర్చలలో డెవలపర్ల నుండి వచ్చే ఒక సాధారణ స్పందన తరచుగా నిర్ణయాత్మకత భావనతో సంబంధం కలిగి ఉంటుందని నాకు అనిపిస్తోంది. మొత్తం మీద వారికి బాగా సేవలు అందిస్తుంది రోజువారీ పనిలో. ఇంజనీర్లు వారి అవస్థాపనపై ష్రోడింగర్ పిల్లులను పట్టుకోవాల్సినంత తరచుగా వారు నాన్డెటర్మినిజంను ఎదుర్కోరు.
ఇది గమనించిన డెవలపర్ ప్రతిచర్యలను పూర్తిగా వివరించకపోవచ్చు, కానీ మా ప్రతిచర్యలు అనేక కారకాల సంక్లిష్ట మిశ్రమం అని ఇది శక్తివంతమైన రిమైండర్.
మేము ఒకే సంఘటనతో వ్యవహరిస్తున్నా, సాఫ్ట్వేర్ డెలివరీ పైప్లైన్లో సహకరిస్తున్నా లేదా విస్తృత ప్రపంచాన్ని అర్థం చేసుకోవడానికి ప్రయత్నిస్తున్నా ఈ సంక్లిష్టతను గుర్తుంచుకోవడం ముఖ్యం.
మూలం: www.habr.com