Belajar Vitess - Production Hardening & Best Practices

#Pendahuluan

Episode 21 menutup dengan SLO dan alerting — tanda layanan yang diukur dan dijaga. Episode 22 adalah episode terakhir dari series Belajar Vitess. Tidak ada konsep baru yang berat; yang ada adalah penyaringan dan perangkuman. Semua yang pernah kalian pelajari di 22 episode sebelumnya akan dikunci menjadi satu tujuan: Vitess yang aman, terkelola, dan bisa bertahan bertahun-tahun di produksi.

Roadmap episode 22: security hardening checklist, scaling dan failover readiness, runbook dan ownership, lalu upgrade Vitess dan MySQL yang aman, ditutup refleksi perjalanan dari episode 0 sampai di sini. Anggap episode ini sebagai ujian akhir yang terbuka — bukan untuk dihafal, tapi untuk dipakai saat kalian benar-benar menjalankan Vitess di produksi.

#Security Hardening Checklist

Hardening bukan satu langkah besar, tapi kumpulan langkah kecil yang saling melengkapi. Daftar periksa di bawah ini bisa dijalankan sebagai gerbang sebelum rilis atau sebagai evaluasi berkala.

Control plane. Batasi siapa yang bisa menyentuh Vitess. vtctld dan Topology Service sebaiknya hanya bisa diakses dari jaringan internal atau VPN, bukan terekspos publik. Terapkan RBAC Kubernetes paling ketat yang masih bisa dikerjakan, dan pastikan dashboard serta API admin tidak bisa diakses aplikasi. Amankan kredensial admin dengan rotasi terjadwal.

Data plane dan transport. Pastikan TLS aktif di semua hop: client ke VTGate, VTGate ke VTTablet, dan VTTablet ke MySQL (episode 12). Verifikasi NetworkPolicy membatasi traffic hanya ke port dan namespace yang dibutuhkan. Pastikan user aplikasi tidak punya hak DDL dan akses langsung ke tablet dilarang (episode 13).

Secret management. Tidak ada secret di git, tidak ada password di values.yaml. Kredensial MySQL, topology, dan backup dikelola lewat Kubernetes Secret dan external secret manager (episode 11). Rotasi password secara berkala dan audit siapa yang bisa membaca secret.

vtctlclient ListShardHealth
vtctlclient GetTopologyInfo
kubectl get networkpolicies -n vitess
kubectl get secrets -n vitess

vtctlclient ListShardHealth memverifikasi kesehatan shard, GetTopologyInfo memastikan topology konsisten, kubectl get networkpolicies memastikan isolasi jaringan aktif, dan kubectl get secrets menampilkan daftar secret yang ada. Jalankan perintah ini di CI atau audit berkala, bukan hanya saat insiden.

#Scaling dan Failover Readiness

Skala dan ketersediaan hanya bisa dipercaya jika diuji. Checklist readiness untuk produksi:

Scaling. Desain sharding key sudah final dan stabil (episode 4). Vindex utama sudah dipilih dengan benar, dan query hot path tidak scatter (episode 5). Kapasitas shard dipantau dan resharding direncanakan sebelum shard penuh (episode 16). Replica RDONLY tersedia di setiap shard untuk reporting dan backup (episode 17).

Failover. Prosedur PlannedReparentShard dan EmergencyReparentShard terdokumentasi dan pernah diuji (episode 6). Replication lag dipantau dengan alert (episode 21). Backup diuji restore-nya secara rutin, dan backup topologi bisa di-recover (episode 18 dan 20). Region cadangan siap jika DR dibutuhkan (episode 14).

#Runbook dan Ownership

Dokumentasi operasional adalah aset yang paling sering dilupakan sampai darurat. Runbook yang baik menjawab pertanyaan: "saat X terjadi, siapa melakukan apa, dalam urutan apa?"

Struktur runbook yang disarankan untuk setiap skenario penting:

• Gejala — metrik dan log yang menandakan masalah.
• Dampak — apa yang terganggu dan seberapa parah.
• Tindakan — langkah perbaikan urut, dengan perintah persis.
• Eskalasi — siapa yang dihubungi jika langkah tidak berhasil.
• Verifikasi — bukti bahwa masalah sudah selesai.

Skenario yang wajib punya runbook: primary failure, region outage, replication lag parah, resharding gagal, backup gagal, dan topology tidak konsisten.

Ownership melengkapi runbook: setiap komponen dan setiap runbook punya pemilik yang jelas. Jika tidak ada pemilik, perawatan diabaikan. Tetapkan pemilik untuk VTGate, VTTablet, Topology Service, backup, dan skema. Pemilik bertanggung jawab atas kesehatan dan pembaruan dokumentasi area masing-masing.

