Elastic nightshift AI SRE: Mulai dari Engine Investigation

Kebanyakan produk AI SRE datang sebagai satu paket: pasang, lalu ia mendeteksi, mendiagnosis, dan memperbaiki. Susah menjawab ya, karena Anda tidak bisa memberi bagian yang diinginkan (second opinion saat page jam 3 pagi) tanpa memberi bagian yang ditakuti (sesuatu menjalankan command di production).

Pengumuman nightshift dari Elastic pada 8 Oktober 2026 dirancang berbeda, dan itu bagian yang menarik. Saya belum mendapat akses preview, jadi tulisan ini adalah pembacaan cermat atas pengumuman Elastic, halaman sign-up, dan dokumentasi Workflows, ditambah argumen saya sendiri soal urutan rollout. Bila sesuatu adalah penilaian saya dan bukan pernyataan Elastic, saya sebutkan.

Apa yang sebenarnya diumumkan Elastic

Elastic mengumumkan nightshift AI SRE sebagai Private Preview di dalam Elastic Observability, dan menyebut tim SRE-nya sendiri sudah menjalankannya terhadap environment production Elastic. Agent ini memantau telemetry terus-menerus, mendeteksi masalah termasuk yang tidak dicakup alert rule, menyelidikinya, lalu merekomendasikan atau menerapkan perbaikan. Setiap langkah penalaran bisa diikuti dan data mentahnya bisa dibuka.

Aksesnya lewat waitlist. Pengumuman menyebut Private Preview terbuka untuk pengguna Elastic yang sudah ada tanpa biaya selama masa early access, sedangkan halaman sign-up menulisnya gratis untuk pengguna Elastic Observability Serverless, satu-satunya deployment yang didukung saat ini. Kedua halaman tidak memberi harga setelah preview maupun tanggal general availability, jadi anggap biaya sebagai hal yang belum diketahui.

Empat engine, masing-masing bisa dipakai sendiri

Klaim strukturalnya: nightshift adalah empat engine, bukan satu agent, dan Anda boleh memakai salah satunya secara terpisah. Tabel ini diringkas dari deskripsi Elastic sendiri untuk tiap engine.

Baca kolom Pemicu sebagai graf dependency. Investigation satu-satunya engine yang bisa mulai dari sesuatu yang sudah Anda miliki, yaitu alert, sedangkan Detection menciptakan sinyal baru dan Remediation butuh investigation selesai untuk bertindak. Asimetri itu dasar urutan rollout di bagian berikut.

Kenapa Investigation saja adalah pintu masuk berisiko rendah

Argumen saya, bukan Elastic: adopsi Investigation lebih dulu, pada alert yang memang sudah membangunkan Anda. Ia tidak menambah sumber alert baru, jadi volume page tidak berubah. Ia tidak menyentuh apa pun, karena bertindak adalah tugas Remediation. Dan hasilnya bisa dinilai, sebab manusia sudah tahu bagaimana tiap insiden itu sebenarnya berakhir.

Bandingkan alternatifnya. Mengaktifkan Detection menambah aliran Significant Events yang belum punya prosedur on-call, jadi Anda mengukur agent sekaligus mendesain ulang alerting. Mengaktifkan Remediation tanpa rekam jejak berarti memercayai parameter yang belum pernah Anda lihat ia pilih. Investigation lebih dulu memberi waktu membangun rekam jejak itu.

Deskripsi Elastic mendukung pembacaan aman ini dalam dua hal. Setiap aksi yang diusulkan menunggu review pengguna, dan setiap langkah investigation beserta data mentahnya bisa diperiksa, sehingga kesimpulan yang salah bisa dilacak, bukan sekadar diragukan. Satu hal yang tidak bisa saya pastikan dari halaman yang saya baca: apakah Investigation bekerja baik tanpa engine Context menyala. Tanyakan itu saat panggilan waitlist.

Sambungkan alert yang sudah Anda punya

