Keadaan DevOps di Rusia 2020

Bagaimana anda memahami keadaan sesuatu?

Anda boleh bergantung pada pendapat anda, dibentuk daripada pelbagai sumber maklumat, contohnya, penerbitan di laman web atau pengalaman. Anda boleh bertanya kepada rakan sekerja, kenalan. Pilihan lain ialah melihat topik persidangan: jawatankuasa program adalah wakil aktif industri, jadi kami mempercayai mereka dalam memilih topik yang berkaitan. Bidang yang berasingan ialah penyelidikan dan laporan. Tetapi ada masalah. Penyelidikan mengenai keadaan DevOps dijalankan setiap tahun di dunia, laporan diterbitkan oleh syarikat asing, dan hampir tiada maklumat tentang DevOps Rusia.

Tetapi hari telah tiba apabila kajian sedemikian dijalankan, dan hari ini kami akan memberitahu anda tentang keputusan yang diperolehi. Keadaan DevOps di Rusia dikaji bersama oleh syarikat "Ekspres 42"Dan"Ontico". Express 42 membantu syarikat teknologi melaksanakan dan membangunkan amalan dan alatan DevOps dan merupakan antara yang pertama bercakap tentang DevOps di Rusia. Penulis kajian, Igor Kurochkin dan Vitaly Khabarov, terlibat dalam analisis dan perundingan di Express 42, sambil mempunyai latar belakang teknikal dari operasi dan pengalaman dalam syarikat yang berbeza. Selama 8 tahun, rakan sekerja telah melihat berpuluh-puluh syarikat dan projek - daripada syarikat permulaan kepada perusahaan - dengan masalah yang berbeza, serta kematangan budaya dan kejuruteraan yang berbeza.

Dalam laporan mereka, Igor dan Vitaly menjelaskan masalah yang ada semasa proses penyelidikan, cara mereka menyelesaikannya, serta cara penyelidikan DevOps dijalankan secara prinsip dan sebab Express 42 memutuskan untuk menjalankan sendiri. Anda boleh melihat laporan mereka di sini.

Penyelidikan DevOps

Igor Kurochkin memulakan perbualan.

Kami kerap bertanya kepada penonton di persidangan DevOps, "Sudahkah anda membaca laporan status DevOps untuk tahun ini?" Sebilangan kecil yang mengangkat tangan mereka, dan kajian kami menunjukkan bahawa hanya satu pertiga yang mengkaji mereka. Jika anda tidak pernah melihat laporan sedemikian, katakan segera bahawa mereka semua sangat serupa. Selalunya terdapat frasa seperti: "Berbanding tahun lepas ..."

Di sini kita mempunyai masalah pertama, dan selepas itu dua lagi:

1. Kami tidak mempunyai data untuk tahun lepas. Tiada siapa yang berminat dengan keadaan DevOps di Rusia;
2. Metodologi. Tidak jelas cara menguji hipotesis, cara membina soalan, cara menganalisis, membandingkan keputusan, mencari sambungan;
3. Terminologi. Semua laporan adalah dalam bahasa Inggeris, terjemahan diperlukan, rangka kerja DevOps biasa masih belum dicipta dan semua orang menghasilkan mereka sendiri.

Mari kita lihat bagaimana analisis keadaan DevOps telah dilakukan di seluruh dunia.

Maklumat sejarah

Penyelidikan DevOps telah dijalankan sejak 2011. Yang pertama mengendalikannya ialah Puppet, pembangun sistem pengurusan konfigurasi. Pada masa itu, ia adalah salah satu alat utama untuk menerangkan infrastruktur dalam bentuk kod. Sehingga 2013, kajian ini hanyalah tinjauan dalam format tertutup dan tanpa laporan awam.

Pada tahun 2013, Revolusi IT muncul, penerbit semua buku utama di DevOps. Bersama-sama dengan Puppet, mereka menyediakan penerbitan State of DevOps yang pertama, di mana 4 metrik utama muncul buat kali pertama. Pada tahun berikutnya, ThoughtWorks, firma perunding yang terkenal dengan radar teknologi biasa mengenai amalan dan alatan industri, terlibat. Dan pada tahun 2015, bahagian dengan metodologi telah ditambah, dan menjadi jelas cara mereka melaksanakan analisis.

