Runbook deploy ujian online harus dirancang untuk satu tujuan utama: perubahan produksi tidak boleh mengganggu akses peserta, proses autentikasi, penilaian, atau audit integritas saat ujian sedang berlangsung. Dalam konteks meningkatnya kekhawatiran kampus terhadap kecurangan berbantuan AI, tekanan terhadap platform ujian tidak hanya soal skalabilitas, tetapi juga soal reliability, jejak audit, dan kemampuan rollback yang benar-benar cepat ketika sistem deteksi atau layanan login mulai salah bertindak.

Artikel ini membahas praktik yang bisa langsung dipakai oleh tim DevOps dan engineering: checklist rilis sebelum jadwal ujian, strategi canary dan kill switch, metrik serta log yang wajib ada, pola rollback untuk perubahan aplikasi dan konfigurasi, serta postmortem ringan yang tetap cukup untuk audit dan perbaikan proses.

Mengapa platform ujian butuh runbook yang lebih ketat

Platform ujian berbeda dari aplikasi internal biasa. Waktu gangguan sangat sempit, toleransi kesalahan rendah, dan dampak insiden bisa langsung memengaruhi hasil akademik. Perubahan yang tampak kecil, misalnya aturan rate limit login, model deteksi perilaku mencurigakan, atau validasi token sesi, bisa menyebabkan:

  • False positive: peserta sah diblokir, dipaksa logout, atau ditandai curang tanpa dasar cukup.
  • False negative: perilaku mencurigakan lolos karena perubahan rule, timeout observability, atau pipeline event yang rusak.
  • Gangguan audit: event penting tidak tercatat sehingga tim tidak bisa membuktikan apa yang terjadi.
  • Kerusakan integritas ujian: perbedaan state antar layanan membuat jawaban, waktu ujian, atau status submit menjadi tidak konsisten.

Karena itu, runbook deploy untuk ujian online harus lebih konservatif dibanding deploy aplikasi umum. Fokusnya bukan kecepatan rilis semata, melainkan keamanan perubahan, rollback deterministik, dan keterlacakan insiden.

Prinsip inti runbook deploy ujian online

1. Hindari perubahan berisiko dekat jadwal ujian

Terapkan change freeze window sebelum ujian besar. Freeze tidak berarti tidak boleh deploy sama sekali, tetapi perubahan yang diizinkan harus terbatas pada:

  • perbaikan kritikal dengan dampak terukur,
  • rollback perubahan sebelumnya,
  • konfigurasi operasional yang sudah teruji,
  • penyesuaian kapasitas infrastruktur.

Perubahan pada model deteksi, rule anti-cheat, alur login, session handling, dan skema database sebaiknya dihindari jika tidak benar-benar mendesak.

2. Pisahkan deploy kode dari aktivasi fitur

Gunakan feature flag untuk memisahkan artefak yang sudah ter-deploy dari fitur yang benar-benar aktif. Ini penting untuk modul berisiko seperti:

  • deteksi anomali berbasis rule atau model,
  • kebijakan lock akun,
  • validasi perangkat atau browser,
  • integrasi proctoring atau analitik perilaku.

Dengan pola ini, rollback sering kali cukup dilakukan dengan mematikan flag, bukan mengembalikan seluruh versi aplikasi.

3. Semua perubahan harus bisa dibatalkan cepat

Rollback yang baik bukan sekadar tersedia di pipeline, tetapi sudah diuji dan diketahui batasannya. Tim harus tahu perbedaan rollback untuk:

  • kode aplikasi: kembali ke artefak stabil sebelumnya,
  • konfigurasi: mengembalikan config map, secret reference, rule rate limit, atau policy gateway,
  • database: tidak semua migrasi aman untuk di-rollback,
  • feature flag: mematikan fitur tanpa redeploy,
  • traffic routing: memindahkan trafik dari canary ke stable, atau menonaktifkan service baru.

