Daftar Periksa Serah Terima Aplikasi Siap Produksi untuk Self‑Hosting

Apa arti “serah terima siap produksi” dalam praktik

Serah terima siap produksi berarti tim operasi (ops) bisa menjalankan aplikasi tanpa menebak-nebak. Mereka bisa mendeploy versi yang diketahui, memeriksa kesehatan, merespon alert, dan memulihkan dari rilis buruk atau outage. Jika salah satu hal itu bergantung pada ingatan satu pengembang, serah terima belum selesai.

Anggap serah terima sebagai paket yang menjawab satu pertanyaan: jika pembuat asli hilang selama seminggu, apakah ops masih bisa menjaga sistem tetap aman dan tersedia?

Paket yang baik biasanya menjelaskan apa yang dilakukan aplikasi, bagaimana terlihatnya kondisi “sehat”, bagaimana proses rilis bekerja (deploy, verifikasi, rollback), di mana konfigurasi berada, bagaimana rahasia dikelola, dan bagaimana memonitor, backup, serta merespons insiden.

Sama pentingnya: apa yang tidak ditanggung. Serah terima bukan janji untuk menambah fitur, refactor, desain ulang layar, atau “bersihkan nanti.” Itu proyek terpisah dengan ruang lingkup masing‑masing.

Sebelum menyatakan selesai, sepakati kepemilikan dan waktu respons. Misalnya: ops memegang uptime dan melakukan deploy; tim produk memegang roadmap; tim dev menyediakan jendela dukungan pasca-serah terima yang jelas untuk perbaikan dan pertanyaan.

Buat inventaris sistem sederhana (apa berjalan di mana)

Ops hanya bisa mengelola apa yang bisa mereka lihat. Inventaris satu halaman mencegah tebak‑tebakan saat deploy, insiden, dan audit. Gunakan bahasa yang sederhana dan spesifik.

Cantumkan setiap bagian yang berjalan dan lokasinya: backend API, web app, background worker, job terjadwal, dan bagaimana aplikasi mobile terhubung. Meski iOS/Android didistribusikan lewat store, mereka tetap bergantung pada backend yang sama.

Sertakan layanan eksternal yang wajib ada. Jika Anda memakai PostgreSQL, antrean, object storage, atau API pihak ketiga (pembayaran seperti Stripe, messaging, email/SMS, Telegram), tuliskan nama layanan tepat dan fungsinya.

Catat persyaratan jaringan agar hosting tidak menjadi coba‑coba: domain yang dibutuhkan (app, api, admin), port dan protokol, siapa yang memperbarui sertifikat TLS, di mana DNS dikelola, dan daftar allowlist inbound/outbound bila perlu.

Terakhir, tuliskan beban yang diharapkan dalam angka: puncak request per menit, pengguna aktif, ukuran payload tipikal, ukuran database saat ini, dan pertumbuhan yang diperkirakan. Kisaran kasar sudah membantu ops menetapkan batas dan alert.

Jika Anda membangun dengan AppMaster, inventaris backend yang dihasilkan, web app, dan integrasinya supaya ops tahu apa yang harus dideploy bersama.

Paket konfigurasi lingkungan (tanpa mengekspos rahasia)

Setup produksi biasanya gagal pada bagian membosankan: konfigurasi yang hanya ada di kepala seseorang. Perlakukan konfigurasi sebagai deliverable. Ops seharusnya bisa melihat pengaturan apa saja, apa yang berbeda antar lingkungan, dan bagaimana mengubahnya dengan aman.

Mulai dengan menamai setiap lingkungan yang ada hari ini, meski bersifat sementara. Banyak tim punya dev, staging, dan production, plus salinan seperti “production-eu” atau “staging-us.” Catat lingkungan mana yang dipakai untuk pengujian rilis, migrasi data, dan latihan insiden.

Sediakan referensi konfigurasi tunggal yang mencantumkan nama variabel dan contoh nilai yang aman (jangan pernah pakai kredensial nyata). Buat placeholder jelas terlihat.

Paket serah terima Anda sebaiknya meliputi:

• Daftar lingkungan dan tujuan masing‑masing
• Referensi kunci konfigurasi (env vars atau kunci file config), tipe yang diharapkan, dan contoh nilai non-rahasia
• Perbedaan yang diketahui antar lingkungan (feature flags, batas laju, ukuran cache, mode email, level logging)
• Nilai default dan apa yang terjadi jika kunci hilang
• Di mana konfigurasi disimpan dan bagaimana diterapkan saat deploy

