Apakah sulit untuk memahami intinya ketika berbicara tentang DevOps? Kami telah mengumpulkan untuk Anda analogi yang jelas, formulasi perkusi dan saran ahli yang akan membantu bahkan non-spesialis untuk sampai ke titik. Pada akhirnya, bonusnya adalah DevOps milik Red Hat sendiri.
Istilah DevOps muncul 10 tahun yang lalu dan berubah dari hashtag di Twitter menjadi gerakan budaya yang kuat di dunia IT, sebuah filosofi sejati yang mendorong pengembang untuk mencapai hasil lebih cepat, bereksperimen dan bergerak maju menggunakan metode iterasi. DevOps telah menjadi terkait erat dengan konsep transformasi digital. Tetapi seperti yang sering terjadi dengan terminologi IT, lebih dari satu dekade, DevOps telah berhasil memperoleh banyak definisi, interpretasi, dan kesalahpahaman.
Karena itu, tentang DevOps Anda sering dapat mendengar pertanyaan seperti, apakah itu sama dengan gesit? Atau apakah ini semacam metodologi khusus? Atau hanya sinonim untuk kata "kolaborasi"?
DevOps mencakup banyak konsep berbeda (pengiriman terus-menerus, integrasi berkelanjutan, otomatisasi, dll.), Sehingga mengisolasi hal utama dapat menjadi sulit, terutama ketika Anda tidak menyukai subjek. Namun, keterampilan ini sangat berguna, tidak masalah jika Anda mencoba menyampaikan ide Anda kepada atasan Anda atau hanya memberi tahu kerabat atau teman Anda tentang pekerjaan Anda. Karena itu, untuk saat ini, kesampingkan nuansa terminologis DevOps dan fokus pada gambaran besar.
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 pelatihan teknis apa pun. Berdasarkan hasil percakapan ini, kami memilih analogi dan perkusi 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) mengakui bahwa perangkat lunak tidak membawa manfaat nyata sampai seseorang mulai menggunakannya: pelanggan, pelanggan, karyawan, bukan itu intinya, kata Eveline Oehrlich, analis senior di DevOps Institute. "Oleh karena itu, kedua pihak ini bersama-sama menyediakan pengiriman perangkat lunak yang cepat dan berkualitas tinggi."
2. DevOps adalah yang memberdayakan pengembang
“DevOps memberdayakan pengembang dengan kepemilikan aplikasi, peluncuran dan manajemen pengiriman mereka dari awal hingga akhir”"DevOps biasanya disebut sebagai cara untuk mempercepat pengiriman aplikasi ke produksi dengan membangun dan menerapkan proses otomatis," kata Jai Schniepp, direktur platform DevOps di Liberty Mutual. "Tapi bagiku itu adalah hal yang jauh lebih mendasar." DevOps memberi pengembang wewenang untuk memiliki aplikasi atau bagian tertentu dari perangkat lunak, meluncurkannya dan mengelola pengiriman dari awal hingga selesai. DevOps menghilangkan kebingungan akan tanggung jawab dan mengarahkan semua peserta dalam proses untuk menciptakan infrastruktur otomatis dan digerakkan oleh pengembang. "
3. DevOps adalah kolaborasi dalam pembuatan dan pengiriman aplikasi
"Sederhananya, DevOps adalah pendekatan untuk produksi dan pengiriman perangkat lunak ketika semua orang bekerja bersama," kata Gur Staf, Presiden dan Kepala Digital Business Automation di BMC.
4. DevOps adalah saluran pipa
"Perakitan konveyor hanya mungkin jika semua bagian saling cocok.""Saya akan membandingkan DevOps dengan jalur perakitan mobil," lanjut Gur Staf. - Idenya adalah untuk pra-desain dan membuat semua detail sehingga nantinya mereka dapat dirakit tanpa kecocokan individu. Perakitan konveyor hanya dimungkinkan jika semua bagian saling bersesuaian. Mereka yang merancang dan membuat mesin harus mempertimbangkan cara memasangnya ke bodi atau rangka. Mereka yang membuat rem harus memikirkan roda, dan sebagainya. Seharusnya sama dengan perangkat lunak.
Pengembang yang membuat logika bisnis atau antarmuka pengguna harus berpikir tentang database yang menyimpan informasi tentang pelanggan, tentang langkah-langkah keamanan untuk melindungi data pengguna, dan bagaimana itu akan bekerja ketika layanan mulai melayani banyak, mungkin bahkan multi-juta audiens pengguna. "
“Untuk membuat orang bekerja sama dan memikirkan bagian-bagian pekerjaan yang dilakukan oleh orang lain, dan tidak fokus hanya pada tugas mereka sendiri - ini adalah kendala terbesar yang harus diatasi. Jika berhasil, Anda memiliki peluang bagus untuk transformasi digital, ”tambah Gur Staf.
5. DevOps adalah kombinasi yang tepat dari orang, proses dan otomatisasi
Jayne Groll, Direktur Eksekutif DevOps Institute, menawarkan analogi yang bagus untuk menjelaskan DevOps. Menurutnya, “DevOps seperti resep kuliner di mana ada tiga kategori utama bahan: orang, proses, dan otomatisasi. Sebagian besar bahan ini dapat diambil dari area dan sumber lain: Lean, Agile, SRE, CI / CD, ITIL, kepemimpinan, budaya, alat. Rahasia DevOps, serta resep yang bagus, adalah bagaimana memilih proporsi yang tepat dan mencampur bahan-bahan ini untuk meningkatkan kecepatan dan efektivitas kerja saat membuat dan merilis aplikasi. "
6. DevOps - ini adalah saat programmer bekerja sebagai tim Formula 1
"Perlombaan ini direncanakan bukan dari awal hingga akhir, tetapi dari awal hingga awal.""Berbicara tentang apa yang diharapkan dari inisiatif DevOps, saya akan mengutip NASCAR atau tim balap Formula 1 sebagai contoh," kata Chris Short, general manager pemasaran cloud untuk Red Hat dan penerbit milis DevOps. - Kepala tim semacam itu memiliki satu tujuan: untuk mengambil tempat semaksimal mungkin sesuai dengan hasil lomba, dengan mempertimbangkan sumber daya yang tersedia untuk tim dan uji coba yang jatuh ke bagiannya. Selain itu, balapan tidak direncanakan dari awal hingga selesai, melainkan dari awal hingga awal. Tujuan ambisius pertama kali ditetapkan, dan kemudian cara untuk mencapainya ditentukan. Kemudian mereka dibagi menjadi beberapa subtugas dan didelegasikan kepada anggota tim. "
“Sepanjang minggu sebelum perlombaan, tim mengasah pit stop. Dia terlibat dalam pelatihan kekuatan dan kardio untuk menjadi bugar pada hari perlombaan yang melelahkan. Dia melakukan aksi bersama untuk memecahkan masalah yang mungkin timbul dalam lomba. Demikian pula, tim pengembangan harus melatih keterampilan untuk sering merilis versi baru. Dengan keterampilan seperti itu dan sistem keamanan yang berfungsi dengan baik, meluncurkan versi baru dalam produksi juga lebih sering terjadi. Dalam pandangan dunia ini, peningkatan kecepatan berarti peningkatan keamanan, ”kata Short.
“Intinya bukan untuk melakukan“ hal yang benar, ”Short menambahkan,“ tetapi untuk menghilangkan sebanyak mungkin hal yang menghalangi hasil yang diinginkan. Berkolaborasi dan beradaptasi berdasarkan umpan balik yang Anda terima secara real time. Bersiaplah untuk anomali dan bekerja untuk meningkatkan kualitas untuk meminimalkan dampaknya pada gerakan menuju tujuan. Itulah yang menanti kita di dunia DevOps. ”
Cara Mengatur Skala DevOps: 10 Tips Ahli
Hanya DevOps dan DevOps besar adalah dua hal yang sangat berbeda. Kami akan memberi tahu Anda cara mengatasi hambatan dari yang pertama hingga yang kedua.Bagi banyak organisasi, jalan menuju DevOps dimulai dengan mudah dan baik. Tim kecil yang bersemangat diciptakan, proses lama digantikan oleh yang baru dan kesuksesan pertama tidak lama datang.
Sayangnya, ini hanya kilau palsu, ilusi kemajuan, menurut Ben Grinnell, direktur pelaksana dan kepala teknologi digital di perusahaan konsultan North Highland. Kemenangan awal tentu menggembirakan, tetapi tidak membantu mencapai tujuan akhir, yaitu, penggunaan besar-besaran DevOps dalam organisasi.
Mudah untuk melihat bahwa sebagai hasilnya, budaya pemisahan menjadi "kita" dan "mereka" terbentuk."Seringkali, organisasi meluncurkan proyek perintis seperti itu, percaya bahwa mereka akan membuka jalan bagi DevOps massal, tanpa ragu, mereka dapat dan akan orang lain ingin pergi dengan cara ini," jelas Ben Grinnel. - Tim untuk implementasi proyek seperti itu biasanya direkrut dari “Viking” yang percaya diri yang telah melakukan hal serupa di tempat lain, tetapi baru di organisasi Anda. Pada saat yang sama, mereka didorong untuk melanggar dan menghancurkan aturan yang tetap mengikat orang lain. Mudah untuk melihat bahwa sebagai hasilnya, budaya pemisahan menjadi "kita" dan "mereka" terbentuk, yang mencegah transfer pengetahuan dan keterampilan. "
“Dan masalah budaya ini hanyalah salah satu alasan mengapa DevOps sulit untuk diukur. Tim DevOps dihadapkan dengan pertumbuhan kesulitan teknis murni karakteristik perusahaan yang tumbuh cepat yang mengandalkan teknologi IT, ”kata Steve Newman, pendiri dan ketua dewan di Scalyr.
“Di dunia modern, layanan berubah segera setelah kebutuhan seperti itu muncul. Terus menerapkan dan mengimplementasikan fitur-fitur baru tentu saja bagus, tetapi mengoordinasikan proses ini dan memperbaiki masalah adalah sakit kepala yang nyata, ”tambah Steve Newman. - Dalam organisasi yang tumbuh sangat cepat, para insinyur sebagai bagian dari tim lintas fungsi berjuang untuk mempertahankan kemampuan untuk melacak perubahan dan efek berjenjang yang mereka hasilkan pada tingkat ketergantungan. Terlebih lagi, para insinyur sama sekali tidak bahagia ketika mereka kehilangan kesempatan seperti itu dan sebagai akibatnya menjadi lebih sulit bagi mereka untuk memahami esensi dari masalah yang muncul. "
Bagaimana mengatasi kesulitan-kesulitan yang dijelaskan di atas dan beralih ke penggunaan besar-besaran DevOps di sebuah organisasi besar? Para ahli mendesak Anda untuk bersabar, bahkan jika tujuan akhir Anda adalah untuk mempercepat siklus pengembangan perangkat lunak dan proses bisnis.1. Ingatlah bahwa perubahan budaya membutuhkan waktu
Jayne Groll, Direktur Eksekutif DevOps Institute: “Menurut saya, ekstensi DevOps harus setahap dan berulang seperti pengembangan tangkas (dan sama-sama memengaruhi budaya). Agile dan DevOps fokus pada tim kecil. Tetapi dengan bertambahnya jumlah dan integrasi tim-tim semacam itu, semakin banyak orang yang menerapkan metode kerja baru, dan sebagai akibatnya, transformasi budaya skala besar muncul. ”
2. Luangkan waktu yang cukup untuk merencanakan dan memilih platform
Eran Kinsbruner, Evangelist Teknis Utama, Perfecto: “Untuk penskalaan untuk bekerja, tim DevOps pertama-tama perlu belajar bagaimana menggabungkan proses, alat dan keterampilan tradisional, dan kemudian perlahan-lahan menumbuhkan setiap fase DevOps individu dan menstabilkannya. Semuanya dimulai dengan perencanaan yang cermat tentang cerita pengguna dan aliran nilai (valuestream), diikuti oleh tahap penulisan perangkat lunak dan kontrol versi menggunakan pengembangan berbasis trunk atau pendekatan lain yang paling cocok untuk percabangan dan penggabungan kode. "
“Kemudian datang tahap integrasi dan pengujian, di mana platform otomatisasi yang dapat diskalakan sudah diperlukan. Dan di sini penting bagi tim DevOps untuk memilih platform yang tepat yang memenuhi tingkat keahlian mereka dan tujuan akhir proyek.
Fase berikutnya adalah penyebaran di lingkungan produksi, dan harus sepenuhnya otomatis menggunakan alat dan wadah orkestrasi. Pada saat yang sama, penting untuk memiliki lingkungan tervirtualisasi pada semua tahap DevOps (simulator lingkungan produksi, lingkungan kontrol kualitas dan, pada kenyataannya, lingkungan produksi) dan selalu menggunakan hanya data terbaru untuk pengujian untuk mendapatkan kesimpulan yang relevan. Analytics harus pintar dan mampu memproses data besar dengan umpan balik yang cepat dan efisien. "
3. Singkirkan rasa bersalah
Gordon Haff, penginjil RedHat: “Menciptakan sistem dan suasana yang memungkinkan dan mendorong eksperimen memungkinkan kita untuk menyadari apa yang disebut kegagalan sukses dalam pengembangan perangkat lunak yang gesit. Ini tidak berarti bahwa tidak ada orang lain yang bertanggung jawab atas kegagalan tersebut. Bahkan, menjadi lebih mudah untuk membentuk orang yang bertanggung jawab, karena "menjadi bertanggung jawab" tidak lagi berarti "menjadi penyebab kecelakaan." Artinya, esensi tanggung jawab berubah secara kualitatif. Dalam hal ini, empat faktor menjadi sangat penting: skala kegagalan, pendekatan, proses produksi, dan insentif. ” (Untuk lebih lanjut tentang faktor-faktor ini, lihat pelajaran DevOps Gordon Huff: 4 aspek percobaan sehat.)
4. Bersihkan jalan ke depan
Ben Grinnell, Direktur Pelaksana dan Kepala Teknologi Digital, North Highland Consulting: “Untuk meningkatkan, saya merekomendasikan agar program Pathfinder diluncurkan bersama dengan proyek perintis. Tujuan dari program ini adalah untuk membersihkan sampah yang tersisa dengan pelopor DevOps, seperti aturan yang telah kehilangan relevansi dan hal-hal serupa lainnya, sehingga jalan ke depan tetap jelas. "
”Berikan dukungan organisasi kepada orang-orang dan berikan dorongan melalui komunikasi yang jauh melampaui kelompok perintis, yang merayakan keberhasilan metode kerja baru. Latih orang-orang yang terlibat dalam gelombang proyek DevOps berikutnya dan gugup menggunakan DevOps untuk pertama kalinya. Dan ingatlah bahwa orang-orang ini sangat berbeda dari para perintis. ”
5. Jadikan alat lebih demokratis
Steve Newman, pendiri dan ketua Scalyr: “Alat tidak boleh disembunyikan dari orang, dan itu harus relatif mudah dipelajari bagi siapa saja yang bersedia meluangkan waktu untuk hal ini. Jika kemampuan untuk meminta log disediakan hanya untuk tiga orang yang "bersertifikat" untuk bekerja dengan beberapa jenis alat, Anda akan selalu memiliki maksimal tiga orang yang dapat menangani masalah terkait, bahkan jika Anda memiliki lingkungan komputasi yang sangat besar. Dengan kata lain, kemacetan muncul di sini yang dapat menyebabkan konsekuensi serius (untuk bisnis). "
6. Ciptakan kondisi ideal untuk kerja tim
Tom Clark, Kepala Platform Bersama di ITV: “Anda bisa melakukan apa saja, tetapi tidak sekaligus. Oleh karena itu, tetapkan tujuan besar, mulai dari yang kecil dan bergerak maju dengan iterasi yang cepat. Seiring waktu, Anda akan mendapatkan reputasi sebagai tim yang berhasil, sehingga orang lain juga ingin menggunakan metode Anda. Dan jangan mengejar membangun tim yang sangat efektif. Sebaliknya, memberikan orang-orang dengan kondisi kerja yang ideal dan efisiensi akan datang dengan sendirinya. "
7. Jangan Lupa Conway Law dan Kanban Board
Logan Daigle, CollabNetVersionOne DevOps, Direktur Pengiriman dan Strategi Perangkat Lunak: "Penting untuk memahami konsekuensi dari hukum Conway. Dalam kalimat bebas saya, undang-undang ini menyatakan bahwa produk yang kami buat dan proses yang kami gunakan, termasuk DevOps, ternyata sama dengan organisasi kami. "
“Jika organisasi sangat terfragmentasi, dan ketika merencanakan, membuat, dan merilis perangkat lunak, manajemen berpindah dari tangan ke tangan berkali-kali, efek penskalaan akan menjadi nol atau berumur pendek. Jika organisasi membentuk tim lintas fungsi di sekitar produk yang didanai dengan orientasi pasar, maka peluang keberhasilan meningkat secara dramatis. ”
“Aspek penting lain dari penskalaan adalah untuk menampilkan pada papan kanban semua pekerjaan yang sedang berjalan (WIP, workinprogress). Ketika sebuah organisasi muncul di tempat di mana orang dapat melihat hal-hal seperti itu, itu sangat merangsang kerja sama, yang memiliki efek positif pada penskalaan. ”
8. Cari bekas luka lama
Manuel Pais, Konsultan DevOps, dan salah satu penulis Tim Topologi: “Mengambil praktik DevOps di luar Devi Ops sendiri dan mencoba menerapkannya pada fungsi lain hampir tidak bisa disebut pendekatan optimal. Ini tidak diragukan lagi akan memberikan efek tertentu (misalnya, karena otomatisasi kontrol manual), tetapi lebih banyak yang dapat dicapai jika kita mulai dengan pemahaman tentang proses pengiriman dan umpan balik. "
"Jika ada bekas luka lama dalam sistem TI organisasi - prosedur dan mekanisme manajemen yang diimplementasikan sebagai akibat dari insiden masa lalu, tetapi telah kehilangan relevansinya (karena perubahan dalam produk, teknologi atau proses), maka mereka tentu perlu dihapus atau dihaluskan, dan tidak mengotomatiskan proses yang tidak efisien atau tidak perlu. "
9. Jangan Menanamkan Opsi DevOps
Anthony Edwards, Direktur Produksi Terong: “DevOps adalah istilah yang sangat kabur, sehingga setiap tim memiliki versi DevOps sendiri. Dan tidak ada yang lebih buruk ketika 20 varietas DevOps segera muncul dalam organisasi, yang tidak rukun. Masing-masing dari tiga tim pengembangan tidak dapat memiliki antarmuka khusus antara pengembangan dan manajemen produk. Karena tidak mungkin bagi produk untuk memiliki harapan mereka sendiri yang unik terkait pemrosesan umpan balik ketika mentransfer lingkungan produksi ke simulator. Jika tidak, Anda tidak akan pernah bisa mengukur DevOps. "
10. Mengkhotbahkan nilai DevOps untuk bisnis
Steve Newman, Pendiri dan Ketua, Scalyr: “Berusahalah mengenali nilai DevOps. Belajar dan merasa bebas untuk berbicara tentang manfaat dari apa yang Anda lakukan. DevOps sangat menghemat waktu dan uang (hanya berpikir: lebih sedikit downtime, rata-rata waktu pemulihan lebih pendek), dan tim DevOps harus tanpa henti menekankan (dan berkhotbah) pentingnya inisiatif ini untuk kesuksesan bisnis. Sehingga Anda dapat memperluas lingkaran penganut dan memperkuat pengaruh DevOps dalam organisasi. "
BONUS
Pada 13 September, DevOps kita sendiri akan tiba di Red Hat Forum Russia - ya, Red Hat, sebagai produsen perangkat lunak, memiliki tim dan praktik DevOps sendiri.Insinyur kami Mark Birger, yang sedang mengembangkan layanan otomasi internal untuk grup lain di seluruh organisasi, menceritakan kisahnya sendiri dalam bahasa Rusia murni - bagaimana tim Red Hat DevOps memigrasi aplikasi dari lingkungan yang dikelola oleh Hat Virtualization dengan Memungkinkan ke dalam format kontainer penuh pada platform OpenShift.
Tapi itu belum semuanya:Setelah organisasi memindahkan beban kerja ke kontainer, metode pemantauan aplikasi tradisional mungkin tidak berfungsi. Dalam laporan kedua, kami akan menjelaskan motivasi kami untuk mengubah metode registrasi dan menunjukkan kelanjutan dari jalan yang membawa kami ke metode jurnal dan pemantauan modern.