Belajar Network Engineer - Network Design & Documentation

#Pendahuluan

Setelah di episode 24 kalian bisa membuktikan performa dengan angka, sekarang kita bahas skill yang menentukan apakah semua kemampuan itu bernilai bagi organisasi: merancang dan mendokumentasikan. Fakta pahit lapangan: jaringan terburuk biasanya bukan hasil engineer bodoh, melainkan hasil desain yang tak pernah ada dan dokumentasi yang tertinggal tiga tahun dari realita.

Episode ini menyatukan seluruh series menjadi metodologi kerja formal — dan berakhir pada satu deliverable besar: dokumen desain lengkap studi kasus kita.

#Requirement Gathering: Sebelum Satu Diagram Digambar

Kesalahan pemula: langsung memilih vendor/topologi. Kesalahan senior jarang. Desain dimulai dari pertanyaan, bukan jawaban:

#Kebutuhan Bisnis (Bahasa Manajemen)

• Apa fungsi kritikal? Berapa biaya downtime per jam?
• Timeline & budget: sekarang atau bertahap?
• Growth: rencana rekrutmen/expansi 3 tahun?
• Kepatuhan: ISO 27001? Regulasi industri?

#Kebutuhan Teknis (Bahasa Engineer)

Output tahap ini satu dokumen ringkas: requirements specification — yang kelak menjadi alasan setiap keputusan desain bisa dipertanggungjawabkan ("kami pilih dual ISP karena downtime ERP dihargai RpX/jam").

#Logical Design vs Physical Design

Dua lapisan dokumen yang wajib dipisah — mencampurnya adalah sumber kebingungan klasik:

• Logical design: bagaimana jaringan berpikir — subnet/VLAN plan, routing domains, zona keamanan, IP addressing schema. Bebas dari merek kabel.
• Physical design: bagaimana jaringan berdiri — posisi rack, model perangkat, port mapping, jenis kabel, path riser, power feed.

Mengapa dipisah? Karena physical berubah tiap maintenance, sedangkan logical stabil bertahun-tahun. Reviewer manajemen cukup membaca logical; technician eksekusi bekerja di physical.

#Standar Diagram yang Bisa Dibaca Orang Lain

Diagram adalah bahasa utama profesi ini. Standar minimal yang membuat diagram kalian dipercaya:

1. Satu diagram = satu tujuan: jangan campur L1 fisik, VLAN, dan routing dalam satu gambar.
2. Legenda: simbol, warna link speed, garis putus untuk redundant.
3. Metadata: tanggal, versi, penulis, status (design/as-built) — diagram tanpa tanggal adalah misinformasi berjalan.
4. Naming konsisten: acc-lt1-sw01 bukan "switch baru dekat pantry".
5. Level detail tepat: overview untuk rapat; port-level untuk teknisi — dua file terpisah.

Tooling praktis: draw.io/diagrams.net gratis dan cukup; PlantUML/Mermaid untuk diagram-as-code yang ikut git; Visio/Lucidchart di lingkungan korporat. Pilihan tool kurang penting daripada disiplin update.

#Source of Truth: NetBox dan Sahabatnya

Diagram menjelaskan; database mengendalikan. NetBox (open source, DCIM+IPAM) menjadi standar de facto source of truth jaringan:

• IPAM: subnet, VLAN, rentang cadangan — persis IP plan episode 3, tapi queryable.
• DCIM: rack, device, port mapping, kabel.
• API-first: script Python episode 12 bisa membaca/menulis data nyata — inventaris otomatis, playbook Ansible episode 13 men-target peran dari NetBox, bukan spreadsheet usang.

Rantainya inilah yang membedakan tim matang: desain → data → otomasi saling merujuk satu sumber. Spreadsheet terpisah milik tiap engineer adalah kebalikan dari semuanya.

#Runbook: Prosedur Saat Tangan Gemetar

Runbook adalah dokumen operasional untuk situasi spesifik — ditulis untuk pembaca yang panik pukul 03.00. Struktur yang efektif:

## Gejala
- Alarm WAN-SBY down di monitoring; cabang offline total.
 
## Verifikasi cepat
1. show interfaces gi0/0 (edge SBY) -> down/up?
2. ping 8.8.8.8 dari edge SBY -> ISP issue vs internal?
 
