State of DevOps di Rusia 2020

Bagaimana memahami keadaan sesuatu?

Anda bisa mengandalkan opini Anda yang terbentuk dari berbagai sumber informasi, misalnya publikasi di website atau pengalaman. Anda bisa bertanya kepada kolega, kenalan. Pilihan lainnya adalah dengan 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 status DevOps dilakukan setiap tahun di dunia, laporan diterbitkan oleh perusahaan asing, dan hampir tidak ada informasi tentang DevOps Rusia.

Tetapi harinya telah tiba ketika penelitian semacam itu dilakukan, dan hari ini kita akan membicarakan hasilnya. Keadaan DevOps di Rusia dipelajari bersama oleh perusahaan "Ekspres 42"Dan"Ontico". Express 42 membantu perusahaan teknologi menerapkan dan mengembangkan praktik dan alat DevOps dan merupakan salah satu yang pertama berbicara tentang DevOps di Rusia. Penulis penelitian, Igor Kurochkin dan Vitaly Khabarov, terlibat dalam analisis dan konsultasi di Express 42, sambil memiliki latar belakang teknis dari operasi dan pengalaman di berbagai perusahaan. Selama 8 tahun, rekan kerja telah melihat lusinan perusahaan dan proyek - dari startup hingga perusahaan - dengan masalah yang berbeda, serta kematangan budaya dan teknik yang berbeda.

Dalam laporan mereka, Igor dan Vitaly menceritakan masalah apa yang ada dalam proses penelitian, bagaimana mereka menyelesaikannya, serta bagaimana penelitian DevOps dilakukan pada prinsipnya dan mengapa Express 42 memutuskan untuk melakukannya sendiri. Laporan mereka dapat dilihat di sini.

Riset DevOps

Percakapan dimulai oleh Igor Kurochkin.

Kami secara teratur bertanya 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 mempelajarinya. Jika Anda belum pernah melihat laporan seperti itu, katakanlah langsung bahwa semuanya sangat mirip. Paling sering ada ungkapan seperti: "Dibandingkan tahun lalu ..."

Di sini kita memiliki masalah pertama, dan setelah itu dua lagi:

1. Kami tidak memiliki data untuk tahun lalu. Keadaan DevOps di Rusia tidak menarik bagi siapa pun;
2. Metodologi. Tidak jelas bagaimana menguji hipotesis, bagaimana membangun pertanyaan, bagaimana menganalisis, membandingkan hasil, menemukan koneksi;
3. Terminologi. Semua laporan dalam bahasa Inggris, terjemahan diperlukan, kerangka kerja DevOps umum belum ditemukan dan semua orang membuatnya sendiri.

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

sejarah

Riset DevOps telah dilakukan sejak 2011. Puppet, pengembang sistem manajemen konfigurasi, adalah yang pertama melakukannya. Saat itu, itu adalah salah satu alat utama untuk mendeskripsikan infrastruktur dalam bentuk kode. Hingga 2013, studi ini hanyalah survei tertutup dan tidak ada laporan publik.

Pada 2013, Revolusi TI muncul, penerbit semua buku utama di DevOps. Bersama dengan Puppet, mereka menyiapkan publikasi State of DevOps pertama, 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, terlibat. Dan pada 2015, bagian dengan metodologi ditambahkan, dan menjadi jelas bagaimana mereka melakukan analisis.

Pada tahun 2016, penulis penelitian, setelah mendirikan perusahaan mereka sendiri DORA (DevOps Research and Assessment), menerbitkan laporan tahunan. Tahun berikutnya, DORA dan Puppet merilis laporan bersama terakhir mereka.

Dan kemudian sesuatu yang menarik dimulai:

