Accelerate State of DevOps 2021

Laporan Accelerate State of DevOps tahun ini oleh tim DevOps Research and Assessment (DORA) di Google Cloud mewakili riset dan data selama tujuh tahun dari lebih dari 32.000 profesional di seluruh dunia.

Riset kami meneliti kemampuan dan praktik yang mendorong performa organisasi, operasional, dan pengiriman software. Dengan memanfaatkan teknik statistik yang ketat, kami ingin memahami praktik yang menghasilkan keunggulan dalam penyampaian teknologi dan pada hasil bisnis yang efektif. Untuk mencapainya, kami menyajikan insight berbasis data tentang cara paling efektif dan efisien untuk mengembangkan dan menyampaikan teknologi.

Riset kami terus menunjukkan bahwa keunggulan dalam pengiriman software dan performa operasional mendorong performa organisasi dalam transformasi teknologi. Agar tim dapat membandingkan diri mereka dengan industri tertentu, kami menggunakan analisis klaster untuk membentuk kategori performa yang bermakna (seperti pemain dengan performa rendah, sedang, tinggi, atau elit). Setelah tim Anda memiliki gambaran tentang performa mereka saat ini dibandingkan dengan industri, Anda dapat menggunakan temuan dari analisis prediktif kami untuk menargetkan praktik dan kemampuan guna meningkatkan hasil utama, dan pada akhirnya posisi relatif Anda. Tahun ini, kami menekankan pentingnya memenuhi target keandalan, dengan mengintegrasikan keamanan di seluruh supply chain software, membuat dokumentasi internal yang berkualitas, dan memanfaatkan cloud secara maksimal. Kami juga mengeksplorasi apakah budaya tim yang positif dapat memitigasi dampak bekerja dari jarak jauh sebagai akibat dari pandemi COVID-19.

Untuk mencapai peningkatan yang bermakna, tim harus mengadopsi filosofi peningkatan berkelanjutan. Gunakan tolok ukur untuk mengukur situasi Anda saat ini, identifikasi kendala berdasarkan kapabilitas yang diselidiki oleh riset, dan lakukan eksperimen dengan aneka peningkatan untuk meniadakan kendala tersebut. Eksperimen akan menghasilkan perpaduan antara kesuksesan dan kegagalan. Namun, dalam kedua skenario tersebut, tim dapat mengambil tindakan bermakna sebagai hasil dari pembelajaran yang diperoleh. 

Kelompok berperforma tertinggi terus bertambah dan terus meningkatkan standar.

Kelompok berperforma elit kini berjumlah 26% dari tim dalam studi kami, dan telah mengurangi lama pengerjaan perubahan pada produksi. Industri terus mengalami percepatan, dan tim memperoleh manfaat yang signifikan dari kegiatan tersebut.

SRE dan DevOps adalah filosofi yang saling melengkapi.

Tim yang memanfaatkan praktik operasional modern yang diuraikan oleh rekan Site Reliability Engineering (SRE) kami melaporkan performa operasional yang lebih tinggi. Tim yang memprioritaskan keunggulan pengiriman dan operasional melaporkan performa organisasi tertinggi.

Lebih banyak tim yang memanfaatkan cloud dan memperoleh manfaat signifikan dari upaya tersebut.

Tim terus memindahkan workload ke cloud dan tim yang memanfaatkan kelima kemampuan cloud mengalami peningkatan dalam performa pengiriman software dan operasional (SDO), serta performa organisasi. Penggunaan multicloud juga semakin meningkat sehingga tim dapat memanfaatkan kemampuan unik dari setiap penyedia.

supply chain software yang aman sangat penting dan meningkatkan performa.

Mengingat peningkatan serangan berbahaya yang signifikan dalam beberapa tahun terakhir, organisasi harus beralih dari praktik reaktif ke tindakan proaktif dan diagnostik. Tim yang mengintegrasikan praktik keamanan di seluruh supply chain software mereka mengirimkan software dengan cepat, andal, dan aman.

Dokumentasi yang baik merupakan fondasi agar berhasil mengimplementasikan kemampuan DevOps.

Untuk pertama kalinya, kami mengukur kualitas dokumentasi dan praktik internal yang berkontribusi pada kualitas ini. Tim dengan dokumentasi berkualitas tinggi akan lebih mampu menerapkan praktik teknis dan berperforma lebih baik secara keseluruhan.

Budaya tim yang positif dapat mengurangi kejenuhan dalam situasi yang menantang.

Budaya tim membuat perbedaan besar pada kemampuan tim untuk mengirimkan software dan memenuhi atau melampaui tujuan organisasi mereka. Tim inklusif dengan budaya generatif^1,2 tidak mengalami kejenuhan selama pandemi COVID-19. 

____________________________

1. Dari budaya organisasi tipologi Westrum, budaya tim generatif mengacu pada tim yang sangat kooperatif, mengurai silo, membiarkan kegagalan mengarah pada pertanyaan, dan berbagi risiko dalam pengambilan keputusan.

2. Westrum, R (2004). "Tipologi budaya organisasi." Kualitas & Keamanan BMJ, 13(suppl 2), ii22-ii27.

Kami memeriksa bagaimana tim mengembangkan, mengirimkan, dan mengoperasikan sistem software, lalu menyegmentasikan responden ke dalam empat klaster performa: elit, tinggi, sedang, dan rendah. Dengan membandingkan performa tim Anda dengan performa setiap klaster, Anda dapat melihat posisi Anda dalam konteks temuan yang dijelaskan di seluruh laporan ini.

Performa delivery software dan operasional

Untuk memenuhi permintaan industri yang terus berubah, organisasi harus menghadirkan dan mengoperasikan software dengan cepat dan andal. Makin cepat tim Anda dapat membuat perubahan pada software, makin cepat Anda dapat menyampaikan nilai kepada pelanggan, menjalankan eksperimen, dan menerima masukan berharga. Setelah mengumpulkan data dan melakukan riset selama delapan tahun, kami mengembangkan dan memvalidasi empat metrik yang mengukur performa pengiriman software. Sejak 2018, kami telah menyertakan metrik kelima untuk mencatat kemampuan operasional. 

Tim yang unggul dalam kelima ukuran tersebut menunjukkan performa organisasi yang istimewa. Kami menyebut kelima ukuran ini metrik performa pengiriman software dan operasional (SDO). Perhatikan bahwa metrik ini berfokus pada hasil tingkat sistem, yang membantu menghindari kesalahan umum metrik software, seperti mengadu fungsi satu sama lain dan membuat pengoptimalan lokal dengan mengorbankan hasil keseluruhan.

Keempat metrik performa pengiriman software dapat dipahami dari segi throughput dan stabilitas. Kami mengukur throughput menggunakan lama pengerjaan perubahan kode (artinya, waktu dari ketika kode di-commit hingga dirilis ke produksi) dan frekuensi deployment. Kami mengukur stabilitas menggunakan waktu untuk memulihkan layanan setelah terjadi insiden dan tingkat kegagalan perubahan.

Sekali lagi, analisis klaster dari keempat metrik pengiriman software mengungkapkan empat profil performa yang berbeda—elit, tinggi, sedang, dan rendah—dengan perbedaan signifikan secara statistik dalam ukuran throughput dan stabilitas di antara mereka. Seperti tahun-tahun sebelumnya, kelompok berperforma tertinggi secara signifikan lebih baik dalam keempat ukuran tersebut, dan kelompok berperforma rendah menjadi jauh lebih buruk di semua bidang.

Metrik kelima merepresentasikan performa operasional dan merupakan ukuran dari praktik operasional modern. Metrik utama untuk performa operasional adalah keandalan, yang merupakan sejauh mana tim dapat memegang janji dan pernyataan tentang software yang mereka operasikan. Selama ini, kami telah mengukur ketersediaan daripada keandalan, tetapi karena ketersediaan adalah fokus spesifik dari reliabilitas keandalan, kami telah memperluas ukuran kami pada keandalan sehingga ketersediaan, latensi, performa, dan skalabilitas terwakili secara lebih luas. Secara khusus, kami meminta responden menilai kemampuan mereka dalam mencapai atau melampaui target keandalan. Kami mendapati bahwa tim dengan berbagai tingkat performa pengiriman memperoleh hasil yang lebih baik jika mereka juga memprioritaskan performa operasional.

Seperti laporan sebelumnya, kami membandingkan kelompok berperforma elit dengan kelompok berperforma rendah untuk menggambarkan dampak dari kemampuan tertentu. Namun, tahun ini kami berusaha memperhitungkan dampak performa operasional. Di semua kategori performa pengiriman (rendah hingga elit), kami melihat manfaat besar di berbagai hasil untuk tim yang memprioritaskan pemenuhan atau melampaui target keandalan mereka.

