การจัดการกับข้อบกพร่องที่ไม่สามารถทำซ้ำได้

สมมติว่าทีมของคุณเขียนระบบซอฟต์แวร์ที่ทำงานได้ค่อนข้างดี

วันหนึ่งวิศวกรคนหนึ่งเรียกใช้แบบสอบถาม SQL บางอย่างที่เปลี่ยนข้อมูล DB บางส่วนแล้วลืมเรื่องนั้นไป

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

คุณจัดการกับสิ่งนี้ได้อย่างไร

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

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

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

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

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

วันหนึ่งวิศวกรคนหนึ่งเรียกใช้แบบสอบถาม SQL บางอย่างที่เปลี่ยนข้อมูล DB บางส่วนแล้วลืมเรื่องนั้นไป

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

นี่ไม่ใช่ข้อผิดพลาด

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

คุณจัดการกับสิ่งนี้ได้อย่างไร

ค่อนข้างง่ายโดยไม่ปล่อยให้วิศวกรเปลี่ยนการผลิตหรือฐานข้อมูลการพัฒนาร่วมกัน

สมมติว่านี่เป็นฐานข้อมูลการพัฒนาร่วมกัน:

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

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

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

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

สมมติว่านี่เป็นฐานข้อมูลการผลิต:

หาก devs ของคุณกำลังเปลี่ยนแปลงฐานข้อมูลการผลิตหลายสิ่งผิดพลาดอย่างน่ากลัวแม้ว่าการเปลี่ยนแปลงจะถูกต้องอย่างแน่นอน

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

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

หากคุณต้องการทดสอบบางอย่างในฐานข้อมูลการผลิต ... ไม่คุณไม่ต้องการ การทดสอบใด ๆ ที่คุณต้องทำคุณควรทำในตัวอย่างการพัฒนา หากคุณต้องการข้อมูลเพื่อทำการทดสอบคุณจะได้รับข้อมูลนั้น

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

ในกรณีนี้ในที่สุดคุณก็สามารถหาสาเหตุได้ แต่สมมุติว่าคุณไม่ได้ ...

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

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

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

1. อธิบายกับผู้จัดการโครงการของคุณว่าคุณคิดว่าสาเหตุที่เป็นไปได้มากที่สุดคือการเข้าถึงฐานข้อมูลด้วยตนเอง
2. หากพวกเขายังต้องการให้คุณมองหารหัสที่เป็นสาเหตุให้ไปและลองดูรหัสอีกครั้ง
3. กลับมาในอีกสองสามชั่วโมง (หรือบางเวลาที่เหมาะสม) และบอกว่าคุณไม่สามารถหารหัสใด ๆ ที่จะทำให้เกิดปัญหานี้ได้ดังนั้นคุณยังเชื่อว่าสาเหตุที่เป็นไปได้มากที่สุดคือการเข้าถึงฐานข้อมูลด้วยตนเอง
4. หากพวกเขายังต้องการให้คุณมองหารหัสถามว่าพวกเขาต้องการให้คุณใช้เวลาเท่าไหร่ เตือนพวกเขาอย่างละเอียดว่าคุณจะไม่ทำงานบนฟีเจอร์ X ข้อผิดพลาด Y หรือการปรับปรุง Z ในขณะที่คุณกำลังทำ
5. ใช้เวลามากเท่าที่พวกเขาถาม หากคุณยังคิดว่าสาเหตุที่เป็นไปได้มากที่สุดคือการเข้าถึงฐานข้อมูลด้วยตนเองให้บอกสิ่งนี้
6. หากพวกเขายังต้องการให้คุณมองหารหัสให้เพิ่มปัญหาเนื่องจากนี่เป็นการใช้เวลาของทีมอย่างไม่ก่อผล

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

ฉันทำงานกับทีมพัฒนาสำหรับผลิตภัณฑ์ฐานข้อมูลเมนเฟรมเมื่อลูกค้ารายงานว่าพวกเขามีฐานข้อมูลเสียหาย ความเสียหายในแง่ที่ว่าสถานะภายในของบิตบนแผ่นดิสก์หมายความว่าฐานข้อมูลนั้นไม่สามารถอ่านได้ผ่านซอฟต์แวร์ฐานข้อมูล ในโลกของลูกค้าเมนเฟรมกำลังจ่ายเงินให้คุณ $ ล้านและคุณต้องทำสิ่งนี้อย่างจริงจัง นี่คือสิ่งที่เราทำ:

ขั้นตอนที่ 0: ช่วยลูกค้าในการเริ่มต้นและทำงานอีกครั้งโดยการซ่อมแซมฐานข้อมูล

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

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

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

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

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

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

แต่คุณควรมีกระบวนการปฏิบัติงานมาตรฐานเกี่ยวกับการเปลี่ยนแปลงข้อมูลในการผลิต ตัวอย่างเช่นไม่ควรเปลี่ยนข้อมูล DBA ไม่มีนักพัฒนาควรดำเนินการเปลี่ยนแปลงด้วยตนเองและควรกำหนดให้มีการเปลี่ยนแปลงทางไปรษณีย์หรือตั๋วอย่างเป็นทางการตามที่กำหนดไว้ใน SOP

จะต้องมีคำพูดเช่นนี้อยู่ที่ไหนสักแห่งถ้าไม่ใช่คุณสามารถพูดกับฉันได้ที่:

มีเหตุผลที่ดีอย่างสมบูรณ์แบบสำหรับพ่อครัวที่ไม่รับผิดชอบต่อการทำความสะอาดห้องน้ำ

มีหลายสิ่งที่ต้องทำกับข้อบกพร่องที่ไม่สามารถทำซ้ำได้

1. สร้างตั๋วสำหรับมัน

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

2. ทำการวิเคราะห์ที่แข็ง

ดูระบบสิ่งที่ล้มเหลวและความล้มเหลว ลองค้นหารหัสพื้นที่ที่สามารถอัปเดตเพื่อทำให้เกิดความล้มเหลวได้น้อย ตัวอย่างบางส่วน ...

• แทนที่โค้ดโฆษณาด้วยการโทรเฉพาะ (เช่นเดียวexecute(<query>)กับexecuteMyStoredProcedure(<params>)
• เรียกใช้สคริปต์ตรวจสอบทุกคืนเพื่อตรวจสอบความถูกต้องของข้อมูล (เพื่อให้สามารถตรวจพบได้ภายใน 24 ชั่วโมงในครั้งต่อไป)
• เพิ่ม / ปรับปรุงการบันทึกและการเก็บถาวร (สำรอง)
• เปลี่ยนขีดจำกัดความปลอดภัยที่ไม่เหมาะสม (ตัวอย่างเช่นผู้คน / โปรแกรมที่อ่านข้อมูลเท่านั้นไม่มีสิทธิ์ในการเขียนไม่อนุญาตให้นักพัฒนาที่ไม่รับผิดชอบการผลิตไม่สามารถเข้าสู่เซิร์ฟเวอร์การผลิตได้)
• เพิ่มการตรวจสอบข้อมูล / สุขาภิบาลที่หายไป

สิ่งนี้อาจไม่แก้ไขข้อผิดพลาด แต่ถึงแม้ว่ามันจะไม่เป็นเช่นนั้น แต่ตอนนี้ระบบมีความเสถียร / ปลอดภัยมากขึ้นดังนั้นมันจึงยังคงจ่ายอยู่

3. เพิ่มระบบเตือน

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

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

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

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