4. Audit lebih penting daripada log verbose tanpa struktur

Dalam insiden ujian, pertanyaan yang muncul biasanya sangat spesifik: siapa yang terdampak, kapan perubahan aktif, request mana yang gagal, rule mana yang memblokir, dan siapa yang mengeksekusi perubahan. Jawabannya tidak akan ditemukan dari log acak. Anda butuh event audit yang terstruktur.

Checklist rilis sebelum jadwal ujian

Checklist berikut sebaiknya menjadi bagian wajib dari runbook deploy ujian online.

Checklist teknis pra-rilis

  1. Pastikan jadwal ujian dan freeze window jelas
    Deploy berisiko tinggi tidak boleh masuk beberapa jam sebelum ujian besar dimulai.
  2. Verifikasi artefak rilis
    Pastikan commit, image tag, dan changelog cocok dengan tiket perubahan.
  3. Pastikan rollback target tersedia
    Versi stabil sebelumnya harus masih bisa dijalankan, lengkap dengan konfigurasi yang kompatibel.
  4. Periksa kompatibilitas migrasi database
    Gunakan pendekatan expand-contract: tambah kolom atau tabel baru dulu, pindahkan pembacaan bertahap, lalu hapus struktur lama di rilis terpisah. Hindari migrasi destruktif tepat sebelum ujian.
  5. Jalankan smoke test yang relevan
    Minimal: login, ambil token, mulai ujian, autosave jawaban, submit, buka halaman pengawas, dan audit event.
  6. Validasi observability
    Dashboard, alert, dan log query untuk login, session, submit, dan rule deteksi harus siap dipakai sebelum deploy.
  7. Siapkan jalur komunikasi insiden
    Tentukan siapa incident commander, siapa PIC aplikasi, siapa PIC database, siapa PIC komunikasi ke tim akademik atau helpdesk.
  8. Nonaktifkan fitur eksperimen
    A/B test, rule eksperimental, dan konfigurasi yang mengubah pengalaman peserta sebaiknya dimatikan saat periode ujian.

Checklist operasional saat rilis

  • Deploy di luar puncak aktivitas peserta.
  • Gunakan canary atau progressive delivery, jangan langsung 100% trafik jika perubahan menyentuh login, sesi, atau evaluasi risiko.
  • Monitor 10-30 menit pertama dengan metrik dan log yang sudah ditentukan.
  • Tahan deploy lanjutan sampai state stabil.
  • Catat timestamp mulai deploy, aktivasi flag, perubahan routing, dan keputusan rollback.

Strategi deploy aman: canary, feature flag, dan kill switch

Canary untuk layanan kritikal

Canary cocok ketika Anda ingin menguji perilaku versi baru terhadap sebagian kecil trafik nyata. Untuk platform ujian, canary biasanya lebih aman diterapkan pada:

  • API non-kritis lebih dulu,
  • tenant atau kampus tertentu yang tidak sedang ujian,
  • trafik internal admin atau pengawas,
  • persentase kecil request baca sebelum request tulis penting.

Hindari canary agresif pada endpoint submit jawaban jika desain state belum benar-benar idempoten dan kompatibel antar versi.

Feature flag untuk rule deteksi dan kebijakan

False positive pada sistem deteksi adalah salah satu sumber insiden paling sensitif. Rule deteksi, scoring, atau enforcement sebaiknya dipisah menjadi beberapa lapisan flag:

  • observe-only: rule berjalan, tetapi belum memblokir, hanya mencatat event.
  • warn-only: pengguna atau pengawas mendapat sinyal, tetapi tidak ada aksi pemblokiran.
  • enforce: rule mulai memicu lock, logout, atau penandaan insiden.

Pola bertahap ini mencegah satu perubahan langsung merusak pengalaman peserta.

Kill switch untuk menonaktifkan modul berisiko

