Saat memperkenalkan alat baru, bahasa pemrograman, atau ketergantungan ke lingkungan Anda, langkah apa yang Anda ambil untuk mengevaluasinya? Dalam artikel ini, saya akan membahas kerangka kerja enam pertanyaan yang saya gunakan untuk membuat keputusan ini.
Masalah apa yang saya coba selesaikan?
Kita semua terjebak dalam hal-hal kecil dari masalah langsung yang dihadapi. Penilaian yang jujur dan kritis membantu mengungkap akar masalah yang lebih luas dan mencegah pengoptimalan mikro.
[ Anda mungkin juga menyukai: Enam langkah penerapan untuk layanan Linux dan alat terkaitnya ]
Katakanlah Anda mengalami masalah dengan sistem manajemen konfigurasi Anda. Tugas operasional sehari-hari memakan waktu lebih lama dari yang seharusnya, dan bekerja dengan bahasa itu sulit. Sistem manajemen konfigurasi baru mungkin dapat mengatasi masalah ini, tetapi pastikan untuk melihat konteks sistem ini secara lebih luas. Mungkin beralih dari mesin virtual ke wadah yang tidak dapat diubah memudahkan masalah ini dan lebih banyak lagi di lingkungan Anda sambil menjadi jumlah pekerjaan yang setara. Pada titik ini, Anda juga harus mengeksplorasi kelayakan solusi yang lebih komprehensif. Anda mungkin memutuskan bahwa ini bukan proyek yang layak untuk organisasi saat ini karena kurangnya pengetahuan organisasi tentang container, tetapi dengan hati-hati menerima tradeoff ini memungkinkan Anda untuk menempatkan container pada peta jalan untuk kuartal berikutnya.
Latihan intelektual ini membantu Anda menelusuri akar penyebab dan memecahkan masalah inti, bukan gejala masalah yang lebih besar. Ini tidak selalu memungkinkan, tetapi berhati-hatilah dalam membuat keputusan ini.
Apakah alat ini menyelesaikan masalah itu?
Sekarang kita telah mengidentifikasi masalahnya, sekarang saatnya untuk evaluasi kritis dari diri kita sendiri dan alat yang dipilih.
Teknologi tertentu mungkin tampak menarik karena baru karena Anda membaca entri blog yang keren tentangnya atau Anda ingin menjadi orang yang memberikan ceramah konferensi. Lonceng dan peluit bisa menyenangkan, tetapi alat tersebut harus menyelesaikan masalah inti yang Anda identifikasi di pertanyaan pertama.
Apa yang saya menyerah?
Alat ini akan, pada kenyataannya, memecahkan masalah, dan kami tahu bahwa kami sedang memecahkan benar masalah, tapi apa pengorbanannya?
Pertimbangan ini bisa murni teknis. Akankah kurangnya alat observabilitas mencegah debugging yang efisien dalam produksi? Apakah sifat sumber tertutup dari alat ini membuat lebih sulit untuk melacak bug halus? Apakah mengelola ketergantungan lain sepadan dengan manfaat operasional menggunakan alat ini?
Selain itu, sertakan konteks organisasi, bisnis, dan hukum yang lebih besar tempat Anda beroperasi.
Apakah Anda menyerahkan kendali atas alur kerja bisnis penting kepada vendor pihak ketiga? Jika vendor tersebut menggandakan biaya API mereka, apakah itu sesuatu yang mampu dan bersedia diterima oleh organisasi Anda? Apakah Anda nyaman dengan perkakas sumber tertutup yang menangani sedikit informasi kepemilikan yang sensitif? Apakah lisensi perangkat lunak membuat ini sulit untuk digunakan secara komersial?
Meskipun bukan pertanyaan sederhana untuk dijawab, meluangkan waktu untuk mengevaluasi ini di awal akan menghemat banyak masalah di kemudian hari.
Apakah proyek atau vendor sehat?
Pertanyaan ini datang dengan tambahan "untuk keseimbangan kebutuhan Anda." Jika Anda hanya membutuhkan alat untuk membawa tim Anda melewati empat hingga enam bulan hingga Project X selesai, pertanyaan ini menjadi kurang penting. Jika ini merupakan komitmen multi-tahun dan alat tersebut mendorong alur kerja bisnis yang penting, ini menjadi perhatian.
Saat melewati langkah ini, manfaatkan semua sumber daya yang tersedia. Jika solusinya adalah open source, lihat riwayat komit, milis, dan diskusi forum tentang perangkat lunak itu. Apakah komunitas tampaknya berkomunikasi secara efektif dan bekerja sama dengan baik, atau apakah ada perpecahan yang jelas di antara anggota komunitas? Jika bagian dari apa yang Anda beli adalah kontrak dukungan, gunakan dukungan itu selama fase pembuktian konsep. Apakah itu sesuai dengan harapan Anda? Apakah kualitas dukungan sepadan dengan biayanya?
Pastikan Anda mengambil langkah melampaui bintang dan garpu GitHub saat mengevaluasi alat sumber terbuka juga. Sesuatu mungkin muncul di halaman depan agregator berita dan mendapat perhatian selama beberapa hari, tetapi pengamatan yang lebih dalam mungkin mengungkapkan bahwa hanya beberapa pengembang inti yang benar-benar mengerjakan sebuah proyek, dan mereka mengalami kesulitan menemukan kontribusi dari luar. Mungkin sebuah alat adalah open source, tetapi tim yang didanai perusahaan mendorong pengembangan inti, dan dukungan kemungkinan akan berhenti jika organisasi itu meninggalkan proyek. Mungkin API telah berubah setiap enam bulan, menyebabkan banyak kesulitan bagi orang-orang yang telah mengadopsi versi sebelumnya.
Apa risikonya?
Sebagai seorang teknolog, Anda memahami bahwa tidak ada yang berjalan sesuai rencana. Jaringan mati, drive gagal, server reboot, baris di pusat data kehilangan daya, seluruh wilayah AWS menjadi tidak dapat diakses, atau BGP membajak merutekan ulang ratusan terabyte lalu lintas Internet.
Tanyakan pada diri Anda bagaimana alat ini bisa gagal dan apa dampaknya. Jika Anda menambahkan produk vendor keamanan ke saluran CI/CD Anda, apa yang terjadi jika vendor tersebut mati?
Ini memunculkan pertimbangan teknis dan bisnis. Apakah pipa CI/CD hanya habis waktu karena tidak dapat menjangkau vendor, atau apakah Anda "gagal membuka" dan mengizinkan pipa untuk menyelesaikan dengan peringatan? Ini adalah masalah teknis tetapi pada akhirnya merupakan keputusan bisnis. Apakah Anda bersedia melakukan produksi dengan perubahan yang telah melewati pemindaian keamanan dalam skenario ini?
Jelas, tugas ini menjadi lebih sulit karena kami meningkatkan kompleksitas sistem. Untungnya, situs seperti k8s.af mengkonsolidasikan contoh skenario pemadaman. Postmortem publik ini sangat membantu untuk memahami bagaimana suatu perangkat lunak dapat gagal dan bagaimana merencanakan skenario itu.
Berapa biayanya?
Pertimbangan utama di sini adalah waktu karyawan dan, jika berlaku, biaya vendor. Apakah aplikasi SaaS itu lebih murah daripada jumlah karyawan yang lebih banyak? Jika Anda menyimpan setiap pengembang di tim dua jam sehari dengan alat CI/CD baru itu, apakah itu membayar sendiri selama tahun fiskal berikutnya?
Memang, tidak semuanya harus menjadi proposisi hemat biaya. Mungkin tidak akan hemat biaya jika Anda menyimpan tim pengembang beberapa jam sehari, tetapi Anda menghapus pemblokir besar dalam alur kerja harian mereka, dan mereka akan jauh lebih bahagia karenanya. Kebahagiaan itu kemungkinan sepadan dengan biaya finansialnya. Mengangkat pengembang baru itu mahal, jadi jangan meremehkan nilai peningkatan retensi saat membuat perhitungan ini.
[ Panduan gratis dari Red Hat:5 langkah untuk mengotomatisasi bisnis Anda. ]
Menutup
Saya harap Anda telah menemukan kerangka kerja ini berwawasan luas, dan saya mendorong Anda untuk memasukkannya ke dalam proses pengambilan keputusan Anda sendiri. Tidak ada kerangka kerja satu ukuran untuk semua yang berfungsi untuk setiap keputusan. Jangan lupa bahwa, terkadang, Anda mungkin perlu mengambil keputusan dan membuat keputusan. Namun, memiliki proses standar seperti ini akan membantu membedakan antara saat Anda dapat menganalisis keputusan secara kritis dan saat Anda perlu membuat lompatan itu.