Setiap tahun kami terus melihat industri berkembang dan mempercepat kemampuan untuk mengirimkan software dengan kecepatan yang lebih tinggi dan stabilitas yang lebih baik. Untuk pertama kalinya, dua per tiga responden merupakan kelompok berperforma tinggi dan elit. Selain itu, kelompok berperforma elit tahun ini sekali lagi menaikkan standar, sehingga mengurangi lama pengerjaan perubahan jika dibandingkan dengan penilaian sebelumnya (misalnya, meningkat dari kurang dari satu hari pada tahun 2019 menjadi kurang dari satu jam pada tahun 2021). Selain itu, untuk pertama kalinya, hanya kelompok berperforma elit yang berhasil meminimalkan tingkat kegagalan perubahan dibandingkan tahun-tahun sebelumnya. Saat itu, kelompok berperforma menengah dan tinggi dapat melakukan hal yang sama.

Throughput

Frekuensi deployment

Sesuai dengan tahun-tahun sebelumnya, kelompok elit melaporkan bahwa mereka secara rutin melakukan deployment sesuai permintaan dan melakukan beberapa deployment per hari. Sebagai perbandingan, kelompok berperforma rendah melaporkan deployment kurang dari satu kali per enam bulan (kurang dari dua kali per tahun), yang sekali lagi merupakan penurunan performa jika dibandingkan dengan tahun 2019. Jumlah deployment tahunan yang dinormalisasi berkisar antara 1.460 deployment per tahun (dihitung sebagai empat deployment per hari x 365 hari) untuk kelompok berperforma tertinggi hingga 1,5 deployment per tahun untuk kelompok berperforma rendah (rata-rata dua deployment dan satu deployment). Analisis ini memperkirakan bahwa kelompok berperforma elit men-deploy kode 973 kali lebih sering daripada kelompok berperforma rendah.

Lama pengerjaan perubahan

Sebagai peningkatan dari tahun 2019, kelompok berperforma elite melaporkan perubahan lama pengerjaan kurang dari satu jam, dengan lama pengerjaan perubahan yang diukur sebagai waktu mulai dari kode di-commit hingga kode tersebut berhasil di-deploy dalam produksi. Jumlah ini merupakan peningkatan performa jika dibandingkan dengan tahun 2019, saat kelompok berperforma tertinggi melaporkan lama pengerjaan perubahan kurang dari satu hari. Berbeda dengan kelompok berperforma elit, kelompok berperforma rendah membutuhkan lama pengerjaan lebih dari enam bulan. Dengan lama pengerjaan satu jam untuk kelompok berperforma elit (perkiraan konservatif “kurang dari satu jam”) dan 6.570 jam untuk kelompok berperforma rendah—dihitung dengan mengambil rata-rata 8.760 jam per tahun dan 4.380 jam selama enam bulan—kelompok elit memiliki lama pengerjaan perubahan 6.570 kali lebih cepat daripada kelompok berperforma rendah. 

Stabilitas

Waktu untuk memulihkan layanan

Kelompok elit melaporkan waktu pemulihan layanan kurang dari satu jam, sementara kelompok berperforma rendah melaporkan lebih dari enam bulan. Untuk perhitungan ini, kami memilih rentang waktu konservatif: satu jam untuk kelompok berperforma tinggi dan rata-rata satu tahun (8.760 jam) dan enam bulan (4.380 jam) untuk kelompok berperforma rendah. Berdasarkan angka-angka ini, kelompok elit memiliki waktu 6.570 kali lebih cepat untuk memulihkan layanan daripada kelompok berperforma rendah. Performa waktu untuk memulihkan layanan tetap sama untuk kelompok berperforma elit dan meningkat untuk kelompok berperforma rendah jika dibandingkan dengan tahun 2019.

Tingkat kegagalan perubahan

Kelompok berperforma elit melaporkan tingkat kegagalan perubahan antara 0%–15%, sementara kelompok berperforma rendah melaporkan tingkat kegagalan perubahan 16%–30%. Rata-rata di antara kedua rentang ini menunjukkan tingkat kegagalan perubahan 7,5% untuk kelompok berperforma elit dan 23% untuk kelompok berperforma rendah. Tingkat kegagalan perubahan untuk kelompok berperforma elit tiga kali lebih baik daripada untuk kelompok berperforma rendah. Tahun ini, tingkat kegagalan perubahan tetap sama untuk kelompok berperforma elit dan lebih baik untuk kelompok berperforma rendah jika dibandingkan dengan tahun 2019, tetapi lebih buruk untuk kelompok di antaranya. 

Membandingkan kelompok elit dengan kelompok berperforma rendah, kami menemukan bahwa kelompok berperforma elit memiliki:

• Deployment kode yang 973x lebih sering
• Waktu tunggu 6.570x lebih cepat mulai dari commit hingga deploy
• Tingkat kegagalan perubahan 3x lebih rendah (perubahan 1/3 lebih kecil kemungkinannya untuk gagal) 
• Waktu pemulihan dari insiden 6.570x lebih cepat 

Bagaimana cara meningkatkan SDO dan performa organisasi? Riset kami memberikan panduan berbasis bukti untuk membantu Anda berfokus pada kemampuan yang mendorong performa.

Laporan tahun ini membahas dampak cloud, praktik SRE, keamanan, praktik teknis, dan budaya. Di sepanjang bagian ini, kami memperkenalkan masing-masing kemampuan ini dan mencatat dampaknya terhadap berbagai hasil. Bagi Anda yang sudah memahami model riset State of DevOps DORA, kami telah membuat referensi online yang menghosting model tahun ini dan semua model sebelumnya.³

^{____________________________}

3. https://devops-research.com/models.htm

____________________________

Sejalan dengan Accelerate State of DevOps 2019, semakin banyak organisasi yang memilih solusi multicloud dan hybrid cloud. Dalam survei kami, responden ditanyai lokasi hosting layanan atau aplikasi utama mereka, dan penggunaan cloud publik meningkat. 56% responden menyatakan bahwa mereka menggunakan cloud publik (termasuk beberapa cloud publik), naik 5% dari tahun 2019. Tahun ini kami juga bertanya secara khusus tentang penggunaan multicloud, dan 21% responden melaporkan melakukan deployment ke beberapa cloud publik. 21% responden menyatakan tidak menggunakan cloud, dan justru menggunakan pusat data atau solusi lokal. Akhirnya, 34% responden melaporkan menggunakan hybrid cloud dan 29% melaporkan menggunakan cloud pribadi. 

Mempercepat hasil bisnis dengan hybrid dan multicloud

Tahun ini kami melihat pertumbuhan penggunaan hybrid dan multicloud, dengan dampak signifikan pada hasil yang diinginkan bisnis. Responden yang menggunakan hybrid atau multicloud memiliki kemungkinan 1,6 kali lebih besar untuk melampaui target performa organisasi mereka dibandingkan dengan responden yang tidak menggunakannya. Kami juga melihat dampak yang kuat pada SDO, dengan pengguna hybrid dan multicloud 1,4 kali lebih mungkin unggul dalam hal frekuensi deployment, lama pengerjaan perubahan, waktu pemulihan, tingkat kegagalan perubahan, dan keandalan.

Mengapa multicloud?

Serupa dengan penilaian kami pada tahun 2018, kami meminta responden melaporkan alasan mereka memanfaatkan beberapa penyedia cloud publik. Alih-alih memilih semua yang sesuai, tahun ini kami meminta responden untuk melaporkan alasan utama mereka menggunakan beberapa penyedia. Lebih dari seperempat (26%) responden melakukannya untuk memanfaatkan keunikan setiap penyedia cloud. Hal ini menunjukkan bahwa ketika responden memilih penyedia tambahan, mereka akan mencari perbedaan antara penyedia mereka saat ini dan penyedia alternatif. Alasan paling umum kedua untuk beralih ke multicloud adalah ketersediaan (22%). Tidak mengherankan, responden yang telah mengadopsi beberapa penyedia cloud 1,5 kali lebih mungkin untuk memenuhi atau melampaui target keandalan mereka.

Alasan utama menggunakan beberapa penyedia

Perubahan benchmark

Cara Anda mengimplementasikan infrastruktur cloud itu penting

Secara historis, kami menemukan bahwa tidak semua responden mengadopsi cloud dengan cara yang sama. Hal ini menyebabkan variasi dalam seberapa efektif adopsi cloud dalam mendorong hasil bisnis. Kami mengatasi keterbatasan ini dengan berfokus pada karakteristik penting cloud computing—seperti yang didefinisikan oleh National Institute of Standards and Technology (NIST)—dan menggunakannya sebagai panduan kami. Dengan menggunakan Definisi Cloud Computing dari NIST, kami menyelidiki dampak praktik penting terhadap performa SDO, bukan sekadar menyelidiki dampak adopsi cloud terhadap SDO.