Tambahkan proses perubahan sederhana. Misalnya: minta lewat tiket, review oleh pemilik layanan, terapkan di staging dulu, lalu promosikan ke production pada jendela terjadwal dengan rencana rollback bila tingkat error naik.

Jika Anda mengekspor dan self‑hosting aplikasi AppMaster, terapkan aturan yang sama: kirimkan set kunci konfigurasi yang bersih dan terdokumentasi bersama kode yang dihasilkan agar ops bisa menjalankannya konsisten di semua lingkungan.

Rahasia dan kredensial: penyimpanan, rotasi, dan akses

Rahasia adalah cara tercepat serah terima yang rapi berubah jadi insiden keamanan. Tujuannya sederhana: ops harus tahu setiap secret yang dibutuhkan aplikasi, di mana disimpan, siapa yang bisa membacanya, dan bagaimana menggantinya tanpa downtime.

Mulai dengan daftar rahasia singkat yang bisa dipindai ops dalam satu menit. Untuk tiap item, catat apa yang dibuka (database, SMTP, Stripe, kunci JWT), di mana tersimpan (vault, cloud secret store, Kubernetes Secret, file terenkripsi), dan siapa yang bertanggung jawab rotasi.

Tulis langkah rotasi seperti resep, bukan kebijakan. Sertakan urutan tepat, berapa lama secret lama harus tetap valid, dan satu pemeriksaan yang membuktikan berhasil.

Checklist rotasi (contoh)

Gunakan pola ini untuk tiap secret:

• Buat nilai secret baru dan simpan di secret manager yang disetujui.
• Terapkan perubahan konfigurasi sehingga aplikasi memakai nilai baru.
• Verifikasi: login, pembayaran, atau panggilan API berhasil dan tingkat error tetap normal.
• Cabut secret lama dan pastikan tidak lagi berfungsi.
• Catat tanggal rotasi, siapa yang melakukannya, dan tanggal berikutnya.

Jelaskan ekspektasi enkripsi. Secret harus terenkripsi saat disimpan di secret store dan dilindungi saat transit (TLS) antara aplikasi dan dependensinya. Jangan pernah menaruh secret di source control, artefak build, atau dokumen bersama.

Tentukan akses break‑glass. Jika outage menghalangi akses normal, sebutkan siapa yang bisa menyetujui akses darurat, berapa lama berlaku, dan apa yang harus diaudit setelahnya.

Paket deploy: artefak, versi, dan rollback

Ops hanya bisa mengelola apa yang bisa mereka reproduksi. Paket deploy yang baik membuat tiga pertanyaan mudah dijawab: apa tepatnya yang kita jalankan, bagaimana kita deploy lagi, dan bagaimana cepat kembali jika ada yang rusak?

Cantumkan “bill of materials” untuk build. Sebutkan detail artefak dan bagaimana memverifikasinya, bukan hanya lokasinya:

• Detail artefak: nama/tag image container (atau nama binary/paket), versi aplikasi, tanggal build, checksum
• Referensi sumber: tag release atau commit hash yang dipakai untuk build, plus flag build yang penting
• Target yang didukung: VM, container (Docker), atau Kubernetes, dan mana yang direkomendasikan
• Langkah deploy: prasyarat (runtime, database, storage), urutan tepat, dan waktu deploy khas
• Migrasi database: bagaimana dijalankan (otomatis saat startup atau manual), di mana log berada, dan bagaimana memastikan sukses

Tambahkan satu contoh kecil dan konkret. Misalnya: “Deploy v1.8.2 dengan mengubah tag image, jalankan migrasi, lalu restart web worker. Jika health check gagal dalam 10 menit, revert ke v1.8.1 dan hentikan job migrasi.”

Rollback, tanpa menebak‑nebak

Rencana rollback harus terbaca seperti instruksi yang bisa diikuti jam 2 pagi. Harus menyatakan:

• Sinyal yang memicu rollback (tingkat error, health check gagal, login rusak)
• Versi terakhir yang diketahui baik dan di mana disimpannya
• Apakah perubahan database dapat dibalik, dan apa yang dilakukan jika tidak

Jika aplikasi dibangun dengan AppMaster dan diekspor sebagai source untuk self‑hosting, sertakan versi kode yang dihasilkan, instruksi build, dan ekspektasi runtime supaya ops bisa membangun ulang rilis yang sama nanti.

Monitoring dan alerting: apa yang diukur dan kapan dipanggil

Serah terima belum lengkap sampai ops bisa melihat apa yang terjadi pada aplikasi dan mendapat peringatan sebelum pengguna mengeluh.

