DevOps adalah perubahan yang diinginkan semua orang, dan sering menjadi suatu proses yang baru. Pergeseran yang sulit (namun menguntungkan) ke arus proses DevOps merubah segalanya dari rilis hingga ke respon kejadian. Banyak yang alami kegagalan implementasi DevOps selain yang berhasil dan mendapatkan keuntungan. Anda dapat hindari kegagalan devops tersebut.

Pada tahun 2020, Gartner memprediksi setidaknya 80% perusahaan besar akan menggunakan DevOps atau memiliki proyek percontohan, naik 38% dari saat ini. Namun, ada banyak kekecewaan (dengan DevOps) dalam tiga atau empat tahun ke depan, karena pilot project yang tidak memiliki skala.

Dalam survei Gartner terhadap 400 organisasi, 50% responden menyalahkan orang dan masalah budaya karena menahan proses DevOps. 37% mengatakan bahwa mereka tidak dapat menemukan proses yang dapat bekerja dengan sesuai untuk DevOps. Hanya 8% yang melaporkan hambatan teknologi.

Hindari Kegagalan Implementasi DevOps

Untuk menghindari nasib ‘korban DevOps’ yang sangat umum, organisasi harus memahami proses dan proses DevOps serta merancang proses untuk tim tersebut. Para pimpinan IT harus bertanya: Apa proses saya, apa tujuan proses dan bagaimana mengukur hasilnya?

 Tentukan proses dan platform DevOps

Setidaknya setengah dari bisnis belum tepat sasaran dalam implementasi DevOps. Kesalahan terletak pada proses operasional yang tidak sesuai untuk DevOps. Ini seperti terlalu banyak kontrol di wilayah yang salah dan kurangnya kepercayaan dan tanggung jawab bersama antara pengembangan dan operasi.

Para ahli merekomendasikan untuk tetap ‘meminjam’ konsep Agile dari produk yang layak minimum dan menciptakan proses minimum yang layak. Proses devOps harus membongkar perangkat yang sangat rumit, memberikan perlindungan yang cukup sehingga kecepatan tidak menyebabkan bencana dan melawan perubahan yang tidak terkelola.

Oleh karena itu, di awal transformasi digital sebaiknya melakukan transformasi infrastruktur IT agar tidak terlalu menemukan hambatan. Set minimum proses DevOps yang semestinya menjadikan platform ini berliku seperti produk yang didukungnya.

Mulailah dengan cara holistik dengan semua tim yang terlibat dan jejak arsitektural yang bagus. Rangkul produk layak minimum, dan bangunlah di atasnya. Misalnya, jika Anda membangun server secara manual, kembangkan proses untuk membuat dan menerapkan citra emas di platform virtualisasi pilihan Anda.

Langkah selanjutnya: Terapkan rencana dasar yang aman dan sesuai di semua sistem Windows dan di semua sistem Linux, lalu generalisasikan tumpukan aplikasi. Sebuah bisnis dapat memiliki 50.000 server dengan banyak konfigurasi berbeda. Perubahan platform yang berulang harus terjadi sebelum proses DevOps dapat diterjemahkan.

Pada akhirnya, Anda ingin mendapatkan otomasi dari ujung ke ujung. Lakukan sedikit demi sedikit, buat lebih baik dan naikkan tumpukannya. Saat proses DevOps saling membangun, tantangan semakin berkurang.

Berpegang ke sumber, dan memberdayakannya

Alih-alih memaksa orang di sepanjang alur kerja, biarkan mereka membuat penilaian berdasarkan informasi yang dihasilkan oleh proses otomatis. Proses devOps menjaga keputusan terkait erat dengan informasi.

Jangan membuat proses baru – integrasi ke dalam standar praktik kerja sangat penting. Tetap dalam antrian kerja normal untuk mendorong adopsi DevOps. .

Manajemen perubahan berarti rilis lebih awal dan sering

Proses devOps untuk melepaskan mentalitas ‘WaterFall’. Dalam proses waterfall, perubahan besar dengan hubungan kompleks meningkatkan risiko karena ketergantungan. Pembaruan digulirkan dan menugaskan seseorang untuk mengelolanya dalam satu paket besar, dapat lebih berisiko.

Sebagai gantinya, DevOps menuntut agar tim dapat sering menerbitkan rilis. Pemilik produk bisnis harus menentukan kriteria penerimaan risiko dan layanan. Proses DevOps mendukung sprint kecil di bidang infrastruktur dan operasi di atas proyek-proyek besar, sehingga masalah mudah ditemukan dan diperbaiki.

Anda mungkin dapat merancang sebuah proses baru hanya untuk beberapa produk. Lakukanlah dengan benar, dan pahami, serta biarkan prosesnya berkembang dalam skala dan tugas.

Dengan kata lain, tirulah mentalitas Agile Scrum dalam operasi.