Sebelum agent menyentuh apa pun, catat dulu bahan penilaiannya. Workflows Elastic adalah automasi YAML di Kibana dengan trigger, input, dan step, dan halaman triggers menyebut alert trigger memulai workflow saat detection atau alerting rule menghasilkan alert, dengan alert tersedia lewat field event. Ini baseline recorder, bukan konfigurasi nightshift.

# Kibana Workflow: record every alert as a baseline BEFORE any AI touches it.
# Syntax follows Elastic's Workflows docs: triggers with "type: alert", the
# alert exposed under "event", and a "console" step that prints a message.
name: alert-baseline-recorder
description: Log each alert the AI SRE pilot will later investigate
enabled: true
tags: ["ai-sre-pilot", "baseline"]

triggers:
  - type: alert        # starts when a detection or alerting rule raises an alert

steps:
  - name: dump_event
    type: console
    with:
      # Print the whole event first. The docs page says it carries fields,
      # severity and rule information, but does not list the exact paths,
      # so read one real payload before you template individual fields.
      message: |
        alert received at ingest time
        event: {{event}}

Pengumuman menyebut Investigation bisa dimulai oleh alert apa pun di Elastic atau tool terhubung, tetapi halaman yang saya baca tidak mendokumentasikan cara koneksi itu dikonfigurasi selama preview, jadi saya tidak mengarang pengaturannya. Sisi Kibana adalah alerting biasa: rule punya condition, schedule, dan action, dan action mengirim notifikasi lewat connector seperti email atau Slack.

Poin praktisnya adalah urutan. Biarkan rule dan connector Anda apa adanya, tambahkan recorder, dan kumpulkan alert seminggu lengkap dengan timestamp sebelum ada investigation sebagai pembanding. Kalau tidak, Anda akan mengingat versi agent atas kejadian, bukan versi Anda sendiri.

Remediation: buat review benar-benar bermakna

Elastic menyebut engine Remediation memilih Elastic Workflow atau connector action dan mengisi parameternya, dan setiap aksi yang diusulkan menunggu review. Pengguna menentukan seberapa banyak yang dikerjakan agent sendiri: review tiap aksi beserta parameternya sebelum jalan, atau biarkan ia menerapkan perbaikan otomatis.

Opsi kedua akan menggoda, dan opsi pertama hanya sebaik reviewer-nya. Reviewer yang menekan approve di setiap usulan sama saja dengan auto-apply dengan langkah tambahan. Jadi saya akan menuliskan di muka apa yang dibaca reviewer dan kapan ia menolak. Blok di bawah adalah template buatan saya sendiri, karena tidak ada file semacam itu di pengumuman.

# MY OWN review rubric, not Elastic syntax. Nothing in the announcement
# defines a policy file; this is what I would write down before enabling
# Remediation, so that "review each action" means something specific.
remediation_review:
  default: human_approves_every_action
  read_before_approving:
    - the Workflow or connector action chosen
    - every parameter value it filled in
    - the investigation step that justified it
    - the blind spots the investigation listed
  never_approve_when:
    - a blind spot overlaps the target service
    - the parameters name a resource the root cause did not mention
    - the action cannot be undone and nobody is on call to watch it
  auto_apply:
    allowed: false           # revisit only after a month of approved-as-written actions
    candidate_actions: []    # start empty; add one reversible action at a time

Halaman Agent Builder Elastic menyebut Elastic Workflows dapat diekspos sebagai tool yang bisa dipakai ulang, yang memberi petunjuk mengapa katalog aksi penting: setup Remediation paling aman adalah yang menawarkan aksi paling sedikit dan paling mudah dibatalkan. Mulai dari daftar pendek yang nyaman Anda jalankan sendiri, lalu tambah dengan sengaja.

Failure mode dan trade-off yang perlu diperhitungkan

Pertama, bukti. Halaman yang saya baca tidak memuat angka akurasi, presisi, atau waktu penyelesaian yang dipublikasikan untuk nightshift, dan satu-satunya bukti yang disebut adalah tim SRE Elastic sendiri memakainya di production. Itu sinyal wajar untuk preview, bukan benchmark. Halaman sign-up memang menampilkan angka pelanggan, tetapi itu menggambarkan Elastic Observability, bukan agent ini, jadi jangan dibawa ke sini.