Sepakati log apa yang harus ada dan ke mana mereka pergi (file, syslog, platform logging). Pastikan log sinkron waktu dan menyertakan request atau correlation ID sehingga insiden dapat ditelusuri end‑to‑end.

Biasanya Anda ingin log aplikasi (event penting dan kegagalan), log error (stack trace dan job gagal), log akses (request dan status code), log audit (aksi admin dan ekspor), dan log infrastruktur (restart, tekanan node, masalah disk).

Selanjutnya, definisikan sekumpulan metrik kecil yang mencerminkan dampak pengguna dan kesehatan sistem. Jika hanya memilih lima: latensi (p95/p99), tingkat error, saturasi (CPU/memory/disk), kedalaman antrean, dan pemeriksaan ketersediaan eksternal.

Aturan alert harus tegas: apa yang memicu, tingkat keparahan (page vs tiket), siapa on‑call, dan kapan eskalasi. Tambahkan snapshot dashboard “yang baik” dan catatan singkat menggambarkan normal (rentang latensi biasa, tingkat error yang diharapkan, kedalaman antrean umum). Konteks itu mencegah alert bising dan membantu responder baru bertindak cepat.

Backup dan pemulihan: buat restore yang dapat diulang

Backup bukan sesuatu yang “dimiliki.” Mereka adalah sesuatu yang bisa Anda restore kapan diminta.

Tuliskan ruang lingkup persisnya: database, file storage (upload, laporan, invoice), dan bagian yang sering terlupakan seperti konfigurasi yang tidak ada di kode dan kunci enkripsi yang dibutuhkan untuk membaca data terlindungi.

Gunakan istilah yang jelas. RPO adalah berapa banyak data yang boleh hilang (mis. 15 menit). RTO adalah berapa lama Anda boleh down (mis. 1 jam). Pilih angka yang disepakati bisnis karena itu menentukan biaya dan usaha.

Sertakan:

• Apa yang dibackup, di mana disimpan, dan retensinya
• Siapa yang bisa menjalankan backup dan restore, dan bagaimana akses disetujui
• Prosedur restore langkah‑demi‑langkah dengan pemeriksaan verifikasi
• Di mana log restore berada, dan seperti apa “sukses” terlihat
• Mode kegagalan umum (kunci salah, bucket hilang, mismatch skema) dan perbaikannya

Jika Anda mengekspor dan self‑hosting aplikasi yang dibuat AppMaster, sertakan langkah restore PostgreSQL serta bucket storage eksternal dan kunci yang digunakan untuk field terenkripsi.

Jadwalkan drill restore. Catat waktu, apa yang rusak, dan apa yang Anda ubah agar restore berikutnya lebih cepat dan kurang menegangkan.

Runbook dan on‑call: bagaimana ops menangani insiden nyata

Serah terima belum nyata sampai seseorang bisa dipanggil jam 2 pagi dan memperbaiki masalah tanpa menebak. Runbook mengubah pengetahuan tribal menjadi langkah yang bisa diikuti on‑call.

Mulailah dengan insiden yang paling mungkin terjadi: outage total, request lambat, dan deploy yang merusak sesuatu. Buat setiap runbook singkat. Taruh pengecekan tercepat di atas supaya responder mendapat sinyal dalam hitungan menit.

Isi runbook yang baik

Pertahankan struktur konsisten agar mudah dipindai saat tekanan:

• Apa yang dilihat pengguna dan bagaimana mengonfirmasinya (mis. error rate di atas X%, checkout gagal)
• Pemeriksaan pertama (status layanan, deploy terakhir, kesehatan dependensi, disk/CPU, koneksi database)
• Pemeriksaan berikutnya (log mana yang dibuka, dashboard kunci, perubahan konfigurasi terbaru, kedalaman antrean)
• Titik keputusan (kapan rollback, kapan scale, kapan menonaktifkan fitur)
• Eskalasi (siapa pemilik aplikasi, siapa pemilik infra, dan kapan memanggil mereka)

Jika aplikasi diekspor atau di‑self‑host dari AppMaster, sertakan di mana layanan yang dihasilkan berjalan, bagaimana me‑restartnya dengan aman, dan nilai konfigurasi yang diharapkan per lingkungan.

Setelah insiden: tangkap fakta yang benar

Simpan checklist pasca‑insiden singkat. Catat timeline, apa yang berubah terakhir, pesan error tepatnya, pengguna terdampak, dan tindakan yang memperbaiki. Lalu perbarui runbook saat detail masih segar.

Kontrol akses dan izin: siapa boleh melakukan apa

