ความเป็นจริงของวิศวกรเครือข่าย (กับบะหมี่และ... เกลือ?)
เมื่อเร็ว ๆ นี้ ขณะพูดคุยถึงเหตุการณ์ต่าง ๆ กับวิศวกร ฉันสังเกตเห็นรูปแบบที่น่าสนใจ
ในการสนทนาเหล่านี้ คำถามเกี่ยวกับ "สาเหตุที่แท้จริง" มักจะผุดขึ้นมาอยู่เสมอ ผู้อ่านที่ซื่อสัตย์อาจจะรู้ว่าฉันมี บน . ในหลายองค์กร การวิเคราะห์เหตุการณ์อิงตามแนวคิดนี้ทั้งหมด พวกเขาใช้เทคนิคที่แตกต่างกันในการระบุความสัมพันธ์ระหว่างเหตุและผล เช่น . วิธีการเหล่านี้ถือว่าสิ่งที่เรียกว่า "ความเป็นเชิงเส้นของเหตุการณ์" เป็นความเชื่อที่เถียงไม่ได้
เมื่อคุณท้าทายแนวคิดนี้และชี้ให้เห็นว่าความเป็นเชิงเส้นนั้นหลอกลวงอย่างมั่นใจในระบบที่ซับซ้อน การอภิปรายที่น่าสนใจก็เกิดขึ้น ผู้โต้แย้งยืนกรานอย่างกระตือรือร้นว่าความรู้เกี่ยวกับ "สาเหตุที่แท้จริง" เท่านั้นที่ช่วยให้เราเข้าใจสิ่งที่เกิดขึ้นได้
ฉันสังเกตเห็นรูปแบบที่น่าสนใจ: นักพัฒนาและ Devop ตอบสนองต่อแนวคิดนี้แตกต่างออกไป จากประสบการณ์ของผม นักพัฒนามีแนวโน้มที่จะโต้แย้งว่าสาเหตุที่แท้จริงมีความสำคัญ และความสัมพันธ์ระหว่างเหตุและผลนั้นสามารถสร้างขึ้นได้ในเหตุการณ์เสมอ ในทางกลับกัน DevOps มักจะเห็นด้วยว่าโลกที่ซับซ้อนไม่ได้เชื่อฟังความเป็นเส้นตรงเสมอไป
ฉันสงสัยอยู่เสมอว่าทำไมถึงเป็นเช่นนี้? อะไร ทำให้ โปรแกรมเมอร์วิพากษ์วิจารณ์แนวคิด “ต้นเหตุเป็นเพียงตำนาน” เช่นนั้นหรือ? เหมือนระบบภูมิคุ้มกันที่รับรู้ถึงตัวแทนจากต่างประเทศ ทำไมพวกเขาถึงมีปฏิกิริยาเช่นนี้ในขณะที่พวกเดวอปส์ ค่อนข้างโน้มเอียง พิจารณาความคิดนี้?
ฉันไม่แน่ใจทั้งหมด แต่ฉันมีความคิดบางอย่างเกี่ยวกับเรื่องนี้ มันเกี่ยวข้องกับบริบทต่างๆ ที่ผู้เชี่ยวชาญเหล่านี้ทำงานในแต่ละวัน
นักพัฒนามักจะทำงานกับเครื่องมือที่กำหนด แน่นอน คอมไพเลอร์ ตัวเชื่อมโยง ระบบปฏิบัติการ - ทั้งหมดนี้เป็นระบบที่ซับซ้อน แต่เราคุ้นเคยกับความจริงที่ว่าพวกมันให้ผลลัพธ์ที่กำหนด และเราจินตนาการว่ามันเป็นสิ่งที่กำหนดได้: ถ้าเราให้ข้อมูลอินพุตเดียวกัน เราก็มักจะคาดหวังว่า ผลลัพธ์เดียวกันจากระบบเหล่านี้ และหากมีปัญหากับเอาต์พุต (“ข้อบกพร่อง”) นักพัฒนาจะแก้ไขโดยการวิเคราะห์ข้อมูลอินพุต (ไม่ว่าจะจากผู้ใช้หรือจากชุดเครื่องมือในระหว่างกระบวนการพัฒนา) พวกเขามองหา "ข้อผิดพลาด" จากนั้นจึงเปลี่ยนข้อมูลอินพุต วิธีนี้จะช่วยแก้ไข "ข้อบกพร่อง"
ข้อสันนิษฐานพื้นฐานของการพัฒนาซอฟต์แวร์: ข้อมูลอินพุตเดียวกันจะสร้างเอาต์พุตเดียวกันได้อย่างน่าเชื่อถือและกำหนดไว้
ในความเป็นจริง ผลลัพธ์ที่ไม่สามารถกำหนดได้นั้นถือว่าเป็นจุดบกพร่อง: หากผลลัพธ์ที่ไม่คาดคิดหรือผิดพลาดไม่ได้รับการทำซ้ำ นักพัฒนามักจะขยายการตรวจสอบไปยังส่วนอื่น ๆ ของสแต็ก (ระบบปฏิบัติการ เครือข่าย ฯลฯ) ซึ่งทำงานเช่นกัน ไม่มากก็น้อยตามที่กำหนด โดยให้ผลลัพธ์เดียวกันกับข้อมูลอินพุตเดียวกัน... และ ถ้าไม่ใช่ก็ถือว่ายังเป็นจุดบกพร่องอยู่ ตอนนี้เป็นเพียงระบบปฏิบัติการหรือข้อบกพร่องของเครือข่าย
ไม่ว่าในกรณีใด การกำหนดระดับเป็นข้อสันนิษฐานพื้นฐานที่แทบจะเป็นที่ยอมรับสำหรับโปรแกรมเมอร์ส่วนใหญ่
แต่สำหรับนักพัฒนาซอฟต์แวร์คนใดก็ตามที่ใช้เวลาทั้งวันในการรวบรวมฮาร์ดแวร์หรือค้นหา Cloud API แนวคิดเกี่ยวกับโลกที่กำหนดได้อย่างสมบูรณ์ (ตราบใดที่เป็นไปได้ที่จะแมปอินพุตทั้งหมด!) ถือเป็นแนวคิดที่เกิดขึ้นเพียงชั่วคราวอย่างดีที่สุด ถึงแม้จะวางทิ้งไว้ก็ตาม. วิศวกรมากประสบการณ์ได้เห็นสิ่งแปลกประหลาดที่สุดในโลกนี้ พวกเขารู้สิ่งนั้น ไม่ต้องพูดถึงปัจจัยอื่นๆ อีกนับล้านในสิ่งแวดล้อม
ดังนั้นจึงง่ายกว่าสำหรับวิศวกรที่มีประสบการณ์ที่จะสงสัยว่าเหตุการณ์ทั้งหมดมีสาเหตุที่แท้จริงเพียงประการเดียว และเทคนิคเช่น "เหตุผล XNUMX ประการ" จะนำไปสู่สาเหตุที่แท้จริงได้อย่างถูกต้อง (และทำซ้ำได้!) ในความเป็นจริง สิ่งนี้ขัดแย้งกับประสบการณ์ของพวกเขาเอง โดยที่ชิ้นส่วนปริศนาไม่พอดีในทางปฏิบัติมากนัก ดังนั้นพวกเขาจึงยอมรับแนวคิดนี้ได้ง่ายขึ้น
แน่นอนว่า ฉันไม่ได้บอกว่านักพัฒนาไร้เดียงสา โง่เขลา หรือไม่สามารถเข้าใจว่าความเป็นเส้นตรงสามารถหลอกลวงได้อย่างไร
แต่สำหรับฉันแล้วดูเหมือนว่าปฏิกิริยาทั่วไปจากนักพัฒนาในการอภิปรายเหล่านี้มักเกี่ยวข้องกับข้อเท็จจริงที่ว่าแนวคิดเรื่องการกำหนดระดับ ให้บริการได้ดีโดยรวม ในการทำงานทุกวัน พวกเขาไม่ได้เผชิญกับความไม่แน่นอนบ่อยเท่าที่วิศวกรต้องจับแมวของชโรดิงเงอร์บนโครงสร้างพื้นฐาน
สิ่งนี้อาจอธิบายปฏิกิริยาของนักพัฒนาที่สังเกตได้ไม่ครบถ้วน แต่เป็นเครื่องเตือนใจที่มีประสิทธิภาพว่าปฏิกิริยาของเราเป็นส่วนผสมที่ซับซ้อนของหลายปัจจัย
สิ่งสำคัญคือต้องจดจำความซับซ้อนนี้ ไม่ว่าเราจะจัดการกับเหตุการณ์เดียว การทำงานร่วมกันในขั้นตอนการส่งมอบซอฟต์แวร์ หรือพยายามทำความเข้าใจกับโลกที่กว้างขึ้น
ที่มา: will.com