Suatu hari, Ivan dipanggil ke pertemuan untuk membahas metrik DevOps.
Setiap peserta menyiapkan rapat metrik tertentu yang menurut pendapatnya layak diterapkan.
Mendengarkan laporan, Ivan mencoba menghitung berapa banyak metrik yang disarankan: 5.10, lagi 10, dan sekitar selusin lagi. Ternyata 30 dengan sesuatu.
Entah mengapa, tiba-tiba muncul ide bahwa orang-orang berkumpul di Google dan menulis nama-nama yang tampaknya menarik bagi mereka. Ternyata, tidak ada yang memikirkan esensi metrik.
Menonton dari samping, Ivan bertanya pada dirinya sendiri: mengapa? Mengapa tepatnya metrik ini? Apa yang akan mereka berikan padamu? Tiba-tiba menjadi jelas bahwa pertemuan itu menyatukan orang-orang yang jauh dari pemahaman nyata tentang sifat metrik, dan bahwa semuanya akan berakhir seperti biasa, dengan kehilangan banyak waktu dan membuang pekerjaan ke tempat sampah.
Itu menjadi sedih dan menghina. Sangat memalukan bahwa waktu dan uang perusahaan tidak menuju ke mana-mana, dan menyedihkan bahwa bisnis yang bermanfaat tidak akan selesai.
Ivan telah mempelajari metrik untuk waktu yang lama dan memahami untuk waktu yang lama bahwa topiknya sangat serius dan kompleks, dan dalam hal apa pun mustahil untuk mendekatinya dari kolek.
Pada hari itu, pertemuan berakhir dengan segalanya dan tanpa apapun - kami memutuskan untuk mengimplementasikan semuanya sekaligus (tidak ada yang mau bertanggung jawab atas penolakan itu, karena saya tidak mengerti mengapa orang lain membutuhkan metrik ini).
Ivan memutuskan untuk menyiapkan visinya tentang metrik DevOps, dan memastikan bahwa setiap metrik dibenarkan di dalamnya, memiliki tujuan tertentu, bermanfaat, dan dapat dipahami.
Itu yang dia lakukan ...
Apa yang ingin Anda kelola?
Pertama-tama, Ivan memutuskan untuk memikirkan TUJUAN UTAMA, yang metriknya dibuat.
Buku-buku yang banyak dibaca Lean Analytics dan The Practice of Tao Toyota menyarankan: pilih nomor yang ingin Anda kontrol sebagai metrik utama. Selanjutnya, pilih komponen nomor ini yang dapat Anda pengaruhi sebagai metrik.
Tujuan DevOps pada pertemuan terakhir menyatakan "kualitas perangkat lunak", tetapi konsep kualitasnya sangat kabur. Apa itu kualitas? Bagaimana cara mengekspresikannya dalam satu nomor? Komponen apa yang mempengaruhinya?
Sayangnya, kualitas perangkat lunak tidak dapat dinyatakan dalam satu nomor.
Lagi pula, apakah tujuan menggunakan DevOps benar-benar berkualitas?
Beberapa tahun yang lalu, Ivan bekerja sebagai direktur TI untuk sebuah perusahaan kecil yang memproduksi perangkat lunaknya sendiri, dan di sana ia berhasil meluncurkan dan menggunakan DevOps. Dan tujuan dari DevOps ini sama sekali tidak berkualitas. Sebaliknya, kualitas juga. Tujuan utama dan satu-satunya adalah untuk menghilangkan tenaga kerja manual selama penyebaran di prom.
Dengan menghapus tenaga kerja manual, ia kemudian mencapai akselerasi dan pengurangan jumlah kesalahan sehingga menjadi mungkin untuk melepaskan peningkatan setidaknya sekali dalam satu menit.
Jadi, ternyata bahwa sebagai
TARGET METRIC DevOps dengan sendirinya menunjukkan dirinya
Waktu pengiriman
Justru penurunan atau kenaikannya yang akan menunjukkan efek dari keputusan manajerial yang dibuat.
Waktu pengiriman (Time To Market, TTM) telah meningkat - buruk. Menurun - sangat baik.
Tetapi waktu pengiriman tergantung pada volume tugas dan pada durasi pengujian dan pada banyak faktor lainnya! Ya itu benar.
Dan itulah sebabnya Ivan sengaja memutuskan untuk memulai hitung mundur bukan dari saat pengkodean dan analisis, tetapi sejak saat perakitan (distribusi) telah dibuat dan berada di penyimpanan dan yang tersisa hanyalah melakukan serangkaian pemeriksaan dan menyebarkannya pada lingkungan industri (yang disebut Pengiriman Continious, CDL).
Penting di sini untuk pertama-tama mengembangkan prinsip, konsep, pikir Ivan, dan untuk memperluasnya ke wilayah-wilayah yang belum terjangkau lainnya, karena pengkodean, perakitan, dan semua langkah pengembangan lainnya juga memengaruhi waktu pengiriman seperti halnya tahap CDL. Mari kita lakukan di satu - kita akan melakukannya di yang lain.
Di perusahaan besar tempat Ivan bekerja, metrik sangat penting. Ribuan pengembang melihat kode dan ratusan majelis dibuat setiap hari, tetapi tidak ada seorang pun di perusahaan yang tahu berapa banyak waktu yang dihabiskan tim untuk DevOps.
Keluhan mengalir dari semua sisi: DevOps adalah sampah, tidak berfungsi, melambat, tidak ada gunanya. Tetapi tidak ada yang memiliki angka nyata, dan itu tidak mungkin untuk membuktikan atau menyangkal pernyataan tim.
Ini adalah tujuan yang ditetapkan Ivan sendiri - untuk menghitung waktu yang dihabiskan tim pada DevOps, dan khususnya pada tahap pengiriman perakitan.
Ini tidak mungkin, pikir Ivan, jika saya pernah meluncurkan DevOps dan itu memberikan efek instan, lalu mengapa tidak ada di sini?
Penciptaan sistem metrik menjadi masalah kehormatan bagi Ivan.
Kontrol apa yang bisa Anda kontrol
Bagaimana cara mengatur waktu pengiriman? Apakah ini mungkin? - tanya Ivan.
Jika kami menganggap waktu pengiriman sebagai angka, menjadi jelas bahwa ada tempat dalam proses DevOps yang secara signifikan mempengaruhi nomor ini.
Perusahaan Ivan memiliki standar: setiap perakitan sebelum pergi ke prom seharusnya melewati tiga bangku tes, di mana berbagai aspek perangkat lunak diuji.
Secara alami, rakitan pada mereka "jatuh" karena kesalahan, dan yang baru dibuat sebagai gantinya.
Ternyata tribun adalah elemen kunci dari total waktu pengiriman, dan merekalah yang memengaruhi total waktu, meningkatkannya.
Waktu pengiriman = Waktu berdiri 1 + Waktu berdiri 2 + Waktu berdiri 3Mempengaruhi waktu yang dihabiskan oleh tim di masing-masing stan, akan mungkin untuk mempengaruhi waktu pengiriman akhir.
Masih ada dua pertanyaan sederhana:
- bagaimana cara menghitung biaya tim secara fisik dan
- apa yang harus dilakukan dengan waktu henti antar tegakan (downtime juga merupakan komponen waktu pengiriman)?
Ivan tidak punya pilihan selain terjun ke hutan Jenkins dan Nexus (perangkat lunak yang digunakan dalam CDL).
Jenkins dan Nexus membantu
Perakitan "Roll" di dudukan dilakukan menggunakan Jenkins. Sebenarnya, Jenkins adalah sheduler biasa, seperti crontab, tetapi dengan fitur-fitur canggih.
Jenkins tahu cara menampilkan log dari semua pekerjaan yang sedang berjalan (tugas untuk menggulung rakitan di dudukan) dalam bentuk RSS, dan ada awal, waktu akhir dan tautan ke rakitan tertentu.
Ternyata bahwa pada saat pembuangan Ivan mendapatkan data tentang waktu yang tepat dari awal dan akhir pekerjaan perakitan, yaitu adalah mungkin untuk dengan mudah dan akurat menghitung waktu bersih yang dihabiskan oleh tim di tribun.
Dan jika data dari semua tegakan dibuang ke satu basis data, maka dimungkinkan untuk menghitung waktu henti di antara tegakan. Itu luar biasa!
Dari Nexus (penyimpanan file jaringan), Ivan akan mendapatkan tanggal pembuatan perakitan itu sendiri, dan seterusnya. tentukan saat kemunculannya dan titik referensi.
Semuanya jatuh pada tempatnya. Hampir.
- Dan bagaimana mengelola ini, pikir Ivan? ..
Untuk dilanjutkan. Objek pengaruh