Ops hanya bisa mengelola sistem jika jelas siapa yang boleh melakukan apa, dan bagaimana akses dilacak.

Tulis peran yang benar‑benar Anda gunakan. Untuk banyak tim, ini sudah cukup:

• Deployer: melakukan deploy versi yang disetujui dan memicu rollback
• DB admin: menjalankan perubahan skema dan restore backup
• Read-only: melihat dashboard, log, dan konfigurasi tanpa mengubah
• Incident commander: menyetujui tindakan darurat saat outage

Dokumentasikan “kebijakan pintu” dalam langkah sederhana: siapa memberi akses, di mana diberikan (SSO, cloud IAM, user database, CI/CD, panel admin), siapa yang mencabut, dan bagaimana memastikan akses dihapus saat offboarding.

Jangan lupa akses non-manusia. Daftarkan setiap service account dan token yang digunakan oleh job, integrasi, dan monitoring, dengan catatan prinsip least‑privilege untuk masing‑masing (mis. “hanya bisa baca dari bucket X”). Jika Anda mengekspor kode AppMaster untuk self‑hosting, sertakan variabel env atau file konfigurasi yang menentukan identitas ini, tetapi jangan pernah menempelkan nilai rahasia di dokumen serah terima.

Juga tetapkan ekspektasi log audit: apa yang harus dilog (login, deploy, perubahan konfigurasi, aksi DB admin), siapa yang bisa membaca log, retensi, tempat penyimpanan, dan bagaimana meminta log saat insiden atau review.

Dasar keamanan dan kepatuhan (dalam bahasa sederhana)

Catatan keamanan harus bisa dibaca oleh non‑spesialis, tapi cukup spesifik agar ops bisa bertindak. Tambahkan ringkasan satu halaman yang menjawab: data apa yang kita simpan, di mana, dan siapa yang bisa mengakses?

Mulai dengan tipe data: profil pelanggan, tiket dukungan, metadata pembayaran, file. Sebut kategori sensitif seperti PII (nama, email, nomor telepon), kredensial, dan data teratur yang relevan bagi perusahaan. Jika Anda mengekspor kode untuk self‑hosting (termasuk dari AppMaster), catat di mana data itu berada di database dan layanan mana yang bisa membacanya.

Lalu tulis aturan retensi dan penghapusan dalam istilah praktis. Katakan apa yang disimpan, berapa lama, dan bagaimana penghapusan bekerja (soft delete vs hard delete, penundaan purge, backup). Jika ada hold hukum atau kebutuhan audit, sebut siapa yang menyetujui pengecualian.

Log sering bocor lebih dari database. Jelaskan di mana PII bisa muncul (access log, error log, event analytics) dan bagaimana Anda mengurangi atau memaskerinya. Jika suatu field tidak boleh pernah dilog, nyatakan aturan itu.

Buat persetujuan eksplisit:

• Perubahan autentikasi perlu approver bernama.
• Perubahan terkait pembayaran (kunci Stripe, endpoint webhook, logika refund) butuh approver bernama.
• Perubahan model peran dan izin butuh approver bernama.
• Jendela patch keamanan dan aturan perubahan darurat tertulis.

Jika hanya menambahkan satu hal ekstra, tambahkan catatan bukti: di mana log audit disimpan dan bagaimana mengekspornya bila diminta.

Contoh skenario serah terima: ops mengambil alih dalam satu minggu

Ops mengambil alih portal pelanggan yang dibuat tim produk kecil dan memindahkannya ke infrastruktur self‑hosted baru. Tujuannya bukan sekadar “berjalan,” melainkan “ops bisa menjalankannya tanpa menghubungi pembuat.”

Seperti apa minggu itu

Hari 1: Ops melakukan deploy bersih pertama di lingkungan baru menggunakan hanya paket serah terima. Aplikasi hidup, tapi login gagal karena variabel lingkungan untuk penyedia email hilang. Itu ditambahkan ke template env, dan deploy diulang sampai berjalan dari nol.

Hari 2: Alert pertama sengaja dipicu. Ops melakukan kegagalan terkontrol (hentikan satu layanan atau blokir email keluar) dan memastikan: metrik menunjukkan isu, alert sampai ke kanal yang benar, dan pesan memberi tahu langkah selanjutnya.

Hari 3: Token kadaluarsa di sandbox pembayaran. Karena lokasi kredensial dan langkah rotasi terdokumentasi, ops menggantinya tanpa menebak atau mengekspos rahasia.

