tantangan metrik penerapan pra-DevOps


9

TL; DR, bagaimana Anda membuktikan devops, khususnya otomatisasi penyebaran, meningkatkan tingkat kegagalan perubahan?

Kita semua mencoba menangkap metrik pada 'kegagalan penyebaran' menggunakan sarana saat ini (kebanyakan manual). Sayangnya, 'kegagalan' jarang terjadi, bukan? Karena ketika ada masalah, tim datang bersama (biasanya dengan heroik) untuk memperbaiki masalah (biasanya izin, konfigurasi yang terlewat, Anda tahu latihannya). Jadi ... ketika kita bertanya bagaimana penyebarannya, jawabannya adalah "itu berhasil."

Tapi, secara intuitif kita semua tahu itu tidak baik. Laporan State of Devops 2017 mengatakan bahwa ada sekitar 31-45% " tingkat perubahan kegagalan. " Sementara itu secara intuitif terdengar benar, apakah mereka dilacak sebagai insiden? Tidak Karena mereka diperbaiki dengan sangat cepat, biasanya selama validasi. Jauh lebih jarang untuk benar-benar menghentikan penyebaran.

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.

Jadi, bagaimana Anda membuktikan devops, khususnya penyebaran otomatisasi, meningkatkan tingkat kegagalan perubahan?

(PS mencoba memberi tag ini dengan "# devops-kapabilitas-model")


Satu hal yang mungkin bermanfaat adalah melihat studi kasus sebagai contoh (selain survei yang Anda rujuk).
James Shewey

Jawaban:


6

Teknik yang kami gunakan di masa lalu dalam situasi yang sama adalah untuk mendapatkan "komitmen manajemen" yang menerapkan aturan-aturan ini kepada setiap anggota tim:

  1. Akses untuk melakukan pembaruan ke area penyebaran target (yaitu produksi) terbatas pada sistem otomatis terpilih, yang memiliki jalur audit yang sesuai (= logging) dari segala jenis pembaruan ke area yang mereka kelola.

  2. Pembaruan manual ke area penyebaran target, untuk alasan apa pun, tidak lagi diizinkan oleh anggota tim biasa (id pengguna) yang dulu dapat (berwenang) melakukan pembaruan ini. Sebaliknya, ID pengguna BARU (tambahan) akan dibuat yang akan memiliki semua izin yang diperlukan untuk (masih) melakukan pembaruan manual tersebut, kapan pun diperlukan. Tetapi untuk benar-benar dapat menggunakan ID pengguna baru tersebut (= melakukan login dengan mereka), anggota tim yang ingin melakukan login dengan ID pengguna baru tersebut harus melakukan "beberapa" langkah tambahan untuk mendapatkan akses ke kata sandi untuk Id pengguna baru tersebut. Idealnya langkah tambahan ini juga otomatis (gunakan imajinasi Anda sendiri seperti apa bentuknya), tetapi jika ada yang gagal: hubungi saja (= eMail, panggil, dll.) Penjaga pintu dari kata sandi yang diperlukan, termasuk "masalah yang mereka miliki untuk diperbaiki "

  3. Mendapatkan penjaga gerbang seperti itu di tempat bukanlah pekerjaan mudah. Dan sebagian besar perlawanan akan datang dari ... anggota tim (untuk semua alasan). Karenanya variasi ID pengguna baru tersebut (seperti pada langkah sebelumnya) adalah bahwa setiap anggota tim mendapatkan ID pengguna tambahan (dengan kata sandi yang mereka tentukan sendiri), tetapi dengan string tambahan yang melekat padanya: mereka hanya diperbolehkan melakukan logon dengan ID pengguna (tambahan) jika mereka benar-benar memiliki alasan yang baik untuk melakukannya. Dan setiap kali mereka melakukan login seperti itu, mereka diharuskan untuk mengajukan beberapa jenis laporan tentang "masalah mana yang mereka perbaiki" (mirip dengan pertanyaan Anda).

Dengan prosedur ini, semua yang tersisa untuk dilakukan adalah meninjau secara berkala masing-masing laporan / alasan mengapa diperlukan untuk menggunakan ID pengguna khusus tersebut, dan mengajukan pertanyaan " Apakah ada yang dapat dilakukan untuk mengotomatisasi lebih lanjut ini, untuk lebih lanjut mengurangi perlunya login khusus seperti itu? "

Perbarui :

Kutip dari komentar ekstra Anda di bawah jawaban ini:

Saya pikir menambahkan penghalang buatan untuk memperbaiki masalah penyebaran adalah kontraproduktif.

Benar itu menambah penghalang tambahan, tapi saya tidak yakin itu "buatan". Karena ini, setahu saya, satu-satunya cara untuk mengetahui hal-hal yang tidak akan pernah diberitahukan oleh anggota tim Anda, karena alasan seperti:

  • keamanan kerja.
  • hal-hal buruk / praktik yang mereka sukai untuk disembunyikan.
  • kekuatan mereka tidak mau lepas.

Terima kasih atas umpan baliknya. Meskipun itu mungkin berhasil, saya pikir menambahkan penghalang buatan untuk memperbaiki masalah penyebaran adalah kontraproduktif. Ini adalah tongkat yang berat untuk digunakan tetapi mungkin diperlukan dalam beberapa kasus. Saya lebih suka review pasca-penempatan wajib setelah asap hilang. Ini kurang destruktif tetapi membutuhkan tingkat komitmen manajemen yang sama. Saya hanya ingin tahu apakah orang lain telah melakukan ini.
John O'Keefe

5

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.

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.