นิทานพื้นบ้านของโปรแกรมเมอร์และวิศวกร (ตอนที่ 1)

นี่คือเรื่องราวที่คัดสรรจากอินเทอร์เน็ตเกี่ยวกับวิธีที่แมลงบางครั้งมีอาการที่น่าเหลือเชื่อโดยสิ้นเชิง บางทีคุณอาจมีบางอย่างที่จะบอกด้วย

แพ้ไอศกรีมวานิลลาในรถยนต์

เรื่องราวสำหรับวิศวกรที่เข้าใจว่าสิ่งที่ชัดเจนไม่ใช่คำตอบเสมอไป และไม่ว่าข้อเท็จจริงจะดูลึกซึ้งแค่ไหน มันก็ยังคงเป็นข้อเท็จจริง แผนกรถปอนเตี๊ยกของบริษัทเจนเนอรัล มอเตอร์ส ได้รับการร้องเรียน:

นี่เป็นครั้งที่สองที่ฉันเขียนถึงคุณ และฉันไม่โทษคุณไม่ตอบ เพราะมันฟังดูบ้าไปแล้ว ครอบครัวของเรามีประเพณีกินไอศกรีมทุกคืนหลังอาหารเย็น ประเภทของไอศกรีมเปลี่ยนไปทุกครั้ง และหลังอาหารเย็น ทุกคนในครอบครัวเลือกไอศกรีมที่จะซื้อ หลังจากนั้นฉันก็ไปที่ร้าน ฉันเพิ่งซื้อรถปอนเตี๊ยกคันใหม่ และตั้งแต่นั้นมาการเดินทางไปซื้อไอศกรีมของฉันก็กลายเป็นปัญหา เห็นไหมทุกครั้งที่ซื้อไอศกรีมวานิลลาแล้วกลับจากร้าน รถสตาร์ทไม่ติด ถ้าผมเอาไอศกรีมอย่างอื่นมาด้วย รถก็สตาร์ทได้ไม่มีปัญหาครับ ฉันต้องการถามคำถามที่จริงจังไม่ว่ามันจะฟังดูงี่เง่าแค่ไหนก็ตาม: “ แล้วรถปอนเตี๊ยกล่ะที่ทำให้มันไม่เริ่มต้นเมื่อฉันนำไอศกรีมวานิลลามา แต่เริ่มต้นอย่างง่ายดายเมื่อฉันนำไอศกรีมรสชาติอื่นมา” "

ดังที่คุณจะจินตนาการได้ ประธานแผนกไม่เชื่อเกี่ยวกับจดหมายฉบับนี้ อย่างไรก็ตาม เผื่อว่าผมได้ส่งวิศวกรไปตรวจสอบ เขาแปลกใจที่ได้พบกับชายผู้มั่งคั่งและมีการศึกษาดีซึ่งอาศัยอยู่ในพื้นที่ที่สวยงาม พวกเขาตกลงที่จะพบกันทันทีหลังอาหารเย็นเพื่อที่พวกเขาทั้งสองจะได้ไปที่ร้านเพื่อซื้อไอศกรีม เย็นวันนั้นมันเป็นวานิลลา และเมื่อพวกเขากลับไปที่รถ รถก็สตาร์ทไม่ติด

วิศวกรมาอีกสามเย็น ครั้งแรกที่ไอศกรีมเป็นช็อคโกแลต รถก็สตาร์ท ครั้งที่สองมีไอศกรีมสตรอเบอร์รี่ รถก็สตาร์ท ในเย็นวันที่สามเขาขอเอาวานิลลา รถสตาร์ทไม่ติด

วิศวกรปฏิเสธที่จะเชื่อว่ารถคันนั้นแพ้ไอศกรีมวานิลลาด้วยเหตุผลที่สมเหตุสมผล ดังนั้นฉันจึงตกลงกับเจ้าของรถว่าเขาจะเยี่ยมเยียนต่อไปจนกว่าจะพบวิธีแก้ปัญหา และระหว่างทางเขาเริ่มจดบันทึก: เขาจดข้อมูลทั้งหมด เวลาของวัน ประเภทน้ำมัน เวลาที่มาถึงและกลับจากร้านค้า ฯลฯ

วิศวกรก็ตระหนักได้ว่าเจ้าของรถใช้เวลาซื้อไอศกรีมวานิลลาน้อยลง เหตุผลก็คือแผนผังของสินค้าในร้าน ไอศกรีมวานิลลาได้รับความนิยมมากที่สุดและแยกเก็บไว้ในช่องแช่แข็งบริเวณหน้าร้านเพื่อให้ง่ายต่อการค้นหา และพันธุ์อื่นๆ ทั้งหมดอยู่ที่ด้านหลังของร้าน และต้องใช้เวลานานกว่ามากในการหาพันธุ์ที่เหมาะสมและจ่ายเงิน

ตอนนี้คำถามสำหรับวิศวกร: ทำไมรถไม่สตาร์ทถ้าเวลาผ่านไปน้อยลงนับตั้งแต่ดับเครื่องยนต์? เนื่องจากปัญหาอยู่ที่เวลา ไม่ใช่ไอศกรีมวานิลลา วิศวกรจึงพบคำตอบอย่างรวดเร็ว นั่นคือตัวล็อคแก๊ส มันเกิดขึ้นทุกเย็น แต่เมื่อเจ้าของรถใช้เวลามองหาไอศกรีมมากขึ้น เครื่องยนต์ก็เย็นลงเพียงพอและสตาร์ทติดได้ง่าย และตอนที่ชายคนนั้นซื้อไอศกรีมวานิลลา เครื่องยนต์ยังร้อนเกินไป และตัวล็อคแก๊สก็ไม่มีเวลาที่จะละลาย

คุณธรรม: แม้แต่ปัญหาที่บ้าบอสุดๆ บางครั้งก็มีอยู่จริง

Crash Bandicoot

มันเจ็บปวดที่ต้องเจอกับสิ่งนี้ ในฐานะโปรแกรมเมอร์ คุณจะคุ้นเคยกับการตำหนิโค้ดของคุณเป็นอันดับแรก ที่สอง สาม... และที่ใดที่หนึ่งในหมื่นที่คุณตำหนิคอมไพเลอร์ และยิ่งไปกว่านั้น คุณได้ตำหนิอุปกรณ์แล้ว

นี่คือเรื่องราวของฉันเกี่ยวกับข้อบกพร่องของฮาร์ดแวร์

สำหรับเกม Crash Bandicoot ฉันเขียนโค้ดเพื่อโหลดและบันทึกลงในการ์ดหน่วยความจำ สำหรับนักพัฒนาเกมที่ใจกว้างเช่นนี้ มันเหมือนกับการเดินเล่นในสวนสาธารณะ ฉันคิดว่างานนี้จะใช้เวลาหลายวัน อย่างไรก็ตาม ฉันลงเอยด้วยการแก้ไขโค้ดเป็นเวลาหกสัปดาห์ ระหว่างทาง ฉันได้แก้ไขปัญหาอื่นๆ แต่ทุกๆ สองสามวัน ฉันกลับมาที่โค้ดนี้เป็นเวลาสองสามชั่วโมง มันเป็นความเจ็บปวด

อาการมีลักษณะดังนี้: เมื่อคุณบันทึกการเล่นเกมปัจจุบันและเข้าถึงการ์ดหน่วยความจำ ทุกอย่างเกือบจะเป็นไปด้วยดีเสมอ... แต่บางครั้งการดำเนินการอ่านหรือเขียนก็หมดเวลาโดยไม่มีเหตุผลที่ชัดเจน การบันทึกสั้นๆ มักจะทำให้การ์ดหน่วยความจำเสียหาย เมื่อผู้เล่นพยายามที่จะบันทึก เขาไม่เพียงแต่ล้มเหลวในการบันทึก แต่ยังทำลายแผนที่อีกด้วย อึ.

หลังจากนั้นไม่นาน Connie Bus โปรดิวเซอร์ของเราที่ Sony ก็เริ่มตื่นตระหนก เราไม่สามารถจัดส่งเกมด้วยข้อผิดพลาดนี้ได้ และหกสัปดาห์ต่อมา ฉันไม่เข้าใจว่าอะไรเป็นสาเหตุของปัญหา เราได้ติดต่อกับนักพัฒนา PS1 คนอื่นๆ ผ่าน Connie: มีใครเคยเจอสิ่งที่คล้ายกันบ้างไหม? เลขที่ ไม่มีใครมีปัญหากับการ์ดหน่วยความจำ

เมื่อคุณไม่มีแนวคิดในการดีบั๊ก แนวทางเดียวที่เหลืออยู่คือ "แบ่งและพิชิต": ลบโค้ดออกจากโปรแกรมที่ผิดพลาดมากขึ้นเรื่อย ๆ จนกว่าจะเหลือแฟรกเมนต์ที่ค่อนข้างเล็กซึ่งยังคงทำให้เกิดปัญหา นั่นคือคุณตัดโปรแกรมออกทีละชิ้นจนกว่าส่วนที่มีข้อบกพร่องจะยังคงอยู่

แต่ประเด็นก็คือ มันยากมากที่จะตัดส่วนต่างๆ ออกจากวิดีโอเกม จะรันได้อย่างไรถ้าคุณลบโค้ดที่จำลองแรงโน้มถ่วงออก? หรือวาดตัวละคร?

ดังนั้นเราจึงต้องแทนที่โมดูลทั้งหมดด้วย stub ที่แสร้งทำเป็นว่าทำสิ่งที่มีประโยชน์ แต่จริงๆ แล้วทำสิ่งง่ายๆ ที่ไม่มีข้อผิดพลาด เราต้องเขียนไม้ค้ำยันเพื่อให้เกมใช้งานได้อย่างน้อยที่สุด นี่เป็นกระบวนการที่ช้าและเจ็บปวด

ในระยะสั้นฉันทำมัน ฉันลบโค้ดออกมากขึ้นเรื่อยๆ จนกระทั่งเหลือโค้ดเริ่มต้นที่กำหนดค่าระบบให้รันเกม เริ่มต้นฮาร์ดแวร์การเรนเดอร์ ฯลฯ แน่นอนว่าในขั้นตอนนี้ ฉันไม่สามารถสร้างเมนูบันทึกและโหลดได้ เนื่องจากฉันต้องสร้างสตับสำหรับโค้ดกราฟิกทั้งหมด แต่ฉันสามารถแกล้งทำเป็นผู้ใช้โดยใช้หน้าจอบันทึกและโหลด (มองไม่เห็น) และขอให้บันทึกแล้วเขียนลงในการ์ดหน่วยความจำ

สิ่งนี้ทำให้ฉันมีโค้ดเล็กๆ น้อยๆ ที่ยังคงมีปัญหาข้างต้น - แต่มันก็ยังคงเกิดขึ้นแบบสุ่ม! ส่วนใหญ่แล้วทุกอย่างทำงานได้ดี แต่บางครั้งก็เกิดข้อผิดพลาด ฉันลบโค้ดเกมเกือบทั้งหมดแล้ว แต่จุดบกพร่องยังคงอยู่ สิ่งนี้น่างงมาก: โค้ดที่เหลือไม่ได้ทำอะไรเลยจริงๆ

เมื่อถึงจุดหนึ่งน่าจะประมาณสามโมงเช้า ความคิดหนึ่งก็เกิดขึ้นกับฉัน การดำเนินการอ่านและเขียน (อินพุต/เอาต์พุต) เกี่ยวข้องกับเวลาดำเนินการที่แม่นยำ เมื่อคุณทำงานกับฮาร์ดไดรฟ์ การ์ดหน่วยความจำ หรือโมดูลบลูทูธ รหัสระดับต่ำที่รับผิดชอบในการอ่านและการเขียนจะเป็นไปตามพัลส์นาฬิกา

