Fundamental Observability dan SRE - Deep Dive ke Reliabilitas Sistem Modern

#Pendahuluan

Sistem production kamu baru saja down. Revenue terus berkurang. User marah-marah. CEO kamu mulai bertanya-tanya. Dan kamu cuma bisa menatap dashboard yang tidak memberikan informasi berguna tentang apa yang sebenarnya rusak.

Skenario ini terjadi setiap hari di perusahaan-perusahaan di seluruh dunia. Perbedaan antara tim yang bisa recovery dalam hitungan menit versus jam sering kali bergantung pada satu hal: seberapa baik mereka memahami prinsip observability dan Site Reliability Engineering.

Observability bukan sekadar mengumpulkan log atau membuat dashboard. Ini adalah perubahan fundamental dalam cara kamu membangun, mengoperasikan, dan men-debug sistem terdistribusi. SRE bukan sekadar job title—ini adalah disiplin yang membawa rigor engineering ke operations, dengan praktik konkret untuk mengukur dan meningkatkan reliability.

Panduan ini akan membawa kamu deep dive ke kedua dunia tersebut. Kita akan menelusuri sejarah bagaimana kita sampai di sini, membedah tiga pilar observability, decode alphabet soup SLI, SLO, dan SLA, serta menjelaskan mengapa memahami percentile dan tipe metrik bisa membuat perbedaan antara sistem yang scale dan sistem yang collapse di bawah load.

#Sejarah Mengapa Observability dan SRE Ada

#Era Monolith

Dua puluh tahun yang lalu, sebagian besar aplikasi adalah monolith yang berjalan di physical server. Kamu punya satu aplikasi, mungkin sebuah database, dan load balancer. Monitoring sangat straightforward: cek apakah server up, pantau CPU dan memory, tail log file. Ketika ada yang rusak, kamu SSH ke box dan lihat-lihat.

Ini bekerja karena sistem cukup sederhana untuk dipahami sepenuhnya. Kamu bisa menyimpan seluruh arsitektur di kepala. Debugging berarti membaca log dan mengecek system resource.

#Revolusi Cloud dan Microservices

Lalu semuanya berubah. Cloud computing memudahkan untuk spin up ratusan server. Arsitektur microservices memecah monolith menjadi puluhan atau ratusan service independen. Container dan platform orkestrasi seperti Kubernetes menambahkan layer abstraksi lain.

Tiba-tiba, satu user request bisa menyentuh 20 service berbeda, masing-masing berjalan di container berbeda, dijadwalkan di node berbeda, di availability zone berbeda. Pendekatan monitoring lama tidak berfungsi lagi. Kamu tidak bisa SSH ke setiap container. Kamu tidak bisa tail 50 log file berbeda. Kamu bahkan tidak bisa memprediksi service mana yang akan disentuh request.

Monitoring tradisional—mengecek apakah service up, memantau CPU—tidak cukup. Kamu perlu memahami bagaimana request mengalir melalui sistem, di mana mereka menghabiskan waktu, dan mengapa mereka gagal.

#Revolusi SRE Google

Sementara industri berjuang dengan kompleksitas ini, Google menghadapinya dalam skala massive. Mereka menciptakan Site Reliability Engineering: memperlakukan operations sebagai software engineering problem.

Alih-alih memiliki tim ops terpisah yang mengelola infrastruktur secara manual, Google menciptakan tim SRE yang menulis software untuk mengotomatisasi operations. Mereka mendefinisikan metrik konkret untuk reliability, membangun tool untuk mengukurnya, dan menciptakan praktik untuk meningkatkannya secara sistematis.

Buku SRE, yang diterbitkan pada 2016, membagikan praktik-praktik ini ke dunia. Ini memperkenalkan konsep seperti error budget, SLO, dan toil reduction yang sekarang menjadi standar industri.

#Gerakan Observability

Sekitar waktu yang sama, perusahaan seperti Honeycomb dan Lightstep mempelopori observability sebagai disiplin yang berbeda. Mereka menyadari bahwa monitoring tradisional—mengumpulkan metrik yang telah ditentukan dan memeriksa threshold—tidak bisa menangani kompleksitas sistem terdistribusi modern.