Pada 2018, perusahaan berpisah dan dua laporan independen dirilis: satu dari Puppet, yang kedua dari DORA bekerja sama dengan Google. DORA terus meningkatkan metodologinya dengan metrik utama, profil kinerja, dan praktik rekayasa yang berdampak pada metrik utama dan kinerja seluruh perusahaan. Dan Wayang menawarkan pendekatannya sendiri dengan deskripsi proses dan evolusi DevOps. Namun ceritanya tidak mengakar, pada 2019 Puppet meninggalkan metodologi ini dan merilis versi baru laporan, yang mencantumkan praktik utama dan bagaimana pengaruhnya terhadap DevOps dari sudut pandang mereka. Kemudian peristiwa lain terjadi: Google membeli DORA, dan bersama-sama mereka merilis laporan lain. Anda mungkin pernah melihatnya.

Tahun ini, segalanya menjadi rumit. Wayang diketahui telah meluncurkan survei sendiri. Mereka melakukannya seminggu lebih awal dari kami, dan itu sudah berakhir. Kami mengambil bagian di dalamnya dan melihat topik apa yang mereka minati. Sekarang 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 bahwa tidak akan ada penelitian dan laporan dari DORA tahun ini.

Bagaimana keadaan di Rusia?

Kami belum melakukan penelitian DevOps. Kami berbicara di konferensi, menceritakan kembali temuan orang lain, dan Raiffeisenbank menerjemahkan "State of DevOps" untuk 2019 (Anda dapat menemukan pengumumannya di Habré), terima kasih banyak kepada mereka. Dan itu semua.

Oleh karena itu, kami melakukan penelitian kami sendiri di Rusia dengan menggunakan metodologi dan temuan DORA. Kami menggunakan laporan rekan dari Raiffeisenbank untuk penelitian kami, termasuk untuk sinkronisasi terminologi dan terjemahan. Dan pertanyaan yang relevan dengan industri diambil dari laporan DORA dan kuesioner Wayang tahun ini.

Proses penelitian

Laporan itu hanyalah bagian akhir. Seluruh proses penelitian terdiri dari empat langkah utama:

Selama tahap persiapan, kami mewawancarai pakar industri dan menyiapkan daftar hipotesis. Atas dasar mereka, pertanyaan disusun dan survei diluncurkan sepanjang Agustus. Kemudian kami menganalisis dan menyiapkan laporan itu sendiri. Untuk DORA, proses ini memakan waktu 6 bulan. Kami bertemu dalam 3 bulan, dan sekarang kami memahami bahwa kami hampir tidak punya cukup waktu: hanya dengan melakukan analisis Anda memahami pertanyaan apa yang perlu Anda tanyakan.

Peserta

Semua laporan asing dimulai dengan potret para peserta, dan kebanyakan dari mereka bukan dari Rusia. Persentase responden Rusia berfluktuasi antara 5 dan 1% dari tahun ke tahun, dan ini tidak memungkinkan untuk menarik kesimpulan apa pun.

Peta dari laporan Accelerate State of DevOps 2019:

Dalam penelitian kami, kami berhasil mewawancarai 889 orang - ini cukup banyak (DORA melakukan jajak pendapat tentang seribu orang setiap tahun dalam laporannya) dan di sini kami telah mencapai tujuan:

Benar, tidak semua peserta kami mencapai akhir: persentase penyelesaian ternyata sedikit kurang dari setengahnya. Tetapi ini pun cukup untuk mendapatkan sampel yang representatif dan melakukan analisis. DORA tidak mengungkapkan persentase pengisian dalam laporannya, jadi tidak ada perbandingan di sini.

Industri dan posisi

Responden kami mewakili selusin industri. Setengah bekerja di bidang teknologi informasi. Diikuti oleh jasa keuangan, perdagangan, telekomunikasi dan lain-lain. Di antara posisi tersebut adalah spesialis (pengembang, penguji, insinyur operasi) dan staf manajemen (kepala tim, kelompok, area, direktur):

Satu dari dua bekerja untuk perusahaan menengah. 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:

Jadi kami mengumpulkan informasi untuk perbandingan dan analisis perwakilan dari berbagai industri, perusahaan, tim. Rekan saya Vitaly Khabarov akan menceritakan 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 telah membantu mengidentifikasi masalah industri dan merumuskan hipotesis yang kami uji dalam penelitian kami.

