Automasi Tugas Berulang dengan Skrip Kecil

Hampir setiap orang yang bekerja di IT punya daftar tugas kecil yang dikerjakan berulang: restart service tertentu, cek status backup, bersihkan log lama, rename dan pindahkan file, atau menjalankan query yang sama setiap minggu. Godaan pertama biasanya "nanti saya bikinkan skrip" — tapi tidak semua tugas berulang layak diotomasi. Saya sering melihat dua kegagalan yang berlawanan: ada yang terlalu cepat menulis skrip untuk sesuatu yang cuma dikerjakan sekali dua kali, dan ada yang bertahun-tahun mengerjakan sesuatu manual padahal sudah jelas-jelas pola yang sama diulang tiap hari. Keduanya buang waktu, hanya arahnya berbeda.

Kapan sebuah tugas layak diotomasi

Ada beberapa sinyal yang menurut saya cukup andal untuk menentukan sebuah tugas manual sudah waktunya jadi skrip.

Frekuensinya tinggi dan polanya konsisten. Kalau langkah-langkahnya persis sama setiap kali dijalankan, itu kandidat kuat. Tugas yang setiap eksekusinya butuh keputusan berbeda biasanya belum cocok diotomasi penuh.
Ada risiko human error yang nyata. Tugas yang melibatkan banyak langkah manual — misalnya backup database lalu verifikasi lalu upload ke tempat lain — rawan terlewat satu langkah saat dikerjakan capek atau buru-buru. Skrip menghilangkan variasi itu.
Waktu yang dihemat lebih besar dari waktu membuat skripnya, dalam jangka wajar. Ini bukan matematika presisi, tapi sebagai ilustrasi saja: kalau sebuah tugas makan lima menit dan dikerjakan tiap hari, dalam sebulan itu sudah terasa. Kalau tugasnya butuh sepuluh menit tapi cuma terjadi setahun sekali, mungkin dokumentasi langkah manual sudah cukup.
Bisa diverifikasi otomatis. Skrip yang hasilnya bisa dicek sendiri (exit code, log, notifikasi gagal/berhasil) jauh lebih aman dipercaya dibanding skrip yang "jalan diam-diam" dan baru ketahuan gagal saat sudah terlambat.

Kapan belum sepadan diotomasi

Sebaliknya, ada situasi di mana saya sengaja menunda bikin skrip meski tugasnya berulang.

Prosesnya masih berubah-ubah. Kalau langkah kerja masih dalam tahap dicari-cari bentuknya, menulis skrip di fase ini justru bikin kita terikat pada cara lama yang belum tentu benar. Lebih baik kerjakan manual beberapa kali dulu sampai polanya stabil, baru diotomasi.
Butuh judgment manusia di tengah proses. Tugas yang melibatkan keputusan kontekstual — misalnya menentukan apakah sebuah error di log itu serius atau bisa diabaikan — sulit diotomasi penuh tanpa risiko salah tindak. Skrip di kasus ini lebih cocok sebagai alat bantu (misalnya merangkum atau memfilter), bukan pengganti keputusan.
Frekuensinya rendah dan kemungkinan besar tidak akan terulang persis sama. Skrip sekali pakai yang ditulis terburu-buru sering jadi utang teknis: tidak ada yang mendokumentasikan, dan enam bulan kemudian tidak ada yang berani menjalankannya lagi karena tidak tahu efek sampingnya.

Prinsip menulis skrip kecil yang tahan lama

Kalau sudah yakin sebuah tugas layak diotomasi, saya biasa pegang beberapa prinsip sederhana. Buat skrip sekecil mungkin dan fokus satu tanggung jawab — jangan gabungkan lima hal berbeda dalam satu file. Pastikan skrip aman dijalankan berulang kali (idempotent), misalnya cek dulu apakah sebuah proses sudah berjalan sebelum menjalankannya lagi, alih-alih asumsi selalu dari kondisi bersih. Tambahkan log secukupnya supaya saat sesuatu gagal, kita tidak perlu menebak-nebak.

#!/usr/bin/env bash
set -euo pipefail

LOG="/var/log/tugas-harian.log"
echo "[$(date)] mulai" >> "$LOG"

# contoh: bersihkan file sementara lebih dari 7 hari
find /tmp/app-cache -type f -mtime +7 -delete

echo "[$(date)] selesai" >> "$LOG"

Skrip sesederhana itu, dijadwalkan lewat cron atau scheduler serupa, sudah cukup untuk banyak kasus. Tidak perlu langsung membangun tooling rumit dengan konfigurasi YAML dan sistem plugin — itu baru dibutuhkan kalau skala dan kompleksitasnya memang sudah menuntut.

Intinya

Pertanyaan yang layak ditanyakan sebelum menulis skrip bukan "apakah tugas ini bisa diotomasi", karena hampir semua tugas manual bisa. Pertanyaan yang lebih tepat: apakah pola kerjanya sudah stabil, apakah risiko kesalahan manual cukup besar, dan apakah waktu yang dihemat sepadan dengan usaha membuat serta merawat skripnya. Kalau tiga hal itu terjawab ya, saatnya menulis skrip kecil — dan biarkan dia tetap kecil.