Pada 2016, pengarang kajian itu, setelah mencipta syarikat mereka DORA (Penyelidikan dan Penilaian DevOps), menerbitkan laporan tahunan. Pada tahun berikutnya, DORA dan Puppet mengeluarkan laporan akhir bersama mereka.

Dan kemudian perkara menjadi menarik:

Pada 2018, syarikat berpecah dan dua laporan bebas dikeluarkan: satu daripada Puppet, yang kedua daripada DORA dengan kerjasama Google. DORA terus menggunakan metodologinya dengan metrik utama, profil prestasi dan amalan kejuruteraan yang memberi kesan kepada metrik dan prestasi utama di seluruh syarikat. Dan Puppet mencadangkan pendekatannya dengan penerangan tentang proses dan evolusi DevOps. Tetapi cerita itu tidak menarik; pada tahun 2019, Puppet meninggalkan metodologi ini dan mengeluarkan versi baharu laporan, yang menyenaraikan amalan utama dan cara ia mempengaruhi DevOps dari sudut pandangan mereka. Kemudian perkara lain berlaku: Google membeli DORA, dan bersama-sama mereka mengeluarkan laporan lain. Mungkin anda pernah melihatnya.

Tahun ini keadaan menjadi rumit. Adalah diketahui bahawa Puppet melancarkan tinjauannya. Mereka melakukannya seminggu lebih awal daripada kami, dan ia telah pun selesai. Kami mengambil bahagian di dalamnya dan melihat topik yang menarik minat mereka. Puppet kini sedang menjalankan analisisnya dan bersiap sedia untuk menerbitkan laporan tersebut.

Tetapi masih tiada pengumuman dari DORA dan Google. Pada bulan Mei, apabila tinjauan biasanya bermula, maklumat datang bahawa Nicole Forsgren, salah seorang pengasas DORA, telah berpindah ke syarikat lain. Oleh itu, kami mengandaikan bahawa tidak akan ada penyelidikan dan laporan daripada DORA tahun ini.

Bagaimana keadaan di Rusia?

Kami tidak menjalankan sebarang penyelidikan tentang DevOps. Kami bercakap di persidangan, menceritakan semula kesimpulan orang lain, dan Raiffeisenbank menterjemah "State of DevOps" untuk 2019 (anda boleh menemui pengumuman mereka di Habré), terima kasih kepada mereka. Dan itu semua.

Oleh itu, kami menjalankan penyelidikan kami sendiri di Rusia menggunakan metodologi dan penemuan DORA. Kami menggunakan laporan rakan sekerja dari Raiffeisenbank untuk penyelidikan kami, termasuk untuk menyegerakkan istilah dan terjemahan. Dan soalan yang berkaitan dengan industri diambil daripada laporan DORA dan soal selidik Boneka tahun ini.

Proses penyelidikan

Laporan itu hanya bahagian akhir. Keseluruhan proses penyelidikan terdiri daripada empat peringkat besar:

Semasa fasa penyediaan, kami menemu bual pakar industri dan menyediakan senarai hipotesis. Berdasarkan mereka, kami menyusun soalan dan melancarkan tinjauan untuk keseluruhan bulan Ogos. Kemudian kami menganalisis dan menyediakan laporan itu sendiri. Untuk DORA, proses ini mengambil masa 6 bulan. Kami bertemu dalam masa 3 bulan, dan kini kami memahami bahawa kami hampir tidak mempunyai masa yang mencukupi: hanya dengan melakukan analisis anda memahami soalan yang perlu anda tanyakan.

Peserta

Semua laporan asing bermula dengan potret peserta, dan kebanyakan mereka bukan dari Rusia. Peratusan responden Rusia turun naik dari 5 hingga 1% dari tahun ke tahun, dan ini tidak membenarkan kami membuat sebarang kesimpulan.

Peta daripada laporan Accelerate State of DevOps 2019:

Dalam kajian kami, kami berjaya menemu bual 889 orang - ini agak banyak (DORA meninjau kira-kira seribu orang setiap tahun dalam laporannya) dan di sini kami telah mencapai matlamat:

Benar, tidak semua peserta kami mencapai penghujung: peratusan penyiapan adalah kurang daripada separuh. Tetapi ini sudah cukup untuk mendapatkan sampel yang mewakili dan menjalankan analisis. DORA tidak mendedahkan kadar penghunian dalam laporannya, jadi perbandingan tidak boleh dibuat di sini.

