Satuan 4 / 11

Pemantauan Kapasitas dan Kinerja: Membaca Metrik dan Perencanaan untuk Masa Depan

Keuntungan:

  • Kemampuan untuk menafsirkan metrik dengan benar dengan dukungan kecerdasan buatan menggunakan persentil (p95/p99) dan garis dasar, bukan rata-rata
  • Kemampuan untuk memisahkan musiman dari tren dan menghasilkan proyeksi kapasitas sebagai kisaran optimis-pesimis, bukan angka tunggal
  • Memahami bahwa keputusan investasi sumber daya dan ambang batas alarm bersifat manusiawi, serta waktu tunggu sumber daya dan konteks bisnis.

Pemantauan Kapasitas dan Kinerja: Membaca Metrik dengan AI dan Merencanakan Masa Depan

Anda tidak dapat melihat kesehatan suatu sistem dengan mata kepala sendiri; Anda memahaminya melalui metrik. Metrik adalah nilai numerik yang bergantung pada waktu dari karakteristik sistem yang dapat diukur: penggunaan CPU, penggunaan memori, ruang kosong disk, latensi jaringan, permintaan per detik. Pemantauan kinerja terus mengumpulkan metrik ini dan menjawab pertanyaan "apakah sistem sekarang baik-baik saja?" Perencanaan kapasitas berjalan satu langkah lebih jauh: Perencanaan kapasitas menjawab pertanyaan "pada tingkat ini, kapan saya akan menjadi tidak mencukupi, kapan saya harus membeli sumber daya baru?" Di sini, AI adalah asisten yang sangat terampil dalam menafsirkan tumpukan metrik, menandai anomali, membaca tren, dan menghasilkan proyeksi masa depan. Namun ada satu hal yang perlu diperhatikan: AI mengekstrak pola dari data historis; Andalah yang membuat keputusan investasi sumber daya, penskalaan, dan ambang batas peringatan dengan konteks.

Pada unit ini konsep pemantauan seperti baseline (garis perilaku normal), anomali (penyimpangan dari normal), persentil (persentil); Interpretasi metrik dengan AI; tren dan perkiraan pertumbuhan; dan Anda akan belajar mengatur ambang alarm yang benar.

Kebohongan rata-rata: mengapa persentil?

Kesalahan paling umum dalam pelacakan adalah mengukur segala sesuatu dengan rata-rata. Katakanlah waktu respons Anda rata-rata 200 mdtk. Kedengarannya bagus. Namun 5% pengguna mungkin menunggu 8 detik; Rata-rata menyembunyikan ini. Itu sebabnya para profesional menggunakan persentil: p95 = "95% permintaan berada di bawah jangka waktu ini." Jika waktu respons p95 adalah 8 detik, satu dari dua puluh pengguna mengalami pengalaman buruk — rata-rata tidak pernah menunjukkan hal tersebut. Saat memberikan metrik pada AI, jelaskan statistik mana yang Anda inginkan: "interpretasikan p50, p95, dan p99 kepada saya, bukan rata-rata." Kebiasaan yang satu ini mengungkap masalah yang terpendam.

Tip: Lihat persentil untuk setiap metrik yang berkaitan dengan pengalaman pengguna (waktu respons, latensi); p95/p99 alih-alih rata-rata membawa Anda ke kelompok minoritas yang benar-benar menderita. Dalam metrik sumber daya (CPU, memori), lihat nilai puncak dan nilai berkelanjutan.

Tidak ada anomali tanpa garis dasar

Sebelum Anda dapat mengetahui apakah suatu metrik “tidak normal”, Anda perlu mengetahui “normal”. Dasarnya adalah rentang perilaku umum sistem pada hari-hari sehat: "CPU siang hari kerja layanan ini biasanya 40–60%". Tanpa garis dasar, Anda tidak dapat mengetahui apakah nilai 70% itu menakutkan atau normal. Anda dapat menetapkan garis dasar dengan memberikan riwayat data sehat kepada AI dan mengatakan "ekstraksi rentang normal dan pola harian/mingguan dari metrik ini". Kemudian Anda menafsirkan data baru berdasarkan garis dasar ini: "di manakah nilai normal ini?" Anomali adalah penyimpangan yang signifikan dan berkelanjutan dari garis dasar — ​​satu lompatan tiba-tiba sering kali menimbulkan kebisingan.

