Memilih Arsitektur AI Ops: Otomasi, Rollback, dan Batas Risiko

Saat workflow AI diberi wewenang untuk patch, deploy, atau rollback, masalah utamanya bukan apakah AI bisa mengeksekusi perintah, tetapi bagaimana membatasi dampak kesalahan. Dalam praktik operasional, rollback yang salah sering lebih berbahaya daripada tidak melakukan apa-apa: versi yang sebenarnya memperbaiki insiden bisa diganti dengan versi lama yang membawa bug lama, migrasi data bisa menjadi tidak kompatibel, dan tim on-call dipaksa menangani kegagalan berantai.

Karena itu, memilih arsitektur AI Ops tidak boleh dimulai dari pertanyaan “seberapa pintar modelnya”, melainkan dari batas risiko, blast radius, auditability, dan kemampuan rollback yang benar. Artikel ini membahas tiga pendekatan yang umum dipertimbangkan: AI agent otonom penuh, AI-assisted dengan human approval, dan automation tradisional berbasis rule, lalu mengaitkannya dengan biaya operasional, MTTR, beban on-call, serta maintainability sistem.

Mengapa rollback adalah titik risiko tertinggi

Pada banyak sistem produksi, rollback terdengar aman karena diasumsikan sebagai “kembali ke kondisi stabil terakhir”. Kenyataannya, asumsi itu sering salah.

• State aplikasi berubah: skema database, isi cache, indeks pencarian, atau kontrak antarlayanan bisa sudah berubah sejak versi lama berjalan.
• Rollback kode tidak sama dengan rollback data: Anda bisa menurunkan versi service, tetapi data yang ditulis versi baru belum tentu kompatibel dengan versi lama.
• Insiden observability bisa menipu: AI atau otomasi dapat melihat lonjakan error rate lalu menyimpulkan deploy terbaru adalah penyebab, padahal akar masalahnya ada di dependency eksternal, feature flag, atau kapasitas infrastruktur.
• Tindakan cepat memperbesar blast radius: agent yang diberi hak otomatis untuk rollback ke banyak service sekaligus dapat memperburuk outage lintas domain.

Pelajaran pentingnya: rollback harus diperlakukan sebagai perubahan berisiko tinggi, bukan sekadar tombol undo. Jika arsitektur AI Ops Anda tidak memisahkan antara deteksi, rekomendasi, persetujuan, dan eksekusi yang terkontrol, maka kesalahan keputusan akan langsung berubah menjadi insiden produksi.

Tiga pendekatan arsitektur AI Ops

1. AI agent otonom penuh

Pada model ini, agent dapat mengamati telemetry, menganalisis kemungkinan akar masalah, lalu mengeksekusi tindakan seperti restart, scale up, patch config, deploy hotfix, atau rollback tanpa persetujuan manusia.

Kapan cocok:

• Lingkungan dengan cakupan sangat sempit dan terkontrol.
• Tindakan yang benar-benar reversible dan berdampak kecil, misalnya restart worker stateless atau rotate pod pada service non-kritis.
• Organisasi yang sudah punya observability, policy engine, canary, dan verifikasi pasca-aksi yang matang.

Kelebihan:

• MTTR rendah untuk insiden sederhana dan berulang.
• Mengurangi beban tindakan manual pada on-call untuk kasus yang sudah dipahami.
• Berguna pada jam-jam kritis saat respon manusia lambat.

Kekurangan:

• Blast radius paling besar jika diagnosis salah.
• Auditability lebih sulit bila reasoning agent tidak diterjemahkan menjadi artefak yang dapat diperiksa.
• Biaya operasional bisa naik karena loop observasi, inferensi, dan validasi berjalan terus-menerus.
• Maintainability menurun bila logika operasi tersebar di prompt, tool wrapper, policy, dan orchestrator tanpa pemisahan tanggung jawab yang jelas.

Kesalahan umum:

• Memberi hak rollback lintas service tanpa batas domain.
• Mengizinkan agent mengeksekusi perubahan stateful tanpa pemeriksaan kompatibilitas data.
• Mengandalkan confidence score model sebagai dasar otorisasi tindakan produksi.

