Bagaimana Mengelola Resiko Perubahan Aplikasi?

Ketika manusia dikatakan sebagai jantung dan jiwa dari bisnis, perusahaan modern juga hidup atau mati atas keberhasilan aplikasi perusahaannya.

Sebagian besar proses bisnis dalam sebuah perusahaan didukung oleh aplikasi bisnis yang kuat; apakah mengambil pesanan dan pemenuhan, atau meminta liburan. Masalah aplikasi biasanya akan menghasilkan beberapa bentuk kerugian finansial atau produktivitas.

Sebuah aplikasi tidaklah tahan lama. Diperlukan tindakan untuk membenahinya misalnya perlu menambal keamanan, meningkatkan kemampuan yang lebih besar, atau bahkan mengintegrasikan aplikasi yang sama sekali baru. Perusahaan terus melakukan perubahan pada lingkungan aplikasi. Menyeimbangkan kebutuhan untuk meng-upgrade aplikasi dengan kebutuhan bisnis modern agar ‘selalu-on’ bisa menjadi proses yang sulit bagi perusahaan yang melakukan segala sesuatu yang mungkin untuk menghindari downtime aplikasi.

Keyakinan

Menambal aplikasi yang ada sejauh ini merupakan tindakan perusahaan yang paling sering dilakukan. Sedangkan memperbarui aplikasi yang ada, atau menerapkan yang baru, adalah kejadian yang jarang terjadi. Terlepas dari skala, perusahaan perlu memastikan bahwa setiap perubahan pada lingkungan aplikasi akan berjalan sesuai rencana, dan mudah diimplementasikan. Testing merupakan hal yang terpenting di sini. Dengan menerapkan perubahan terlebih dahulu ke dalam lingkungan non-produksi, tim IT dapat memastikan bahwa mereka mengetahui cara membuat proses tersebut semudah mungkin, dan memastikan bahwa perubahan tersebut tidak akan memiliki efek yang tidak diharapkan pada lingkungan produksi.

Secara tradisional, lama downtime selama akhir pekan atau malam hari artinya infrastruksi produksi IT dapat digunakan untuk testing tanpa mengganggu pengguna aplikasi. Namun, pertumbuhan globalisasi dan pergeseran terhadap jam kerja yang fleksibel telah mengubah hal ini. Modern bisnis saat ini menganut sistem 24/7, operasional selalu on. Aplikasi harus selalu tersedia, masa tenggang alami dari downtime perusahaan menjadi hilang atau tidak berdampak lagi. Malahan, tim IT menghadapi jurang antara keperluan untuk menguji aplikasi dan garansi sukses perbaikan atau perubahan lainnya dan kebutuhan agar bisnis terus berjalan.

Skala Two Ends

Meskipun penyebaran aplikasi yang baru akan selalu menjalani pengujian secara menyeluruh, untuk kasus patch dan upgrade bisa jadi kurang jelas. Umumnya, perusahaan harus membuat pilihan ekstrim antara satu dari dua.

Pertama adalah melanjutkan pengujian dengan gaya tradisional yakni mengambil alih lingkungan produksi saat tambalan atau perubahan lainnya diuji. Tim IT dapat mengatasi kejadian yang ada di sistem; pengguna aplikasi menjadi tidak bisa mengakses ataupun menggunakan aplikasi selama waktu tersebut. Meskipun hal ini akan memberi kepercayaan diri bahwa aplikasi akan berperilaku seperti yang diharapkan, namun juga akan menghasilkan periode downtime yang lama. Akibatnya, CIO harus meyakinkan perusahaan bahwa keuntungan yang didapatkan dari setiap perubahan tersebut melebihi yang sebenarnya dan berpotensi rugi dikarenakan kehilangan kesempatan dan produktivitas berkurang.

Pilihan ekstrim kedua adalah menggelar perubahan dengan sedikit pengujian; memperbaiki masalah saat aplikasi sedang berjalan (live). Meskipun hal ini akan mengakibatkan downtime terpendek untuk perusahaan, hampir tidak perlu dikatakan bahwa ini bisa dengan mudah menjadi ekonomi palsu. Tanpa testing, kemungkinan menghadapi masalah baik selama atau setelah peluncuran akan meningkat secara besar-besaran. Biaya aplikasi kritis yang tidak berjalan sesuai rencana pasca perubahan dapat melemah.