Industri dan jawatan

Responden kami mewakili sedozen industri. Separuh kerja dalam teknologi maklumat. Ini diikuti oleh perkhidmatan kewangan, perdagangan, telekomunikasi dan lain-lain. Antara jawatan tersebut ialah pakar (pembangun, penguji, jurutera operasi) dan kakitangan pengurusan (ketua pasukan, kumpulan, kawasan, pengarah):

Setiap orang kedua bekerja di syarikat bersaiz sederhana. Setiap orang ketiga bekerja di syarikat besar. Kebanyakan bekerja dalam pasukan sehingga 9 orang. Secara berasingan, kami bertanya tentang aktiviti utama, dan majoriti dalam satu atau lain cara berkaitan dengan operasi, dan kira-kira 40% terlibat dalam pembangunan:

Jadi kami mengumpul maklumat untuk perbandingan dan analisis wakil industri, syarikat, pasukan yang berbeza. Rakan sekerja saya Vitaly Khabarov akan memberitahu tentang analisis.

Analisis dan perbandingan

Vitaly Khabarov: Terima kasih banyak kepada semua peserta yang melengkapkan tinjauan kami, mengisi soal selidik dan memberi kami data untuk analisis lanjut dan ujian hipotesis kami. Dan terima kasih kepada pelanggan dan pelanggan kami, kami mempunyai banyak pengalaman yang telah membantu kami mengenal pasti isu yang membimbangkan industri dan merumuskan hipotesis yang kami uji dalam penyelidikan kami.

Malangnya, anda tidak boleh hanya mengambil senarai soalan di satu pihak dan data di pihak yang lain, entah bagaimana membandingkannya, katakan: "Ya, semuanya berfungsi seperti itu, kami betul" dan pergi ke arah yang berbeza. Tidak, kami memerlukan metodologi dan kaedah statistik untuk memastikan bahawa kami tidak tersilap dan bahawa kesimpulan kami boleh dipercayai. Kemudian kita boleh membina kerja selanjutnya berdasarkan data ini:

Metrik utama

Kami mengambil metodologi DORA sebagai asas, yang mereka jelaskan secara terperinci dalam buku "Accelerate State of DevOps". Kami menyemak sama ada metrik utama sesuai untuk pasaran Rusia, sama ada ia boleh digunakan dengan cara yang sama seperti yang digunakan DORA untuk menjawab soalan: "Bagaimanakah industri di Rusia sepadan dengan industri asing?"

Metrik utama:

1. Kekerapan penggunaan. Berapa kerapkah versi baharu aplikasi digunakan pada persekitaran pengeluaran (perubahan yang dirancang, tidak termasuk pembaikan terkini dan tindak balas insiden)?
2. Masa penghantaran. Apakah purata masa antara melakukan perubahan (fungsi menulis sebagai kod) dan menggunakan perubahan kepada persekitaran pengeluaran?
3. Masa pemulihan. Berapa lama masa yang diambil secara purata untuk memulihkan aplikasi kepada persekitaran pengeluaran selepas insiden, kemerosotan perkhidmatan atau penemuan pepijat yang menjejaskan pengguna aplikasi?
4. Perubahan yang tidak berjaya. Berapakah peratusan penggunaan dalam persekitaran pengeluaran yang membawa kepada kemerosotan atau insiden aplikasi dan memerlukan pemulihan (pemulihan semula perubahan, pembangunan hotfix atau tampung)?

DORA dalam penyelidikannya telah menemui hubungan antara metrik ini dan prestasi organisasi. Kami juga menyemaknya dalam kajian kami.

Tetapi untuk memastikan bahawa empat metrik utama boleh mempengaruhi sesuatu, anda perlu memahami - adakah ia berkaitan antara satu sama lain? DORA menjawab secara afirmatif dengan satu kaveat: hubungan antara perubahan yang tidak berjaya (Kadar Kegagalan Perubahan) dan tiga metrik lain adalah lebih lemah sedikit. Kami mendapat gambar yang sama. Jika masa penghantaran, kekerapan penggunaan dan masa pemulihan berkait antara satu sama lain (kami mewujudkan korelasi ini melalui korelasi Pearson dan melalui skala Chaddock), maka tidak ada korelasi yang begitu kuat dengan perubahan yang tidak berjaya.

