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


13

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?


1
Anda telah menemukan masalah inheren dengan semua KPI. Orang akan bekerja untuk memaksimalkan indikator kinerja alih-alih memaksimalkan kinerja aktual . Metrik memberi orang skor untuk naik, dan mereka akan, bahkan dengan biaya melakukan pekerjaan mereka dengan baik.
Adrian

@Adrian Saya setuju, namun ada KPI tertentu, seperti waktu siklus, yang secara inheren sulit untuk permainan.
Richard Slater

Benar. Namun, bahkan mereka yang sulit untuk game akan mengarah pada optimalisasi untuk KPI, yang mungkin kurang optimal secara umum, atau hanya mendukung KPI yang bisa dimainkan. Saya telah menemukan sangat sedikit cara untuk mengukur kinerja DevOps secara otomatis dengan metrik; sebagian besar subyektif dan membutuhkan pengamatan dan keterlibatan pribadi.
Adrian

Itu bukan DevOps, itu ITIL haha
Gayus

Jawaban:


12

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.


2

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.


0
  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

5.DevOpsCulture, which actually can’t be measured=> buat kuesioner anonim untuk semua orang yang terlibat sedikit dan tanyakan kepada mereka bagaimana perasaan mereka tentang semua ini. Ini pasti akan memberi tahu Anda jika Anda memiliki proses yang dijalani oleh orang-orang Anda, atau jika banyak orang yang sebenarnya setengah jalan keluar dari pintu ...
AnoE
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.