Wawancara Linux: Mengapa Load Average Tinggi Saat Penggunaan CPU Rendah, dan Bagaimana Cara Mendiagnosisnya?

Perintah dan Peran yang Berlaku

Sebuah server Linux dengan 16 CPU logis menjadi lambat. uptime melaporkan load average sebesar 48 / 36 / 18, sementara mpstat masih melaporkan 72% aggregate CPU idle. Tentukan apakah hal ini membuktikan kelebihan beban CPU dan jelaskan cara mengidentifikasi sumber daya yang sebenarnya sedang ditunggu oleh tugas (task).

Jawaban harus menjelaskan tugas runnable dan uninterruptible dalam penghitungan beban Linux, menginterpretasikan nilai 1, 5, dan 15 menit dengan benar, lalu menggunakan status tugas, Pressure Stall Information (PSI), dan metrik subsistem untuk membedakan kasus-kasus berikut:

• antrean eksekusi (run queue) CPU benar-benar padat;
• penyimpanan lokal, sistem berkas jaringan, driver, atau tunggu kernel lainnya menahan tugas dalam status D;
• reklamasi memori (memory reclaim) atau swapping menciptakan waktu tunggu tidak langsung;
• metrik tingkat host dan metrik tingkat kontainer atau layanan mencakup cakupan yang berbeda.

Pertanyaan ini cocok untuk wawancara SRE, DevOps, infrastruktur, sistem, dan backend. Nilai 16, 48, 36, 18, dan 72% adalah data latihan fiktif, bukan ambang batas peringatan universal. Skenario mengasumsikan metrik berasal dari host dan jendela waktu yang sama. Jika pengumpul atau cgroup yang berbeda menghasilkannya, selaraskan cakupan sebelum menginterpretasikannya.

Hal yang Diuji oleh Pewawancara

Pertama, kandidat harus mengetahui bahwa load average bukanlah utilisasi CPU. Beban global Linux adalah rata-rata peluruhan eksponensial (exponentially decaying average) dari tugas runnable ditambah tugas dalam uninterruptible sleep. Hanya kelompok pertama yang secara langsung mengekspresikan permintaan CPU; kelompok kedua dapat meningkatkan beban sementara CPU tetap menganggur (idle).

Kedua, ketiga angka tersebut memerlukan interpretasi yang tepat. Angka-angka tersebut bukanlah rata-rata aritmatika sederhana dari sampel dalam 1, 5, dan 15 menit terakhir. Angka tersebut adalah nilai peluruhan eksponensial dengan konstanta waktu tersebut. 48 > 36 > 18 mendukung kesimpulan terarah bahwa beban meningkat baru-baru ini, tetapi tidak dapat merekonstruksi panjang antrean yang tepat pada menit sebelumnya atau membuktikan akar masalah.

Ketiga, diagnosis yang kuat berpindah dari total ke komposisi dan titik tunggu (wait sites). Ini membandingkan bidang vmstat r dan b, menghitung thread di R dan D, lalu menggunakan wchan, kernel stack, PSI, dan metrik penyimpanan atau sistem berkas jaringan untuk mengidentifikasi sumber daya. Hanya mencantumkan top dan iostat tidak menjelaskan bagaimana bukti mengubah kesimpulan.

Keempat, kandidat harus menangani contoh kasus khusus (counterexamples). Alat pemantau sering melabeli D sebagai disk sleep, tetapi tunggu uninterruptible tidak terbatas pada disk lokal. NFS, sistem berkas, driver perangkat, dan beberapa tunggu sumber daya kernel juga dapat muncul. %iowait adalah penghitungan waktu CPU, sehingga iowait yang rendah tidak mengesampingkan tugas yang terblokir.

Terakhir, respons memerlukan mitigasi yang aman dan loop verifikasi. Menambahkan CPU, memulai ulang (restart), mematikan proses (kill), atau meningkatkan penyimpanan hanya sesuai untuk bukti tertentu. Setelah perbaikan, jumlah tugas R/D, PSI, latensi subsistem, dan latensi ekor bisnis (tail latency) harus pulih bersamaan. Hanya menunggu load average turun tidaklah cukup.

Pertanyaan untuk Diklarifikasi Sebelum Menjawab

