Circle K Amazon Bedrock DevOps: Triage Insiden Pangkas Jadi 15 Menit

Masalah Nyata di Balik Ribuan Toko Circle K: Kenapa Triage Bikin Pusing?

Circle K bukan sekadar minimarket biasa di pinggir jalan. Perusahaan ini mengoperasikan lebih dari 17.200 gerai toko kelontong dan stasiun pengisian bahan bakar di 27 negara. Di balik etalase toko fisiknya, berjalan infrastruktur berbasis cloud di AWS yang menopang sistem kasir (point-of-sale atau POS), aplikasi program loyalitas pelanggan, hingga jaringan pengisian daya kendaraan listrik (EV charging).

Ketika operasional digital makin gede, jumlah alert otomatis yang masuk ke tim DevOps ikutan meledak. Tim memantau seluruh infrastruktur lintas akun AWS menggunakan Grafana. Dalam sehari, alert yang masuk bisa bermacam-macam bentuknya: mulai dari container yang restart mendadak, lonjakan error rate, latensi yang melonjak tinggi, sampai deployment kode yang gagal.

Setiap ada alert masuk, engineer on-call biasanya harus melakukan ritual panjang:

1. Membuka Amazon CloudWatch buat memeriksa log terbaru dari container atau server.
2. Mengecek distributed traces di Amazon OpenSearch Service guna melihat alur eror di tingkat aplikasi.
3. Memeriksa status task di Amazon Elastic Container Service (Amazon ECS).
4. Mencocokkan gejala kerusakan dengan runbook manual yang disimpan di repositori GitHub.

Proses manual ini memunculkan dua masalah besar. Pertama, tugas menarik log dan memeriksa metrik selalu berulang persis sama di setiap insiden. Kedua, kecepatan dan ketepatan triage insiden devops ai ini sangat bergantung pada seberapa hafal engineer tersebut dengan layanan yang sedang tumbang. Kalau yang kebagian on-call adalah engineer baru, proses investigasi otomatis makan waktu lebih lama.

Kenapa Circle K Memilih Amazon Bedrock Dibanding Bikin Sendiri?

Sebelum memutuskan pakai Amazon Bedrock, tim engineering Circle K sempat mengevaluasi opsi lain, termasuk memakai framework open source di server sendiri (self-managed). Tapi jalan itu langsung ditinggalkan karena bakal bikin tim repot mengurus hosting model AI, versi prompt, integrasi alat, sampai tambal celah keamanan infrastruktur.

Circle K akhirnya memilih Amazon Bedrock karena beberapa alasan praktis:

• Satu API untuk banyak model: Tim bisa memanggil berbagai foundation model terbaik cukup lewat satu antarmuka API, bahkan bisa gonta-ganti model tanpa perlu merombak ulang baris kode aplikasi. Ketersediaan model tiap region bisa dicek langsung di panduan daftar model per AWS Region.
• Integrasi ekosistem AWS: Karena beban kerja Circle K sudah berjalan di AWS, Bedrock langsung klop dengan konfigurasi IAM policies, Amazon VPC, dan pipeline pencatatan log yang sudah ada.
• Orkestrasi dan RAG terkelola penuh: Fitur Amazon Bedrock Knowledge Bases menangani proses Retrieval-Augmented Generation (RAG) secara otomatis untuk membaca lembar informasi produk (product cards), tanpa tim harus repot menyetel dan memelihara vector database terpisah.
• Privasi dan keamanan data ketat: Log produksi sistem ritel memuat data sensitif. Amazon Bedrock memastikan data operasional milik pelanggan tidak dibagikan ke pihak penyedia model mana pun dan tidak dipakai buat melatih ulang model dasar.

Bedah Arsitektur Pertama: Triage Otomatis Pakai Amazon Bedrock Flows

Pada versi pertama sistem otomasi devops bedrock ini, Circle K mengandalkan Amazon Bedrock Flows sebagai pengatur orkestrasi beberapa agen AI khusus yang bekerja sama secara terstruktur.