Observability meminjam dari control theory: sebuah sistem observable jika kamu bisa menentukan state internalnya dari output eksternalnya. Diterapkan pada software, ini berarti mengumpulkan data terstruktur yang kaya yang memungkinkan kamu mengajukan pertanyaan arbitrary tentang apa yang terjadi, tanpa memprediksi pertanyaan tersebut sebelumnya.

Gerakan observability memberi kita distributed tracing, high-cardinality metrics, dan structured logging. Ini menggeser fokus dari "apakah sistem up?" menjadi "bisakah saya memahami apa yang dilakukan sistem?"

#Tiga Pilar Observability

Observability bertumpu pada tiga jenis data telemetry: metrics, logs, dan traces. Masing-masing melayani tujuan berbeda, dan bersama-sama mereka memberi kamu visibility lengkap ke dalam sistem.

#Metrics Pandangan Agregat

Metrics adalah pengukuran numerik dari waktu ke waktu. Mereka menjawab pertanyaan seperti "berapa banyak request per detik?" atau "berapa average response time?" Metrics diagregasi, yang membuatnya efisien untuk disimpan dan di-query.

Pikirkan metrics sebagai vital sign sistem kamu. Sama seperti dokter memeriksa heart rate dan blood pressure, kamu memeriksa request rate dan error rate. Metrics memberi tahu kamu kapan ada yang salah, tapi tidak selalu mengapa.

Contoh metric umum:

http_requests_total{method="GET", status="200"} 1547
http_requests_total{method="POST", status="500"} 23

http_request_duration_seconds{endpoint="/api/users"} 0.145

Metrics murah untuk dikumpulkan dan disimpan karena mereka diagregasi. Alih-alih menyimpan setiap request, kamu menyimpan count dan average. Ini memungkinkan kamu menyimpan metrics selama berbulan-bulan atau bertahun-tahun tanpa tenggelam dalam data.

Tradeoff-nya adalah granularity. Metrics memberi tahu kamu bahwa error rate melonjak pada jam 3 pagi, tapi tidak request spesifik mana yang gagal atau mengapa.

#Logs Event Detail

Logs adalah event diskrit dengan konteks. Ini adalah cara tradisional untuk memahami apa yang dilakukan aplikasi kamu. Setiap kali ada yang menarik terjadi, kamu menulis log line.

{
  "timestamp": "2026-03-04T10:15:30Z",
  "level": "error",
  "message": "Failed to process payment",
  "user_id": "user_12345",
  "payment_id": "pay_67890",
  "error": "Payment gateway timeout",
  "duration_ms": 5000
}

Logs memberi kamu detail yang tidak bisa diberikan metrics. Ketika kamu melihat error rate spike, kamu melihat log untuk melihat apa yang sebenarnya gagal. Logs menceritakan kisah apa yang terjadi.

Masalahnya dengan logs adalah scale. Sistem yang sibuk mungkin menghasilkan jutaan log line per menit. Menyimpan dan mencari data sebanyak itu menjadi mahal dengan cepat. Kamu harus memutuskan apa yang akan di-log, berapa lama menyimpannya, dan bagaimana mencarinya secara efisien.

Logging modern menggunakan format terstruktur seperti JSON alih-alih plain text. Ini membuat log queryable: kamu bisa mencari semua error dari user tertentu, atau semua request yang memakan waktu lebih dari 5 detik.

#Traces Perjalanan Request

Traces mengikuti satu request melalui seluruh sistem kamu. Ketika user membuat request, trace menangkap setiap service yang disentuhnya, setiap database query, setiap cache lookup, dan berapa lama setiap langkah memakan waktu.

Bayangkan user memuat halaman profil mereka. Request mengenai API gateway, yang memanggil auth service untuk memverifikasi token, lalu memanggil user service untuk mendapatkan data profil, yang query database dan memanggil image service untuk mendapatkan URL gambar profil. Trace menunjukkan seluruh perjalanan ini.

trace_id: "abc123"
spans:
  - span_id: "span1"
    name: "GET /profile"
    service: "api-gateway"
    duration_ms: 245
    parent_span_id: null
    
  - span_id: "span2"
    name: "verify_token"
    service: "auth-service"
    duration_ms: 15
    parent_span_id: "span1"
    
  - span_id: "span3"
    name: "get_user_data"
    service: "user-service"
    duration_ms: 180
    parent_span_id: "span1"
    
  - span_id: "span4"
    name: "SELECT * FROM users"
    service: "postgres"
    duration_ms: 120
    parent_span_id: "span3"
    
  - span_id: "span5"
    name: "get_profile_image"
    service: "image-service"
    duration_ms: 45
    parent_span_id: "span3"

