Laporan State of Devops 2017 mengatakan ada sekitar 31-45% "tingkat kegagalan berubah." Meskipun secara intuitif terdengar benar, apakah itu dilacak sebagai insiden? Tidak Karena mereka diperbaiki dengan sangat cepat, biasanya selama validasi.
Masalah yang diperbaiki dengan cepat masih menjadi masalah. Jika Anda tidak melaporkannya seperti itu, itu masalah.
Jadi, dibutuhkan disiplin untuk melaporkan tingkat kegagalan secara akurat. Kami tidak bersemangat untuk melaporkan seperti itu karena kami ingin segala sesuatunya berfungsi dan kami melakukan apa yang diperlukan untuk mewujudkannya.
Jika tujuan Anda sebenarnya agar semuanya berjalan lancar, maka Anda harus jujur tentang kegagalan sehingga Anda dapat mencegahnya di masa depan. Kedengarannya seperti tim di sini berbohong (mungkin untuk diri mereka sendiri, tentu manajemen) tentang kegagalan karena tujuan mereka adalah untuk memiliki hal-hal muncul untuk dapat bekerja.
Ini adalah hal yang berbeda. Sebagai contoh, ambil lelucon lama bahwa QA menghasilkan bug - "kode saya baik-baik saja sampai QA memilikinya, dan kemudian mereka membuat semua bug ini!". Bug ada di sana selama ini, tetapi pengembang tidak tahu tentang mereka. Sasaran tim operasi haruslah keandalan yang sebenarnya , dan mereka harus diberi insentif seperti itu oleh manajemen mereka. Itu berarti bahwa jika mereka menempatkan lebih banyak pemantauan di tempat yang mengarah pada penemuan masalah baru, mereka harus diberi penghargaan, tidak dihukum karena penurunan berikutnya dalam metrik keandalan.
TL; DR, bagaimana Anda membuktikan devops, khususnya otomatisasi penyebaran, meningkatkan tingkat kegagalan perubahan?
Jika Anda mencoba memotivasi perubahan dalam organisasi Anda, maka Anda seharusnya tidak mencoba untuk membuktikan apa pun, tetapi berikan bukti dari apa yang dikatakan organisasi lain tentang transisi mereka sendiri. Jika Anda mencoba mengukur proses yang sudah Anda miliki dan menjustifikasi keberlanjutannya, maka Anda harus melacak metrik keandalan standar, seperti mean time to repair (MTTR).
Tetapi prinsip-prinsip devops bukan hanya tentang meningkatkan keandalan. Bahkan rekayasa keandalan situs tidak hanya tentang peningkatan keandalan. Sebaliknya, Anda ingin mencapai tingkat keandalan yang sesuai - sesuatu yang menguntungkan bisnis tetapi tidak menghambat pengembangan. Dan itu memunculkan motivator sejati dalam devops, yaitu memberdayakan perubahan . Anda ingin agar bisnis merespons lebih cepat terhadap rangsangan pasar, yang terjadi dengan mengurangi gesekan pengembang, meningkatkan tingkat penyebaran, mengotomatiskan proses manual, dll. Sambil tetap dalam batas keandalan yang dapat diterima. Ini berarti Anda perlu mengukur keandalan, tetapi Anda juga perlu mengukur kecepatan, karena tujuan Anda adalah meningkatkan yang terakhir sambil menjaga yang sebelumnya relatif statis.