Ivan bekerja di organisasi besar di departemen yang terkait dengan DevOps. Setiap hari, ribuan karyawan menggunakan alat DevOps untuk membuat, menguji, dan mengimplementasikan perangkat lunak mereka.
Ribuan distribusi per hari yang melewati jalur perakitan adalah situasi normal.
Namun, di mana ada kekuatan besar, ada juga tanggung jawab besar. Kesulitan yang tak terelakkan dari tim menghasilkan ratusan panggilan dukungan teknis per hari.
Secara alami, banyak yang tidak menyukai alat DevOps. Seseorang berkata bahwa mereka terlalu buggy, sementara yang lain percaya bahwa Anda dapat melakukannya tanpa mereka sama sekali, dan itu akan jauh lebih cepat.
Manajemen perusahaan memahami bahwa semua 100% tim tidak dapat puas dengan DevOps, namun, tidak ada data yang pasti. Akan menyenangkan untuk melihat masalah di jalur perakitan, tetapi bahkan jumlah distribusi yang biasa melewatinya per hari tidak diketahui. Apa yang bisa kita katakan tentang metrik serius.
Pertanyaan tentang metrik DevOps terus muncul - semua orang sangat membutuhkannya.
Ivan, sebagai karyawan yang tahu metrik dan tahu teknologi DevOps, mengambil bagian dekat dalam mempersiapkan proyek.
Bersama dengan administrator DevOps, ia menyusun arsitektur solusi yang memungkinkan, dan juga mempelajari sejumlah besar literatur tentang metrik DevOps. Tidak ada satu artikel pun di Internet dan tidak ada satu buku pun tentang topik ini yang tidak akan dia baca.
Akibatnya, lahirlah solusi teknis lengkap, yang disajikan Ivan kepada manajemen.
Semua hilang
Reaksi manajemen tidak terduga - tidak ada keputusan tentang implementasi yang dibuat.
"Ini kegagalan, kawan," kata kolega yang baik itu sambil tersenyum, meninggalkan Ivan dari rapat.
Meskipun ironi, dia benar. Jika keputusan itu tidak dibuat, maka ada semacam pencegah yang tidak dilihat Ivan dan tidak diperhitungkan.
Manajemen yakin kelayakan teknis menerapkan metrik DevOps, tetapi masih meragukannya.
Dan ini disebabkan oleh alasan yang sangat sederhana: solusi teknis menunjukkan bahwa implementasi, meskipun mungkin, akan membutuhkan sejumlah besar sumber daya manusia dan teknis, yaitu akan sayang. Tetapi apakah akan ada hasil nyata yang bermanfaat dari ini adalah pertanyaan besar.
Ketika datang ke proyek mahal, maka:
- Presentasi tidak mengesankan
- Layout layar tidak mengesankan
- Contohnya tidak mengesankan.
Secara umum, awal proyek ditunda tanpa batas waktu. Bagi Ivan tugas itu tampaknya sama sekali tidak dapat diselesaikan.
Kasus yang menakutkan
Semuanya diputuskan secara kebetulan. Suatu hari, sebuah surat tiba di kantor pos yang menyatakan bahwa dua siswa dibawa ke departemen untuk magang. Salah satu siswa siap melakukan pekerjaan kecil.
Ivan berpikir bahwa itu mungkin untuk melakukan setidaknya sesuatu dengan metrik - dan mengirim siswa tugas teknis untuk bagian dari proyek yang berkurang menjadi tidak mungkin.
Semua yang ada di sana adalah menarik data dari Jenkins dan Nexus dengan cara termudah dari semua cara yang mungkin.
Bayangkan betapa terkejutnya Ivan ketika hanya beberapa hari kemudian seorang siswa mengundangnya untuk melihat sistem kerja. Untuk pertanyaan "Bagaimana saya mendapat prioritas tinggi?" diikuti oleh jawaban: "Anda hanya memiliki TK normal."
Meski begitu, tetapi sistem bekerja. Dia menarik data dari Jenkins dan Nexus dan memasukkannya ke dalam databasenya sendiri.
Ivan menyadari bahwa dia perlu menyelesaikan sisanya secepat mungkin. Dia menggunakan versi gratis QlikView untuk menghasilkan laporan dari data mentah dan pada malam hari versi pertama metrik DevOps sudah siap.
Senin berikutnya adalah terobosan. Melihat metrik yang berfungsi, kepala Ivan berseru: "Ini adalah data paling berguna yang saya lihat belakangan ini!"
Masalah sumber daya diselesaikan secara instan, dan dalam beberapa hari berikutnya, proyek dengan metrik diluncurkan secara maksimal.
Ivan bertindak dengan benar dan tanpa disadari memberikan "hasil cepat" - sistem kerja dengan fungsi terpotong yang memberikan manfaat nyata.
“Hasil Cepat” berfungsi, karena ketika menyangkut sistem mahal yang besar, pasti banyak ambiguitas muncul. Dengan biaya tinggi yang signifikan, hasilnya tidak selalu jelas.
Oleh karena itu, permulaan pekerjaan terus tertunda atau sistem benar-benar ditinggalkan.
Hasil cepat membantu menguji hipotesis dengan cara minimal. Hal utama adalah mencoba membuat prototipe tanpa menarik sumber daya tambahan dan pada saat yang sama membawa nilai dan manfaat.
Beberapa wawasan yang diterima oleh Ivan dari proyek:
Pertama-tama bayangkan hasil akhir yang Anda butuhkan
Ivan tahu persis metrik apa yang akan ia butuhkan, hingga tata letak layar. Ini memungkinkannya untuk dengan cepat membuang fungsionalitas yang tidak perlu dan hanya meninggalkan yang tanpanya metrik benar-benar kehilangan artinya.
Dari sepuluh metrik DevOps yang diusulkan untuk implementasi, Ivan hanya menyisakan satu, dan membatasi hanya untuk satu stan dan satu tim. Bahkan, ini adalah pemerasan yang paling terkonsentrasi di satu sisi, dan data nyata yang praktis di sisi lain.
Versi singkat seperti itu memungkinkan untuk memecahkan satu masalah yang sepenuhnya praktis - untuk menganalisis tim yang sebenarnya dan untuk memahami apakah metrik di dalamnya akan memberikan hasil yang diharapkan dari mereka.
Diagram arsitektur sederhana membuat segalanya lebih mudah
Skema Penyebaran paling sederhana dengan aliran informasi dan data dengan sangat baik membantu Ivan memahami di mana letak dan seberapa mudah untuk mendapatkannya.
Jenkins: Pekerjaan. Apa yang diperlukan untuk metrik dalam pekerjaan? Bagaimana cara mencabutnya? Protokol apa, dari alamat mana?
Nexus: distribusi. Apa yang dibutuhkan Nexus untuk metrik? Bagaimana cara mendapatkannya?
Sistem bantuan: turun karena mereka tidak diperlukan untuk metrik.
Bagaimana cara menggabungkan data? Di mana cara termudah untuk melakukannya secepat mungkin?
Jika memungkinkan, lakukan tanpa coding. Cukup
Jika Anda dapat melakukannya dengan mengunggah yang sudah jadi ke XLS atau CSV, lebih baik melakukan ini dan tidak menyandikannya sama sekali.
Terkadang Anda tidak dapat melakukannya tanpa coding, tetapi Anda masih harus memilih opsi yang paling mudah.
Misalnya, Jenkins memberi makan data dalam RSS dan JSON. Pilih opsi yang lebih mudah diterapkan.
Nexus hanya mengembalikan XML? Nah, tidak ada yang harus dilakukan, Anda harus kode.
Jangan menggantung terlalu banyak. Bersihkan semuanya
Otomatisasi super tidak diperlukan untuk hasil yang cepat. Anda dapat melakukannya dengan kode perintah alih-alih nama mereka. Anda seharusnya tidak menghubungkan sistem tambahan hanya untuk pengayaan data. Ini hanya panduan bunga dan kecantikan - lebih baik melakukannya tanpa bunga dan menghemat waktu.
Alih-alih menulis ke database, Anda dapat menulis ke file teks biasa atau csv, jika akan lebih cepat.
Di mana Anda dapat memulai secara manual - mulai, jangan buang waktu untuk sheduler.
Jika lebih mudah menulis dalam bahasa scripting ringan seperti Python atau PHP - tulis. Bagaimanapun, Anda melakukan yang minimum, jadi Anda tidak perlu menulis ulang banyak.
Gunakan alat yang memungkinkan Anda untuk mendapatkan hasil dengan cepat, misalnya, QlikView atau Tablue gratis untuk metrik - membuatnya mudah untuk memuat dan menggabungkan data, serta membuat semua grafik yang diperlukan.
Ivan mengambil "hasil cepat" ke dalam layanan dan dalam proyek-proyek berikut ini ia selalu mencoba untuk pertama-tama membuat sistem kerja minimal yang memberikan manfaat, dan baru kemudian mengambil sisanya. Dan itu selalu berhasil.
Jika kisah Ivan tampak bermanfaat bagi Anda, saya akan sangat senang karenanya.
Silakan tulis di komentar kasus Anda ketika hasil cepat berpengaruh.