# Kontrol akses, staging, dan persetujuan rilis

Oura Works · Playbook · 2 Oktober 2026

Atur siapa yang boleh mengubah apa, bagaimana perubahan diperiksa, dan apa yang dilakukan jika rilis bermasalah.

## Hasil yang disiapkan
Matriks akses, daftar pemeriksaan rilis, dan rencana pemulihan.

## Bahan awal
- Daftar sistem dan pemilik akun
- Lingkungan pengujian yang tersedia
- Daftar perubahan yang akan dirilis

## Langkah kerja

### 1. Inventaris sistem dan pemiliknya
Catat domain, hosting, CMS, repository, analytics, dan layanan pengiriman formulir. Tetapkan akun pemilik di bawah kontrol bisnis, bukan hanya satu orang vendor. Beri akses sesuai tugas dan gunakan MFA bila tersedia. Jangan menyimpan password, token, atau recovery code di brief umum maupun lembar latihan ini.

Output: Daftar sistem, pemilik, peran, dan cara mencabut akses.

### 2. Pisahkan pengujian dari produksi
Staging digunakan untuk meninjau perubahan sebelum diterapkan ke website publik. Batasi aksesnya dan gunakan data uji, bukan salinan data pelanggan yang tidak terlindungi. Pengaturan noindex saja bukan kontrol akses. Perbedaan konfigurasi antara staging dan produksi perlu dicatat agar keberhasilan uji tidak disalahartikan sebagai jaminan rilis.

Output: Lingkungan uji dengan data, akses, dan perbedaan konfigurasi.

### 3. Tentukan siapa yang memberi persetujuan
Pemilik konten memeriksa fakta dan copy; pengembang memeriksa perubahan teknis; operasional memeriksa proses penerimaan inquiry. Untuk setiap perubahan, catat versi, ruang lingkup, hasil uji, dan pihak yang menyetujui. Pisahkan perbaikan darurat dari perubahan rutin, tetapi tetap dokumentasikan keputusan dan pengecekan setelahnya.

Output: Catatan persetujuan versi yang akan dirilis.

### 4. Siapkan pemulihan sebelum rilis
Tentukan kondisi yang mengharuskan rollback, lokasi cadangan, penanggung jawab, dan urutan tindakan. Pastikan cadangan bisa dipulihkan di lingkungan yang sesuai. Setelah rilis, periksa halaman prioritas dan transaksi atau formulir penting. Rencana ini mengurangi risiko; ia tidak menjamin nol downtime atau keamanan total.

Output: Rencana rollback dan daftar pemeriksaan setelah rilis.

## Contoh latihan
Latihan perubahan formulir penawaran: tim mengganti field kebutuhan, bukan seluruh website. Keputusan rilis didasarkan pada penerimaan formulir serta kejelasan pesan bagi pengguna.

| Peran | Yang ditinjau | Bukti sebelum rilis |
| --- | --- | --- |
| Pemilik konten | Label dan instruksi formulir | Versi copy disetujui |
| Pengembang | Validasi, respons, dan akses | Hasil uji sukses dan gagal |
| Operasional | Penerimaan serta tindak lanjut | Inquiry uji diterima sistem tujuan |
| Penanggung jawab rilis | Versi, jadwal, dan rollback | Persetujuan dan cadangan tersedia |

## Hindari salah langkah

### Memakai satu akun admin bersama
Pisahkan akun sesuai kemampuan platform agar tanggung jawab dan pencabutan akses lebih jelas.

### Menganggap backup sukses berarti pemulihan sukses
Uji restore dan periksa hasilnya. Status file cadangan saja belum cukup.

## Checklist
- [ ] Akun pemilik berada di bawah kontrol bisnis
- [ ] Akses mengikuti kebutuhan tugas
- [ ] Staging tidak membuka data pelanggan
- [ ] Versi dan persetujuan dicatat
- [ ] Pemulihan pernah diuji

## Lembar kerja

### Sistem dan pemilik
[Isi catatan Anda]

### Peran yang membutuhkan akses
[Isi catatan Anda]

### Perubahan yang akan dirilis
[Isi catatan Anda]

### Skenario uji dan bukti
[Isi catatan Anda]

### Pihak pemberi persetujuan
[Isi catatan Anda]

### Pemicu rollback dan penanggung jawab
[Isi catatan Anda]

## Pertanyaan yang sering muncul

### Apakah staging wajib identik dengan produksi?
Kemiripan membantu pengujian, tetapi perbedaan sering tetap ada. Catat perbedaan dan lakukan pemeriksaan produksi setelah rilis.

### Apakah approval memperlambat semua perubahan?
Tetapkan level review berdasarkan dampak. Perubahan kecil dan perubahan kritis dapat memiliki jalur berbeda yang terdokumentasi.

## Rujukan
- CISA: autentikasi multifaktor: https://www.cisa.gov/audiences/small-and-medium-businesses/secure-your-business/require-multifactor-authentication
- CISA: pengujian cadangan dan pemulihan: https://www.cisa.gov/stopransomware/ransomware-guide

Contoh adalah latihan, bukan hasil klien. Sesuaikan keputusan dengan kondisi bisnis. Panduan editorial disusun dengan bantuan AI dan rujukan publik; bukan jaminan hasil atau pengganti penilaian teknis khusus.