Apa itu Mean Time to Innocence?
Mean Time to Innocence (MTTI) adalah rata-rata waktu yang dibutuhkan sejak sebuah masalah sistem terdeteksi hingga tim tertentu bisa membuktikan bahwa mereka atau bagian dari sistem mereka bukan penyebab masalah tersebut. Ada metrik terkait yang disebut Mean Time to Blame (MTTB), yaitu rata-rata waktu yang dibutuhkan untuk menemukan penyebab utama masalah tersebut, alias siapa atau apa yang harus disalahkan atas sebuah gangguan atau turunnya performa aplikasi secara tiba-tiba.
Mean Time to Innocence bukan metrik yang berlaku di seluruh organisasi, melainkan spesifik untuk tim atau bagian tertentu dari stack teknologi. Misalnya, admin server pasti ingin MTTI sekecil mungkin supaya mereka bisa cepat membuktikan bahwa server bukan penyebab utama sistem klien mengalami perlambatan besar.
Apa itu Mean Time to Identify?
Singkatan MTTI biasanya merujuk pada Mean Time to Identify, yaitu rata-rata waktu yang dibutuhkan organisasi untuk mengidentifikasi akar penyebab gangguan. Metrik ini tidak terbatas pada satu tim saja karena fokusnya adalah pada insiden itu sendiri, bukan tanggung jawab individu atau tim tertentu. MTTI ini juga membantu memastikan bahwa yang menjadi prioritas adalah memperbaiki masalah, bukan mencari kambing hitam.
MTTI biasanya berpasangan dengan metrik lain yang disebut Mean Time to Resolve (MTTR), yaitu rata-rata waktu yang dibutuhkan sejak insiden terdeteksi hingga layanan kembali normal. Dalam arsitektur modern, ada kemungkinan MTTR lebih pendek daripada Mean Time to Identify. Misalnya, cukup dengan me-restart satu microservice atau menghapus instance yang bermasalah dari load balancer produksi sudah bisa memulihkan layanan tanpa harus tahu pasti apa penyebab penurunan performanya.
Bagaimana menghindari budaya saling menyalahkan?
Di dunia IT, istilah Mean Time to Innocence sering digunakan, bahkan terkadang sebagai candaan. Tapi kalau terus dipakai dalam konteks serius, bisa jadi ini pertanda buruk dalam budaya kerja tim IT.
MTTI dan MTTB berfokus pada menyalahkan atau menghindari tanggung jawab, bukannya mencari cara memulihkan layanan, mencegah kejadian serupa, dan meminimalkan dampak bagi pengguna. Kadang, budaya ini datang dari atas—misalnya, manajemen yang lebih sibuk mencari siapa yang salah daripada memperbaiki masalah. Kadang juga, datang dari bawah—misalnya, tim yang lebih peduli membela diri daripada mencari penyebab utama gangguan.
Tim yang lebih sibuk membuktikan diri tidak bersalah bisa menghambat upaya mencari akar masalah. Alih-alih memperbaiki layanan lebih cepat, mereka justru menghabiskan waktu dan sumber daya untuk menghindari kesalahan. Fenomena ini disebut juga blame shifting, yaitu melempar tanggung jawab ke tim lain.
Cara terbaik untuk menghindari budaya MTTI yang negatif adalah dengan berhenti bermain blame game. Fokuslah pada langkah-langkah berikut:
- Segera pulihkan layanan, lalu perbaiki masalah sistemik atau prosedural yang menyebabkan insiden.
- Prioritaskan dan selesaikan insiden yang berdampak pada layanan pelanggan.
- Hindari pola pikir dan ucapan yang berfokus pada menyalahkan atau mencari siapa yang “tidak bersalah.”
Gunakan pendekatan blameless retrospective seperti yang dianjurkan dalam metodologi DevOps, atau blameless post-mortem dalam praktik site reliability engineering (SRE). Dalam pendekatan ini, kesalahan tidak langsung dihukum, tetapi dicari solusinya. Tentu saja, kesalahan fatal tetap bisa berakibat buruk pada karier seseorang, tapi biasanya hanya jika ada pola kecerobohan atau ketidaktahuan yang berulang, bukan karena kesalahan sekali jalan yang langsung berujung pada pemecatan.