Hari 4: Cutover DNS. Record yang salah menunjuk ke IP lama, dan beberapa pengguna mendapati portal down. Ops memakai runbook untuk memverifikasi DNS, TLS, dan health check secara urut.

Hari 5: Tes restore backup pertama. Ops merestore ke database baru dan membuktikan portal bisa memuat data nyata.

Apa arti “selesai” setelah 1 minggu

Aplikasi berjalan selama 7 hari tanpa perbaikan misterius, ada satu restore sukses, alert jelas, dan deploy yang dapat diulang oleh ops sendiri.

Kesalahan umum serah terima yang menyebabkan kebakaran jam 2 pagi

Cara tercepat mengubah serah terima tenang jadi kejadian tengah malam adalah menganggap “kami sudah memberi tahu ops segalanya” sama dengan “ops bisa menjalankannya tanpa kami.”

Pola kegagalan umum setelah serah terima self‑hosting termasuk: secret dibagikan lewat spreadsheet atau chat, rollback bergantung pada pengembang, backup ada tapi restore tidak pernah diuji, alert berbunyi terus karena threshold tidak disetel, dan detail lingkungan hanya tersimpan di kepala seseorang (port, nama DNS, jadwal cron, permission cloud).

Contoh: Anda mengekspor kode dari AppMaster untuk self‑hosting, dan deploy pertama berhasil. Dua minggu kemudian perubahan konfigurasi merusak login. Jika secret disebar lewat chat dan rollback butuh pembuat asli, ops kehilangan jam hanya untuk mengembalikan kondisi “berjalan kemarin.”

Cek cepat sebelum menyatakan “serah terima selesai”

Sebelum menutup tiket, jalankan drill fresh‑start singkat. Berikan paket serah terima ke satu engineer ops dan lingkungan bersih (VM baru, namespace Kubernetes baru, atau project cloud kosong). Jika mereka bisa deploy, mengamati, dan memulihkan aplikasi dalam waktu yang ditetapkan (mis. 2 jam), Anda hampir selesai.

Gunakan cek ini:

• Bangun ulang dan deploy dari nol menggunakan hanya artefak paket, dokumen konfigurasi, dan runbook (termasuk rollback).
• Verifikasi setiap secret berada di tempat yang disepakati, dan langkah rotasi ditulis serta diuji.
• Buka dashboard dan pastikan menjawab pertanyaan dasar: apakah up, lambat, error, atau kehabisan resource?
• Picu satu alert aman untuk memastikan paging, pemilik, dan jam tenang berfungsi.
• Lakukan tes restore nyata ke lingkungan terpisah, lalu dokumentasikan langkah dan hasil yang diharapkan.

Jika Anda mengekspor kode yang dihasilkan untuk self‑hosting, pastikan ops tahu di mana input build, versi, dan tag rilis dicatat agar rilis mendatang tetap dapat diulang.

Langkah berikutnya: finalisasi kepemilikan dan jaga paket tetap mutakhir

Lakukan walkthrough akhir dengan orang yang akan menerima pager. Perlakukan seperti latihan. Buktikan deploy, rollback, restore, dan alerting bekerja dengan paket yang sama yang Anda serahkan.

Walkthrough akhir biasanya mencakup: deploy ke lingkungan test lalu production menggunakan langkah yang sama, rollback ke versi sebelumnya dan verifikasi aplikasi masih berfungsi, restore dari backup ke lingkungan bersih dan validasi cek sederhana (login, buat record, kirim pesan), picu satu alert aman, dan konfirmasi di mana menemukan log dan dashboard saat insiden.

Jadikan kepemilikan eksplisit. Tetapkan pemilik bernama untuk setiap runbook (deploy, insiden, restore) dan untuk setiap rute alert (on‑call utama, cadangan, perilaku setelah jam kerja). Jika tidak ada yang memiliki alert, alert itu akan diabaikan atau membangunkan orang yang salah.

Tulislah rencana Day 2 singkat agar ops tahu apa yang harus ditingkatkan setelah minggu pertama: menyetel threshold, memeriksa biaya, membersihkan artefak lama, dan meninjau akses. Buat kecil dan dibatasi waktu.

Jika Anda membangun dengan AppMaster (appmaster.io), sertakan kode sumber yang diekspor atau detail target deployment yang tepat (cloud, region, pengaturan build, layanan yang diperlukan) supaya ops bisa mereproduksi aplikasi tanpa bergantung pada workspace proyek asli. Tetapkan ritme sederhana untuk memperbarui paket kapan pun kebutuhan berubah sehingga runbook tidak menyimpang dari kenyataan.