Ketika sistem mulai bermasalah, refleks pertama seringkali adalah: buka log.
Saya memahami itu. Log terasa konkret. Ada sesuatu di sana. Pesan kesalahan. Timestamp. Stack trace. Kode. Sesuatu yang bisa Anda telusuri.
Tetapi troubleshooting yang baik jarang dimulai dengan mencari kesalahan.
Troubleshooting yang baik dimulai dengan membuat masalah lebih kecil.
Karena di lingkungan IT dan OT yang kompleks, hampir semuanya terhubung dengan segalanya. Sebuah aplikasi berbicara dengan database. Database itu berjalan di server. Server itu terhubung ke jaringan. Jaringan itu berjalan melalui firewall, switch, VLAN, DNS, sertifikat, izin, skrip, antarmuka, pengguna, mesin, proses — dan terkadang file Excel yang tidak ada yang tahu persis mengapa ada.
Jika Anda mulai mencari tanpa arah, Anda bisa menghabiskan berjam-jam tanpa mendekati penyebabnya.
Anda membaca log. Anda melihat peringatan. Anda menemukan kesalahan lama. Anda menemukan penyimpangan yang mungkin selalu ada. Seseorang berteriak bahwa ini “pasti firewallnya.” Yang lain berkata “aplikasinya sudah berperilaku aneh kemarin.” Sementara itu tekanan meningkat, semakin banyak orang ditarik masuk, dan kabut teknis muncul.
Semua orang melihat sesuatu.
Tetapi tidak ada yang tahu persis masalah mana yang sedang diselesaikan.
Bukan: di mana kesalahannya? Tapi: di mana masalah berhenti?
Itulah mengapa saya lebih suka memulai dari tempat lain.
Apakah tidak bekerja di satu workstation, atau di semua? Apakah bekerja secara lokal tetapi tidak dari luar? Apakah gagal untuk satu pengguna, satu peran, satu mesin, satu segmen jaringan, satu titik waktu, satu jenis file, satu lini produksi, satu batch, satu panggilan API?
Apa yang bekerja sebelumnya? Apa yang telah berubah? Apa yang masih bekerja?
Pertanyaan-pertanyaan itu terdengar sederhana. Terkadang hampir terlalu sederhana. Tetapi mereka sering lebih penting dari analisis teknis pertama.
Kegagalan adalah perilaku dalam konteks
Sebuah sistem melakukan sesuatu yang tidak diharapkan. Tetapi itu tidak secara otomatis berarti sistem itu sendiri rusak.
Saya pernah berada di sebuah instalasi di mana lini produksi gagal setelah pembaruan Windows rutin. Semua orang melihat perangkat lunak PLC. Logis, karena di situlah pesan kesalahan berada. Tetapi kode PLC tidak berubah. Lingkungannya yang berubah.
Pembaruan itu telah mengganti driver yang menangani komunikasi dengan port serial. Sistem melakukan persis apa yang seharusnya dilakukan — hanya lapisan di bawahnya yang telah ditarik keluar.
Saya terus melihat pola itu.
Pesan kesalahan menunjuk ke aplikasi, tetapi penyebabnya ada di lingkungan. Kodenya tidak berubah, tetapi drivernya berubah. Atau sertifikat SSL telah kedaluwarsa sementara seluruh tim mencari di logika aplikasi. Atau data diarahkan ke gateway yang salah setelah perubahan jaringan, dan aplikasi mendapat timeout yang terlihat seperti bug.
Salah satu varian yang paling sulit: firewall dengan deep packet inspection yang diam-diam menambahkan sesuatu ke header HTTP. Aplikasi gagal, permintaan terlihat normal di log, tetapi di suatu tempat di sepanjang jalan paket sedikit berbeda dari yang diharapkan server.
Anda bisa menghabiskan berhari-hari dalam kode tanpa menemukannya, karena masalahnya bukan di kode.
Pesan kesalahan bukan penyebabnya. Itu hanya tempat di mana sistem mulai mengeluh.
Termometer tidak menyebabkan demam. Baris log tidak menyebabkan pemadaman. Alarm di HMI bukan secara otomatis masalah di mesin. Itu adalah sinyal. Dan sinyal harus dibaca dalam keseluruhan.
Cari kontrasnya
Itulah mengapa saya pertama-tama mencari kontras.
Ini bekerja. Itu tidak. Kemarin berhasil. Hari ini tidak. Mesin ini merespons secara normal. Mesin itu tidak.
Kontras itulah titik masuknya.
Dari sana Anda dapat membentuk hipotesis. Bukan sebagai tebakan liar, tetapi sebagai rute yang dapat dikerjakan. Jika masalah hanya ada di satu segmen jaringan, Anda tidak perlu menelusuri semua kode aplikasi terlebih dahulu. Jika masalah hanya terjadi dengan catatan baru, Anda melihat lebih awal pada data, validasi, atau perubahan proses. Jika masalah hanya terjadi setelah waktu tertentu, Anda melihat pada proses batch, sertifikat, tugas terjadwal, penggunaan sumber daya, atau antarmuka eksternal.
Dengan cara ini troubleshooting bukan pencarian di tumpukan jerami, tetapi penyempitan yang terkontrol.
Pengalaman juga bisa menyesatkan
Itu membutuhkan disiplin. Karena menggoda untuk langsung menyelami teknologi. Terutama jika Anda secara teknis kuat.
Anda melihat pesan kesalahan dan berpikir: di sanalah.
Anda mengenali polanya. Anda pernah melihat sesuatu seperti ini sebelumnya. Anda ingin menyelesaikannya.
Tetapi terkadang kesalahan terlihat seperti sesuatu yang Anda kenal, sementara penyebabnya ada di tempat lain. Kesalahan database yang disebabkan oleh izin. Kesalahan jaringan oleh DNS. Kesalahan aplikasi oleh sertifikat yang kedaluwarsa. Masalah kinerja oleh logging, penyimpanan, penguncian, atau proses yang berjalan sedikit berbeda dari sebelumnya.
Dalam perangkat lunak Anda melihat hal yang sama. Sebuah layanan gagal karena dependensi hilir mengembalikan format respons yang berbeda setelah pembaruan. Semua orang men-debug layanan. Tidak ada yang melihat dependensinya.
Atau API bekerja sempurna di staging tetapi rusak di produksi. Bukan karena kodenya, tetapi karena variabel lingkungan yang diset berbeda, sertifikat yang berbeda, atau kebijakan jaringan yang lebih ketat.
Sistem mengeluh di tempat yang salah.
Dan jika Anda hanya melihat di mana ia mengeluh, Anda menggali di tempat yang salah.
Di OT, perilaku terkadang lebih penting dari dokumentasi
Di lingkungan OT ini menjadi lebih tajam.
Di sana, perilaku terkadang lebih penting dari apa yang ada di atas kertas. Sebuah instalasi telah berjalan selama bertahun-tahun. Orang tahu dari pengalaman apa yang normal. Penundaan kecil bisa memiliki makna. Suara yang tidak biasa, perbedaan waktu, tindakan manual, atau bypass lama mungkin telah menjadi bagian dari sistem yang sebenarnya.
Dalam perangkat lunak Anda juga tahu itu.
Stored procedure dari 2011 yang tidak berani disentuh siapapun. Blok try-catch yang “sementara” dimasukkan dan kini telah berjalan di produksi selama tiga tahun. Layanan legacy yang seharusnya diganti, tetapi dua puluh sistem lain bergantung padanya.
Di atas kertas mungkin tidak seharusnya bekerja seperti itu.
Dalam praktiknya memang bekerja seperti itu.
Itulah mengapa selama pemadaman saya suka bertanya kepada orang-orang di lantai — baik mereka operator maupun pengembang:
Apa perilaku normal?
Bukan karena mereka selalu tahu penyebab teknisnya. Tetapi karena mereka sering lebih cepat melihat apa yang menyimpang. Mereka mengetahui ritme prosesnya. Mereka tahu apa yang berbeda kemarin. Mereka tahu solusi sementara mana yang telah digunakan selama berbulan-bulan. Mereka tahu notifikasi mana yang diabaikan karena “selalu ada.”
Informasi semacam itu jarang ada dengan rapi dalam dokumentasi. Tetapi sering kali sangat penting.
Diagnosis, bukan rapat
Troubleshooting oleh karena itu bukan hanya teknologi. Ini juga mendengarkan perilaku. Dari sistem, proses, dan orang-orang.
Pertama tentukan batasnya. Kemudian temukan perubahannya. Kemudian lacak ketergantungannya. Dan baru kemudian pergi mendalam secara terarah.
Itu juga mencegah tim saling menyalahkan secara tidak perlu.
Di lingkungan yang kompleks, semua orang dengan cepat menunjuk ke domain orang lain. Pengembangan melihat infrastruktur. Infrastruktur melihat manajemen aplikasi. Manajemen melihat keamanan. Keamanan melihat kebijakan. Operasi melihat “pembaruan baru itu.”
Tetapi diagnosis yang baik menghilangkan emosinya.
Bukan: siapa yang menyebabkan ini? Tetapi: dalam kondisi apa perilaku ini terjadi?
Itu membuatnya lebih bisnis. Lebih tenang. Dan sering kali lebih cepat juga.
Konteks membuat perbedaan
Dalam troubleshooting saya lebih mengandalkan pembatasan sistematis daripada pencarian heroik.
Bukan karena log tidak penting. Log itu penting. Pemantauan itu penting. Metrik, tangkapan paket, trace, event viewer, audit log, dan dasbor bisa sangat berharga. Tetapi hanya ketika Anda tahu apa yang dicari.
Tanpa konteks, file log terutama merupakan kumpulan kebisingan teknis.
Dengan konteks, itu menjadi bukti.
Anda tidak mulai dengan menggali. Anda mulai dengan menentukan di mana harus menggali. Dan terkadang langkah pertama terbaik bukan perintah, kueri, atau dasbor.
Tetapi beberapa pertanyaan sederhana:
Apa yang bekerja sebelumnya? Apa yang telah berubah? Di mana masalah berhenti? Apa yang masih stabil?