Operability: Agar Solusi Tidak Jadi Beban Tim Ops

10.6 Operability: Agar Solusi Tidak Jadi Beban Tim Ops

Setelah aman, solusi harus bisa dioperasikan: dipantau, dipulihkan, dan didukung.

Saya pernah melihat sebuah sistem rekomendasi yang sukses diluncurkan ke produksi. Tim bangga karena modelnya akurat, integrasinya lancar, dan security review sudah lulus. Tiga minggu kemudian, tim operasional mulai mengeluh. Setiap malam mereka mendapat laporan bahwa sistem lambat, tetapi tidak ada yang bisa memastikan apakah itu karena traffic tinggi, karena model sedang melakukan perhitungan ulang, atau karena ada error di koneksi ke CRM. Log yang tersedia hanya mencatat “error occurred” tanpa konteks. Tidak ada dashboard yang menunjukkan berapa banyak request masuk, berapa lama rata-rata respons, atau apakah data yang dikirim dari sistem lain masih segar.

Inilah yang terjadi ketika operability tidak dirancang sejak awal. Solusi bekerja secara fungsional, tetapi tidak bisa dioperasikan dengan efisien. Tim operasi harus menebak-nebak, membuka kode untuk mencari tahu apa yang terjadi, dan menghubungi pengembang di tengah malam untuk masalah yang seharusnya bisa dideteksi lebih awal.

Operability view adalah cara arsitek memastikan bahwa solusi tidak hanya berfungsi, tetapi juga bisa dijalankan, dipantau, dan dipulihkan oleh tim operasi tanpa harus melibatkan pengembang setiap kali ada masalah. Ini bukan sekadar soal menambahkan logging. Ini soal merancang bagaimana solusi akan hidup di lingkungan produksi.

Pertama, observability. Solusi harus bisa menjawab tiga pertanyaan: apa yang terjadi sekarang, apa yang pernah terjadi, dan mengapa itu terjadi. Ini membutuhkan tiga jenis data sekaligus. Logging mencatat peristiwa secara detail: siapa yang mengakses, data apa yang diproses, error apa yang muncul. Metric memberikan angka agregat: jumlah request per menit, latency rata-rata, penggunaan CPU dan memori. Tracing menghubungkan satu permintaan yang melewati beberapa sistem: dari aplikasi mobile ke API rekomendasi, ke model AI, ke database, lalu kembali. Tanpa tracing, ketika sistem lambat, Anda tidak tahu apakah kemacetan ada di model, di database, atau di jaringan.

Berikut contoh konfigurasi logging terstruktur dalam format YAML dan endpoint metrics sederhana yang bisa langsung diintegrasikan.

# config/logging.yaml
version: 1
formatters:
  json:
    format: '{"timestamp": "%(asctime)s", "level": "%(levelname)s", "service": "recommendation-engine", "message": "%(message)s"}'
handlers:
  console:
    class: logging.StreamHandler
    formatter: json
    level: INFO
  file:
    class: logging.handlers.RotatingFileHandler
    filename: /var/log/recommendation/engine.log
    formatter: json
    maxBytes: 10485760
    backupCount: 5
loggers:
  recommendation:
    handlers: [console, file]
    level: DEBUG

# metrics.py
from prometheus_client import start_http_server, Counter, Histogram
import random
import time

REQUEST_COUNT = Counter('recommendation_requests_total', 'Total requests')
REQUEST_LATENCY = Histogram('recommendation_request_duration_seconds', 'Request latency')

@REQUEST_LATENCY.time()
def process_request():
    REQUEST_COUNT.inc()
    time.sleep(random.uniform(0.1, 0.5))

if __name__ == '__main__':
    start_http_server(8000)
    while True:
        process_request()

Kedua, alert dan runbook. Tidak semua masalah perlu membangunkan tim di malam hari. Arsitek perlu menentukan ambang batas: kapan sistem dianggap sehat, kapan perlu perhatian, dan kapan darurat. Setiap alert harus disertai runbook—dokumen yang menjelaskan langkah-langkah yang harus diambil saat alert menyala. Runbook yang baik tidak hanya mengatakan “restart server”, tetapi menjelaskan cara memeriksa penyebab, langkah mitigasi sementara, dan kapan harus menghubungi pengembang. Tanpa runbook, setiap alert menjadi panik.

Ketiga, backup dan recovery. Ini adalah jaring pengaman terakhir. Arsitek harus menentukan data apa yang perlu dicadangkan, seberapa sering, dan bagaimana cara memulihkannya. Lebih penting lagi, recovery harus diuji secara berkala. Saya pernah melihat tim yang bangga dengan backup harian mereka, tetapi ketika sistem benar-benar tumbang, mereka baru tahu bahwa backup selama tiga bulan terakhir ternyata korup. Recovery yang tidak pernah diuji hanyalah ilusi keamanan.

Keempat, support model. Siapa yang akan menangani masalah ketika sistem sudah berjalan? Apakah ada tim operasi yang terlatih? Apakah mereka punya akses ke log dan dashboard? Apakah ada jam kerja support atau 24/7? Arsitek perlu merancang support model bersama tim operasi, bukan menyerahkan begitu saja setelah solusi selesai.

Operability bukanlah lapisan yang bisa ditambahkan di akhir. Jika arsitek hanya fokus pada fitur dan keamanan, solusi akan menjadi beban bagi tim operasi. Dan beban yang menumpuk akan mengurangi kepercayaan organisasi terhadap solusi itu sendiri. Setelah operability dirancang, tibalah saatnya membahas bagaimana solusi akan dikirim ke produksi: deployment.

Diagram berikut merangkum alur operability yang dirancang agar tim operasi tidak perlu menebak-nebak saat terjadi masalah.