Indikator Kinerja Utama (KPI) apa yang digunakan untuk mengukur DevOps?

Saya mencoba untuk mengarahkan perilaku yang baik dalam program transformasi DevOps, untuk mendukung ini saya melihat mengidentifikasi metrik yang dapat ditindaklanjuti di sekitar disiplin operasi:

• Masalah dan Manajemen Insiden
• Manajemen kapasitas
• Ubah dan Lepaskan Manajemen

Agar benar-benar jelas, ini adalah fungsi yang dulunya milik organisasi operasi dan sekarang dimiliki oleh organisasi Agile / DevOps. Ada KPI yang ada yang mendorong perilaku buruk adalah:

• Waktu untuk Root Cause Analysis selesai:
  • Menggerakkan RCA yang tidak lengkap hanya untuk membawanya ke sistem tepat waktu.
• Durasi pelaksanaan tes:
  • Menonaktifkan tes jangka panjang, terlepas dari nilai bisnis mereka.
• Rata-rata pemanfaatan layanan cloud:
  • Mendorong komitmen yang berlebihan atas sumber daya komputasi, menghasilkan waktu respons yang lambat

Indikator Kinerja Utama apa yang dapat digunakan untuk mendorong perilaku yang baik dalam Program DevOps?

Saya tidak berpikir ada KPI DevOps "universal". Misalnya, kecepatan itu bagus, kecuali itu bukan penggerak utama bisnis Anda. Amazon sangat peduli dengan kecepatan karena mereka memiliki operasi ritel besar-besaran. Itu kurang penting untuk aplikasi kecil dengan 100 pengguna.

Ini menimbulkan pertanyaan: bagaimana Anda memilih KPI terbaik yang relevan dengan bisnis Anda ? Itu adalah proses penelitian dan penemuan yang melibatkan seluruh Perusahaan Anda.

Apa yang kamu pedulikan?

• Kualitas
• Keandalan
• Maintabilitas
• Kecepatan
• Peningkatan proses
• Tingkat Layanan

Apa yang membuat para pemangku kepentingan bisnis Anda terjaga di malam hari? Apa yang menentukan apakah Anda menghasilkan uang pada kuartal ini atau tidak? Daftar di atas mungkin termasuk beberapa dari hal-hal itu, atau mungkin tidak. Buat daftar Anda, lalu cari tahu bagaimana menyelaraskan insentif di setiap departemen untuk mencapainya.

Insentif mendorong perilaku, jadi putuskan secara kolaboratif pada tujuan-tujuan SMART. Pilih dua atau tiga item dari daftar curah pendapat Anda, dan mulailah siklus ukur / perbaiki umpan balik untuk masing-masing item. Jangan memilih terlalu banyak sekaligus - Anda lebih mungkin berhasil dengan berfokus pada dua atau tiga hal.

DevOps tidak memiliki KPI . Itu seperti bertanya apa KPI Cinta. Tapi beberapa hal yang Anda sebutkan ( Masalah dan Manajemen Insiden , Kapasitas Manajemen , Perubahan dan Manajemen Pers ) memiliki baik KPI, beberapa di antaranya didasarkan pada teori di balik DevOps.

Secara umum, untuk proses bisnis apa pun, Anda dapat membuat Peta Rantai Nilai yang menggambarkan bagaimana nilai mengalir dari Pelanggan , melalui perusahaan kembali ke Pelanggan . Seluruh loop selalu harus dimulai dan diakhiri dengan Pelanggan, tetapi kadang-kadang, untuk organisasi layanan, Pelanggan dapat internal. The throughput nilai melalui rantai tersebut dapat menjadi cara yang baik untuk merancang KPI Anda dengan cara tamper-proof. Mengukur setiap KPI di setiap tautan individual dari rantai nilai hanya masuk akal selama tautan tersebut merupakan hambatan dari proses tersebut dan Anda mencoba untuk mengeksploitasi atau meninggikan hambatan tersebut.

Masalah umum dengan KPI adalah ketika mulai setengah dari rantai. Misalnya, proses Perubahan dan Rilis sering dimulai dengan pengembang dan berakhir dengan penerapan. Proses ini tidak termasuk:

• Pelanggan mengalami masalah
• Tim pendukung mengidentifikasi masalah
• Tim produk mendefinisikan masalah untuk jaminan simpanan
• Tim Solusi menyesuaikan penyebaran untuk pelanggan
• Pelanggan menyadari nilai dari solusi

Masalahnya adalah bahwa mengukur waktu siklus saja dapat menyebabkan dua masalah utama:

1. Kemacetan ada di salah satu bagian yang dikecualikan yang disebutkan di atas dan pelanggan Anda tidak menyadari nilai dan Anda tidak menyadari pendapatan yang proporsional dengan kecepatan waktu siklus Anda. Jadi, sementara teknik Anda sangat baik, bisnis Anda menderita.

2. Putus dari Pelanggan akan membuat siklus rilis Anda kosong - tidak menghasilkan nilai apa pun, meskipun perubahan telah dilakukan - atau bahkan menangkal kebutuhan Pelanggan Anda dan pekerjaan yang dilakukan dapat memiliki nilai bisnis negatif.

Masalah lain dengan KPI adalah bahwa ketika memulai dan mengakhiri dengan pelanggan itu mungkin tidak benar-benar mengukur nilai kepada pelanggan. Contoh yang baik adalah proses Problem and Incident Response dan MTTR (Mean Time To Repair) sebagai KPI. Apakah masalah bahkan memengaruhi siapa pun? Apa nilai bagi pelanggan? Anda dapat memiliki MTTR luar biasa 3 jam lebih dari 100 insiden. Tetapi jika kebanyakan dari mereka adalah internal, tanpa dampak minimal terhadap pelanggan dan diselesaikan dalam hitungan menit, sedangkan satu insiden besar dengan dampak pelanggan besar membutuhkan waktu 3 hari untuk ditangani, nilai bisnis lebih rendah daripada jika Anda memiliki MTTR 1 hari, karena Anda abaikan sebagian besar insiden internal, tetapi Anda merespons insiden dampak pelanggan yang besar dalam waktu 1 jam.

CATATAN: Untuk pelanggan internal, dalam hal proses bisnis tim pendukung, nilai yang diturunkan bukanlah nilai pekerjaan bagi pelanggan internal, tetapi nilai yang diperoleh oleh bisnis dalam membebaskan pelanggan internal dalam proses bisnis mereka sendiri. Membuka blokir tim yang merupakan hambatan dalam proses mereka sendiri mendapatkan nilai yang lebih tinggi daripada membuka blokir tim atau individu yang tidak mengalami bottleneck. Semua KPI tim pendukung seperti itu perlu memasukkan nilai bisnis dalam perhitungannya.

1. Frekuensi penyebaran
2. Kecepatan penyebaran
3. Tingkat keberhasilan penyebaran
4. Seberapa cepat layanan dapat dipulihkan setelah penyebaran yang gagal
   Dan akhirnya,
5. DevOps Culture, yang sebenarnya tidak bisa diukur