ด้วยความช่วยเหลือของนาฬิกา อุปกรณ์ที่ไม่ได้เชื่อมต่อโดยตรงกับโปรเซสเซอร์จะถูกซิงโครไนซ์กับโค้ดที่ทำงานบนโปรเซสเซอร์ นาฬิกาจะกำหนดอัตรารับส่งข้อมูล ซึ่งเป็นความเร็วในการถ่ายโอนข้อมูล หากมีความสับสนในเรื่องเวลา แสดงว่าทั้งฮาร์ดแวร์หรือซอฟต์แวร์ หรือทั้งสองอย่างก็สับสนเช่นกัน และนี่เป็นสิ่งที่แย่มากเพราะข้อมูลอาจเสียหายได้

จะเกิดอะไรขึ้นถ้ามีบางอย่างในโค้ดของเราทำให้การกำหนดเวลาสับสน? ฉันตรวจสอบทุกอย่างที่เกี่ยวข้องกับสิ่งนี้ในโค้ดโปรแกรมทดสอบ และสังเกตเห็นว่าเราตั้งค่าตัวจับเวลาที่ตั้งโปรแกรมได้ใน PS1 เป็น 1 kHz (1000 ติ๊กต่อวินาที) ซึ่งค่อนข้างมาก โดยค่าเริ่มต้น เมื่อคอนโซลเริ่มทำงาน มันจะทำงานที่ 100 Hz และเกมส่วนใหญ่ก็ใช้ความถี่นี้

Andy ผู้พัฒนาเกมตั้งเวลาไว้ที่ 1 kHz เพื่อให้คำนวณการเคลื่อนไหวได้แม่นยำยิ่งขึ้น แอนดี้มีแนวโน้มที่จะเล่นมากเกินไป และถ้าเราเลียนแบบแรงโน้มถ่วง เราจะทำมันให้แม่นยำที่สุดเท่าที่จะเป็นไปได้!

แต่จะเกิดอะไรขึ้นถ้าการเร่งความเร็วตัวจับเวลาส่งผลต่อระยะเวลาโดยรวมของโปรแกรมและนาฬิกาที่ควบคุมอัตรารับส่งข้อมูลของการ์ดหน่วยความจำล่ะ

ฉันแสดงความคิดเห็นรหัสตัวจับเวลา ข้อผิดพลาดก็ไม่เกิดขึ้นอีก แต่นี่ไม่ได้หมายความว่าเราได้แก้ไขแล้ว เนื่องจากความล้มเหลวเกิดขึ้นแบบสุ่ม ถ้าฉันแค่โชคดีล่ะ?

ไม่กี่วันต่อมา ฉันก็ทดลองโปรแกรมทดสอบอีกครั้ง จุดบกพร่องไม่เกิดขึ้นอีก ฉันกลับไปที่ฐานโค้ดเกมตัวเต็ม และแก้ไขโค้ดบันทึกและโหลดเพื่อให้ตัวจับเวลาที่ตั้งโปรแกรมได้รีเซ็ตเป็นค่าดั้งเดิม (100Hz) ก่อนที่จะเข้าถึงการ์ดหน่วยความจำ จากนั้นจึงรีเซ็ตกลับเป็น 1kHz ไม่มีข้อขัดข้องอีกต่อไป

แต่ทำไมสิ่งนี้ถึงเกิดขึ้น?

ฉันกลับมาที่โปรแกรมทดสอบอีกครั้ง ฉันพยายามค้นหารูปแบบบางอย่างที่เกิดข้อผิดพลาดกับตัวจับเวลา 1 kHz ในที่สุดฉันก็สังเกตเห็นว่าข้อผิดพลาดเกิดขึ้นเมื่อมีคนเล่นกับคอนโทรลเลอร์ PS1 เนื่องจากฉันไม่ค่อยทำสิ่งนี้ด้วยตัวเอง - เหตุใดฉันจึงต้องมีคอนโทรลเลอร์เมื่อทดสอบการบันทึกและโหลดโค้ด - ฉันไม่ได้สังเกตเห็นการพึ่งพาอาศัยกันนี้ด้วยซ้ำ แต่วันหนึ่งศิลปินของเรากำลังรอให้ฉันทำการทดสอบเสร็จ - ตอนนั้นฉันอาจจะสาปแช่ง - และหมุนคอนโทรลเลอร์ในมือของเขาอย่างประหม่า เกิดข้อผิดพลาด. "รออะไร?!" เอาล่ะ ทำมันอีกครั้ง!”

เมื่อฉันรู้ว่าเหตุการณ์ทั้งสองนี้เชื่อมโยงถึงกัน ฉันสามารถสร้างข้อผิดพลาดขึ้นมาใหม่ได้อย่างง่ายดาย: ฉันเริ่มบันทึกลงในการ์ดหน่วยความจำ ย้ายตัวควบคุม และทำให้การ์ดหน่วยความจำเสียหาย สำหรับฉันมันดูเหมือนเป็นข้อบกพร่องของฮาร์ดแวร์

ฉันมาหาคอนนีและเล่าให้เธอฟังเกี่ยวกับการค้นพบของฉัน เธอส่งข้อมูลไปยังวิศวกรคนหนึ่งที่ออกแบบ PS1 “เป็นไปไม่ได้” เขาตอบ “ไม่ใช่ปัญหาฮาร์ดแวร์” ฉันขอให้คอนนี่จัดการสนทนาให้เรา

วิศวกรโทรหาฉัน และเราโต้เถียงกันด้วยภาษาอังกฤษที่บกพร่องของเขา และภาษาญี่ปุ่นของฉัน (แย่มาก) ในที่สุดฉันก็พูดว่า “ให้ฉันส่งโปรแกรมทดสอบ 30 บรรทัดของฉันไปซึ่งการเคลื่อนย้ายคอนโทรลเลอร์ทำให้เกิดข้อผิดพลาด” เขาเห็นด้วย. บอกว่ามันเสียเวลาและเขายุ่งมากกับการทำงานในโครงการใหม่ แต่ก็ยอมแพ้เพราะเราเป็นผู้พัฒนาที่สำคัญมากสำหรับ Sony ฉันทำความสะอาดโปรแกรมทดสอบแล้วส่งไปให้เขา

เย็นวันรุ่งขึ้น (เราอยู่ในลอสแองเจลิสและเขาอยู่ที่โตเกียว) เขาโทรหาฉันและขอโทษอย่างเขินอาย มันเป็นปัญหาฮาร์ดแวร์

ฉันไม่รู้ว่าจุดบกพร่องนั้นคืออะไร แต่จากสิ่งที่ฉันได้ยินจากสำนักงานใหญ่ Sony หากคุณตั้งค่าตัวจับเวลาให้สูงเพียงพอ มันจะรบกวนส่วนประกอบบนเมนบอร์ดใกล้กับคริสตัลตัวจับเวลา หนึ่งในนั้นคือตัวควบคุมอัตรารับส่งข้อมูลสำหรับการ์ดหน่วยความจำ ซึ่งตั้งค่าอัตรารับส่งข้อมูลสำหรับตัวควบคุมด้วย ฉันไม่ใช่วิศวกร ดังนั้นฉันอาจจะทำอะไรผิดพลาดไปก็ได้

แต่ประเด็นสำคัญก็คือ มีการรบกวนระหว่างส่วนประกอบต่างๆ บนเมนบอร์ด และเมื่อส่งข้อมูลพร้อมกันผ่านพอร์ตคอนโทรลเลอร์และพอร์ตการ์ดหน่วยความจำโดยมีตัวจับเวลาทำงานที่ 1 kHz บิตจะสูญหาย ข้อมูลสูญหาย และการ์ดเสียหาย

วัวที่ไม่ดี

ในช่วงทศวรรษ 1980 Sergei ที่ปรึกษาของผมได้เขียนซอฟต์แวร์สำหรับ SM-1800 ซึ่งเป็นโคลนของ PDP-11 ของโซเวียต ไมโครคอมพิวเตอร์เครื่องนี้เพิ่งได้รับการติดตั้งที่สถานีรถไฟใกล้กับ Sverdlovsk ซึ่งเป็นศูนย์กลางการขนส่งที่สำคัญในสหภาพโซเวียต ระบบใหม่ได้รับการออกแบบมาเพื่อกำหนดเส้นทางเกวียนและการขนส่งสินค้า แต่มันมีข้อผิดพลาดที่น่ารำคาญซึ่งนำไปสู่การล่มและล่มแบบสุ่ม น้ำตกมักเกิดขึ้นเมื่อมีคนกลับบ้านในตอนเย็น แม้จะมีการตรวจสอบอย่างละเอียดในวันรุ่งขึ้น แต่คอมพิวเตอร์ก็ทำงานได้อย่างถูกต้องในการทดสอบด้วยตนเองและอัตโนมัติทั้งหมด ซึ่งมักจะบ่งบอกถึงสภาพการแข่งขันหรือข้อบกพร่องทางการแข่งขันอื่น ๆ ที่เกิดขึ้นภายใต้เงื่อนไขบางประการ เบื่อกับการโทรตอนดึก Sergei จึงตัดสินใจลงไปที่จุดต่ำสุดและก่อนอื่นเลยต้องทำความเข้าใจว่าเงื่อนไขใดที่ลานจอดรถที่นำไปสู่การพังของคอมพิวเตอร์

ขั้นแรก เขารวบรวมสถิติการล้มโดยไม่ทราบสาเหตุทั้งหมดและสร้างกราฟตามวันที่และเวลา รูปแบบก็ชัดเจน หลังจากสังเกตต่อไปอีกสองสามวัน Sergei ก็ตระหนักว่าเขาสามารถคาดการณ์เวลาที่ระบบล่มในอนาคตได้อย่างง่ายดาย

ในไม่ช้าเขาก็ได้เรียนรู้ว่าการหยุดชะงักจะเกิดขึ้นเฉพาะเมื่อสถานีคัดแยกฝูงวัวจากทางตอนเหนือของยูเครนและรัสเซียตะวันตกมุ่งหน้าไปยังโรงฆ่าสัตว์ในบริเวณใกล้เคียง เรื่องนี้เป็นเรื่องแปลกเพราะโรงฆ่าสัตว์ได้รับการจัดหาโดยฟาร์มที่ตั้งอยู่ใกล้กับมากในคาซัคสถาน

โรงไฟฟ้านิวเคลียร์เชอร์โนบิลระเบิดในปี 1986 และกัมมันตภาพรังสีที่ปล่อยออกมาทำให้พื้นที่โดยรอบไม่สามารถอยู่อาศัยได้ พื้นที่กว้างใหญ่ทางตอนเหนือของยูเครน เบลารุส และรัสเซียตะวันตก ได้รับการปนเปื้อน เมื่อสงสัยว่ามีรังสีในระดับสูงในตู้โดยสารที่มาถึง Sergei จึงพัฒนาวิธีทดสอบทฤษฎีนี้ ห้ามมิให้ประชากรมีเครื่องวัดปริมาตร ดังนั้น Sergei จึงลงทะเบียนกับทหารหลายคนที่สถานีรถไฟ หลังจากดื่มวอดก้าไปหลายแก้ว เขาก็พยายามโน้มน้าวทหารให้วัดระดับรังสีในตู้โดยสารที่น่าสงสัยคันหนึ่ง ปรากฎว่าระดับนั้นสูงกว่าค่าปกติหลายเท่า

วัวไม่เพียงปล่อยรังสีออกมามากเท่านั้น แต่ระดับของมันยังสูงมากจนทำให้สูญเสียบิตในหน่วยความจำของ SM-1800 แบบสุ่มซึ่งตั้งอยู่ในอาคารถัดจากสถานี