Alur investigasinya berjalan secara otomatis dari hulu ke hilir:

1. Alert terpicu: Saat Grafana mendeteksi anomali metrik, notifikasi dikirim ke Amazon SNS, lalu diteruskan ke antrean Amazon SQS.
2. Pemicu Lambda: Fungsi AWS Lambda mengambil payload alert dari SQS dan langsung memanggil Bedrock Flow.
3. Dua agen bekerja paralel: Di dalam Flow, ada dua agen yang jalan berbarengan:
   • AWSResourceExplorerAgent: Memeriksa kondisi infrastruktur lintas akun AWS Organizations, mulai dari status task Amazon ECS, kesehatan target Application Load Balancer (ALB), sampai metrik CloudWatch.
   • OpenSearchExplorerAgent: Menyisir trace dan log aplikasi bervolume besar di Amazon OpenSearch Service. Agen ini juga punya akses khusus ke Knowledge Base untuk menarik product card layanan terkait.
4. Agen penelusur kode: Setelah dua agen tadi selesai, GitHubExplorerAgent mulai bekerja. Karena sudah mengantongi informasi spesifik dari agen sebelumnya, agen ini nggak mencari kode secara membabi buta, melainkan langsung memeriksa repositori GitHub yang relevan, definisi infrastruktur, dan commit terakhir.
5. Penyusunan ringkasan: Semua temuan masuk ke node AnalysisPrompt. Node ini memanggil satu model LLM tanpa tools tambahan untuk merangkum akar masalah, bukti log, penanggung jawab, dan saran perbaikan.
6. Kirim ke Slack: Hasil akhir dikirim kembali ke Lambda, lalu otomatis diposting ke channel Slack tim on-call dalam format ringkas yang bisa dibaca dalam waktu kurang dari 2 menit.

Seluruh proses dari alarm pertama berbunyi sampai ringkasan muncul di Slack cuma butuh waktu 5 sampai 15 menit.

Contoh Nyata: Cara AI Menganalisis Eror Database dalam Hitungan Menit

Biar ada gambaran jelas, bayangkan skenario nyata yang dialami Circle K berikut. Sistem monitoring Grafana menangkap alert: tingkat eror HTTP 5xx pada suatu microservice menembus angka lebih dari 5% selama 3 menit berturut-turut.

Begitu sistem triage berjalan:

• AWSResourceExplorerAgent memeriksa ECS task dan mendapati connection pool database habis terpakai, sehingga container ECS terus-menerus gagal dan mencoba restart.
• OpenSearchExplorerAgent menemukan log aplikasi berisi pesan eror "connection refused" saat menghubungi database PostgreSQL. Agen ini juga membaca product card layanan dari knowledge base yang mengonfirmasi ketergantungan service tersebut ke database terkait.
• GitHubExplorerAgent membuka file konfigurasi Amazon RDS milik service tersebut di GitHub. Agen menemukan bahwa kode aplikasi ternyata membuka koneksi database baru di setiap request yang masuk, alih-alih memakai ulang koneksi yang sudah ada (connection pooling).
• AnalysisPrompt menggabungkan data itu dengan jadwal kampanye promosi marketing yang kebetulan baru dimulai 10 menit sebelum alert meledak.

Notifikasi yang mendarat di Slack engineer on-call langsung berbentuk ringkasan siap tindak seperti ini:

Summary: XYZ Service 5xx errors caused by connection pool exhaustion
Root cause: Scheduled marketing campaign drove traffic spike; connection pool max (50) insufficient for load
Evidence: OpenSearch logs show "connection refused" at 14:32 UTC; ECS shows 3 task restarts since 14:30
Owner: XYZ team (backend)
Next steps: Add Amazon RDS Proxy to pool connections, or update the service to reuse existing connections instead of opening a new one per request; consider an Auto Scaling rule for future campaigns

