Belajar Kotlin - Operational Readiness & Runbooks

#Pendahuluan

Aplikasi yang berjalan di laptop berbeda dari aplikasi yang dioperasikan di production. Episode 19 membahas operational readiness: runbook untuk operasi harian, monitoring dan logging, containerization dan CI/CD, serta release management dengan rollback yang aman.

Kesiapan operasional bukan topik yang menyenangkan seperti fitur baru, tetapi di sinilah keandalan ditentukan. Error handling yang baik, observability yang lengkap, dan deployment yang bisa di-rollback adalah pembeda antara aplikasi yang dipercaya dan yang selalu "sedang diperbaiki".

Setelah episode ini, kalian akan membawa aplikasi Kotlin ke production dengan rencana yang jelas.

#Runbook untuk Operasi Aplikasi Kotlin

#Apa itu Runbook

Runbook adalah dokumen langkah-demi-langkah untuk menangani situasi operasional: bagaimana memulai ulang layanan, membaca log, mengambil heap dump, atau mengembalikan versi. Runbook yang baik mengurangi kepanikan saat insiden dan membuat pengetahuan tidak hanya di kepala satu orang.

Sebuah runbook Kotlin biasanya mencakup perintah inti:

./gradlew bootJar
docker logs --tail 200 aplikasi
curl http://localhost:8080/actuator/health

./gradlew bootJar membangun artifact, docker logs memeriksa log terbaru, dan curl memeriksa health endpoint. Perintah-perintah ini didokumentasikan di runbook sehingga siapapun bisa mengeksekusi saat dibutuhkan.

#Runbook untuk Insiden

Untuk insiden, runbook mengikuti struktur yang jelas: deteksi, diagnosis, mitigasi, dan resolusi. Menulis langkah diagnosis sebelum terjadi insiden — seperti "periksa metrik GC dengan jstat" atau "cek error rate pada dashboard" — membuat penyelesaian jauh lebih cepat saat benar-benar terjadi.

#Monitoring, Logging, dan Error Handling

#Logging Terstruktur

Logging adalah jendela aplikasi di production. Kotlin memakai SLF4J dengan implementasi seperti Logback. Log terstruktur dalam format JSON lebih mudah dicari dan di-agregasi:

Logging dengan SLF4J

import org.slf4j.LoggerFactory
 
private val log = LoggerFactory.getLogger("OrderService")
 
fun proses(id: String) {
    log.info("Memproses order id={}", id)
    try {
        simpan(id)
    } catch (e: Exception) {
        log.error("Gagal memproses order id={}", id, e)
    }
}

Pola log.info("... id={}", id) menghindari concatenation string yang boros. Selalu sertakan exception pada log error agar stack trace tersimpan. Logging yang baik adalah dasar semua diagnosis.

#Monitoring dan Alerting

Monitoring mengukur kesehatan: CPU, memori heap, GC pause, latensi, dan error rate. Health endpoint seperti Spring Actuator diekspos agar orchestration bisa menilai kesiapan:

curl -s http://localhost:8080/actuator/health

curl -s http://localhost:8080/actuator/health mengembalikan status aplikasi. Metrik dari actuator di-export ke Prometheus, dan Grafana menampilkannya dalam dashboard. Alerting dibangun di atas metrik: tidak ada alert yang berarti insiden ditemukan oleh pengguna.

#Deployment: Containerization dan CI/CD

#Container dengan Docker

Mengemas aplikasi Kotlin dalam container membuat deployment konsisten di semua environment. Dockerfile memakai image JRE ringan dan memisahkan layer dependency:

FROM eclipse-temurin:21-jre-alpine
WORKDIR /app
COPY build/libs/aplikasi.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-XX:MaxRAMPercentage=75.0", "-jar", "app.jar"]

-XX:MaxRAMPercentage=75.0 membiarkan JVM menyesuaikan heap dengan batas memori container — pola penting agar JVM tidak memakai memori melebihi limit. Image dibangun dan dijalankan dengan perintah Docker standar.

#Pipeline CI/CD

CI/CD otomatis mem-build, menguji, dan men-deploy. Alur khas: push ke main memicu build dan test, lalu image Docker dikirim ke registry, dan deployment dijalankan:

jobs:
  deploy:
    steps:
      - run: ./gradlew bootJar
      - run: docker build -t app:$GITHUB_SHA .
      - run: docker push registry.example/app:$GITHUB_SHA

Blok YAML di atas membangun, menandai, dan mengirim image dengan SHA commit sebagai tag. Tag berbasis SHA membuat setiap deployment bisa diidentifikasi dan di-rollback ke versi tertentu.

#Release Management dan Rollback

#Release yang Dapat Diputar Balik

Deployment yang aman selalu punya jalan keluar. Praktik yang membuat rollback cepat:

• Tag image dengan SHA commit dan versi semantik.
• Pertahankan beberapa versi image terakhir di registry.
• Gunakan deployment strategy seperti rolling update atau blue-green.
• Simpan runbook rollback yang sudah diuji.

#Menjalankan Rollback

Rollback adalah deployment ulang ke versi sebelumnya, bukan proses yang menakutkan jika sudah diotomatiskan:

kubectl set image deployment/aplikasi app=registry.example/app:1.2.1

Perintah kubectl set image memutar image kembali ke versi 1.2.1. Karena image berbasis immutable tag dan health check aktif, deployment service akan menunggu aplikasi sehat sebelum menyelesaikan rollback.

#Penutup

Episode 19 menyiapkan aplikasi Kotlin untuk production: runbook untuk operasi dan insiden, logging terstruktur dan monitoring, containerization dengan Docker dan pipeline CI/CD, serta release management dengan rollback yang cepat dan aman.

Inti yang harus dibawa pulang:

• Runbook mengubah pengetahuan operasional menjadi langkah terdokumentasi.
• Log terstruktur dengan SLF4J dan health endpoint adalah dasar observability.
• Container dengan -XX:MaxRAMPercentage menyesuaikan JVM ke limit memori.
• Pipeline CI/CD membangun, menandai, dan men-deploy image berbasis SHA.
• Tag immutable dan beberapa versi image memungkinkan rollback cepat.
• Rollback adalah deployment ulang yang sehat, bukan prosedur menakutkan.

Di episode 20 selanjutnya kita akan membahas real-world use cases dan patterns — contoh aplikasi Android, backend service, dan library multiplatform, arsitektur clean, hexagonal, dan reactive, alur data dan state management, serta pola scalability dan maintainability untuk kode yang bertahan lama.