## Aksi
A. Link ISP-A down  : verifikasi BGP failover ke ISP-B (show ip bgp summary)
B. Router down      : konfirmasi HSRP aktif di router-B; eskalasi RMA vendor
C. Fiber gedung     : hubungi telco NOC (nomor di bawah), ticket ref format...
 
## Eskalasi
- Telco NOC   : +62-xxx (SLA 30 menit)
- Vendor TAC  : portal + kontrak nomor...
## Riwayat insiden serupa
- 2026-03-14: fiber putus riser barat, MTTR 47 menit.

Perhatikan karakternya: langkah bernomor yang bisa dieksekusi tanpa konteks tambahan, angka kontak nyata, dan riwayat — runbook hidup yang diperbarui tiap insiden.

#Change Management: Disiplin yang Menyelamatkan

Episode 10 sudah menyebutnya sebagai sumber insiden; kini formalisasinya:

1. Change request: apa, kenapa, risiko, rollback plan, uji validasi.
2. Review: disetujui pemilik layanan terdampak.
3. Window: di luar jam produksi; komunikasi awal.
4. Eksekusi: sesuai dokumen, bukan improvisasi.
5. Verifikasi: checklist post-change (episode 23: failover masih oke?).
6. Post-review: dokumentasi as-built diperbarui — atau change itu belum selesai.

Untuk perubahan berisiko tinggi, pasangkan dengan teknik aman: config backup otomatis (episode 12), dry-run Ansible (episode 13), dan reload timer (reload in 15) saat mengubah akses remote.

#Praktik: Proyek Desain Lengkap Studi Kasus

Saatnya merakit semuanya. Deliverable Network Design Document (NDD) kantor 120 user — struktur yang bisa kalian pakai ulang:

01 Executive Summary        : 1 halaman, bahasa manajemen
02 Requirements             : bisnis + teknis (tabel episode atas)
03 Logical Design           : topology logical, VLAN/IP plan (ep.3),
                              routing design (ep.5), security zones (ep.9)
04 Physical Design          : rack layout, BOM + estimasi, cabling path
05 Services                 : DNS/DHCP/NAT/FHRP (ep.8), wireless plan (ep.7)
06 HA & Resilience          : matriks SPOF + redundansi (ep.23)
07 Security                 : hardening switch (ep.9), NGFW rulebase (ep.18),
                              remote access/ZTNA (ep.19)
08 Operations               : monitoring design (ep.10), QoS policy (ep.11),
                              backup konfigurasi, runbooks
09 Automation               : inventory NetBox, baseline Ansible (ep.13)
10 Migration Plan           : fase cut-over + rollback tiap fase
11 Appendix                 : diagram L1/L2/L3, tabel lengkap

Dokumen ini punya nilai rangkap: portofolio interview (bisa menjelaskan tiap halaman = penguasaan series ini), dan template nyata pekerjaan pertama kalian. Kerjakan serius sekali, pakai ulang bertahun-tahun dengan penyesuaian minor.

#Common Pitfalls

• Desain tanpa requirement tertulis — keputusan jadi selera; tiap revisi tanpa dasar akan berujung perang pendapat.
• As-built tidak pernah di-update — enam bulan kemudian diagram berbohong; masukkan update dokumentasi sebagai langkah wajib change management.
• Dokumentasi tersebar personal — drive pribadi engineer yang resign = amnesia organisasi; satu repo/sistem bersama, satu pemilik proses.
• Over-engineering — lima sembilan untuk warung kopi; ukuran desain harus proporsional requirement, bukan ego arsitek.

#Penutup

Inti yang harus dibawa pulang:

• Desain dimulai dari requirement gathering dua bahasa: dampak bisnis dan parameter teknis.
• Pisahkan logical (subnet/zona/routing) dari physical (rack/port/kabel) — keduanya hidup dengan siklus berbeda.
• Diagram profesional punya legenda, metadata, naming, dan satu tujuan per gambar; NetBox mengubah data menjadi source of truth yang menyambung otomasi.
• Runbook + change management mengubah pengetahuan tribal menjadi kapabilitas organisasi.
• NDD studi kasus kita adalah portofolio utuh: 11 bab yang merangkum seluruh materi series.

Di episode 26 kita pandang ke depan: ekosistem dan tren modern 2026 — automation sebagai kewajiban, SDN mainstream, cloud/hybrid dominan, AIOps, dan bagaimana profil network SRE mengubah aturan main karir kalian. Sampai jumpa!