2. AI-assisted dengan human approval

Pendekatan ini menempatkan AI sebagai sistem rekomendasi dan persiapan eksekusi. AI boleh mengumpulkan context, menyusun diagnosis awal, membuat rencana rollback atau patch, menyiapkan command, bahkan menjalankan validasi pra-eksekusi, tetapi tindakan final membutuhkan persetujuan operator.

Kapan cocok:

• Sebagian besar sistem produksi yang berdampak bisnis nyata.
• Tim yang ingin mempercepat respons insiden tanpa menyerahkan kewenangan penuh ke agent.
• Lingkungan yang sering berubah, sehingga aturan tetap sulit menutupi semua kondisi.

Kelebihan:

• Keseimbangan terbaik antara MTTR dan kontrol risiko.
• Auditability lebih baik karena ada artefak approval, siapa menyetujui, kapan, dan atas dasar apa.
• Lebih mudah diterima oleh tim operasi dan compliance.
• On-call terbantu karena AI mengurangi waktu pencarian data, bukan mengambil seluruh keputusan.

Kekurangan:

• MTTR tidak serendah agent otonom pada insiden yang benar-benar rutin.
• Masih bergantung pada kualitas keputusan manusia di bawah tekanan.
• Jika UX approval buruk, operator cenderung menekan setuju tanpa verifikasi.

Kesalahan umum:

• Approval manusia hanya formalitas, tanpa ringkasan risiko yang jelas.
• AI boleh menyiapkan rollback, tetapi sistem tidak memvalidasi apakah migrasi database aman untuk diturunkan.
• Tidak ada mode simulasi atau dry-run sebelum tombol approve ditekan.

3. Automation tradisional berbasis rule

Ini adalah otomasi klasik: alert tertentu memicu playbook tertentu, dengan kondisi deterministik yang telah ditulis manusia. Tidak ada inferensi generatif dalam pengambilan tindakan inti.

Kapan cocok:

• Kasus operasi yang stabil, sering berulang, dan punya pola jelas.
• Organisasi dengan kebutuhan audit ketat.
• Lingkungan yang mengutamakan prediktabilitas di atas fleksibilitas.

Kelebihan:

• Paling mudah diaudit karena perilakunya deterministik.
• Biaya operasional lebih mudah diprediksi.
• Blast radius lebih mudah dibatasi lewat rule dan scope yang eksplisit.
• Maintainability baik selama rule tidak tumbuh liar.

Kekurangan:

• Kurang adaptif untuk insiden baru atau kombinasi gejala yang belum pernah didokumentasikan.
• MTTR bisa lebih tinggi jika operator tetap harus mengumpulkan banyak konteks manual.
• Rule bisa menjadi rapuh saat arsitektur sistem cepat berubah.

Kesalahan umum:

• Menumpuk banyak pengecualian hingga playbook sulit dipahami.
• Menganggap rule statis cukup untuk sistem yang terus berevolusi.
• Tidak menghapus atau menguji ulang rule lama setelah perubahan arsitektur.

Matriks keputusan: memilih pendekatan yang tepat

Tabel berikut bisa dipakai sebagai alat bantu awal. Nilai sebenarnya tetap harus dikalibrasi dengan konteks organisasi, tingkat kematangan observability, dan toleransi risiko.

Ringkasan praktis:

• Pilih AI otonom penuh hanya untuk aksi berisiko rendah, ruang lingkup sempit, dan verifikasi pasca-aksi otomatis.
• Pilih AI-assisted dengan human approval untuk patch, deploy, dan rollback pada sistem produksi penting.
• Pilih rule-based automation untuk tindakan yang sudah sangat dipahami dan harus sangat dapat diaudit.

Guardrail teknis minimum untuk workflow patch, deploy, dan rollback

Apa pun pendekatan yang dipilih, ada beberapa guardrail yang sebaiknya dianggap wajib. Tanpa guardrail ini, kemampuan AI hanya mempercepat kegagalan.

1. Pisahkan hak baca, rekomendasi, dan eksekusi

Jangan beri satu komponen akses penuh ke observability, perubahan konfigurasi, dan deployment target sekaligus tanpa pembatasan. Pisahkan peran menjadi:

• Reader: hanya membaca metrics, logs, traces, deployment history.
• Planner: menyusun hipotesis dan rencana tindakan.
• Executor: mengeksekusi command melalui policy engine yang ketat.

Dengan model ini, meskipun planner salah mendiagnosis, executor masih bisa menolak tindakan di luar policy.

2. Gunakan policy engine yang eksplisit

Prompt bukan policy. Guardrail harus berada di lapisan yang deterministik. Contoh kebijakan yang masuk akal:

• Rollback hanya boleh untuk service stateless.
• Rollback dilarang jika ada migrasi skema yang belum ditandai kompatibel mundur.
• Deploy hanya boleh ke canary environment lebih dulu.
• Perubahan maksimal satu service per eksekusi kecuali ada override manusia.

policy:
  actions:
    rollback:
      allowed_if:
        - service.is_stateless == true
        - release.has_backward_compatible_schema == true
        - deployment.age_minutes <= 30
      denied_if:
        - active_incident.severity == "critical-cross-service"
        - service.depends_on_stateful_migration == true
    patch_config:
      allowed_if:
        - target.environment in ["staging", "canary"]
        - diff.scope == "runtime-config"
    deploy:
      required_steps:
        - run_smoke_test
        - canary_5_percent
        - observe_error_budget

Formatnya bisa berbeda sesuai tool yang dipakai, tetapi prinsipnya sama: aturan eksekusi harus dapat diperiksa tanpa bergantung pada interpretasi model.

3. Wajibkan verifikasi pra-eksekusi dan pasca-eksekusi

Sebelum aksi dijalankan:

• Periksa deployment history.
• Validasi status migrasi dan kompatibilitas skema.
• Bandingkan sinyal sebelum dan sesudah perubahan terakhir.
• Pastikan tidak ada incident lock atau freeze window.

Sesudah aksi dijalankan:

• Jalankan smoke test.
• Pantau error rate, latency, saturation, dan business KPI minimum.
• Batalkan rollout jika metrik memburuk melewati ambang batas.

Tanpa verifikasi pasca-eksekusi, sistem tidak benar-benar “ops otomatis”; itu hanya runner command yang cepat.

4. Batasi blast radius secara default

• Satu aksi, satu service, satu environment.
• Gunakan canary atau traffic splitting sebelum full rollout.
• Batasi concurrency untuk aksi otomatis.
• Sediakan emergency stop yang bisa memutus seluruh eksekusi otomatis.

5. Simpan jejak audit yang utuh

Audit log minimal harus berisi:

• sinyal yang dibaca,
• hipotesis atau alasan tindakan,
• policy yang dievaluasi,
• command yang disiapkan dan dijalankan,
• hasil verifikasi pasca-eksekusi,
• identitas approver bila ada.

Ini penting bukan hanya untuk compliance, tetapi juga untuk postmortem dan perbaikan policy berikutnya.

Pola implementasi yang praktis

Pisahkan control plane dan execution plane

Jangan biarkan komponen analisis langsung menjalankan shell command ke cluster atau server. Gunakan control plane untuk reasoning, policy evaluation, dan approval flow; lalu gunakan execution plane yang sempit untuk menjalankan aksi yang sudah disetujui.

Incident Signals -> Context Collector -> AI Planner -> Policy Engine -> Approval Gate -> Execution Runner
                                                |                |
                                                |                -> Audit Log
                                                -> Suggested Runbook

Arsitektur ini bekerja karena tanggung jawabnya jelas:

• Context Collector mengumpulkan fakta, bukan keputusan.
• AI Planner menyusun opsi dan risiko.
• Policy Engine memutuskan apakah aksi boleh dilakukan.
• Approval Gate memegang kontrol manusia bila diperlukan.
• Execution Runner hanya menerima aksi yang sudah tervalidasi.

Gunakan status tindakan yang eksplisit

Workflow patch/deploy/rollback sebaiknya berbasis state machine sederhana, bukan sekumpulan webhook yang saling memanggil tanpa status yang jelas.