Pada dasarnya, kebanyakan responden cenderung menjawab bahawa mereka mempunyai bilangan insiden yang agak kecil dalam pengeluaran. Walaupun kita akan lihat kemudian bahawa masih terdapat perbezaan yang ketara antara kumpulan responden dari segi perubahan yang tidak berjaya, kita belum boleh menggunakan metrik ini untuk bahagian ini.

Kami mengaitkan ini dengan fakta bahawa (seperti yang ternyata semasa analisis dan komunikasi dengan beberapa pelanggan kami) terdapat sedikit perbezaan dalam persepsi tentang perkara yang dianggap sebagai insiden. Jika kami berjaya memulihkan prestasi perkhidmatan kami semasa tetingkap teknikal, adakah ini boleh dianggap sebagai insiden? Mungkin tidak, kerana kami membetulkan segala-galanya, kami hebat. Bolehkah kami menganggapnya sebagai insiden jika kami terpaksa melancarkan semula permohonan kami 10 kali dalam mod biasa dan biasa untuk kami? Nampaknya tidak. Oleh itu, persoalan tentang hubungan perubahan yang tidak berjaya dengan metrik lain masih terbuka. Kami akan memperhalusinya lagi.

Yang penting di sini ialah kami mendapati korelasi yang ketara antara masa penghantaran, masa pemulihan dan kekerapan penggunaan. Oleh itu, kami mengambil ketiga-tiga metrik ini untuk membahagikan lagi responden kepada kumpulan prestasi.

Berapa banyak yang digantung dalam gram?

Kami menggunakan analisis kelompok hierarki:

• Kami mengedarkan responden pada ruang dimensi-n, di mana koordinat setiap responden ialah jawapan mereka kepada soalan.
• Setiap responden diisytiharkan sebagai kelompok kecil.
• Kami menggabungkan dua kluster yang paling hampir antara satu sama lain menjadi satu kluster yang lebih besar.
• Kami mencari pasangan gugusan seterusnya dan menggabungkannya menjadi gugusan yang lebih besar.

Beginilah cara kami mengumpulkan semua responden kami ke dalam bilangan kelompok yang kami perlukan. Dengan bantuan dendrogram (pokok sambungan antara gugusan), kita melihat jarak antara dua gugusan yang berdekatan. Apa yang tinggal untuk kita ialah menetapkan had jarak tertentu antara gugusan ini dan berkata: "Kedua-dua kumpulan ini agak boleh dibezakan antara satu sama lain kerana jarak di antara mereka sangat besar."

Tetapi terdapat masalah tersembunyi di sini: kami tidak mempunyai sekatan pada bilangan kluster - kita boleh mendapatkan 2, 3, 4, 10 kluster. Dan idea pertama ialah - mengapa tidak membahagikan semua responden kami kepada 4 kumpulan, seperti yang dilakukan oleh DORA. Tetapi kami mendapati bahawa perbezaan antara kumpulan ini menjadi tidak ketara, dan kami tidak dapat memastikan bahawa responden benar-benar tergolong dalam kumpulannya dan bukan milik jiran. Kami belum boleh membahagikan pasaran Rusia kepada empat kumpulan. Oleh itu, kami menetapkan tiga profil, di antaranya terdapat perbezaan yang signifikan secara statistik:

Seterusnya, kami menentukan profil mengikut kelompok: kami mengambil median untuk setiap metrik untuk setiap kumpulan dan menyusun jadual profil kecekapan. Malah, profil prestasi yang terhasil untuk purata peserta dalam setiap kumpulan telah diperolehi. Kami telah mengenal pasti tiga profil kecekapan: Rendah, Sederhana, Tinggi:

Di sini kami mengesahkan hipotesis kami bahawa 4 metrik utama sesuai untuk menentukan profil prestasi, dan ia berfungsi di pasaran Barat dan Rusia. Terdapat perbezaan antara kumpulan dan ia adalah signifikan secara statistik. Saya menekankan bahawa terdapat perbezaan yang ketara antara profil prestasi dari segi metrik perubahan yang tidak berjaya dari segi purata, walaupun pada mulanya kami tidak membahagikan responden dengan parameter ini.