Kill switch adalah mekanisme tercepat untuk mematikan subsistem tertentu tanpa menurunkan seluruh aplikasi. Contoh modul yang layak punya kill switch:

  • deteksi perilaku mencurigakan real-time,
  • integrasi pihak ketiga untuk proctoring,
  • rate limit adaptif yang agresif,
  • langkah verifikasi perangkat tambahan.

Kill switch harus memenuhi dua syarat: mudah dipicu oleh on-call dan perubahan statusnya tercatat dalam audit.

# Contoh pseudo-config feature flag dan kill switch yang sederhana
feature_flags:
  anomaly_detection_mode: observe-only
  adaptive_login_rate_limit: enabled
  external_proctoring: enabled
  suspicious_session_auto_lock: disabled

kill_switches:
  disable_anomaly_enforcement: true
  bypass_external_proctoring: false
  bypass_device_fingerprint_check: false

Konfigurasi semacam ini tidak harus persis sama dengan alat Anda, tetapi prinsipnya jelas: mode operasi harus bisa diubah cepat tanpa rebuild aplikasi.

Rollback cepat saat false positive, false negative, atau login bermasalah

Skenario 1: false positive pada deteksi kecurangan

Gejala umumnya:

  • lonjakan akun yang ditandai mencurigakan,
  • pengawas menerima alert berlebihan,
  • peserta sah tiba-tiba di-lock atau dipaksa verifikasi ulang.

Urutan respons yang disarankan:

  1. Aktifkan kill switch untuk mematikan enforcement, bukan observability.
  2. Biarkan event tetap tercatat agar analisis pasca-insiden tetap mungkin.
  3. Verifikasi apakah perubahan berasal dari rule, model, threshold, atau input telemetry yang salah.
  4. Jika masalah dari kode aplikasi, rollback ke artefak stabil.
  5. Jika masalah dari konfigurasi, kembalikan config terakhir yang diketahui aman.

Kesalahan umum: mematikan seluruh logging atau pipeline event saat ingin mengurangi dampak. Ini justru menghilangkan data audit yang dibutuhkan nanti.

Skenario 2: false negative setelah pembaruan rule

Gejalanya lebih sulit terlihat karena sistem tampak normal. Indikasi yang perlu dicari:

  • volume event deteksi turun drastis tanpa penurunan trafik,
  • trace dari modul deteksi hilang atau timeout,
  • field input penting tidak lagi terisi akibat perubahan skema event.

Langkah respons:

  1. Bandingkan volume event sebelum dan sesudah deploy.
  2. Periksa kompatibilitas skema event antar layanan.
  3. Jika perlu, rollback parser, consumer, atau rule engine.
  4. Aktifkan mode observe-only pada rule sebelumnya untuk memulihkan visibilitas tanpa aksi paksa berlebihan.

Skenario 3: layanan login atau sesi terganggu

Ini biasanya insiden paling mendesak karena peserta tidak bisa masuk ujian. Penyebab umum:

  • perubahan session store,
  • cookie atau token mismatch antar instance,
  • rate limit terlalu ketat,
  • ketergantungan ke identitas eksternal melambat atau gagal.

Runbook respons cepat:

  1. Periksa metrik login success rate, error 4xx/5xx, dan latency di endpoint autentikasi.
  2. Rollback perubahan paling dekat dengan gejala: config rate limit, secret/session config, atau image aplikasi.
  3. Jika integrasi upstream yang gagal, aktifkan mode degradasi yang aman jika tersedia.
  4. Pastikan sesi peserta yang sudah aktif tidak ikut terputus akibat rollback.

Jika harus memilih, prioritaskan kelangsungan akses peserta yang sah sambil tetap mencatat anomali untuk audit manual nanti.

Contoh langkah rollback operasional

# Contoh urutan tindakan, sesuaikan dengan tooling CI/CD Anda
1. Pause rollout canary
2. Set traffic ke stable = 100%
3. Disable flag suspicious_session_auto_lock
4. Restore config revision sebelumnya
5. Verifikasi smoke test login dan submit
6. Catat waktu rollback dan incident ticket
7. Monitor 15 menit setelah stabilisasi