states:
  - proposed
  - validated
  - awaiting_approval
  - approved
  - executing
  - verifying
  - succeeded
  - failed
  - blocked

Keuntungan state machine:

• mudah diaudit,
• mudah di-retry secara aman,
• mudah dihentikan di titik tertentu,
• mengurangi risiko aksi ganda saat event terduplikasi.

Bedakan tindakan reversible dan irreversible

Ini salah satu desain yang paling sering dilupakan. Restart pod stateless, mengganti replica count, atau mengalihkan traffic canary relatif lebih reversible. Sebaliknya, menjalankan migrasi destruktif, menghapus data, atau rollback service yang mengubah format penyimpanan adalah tindakan irreversible atau sulit dipulihkan.

AI boleh lebih otonom untuk tindakan reversible. Untuk tindakan irreversible, default yang sehat adalah human approval + validasi lebih ketat.

Kapan monolith, modular monolith, atau service terpisah lebih masuk akal

Monolith

Cocok jika:

• tim masih kecil,
• workflow AI Ops masih terbatas,
• jumlah integrasi belum banyak,
• kebutuhan audit dan policy masih sederhana.

Kelebihan:

• Pengembangan lebih cepat.
• Debugging lebih mudah karena alur data berada di satu proses atau satu codebase.
• Latensi internal rendah dan deployment sederhana.

Kekurangan:

• Sulit memisahkan trust boundary jika semua komponen hidup bersama.
• Jika execution runner ada di monolith yang sama dengan planner, risiko eskalasi wewenang meningkat.
• Perubahan kecil pada satu modul dapat memaksa deploy seluruh sistem kontrol operasi.

Gunakan monolith jika Anda masih membangun fondasi dan belum membutuhkan isolasi kuat antara analisis, policy, dan eksekusi.

Modular monolith

Untuk banyak tim, ini adalah titik tengah terbaik.

Cocok jika:

• fitur AI Ops mulai berkembang,
• ingin memisahkan domain tanpa overhead service terpisah,
• membutuhkan pengujian dan ownership modul yang lebih disiplin.

Struktur modul yang masuk akal:

• incident-context
• planner
• policy
• approval
• executor
• audit

Kelebihan:

• Maintainability lebih baik daripada monolith datar.
• Boundary domain masih cukup jelas.
• Refactor lebih mudah bila nanti satu modul perlu dipisah menjadi service.

Kekurangan:

• Jika disiplin boundary lemah, modular monolith bisa jatuh menjadi monolith biasa.
• Isolasi keamanan tetap terbatas dibanding service terpisah.

Rekomendasi praktis: bila Anda sedang membangun AI-assisted workflow untuk patch/deploy/rollback, mulailah dari modular monolith kecuali ada kebutuhan compliance atau isolasi yang sangat kuat sejak awal.

Service terpisah

Cocok jika:

• trust boundary harus dipisah dengan tegas,
• executor perlu dijalankan di lingkungan yang lebih terkunci,
• audit log harus independen,
• skala dan ownership tim sudah besar.

Contoh pemisahan yang masuk akal:

• Planner Service: membaca context dan menghasilkan rekomendasi.
• Policy Service: mengevaluasi apakah aksi diperbolehkan.
• Execution Service: menjalankan aksi melalui kredensial yang dibatasi.
• Audit Service: menyimpan jejak keputusan yang tidak bisa dimodifikasi sembarangan.

Kelebihan:

• Isolasi keamanan dan wewenang lebih baik.
• Skalabilitas komponen lebih fleksibel.
• Kegagalan satu service tidak selalu menjatuhkan seluruh control plane.

Kekurangan:

• Kompleksitas distribusi meningkat: retry, idempotency, ordering event, dan observability antarlayanan menjadi pekerjaan nyata.
• Biaya operasional dan cognitive load tim naik.

Pilih service terpisah jika aksi produksi sudah kritis, ada banyak integrasi, atau Anda perlu memisahkan planner yang adaptif dari executor yang sangat ketat dan terkontrol.

Dampak arsitektur terhadap biaya operasional, on-call, dan maintainability

Biaya operasional

Biaya tidak hanya berasal dari infrastruktur model. Yang sering lebih mahal adalah:

• integrasi ke observability dan deployment tool,
• engineering time untuk policy dan guardrail,
• biaya insiden saat aksi salah,
• biaya audit dan postmortem,
• biaya maintainability saat sistem sulit dipahami.

AI otonom bisa terlihat hemat karena mengurangi intervensi manual, tetapi satu rollback salah pada sistem penting dapat menghapus penghematan itu. Untuk mayoritas tim, model AI-assisted sering memberi rasio biaya-manfaat yang lebih sehat.

On-call

Tujuan AI Ops bukan menghapus on-call, melainkan mengubah jenis kerja on-call:

• dari mengumpulkan data manual,
• menjadi memverifikasi hipotesis dan menyetujui tindakan yang aman.

Jika AI membuat keputusan secara otonom tanpa guardrail, on-call justru berpindah dari “operator” menjadi “pemadam kebakaran saat agent salah”. Itu jauh lebih melelahkan.

Maintainability

Maintainability memburuk ketika logika bisnis tersembunyi di banyak tempat: prompt, parser, policy file, skrip shell, pipeline CI/CD, dan runbook. Solusinya adalah memastikan setiap keputusan penting punya rumah yang jelas:

• heuristik dan reasoning di planner,
• izin dan batas risiko di policy engine,
• langkah teknis di executor,
• rekam jejak di audit service.

Contoh workflow rollback yang lebih aman

Berikut contoh alur untuk AI-assisted rollback pada service stateless:

1. Alert mendeteksi peningkatan error rate pasca deploy.
2. Context collector mengambil deployment history, change diff, logs, traces, dan status dependency eksternal.
3. AI planner menyusun dua atau tiga hipotesis, misalnya: bug aplikasi, timeout ke dependency, atau cache poisoning.
4. Policy engine memeriksa apakah rollback diperbolehkan: service stateless, tidak ada migrasi inkompatibel, usia deploy masih dalam jendela aman, dan tidak ada incident freeze.
5. Sistem menampilkan rekomendasi ke operator beserta risiko, command yang akan dijalankan, dan metrik verifikasi sesudah rollback.
6. Operator menyetujui rollback canary ke sebagian traffic.
7. Execution runner melakukan rollback terbatas.
8. Verifier memantau error rate dan latency. Jika membaik, rollout diperluas; jika tidak, rollback dihentikan dan hipotesis lain diprioritaskan.

Alur ini bekerja karena rollback diperlakukan sebagai eksperimen terkontrol, bukan respons refleks.

Checklist keputusan sebelum memberi AI hak patch, deploy, atau rollback

• Apakah tindakan ini reversible?
• Apakah sistem mampu membedakan rollback kode dan rollback data?
• Apakah ada policy engine terpisah dari prompt dan model?
• Apakah blast radius dibatasi per service dan per environment?
• Apakah ada verifikasi pasca-eksekusi yang otomatis?
• Apakah audit log cukup untuk postmortem?
• Apakah operator bisa menekan emergency stop?
• Apakah executor hanya memiliki kredensial minimum yang dibutuhkan?
• Apakah workflow tahan terhadap retry, duplikasi event, dan partial failure?

Penutup

Memilih arsitektur AI Ops untuk otomasi, rollback, dan batas risiko pada dasarnya adalah keputusan kontrol, bukan sekadar keputusan kecerdasan. AI agent otonom penuh hanya masuk akal untuk ruang lingkup yang sempit dan reversible. Untuk patch, deploy, atau rollback pada sistem produksi penting, pendekatan yang paling realistis biasanya adalah AI-assisted dengan human approval, didukung policy engine yang deterministik, blast radius yang kecil, dan audit trail yang lengkap.

Jika Anda baru mulai, jangan langsung membangun agent yang boleh melakukan semua hal. Mulailah dari workflow yang sempit, gunakan modular monolith bila perlu, pisahkan planner dari executor, dan perlakukan rollback sebagai tindakan berisiko tinggi. Dalam operasi produksi, sistem yang lebih lambat tetapi bisa dipercaya hampir selalu lebih bernilai daripada sistem yang sangat cepat tetapi salah mengambil tindakan.