Kemudian persoalan timbul: bagaimana untuk menggunakan semua ini?

Bagaimana nak guna

Jika kami mengambil mana-mana pasukan, 4 metrik utama dan menerapkannya pada jadual, maka dalam 85% kes kami tidak akan mendapat perlawanan yang lengkap - ini hanyalah peserta biasa, dan bukan apa yang sebenarnya. Kami semua (dan setiap pasukan) sedikit berbeza.

Kami menyemak: kami mengambil responden kami dan profil prestasi DORA, dan melihat bilangan responden yang sesuai dengan profil ini atau profil itu. Kami mendapati bahawa hanya 16% daripada responden pasti jatuh ke dalam salah satu profil. Semua yang lain bertaburan di suatu tempat di antara:

Ini bermakna profil prestasi mempunyai skop yang terhad. Untuk mendapatkan anggaran pertama tempat anda berada, anda boleh menggunakan jadual ini: "Oh, nampaknya kami lebih dekat dengan Sederhana atau Tinggi!" Jika anda faham ke mana anda akan pergi seterusnya, itu mungkin sudah memadai. Tetapi jika matlamat anda berterusan, penambahbaikan berterusan, dan anda ingin mengetahui dengan lebih tepat tempat untuk dibangunkan dan perkara yang perlu dilakukan, maka dana tambahan diperlukan. Kami memanggil mereka kalkulator:

• kalkulator DORA
• Kalkulator Ekspres 42* (dalam pembangunan)
• Pembangunan sendiri (anda boleh membuat kalkulator dalaman anda sendiri).

Untuk apa mereka diperlukan? Untuk memahami:

• Adakah pasukan dalam organisasi kita memenuhi piawaian kita?
• Jika tidak, bolehkah kami membantunya - mempercepatkannya dalam rangka kerja kepakaran yang dimiliki oleh syarikat kami?
• Jika ya, bolehkah kita berbuat lebih baik?

Anda juga boleh menggunakannya untuk mengumpul statistik dalam syarikat:

• Pasukan apa yang kita ada?
• Bahagikan pasukan ke dalam profil;
• Lihat: Oh, pasukan ini berprestasi rendah (sedikit perlahan), tetapi ini hebat: mereka menggunakan setiap hari, tanpa ralat, masa utama mereka kurang daripada satu jam.

Dan kemudian anda boleh mengetahui bahawa dalam syarikat kami, kami mempunyai kepakaran dan alatan yang diperlukan untuk pasukan yang masih kurang.

Atau, jika anda memahami bahawa anda berasa hebat dalam syarikat, bahawa anda lebih baik daripada ramai, maka anda boleh melihat sedikit lebih luas. Inilah tepatnya industri Rusia: bolehkah kita mendapatkan kepakaran yang diperlukan dalam industri Rusia untuk mempercepatkan diri kita? Kalkulator Express 42 akan membantu di sini (ia sedang dibangunkan). Jika anda telah mengatasi pasaran Rusia, maka lihat kalkulator DORA dan ke pasaran dunia.

baik. Dan jika anda berada dalam kumpulan Elit pada kalkulator DORA, apakah yang perlu anda lakukan? Tiada penyelesaian yang baik di sini. Anda berkemungkinan besar berada di barisan hadapan dalam industri, dan pecutan dan kebolehpercayaan selanjutnya boleh dilakukan melalui R&D dalaman dan membelanjakan lebih banyak sumber.

Mari kita beralih ke bahagian yang paling manis - perbandingan.

Perbandingan

Kami pada mulanya ingin membandingkan industri Rusia dengan industri Barat. Jika kita membandingkan secara langsung, kita melihat bahawa kita mempunyai lebih sedikit profil, dan mereka sedikit lebih bercampur antara satu sama lain, sempadannya lebih kabur sedikit:

Pemain berprestasi Elit kami tersembunyi di kalangan berprestasi Tinggi, tetapi mereka ada di sana - mereka adalah elit, unicorn yang telah mencapai tahap yang tinggi. Di Rusia, perbezaan antara profil Elit dan Tinggi masih belum cukup ketara. Kami berpendapat bahawa pada masa hadapan bahagian ini akan berlaku disebabkan oleh peningkatan dalam budaya kejuruteraan, kualiti pelaksanaan amalan kejuruteraan dan kepakaran dalam syarikat.