Traces sangat powerful untuk debugging. Ketika request lambat, trace menunjukkan tepat di mana waktu dihabiskan. Ketika request gagal, trace menunjukkan service mana yang gagal dan apa yang coba dilakukannya.

Tantangan dengan traces adalah sampling. Kamu tidak bisa trace setiap request—itu akan menghasilkan terlalu banyak data. Sebaliknya, kamu sampling: trace 1% request, atau trace semua request lambat, atau trace semua error. Seninya adalah memilih strategi sampling yang tepat sehingga kamu memiliki traces ketika kamu membutuhkannya.

#Bagaimana Tiga Pilar Bekerja Bersama

Setiap pilar memiliki kekuatan dan kelemahan. Digunakan bersama, mereka memberi kamu observability lengkap.

Metrics memberi tahu kamu ada yang salah. Dashboard error rate kamu menunjukkan spike.

Logs memberi tahu kamu apa yang salah. Kamu mencari log dan melihat error "database connection timeout".

Traces memberi tahu kamu mengapa itu salah. Kamu melihat trace dan melihat bahwa database query lambat karena missing index, dan timeout setelah 5 detik.

Ini adalah workflow observability: metrics untuk deteksi, logs untuk investigasi, traces untuk root cause analysis.

#Memahami Tipe Metrik

Tidak semua metrik dibuat sama. Tipe metrik yang kamu gunakan menentukan pertanyaan apa yang bisa kamu jawab dan seberapa akurat. Ada empat tipe metrik fundamental: counter, gauge, histogram, dan summary.

#Counter Angka yang Selalu Naik

Counter adalah metrik yang hanya naik. Dimulai dari nol dan increment setiap kali sesuatu terjadi. Counter mengukur total: total request, total error, total byte dikirim.

# Total HTTP request sejak server dimulai
http_requests_total 15847
 
# Total error sejak server dimulai  
http_errors_total 234
 
# Total byte dikirim sejak server dimulai
http_bytes_sent_total 1048576000

Counter tidak pernah turun. Jika server restart, counter reset ke nol dan mulai menghitung lagi. Ini tidak masalah karena kamu biasanya peduli dengan rate of change, bukan nilai absolut.

Untuk mendapatkan informasi berguna dari counter, kamu menghitung rate: berapa banyak peningkatannya selama time window?

# Request per detik selama 5 menit terakhir
rate(http_requests_total[5m])
 
# Error per detik selama 5 menit terakhir
rate(http_errors_total[5m])

Kapan menggunakan counter: Apa pun yang terakumulasi dari waktu ke waktu. Request diproses, error ditemui, byte ditransfer, task selesai, cache hit, database query.

#Gauge Nilai Saat Ini

Gauge adalah metrik yang bisa naik atau turun. Ini mewakili nilai saat ini pada titik waktu tertentu. Gauge mengukur hal-hal seperti temperature, memory usage, queue depth, atau jumlah koneksi aktif.

# Memory usage saat ini dalam byte
memory_usage_bytes 2147483648
 
# Jumlah koneksi aktif saat ini
active_connections 42
 
# Queue depth saat ini
queue_depth 156
 
# CPU temperature saat ini
cpu_temperature_celsius 67.5

Tidak seperti counter, gauge bisa turun. Jika memory usage turun, gauge turun. Jika koneksi ditutup, gauge turun.

Kapan menggunakan gauge: Apa pun yang mewakili state saat ini. Memory usage, CPU usage, disk space, koneksi aktif, queue depth, cache size, jumlah goroutine, thread pool size.

Kesalahan umum: Menggunakan gauge untuk sesuatu yang seharusnya counter. Jika kamu menghitung event, gunakan counter. Jika kamu mengukur state saat ini, gunakan gauge.

#Histogram Distribusi Bucket

Histogram mengukur distribusi nilai. Alih-alih hanya melacak average, histogram menunjukkan bagaimana nilai didistribusikan di seluruh bucket.

