"Banyak perusahaan yang ada karena aplikasi, yang berarti kinerja aplikasi merupakan pengukuran paling penting di luar pendapatan," kata Chris Farrell, wakil presiden perangkat lunak layanan nilai otomatisasi di IBM. "Ketika aplikasi Anda adalah bisnis Anda, kecepatan adalah senjata sekaligus proksi untuk kualitas aplikasi Anda."

Di dunia yang penuh dengan penerapan tingkat tinggi ini, Farrel mengatakan bahwa sangat penting bagi organisasi untuk "membalikkan naskah" dalam cara mereka berpikir untuk mencapai integrasi berkelanjutan dan pengiriman berkelanjutan (CI/CD). "Daripada berbicara tentang jumlah hari di antara penerapan, Anda seharusnya berbicara tentang jumlah pembaruan per periode waktu," katanya. "Semakin pendek periode waktunya, semakin banyak Anda bergerak ke atas."

Seri IBM "Pikirkan Kembali & Otomatiskan" mengundang para pemimpin untuk menata ulang proses bisnis dan TI yang umum dengan mendekatinya dari perspektif greenfield dan merangkul otomatisasi. Proses DevOps yang khas adalah serangkaian siklus delapan langkah, yaitu perencanaan, pengkodean, pembangunan, dan pengujian, diikuti dengan rilis, penerapan, pengoperasian, dan pemantauan.  Ketika salah satu dari delapan langkah melambat, seluruh pipa akan melambat.

“Di luar dunia 'lahir digital', peningkatan kecepatan mungkin bahkan lebih penting bagi perusahaan besar,” tulis Hans A.T. Dekkers dari IBM dalam  "The speed of smarter architecture", sebuah makalah yang diterbitkan oleh IBM Institute for Business Value. “Ketika kita melihat umur rata-rata perusahaan pada S&P 500 turun dari 60 tahun (pada tahun 1960-an) menjadi di bawah 20 tahun (hari ini), dengan tren percepatan menuju omset yang lebih tinggi, kita melihat efek dari memiliki atau kurang kecepatan.”

Temukan cara-cara baru untuk meningkatkan proses DevOps TI Anda dalam Lokakarya Inovasi Otomatisasi gratis.

Untuk mencapai CI/CD, pengembang harus membangun sekali, menerapkan di mana saja, dan mengelola pipeline secara konstan. Berikut ini cara Farrel mendesain ulang siklus umum menggunakan otomatisasi, dengan mencatat bahwa setiap perbaikan membutuhkan "komitmen penuh terhadap DevOps dan keinginan untuk mencapai pengiriman yang berkelanjutan."

Beralih dari pemantauan ke observabilitas

"Hal ini mungkin mengejutkan banyak orang, tetapi jika saya harus mendesain ulang proses DevOps dari awal, fokus pertama saya adalah langkah terakhir: pemantauan," ujar Farrel. "Anda harus menyingkirkan alat bantu dari ruang pemantauan tradisional dan beralih ke observabilitas secepat mungkin. Ingat, semakin banyak beban kerja yang Anda terapkan pada observabilitas, semakin cepat dan akurat setiap anggota Ops dapat menavigasi dari masalah ke akar masalah, tanpa melibatkan pengembang dan pakar bidang lainnya."

Di bidang TI, observabilitas mengacu pada alat dan praktik perangkat lunak untuk mengumpulkan, menghubungkan, dan menganalisis aliran data kinerja yang stabil dari aplikasi terdistribusi, bersama dengan perangkat keras dan jaringan tempat aplikasi tersebut berjalan, sehingga Anda dapat memecahkan masalah dan melakukan debug aplikasi serta jaringan dengan lebih efektif. Observabilitas adalah evolusi alami dari pemantauan kinerja aplikasi (APM) untuk mengatasi penerapan aplikasi cloud native yang semakin cepat, terdistribusi, dan dinamis dengan lebih baik.

Di luar pemantauan, setiap langkah dari proses DevOps sudah memiliki banyak alat yang mempercepat, mengintegrasikan, dan mengotomatiskan proses. "Alat pemantauan tradisional kesulitan untuk beradaptasi dengan percepatan pipeline dan tumpukan teknologi modern, khususnya karena pengaturan manual, konfigurasi ulang dan/atau penyebaran ulang memperlambat segalanya," ujar Farrell. Platform observabilitas memberikan pemahaman, visibilitas dengan konteks, dan menyesuaikan diri dengan perubahan apa pun secara real time, yang berarti platform ini selalu diperbarui.

Observabilitas juga menyatukan aplikasi dan infrastruktur, yang diperlukan karena batas antara kode aplikasi, infrastruktur berbasis kode, dan tumpukan perangkat keras menjadi kabur. "Jika Anda berpikir tentang kebutuhan akan kecepatan di seluruh pipeline, platform harus bisa sefleksibel dan secepat kode aplikasi itu sendiri," kata Farrell.

Otomatiskan observabilitas untuk kecepatan dan hasil yang lebih baik

"Kebutuhan untuk beralih ke observabilitas adalah mutlak, tetapi harus otomatis," kata Farrell. Platform observabilitas otomatis dengan analytics engine memungkinkan platform itu sendiri untuk memberikan pemahaman, rekomendasi, dan remediasi untuk masalah. Anda tidak lagi harus menghabiskan waktu mendiagnosis masalah; itu dilakukan secara otomatis.

Otomatisasi di seluruh proses DevOps TI memberikan sejumlah manfaat lain di luar kecepatan. Masukan yang berkelanjutan berarti pengembang dapat dengan cepat dan tegas mengambil tindakan untuk perbaikan yang berkelanjutan. Deteksi kesalahan yang lebih baik memungkinkan pengembang untuk melakukan remediasi sebelum kesalahan menyebabkan apa yang digambarkan Farrell sebagai dampak "bencana". Dan terakhir, integrasi sistem meningkatkan kolaborasi tim, memungkinkan semua profesional TI dan DevOps dalam sebuah tim untuk mengubah kode, merespons masukan, dan memperbaiki masalah tanpa memperlambat rekan kerja mereka.

Menurut laporan DORA 2018 Accelerate: State of DevOps (Tautan berada di luar ibm.com), "organisasi berkinerja elit" memiliki penerapan kode 46x lebih sering, waktu tunggu 2.555x lebih cepat dari komit ke penerapan, tingkat kegagalan perubahan 7x lebih rendah, dan 2.604x lebih cepat pulih dari insiden. Anda bisa melihat manfaat eksponensial dari penerapan yang lebih sering yang mengarah pada percepatan rilis perangkat lunak baru, dan ribuan kali lebih cepat dalam penyelesaian insiden. "Salah satu korelasi favorit saya adalah penurunan tingkat kegagalan perubahan, bahkan ketika Anda menerapkannya dengan lebih cepat," ujar Farrel.

Ketika organisasi mengotomatiskan kedelapan langkah proses, mereka dapat mengharapkan kualitas yang lebih tinggi dan kepuasan pelanggan yang lebih baik. Namun Farrell mengatakan manfaat favoritnya adalah kecepatan. “Salah satu contoh yang saya lihat adalah di bank. Mereka membutuhkan waktu sekitar 10 hingga 12 bulan untuk mendapatkan ide produk sebelum diluncurkan. Setelah mereka mendapatkan proses DevOps baru, jangka waktu tersebut berubah menjadi dua minggu," katanya. "Anda melihat hasil yang mutlak dan langsung dari kesuksesan di pasar."