เขียนบรีฟการออกแบบ VPN ที่ใครบางคนสามารถรีวิวได้จริง

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

ข้อแรก คำถามคือการตัดสินใจหรือความปรารถนา

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

ความปรารถนามักซ่อนผู้ฟังด้วย บอกว่าใครต้องอนุมัติการออกแบบ เพราะบรีฟเดียวกันถูกอ่านต่างกันโดยเจ้าของเครือข่าย ผู้ตรวจสอบความปลอดภัย และผู้อนุมัติการเงิน

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

ข้อสอง ระบุโฟลว์และการปฏิเสธ

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

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

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

ทำให้รายการสั้นพอที่จะทดสอบได้ สิบโฟลว์ที่ตรวจสอบได้ดีกว่าสี่สิบโฟลว์ที่ตรวจสอบไม่ได้

การตรวจสอบ 3: แยกข้อเท็จจริงออกจากสมมติฐาน

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

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

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

ip route get 10.50.0.10
traceroute -n -m 6 10.50.0.10
nc -vz 10.50.0.10 443

ข้อสี่ เขียนสัญญาความล้มเหลว

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

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

เพิ่มเป้าหมายการกู้คืนด้วยภาษาธรรมดา เช่น ไซต์สามารถทำงานในสถานะเสื่อมได้นานเท่าใด และใครประกาศเหตุการณ์

การตรวจสอบ 5 และ 6: เลือกตะเข็บและบันทึกการเปลี่ยนแปลง

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

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

git diff --stat design/vpn-brief.md
grep -n 'assumption' design/vpn-brief.md
ip route get 10.50.0.10

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