Production Operations

Semua chapter sebelumnya menyiapkan sistem: server yang terprovision otomatis, deployment yang berulang, log yang terpusat, health check yang waspada, dan pintu yang terkunci. Chapter penutup ini membahas setengah bagian lain dari pekerjaan operasional: manusianya. Menjalankan produksi adalah disiplin harian — prosedur yang tertulis, rotasi on-call yang adil, penanganan insiden yang tenang, dan budaya belajar dari kegagalan tanpa menjatuhkan hukuman. Kita bedah empat artefaknya satu per satu: runbook, timeline insiden, laporan hasil render skrip, dan template postmortem — semuanya dibaca dan dijalankan sungguhan di sandbox dengan data insiden yang dibekukan.

Runbook: Prosedur yang Bisa Dijalankan Siapa Pun #

Runbook adalah dokumen “ketika X terjadi, lakukan Y” — prosedur operasional yang ditulis sebelum dibutuhkan, saat kepala masih dingin. Tanpanya, penanganan insiden bergantung pada satu orang yang kebetulan tahu; bersamanya, siapa pun yang memegang pager bisa menjalankan langkah pertama dengan benar. Tabel runbook perawatan di Chapter Server Maintenance adalah contoh bentuk ringkasnya; untuk insiden, formatnya lebih panjang. Bundle chapter ini membawa satu contoh utuh:

cat runbook-app-toko.txt

Output yang Dihasilkan:

RUNBOOK: api-toko tidak merespons
Kapan dipakai   : health check api-toko gagal lebih dari 5 menit
Prasyarat       : akses server 192.0.2.20, kunci SSH, halaman status
Langkah         :
  1. Konfirmasi dampak: bash cek-kesehatan.sh 192.0.2.20/healthz 3
  2. Cek service   : systemctl status api-toko
  3. Baca log      : journalctl -u api-toko -n 100
  4. Bila crash loop: systemctl restart api-toko
  5. Bila masih gagal: rollback ke rilis sebelumnya (lihat runbook deploy)
  6. Verifikasi    : ulangi langkah 1 sampai SEHAT 3 kali berturut-turut
Indikator sukses: /healthz HTTP 200 stabil selama 5 menit
Eskalasi        : langkah 5 gagal -> telepon on-call backend (daftar di halaman oncall)

Enam blok penyusunnya layak dijadikan pola untuk runbook apa pun:

1. Judul dan “Kapan dipakai”: pemicu yang terukur — “health check gagal lebih dari 5 menit”, bukan “kalau kelihatan error” — sehingga pembaca tidak menebak apakah runbook ini yang tepat.
2. Prasyarat: apa yang harus dimiliki sebelum mulai — akses server, kunci, halaman status. Menemukannya kurang di tengah insiden adalah kehilangan waktu yang paling membodohkan.
3. Langkah bernomor: urutan eksplisit, dari konfirmasi dampak sampai verifikasi pulih. Nomor membuat setiap langkah bisa dilaporkan (“saya di langkah 3”) tanpa ambigu.
4. Langkah diagnosis sebelum tindakan: langkah 1–3 membaca keadaan; barulah langkah 4–5 mengubah. Men-restart sebelum membaca log adalah cara menghapus bukti.
5. Indikator sukses: definisi “selesai” yang objektif — /healthz 200 stabil 5 menit, bukan “kayaknya udah oke”.
6. Eskalasi: kapan dan ke siapa menyerahkan — runbook yang baik tahu batasnya sendiri.

On-Call: Rotasi dan Tanggung Jawab #

On-call adalah giliran memegang pager — siapa yang akan dibangunkan alert pukul tiga pagi. Praktik sehatnya sederhana: rotasi bergantian (misalnya mingguan) antar anggota tim yang memahami sistem, dengan rekan secondary sebagai lapis kedua, dan aturan reaksi yang jelas (misalnya membalas halaman dalam 5 menit, menilai dalam 15 menit). Dua prinsip menjaga rotasi tetap manusiawi. Pertama, on-call bukan hukuman: kalau satu orang terus-menerus terjaga malam, masalahnya ada di sistem yang sering jatuh atau alert yang terlalu sensitif — keduanya adalah pekerjaan tim, bukan nasib si penjaga. Kedua, on-call berhak mengganggu: rapat esok paginya boleh dihindari, dan pekerjaan fitur boleh ditunda — penjaga pager yang setengah tidur adalah risiko baru.

