Negara DevOps ing Rusia 2020

Kepiye sampeyan ngerti kahanan apa wae?

Sampeyan bisa ngandelake pendapat sampeyan, dibentuk saka macem-macem sumber informasi, contone, publikasi ing situs web utawa pengalaman. Sampeyan bisa takon kolega lan kanca-kanca. Pilihan liyane yaiku ndeleng topik konferensi: panitia program minangka wakil aktif industri, mula kita dipercaya kanggo milih topik sing cocog. Wilayah sing kapisah yaiku riset lan laporan. Nanging ana masalah. Riset babagan negara DevOps ditindakake saben taun ing saindenging jagad, laporan diterbitake dening perusahaan asing, lan meh ora ana informasi babagan DevOps Rusia.

Nanging dina wis teka nalika sinau kasebut ditindakake, lan dina iki kita bakal ngandhani babagan asil sing dipikolehi. Negara DevOps ing Rusia ditliti bebarengan dening perusahaan "Ekspres 42"Lan"Ontiko" Perusahaan Express 42 mbantu perusahaan teknologi ngetrapake lan ngembangake praktik lan alat DevOps lan minangka salah sawijining sing pertama ngomong babagan DevOps ing Rusia. Penulis sinau, Igor Kurochkin lan Vitaly Khabarov, melu analisis lan konsultasi ing Express 42, duwe latar mburi teknis saka operasi lan pengalaman ing perusahaan sing beda-beda. Swara 8 taun, kolega nyawang Welasan perusahaan lan proyèk - saka startups kanggo Enterprises - karo masalah beda, uga kadewasan budaya lan engineering beda.

Ing laporan kasebut, Igor lan Vitaly nerangake apa masalah sing ana sajrone proses riset, kepiye cara ngrampungake, uga kepiye riset DevOps ditindakake kanthi prinsip lan kenapa Express 42 mutusake kanggo nindakake dhewe. Sampeyan bisa ndeleng laporan sing kene.

Riset DevOps

Igor Kurochkin miwiti obrolan.

Kita ajeg takon pamirsa ing konferensi DevOps: "Apa sampeyan wis maca laporan State of DevOps taun iki?" Mung sawetara sing ngangkat tangan, nanging riset kita nuduhake yen mung katelu sing nyinaoni. Yen sampeyan durung nate ndeleng laporan kaya ngono, ayo ngomong yen kabeh padha banget. Paling asring ana frasa kaya: "Dibandhingake taun kepungkur ..."

Ing kene kita duwe masalah pisanan, banjur loro maneh:

1. Kita ora duwe data kanggo taun kepungkur. Ora ana sing kasengsem ing negara DevOps ing Rusia;
2. Metodologi. Ora jelas carane nguji hipotesis, carane mbangun pitakonan, carane nindakake analisis, mbandhingake asil, nemokake sambungan;
3. Terminologi. Kabeh laporan ana ing basa Inggris, terjemahan dibutuhake, kerangka umum kanggo DevOps durung diciptakake lan saben wong nggawe dhewe.

Ayo goleki kepiye cara nganalisa kahanan DevOps ing jagad iki umume ditindakake.

Latar belakang Sajarah

Riset DevOps wis ditindakake wiwit 2011. Sing pisanan nindakake yaiku Wayang, pangembang sistem manajemen konfigurasi. Ing wektu iku, iku salah siji saka piranti utama kanggo njlèntrèhaké infrastruktur ing wangun kode. Nganti 2013, studi kasebut mung survey ing format tertutup lan tanpa laporan umum.

Ing 2013, Revolusi IT muncul, penerbit kabeh buku utama ing DevOps. Bebarengan karo Wayang, padha nyiapake publikasi pisanan "Negara DevOps", ing ngendi 4 metrik kunci muncul kanggo pisanan. Taun sabanjure, perusahaan konsultasi ThoughtWorks, sing dikenal kanthi radar teknologi biasa babagan praktik lan alat industri, melu. Lan ing 2015, bagean kanthi metodologi ditambahake, lan dadi jelas carane nindakake analisis kasebut.