เกิดการขาดแคลนอาหารในสหภาพโซเวียต และทางการได้ตัดสินใจผสมเนื้อเชอร์โนบิลกับเนื้อสัตว์จากภูมิภาคอื่น ๆ ของประเทศ ทำให้สามารถลดระดับกัมมันตภาพรังสีโดยรวมได้โดยไม่สูญเสียทรัพยากรอันมีค่า เมื่อทราบเรื่องนี้แล้ว Sergei ก็กรอกเอกสารการย้ายถิ่นฐานทันที และคอมพิวเตอร์ก็หยุดทำงานเองเมื่อระดับรังสีลดลงเมื่อเวลาผ่านไป

ผ่านท่อ

กาลครั้งหนึ่ง Movietech Solutions ได้สร้างซอฟต์แวร์สำหรับโรงภาพยนตร์ ซึ่งออกแบบมาเพื่อการบัญชี การขายตั๋ว และการจัดการทั่วไป แอพเรือธงเวอร์ชัน DOS ค่อนข้างได้รับความนิยมในหมู่เครือโรงภาพยนตร์ขนาดเล็กและขนาดกลางในอเมริกาเหนือ ดังนั้นจึงไม่น่าแปลกใจที่เมื่อมีการประกาศเวอร์ชัน Windows 95 ซึ่งรวมเข้ากับหน้าจอสัมผัสล่าสุดและตู้บริการตนเอง และติดตั้งเครื่องมือการรายงานทุกประเภท มันก็ได้รับความนิยมอย่างรวดเร็วเช่นกัน บ่อยครั้งที่การอัปเดตดำเนินไปโดยไม่มีปัญหา เจ้าหน้าที่ไอทีในพื้นที่ติดตั้งอุปกรณ์ใหม่ ย้ายข้อมูล และดำเนินธุรกิจต่อไป ยกเว้นตอนที่มันไปไม่ถึง เมื่อสิ่งนี้เกิดขึ้น บริษัทจะส่งเจมส์ซึ่งมีชื่อเล่นว่า "คนทำความสะอาด" ออกไป

แม้ว่าชื่อเล่นจะบ่งบอกถึงประเภทที่ชั่วร้าย แต่คนทำความสะอาดก็เป็นเพียงการผสมผสานระหว่างผู้สอน ผู้ติดตั้ง และนักการค้าชั้นยอด James จะใช้เวลาสองสามวันในไซต์ของลูกค้าเพื่อรวบรวมส่วนประกอบทั้งหมดเข้าด้วยกัน จากนั้นใช้เวลาอีกสองสามวันในการสอนพนักงานถึงวิธีใช้ระบบใหม่ แก้ไขปัญหาฮาร์ดแวร์ใดๆ ที่เกิดขึ้นและช่วยเหลือซอฟต์แวร์เป็นหลักในช่วงวัยเด็ก

ดังนั้นจึงไม่น่าแปลกใจที่ในช่วงเวลาที่วุ่นวายเหล่านี้ เจมส์มาถึงออฟฟิศในตอนเช้า และก่อนที่เขาจะไปถึงโต๊ะ ผู้จัดการก็เข้ามาทักทายเขา เต็มไปด้วยคาเฟอีนเกินกว่าปกติ

“ฉันเกรงว่าคุณจะต้องไปที่แอนนาโพลิส โนวาสโกเชียโดยเร็วที่สุด” ระบบทั้งหมดของพวกเขาล่ม และหลังจากทำงานร่วมกับวิศวกรมาทั้งคืน เราก็ไม่รู้ว่าเกิดอะไรขึ้น ดูเหมือนว่าเครือข่ายล้มเหลวบนเซิร์ฟเวอร์ แต่หลังจากที่ระบบทำงานมาหลายนาทีแล้วเท่านั้น

— พวกเขาไม่ได้กลับไปสู่ระบบเก่าเหรอ? - เจมส์ตอบอย่างจริงจังแม้ว่าในใจเขาจะเบิกตากว้างด้วยความประหลาดใจก็ตาม

— แน่นอน: ผู้เชี่ยวชาญด้านไอทีของพวกเขา “เปลี่ยนลำดับความสำคัญ” และตัดสินใจเลิกใช้เซิร์ฟเวอร์เก่า เจมส์ พวกเขาติดตั้งระบบที่ไซต์งาน 1950 แห่ง และเพิ่งจ่ายค่าสนับสนุนระดับพรีเมียม และตอนนี้ธุรกิจของพวกเขาดำเนินไปเหมือนในทศวรรษ XNUMX

เจมส์ยืดตัวขึ้นเล็กน้อย

- นั่นเป็นอีกเรื่องหนึ่ง เอาล่ะ มาเริ่มกันเลย

เมื่อเขามาถึงแอนนาโพลิส สิ่งแรกที่เขาทำคือค้นหาโรงละครแห่งแรกของลูกค้าที่มีปัญหา บนแผนที่ที่ถ่ายที่สนามบิน ทุกอย่างดูดี แต่บริเวณรอบๆ ที่อยู่ที่ต้องการดูน่าสงสัย ไม่ใช่สลัม แต่ชวนให้นึกถึงฟิล์มนัวร์ ขณะที่เจมส์จอดรถที่ขอบถนนในตัวเมือง โสเภณีคนหนึ่งเดินเข้ามาหาเขา เมื่อพิจารณาจากขนาดของแอนนาโพลิส ก็น่าจะมีเพียงแห่งเดียวในเมืองนี้ การปรากฏตัวของเธอทำให้นึกถึงตัวละครชื่อดังที่เสนอเซ็กส์เพื่อเงินบนจอภาพยนตร์ทันที ไม่ ไม่เกี่ยวกับจูเลีย โรเบิร์ตส์ แต่เกี่ยวกับจอน วอยต์ [พาดพิงถึงภาพยนตร์เรื่อง "Midnight Cowboy" - ประมาณ เลน].

หลังจากส่งโสเภณีไปตามทางแล้วเจมส์ก็ไปดูหนัง บริเวณโดยรอบดีขึ้น แต่ก็ยังให้ความรู้สึกทรุดโทรม ไม่ใช่ว่าเจมส์กังวลเกินไป เขาเคยไปสถานที่เลวร้ายมาก่อน และนี่คือแคนาดา ที่แม้แต่คนร้ายก็ยังสุภาพพอที่จะพูดว่า "ขอบคุณ" หลังจากหยิบกระเป๋าเงินของคุณไป

ทางเข้าโรงภาพยนตร์ด้านข้างอยู่ในตรอกที่เปียกชื้น เจมส์เดินไปเคาะประตู ไม่นานมันก็ส่งเสียงดังเอี๊ยดและเปิดออกเล็กน้อย

-คุณเป็นคนทำความสะอาดหรือเปล่า? - เสียงแหบห้าวดังมาจากข้างใน

- ใช่ ฉันเอง... ฉันมาซ่อมทุกอย่าง

เจมส์เดินเข้าไปในล็อบบี้โรงหนัง ดูเหมือนว่าไม่มีทางเลือกอื่น เจ้าหน้าที่จึงเริ่มแจกตั๋วกระดาษให้กับผู้มาเยี่ยมชม สิ่งนี้ทำให้การรายงานทางการเงินทำได้ยาก ไม่ต้องพูดถึงรายละเอียดที่น่าสนใจอีกต่อไป แต่เจ้าหน้าที่ก็ทักทายเจมส์ด้วยความโล่งใจแล้วพาเขาไปที่ห้องเซิร์ฟเวอร์ทันที

เมื่อมองแวบแรกทุกอย่างก็ดี เจมส์เข้าสู่ระบบเซิร์ฟเวอร์และตรวจสอบสถานที่ต้องสงสัยตามปกติ ไม่มีปัญหา. อย่างไรก็ตาม ด้วยความระมัดระวังอย่างยิ่ง James จึงปิดเซิร์ฟเวอร์ เปลี่ยนการ์ดเครือข่าย และย้อนกลับระบบ เธอเริ่มทำงานเต็มตัวทันที เจ้าหน้าที่เริ่มจำหน่ายตั๋วอีกครั้ง

เจมส์โทรหามาระโกและแจ้งให้เขาทราบถึงสถานการณ์นี้ ไม่ยากเลยที่จะจินตนาการว่าเจมส์อาจอยากจะอยู่เฉยๆ และดูว่ามีอะไรที่ไม่คาดคิดเกิดขึ้นหรือไม่ เขาลงบันไดแล้วถามพนักงานว่าเกิดอะไรขึ้น แน่นอนว่าระบบหยุดทำงานแล้ว พวกเขาปิดและเปิดใหม่ ทุกอย่างทำงานได้ แต่ผ่านไป 10 นาที ระบบก็ล่ม

ในขณะนี้มีสิ่งที่คล้ายกันเกิดขึ้น ทันใดนั้นระบบจองตั๋วก็เริ่มแสดงข้อผิดพลาด พนักงานถอนหายใจและหยิบตั๋วกระดาษ เจมส์รีบไปที่ห้องเซิร์ฟเวอร์ ทุกอย่างดูดีเมื่อใช้ร่วมกับเซิร์ฟเวอร์

จากนั้นพนักงานคนหนึ่งก็เข้ามา

— ระบบกำลังทำงานอีกครั้ง

เจมส์งงเพราะเขาไม่ได้ทำอะไรเลย แม่นยำยิ่งขึ้นไม่มีอะไรที่จะทำให้ระบบทำงานได้ เขาออกจากระบบ หยิบโทรศัพท์ขึ้นมา และโทรหาสายสนับสนุนของบริษัท ไม่นานพนักงานคนเดียวกันก็เข้าไปในห้องเซิร์ฟเวอร์

- ระบบล่ม.

เจมส์มองไปที่เซิร์ฟเวอร์ รูปแบบที่น่าสนใจและคุ้นเคยของรูปทรงหลากสีที่เต้นอยู่บนหน้าจอ - ท่อที่บิดเบี้ยวและพันกันอย่างวุ่นวาย เราเคยเห็นสกรีนเซฟเวอร์นี้มาบ้างแล้ว มันถูกเรนเดอร์อย่างสวยงามและสะกดจิตอย่างแท้จริง

เจมส์กดปุ่มแล้วรูปแบบก็หายไป เขารีบไปที่ห้องขายตั๋ว และระหว่างทางพบพนักงานคนหนึ่งเดินกลับมาหาเขา

— ระบบกำลังทำงานอีกครั้ง

หากคุณสามารถเอามือปิดหน้าทางจิตได้ นั่นคือสิ่งที่เจมส์ทำอย่างแน่นอน สกรีนเซฟเวอร์ มันใช้ OpenGL ดังนั้นในระหว่างดำเนินการจะใช้ทรัพยากรทั้งหมดของโปรเซสเซอร์เซิร์ฟเวอร์ เป็นผลให้การเรียกไปยังเซิร์ฟเวอร์แต่ละครั้งสิ้นสุดลงด้วยการหมดเวลา

เจมส์กลับไปที่ห้องเซิร์ฟเวอร์ เข้าสู่ระบบ และเปลี่ยนสกรีนเซฟเวอร์เป็นไปป์ที่สวยงามด้วยหน้าจอว่างเปล่า นั่นคือแทนที่จะเป็นสกรีนเซฟเวอร์ที่ใช้ทรัพยากรโปรเซสเซอร์ 100% ฉันติดตั้งอีกอันที่ไม่ใช้ทรัพยากร จากนั้นฉันก็รอ 10 นาทีเพื่อตรวจสอบการเดาของฉัน

เมื่อเจมส์มาถึงโรงภาพยนตร์แห่งถัดไป เขาสงสัยว่าจะอธิบายให้ผู้จัดการของเขาฟังได้อย่างไรว่าเขาเพิ่งบินเป็นระยะทาง 800 กม. เพื่อปิดโปรแกรมรักษาหน้าจอ

ชนในช่วงหนึ่งของดวงจันทร์