Kedua, angka pinjaman. Artikel context engineering Elastic melaporkan tool call turun dari 33 ke 9 dan input token turun 71 persen, tetapi itu satu contoh simulasi, bukan benchmark umum dan bukan nightshift. Kutip sebagai ilustrasi mengapa context yang disiapkan membantu, jangan sebagai hasil yang diharapkan.

Ketiga, cakupan. Data Serverless didukung sekarang. Elastic Cloud Hosted, cluster self-managed, tool observability pihak ketiga, dan telemetry store lain direncanakan untuk technical preview akhir tahun ini, dan integrasi Slack masih dikembangkan. Beranda Kibana, Elastic CLI, dan MCP adalah permukaan yang disebut saat ini. Jika telemetry Anda ada di tempat lain, pilot Anda berarti menunggu.

Empat tahap adopsi dibandingkan

Empat engine yang sama menghasilkan profil risiko yang sangat berbeda tergantung seberapa banyak yang Anda nyalakan. Ini perbandingan saya atas tahap-tahap itu, diturunkan dari deskripsi engine Elastic, bukan panduan rollout dari vendor.

Context ada di bawah keempat tahap. Elastic menjelaskan ia memberi makan engine lain, jadi harapkan memberinya akses data dan sistem sejak awal, dan putuskan siapa yang boleh melihat runbook dan wiki sebelum ia membacanya.

Yang dikerjakan hari Senin

Semua ini bisa dimulai tanpa akses preview. Lima langkah ini menyiapkan Anda, sehingga saat akses datang Anda mengukur, bukan menebak.

1. Daftar waitlist lewat halaman sign-up, dan pastikan deployment Anda: saat ini hanya data Elastic Observability Serverless yang didukung.
2. Deploy alert baseline recorder, lalu kumpulkan alert seminggu beserta resolusi sebenarnya yang ditulis engineer yang menanganinya.
3. Pilih satu service yang berisik tetapi taruhannya rendah sebagai lingkup pilot, dan tanyakan ke Elastic secara tertulis bagaimana alert dari setup Anda sampai ke Investigation dan apakah Context harus menyala.
4. Jalankan Investigation saja. Nilai setiap laporan dengan scorecard di bawah, termasuk apakah kesalahan jatuh di dalam blind spot yang tercantum.
5. Tulis rubrik Remediation sebelum mengaktifkannya, dan biarkan scorecard yang memutuskan kapan engine itu layak mendapat aksi pertamanya.

# Pilot scorecard: one row per investigation, filled in by the on-call human.
# Score against the incident's real resolution, not against how confident
# the report sounded.
alert_id:            # the alert that triggered the investigation
human_root_cause:    # written by the engineer, BEFORE reading the report
report_root_cause:   # copied from the investigation conclusion
verdict:             # match | partial | wrong
blind_spots_listed:  # yes | no  (did it admit what it could not check?)
blind_spot_was_real: # yes | no  (was the missed cause inside a listed blind spot?)
minutes_to_first_useful_hypothesis_human:
minutes_to_first_useful_hypothesis_report:
proposed_action:     # what Remediation would have run, even if you never enable it
action_would_have_helped:  # yes | no | harmful

Sebulan scorecard juga satu-satunya bukti yang benar-benar tentang sistem Anda. Cerita production dari vendor, sejujur apa pun, adalah tentang sistem mereka.

Ide berguna di nightshift bukan otonominya, melainkan sambungannya. Karena engine Context, Detection, Investigation, dan Remediation bisa dipisah, Anda dapat menerima bagian terkecil yang layak dan menolak sisanya sampai ia punya rekam jejak. Mulai dari tempat agent hanya bisa membaca, nilai terhadap kesimpulan engineer Anda, dan beri hak bertindak paling akhir.