Yang penting bukan nama perintahnya, melainkan urutan pengambilan keputusan: hentikan perluasan dampak, kembalikan jalur stabil, verifikasi alur inti, lalu dokumentasikan.

Observability yang wajib dipasang

Observability untuk ujian online harus fokus pada alur bisnis kritikal, bukan hanya CPU dan memory.

Metrik utama

  • Login success rate per menit dan per tenant.
  • Latency autentikasi p50/p95 untuk endpoint login dan token refresh.
  • Error rate per endpoint penting: login, mulai ujian, autosave, submit.
  • Session invalidation rate atau logout paksa.
  • Queue lag untuk event audit, scoring, atau deteksi.
  • Jumlah peserta aktif dan korelasi dengan throughput layanan.
  • Volume event deteksi dan distribusi hasil rule: observe, warn, enforce.
  • Submit success rate dan jumlah retry.

Log terstruktur

Gunakan log JSON atau format terstruktur lain agar mudah dicari. Field yang umumnya penting:

  • timestamp, environment, service, version, region,
  • request_id, trace_id, user_id atau candidate_id yang telah dipseudonimkan bila perlu,
  • exam_id, tenant_id, policy_version, feature_flag_state,
  • result, error_code, upstream_dependency, decision_source.

Untuk audit, log perubahan konfigurasi dan flag juga harus menyimpan:

  • siapa yang mengubah,
  • kapan diubah,
  • nilai sebelum dan sesudah,
  • tiket perubahan atau incident ID.

Tracing untuk alur lintas layanan

Tracing sangat membantu ketika false negative atau timeout muncul akibat rantai layanan. Minimal, pastikan trace menghubungkan:

  • gateway atau ingress,
  • service login,
  • session store atau auth provider,
  • service ujian,
  • service audit/event bus,
  • engine deteksi atau rule evaluation.

Tanpa tracing, tim sering keliru menyalahkan aplikasi utama padahal bottleneck ada di dependency lain.

Alert yang layak dibuat

  • penurunan login success rate secara tajam,
  • kenaikan submit failure rate,
  • drop volume event audit atau deteksi yang tidak wajar,
  • lonjakan akun yang terkunci,
  • queue backlog pada pipeline audit atau deteksi,
  • perubahan feature flag di luar window yang diizinkan.

Audit insiden dan jejak perubahan

Audit insiden bukan dokumen legal besar setiap saat. Untuk platform ujian, audit minimal harus cukup menjawab:

  • perubahan apa yang dilakukan,
  • siapa yang melakukannya,
  • kapan perubahan aktif,
  • peserta atau tenant mana yang terdampak,
  • apa tindakan mitigasinya,
  • bagaimana status integritas ujian dipulihkan.

Event audit yang sebaiknya wajib

  • deploy dimulai dan selesai,
  • rollback dimulai dan selesai,
  • feature flag diubah,
  • kill switch diaktifkan atau dimatikan,
  • migrasi database dijalankan,
  • konfigurasi rate limit atau policy diubah,
  • user diblokir oleh rule tertentu,
  • override manual oleh operator atau pengawas.

Catatan: audit yang baik harus menjaga privasi. Simpan data yang cukup untuk investigasi, tetapi hindari menyebarkan data sensitif peserta ke banyak sistem observability tanpa kontrol akses yang tepat.

Runbook komunikasi saat insiden

Masalah teknis pada ujian hampir selalu berkembang menjadi masalah operasional. Karena itu runbook komunikasi harus ditulis sedetail runbook teknis.

Peran yang jelas

  • Incident Commander: memimpin keputusan, termasuk rollback atau freeze perubahan.
  • PIC aplikasi: menganalisis service utama dan deploy.
  • PIC platform/infrastruktur: menangani jaringan, ingress, compute, dan observability.
  • PIC database/data: memeriksa migrasi, lock, replikasi, queue, dan konsistensi.
  • Liaison operasional: menyampaikan status ke helpdesk, tim akademik, atau pengawas ujian.