Ing 2016, penulis sinau, nggawe perusahaan DORA (DevOps Research and Assessment), nerbitake laporan taunan. Ing taun candhake, DORA lan Wayang ngetokake laporan gabungan pungkasan.

Lan banjur dadi menarik:

Ing 2018, perusahaan pamisah lan loro laporan independen dirilis: siji saka Wayang, nomer loro saka DORA kanthi kolaborasi karo Google. DORA terus nggunakake metodologi kanthi metrik utama, profil kinerja lan praktik teknik sing mengaruhi metrik lan kinerja utama ing perusahaan. Lan Wayang ngusulake pendekatan kanthi deskripsi proses lan evolusi DevOps. Nanging crita kasebut ora kedadeyan; ing taun 2019, Wayang nilar metodologi iki lan ngrilis versi anyar saka laporan kasebut, sing nyathet praktik utama lan kepiye pengaruhe DevOps saka sudut pandange. Banjur kedadeyan liyane: Google tuku DORA, lan bareng-bareng ngeculake laporan liyane. Mbok menawa sampeyan wis weruh.

Taun iki perkara dadi rumit. Dikawruhi yen Wayang ngluncurake survey. Dheweke nindakake seminggu luwih awal tinimbang kita, lan wis rampung. We njupuk bagéyan ing lan weruh topik apa kasengsem wong. Wayang saiki nindakake analisis lan nyiapake kanggo nerbitake laporan kasebut.

Nanging isih durung ana pengumuman saka DORA lan Google. Ing wulan Mei, nalika survey biasane diwiwiti, ana informasi manawa Nicole Forsgren, salah sawijining pendiri DORA, wis pindhah menyang perusahaan liyane. Mula, kita nganggep ora ana riset utawa laporan saka DORA ing taun iki.

Kepiye kahanan ing Rusia?

Kita durung nindakake riset babagan DevOps. Kita ngomong ing konferensi, nyritakake maneh kesimpulan wong liya, lan Raiffeisenbank nerjemahake "State of DevOps" kanggo 2019 (sampeyan bisa nemokake woro-woro ing Habré), matur nuwun banget. Lan iku kabeh.

Mulane, kita nindakake riset dhewe ing Rusia nggunakake metodologi lan temuan DORA. Kita nggunakake laporan saka kolega saka Raiffeisenbank kanggo riset kita, kalebu kanggo nyinkronake terminologi lan terjemahan. Lan pitakonan sing cocog karo industri dijupuk saka laporan DORA lan kuesioner Wayang taun iki.

Proses riset

Laporan mung bagean pungkasan. Proses riset kabeh kasusun saka papat tahapan gedhe:

Sajrone tahap persiapan, kita diwawancarai pakar industri lan nyiapake dhaptar hipotesis. Adhedhasar kasebut, kita nyusun pitakonan lan ngluncurake survey kanggo kabeh wulan Agustus. Banjur kita nganalisa lan nyiapake laporan kasebut dhewe. Kanggo DORA, proses iki njupuk 6 sasi. Kita ngrampungake ing 3 sasi, lan saiki kita ngerti yen kita ora duwe cukup wektu: mung kanthi nindakake analisis sampeyan ngerti pitakonan apa sing kudu dijaluk.

peserta

Kabeh laporan manca diwiwiti kanthi potret peserta, lan umume ora saka Rusia. Persentase responden Rusia fluktuasi saka 5 nganti 1% saben taun, lan iki ora ngidini kita nggawe kesimpulan.

Peta saka laporan Accelerate State of DevOps 2019:

Ing panliten iki, kita bisa wawancara karo 889 wong - iki cukup akeh (survei DORA babagan sewu wong saben taun ing laporan) lan ing kene kita entuk target:

Bener, ora kabeh peserta tekan pungkasan: persentase rampung rada kurang saka setengah. Nanging iki cukup kanggo njupuk sampel perwakilan lan nindakake analisis. DORA ora ngumumake tingkat pendhudhukan ing laporane, mula ora bisa mbandhingake ing kene.

Industri lan posisi

Responden kita makili puluhan industri. Setengah kerja ing teknologi informasi. Iki diikuti dening layanan finansial, perdagangan, telekomunikasi lan liya-liyane. Antarane posisi kasebut yaiku spesialis (pengembang, penguji, insinyur operasi) lan staf manajemen (pimpinan tim, grup, wilayah, direktur):

Saben wong liya kerja ing perusahaan ukuran medium. Saben wong katelu kerja ing perusahaan gedhe. Umume kerja ing tim nganti 9 wong. Dhewe, kita takon babagan kegiatan utama, lan mayoritas ana ing salah sawijining cara utawa liyane sing ana gandhengane karo operasi, lan udakara 40% melu pembangunan:

Mangkene carane kita ngumpulake informasi kanggo mbandhingake lan analisis perwakilan saka industri, perusahaan, lan tim sing beda-beda. Kolegaku Vitaly Khabarov bakal ngandhani babagan analisis kasebut.

Analisis lan perbandingan

Vitaly Khabarov: Many thanks kanggo kabeh peserta sing ngrampungake survey kita, ngisi kuesioner lan menehi data kanggo analisis luwih lanjut lan nguji hipotesis kita. Lan matur nuwun kanggo klien lan pelanggan, kita duwe akeh pengalaman sing mbantu kita ngenali masalah sing dadi keprihatinan ing industri lan ngramu hipotesis sing diuji ing riset kita.

Sayange, sampeyan ora bisa mung njupuk dhaptar pitakonan ing tangan siji lan data ing tangan liyane, piye wae mbandhingake, ngomong: "Ya, kabeh tumindak kaya sing, kita padha tengen" lan pindhah cara kita kapisah. Ora, kita butuh metodologi lan metode statistik kanggo mesthekake yen kita ora salah lan kesimpulan kita bisa dipercaya. Banjur kita bisa mbangun karya luwih lanjut adhedhasar data iki:

Metrik kunci

Kita njupuk metodologi DORA minangka basis, sing diterangake kanthi rinci ing buku "Accelerate State of DevOps". Kita mriksa apa metrik kunci cocok kanggo pasar Rusia, apa bisa digunakake kanthi cara sing padha karo DORA kanggo njawab pitakonan: "Kepiye industri ing Rusia cocog karo industri manca?"

Metrik utama:

1. Frekuensi panyebaran. Sepira kerepe versi anyar saka aplikasi disebarake menyang lingkungan produksi (owah-owahan sing direncanakake, ora kalebu hotfix lan respon kedadeyan)?
2. wektu pangiriman. Apa wektu rata-rata antarane nindakake owah-owahan (fungsi nulis minangka kode) lan nyebarake owah-owahan menyang lingkungan produksi?
3. wektu Recovery. Suwene suwene rata-rata kanggo mulihake aplikasi ing lingkungan produksi sawise kedadeyan, degradasi layanan, utawa deteksi kesalahan sing mengaruhi pangguna aplikasi?
4. Owah-owahan sing ora kasil. Apa persentase penyebaran ing lingkungan produk sing nyebabake degradasi utawa kedadeyan aplikasi lan mbutuhake ngilangi akibat (ngganti owah-owahan, ngembangake hotfix utawa tembelan)?

Riset DORA nemokake hubungan antarane metrik kasebut lan kinerja organisasi. Kita uga mriksa ing sinau kita.

Nanging kanggo mesthekake yen papat metrik kunci bisa mengaruhi apa wae, sampeyan kudu ngerti - apa ana hubungane karo siji liyane? DORA mangsuli ya, kanthi siji caveat: hubungan antarane Tingkat Kegagalan Ganti lan telung metrik liyane rada lemah. Kita entuk gambar sing padha. Yen wektu pangiriman, frekuensi panyebaran lan wektu pemulihan ana hubungane karo saben liyane (kita netepake korélasi iki liwat korelasi Pearson lan liwat skala Chaddock), mula ora ana korélasi sing kuat karo owah-owahan sing ora kasil.