Ini sangat penting untuk memahami latency. Average berbohong. Jika 99% request memakan 100ms dan 1% memakan 10 detik, average masih cukup bagus, tapi 1% user kamu mengalami pengalaman yang buruk.

# Histogram durasi request dengan bucket
http_request_duration_seconds_bucket{le="0.1"} 9500
http_request_duration_seconds_bucket{le="0.5"} 9800
http_request_duration_seconds_bucket{le="1.0"} 9950
http_request_duration_seconds_bucket{le="5.0"} 9990
http_request_duration_seconds_bucket{le="+Inf"} 10000
http_request_duration_seconds_sum 1250.5
http_request_duration_seconds_count 10000

Histogram ini memberi tahu kamu:

• 9.500 request memakan waktu kurang dari 100ms
• 9.800 request memakan waktu kurang dari 500ms
• 9.950 request memakan waktu kurang dari 1 detik
• 9.990 request memakan waktu kurang dari 5 detik
• 10 request memakan waktu lebih dari 5 detik

Dari ini, kamu bisa menghitung percentile. Percentile ke-95 (p95) ada di antara 1 dan 5 detik. Percentile ke-99 (p99) pasti lebih dari 5 detik.

Kapan menggunakan histogram: Request latency, response size, query duration, batch processing time—apa pun di mana kamu peduli dengan distribusi, bukan hanya average.

Masalah bucket: Kamu harus memilih bucket sebelumnya. Jika kamu memilih bucket 0.1s, 0.5s, 1s, 5s, tapi sebagian besar request memakan 0.05s, bucket kamu tidak cukup granular. Jika sebagian besar request memakan 10s, bucket kamu terlalu kecil. Pilih bucket berdasarkan apa yang kamu harapkan untuk diukur.

#Summary Percentile Terhitung

Summary mirip dengan histogram tapi menghitung percentile di sisi client alih-alih menggunakan bucket. Client melacak nilai dan menghitung percentile seperti p50, p95, p99 secara langsung.

http_request_duration_seconds{quantile="0.5"} 0.145
http_request_duration_seconds{quantile="0.95"} 0.892
http_request_duration_seconds{quantile="0.99"} 2.341
http_request_duration_seconds_sum 1250.5
http_request_duration_seconds_count 10000

Summary memberi kamu percentile yang tepat tanpa memilih bucket. Tradeoff-nya adalah percentile dihitung per instance. Kamu tidak bisa mengagregasi summary di beberapa server untuk mendapatkan p99 global.

Histogram vs Summary: Gunakan histogram ketika kamu perlu mengagregasi di beberapa instance (sebagian besar waktu). Gunakan summary ketika kamu membutuhkan percentile yang tepat untuk satu instance dan tidak akan mengagregasi.

#Mengapa Percentile Lebih Penting dari Average

Average berbahaya. Mereka menyembunyikan masalah. Jika kamu hanya melihat average response time, kamu akan melewatkan fakta bahwa beberapa user mengalami pengalaman yang buruk.

#Jebakan Average

Bayangkan API endpoint dengan response time ini untuk 10 request:

50ms, 52ms, 48ms, 51ms, 49ms, 50ms, 53ms, 47ms, 51ms, 5000ms

Average-nya adalah 545ms. Itu terlihat buruk. Tapi 9 dari 10 request sekitar 50ms. Hanya satu request yang lambat. Average tidak memberi tahu kamu ini.

Sekarang bayangkan response time ini:

100ms, 200ms, 300ms, 400ms, 500ms, 600ms, 700ms, 800ms, 900ms, 1000ms

Average-nya adalah 550ms. Hampir sama dengan sebelumnya. Tapi pengalamannya benar-benar berbeda. Dalam kasus pertama, sebagian besar user memiliki pengalaman cepat. Dalam kasus kedua, setiap user memiliki pengalaman biasa-biasa saja hingga buruk.

Average tidak bisa membedakan antara skenario ini. Percentile bisa.

#Memahami Percentile

Percentile memberi tahu kamu nilai di bawah mana persentase tertentu dari observasi jatuh. Percentile ke-95 (p95) berarti 95% nilai berada di bawah angka ini.

Untuk contoh pertama di atas:

• p50 (median): 50ms
• p95: 51ms
• p99: 5000ms