• Apakah metrik mencakup cakupan yang sama? Load average umumnya berlaku untuk seluruh host, sedangkan CPU aplikasi mungkin hanya mendeskripsikan satu kontainer atau proses. Bandingkan metrik host, cgroup, dan layanan terlebih dahulu; jika tidak, "beban tinggi, CPU rendah" bisa jadi merupakan ketidakcocokan cakupan.
• Apakah CPU idle merupakan nilai agregat atau per-CPU? Satu CPU, node NUMA, atau beban kerja yang dibatasi afinitas mungkin mengantre sementara CPU lainnya menganggur. Periksa mpstat -P ALL, afinitas, dan kuota CPU cgroup.
• Permintaan mana yang melambat, dan kapan? Selaraskan gejala dengan deployment, lalu lintas, pencadangan, latensi penyimpanan, perubahan mount, dan reklamasi memori sehingga sinyal host dapat dikaitkan dengan dampak pengguna.
• Apakah tugas R atau D mendominasi? Banyak tugas R dengan CPU yang sibuk mendukung adanya perebutan (contention) CPU. Banyak tugas D dengan CPU yang menganggur mendukung adanya tunggu uninterruptible. Keduanya dapat hidup berdampingan, jadi kelompokkan berdasarkan thread dan beban kerja.
• Jalur penyimpanan apa yang terlibat? NVMe lokal, penyimpanan blok cloud, FUSE, NFS, dan database jarak jauh memerlukan bukti yang berbeda. iostat tidak dapat melihat RPC jaringan biasa, dan NFS memerlukan metrik mount dan sistem berkas jaringan.
• Apakah ada tekanan memori atau virtualisasi? Swap-in/out, direct reclaim, major fault, steal time hypervisor, dan batas cgroup mengubah urutan penyelidikan.
• Bisakah stack tugas dibaca dengan aman? /proc/12345/stack, beberapa nilai wchan, dan data I/O proses mungkin memerlukan izin tambahan. Mulailah dengan sampling ber-overhead rendah dan gunakan hanya hak akses produksi minimum yang diperlukan.

Kerangka Jawaban 30 Detik

"Load average bukanlah persentase CPU. Linux menghitung tugas runnable dan tugas dalam status uninterruptible sleep, lalu menghitung rata-rata peluruhan eksponensial dengan konstanta waktu 1, 5, dan 15 menit. Beban 48 pada 16 CPU logis menunjukkan banyak tugas aktif atau menunggu secara uninterruptible. Dengan 72% CPU idle, saya tidak dapat menyimpulkan bahwa CPU mengalami saturasi.

Pertama-tama saya akan menyelaraskan cakupan metrik dan memeriksa utilisasi per-CPU. Kemudian saya akan menggunakan vmstat untuk membandingkan tugas runnable di r dengan tugas terblokir di b, dan menghitung thread di R dan D. Banyak tugas R, PSI CPU yang tinggi, dan CPU yang sibuk mengindikasikan antrean CPU. Banyak tugas D dengan PSI I/O yang tinggi mengarahkan saya ke wchan, stack tugas, pidstat, iostat, metrik NFS, dan log kernel. Jika PSI memori, swapping, dan major fault meningkat bersamaan, saya menyelidiki tekanan memori. Setelah perbaikan, saya memverifikasi p99 bisnis, jumlah R/D, PSI, dan latensi subsistem alih-alih hanya menunggu angka beban turun."

Pembahasan Mendalam Langkah Demi Langkah

Langkah 1: Pisahkan Load Average ke dalam Dua Sumbernya

Masukan inti untuk penghitungan beban global Linux dapat diringkas sebagai:

nr_running + nr_uninterruptible

nr_running mencakup tugas yang sedang dieksekusi pada CPU dan tugas yang dapat dijalankan (runnable) tetapi sedang menunggu untuk dijadwalkan. nr_uninterruptible mewakili tugas dalam uninterruptible sleep. Tiga bidang pertama dari /proc/loadavg adalah nilai beban 1, 5, dan 15 menit untuk populasi tugas aktif ini. Bidang keempat terlihat seperti 7/1280: angka pertama adalah entitas penjadwalan yang saat ini dapat dijalankan, dan yang kedua adalah semua entitas penjadwalan yang saat ini ada. Bidang kelima adalah PID yang paling baru dibuat.