Jika kita beralih kepada perbandingan langsung dalam industri Rusia, kita melihat bahawa pasukan berprofil tinggi adalah lebih baik dalam semua aspek. Kami juga mengesahkan hipotesis kami bahawa terdapat kaitan antara metrik ini dan keberkesanan organisasi: Pasukan berprofil tinggi secara ketara lebih berkemungkinan bukan sahaja mencapai matlamat, tetapi juga melebihi mereka.
Mari menjadi pasukan berprofil tinggi dan tidak berhenti di situ:

Tetapi tahun ini istimewa, dan kami memutuskan untuk menyemak cara syarikat hidup dalam wabak: Pasukan berprofil tinggi menghadapi dengan lebih baik dan berasa lebih baik daripada purata industri:

• 1,5-2 kali lebih berkemungkinan mengeluarkan produk baharu,
• Peningkatan kebolehpercayaan dan/atau prestasi infrastruktur aplikasi 2 kali lebih kerap.

Iaitu, kecekapan yang telah mereka miliki membantu mereka membangun dengan lebih pantas, memperkenalkan produk baharu, mengubah suai produk sedia ada, dengan itu menakluki pasaran baharu dan pengguna baharu:

Apa lagi yang telah membantu pasukan kami?

Amalan kejuruteraan

Saya akan memberitahu anda tentang penemuan penting untuk setiap amalan yang kami uji. Mungkin sesuatu yang lain membantu pasukan, tetapi kita bercakap tentang DevOps. Dan dalam DevOps, kami melihat perbezaan antara pasukan profil yang berbeza.

Platform sebagai perkhidmatan

Kami tidak menemui hubungan yang signifikan antara umur platform dan profil pasukan: Platform muncul pada masa yang hampir sama untuk pasukan Rendah dan Pasukan Tinggi. Tetapi untuk yang terakhir, platform menyediakan, secara purata, lebih banyak perkhidmatan dan lebih banyak antara muka pengaturcaraan untuk kawalan melalui kod program. Dan pasukan platform lebih berkemungkinan membantu pembangun dan pasukan mereka menggunakan platform, menyelesaikan masalah mereka dan insiden berkaitan platform dengan lebih kerap, dan mendidik pasukan lain.

Infrastruktur sebagai kod

Semuanya di sini agak standard. Kami telah menemui hubungan antara mengautomasikan kerja kod infrastruktur dan jumlah maklumat yang disimpan di dalam repositori infrastruktur. Perintah profil tinggi menyimpan lebih banyak maklumat dalam repositori: ini ialah konfigurasi infrastruktur, saluran paip CI / CD, tetapan persekitaran dan parameter binaan. Mereka menyimpan maklumat ini dengan lebih kerap, berfungsi lebih baik dengan kod infrastruktur dan mengautomasikan lebih banyak proses dan tugas untuk bekerja dengan kod infrastruktur.

Menariknya, kami tidak melihat perbezaan yang ketara dalam ujian infrastruktur. Saya mengaitkannya dengan fakta bahawa pasukan berprofil tinggi biasanya mempunyai lebih banyak automasi ujian. Mungkin mereka tidak sepatutnya terganggu secara berasingan oleh ujian infrastruktur, sebaliknya ujian yang mereka gunakan untuk menyemak aplikasi sudah mencukupi, dan terima kasih kepada mereka, mereka dapat melihat apa dan di mana mereka telah rosak.

Integrasi dan Penyampaian

Bahagian yang paling membosankan, kerana kami mengesahkan bahawa lebih banyak automasi yang anda miliki, lebih baik anda bekerja dengan kod, lebih besar kemungkinan anda mendapat hasil yang lebih baik.

seni bina

Kami ingin melihat cara perkhidmatan mikro memberi kesan kepada prestasi. Sejujurnya, mereka tidak, kerana penggunaan perkhidmatan mikro tidak dikaitkan dengan peningkatan dalam penunjuk kecekapan. Perkhidmatan mikro digunakan oleh kedua-dua pasukan berprofil Tinggi dan Rendah.

