19.3 Production Feedback sebagai Bahan Desain

Seorang arsitek yang saya kenal pernah mendesain sistem antrean pesan yang sangat elegan. Ia memilih message broker tertentu, menentukan skema routing yang rapi, dan memastikan semua pesan punya skema validasi yang ketat. Diagramnya indah. Tim engineering setuju bahwa desain itu bersih. Tiga minggu setelah production, sistem mulai melambat di jam sibuk. Ternyata skema validasi yang ia anggap ringan ternyata memakan waktu karena pesan yang masuk lima kali lebih besar dari perkiraan. Ia tidak pernah tahu karena tidak ada yang mengukur ukuran rata-rata pesan di production.

Situasi ini bukan karena arsiteknya ceroboh. Ia hanya terbiasa mendesain berdasarkan asumsi. Asumsi tentang volume, asumsi tentang pola traffic, asumsi tentang perilaku sistem. Padahal production selalu punya cerita yang tidak bisa diramalkan di atas kertas.

Observability adalah kemampuan untuk memahami apa yang terjadi di dalam sistem berdasarkan data yang keluar dari sistem itu sendiri. Bukan sekadar tahu bahwa server hidup atau mati. Bukan sekadar log yang menumpuk di file. Observability berarti arsitek bisa menjawab pertanyaan seperti: berapa lama rata-rata waktu respons sebuah service? endpoint mana yang paling lambat? berapa banyak data yang mengalir melalui jalur tertentu? apakah pola penggunaan sesuai dengan asumsi desain?

Misalnya, untuk mengukur latency dan ukuran respons sebuah endpoint, arsitek bisa menggunakan curl dengan opsi -w:

curl -o /dev/null -s -w "\nLatency: %{time_total}s\nSize: %{size_download} bytes\n" https://api.example.com/orders

Atau skrip bash sederhana untuk mencatat beberapa sampel:

#!/bin/bash
for i in {1..5}; do
  curl -o /dev/null -s -w "%{time_total}\t%{size_download}\n" \
    https://api.example.com/orders
done

Berikut adalah diagram yang menggambarkan siklus umpan balik dari production ke desain:

flowchart TD A[Asumsi Desain] --> B[Deployment ke Production] B --> C[Observability] C --> D[Data Production] D --> E[Latency] D --> F[Error Rate] D --> G[Data Volume] D --> H[Traffic Pattern] E --> I[Analisis & Koreksi Asumsi] F --> I G --> I H --> I I --> J[Perbaikan Desain] J --> B

Monitoring adalah langkah pertama. Arsitek perlu tahu apakah sistem berjalan atau tidak, apakah ada error, apakah resource mencukupi. Tetapi observability melangkah lebih jauh. Ia memungkinkan arsitek menjelajahi sistem tanpa harus menebak-nebak. Ketika terjadi anomali, arsitek bisa melacak penyebabnya bukan dari dugaan, tetapi dari data.

Saya melihat banyak tim yang memasang monitoring hanya untuk kepentingan operasional. Mereka pasang dashboard, atur alert, lalu puas. Padahal data dari production adalah bahan desain yang paling jujur. Ketika sebuah service terus menerus mengalami timeout, itu bukan masalah operasional semata. Itu sinyal bahwa desain perlu diubah. Mungkin pola komunikasi antar service tidak cocok dengan karakter traffic yang sebenarnya. Mungkin ukuran payload terlalu besar. Mungkin caching tidak dipasang di tempat yang tepat.

Arsitek yang baik menjadikan production feedback sebagai ritual. Ia tidak menunggu insiden untuk melihat data. Ia secara rutin memeriksa metrik, melihat tren, dan bertanya: apakah asumsi saya masih berlaku? Apakah pola penggunaan berubah? Apakah ada bagian sistem yang mulai menunjukkan tekanan?

Salah satu praktik yang mulai banyak diadopsi adalah chaos engineering. Tim sengaja memasukkan gangguan ke dalam sistem untuk melihat bagaimana sistem merespons. Tujuannya bukan untuk merusak, tetapi untuk menguji apakah desain arsitektur yang sudah dibuat benar-benar tahan terhadap kondisi nyata. Hasil chaos experiment menjadi feedback yang sangat berharga untuk perbaikan desain.

Implikasinya untuk arsitek cukup jelas. Desain arsitektur tidak selesai saat diagram disetujui. Desain baru benar-benar teruji ketika sistem berjalan di production dan arsitek mau mendengarkan apa yang dikatakan sistem itu. Setiap anomali, setiap perlambatan, setiap error adalah undangan untuk mendesain ulang bagian yang lemah.

Jika jalur pemrosesan dan mekanisme release adalah cara kita mengirim kode ke production, maka observability adalah cara kita mendengar apa yang terjadi setelah kode sampai. Keduanya harus berjalan beriringan. Tanpa feedback dari production, jalur pemrosesan hanya menjadi jalur satu arah yang tidak pernah belajar. Dengan feedback, jalur pemrosesan menjadi siklus yang terus memperbaiki dirinya sendiri.

Setelah arsitek memiliki data dari production, pertanyaan berikutnya adalah: bagaimana cara membuat jalur yang sudah teruji ini bisa dipakai oleh banyak tim tanpa harus memulai dari nol? Di sinilah platform engineering mulai berperan.