Ing asas, paling responden cenderung njawab sing padha duwe nomer cukup cilik saka kedadean ing produksi. Senajan kita bakal weruh mengko isih ana prabédan pinunjul antarane kelompok responden ing tingkat saka owah-owahan kasil, kita durung bisa nggunakake metrik iki kanggo divisi iki.

Kita ngubungake iki kanggo kasunyatan sing (kaya sing katon ing proses analisis lan komunikasi karo sawetara pelanggan) ana prabédan tipis ing persepsi apa sing dianggep minangka kedadeyan. Yen kita bisa mulihake fungsi layanan sajrone jendela teknis, apa iki bisa dianggep minangka kedadeyan? Mbokmenawa ora, amarga kita ndandani kabeh, kita apik. Apa bisa dianggep minangka kedadeyan yen kita kudu muter maneh aplikasi 10 kaping ing mode normal lan akrab? Kayane ora. Mulane, pitakonan babagan hubungan antarane owah-owahan sing ora kasil lan metrik liyane tetep mbukak. Kita bakal njlentrehake luwih.

Sing penting ing kene yaiku nemokake korélasi sing signifikan antarane wektu pangiriman, wektu pemulihan, lan frekuensi penyebaran. Mulane, kita njupuk telung metrik iki kanggo luwih dibagi responden menyang klompok adhedhasar produktivitas.

Carane akeh kanggo nimbang ing gram?

Kita nggunakake analisis cluster hierarkis:

• Kita nyebarake responden ing spasi n-dimensi, ing ngendi koordinat saben responden minangka jawaban kanggo pitakonan kasebut.
• We ngumumake saben responden minangka klompok cilik.
• Kita gabungke rong klompok sing paling cedhak dadi siji klompok sing luwih gedhe.
• Kita nemokake pasangan kluster sabanjure lan gabungke dadi kluster sing luwih gedhe.

Iki cara kita nglumpukake kabeh responden menyang jumlah klompok sing dibutuhake. Nggunakake dendrogram (wit sambungan antarane klompok) kita ndeleng jarak antarane rong klompok tetanggan. Kabeh sing isih ana kanggo kita yaiku nyetel watesan tartamtu ing jarak antarane klompok kasebut lan ujar: "Klompok loro iki bisa dibedakake amarga jarak ing antarane akeh banget."

Nanging ana masalah sing didhelikake ing kene: ora ana watesan babagan jumlah klompok - kita bisa entuk 2, 3, 4, 10 klompok. Lan ide pisanan yaiku - kenapa ora dibagi kabeh responden dadi 4 klompok, kaya sing ditindakake DORA. Nanging kita nemokake manawa beda antarane klompok kasebut dadi ora pati penting, lan kita ora bisa yakin manawa responden pancen kalebu klompoke lan dudu tetanggan. Kita durung bisa mbagi pasar Rusia dadi papat klompok. Mulane, kita netepake telung profil, ing antarane ana prabédan sing signifikan sacara statistik:

Sabanjure, kita nemtokake profil kanthi kluster: kita njupuk median kanggo saben metrik kanggo saben klompok lan nyusun tabel profil efisiensi. Nyatane, profil kinerja asil kanggo rata-rata peserta ing saben klompok dijupuk. Kita wis nemtokake telung profil efisiensi: Low, Medium, High:

Ing kene kita wis ngonfirmasi hipotesis yen 4 metrik kunci cocok kanggo nemtokake profil kinerja, lan bisa digunakake ing pasar Kulon lan Rusia. Ana prabédan antarane klompok, lan iku signifikan sacara statistik. Aku kaya kanggo nandheske sing ana prabédan pinunjul ing tegese antarane profil kinerja kanggo metrik saka owah-owahan kasil, sanajan kita ora pisanan dibagi responden dening parameter iki.

