Belajar Site Reliability Engineer - Toil Reduction & Automation

#Pendahuluan

Ada satu musuh yang jarang dibicarakan tapi diam-diam menghancurkan tim operasi: toil. Ia bukan kesalahan, bukan insiden, dan bukan pekerjaan yang menantang — ia adalah pekerjaan manual yang berulang, tanpa nilai jangka panjang, yang perlahan menguras energi dan semangat tim. Restart service yang crash dengan alasan sama setiap malam, patch manual ke seratus server, laporan yang diketik ulang dari dashboard — semua ini toil.

Di episode 2 kita menyebut aturan 50%: maksimal setengah waktu SRE boleh untuk toil. Episode ini menjadikan aturan itu praktik: cara mengenali toil, mengukur berapa banyak yang kita miliki, dan menguranginya lewat otomasi yang bertahap dan terarah. Kita akhiri dengan praktik mengotomasi satu task operasional yang nyata.

#Apa Itu Toil (dan Apa Bukan)

Definisi kerja toil dari Google: pekerjaan yang manual, berulang, tanpa nilai otomatis, dan bukan menantang secara intelektual. Empat ciri yang sering tumpang tindih dengan pekerjaan "penting" — karena itu harus diuji dengan jujur:

Contoh perbandingan: mengembalikan kredensial yang hilang untuk pengguna baru adalah toil (berulang, manual, tidak menambah nilai). Menulis ulang pipeline CI untuk mengatasi bottleneck bukan toil — ia engineering, meski terasa berat.

#Cara Mengukur Toil

Toil sulit dirasakan tapi mudah diukur jika dicatat. Praktik yang sederhana namun kuat:

1. Track task per minggu — setiap SRE mencatat waktu yang habis untuk pekerjaan manual berulang (bisa lewat ticket atau jujur mencatat di spreadsheet).
2. Hitung persentase terhadap total waktu; target di bawah 50%.
3. Buat "toil register" — daftar task toil dengan frekuensi dan waktu per kejadian, diurutkan dari yang paling menyakitkan.

Task                         Frekuensi    Waktu   Skor  Rencana
restart payment-worker       3x/minggu    10 mnt  30    otomasi healthcheck + auto-restart
ganti sertifikat staging     1x/bulan     30 mnt  30    otomasi cert-manager
rekon data malam (manual)    1x/hari      45 mnt  45    perbaiki pipeline kode

Skor frekuensi × waktu memberi peringkat objektif: kerjakan yang paling besar dampaknya dulu.

#Strategi Otomasi: Dari Kecil ke Sistemik

#Level 1: Bot untuk Task Berulang

Mulai dari toil yang paling jelas: task manual dengan prosedur tetap. Ubah prosedur menjadi script, lalu jalan otomatis (cron, sistemd timer, atau workflow). Contoh paling klasik: log rotation dan pembersihan artifact lama.

#!/usr/bin/env bash
# hapus artifact build yang lebih tua dari 7 hari
find /var/lib/artifacts -type f -mtime +7 -delete
# kirim ringkasan ke channel otomasi
echo "artifacts dibersihkan: $(date)" >> /var/log/cleanup.log

Pasang dengan cron harian dan — penting — pantau hasilnya, karena otomasi yang gagal diam-diam adalah toil baru.

#Level 2: Self-Service untuk Developer

Banyak toil tim operasi sebenarnya berasal dari developer yang tidak punya jalan lain: "tolong buatkan environment staging", "minta akses ke dashboard". Jawaban yang sehat bukan melarang, melainkan memberi jalan yang lebih mudah: internal developer platform dengan templat environment, akses via approval otomatis, atau golden path deployment.

#!/usr/bin/env bash
# pratinjau environment dari branch
set -euo pipefail
BRANCH="${1:?nama branch wajib ada}"
 
# jalankan templat deployment untuk branch ini
kubectl create namespace "preview-$BRANCH"
kubectl apply -f "manifests/preview-$BRANCH.yaml"
 
echo "Preview siap: https://$BRANCH.preview.internal"

#Level 3: Otomasi Siklus Penuh

Pada level ini, perbaikan berulang diubah menjadi pencegahan sistemik: alert yang memicu runbook otomatis, keputusan yang diubah menjadi konfigurasi, dan proses manual digantikan pipeline. Contoh: alih-alih menunggu insiden "disk penuh" lalu membersihkan manual, otomasi membersihkan otomatis sebelum ambang tercapai — dan alert hanya berbunyi jika otomasi gagal.

#Pelajaran dari ITIL: Disiplin, Bukan Birokrasi

ITIL (IT Infrastructure Library) sering dianggap birokratis, tetapi prinsip-prinsipnya justru sejalan dengan pengurangan toil jika diterapkan ringan:

• Change management — perubahan yang direncanakan, direview, dan di-rollback-able mengurangi insiden yang disebabkan oleh keputusan asal-asalan.
• Incident vs Problem management — incident adalah memadamkan api; problem management adalah mencari penyebab yang sama di balik banyak incident. Ini identik dengan semangat blameless postmortem.
• Service catalog — daftar layanan yang jelas memudahkan developer self-service, mengurangi pertanyaan manual ke tim operasi.

Kuncinya: ambil disiplinnya, buang paperwork-nya. Setiap proses ITIL di tim SRE harus lulus uji yang sama seperti toil: apakah proses ini menambah nilai atau hanya birokrasi?

#Praktik: Otomasi Task Operasional

Pilih satu task toil dari register kalian, lalu jalankan siklus:

1. Dokumentasikan prosedur manual saat ini (runbook singkat).
2. Buat script yang meniru prosedur itu, dengan error handling dan log.
3. Uji dengan menjalankan script saat prosedur manual masih aktif — bandingkan hasilnya.
4. Pasang penjadwalan (cron/sistemd) dan alert jika script gagal.
5. Ukur ulang skor toil register setelah 2 minggu.

Contoh cepat yang bisa kalian tiru sekarang — auto-restart worker yang crash:

Auto-restart + notifikasi di Kubernetes

apiVersion: batch/v1
kind: CronJob
metadata:
  name: health-restart
spec:
  schedule: "*/5 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: check
              image: curlimages/curl:8.13.0
              command:
                - /bin/sh
                - -c
                - |
                  code=$(curl -s -o /dev/null -w "%{http_code}" \
                    http://payment-worker.internal/health)
                  if [ "$code" != "200" ]; then
                    curl -s -X POST http://k8s-api/... # restart pod
                    curl -s -H 'Content-Type: application/json' \
                      -d '{"text":"worker di-restart (health gagal)"}' \
                      https://discord.com/api/webhooks/...
                  fi
          restartPolicy: OnFailure

#Penutup

Pada episode 9 ini, kalian telah belajar menyerang musuh yang paling senyap di tim operasi.

Inti yang harus dibawa pulang:

• Toil = manual, berulang, otomatisable, tanpa nilai jangka panjang — ukur dan daftarkan.
• Target: toil ≤ 50% waktu; sisa untuk engineering.
• Otomasi berjenjang: bot task → self-service → pencegahan sistemik.
• Ambil disiplin ITIL (change/incident/problem management), buang birokrasinya.
• Otomasi yang menghabiskan lebih dari yang dihemat adalah toil terselubung.

Di episode 10 selanjutnya, kita akan mempraktikkan semua prinsip reliability pada platform paling umum di dunia modern: Kubernetes — resource requests/limits, HPA, PodDisruptionBudget, dan multi-AZ untuk meng-hardening reliability cluster. Sampai jumpa di episode 10!