Sayangnya, Anda tidak bisa begitu saja mengambil daftar pertanyaan di satu sisi dan data di sisi lain, entah bagaimana membandingkannya, katakan: "Ya, semuanya berjalan seperti itu, kami benar" dan bubar. Tidak, metodologi dan metode statistik diperlukan untuk memastikan bahwa kami tidak salah dan kesimpulan kami dapat diandalkan. Kemudian kita dapat membangun pekerjaan selanjutnya berdasarkan data ini:

Metrik Kunci

Kami mengambil metodologi DORA sebagai dasar, yang mereka jelaskan secara rinci dalam buku "Accelerate State of DevOps". Kami memeriksa apakah metrik utama cocok untuk pasar Rusia, apakah metrik tersebut dapat digunakan dengan cara yang sama seperti yang digunakan DORA untuk menjawab pertanyaan: "Bagaimana hubungan industri di Rusia dengan industri asing?"

Metrik utama:

1. Frekuensi penyebaran. Seberapa sering versi baru aplikasi disebarkan ke lingkungan produksi (perubahan terencana, tidak termasuk hotfix dan respons insiden)?
2. Waktu pengiriman. Berapa waktu rata-rata antara melakukan perubahan (menulis fungsionalitas sebagai kode) dan menerapkan perubahan ke lingkungan produksi?
3. Waktu Pemulihan. Rata-rata berapa lama waktu yang diperlukan untuk memulihkan aplikasi ke lingkungan produksi setelah insiden, penurunan layanan, atau ditemukannya bug yang memengaruhi pengguna aplikasi?
4. Perubahan yang tidak berhasil. Berapa persentase penerapan di lingkungan produksi yang menyebabkan degradasi atau insiden aplikasi dan memerlukan perbaikan (kembalikan perubahan, pengembangan hotfix atau tambalan)?

DORA dalam penelitiannya telah menemukan hubungan antara metrik tersebut dan kinerja organisasi. Kami juga mengujinya dalam penelitian kami.

Tetapi untuk memastikan bahwa empat metrik utama dapat memengaruhi sesuatu, Anda perlu memahami - apakah mereka terkait satu sama lain? DORA menjawab dengan tegas dengan satu peringatan: hubungan antara perubahan yang tidak berhasil (Tingkat Kegagalan Perubahan) dan tiga metrik lainnya sedikit lebih lemah. Kami mendapat gambaran yang hampir sama. Jika waktu pengiriman, frekuensi penerapan, dan waktu pemulihan berkorelasi satu sama lain (kami menetapkan korelasi ini melalui korelasi Pearson dan melalui skala Chaddock), maka tidak ada korelasi yang kuat dengan perubahan yang gagal.

Pada prinsipnya, sebagian besar responden cenderung menjawab bahwa mereka memiliki jumlah insiden yang cukup kecil dalam produksi. Meskipun nanti kita akan melihat bahwa masih ada perbedaan yang signifikan antara kelompok responden dalam hal perubahan yang gagal, kita belum bisa menggunakan metrik ini untuk divisi ini.

Kami menghubungkan 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 kinerja layanan kami selama jendela teknis, dapatkah ini dianggap sebagai insiden? Mungkin tidak, karena kami memperbaiki semuanya, kami hebat. Bisakah kita menganggapnya sebagai insiden jika kita harus memutar ulang aplikasi kita 10 kali dalam mode normal yang kita kenal? Sepertinya tidak. Oleh karena itu, pertanyaan tentang hubungan perubahan yang gagal dengan metrik lain tetap terbuka. Kami akan menyempurnakannya lebih lanjut.

Penting di sini adalah kami menemukan korelasi yang signifikan antara waktu pengiriman, waktu pemulihan, dan frekuensi penerapan. Oleh karena itu, kami menggunakan tiga metrik ini untuk membagi lebih lanjut responden ke dalam kelompok kinerja.

Berapa banyak yang harus disimpan dalam gram?