Banjur pitakonan muncul: carane nggunakake kabeh iki?

Cara nggunakake

Yen njupuk tim apa wae, 4 metrik kunci lan ditrapake ing meja, mula ing 85% kasus, kita ora bakal entuk pertandhingan lengkap - iki mung rata-rata peserta, lan dudu apa sing ana ing kasunyatan. Kita kabeh (lan saben tim) beda-beda.

We mriksa: kita njupuk penjawab lan profil kinerja DORA, lan katon ing carane akeh penjawab cocog kanggo siji utawa profil liyane. Kita nemokake yen mung 16% saka responden kanthi akurat tiba ing salah sawijining profil. Kabeh liyane kasebar nang endi wae ing antarane:

Iki tegese profil kinerja nduweni ruang lingkup sing winates. Kanggo njupuk kira-kira ing ngendi sampeyan lagi, sampeyan bisa nggunakake tabel iki: "Oh, kayane kita luwih cedhak karo Sedheng utawa Dhuwur!" Yen sampeyan ngerti arep menyang ngendi sabanjure, bisa uga cukup. Nanging yen goal sampeyan tetep, terus-terusan dandan, lan sampeyan pengin ngerti luwih tepat ing ngendi arep berkembang lan apa sing kudu dilakoni, dana tambahan dibutuhake. Kita disebut kalkulator:

• DORA kalkulator
• Kalkulator Ekspres 42* (ing pembangunan)
• Pangembangan dhewe (sampeyan bisa nggawe kalkulator internal dhewe).

Apa sing dibutuhake? Gawe ngerti:

• Apa tim ing organisasi kita cocog karo standar kita?
• Yen ora, apa kita bisa nulungi dheweke - nyepetake ing kerangka keahlian sing diduweni perusahaan kita?
• Yen mangkono, apa kita bisa nindakake luwih apik?

Sampeyan uga bisa digunakake kanggo ngumpulake statistik ing perusahaan:

• Apa jenis tim sing kita duwe?
• Dibagi tim menyang profil;
• Waca: Oh, tim iki kurang performa (agak alon), nanging iki apik banget: padha nyebar saben dina, tanpa kesalahan, wektu timbal kurang saka jam.

Banjur sampeyan bisa ngerteni manawa ing perusahaan kita duwe keahlian lan alat sing dibutuhake kanggo tim sing isih kurang.

Utawa, yen sampeyan ngerti manawa sampeyan rumangsa apik ing perusahaan, manawa sampeyan luwih apik tinimbang akeh, mula sampeyan bisa katon luwih wiyar. Iki persis industri Rusia: apa kita bisa entuk keahlian sing dibutuhake ing industri Rusia kanggo nyepetake awake dhewe? Kalkulator Express 42 bakal mbantu ing kene (saiki dikembangake). Yen sampeyan wis ngluwihi pasar Rusia, banjur deleng DORA kalkulator lan menyang pasar donya.

nggih. Lan yen sampeyan ana ing grup Elit miturut kalkulator DORA, banjur apa sing kudu sampeyan lakoni? Ora ana solusi sing apik ing kene. Paling kamungkinan, sampeyan ana ing ngarep ing industri, lan akselerasi luwih lan dandan linuwih bisa liwat R & D internal lan pangeluaran sumber daya gedhe.

Ayo pindhah menyang sisih paling manis - comparison.

Perbandingan

Kita pisanan pengin mbandhingake industri Rusia karo industri Kulon. Yen kita mbandhingake langsung, kita weruh yen kita duwe profil kurang, lan padha sethitik liyane dicampur karo saben liyane, wates sing sethitik liyane burem:

Elite-performers kita didhelikake ing antarane High-performers, nanging padha ana - iki elit, unicorns sing wis tekan dhuwur pinunjul. Ing Rusia, prabédan antarane profil Elite lan Dhuwur durung cukup signifikan. Kita mikir yen ing mangsa ngarep divisi iki bakal kedadeyan amarga paningkatan budaya teknik, kualitas implementasine praktik teknik lan keahlian ing perusahaan.