#Upgrading Vitess dan MySQL dengan Aman

Upgrade adalah salah satu operasi paling berisiko — dan paling rutin. Prinsipnya: rencana, uji, lalu eksekusi bertahap. Checklist upgrade:

• Baca release notes: ketahui perubahan perilaku dan deprecation versi baru.
• Upgrade staging dulu: uji di environment yang menyerupai produksi.
• Backup lengkap: backup data dan topology sebelum mulai.
• Ikuti urutan: VTGate dulu (stateless), lalu VTTablet bertahap.
• Pantau: bandingkan metrik sebelum dan sesudah (episode 21).
• Rencana rollback: tahu cara mundur jika upgrade bermasalah.

helm list -n vitess
helm upgrade vitess vitess/vitess -f values.yaml --namespace vitess --version 21.0.1
kubectl rollout status deploy/vtgate -n vitess

helm list -n vitess menampilkan versi terpasang, helm upgrade menaikkan versi, dan kubectl rollout status menunggu sampai selesai. Upgrade MySQL serupa: verifikasi kompatibilitas versi dengan Vitess, uji di staging, lalu naikkan per shard secara bertahap.

#Refleksi Perjalanan Series

Mari kita berhenti sejenak dan melihat kembali jalan yang sudah kalian tempuh.

Fase 1 (episode 0-2) membangun fondasi: environment, sejarah Vitess, dan arsitektur VTGate, VTTablet, Topology Service, keyspace, shard, dan vindex. Fase 2 (episode 3-7) membuat kalian terbiasa dengan operasi dasar: instalasi, keyspace dan shard, query routing, replikasi dan failover, serta observability.

Fase 3 (episode 8-11) menaikkan kedalaman: schema dan vindexes, transaksi dan konsistensi, online migration, serta konfigurasi dan secrets. Fase 4 (episode 12-14) membuka ranah keamanan dan jaringan: TLS, access control dan audit, serta multi-region dan DR.

Fase 5 (episode 15-18) membawa Vitess ke level lanjutan: performance tuning, resharding, hybrid workload dan OLAP, serta control plane dan topology. Fase 6 (episode 19-22) menutup siklus: CI/CD dan release, disaster recovery, SLO, dan hardening yang baru saja kalian susun.

Sepanjang jalan, ada pola yang berulang: kuasai vindex sebelum sharding, fast path sebelum scatter, observasi sebelum mengubah, backup sebelum upgrade, dan dokumentasi sebelum panik. Pola-pola ini bukan khusus Vitess — ia berlaku untuk platform database mana pun. Yang kalian kuasai di series ini bukan sekadar fitur per fitur, melainkan cara berpikir operasional yang utuh.

#Penutup

Perjalanan ini selesai, dan layak diingat secara utuh. Kalian mulai dari pertanyaan paling dasar di episode 0, mengenal Vitess dan arsitekturnya di episode 1-2, lalu bertahap menguasai operasi, keamanan, observability, hingga skala besar dan kesiapan produksi. Kini kalian tidak lagi bertanya "apa itu shard?", melainkan "bagaimana keyspace ini di-shard, diamankan, dan diskalakan selama bertahun-tahun?".

Inti yang harus dibawa pulang dari seluruh series:

• Vitess menang karena arsitektur: VTGate yang stateless, VTTablet yang mengelola MySQL, dan Topology Service sebagai sumber kebenaran.
• Sharding yang baik dimulai dari desain: pilih sharding key yang stabil, dan pastikan query hot path tidak scatter.
• Setiap transaksi ingin jadi single-shard: co-location adalah prinsip desain paling ampuh.
• Observability, SLO, dan alerting bukan pelengkap, melainkan kunci untuk percaya diri mengubah produksi.
• Backup yang teruji, failover yang dilatih, dan upgrade yang direncanakan menjaga Vitess sehat dalam jangka panjang.
• Proses yang terdokumentasi dan dieksekusi akan bertahan; kebiasaan perorangan tidak.

Terima kasih sudah menemani sampai episode terakhir. Semua konsep dalam series ini sekarang menjadi milik kalian — saatnya keluar, membangun database yang skalabel dan terkelola dengan Vitess, dan terus belajar di setiap insiden yang kalian tangani. Langkah berikutnya ada di tangan kalian: jalankan di lab, buat kesalahan kecil, dan biarkan setiap kesalahan memperkuat runbook. Sampai jumpa di series berikutnya!