Viết bản tóm tắt thiết kế VPN mà ai đó thực sự có thể xem xét

Hầu hết các buổi xem xét thiết kế đều dừng ở câu hỏi đầu tiên, vì yêu cầu mô tả một sản phẩm chứ không phải một quyết định. Một bản tóm tắt nêu tên các luồng, người sở hữu và hành vi khi thất bại có thể được trả lời trong một cuộc họp. Một bản tóm tắt nói hãy xây dựng một VPN an toàn hoàn toàn không thể trả lời được. Hãy đi qua sáu bước kiểm tra dưới đây trước khi gửi bất cứ điều gì, và buổi xem xét trở thành một so sánh thay vì một cuộc tranh luận.

Thứ nhất, câu hỏi là một quyết định hay một mong muốn

Một quyết định có các lựa chọn thay thế và một quan sát sẽ chọn giữa chúng. Nếu bạn không thể nêu ra bạn sẽ nhìn vào đâu để chọn một, câu hỏi vẫn là một mong muốn. Trước tiên hãy viết ra các lựa chọn thay thế, kể cả khi danh sách chỉ có hai mục. Sau đó viết ra sự đánh đổi phân tách chúng.

Một mong muốn cũng có xu hướng che giấu người đọc. Hãy nói ai phải phê duyệt thiết kế, vì cùng một bản tóm tắt được đọc khác nhau bởi chủ sở hữu mạng, người đánh giá bảo mật và người phê duyệt tài chính.

Hãy dừng ở đây nếu câu trả lời là không ai, vì một quyết định không có chủ sở hữu sẽ bị làm lại bởi người phàn nàn to nhất. Đó là vấn đề quản trị chứ không phải vấn đề thiết kế.

Thứ hai, nêu tên các luồng và các từ chối

Liệt kê nguồn, đích và ứng dụng cho mọi luồng phải hoạt động. Sau đó liệt kê các luồng phải tiếp tục thất bại, vì một thiết kế âm thầm cho phép chúng đã thay đổi yêu cầu mà không nói ra. Sự chồng lấn địa chỉ và khả năng tiếp cận ngược dòng thuộc danh sách này như những ràng buộc chứ không phải bất ngờ.

Hãy cụ thể về hướng. Một địa điểm có thể khởi tạo kết nối tới trụ sở là một thiết kế khác với địa điểm chỉ có thể chấp nhận chúng, và sự khác biệt xuất hiện trong mọi quy tắc bạn viết sau đó.

Cũng hãy ghi chú các máy khách và trạng thái quản lý của chúng, vì một thiết bị được quản lý có tác nhân có thể làm những việc mà máy tính xách tay tự mang đến không làm được.

Giữ danh sách đủ ngắn để kiểm tra. Mười luồng bạn có thể xác minh tốt hơn bốn mươi luồng bạn không thể.

Kiểm tra 3: tách sự kiện khỏi giả định

Đánh dấu mọi phát biểu bạn đã xác minh, và đánh dấu những phát biểu bạn chưa xác minh. Địa chỉ công cộng, thông lượng khả dụng và quyền truy cập quản trị viên là ba giả định thường thay đổi câu trả lời nhất. Nếu một trong số đó chưa biết, hãy nói thiết kế thay đổi thế nào khi nó lộ ra theo bất kỳ hướng nào.

Một mạng minh họa thì ổn miễn là được dán nhãn. Vấn đề là một chi nhánh giả định âm thầm có thêm một đường lên thứ hai hoặc một khối địa chỉ công cộng mà nó chưa từng có.

Hãy xác minh giả định bạn có thể kiểm tra trước buổi xem xét, vì một sự kiện được đo lường loại bỏ cả một nhánh thảo luận.

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

Thứ tư, viết hợp đồng thất bại

Hãy nói điều gì xảy ra khi đường hầm ngừng hoạt động, và nêu rõ hai lời hứa khác nhau. Khôi phục các kết nối mới sau khi kết nối lại thì dễ hứa. Giữ lại các phiên đã được thiết lập qua một sự cố là một yêu cầu mạnh hơn nhiều, và nó ràng buộc việc lựa chọn công nghệ.

Sau đó quyết định phương án dự phòng: chặn lưu lượng, chuyển nó qua một đường đã được phê duyệt khác, hoặc làm điều gì đó khác cho từng ứng dụng. Quay lại âm thầm về đường trực tiếp cũng là một quyết định thiết kế kể cả khi không ai viết ra.

Thêm mục tiêu khôi phục bằng ngôn ngữ đơn giản, chẳng hạn một địa điểm có thể hoạt động trong trạng thái suy giảm bao lâu, và ai tuyên bố sự cố.

Kiểm tra 5 và 6: chọn đường nối và ghi lại thay đổi

Chọn một đường nối để tranh luận, vì một buổi xem xét cố gắng giải quyết mọi thứ thì không giải quyết được gì. Định tuyến, cấp quyền và mã hóa là ba đường nối khác nhau, và bản tóm tắt nên nói câu hỏi thuộc về đường nào. RFC 4301 là một lời nhắc hữu ích ở đây, vì nó tách các quyết định chính sách, lưu lượng được bảo vệ và các hiệp hội bảo mật thay vì coi chúng là một đối tượng.

Sau đó ghi lại điều gì đã thay đổi sau quyết định, bao gồm các giả định đã sửa. Chính bản ghi đó làm cho buổi xem xét tiếp theo ngắn hơn.

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

Một bản tóm tắt vượt qua cả sáu bước kiểm tra tạo ra một câu hỏi có câu trả lời: thiết kế đáp ứng các luồng đã nêu và hợp đồng thất bại, hoặc một ràng buộc được nêu tên ngăn cản điều đó. Khi ràng buộc thay đổi sau này, bản ghi cho thấy quyết định nào phải xem lại và quyết định nào có thể giữ nguyên. Đó là điều làm cho bài tập này có thể tái sử dụng chứ không phải một cuộc tranh luận một lần.