Yen kita pindhah menyang perbandingan langsung ing industri Rusia, kita bakal weruh manawa tim profil dhuwur luwih apik ing kabeh babagan. Kita uga ngonfirmasi hipotesis yen ana hubungane antarane metrik kasebut lan efektifitas organisasi: Tim profil dhuwur luwih cenderung ora mung entuk gol, nanging uga ngluwihi.
Ayo dadi tim profil dhuwur lan ora mandheg ing kono:

Nanging taun iki khusus, lan kita mutusake kanggo mriksa kepiye perusahaan urip ing pandemik: Tim profil dhuwur bisa ngatasi kanthi luwih apik lan rumangsa luwih apik tinimbang rata-rata industri:

• Produk anyar dirilis 1,5-2 kaping luwih asring,
• Tambah linuwih lan/utawa kinerja infrastruktur aplikasi 2 kaping luwih kerep.

Yaiku, kompetensi sing wis ana mbantu dheweke berkembang luwih cepet, ngenalake produk anyar, ngowahi produk sing wis ana, saengga bisa nelukake pasar anyar lan pangguna anyar:

Apa maneh sing mbantu tim kita?

Praktek teknik

Aku bakal ngandhani babagan temuan sing penting kanggo saben praktik sing kita priksa. Bisa uga ana sing mbantu tim kasebut, nanging kita ngomong babagan DevOps. Lan ing DevOps, kita ndeleng beda ing antarane tim sing beda-beda profil.

Platform minangka layanan

Kita ora nemokake hubungan sing signifikan antarane umur platform lan profil tim: Platform muncul ing wektu sing padha kanggo tim Low lan High. Nanging kanggo sing terakhir, platform kasebut nyedhiyakake layanan rata-rata luwih akeh lan antarmuka piranti lunak liyane kanggo kontrol liwat kode program. Lan tim platform luwih seneng mbantu pangembang lan tim nggunakake platform kasebut, luwih cenderung ngrampungake masalah lan kedadeyan sing ana gandhengane karo platform kasebut, lan nglatih tim liyane.

Infrastruktur minangka kode

Kabeh ing kene cukup standar. Kita nemokake hubungan antarane otomatisasi kode infrastruktur lan jumlah informasi sing disimpen ing repositori infrastruktur. Tim profil dhuwur nyimpen informasi luwih akeh ing repositori: iki kalebu konfigurasi infrastruktur, pipa CI / CD, setelan lingkungan lan paramèter mbangun. Padha nyimpen informasi iki luwih kerep, bisa luwih apik karo kode infrastruktur, lan wis otomatis liyane pangolahan lan tugas kanggo nggarap kode infrastruktur.

Apike, kita ora weruh prabédan signifikan ing tes infrastruktur. Aku ngubungake iki amarga tim profil dhuwur umume duwe otomatisasi tes luwih akeh. Mbok padha ora bakal ditampani dhewe dening tes infrastruktur, nanging rodo tes digunakake kanggo mriksa aplikasi cukup, lan thanks kanggo wong-wong mau padha bisa ndeleng apa lan ing ngendi padha rusak.

Integrasi lan Pangiriman

Bagean sing paling mboseni, amarga wis dikonfirmasi: luwih akeh otomatisasi, luwih apik sampeyan nggarap kode kasebut, luwih akeh sampeyan bakal entuk asil sing luwih apik.

arsitektur

Kita pengin ndeleng carane microservices mengaruhi kinerja. Jujur, ora, amarga panggunaan layanan mikro ora ana gandhengane karo paningkatan indikator efisiensi. Layanan mikro digunakake dening tim profil Dhuwur lan Low.