เรื่องจริง. วันหนึ่งเกิดข้อผิดพลาดของซอฟต์แวร์ซึ่งขึ้นอยู่กับระยะของดวงจันทร์ มีกิจวัตรเล็กๆ น้อยๆ ที่ใช้กันทั่วไปในโปรแกรมต่างๆ ของ MIT เพื่อคำนวณการประมาณระยะที่แท้จริงของดวงจันทร์ GLS สร้างรูทีนนี้ไว้ในโปรแกรม LISP ซึ่งเมื่อเขียนไฟล์จะส่งออกบรรทัดที่มีการประทับเวลายาวเกือบ 80 อักขระ เป็นเรื่องยากมากที่บรรทัดแรกของข้อความจะยาวเกินไปและนำไปสู่บรรทัดถัดไป และเมื่อโปรแกรมอ่านไฟล์นี้ในภายหลังมันก็ถูกสาป ความยาวของบรรทัดแรกขึ้นอยู่กับวันที่และเวลาที่แน่นอน ตลอดจนความยาวของข้อกำหนดเฟส ณ เวลาที่พิมพ์การประทับเวลา นั่นคือข้อผิดพลาดนั้นขึ้นอยู่กับระยะของดวงจันทร์!

ฉบับกระดาษครั้งแรก ไฟล์ศัพท์แสง (Steele-1983) มีตัวอย่างของบรรทัดดังกล่าวที่นำไปสู่ข้อผิดพลาดที่อธิบายไว้ แต่ผู้เรียงพิมพ์ "แก้ไข" แล้ว ตั้งแต่นั้นมา สิ่งนี้ได้รับการอธิบายว่าเป็น "ข้อผิดพลาดข้างขึ้นข้างแรม"

อย่างไรก็ตามควรระมัดระวังกับสมมติฐาน เมื่อไม่กี่ปีก่อน วิศวกรจาก CERN (ศูนย์วิจัยนิวเคลียร์แห่งยุโรป) ประสบข้อผิดพลาดในการทดลองที่เครื่องชนอิเล็กตรอน-โพซิตรอนขนาดใหญ่ เนื่องจากคอมพิวเตอร์ประมวลผลข้อมูลจำนวนมหาศาลที่สร้างโดยอุปกรณ์นี้ก่อนที่จะแสดงผลให้นักวิทยาศาสตร์เห็น หลายคนจึงสันนิษฐานว่าซอฟต์แวร์ดังกล่าวมีความไวต่อระยะของดวงจันทร์ วิศวกรที่สิ้นหวังหลายคนได้ค้นพบความจริง ข้อผิดพลาดเกิดขึ้นเนื่องจากการเปลี่ยนแปลงเล็กน้อยในรูปทรงของวงแหวนยาว 27 กม. เนื่องจากการเสียรูปของโลกระหว่างการเคลื่อนตัวของดวงจันทร์! เรื่องราวนี้ได้เข้าสู่คติชนวิทยาฟิสิกส์ในชื่อ "การแก้แค้นของนิวตันต่อฟิสิกส์ของอนุภาค" และเป็นตัวอย่างของความเชื่อมโยงระหว่างกฎฟิสิกส์ที่ง่ายที่สุดและเก่าแก่ที่สุดกับแนวคิดทางวิทยาศาสตร์ที่ล้ำหน้าที่สุด

การกดชักโครกจะหยุดรถไฟ

จุดบกพร่องด้านฮาร์ดแวร์ที่ดีที่สุดที่ฉันเคยได้ยินคือบนรถไฟความเร็วสูงในฝรั่งเศส ข้อผิดพลาดดังกล่าวนำไปสู่การเบรกฉุกเฉินของรถไฟ แต่เมื่อมีผู้โดยสารอยู่บนรถไฟเท่านั้น โดยในแต่ละกรณีมีการนำรถไฟออกจากการให้บริการ ตรวจสอบแล้ว แต่ไม่พบสิ่งใด จากนั้นเขาก็ถูกส่งกลับเข้าแถว และเขาก็หยุดรถทันที

ระหว่างการตรวจสอบครั้งหนึ่ง วิศวกรคนหนึ่งที่เดินทางด้วยรถไฟไปเข้าห้องน้ำ ในไม่ช้าเขาก็ล้างออก บูม! หยุดฉุกเฉิน.

วิศวกรติดต่อคนขับและถามว่า:

— คุณทำอะไรก่อนจะเบรก?

- ฉันชะลอความเร็วลงแล้ว...

เรื่องนี้แปลกเพราะในระหว่างการดำเนินการตามปกติ รถไฟจะชะลอความเร็วลงหลายสิบครั้ง รถไฟเคลื่อนตัวต่อไป และเมื่อลงต่อไป คนขับก็เตือน:

- ฉันจะช้าลง.

ไม่มีอะไรเกิดขึ้น.

— คุณทำอะไรในช่วงเบรกครั้งสุดท้าย? - ถามคนขับ

- คือ... ฉันอยู่ในห้องน้ำ...

- ถ้าอย่างนั้นก็ไปเข้าห้องน้ำแล้วทำอย่างที่คุณทำเมื่อเราลงไปอีกครั้ง!

วิศวกรเดินไปเข้าห้องน้ำ และเมื่อคนขับเตือนว่า “ฉันกำลังขับช้าลง” เขาก็กดน้ำทิ้ง แน่นอนว่ารถไฟก็หยุดทันที

ตอนนี้พวกเขาสามารถทำให้เกิดปัญหาซ้ำได้และจำเป็นต้องค้นหาสาเหตุ

หลังจากผ่านไปสองนาที พวกเขาสังเกตเห็นว่าสายรีโมทคอนโทรลเบรกเครื่องยนต์ (รถไฟมีเครื่องยนต์หนึ่งเครื่องอยู่ที่ปลายแต่ละด้าน) ถูกตัดการเชื่อมต่อจากผนังตู้ไฟฟ้า และอยู่บนรีเลย์ที่ควบคุมโซลินอยด์ปลั๊กโถส้วม... เมื่อรีเลย์ เมื่อเปิดเครื่อง ทำให้เกิดการรบกวนสายเบรก และการป้องกันระบบต่อความล้มเหลวก็รวมถึงการเบรกฉุกเฉินด้วย

ประตูที่เกลียด FORTRAN

ไม่กี่เดือนที่ผ่านมา เราสังเกตเห็นว่าการเชื่อมต่อเครือข่ายบนแผ่นดินใหญ่ (ซึ่งก็คือในฮาวาย) เริ่มช้ามาก อาการนี้อาจคงอยู่ประมาณ 10-15 นาที แล้วเกิดขึ้นอีกกะทันหัน หลังจากนั้นไม่นาน เพื่อนร่วมงานของฉันบ่นกับฉันว่าการเชื่อมต่อเครือข่ายบนแผ่นดินใหญ่ โดยทั่วไป ไม่ทำงาน, ไม่เป็นผล. เขามีรหัส FORTRAN บางส่วนที่ต้องคัดลอกไปยังเครื่องบนแผ่นดินใหญ่ แต่ทำไม่ได้เพราะ "เครือข่ายใช้เวลาไม่นานพอที่จะอัปโหลด FTP ให้เสร็จสิ้น"

ใช่ ปรากฎว่าเครือข่ายล้มเหลวเกิดขึ้นเมื่อเพื่อนร่วมงานพยายาม FTP ไฟล์ที่มีซอร์สโค้ดใน FORTRAN ไปยังเครื่องบนแผ่นดินใหญ่ เราพยายามเก็บถาวรไฟล์: จากนั้นก็คัดลอกได้อย่างราบรื่น (แต่เครื่องเป้าหมายไม่มีตัวแตกไฟล์ ดังนั้นปัญหาจึงไม่ได้รับการแก้ไข) ในที่สุด เราก็ "แบ่ง" รหัส FORTRAN ออกเป็นส่วนเล็กๆ และส่งไปทีละรหัส ชิ้นส่วนส่วนใหญ่ถูกคัดลอกโดยไม่มีปัญหา แต่มีบางส่วนที่ไม่ผ่านหรือผ่านไปหลังจากนั้น นานา ความพยายาม

หลังจากตรวจสอบข้อความที่เป็นปัญหาแล้ว เราพบว่ามีบางอย่างที่เหมือนกัน: ทั้งหมดมีบล็อกความคิดเห็นที่เริ่มต้นและสิ้นสุดด้วยบรรทัดที่ประกอบด้วยตัวพิมพ์ใหญ่ C (ในฐานะเพื่อนร่วมงานต้องการแสดงความคิดเห็นใน FORTRAN) เราส่งอีเมลถึงผู้เชี่ยวชาญเครือข่ายบนแผ่นดินใหญ่และขอความช่วยเหลือ แน่นอนว่าพวกเขาต้องการดูตัวอย่างไฟล์ของเราที่ไม่สามารถถ่ายโอนผ่าน FTP... แต่จดหมายของเราไปไม่ถึงพวกเขา ในที่สุดเราก็มีเรื่องง่ายๆ ขึ้นมา อธิบายไฟล์ที่ไม่สามารถถ่ายโอนได้มีลักษณะอย่างไร มันได้ผล :) [ฉันกล้าเพิ่มตัวอย่างหนึ่งในความคิดเห็น FORTRAN ที่มีปัญหาที่นี่ไหม คงไม่คุ้มหรอก!]

ในที่สุดเราก็สามารถคิดออกได้ เกตเวย์ใหม่ได้รับการติดตั้งเมื่อเร็วๆ นี้ระหว่างส่วนหนึ่งของวิทยาเขตของเราและเครือข่ายบนแผ่นดินใหญ่ มันมีปัญหาอย่างมากในการส่งแพ็กเก็ตที่มีบิตตัวพิมพ์ใหญ่ C ซ้ำกัน! แพ็กเก็ตเหล่านี้เพียงไม่กี่แพ็กเก็ตอาจใช้ทรัพยากรเกตเวย์ทั้งหมด และป้องกันไม่ให้แพ็กเก็ตอื่นๆ ส่วนใหญ่ผ่านไปได้ เราร้องเรียนกับผู้ผลิตเกตเวย์... และพวกเขาก็ตอบว่า: “โอ้ ใช่แล้ว คุณกำลังเผชิญกับข้อผิดพลาดของ C ซ้ำแล้วซ้ำอีก! เรารู้เรื่องของเขาแล้ว” ในที่สุดเราก็แก้ไขปัญหาด้วยการซื้อเกตเวย์ใหม่จากผู้ผลิตรายอื่น (ในการป้องกันของเดิม การไม่สามารถถ่ายโอนโปรแกรม FORTRAN อาจเป็นข้อได้เปรียบสำหรับบางคน!)

ช่วงเวลาที่ยากลำบาก

ไม่กี่ปีที่ผ่านมา ขณะที่ทำงานเพื่อสร้างระบบ ETL ใน Perl เพื่อลดต้นทุนของการทดลองทางคลินิกระยะที่ 40 ฉันจำเป็นต้องประมวลผลวันที่ประมาณ 000 รายการ พวกเขาสองคนไม่ผ่านการทดสอบ สิ่งนี้ไม่ได้กวนใจฉันมากนักเพราะวันที่เหล่านี้นำมาจากข้อมูลที่ลูกค้าให้มาซึ่งมักจะน่าประหลาดใจ แต่เมื่อตรวจสอบข้อมูลเดิมพบว่าวันที่เหล่านี้เป็นวันที่ 1 มกราคม 2011 และ 1 มกราคม 2007 ฉันคิดว่ามีข้อผิดพลาดอยู่ในโปรแกรมที่ฉันเพิ่งเขียน แต่ปรากฏว่าเป็นเวลา 30 ปีแล้ว เก่า. สิ่งนี้อาจฟังดูลึกลับสำหรับผู้ที่ไม่คุ้นเคยกับระบบนิเวศของซอฟต์แวร์ เนื่องจากบริษัทอื่นตัดสินใจทำเงินมาอย่างยาวนาน ลูกค้าของฉันจึงจ่ายเงินให้ฉันเพื่อแก้ไขข้อบกพร่องที่บริษัทหนึ่งแนะนำโดยบังเอิญและอีกบริษัทหนึ่งโดยตั้งใจ เพื่อให้เข้าใจถึงสิ่งที่ฉันกำลังพูดถึง ฉันต้องพูดถึงบริษัทที่เพิ่มฟีเจอร์ที่กลายเป็นจุดบกพร่อง รวมถึงเหตุการณ์ที่น่าสนใจอื่นๆ อีกสองสามเหตุการณ์ที่มีส่วนทำให้เกิดจุดบกพร่องลึกลับที่ฉันแก้ไข

