Apakah sulit untuk memahami poin utama ketika berbicara tentang DevOps? Kami telah mengumpulkan untuk Anda analogi yang jelas, rumusan yang menarik, dan saran dari para ahli yang akan membantu bahkan non-spesialis untuk langsung ke pokok permasalahan. Pada akhirnya, bonusnya adalah DevOps milik karyawan Red Hat.
Istilah DevOps berasal dari 10 tahun yang lalu dan telah berubah dari hashtag Twitter menjadi gerakan budaya yang kuat di dunia TI, sebuah filosofi sejati yang mendorong pengembang untuk menyelesaikan sesuatu dengan lebih cepat, bereksperimen, dan terus melakukan iterasi. DevOps sangat terkait dengan konsep transformasi digital. Namun seperti yang sering terjadi pada terminologi TI, selama sepuluh tahun terakhir DevOps telah memperoleh banyak definisi, interpretasi, dan kesalahpahaman tentang dirinya sendiri.
Oleh karena itu, Anda sering mendengar pertanyaan tentang DevOps seperti, apakah sama dengan agile? Atau apakah ini metodologi khusus? Ataukah itu hanya sinonim lain dari kata “kolaborasi”?
DevOps mencakup banyak konsep berbeda (pengiriman berkelanjutan, integrasi berkelanjutan, otomatisasi, dll.), sehingga menyaring hal-hal penting dapat menjadi tantangan, terutama jika Anda tertarik dengan subjek tersebut. Namun, keterampilan ini sangat berguna, tidak peduli apakah Anda mencoba menyampaikan ide Anda kepada atasan Anda atau sekadar memberi tahu seseorang dari keluarga atau teman Anda tentang pekerjaan Anda. Oleh karena itu, mari kita kesampingkan nuansa terminologis DevOps untuk saat ini dan fokus pada gambaran besarnya.
Apa itu DevOps: 6 Definisi dan Analogi
Kami meminta para ahli untuk menjelaskan esensi DevOps sesederhana dan sesingkat mungkin sehingga nilainya menjadi jelas bagi pembaca dengan tingkat pengetahuan teknis apa pun. Berdasarkan hasil percakapan ini, kami telah memilih analogi dan formulasi paling mencolok yang akan membantu Anda membangun cerita Anda tentang DevOps.
1. DevOps adalah gerakan budaya
“DevOps adalah gerakan budaya di mana kedua belah pihak (pengembang perangkat lunak dan spesialis pengoperasian sistem TI) menyadari bahwa perangkat lunak tidak memberikan manfaat nyata sampai seseorang mulai menggunakannya: pelanggan, klien, karyawan, bukan itu intinya,” kata Eveline Oehrlich, peneliti senior analis di DevOps Institute. “Oleh karena itu, kedua pihak bersama-sama memastikan pengiriman perangkat lunak yang cepat dan berkualitas tinggi.”
2. DevOps adalah tentang memberdayakan pengembang.
“DevOps memberdayakan pengembang untuk memiliki aplikasi, menjalankannya, dan mengelola pengiriman dari awal hingga akhir.”
“Biasanya, DevOps dibicarakan sebagai cara untuk mempercepat pengiriman aplikasi ke produksi dengan membangun dan menerapkan proses otomatis,” kata Jai Schniepp, direktur platform DevOps di perusahaan asuransi Liberty Mutual. “Tetapi bagi saya itu adalah hal yang jauh lebih mendasar.” DevOps memberdayakan pengembang untuk memiliki aplikasi atau perangkat lunak tertentu, menjalankannya, dan mengelola pengirimannya dari awal hingga akhir. DevOps menghilangkan kebingungan tanggung jawab dan memandu semua orang yang terlibat dalam menciptakan infrastruktur otomatis yang digerakkan oleh pengembang.”
3. DevOps adalah tentang kolaborasi dalam pembuatan dan penyampaian aplikasi.
“Sederhananya, DevOps adalah pendekatan produksi dan pengiriman perangkat lunak di mana semua orang bekerja bersama,” kata Gur Staf, presiden dan kepala otomasi bisnis digital di BMC.
4. DevOps adalah sebuah saluran
“Perakitan konveyor hanya dapat dilakukan jika semua bagiannya cocok satu sama lain.”
“Saya akan membandingkan DevOps dengan jalur perakitan mobil,” lanjut Staf Gur. – Idenya adalah merancang dan membuat semua bagian terlebih dahulu sehingga dapat dirakit tanpa penyesuaian individual. Perakitan konveyor hanya dapat dilakukan jika semua bagian dipasangkan. Mereka yang merancang dan membuat mesin harus mempertimbangkan cara memasangnya ke bodi atau rangka. Yang bikin rem pasti mikir soal roda, dan sebagainya. Hal yang sama juga berlaku pada perangkat lunak.
Pengembang yang membuat logika bisnis atau antarmuka pengguna harus memikirkan tentang database yang menyimpan informasi pelanggan, langkah-langkah keamanan untuk melindungi data pengguna, dan bagaimana semua ini akan bekerja ketika layanan mulai melayani audiens pengguna yang besar, bahkan mungkin bernilai jutaan dolar. ."
“Mendorong orang-orang untuk berkolaborasi dan memikirkan bagian-bagian pekerjaan yang dilakukan orang lain, daripada hanya berfokus pada tugas mereka sendiri, merupakan hambatan terbesar yang harus diatasi. Jika Anda dapat melakukan ini, Anda memiliki peluang besar untuk melakukan transformasi digital,” tambah Staf Gur.
5. DevOps adalah kombinasi yang tepat antara manusia, proses, dan otomatisasi
Jayne Groll, direktur eksekutif DevOps Institute, menawarkan analogi yang bagus untuk menjelaskan DevOps. Dalam kata-katanya, “DevOps seperti resep dengan tiga kategori bahan utama: manusia, proses, dan otomatisasi. Sebagian besar bahan-bahan ini dapat diambil dari bidang dan sumber lain: Lean, Agile, SRE, CI/CD, ITIL, kepemimpinan, budaya, alat. Rahasia DevOps, seperti resep bagus lainnya, adalah bagaimana mendapatkan proporsi yang tepat dan memadukan bahan-bahan ini untuk meningkatkan kecepatan dan efisiensi dalam membuat dan merilis aplikasi.”
6. DevOps adalah saat programmer bekerja seperti tim Formula 1
“Balapan tidak direncanakan dari awal hingga akhir, namun sebaliknya, dari akhir hingga awal.”
“Ketika saya berbicara tentang apa yang diharapkan dari inisiatif DevOps, saya memikirkan tim balap NASCAR atau Formula 1 sebagai contohnya,” kata Chris Short, manajer senior pemasaran platform cloud di Red Hat dan penerbit buletin DevOps. – Pemimpin tim tersebut memiliki satu tujuan: meraih posisi setinggi mungkin di akhir perlombaan, dengan mempertimbangkan sumber daya yang tersedia untuk tim dan tantangan yang menimpanya. Dalam hal ini perlombaan direncanakan bukan dari awal sampai akhir, melainkan sebaliknya, dari akhir sampai awal. Pertama, tujuan yang ambisius ditetapkan, dan kemudian cara untuk mencapainya ditentukan. Kemudian mereka dipecah menjadi subtugas dan didelegasikan kepada anggota tim.”
“Tim menghabiskan seminggu penuh sebelum balapan untuk menyempurnakan pit stop. Dia melakukan latihan kekuatan dan kardio agar tetap bugar untuk hari perlombaan yang melelahkan. Berlatih bekerja sama untuk menyelesaikan setiap masalah yang mungkin timbul saat lomba. Demikian pula, tim pengembangan harus melatih keterampilan untuk sering merilis versi baru. Jika Anda memiliki keterampilan dan sistem keamanan yang berfungsi dengan baik, peluncuran versi baru ke dalam produksi juga lebih sering terjadi. Dalam pandangan dunia ini, peningkatan kecepatan berarti peningkatan keselamatan,” kata Short.
“Ini bukan tentang melakukan 'hal yang benar',” Short menambahkan, “ini tentang menghilangkan sebanyak mungkin hal yang menghalangi hasil yang diinginkan. Berkolaborasi dan beradaptasi berdasarkan masukan yang Anda terima secara real time. Bersiaplah menghadapi anomali dan berupaya meningkatkan kualitas guna meminimalkan dampaknya terhadap kemajuan menuju tujuan Anda. Inilah yang menanti kita di dunia DevOps.”
Cara menskalakan DevOps: 10 tips dari para ahli
Hanya saja DevOps dan DevOps massal adalah hal yang sangat berbeda. Kami akan memberi tahu Anda cara mengatasi hambatan dari yang pertama ke yang kedua.
Bagi banyak organisasi, perjalanan menuju DevOps dimulai dengan mudah dan menyenangkan. Tim kecil yang penuh semangat diciptakan, proses lama diganti dengan yang baru, dan kesuksesan pertama tidak lama lagi akan datang.
Sayangnya, ini hanyalah kemewahan palsu, ilusi kemajuan, kata Ben Grinnell, direktur pelaksana dan kepala digital di konsultan North Highland. Kemenangan awal tentu saja menggembirakan, namun tidak membantu mencapai tujuan akhir yaitu adopsi DevOps secara luas di seluruh organisasi.
Sangat mudah untuk melihat bahwa akibatnya adalah budaya perpecahan antara “kita” dan “mereka”.
“Seringkali, organisasi meluncurkan proyek perintis ini dengan pemikiran bahwa mereka akan membuka jalan bagi DevOps arus utama, tanpa mempertimbangkan apakah pihak lain akan mampu atau bersedia mengikuti jalur tersebut,” jelas Ben Grinnell. – Tim untuk melaksanakan proyek semacam itu biasanya direkrut dari “Varangia” yang percaya diri yang telah melakukan hal serupa di tempat lain, tetapi masih baru di organisasi Anda. Pada saat yang sama, mereka didorong untuk melanggar dan menghancurkan peraturan yang tetap mengikat orang lain. Sangat mudah untuk melihat bahwa akibatnya adalah budaya “kita” dan “mereka” yang menghambat transfer pengetahuan dan keterampilan.”
“Dan masalah budaya ini hanyalah salah satu alasan mengapa DevOps sulit untuk diukur. Tim DevOps menghadapi peningkatan tantangan teknis yang biasa terjadi pada perusahaan IT yang berkembang pesat,” kata Steve Newman, pendiri dan ketua Scalyr.
“Di dunia modern, layanan berubah begitu diperlukan. Sangat menyenangkan untuk terus menerapkan dan mengimplementasikan fitur-fitur baru, tetapi mengoordinasikan proses ini dan menghilangkan masalah yang muncul benar-benar memusingkan, tambah Steve Newman. – Dalam organisasi yang berkembang sangat pesat, para insinyur di tim lintas fungsi berjuang untuk mempertahankan visibilitas terhadap perubahan dan dampak tingkat ketergantungan yang ditimbulkannya. Selain itu, para insinyur tidak senang ketika mereka kehilangan kesempatan ini dan, akibatnya, semakin sulit bagi mereka untuk memahami inti permasalahan yang muncul.”
Bagaimana cara mengatasi tantangan yang dijelaskan di atas dan beralih ke adopsi DevOps secara massal di organisasi besar? Para ahli mendesak agar Anda bersabar, meskipun tujuan akhir Anda adalah mempercepat siklus pengembangan perangkat lunak dan proses bisnis Anda.
1. Ingatlah bahwa perubahan budaya membutuhkan waktu.
Jayne Groll, Direktur Eksekutif, DevOps Institute: “Menurut pendapat saya, perluasan DevOps harus dilakukan secara bertahap dan berulang seperti pengembangan tangkas (dan sama-sama menyentuh budaya). Agile dan DevOps menekankan tim kecil. Namun seiring bertambahnya jumlah dan integrasi tim-tim ini, semakin banyak orang yang mengadopsi cara kerja baru, dan sebagai hasilnya terjadi transformasi budaya secara besar-besaran.”
2. Luangkan cukup waktu untuk merencanakan dan memilih platform
Eran Kinsbruner, Penginjil Teknis Utama di Perfecto: “Agar penskalaan berhasil, tim DevOps pertama-tama harus belajar menggabungkan proses, alat, dan keterampilan tradisional, lalu perlahan-lahan memelihara dan menstabilkan setiap fase DevOps. Semuanya dimulai dengan perencanaan yang cermat atas cerita pengguna dan aliran nilai, diikuti dengan penulisan perangkat lunak dan kontrol versi menggunakan pengembangan berbasis trunk atau pendekatan lain yang paling cocok untuk percabangan dan penggabungan kode.”
“Kemudian tibalah tahap integrasi dan pengujian, yang mana platform scalable untuk otomatisasi sudah diperlukan. Di sinilah penting bagi tim DevOps untuk memilih platform yang tepat yang sesuai dengan tingkat keahlian mereka dan tujuan akhir proyek.
Fase selanjutnya adalah penerapan ke produksi dan ini harus sepenuhnya diotomatisasi menggunakan alat orkestrasi dan container. Penting untuk memiliki lingkungan tervirtualisasi di semua tahap DevOps (simulator produksi, lingkungan QA, dan lingkungan produksi aktual) dan selalu hanya menggunakan data terbaru untuk pengujian guna mendapatkan kesimpulan yang relevan. Analytics harus cerdas dan mampu memproses data besar dengan umpan balik yang cepat dan dapat ditindaklanjuti.”
3. Hilangkan rasa bersalah dari tanggung jawab.
Gordon Haff, Penginjil RedHat: “Menciptakan sistem dan suasana yang memungkinkan dan mendorong eksperimen memungkinkan terjadinya apa yang dikenal sebagai kegagalan sukses dalam pengembangan perangkat lunak tangkas. Ini tidak berarti bahwa tidak ada orang lain yang bertanggung jawab atas kegagalan. Faktanya, mengidentifikasi siapa yang bertanggung jawab menjadi lebih mudah, karena “bertanggung jawab” tidak lagi berarti “menyebabkan kecelakaan”. Artinya, esensi tanggung jawab berubah secara kualitatif. Ada empat faktor yang menjadi penting: tingkat gangguan, pendekatan, proses produksi, dan insentif.” (Anda dapat membaca lebih lanjut tentang faktor-faktor ini dalam artikel Gordon Huff “Pelajaran DevOps: 4 aspek eksperimen yang sehat.”)
4. Bersihkan jalan ke depan
Ben Grinnell, direktur pelaksana dan kepala digital di konsultan North Highland: “Untuk mencapai skala, saya merekomendasikan peluncuran program “pembersihan jalur” bersama dengan proyek perintis. Tujuan dari program ini adalah untuk membersihkan sampah yang ditinggalkan oleh para pionir DevOps, seperti peraturan yang sudah ketinggalan zaman dan sejenisnya, sehingga jalan ke depannya tetap jelas.”
“Berikan dukungan dan momentum organisasi kepada masyarakat melalui komunikasi yang melampaui kelompok perintis dengan merayakan keberhasilan cara kerja baru secara luas. Latih orang-orang yang terlibat dalam proyek DevOps gelombang berikutnya dan merasa gugup saat menggunakan DevOps untuk pertama kalinya. Dan ingatlah bahwa orang-orang ini sangat berbeda dengan para pionir.”
5. Mendemokratisasikan alat
Steve Newman, pendiri dan ketua Scalyr: “Alat tidak boleh disembunyikan dari orang lain, dan alat tersebut harus relatif mudah dipelajari oleh siapa pun yang mau meluangkan waktu. Jika kemampuan untuk menanyakan log dibatasi pada tiga orang yang "bersertifikat" untuk menggunakan suatu alat, Anda akan selalu memiliki maksimal tiga orang yang tersedia untuk menangani masalah tersebut, bahkan jika Anda memiliki lingkungan komputasi yang sangat besar. Dengan kata lain, ada hambatan di sini yang dapat menimbulkan konsekuensi (bisnis) yang serius.”
6. Ciptakan kondisi ideal untuk kerja tim
Tom Clark, kepala Platform Umum di ITV: “Anda bisa melakukan apa saja, tapi tidak semuanya sekaligus. Jadi tetapkan tujuan besar, mulai dari yang kecil, dan maju terus secara cepat. Seiring waktu, Anda akan mengembangkan reputasi dalam menyelesaikan sesuatu, sehingga orang lain juga ingin menggunakan metode Anda. Dan jangan khawatir tentang membangun tim yang sangat efektif. Sebaliknya, sediakan kondisi kerja yang ideal bagi masyarakat dan efisiensi pun akan terjadi.”
7. Jangan lupa tentang Hukum Conway dan papan Kanban
Logan Daigle, Direktur Pengiriman Perangkat Lunak dan Strategi DevOps di CollabNetVersionOne: “Penting untuk memahami konsekuensi dari Hukum Conway. Dalam uraian saya yang longgar, undang-undang ini menyatakan bahwa produk yang kami buat dan proses yang kami gunakan untuk melakukannya, termasuk DevOps, ternyata terstruktur dengan cara yang sama seperti organisasi kami.”
“Jika ada banyak silo dalam suatu organisasi, dan kendali berpindah tangan berkali-kali ketika merencanakan, membangun, dan merilis perangkat lunak, efek penskalaan akan menjadi nol atau berumur pendek. Jika sebuah organisasi membangun tim lintas fungsi seputar produk yang didanai dengan fokus pasar, maka peluang keberhasilannya akan meningkat secara dramatis.”
“Aspek penting lainnya dari penskalaan adalah menampilkan semua pekerjaan yang sedang berjalan (WIP, kemajuan pekerjaan) di papan Kanban. Ketika sebuah organisasi memiliki tempat di mana orang-orang dapat melihat hal-hal ini, hal ini akan sangat mendorong kolaborasi, yang berdampak positif pada peningkatan skala.”
8. Carilah bekas luka lama
Manuel Pais, konsultan DevOps dan salah satu penulis Team Topologies: “Mengambil praktik DevOps di luar Dev dan Ops itu sendiri dan mencoba menerapkannya pada fungsi lain bukanlah pendekatan yang optimal. Hal ini tentu saja akan memberikan dampak tertentu (misalnya, dengan mengotomatiskan kontrol manual), namun lebih banyak hal yang dapat dicapai jika kita mulai dengan memahami proses penyampaian dan umpan balik.”
“Jika ada bekas luka lama dalam sistem TI suatu organisasi – prosedur dan mekanisme manajemen yang diterapkan sebagai akibat dari kejadian di masa lalu, namun telah kehilangan relevansinya (karena perubahan produk, teknologi, atau proses) – maka hal tersebut tentu perlu dihilangkan. atau diperhalus, daripada mengotomatiskan proses yang tidak efisien atau tidak perlu.”
9. Jangan membiakkan opsi DevOps
Anthony Edwards, Direktur Operasi di Terong: “DevOps adalah istilah yang sangat kabur, sehingga setiap tim memiliki versi DevOpsnya sendiri. Dan tidak ada yang lebih buruk ketika sebuah organisasi tiba-tiba memiliki 20 jenis DevOps yang tidak dapat digabungkan dengan baik. Tidak mungkin masing-masing dari ketiga tim pengembangan memiliki antarmuka khusus antara pengembangan dan manajemen produk. Produk juga tidak boleh memiliki ekspektasi uniknya sendiri dalam menangani umpan balik saat ditransfer ke simulator produksi. Jika tidak, Anda tidak akan pernah bisa menskalakan DevOps.”
10. Memberitakan nilai bisnis DevOps
Steve Newman, pendiri dan ketua Scalyr: “Berusahalah untuk menyadari nilai DevOps. Pelajari dan jangan ragu untuk berbicara tentang manfaat dari apa yang Anda lakukan. DevOps sangat menghemat waktu dan uang (bayangkan saja: waktu henti yang lebih sedikit, waktu pemulihan yang lebih singkat), dan tim DevOps harus tanpa lelah menekankan (dan mengajarkan) pentingnya inisiatif ini untuk kesuksesan bisnis. Dengan cara ini Anda dapat memperluas lingkaran pengikut dan meningkatkan pengaruh DevOps dalam organisasi.”
BONUS
Pada DevOps kami sendiri akan hadir pada 13 September - ya, Red Hat, sebagai produsen perangkat lunak, memiliki tim dan praktik DevOps sendiri.
Insinyur kami Mark Birger, yang mengembangkan layanan otomatisasi internal untuk grup lain di seluruh organisasi, akan menceritakan kisahnya sendiri dalam bahasa Rusia murni - bagaimana tim Red Hat DevOps memigrasikan aplikasi dari lingkungan virtual Hat Virtualization yang dikelola oleh Ansible ke format container lengkap di platform OpenShift.
Tapi itu tidak semua:
Setelah organisasi memindahkan beban kerja ke container, metode pemantauan aplikasi tradisional mungkin tidak berfungsi. Pada pembicaraan kedua kami akan menjelaskan motivasi kami untuk mengubah cara kami melakukan pencatatan dan menunjukkan kelanjutan dari jalur yang membawa kami pada metode pencatatan dan pemantauan modern.
Sumber: www.habr.com