Langkah demi langkah: proyeksi kapasitas

  1. Kumpulkan sejarah yang bersih dan memadai. Sebuah tren memerlukan data setidaknya beberapa minggu, sebaiknya bulanan. Proyeksi yang dibuat dengan sedikit data hanyalah dugaan, bukan prediksi.
  2. Pisahkan musiman. Lalu lintas turun di akhir pekan, meningkat di akhir bulan, dan meledak selama kampanye. Beri tahu AI siklus ini agar tidak mengacaukan pertumbuhan dengan fluktuasi musiman.
  3. Hilangkan tren. "Berapa GB rata-rata peningkatan disk ini per minggu dalam 8 minggu terakhir?" AI menghitung tingkat pertumbuhan.
  4. Mintalah proyeksi, beri jarak. "Kalau terus begini, kapan disknya akan 90% penuh?" — tetapi mintalah kisaran optimis/pesimis, bukan satu tanggal pun. Masa depan tidak pasti; angka ganjil adalah presisi palsu.
  5. Tentukan ambang batas keputusan dengan orang-orang. Jika proyeksinya mengatakan "Ini akan selesai dalam 6 minggu", Anda mempertimbangkan waktu pengadaan (pembelian, persetujuan) dan memutuskan apakah akan mengambil tindakan hari ini.
  6. Atur alarm dengan benar. Alarm yang sangat sensitif menghasilkan kebisingan dan kelelahan alarm; terlalu longgar alarm akan melewatkan acara tersebut. Dapatkan rekomendasi ambang batas dari AI, namun tentukan ambang batas akhir dengan toleransi risiko Anda sendiri.

tiga kasus mini

Kasus 1 - Rata-rata tersembunyi, hal 99 menunjukkan. Satu tim mengira API mereka "rata-rata 180 ms, baik-baik saja". Saat saya memasukkan metrik ke AI dan meminta interpretasi persentil, ternyata p99 adalah 6.400 ms — satu dari setiap seratus permintaan lebih lambat dari 6 detik. Akar penyebabnya adalah permintaan database yang lambat. Meskipun rata-rata terlihat sehat, sebagian kecil mengalami pengalaman buruk.

Kasus 2 — Proyeksi diperingatkan 3 minggu sebelumnya. Administrator memberikan data okupansi log disk ke AI. AI menyimpulkan tren pertumbuhan mingguan sebesar ~7 GB dan memproyeksikan bahwa pada tingkat saat ini, 90% akan tercapai dalam waktu 19 hari, dengan kisaran optimis-pesimis dalam 16-23 hari. Karena pasokan disk baru memerlukan waktu 10 hari, tim segera memesan dan mencegah pemadaman listrik sebelum terjadi.

Kasus 3 — Kembali dari anomali palsu. Alarm pemantauan berbunyi setiap Minggu malam yang mengatakan CPU meningkat hingga 95%. Sebelum panik, insinyur tersebut meminta AI menaikkan garis dasar: lompatan ini adalah pekerjaan cadangan terencana yang terjadi pada waktu yang sama setiap minggu, jadi itu adalah bagian dari norma. Itu bukanlah sebuah anomali; garis dasar hilang. Ambang batas alarm telah diperbaiki untuk jangka waktu tersebut dan bangun malam yang tidak perlu telah hilang.

Empat templat yang dapat disalin

1) Interpretasi metrik (persentil):

Di bawah ini adalah metrik waktu respons [layanan] (disamarkan). Komentari saya p50, p95 dan p99, bukan rata-rata. Apa perbedaan antara p99 dan p50, masalah pengalaman pengguna apa yang ditunjukkannya? Jangan menambahkan nilai-nilai yang dibuat-buat, tafsirkan saja data yang saya berikan. Data: [metrik]

2) Pengurangan dasar:

Di bawah ini adalah data [metrik] yang sehat selama 4 minggu terakhir. Ekstrak (1) kisaran normal (2) pola harian dan mingguan (misalnya harga terendah malam hari, harga tertinggi tengah hari) dari metrik ini. Lalu saya akan memberikan satu nilai baru; mengklasifikasikannya sebagai "normal/hati-hati/abnormal" berdasarkan data dasar ini: [metrik historis]

3) Proyeksi kapasitas (dengan jangkauan):

Di bawah ini adalah data hunian [sumber daya] selama 8 minggu terakhir. (1) Hitung tingkat pertumbuhan rata-rata mingguan, (2) tunjukkan dampak musiman, (3) perkirakan waktu untuk mencapai ambang batas 90% pada tingkat saat ini, dengan rentang OPTIMIS dan PESIMISTIS. Berikan satu tanggal, berikan kisarannya, dan tuliskan asumsi Anda. Data: [deretan waktu]

4) Rekomendasi ambang batas alarm:

Dasar saya untuk [metrik] adalah [rentang]. Tujuan saya adalah meminimalkan alarm palsu tanpa melewatkan masalah sebenarnya. Beri saya rekomendasi untuk (1) peringatan dan (2) ambang batas kritis, yang membenarkan masing-masing dan menilai risiko kelelahan alarm. Saya akan menentukan ambang batas akhir.

Perintah lemah / Perintah kuat