Siklus Insiden: Detect sampai Postmortem #

Insiden (incident) adalah gangguan yang berdampak ke pengguna dan butuh penanganan segera. Siklusnya punya lima tahap dengan target durasi — angka persisnya berbeda antar organisasi, tetapi keberadaan targetnya adalah yang membedakan tim yang tenang dari yang panik:

Pembeda penting ada di antara mitigate dan resolve: mitigasi bukan perbaikan. Rollback ke rilis sebelumnya — latihan persisnya di Chapter Deployment Automation — atau mematikan feature flag yang baru menyala akan menghentikan pendarahan dalam hitungan menit, sementara akar masalahnya boleh menyusul diperbaiki dengan kepala dingin. Tim yang mencampur keduanya biasanya menghabiskan jam pertama insiden sambil menebak-nebak akar masalah, dan pengguna menunggu selama itu.

Timeline insiden merekam kenyataan siklus itu. Fixture timeline-insiden.txt mencatat insiden INS-2026-0210 — alert dari health check (Chapter Uptime dan Health Checks ), mitigasi lewat rollback, sampai pulih — dan skrip insiden-tracker.sh merendernya menjadi laporan:

cat timeline-insiden.txt
bash insiden-tracker.sh

Output yang Dihasilkan:

2026-02-10T03:12:00Z|detect|alert otomatis: api-toko TIDAK SEHAT 3x berturut-turut
2026-02-10T03:14:00Z|triage|dampak: checkout gagal untuk sebagian pengguna
2026-02-10T03:19:00Z|mitigate|rollback ke releases/1 lewat pipeline deploy
2026-02-10T03:26:00Z|resolve|/healthz HTTP 200 stabil 5 menit
== Laporan Insiden INS-2026-0210 ==
detect   -> triage  :   2 menit  (dampak: checkout gagal untuk sebagian pengguna)
triage   -> mitigate:   5 menit  (rollback ke releases/1 lewat pipeline deploy)
mitigate -> resolve :   7 menit  (/healthz HTTP 200 stabil 5 menit)
Total dampak (detect -> resolve): 14 menit

Bedah skrip render-nya:

1. while IFS='|' read -r waktu fase pesan; do ... done < timeline-insiden.txt: membaca fixture baris demi baris dengan pemisah | — tiga variabel otomatis terisi, termasuk pesan yang menampung sisa baris.
2. date -d "$waktu" +%s: mengubah timestamp ISO 8601 (dengan akhiran Z untuk UTC) menjadi detik epoch — bentuk yang bisa dikurangkan.
3. menit=$(( (epok - epok_sebelumnya) / 60 )): aritmetika selisih antar fase; epok_sebelumnya dan fase_sebelumnya dibawa antar iterasi.
4. Baris resolve: mengunci total dampak — selisih dari detect pertama sampai resolve. Laporan tercetak: triage 2 menit, mitigasi 5 menit, pulih 7 menit, total 14 menit — semuanya di bawah target tabel di atas.

Postmortem Tanpa Menyalahkan #

Postmortem ditulis setelah debu reda, dan isinya adalah kejujuran tanpa ancaman. Prinsip blameless sering disalahpahami sebagai membiarkan kesalahan — padahal sebaliknya: penyalahan mengajari orang menyembunyikan informasi, dan informasi yang disembunyikan hari ini menjadi insiden yang lebih besar besok. Akar masalah hampir selalu sistemik: perubahan berbahaya lolos review, deployment dipublikasikan tanpa canary, alert yang seharusnya menyala tiga jam lebih awal. Formatnya mengikuti template di bundle:

cat postmortem-template.txt

Output yang Dihasilkan:

# Postmortem: INS-2026-0210 — checkout api-toko gagal selama 14 menit

## Ringkasan
Satu-dua kalimat: apa yang terjadi, kapan, berapa lama, siapa yang terdampak.

## Dampak
Metrik, bukan kesan: jumlah request gagal, persentase pengguna terdampak,
nilai transaksi yang hilang.

