Yen sampeyan ora ngerti apa DevOps, iki sheet cheat cepet. DevOps minangka set praktik sing nyuda wedi engineers lan nyuda jumlah gagal ing produksi piranti lunak. Minangka aturan, padha nyuda wektu kanggo pasar — wektu saka idea kanggo pangiriman produk final kanggo pelanggan, sing ngijini sampeyan kanggo cepet nindakake eksperimen bisnis.
Kepiye carane miwiti transformasi DevOps? Singkat: kita milih layanan kanggo miwiti proses, ngenali wong-wong sing ana hubungane karo layanan, mbangun Peta Nilai Stream, nggawe tim sementara sing bakal nangani transformasi kanggo pisanan lan nyetel tugas. Kita mbaleni siklus kaping pirang-pirang sing dibutuhake.
Rencana transformasi DevOps sing rinci kanthi conto lan instruksi ing potongan - ing transkrip Andrey Alexandrov - insinyur ing Express42, sing menehi saran babagan germination DevOps, nyepetake proses iki amarga dheweke wis nggawe peta rake. Yen misale jek sampeyan ora mbutuhake transformasi, utawa spesifik sampeyan kaya praktik DevOps ora cocog, gunakake laporan kasebut minangka pandhuan kanggo nemokake lan ngilangi watesan.
Yen sampeyan prihatin babagan masalah transformasi DevOps, mula sampeyan duwe perusahaan gedhe, lan sampeyan kudu nggedhekake proses iki kanthi bertahap ing kabeh struktur. Anggere ana perlu kanggo ngowahi printah utawa ngilangi sawetara watesan, algoritma ing ngisor iki bisa diulang.
Milih layanan
Kita wis mbatesi rencana, ayo miwiti kanthi langkah pertama - milih layanan. Kriteria pisanan yaiku umur: ana layanan lawas - warisan, lan anyar. Sampeyan bisa miwiti karo loro.
Iku logis kanggo milih layanan enom. Wis seger, durung ana proses sing mapan kanggo nggarap tim sing ngurusi. Ora ana gunung utang teknis ing saubengé, sampeyan ora perlu ndandani kabeh wektu. Kita bisa nindakake apa wae sing dikarepake.
Ing cilik saka layanan lawas, ana masalah related kanggo kasunyatan sing owah-owahan tansah angel. Wis ana sawetara watesan sing serius, nanging bisa uga ditindakake dening wong sing wis siyap nyopot kabeh - dheweke kesel lan pengin nindakake kanthi beda amarga lara.
Nggarap layanan lawas nggawe preseden sing kuat ing perusahaan sampeyan - sampeyan bisa ngganti soko. Yen sampeyan ngganti layanan anyar, iku muter mudhun 100 kaping jam, lan kabeh iku apik, banjur wong ing perusahaan sampeyan bisa ngomong:
- Iki layanan anyar! Kabeh ana prasaja ana, nyoba kanggo nindakake soko karo wreck kita.
Iku ndadekake pangertèn kanggo nggunakake layanan Warisan kanggo transformasi nalika sampeyan nindakake karo wong, contone, yen sampeyan ngundang konsultan external. Ayo dadi jujur, transformasi bakal goyangake kabeh bisa. Sampeyan nyoba lan ora ngerti ngendi sampeyan bakal mungkasi, apa teknologi sing bakal digunakake lan apa, ngendi lan apa pitfalls bakal muncul ing proses. Mulane, luwih gampang ngganti sing anyar.
Yen sampeyan nindakake kabeh dhewe, lan perusahaan ora duwe kompetensi serius, kita njupuk layanan anyar. Yen sampeyan ngerti konsultan eksternal lan duwe dana, pilih sing lawas.
Ana layanan sing mung antarmuka kanggo pangguna, contone, situs web utawa aplikasi seluler sing prasaja. Nanging ana perkara serius ing semangat tagihan. Yen ana sing salah karo tagihan, bakal angel ngerteni. Ing kene kita uga duwe pilihan.
Kita bisa uga karo layanan kritis, nanging kita nandhang sangsara marga saka iku, iku nggawe Watesan, utawa kita bisa karo antarmuka. Iki minangka kriteria pilihan kapindho. Kajaba iku, sampeyan bisa narik konsultan sing berpengalaman - kita nggarap pilihan sing angel.
Nanging sanajan ing kasus iki, aku ora nyaranake nindakake iki, amarga nganti ana pangerten babagan apa sing kudu ditindakake lan arah sing bakal ditindakake, njupuk perkara kritis lan goyangake iku dudu ide sing apik banget. Mulane, ing kasus iki, kita luwih seneng nggarap antarmuka sing gagal ora kritis.
Ayo katon luwih tim layanan. Kita kudu terus-terusan kerja lan sesambungan rapet karo sing nyedhiyakake layanan iki.
Wong ing tim dipérang dadi rong kategori: konservatif - manggon ing donya lawas, utawa mung ora ngerti apa-apa bab DevOps, lan inovator, sing nyeret kabeh laku modern. Sing terakhir ora mesthi ngerti topik kasebut, nanging paling ora dheweke wis siyap.
Ing sisih siji, konservatif minangka wong sing berpengalaman: dheweke wis suwe ana ing perusahaan, dheweke ngerti jero lan njaba, nanging ora ngerti persis babagan praktik kasebut. Ing tangan liyane, ana inovator sing wis krungu soko, nanging paling kamungkinan wis ora makarya ing perusahaan kanggo dangu. Kang siji luwih apik kanggo nggarap?
Sampeyan kudu sesambungan karo konservatif ing kasus apa wae, amarga iki layanane. Sampeyan kudu komunikasi karo wong-wong mau, ngerteni spesifik layanan kasebut, apa sing bisa ditindakake kanthi cara iki lan liya-liyane. Kita gumantung marang saran. Sampeyan mbokmenawa kudu ngandelake apa wae, amarga dheweke luwih ngerti layanane. Mulane, penting karo tim apa sing bakal kita hubungi.
Iku logis kanggo milih inovator kanggo tim, amarga konservatif bisa sijine babi ing.
Ing laku, asring kedadeyan yen wong konservatif duwe pengalaman sing signifikan, nanging ora duwe pangerten babagan cara urip luwih lanjut. Dheweke mung wedi yen sawise transformasi lan desain ulang layanan kasebut, dheweke bakal dipecat minangka ora perlu. Kadhangkala, mung amarga ora ngerti apa sing kedadeyan, dheweke sabotase karya kasebut.
Aku duwe kasus nalika ana wong saka tim sing ndandani kabeh, amarga mesthine luwih kritis tinimbang sing ditindakake saiki. Kita nyetel tugas: kanggo ngleksanakake potongan iki dina iki - ora, ana geni ing sisih liya, kita bakal ndandani. Pancen angel nyambut gawe karo wong sing kaya ngono.
Wong saka tim konservatif kerep lali babagan tugas utawa nundha nganti menit pungkasan. Lan yen, John Willis ngalang-alangi, sampeyan nggawe kesalahan lan menehi KPI kanggo jumlah tugas sing wis rampung, lan sakperangan alesan ora kalebu ing KPI, mula dheweke ora bakal nindakake apa-apa. Umumé, padha bakal tengen, amarga banjur padha kelangan bonus.
Luwih gampang karo inovator - luwih setya. Wis padha krungu apa-apa, padha arep menyang ngendi wae, supaya padha bantuan. Kita butuh wong sing wis siyap nandhang sangsara sepisanan: yen layanan diganti, para inovator bakal nyekel kabeh bongkahan lan rakes minangka pionir. Inovator pengin kabeh anyar lan modis, lan nandhang sangsara.
Konservatif mengko bisa diowahi. Yen sampeyan nuduhake yen sampeyan ngganti potongan lan kabeh bisa digunakake kanthi apik, mesthine dheweke uga pengin nyoba lan bakal nganut agama DevOps anyar.
Ayo ngringkes. Yen kita nindakake kabeh transformasi ing perusahaan kita dhewe, banjur kita milih: layanan anyar, luwih antarmuka prasaja supaya ora nandhang sangsara akeh banget saka risak sawijining, lan tim inovator.
Yen bisa nelpon konsultan eksternal, tinimbang sing anyar, kita njupuk layanan lawas, amarga kita wis nandhang sangsara. Wong-wong sing wis suwe melu transformasi ing perusahaan sing beda-beda wis ndeleng macem-macem kasus lan wis ngerti carane nindakake kanthi bener, lan arah sing kudu ditindakake kanthi umum.
Sapa sing melu?
Kita kudu nemokake saben wong sing paling ora ana hubungane karo layanan kasebut: pangembang, penguji, admin, spesialis keamanan, manajer lan, bisa uga, Pamilik Produk. Senadyan kasunyatan manawa Pamilik Produk dudu spesialis teknis, ana hubungane karo layanan kasebut: nggawe keputusan, nyetel tugas.
Saben uwong sing nggawe paling ora sawetara keputusan lan mengaruhi apa sing kedadeyan karo layanan kasebut kudu ditemokake, ditemoni lan dikomunikasikake.
Apa sing kita butuhake? Kanggo ngerti sing arep rembugan karo. Sajrone transformasi, nalika prinsip biasa nggarap layanan diganti, isih bakal goyang. Bakal ana glitches sawetara nalika kita nyoba pendekatan anyar. Wong kudu siyap lan setuju karo iki.
Sabanjure sampeyan kudu mbangun Peta Nilai Stream, lan tanpa wong-wong iki, sampeyan ora bakal bisa mbangun, amarga mung wong-wong mau kabeh ngerti gambar lengkap babagan apa sing kedadeyan. Siji wong ora ngerti kabeh sing kedadeyan karo layanan kasebut.
Dheweke bakal menehi rekomendasi wong kanggo tim kasebut. Mengko kita bakal ngrembug kenapa tim sing kapisah dibutuhake. Bakal kudu njupuk wong saka departemen sing ana. Wong-wong sing melu layanan kasebut bakal bisa menehi saran marang kolega sing mikir babagan arah kita, sing bisa nulungi kita lan kompeten ing apa sing kita butuhake.
Sabanjure, kita klumpukne kabeh wong iki saka departemen beda menyang siji kamar lan miwiti mbangun Peta Nilai Stream.
Nggawe Peta Aliran Nilai
Value Stream Map minangka diagram utawa peta sing nuduhake aliran nilai menyang klien. Iki kabeh proses saka teka munggah karo idea kanggo implementasine, kalebu kabeh orane tumrap sekolah penengah lan carane nilai pungkasanipun nemu kanggo kita klien.
Nilai Stream Map dibutuhake kanggo nggambarake kabeh tahap pangembangan, localize masalah liwat pangukuran sing ana ing proses saiki lan miwiti kanggo ngilangke masalah iki, lan nyetel gol dhisikan. Iki ngendi kita miwiti kanggo bener nindakake soko.
Metrik
Ana macem-macem metrik sing diterangake ing literatur Peta Stream Nilai, nanging mung telung cukup kanggo miwiti.
Lead Time - wektu tundha / ngenteni - wektu nalika kita nunggu soko. Contone, tester ngenteni nganti stand test gratis, lan ing wektu iki ora bisa nindakake apa-apa.
Wektu Tambah Nilai - wektu kerja sing migunani - apa sing kita gunakake ing tahapan kasebut kanggo nggawe nilai pungkasan kanggo pangguna. Contone, panguji miwiti tes lan miwiti mriksa apa wae. Iki wektu karya migunani, nalika kita bener nindakake soko kanggo produk. Iki sing dibayar klien - quality software .
%C/A minangka persentase karya sing ditampa. Kita duwe siji tahap - pangembangan, tahap kapindho - testing. Pira fitur panguji sing ditampa saka pangembang yaiku persentase iki.
Iki kira-kira kaya peta kita.
Bisa uga beda-beda gumantung saka struktur organisasi, jumlah departemen lan apa sing sampeyan lakoni. Nanging umume bakal ana rong tahap ing peta: idea и analytics. Ing tahap iki, data samesthine, contone, Lead Time 2 minggu lan Value Added Time 2 dina.
Kita nutupi kabeh tahapan kanthi metrik.
Backlog - carane akeh masalah ana sawise analis teka munggah karo wong-wong mau.
Pangembangan saka - pirang-pirang minggu para pangembang ngenteni klarifikasi babagan tugas, papan utawa peralatan - ora masalah, nanging ngenteni apa wae. Contone, butuh 4 dina kanggo ngetrapake fitur. Iki ngendi metrik %C/A mlebu. Pangembang mung njupuk 80% tugas saka Backlog. Dheweke percaya yen 20% isih ora duwe spesifikasi teknis sing cukup jelas, lan dikirim kanggo revisi.
Tes. Diagram LT disetel dadi 4 dina. Contone, penguji nunggu bangku tes dadi gratis, VA bener-bener nguji apa-apa sajrone 2 dina, lan% C / A = 40%. - mung 40% kode utawa fitur sing dikirim dening pangembang dianggep cukup dening penguji. Padha ora seneng kabeh liyane kanggo sawetara alasan.
Aku ora bakal manggon kanthi rinci babagan cara nindakake pangukuran kasebut, ing pungkasan artikel, aku bakal menehi rekomendasi literatur sing bisa sampeyan sinau babagan.
Siji-sijine sing bisa disaranake yaiku sampeyan ora percaya karo wong sing bakal nggawe Peta Stream Nilai karo sampeyan. Dheweke menehi ide babagan suwene proses sing beda-beda, nanging perkiraan kasebut ora mesthi bener, mula luwih becik ngukur dhewe.
Kita duwe kasus nalika teka ing departemen Operasi lan takon suwene wektu kanggo ngirim fitur anyar kanggo produksi. Kita padha marang sing 10 menit, lan kita panginten, kok kita malah teka ing perusahaan iki? Ternyata 10 menit minangka wektu skrip sing njupuk kode lan dikirim menyang server. Nanging sadurunge iki, rilis lenggah ing server telung dina lan mung ngumpulake bledug - ana tugas ing Backlog sing kudu disebarake. Pranyata sadurunge tahap penyebaran ana tahap nunggu, nalika proyek mung lungguh ana. Yen kita wis ora lunga karo notepad a, wis ora kejiret mripat ing tugas ing Jira lan miwiti nelusuri langkah dening langkah, kita wis panginten sing kabeh apik lan ora ana masalah.
Mula, sampeyan isih kudu nindakake pangukuran dhewe, luwih becik luwih saka sepisan, supaya duwe ide sing cedhak karo kasunyatan. Gumantung ing Peta Value Stream, sampeyan bakal nemtokake ngendi arep miwiti lan apa sing kudu didandani dhisik.
Tim sementara
Akeh perusahaan sing mutusake kanggo ngetrapake DevOps nggawe tim, nanging ora sementara, nanging sing wis ana sawetara taun. Yen sampeyan pindhah menyang layanan nyuwun pangapunten DevOps, sing nggambarake macem-macem pola kanggo mbangun struktur organisasi ing DevOps, sampeyan bakal ngerti manawa iki minangka anti-pola.
Nalika tim DevOps ana terus-terusan nganti pirang-pirang taun, iki minangka kesalahan gedhe, amarga DevOps babagan komunikasi antarane departemen, babagan kacepetan lan efisiensi.
Yen tim ana antarane departemen mung kanggo nindakake soko liyane kapisah, lan ana kanggo dangu, banjur nggawe alangi rasah. Saiki programmer, tinimbang langsung menyang administrator kanggo ngrampungake masalah kasebut, kudu ngontak departemen DevOps dhisik, lan dheweke bakal maju.
Mulane, kanggo miwiti, sampeyan kudu nggawe tim sementara. Bakal ana kanthi kondisional sajrone nem sasi, maksimal setahun, gumantung saka tugas sing ditindakake, mung kanggo ngilangi siji watesan sing wis dipilih. Banjur dheweke bakal mati. Yen kita milih titik sabanjure ing ngendi kita nandhang lara lan ngerti yen kita uga butuh tim sing kapisah, mula kita bakal nggawe maneh. Nanging tim kasebut ora kudu ana "kanthi basis permanen" - banjur mung ngganggu komunikasi lan umume nindakake tugas sing kapisah mung kanggo ngrampungake. Tugas kasebut bisa uga ora ana gandhengane karo DevOps utawa transformasi. Yagene kita ora menehi tugas iki menyang departemen sing wis ana?
Napa tim sementara dibutuhake?
Konflik karo pangolahan saiki. Transformasi DevOps ora mung owah-owahan ing teknologi lan alat sing digunakake, nanging owah-owahan ing proses kerja, pamikiran lan nilai. Yen tim nggarap cara sing wis digunakake, ora bakal bisa nyoba pendekatan liyane.
Wong-wong iki kudu urip kanthi aturan sing beda-beda: nglirwakake kabeh KPI ing perusahaan amarga padha nyoba kerja kanthi beda. Tim sauntara ora bakal ngisi aplikasi kanggo njaluk server, nanging bakal langsung menyang departemen sing ngatur, nuntut supaya diwenehi apa sing dibutuhake dhisik, amarga iku prioritas lan amarga padha nyoba urip kanthi beda. Tim kasebut ana konflik lengkap karo kabeh proses saiki. Kanggo mesthekake yen praktik kerja sing ana saiki ora ngganggu lan ora ngganggu wong liya, kita ngisolasi wong-wong iki dadi tim sing kapisah.
Nyingkiri birokrasi ing eksperimen. Tim sementara ora duwe birokrasi, ora ngajukake laporan wektu, ora laporan menyang manajer. Iki minangka jagad sing kapisah ing ngendi wong urip lan mikir kanthi beda lan nindakake perkara sing beda. Ora perlu ngganggu wong-wong mau maneh.
Non-stop karya ing layanan. Ing titik pisanan, kita milih soko sing bakal kita eksprimen. Nyobi lan golek cara kanggo bisa luwih apik iku apik, nanging kita uga pengin nggawe fitur. Yen kabeh tim fokus ing transformasi tinimbang fitur, mula kita bakal kelangan penghasilan, kewan omo bakal suwe saya suwe - kita ora butuh iki. Nggawe tim sauntara ngidini sampeyan nyoba tanpa mandheg nggarap produk kasebut.
Aja mbuwang wektu kanggo tugas kerja. Iku babagan produk maneh. Perlu wektu akeh kanggo tim nyoba alat lan barang liyane. Bakal njupuk paling sethithik nem sasi kanggo wong bisa nguwasani alat kasebut, miwiti ngetrapake lan digunakake kanthi normal. Yen padha uga fokus ing prodhuk, nem sasi bakal metu cosmically. Yen wong nggarap produk kasebut, dheweke bakal nggarap proses lawas - kita ora butuh.
Mulane, kita nemtokake wong saka departemen sing beda menyang tim sing kapisah sing bakal ngowahi layanan kasebut. Akibaté, layanan kasebut terus berkembang, lan ing wektu sing padha kita nindakake sawetara eksperimen.
Tim sementara mung darmabakti kanggo transformasi DevOps - ngilangi watesan sing ditemokake, lan ora liya.
Tim kasebut kalebu wong sing serbaguna. Iki tegese kita nyewa ora mung pangembang. Kita ora teka ing pusat layanan lan njupuk setengah tim saka kana - ora, kita njupuk wong saka departemen beda. Sawetara titik kepungkur, kita nemokake departemen sing beda lan karyawan sing beda-beda sing ana hubungane karo layanan sing diowahi. Kita ngrekrut tim saka wong-wong mau, amarga kudu universal - kita bakal ngganti proses tes, proses pangembangan, lan proses pangopènan layanan. Kompetensi sing beda-beda dibutuhake.
Biasane kita njupuk pangembang, tester lan insinyur, siji-sijine, lan bebarengan karo solusi sing ngidini kita urip kanthi beda.
Iku seng di pengeni sing wong iki duwe wewenang ing organisasi. Sampeyan bisa uga kudu njupuk siji konservatif, sanajan sampeyan ora pengin. Yen kita duwe perusahaan gedhe, ora kabeh wong bakal pracaya ing idea kita, lan sawetara bisa sijine ngandika ing gembong, contone, dening ora nyedhiyani ngadeg. Ing kene sampeyan butuh "panguwasa" - wong sing dihormati kanthi pengalaman ekstensif sing entuk sikap apik saka kanca-kancane. Wewenang karyawan ing tim bakal nyederhanakake tugas lan karya tim sementara. Wong bakal mikir:
- Ya, wong lanang sing apik iki sing kita kenal lan tresna banget - ketoke ana sing kudu ditonton ing DevOps!
Nyetel gol
Kita ngumpulake wong, milih layanan, ndeleng watesan, lan nemtokake wong sing bakal kita pengaruhi. Saiki sampeyan kudu nyetel gol lan kudu lurus dening SMART - kabeh sing kita tresnani.
Spesifik - spesifik.
Bisa diukur - bisa diukur. Iki minangka titik SMART sing penting banget. Yen sampeyan ora bisa ngukur soko, sampeyan ora bisa ngganti lan ngerti apa lan carane sampeyan nindakake luwih apik utawa luwih elek.
Achievable - achievable. Nggawe pangaturan sing cocog karo kabutuhan tartamtu. Yen sampeyan minangka perusahaan perusahaan kanthi sejarah sing dawa lan akeh tanggung jawab, sing ngeculake versi produk sapisan taun, mula sampeyan ora bakal bisa entuk rilis versi anyar produk saben jam sajrone nem sasi. Ora bakal bisa kaya ngono. Mula, aturake target sing nyata sing bisa ditindakake sajrone wektu sing bisa ditampa.
Relevan - relevan. Kita mbusak mung watesan sing bener-bener nggayuh tujuan kita saiki.
Wektu Limited - winates ing wektu. Yen ora ana tenggat wektu, tim bakal nindakake apa wae sing dikarepake: nyoba 15 teknologi tinimbang 3, nulis laporan gedhe, nindakake riset sing ora ana gunane, polish implementasine nganti sumunar nalika target wis diraih.
We njupuk goal nggunakake Value Stream Map - kita ngumpulake kabeh wong maneh lan tarik wong. Nanging mung saiki, adhedhasar Peta Aliran Nilai sadurunge, kita nggambar apa sing dikarepake.
Kita nyorot siji watesan sing bakal kita ngilangi saiki - iki sing bakal ditindakake tim. Minangka conto, aku ngenteni saka rilis rampung nganti penyebarane ing produksi - iki minangka watesan sing paling umum sing ditindakake wong menyang konsultan.
Adhedhasar iki, kita nyetel tugas: kita pengin ngenteni ing antarane rilis rampung lan arep perang dadi maksimal jam.
Conto tugas.
- Ngurangi Lead Time testing saka 4 dina dadi 1 jam.
- Ngurangi Wektu Tambah Nilai kanggo tes saka 2 dina dadi 3 jam.
- Ngurangi Lead Time penyebaran saka 5 jam nganti 10 menit.
- Nambah C / A saka 50% dadi 95%, yaiku, nambah jumlah fitur sing ditampa penguji, kanthi tembung liya, nambah kualitas karya pangembang.
Conto tugas ora dijupuk saka kepala kita - adhedhasar pangukuran sing digawe nalika ngembangake Peta Aliran Nilai.
Kita nyetel tugas sing padha kanggo tim lan watesan wektu. Gumantung carane perusahaan sampeyan nindakake, sampeyan nyetel tenggat wektu sing beda. Rata-rata, biasane njupuk enem sasi kanggo ngilangi watesan, yen wong nindakake iki kanggo pisanan lan durung ngerti apa teknologi lan carane khusus bakal ngatasi masalah.
Perencanaan singkat
Dadi, tim kita digawe, duwe tujuan, wong wiwit kerja. Titik penting yaiku rencana kerja sing cendhak: sprints siji kanggo rong minggulan ora luwih, dandan sing bisa diukur saben minggu lan koreksi kursus.
Contone, kita asring nggunakake pendekatan obah-obahNalika kabeh tim kumpul ing awal saben minggu, dheweke nulis ing file apa sing bakal ditindakake saben wong. Sawise seminggu, kita nyathet apa sing wis ditindakake lan apa sing durung rampung, yen ora, banjur kenapa, lan kita mikir apa sing kudu ditindakake sabanjure.
Sprint ngidini sampeyan nggawe koreksi kursus sing pas wektune.
Kanggo seminggu utawa loro sampeyan nyoba soko: teknologi, pendekatan, cara kerja, sawise sampeyan ngukur maneh lan ndeleng - apa wis dadi luwih apik utawa luwih elek karo pendekatan iki? Yen luwih elek, tegese kita arep menyang arah sing salah, kita kudu mbenerake dalan: nyetel tugas sing beda, njupuk teknologi sing beda, utawa nindakake liyane. Sprint cendhak 1-2 minggu ngidini sampeyan maneuver lan ngindhari keputusan sing ala ing wektu.
Nuduhake sukses
Tim entuk sawetara sukses, cilik utawa gedhe - ora masalah, mesthi ana asil. Saben uwong kudu ngerti babagan asil iki: loro sing melu DevOps lan departemen tetanggan. Ing donya becik, iku bakal seng di pengeni kanggo iki teka ing kabeh kanggo kabeh wong ing perusahaan.
Kanggo apa? Yen kita pengin ngowahi ora mung bagean saka perusahaan, ngilangi ora mung siji watesan, nanging kabeh umume, supaya perusahaan dadi fleksibel, kode kasebut cepet tekan klien, lan ora ana sing rusak, kabeh wong kudu setya karo ide kasebut. saka DevOps. Sampeyan ora bakal bisa ngetrapake pendekatan kasebut menyang layanan lan tim sing nglawan.
Supaya kesetiaan katon, kita kudu ngandhani kabeh wong yen wis nyoba iki - kita duwe asil, coba uga! Iki bakal nambah kapentingan lan kasetyan kanggo apa kita apa, wong bakal miwiti nyoba kanggo nindakake soko sapunika. Minangka praktik nuduhake, nalika kita ngandhani apa sing kita coba lan apa sing diraih, tim liyane wiwit takon kepiye lan apa sing ditindakake. Padha katon ing implementasine, kode, dokumentasi, teka karo pitakonan lan nyoba kanggo ngganti soko dhewe.
Ngomong apa sing sampeyan lakoni iku penting. Kanthi cara iki sampeyan bakal ngyakinake konservatif sing pengin nindakake kabeh cara lawas kanggo gabung karo kemah sampeyan lan ngowahi dadi inovator.
Total
Milih layanan, minangka titik wiwitan - papan ing ngendi kita bakal miwiti owah-owahan ing perusahaan. Kita ngenali saben wong sing ana hubungane karo layanan kasebut lan karo wong-wong mau mbangun Peta Aliran Nilai, kita ngukur lan ndeleng ngendi lan apa watesan.
Nggawe tim sauntara anyar, sing bakal ngatasi masalah. Adhedhasar pangukuran lan Peta Aliran Nilai kita tarik peta anyar, ngendi kita nyorot watesan sing bakal kita ngatasi. Adhedhasar watesan iki atur tugas, sing bakal ditangani tim. Tugas kudu kudu SMART - spesifik, bisa diukur, cocog karo tugas saiki lan winates ing wektu.
Baleni proses kasebut, nganti kita ngowahi kabeh layanan kita menyang formulir sing dibutuhake lan ngilangi kabeh watesan.
Bonus. Bahan sing migunani
Kanggo sing mutusake nindakake DevOps dhewe.
Proyek "Phoenix"
Judhul asli yaiku "Proyek Phoenix: Novel babagan, Devops, lan Mbantu Menang Bisnis Sampeyan." Iki minangka novel babagan DevOps - crita babagan carane karyawan dadi kepala departemen sing tansah kobong. Bos anyar diwenehi tugas:
"Sampeyan duwe sawetara taun kanggo ngrampungake kabeh supaya pungkasane bisa ngirim produk menyang pelanggan kanthi cepet lan efisien."
"Proyek Phoenix" Novel babagan carane DevOps ngganti urip dadi luwih apik" minangka buku kanggo kabeh manajer, amarga iki wong sing nggawe keputusan babagan apa sing kedadeyan ing perusahaan. Yen sampeyan insinyur utawa programmer lan pengin gerakan lan transformasi diwiwiti ing perusahaan sampeyan, tuku buku lan menehi menyang manajemen. Novel iki nerangake kabeh lan maca kanthi cepet lan gampang.
Pandhuan DevOps
Buku kasebut luwih rumit. Iki diterbitake sawetara taun kepungkur ing basa Inggris kanthi judhul "The DevOps Handbook How to create world-class agility, reliability, and security in Technology organizations," nanging saiki wis kasedhiya ing basa Rusia. Iki nyata buku pegangan - pandhuan praktis: carane nindakake pangukuran, apa Value Stream Map lan apa iku perlu, ngendi kanggo pindhah, ing urutan apa. Buku kasebut mung kanggo wong sing pengin nindakake kabeh dhewe. Sing paling penting, ngemot conto pengalaman perusahaan liyane.
Contone, ngandhani carane siji perusahaan dibangun Value Stream Map lan temen maujud sing watesan ora ing produk, nanging ing kasunyatan sing kasir mlaku saka toko menyang kantor sabanjuré kanggo nggunakake produk iki. Tinimbang ngrampungake masalah karo program kasebut, dheweke mung tuku tablet kanggo para penjual, lan saiki ora ana sing lunga, lan kabeh tumindak ditindakake ing papan kerja. Kesimpulan: Value Stream Map bisa ditambah ora mung kanggo piranti lunak, nanging uga kanggo kabeh proses ing organisasi.
akselerasi
Judhul lengkap: "Akselerasi: Ilmu Piranti Lunak Lean lan DevOps: Mbangun lan Nggawe Organisasi Teknologi Berprestasi Tinggi." Iki minangka level sabanjure - hardcore. Buku iki diterbitake taun kepungkur, nganti saiki mung ing basa Inggris lan babagan riset. Penulis-Nicole Forsgren, Jez Humble, lan Gene Kim-wis nggunakake praktik sing beda-beda ing perusahaan sing beda-beda sajrone pirang-pirang taun lan nliti praktik sing mengaruhi apa lan kepiye.
Bab kapindho, babagan pangukuran, nyebutake Peta Aliran Nilai, metrik sing dakkandhakake, lan liya-liyane, lan uga nggambarake proses pangukuran kanthi rinci. Penulis ngukur nggunakake kuesioner lan tugas nelusuri dhewe. Iki njlèntrèhaké kanthi rinci metrik endi sing bener kanggo diukur, sing ora kudu diukur, lan kesalahan manungsa ing pangukuran. Yen sampeyan duwe masalah karo pangukuran, waca bab kapindho saka buku "Akselerasi". Yen tim sampeyan mung duwe akeh praktik, nanging ora jelas praktik apa sing kudu ditrapake saiki, endi sing mengko, endi sing bener lan sing ora - maca, buku kasebut nerangake kabeh.
Transformasi minangka masalah ing persimpangan DevOps lan manajemen. Nang endi wae ing area persimpangan pembangunan, operasi lan tes sing padha yaiku topik sing kita coba rembugan , integrasi sing padha dibutuhake kanggo nggawe produk sing berkualitas - topik utama . Manajemen festival diwenehi - tegese saben wong ana kanggo gagasan kanggo transformasi. Gabung karo kita tanggal 27 lan 28 Mei, kita bakal nggabungake lan ngowahi.
Source: www.habr.com