Perintah yang lemah:

Apakah server saya lambat?

Tidak ada konteks, tidak ada metrik, dan tidak ada dasar. AI tidak mengetahui definisi "lambat" dan juga tidak memiliki nilai normal untuk membandingkannya. Jawabannya hanyalah tebakan kosong.

Perintah yang kuat:

Peran Anda: spesialis perencanaan kapasitas. Di bawah ini adalah 14 hari terakhir waktu respons p95 dan data permintaan/detik API (disamarkan). Baseline saya adalah 250-400 ms untuk p95. Beri tahu saya (1) tandai hari-hari yang melampaui garis dasar dalam 14 hari terakhir, (2) beri tahu saya apakah ada hubungan yang terlihat antara waktu respons dan beban permintaan (sebagai hipotesis), (3) prediksi kemana arah p95 dalam 30 hari jika tren ini terus berlanjut. Data: [deretan waktu]

Tipe metrik

pengukuran yang salah

pengukuran yang akurat

waktu respons

Rata-rata saja

hal50, hal95, hal99

CPU/memori

nilai sesaat

Puncak + berkelanjutan + garis dasar

pertumbuhan cakram

Okupansi hari ini

Tren + proyeksi mingguan

Anomali

pantulan tunggal

Penyimpangan terus menerus dari garis dasar

alarm

Ambang batas tunggal yang sewenang-wenang

Peringatan yang masuk akal + ambang batas kritis

Kesalahan umum

  • Mengukur segala sesuatu dengan rata-rata. Rata-rata menyembunyikan pengalaman buruk segelintir orang; Lihat persentil.
  • Mencari anomali tanpa baseline. Anda tidak dapat mengatakan bahwa suatu nilai tidak normal tanpa mengetahui apa yang normal; Anda membuat alarm palsu.
  • Salah mengira musim sebagai tren. Menganggap puncak kampanye sebagai pertumbuhan permanen dan mengambil sumber daya yang tidak perlu memerlukan biaya.
  • Mengandalkan proyeksi angka ganjil. “Tepat 19 hari” adalah ketepatan yang salah; Gunakan rentang optimis-pesimis.
  • Lupa waktu sumber. Tim yang tidak mempertimbangkan ambang batas proyeksi dan mengulur waktu bersama akan terjebak dalam interupsi.
Perhatian: Proyeksi tren AI mengasumsikan bahwa masa lalu akan terus berlanjut di masa depan. Peluncuran produk baru, migrasi pelanggan, atau perubahan arsitektur mematahkan asumsi ini. Tugas Anda adalah mengoreksi proyeksi tersebut dengan konteks Anda.

Singkatnya

Pemantauan kinerja menjawab pertanyaan "apakah sekarang sudah bagus?" dan perencanaan kapasitas menjawab pertanyaan “kapan hal tersebut tidak cukup?” AI adalah mitra yang kuat dalam menafsirkan metrik, menetapkan dasar, menandai anomali, dan memproyeksikan tren. Tapi kebohongan rata-rata — gunakan persentil; Tanpa garis dasar, tidak akan ada anomali — tetapkan garis normalnya terlebih dahulu; pisahkan musim dari tren; dan menganggap proyeksi sebagai rentang, bukan angka tunggal. Keputusan investasi sumber daya dan ambang batas peringatan bersifat manusiawi, seiring dengan waktu tunggu sumber daya dan konteks bisnis.

Tugas aplikasi

Ambil data beberapa minggu terakhir untuk sumber daya (disk, memori, waktu respons) dari sistem Anda sendiri dan tutupi area sensitif. Kurangi rentang dan pola normal dengan templat "Pengurangan garis dasar" di atas. Kemudian buat template “Proyeksi kapasitas” memprediksi kapan Anda akan mencapai suatu ambang batas, dengan rentang optimis-pesimis. Selain itu, interpretasikan metrik waktu respons Anda menggunakan templat "persentil" dan lihat apakah ada rata-rata yang disembunyikan. Tuliskan temuan Anda dan tindakan yang akan Anda ambil dalam 5 item.

daftar periksa

  • [ ] Apakah saya melihat p95/p99 dan bukan rata-rata dalam metrik waktu respons?
  • [ ] Sudahkah saya menetapkan dasar dari data yang sehat sebelum mencari anomali?
  • [ ] Sudahkah saya membedakan fluktuasi musiman dari tren permanen?
  • [ ] Apakah saya menganggap proyeksi tersebut sebagai rentang optimis-pesimis dan bukan hanya satu tanggal?
  • [ ] Sudahkah saya mengevaluasi waktu pengadaan dan ambang batas proyeksi?
  • [ ] Apakah saya menetapkan ambang alarm berdasarkan toleransi risiko saya sendiri dan bukan berdasarkan rekomendasi AI?