Oleh karena itu, "beban 48" tidak berarti "utilisasi CPU 300%", dan ini tidak berarti tepat 48 proses sedang mengantre pada saat ini. Ini adalah sinyal jumlah tugas yang diperhalus (smoothed). Membagi beban dengan jumlah CPU logis hanyalah petunjuk saturasi kasar untuk beban kerja yang terikat CPU (CPU-bound). Begitu tugas status D berkontribusi secara signifikan, rasio tersebut tidak lagi menggambarkan antrean CPU.

Kernel memperbarui rata-rata peluruhan eksponensial pada interval tetap. Sampel baru memiliki bobot lebih, sementara sampel yang lebih lama meluruh. Dengan demikian, 48 / 36 / 18 menunjukkan lebih banyak tugas aktif baru-baru ini daripada sebelumnya. Nilai 15 menit dapat tetap tinggi setelah penyebabnya hilang, sehingga keputusan pemulihan harus memprioritaskan status tugas saat ini, PSI, dan metrik yang dihadapi pengguna.

Langkah 2: Selaraskan Cakupan, Utilisasi Per-CPU, dan Antrean Saat Ini

Mulailah dengan observasi bertanda waktu dan ber-overhead rendah:

nproc
uptime
cat /proc/loadavg
vmstat 1 10
mpstat -P ALL 1 10

Laporan vmstat pertama umumnya merupakan rata-rata sejak boot, jadi gunakan sampel setelahnya untuk insiden saat ini. Bidang penting meliputi:

• r: tugas runnable; nilai berkelanjutan yang jauh di atas CPU yang tersedia bersama dengan CPU yang sibuk mendukung adanya antrean CPU;
• b: tugas dalam uninterruptible sleep; peningkatan yang berkelanjutan mengarahkan penyelidikan ke arah sumber daya yang ditunggu;
• us, sy, id, wa, dan st: waktu user, system, idle, I/O-wait, dan steal hypervisor;
• si dan so: aktivitas swap-in dan swap-out, untuk diinterpretasikan bersama PSI memori dan fault.

Tujuh puluh dua persen aggregate idle masih bisa menyembunyikan satu CPU yang panas. Sebuah thread serial yang disematkan (pinned) ke CPU 3 dapat menjenuhkan CPU tersebut sementara 15 CPU lainnya sebagian besar tetap menganggur. Utilisasi per-CPU, afinitas tugas, kuota CPU kontainer, dan throttling membedakan hal ini dari kebutuhan akan lebih banyak CPU di seluruh host.

Langkah 3: Hitung R dan D Berdasarkan Thread dan Temukan Titik Tunggu

Beberapa thread dalam satu proses berkontribusi pada beban, jadi gunakan tampilan tingkat thread:

ps -eLo state,pid,tid,ppid,wchan:32,comm --sort=state
ps -eLo state= | sort | uniq -c

R berarti running atau runnable. D berarti uninterruptible sleep. Sinyal biasanya tidak dapat berlaku sampai tugas meninggalkan waktu tunggu tersebut, jadi mengirimkan kill -9 berulang kali tidak akan melepaskan sumber daya kernel secara instan atau mempertahankan bukti yang berguna.

Untuk sekumpulan thread status D, kelompokkan berdasarkan perintah, proses induk, cgroup, dan wchan. wchan menunjukkan di mana sebuah thread tidur di kernel dan dapat mempersempit pencarian ke I/O blok, NFS, sistem berkas, atau jalur driver. Jika izin memungkinkan, periksa kernel stack dari tugas representatif:

cat /proc/12345/stack
cat /proc/12345/wchan

Satu nama fungsi bukanlah akar penyebab. Banyak tugas yang berkumpul di titik tunggu yang sama, yang selaras dalam waktu dengan latensi subsistem dan dampak pengguna, membentuk bukti yang lebih kuat. Status D juga tidak membuktikan bahwa suatu aplikasi secara sengaja menghasilkan I/O yang berlebihan. Perangkat yang gagal, mount jarak jauh yang tidak dapat dijangkau, atau jalur kernel yang macet dapat mengumpulkan banyak thread yang menunggu dari laju permintaan yang kecil.

Langkah 4: Gunakan PSI untuk Mengidentifikasi Sumber Daya yang Menghentikan Kemajuan

PSI mengukur waktu yang hilang karena perebutan CPU, memori, atau I/O:

for resource in cpu io memory; do
  echo "[$resource]"
  cat /proc/pressure/"$resource"