Kami menggunakan analisis klaster hierarkis:

• Kami mendistribusikan responden ke ruang n-dimensi, di mana koordinat setiap responden adalah jawaban atas pertanyaan mereka.
• Setiap responden dinyatakan sebagai cluster kecil.
• Kami menggabungkan dua cluster yang paling dekat satu sama lain menjadi satu cluster yang lebih besar.
• Kami menemukan pasangan cluster berikutnya dan menggabungkannya menjadi cluster yang lebih besar.

Beginilah cara kami mengelompokkan semua responden kami ke dalam jumlah cluster yang kami butuhkan. Dengan bantuan dendrogram (pohon koneksi antar cluster), kami melihat jarak antara dua cluster yang berdekatan. Yang tersisa bagi kita hanyalah menetapkan batas jarak tertentu antara kelompok-kelompok ini dan berkata: "Kedua kelompok ini cukup dapat dibedakan satu sama lain karena jarak antara mereka sangat besar."

Tapi ada masalah tersembunyi di sini: kami tidak membatasi jumlah cluster - kami bisa mendapatkan 2, 3, 4, 10 cluster. Dan ide 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 apakah responden benar-benar milik kelompoknya, dan bukan milik tetangganya. Kami belum bisa membagi pasar Rusia menjadi empat kelompok. Oleh karena itu, kami memilih tiga profil yang memiliki perbedaan yang signifikan secara statistik:

Selanjutnya, kami menentukan profil berdasarkan cluster: kami mengambil median untuk setiap metrik untuk setiap grup dan menyusun tabel profil kinerja. Bahkan, kami mendapatkan profil kinerja rata-rata peserta di setiap kelompok. Kami telah mengidentifikasi tiga profil efisiensi: Rendah, Sedang, Tinggi:

Di sini kami mengonfirmasi hipotesis kami bahwa 4 metrik utama cocok untuk menentukan profil kinerja, dan keduanya berfungsi baik di pasar Barat maupun Rusia. Ada perbedaan antara kelompok dan secara statistik signifikan. Saya menekankan bahwa ada perbedaan yang signifikan antara profil kinerja dalam hal metrik perubahan yang gagal dalam rata-rata, meskipun kami awalnya tidak membagi responden dengan parameter ini.

Kemudian muncul pertanyaan: bagaimana cara menggunakan semua ini?

Bagaimana cara menggunakan

Jika kami mengambil tim mana pun, 4 metrik kunci dan menerapkannya ke tabel, maka dalam 85% kasus kami tidak akan mendapatkan pertandingan yang lengkap - ini hanya peserta biasa, dan bukan yang sebenarnya. Kita semua (dan setiap tim) sedikit berbeda.

Kami memeriksa: kami mengambil responden kami dan profil kinerja DORA, dan melihat berapa banyak responden yang cocok dengan profil ini atau itu. Kami menemukan bahwa hanya 16% responden yang benar-benar termasuk dalam salah satu profil. Semua yang lain tersebar di suatu tempat di antara:

Artinya profil efisiensi memiliki ruang lingkup yang terbatas. Untuk memahami di mana Anda berada 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 peningkatan yang konstan dan berkelanjutan, dan Anda ingin tahu lebih tepatnya di mana harus berkembang dan apa yang harus dilakukan, maka diperlukan 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 kami membantu, mempercepatnya dalam kerangka keahlian yang dimiliki perusahaan kami?
• Jika demikian, dapatkah kita melakukan lebih baik lagi?

Anda juga dapat menggunakannya untuk mengumpulkan statistik dalam perusahaan:

• Tim apa yang kita miliki?
• Bagilah tim menjadi beberapa profil;
• Lihat: Oh, perintah ini berkinerja buruk (tidak menarik sedikit), tetapi ini keren: perintah ini diterapkan setiap hari, tanpa kesalahan, waktu tunggu kurang dari satu jam.

Dan kemudian Anda dapat mengetahui bahwa di dalam perusahaan kami terdapat keahlian dan alat yang diperlukan untuk tim yang belum setara.