ในอดีต คอมพิวเตอร์ของ Apple มักจะรีเซ็ตวันที่เป็นวันที่ 1 มกราคม 1904 โดยอัตโนมัติ เหตุผลง่ายๆ คือ ใช้ "นาฬิการะบบ" ที่ใช้พลังงานแบตเตอรี่เพื่อติดตามวันที่และเวลา เกิดอะไรขึ้นเมื่อแบตเตอรี่หมด? คอมพิวเตอร์เริ่มติดตามวันที่ตามจำนวนวินาทีนับตั้งแต่เริ่มต้นยุค ในยุคนั้น เราหมายถึงวันที่ดั้งเดิมอ้างอิง และสำหรับ Macintoshes คือวันที่ 1 มกราคม 1904 และหลังจากที่แบตเตอรี่หมด วันที่ปัจจุบันก็ถูกรีเซ็ตเป็นวันที่ที่ระบุ แต่ทำไมสิ่งนี้ถึงเกิดขึ้น?

ก่อนหน้านี้ Apple ใช้ 32 บิตเพื่อจัดเก็บจำนวนวินาทีนับตั้งแต่วันที่ดั้งเดิม หนึ่งบิตสามารถเก็บค่าหนึ่งในสองค่า - 1 หรือ 0 สองบิตสามารถเก็บค่าหนึ่งในสี่ค่า: 00, 01, 10, 11 สามบิต - หนึ่งค่าจากแปดค่า: 000, 001, 010, 011, 100 , 101, 110, 111 ฯลฯ และ 32 สามารถเก็บค่าใดค่าหนึ่งจาก 232 ค่า ซึ่งก็คือ 4 วินาที สำหรับวันที่ของ Apple จะเท่ากับประมาณ 294 ปี ดังนั้น Mac รุ่นเก่าๆ จึงไม่สามารถรองรับวันที่หลังปี 967 ได้ และหากแบตเตอรี่ของระบบหมด วันที่จะถูกรีเซ็ตเป็น 296 วินาทีนับตั้งแต่เริ่มต้นยุค และคุณต้องตั้งค่าวันที่ด้วยตนเองทุกครั้งที่เปิดคอมพิวเตอร์ (หรือจนกว่าคุณจะซื้อแบตเตอรี่ใหม่)

อย่างไรก็ตาม การตัดสินใจของ Apple ที่จะจัดเก็บวันที่เป็นวินาทีนับตั้งแต่ยุคนั้น หมายความว่าเราไม่สามารถประมวลผลวันที่ก่อนยุคนั้นได้ ซึ่งจะส่งผลกระทบในวงกว้าง ดังที่เราจะได้เห็น Apple เปิดตัวฟีเจอร์ ไม่ใช่ข้อบกพร่อง เหนือสิ่งอื่นใด นั่นหมายความว่าระบบปฏิบัติการ Macintosh ได้รับการยกเว้นจาก "ข้อผิดพลาดแห่งสหัสวรรษ" (ซึ่งไม่สามารถพูดได้เกี่ยวกับแอปพลิเคชัน Mac จำนวนมากที่มีระบบวันที่ของตัวเองเพื่อหลีกเลี่ยงข้อจำกัด)

ไปข้างหน้า. เราใช้ Lotus 1-2-3 ซึ่งเป็น "แอปพลิเคชันนักฆ่า" ของ IBM ที่ช่วยเปิดตัวการปฏิวัติพีซี แม้ว่าคอมพิวเตอร์ Apple จะมี VisiCalc ซึ่งทำให้คอมพิวเตอร์ส่วนบุคคลประสบความสำเร็จก็ตาม พูดตามตรง หากไม่มี 1-2-3 ปรากฏ พีซีก็คงแทบจะไม่ถูกถอดออก และประวัติความเป็นมาของคอมพิวเตอร์ส่วนบุคคลอาจมีการพัฒนาแตกต่างออกไปมาก โลตัส 1-2-3 ถือว่าปี 1900 เป็นปีอธิกสุรทินอย่างไม่ถูกต้อง เมื่อ Microsoft เปิดตัวสเปรดชีตแรก Multiplan ก็ครองส่วนแบ่งตลาดเพียงเล็กน้อย และเมื่อพวกเขาเปิดตัวโครงการ Excel พวกเขาตัดสินใจไม่เพียงแค่คัดลอกรูปแบบการตั้งชื่อแถวและคอลัมน์จาก Lotus 1-2-3 เท่านั้น แต่ยังรับประกันความเข้ากันได้ของจุดบกพร่องโดยจงใจถือว่าปี 1900 เป็นปีอธิกสุรทิน ปัญหานี้ยังคงมีอยู่ในปัจจุบัน นั่นคือใน 1-2-3 นี่เป็นจุดบกพร่อง แต่ใน Excel เป็นการตัดสินใจอย่างมีสติเพื่อให้แน่ใจว่าผู้ใช้ 1-2-3 ทั้งหมดสามารถนำเข้าตารางของตนไปยัง Excel ได้โดยไม่ต้องเปลี่ยนแปลงข้อมูล แม้ว่าจะไม่ถูกต้องก็ตาม

แต่มีปัญหาอื่น ประการแรก Microsoft เปิดตัว Excel สำหรับ Macintosh ซึ่งไม่รู้จักวันที่ก่อนวันที่ 1 มกราคม พ.ศ. 1904 และใน Excel วันที่ 1 มกราคม พ.ศ. 1900 ถือเป็นจุดเริ่มต้นของยุค ดังนั้นนักพัฒนาจึงทำการเปลี่ยนแปลงเพื่อให้โปรแกรมของพวกเขาจดจำประเภทของยุคและจัดเก็บข้อมูลภายในตัวเองให้สอดคล้องกับยุคที่ต้องการ Microsoft ยังเขียนบทความอธิบายเกี่ยวกับเรื่องนี้ด้วย และการตัดสินใจครั้งนี้นำไปสู่ข้อผิดพลาดของฉัน

ระบบ ETL ของฉันได้รับสเปรดชีต Excel จากลูกค้าที่สร้างขึ้นบน Windows แต่ก็สามารถสร้างบน Mac ได้เช่นกัน ดังนั้นการเริ่มต้นยุคในตารางอาจเป็นวันที่ 1 มกราคม พ.ศ. 1900 หรือวันที่ 1 มกราคม พ.ศ. 1904 จะทราบได้อย่างไร? รูปแบบไฟล์ Excel แสดงข้อมูลที่จำเป็น แต่ parser ที่ฉันใช้ไม่ได้แสดงมัน (ตอนนี้แสดงแล้ว) และสันนิษฐานว่าคุณทราบยุคของตารางเฉพาะ ฉันอาจใช้เวลามากขึ้นในการทำความเข้าใจรูปแบบไบนารี่ของ Excel และส่งแพตช์ไปยังผู้สร้าง parser แต่ฉันยังมีอะไรให้ทำอีกมากมายสำหรับลูกค้า ดังนั้นฉันจึงเขียนฮิวริสติกอย่างรวดเร็วเพื่อกำหนดยุคสมัย เธอเป็นคนเรียบง่าย

ใน Excel วันที่ 5 กรกฎาคม 1998 สามารถแสดงในรูปแบบ "07-05-98" (ระบบอเมริกันไร้ประโยชน์), "5 กรกฎาคม 98", "5 กรกฎาคม 1998", "5-Jul-98" หรือ รูปแบบอื่น ๆ รูปแบบที่ไม่มีประโยชน์อีกรูปแบบหนึ่ง (แดกดัน หนึ่งในรูปแบบที่ Excel เวอร์ชันของฉันไม่มีคือ ISO 8601) อย่างไรก็ตาม ภายในตาราง วันที่ที่ยังไม่ได้จัดรูปแบบจะถูกจัดเก็บเป็น "35981" สำหรับยุค 1900 หรือ "34519" สำหรับยุค 1904 (ตัวเลขแสดงถึงจำนวนวันนับตั้งแต่ยุค) ฉันเพียงแค่ใช้โปรแกรมแยกวิเคราะห์แบบธรรมดาเพื่อแยกปีออกจากวันที่ที่จัดรูปแบบ จากนั้นใช้โปรแกรมแยกวิเคราะห์ของ Excel เพื่อแยกปีออกจากวันที่ที่ไม่ได้จัดรูปแบบ หากค่าทั้งสองแตกต่างกัน 4 ปี ฉันก็รู้ว่าฉันกำลังใช้ระบบที่มียุค 1904

เหตุใดฉันจึงไม่ใช้วันที่ที่จัดรูปแบบแล้ว เนื่องจากวันที่ 5 กรกฎาคม 1998 สามารถจัดรูปแบบเป็น "กรกฎาคม 98" โดยที่วันของเดือนหายไป เราได้รับโต๊ะจากบริษัทมากมายที่สร้างโต๊ะขึ้นมาด้วยวิธีต่างๆ มากมาย ซึ่งขึ้นอยู่กับเรา (ในกรณีนี้คือฉัน) ที่จะคิดหาวันที่ นอกจากนี้ หาก Excel ทำถูกต้อง เราก็ควรทำเช่นกัน!

ในเวลาเดียวกันฉันก็พบกับ 39082 ฉันขอเตือนคุณว่า Lotus 1-2-3 ถือว่า 1900 เป็นปีอธิกสุรทินและสิ่งนี้ถูกทำซ้ำอย่างซื่อสัตย์ใน Excel และเนื่องจากสิ่งนี้เพิ่มหนึ่งวันเข้าไปในปี 1900 ฟังก์ชันการคำนวณวันที่จำนวนมากจึงอาจผิดสำหรับวันนั้น ๆ นั่นคือ 39082 อาจเป็นวันที่ 1 มกราคม 2011 (บน Mac) หรือ 31 ธันวาคม 2006 (บน Windows) หาก "ตัวแยกวิเคราะห์ปี" ของฉันแยกปี 2011 ออกจากค่าที่จัดรูปแบบแล้ว ทุกอย่างก็โอเค แต่เนื่องจากตัวแยกวิเคราะห์ของ Excel ไม่ทราบว่ามีการใช้ยุคใด จึงใช้ค่าเริ่มต้นเป็นยุค 1900 โดยส่งคืนปี 2006 แอปพลิเคชันของฉันเห็นว่าความแตกต่างคือ 5 ปี ซึ่งถือว่าเป็นข้อผิดพลาด จึงบันทึกและส่งคืนค่าที่ไม่ได้ฟอร์แมต

เพื่อหลีกเลี่ยงปัญหานี้ ฉันเขียนสิ่งนี้ (pseudocode):

diff = formatted_year - parsed_year
if 0 == diff
    assume 1900 date system
if 4 == diff
    assume 1904 date system
if 5 == diff and month is December and day is 31
    assume 1904 date system

จากนั้นวันที่ทั้งหมด 40 วันก็ถูกแยกวิเคราะห์อย่างถูกต้อง

ท่ามกลางงานพิมพ์ขนาดใหญ่

ในช่วงต้นทศวรรษ 1980 พ่อของฉันทำงานที่ Storage Technology ซึ่งเป็นแผนกที่ปัจจุบันเลิกผลิตแล้วซึ่งสร้างเทปไดรฟ์และระบบนิวแมติกสำหรับการป้อนเทปด้วยความเร็วสูง