Engineer yang membaca pesan tersebut nggak perlu menebak-nebak lagi. Mereka langsung tahu akar masalahnya ada pada lonjakan traffic kampanye promosi dan tahu persis solusi kode apa yang harus diterapkan.

Upgrade ke Amazon Bedrock AgentCore: Solusi Buat Data Skala Besar

Arsitektur Bedrock Flows berhasil dipakai selama berbulan-bulan. Tapi seiring makin banyaknya volume log dan data investigasi yang kian dalam, beberapa insiden rumit butuh durasi analisis yang lebih panjang daripada batas waktu eksekusi satu node Flow.

Untuk mengatasi kendala itu, Circle K melakukan migrasi ke Amazon Bedrock AgentCore. Platform ini dirancang khusus untuk membangun, menghubungkan, dan mengoptimalkan agen AI skala besar.

Pada arsitektur baru ini, tiga agen khusus yang sebelumnya terpisah disatukan menjadi satu kesatuan agen yang berjalan di dalam sesi AgentCore Runtime. Komponen AgentCore Gateway bertindak sebagai perantara yang menyediakan akses ke seluruh sumber data (OpenSearch, Knowledge Bases, dan GitHub) dalam bentuk kumpulan tools yang aman.

Ada tiga keunggulan utama yang didapat tim Circle K setelah beralih ke bedrock agentcore devops:

Hasil Nyata Circle K: Waktu Triage Terpangkas Sampai 75%

Setelah versi AgentCore resmi meluncur ke lingkungan produksi pada April 2026, metrik internal incident-response Circle K mencatat lompatan efisiensi yang sangat memuaskan:

• Rata-rata waktu triage (MTTT): Turun drastis dari 45–60 menit menjadi di bawah 15 menit. Penurunan waktu tunggu ini mencapai 67% hingga 75%.
• Insiden sederhana: Investigasi pada satu layanan tunggal rata-rata selesai hanya dalam 5 sampai 8 menit.
• Insiden kompleks: Kasus gangguan multi-service rumit yang tadinya butuh investigasi manual lebih dari 1 jam kini tuntas dianalisis dalam waktu maksimal 15 menit.

Selain angka metrik yang turun, gaya kerja tim engineering di lapangan juga berubah total. Standar kualitas triage kini jadi konsisten karena siapa pun yang bertugas bakal menerima format ringkasan yang sama lengkapnya. Eskalasi ke tim backend lain jadi jauh lebih mulus karena data bukti sudah tersaji rapi, dan tim bisa mengabaikan alarm palsu (false alarms) jauh lebih cepat tanpa buang-buang waktu.

4 Pelajaran Penting Buat Tim DevOps yang Mau Bikin AI Agent

Dari perjalanan riset dan uji coba membangun sistem ini, tim studi kasus bedrock circle k membagikan empat pelajaran berharga yang sangat krusial buat tim mana pun yang ingin mengadopsi AI di pipeline operasional mereka:

1. Masukkan Cuplikan Log Langsung ke Prompt

Di versi awal, sistem cuma mengirim nama log group dan rentang waktu ke agen, lalu membiarkan agen memanggil CloudWatch lewat action groups. Hasilnya lambat dan datanya sering kali terlalu menumpuk. Solusi terbaiknya: biarkan fungsi Lambda melakukan query awal (pre-query), lalu masukkan baris log eror yang relevan langsung ke dalam teks prompt. LLM bernalar jauh lebih cepat saat langsung membaca teks eror aslinya.

2. Jangan Mengutak-atik RAG Berlebihan Jika Pengaturan Default Sudah Bagus

Circle K menguji berbagai konfigurasi vector database. Menariknya, fitur bawaan Amazon Bedrock Knowledge Bases dengan pengaturan default justru memberikan hasil paling optimal untuk dokumen product card mereka. Memakai fitur terkelola penuh membuat tim nggak perlu repot mengurus vector store sendiri.