Atau, jika Anda memahami bahwa Anda merasa hebat di dalam perusahaan, Anda lebih baik daripada banyak orang, maka Anda dapat terlihat sedikit lebih luas. Ini hanya industri Rusia: bisakah kita mendapatkan keahlian yang diperlukan di industri Rusia untuk mempercepat diri kita sendiri? Kalkulator Express 42 akan membantu di sini (sedang dikembangkan). Jika Anda telah melampaui pasar Rusia, maka lihatlah Kalkulator DORA dan ke pasar dunia.

Bagus. Dan jika Anda berada di grup Elit pada kalkulator DORA, apa yang harus Anda lakukan? Tidak ada solusi yang baik di sini. Anda kemungkinan besar berada di garis depan industri, dan akselerasi serta keandalan lebih lanjut dimungkinkan melalui R&D internal dan menghabiskan lebih banyak sumber daya.

Mari beralih ke yang paling manis - perbandingan.

Сравнение

Kami awalnya ingin membandingkan industri Rusia dengan industri Barat. Jika kita membandingkan secara langsung, kita melihat bahwa profil kita lebih sedikit, dan mereka sedikit lebih bercampur satu sama lain, batasnya sedikit lebih kabur:

Para pemain Elit kami tersembunyi di antara para Pemain Tinggi, tetapi mereka ada di sana - ini adalah para elit, unicorn yang telah mencapai ketinggian yang signifikan. Di Rusia, perbedaan antara profil Elite dan High profile belum cukup signifikan. Kami berpikir bahwa di masa depan pemisahan ini akan terjadi karena peningkatan budaya engineering, kualitas penerapan praktek engineering dan keahlian di dalam perusahaan.

Jika kita beralih ke perbandingan langsung dalam industri Rusia, kita dapat melihat bahwa tim terkenal lebih baik dalam segala hal. Kami juga mengkonfirmasi hipotesis kami bahwa ada hubungan antara metrik ini dan kinerja organisasi: Tim profil tinggi jauh lebih mungkin untuk tidak hanya mencapai tujuan, tetapi juga melampauinya.
Mari menjadi tim profil tinggi dan tidak berhenti di situ:

Namun tahun ini istimewa, dan kami memutuskan untuk memeriksa bagaimana kinerja perusahaan dalam pandemi: Tim terkenal bekerja jauh lebih baik dan merasa lebih baik daripada rata-rata industri:

• 1,5-2 kali lebih mungkin untuk merilis produk baru,
• 2 kali lebih mungkin untuk meningkatkan keandalan dan/atau kinerja infrastruktur aplikasi.

Artinya, kompetensi yang sudah mereka miliki membantu mereka berkembang lebih cepat, meluncurkan produk baru, memodifikasi produk yang sudah ada, sehingga menaklukkan pasar baru dan pengguna baru:

Apa lagi yang membantu tim kami?

Praktek rekayasa

Saya akan memberi tahu Anda tentang temuan signifikan untuk setiap praktik yang kami uji. 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 rata-rata menyediakan lebih banyak layanan dan lebih banyak antarmuka pemrograman untuk kontrol melalui kode program. Dan tim platform lebih cenderung membantu pengembang dan tim mereka menggunakan platform, memecahkan masalah mereka dan insiden terkait platform lebih sering, dan mengedukasi tim lain.

Infrastruktur sebagai kode

Semuanya cukup standar di sini. Kami menemukan hubungan antara otomatisasi pekerjaan kode infrastruktur dan berapa banyak informasi yang disimpan di dalam repositori infrastruktur. Perintah profil tinggi menyimpan lebih banyak informasi di repositori: ini adalah konfigurasi infrastruktur, pipa 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 menghubungkan ini dengan fakta bahwa tim profil tinggi memiliki lebih banyak otomatisasi pengujian secara umum. Mungkin mereka tidak boleh terganggu secara terpisah oleh pengujian infrastruktur, melainkan pengujian yang digunakan untuk memeriksa aplikasi, dan terima kasih kepada mereka, mereka sudah melihat apa dan di mana mereka rusak.

