Apa itu rata-rata waktu hingga kegagalan (mean time to failure atau MTTF)?
Rata-rata waktu hingga kegagalan (MTTF) adalah waktu rata-rata sistem atau aset yang tidak dapat diperbaiki (seperti bola lampu) berjalan sebelum mengalami kegagalan yang membuatnya tidak tersedia atau berada di luar spesifikasi.
Bisnis menggunakan indikator kinerja kunci keandalan (KPI) ini untuk memperkirakan umur yang diharapkan dari komponen teknis atau mekanis.
Dalam DevOps, MTTF sering kali merupakan ukuran berapa lama layanan tetap tersedia bagi pengguna sebelum kegagalan dan waktu henti yang berdampak.
MTTF yang rendah atau menurun memperingatkan pengembang dan insinyur keandalan situs bahwa infrastruktur, kode, atau dependensi rapuh dan memerlukan peningkatan untuk meningkatkan keandalannya. MTTF yang tinggi berarti bahwa lingkungan produksi tetap stabil untuk rentang yang lebih lama antara insiden besar dan kemacetan, dan oleh karena itu, tim TI menjalankan arsitektur TI yang kuat dan memberikan aplikasi perangkat lunak dengan aman.
Metrik MTTF—bersama dengan metrik pemeliharaan lainnya, seperti rata-rata waktu antara kegagalan (MTBF)—membantu tim DevOps meningkatkan kapasitas dan perencanaan siklus hidup untuk berbagai komponen TI (termasuk node jaringan, kontainer, dan layanan terkelola), mengurangi kemungkinan pemadaman mendadak.
Metrik ini juga memungkinkan perusahaan untuk melacak keandalan peralatan di seluruh rilis, sehingga mereka dapat menentukan apakah kode, infrastruktur sebagai kode (IaC), dan perubahan konfigurasi membuat sistem lebih tangguh, tidak hanya membuatnya lebih cepat untuk dikirim.
MTTF menunjukkan waktu operasi rata-rata sampai kegagalan untuk populasi item yang identik. Dalam bentuknya yang paling sederhana, MTTF membagi total waktu operasi semua aset dengan jumlah total kegagalan aset.
Di mana “total jam operasi” adalah jumlah masa pakai setiap item sampai kegagalan (atau sampai pengamatan berhenti), dan “jumlah kegagalan” adalah jumlah item yang benar-benar gagal:
MTTF = Total jam operasi semua item/Jumlah total kegagalan
Ambil klaster kontainer, sebagai contoh.
Kontainer adalah instans sementara yang biasanya tidak diperbaiki. Ketika sebuah kontainer macet atau menjadi tidak sehat, alat orkestrasi kontainer (seperti Kubernetes) akan menghancurkan kontainer tersebut dan membuat kontainer baru.
Tim TI yang menjalankan layanan web stateless pada 50 kontainer aplikasi yang identik dapat menghitung MTTF dengan mengukur berapa lama setiap kontainer berjalan (dari pembuatan hingga kegagalan) dan membaginya dengan jumlah kontainer yang gagal. Dalam penilaian mereka, tim menemukan bahwa kelompok 50 kontainer berjalan selama total 200 jam, dengan lima kontainer gagal dalam prosesnya.
MTTF = 200 jam waktu pengoperasian/5 kegagalan = 40 jam
MTTF untuk kontainer di klaster ini adalah 40 jam.
MTTF bukanlah formula yang sempurna atau tepat untuk contoh penggunaan dunia nyata, sehingga tim DevOps umumnya menggunakannya sebagai perkiraan daya tahan komponen dan dalam konteks KPI manajemen insiden lainnya, seperti rata-rata waktu perbaikan (MTTR) dan MTBF. MTTF dapat—dalam contoh ini—membantu tim memperkirakan berapa banyak tindakan mulai kembali yang dibutuhkan klaster kontainer setiap hari, sehingga mereka dapat menetapkan ukuran klaster dan sumber daya penskalaan otomatis dengan tepat.
Namun, semakin tepat data kegagalan dan operasi, dan semakin banyak tim data yang disertakan, perhitungan MTTF akan semakin akurat.
Berita teknologi terbaru, didukung oleh insight dari pakar
Tetap terinformasi tentang tren industri yang paling penting—dan menarik—tentang AI, otomatisasi, data, dan di luarnya dengan buletin Think. Lihat Pernyataan Privasi IBM®.
Melacak MTTF memungkinkan tim untuk mengukur keandalan sistem dan membuat keputusan yang tepat tentang manajemen aset, mendorong perencanaan yang lebih baik dan mendorong desain dan proses yang lebih tangguh. Ini membantu perusahaan memprioritaskan:
MTTF memberikan gambaran numerik yang jelas tentang umur aset sebelum kegagalan, sehingga tim dapat menilai keandalan secara objektif alih-alih mengandalkan anekdot.
MTTF juga mengisolasi keandalan bawaan komponen atau layanan dari MTTR, yang mengukur seberapa cepat tim memperbaiki masalah sistem saat terjadi. Ketika MTTF turun untuk suatu layanan, itu sering menandakan masalah desain atau ketergantungan yang lebih dalam (misalnya, pustaka yang buruk). Tim dapat menggunakan sinyal tersebut untuk memulai pemecahan masalah dan menemukan akar masalah kegagalan sistem.
Dengan melacak metrik kegagalan dari waktu ke waktu, tim dapat mengidentifikasi layanan yang rapuh dan memprioritaskan peningkatan untuk mengurangi frekuensi insiden pada masa mendatang.
Pemantauan MTTF dapat membantu perusahaan mengoptimalkan praktik manajemen pemeliharaan dan mengambil pendekatan yang lebih proaktif untuk penyelesaian masalah.
Alih-alih tugas pemeliharaan berbasis waktu atau ad hoc (seperti “mulai kembali layanan X setiap hari Minggu”), tim dapat menggunakan MTTF yang diamati untuk menjadwalkan pemeliharaan sebelum jendela kegagalan normal (“daur ulang pod saat mencapai 80% dari usia kegagalan normal mereka”).
Bahkan, manajer TI dan tim pemeliharaan dapat menyandikan runbook—serangkaian instruksi terperinci untuk menyelesaikan tugas TI—dengan panduan berbasis MTTF yang eksplisit. Misalnya, mereka mungkin menyertakan prompt tugas seperti “Jika layanan X telah berjalan lebih lama dari MTTF normal dan menunjukkan sinyal peringatan dini (kesalahan, latensi), secara proaktif menonaktifkan dan memulai ulang, alih-alih menunggu kegagalan permanen.”
Dalam manajemen insiden, MTTF dapat menunjukkan rata-rata lamanya waktu antara mendeteksi cacat dan kegagalan sistem lengkap, menunjukkan berapa lama sistem kemungkinan akan terus berjalan dalam keadaan kualitas menurun atau tidak aman. Mengetahui jendela penurunan kualitas ini membantu tim memutuskan apakah mereka memiliki menit, jam, atau hari untuk menerapkan perbaikan sebelum komponen berhenti berfungsi.
Ini juga membantu mengurangi keparahan insiden. Alih-alih mengalami kesulitan selama kegagalan yang tidak terduga, staf TI dapat mengeksekusi swap atau failover yang telah mereka rencanakan, uji, dan sediakan sumber daya sebelumnya.
Memasukkan MTTF ke dalam KPI DevOps mendorong tim TI untuk merancang keandalan dan penurunan kualitas yang mulus, alih-alih hanya berfokus pada kecepatan pengiriman. Tim dapat membandingkan MTTF di seluruh komponen untuk menginformasikan pilihan arsitektur seperti mengganti komponen yang berkinerja buruk dan mendesain ulang layanan.
Mengamati MTTF membantu arsitek TI memutuskan di mana redundansi diperlukan. Misalnya, layanan penting dengan MTTF rendah kemungkinan akan membutuhkan replika, klaster failover, atau pemutus sirkuit (yang mencegah layanan mencoba mengulangi operasi yang gagal) agar berjalan dengan sukses.
MTTF juga memberi arsitek metrik panduan untuk menggabungkan layanan. Jika aplikasi bergantung pada rantai dependensi dengan MTTF rendah (yang akan gagal lebih sering), tim DevOps dapat memilih untuk memisahkannya atau menambahkan jalur fallback untuk mencegah kegagalan bertingkat di seluruh layanan.
MTTF membantu tim DevOps memprioritaskan utang teknis dengan mengubah keluhan “kerapuhan” yang samar menjadi risiko keandalan yang dapat diukur yang dapat diberi peringkat dan ditindaklanjuti. Mereka dapat menggunakan data MTTF untuk membuat tumpukan keandalan yang diurutkan oleh MTTF dan dampak insiden sehingga faktor ulang, desain ulang, dan peningkatan ketergantungan menargetkan area yang terbukti paling merusak stabilitas sistem.
Selain itu, data MTTF memungkinkan perusahaan untuk menghubungkan utang teknis dengan hasil bisnis dengan menunjukkan seberapa sering layanan rusak dan berapa banyak waktu henti atau gangguan pengguna yang ditimbulkannya dari waktu ke waktu. Ini membantu para insinyur memberikan argumen berbasis bukti untuk membayar utang. Alih-alih mengandalkan intuisi, mereka dapat mengatakan “modul ini gagal setiap N hari dan mendorong X% dari insiden kami,” yang lebih relevan bagi tim kepemimpinan dan produk.
SLO adalah target kinerja yang disepakati untuk layanan tertentu selama periode waktu tertentu. Mereka membantu menentukan status layanan yang diharapkan dan membantu merampingkan pengambilan keputusan seputar modifikasi sistem.
Ketersediaan SLO menentukan jendela waktu henti layanan yang dapat diterima, yang dikenal sebagai anggaran kesalahan. Anggaran kesalahan dirancang untuk membantu perusahaan menyeimbangkan inovasi dan stabilitas. Jika anggarannya sehat, tim dapat dengan aman memprioritaskan pengiriman fitur. Jika anggaran hampir habis, mereka harus mengalihkan fokus ke keandalan.
Layanan dengan MTTF rendah dapat dengan cepat menghabiskan anggaran kesalahan, menandakan bahwa SLO tidak realistis untuk desain saat ini atau tim TI harus meningkatkan keandalan layanan untuk meningkatkan MTTF.
MTTF dan MTBF keduanya merupakan metrik keandalan yang menggambarkan berapa lama peralatan cenderung beroperasi, tetapi keduanya berlaku pada berbagai jenis aset dan siklus hidup. MTTF menunjukkan rata-rata waktu sampai kegagalan pertama komponen, sedangkan MTBF menunjukkan rata-rata waktu antara siklus kegagalan.
MTTF memperkirakan waktu operasi rata-rata aset yang tidak dapat diperbaiki sampai kegagalan permanen dan harus diganti setelahnya. Ini mengasumsikan bahwa satu peristiwa kegagalan akan mengakhiri umur berguna suatu komponen.
MTTF berlaku untuk komponen perangkat keras yang langsung diganti, seperti disk penyimpanan, unit pemrosesan pusat (CPU), dan kabel. Hal ini juga berlaku untuk komponen perangkat lunak seperti kontainer dan layanan mikro, yang pada akhirnya digantikan oleh versi baru atau layanan yang berbeda, alih-alih diperbaiki di tempat.
MTBF mengukur jumlah waktu rata-rata antara kegagalan berturut-turut dari aset yang dapat diperbaiki—termasuk server, komponen jaringan, dan kode perangkat lunak—yang diperbaiki dan dikembalikan ke layanan setelah kerusakan. Metrik ini mengasumsikan sebuah peralatan akan gagal, diperbaiki, dan kemudian gagal lagi, sehingga masa manfaat sistem terdiri dari beberapa siklus “kegagalan → perbaikan”.
Bersama-sama, metrik MTTF dan MTBF menginformasikan bagaimana tim TI melakukan pendekatan terhadap insiden dan manajemen layanan TI.
Dalam banyak arsitektur, komponen yang tidak dapat diperbaiki (dilacak dengan MTTF) tertanam dalam sistem besar, kompleks, dan dapat diperbaiki (dilacak dengan MTBF), sehingga MTTF dapat membantu tim memprediksi kapan mekanisme internal akan memaksa kegagalan yang berkontribusi pada MTBF sistem yang lebih besar.
Misalkan data observabilitas mengungkapkan bahwa layanan mikro pemrosesan pembayaran dalam aplikasi retail memiliki MTTF 1.000 jam sebelum kebocoran memori penting menyebabkannya macet dan tidak dapat dipulihkan. Tim DevOps dapat menjadwalkan dan mengotomatiskan mulai kembali layanan mikro pada posisi 800 jam untuk mencegah rantai kegagalan yang akan menyebabkan MTBF aplikasi anjlok.
Dengan demikian, penggantian preventif layanan mikro yang tidak dapat diperbaiki secara langsung meningkatkan keandalan seluruh aplikasi.
Kedua metrik tersebut juga merupakan dasar pada perencanaan ketersediaan dan pemeliharaan. MTTF mendukung keputusan tentang manajemen inventaris dan persediaan suku cadang pengganti, sementara MTBF mendukung keputusan tentang jadwal pemeliharaan preventif dan frekuensi gangguan yang diharapkan.
Digunakan bersama metrik waktu perbaikan seperti MTTR, MTTF dan MTBF memungkinkan perencana untuk memperkirakan waktu aktif sistem, anggaran suku cadang, dan melakukan penyempurnaan sistem TI untuk keandalan yang optimal.
Proses untuk meningkatkan MTTF aset sangat bervariasi berdasarkan sistem yang dimaksud, dependensinya, ekosistem DevOps lebih besar yang dioperasikannya, dan tujuan bisnis yang lebih luas. Namun, ini cenderung melibatkan beberapa praktik kunci tertentu, termasuk:
- Pemantauan berkelanjutan. Dengan menggunakan alat pemantauan dan observabilitas, tim TI dapat melacak penyimpangan kinerja dan keandalan secara real-time, memungkinkan mereka untuk menerapkan tindakan pencegahan yang mencegah masalah kecil mempercepat kegagalan sistem.
- Pemeliharaan preventif. Melakukan inspeksi rutin dan menjadwalkan pemeliharaan sistem secara proaktif dapat membantu tim mengurangi tingkat kegagalan dan memperpanjang umur rata-rata layanan TI.
- Protokol pengujian yang tangguh. Praktik pengujian komprehensif dan otomatis memungkinkan tim untuk mendeteksi cacat pada perangkat lunak sebelum penerapan (dan sebelum memengaruhi pengguna akhir). Sebagian besar saluran dan alat continuous integration/continuous delivery (CI/CD) berkualitas tinggi mengintegrasikan pengujian di seluruh siklus pengembangan perangkat lunak.
- Strategi redundansi. Banyak perusahaan mengandalkan replika dengan beban seimbang , arsitektur TI di berbagai wilayah, alat orkestrasi kontainer, dan proses data replication untuk menghilangkan titik kegagalan tunggal dan membantu tim mengurangi dampak kegagalan.
Sumber daya
Memanfaatkan kekuatan AI dan otomatisasi untuk memecahkan masalah secara proaktif di seluruh tumpukan aplikasi.
Gunakan perangkat lunak dan alat bantu DevOps untuk membangun, menerapkan, dan mengelola aplikasi cloud native di berbagai perangkat dan lingkungan.
Percepat ketangkasan dan pertumbuhan bisnis — terus modernisasi aplikasi Anda di platform apa pun menggunakan layanan konsultasi cloud kami.