พวกเขาออกแบบไดรฟ์ใหม่เพื่อให้สามารถมีไดรฟ์ "A" ส่วนกลางหนึ่งไดรฟ์ที่เชื่อมต่อกับไดรฟ์ "B" เจ็ดไดรฟ์ และระบบปฏิบัติการขนาดเล็กใน RAM ที่ควบคุมไดรฟ์ "A" สามารถมอบหมายการดำเนินการอ่านและเขียนให้กับไดรฟ์ "B" ทั้งหมดได้

แต่ละครั้งที่ไดรฟ์ "A" เริ่มทำงาน จำเป็นต้องใส่ฟล็อปปี้ดิสก์ลงในไดรฟ์ต่อพ่วงที่เชื่อมต่อกับ "A" เพื่อโหลดระบบปฏิบัติการลงในหน่วยความจำ มันเป็นแบบดั้งเดิมอย่างยิ่ง: พลังการประมวลผลนั้นมาจากไมโครคอนโทรลเลอร์ 8 บิต

กลุ่มเป้าหมายสำหรับอุปกรณ์ดังกล่าวคือบริษัทที่มีคลังข้อมูลขนาดใหญ่มาก เช่น ธนาคาร เครือข่ายร้านค้าปลีก ฯลฯ ซึ่งจำเป็นต้องพิมพ์ฉลากที่อยู่หรือใบแจ้งยอดจากธนาคารจำนวนมาก

ลูกค้ารายหนึ่งประสบปัญหา ในระหว่างงานพิมพ์ ไดรฟ์ “A” ตัวใดตัวหนึ่งอาจหยุดทำงาน ส่งผลให้งานทั้งหมดหยุดชะงัก ในการคืนค่าการทำงานของไดรฟ์ พนักงานต้องรีบูททุกอย่าง และหากสิ่งนี้เกิดขึ้นระหว่างงานหกชั่วโมง เวลาคอมพิวเตอร์ราคาแพงจำนวนมากก็จะหายไป และกำหนดการของการดำเนินการทั้งหมดก็หยุดชะงัก

ช่างเทคนิคถูกส่งมาจาก Storage Technologies แม้จะพยายามอย่างดีที่สุดแล้วก็ตาม พวกเขาไม่สามารถจำลองจุดบกพร่องภายใต้เงื่อนไขการทดสอบได้ ดูเหมือนว่าจะเกิดขึ้นในช่วงกลางของงานพิมพ์ขนาดใหญ่ ปัญหาไม่ได้อยู่ที่ฮาร์ดแวร์ แต่มาแทนที่ทุกสิ่งที่พวกเขาสามารถทำได้: RAM, ไมโครคอนโทรลเลอร์, ฟล็อปปี้ไดรฟ์, ทุกส่วนที่เป็นไปได้ของเทปไดรฟ์ - ปัญหายังคงมีอยู่

จากนั้นช่างเทคนิคก็โทรหาสำนักงานใหญ่และโทรหาผู้เชี่ยวชาญ

ผู้เชี่ยวชาญหยิบเก้าอี้และกาแฟหนึ่งแก้ว นั่งอยู่ในห้องคอมพิวเตอร์ ในสมัยนั้นมีห้องสำหรับคอมพิวเตอร์โดยเฉพาะ และเฝ้าดูพนักงานเข้าคิวงานพิมพ์ขนาดใหญ่ ผู้เชี่ยวชาญกำลังรอให้ความล้มเหลวเกิดขึ้น และมันก็เป็นเช่นนั้น ทุกคนมองไปที่ผู้เชี่ยวชาญ แต่เขาไม่รู้ว่าทำไมสิ่งนี้ถึงเกิดขึ้น เขาจึงสั่งให้จัดคิวงานอีกครั้ง พนักงาน และช่างเทคนิคทุกคนก็กลับมาทำงานอีกครั้ง

ผู้เชี่ยวชาญนั่งลงบนเก้าอี้อีกครั้งและเริ่มรอให้เกิดความล้มเหลว ผ่านไปประมาณหกชั่วโมงและเกิดความล้มเหลว ผู้เชี่ยวชาญไม่มีความคิดอีกครั้ง ยกเว้นว่าทุกอย่างเกิดขึ้นในห้องที่เต็มไปด้วยผู้คน เขาสั่งให้เริ่มภารกิจใหม่ นั่งลงและรอ

จากความล้มเหลวครั้งที่สาม ผู้เชี่ยวชาญสังเกตเห็นบางสิ่งบางอย่าง ความล้มเหลวเกิดขึ้นเมื่อบุคลากรเปลี่ยนเทปในไดรฟ์ต่างประเทศ ยิ่งไปกว่านั้น ความล้มเหลวยังเกิดขึ้นทันทีที่พนักงานคนหนึ่งเดินผ่านกระเบื้องแผ่นหนึ่งบนพื้น

พื้นยกสูงปูกระเบื้องอลูมิเนียมสูง 6-8 นิ้ว สายไฟจำนวนมากจากคอมพิวเตอร์วิ่งอยู่ใต้พื้นยกสูงเพื่อป้องกันไม่ให้ใครไปเหยียบสายเคเบิลสำคัญโดยไม่ได้ตั้งใจ ปูกระเบื้องอย่างแน่นหนาเพื่อป้องกันไม่ให้เศษหินเข้าไปใต้พื้นยก

ผู้เชี่ยวชาญตระหนักว่ากระเบื้องแผ่นหนึ่งมีรูปร่างผิดปกติ เมื่อพนักงานเหยียบมุม ขอบกระเบื้องจะถูกับกระเบื้องที่อยู่ติดกัน ชิ้นส่วนพลาสติกที่เชื่อมต่อกับกระเบื้องก็ถูด้วย ซึ่งทำให้เกิดการปล่อยประจุขนาดเล็กแบบคงที่ซึ่งทำให้เกิดการรบกวนของความถี่วิทยุ

ปัจจุบัน RAM ได้รับการปกป้องจากการรบกวนความถี่วิทยุได้ดีขึ้นมาก แต่ในหลายปีที่ผ่านมาสิ่งนี้ไม่เป็นเช่นนั้น ผู้เชี่ยวชาญตระหนักว่าการรบกวนนี้ทำให้หน่วยความจำหยุดชะงักและส่งผลให้ระบบปฏิบัติการทำงานด้วย เขาโทรติดต่อฝ่ายสนับสนุน สั่งกระเบื้องใหม่ ติดตั้งเอง ปัญหาก็หมดไป

น้ำขึ้นแล้ว!

เรื่องราวเกิดขึ้นในห้องเซิร์ฟเวอร์ บนชั้น XNUMX หรือ XNUMX ของสำนักงานในพอร์ตสมัธ (ผมคิดว่า) ในบริเวณท่าเรือ

วันหนึ่งเซิร์ฟเวอร์ Unix ที่มีฐานข้อมูลหลักเกิดขัดข้อง พวกเขารีบูทเขา แต่เขายังคงล้มลงซ้ำแล้วซ้ำอีกอย่างมีความสุข เราตัดสินใจโทรหาใครบางคนจากบริการสนับสนุน

คนสนับสนุน... ฉันคิดว่าเขาชื่อมาร์ค แต่นั่นไม่สำคัญ... ฉันไม่คิดว่าจะรู้จักเขา มันไม่สำคัญจริงๆ คบกับมาร์คดีกว่ามั้ย? ยอดเยี่ยม.

ดังนั้น ไม่กี่ชั่วโมงต่อมา มาร์คก็มาถึง (ไม่ไกลจากลีดส์ถึงพอร์ตสมัธ) เปิดเซิร์ฟเวอร์และทุกอย่างทำงานได้โดยไม่มีปัญหา การสนับสนุนแบบเดิมๆ ลูกค้าจะรู้สึกไม่พอใจกับเรื่องนี้มาก มาร์คตรวจดูไฟล์บันทึกและไม่พบสิ่งใดที่ไม่ดี มาร์คจึงกลับขึ้นรถไฟ (หรือเดินทางด้วยวิธีใดก็ตามที่เขามาถึง มันอาจจะเป็นวัวง่อยก็ได้นะ... ยังไงซะ มันก็ไม่สำคัญหรอก โอเคไหม?) และมุ่งหน้ากลับไปที่ลีดส์โดยเปล่าประโยชน์ วัน.

เย็นวันเดียวกันนั้นเองเซิร์ฟเวอร์ก็ล่มอีกครั้ง เรื่องราวก็เหมือนเดิม...เซิฟเวอร์ไม่ขึ้น มาร์กพยายามช่วยเหลือจากระยะไกล แต่ลูกค้าไม่สามารถเริ่มเซิร์ฟเวอร์ได้

รถไฟอีกสาย รถบัส เลมอนเมอแรงค์ หรืออะไรไร้สาระอื่นๆ แล้วมาร์คก็กลับมาที่พอร์ตสมัธ ดูสิ เซิร์ฟเวอร์บูทโดยไม่มีปัญหาใดๆ! ความมหัศจรรย์. มาร์กใช้เวลาหลายชั่วโมงในการตรวจสอบว่าทุกอย่างเป็นไปตามระบบปฏิบัติการหรือซอฟต์แวร์ และออกเดินทางสู่ลีดส์

ประมาณช่วงกลางวันเซิร์ฟเวอร์ล่ม (ใจเย็นๆ!) ครั้งนี้ดูเหมือนสมเหตุสมผลที่จะนำผู้ให้การสนับสนุนด้านฮาร์ดแวร์เข้ามาแทนที่เซิร์ฟเวอร์ แต่เปล่าเลย หลังจากผ่านไปประมาณ 10 ชั่วโมง มันก็ตกลงมาเช่นกัน

สถานการณ์ซ้ำรอยเป็นเวลาหลายวัน เซิร์ฟเวอร์ใช้งานได้ เกิดข้อขัดข้องหลังจากผ่านไปประมาณ 10 ชั่วโมง และไม่เริ่มทำงานในอีก 2 ชั่วโมงข้างหน้า พวกเขาตรวจสอบการระบายความร้อน หน่วยความจำรั่ว ตรวจสอบทุกอย่าง แต่ไม่พบอะไรเลย จากนั้นข้อขัดข้องก็หยุดลง

สัปดาห์ผ่านไปอย่างไร้กังวล...ทุกคนมีความสุข มีความสุขจนกว่าทุกอย่างจะเริ่มต้นใหม่อีกครั้ง ภาพก็เหมือนกัน ทำงาน 10 ชั่วโมง หยุดทำงาน 2-3 ชั่วโมง...

แล้วมีคน (ฉันคิดว่าพวกเขาบอกฉันว่าบุคคลนี้ไม่มีส่วนเกี่ยวข้องกับไอที) กล่าวว่า:

"ถึงกระแสน้ำแล้ว!"

เครื่องหมายอัศเจรีย์พบกับการจ้องมองที่ว่างเปล่า และมือของใครบางคนอาจลังเลที่ปุ่มโทรเพื่อความปลอดภัย

“มันหยุดทำงานกับกระแสน้ำ”

นี่ดูเหมือนจะเป็นแนวคิดที่แปลกใหม่โดยสิ้นเชิงสำหรับพนักงานสนับสนุนด้านไอที ซึ่งไม่น่าจะอ่านหนังสือ Tide Yearbook ขณะนั่งดื่มกาแฟ พวกเขาอธิบายว่าสิ่งนี้ไม่เกี่ยวข้องกับกระแสน้ำแต่อย่างใด เนื่องจากเซิร์ฟเวอร์ทำงานมาหนึ่งสัปดาห์โดยไม่มีข้อผิดพลาดใดๆ

“สัปดาห์ที่แล้วน้ำลง แต่สัปดาห์นี้น้ำขึ้นสูง”