Nanging sing penting yaiku kanggo tim Dhuwur, transisi menyang arsitektur layanan mikro ngidini dheweke ngembangake layanan lan muter kanthi mandiri. Yen arsitektur ngidini pangembang kanggo tumindak autonomously, tanpa nunggu wong njaba kanggo tim, banjur iki kompetensi tombol kanggo nambah kacepetan. Iki ngendi microservices mbantu. Nanging mung implementasine ora duwe peran gedhe.

Kepiye carane kita nemokake kabeh iki?

Kita duwe rencana ambisi kanggo niru metodologi DORA kanthi lengkap, nanging ora duwe sumber daya. Yen DORA nggunakake akeh sponsor lan sinau njupuk enem sasi, kita nindakake sinau ing wektu cendhak. Kita pengin nggawe model DevOps kaya DORA, lan bakal ditindakake ing mangsa ngarep. Saiki kita mbatesi awake dhewe kanggo peta panas:

We katon ing distribusi saka laku engineering antarane tim saben profil, lan ketemu sing tim saka profil High, ing rata-rata, nggunakake laku engineering luwih kerep. Sampeyan bisa maca liyane babagan kabeh iki ing kita laporan.

Kanggo ngganti, ayo ngalih saka statistik rumit menyang sing prasaja.

Apa maneh sing wis ditemokake?

Piranti

Kita mirsani manawa kulawarga OS Linux nggunakake paling akeh perintah. Nanging Windows isih dadi tren - paling ora seprapat saka responden nyathet panggunaan siji utawa versi liyane. Pasar katon duwe kabutuhan iki. Mula, sampeyan bisa ngembangake kompetensi kasebut lan menehi presentasi ing konferensi.

Antarane orkestrator, iku ora rahasia sing Kubernetes mimpin (52%). Orkestrator sabanjure yaiku Docker Swarm (udakara 12%). Sistem CI sing paling populer yaiku Jenkins lan GitLab. Sistem manajemen konfigurasi sing paling populer yaiku Ansible, diikuti dening Shell sing ditresnani.

Antarane panyedhiya hosting awan, Amazon saiki duwe posisi utama. Panggabungan awan Rusia saya suwe saya mundhak. Taun ngarep bakal dadi menarik kanggo ndeleng kepiye para panyedhiya awan Rusia bakal ngrasa lan apa pangsa pasar bakal tambah. Dheweke ana, bisa digunakake, lan sing apik:

Aku menehi lantai kanggo Igor, sing bakal menehi sawetara statistik liyane.

Panyebaran laku

Igor Kurochkin: Kapisah, kita takon responden kanggo nunjukake carane praktik teknik sing dianggep disebarake ing perusahaan. Umume perusahaan duwe pendekatan campuran sing kalebu macem-macem pola, lan proyek pilot banget populer. Kita uga weruh prabédan tipis antarane profil. Perwakilan saka profil Dhuwur luwih kerep nggunakake pola "Inisiatif saka ngisor", nalika tim spesialis cilik ngganti proses kerja, alat, lan nuduhake perkembangan sing sukses karo tim liyane. Ing Medium, iki minangka inisiatif top-down sing ndemek kabeh perusahaan liwat nggawe komunitas lan pusat keunggulan:

Agile lan DevOps

Hubungan antarane Agile lan DevOps asring dibahas ing industri. Pitakonan iki uga ditimbulake ing Laporan Negara Agile kanggo 2019/2020, mula kita mutusake kanggo mbandhingake kepiye hubungane aktivitas Agile lan DevOps ing perusahaan. Kita wis nemokake yen DevOps tanpa Agile langka. Kanggo setengah saka responden, panyebaran Agile wiwit katon luwih awal, lan udakara 20% diamati wiwitan bebarengan, lan salah sawijining pratandha profil Low bakal ora ana praktik Agile lan DevOps:

Topologi tim

Ing pungkasan taun pungkasan buku "Topologi tim", sing ngusulake kerangka kanggo njlentrehake topologi tim. Kita kepingin weruh yen bakal ditrapake kanggo perusahaan Rusia. Lan kita takon pitakonan: "Pola apa sampeyan ndeleng?"