Integrasi dan Pengiriman

Bagian yang paling membosankan, karena kami mengonfirmasi bahwa semakin banyak otomatisasi yang Anda miliki, semakin baik Anda bekerja dengan kode, semakin besar kemungkinan Anda mendapatkan hasil yang lebih baik.

Arsitektur

Kami ingin melihat bagaimana layanan mikro memengaruhi kinerja. Sebenarnya tidak, karena penggunaan layanan mikro tidak terkait dengan peningkatan indikator kinerja. Layanan mikro digunakan untuk perintah profil tinggi dan perintah profil rendah.

Namun yang penting adalah bagi tim Tinggi, transisi ke arsitektur layanan mikro memungkinkan mereka untuk mengembangkan dan meluncurkan layanan secara mandiri. Jika arsitektur memungkinkan pengembang untuk bertindak secara mandiri, tanpa menunggu seseorang di luar tim, maka ini adalah kompetensi utama untuk meningkatkan kecepatan. Dalam hal ini, layanan mikro membantu. Dan implementasinya saja tidak memainkan peran besar.

Bagaimana kami menemukan semua ini?

Kami memiliki rencana ambisius untuk mereplikasi sepenuhnya metodologi DORA, tetapi kekurangan sumber daya. Jika DORA menggunakan banyak sponsor dan penelitian mereka memakan waktu setengah tahun, kami melakukan penelitian kami dalam waktu singkat. Kami ingin membuat model DevOps seperti DORA, dan kami akan melakukannya di masa mendatang. Sejauh ini kami membatasi diri pada peta panas:

Kami melihat distribusi praktik teknik di seluruh tim di setiap profil dan menemukan bahwa rata-rata tim profil tinggi lebih cenderung menggunakan praktik teknik. Anda dapat membaca lebih lanjut tentang semua ini di kami laporan.

Untuk perubahan, mari beralih dari statistik kompleks ke statistik sederhana.

Apa lagi yang telah kita temukan?

Alat

Kami mengamati bahwa sebagian besar perintah digunakan oleh OS keluarga Linux. Tetapi Windows masih dalam tren - setidaknya seperempat responden kami mencatat penggunaan salah satu versinya. Tampaknya pasar memiliki kebutuhan ini. Oleh karena itu, Anda dapat mengembangkan kompetensi tersebut dan melakukan presentasi di konferensi.

Di antara orkestra, bukan rahasia lagi bagi siapa pun, Kubernetes memimpin (52%). Orkestrator berikutnya 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 kesayangan kita.

Amazon saat ini adalah penyedia cloud hosting terkemuka. Bagian awan Rusia secara bertahap meningkat. Tahun depan akan menarik untuk melihat bagaimana perasaan penyedia cloud Rusia, apakah pangsa pasar mereka akan meningkat. Mereka, mereka dapat digunakan, dan itu bagus:

Saya memberikan kesempatan kepada Igor, yang akan memberikan beberapa statistik lagi.

Penyebaran praktik

Igor Kurochkin: Secara terpisah, kami meminta responden untuk menunjukkan bagaimana praktik rekayasa yang dipertimbangkan didistribusikan di perusahaan. Di sebagian besar perusahaan, ada pendekatan campuran, yang terdiri dari kumpulan 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 praktik sukses dengan tim lain. Di Medium, ini adalah inisiatif top-down yang memengaruhi seluruh perusahaan melalui penciptaan komunitas dan pusat keunggulan:

Agile dan DevOps

Pertanyaan tentang hubungan antara Agile dan DevOps sering dibahas di industri. Masalah ini juga diangkat dalam Laporan Status Agile untuk 2019/2020, jadi kami memutuskan untuk membandingkan bagaimana aktivitas Agile dan DevOps terhubung di perusahaan. Kami menemukan bahwa DevOps tanpa Agile jarang terjadi. Untuk separuh responden, penyebaran Agile dimulai jauh lebih awal, dan sekitar 20% mengamati peluncuran secara bersamaan, dan salah satu tanda profil Rendah adalah tidak adanya praktik Agile dan DevOps:

Topologi perintah

Di penghujung tahun lalu, buku "Topologi tim”, yang mengusulkan kerangka kerja untuk mendeskripsikan topologi perintah. Menjadi menarik bagi kami apakah itu berlaku untuk perusahaan Rusia. Dan kami mengajukan pertanyaan: "Pola apa yang Anda temukan?".

Tim infrastruktur diamati di separuh responden, serta tim terpisah untuk pengembangan, pengujian, dan pengoperasian. Tim DevOps terpisah mencatat 45%, di antaranya perwakilan Tinggi lebih umum. Berikutnya adalah tim lintas fungsi, yang juga lebih umum di Tingkat Tinggi. Perintah SRE terpisah muncul di profil Tinggi, Sedang dan jarang terlihat di profil Rendah:

Rasio DevQaOps

Kami melihat pertanyaan ini di Facebook dari pemimpin tim tim platform Skyeng - dia tertarik dengan rasio pengembang, penguji, dan administrator di perusahaan. Kami menanyakannya dan melihat tanggapan berdasarkan profil: Perwakilan profil tinggi memiliki lebih sedikit insinyur pengujian dan operasi untuk setiap pengembang:

Paket untuk tahun 2021

Dalam rencana tahun depan, responden mencatat kegiatan berikut:

Di sini Anda dapat melihat persimpangan dengan konferensi DevOps Live 2020. Kami meninjau program dengan cermat:

• Infrastruktur sebagai produk
• transformasi DevOps
• Distribusi praktik DevOps
• DevSecOps
• Klub kasus dan diskusi

Namun waktu presentasi kami tidak cukup untuk mencakup semua topik. Tertinggal di belakang layar:

• Platform sebagai layanan dan sebagai produk;
• Infrastruktur sebagai kode, lingkungan, dan awan;
• Integrasi dan Pengiriman Berkelanjutan;
• Arsitektur;
• pola DevSecOps;
• Platform dan tim lintas fungsi.

Laporan kami mendapat banyak sekali, 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 pengoperasian, serta membantu Anda menavigasi, membandingkan diri Anda dengan peserta lain dalam penelitian ini, dan mengidentifikasi area di mana Anda dapat meningkatkan pendekatan Anda sendiri.

Hasil studi pertama tentang keadaan DevOps di Rusia:

• Metrik kunci. Kami telah menemukan bahwa metrik utama (waktu pengiriman, frekuensi penerapan, waktu pemulihan, dan kegagalan perubahan) cocok untuk menganalisis efektivitas proses pengembangan, pengujian, dan operasi.
• Profil Tinggi, Sedang, Rendah. Berdasarkan data yang dikumpulkan, kami dapat membedakan kelompok yang berbeda secara statistik dari Tinggi, Sedang, Rendah dengan ciri khas dalam hal metrik, praktik, proses, dan alat. Perwakilan dari profil Tinggi menunjukkan hasil yang lebih baik daripada Rendah. Mereka lebih mungkin untuk mencapai dan melampaui tujuan mereka.
• Indikator, pandemi dan rencana untuk tahun 2021. Indikator khusus tahun ini adalah bagaimana perusahaan mengatasi pandemi. Perwakilan Tinggi bernasib lebih baik, mengalami peningkatan keterlibatan pengguna, dan alasan utama kesuksesan adalah proses pengembangan yang efisien dan budaya rekayasa yang kuat.
• Praktik DevOps, alat, dan pengembangannya. Rencana utama perusahaan untuk tahun depan meliputi 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 keunggulan, inisiatif di tingkat atas dan bawah perusahaan.

Kami ingin mendengar tanggapan, cerita, umpan balik Anda. Kami berterima kasih kepada semua orang yang berpartisipasi dalam penelitian ini dan menantikan partisipasi Anda tahun depan.

Sumber: www.habr.com