คำศัพท์เล็กๆ น้อยๆ สำหรับผู้ที่ไม่มีใบอนุญาตเรือยอชท์ น้ำขึ้นน้ำลงขึ้นอยู่กับวัฏจักรของดวงจันทร์ และในขณะที่โลกหมุน แรงดึงดูดของดวงอาทิตย์และดวงจันทร์ทุกๆ 12,5 ชั่วโมงจะทำให้เกิดคลื่นยักษ์ ช่วงเริ่มต้นของรอบ 12,5 ชั่วโมงน้ำขึ้นสูง กลางรอบน้ำลง และสุดท้ายน้ำขึ้นอีกครั้ง แต่เมื่อวงโคจรของดวงจันทร์เปลี่ยนแปลงไป ความแตกต่างระหว่างน้ำขึ้นและน้ำลงก็เปลี่ยนแปลงเช่นกัน เมื่อดวงจันทร์อยู่ระหว่างดวงอาทิตย์กับโลกหรืออยู่ฝั่งตรงข้ามของโลก (พระจันทร์เต็มดวงหรือไม่มีดวงจันทร์) เราจะได้รับกระแสน้ำ Syzygyn ซึ่งเป็นระดับน้ำสูงสุดและระดับน้ำต่ำสุด เมื่อถึงพระจันทร์ครึ่งเสี้ยว เราจะได้กระแสน้ำสร้างพื้นที่สี่เหลี่ยมจัตุรัส ซึ่งเป็นระดับน้ำต่ำสุด ความแตกต่างระหว่างสุดขั้วทั้งสองลดลงอย่างมาก วงจรดวงจันทร์ใช้เวลา 28 วัน: ไซซิเกียน - การสร้างพื้นที่สี่เหลี่ยมจัตุรัส - ไซซิเจียน - การสร้างพื้นที่สี่เหลี่ยมจัตุรัส

เมื่อช่างเทคนิคได้รับการอธิบายแก่นแท้ของพลังน้ำขึ้นน้ำลง พวกเขาคิดทันทีว่าจำเป็นต้องโทรหาตำรวจ และค่อนข้างสมเหตุสมผล แต่ปรากฎว่าเพื่อนพูดถูก เมื่อสองสัปดาห์ก่อน เรือพิฆาตลำหนึ่งจอดอยู่ไม่ไกลจากที่ทำการ ทุกครั้งที่น้ำขึ้นถึงระดับความสูงที่กำหนด เสาเรดาร์ของเรือจะไปอยู่ที่ระดับพื้นห้องเซิร์ฟเวอร์ และเรดาร์ (หรืออุปกรณ์สงครามอิเล็กทรอนิกส์หรือของเล่นทางทหารอื่น ๆ ) สร้างความโกลาหลในคอมพิวเตอร์

ภารกิจการบินเพื่อจรวด

ฉันได้รับมอบหมายให้ย้ายระบบควบคุมการปล่อยจรวดขนาดใหญ่ (ประมาณ 400 บรรทัด) และระบบติดตามไปยังระบบปฏิบัติการ คอมไพเลอร์ และภาษาเวอร์ชันใหม่ แม่นยำยิ่งขึ้นจาก Solaris 2.5.1 ถึง Solaris 7 และจาก Verdix Ada Development System (VADS) ที่เขียนด้วย Ada 83 ไปจนถึงระบบ Rational Apex Ada ที่เขียนด้วย Ada 95 VADS ถูกซื้อโดย Rational และผลิตภัณฑ์ของมันคือ ล้าสมัยแม้ว่า Rational จะพยายามใช้แพ็คเกจเฉพาะ VADS เวอร์ชันที่เข้ากันได้เพื่อลดความยุ่งยากในการเปลี่ยนไปใช้คอมไพเลอร์ Apex

คนสามคนช่วยฉันในการเรียบเรียงโค้ดอย่างหมดจด ใช้เวลาสองสัปดาห์ จากนั้นฉันก็ทำงานด้วยตัวเองเพื่อทำให้ระบบทำงานได้ กล่าวโดยสรุป มันเป็นสถาปัตยกรรมและการใช้งานระบบซอฟต์แวร์ที่แย่ที่สุดที่ฉันเคยพบมา ดังนั้นจึงต้องใช้เวลาอีกสองเดือนในการพอร์ตให้เสร็จสมบูรณ์ จากนั้นระบบก็ถูกส่งไปทดสอบ ซึ่งใช้เวลาอีกหลายเดือน ฉันแก้ไขข้อบกพร่องที่พบในระหว่างการทดสอบทันที แต่จำนวนลดลงอย่างรวดเร็ว (ซอร์สโค้ดเป็นระบบที่ใช้งานจริง ดังนั้นฟังก์ชันการทำงานจึงค่อนข้างเชื่อถือได้ ฉันแค่ต้องลบข้อบกพร่องที่เกิดขึ้นระหว่างการปรับให้เข้ากับคอมไพเลอร์ใหม่) ในที่สุด เมื่อทุกอย่างทำงานได้ตามปกติ ฉันจึงถูกย้ายไปยังโครงการอื่น

และในวันศุกร์ก่อนวันขอบคุณพระเจ้า โทรศัพท์ก็ดังขึ้น

การปล่อยจรวดควรจะได้รับการทดสอบภายในเวลาประมาณสามสัปดาห์ และในระหว่างการทดสอบการนับถอยหลังในห้องปฏิบัติการ ลำดับคำสั่งถูกบล็อก ในชีวิตจริง สิ่งนี้จะยกเลิกการทดสอบ และหากการอุดตันเกิดขึ้นภายในไม่กี่วินาทีหลังจากสตาร์ทเครื่องยนต์ การกระทำหลายอย่างที่ไม่สามารถย้อนกลับได้จะเกิดขึ้นในระบบเสริม ซึ่งจะต้องอาศัยความพร้อมของจรวดที่ยาวนานและมีราคาแพง แม้จะยังไม่เริ่ม แต่หลายๆ คนคงจะเสียใจมากกับการเสียเวลาและเงินจำนวนมาก อย่าให้ใครบอกคุณว่ากระทรวงกลาโหมใช้จ่ายเงินอย่างไม่ระมัดระวัง ฉันไม่เคยพบผู้จัดการที่ทำสัญญาที่ไม่ให้ความสำคัญกับงบประมาณก่อนหรือหลังแล้วตามด้วยกำหนดการ

ในเดือนที่ผ่านมา การแข่งขันนับถอยหลังนี้จัดขึ้นหลายร้อยครั้งในรูปแบบต่างๆ มากมาย โดยมีข้อผิดพลาดเล็กน้อยเพียงเล็กน้อยเท่านั้น ดังนั้นโอกาสที่สิ่งนี้จะเกิดขึ้นจึงต่ำมาก แต่ผลที่ตามมามีนัยสำคัญมาก คูณปัจจัยทั้งสองนี้แล้วคุณจะเข้าใจว่าข่าวดังกล่าวทำนายสัปดาห์วันหยุดที่พังทลายสำหรับฉันและวิศวกรและผู้จัดการหลายสิบคน

และให้ความสนใจกับฉันในฐานะบุคคลที่ย้ายระบบ

เช่นเดียวกับระบบที่มีความสำคัญต่อความปลอดภัยส่วนใหญ่ พารามิเตอร์จำนวนมากถูกบันทึกไว้ ดังนั้นจึงค่อนข้างง่ายที่จะระบุโค้ดสองสามบรรทัดที่ถูกดำเนินการก่อนที่ระบบจะเสียหาย และแน่นอนว่าไม่มีอะไรผิดปกติเลย สำนวนเดียวกันนี้ถูกดำเนินการสำเร็จหลายพันครั้งในระหว่างการวิ่งครั้งเดียวกัน

เราเรียกผู้คนจาก Apex มาเป็น Rational เพราะพวกเขาคือคนที่พัฒนาคอมไพเลอร์ และรูทีนบางส่วนที่พวกเขาพัฒนาถูกเรียกด้วยโค้ดที่น่าสงสัย พวกเขา (และคนอื่นๆ) รู้สึกประทับใจที่จำเป็นต้องค้นหาต้นตอของปัญหาที่มีความสำคัญระดับชาติอย่างแท้จริง

เนื่องจากไม่มีอะไรน่าสนใจในวารสาร เราจึงตัดสินใจลองจำลองปัญหาในห้องปฏิบัติการในพื้นที่ นี่ไม่ใช่เรื่องง่ายเนื่องจากเหตุการณ์เกิดขึ้นประมาณหนึ่งครั้งต่อการวิ่ง 1000 ครั้ง เหตุผลที่น่าสงสัยประการหนึ่งคือการเรียกฟังก์ชัน mutex ที่ผู้ขายพัฒนาขึ้น (ส่วนหนึ่งของแพ็คเกจการโยกย้าย VADS) Unlock ไม่ได้นำไปสู่การปลดล็อค เธรดการประมวลผลที่เรียกว่าฟังก์ชันประมวลผลข้อความฮาร์ทบีท ซึ่งมาถึงทุกวินาทีในนาม เราเพิ่มความถี่เป็น 10 Hz ซึ่งก็คือ 10 ครั้งต่อวินาที และเริ่มทำงาน หลังจากนั้นประมาณหนึ่งชั่วโมง ระบบก็ล็อคตัวเอง ในบันทึก เราเห็นว่าลำดับของข้อความที่บันทึกไว้เหมือนกับระหว่างการทดสอบที่ล้มเหลว เราดำเนินการวิ่งอีกหลายครั้ง ระบบถูกบล็อกอย่างต่อเนื่องหลังจากเริ่มต้น 45-90 นาที และทุกครั้งที่บันทึกมีเส้นทางเดียวกัน แม้ว่าในทางเทคนิคแล้วเราจะใช้โค้ดที่แตกต่างกัน แต่ความถี่ของข้อความก็ต่างกัน ลักษณะการทำงานของระบบก็เหมือนกัน ดังนั้นเราจึงมั่นใจว่าสถานการณ์การโหลดนี้ทำให้เกิดปัญหาเดียวกัน

ตอนนี้เราจำเป็นต้องหาให้แน่ชัดว่าการบล็อกเกิดขึ้นที่ใดในลำดับของนิพจน์

การใช้งานระบบนี้ใช้ระบบงาน Ada และใช้งานได้แย่มาก งานเป็นโครงสร้างที่สามารถเรียกใช้งานได้พร้อมกันในระดับสูงใน Ada ซึ่งคล้ายกับเธรดของการดำเนินการซึ่งสร้างขึ้นในภาษาเท่านั้น เมื่อสองงานจำเป็นต้องสื่อสารกัน พวกเขา "นัดพบกัน" แลกเปลี่ยนข้อมูลที่จำเป็น จากนั้นหยุดการนัดพบและกลับสู่การดำเนินการที่เป็นอิสระ อย่างไรก็ตาม ระบบมีการใช้งานแตกต่างออกไป หลังจากที่งานเป้าหมายถูกนัดพบ งานเป้าหมายนั้นจะนัดพบกับงานอื่น ซึ่งจากนั้นนัดพบกับงานที่สาม และต่อไปเรื่อยๆ จนกว่าการประมวลผลบางอย่างจะเสร็จสิ้น หลังจากนั้นการพบปะทั้งหมดนี้ก็เสร็จสิ้นและแต่ละงานก็ต้องกลับมาดำเนินการอีกครั้ง นั่นคือเรากำลังเผชิญกับระบบการเรียกฟังก์ชันที่แพงที่สุดในโลก ซึ่งหยุดกระบวนการ "มัลติทาสก์" ทั้งหมดในขณะที่ประมวลผลข้อมูลอินพุตบางส่วน และก่อนหน้านี้ไม่ได้นำไปสู่ปัญหาเพียงเพราะปริมาณงานต่ำมาก

