Adakah sukar untuk memahami perkara utama apabila bercakap tentang DevOps? Kami telah mengumpulkan analogi yang jelas untuk anda, formulasi yang menarik dan nasihat daripada pakar yang akan membantu walaupun bukan pakar untuk memahami perkara ini. Pada akhirnya, bonus adalah DevOps milik pekerja Red Hat.
Istilah DevOps berasal 10 tahun yang lalu dan telah bertukar daripada hashtag Twitter kepada pergerakan budaya yang kuat dalam dunia IT, falsafah sebenar yang menggalakkan pembangun untuk menyelesaikan sesuatu dengan lebih pantas, bereksperimen dan bergerak ke hadapan. DevOps telah menjadi berkait rapat dengan konsep transformasi digital. Tetapi seperti yang sering berlaku dengan terminologi IT, sejak sepuluh tahun yang lalu DevOps telah memperoleh banyak definisi, tafsiran dan salah tanggapan tentang dirinya.
Oleh itu, anda sering mendengar soalan tentang DevOps seperti, adakah ia sama dengan tangkas? Atau adakah ini metodologi khas? Atau adakah ia hanya sinonim lain untuk perkataan "kerjasama"?
DevOps merangkumi banyak konsep yang berbeza (penyampaian berterusan, penyepaduan berterusan, automasi, dll.), jadi menyaring perkara yang penting boleh menjadi mencabar, terutamanya apabila anda berminat dengan subjek itu. Walau bagaimanapun, kemahiran ini sangat berguna, tidak kira sama ada anda cuba menyampaikan idea anda kepada atasan anda atau sekadar memberitahu seseorang daripada keluarga atau rakan anda tentang kerja anda. Oleh itu, mari kita ketepikan nuansa terminologi DevOps buat masa ini dan fokus pada gambaran besar.
Apakah itu DevOps: 6 Definisi dan Analogi
Kami meminta pakar untuk menerangkan intipati DevOps semudah dan sesingkat mungkin supaya nilainya menjadi jelas kepada pembaca yang mempunyai sebarang tahap pengetahuan teknikal. Berdasarkan hasil perbualan ini, kami telah memilih analogi dan formulasi yang paling menarik yang akan membantu anda membina cerita anda tentang DevOps.
1. DevOps ialah gerakan budaya
"DevOps ialah pergerakan budaya di mana kedua-dua pihak (pembangun perisian dan pakar operasi sistem IT) menyedari bahawa perisian tidak membawa faedah sebenar sehingga seseorang mula menggunakannya: pelanggan, pelanggan, pekerja, bukan intinya," kata Eveline Oehrlich, penyelidik kanan penganalisis di Institut DevOps. "Oleh itu, kedua-dua pihak ini bersama-sama memastikan penghantaran perisian yang cepat dan berkualiti tinggi."
2. DevOps adalah tentang memperkasakan pembangun.
"DevOps memperkasakan pembangun untuk memiliki aplikasi, menjalankannya dan mengurus penghantaran dari awal hingga akhir."
"Biasanya, DevOps dibincangkan sebagai cara untuk mempercepatkan penghantaran aplikasi kepada pengeluaran dengan membina dan melaksanakan proses automatik," kata Jai Schniepp, pengarah platform DevOps di syarikat insurans Liberty Mutual. "Tetapi bagi saya ia adalah perkara yang lebih asas." DevOps memperkasakan pembangun untuk memiliki aplikasi atau perisian tertentu, menjalankannya dan mengurus penghantaran mereka dari awal hingga akhir. DevOps menghapuskan kekeliruan tanggungjawab dan membimbing semua orang yang terlibat dalam mencipta infrastruktur yang didorong oleh pembangun secara automatik."
3. DevOps adalah mengenai kerjasama dalam mencipta dan menyampaikan aplikasi.
"Ringkasnya, DevOps ialah pendekatan kepada pengeluaran dan penyampaian perisian di mana semua orang bekerjasama," kata Gur Staf, presiden dan ketua automasi perniagaan digital di BMC.
4. DevOps ialah saluran paip
"Pemasangan penghantar hanya boleh dilakukan jika semua bahagian sesuai bersama."
"Saya akan membandingkan DevOps dengan barisan pemasangan kereta," sambung Staf Gur. – Ideanya adalah untuk mereka bentuk dan membuat semua bahagian terlebih dahulu supaya ia kemudiannya boleh dipasang tanpa pelarasan individu. Pemasangan penghantar hanya boleh dilakukan jika semua bahagian sesuai bersama. Mereka yang mereka bentuk dan membina enjin mesti mempertimbangkan cara memasangnya pada badan atau bingkai. Mereka yang membuat brek mesti memikirkan tentang roda, dan sebagainya. Perkara yang sama sepatutnya berlaku dengan perisian.
Pembangun yang mencipta logik perniagaan atau antara muka pengguna mesti memikirkan pangkalan data yang menyimpan maklumat pelanggan, langkah keselamatan untuk melindungi data pengguna dan cara semua ini akan berfungsi apabila perkhidmatan mula memberi khidmat kepada khalayak pengguna yang besar, mungkin berjuta-juta dolar. ."
“Membuat orang ramai berkolaborasi dan memikirkan bahagian kerja yang orang lain lakukan, dan bukannya memberi tumpuan semata-mata pada tugas mereka sendiri, adalah halangan terbesar untuk diatasi. Jika anda boleh melakukan ini, anda mempunyai peluang yang sangat baik untuk transformasi digital,” tambah Staf Gur.
5. DevOps ialah gabungan orang, proses dan automasi yang betul
Jayne Groll, pengarah eksekutif Institut DevOps, menawarkan analogi yang hebat untuk menerangkan DevOps. Dalam kata-katanya, "DevOps adalah seperti resipi dengan tiga kategori utama bahan: orang, proses dan automasi. Kebanyakan ramuan ini boleh diambil dari kawasan dan sumber lain: Lean, Agile, SRE, CI/CD, ITIL, kepimpinan, budaya, alatan. Rahsia kepada DevOps, seperti mana-mana resipi yang baik, adalah bagaimana untuk mendapatkan perkadaran yang betul dan campuran bahan-bahan ini untuk meningkatkan kelajuan dan kecekapan mencipta dan mengeluarkan aplikasi.
6. DevOps ialah apabila pengaturcara bekerja seperti pasukan Formula 1
"Perlumbaan tidak dirancang dari awal hingga akhir, tetapi sebaliknya, dari penamat hingga permulaan."
"Apabila saya bercakap tentang perkara yang diharapkan daripada inisiatif DevOps, saya menganggap pasukan perlumbaan NASCAR atau Formula 1 sebagai contoh," kata Chris Short, pengurus kanan pemasaran platform awan di Red Hat dan penerbit surat berita DevOps'ish. – Ketua pasukan sedemikian mempunyai satu matlamat: untuk mengambil tempat tertinggi yang mungkin pada penghujung perlumbaan, dengan mengambil kira sumber yang tersedia untuk pasukan dan cabaran yang menimpanya. Dalam kes ini, perlumbaan dirancang bukan dari awal hingga akhir, tetapi sebaliknya, dari penamat hingga permulaan. Pertama, matlamat yang bercita-cita tinggi ditetapkan, dan kemudian cara untuk mencapainya ditentukan. Kemudian mereka dipecahkan kepada subtugas dan diwakilkan kepada ahli pasukan.”
“Pasukan menghabiskan sepanjang minggu sebelum perlumbaan menyempurnakan hentian pit. Dia melakukan latihan kekuatan dan kardio untuk kekal cergas untuk hari perlumbaan yang melelahkan. Amalan bekerjasama untuk menyelesaikan sebarang masalah yang mungkin timbul semasa perlumbaan. Begitu juga, pasukan pembangunan harus melatih kemahiran mengeluarkan versi baharu dengan kerap. Jika anda mempunyai kemahiran sedemikian dan sistem keselamatan yang berfungsi dengan baik, pelancaran versi baharu ke dalam pengeluaran juga lebih kerap berlaku. Dalam pandangan dunia ini, peningkatan kelajuan bermakna peningkatan keselamatan, "kata Short.
"Ini bukan tentang melakukan 'perkara yang betul,'" Short menambah, "ia mengenai menghapuskan sebanyak mungkin perkara yang menghalang hasil yang diinginkan. Bekerjasama dan menyesuaikan diri berdasarkan maklum balas yang anda terima dalam masa nyata. Bersedia untuk anomali dan berusaha untuk meningkatkan kualiti untuk meminimumkan kesannya terhadap kemajuan ke arah matlamat anda. Inilah yang menanti kami di dunia DevOps.”
Cara skala DevOps: 10 petua daripada pakar
Cuma DevOps dan DevOps massa adalah perkara yang sama sekali berbeza. Kami akan memberitahu anda bagaimana untuk mengatasi halangan dalam perjalanan dari yang pertama hingga yang kedua.
Bagi kebanyakan organisasi, perjalanan ke DevOps bermula dengan mudah dan menyenangkan. Pasukan kecil yang bersemangat dicipta, proses lama digantikan dengan yang baru, dan kejayaan pertama tidak lama lagi.
Malangnya, ini hanyalah kemewahan palsu, ilusi kemajuan, kata Ben Grinnell, pengarah urusan dan ketua digital di perundingan North Highland. Kemenangan awal sememangnya menggalakkan, tetapi ia tidak membantu mencapai matlamat utama penggunaan DevOps yang meluas di seluruh organisasi.
Adalah mudah untuk melihat bahawa hasilnya adalah budaya perpecahan antara "kita" dan "mereka".
"Selalunya, organisasi melancarkan projek perintis ini memikirkan mereka akan membuka jalan untuk DevOps arus perdana, tanpa mempertimbangkan sama ada orang lain akan dapat atau sanggup mengikuti laluan itu," jelas Ben Grinnell. – Pasukan untuk melaksanakan projek sedemikian biasanya diambil daripada "Varangians" yang yakin diri yang telah melakukan sesuatu yang serupa di tempat lain, tetapi baru dalam organisasi anda. Pada masa yang sama, mereka digalakkan untuk melanggar dan memusnahkan peraturan yang masih mengikat orang lain. Adalah mudah untuk melihat bahawa hasilnya adalah budaya "kita" dan "mereka" yang menghalang pemindahan pengetahuan dan kemahiran."
"Dan masalah budaya ini hanyalah salah satu sebab DevOps sukar untuk skala. Pasukan DevOps menghadapi peningkatan cabaran teknikal yang tipikal bagi syarikat yang mengutamakan IT yang berkembang pesat,” kata Steve Newman, pengasas dan pengerusi Scalyr.
“Dalam dunia moden, perkhidmatan berubah sebaik sahaja keperluan itu timbul. Memang bagus untuk sentiasa melaksanakan dan melaksanakan ciri-ciri baharu, tetapi menyelaraskan proses ini dan menghapuskan masalah yang timbul adalah pening kepala, tambah Steve Newman. – Dalam organisasi yang berkembang pesat, jurutera dalam pasukan merentas fungsi bergelut untuk mengekalkan keterlihatan terhadap perubahan dan kesan melata peringkat pergantungan yang dihasilkannya. Lebih-lebih lagi, jurutera tidak gembira apabila mereka kehilangan peluang ini dan, akibatnya, menjadi lebih sukar bagi mereka untuk memahami intipati masalah yang timbul.”
Bagaimanakah cara untuk mengatasi cabaran yang diterangkan di atas dan beralih kepada penggunaan DevOps secara besar-besaran dalam organisasi yang besar? Pakar menggesa kesabaran, walaupun matlamat utama anda adalah untuk mempercepatkan kitaran pembangunan perisian dan proses perniagaan anda.
1. Ingat bahawa perubahan budaya memerlukan masa.
Jayne Groll, Pengarah Eksekutif, Institut DevOps: “Pada pendapat saya, pengembangan DevOps haruslah meningkat dan berulang seperti pembangunan tangkas (dan sama-sama menyentuh budaya). Agile dan DevOps menekankan pasukan kecil. Tetapi apabila pasukan ini berkembang dalam bilangan dan integrasi, kami akhirnya dengan lebih ramai orang yang menggunakan cara kerja baharu, dan akibatnya terdapat transformasi budaya yang besar-besaran.”
2. Luangkan masa yang cukup untuk merancang dan memilih platform
Eran Kinsbruner, Penginjil Teknikal Utama di Perfecto: “Untuk penskalaan untuk berfungsi, pasukan DevOps mesti terlebih dahulu belajar untuk menggabungkan proses, alatan dan kemahiran tradisional, kemudian perlahan-lahan memupuk dan menstabilkan setiap fasa individu DevOps. Semuanya bermula dengan perancangan teliti cerita pengguna dan aliran nilai, diikuti dengan menulis perisian dan kawalan versi menggunakan pembangunan berasaskan trunk atau pendekatan lain yang paling sesuai untuk percabangan dan penggabungan kod.
“Kemudian datang peringkat integrasi dan ujian, di mana platform berskala untuk automasi sudah diperlukan. Di sinilah pentingnya pasukan DevOps memilih platform yang sesuai yang sesuai dengan tahap kemahiran mereka dan matlamat akhir projek.
Fasa seterusnya ialah penempatan kepada pengeluaran dan ini harus diautomatikkan sepenuhnya menggunakan alat dan bekas orkestrasi. Adalah penting untuk mempunyai persekitaran maya pada semua peringkat DevOps (simulator pengeluaran, persekitaran QA dan persekitaran pengeluaran sebenar) dan sentiasa menggunakan data terkini sahaja untuk ujian untuk mendapatkan kesimpulan yang berkaitan. Analitis mesti pintar dan mampu memproses data besar dengan maklum balas yang pantas dan boleh diambil tindakan.”
3. Keluarkan rasa bersalah daripada tanggungjawab.
Gordon Haff, Penginjil RedHat: “Mewujudkan sistem dan suasana yang membenarkan dan menggalakkan eksperimen membolehkan apa yang dikenali sebagai kegagalan yang berjaya dalam pembangunan perisian tangkas. Ini tidak bermakna tiada orang lain yang bertanggungjawab atas kegagalan. Malah, mengenal pasti siapa yang bertanggungjawab menjadi lebih mudah, kerana "bertanggungjawab" tidak lagi bermaksud "menyebabkan kemalangan." Iaitu, intipati tanggungjawab berubah secara kualitatif. Empat faktor menjadi kritikal: tahap gangguan, pendekatan, proses pengeluaran dan insentif. (Anda boleh membaca lebih lanjut tentang faktor ini dalam artikel Gordon Huff "Pelajaran DevOps: 4 aspek eksperimen yang sihat.")
4. Kosongkan laluan ke hadapan
Ben Grinnell, pengarah urusan dan ketua digital di perundingan North Highland: "Untuk mencapai skala, saya mengesyorkan melancarkan program" pembersihan laluan " bersama-sama dengan projek perintis. Matlamat program ini adalah untuk membersihkan sampah yang ditinggalkan oleh perintis DevOps, seperti peraturan lapuk dan perkara seperti itu, supaya laluan ke hadapan kekal jelas.”
“Berikan sokongan dan momentum organisasi kepada orang ramai melalui komunikasi yang melampaui kumpulan perintis dengan meraikan kejayaan cara kerja baharu secara meluas. Ajar orang yang terlibat dalam gelombang projek DevOps seterusnya dan gementar untuk menggunakan DevOps buat kali pertama. Dan ingatlah bahawa orang-orang ini sangat berbeza daripada para perintis.”
5. Mendemokrasikan alat
Steve Newman, pengasas dan pengerusi Scalyr: "Alat tidak sepatutnya disembunyikan daripada orang ramai, dan ia sepatutnya mudah dipelajari bagi sesiapa sahaja yang sanggup meluangkan masa. Jika keupayaan untuk membuat pertanyaan log dihadkan kepada tiga orang "diperakui" untuk menggunakan alat, anda akan sentiasa mempunyai maksimum tiga orang yang tersedia untuk menangani masalah itu, walaupun anda mempunyai persekitaran pengkomputeran yang sangat besar. Dalam erti kata lain, terdapat kesesakan di sini yang boleh membawa kepada akibat (perniagaan) yang serius.”
6. Wujudkan keadaan yang ideal untuk kerja berpasukan
Tom Clark, ketua Common Platform di ITV: “Anda boleh melakukan apa sahaja, tetapi bukan semuanya sekaligus. Jadi tetapkan matlamat yang besar, mulakan yang kecil, dan teruskan ke hadapan dalam lelaran yang pantas. Lama kelamaan, anda akan membina reputasi untuk menyelesaikan sesuatu, jadi orang lain akan mahu menggunakan kaedah anda juga. Dan jangan risau tentang membina pasukan yang sangat berkesan. Sebaliknya, sediakan orang dengan keadaan kerja yang ideal dan kecekapan akan menyusul.”
7. Jangan lupa tentang Undang-undang Conway dan papan Kanban
Logan Daigle, Pengarah Penghantaran Perisian dan Strategi DevOps di CollabNetVersionOne: “Adalah penting untuk memahami akibat daripada Undang-undang Conway. Dalam parafrasa longgar saya, undang-undang ini menyatakan bahawa produk yang kami cipta dan proses yang kami gunakan untuk berbuat demikian, termasuk DevOps, ternyata distrukturkan dengan cara yang sama seperti organisasi kami."
"Jika terdapat banyak silo dalam organisasi, dan kawalan bertukar tangan berkali-kali apabila merancang, membina dan mengeluarkan perisian, kesan penskalaan akan menjadi sifar atau jangka pendek. Jika organisasi membina pasukan merentas fungsi di sekitar produk yang dibiayai dengan tumpuan pasaran, maka peluang kejayaan meningkat secara mendadak."
“Satu lagi aspek penskalaan yang penting ialah memaparkan semua kerja sedang berjalan (WIP, workinprogress) pada papan Kanban. Apabila organisasi mempunyai tempat di mana orang boleh melihat perkara ini, ia sangat menggalakkan kerjasama, yang mempunyai kesan positif pada penskalaan."
8. Cari parut lama
Manuel Pais, perunding DevOps dan pengarang bersama Topologi Pasukan: “Mengambil amalan DevOps melebihi Dev dan Ops itu sendiri dan cuba menerapkannya pada fungsi lain bukanlah pendekatan yang optimum. Ini pastinya akan memberi sedikit impak (contohnya, dengan mengautomasikan kawalan manual), tetapi banyak lagi yang boleh dicapai jika kita bermula dengan memahami proses penghantaran dan maklum balas.”
“Sekiranya terdapat parut lama dalam sistem IT sesebuah organisasi - prosedur dan mekanisme pengurusan yang dilaksanakan akibat insiden lalu, tetapi telah hilang kaitannya (akibat perubahan dalam produk, teknologi atau proses) - maka ia sudah tentu perlu dibuang atau diperlancar, bukannya mengautomasikan proses yang tidak cekap atau tidak perlu.”
9. Jangan membiak pilihan DevOps
Anthony Edwards, Pengarah Operasi di Eggplant: "DevOps adalah istilah yang sangat kabur, jadi setiap pasukan berakhir dengan versi DevOps mereka sendiri. Dan tidak ada yang lebih buruk apabila organisasi tiba-tiba mempunyai 20 jenis DevOps yang tidak serasi dengan baik. Adalah mustahil untuk setiap tiga pasukan pembangunan mempunyai antara muka khas mereka sendiri antara pembangunan dan pengurusan produk. Produk juga tidak sepatutnya mempunyai jangkaan unik mereka sendiri untuk mengendalikan maklum balas apabila dipindahkan ke simulator pengeluaran. Jika tidak, anda tidak akan dapat menskalakan DevOps.”
10. Beritahu nilai perniagaan DevOps
Steve Newman, pengasas dan pengerusi Scalyr: “Bekerja untuk mengenali nilai DevOps. Belajar dan berasa bebas untuk bercakap tentang faedah daripada apa yang anda lakukan. DevOps ialah penjimat masa dan wang yang luar biasa (fikirkan sahaja: kurang masa henti, lebih pendek masa untuk pemulihan), dan pasukan DevOps mesti tanpa jemu menekankan (dan mengkhutbah) kepentingan inisiatif ini untuk kejayaan perniagaan. Dengan cara ini anda boleh mengembangkan kalangan penganut dan meningkatkan pengaruh DevOps dalam organisasi.”
BONUS
Pada DevOps kami sendiri akan tiba pada 13 September - ya, Red Hat, sebagai pengeluar perisian, mempunyai pasukan dan amalan DevOps sendiri.
Jurutera kami Mark Birger, yang membangunkan perkhidmatan automasi dalaman untuk kumpulan lain di seluruh organisasi, akan menceritakan kisahnya sendiri dalam bahasa Rusia tulen - cara pasukan Red Hat DevOps memindahkan aplikasi daripada persekitaran maya Hat Virtualization yang diuruskan oleh Ansible kepada format kontena sepenuhnya pada platform OpenShift.
Tetapi itu bukan semua:
Sebaik sahaja organisasi telah memindahkan beban kerja ke bekas, kaedah pemantauan aplikasi tradisional mungkin tidak berfungsi. Dalam ceramah kedua kami akan menerangkan motivasi kami untuk mengubah cara kami log dan menunjukkan kesinambungan laluan yang membawa kami kepada kaedah pembalakan dan pemantauan moden.
Sumber: www.habr.com