Untuk contoh kedua:

• p50 (median): 550ms
• p95: 950ms
• p99: 1000ms

Sekarang kamu bisa melihat perbedaannya. Contoh pertama memiliki p50 dan p95 yang bagus, tapi p99 yang buruk. Contoh kedua konsisten biasa-biasa saja.

#Percentile Mana yang Harus Dilacak

p50 (median): Pengalaman user tipikal. Setengah request lebih cepat, setengah lebih lambat. Ini lebih berguna daripada average karena tidak condong oleh outlier.

p95: Pengalaman user yang lebih lambat. Jika p95 adalah 1 detik, itu berarti 95% user mendapatkan response dalam waktu kurang dari 1 detik, tapi 5% menunggu lebih lama. Untuk situs high-traffic, 5% adalah banyak user.

p99: Pengalaman user paling lambat (tidak termasuk yang paling buruk). Ini sering kali di mana kamu menemukan masalah nyata. P99 yang buruk berarti sejumlah besar user mengalami waktu yang buruk.

p99.9: Skenario worst-case (tidak termasuk outlier ekstrem). Ini adalah apa yang dialami user paling tidak beruntung. Untuk sistem kritis, kamu peduli dengan p99.9 karena bahkan pengalaman buruk yang langka penting.

#Masalah Long Tail

Dalam sistem terdistribusi, percentile tinggi lebih penting dari yang kamu pikirkan. Ketika user request menyentuh beberapa service, service paling lambat menentukan latency keseluruhan.

Jika kamu memiliki 10 service, masing-masing dengan p99 100ms, berapa p99 untuk request yang memanggil semua 10 service?

Bukan 1000ms (10 × 100ms). Lebih buruk. Probabilitas bahwa setidaknya satu service mencapai p99-nya jauh lebih tinggi dari 1%. Faktanya, jika setiap service secara independen memiliki peluang 1% menjadi lambat, probabilitas bahwa setidaknya satu lambat adalah sekitar 10%.

Ini adalah masalah long tail. Saat kamu menambahkan lebih banyak service, p99 kamu menjadi lebih buruk. Inilah mengapa microservices bisa memiliki tail latency yang lebih buruk daripada monolith, bahkan jika setiap service secara individual cepat.

Solusinya: Optimalkan untuk percentile, bukan average. Set SLO berdasarkan percentile. Alert pada percentile. Buat keputusan arsitektur berdasarkan percentile.

#SLI, SLO, dan SLA Mengukur Reliability

Site Reliability Engineering memperkenalkan framework yang ketat untuk mengukur dan mengelola reliability. Inti dari framework ini adalah tiga konsep: SLI, SLO, dan SLA.

#SLI Service Level Indicator

SLI adalah ukuran kuantitatif dari beberapa aspek service kamu. Ini adalah metrik yang memberi tahu kamu seberapa baik service kamu berkinerja.

SLI yang baik adalah:

• Measurable: Kamu bisa menghitungnya dari data telemetry
• Meaningful: Mereka berkorelasi dengan user experience
• Actionable: Kamu bisa meningkatkannya melalui engineering work

SLI umum:

Availability: Berapa persen request yang berhasil?

# Availability = successful requests / total requests
sum(rate(http_requests_total{status!~"5.."}[5m])) 
/ 
sum(rate(http_requests_total[5m]))

Latency: Berapa persen request selesai dalam target time?

# Latency SLI: % request di bawah 500ms
histogram_quantile(0.95, http_request_duration_seconds_bucket) < 0.5

Throughput: Berapa banyak request per detik yang bisa kamu tangani?

Correctness: Berapa persen response yang benar?

Freshness: Seberapa lama data yang kamu sajikan?

Kuncinya adalah memilih SLI yang penting bagi user. User tidak peduli dengan CPU usage atau memory. Mereka peduli apakah service bekerja dan seberapa cepat.

#SLO Service Level Objective

SLO adalah target untuk SLI. Ini adalah goal yang kamu tetapkan untuk seberapa reliable service kamu seharusnya.

SLO memiliki tiga bagian:

1. SLI yang kamu ukur
2. Nilai target
3. Time window

Contoh SLO:

"99.9% request akan berhasil selama window 30 hari"
"95% request akan selesai dalam waktu kurang dari 500ms selama window 7 hari"
"99% data akan fresh dalam 5 menit selama window 24 jam"

SLO bukan aspirasional. Mereka bukan "mari coba mencapai 100% uptime." Mereka adalah target realistis berdasarkan apa yang dibutuhkan user dan apa yang bisa kamu deliver secara reliable.

Mengapa bukan 100%? Karena 100% reliability tidak mungkin dan mencoba mencapainya adalah pemborosan. Setiap nine tambahan dari reliability (99% → 99.9% → 99.99%) biayanya eksponensial lebih banyak. Pada titik tertentu, biaya melebihi manfaat.

Sebaliknya, kamu menetapkan SLO yang cukup baik untuk user dan dapat dicapai untuk tim kamu. Jika kamu mencapai SLO, kamu melakukan pekerjaan kamu. Jika kamu melewatkannya, kamu punya pekerjaan yang harus dilakukan.

#Error Budget Senjata Rahasia SRE

Error budget adalah kebalikan dari SLO kamu. Jika SLO kamu adalah 99.9% availability, error budget kamu adalah 0.1% unavailability.

Selama bulan 30 hari, 0.1% unavailability adalah sekitar 43 menit. Itu error budget kamu. Kamu bisa "menghabiskannya" untuk outage, deployment, eksperimen, atau apa pun yang mungkin menyebabkan error.

Error budget mengubah percakapan antara dev dan ops:

Tanpa error budget:

• Dev: "Kita perlu ship fitur ini sekarang"
• Ops: "Terlalu berisiko, mungkin merusak hal-hal"
• Hasil: Konflik, rilis lambat, atau sistem rusak

Dengan error budget:

• Dev: "Kita perlu ship fitur ini"
• Ops: "Kita punya 20 menit error budget tersisa bulan ini"
• Dev: "Oke, mari tunggu sampai bulan depan" atau "Mari buat lebih aman dulu"
• Hasil: Keputusan berbasis data, tanggung jawab bersama

Ketika kamu memiliki error budget tersisa, kamu bisa mengambil risiko: deploy pada Jumat, coba database baru, refactor kode kritis. Ketika kamu telah menghabiskan error budget, kamu fokus pada reliability: perbaiki bug, tingkatkan monitoring, tambahkan redundancy.

Ini menciptakan keseimbangan alami antara velocity dan reliability.

#SLA Service Level Agreement

SLA adalah kontrak dengan konsekuensi. Ini adalah janji yang kamu buat kepada customer tentang service level, dengan penalti jika kamu melanggarnya.

SLA biasanya kurang ketat dari SLO. Jika SLO internal kamu adalah 99.9%, SLA yang menghadap customer mungkin 99.5%. Ini memberi kamu buffer room.

Contoh SLA:

"Kami menjamin 99.5% uptime per bulan. Jika kami gagal memenuhi ini, 
kamu akan menerima kredit 10% untuk bulan itu. Jika uptime turun di bawah 
99%, kamu akan menerima kredit 25%."

SLA adalah komitmen legal dan finansial. SLO adalah target engineering. Kamu menetapkan SLO lebih ketat dari SLA sehingga kamu memiliki ruang untuk memperbaiki masalah sebelum memicu penalti SLA.

#Kesimpulan

Observability dan SRE bukan sekadar buzzword. Mereka adalah disiplin praktis yang membantu kamu membangun dan mengoperasikan sistem yang reliable dalam skala besar.

Tiga pilar—metrics, logs, dan traces—memberi kamu visibility ke dalam apa yang dilakukan sistem. Memahami tipe metrik membantu kamu mengukur hal yang tepat. Percentile menunjukkan pengalaman user yang sebenarnya, bukan hanya average. SLI, SLO, dan error budget memberi kamu framework untuk menyeimbangkan reliability dan velocity.

Mulai dengan dasar: instrumentasi critical path, set up dashboard untuk SLI, dan definisikan SLO untuk service paling penting. Saat kamu tumbuh, tambahkan distributed tracing, implementasikan error budget, dan bangun kultur reliability.

Tujuannya bukan perfect reliability. Ini adalah predictable, measurable reliability yang memenuhi kebutuhan user tanpa membakar tim kamu. Itulah yang diberikan observability dan SRE kepada kamu.