done

some adalah proporsi waktu ketika setidaknya beberapa tugas terhenti pada suatu sumber daya. full adalah proporsi ketika semua tugas non-idle terhenti secara bersamaan. full CPU tingkat sistem dipertahankan sebagai nol dan tidak boleh digunakan untuk menyimpulkan saturasi CPU. avg10, avg60, dan avg300 mendeskripsikan tren 10, 60, dan 300 detik terakhir; total adalah waktu henti kumulatif dalam mikrodetik.

PSI dan load average menjawab pertanyaan yang berbeda. Load average mendeskripsikan berapa banyak tugas yang aktif atau menunggu secara uninterruptible. PSI mendeskripsikan berapa banyak waktu beban kerja tidak dapat membuat kemajuan. Menggabungkan keduanya mencegah refleks untuk "menambah CPU karena beban tinggi." Dengan cgroup v2, baca juga cpu.pressure, io.pressure, dan memory.pressure di cgroup target untuk memisahkan tekanan layanan dari derau (noise) host.

Gunakan matriks ini untuk mengatur bukti:

Matriks ini adalah titik awal, bukan pendeteksi akar penyebab otomatis. Tekanan CPU, memori, dan I/O dapat membentuk loop umpan balik. Reklamasi memori dapat memicu pembacaan berkas, misalnya, yang kemudian dapat menempatkan thread ke dalam status D.

Langkah 5: Masuk ke Subsistem yang Relevan daripada Menyebut Setiap Tunggu sebagai "Disk Lambat"

Jika bukti mengarah ke perangkat blok, periksa throughput, latensi, antrean, dan kesalahan:

pidstat -d -p ALL 1 10
iostat -xz 1 10
dmesg -T | tail -200

pidstat membantu mengidentifikasi proses yang mengeluarkan I/O, sementara iostat melaporkan aktivitas perangkat dan partisi. Interpretasikan setiap bidang terhadap jenis perangkat dan baseline-nya. Nilai %util, misalnya, tidak memiliki satu ambang batas saturasi universal di seluruh arsitektur penyimpanan. Batas waktu habis (timeouts), reset, kesalahan sistem berkas, atau perangkat yang terlepas (detached) dalam log kernel lebih mendekati penyebab kegagalan daripada kedalaman antrean saja.

Jika wchan atau titik mount menunjukkan NFS, FUSE, atau penyimpanan jaringan, periksa status mount, nfsiostat, retransmisi klien, latensi jaringan, dan kesehatan server. Waktu tunggu RPC HTTP atau database biasa biasanya dapat diinterupsi (interruptible) dan mungkin tidak masuk ke dalam load average Linux, sehingga trace aplikasi, connection pool, dan latensi dependensi masih berada pada garis waktu yang sama.

Jika PSI memori, swapping, atau major fault meningkat, periksa event memori cgroup, working set anonim dan berkas, direct reclaim, dan perangkat swap. Penyimpanan yang lebih cepat dapat mengurangi biaya swapping tanpa memperbaiki working set yang melebihi anggaran memori.

Langkah 6: Mitigasi Berdasarkan Bukti dan Verifikasi Kausalitas

Mitigasi harus sesuai dengan sumber daya tunggu yang telah dikonfirmasi:

• Perebutan antrean CPU: pangkas admisi (shed admission), turunkan konkurensi atau prioritas batch, hapus afinitas yang salah, dan tambahkan CPU hanya berdasarkan model kapasitas yang terukur;
• Kegagalan penyimpanan atau NFS: hentikan amplifikasi I/O, beralih ke replika atau jalur mount yang sehat, dan perbaiki perangkat, jaringan, atau server;
• Tekanan memori: batasi working set dan konkurensi, hentikan beban kerja yang mengalami thrashing, dan tambahkan memori dalam batas kapasitas yang kompatibel;
• Ketidakcocokan cakupan: isolasi beban kerja yang bising atau perbaiki kuota cgroup sebelum memutuskan apakah layanan target perlu diskalakan.

Memulai ulang dapat membersihkan tugas yang menumpuk, tetapi juga dapat menghapus stack dan log yang berguna. Jika sumber daya yang mendasarinya tetap tidak tersedia, proses baru akan terblokir lagi. Sebelum bertindak, pertahankan PID representatif, status tugas, wchan, PSI, dan snapshot subsistem, serta nyatakan perkiraan perubahan metrik.

