Apa angel ngerteni titik utama nalika ngomong babagan DevOps? Kita wis nglumpukake analogi sing jelas, formulasi sing apik lan saran saka para ahli sing bakal nulungi malah non-spesialis menyang titik kasebut. Ing pungkasan, bonus kasebut yaiku DevOps karyawan Red Hat dhewe.
Istilah DevOps asale saka 10 taun kepungkur lan wis pindhah saka hashtag Twitter dadi gerakan budaya sing kuat ing jagad IT, filosofi sejati sing nyengkuyung para pangembang supaya bisa nindakake kanthi luwih cepet, eksperimen, lan terus maju. DevOps wis dadi ora bisa dipisahake karo konsep transformasi digital. Nanging kaya sing asring kedadeyan karo terminologi IT, sajrone sepuluh taun kepungkur, DevOps entuk akeh definisi, interpretasi lan salah paham babagan awake dhewe.
Mulane, sampeyan bisa kerep krungu pitakonan babagan DevOps kaya, apa padha tangkas? Utawa iki sawetara metodologi khusus? Utawa mung sinonim liyane kanggo tembung "kolaborasi"?
DevOps kalebu macem-macem konsep (pangiriman terus-terusan, integrasi terus-terusan, otomatisasi, lsp.), saengga nyaring apa sing penting bisa dadi tantangan, utamane yen sampeyan kepengin banget babagan subjek kasebut. Nanging, katrampilan iki migunani banget, ora preduli manawa sampeyan nyoba ngirim ide menyang atasan utawa mung ngandhani wong saka kulawarga utawa kanca babagan pakaryan sampeyan. Mula, ayo nyingkirake nuansa terminologi DevOps saiki lan fokus ing gambar gedhe.
Apa DevOps: 6 Definisi lan Analogi
Kita takon para ahli kanggo nerangake inti saka DevOps kanthi gampang lan sedhela supaya regane dadi jelas kanggo para pamaca kanthi tingkat pengetahuan teknis apa wae. Adhedhasar asil obrolan kasebut, kita wis milih analogi lan formulasi sing paling nggumunake sing bakal mbantu sampeyan mbangun crita babagan DevOps.
1. DevOps minangka gerakan budaya
"DevOps minangka gerakan budaya ing ngendi loro pihak (pangembang piranti lunak lan spesialis operasi sistem IT) ngerteni manawa piranti lunak ora nggawa keuntungan nyata nganti ana wong sing nggunakake: pelanggan, klien, karyawan, dudu titik," ujare Eveline Oehrlich, riset senior. analis ing Institut DevOps. "Mulane, loro pihak kasebut bebarengan njamin pangiriman piranti lunak kanthi cepet lan berkualitas."
2. DevOps babagan nguatake pangembang.
"DevOps nguatake pangembang kanggo duwe aplikasi, mbukak, lan ngatur pangiriman saka wiwitan nganti rampung."
"Biasane, DevOps diomongake minangka cara kanggo nyepetake pangiriman aplikasi menyang produksi kanthi mbangun lan ngetrapake proses otomatis," ujare Jai Schniepp, direktur platform DevOps ing perusahaan asuransi Liberty Mutual. "Nanging kanggo kula, iki minangka perkara sing luwih dhasar." DevOps nguatake pangembang kanggo duwe aplikasi utawa piranti lunak tartamtu, mbukak, lan ngatur pangiriman saka wiwitan nganti rampung. DevOps ngilangi kebingungan tanggung jawab lan nuntun kabeh wong sing melu nggawe infrastruktur sing didhukung pangembang kanthi otomatis.
3. DevOps babagan kolaborasi nggawe lan ngirim aplikasi.
"Cukup, DevOps minangka pendekatan kanggo produksi lan pangiriman piranti lunak ing ngendi kabeh wong bisa kerja bareng," ujare Gur Staf, presiden lan kepala otomatisasi bisnis digital ing BMC.
4. DevOps minangka pipa
"Perakitan konveyor mung bisa ditindakake yen kabeh bagean pas."
"Aku bakal mbandhingake DevOps karo garis perakitan mobil," ujare Gur Staff. β Ide iki kanggo ngrancang lan nggawe kabeh bagean ing advance supaya padha bisa nglumpuk tanpa imbuhan individu. DΓ©wan conveyor mung bisa yen kabeh bagean pas bebarengan. Sing ngrancang lan mbangun mesin kudu nimbang carane dipasang ing awak utawa pigura. Sing nggawe rem kudu mikir babagan roda, lan liya-liyane. Padha kudu bener karo piranti lunak.
Pangembang sing nggawe logika bisnis utawa antarmuka pangguna kudu mikir babagan basis data sing nyimpen informasi pelanggan, langkah-langkah keamanan kanggo nglindhungi data pangguna, lan kepiye kabeh iki bakal ditindakake nalika layanan kasebut wiwit nglayani pamirsa pangguna sing akeh, bisa uga jutaan dolar. ."
"Njupuk wong kanggo kolaborasi lan mikir babagan bagean saka pakaryan sing ditindakake wong liya, tinimbang mung fokus ing tugas dhewe, minangka alangan paling gedhe sing kudu diatasi. Yen sampeyan bisa nindakake iki, sampeyan duwe kesempatan sing apik kanggo transformasi digital, "tambah Staff Gur.
5. DevOps minangka kombinasi sing tepat saka wong, proses lan otomatisasi
Jayne Groll, direktur eksekutif Institut DevOps, nawakake analogi sing apik kanggo nerangake DevOps. Ing tembung dheweke, "DevOps kaya resep kanthi telung kategori bahan utama: wong, proses lan otomatisasi. Umume bahan kasebut bisa dijupuk saka wilayah lan sumber liyane: Lean, Agile, SRE, CI / CD, ITIL, kepemimpinan, budaya, alat. Rahasia kanggo DevOps, kaya resep sing apik, yaiku entuk proporsi sing tepat lan nyampur bahan kasebut kanggo nambah kacepetan lan efisiensi nggawe lan ngeculake aplikasi.
6. DevOps yaiku nalika programer kerja kaya tim Formula 1
"Lomba ora direncanakake saka wiwitan nganti rampung, nanging sebaliknya, saka pungkasan nganti wiwitan."
"Nalika ngomong babagan apa sing bakal dikarepake saka inisiatif DevOps, aku mikir tim balap NASCAR utawa Formula 1 minangka conto," ujare Chris Short, manajer senior pemasaran platform awan ing Red Hat lan penerbit newsletter DevOps'ish. - Pimpinan tim kasebut duwe tujuan siji: njupuk papan sing paling dhuwur ing pungkasan balapan, kanthi njupuk sumber daya sing kasedhiya kanggo tim lan tantangan sing bakal ditindakake. Ing kasus iki, balapan direncanakake ora saka wiwitan nganti rampung, nanging kosok balene, saka pungkasan nganti wiwitan. Kaping pisanan, tujuan sing ambisi ditetepake, banjur cara kanggo nggayuh tujuan kasebut ditemtokake. Banjur dipΓ©rang dadi subtugas lan didelegasikan menyang anggota tim.
"Tim ngentekake seminggu sadurunge balapan nyempurnakake pit stop. Dheweke nindakake latihan kekuatan lan kardio kanggo tetep ing wangun kanggo dina lomba grueling. Praktek kerja bareng kanggo ngrampungake masalah sing bisa kedadeyan sajrone balapan. Kajaba iku, tim pangembang kudu nglatih katrampilan ngeculake versi anyar kanthi kerep. Yen sampeyan duwe katrampilan lan sistem keamanan sing apik, peluncuran versi anyar menyang produksi uga luwih kerep. Ing worldview iki, tambah kacepetan tegese tambah safety, "ujare Short.
"Iku ora babagan nindakake 'bab sing bener,'" Short nambah, "iku babagan ngilangi akeh perkara sing bisa nyebabake asil sing dikarepake. Kolaborasi lan adaptasi adhedhasar umpan balik sing ditampa kanthi nyata. Disiapake kanggo anomali lan kerja kanggo nambah kualitas kanggo nyuda pengaruhe marang kemajuan menyang tujuan sampeyan. Iki sing nunggu kita ing jagad DevOps.
Cara skala DevOps: 10 tips saka ahli
Mung DevOps lan DevOps massal pancen beda. Kita bakal pitutur marang kowe carane ngatasi alangan ing dalan saka pisanan kanggo kaloro.
Kanggo akeh organisasi, perjalanan menyang DevOps diwiwiti kanthi gampang lan nyenengake. Tim hasrat cilik digawe, proses lawas diganti karo sing anyar, lan sukses pisanan ora suwe.
Sayange, iki mung glitz palsu, khayalan kemajuan, ujare Ben Grinnell, direktur ngatur lan kepala digital ing konsultasi North Highland. Kamenangan awal mesthi nyemangati, nanging ora mbantu nggayuh tujuan utama kanggo nyebarake DevOps ing saindenging organisasi.
Iku gampang kanggo ndeleng sing asil punika budaya divisi antarane "kita" lan "dheweke".
"Asring, organisasi ngluncurake proyek perintis iki kanthi mikir bakal mbukak dalan kanggo DevOps mainstream, tanpa mikir manawa wong liya bisa utawa gelem ngetutake dalan kasebut," jelas Ben Grinnell. - Tim kanggo ngleksanakake proyek kasebut biasane direkrut saka "Varangians" sing percaya diri sing wis nindakake perkara sing padha ing papan liya, nanging anyar ing organisasi sampeyan. Ing wektu sing padha, padha dianjurake kanggo nglanggar lan ngrusak aturan sing tetep ngiket wong liya. Iku gampang kanggo ndeleng yen asil minangka budaya "kita" lan "dheweke" sing nyegah transfer kawruh lan katrampilan.
"Lan masalah budaya iki mung minangka salah sawijining sebab DevOps angel diukur. Tim DevOps ngadhepi tantangan teknis sing luwih akeh sing khas saka perusahaan IT-first sing berkembang cepet, "ujare Steve Newman, pangadeg lan ketua Scalyr.
"Ing jagad modern, layanan diganti sanalika perlu. Iku apik kanggo terus-terusan ngleksanakake lan ngleksanakake fitur anyar, nanging koordinasi proses iki lan mbusak masalah sing njedhul punika sirah nyata, nambah Steve Newman. - Ing organisasi sing tuwuh kanthi cepet, para insinyur ing tim lintas fungsi berjuang kanggo njaga visibilitas menyang owah-owahan lan efek runtun sing digawe ing tingkat ketergantungan. Kajaba iku, para insinyur ora seneng yen ora entuk kesempatan iki lan, minangka asil, dadi luwih angel kanggo ngerti inti saka masalah sing muncul.
Kepiye cara ngatasi tantangan kasebut ing ndhuwur lan pindhah menyang adopsi massal DevOps ing organisasi gedhe? Para ahli njaluk sabar, sanajan tujuan utama sampeyan yaiku nyepetake siklus pangembangan piranti lunak lan proses bisnis.
1. Elinga yen owah-owahan budaya mbutuhake wektu.
Jayne Groll, Direktur Eksekutif, DevOps Institute: "Miturut pendapatku, ekspansi DevOps kudu dadi tambahan lan iteratif kaya pangembangan tangkas (lan uga ndemek budaya). Agile lan DevOps nandheske tim cilik. Nanging amarga tim kasebut saya tambah akeh lan integrasi, kita bakal entuk luwih akeh wong sing nggunakake cara kerja anyar, lan akibate ana transformasi budaya sing akeh banget.
2. Nglampahi cukup wektu planning lan milih platform
Eran Kinsbruner, Penginjil Teknis Utama ing Perfecto: "Kanggo skala kerja, tim DevOps kudu sinau kanggo nggabungake proses, alat, lan katrampilan tradisional, banjur alon-alon ngrawat lan nyetabilake saben fase DevOps. Kabeh diwiwiti kanthi ngrancang crita pangguna lan aliran nilai kanthi ati-ati, banjur nulis piranti lunak lan kontrol versi nggunakake pangembangan basis trunk utawa pendekatan liyane sing paling cocog kanggo kode cabang lan gabung.
"Banjur ana tahap integrasi lan tes, ing ngendi platform sing bisa diukur kanggo otomatisasi wis dibutuhake. Ing kene penting kanggo tim DevOps milih platform sing cocog sing cocog karo level katrampilan lan tujuan pungkasan proyek kasebut.
Tahap sabanjure yaiku penyebaran menyang produksi lan iki kudu otomatis kanthi otomatis nggunakake alat lan wadhah orkestrasi. Penting kanggo duwe lingkungan virtual ing kabeh tahapan DevOps (simulator produksi, lingkungan QA, lan lingkungan produksi nyata) lan mung nggunakake data paling anyar kanggo tes kanggo entuk kesimpulan sing cocog. Analytics kudu pinter lan bisa ngolah data gedhe kanthi umpan balik sing cepet lan bisa ditindakake.
3. Njupuk kaluputan saka tanggung jawab.
Gordon Haff, Penginjil RedHat: "Nggawe sistem lan atmosfer sing ngidini lan nyengkuyung eksperimen ngidini apa sing dikenal minangka kegagalan sukses ing pangembangan piranti lunak tangkas. Iki ora ateges ora ana wong liya sing tanggung jawab kanggo kegagalan. Nyatane, ngenali sapa sing tanggung jawab dadi luwih gampang, amarga "tanggung jawab" ora ateges "nyebabake kacilakan". Tegese, inti saka tanggung jawab diganti kanthi kualitatif. Papat faktor dadi kritis: tingkat gangguan, pendekatan, proses produksi lan insentif. (Sampeyan bisa maca liyane babagan faktor kasebut ing artikel Gordon Huff "Pelajaran DevOps: 4 aspek eksperimen sehat.")
4. Mbusak dalan maju
Ben Grinnell, direktur ngatur lan kepala digital ing konsultasi North Highland: "Kanggo entuk skala, aku nyaranake ngluncurake program" path clearing "bebarengan karo proyek perintis. Tujuan saka program iki yaiku ngresiki sampah sing ditinggalake dening para pionir DevOps, kayata aturan sing wis lawas lan liya-liyane, supaya dalan sing maju tetep jelas.
"Menehi dhukungan organisasi lan momentum wong liwat komunikasi sing ngluwihi klompok perintis kanthi ngrayakake sukses kanthi cara kerja anyar. Pelatih wong sing melu ing gelombang sabanjure proyek DevOps lan gugup babagan nggunakake DevOps kanggo pisanan. Lan elinga yen wong-wong iki beda banget karo para perintis.β
5. alat Demokratisasi
Steve Newman, pangadeg lan ketua Scalyr: "Alat kudu ora didhelikake saka wong, lan kudu gampang disinaoni kanggo sapa wae sing pengin ngetrapake wektu kasebut. Yen kemampuan kanggo query log diwatesi kanggo telung wong "certified" kanggo nggunakake alat, sampeyan bakal tansah duwe maksimum telung wong kasedhiya kanggo nangani masalah, sanajan sampeyan duwe lingkungan komputerisasi gedhe banget. Ing tembung liyane, ana bottleneck ing kene sing bisa nyebabake konsekuensi serius (bisnis).
6. Nggawe kahanan sing cocog kanggo kerja tim
Tom Clark, kepala Platform Umum ing ITV: "Sampeyan bisa nindakake apa wae, nanging ora kabeh bebarengan. Dadi nyetel gol gedhe, miwiti cilik, lan maju kanthi cepet. Suwe-suwe, sampeyan bakal duwe reputasi kanggo ngrampungake, mula wong liya uga pengin nggunakake metode sampeyan. Lan aja kuwatir babagan mbangun tim sing efektif banget. Nanging, nyedhiyakake kahanan kerja sing cocog lan efisiensi bakal ditindakake.
7. Aja lali babagan Hukum Conway lan papan Kanban
Logan Daigle, Direktur Pangiriman Piranti Lunak lan Strategi DevOps ing CollabNetVersionOne: "Penting kanggo ngerti akibat saka Hukum Conway. Ing paraphrase sing longgar, undang-undang iki nyatakake yen produk sing digawe lan proses sing digunakake kanggo nindakake, kalebu DevOps, dadi terstruktur kanthi cara sing padha karo organisasi kita.
"Yen ana akeh silo ing organisasi, lan kontrol diganti kaping pirang-pirang nalika ngrancang, mbangun lan ngeculake piranti lunak, efek skala bakal nol utawa ora suwe. Yen organisasi mbangun tim lintas fungsi ing babagan produk sing didanai kanthi fokus pasar, kemungkinan sukses saya tambah akeh.
"Aspek penting liyane saka skala yaiku nampilake kabeh karya sing lagi ditindakake (WIP, workinprogress) ing papan Kanban. Nalika organisasi duwe papan ing ngendi wong bisa ndeleng prekara kasebut, mula bisa nyengkuyung kolaborasi, sing nduwe pengaruh positif kanggo skala.
8. Goleki bekas bekas
Manuel Pais, konsultan DevOps lan co-penulis Team Topologies: "Njupuk praktik DevOps ngluwihi Dev lan Ops dhewe lan nyoba ngetrapake menyang fungsi liyane meh ora dadi pendekatan sing optimal. Iki mesthi bakal duwe sawetara pengaruh (contone, kanthi ngotomatisasi kontrol manual), nanging luwih akeh bisa digayuh yen kita miwiti ngerteni proses pangiriman lan umpan balik.
"Yen ana parut lawas ing sistem IT organisasi - prosedur lan mekanisme manajemen sing ditindakake minangka akibat saka kedadeyan kepungkur, nanging wis ilang relevansi (amarga owah-owahan ing produk, teknologi utawa proses) - mula mesthine kudu dibusak. utawa lancar, tinimbang ngotomatisasi proses sing ora efisien utawa ora perlu.
9. Aja jenis DevOps pilihan
Anthony Edwards, Direktur Operasi ing Eggplant: "DevOps minangka istilah sing ora jelas, mula saben tim entuk versi DevOps dhewe. Lan ora ana sing luwih elek nalika organisasi dumadakan duwe 20 jinis DevOps sing ora cocog banget. Ora mungkin saben telung tim pangembangan duwe antarmuka khusus dhewe ing antarane pangembangan lan manajemen produk. Uga produk kudu duwe pangarepan unik dhewe kanggo nangani umpan balik nalika ditransfer menyang simulator produksi. Yen ora, sampeyan ora bakal bisa skala DevOps.
10. Martakake nilai bisnis DevOps
Steve Newman, pangadeg lan ketua Scalyr: "Gawe kanggo ngenali nilai DevOps. Sinau lan rumangsa bebas ngomong babagan keuntungan saka apa sing sampeyan lakoni. DevOps minangka wektu lan dhuwit sing luar biasa ngirit (mung mikir: kurang downtime, wektu sing luwih cendhek kanggo pulih), lan tim DevOps kudu tanpa lelah nandheske (lan martakake) pentinge inisiatif kasebut kanggo sukses bisnis. Kanthi cara iki sampeyan bisa nggedhekake bunder para penganut lan nambah pengaruh DevOps ing organisasi.
BONUS
Ing DevOps kita dhewe bakal teka ing 13 September - ya, Red Hat, minangka produsen piranti lunak, duwe tim lan praktik DevOps dhewe.
Insinyur kita Mark Birger, sing ngembangake layanan otomatisasi internal kanggo grup liyane ing saindhenging organisasi, bakal nyritakake critane dhewe ing basa Rusia murni - kepiye tim Red Hat DevOps migrasi aplikasi saka lingkungan virtual Hat Virtualization sing dikelola dening Ansible menyang format wadhah lengkap ing platform OpenShift.
Nanging ora mung iku:
Sawise organisasi wis mindhah beban kerja menyang wadhah, cara ngawasi aplikasi tradisional bisa uga ora bisa digunakake. Ing pirembagan kapindho kita bakal nerangake motivasi kita kanggo ngganti cara kita log lan nuduhake kelanjutan saka path sing mimpin kita logging modern lan cara ngawasi.
Source: www.habr.com