Dari Waktu Aktif ke Pengalaman: Peralihan Berbasis AI dalam Observabilitas Modern

Pada tahun 2001, IBM menulis manifesto TI otonom. Visi Komputasi Otonom memecah manajemen mandiri menjadi empat pilar: optimasi mandiri, penyembuhan mandiri, konfigurasi mandiri, dan perlindungan mandiri. Saya berada di Microsoft ketika IBM menyampaikan visi TI ini. Kami merespons dengan mengusulkan ide teknologi seperti pusat data otonom, namun pada akhirnya, itu hanyalah mimpi yang terlalu maju untuk zamannya. Tidak ada cara praktis untuk mewujudkan visi tersebut.

Pada masa saya di Microsoft, saya berada di tim yang mengerjakan Clippy. Meskipun asisten klip kertas animasi itu terkenal mengganggu, idenya sendiri kuat: komputer harus secara aktif membantu manusia dalam pekerjaan mereka. Kami hanya belum memiliki daya komputasi dan AI yang cukup untuk mewujudkannya. 25 tahun kemudian, kami akhirnya dapat melakukannya.

Dari Tingkat Layanan ke Tingkat Pengalaman

Konsep observabilitas tidak berasal dari TI. Pada tahun 1960, insinyur dan matematikawan Hungaria‑Amerika Rudolf E. Kálmán memperkenalkan istilah “observability” untuk menggambarkan seberapa baik sebuah sistem dapat diukur melalui outputnya. Kemudian, pada tahun 2013, Twitter mengadopsi istilah dalam serangkaian posting blog, secara efektif menyatakan bahwa pemantauan tradisional, melalui semua alat komersial siap pakai yang mereka miliki, dirancang untuk era teknologi yang berbeda dan tidak berfungsi pada arsitektur berskala mikroservis.

Anggaplah seperti dokter memeriksa pasien. Mereka dapat memeriksa denyut nadi, mengukur tekanan darah, dan mengamati fitur eksternal lain untuk secara tidak langsung menilai kesehatan internal pasien. Dalam TI, kita harus melakukan hal yang sama. Ketika ada fluktuasi pada denyut nadi pasien, kita perlu mengetahui apakah itu menandakan masalah pada ginjal atau hati. Pada skala dan kompleksitas operasi yang dihadapi Twitter bahkan 20 tahun yang lalu (perusahaan hanya melayani 100 juta pengguna dengan tweet dan feed real‑time), observabilitas memerlukan alat dan pendekatan pemantauan yang berbeda.

Sistem saat ini menjadi semakin besar dan kompleks, dengan ketergantungan pada jaringan pengiriman konten, caching dan distribusi bitmap, font, berkas JavaScript, dan sebagainya di seluruh dunia. Memahami secara mendalam kinerja aplikasi dunia nyata bukanlah hal yang mudah.

Ketika tim TI dipanggil pada pukul 4 pagi, seseorang harus bangun dari tempat tidur dan mencari tahu apakah masalahnya disebabkan oleh sektor buruk pada hard drive atau aktor jahat yang mencoba menembus dan mengacaukan infrastruktur. Sebenarnya tidak penting mana yang terjadi: pada akhirnya, tugas mereka adalah menjaga semua sistem tetap berjalan. Untungnya, untuk menilai kesehatan aplikasi saat ini, kita dapat mengumpulkan semua telemetri yang tersedia: setiap perangkat jaringan, setiap aplikasi, ribuan integrasi siap pakai, alur tiket melalui JIRA atau Atlassian, dan banyak sinyal lainnya.

Di sinilah Experience Level Objectives (XLOs) berperan. Anda mungkin pernah mendengar Service Level Agreements (SLAs) dan Service Level Objectives (SLOs), tetapi XLOs melangkah lebih jauh dengan mengukur apakah pelanggan dan karyawan Anda memperoleh tingkat pengalaman yang mereka inginkan. Ini tentang kualitas, bukan sekadar waktu aktif. Dari perspektif teknis, satu‑satunya cara untuk mencapai XLOs adalah dengan memiliki visibilitas dari NIC hingga perangkat pengguna akhir.