Untuk menghindari hal ini, kebanyakan organisasi perlu berjalan di tengah antara hal ekstrim ini, tergantung pada seberapa ekstrim perubahan dan seberapa penting aplikasi bisnis tersebut. Pada ujung skala, penambalan yang kecil kemungkinan akan sedikit diuji or bahkan diluncurkan dengan keyakinan vendor telah menguji keseluruhan dan perusahaan dapat dengan cepat melihat serta menangani masalah apapun. Perusahaan juga akan menjaga pilihan untuk meluncurkan kembali aplikasi ke status penambalan awal (pre patch) atau peningkatan versi (upgrade), dengan asumsi bahwa jika yang terburuk tidak sampai pada yang terburuk, setidaknya bisa kembali ke konfigurasi yang diketahui dan stabil.

Di mana ada Kemauan, di situ ada Jalan

Tidak ada solusi yang ideal. Terlepas dari rute yang tepat yang mereka ambil, perusahaan akan selalu memperdagangkan ketersediaan dengan pikiran tenang dan menemukan hidup bersama yang seimbang. Namun, harusnya ini tidak menjadi masalah. Dalam waktu kurang dari satu dekade telah terjadi kemajuan dalam teknologi dan teknik yang memungkinkan perusahaan menguji aplikasi mereka secara menyeluruh tanpa mempengaruhi ketersediaan layanan mereka.

Sebagai permulaan, karena harga penyimpanan dan server menjadi semakin terkomoditas, semakin terjangkau untuk membuat pengujian infrastruktur terpisah di mana peluncuran aplikasi dapat disempurnakan tanpa mempengaruhi lingkungan produksi. Ini bukan berarti berinvestasi di infrastruktur terpisah, virtual atau lainnya, ini benar-benar untuk testing. Umpamanya, perusahaan rata-rata akan memiliki sejumlah besar infrastruktur cadangan yang belum terpakai yang pada dasarnya bebas untuk dieksploitasi. Dengan alat modern, perusahaan dapat memfungsikan kembali (repurpose) ini sebagai pengujian sementara infrastruktur; selanjutnya menghemat biaya pemasangan lingkungan pengujian khusus.

Meskipun ruang (space) tidak menjadi masalah, masih ada kasus di mana untuk menguji infrastruktur dapat menghabiskan waktu yang berharga bagi tim IT dan memerlukan keahlian khusus. Namun, semakin proses ini banyak bisa diotomatisasi sampai tingkat tertentu. Misalnya, teknik perlindungan data, seperti replikasi dan membuat cadangan (backup) berkecepatan tinggi, menjadi jauh lebih terjangkau dan mudah diakses oleh perusahaan; berarti membuat replikasi pengujian infrastruktur semudah melakukan pencadangan. Akhirnya, perusahaan bisa cepat menyiapkan pengujian infrastruktur dalam skala apa pun, yang identik dengan lingkungan produksi dan kapan mereka membutuhkannya. Kecepatan pencadangan juga berarti bahwa meluncurkan kembali lingkungan tersebut untuk pengujian berulang yang merupakan proses yang jauh lebih simpel.

Bagaimana Mengelola Resiko Perubahan Aplikasi?
source image from freepik.com

Jika perusahaan memanfaatkan kapabilitas ini, mereka akan yakin bahwa setiap pembaruan aplikasi, pembenahan atau penyebaran (deployment) telah diuji secara menyeluruh sebelumnya, dan belum terpengaruh pihak IT. Teknologi membuat proses ini bekerja, yang dibutuhkan perusahaan adalah kehendak untuk mewujudkannya. Dengan demikian, mereka akan menemukan bahwa jurang antara kepercayaan dan ketersediaan yang mereka butuhkan, juga yang dapat mereka berikan, menjadi semakin kecil.