Belajar Chief Technology Officer - Business Continuity & DR
Business continuity memastikan operasi berjalan meski terjadi disruption, sementara disaster recovery memastikan sistem bisa dipulihkan. Di episode ini kalian memahami RPO/RTO, DR drills, dan resilience strategy yang menjadi tanggung jawab CTO untuk melindungi bisnis dari disruption besar.
#Pendahuluan
Setelah di episode 21 kita memahami M&A & technical due diligence, pada episode ini kita membahas business continuity (BC) dan disaster recovery (DR) -- dua konsep yang menentukan apakah organisasi bisa bertahan dari disruption besar seperti bencana alam, serangan siber, atau kegagalan infrastruktur.
CTO bertanggung jawab memastikan sistem yang dibangun bisa pulih dari bencana dengan data loss minimal dan downtime sesingkat mungkin. Tanpa BC/DR planning, satu insiden bisa mengakhiri bisnis.
#RPO dan RTO
#Definisi
- RPO (Recovery Point Objective) -- seberapa banyak data yang bisa diterima hilang. RPO 1 jam berarti kalian bersedia kehilangan data maksimal 1 jam terakhir.
- RTO (Recovery Time Objective) -- seberapa cepat sistem harus pulih. RTO 4 jam berarti sistem harus kembali online dalam 4 jam setelah bencana.
#Trade-off RPO/RTO vs Cost
| RPO/RTO | Biaya | Cocok untuk |
|---|---|---|
| RPO: 0, RTO: 0 (zero downtime) | Sangat tinggi | Financial, healthcare |
| RPO: 1 jam, RTO: 1 jam | Tinggi | E-commerce, SaaS utama |
| RPO: 24 jam, RTO: 4 jam | Sedang | Internal tools |
| RPO: 1 minggu, RTO: 24 jam | Rendah | Non-critical systems |
Note
RPO dan RTO harus ditentukan oleh dampak bisnis, bukan oleh kemampuan teknis. CFO harus terlibat dalam menentukan berapa banyak data loss dan downtime yang bisa diterima per unit waktu. RPO/RTO 0 mungkin terdengar ideal, tetapi biayanya bisa melebihi dampak downtime itu sendiri.
#Business Continuity Plan
#Komponen BCP
| Komponen | Deskripsi |
|---|---|
| Risk assessment | Identifikasi potensi disruption dan probabilitasnya |
| Business impact analysis | Dampak finansial dan operasional dari setiap disruption |
| Recovery strategies | Strategi untuk memulihkan operasi |
| Plan development | Dokumen detail langkah-langkah recovery |
| Testing & exercises | Uji BCP secara berkala |
| Maintenance | Update BCP setiap ada perubahan signifikan |
#BCP untuk Tech Organization
1. Critical systems inventory
- Sistem yang paling berdampak pada revenue
- Sistem yang paling berdampak pada pengguna
- Sistem yang paling berdampak pada compliance
2. Dependencies mapping
- Infrastructure dependencies
- Third-party service dependencies
- Team dependencies
3. Communication plan
- Internal communication channels
- External communication channels
- Escalation procedures
4. Recovery procedures
- Step-by-step recovery untuk setiap critical system
- Contingency plans jika primary recovery gagal
5. Vendor & contact list
- Vendor emergency contacts
- Internal team contacts
- Legal & PR contacts#Disaster Recovery
#DR Strategies
| Strategi | Description | RPO/RTO |
|---|---|---|
| Backup & restore | Backup periodik, restore manual saat bencana | Jam-hari / jam-hari |
| Pilot light | Minimal infrastructure yang selalu running | Menit / menit-jam |
| Warm standby | Reduced version yang selalu running | Detik / menit |
| Multi-site active-active | Full deployment di beberapa region | Near-zero / near-zero |
#DR Testing
DR plan yang tidak pernah diuji adalah DR plan yang tidak berfungsi. Jenis testing:
| Jenis | Deskripsi | Frekuensi |
|---|---|---|
| Tabletop exercise | Walkthrough skenario tanpa eksekusi teknis | Quarterly |
| Component testing | Uji komponen spesifik (restore backup, failover) | Monthly |
| Full DR drill | Simulasi bencana penuh | Annually |
| Chaos engineering | Eksperimen kegagalan yang terkontrol (Chaos Monkey) | Continuous |
#Chaos Engineering
Chaos engineering menguji resilience dengan menyuntikkan kegagalan secara terkontrol:
- Chaos Monkey -- mematikan instance secara acak.
- Gremlin -- platform chaos engineering enterprise.
- Litmus -- chaos engineering untuk Kubernetes.
Warning
Jangan mulai dari chaos engineering yang agresif. Mulai dari tabletop exercise, lalu component testing, baru kemudian full DR drill. Chaos engineering yang dilakukan tanpa kesiapan hanya akan menciptakan kekacauan nyata alih-alih pengujian yang terkontrol.
#Resilience Strategy
#Desain untuk Failure
Setiap sistem harus didesain dengan asumsi kegagalan akan terjadi:
- Redundancy -- komponen kritis harus punya backup.
- Circuit breaker -- hentikan cascading failure.
- Retry with backoff -- coba ulang dengan exponential delay.
- Graceful degradation -- kurangi fungsionalitas alih-alih total outage.
- Health checks -- monitor kesehatan setiap komponen.
#Multi-Region Strategy
- Active-passive -- region aktif dan standby. Failover manual atau otomatis.
- Active-active -- beberapa region aktif secara bersamaan. Load balancing di depan.
- DNS-based failover -- alihkan traffic ke region yang sehat jika region utama down.
#Penutup
Inti yang harus dibawa pulang:
- RPO dan RTO harus ditentukan berdasarkan dampak bisnis, bukan kemampuan teknis.
- BCP harus diuji secara berkala -- tabletop exercise, component testing, dan full DR drill.
- Chaos engineering efektif untuk menguji resilience, tapi mulai dari yang sederhana.
- Desain untuk failure -- asumsi kegagalan akan terjadi dan siapkan redundansi.
Di episode 23 selanjutnya kita akan membahas executive leadership & board -- board dynamics, investor relations, dan strategic narrative. Pastikan kalian sudah memahami BC/DR, karena board akan menanyakan kesiapan organisasi menghadapi disruption!