## Timeline
Daftar peristiwa dengan waktu (UTC) — ambil dari berkas timeline insiden.

## Akar Masalah
Rantai sebabnya, bukan satu orang: apa yang membuat perubahan berbahaya
bisa masuk, mengapa tidak tertahan di review, mengapa monitoring terlambat.

## Yang Berjalan Baik
Hal yang bekerja sesuai desain — catat agar tidak dibongkar tanpa sengaja.

## Yang Berjalan Buruk
Keterlambatan deteksi, jalur eskalasi yang macet, informasi yang tercecer.

## Aksi Tindak Lanjut
- [ ] Aksi konkret, pemilik, tenggat — ditinjau dalam rapat mingguan

Dua bagian di dalamnya yang paling sering dipendekkan justru yang paling penting:

1. Akar Masalah: tulis rantai sebabnya sampai ke sistem, bukan berhenti di “human error”. “Developer salah deploy” bukan akar; “pipeline memungkinkan deploy melewati staging tanpa peringatan” adalah akar — dan yang kedua bisa diperbaiki.
2. Yang Berjalan Baik: hal yang bekerja sesuai desain — alert yang cepat, runbook yang diikuti, rollback yang mulus — dicatat agar tidak dibongkar tanpa sengaja oleh perbaikan yang terburu-buru. Aksi tindak lanjut punya pemilik dan tenggat; postmortem tanpa aksi hanyalah sastra.

Komunikasi Status dan Manajemen Perubahan #

Selama insiden, diam adalah keputusan terburuk. Halaman status (status page) yang mengumumkan “sedang ganggu, update berikutnya 30 menit lagi” memangkas banjiri pertanyaan dan menyelamatkan kepercayaan — pengguna bisa menerima gangguan, yang sulit diterima adalah ketidaktahuan. Jadwal update yang diumumkan dan ditepati lebih penting daripada berita bagus. Sementara itu, manajemen perubahan menjawab pertanyaan yang lebih tua dari cloud: boleh deploy Jumat sore? Kebijakan freeze — tidak ada perubahan non-darurat menjelang akhir pekan, menjelang hari besar, saat libur panjang — bukan pesimisme, melainkan pengakuan bahwa perubahan adalah sumber insiden nomor satu dan on-call berhak atas akhir pekan yang sunyi. Perubahan yang lolos adalah yang kecil, mundur cepat (Chapter Deployment Automation menyediakannya), dan tercatat.

Dari terminal pertama di Chapter Pengenalan Terminal sampai di sini, perjalanan Course Linux menuntaskan satu lingkaran penuh: dari perintah-perintah kecil untuk melihat dunia, sampai sistem — dan budaya — yang menjaga aplikasi tetap hidup di produksi. Keterampilan ini mengeras lewat pemakaian, dan tempat terbaik memakainya adalah proyek: mulai dari membangun server web, mengotomatiskan pemeliharaan, sampai meng-hardening server sendiri di section Proyek — sampai jumpa di sana.

Referensi lanjut: halaman manual date untuk format timestamp ISO 8601 yang dipakai timeline insiden.

#!/usr/bin/env bash
# insiden-tracker.sh — render laporan insiden dari berkas timeline.
# Format baris: <waktu-iso>|<fase>|<pesan>

echo "== Laporan Insiden INS-2026-0210 =="
epok_pertama=""
epok_sebelumnya=""
fase_sebelumnya=""
total=""
while IFS='|' read -r waktu fase pesan; do
    epok=$(date -d "$waktu" +%s)
    if [ -n "$epok_sebelumnya" ]; then
        menit=$(( (epok - epok_sebelumnya) / 60 ))
        printf '%-8s -> %-8s: %3d menit  (%s)\n' "$fase_sebelumnya" "$fase" "$menit" "$pesan"
    fi
    if [ -z "$epok_pertama" ]; then
        epok_pertama=$epok
    fi
    epok_sebelumnya=$epok
    fase_sebelumnya=$fase
    if [ "$fase" = "resolve" ]; then
        total=$(( (epok - epok_pertama) / 60 ))
    fi
done < timeline-insiden.txt
echo "Total dampak (detect -> resolve): ${total} menit"