Tetapi apa yang penting ialah untuk Pasukan Tinggi, peralihan kepada seni bina perkhidmatan mikro membolehkan mereka membangunkan perkhidmatan mereka secara bebas dan melancarkannya. Jika seni bina membenarkan pembangun bertindak secara autonomi, tanpa menunggu seseorang di luar pasukan, maka ini adalah kecekapan utama untuk meningkatkan kelajuan. Di sinilah perkhidmatan mikro membantu. Tetapi secara ringkas pelaksanaannya tidak memainkan peranan yang besar.

Bagaimanakah kami menemui semua ini?

Kami mempunyai rancangan bercita-cita tinggi untuk meniru sepenuhnya metodologi DORA, tetapi kekurangan sumber. Jika DORA menggunakan banyak tajaan dan penyelidikan mereka mengambil masa setengah tahun, kami melakukan penyelidikan kami dalam masa yang singkat. Kami mahu membina model DevOps seperti yang DORA lakukan, dan kami akan melakukannya pada masa hadapan. Setakat ini kami telah mengehadkan diri kami kepada peta haba:

Kami melihat pengedaran amalan kejuruteraan di kalangan pasukan setiap profil, dan mendapati bahawa pasukan berprofil Tinggi, secara purata, menggunakan amalan kejuruteraan dengan lebih kerap. Anda boleh membaca lebih lanjut tentang semua ini dalam kami laporan.

Untuk perubahan, mari beralih daripada statistik yang kompleks kepada yang mudah.

Apa lagi yang telah kami temui?

Tools

Kami mendapati bahawa keluarga OS Linux menggunakan paling banyak arahan. Tetapi Windows masih dalam trend - sekurang-kurangnya satu perempat daripada responden kami menyatakan penggunaan satu atau versi lain daripadanya. Pasaran nampaknya mempunyai keperluan ini. Oleh itu, anda boleh membangunkan kecekapan ini dan memberikan pembentangan di persidangan.

Di kalangan orkestra, ia bukan satu rahsia bagi sesiapa, Kubernetes mendahului (52%). Orkestra baris seterusnya ialah Docker Swarm (kira-kira 12%). Sistem CI yang paling popular ialah Jenkins dan GitLab. Sistem pengurusan konfigurasi yang paling popular ialah Ansible, diikuti oleh Shell kesayangan kami.

Di antara penyedia hosting awan, Amazon kini menduduki kedudukan utama. Bahagian awan Rusia secara beransur-ansur meningkat. Tahun depan adalah menarik untuk melihat bagaimana perasaan penyedia awan Rusia dan sama ada bahagian pasaran mereka akan meningkat. Mereka wujud, mereka boleh digunakan, dan itu bagus:

Saya menyerahkan lantai kepada Igor, yang akan memberikan lebih banyak statistik.

Penyebaran amalan

Igor Kurochkin: Secara berasingan, kami meminta responden untuk menunjukkan bagaimana amalan kejuruteraan yang dipertimbangkan diedarkan dalam syarikat. Kebanyakan syarikat mempunyai pendekatan campuran yang terdiri daripada set corak yang berbeza, dan projek perintis sangat popular. Kami juga melihat sedikit perbezaan antara profil. Wakil Profil Tinggi lebih kerap menggunakan corak "Inisiatif dari bawah", apabila pasukan kecil pakar menukar proses kerja, alatan dan berkongsi perkembangan yang berjaya dengan pasukan lain. Di Medium, ini adalah inisiatif atas ke bawah yang menyentuh seluruh syarikat melalui penciptaan komuniti dan pusat kecemerlangan:

Agile dan DevOps

Persoalan kaitan antara Agile dan DevOps sering dibincangkan dalam industri. Isu ini juga dibangkitkan dalam Laporan Keadaan Agile untuk 2019/2020, jadi kami memutuskan untuk membandingkan cara aktiviti Agile dan DevOps disambungkan dalam syarikat. Kami mendapati bahawa DevOps tanpa Agile jarang berlaku. Bagi separuh daripada responden, penyebaran Agile bermula lebih awal, dan kira-kira 20% memerhatikan permulaan serentak, dan salah satu tanda Profil Rendah ialah ketiadaan amalan Agile dan DevOps:

Topologi pasukan

