Belajar Staff Engineer - Complex Systems Delivery

#Pendahuluan

Setelah di episode 11 kita menyelesaikan fase kepemimpinan inti dengan konflik dan keputusan — reversibilitas, disagree and commit, dan decision log — kita masuk Fase 3: workload, konfigurasi & data management. Episode pembukanya: complex systems delivery. Inilah pekerjaan yang paling khas arketipe Tech Lead dari episode 1: membawa sistem kompleks — banyak komponen, banyak tim, bulan-bulan eksekusi — sampai benar-benar berjalan di produksi.

Mengapa episode ini penting? Karena proyek besar jarang gagal mendadak; ia gagal perlahan lewat integrasi yang ditunda, mutu yang dikorbankan demi tanggal, dan kejutan yang disembunyikan. Staff engineer adalah orang yang merancang agar kegagalan perlahan itu terlihat dini.

#Anatomi Deliverable Kompleks

Sistem kompleks punya tiga ciri yang membuatnya berbeda dari fitur biasa:

1. Integrasi adalah mayoritas pekerjaan — komponen individual mudah; sambungan antar komponen (data flow, failure mode, timing) adalah tempat semua kesulitan hidup.
2. Kegagalan bersifat emergent — tiap bagian lolos test sendirian, tetapi kombinasi tertentu (retry storm saat failover) hanya muncul di sistem utuh.
3. Jalur balik mahal — setelah data bermigrasi atau klien mengadopsi API baru, memutar keadaan hampir mustahil.

Konsekuensi desain eksekusinya: rencana kalian harus memajukan integrasi sedini mungkin dan menjaga jalur balik tetap hidup selama mungkin.

#Memecah Menjadi Tranches Berisiko Rendah

Jangan pecah proyek besar berdasarkan modul teknis ("tim A bangun service X, tim B service Y, integrasi nanti"). Pecah berdasarkan tranche perilaku end-to-end: irisan tipis yang bisa dibawa sampai produksi dan memberi nilai nyata.

Contoh: migrasi checkout monolit ke arsitektur event-driven.

Manfaat tranche: risiko terdistribusi, pembelajaran awal, dan setiap tranche adalah milestone demonstrable ala episode 7. Kalau proyek harus dihentikan di T2, organisasi masih punya nilai.

#Integration Gates: Menjaga Mutu Tanpa Polisi

Mutu sistem kompleks dijaga oleh gerbang otomatis, bukan tekad moral. Pasang gates ini sejak tranche pertama:

• Contract tests wajib hijau — pelanggaran kontrak antar layanan memblokir merge, bukan ditandai "nanti".
• Zero-diff verification — saat migrasi, jalankan jalur lama dan baru paralel; bandingkan hasilnya otomatis. Selisih apa pun jadi alarm, bukan catatan kaki.
• Load test per tranche — skenario traffic puncak termasuk pola buruk (spike, retry, partial failure).
• Rollback drill — latihan memutar tranche terakhir sebelum lanjut; rollback yang belum pernah dicoba adalah ilusi.

./scripts/shadow-compare.sh --duration 48h --sample 5% \
  --old checkout-v1 --new checkout-v2 \
  --fail-on-mismatch --report artifacts/zero-diff.html

#Koordinasi Lintas Tim Saat Eksekusi

Ritme koordinasi inisiatif besar (menggabungkan praktik episode 5 dan 7):

1. Status async mingguan — progres per tranche, bloker, keputusan dibutuhkan.
2. Integration freeze window — periode tenang sebelum cutover: tidak ada perubahan pada area sentuh, semua fokus stabilisasi.
3. Peta risiko hidup — tabel risiko teratas dengan pemilik mitigasinya; direview tiap sync, bukan disimpan untuk audit.
4. Single source of truth — satu dokumen/dashboard yang jujur; dua sumber status berarti tidak ada sumber status.

Untuk risiko, format ringkas yang cukup:

R1 Settlement mismatch saat partial failure   [TINGGI]
   Mitigasi: zero-diff gate T2 + alarm selisih > 0.01%
   Pemilik: tim billing - selesai minggu depan
R2 Kapasitas event bus saat peak              [SEDANG]
   Mitigasi: load test 3x peak historis sebelum T2
   Pemilik: platform - terjadwal pekan-6

Aturan penting: risiko tanpa pemilik dan langkah konkret bukan manajemen risiko — hanya daftar ketakutan.

#Menangani Kejutan di Tengah Jalan

Proyek multi-bulan pasti punya kejutan. Protokol respons:

1. Ukur dampaknya dulu — "discovery ini menunda T2 dua pekan karena skema legacy ternyata punya duplikasi" lebih berguna daripada "kita ada masalah".
2. Perbarui rencana secara eksplisit — scope, tanggal, atau resource mana yang berubah? Pilih sadar, jangan biarkan semuanya tergelincir diam-diam (iron triangle).
3. Komunikasikan lebih awal, bukan saat deadline — sponsor bisa menerima kabar buruk minggu ke-4; mereka tak bisa menerima kejutan minggu ke-16.
4. Catat sebagai pelajaran proses — kejutan yang sama tidak boleh mengejutkan dua kali; masukkan ke checklist discovery proyek berikutnya.

#Pitfall Umum Delivery Sistem Kompleks

• Big-bang integration di akhir — semua komponen baru bertemu pertama kali saat uji menyeluruh; hasilnya selalu spektakuler dan selalu buruk. Integrasi dini, terus-menerus.
• Parallel workstream tanpa titik sinkron — lima tim berlari lima arah; tanpa integration checkpoint rutin, deviasi kecil mengompound.
• Menunda operasional — monitoring, alerting, runbook, dan on-call handover sering jadi item "setelah go-live". Padahal itulah yang menentukan apakah go-live bertahan hidup.
• Success theater saat cutover — merayakan deploy sukses padahal stabilitas 30 hari pertama belum terbukti. Definisikan "selesai" termasuk masa stabil tanpa insiden terkait.
• Jalur lama tidak pernah mati — sistem ganda menghisap biaya selamanya; deprekasi adalah bagian dari definisi selesai (tranche T4).

#Penutup

Inti yang harus dibawa pulang:

• Sistem kompleks = integrasi sebagai pekerjaan utama, kegagalan emergent, jalur balik mahal — rancang eksekusi sesuai tiganya.
• Pecah berdasarkan tranche perilaku end-to-end, bukan modul teknis; tiap tranche bernilai sendirian.
• Mutu dijaga gates otomatis: contract tests, zero-diff, load test, rollback drill — gate yang bisa dilanggar diam-diam bukan gate.
• Kejutan ditangani dengan pengukuran dampak, rencana yang diperbarui eksplisit, dan komunikasi awal.

Di episode 13 selanjutnya kita akan membahas tech debt & platform initiatives — cara mengukur dan memprioritaskan utang teknis dengan bahasa yang dipahami manajemen, serta memimpin inisiatif platform yang membayar dirinya sendiri. Sampai jumpa di episode 13!