Template komunikasi singkat

Status: Investigasi / Mitigasi / Pulih
Dampak: Peserta gagal login di tenant X, mulai pukul 09:12
Perubahan terkait: deploy auth config revision abc123 pukul 09:05
Tindakan saat ini: rollback config, disable adaptive rate limit
Risiko lanjutan: keterlambatan akses sebagian peserta
Update berikutnya: 10 menit lagi

Komunikasi semacam ini mencegah kebingungan dan mengurangi dorongan untuk melakukan banyak perubahan sekaligus saat insiden masih berlangsung.

Postmortem ringan setelah insiden

Postmortem tidak harus panjang, tetapi harus cukup konkret untuk mencegah kejadian berulang. Format ringan berikut biasanya cukup efektif:

Struktur postmortem

  1. Ringkasan insiden
    Apa yang rusak, kapan mulai, kapan pulih.
  2. Dampak
    Jumlah tenant, peserta, atau alur bisnis yang terdampak.
  3. Timeline
    Deploy, deteksi gejala, alert, rollback, stabilisasi.
  4. Akar masalah
    Misalnya threshold rule terlalu agresif, perubahan config tidak diuji pada tenant besar, atau event schema berubah tanpa backward compatibility.
  5. Yang berjalan baik
    Contoh: kill switch berhasil, rollback cepat, alert tepat sasaran.
  6. Yang perlu diperbaiki
    Contoh: kurangnya dashboard per tenant, tidak ada smoke test submit setelah login.
  7. Tindak lanjut
    Action item dengan pemilik dan tenggat.

Pertanyaan yang wajib dijawab

  • Mengapa perubahan bisa lolos ke produksi?
  • Mengapa deteksi insiden cepat atau justru terlambat?
  • Apakah rollback terhambat oleh migrasi, cache, atau dependency eksternal?
  • Apakah audit cukup untuk membuktikan peserta terdampak dan langkah pemulihan?
  • Perubahan proses apa yang harus diterapkan sebelum ujian berikutnya?

Tindakan pencegahan agar perubahan tidak merusak integritas ujian

  • Uji alur bisnis utama secara end-to-end, bukan hanya unit test layanan terpisah.
  • Gunakan data uji yang menyerupai tenant besar agar perilaku rate limit, queue, dan cache lebih realistis.
  • Pisahkan mode observasi dari mode penegakan untuk semua rule anti-fraud.
  • Pastikan backward compatibility untuk schema event dan API internal.
  • Latih rollback drill secara berkala; rollback yang tidak pernah diuji sering gagal saat benar-benar dibutuhkan.
  • Batasi akses perubahan policy hanya ke peran tertentu dan audit semua override manual.
  • Jangan gabungkan terlalu banyak perubahan dalam satu rilis sebelum ujian.
  • Sediakan dashboard per tenant dan per exam window agar dampak bisa diisolasi cepat.

Penutup

Runbook deploy untuk platform ujian online bukan sekadar dokumen prosedur, tetapi mekanisme perlindungan terhadap akses peserta, integritas penilaian, dan kemampuan audit setelah insiden. Saat tekanan meningkat karena kebutuhan deteksi kecurangan yang lebih ketat, tim DevOps justru perlu lebih disiplin: deploy kecil, observability kuat, feature flag yang jelas, canary yang hati-hati, dan rollback yang bisa dilakukan dalam hitungan menit.

Jika Anda hanya mengambil satu prinsip dari artikel ini, ambillah yang ini: jangan pernah menggabungkan perubahan berisiko tinggi dengan jalur pemulihan yang tidak teruji. Untuk sistem ujian, kegagalan rollback sering lebih merusak daripada bug awalnya.