Tulis ringkasan desain VPN yang benar-benar bisa ditinjau seseorang

Sebagian besar tinjauan desain terhenti pada pertanyaan pertama, karena permintaan itu menjelaskan produk, bukan keputusan. Ringkasan yang menyebutkan aliran, pemilik, dan perilaku kegagalan dapat dijawab dalam satu rapat. Ringkasan yang berbunyi bangun VPN yang aman sama sekali tidak dapat dijawab. Lakukan enam pemeriksaan di bawah sebelum mengirim apa pun, dan tinjauan berubah menjadi perbandingan alih-alih debat.

Pertama, apakah pertanyaannya keputusan atau keinginan

Keputusan memiliki alternatif dan pengamatan yang akan memilih di antaranya. Jika Anda tidak dapat menyebutkan apa yang akan Anda lihat untuk memilih salah satunya, pertanyaannya masih keinginan. Tuliskan dulu alternatifnya, meski daftarnya hanya dua butir. Lalu tuliskan kompromi yang memisahkannya.

Keinginan juga cenderung menyembunyikan audiens. Sebutkan siapa yang harus menyetujui desain, karena ringkasan yang sama dibaca berbeda oleh pemilik jaringan, peninjau keamanan, dan penyetuju keuangan.

Berhenti di sini jika jawabannya tidak ada, karena keputusan tanpa pemilik akan dibuat ulang oleh siapa pun yang mengeluh paling keras. Itu masalah tata kelola, bukan masalah desain.

Kedua, sebutkan aliran dan penolakannya

Daftarkan sumber, tujuan, dan aplikasi untuk setiap aliran yang harus berfungsi. Lalu daftarkan aliran yang harus terus gagal, karena desain yang diam-diam mengizinkannya telah mengubah persyaratan tanpa mengatakannya. Tumpang tindih alamat dan keterjangkauan hulu termasuk dalam daftar ini sebagai batasan, bukan kejutan.

Bersikaplah spesifik soal arah. Situs yang boleh memulai koneksi ke kantor pusat adalah desain yang berbeda dari situs yang boleh menerimanya, dan perbedaannya tampak di setiap aturan yang Anda tulis sesudahnya.

Catat juga klien dan status pengelolaannya, karena perangkat terkelola dengan agen bisa melakukan hal yang tidak bisa dilakukan laptop yang dibawa sendiri.

Jaga daftar cukup pendek untuk diuji. Sepuluh aliran yang bisa Anda verifikasi lebih baik daripada empat puluh yang tidak bisa.

Pemeriksaan 3: pisahkan fakta dari asumsi

Tandai setiap pernyataan yang sudah Anda verifikasi, dan tandai yang belum. Pengalamatan publik, throughput yang tersedia, dan akses administrator adalah tiga asumsi yang paling sering mengubah jawaban. Jika salah satunya tidak diketahui, katakan bagaimana desain berubah saat hasilnya ke salah satu arah.

Jaringan ilustratif tidak masalah asalkan diberi label. Masalahnya adalah cabang hipotetis yang diam-diam memperoleh uplink kedua atau blok alamat publik yang tidak pernah dimilikinya.

Verifikasi asumsi yang bisa Anda periksa sebelum tinjauan, karena satu fakta terukur menghapus seluruh cabang diskusi.

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

Keempat, tulis kontrak kegagalan

Sebutkan apa yang terjadi saat terowongan mati, dan tegas soal dua janji yang berbeda. Memulihkan koneksi baru setelah tersambung ulang mudah dijanjikan. Mempertahankan sesi yang sudah terbentuk melewati kegagalan adalah persyaratan yang jauh lebih kuat, dan itu membatasi pilihan teknologi.

Lalu tentukan cadangannya: blokir lalu lintas, arahkan lewat jalur lain yang disetujui, atau lakukan sesuatu yang berbeda per aplikasi. Kembali diam-diam ke jalur langsung adalah keputusan desain meski tidak ada yang menuliskannya.

Tambahkan target pemulihan dalam bahasa sederhana, seperti berapa lama situs boleh beroperasi dalam keadaan menurun, dan siapa yang menyatakan insiden.

Pemeriksaan 5 dan 6: pilih sambungan dan catat perubahannya

Pilih satu sambungan untuk diperdebatkan, karena tinjauan yang mencoba menyelesaikan semuanya tidak menyelesaikan apa pun. Perutean, otorisasi, dan enkripsi adalah tiga sambungan berbeda, dan ringkasan harus menyebut yang mana yang menjadi pokok pertanyaan. RFC 4301 adalah pengingat berguna di sini, karena memisahkan keputusan kebijakan, lalu lintas terlindungi, dan asosiasi keamanan alih-alih memperlakukannya sebagai satu objek.

Lalu catat apa yang berubah setelah keputusan, termasuk asumsi yang direvisi. Catatan itulah yang membuat tinjauan berikutnya lebih singkat.

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

Ringkasan yang lolos keenam pemeriksaan menghasilkan pertanyaan dengan jawaban: desain memenuhi aliran yang disebutkan dan kontrak kegagalan, atau kendala yang disebutkan mencegahnya. Saat kendala berubah kemudian, catatan menunjukkan keputusan mana yang harus ditinjau ulang dan mana yang bisa bertahan. Itulah yang membuat latihan ini dapat dipakai ulang, bukan debat sekali jalan.