Pada Oktober lalu, AWS US‑EAST‑1 mengalami gangguan. Catchpoint mendeteksi masalah tersebut 16 menit sebelum Amazon mengumumkannya secara publik. Pelanggan yang memiliki visibilitas itu dapat merespons sebelum pengguna mereka merasakan konsekuensi pemadaman.

Janji observabilitas mirip dengan Smokey Bear: mendeteksi keberadaan asap sebelum terjadi kebakaran. Jika dilakukan dengan tepat, observabilitas memungkinkan Anda memadamkan kebakaran padang rumput sebelum menjadi kobaran besar yang menghancurkan Palisades di California. Smokey adalah sistem peringatan dini yang dapat mendeteksi jejak asap kecil terlepas dari asalnya: masalah AWS, masalah Oracle, masalah GCP, masalah Microsoft Azure, atau sesuatu yang tidak beres dalam infrastruktur Anda.

AI Memperluas Sistem Keamanan

Tidak ada operator manusia yang dapat mengawasi sistem infrastruktur saat ini. Satu‑satunya cara untuk memantau sistem secara skala besar, dengan mengonsumsi petabyte data log dan triliunan metrik per hari, adalah dengan menggunakan AI.

Misalnya, Anda ingin melacak kinerja baca/tulis pada sebuah disk atau input/output atau kelebihan buffer paket dalam lingkungan jaringan Anda. Anda dapat menggunakan ambang batas dinamis untuk mendefinisikan apa yang dianggap normal, atau cara deterministik untuk melihat data deret waktu selama minggu, bulan, tahun terakhir, atau rentang waktu apa pun yang Anda inginkan, dan menetapkan ambang batas kinerja normal. Setelah Anda memiliki analisis statistik ini, Anda dapat menetapkan level dua deviasi standar dari rata‑rata, sehingga ketika sesuatu terjadi di luar rentang tersebut, Anda menerima peringatan bahwa kinerja mungkin tidak normal.

Namun, sistem yang sangat kompleks dapat menerima ribuan peringatan per hari. Dasbor mulai berkedip, dan orang‑orang mulai dipanggil. Menyaring semua peringatan tersebut bukanlah penggunaan waktu manusia yang efektif. Bahkan, Vectra memperkirakan bahwa organisasi menerima rata‑rata 2,992 peringatan keamanan per hari, 63 % di antaranya tidak ditangani.

Alat AI dapat mengurangi ribuan peringatan per hari itu menjadi hanya beberapa lusin. Saya ingat satu kasus di mana satu masalah pada satu NIC di satu mesin menyebabkan 2.000 peringatan turunannya. Berkat AI, klien dapat melakukan korelasi peringatan dan mencapai analisis akar penyebab yang jauh lebih cepat, yang pada akhirnya menyimpulkan bahwa satu masalah pada saat itu menyebabkan seluruh dasbor perusahaan menjadi merah.

AI Membuat IT Menjadi Menarik Kembali

Saya mengambil cuti setelah Cisco mengakuisisi Splunk pada tahun 2023. Selama dua tahun berikutnya, saya menyaksikan teman-teman dan mantan kolega saya mendirikan perusahaan untuk menggunakan AI dengan cara yang tidak mungkin dilakukan lima tahun yang lalu. (Ingatlah bahwa jika ChatGPT adalah seorang anak manusia, ia akan berusia tiga tahun).

Tim IT membutuhkan bantuan untuk mendeteksi asap sebelum alarm berbunyi, bukan lebih banyak dasbor untuk dipandangi. Mereka. Dalam hal ini, masalahnya sama dengan yang dihadapi IBM, Twitter, dan bahkan Microsoft dengan Clippy.

Inilah alasan mengapa saya memutuskan untuk kembali terjun. Teknologi akhirnya mencapai titik di mana kami dapat menepati janji awal observabilitas dan IT otonom.