Untuk ketiga kalinya, kami menyadari bahwa yang benar-benar penting adalah cara tim menerapkan layanan cloud mereka, bukan hanya penggunaan teknologi cloud. Kelompok berperforma terbaik 3,5 kali lebih mungkin untuk memenuhi semua karakteristik cloud NIST yang penting. Hanya 32% responden yang mengatakan bahwa mereka menggunakan infrastruktur cloud setuju atau sangat setuju bahwa mereka memenuhi kelima karakteristik penting cloud computing yang didefinisikan oleh NIST, meningkat 3% dari 2019. Secara keseluruhan, penggunaan karakteristik cloud computing NIST telah meningkat sebesar 14%–19%, dengan elastisitas cepat yang menunjukkan peningkatan terbesar.

Layanan mandiri sesuai permintaan

Konsumen dapat menyediakan resource komputasi sesuai kebutuhan, secara otomatis, tanpa perlu interaksi manusia dari penyedia.

73% responden menggunakan layanan mandiri on-demand, meningkat 16% dari 2019.

Akses jaringan yang luas

Kemampuan tersedia secara luas dan dapat diakses melalui berbagai klien seperti ponsel, tablet, laptop, dan workstation.

74% responden menggunakan akses jaringan yang luas, meningkat 14% dari 2019.

Penampungan resource

Resource penyedia ditampung di sebuah model multi-tenant, dengan resource virtual dan fisik ditetapkan dan dialihkan secara dinamis sesuai permintaan. Pelanggan umumnya tidak memiliki kontrol langsung atas lokasi persis resource yang disediakan, tetapi mereka dapat menentukan lokasi di tingkat abstraksi yang lebih tinggi, seperti negara, negara bagian/provinsi, atau pusat data.

73% responden menggunakan penggabungan sumber daya, meningkat 15% dari 2019.

Elastisitas yang cepat

Kemampuan dapat disediakan dan dirilis secara elastis untuk diskalakan dengan cepat ke luar atau ke dalam dengan permintaan. Kapabilitas konsumen yang dapat disediakan tampak tidak terbatas dan dapat disesuaikan dalam jumlah berapa pun dan pada waktu kapan pun.

77% responden menggunakan elastisitas cepat, meningkat 18% dari 2019.

Layanan yang terukur

Sistem cloud otomatis mengontrol dan mengoptimalkan penggunaan resource dengan memanfaatkan kapabilitas pengukuran di tingkat abstraksi yang sesuai dengan jenis layanan, seperti penyimpanan, pemrosesan, bandwidth, dan akun pengguna aktif. Penggunaan resource dapat dipantau, dikontrol, dan dilaporkan untuk transparansi. 

78% responden menggunakan layanan yang terukur, meningkat 16% dari 2019.

Saat komunitas DevOps muncul dalam konferensi dan diskusi publik, terbentuklah gerakan sepemikiran di dalam Google: site reliability engineering (SRE). SRE, dan pendekatan serupa, seperti disiplin rekayasa produksi Facebook, memiliki banyak tujuan dan teknik yang sama yang memotivasi DevOps. Pada tahun 2016, SRE secara resmi bergabung dengan wacana publik saat buku pertama⁴ tentang site reliability engineering diterbitkan. Gerakan tersebut berkembang sejak saat itu, dan saat ini komunitas praktisi SRE global berkolaborasi dalam praktik untuk operasi teknis.

Mungkin kebingungan muncul. Apa perbedaan antara SRE dan DevOps? Apakah saya harus memilih salah satunya? Manakah yang lebih baik? Sebenarnya, tidak ada konflik di sini; SRE dan DevOps sangat saling melengkapi, dan riset kami menunjukkan keselarasan keduanya. SRE adalah disiplin pembelajaran yang mengutamakan komunikasi lintas fungsi dan keamanan psikologis, nilai-nilai yang sama yang menjadi inti budaya generatif berorientasi performa pada tim DevOps elit. Memperluas dari prinsip utamanya, SRE memberikan teknik praktis, termasuk kerangka kerja metrik indikator tingkat layanan/tujuan tingkat layanan (SLI/SLO). Sama seperti framework produk ramping yang menentukan cara mencapai siklus masukan pelanggan dengan cepat yang didukung oleh riset kami, framework SRE menawarkan definisi tentang praktik dan alat yang dapat meningkatkan kemampuan tim untuk menepati janji secara konsisten kepada penggunanya.

Pada tahun 2021, kami memperluas penyelidikan kami ke operasi, dengan memperluas dari analisis ketersediaan layanan ke kategori keandalan yang lebih umum. Survei tahun ini memperkenalkan beberapa item yang terinspirasi oleh praktik SRE, untuk menilai sejauh mana tim:

• Mendefinisikan keandalan dalam hal perilaku yang ditampilkan kepada pengguna
• Menggunakan framework metrik SLI/SLO untuk memprioritaskan pekerjaan sesuai dengan anggaran error 
• Menggunakan otomatisasi untuk mengurangi pekerjaan manual dan pemberitahuan yang mengganggu
• Menentukan protokol dan latihan kesiapan untuk respons insiden
• Menerapkan prinsip keandalan di seluruh siklus proses pengiriman software ("jalankan pengujian sejak awal terhadap keandalan")

Dalam menganalisis hasilnya, kami menemukan bukti bahwa tim yang unggul dalam praktik operasional modern ini 1,4 kali lebih mungkin untuk melaporkan performa SDO yang lebih baik, dan 1,8 kali lebih mungkin untuk melaporkan hasil bisnis yang lebih baik.

Praktik SRE telah diadopsi oleh sebagian besar tim dalam studi kami: 52% responden melaporkan penggunaan praktik ini hingga batas tertentu, meskipun tingkat penggunaannya bervariasi antartim. Data tersebut menunjukkan bahwa penggunaan metode ini memprediksi keandalan yang lebih baik dan performa SDO keseluruhan yang lebih baik: SRE mendorong kesuksesan DevOps. 

Selain itu, kami menemukan bahwa model operasi tanggung jawab bersama, yang tercermin dalam sejauh mana developer dan operator diberdayakan bersama untuk berkontribusi pada keandalan, juga memprediksi hasil keandalan yang lebih baik.

Selain meningkatkan ukuran performa yang objektif, SRE meningkatkan pengalaman kerja praktisi teknis. Biasanya, individu dengan beban tugas operasional yang berat cenderung mengalami kejenuhan, tetapi SRE memiliki efek positif. Kami menemukan bahwa semakin banyak sebuah tim menerapkan praktik SRE, semakin kecil kemungkinan anggotanya untuk mengalami kejenuhan. SRE juga dapat membantu dalam mengoptimalkan resource: tim yang memenuhi target keandalan mereka melalui penerapan praktik SRE melaporkan bahwa mereka menghabiskan lebih banyak waktu untuk menulis kode daripada tim yang tidak mempraktikkan SRE.

Riset kami mengungkapkan bahwa tim dengan performa SDO di tingkat mana pun—dari rendah hingga elit—mungkin akan mendapatkan manfaat dari meningkatnya penggunaan praktik SRE. Semakin baik performa sebuah tim, semakin besar kemungkinan mereka menggunakan mode operasi modern: kelompok berperforma elit 2,1 kali lebih mungkin untuk melaporkan penggunaan praktik SRE dibandingkan dengan kelompok berperforma rendah. Namun, bahkan tim yang beroperasi di tingkat tertinggi pun memiliki ruang untuk berkembang: hanya 10% responden elit yang menyatakan bahwa tim mereka telah sepenuhnya menerapkan setiap praktik SRE yang kami selidiki. Dengan performa SDO di berbagai industri yang terus meningkat, pendekatan setiap tim terhadap operasi menjadi pendorong penting untuk peningkatan DevOps yang berkelanjutan.

____________________________