ฉันอธิบายกลไกของงานนี้เพราะเมื่อมีการร้องขอหรือคาดว่าจะเสร็จสิ้น "การสลับงาน" อาจเกิดขึ้นได้ นั่นคือโปรเซสเซอร์สามารถเริ่มประมวลผลงานอื่นที่พร้อมที่จะดำเนินการได้ ปรากฎว่าเมื่องานหนึ่งพร้อมที่จะพบกับงานอื่น งานที่แตกต่างไปจากเดิมอย่างสิ้นเชิงสามารถเริ่มดำเนินการได้ และในที่สุดการควบคุมจะกลับสู่การนัดพบครั้งแรก และเหตุการณ์อื่น ๆ ที่อาจเกิดขึ้นซึ่งทำให้งานต้องสลับ; เหตุการณ์หนึ่งคือการเรียกฟังก์ชันระบบ เช่น การพิมพ์หรือการดำเนินการ mutex

เพื่อทำความเข้าใจว่าโค้ดบรรทัดใดที่เป็นสาเหตุของปัญหา ฉันจำเป็นต้องค้นหาวิธีบันทึกความคืบหน้าตามลำดับคำสั่งโดยไม่ต้องกระตุ้นให้มีการสลับงาน ซึ่งจะป้องกันไม่ให้เกิดข้อขัดข้อง ฉันก็เลยเอาเปรียบไม่ได้ Put_Line()เพื่อหลีกเลี่ยงการดำเนินการ I/O ฉันสามารถตั้งค่าตัวแปรตัวนับหรือสิ่งที่คล้ายกันได้ แต่ฉันจะดูค่าของมันได้อย่างไรหากไม่สามารถแสดงบนหน้าจอได้

นอกจากนี้ เมื่อตรวจสอบบันทึก ปรากฎว่าแม้การประมวลผลข้อความฮาร์ทบีทจะหยุดนิ่ง ซึ่งบล็อกการดำเนินการ I/O ทั้งหมดของกระบวนการ และป้องกันไม่ให้ประมวลผลอื่นๆ แต่งานอิสระอื่นๆ ยังคงถูกดำเนินการต่อไป นั่นคืองานไม่ได้ถูกปิดกั้นโดยสิ้นเชิง เป็นเพียงสายโซ่ของงาน (วิกฤต) เท่านั้น

นี่เป็นเบาะแสที่จำเป็นในการประเมินนิพจน์การบล็อก

ฉันสร้างแพ็คเกจ Ada ที่มีงาน ประเภทที่แจกแจง และตัวแปรโกลบอลประเภทนั้น ตัวอักษรจำนวนนับถูกผูกไว้กับการแสดงออกซึ่งจำเพาะของลำดับที่เป็นปัญหา (เช่น Incrementing_Buffer_Index, Locking_Mutex, Mutex_Unlocked) จากนั้นแทรกนิพจน์การกำหนดลงในนั้น ซึ่งกำหนดการแจงนับที่สอดคล้องกันให้กับตัวแปรส่วนกลาง เนื่องจากโค้ดอ็อบเจ็กต์ทั้งหมดนี้เก็บค่าคงที่ไว้ในหน่วยความจำ การสลับงานอันเป็นผลมาจากการดำเนินการจึงไม่น่าเป็นไปได้อย่างยิ่ง โดยพื้นฐานแล้วเราสงสัยเกี่ยวกับนิพจน์ที่อาจสลับงานได้ เนื่องจากการบล็อกเกิดขึ้นในการดำเนินการแทนที่จะส่งคืนเมื่อเปลี่ยนงานกลับ (ด้วยเหตุผลหลายประการ)

งานติดตามเพียงดำเนินการเป็นวงและตรวจสอบเป็นระยะเพื่อดูว่าค่าของตัวแปรร่วมมีการเปลี่ยนแปลงหรือไม่ การเปลี่ยนแปลงแต่ละครั้ง ค่าจะถูกบันทึกลงในไฟล์ จากนั้นรอสักครู่และเช็คใหม่ ฉันเขียนตัวแปรลงในไฟล์เนื่องจากงานถูกดำเนินการเฉพาะเมื่อระบบเลือกสำหรับการดำเนินการเมื่อสลับงานในพื้นที่ปัญหา สิ่งที่เกิดขึ้นในงานนี้จะไม่ส่งผลกระทบต่องานอื่น ๆ ที่ไม่เกี่ยวข้องที่ถูกบล็อก

คาดว่าเมื่อระบบถึงจุดดำเนินการโค้ดที่มีปัญหา ตัวแปรส่วนกลางจะถูกรีเซ็ตเมื่อย้ายไปยังแต่ละนิพจน์ถัดไป จากนั้นจะมีบางอย่างเกิดขึ้นซึ่งทำให้งานสลับ และเนื่องจากความถี่ในการดำเนินการ (10 Hz) ต่ำกว่าความถี่ของงานการตรวจสอบ จอภาพจึงสามารถจับค่าของตัวแปรร่วมและเขียนค่าดังกล่าวได้ ในสถานการณ์ปกติ ฉันสามารถรับลำดับการทำซ้ำของชุดย่อยของการแจงนับ: ค่าสุดท้ายของตัวแปร ณ เวลาที่สวิตช์งาน เมื่อหยุดทำงาน ตัวแปรร่วมไม่ควรเปลี่ยนแปลงอีกต่อไป และค่าสุดท้ายที่เขียนจะระบุว่านิพจน์ใดที่ไม่สมบูรณ์

ฉันรันโค้ดพร้อมการติดตาม เขาตัวแข็ง และการเฝ้าติดตามก็ทำงานเหมือนเครื่องจักร

บันทึกประกอบด้วยลำดับที่คาดไว้ ซึ่งถูกขัดจังหวะด้วยค่าที่ระบุว่ามีการเรียก mutex Unlockและงานยังไม่เสร็จสมบูรณ์ - เช่นเดียวกับการโทรครั้งก่อนๆ นับพันครั้ง

วิศวกรของ Apex กำลังวิเคราะห์โค้ดอย่างเอาจริงเอาจังในเวลานี้ และพบจุดหนึ่งใน mutex ที่ซึ่งตามทฤษฎีแล้ว อาจเกิดการล็อกได้ แต่ความน่าจะเป็นนั้นต่ำมาก เนื่องจากมีเพียงลำดับเหตุการณ์บางอย่างที่เกิดขึ้นในช่วงเวลาหนึ่งเท่านั้นที่สามารถนำไปสู่การบล็อกได้ กฎของเมอร์ฟี่ มันคือกฎของเมอร์ฟี่

เพื่อปกป้องส่วนของโค้ดที่ฉันต้องการ ฉันจึงแทนที่การเรียกใช้ฟังก์ชัน mutex (ที่สร้างขึ้นจากฟังก์ชัน mutex ของระบบปฏิบัติการ) ด้วยแพ็คเกจ Ada mutex แบบเนทีฟขนาดเล็กเพื่อควบคุมการเข้าถึง mutex ไปยังส่วนนั้น

ฉันใส่มันลงในโค้ดและทำการทดสอบ เจ็ดชั่วโมงต่อมารหัสยังคงทำงานอยู่

รหัสของฉันถูกส่งไปยัง Rational ซึ่งพวกเขารวบรวม แยกชิ้นส่วน และตรวจสอบว่าไม่ได้ใช้วิธีการเดียวกันกับที่ใช้ในฟังก์ชัน mutex ที่มีปัญหา

นี่เป็นการรีวิวโค้ดที่มีคนหนาแน่นที่สุดในอาชีพของฉัน 🙂 มีวิศวกรและผู้จัดการประมาณสิบคนอยู่ในห้องเดียวกับฉัน และอีกสิบคนอยู่ในการประชุมทางโทรศัพท์ - และพวกเขาทั้งหมดตรวจสอบโค้ดประมาณ 20 บรรทัด

รหัสได้รับการตรวจสอบ มีการรวบรวมไฟล์ปฏิบัติการใหม่และส่งสำหรับการทดสอบการถดถอยอย่างเป็นทางการ สองสามสัปดาห์ต่อมา การทดสอบการนับถอยหลังประสบความสำเร็จ และจรวดก็ทะยานขึ้น

โอเค นั่นคือทั้งหมดที่ดีและดี แต่ประเด็นของเรื่องนี้คืออะไร?

มันเป็นปัญหาที่น่าขยะแขยงอย่างยิ่ง โค้ดหลายแสนบรรทัด การดำเนินการแบบขนาน กระบวนการโต้ตอบมากกว่าหนึ่งโหล สถาปัตยกรรมที่ไม่ดีและการนำไปใช้งานที่ไม่ดี อินเทอร์เฟซสำหรับระบบฝังตัว และการใช้จ่ายหลายล้านดอลลาร์ ไม่มีความกดดันใช่ไหม

ฉันไม่ใช่คนเดียวที่ทำงานเกี่ยวกับปัญหานี้ แม้ว่าฉันจะถูกจับตามองในขณะที่กำลังย้ายพอร์ตก็ตาม แม้ว่าฉันจะทำมัน แต่นั่นไม่ได้หมายความว่าฉันเข้าใจโค้ดหลายแสนบรรทัด หรือแม้แต่อ่านผ่านๆ รหัสและบันทึกได้รับการวิเคราะห์โดยวิศวกรทั่วประเทศ แต่เมื่อพวกเขาบอกฉันเกี่ยวกับสมมติฐานเกี่ยวกับสาเหตุของความล้มเหลว ฉันใช้เวลาเพียงครึ่งนาทีในการหักล้างพวกเขา และเมื่อฉันถูกขอให้วิเคราะห์ทฤษฎี ฉันจะส่งต่อให้คนอื่น เพราะเห็นได้ชัดว่าวิศวกรเหล่านี้กำลังเดินไปผิดทาง ฟังดูอวดดีเหรอ? ใช่ นี่เป็นเรื่องจริง แต่ฉันปฏิเสธสมมติฐานและคำขอด้วยเหตุผลอื่น

ฉันเข้าใจธรรมชาติของปัญหา ฉันไม่รู้ว่ามันเกิดขึ้นที่ไหนหรือทำไม แต่ฉันรู้ว่ากำลังเกิดอะไรขึ้น

ในช่วงหลายปีที่ผ่านมาฉันได้สั่งสมความรู้และประสบการณ์มากมาย ฉันเป็นหนึ่งในผู้บุกเบิกการใช้ Ada และเข้าใจข้อดีและข้อเสียของมัน ฉันรู้ว่าไลบรารีรันไทม์ของ Ada จัดการงานและจัดการกับการดำเนินการแบบขนานได้อย่างไร และฉันเข้าใจการเขียนโปรแกรมระดับต่ำในระดับหน่วยความจำ รีจิสเตอร์ และแอสเซมเบลอร์ กล่าวอีกนัยหนึ่ง ฉันมีความรู้เชิงลึกในสาขาของฉัน และฉันใช้มันเพื่อค้นหาสาเหตุของปัญหา ฉันไม่เพียงแค่แก้ไขจุดบกพร่องเท่านั้น แต่ยังเข้าใจวิธีค้นหาจุดบกพร่องในสภาพแวดล้อมรันไทม์ที่ละเอียดอ่อนมาก

เรื่องราวของการต่อสู้กับโค้ดนั้นไม่น่าสนใจมากสำหรับผู้ที่ไม่คุ้นเคยกับคุณสมบัติและเงื่อนไขของการต่อสู้ดังกล่าว แต่เรื่องราวเหล่านี้ช่วยให้เราเข้าใจว่าต้องทำอย่างไรในการแก้ปัญหาที่ยากจริงๆ

ในการแก้ปัญหาที่ยากจริงๆ คุณต้องเป็นมากกว่าแค่โปรแกรมเมอร์ คุณต้องเข้าใจ "ชะตากรรม" ของโค้ด วิธีโต้ตอบกับสภาพแวดล้อม และวิธีการทำงานของสภาพแวดล้อม

แล้วคุณจะมีสัปดาห์วันหยุดที่พังทลายของคุณเอง

จะยังคง

ที่มา: will.com