# Menentukan urutan pemulihan berdasarkan dependensi layanan

Sumber diperiksa. Metode: https://kompli.id/metodologi/.

Layanan yang diprioritaskan bisnis bisa menunggu komponen pendukung yang belum siap. Peta dependensi membantu menentukan prasyarat, pemilik serta bukti sebelum membuka layanan.

URL kanonis: https://kompli.id/panduan/kelangsungan-usaha/dependensi-dan-urutan-pemulihan/
Sumber diakses: 2026-10-02
Diperbarui: 2026-10-02
Penulis: Kompli
Sumber diperiksa: 2026-10-02


## Mengapa aplikasi penting belum tentu dipulihkan pertama?

**Prioritas bisnis menentukan tujuan; dependensi menentukan apa yang harus siap untuk mencapai tujuan itu.** Aplikasi pesanan tidak bisa melayani pengguna jika identitas, data atau antrean yang diperlukannya belum tersedia.

NIST SP 800-184 bagian 2 membahas dependensi fungsi dan keamanan dalam perencanaan pemulihan. Gunakan sebagai rujukan teknis, bukan kewajiban Indonesia. Alur di sini contoh orisinal; kebutuhan tiap sistem ditinjau bersama pemiliknya.

## Petakan prasyarat, bukan hanya daftar server

Mulai dari layanan minimum pada [BIA](/panduan/kelangsungan-usaha/analisis-dampak-bisnis/). Catat jalur pengguna, identitas, nama jaringan/DNS, konfigurasi, kunci, data, antrean, lampiran, pemantauan dan vendor yang diperlukan. Tentukan dependensi wajib serta fungsi yang boleh dinonaktifkan sementara.

Untuk setiap hubungan, tulis pemilik, cara memeriksa, bukti, batas waktu serta pengganti yang disetujui. “Server hidup” belum sama dengan database dapat dibaca atau pengguna berizin dapat menyelesaikan pekerjaan. Jangan meletakkan kredensial dalam peta yang dibagikan luas.

## Contoh urutan dari grafik buatan

[Lab pemulihan layanan 1.0](/unduhan/lab-pemulihan-layanan-v1.zip) dijalankan 2 Oktober 2026. Python hanya menghitung hubungan pada grafik buatan; ia **tidak menjalankan DNS, layanan identitas, antrean atau aplikasi nyata**.

| Lapisan | Prasyarat dan pemeriksaan di sistem nyata |
| --- | --- |
| DNS dan identitas | Pada grafik ini keduanya akar. Periksa resolusi nama, akses berizin dan akses darurat yang sah; kondisi nyata dapat mempunyai dependensi tambahan. |
| Database dan antrean (queue) | Grafik membutuhkan identitas. Periksa data, izin, integritas dan status antrean; jangan langsung memproses ulang semua pekerjaan. |
| Aplikasi | Membutuhkan DNS, database dan queue. Periksa alur pengguna minimum, data dan batas akses. |
| Jobs | Membutuhkan aplikasi. Aktifkan setelah menilai duplikat, jadwal dan dampak pengiriman; tahan notifikasi nyata di lingkungan uji. |

Runner menghasilkan empat lapisan tersebut. Hubungan melingkar identitas → aplikasi → identitas dan vendor yang belum tercatat ditolak. Aplikasi juga ditahan ketika antrean belum ditandai siap. Itu pemeriksaan **model**, bukan health check jaringan atau hasil pemulihan seluruh dependensi.

## Bagaimana jika dependensinya melingkar?

Contoh fiktif: petugas perlu login untuk memulihkan identitas, tetapi layanan login bergantung pada identitas yang sedang pulih. Jangan memaksakan urutan linier yang menyembunyikan masalah.

Bahas cara memulai pemulihan dengan akses darurat yang sah, konfigurasi minimum atau pengaturan teknis yang sesuai. Tentukan penyetuju, pembatasan akses, pencatatan, pemeriksaan dan penutupan akses sementara. Halaman ini tidak memberi cara melewati autentikasi atau menetapkan satu solusi untuk semua arsitektur.

## Vendor, antrean dan pekerjaan setelah layanan dibuka

Catat jam dukungan, jalur eskalasi dan bukti vendor benar-benar tersedia. SLA vendor menjadi masukan, bukan otomatis target pemulihan seluruh layanan. Tentukan tindakan bila vendor belum pulih: mode terbatas, penundaan atau penghentian yang disetujui.

Periksa backlog, pekerjaan yang sudah selesai, retry serta efek samping sebelum mengaktifkan jobs. Satu transaksi bisa sudah diproses pihak lain meski jawaban tidak diterima; membuka antrean tanpa pemeriksaan berisiko mengulang pekerjaan.

Gunakan [peta dependensi layanan](/template/peta-dependensi-layanan/) untuk urutan dan syarat siap. Hasil nyata dicatat di [catatan uji pemulihan](/template/catatan-uji-pemulihan/). Perubahan arsitektur, akses, vendor atau hasil uji menjadi pemicu tinjauan; grafik lama tidak menjadi bukti kesiapan terbaru.
## Sumber rujukan

- [NIST SP 800-184 — Guide for Cybersecurity Event Recovery](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-184.pdf) — §2.1–2.3, §4: dependensi, rencana dan validasi pemulihan; panduan teknis Desember 2016.
- [NIST SP 800-34 Rev. 1 — Contingency Planning Guide for Federal Information Systems](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf) — §4.3–4.4: urutan pemulihan, pemeriksaan data/fungsi dan pengembalian operasi; bukan prosedur setiap database.

## Perlu membahas kebutuhan tim Anda?

Ceritakan standar atau bukti yang diminta pelanggan dan kesiapan tim Anda saat ini.

[Konsultasikan kebutuhan Anda](https://kompli.id/konsultasi/?topik=standar)

## Bacaan terkait

- [Menyusun analisis dampak bisnis untuk layanan digital](https://kompli.id/panduan/kelangsungan-usaha/analisis-dampak-bisnis/)
- [Peta dependensi dan urutan pemulihan layanan](https://kompli.id/template/peta-dependensi-layanan/)
- [Menguji failover dan pengembalian layanan setelah gangguan](https://kompli.id/panduan/kelangsungan-usaha/uji-failover-dan-failback/)
- [Template catatan uji pemulihan cadangan](https://kompli.id/template/catatan-uji-pemulihan/)