> ## Documentation Index
> Fetch the complete documentation index at: https://itec-docs.digitcodestudio.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Skema BCP & Prosedur Tanggap Insiden

> Rencana Kelangsungan Bisnis (Business Continuity Plan), target RPO/RTO, skema failover, dan prosedur baku saat terjadi insiden teknis

## Gambaran Umum BCP

*Business Continuity Plan* (BCP) PT ITEC Solution Indonesia dirancang untuk memastikan operasional pengujian lingkungan, integritas data hukum LHU, dan layanan klien pada [[https://portal.itec-indonesia.com](https://portal.itec-indonesia.com)](https://portal.itec-indonesia.com) tetap beroperasi atau pulih dengan cepat ketika terjadi gangguan infrastruktur, kegagalan jaringan, atau serangan siber.

```mermaid theme={null}
flowchart TD
    A["Deteksi Gangguan / Insiden"] --> B["Triase & Klasifikasi Tingkat Keparahan"]
    B --> C{"Tingkat Keparahan (Severity)"}
    C -- "P1 (Kritis - Server Down)" --> D["Aktivasi Failover Container / VPS"]
    C -- "P2 (Mayor - DB Degraded)" --> E["Restore Point-In-Time / Read Replica"]
    C -- "P3 (Minor - Parsial)" --> F["Hotfix Rolling Restart Zero Downtime"]
    D --> G["Verifikasi Integritas Data & Layanan"]
    E --> G
    F --> G
    G --> H["Komunikasi Status ke Pengguna / Klien"]
    H --> I["Penyusunan Laporan Pasca-Insiden (Post-Mortem)"]
```

***

## Target Pemulihan (*Recovery Objectives*)

Sistem menetapkan target terukur yang dipantau secara ketat:

| Metrik Pemulihan | Target Sistem | Penjelasan Teknis |
| :- | :- | :- |
| **RPO (Recovery Point Objective)** | **\< 15 Menit** | Maksimal rentang data yang berpotensi hilang saat bencana |
| **RTO (Recovery Time Objective)** | **\< 30 Menit** | Waktu maksimal yang dibutuhkan sistem untuk beroperasi penuh kembali |
| **Uptime SLA** | **99.9%** | Ketersediaan sistem bulanan di luar jadwal pemeliharaan terencana |

***

## 1. Strategi Backup & Redundansi Data

### A. Basis Data MySQL Terjadwal

* **Snapshot Penuh Harian (*Full Backup*)**: Dilakukan otomatis setiap pukul 02:00 WIB saat aktivitas laboratorium minimal, dikompresi, dienkripsi, dan diunggah ke *off-site storage*.
* **Pencatatan Binary Log (Binlog) Berkelanjutan**: Mengarsipkan seluruh transaksi perubahan data secara real-time untuk mendukung pemulihan titik waktu (*Point-in-Time Recovery* / PITR) hingga 1 menit sebelum insiden.
* **Retensi Arsip**: Arsip snapshot disimpan selama 30 hari untuk harian, 12 bulan untuk bulanan, dan 5 tahun untuk arsip tahunan guna kepatuhan regulasi KAN.

### B. Penyimpanan Objek Backblaze B2 Redundan

* Seluruh berkas PDF LHU tersimpan di Backblaze B2 dengan replikasi lintas zona (*cross-region redundancy*).
* Penghapusan berkas dilindungi fitur *Object Lock* dan retensi versi (*versioning*), sehingga berkas tidak dapat ditimpa atau dihapus secara permanen oleh pihak tidak berwenang.

***

## 2. Klasifikasi Tingkat Insiden (*Severity Levels*)

| Level | Kategori | Kriteria Dampak | Respons Wajib |
| :- | :- | :- | :- |
| **P1 - Kritis** | *System Down* | Portal tidak dapat diakses total, kehilangan koneksi database | Respons \< 10 menit, eskalasi ke Lead DevOps & CTO |
| **P2 - Mayor** | *Degraded Service* | Fungsi krusial terganggu (misal: gagal cetak LHU atau gagal upload PO) | Respons \< 30 menit, penanganan tim backend/frontend |
| **P3 - Minor** | *Partial Issue* | Tampilan visual bermasalah, performa lambat di modul tertentu | Respons \< 2 jam, diselesaikan pada sprint reguler |

***

## 3. Prosedur Baku Penanganan Insiden (SOP)

Ketika terjadi insiden teknis, tim operasional wajib menjalankan 6 langkah standar berikut:

### Langkah 1: Deteksi & Notifikasi Otomatis

* Sistem pemantauan (*monitoring agent*) mendeteksi kegagalan layanan (HTTP 5xx, CPU > 95%, disk space > 90%).
* Notifikasi darurat dikirim secara instan ke saluran komunikasi tim teknis melalui WhatsApp/Telegram/Email.

### Langkah 2: Triase & Isolasi Masalah

* *Incident Commander* ditunjuk untuk memimpin penanganan.
* Lakukan isolasi komponen yang bermasalah (misal: memutus container terdampak dari Nginx load balancer) untuk mencegah penyebaran gangguan.

### Langkah 3: Pemulihan Cepat (*Mitigation & Recovery*)

* **Jika kegagalan aplikasi**: Lakukan *rollback* otomatis ke image Docker versi stabil sebelumnya via Jenkins atau `docker compose rolling restart`.
* **Jika kegagalan database**: Jalankan restorasi snapshot terbaru ditambah penerapan binary log ke node cadangan.
* **Jika kegagalan VPS**: Arahkan DNS Cloudflare/Nginx ke server cadangan (*hot-standby VPS*).

### Langkah 4: Verifikasi Integritas Layanan

* Uji fungsionalitas kritis: verifikasi login pengguna, integritas query MySQL, pembacaan dokumen LHU di B2, dan status response time.

### Langkah 5: Komunikasi Publik & Portal Klien

* Pasang banner pemeliharaan informatif di [[https://portal.itec-indonesia.com](https://portal.itec-indonesia.com)](https://portal.itec-indonesia.com) apabila terjadi *downtime*.
* Informasikan kepada tim marketing dan klien perkiraan waktu pemulihan secara transparan.

### Langkah 6: Laporan Pasca-Insiden (*Post-Mortem Report*)

* Dalam waktu maksimal 24 jam setelah insiden teratasi, tim wajib menyusun dokumen Post-Mortem yang mencakup:
  1. Kronologi detail peristiwa (*timeline*).
  2. Akar penyebab masalah (*Root Cause Analysis* / RCA).
  3. Dampak operasional terhadap data dan pengguna.
  4. Tindakan pencegahan permanen (*action items*) agar insiden serupa tidak terulang.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.