Tidak semua perubahan sama, jadi analisis dampak perubahan diperlukan dalam arus proses DevOps. Buat sebuah proses dimana tim produk dapat mengubah produk perangkat lunak tanpa persetujuan operasi, asalkan tidak mempengaruhi konfigurasi infrastruktur.

Tim pengembang harus menginformasikan bagian operasi untuk perubahan kode ini dan bahaya yang terkait sebagai bagian dari proses, dan kemudian perubahan terjadi melalui rantai alat dengan skrip yang diatur.

Tim infrastruktur dan operasi, sementara itu, dapat membangun platform bersama tanpa penyesuaian kode dependensi. Cara ini berguna untuk dapat memahami, mengekspos dan mengurangi risiko perubahan, melepaskan otomasi dan teknik penyebaran strategis.

Proses devOps untuk kepatuhan dapat memunculkan pengerjaan ulang dan downtime yang tidak direncanakan untuk tim operasi. Gunakan cetak biru dari kepatuhan untuk memulai otomasi dengan kode pengiriman.

konsultan devops indonesia

Setelah itu, anda dapat mulai membangun suatu proses DevOps untuk deteksi dan koreksi dengan tujuan remediasi otomatis.

Apa yang penting untuk di monitor ?

DevOps menuntut metrik baru. Dalam setiap keputusan, DevOps juga harus mempertimbangkan metrik bisnis, seperti retensi pelanggan dan keuntungan per pelanggan.

Secara historis, anda dapat berfokus pada metrik waktu rata-rata antara kegagalan, jumlah insiden per bulan. Itu tidak akan dilakukan di dunia DevOps, di mana hal-hal seperti waktu yang berarti untuk mendeteksi dan mengembalikan layanan.

Beberapa pengukuran dapat membantu staf dalam membuktikan nilai proses DevOps atas pekerjaan manual. Konfigurasi firewall manual memakan waktu sekitar 15 menit dalam skenario terbaik, yang mencapai 3.125 hari untuk satu putaran tunggal. Dengan dasar ini, tim akan tahu apakah jaringan pipa dan infrastruktur sebagai kode akan meningkatkan kecepatan operasi.

Kehilangan produktivitas di ujung belakang untuk setiap isu penting dapat menunjukkan bagaimana proses terkontrol mengurangi pekerjaan yang tidak direncanakan untuk semua orang. Tim dapat menyelidiki bagaimana mengukur dampak buruk pada pendapatan bisnis dan keuntungan dari masalah operasi.

Tim produk harus berptokan pada arsitektur yang telah mereka definisikan, yang berarti mereka perlu mengetahui apa yang terjadi. Tim DevOps dapat mengumumkan data pemantauan melalui kombinasi instrumentasi mandiri di aplikasi serta analisis bersama melalui alat umum.

Risiko terukur dan tanggung jawab ganti rugi

Proses devOps mentolerir keniscayaan risiko dan melindungi nilai terhadap tingkat risiko yang dapat diterima.

Kegagalan implementasi DevOps dapat menyebabkan sebagian besar insiden dalam penerapan produksi, terlepas dari fokus infrastruktur dan operasi pada arsitektur. Banyak perusahaan menggunakan alat dan mengikuti alur kerjanya tanpa analisis kritis. Mereka juga mengelilingi operasional dengan tata kelola proses yang tersedak untuk menghindari kegagalan implementasi devops.

Proses manajemen insiden di DevOps membentuk kembali proses pelayanan meja kerja. Panggilan insiden mengarah ke triase daripada upaya perbaikan putaran pertama. Pemilik produk bisnis dan master scrum memutuskan bagaimana insiden mendorong antrian kerja: atur sekarang atau tunggu rilis berikutnya? Jika memungkinkan, segera hentikan, kumpulkan tim dan cari tahu cara mendeteksi masalah itu lebih cepat di lain waktu – dan mengatasinya.

Para praktisi DevOps memperingatkan terhadap sebuah bahaya moral “risiko yang ditanggung oleh orang lain”. Umumnya, orang akan cenderung menyalahkan bagian operasional bila terjadi masalah keterlambatan. Ini adalah skenario yang biasa terjadi. Pengujian membutuhkan waktu lebih lama dari yang diharapkan dan tanggung jawab untuk peluncuran tepat waktu jatuh ke bagian operasional.

 Kesimpulan:

Organisasi harus mencantumkan semua aktivitas sepanjang alur proses DevOps dari rencana produk, pembuatan kode dan verifikasi ke produksi dan rilis melalui konfigurasi dan pemantauan, kembali ke perencanaan. Latihan ini akan mengklarifikasi keterampilan mana yang termasuk dalam tim dan di mana otomasi akan memungkinkan perubahan yang tepat dan terukur.

Tim dan alat terpadu bisa mendapatkan informasi yang benar ke format yang tepat pada waktu yang tepat. Downtime akibat proses benar-benar bisa merusak bisnis, jadi pahami tujuan dan hasil yang ingin diraih.