3. Cari Kode di GitHub Berdasarkan Temuan Log, Bukan Sebaliknya

Mencari akar masalah langsung ke repositori kode tanpa petunjuk log awal cuma bakal menghasilkan ribuan baris pencarian yang nggak relevan. Jalankan pencarian repositori GitHub hanya setelah kamu tahu error message atau komponen apa yang bermasalah dari log sistem.

4. Pisahkan Logika Analisis dari Lapisan Orkestrasi

Pastikan instruksi prompt, definisi alat (tools), dan langkah analisis tidak terikat mati pada arsitektur orkestrasi (apakah itu Flows, LangChain, atau skrip kustom). Kunci keberhasilan migrasi Circle K ke AgentCore tanpa menulis ulang logika penalaran adalah karena struktur prompt mereka dibuat sepenuhnya independen.

Berikut contoh template prompt penalaran yang bisa kamu tiru untuk menganalisis log insiden secara terstruktur:

Kamu adalah DevOps Incident Investigator Agent. Tugasmu adalah menganalisis ringkasan eror berikut dan menemukan akar masalahnya. DATA METRIK & LOG:- Layanan: {{nama_service}}- Pesan Eror Utama: {{cuplikan_log_eror}}- Status Task ECS: {{status_task}}- Riwayat Commit Terakhir: {{commit_github}} INSTRUKSI:1. Analisis korelasi antara perubahan kode terakhir dengan gejala eror di log.2. Tentukan kemungkinan akar masalah utama (root cause).3. Berikan saran perbaikan konkret tingkat kode dan tingkat infrastruktur. FORMAT OUTPUT (Wajib dipatuhi):Summary: [Ringkasan 1 kalimat]Root cause: [Penyebab utama kegagalan]Evidence: [Kutipan log dan metrik pendukung]Owner: [Tim yang bertanggung jawab]Next steps: [Langkah perbaikan langsung dan pencegahan jangka panjang]

Dampak dan Pelajaran Berharga Buat Bisnis & Tim Engineering di Indonesia

Apakah pola arsitektur seperti Circle K ini cocok diterapkan di Indonesia? Jawabannya: sangat cocok, terutama buat startup skala berkembang, perbankan digital, maupun platform e-commerce lokal yang tim engineering-nya sering kewalahan menghadapi alert fatigue.

Bagi perusahaan di Indonesia yang terikat regulasi kepatuhan data seperti UU Perlindungan Data Pribadi (UU PDP), arsitektur berbasis Amazon Bedrock memberikan rasa aman ekstra. Data metrik transaksi dan log internal tidak akan bocor ke publik atau dipakai melatih model pihak ketiga. Kamu bisa menyaring data pribadi (PII) di level Lambda sebelum diteruskan ke agen AI.

Selain itu, efisiensi waktu pemulihan insiden (Mean Time to Recovery / MTTR) berbanding lurus dengan kelangsungan bisnis. Bayangkan jika aplikasi kasir retail atau checkout belanjaan down selama 1 jam di jam sibuk gajian: potensi omzet ratusan juta bisa lenyap begitu saja. Memangkas fase diagnosa menjadi di bawah 15 menit berarti menyelamatkan pendapatan dan menjaga kepercayaan pelanggan.

Kalau tim developer kamu ingin mulai bereksperimen menghubungkan model AI kelas dunia seperti Claude Sonnet 5.5 (Rp3.600 / 1 juta token input) atau GPT-4o (Rp525 / 1 juta token input) ke alur kerja coding dan monitoring tanpa kartu kredit luar negeri, kamu bisa mencoba layanan Classai Router. Cukup pakai satu API key dengan format SDK standar, kamu sudah bisa menghubungkan berbagai model bahasa ke pipeline monitoring aplikasi dengan saldo rupiah terjangkau.

Bagi kamu yang ingin memperdalam keterampilan merancang arsitektur AI agent dan otomasi sistem kerja modern, ikuti juga program belajar praktis di Kelas AI untuk Developer.