Tim infrastruktur diamati ing setengah saka responden, uga tim pangembangan, tes lan operasi sing kapisah. Tim DevOps individu nyathet 45%, ing antarane wakil High luwih umum. Sabanjure teka tim salib-fungsi, kang uga luwih umum ing High. Printah SRE sing kapisah katon ing profil Dhuwur, Sedheng lan arang ditemokake ing profil Kurang:

Rasio DevQaOps

Kita ndeleng pitakonan iki ing FaceBook saka pimpinan tim tim platform Skyeng - dheweke kasengsem ing rasio pangembang, penguji lan pangurus ing perusahaan. Kita takon lan ndeleng jawaban kanthi njupuk profil: wakil saka profil Dhuwur duwe nomer tes lan insinyur operasi sing luwih cilik kanggo saben pangembang:

Rencana kanggo 2021

Ing rencana kanggo taun ngarep, responden nyathet kegiatan ing ngisor iki:

Ing kene sampeyan bisa ndeleng persimpangan karo konferensi DevOps Live 2020. Kita mriksa program kasebut kanthi teliti:

• Infrastruktur minangka produk
• Transformasi DevOps
• Distribusi praktik DevOps
• DevSecOps
• Klub kasus lan diskusi

Nanging pirembagan kita ora bakal duwe wektu cukup kanggo nutupi kabeh topik. Neng mburi layar:

• Platform minangka layanan lan minangka produk;
• Infrastruktur minangka kode, lingkungan lan awan;
• Integrasi lan pangiriman terus-terusan;
• Arsitektur;
• Pola DevSecOps;
• Platform lan tim lintas fungsi.

Laporan Kita akeh banget, dawane 50 kaca, lan sampeyan bisa ndeleng kanthi luwih rinci.

Nyimpul

Muga-muga riset lan laporan bakal menehi inspirasi kanggo sampeyan nyoba pendekatan anyar kanggo pangembangan, tes, lan operasi, uga mbantu sampeyan entuk bantalan, mbandhingake dhewe karo wong liya ing sinau, lan ngenali wilayah sing bisa nambah pendekatan sampeyan dhewe. .

Asil panaliten pisanan babagan negara DevOps ing Rusia:

• Metrik kunci. Kita wis nemokake manawa metrik kunci (wektu pangiriman, tingkat penyebaran, wektu pemulihan, lan kegagalan pangowahan) cocog kanggo nganalisa efektifitas proses pangembangan, tes, lan operasi.
• Profil Dhuwur, Sedheng, Kurang. Adhedhasar data sing diklumpukake, bisa diidentifikasi klompok sing beda-beda kanthi statistik: Dhuwur, Sedheng, Kurang, kanthi fitur khas adhedhasar metrik, praktik, proses lan alat. Perwakilan saka profil Dhuwur nuduhake asil sing luwih apik tinimbang Low. Dheweke luwih seneng nggayuh lan ngluwihi tujuane.
• Indikator, pandemi lan rencana kanggo 2021. Indikator khusus taun iki yaiku kepiye perusahaan ngatasi pandemi kasebut. Dhuwur nindakake luwih apik, ngalami paningkatan aktivitas pangguna, lan alasan utama sukses yaiku proses pangembangan sing efisien lan budaya teknik sing kuwat.
• Praktek DevOps, alat lan pangembangane. Rencana utama perusahaan kanggo taun ngarep kalebu pangembangan praktik lan alat DevOps, introduksi praktik DevSecOps, lan owah-owahan ing struktur organisasi. Lan implementasine efektif lan pangembangan praktik DevOps ditindakake liwat proyek percontohan, pambentukan komunitas lan pusat kompetensi, inisiatif ing tingkat ndhuwur lan ngisor perusahaan.

Kita bakal seneng ngrungokake ulasan, crita, umpan balik sampeyan. Kita matur nuwun kanggo kabeh sing melu sinau lan ngarepake partisipasi sampeyan ing taun ngarep.

Source: www.habr.com