Anda dapat mengandalkan opini Anda, yang dibentuk dari berbagai sumber informasi, misalnya, publikasi di situs atau pengalaman. Anda bisa bertanya kepada kolega dan kenalan. Pilihan lain adalah melihat topik konferensi: panitia program adalah perwakilan aktif industri, jadi kami mempercayai mereka dalam memilih topik yang relevan. Area terpisah adalah penelitian dan laporan. Tapi ada masalah. Penelitian tentang keadaan DevOps dilakukan setiap tahun di dunia, laporan diterbitkan oleh perusahaan asing dan hampir tidak ada informasi tentang DevOps Rusia.
Tetapi saatnya telah tiba ketika studi seperti itu dilakukan, dan hari ini kami akan memberi tahu Anda tentang hasil yang diperoleh. Keadaan DevOps di Rusia diselidiki bersama oleh Express 42 dan Ontiko". Express 42 membantu perusahaan teknologi menerapkan dan mengembangkan praktik dan alat DevOps dan merupakan salah satu orang pertama yang berbicara tentang DevOps di Rusia. Penulis penelitian, Igor Kurochkin dan Vitaly Khabarov, terlibat dalam analisis dan konsultasi di Express 42, memiliki latar belakang teknis dari operasi dan pengalaman kerja di berbagai perusahaan. Selama 8 tahun, kolega telah melihat lusinan perusahaan dan proyek - dari startup hingga perusahaan - dengan masalah yang berbeda, serta kematangan budaya dan teknik yang berbeda.
Dalam laporannya, Igor dan Vitaly menceritakan masalah apa saja yang ada dalam proses penelitian, bagaimana mereka menyelesaikannya, serta bagaimana penelitian DevOps dilakukan pada prinsipnya dan mengapa Express 42 memutuskan untuk melakukan sendiri. Laporan mereka dapat dilihat di sini .
Riset DevOps
Igor Kurochkin memulai percakapan.
Kami secara teratur mengajukan pertanyaan kepada audiens di konferensi DevOps: "Sudahkah Anda membaca laporan status DevOps untuk tahun ini?" Hanya sedikit yang mengangkat tangan, dan penelitian kami menunjukkan bahwa hanya sepertiga yang mempelajari mereka. Jika Anda belum pernah melihat laporan seperti itu, katakanlah langsung bahwa semuanya sangat mirip. Paling sering ada frasa seperti: "Dibandingkan tahun lalu ..."
Di sini kita memiliki masalah pertama, dan setelah itu dua lagi:
- Kami tidak memiliki data selama setahun terakhir. Status DevOps di Rusia tidak menarik bagi siapa pun;
- Metodologi. Tidak jelas bagaimana menguji hipotesis, bagaimana membangun pertanyaan, bagaimana melakukan analisis, membandingkan hasil, menemukan hubungan;
- Terminologi. Semua laporan dalam bahasa Inggris, terjemahan diperlukan, kerangka kerja DevOps umum belum ditemukan dan semua orang membuat sendiri.
Mari kita lihat bagaimana analisis keadaan DevOps di seluruh dunia dilakukan secara umum.
Referensi sejarah
Riset DevOps telah dilakukan sejak 2011. Yang pertama dipegang oleh Puppet, seorang pengembang sistem manajemen konfigurasi. Saat itu, ini adalah salah satu alat utama untuk mendeskripsikan infrastruktur dalam bentuk kode. Hingga tahun 2013, studi ini hanya berupa survei tertutup dan tanpa laporan publik.
Di 2013, Revolusi TI lahir, penerbit semua buku DevOps utama. Bersama dengan Puppet, mereka mempersiapkan publikasi pertama "State of DevOps", di mana 4 metrik utama muncul untuk pertama kalinya. Tahun berikutnya, ThoughtWorks, sebuah perusahaan konsultan yang terkenal dengan radar teknologi regulernya pada praktik dan alat industri, bergabung. Dan pada 2015, bagian metodologi ditambahkan, dan menjadi jelas bagaimana mereka melakukan analisis.
Pada tahun 2016, penulis studi, setelah membuat DORA perusahaan mereka (Penelitian dan Penilaian DevOps), menerbitkan laporan tahunan. Tahun berikutnya, DORA dan Puppet merilis laporan bersama untuk terakhir kalinya.
Dan kemudian yang menarik dimulai:
Pada tahun 2018, perusahaan tersebut berpisah dan dua laporan independen dirilis: satu dari Puppet, yang lain dari DORA sehubungan dengan Google. DORA terus menggunakan metodologinya dengan metrik utama, profil kinerja, dan praktik teknik yang memengaruhi metrik utama dan kinerja di seluruh perusahaan. Dan Puppet menawarkan pendekatannya sendiri yang menggambarkan proses dan evolusi DevOps. Namun ceritanya tidak menarik, pada tahun 2019 Puppet meninggalkan metodologi ini dan merilis versi baru dari laporan tersebut, yang mencantumkan praktik-praktik utama dan bagaimana pengaruhnya terhadap DevOps dari sudut pandang mereka. Kemudian hal lain terjadi: Google membeli DORA, dan bersama-sama mereka merilis laporan lain. Anda mungkin pernah melihatnya.
Banyak hal menjadi rumit tahun ini. Wayang diketahui telah melancarkan pollingnya sendiri. Mereka melakukannya seminggu lebih awal dari yang kami lakukan, dan itu sudah berakhir. Kami ambil bagian di dalamnya dan melihat topik apa yang mereka minati. Wayang sedang melakukan analisisnya dan bersiap untuk menerbitkan laporan tersebut.
Namun masih belum ada pengumuman dari DORA dan Google. Pada bulan Mei, ketika survei biasanya dimulai, muncul informasi bahwa Nicole Forsgren, salah satu pendiri DORA, telah pindah ke perusahaan lain. Oleh karena itu, kami berasumsi tidak akan ada penelitian dan tidak ada laporan dari DORA tahun ini.
Bagaimana keadaan di Rusia?
Kami belum melakukan penelitian DevOps. Kami berbicara di konferensi, menceritakan kembali kesimpulan orang lain dan Raiffeisenbank menerjemahkan "Status DevOps" untuk 2019 (Anda dapat menemukan pengumuman mereka di Habré), banyak terima kasih kepada mereka. Dan itu semua.
Oleh karena itu, kami melakukan penelitian kami sendiri di Rusia menggunakan metodologi dan temuan DORA. Kami menggunakan laporan rekan dari Raiffeisenbank untuk penelitian kami, termasuk untuk sinkronisasi terminologi dan terjemahan. Dan pertanyaan khusus industri datang dari laporan DORA tahun ini dan survei Boneka.
Proses penelitian
Laporan tersebut hanyalah bagian akhir. Keseluruhan proses penelitian terdiri dari empat langkah besar:
Selama tahap persiapan, kami mewawancarai pakar industri dan menyiapkan daftar hipotesis. Atas dasar mereka, pertanyaan dibuat dan survei diluncurkan sepanjang Agustus. Kemudian kami menganalisis dan menyiapkan laporan itu sendiri. Untuk DORA, proses ini membutuhkan waktu 6 bulan. Kami bertemu selama 3 bulan, dan sekarang kami memahami bahwa kami hampir tidak punya cukup waktu: hanya dengan melakukan analisis Anda memahami pertanyaan apa yang perlu ditanyakan.
Peserta
Semua reportase asing dimulai dengan potret peserta, dan kebanyakan bukan dari Rusia. Persentase responden Rusia naik dari 5 menjadi 1% dari tahun ke tahun, dan ini tidak memungkinkan kesimpulan apa pun.
Peta dari laporan Accelerate State of DevOps 2019:
Dalam studi kami, kami berhasil mewawancarai 889 orang - ini cukup banyak (polling DORA sekitar seribu orang dalam laporannya setiap tahun) dan di sini kami mencapai tujuan:
Benar, tidak semua peserta kami mencapai akhir: persentase isi ternyata sedikit kurang dari setengah. Tetapi bahkan ini sudah cukup untuk mendapatkan sampel yang representatif dan melakukan analisis. DORA tidak mengungkapkan persentase pengisian laporannya, sehingga tidak bisa dibandingkan di sini.
Industri dan posisi
Responden kami mewakili belasan industri. Separuh dari mereka bekerja di bidang teknologi informasi. Ini diikuti oleh jasa keuangan, perdagangan, telekomunikasi dan lain-lain. Di antara posisi tersebut adalah spesialis (pengembang, penguji, insinyur operasi) dan staf manajemen (pemimpin tim, tim, arahan, direktur):
Setiap detik bekerja di perusahaan berukuran sedang. Setiap orang ketiga bekerja di perusahaan besar. Sebagian besar bekerja dalam tim hingga 9 orang. Secara terpisah, kami bertanya tentang kegiatan utama, dan sebagian besar terkait dengan operasi, dan sekitar 40% terlibat dalam pengembangan:
Ini adalah cara kami mengumpulkan informasi untuk perbandingan dan analisis perwakilan dari berbagai industri, perusahaan, tim. Rekan saya Vitaly Khabarov akan memberi tahu Anda tentang analisisnya.
Analisis dan perbandingan
Vitaly Khabarov: Terima kasih banyak kepada semua peserta yang telah menyelesaikan survei kami, mengisi kuesioner dan memberi kami data untuk analisis lebih lanjut dan pengujian hipotesis kami. Dan terima kasih kepada klien dan pelanggan kami, kami memiliki banyak pengalaman yang membantu mengidentifikasi masalah yang menjadi perhatian industri dan merumuskan hipotesis yang kami uji dalam penelitian kami.
Sayangnya, Anda tidak bisa hanya mengambil daftar pertanyaan di satu sisi dan data di sisi lain, entah bagaimana membandingkannya, katakan: "Ya, begitulah cara kerjanya, kami benar," dan bubarkan. Tidak, kami memerlukan metodologi dan metode statistik untuk memastikan bahwa kami tidak salah dan kesimpulan kami dapat diandalkan. Kemudian kami dapat membangun pekerjaan kami lebih lanjut berdasarkan data ini:
Metrik kunci
Kami mengambil dasar metodologi DORA, yang mereka jelaskan secara rinci dalam buku "Accelerate State of DevOps". Kami memeriksa apakah metrik utama cocok untuk pasar Rusia, dapatkah metrik tersebut digunakan dengan cara yang sama seperti yang digunakan DORA untuk menjawab pertanyaan: "Bagaimana hubungan industri di Rusia dengan industri luar negeri?"
Metrik utama:
- Frekuensi penyebaran. Seberapa sering versi baru aplikasi diterapkan ke lingkungan produksi (perubahan yang direncanakan, tidak termasuk hot fix dan respons insiden)?
- Waktu pengiriman. Berapa lama waktu rata-rata antara melakukan perubahan (menulis fungsionalitas sebagai kode) dan menerapkan perubahan ke lingkungan produk?
- . , , ?
- . ( , )?
DORA telah menemukan hubungan antara metrik ini dan kinerja organisasi dalam penelitiannya. Kami juga memeriksanya dalam penelitian kami.
Tetapi untuk memastikan bahwa empat metrik utama dapat memengaruhi sesuatu, Anda perlu memahami - apakah metrik tersebut saling terkait satu sama lain? DORA menjawab setuju dengan satu peringatan: hubungan antara Tingkat Kegagalan Perubahan dan tiga metrik lainnya sedikit lebih lemah. Kami mendapat gambar yang sama. Jika waktu pengiriman, frekuensi penyebaran, dan waktu pemulihan berkorelasi satu sama lain (kami menemukan korelasi ini melalui korelasi Pearson dan melalui skala Chaddock), maka tidak ada korelasi yang kuat dengan perubahan yang tidak berhasil.
Pada prinsipnya sebagian besar responden cenderung menjawab bahwa mereka memiliki jumlah kejadian yang cukup kecil yang terjadi dalam produksi. Meskipun di masa mendatang kita akan melihat bahwa masih terdapat perbedaan yang signifikan antara kelompok responden dalam hal tingkat perubahan yang tidak berhasil, untuk pembagian ini kita belum dapat menggunakan metrik ini.
Kami mengaitkan hal ini dengan fakta bahwa (ternyata selama analisis dan komunikasi dengan beberapa pelanggan kami) ada sedikit perbedaan persepsi tentang apa yang dianggap sebagai insiden. Jika kami berhasil memulihkan pengoperasian layanan kami selama jendela teknis, dapatkah ini dianggap sebagai insiden? Mungkin tidak, karena kita sudah memperbaiki semuanya, kita hebat. Apakah bisa dianggap sebagai insiden jika kami harus meluncurkan kembali aplikasi kami 10 kali dalam mode normal, biasa untuk kami? Sepertinya tidak. Oleh karena itu, pertanyaan tentang hubungan perubahan yang tidak berhasil dengan metrik lain tetap terbuka. Kami akan menyempurnakannya lebih lanjut.
Penting di sini bahwa kami menemukan korelasi yang signifikan antara waktu pengiriman, waktu pemulihan, dan frekuensi penerapan. Oleh karena itu, kami mengambil ketiga metrik ini untuk membagi responden lebih lanjut ke dalam kelompok kinerja.
Berapa berat dalam gram?
Kami menggunakan analisis cluster hierarkis:
- Responden kami distribusikan melalui ruang n-dimensi, di mana koordinat setiap responden adalah jawaban atas pertanyaan mereka.
- Kami mendeklarasikan setiap responden sebagai cluster kecil.
- Kami menggabungkan dua cluster yang paling dekat satu sama lain menjadi satu cluster yang lebih besar.
- Temukan pasangan cluster berikutnya dan gabungkan mereka menjadi cluster yang lebih besar.
Ini adalah cara kami mengelompokkan semua responden kami ke dalam jumlah cluster yang diperlukan. Dengan bantuan dendrogram (pohon penghubung antar cluster) kita melihat jarak antara dua cluster yang bertetangga. Yang tersisa bagi kami adalah menetapkan batas jarak tertentu antara kelompok ini dan berkata: "Kedua kelompok ini cukup dapat dibedakan satu sama lain karena jarak di antara mereka sangat besar."
Tetapi ada masalah tersembunyi di sini: kami tidak memiliki batasan pada jumlah cluster - kami bisa mendapatkan 2, 3, 4, 10 cluster. Dan gagasan pertama adalah - mengapa tidak membagi semua responden kami menjadi 4 kelompok, seperti yang dilakukan DORA. Tetapi kami menemukan bahwa perbedaan antara kelompok-kelompok ini menjadi tidak signifikan, dan kami tidak dapat memastikan bahwa responden benar-benar milik kelompoknya sendiri, dan bukan kelompok tetangganya. Kami masih belum bisa membagi pasar Rusia menjadi empat kelompok. Oleh karena itu, kami berhenti tepat pada tiga profil, di antaranya terdapat perbedaan yang signifikan secara statistik:
Selanjutnya, kami menentukan profil berdasarkan cluster: kami mengambil median untuk setiap metrik untuk setiap grup dan membuat tabel profil kinerja. Faktanya, kami mendapatkan profil kinerja rata-rata peserta di setiap kelompok. Kami telah mengidentifikasi tiga profil efisiensi: Rendah, Sedang, Tinggi:
Di sini kami telah mengonfirmasi hipotesis kami bahwa 4 metrik utama sesuai untuk menentukan profil kinerja, dan keduanya berfungsi baik di pasar Barat dan Rusia. Ada perbedaan antara kelompok, dan itu signifikan secara statistik. Saya ingin menekankan bahwa ada perbedaan yang signifikan dalam rata-rata antara profil kinerja menurut metrik perubahan yang tidak berhasil, meskipun pada awalnya kami tidak membagi responden dengan parameter ini.
Kemudian muncul pertanyaan: bagaimana menggunakan semua ini?
Cara Penggunaan
Jika Anda mengambil tim mana pun, 4 metrik utama dan menerapkannya ke tabel, maka dalam 85% kasus kami tidak akan mendapatkan kecocokan lengkap - ini hanya peserta rata-rata, dan bukan kenyataan. Kami semua (dan setiap tim) sedikit berbeda.
Kami memeriksa: kami mengambil responden kami dan profil kinerja DORA, dan kami melihat berapa banyak responden yang cocok dengan profil tertentu. Kami menemukan bahwa hanya 16% responden yang membuka salah satu profil secara akurat. Yang lainnya tersebar di suatu tempat di antara:
Artinya profil kinerja memiliki cakupan yang terbatas. Untuk memahami posisi Anda pada perkiraan pertama, Anda dapat menggunakan tabel ini: "Oh, sepertinya kita lebih dekat ke Sedang atau Tinggi!" Jika Anda mengerti ke mana harus pergi selanjutnya, ini mungkin cukup. Tetapi jika tujuan Anda adalah perbaikan terus-menerus, dan Anda ingin tahu lebih tepat di mana harus mengembangkan dan apa yang harus dilakukan, maka Anda membutuhkan dana tambahan. Kami menyebutnya kalkulator:
- Kalkulator DORA
- Calculator Express 42 * (dalam pengembangan)
- Pengembangan sendiri (Anda dapat membuat kalkulator internal Anda sendiri).
Untuk apa mereka dibutuhkan? Untuk mengerti:
- Apakah tim dalam organisasi kita memenuhi standar kita?
- Jika tidak, dapatkah kita membantunya - mempercepatnya dalam kerangka keahlian yang dimiliki perusahaan kita?
- Jika ya, dapatkah kita melakukannya dengan lebih baik?
Anda juga dapat menggunakannya untuk mengumpulkan statistik dalam perusahaan:
- Tim apa yang kita miliki;
- Bagilah tim menjadi profil;
- Lihat: Oh, tim ini berkinerja buruk (mereka tidak menarik sedikit), dan ini keren: mereka menyebarkan setiap hari, tanpa kesalahan, mereka memiliki waktu tunggu kurang dari satu jam.
Dan kemudian Anda dapat mengetahui bahwa di dalam perusahaan kami ada keahlian dan alat yang diperlukan untuk tim-tim yang masih belum bertahan.
Atau, jika Anda memahami bahwa di dalam perusahaan Anda merasa hebat, bahwa Anda lebih baik daripada banyak orang, Anda dapat melihat secara lebih luas. Inilah tepatnya industri Rusia: bisakah kita mendapatkan keahlian yang diperlukan dalam industri Rusia untuk mempercepat diri kita sendiri? Calculator Express 42 akan membantu di sini (sedang dalam pengembangan). Jika Anda telah melampaui pasar Rusia, lihat kalkulator DORA dan pasar global.
Baik. Dan jika Anda termasuk dalam grup Kalkulator DORA Elit, apa yang harus dilakukan? Tidak ada solusi yang baik disini. Kemungkinan besar Anda berada di garis depan industri, dan akselerasi lebih lanjut serta peningkatan keandalan dimungkinkan karena R&D internal dan menghabiskan lebih banyak sumber daya.
Mari beralih ke yang paling manis - perbandingan.
Perbandingan
Kami awalnya ingin membandingkan industri Rusia dengan industri Barat. Jika kita membandingkan secara langsung, kita melihat bahwa kita memiliki lebih sedikit profil, dan mereka sedikit lebih bercampur satu sama lain, batasannya sedikit lebih kabur:
Penampil Elit kita tersembunyi di antara Berkinerja Tinggi, tetapi mereka ada - mereka adalah elit, unicorn yang telah mencapai ketinggian yang signifikan. Di Rusia, perbedaan antara profil Elite dan profil Tinggi belum cukup signifikan. Menurut kami kedepannya pemisahan ini akan dilakukan sehubungan dengan peningkatan budaya keteknikan, kualitas penerapan praktek keteknikan dan keahlian di dalam perusahaan.
Beralih ke perbandingan langsung dalam industri Rusia, kami melihat bahwa tim profil tinggi lebih baik dalam segala hal. Kami juga mengkonfirmasi hipotesis kami bahwa ada hubungan antara metrik ini dan kinerja organisasi: tim dengan profil Tinggi jauh lebih mungkin untuk tidak hanya mencapai tujuan, tetapi juga melampauinya.
Mari menjadi tim profil tinggi dan tidak berhenti di situ:
Tetapi tahun ini istimewa, dan kami memutuskan untuk memeriksa bagaimana perusahaan hidup dalam pandemi: Tim profil tinggi bekerja jauh lebih baik dan merasa lebih baik daripada rata-rata industri:
- Produk baru dirilis 1,5-2 kali lebih sering
- 2x lebih mungkin untuk meningkatkan keandalan dan / atau kinerja infrastruktur aplikasi.
Artinya, kompetensi yang telah mereka miliki membantu mereka berkembang lebih cepat, memperkenalkan produk baru, memodifikasi produk yang sudah ada, dengan demikian menaklukkan pasar baru dan pengguna baru:
Apa lagi yang membantu tim kami?
Praktik teknik
Saya akan memberi tahu Anda tentang temuan penting dari setiap praktik yang kami periksa. Mungkin ada hal lain yang membantu tim, tetapi kita berbicara tentang DevOps. Dan di dalam DevOps, kami melihat perbedaan di antara tim dengan profil berbeda.
Platform sebagai layanan
Kami tidak menemukan hubungan yang signifikan antara usia platform dan profil tim: Platform muncul pada waktu yang hampir bersamaan untuk tim Rendah dan tim Tinggi. Tetapi untuk yang terakhir, platform menyediakan, rata-rata, lebih banyak layanan dan lebih banyak antarmuka pemrograman untuk kontrol melalui kode program. Dan tim platform lebih cenderung membantu pengembang dan timnya menggunakan platform, lebih sering untuk memecahkan masalah dan insiden terkait platform, dan melatih tim lain.
Infrastruktur sebagai kode
Semuanya cukup standar di sini. Kami menemukan hubungan antara otomatisasi kode infrastruktur dan berapa banyak informasi yang disimpan di dalam repositori infrastruktur. Perintah profil tinggi menyimpan lebih banyak informasi dalam repositori: konfigurasi infrastruktur, pipeline CI / CD, pengaturan lingkungan, dan parameter build. Mereka lebih sering menyimpan informasi ini, bekerja lebih baik dengan kode infrastruktur, dan mengotomatiskan lebih banyak proses dan tugas untuk bekerja dengan kode infrastruktur.
Menariknya, kami tidak melihat perbedaan yang signifikan dalam pengujian infrastruktur. Saya mengaitkan ini dengan fakta bahwa perintah profil tinggi umumnya memiliki lebih banyak otomatisasi pengujian. Mungkin mereka tidak boleh terganggu secara terpisah oleh pengujian infrastruktur, tetapi pengujian yang mereka gunakan untuk memeriksa aplikasi sudah cukup, dan berkat mereka mereka sudah dapat melihat apa dan di mana mereka rusak.
Integrasi dan pengiriman
Bagian paling membosankan karena kami mengonfirmasi bahwa semakin banyak otomatisasi yang Anda miliki, semakin baik Anda bekerja dengan kodenya, semakin besar kemungkinan Anda mendapatkan metrik terbaik.
Arsitektur
Kami ingin melihat bagaimana layanan mikro memengaruhi kinerja. Jika sebenarnya tidak, karena penggunaan layanan mikro tidak terkait dengan peningkatan indikator kinerja. Layanan mikro digunakan oleh perintah profil tinggi dan perintah profil rendah.
Namun yang penting adalah bagi tim Tinggi, transisi ke arsitektur layanan mikro memungkinkan mereka mengembangkan dan meluncurkan layanan secara mandiri. Jika arsitektur memungkinkan pengembang untuk bertindak secara mandiri, tidak menunggu seseorang di luar tim, maka ini adalah kompetensi utama untuk meningkatkan kecepatan. Di sinilah layanan mikro membantu. Dan implementasinya saja tidak memainkan peran besar.
Bagaimana kami menemukan semua ini?
Kami memiliki rencana ambisius untuk sepenuhnya meniru metodologi DORA, tetapi kami kekurangan sumber daya. Jika DORA menggunakan banyak sponsor dan penelitian memakan waktu setengah tahun, kami melakukan penelitian dalam waktu singkat. Kami ingin membangun model DevOps seperti yang dilakukan DORA, dan kami akan melakukannya di masa mendatang. Sejauh ini, kami telah membatasi diri pada peta panas:
Kami melihat distribusi praktik teknik di antara tim dari setiap profil, dan menemukan bahwa tim di Profil Tinggi, rata-rata, lebih sering menggunakan praktik teknik. Anda dapat membaca lebih lanjut tentang semua ini di laporan kami .
Untuk perubahan, mari beralih dari statistik kompleks ke statistik sederhana.
Apa lagi yang kami temukan?
Alat
Kami mengamati bahwa sebagian besar tim menggunakan sistem operasi Linux. Namun Windows masih menjadi tren - setidaknya seperempat responden kami menggunakan satu atau versi lain. Pasar tampaknya memiliki kebutuhan ini. Oleh karena itu, Anda dapat mengembangkan kompetensi tersebut dan melakukan presentasi di konferensi.
Kubernetes adalah pemimpin di antara orkestra (52%). Orkestrator berikutnya yang sejalan adalah Docker Swarm (sekitar 12%). Sistem CI yang paling populer adalah Jenkins dan GitLab. Sistem manajemen konfigurasi yang paling populer adalah Ansible, diikuti oleh Shell tercinta.
Amazon masih menjadi pemimpin di antara layanan hosting cloud. Pangsa awan Rusia secara bertahap meningkat. Tahun depan, akan menarik untuk melihat bagaimana perasaan penyedia cloud Rusia dan apakah pangsa pasar mereka tumbuh. Ya, Anda dapat menggunakannya, dan itu bagus:
Saya memberikan penjelasan kepada Igor, yang akan memberikan lebih banyak statistik.
Penyebaran praktik
Igor Kurochkin: Secara terpisah, kami meminta responden untuk menunjukkan bagaimana praktik teknik yang dianggap disebarluaskan di perusahaan. Sebagian besar perusahaan memiliki pendekatan campuran dengan serangkaian pola yang berbeda, dan proyek percontohan sangat populer. Kami juga melihat sedikit perbedaan antara profil. Perwakilan dari Profil Tinggi lebih sering menggunakan pola "Inisiatif dari bawah", ketika tim kecil spesialis mengubah proses kerja, alat, dan berbagi perkembangan yang berhasil dengan tim lain. Di Medium, ini adalah inisiatif dari atas, yang memengaruhi seluruh perusahaan dengan menciptakan komunitas dan pusat keunggulan:
Agile dan DevOps
Hubungan antara Agile dan DevOps adalah topik hangat di industri ini. Masalah ini juga diangkat dalam Status Agile Report untuk 2019/2020, jadi kami memutuskan untuk membandingkan bagaimana aktivitas Agile dan DevOps terkait di perusahaan. Kami telah menemukan bahwa DevOps non-Agile jarang terjadi. Untuk setengah dari responden, penyebaran Agile dimulai jauh lebih awal, dan sekitar 20% mengamati permulaan yang simultan, dan salah satu tanda profil Rendah adalah tidak adanya praktik Agile dan DevOps:
Topologi perintah
Pada akhir tahun lalu, buku " Topologi tim " diterbitkan, yang mengusulkan kerangka kerja untuk mendeskripsikan topologi tim. Kami bertanya-tanya apakah itu berlaku untuk perusahaan Rusia. Dan kami mengajukan pertanyaan: "Pola apa yang Anda temukan?"
Tim infrastruktur diamati oleh setengah dari responden, serta tim pengembangan, pengujian, dan operasi yang terpisah. Tim DevOps individu tercatat sebesar 45%, di antaranya perwakilan Tinggi lebih umum. Ini diikuti oleh tim lintas fungsi, yang juga lebih umum untuk Tinggi. Perintah SRE terpisah muncul di profil Tinggi, Sedang dan jarang muncul di profil Rendah:
Rasio DevQaOps
Kami melihat pertanyaan ini di FaceBook dari pemimpin tim platform Skyeng - dia tertarik pada rasio pengembang, penguji, dan administrator di perusahaan. Kami menanyakannya dan melihat tanggapan berdasarkan profil: perwakilan dari profil Tinggi memiliki lebih sedikit teknisi pengujian dan operasi per pengembang:
Rencana untuk 2021
Dalam rencana mereka untuk tahun depan, responden mencatat aktivitas berikut:
Di sini Anda dapat melihat persimpangan dengan konferensi DevOps Live 2020. Kami meninjau program dengan cermat:
- Infrastruktur sebagai produk
- Transformasi DevOps
- Menyebarkan praktik DevOps
- DevSecOps
- Klub kasus dan diskusi
Tetapi pidato kita tidak akan cukup waktu untuk mempertimbangkan semua topik. Tertinggal di belakang layar:
- Platform sebagai layanan dan sebagai produk;
- Infrastruktur sebagai kode, lingkungan, dan cloud;
- Integrasi dan pengiriman berkelanjutan;
- Arsitektur;
- Pola DevSecOps;
- Platform dan tim lintas fungsi.
Laporan kami ternyata sangat banyak, sebanyak 50 halaman, dan Anda dapat melihatnya lebih detail.
Menyimpulkan
Kami berharap penelitian dan laporan kami akan menginspirasi Anda untuk bereksperimen dengan pendekatan baru untuk pengembangan, pengujian, dan operasi, serta membantu Anda menavigasi, membandingkan diri Anda dengan peserta penelitian lain, dan mengidentifikasi area tempat Anda dapat meningkatkan pendekatan Anda sendiri.
Hasil survei pertama negara bagian DevOps di Rusia:
- Metrik kunci. Kami telah menemukan bahwa metrik utama (waktu tunggu, frekuensi penerapan, waktu pemulihan, dan perubahan yang tidak berhasil) sesuai untuk menganalisis keefektifan pengembangan, pengujian, dan operasi.
- High, Medium, Low. High, Medium, Low , , . High , Low. .
- , 2021 . , . High , , .
- Praktik DevOps, alat, dan pengembangannya. Rencana utama perusahaan untuk tahun depan mencakup pengembangan praktik dan alat DevOps, pengenalan praktik DevSecOps, dan perubahan dalam struktur organisasi. Dan implementasi dan pengembangan praktik DevOps yang efektif dilakukan dengan bantuan proyek percontohan, pembentukan komunitas dan pusat kompetensi, inisiatif di tingkat atas dan bawah perusahaan.
Kami akan senang mendengar tanggapan, cerita, umpan balik Anda. Terima kasih kepada semua orang yang berpartisipasi dalam studi ini, dan kami menantikan partisipasi Anda tahun depan.