Penerimaan perbaikan harus mencakup pemulihan p95/p99 bisnis dan tingkat kesalahan, jumlah R/D kembali ke baseline, penurunan tekanan pada sumber daya PSI yang relevan, pemulihan metrik perangkat/NFS/memori/CPU, dan backlog yang terkuras dengan aman. Karena load average meluruh secara bertahap, metrik ini merupakan salah satu sinyal pemulihan dan bukan satu-satunya tolok ukur penutupan insiden.

Contoh Jawaban Berkualitas Tinggi

"Saya tidak akan menyebut ini kelebihan beban CPU hanya karena bebannya 48 pada 16 CPU. Load average Linux memperhalus hitungan tugas yang sedang berjalan atau menunggu CPU ditambah tugas dalam status uninterruptible sleep. Dengan 72% CPU idle, beban mungkin berisi banyak waktu tunggu status D, atau nilai agregat tersebut mungkin menyembunyikan masalah per-CPU, kuota, atau cakupan metrik.

48 / 36 / 18 adalah rata-rata peluruhan eksponensial. Secara terarah, mereka menunjukkan bahwa tugas aktif meningkat baru-baru ini. Mereka bukan rata-rata aritmatika pada tiga jendela independen dan tidak mengidentifikasi penyebabnya. Saya pertama-tama akan memastikan beban, CPU, dan latensi bisnis berasal dari host dan jendela waktu yang sama, lalu memeriksa mpstat -P ALL untuk CPU yang panas atau steal time.

Selanjutnya saya akan membandingkan r dan b dengan vmstat 1. Nilai r yang tinggi secara berkelanjutan, CPU yang sibuk, dan PSI CPU yang tinggi akan mengarahkan pada pemeriksaan profil CPU, afinitas, dan throttling cgroup. Nilai b yang tinggi dan banyak thread status D sementara CPU tetap menganggur akan mengarahkan saya untuk mengelompokkan thread berdasarkan perintah dan wchan, memeriksa /proc/12345/stack untuk tugas representatif, dan menyelaraskan hasilnya dengan PSI I/O.

Misalkan banyak thread menunggu di jalur yang terkait dengan NFS, PSI I/O meningkat, dan iostat perangkat blok lokal tetap normal. Saya akan menyelidiki mount, retransmisi klien, latensi jaringan, dan server NFS alih-alih meningkatkan disk cloud lokal. Mitigasinya dapat berupa penghentian batch job yang relevan, pengalihan pembacaan ke replika yang sehat, atau pengeluaran node yang terpengaruh. Mematikan proses status D berulang kali biasanya tidak akan langsung berlaku.

Setelah perbaikan, saya akan memverifikasi latensi ekor bisnis dan kesalahan, jumlah thread R/D, PSI host dan cgroup, latensi NFS, dan backlog. Nilai beban 1, 5, dan 15 menit meluruh seiring waktu, jadi nilai 15 menit yang masih tinggi seharusnya tidak memicu perubahan yang lebih berisiko ketika waktu tunggu saat ini dan hasil pengguna sudah stabil."

Kesalahan Umum

• Memperlakukan load average sebagai utilisasi CPU → load average menghitung tugas dan mencakup uninterruptible sleep → pisahkan r dari b serta R dari D sebelum mendiagnosis perebutan CPU.
• Menyatakan overload setiap kali beban melebihi jumlah CPU → aturan tersebut hanyalah petunjuk kasar untuk permintaan yang terikat CPU → gabungkan CPU sibuk, PSI CPU, dan antrean runnable.
• Memperlakukan 1, 5, dan 15 sebagai rata-rata jendela sederhana → Linux menggunakan peluruhan eksponensial dan mempertahankan sampel yang lebih lama → gunakan ketiga nilai tersebut untuk melihat arah tren dan konfirmasikan masa kini dengan metrik saat ini.
• Mengatribusikan setiap tugas D ke disk lokal → NFS, sistem berkas, driver, dan tunggu kernel lainnya dapat berupa uninterruptible → lacak wchan, stack, dan subsistem yang cocok.
• Mengesampingkan I/O karena iowait rendah → iowait adalah penghitungan waktu CPU, bukan hitungan tugas yang terblokir → periksa tugas D, PSI I/O, perangkat, dan latensi penyimpanan jarak jauh.
• Hanya melihat CPU rata-rata host → CPU yang panas, afinitas, kuota, atau cgroup lain dapat disembunyikan oleh nilai rata-rata → bandingkan metrik per-CPU, host, dan cgroup target.
• Mengirimkan kill -9 berulang kali ke tugas yang macet → sinyal menunggu operasi uninterruptible kembali dan bukti dapat hilang → pertahankan bukti dan perbaiki sumber daya yang ditunggu.
• Menyebut satu nilai wchan sebagai akar masalah → nilai tersebut hanya mengidentifikasi titik tidur kernel saat ini → perlukan pengelompokan (clustering), korelasi waktu, dan bukti subsistem.
• Menunggu load average mencapai nol sebelum menyatakan pemulihan → peluruhan memerlukan waktu dan sistem yang sehat tidak memerlukan beban nol → terima pemulihan dari hasil pengguna, tugas saat ini, PSI, dan metrik sumber daya.