4. Betsy Beyer et al., eds., Site Reliability Engineering (O'Reilly Media, 2016).

____________________________

Dokumentasi

Tahun ini, kami melihat kualitas dokumentasi internal, yaitu dokumentasi—seperti panduan, README, dan bahkan komentar kode—untuk layanan dan aplikasi yang dikerjakan oleh tim. Kami mengukur kualitas dokumentasi berdasarkan sejauh mana dokumentasi tersebut:

• Membantu pembaca mencapai tujuan mereka
• Akurat, terbaru, dan komprehensif
• Dapat ditemukan, tersusun dengan baik, dan jelas⁵

Mencatat dan mengakses informasi tentang sistem internal adalah bagian penting dari pekerjaan teknis sebuah tim. Kami menemukan bahwa sekitar 25% responden memiliki dokumentasi berkualitas baik, dan dampak pekerjaan dokumentasi ini jelas: tim dengan dokumentasi berkualitas lebih tinggi memiliki kemungkinan 2,4 kali lebih besar untuk memperoleh performa pengiriman software dan operasional (SDO) yang lebih baik. Tim dengan dokumentasi yang baik dapat mengirimkan software lebih cepat dan lebih andal daripada tim dengan dokumentasi yang buruk. Dokumentasi tidak harus sempurna. Riset kami menunjukkan bahwa setiap peningkatan kualitas dokumentasi memiliki dampak positif dan langsung terhadap performa.

Lingkungan teknologi saat ini memiliki sistem yang semakin kompleks, serta pakar dan peran khusus untuk berbagai aspek dari sistem ini. Mulai dari keamanan hingga pengujian, dokumentasi adalah cara utama untuk berbagi pengetahuan dan bimbingan khusus antara sub-tim khusus ini dan dengan tim yang lebih luas.

Kami menemukan bahwa kualitas dokumentasi memprediksi keberhasilan tim dalam menerapkan praktik teknis. Praktik ini selanjutnya memprediksi peningkatan kemampuan teknis sistem, seperti kemampuan observasi, pengujian berkelanjutan, dan otomatisasi deployment. Kami mendapati bahwa tim dengan dokumentasi kualitas:

• 3,8 kali lebih mungkin untuk menerapkan praktik keamanan
• 2,4 kali lebih mungkin untuk memenuhi atau melampaui target keandalan mereka
• 3,5 kali lebih mungkin menerapkan praktik site reliability engineering (SRE) 
• 2,5 kali lebih mungkin untuk memanfaatkan cloud sepenuhnya

Cara meningkatkan kualitas dokumentasi

Pekerjaan teknis melibatkan pencarian dan penggunaan informasi, tetapi dokumentasi berkualitas bergantung pada orang yang menulis dan mengelola isinya. Pada tahun 2019, riset kami menemukan bahwa akses ke sumber informasi internal dan eksternal mendukung produktivitas. Riset tahun ini membawa investigasi ini selangkah lebih maju untuk melihat kualitas dokumentasi yang diakses, dan praktik yang berdampak pada kualitas dokumentasi ini.

Riset kami menunjukkan bahwa praktik berikut memiliki dampak positif yang signifikan terhadap kualitas dokumentasi:

Dokumentasikan kasus penggunaan penting untuk produk dan layanan Anda. Apa yang Anda dokumentasikan tentang sistem adalah hal penting, dan kasus penggunaannya memungkinkan pembaca memanfaatkan informasi dan sistem Anda.

Buat panduan yang jelas untuk memperbarui dan mengedit dokumentasi yang sudah ada. Sebagian besar pekerjaan dokumentasi adalah mengelola isi yang sudah ada. Ketika anggota tim tahu cara memperbarui atau menghapus informasi yang tidak akurat atau tidak berlaku lagi, tim dapat menjaga kualitas dokumentasi bahkan saat sistem berubah dari waktu ke waktu.

Tetapkan pemilik. Tim dengan dokumentasi berkualitas lebih cenderung memiliki kepemilikan dokumentasi yang jelas. Kepemilikan memungkinkan tanggung jawab eksplisit untuk menulis konten baru dan memperbarui atau memverifikasi perubahan pada isinya yang sudah ada. Tim dengan dokumentasi berkualitas lebih cenderung menyatakan bahwa dokumentasi ditulis untuk semua fitur utama dari aplikasi yang mereka kerjakan, dan kepemilikan yang jelas membantu menciptakan cakupan yang luas ini.

Sertakan dokumentasi sebagai bagian dari proses pengembangan software. Tim yang membuat dokumentasi dan memperbaruinya saat sistem berubah memiliki dokumentasi dengan kualitas yang lebih tinggi. Seperti pengujian, pembuatan dan pemeliharaan dokumentasi adalah bagian integral dari proses pengembangan software berperforma tinggi.

Akui pekerjaan dokumentasi selama peninjauan performa dan promosi. Pengakuan berkorelasi dengan kualitas dokumentasi secara keseluruhan. Menulis dan memelihara dokumentasi adalah bagian inti dari pekerjaan software engineering, dan dengan memperlakukan dokumentasi tersebut, kualitasnya akan meningkat.

Referensi lain yang kami temukan untuk mendukung dokumentasi kualitas mencakup:

• Pelatihan tentang cara menulis dan memelihara dokumentasi
• Pengujian otomatis untuk contoh kode atau dokumentasi yang tidak lengkap
• Pedoman, seperti panduan gaya dokumentasi dan panduan penulisan untuk audiens global

Dokumentasi adalah dasar untuk mengimplementasikan kapabilitas DevOps dengan sukses. Dokumentasi berkualitas lebih tinggi memperkuat hasil investasi pada kapabilitas DevOps individual, seperti keamanan, keandalan, dan pemanfaatan cloud sepenuhnya. Menerapkan praktik untuk mendukung dokumentasi kualitas akan berhasil melalui kemampuan teknis yang lebih kuat dan performa SDO yang lebih tinggi.

____________________________

5. Metrik kualitas yang didasarkan pada riset yang ada tentang dokumentasi teknis, seperti:

— Aghajani, E. et al. (2019). Masalah Dokumentasi Software Terungkap. Rangkaian Acara Konferensi Internasional tentang Software Engineering ke-41 IEEE/ACM 2019, 1199-1210. https://doi.org/10.1109/ICSE.2019.00122

— Plösch, R., Dautovic, A. & Saft, M. (2014). Nilai Kualitas Dokumentasi Software. Rangkaian Acara Konferensi Internasional tentang Kualitas Software, 333-342. https://doi.org/10.1109/QSIC.2014.22

— Zhi, J. et al. (2015). Manfaat biaya dan kualitas dokumentasi pengembangan software: Pemetaan sistematis. Jurnal Sistem dan Software, 99(C), 175-198. https://doi.org/10.1016/j.jss.2014.09.042

____________________________

Keamanan

[Jalankan pengujian di awal] dan integrasikan ke seluruh bagian

Seiring akselerasi dan perkembangan tim teknologi, kuantitas dan kerumitan ancaman keamanan pun ikut bertambah. Pada tahun 2020, lebih dari 22 miliar catatan informasi pribadi atau data bisnis rahasia terungkap, menurut Laporan Retrospektif Lanskap Ancaman 2020 dari Tenable.⁶ Keamanan tidak dapat menjadi renungan atau langkah terakhir sebelum pengiriman, keamanan harus terintegrasi di seluruh proses pengembangan perangkat lunak.

Untuk mengirimkan software dengan aman, praktik keamanan harus berkembang lebih cepat daripada teknik yang digunakan oleh pelaku kejahatan. Selama serangan supply chain software SolarWinds dan Codecov tahun 2020, peretas membobol sistem build SolarWinds dan skrip uploader bash Codecov⁷ untuk secara diam-diam menyematkan diri ke dalam infrastruktur ribuan pelanggan perusahaan tersebut. Mengingat dampak serangan tersebut secara luas, industri harus beralih dari pendekatan preventif ke diagnostik, di mana tim software harus berasumsi bahwa sistem mereka sudah disusupi dan mengintegrasikan keamanan ke dalam supply chain mereka.

Sesuai dengan laporan sebelumnya, kami menemukan bahwa kelompok berperforma elit unggul dalam menerapkan praktik keamanan. Tahun ini, kelompok berperforma elit yang memenuhi atau melampaui target keandalan mereka dua kali lipat lebih mungkin mengintegrasikan keamanan ke dalam proses pengembangan software mereka. Hal ini menunjukkan bahwa tim yang telah mempercepat pengiriman sambil mempertahankan standar keandalan mereka telah menemukan cara untuk mengintegrasikan pemeriksaan dan praktik keamanan tanpa mengorbankan kemampuan mereka untuk mengirimkan software dengan cepat atau andal.

Selain menunjukkan performa pengiriman dan operasional yang tinggi, tim yang mengintegrasikan praktik keamanan di seluruh proses pengembangan 1,6 kali lebih mungkin untuk memenuhi atau melampaui tujuan organisasi. Tim pengembangan yang mendukung keamanan melihat nilai signifikan yang didorong pada bisnis.

____________________________

6. https://www.tenable.com/cyber-exposure/2020-threat-landscape-retrospective

7. https://www.cybersecuritydive.com/news/codecov-breach-solarwinds-software-supply-chain/598950/

____________________________

Cara melakukannya dengan benar

Sangat mudah untuk menekankan pentingnya keamanan dan menyarankan agar tim perlu memprioritaskannya, tetapi cara ini memerlukan beberapa perubahan dari metode keamanan informasi tradisional. Anda dapat mengintegrasikan keamanan, meningkatkan performa operasional dan pengiriman software, serta meningkatkan performa organisasi dengan memanfaatkan praktik berikut:

Menguji keamanan. Uji persyaratan keamanan sebagai bagian dari proses pengujian otomatis, termasuk area tempat kode yang telah disetujui sebelumnya harus digunakan.

Integrasikan peninjauan keamanan ke dalam setiap fase. Mengintegrasikan keamanan informasi (InfoSec) ke dalam pekerjaan sehari-hari di seluruh siklus proses pengiriman software. Ini termasuk meminta tim InfoSec memberikan masukan selama fase desain dan arsitektur aplikasi, menghadiri demo perangkat lunak, dan memberikan masukan selama demo.

Peninjauan keamanan. Lakukan peninjauan keamanan untuk semua fitur utama. Buat kode yang telah disetujui sebelumnya. Minta tim InfoSec untuk membangun library, paket, toolchain, dan proses yang telah disetujui sebelumnya dan mudah dikonsumsi untuk digunakan oleh developer dan operator IT dalam pekerjaan mereka. Undang InfoSec lebih awal dan lebih sering. Libatkan InfoSec selama perencanaan dan semua fase pengembangan aplikasi selanjutnya, sehingga mereka dapat menemukan kelemahan terkait keamanan lebih awal, sehingga memberi tim cukup waktu untuk memperbaikinya.

Buat kode yang telah disetujui sebelumnya. Minta tim InfoSec untuk membangun library, paket, toolchain, dan proses yang telah disetujui sebelumnya dan mudah dikonsumsi untuk digunakan oleh developer dan operator IT dalam pekerjaan mereka.

Undang InfoSec lebih awal dan lebih sering. Libatkan InfoSec selama perencanaan dan semua fase pengembangan aplikasi selanjutnya, sehingga mereka dapat menemukan kelemahan terkait keamanan lebih awal, sehingga memberi tim cukup waktu untuk memperbaikinya.

Seperti yang telah disebutkan sebelumnya, dokumentasi berkualitas tinggi mendorong keberhasilan berbagai kemampuan sekaligus keamanan. Kami mendapati bahwa tim dengan dokumentasi berkualitas tinggi 3,8 kali lebih mungkin untuk mengintegrasikan keamanan selama proses pengembangan mereka. Tidak semua orang dalam suatu organisasi memiliki keahlian dalam kriptografi. Keahlian mereka paling baik dibagikan dalam organisasi melalui praktik keamanan terdokumentasi.

Riset kami menunjukkan bahwa organisasi yang melakukan transformasi DevOps dengan mengadopsi continuous delivery cenderung memiliki proses yang berkualitas tinggi, berisiko rendah, dan hemat biaya.

Secara khusus, kami mengukur praktik teknis berikut:

• Arsitektur yang dikaitkan secara longgar
• Pengembangan berbasis trunk
• Pengujian berkelanjutan
• Continuous integration
• Penggunaan teknologi open source
• Praktik pemantauan dan kemampuan observasi
• Pengelolaan perubahan database
• Otomatisasi deployment

Kami mendapati bahwa meskipun semua praktik ini meningkatkan continuous delivery, arsitektur yang dikaitkan secara longgar dan pengujian berkelanjutan memiliki dampak terbesar. Misalnya, tahun ini kami mendapati bahwa kelompok berperforma elit yang memenuhi target keandalan mereka memiliki kemungkinan tiga kali lebih besar untuk menggunakan arsitektur yang dikaitkan secara longgar daripada rekan-rekan mereka yang berperforma rendah.

Arsitektur yang dikaitkan secara longgar

Riset kami terus menunjukkan bahwa Anda dapat meningkatkan performa IT dengan berupaya mengurangi ketergantungan yang terperinci antara layanan dan tim. Faktanya, ini adalah salah satu prediktor terkuat dari continuous delivery yang sukses. Menggunakan arsitektur yang dikaitkan secara longgar, tim dapat menskalakan, gagal, menguji, dan men-deploy secara terpisah satu sama lain. Tim dapat bergerak dengan tempo mereka sendiri, bekerja dalam kelompok yang lebih kecil, mengakumulasi lebih sedikit utang teknis, dan pulih lebih cepat dari kegagalan.

Pengujian berkelanjutan dan continuous integration

Serupa dengan temuan kami dari tahun-tahun sebelumnya, kami menunjukkan bahwa pengujian berkelanjutan adalah prediktor kuat dari keberhasilan continuous delivery. Tim elit yang memenuhi target keandalan mereka 3,7 kali lebih mungkin untuk memanfaatkan pengujian berkelanjutan. Dengan menggabungkan pengujian awal dan sering selama proses pengiriman, dengan penguji yang bekerja bersama developer di seluruh proses, tim dapat melakukan iterasi dan membuat perubahan pada produk, layanan, atau aplikasi mereka dengan lebih cepat. Anda dapat menggunakan feedback loop ini untuk memberikan nilai kepada pelanggan Anda sekaligus dengan mudah menerapkan praktik seperti pengujian otomatis dan continuous integration. 

Continuous integration juga meningkatkan continuous delivery. Kelompok berperforma elit yang memenuhi target keandalan mereka 5,8 kali lebih mungkin untuk memanfaatkan continuous integration. Dalam continuous integration, setiap commit memicu build software dan menjalankan serangkaian pengujian otomatis yang memberikan masukan dalam beberapa menit. Dengan continuous integration, Anda mengurangi koordinasi manual yang sering kali rumit yang diperlukan untuk keberhasilan integrasi.

Continuous integration, seperti yang didefinisikan oleh Kent Beck dan komunitas Extreme Programming, tempat asalnya, juga mencakup praktik pengembangan berbasis trunk, yang akan dibahas selanjutnya.⁷

Pengembangan berbasis trunk

Riset kami secara konsisten menunjukkan bahwa organisasi berperforma tinggi lebih mungkin menerapkan pengembangan berbasis trunk, di mana developer bekerja dalam batch kecil dan sering menggabungkan pekerjaan mereka ke dalam trunk bersama. Faktanya, kelompok berperforma elit yang memenuhi target keandalan mereka 2,3 kali lebih mungkin untuk menggunakan pengembangan berbasis trunk. Kelompok berperforma rendah lebih cenderung menggunakan cabang yang berumur panjang dan menunda penggabungan.

Tim harus menggabungkan pekerjaan mereka setidaknya sekali sehari—beberapa kali sehari jika memungkinkan. Pengembangan berbasis trunk terkait erat dengan continuous integration, sehingga Anda harus menerapkan dua praktik teknis ini secara serentak, karena keduanya memiliki dampak yang lebih besar saat digunakan bersama.

Otomatisasi deployment

Dalam lingkungan kerja yang ideal, komputer melakukan tugas berulang sementara manusia fokus pada pemecahan masalah. Menerapkan otomatisasi deployment membantu tim Anda lebih dekat dengan tujuan ini. 

Saat Anda memindahkan software dari pengujian ke produksi secara otomatis, Anda mengurangi lama pengerjaan dengan memungkinkan deployment yang lebih cepat dan efisien. Anda juga mengurangi kemungkinan error deployment, yang lebih umum terjadi dalam deployment manual. Saat tim Anda menggunakan otomatisasi deployment, mereka menerima masukan langsung, yang dapat membantu Anda meningkatkan layanan atau produk dengan kecepatan yang jauh lebih cepat. Meskipun Anda tidak perlu menerapkan pengujian berkelanjutan, continuous integration, dan deployment otomatis secara bersamaan, kemungkinan besar Anda akan mendapatkan peningkatan yang lebih besar jika menggunakan ketiga praktik ini secara bersamaan. 

Manajemen perubahan database

Melacak perubahan melalui kontrol versi adalah bagian penting dari penulisan dan pemeliharaan kode, serta dalam mengelola database. Menurut riset kami, kelompok berperforma elit yang memenuhi target keandalan mereka 3,4 kali lebih mungkin untuk menjalankan manajemen perubahan database dibandingkan dengan kelompok berperforma rendah. Selain itu, kunci keberhasilan manajemen perubahan database adalah kolaborasi, komunikasi, dan transparansi di semua tim yang relevan. Meskipun Anda dapat memilih di antara pendekatan tertentu untuk diterapkan, kami menyarankan setiap kali Anda perlu melakukan perubahan pada database, tim harus berkumpul dan meninjau perubahan sebelum Anda memperbarui database. 

____________________________

8. Beck, K. (2000). Penjelasan pemrograman ekstrem: Menerima perubahan. Addison-Wesley Professional

____________________________

Kemampuan observasi dan pemantauan

Seperti pada tahun-tahun sebelumnya, kami mendapati bahwa praktik pemantauan dan kemampuan observasi mendukung continuous delivery. Kelompok berperforma elit yang berhasil memenuhi target keandalan mereka 4,1 kali lebih mungkin untuk memiliki solusi yang menyertakan kemampuan observasi ke dalam kesehatan sistem secara keseluruhan. Praktik kemampuan observasi memberi tim Anda pemahaman yang lebih baik tentang sistem Anda, yang mengurangi waktu yang diperlukan untuk mengidentifikasi dan memecahkan masalah. Riset kami juga menunjukkan bahwa tim dengan praktik observasi yang baik menghabiskan lebih banyak waktu untuk coding. Salah satu penjelasan yang mungkin untuk temuan ini adalah bahwa menerapkan praktik kemampuan observasi membantu menghemat waktu developer, dari menelusuri penyebab masalah menuju pemecahan masalah dan pada akhirnya kembali ke coding. 

Teknologi open source

Banyak developer sudah memanfaatkan teknologi open source, dan pemahaman mereka terhadap alat ini merupakan kekuatan bagi organisasi. Kelemahan utama dari teknologi closed source adalah bahwa teknologi tersebut membatasi kemampuan Anda untuk mentransfer pengetahuan masuk dan keluar dari organisasi. Misalnya, Anda tidak dapat mempekerjakan seseorang yang sudah memahami alat-alat organisasi Anda, dan developer tidak dapat mentransfer pengetahuan yang telah mereka kumpulkan ke organisasi lain. Sebaliknya, sebagian besar teknologi open source memiliki komunitas di sekitarnya, yang dapat digunakan developer untuk mendapatkan dukungan. Teknologi open source lebih mudah diakses, biayanya relatif rendah, dan dapat disesuaikan. Kelompok berperforma elit yang memenuhi target keandalan mereka 2,4 kali lebih mungkin untuk memanfaatkan teknologi open source. Sebaiknya beralih untuk menggunakan lebih banyak software open source saat Anda mengimplementasikan transformasi DevOps. 

Untuk mengetahui informasi selengkapnya tentang kemampuan DevOps teknis, lihat kemampuan DORA di https://cloud.google.com/devops/capabilities

COVID-19

Tahun ini kami menyelidiki faktor-faktor yang memengaruhi performa tim selama pandemi COVID-19. Secara khusus, apakah pandemi COVID-19 berdampak negatif pada performa pengiriman software dan operasional (SDO)? Apakah tim mengalami kejenuhan yang lebih besar sebagai akibatnya? Terakhir, faktor apa yang menjanjikan untuk mengurangi kejenuhan?

Pertama, kami ingin memahami dampak pandemi terhadap performa penayangan dan operasional. Banyak organisasi memprioritaskan modernisasi untuk mengakomodasi perubahan pasar yang dramatis (misalnya, peralihan dari pembelian secara langsung ke online). Di bab “Bagaimana perbandingan kita?”, kita membahas bagaimana kinerja di industri perangkat lunak telah meningkat secara signifikan dan terus berakselerasi. Tim berperforma lebih tinggi kini menjadi mayoritas sampel kami, dan kelompok berperforma elit terus meningkatkan standar, dengan melakukan deployment lebih sering dengan waktu pengerjaan yang lebih singkat, waktu pemulihan yang lebih cepat, dan tingkat kegagalan perubahan yang lebih baik. Demikian pula, studi yang dilakukan oleh peneliti GitHub menunjukkan peningkatan aktivitas developer (yaitu, push, permintaan pull, permintaan pull yang ditinjau, dan masalah yang dikomentari per pengguna⁹) sepanjang tahun 2020. Bisa dibilang, industri terus mengalami akselerasi meskipun pandemi melanda, bukan karena pandemi, tetapi perlu diperhatikan bahwa kami tidak melihat tren penurunan performa SDO selama periode yang mengerikan ini.

Pandemi mengubah cara kita bekerja, dan bagi banyak orang, pandemi mengubah lokasi kita bekerja. Oleh karena itu, kami melihat dampak bekerja dari jarak jauh sebagai akibat dari pandemi. Kami mendapati bahwa 89% responden bekerja dari rumah karena pandemi. Hanya 20% yang melaporkan pernah bekerja dari rumah sebelum pandemi. Peralihan ke lingkungan kerja jarak jauh memiliki implikasi yang signifikan terhadap cara kita mengembangkan software, menjalankan bisnis, dan bekerja sama. Bagi banyak orang, kerja dari rumah menghilangkan kemampuan untuk terhubung melalui percakapan di lorong secara mendadak atau berkolaborasi secara langsung. 

____________________________

9. https://octoverse.github.com/

____________________________

Apa yang mengurangi kejenuhan?

Meskipun demikian, kami menemukan faktor yang berpengaruh besar pada apakah sebuah tim mengalami kejenuhan atau tidak akibat bekerja dari jarak jauh: budaya. Tim dengan budaya tim generatif, yang terdiri dari orang-orang yang merasa diikutsertakan dan merasa menjadi bagian dalam tim, memiliki kemungkinan mengalami kejenuhan selama pandemi hanya separuh dari tim yang tidak demikian. Temuan ini menegaskan pentingnya memprioritaskan tim dan budaya. Tim yang lebih baik memiliki persiapan untuk menghadapi periode yang lebih menantang yang memberikan tekanan pada tim maupun individu. 

Budaya

Secara umum, budaya adalah arus bawah interpersonal yang tidak dapat dihindari dari setiap organisasi. Ini adalah hal apa pun yang memengaruhi bagaimana karyawan berpikir, berperasaan, dan berperilaku terhadap organisasi dan satu sama lain. Semua organisasi memiliki budaya unik mereka sendiri, dan temuan kami secara konsisten menunjukkan bahwa budaya merupakan salah satu pendorong utama performa organisasi dan IT. Secara khusus, analisis kami menunjukkan bahwa budaya generatif—yang diukur menggunakan tipologi budaya organisasi Westrum, serta rasa memiliki dan inklusi orang dalam organisasi—memprediksi performa pengiriman software dan operasional (SDO) yang lebih tinggi. Misalnya, kami mendapati bahwa kelompok berperforma elit yang memenuhi target keandalan mereka 2,9 kali lebih mungkin untuk memiliki budaya tim generatif dibandingkan dengan kelompok berperforma rendah. Demikian pula, budaya generatif memprediksi performa organisasi yang lebih tinggi dan tingkat kejenuhan karyawan yang lebih rendah. Singkatnya, budaya benar-benar penting. Untungnya, budaya itu dinamis, multifaset, dan selalu berubah-ubah, sehingga menjadi sesuatu yang dapat Anda ubah.

Agar dapat berhasil menjalankan DevOps, organisasi Anda harus memiliki tim yang bekerja secara kolaboratif dan lintas fungsi. Pada tahun 2018, kami mendapati bahwa tim berperforma tinggi dua kali lebih mungkin mengembangkan dan menghasilkan software dalam satu tim lintas fungsi. Hal ini mempertegas bahwa kolaborasi dan kerja sama sangat penting untuk keberhasilan organisasi mana pun. Satu pertanyaan utamanya adalah: faktor apa yang berkontribusi dalam menciptakan lingkungan yang mendorong dan merayakan kolaborasi lintas fungsi?

Selama bertahun-tahun, kami telah mencoba menjadikan konstruksi budaya yang nyata dan memberi komunitas DevOps pemahaman yang lebih baik tentang dampak budaya terhadap performa organisasi dan IT. Kami memulai perjalanan ini dengan mendefinisikan budaya secara operasional menggunakan tipologi budaya organisasi Westrum. Dia mengidentifikasi tiga jenis organisasi: berorientasi pada kekuasaan, berorientasi pada aturan, dan berorientasi pada performa. Kami menggunakan framework ini dalam riset kami sendiri dan menemukan bahwa budaya organisasi berorientasi performa yang mengoptimalkan aliran informasi, kepercayaan, inovasi, dan pembagian risiko merupakan prediksi performa SDO yang tinggi.

Seiring berkembangnya pemahaman kami tentang budaya dan DevOps, kami telah berupaya memperluas definisi awal budaya kami untuk menyertakan faktor psikososial lainnya seperti keselamatan psikologis. Organisasi berperforma tinggi lebih cenderung memiliki budaya yang mendorong karyawan untuk mengambil risiko yang telah diperhitungkan dan memoderasi risiko tanpa takut akan konsekuensi negatif.

Rasa memiliki dan inklusi

Mengingat budaya dampak yang kuat dan konsisten terhadap performa, tahun ini kami memperluas model kami untuk mengeksplorasi apakah rasa memiliki dan inklusi karyawan berkontribusi pada pengaruh budaya terhadap performa yang bermanfaat.

Penelitian psikologis telah menunjukkan bahwa orang pada dasarnya termotivasi untuk membentuk dan mempertahankan hubungan yang kuat dan stabil dengan orang lain.¹⁰ Kita termotivasi untuk merasa terhubung dengan orang lain dan merasa diterima dalam berbagai kelompok yang kita huni. Perasaan memiliki akan mengarah pada berbagai hasil fisik dan psikologis yang menguntungkan. Misalnya, riset menunjukkan bahwa perasaan memiliki berdampak positif terhadap motivasi dan mengarah pada peningkatan pencapaian akademis.¹¹

Salah satu komponen dari rasa keterhubungan ini adalah gagasan bahwa orang harus merasa nyaman membawa seluruh diri mereka ke tempat kerja serta bahwa pengalaman dan latar belakang unik mereka dihargai dan dirayakan.¹² Berfokus pada penciptaan budaya rasa memiliki yang inklusif dalam organisasi membantu menciptakan tenaga kerja yang berkembang, beragam, dan termotivasi.

Hasil kami menunjukkan bahwa organisasi yang berorientasi pada performa yang menghargai rasa memiliki dan inklusi lebih cenderung memiliki tingkat kejenuhan karyawan yang lebih rendah dibandingkan dengan organisasi yang memiliki budaya organisasi yang kurang positif.

Mengingat bukti yang menunjukkan bagaimana faktor psikososial memengaruhi performa SDO dan tingkat kejenuhan di antara karyawan, kami merekomendasikan bahwa jika Anda ingin mencapai transformasi DevOps yang sukses, sebaiknya lakukan upaya untuk mengatasi masalah terkait budaya sebagai bagian dari upaya transformasi. 

____________________________

10. Baumeister & Leary, 1995. Kebutuhan untuk memiliki: Keinginan akan hubungan interpersonal sebagai motivasi manusia yang mendasar. Buletin Psikologis, 117(3), 497–529. https://doi.org/10.1037/0033-2909.117.3.497

11. Walton et al., 2012. Hanya rasa memiliki: kekuatan hubungan sosial. Jurnal Psikologi Kepribadian dan Sosial, 102(3):513-32. https://doi.org/10.1037/a0025731

12. Mor Barak & Daya, 2014; Mengelola keberagaman: Menuju tempat kerja yang inklusif secara global. Sage. Shore, Cleveland, & Sanchez, 2018; Tempat kerja inklusif: Tinjauan dan model, Tinjauan Sumber Daya Manusia. https://doi.org/10.1016/j.hrmr.2017.07.003

Dengan riset selama tujuh tahun dan lebih dari 32.000 respons survei dari para profesional industri, Accelerate State of DevOps 2021 menampilkan praktik DevOps dan pengembangan software yang membuat tim dan organisasi meraih kesuksesan. 

Tahun ini, lebih dari 1.200 profesional dari berbagai industri di seluruh dunia membagikan pengalaman mereka untuk membantu kami mengembangkan pemahaman tentang faktor-faktor yang mendorong performa yang lebih tinggi. Ringkasnya, representasi di semua kategori demografi dan firmografi tetap luar biasa konsisten.

Mirip dengan tahun-tahun sebelumnya, kami mengumpulkan informasi demografi dari setiap responden survei. Kategorinya meliputi gender, disabilitas, dan kelompok yang kurang terwakili.

Demografi dan firmografi 

Representasi tahun ini konsisten dengan tahun-tahun sebelumnya di semua kategori firmografi, termasuk ukuran perusahaan, industri, dan wilayah. Sekali lagi, lebih dari 60% responden bekerja sebagai engineer atau manajer, dan sepertiga responden bekerja dalam industri teknologi. Selain itu, kami melihat representasi industri dari jasa keuangan, retail, dan perusahaan industri/manufaktur. 

____________________________

13. https://www.washingtongroup-disability.com/question-sets/wg-short-set-on-functioning-wg-ss/

____________________________

Gender

Konsisten dengan survei sebelumnya, sampel tahun ini terdiri dari 83% pria, 12% perempuan, dan 1% non-biner. Responden menyatakan bahwa perempuan membentuk tim sekitar 25% dari jumlahnya, yang merupakan peningkatan besar dari tahun 2019 (16%) dan sekali lagi selaras dengan tahun 2018 (25%)

Disabilitas

Disabilitas diidentifikasi berdasarkan enam dimensi sesuai panduan dari Washington Group Short Set.¹³ Ini adalah tahun ketiga kami menanyakan tentang disabilitas. Persentase difabel konsisten dengan data dalam laporan tahun 2019 kami, yakni 9%.

Kelompok yang kurang terwakili

Identifikasi sebagai anggota kelompok kurang terwakili dapat mengacu pada ras, gender, atau karakteristik lainnya. Ini adalah tahun keempat kami menanyakan tentang kekurang-terwakilan. Persentase responden yang mengidentifikasi dirinya sebagai kurang terwakili meningkat tipis dari 13,7% pada tahun 2019 menjadi 17% pada tahun 2021.

Lama bekerja

Responden dari survei tahun ini sangat berpengalaman, dengan 41% memiliki pengalaman setidaknya 16 tahun. Lebih dari 85% responden kami memiliki pengalaman setidaknya 6 tahun.

Departemen

Sebagian besar responden terdiri dari individu yang bekerja di tim pengembangan atau engineering (23%), tim DevOps atau SRE (21%), pengelola (18%), dan tim operasional atau infrastruktur IT (9%). Kami melihat penurunan jumlah representasi dari konsultan (4% pada tahun 2019 menjadi 2%), dan peningkatan eksekutif level C (4% pada tahun 2019 menjadi 9%). 

Industri

Seperti dalam laporan Accelerate State of DevOps sebelumnya, kami melihat bahwa sebagian besar responden bekerja di industri teknologi, diikuti oleh jasa keuangan, retail, dan lainnya.

Karyawan

Konsisten dengan laporan Accelerate State of DevOps sebelumnya, responden berasal dari berbagai skala organisasi. 22% responden berasal dari perusahaan yang memiliki lebih dari 10.000 karyawan, sedangkan 7% responden dari perusahaan yang mempekerjakan 5.000–9.999 karyawan. 15% responden lainnya berasal dari organisasi dengan 2.000–4.999 karyawan. Kami juga melihat representasi responden yang adil dari organisasi dengan 500–1.999 karyawan sebesar 13%, 100–499 karyawan sebesar 15%, dan akhirnya 20–99 karyawan sebesar 15%. 

Ukuran tim

Lebih dari setengah responden (62%) bekerja dalam tim dengan 10 anggota atau kurang (28% untuk 6–10, 27% untuk 2–5, dan 6% untuk tim satu orang). 19% lainnya bekerja dalam tim yang beranggotakan 11–20 orang.

Region

Survei tahun ini mengalami penurunan respons dari Amerika Utara (50% pada tahun 2019 menjadi 39% pada tahun 2021). Sebaliknya, kami melihat peningkatan representasi dari Eropa (29% pada tahun 2019 menjadi 32% pada tahun 2021), Asia (9% pada tahun 2019 menjadi 13% pada tahun 2021), Oseania (4% pada tahun 2019 menjadi 6% pada tahun 2021), dan Amerika Selatan (2% pada tahun 2019 menjadi 4% pada tahun 2021).

Sistem operasi

Distribusi sistem operasi juga konsisten dengan laporan State of DevOps sebelumnya. Kami juga berterima kasih kepada responden yang membantu menyoroti bahwa update bisa dilakukan di daftar sistem operasi kami. 

Tahun ini kami meninjau tempat responden men-deploy layanan atau aplikasi utama yang mereka kerjakan. Yang mengejutkan, sebagian besar responden menggunakan container (64%), dengan 48% menggunakan virtual machine (VM). Hal ini mungkin mencerminkan pergeseran dalam industri menuju teknologi target deployment yang lebih modern. Kami memeriksa perbedaan antara berbagai ukuran perusahaan dan tidak menemukan perbedaan yang signifikan di antara target deployment.

Tim yang menerapkan prinsip dan kemampuan sistem operasi dapat mengirimkan software dengan cepat dan andal, sekaligus memberikan manfaat langsung ke bisnis. Tahun ini, kami menyelidiki dampak praktik SRE, supply chain software yang aman, dokumentasi yang berkualitas, serta meninjau kembali eksplorasi kami dalam memanfaatkan cloud. Setiap area memungkinkan karyawan dan tim menjadi lebih efektif. Kami berfokus pada pentingnya menyusun solusi yang sesuai dengan karyawan yang memanfaatkan kemampuan ini, bukan menyesuaikan pengguna dengan solusi.

Kami berterima kasih kepada semua pihak yang telah berkontribusi pada survei tahun ini. Semoga riset kami dapat membantu Anda dan organisasi Anda membangun tim dan software yang lebih baik, sekaligus menjaga keseimbangan antara pekerjaan dan kehidupan pribadi.

Laporan tahun ini berhasil diwujudkan oleh keluarga besar kontributor yang penuh semangat. Mereka membantu kami merancang pertanyaan, menganalisis, menulis, mengedit, merancang laporan survei, dan lain-lain untuk mewujudkan upaya besar ini. Penulis ingin mengucapkan terima kasih kepada mereka semua atas masukan dan panduan yang telah diberikan demi selesainya laporan tahun ini. Ucapan terima kasih dicantumkan secara alfabetis.

Dustin Smith

Dustin Smith adalah seorang psikolog faktor manusia dan staf pengelola riset pengalaman pengguna di Google. Dia telah mengerjakan proyek DORA selama tiga tahun. Selama tujuh tahun terakhir, ia telah mempelajari bagaimana orang terpengaruh oleh sistem dan lingkungan di sekitar mereka dalam berbagai konteks: rekayasa software, game gratis, layanan kesehatan, dan militer. Penelitiannya di Google mengidentifikasi aspek yang dapat membuat developer merasa lebih bahagia dan lebih produktif selama proses pengembangan. Ia telah mengerjakan proyek DORA selama dua tahun. Dustin menerima gelar PhD di bidang Psikologi Faktor Manusia dari Wichita State University.

Daniella Villalba

Daniella Villalba adalah peneliti pengalaman pengguna khusus untuk project DORA. Ia berfokus untuk memahami berbagai faktor yang membuat developer senang dan produktif. Sebelum di Google, Daniella mempelajari manfaat pelatihan meditasi, faktor psikososial yang memengaruhi pengalaman mahasiswa, memori saksi mata, dan pengakuan palsu. Ia meraih gelar PhD di bidang Psikologi Eksperimental dari Florida International University. 

Michelle Irvine

Michelle Irvine adalah seorang penulis teknis di Google. Ia bekerja untuk menjembatani kesenjangan antara alat developer dan orang-orang yang menggunakannya. Sebelum di Google, ia bekerja di bidang penerbitan pendidikan dan sebagai penulis teknis untuk software simulasi fisika. Michelle memiliki gelar BSc dalam bidang Fisika, serta MA dalam bidang Desain Retorik dan Komunikasi dari University of Waterloo.

Dave Stanke

Dave Stanke adalah developer relations engineer di Google. Ia memberikan saran kepada pelanggan tentang praktik terbaik untuk mengadopsi DevOps dan SRE. Di sepanjang kariernya, ia telah menduduki segala macam posisi termasuk CTO startup, product manager, dukungan pelanggan, developer software, admin sistem, dan graphic designer. Ia meraih gelar MS di bidang Manajemen Teknologi dari Columbia University. 

Nathen Harvey

Nathen Harvey adalah developer relations engineer di Google yang membangun karier dengan membantu tim mewujudkan potensi mereka sembari menyelaraskan teknologi dengan hasil bisnis. Nathen pernah bekerja sama dengan sejumlah tim dan komunitas open source terbaik, membantu mereka menerapkan prinsip serta praktik DevOps dan SRE. Nathen turut mengedit dan menyumbang artikel dalam “97 Things Every Cloud Engineer Should Know,” yang diterbitkan O’Reilly pada tahun 2020.

Desain riset

Penelitian ini menggunakan desain lintas sektoral dan berbasis teori. Desain berbasis teori ini dikenal sebagai prediktif inferensial, dan merupakan salah satu jenis yang paling umum dilakukan dalam penelitian bisnis dan teknologi saat ini. Desain inferensial digunakan ketika desain eksperimental murni tidak memungkinkan dan eksperimen lapangan lebih disukai.

Populasi target dan pengambilan sampel

Populasi target survei ini adalah para praktisi dan pimpinan yang bekerja di bidang, atau terkait erat dengan, teknologi dan transformasi, terutama mereka yang familier dengan DevOps. Kami mempromosikan survei ini melalui milis, promosi online, panel online, media sosial, dan dengan meminta orang membagikannya kepada jaringan mereka (teknik pengambilan sampel rujukan berantai/snowball).

Membuat konstruk laten

Kami merumuskan hipotesis dan konstruk menggunakan konstruk yang sudah divalidasi sebelumnya, jika memungkinkan. Konstruk baru dikembangkan berdasarkan teori, definisi, dan masukan pakar. Selanjutnya, kami mengambil langkah tambahan untuk mengklarifikasi tujuan agar data yang terkumpul dari survei memiliki kemungkinan tinggi untuk menjadi data yang andal dan valid.¹⁴

Metode analisis statistik

Analisis cluster. Kami menggunakan analisis cluster untuk mengidentifikasi profil performa pengiriman software berdasarkan frekuensi deployment, lama pengerjaan, waktu pemulihan layanan, dan rasio kegagalan perubahan. Kami menggunakan analisis¹⁵ kelas laten karena kami tidak memiliki alasan teoretis atau industri untuk memiliki jumlah cluster yang telah ditentukan sebelumnya, dan kami menggunakan criterion16 informasi Bayesian untuk menentukan jumlah cluster yang optimal.

Model pengukuran. Sebelum melakukan analisis, kami mengidentifikasi konstruk menggunakan analisis faktor eksploratori dengan analisis komponen utama menggunakan rotasi varimax.¹⁷ Kami mengonfirmasi hasil uji statistik untuk validitas dan reliabilitas konvergen dan divergen menggunakan rata-rata varians ekstrak (AVE), korelasi, alfa Cronbach,¹⁸ dan reliabilitas komposit.

Pemodelan persamaan struktural. Kami menguji model persamaan struktural (SEM) menggunakan analisis Kuadrat Terkecil Parsial (PLS), yang merupakan SEM berbasis korelasi.¹⁹

^{________________________}

14. Churchill Jr, G. A. “A paradigm for developing better measures of marketing constructs,” Journal of Marketing Research 16:1, (1979), 64–73.

15. Hagenaars, J. A., & McCutcheon, A. L. (Eds.). (2002). Applied latent class analysis. Cambridge University Press.

16. Vrieze, S. I. (2012). Model selection and psychological theory: a discussion of the differences between the Akaike information criterion (AIC) and the Bayesian information criterion (BIC). Psychological methods, 17(2), 228.

17. Straub, D., Boudreau, M. C., & Gefen, D. (2004). Validation guidelines for IS positivist research. Communications of the Association for Information systems, 13(1), 24.

18. Nunnally, J.C. Psychometric Theory. New York: McGraw-Hill, 1978

19. Hair Jr, J. F., Hult, G. T. M., Ringle, C. M., & Sarstedt, M. (2021). “A primer on partial least squares structural equation modeling (PLS-SEM).” Sage publications

Temukan informasi lebih lanjut tentang kapabilitas DevOps di https://cloud.google.com/devops/capabilities

Temukan referensi tentang Site Reliability Engineering (SRE) di

https://sre.google

Lakukan Pemeriksaan Cepat DevOps:

https://www.devops-research.com/quickcheck.html

Eksplorasi program riset DevOps:

https://www.devops-research.com/research.html

Cari tahu tentang Program Modernisasi Aplikasi Google Cloud:

https://cloud.google.com/solutions/camp

Baca laporan resmi “The ROI of DevOps Transformation: How to quantify the impact of your modernization initiatives”:

https://cloud.google.com/resources/roi-of-devops-transformation-whitepaper

Lihat laporan State of DevOps sebelumnya:

State of DevOps 2014: https://services.google.com/fh/files/misc/state-of-devops-2014.pdf

State of DevOps 2015: https://services.google.com/fh/files/misc/state-of-devops-2015.pdf

State of DevOps 2016: https://services.google.com/fh/files/misc/state-of-devops-2016.pdf

State of DevOps 2017: https://services.google.com/fh/files/misc/state-of-devops-2017.pdf

Accelerate State of DevOps 2018: https://services.google.com/fh/files/misc/state-of-devops-2018.pdf

Accelerate State of DevOps 2019:

https://services.google.com/fh/files/misc/state-of-devops-2019.pdf