Pada akhir tahun lepas buku “Topologi pasukan”, yang mencadangkan rangka kerja untuk menerangkan topologi arahan. Ia menjadi menarik kepada kami sama ada ia terpakai kepada syarikat Rusia. Dan kami bertanya soalan: "Apakah corak yang anda dapati?".

Pasukan infrastruktur diperhatikan dalam separuh daripada responden, serta pasukan pembangunan, ujian dan operasi yang berasingan. Pasukan DevOps individu mencatatkan 45%, antaranya wakil Tinggi adalah lebih biasa. Seterusnya ialah pasukan silang fungsi, yang juga lebih biasa di High. Arahan SRE yang berasingan muncul dalam profil Tinggi, Sederhana dan jarang dilihat dalam profil Rendah:

Nisbah DevQaOps

Kami melihat soalan ini di FaceBook daripada ketua pasukan pasukan platform Skyeng - dia berminat dengan nisbah pembangun, penguji dan pentadbir dalam syarikat. Kami bertanya dan melihat jawapan dengan mengambil kira profil: wakil Profil Tinggi mempunyai bilangan jurutera ujian dan operasi yang lebih kecil untuk setiap pembangun:

Pelan untuk tahun 2021

Dalam rancangan mereka untuk tahun hadapan, responden menyatakan aktiviti berikut:

Di sini anda boleh melihat persimpangan dengan persidangan DevOps Live 2020. Kami menyemak program dengan teliti:

• Infrastruktur sebagai produk
• Transformasi DevOps
• Pengagihan amalan DevOps
• DevSecOps
• Kelab kes dan perbincangan

Tetapi masa pembentangan kami tidak mencukupi untuk menampung semua topik. Tertinggal di belakang tabir:

• Platform sebagai perkhidmatan dan sebagai produk;
• Infrastruktur sebagai kod, persekitaran dan awan;
• Penyepaduan dan penyampaian berterusan;
• Seni bina;
• Corak DevSecOps;
• Pasukan platform dan silang fungsi.

Laporan Halaman kami adalah besar, 50 muka surat panjang, dan anda boleh melihatnya dengan lebih terperinci.

Merumuskan

Kami berharap bahawa penyelidikan dan laporan kami akan memberi inspirasi kepada anda untuk bereksperimen dengan pendekatan baharu untuk pembangunan, ujian dan operasi, serta membantu anda mendapatkan kesan anda, membandingkan diri anda dengan orang lain dalam kajian dan mengenal pasti bidang yang anda boleh memperbaiki pendekatan anda sendiri .

Keputusan kajian pertama keadaan DevOps di Rusia:

• Metrik utama. Kami telah mendapati bahawa metrik utama (masa penghantaran, kekerapan penggunaan, masa pemulihan dan kegagalan perubahan) sesuai untuk menganalisis keberkesanan proses pembangunan, ujian dan operasi.
• Profil Tinggi, Sederhana, Rendah. Berdasarkan data yang dikumpul, adalah mungkin untuk mengenal pasti kumpulan yang berbeza secara statistik: Tinggi, Sederhana, Rendah, dengan ciri tersendiri berdasarkan metrik, amalan, proses dan alatan. Wakil profil Tinggi menunjukkan hasil yang lebih baik daripada Rendah. Mereka lebih cenderung untuk mencapai dan melebihi matlamat mereka.
• Petunjuk, wabak dan rancangan untuk 2021. Penunjuk khas tahun ini ialah cara syarikat menghadapi wabak itu. Wakil Tinggi bernasib baik, mengalami peningkatan penglibatan pengguna, dan sebab utama kejayaan adalah proses pembangunan yang cekap dan budaya kejuruteraan yang kukuh.
• Amalan, alatan dan pembangunan DevOps. Rancangan utama syarikat untuk tahun hadapan termasuk pembangunan amalan dan alatan DevOps, pengenalan amalan DevSecOps dan perubahan dalam struktur organisasi. Dan pelaksanaan berkesan dan pembangunan amalan DevOps dijalankan dengan bantuan projek perintis, pembentukan komuniti dan pusat kecemerlangan, inisiatif di peringkat atasan dan bawahan syarikat.

Kami akan gembira mendengar ulasan, cerita, maklum balas anda. Kami mengucapkan terima kasih kepada semua yang mengambil bahagian dalam kajian ini dan mengharapkan penyertaan anda pada tahun hadapan.

Sumber: www.habr.com