Pertanyaan Lanjutan dan Tanggapan

Pertanyaan lanjutan 1: Mengapa %iowait juga bisa rendah ketika CPU idle tinggi?

%iowait adalah fraksi waktu CPU yang menganggur sementara sistem memperhitungkan I/O yang tertunda. Ini adalah penghitungan waktu CPU. Tugas dapat diblokir di NFS, driver, atau tunggu kernel uninterruptible lainnya sementara CPU menjalankan pekerjaan lain atau tetap menganggur biasa. Agregasi di banyak CPU juga dapat mengaburkan gejala lokal. Gunakan jumlah status D, PSI I/O, wchan, dan latensi subsistem; iowait yang rendah saja tidak dapat mengecualikan I/O atau tunggu kernel.

Pertanyaan lanjutan 2: Apakah load average yang diamati di dalam kontainer mewakili kontainer tersebut?

Jangan berasumsi demikian. Beban yang terlihat dan cakupan /proc bergantung pada host, namespace PID, runtime, dan implementasi pemantauan, sedangkan CPU aplikasi mungkin dicakup oleh cgroup. Baca PSI CPU, I/O, dan memori host serta target cgroup ditambah peristiwa kuota, dan atribusikan thread ke cgroup. Jika beban host tinggi tetapi target cgroup tidak memiliki tekanan, menskalakan layanan tersebut mungkin tidak membantu.

Pertanyaan lanjutan 3: Dengan beban 48 dan 72% CPU idle, apakah pasti ada banyak tugas status D?

Tidak. Metrik mungkin tidak tersinkronisasi, aggregate idle mungkin menyembunyikan CPU yang panas, tugas mungkin dibatasi oleh afinitas atau kuota cgroup, atau beban mungkin baru saja turun sementara rata-rata eksponensial masih mempertahankan nilai puncaknya. Periksa hitungan runnable saat ini di /proc/loadavg, vmstat r/b, utilisasi per-CPU, jumlah thread R/D, dan tanda waktu pengumpulan untuk menentukan komposisinya.

Pertanyaan lanjutan 4: Mengapa proses status D terkadang bertahan dari kill -9?

Uninterruptible sleep memungkinkan beberapa operasi kernel melewati fase kritis tanpa gangguan sinyal biasa. SIGKILL dapat tetap berstatus tunda (pending), tetapi tugas umumnya harus kembali dari waktu tunggu dan mencapai jalur yang dapat keluar sebelum proses menghilang. Memperbaiki tunggu pada perangkat, mount, jaringan, atau driver sering kali lebih penting daripada mengulangi pengiriman sinyal. Memulai ulang host, jika perlu, harus dievaluasi terhadap integritas data dan redundansi layanan.

Pertanyaan lanjutan 5: Bagaimana seharusnya peringatan load-average dikonfigurasi?

Jangan menyalin ambang batas tetap "beban lebih besar dari jumlah CPU". Untuk layanan yang terikat CPU, gabungkan beban, antrean runnable, PSI CPU, utilisasi, dan throttling cgroup. Untuk layanan berat I/O, gabungkan PSI I/O, status D, latensi perangkat atau penyimpanan jarak jauh, dan SLO bisnis. Tetapkan ambang batas dari baseline normal, durasi, waktu penskalaan, dan dampak pengguna, serta beri label pada setiap cakupan metrik.