Saya berpartisipasi dalam utas baru-baru ini di komunitas OTN di mana seseorang mengajukan pertanyaan tentang penurunan versi setelah peningkatan basis data. Salah satu tanggapan menanyakan berapa banyak orang yang benar-benar mempraktikkan penurunan versi basis data. Saya membuat polling ini untuk mencari tahu.
Saya terkejut menemukan satu kontribusi untuk utas itu yang mengatakan:
Sekarang poster itu tidak secara eksplisit mengatakannya, tetapi hampir seolah-olah individu itu mengatakan bahwa berlatih penurunan peringkat adalah buang-buang waktu karena mereka tidak akan pernah membutuhkannya. Saya akan memberi poster keuntungan dari keraguan dan bahwa karyawan Oracle ini tidak benar-benar mengatakan ini. Saya tidak mencoba untuk memilih individu ini. Saya akan membiarkan utas ini memberi saya kesempatan untuk mendiskusikan topik dari sudut pandang yang lebih umum. (Pembaruan: poster yang mendorong saya untuk menulis entri blog ini telah kembali ke utas dalam waktu yang saya perlukan untuk menulis ini dan mengatakan, ” tidak bermaksud menyiratkan bahwa kita tidak boleh 'menguji' penurunan versi.” )
Kembali pada bulan Juli, saya menulis posting blog tentang The Data Guardian. Dalam posting blog itu, saya berkata:
DBA perlu melindungi data. Itulah pekerjaan #1. Tugas #2 adalah DBA menyediakan akses data yang efisien dan tepat waktu. Apa gunanya memiliki data jika orang yang membutuhkan akses tidak dapat mengakses data? Jika orang-orang tersebut memiliki kinerja yang buruk saat berinteraksi dengan data, maka mereka mungkin juga tidak memiliki akses.
Sebagai DBA, kita perlu melakukan manajemen risiko. Kita perlu menentukan risiko apa yang mungkin menjadi kenyataan. Tugas DBA adalah mengukur risiko tersebut dan menentukan dua rencana tindakan. Langkah-langkah apa yang dapat diambil untuk menghindari risiko itu menjadi kenyataan dan langkah-langkah apa yang perlu saya ambil untuk menyelesaikan masalah ketika risiko itu menjadi kenyataan?
Bahkan DBA tingkat junior akan memahami pentingnya pencadangan. Cadangan adalah strategi manajemen risiko. Jika data hilang, kami dapat memulihkan data dari cadangan. Dan bahkan DBA tingkat junior memahami pentingnya dapat memulihkan dari cadangan.
Di utas OTN ini, saya menulis ini:
Bagi saya, ini semacam Hukum Murphy. Saya telah mengatakan hal serupa di masa lalu. Idenya (dan inti dari entri blog ini) adalah jika saya tidak mengambil langkah manajemen risiko yang tepat, maka saya hanya meminta para dewa untuk mengubah risiko itu menjadi kenyataan. Jika saya menolak untuk menyesuaikan kaca spion saya dan menggunakannya ketika saya memundurkan kendaraan saya, itu adalah hari saya kembali ke sesuatu. Jika saya menolak untuk mengikat tali sepatu saya, nah itu hari saya menginjak satu dan tersandung. Mereka hari saya menolak untuk memakai googles pelindung saat menggunakan powertool adalah hari saya mendapatkan sesuatu di mata saya. Hari saya pergi ke pantai dan menolak untuk memakai tabir surya adalah hari saya akan pulang dengan sengatan matahari. Anda mendapatkan idenya.
Beberapa pembaca mungkin berpikir bahwa saya gila dan bahwa alam semesta tidak memiliki rencana induk ini untuk mengacaukan saya hanya karena saya berpuas diri. Dan saya akan setuju. Jadi saya akan mengatakannya dengan cara lain, jika saya tidak berencana untuk mengurangi risiko, maka saya tidak melakukan apa pun untuk menghentikannya menjadi kenyataan. Kemungkinan itu menjadi kenyataan tidak berkurang karena kelambanan saya.
Ada dua komponen utama untuk manajemen risiko. 1) menentukan probabilitas terjadinya item risiko tersebut dan 2) menentukan dampak saat risiko tersebut benar-benar terjadi. Item yang memiliki probabilitas tertinggi yang terjadi dimitigasi terlebih dahulu. Ini mudah dan sesuatu yang sering dilakukan oleh banyak orang yang bekerja pada manajemen risiko. Mereka memasukkan item risiko ke dalam spreadsheet dan mengisi beberapa nilai untuk kemungkinan terjadinya risiko itu. Setelah selesai, mereka mengurutkan pada kolom probabilitas dan memulai mitigasi risiko dari atas ke bawah. Banyak strategi manajemen risiko menarik garis di suatu tempat di tengah daftar dan memutuskan item risiko apa pun di bawah garis itu memiliki probabilitas terlalu rendah sehingga kita tidak akan khawatir tentang item risiko itu. Kami tidak dapat mengurangi semua kemungkinan risiko di alam semesta. Tidak ada cukup waktu untuk menangani semuanya. Jadi kita harus menarik garis di suatu tempat.
Salah satu kegagalan yang saya lihat sepanjang waktu adalah bahwa manajemen risiko tidak menghabiskan banyak waktu untuk berfokus pada dampak dari risiko itu menjadi kenyataan. Spreadsheet perlu menyertakan kolom serupa yang memberikan peringkat dampak terhadap bisnis untuk item risiko tersebut. Manajer risiko perlu mengurutkan spreadsheet pada kolom ini juga. Setiap item yang berdampak besar perlu memiliki aktivitas mitigasi risiko meskipun item tersebut memiliki kemungkinan kecil untuk terjadi! Sayangnya, terlalu banyak dalam bisnis manajemen risiko yang gagal memasukkan langkah penilaian dampak risiko ini. Sekali lagi, ketika spreadsheet diurutkan berdasarkan dampak terhadap bisnis, sebuah garis ditarik di suatu tempat.
Seseorang mungkin menemukan bahwa item berisiko dengan probabilitas TINGGI memiliki dampak RENDAH atau bahkan SANGAT RENDAH untuk bisnis. Saya suka spreadsheet manajemen risiko yang menyertakan kolom ketiga yaitu “probabilitas x dampak”. Kolom ini membantu memahami hubungan antara dua komponen risiko.
Mari kembali ke pertanyaan pemutakhiran basis data yang mendorong posting blog ini. Saya pikir semua orang yang membaca artikel blog ini harus setuju bahwa memutakhirkan database Oracle adalah proposisi yang berisiko. Ada begitu banyak hal berbeda yang bisa salah dengan upgrade database Oracle. Probabilitas kegagalan upgrade adalah TINGGI. Item mitigasi risiko sering kali mencakup, tetapi tidak terbatas pada, mempraktikkan peningkatan pada klon produksi dan mencadangkan database sebelum proses peningkatan dimulai. Mengapa kita melakukan ini? Nah dampaknya untuk bisnis ini SANGAT TINGGI. Jika kami gagal saat memutakhirkan basis data produksi kami, maka pengguna bisnis kami tidak memiliki akses ke data. Kami bukan Penjaga Data yang sangat baik jika kami tidak bisa melewati kegagalan ini. Jika kita mempraktekkan upgrade secara memadai di lingkungan non-produksi, kita dapat mengurangi kemungkinan item risiko menjadi MEDIUM. Tetapi kemungkinan besar, kami tidak dapat mengurangi probabilitas risiko spesifik itu menjadi RENDAH. Itu sebabnya kami mengambil cadangan sebelum peningkatan dimulai. Harusnya masih ada masalah meskipun kita telah melakukan level terbaik kita mengurangi probabilitas dari item risiko tersebut, dampak untuk bisnis ini masih SANGAT TINGGI. Jadi, strategi remediasi risiko DBA adalah mencatat di mana dan apa yang menyebabkan gagalnya upgrade, dan memulihkan dari cadangan. Basis data aktif dan berjalan dan kami telah menghilangkan dampak untuk bisnis. DBA kemudian kembali ke papan gambar untuk menentukan bagaimana menyelesaikan apa yang salah. DBA mencoba mengurangi probabilitas masalah itu terjadi lagi saat mereka kembali di lain waktu untuk melakukan proses peningkatan versi lagi.
Jadi mari kita kembali ke komentar di utas OTN di mana tampaknya mengatakan bahwa mempraktikkan penurunan versi basis data tidak sepadan dengan waktu. saya tidak setuju. Dan ketidaksetujuan saya berkaitan dengan dampak untuk bisnis. Saya setuju dengan komentar yang dikatakan poster dalam balasan mereka.
Saya setuju dengan itu 100%. Mengapa kita melakukan "pengujian menyeluruh" ini? Itu semua karena mitigasi risiko. Kami mencoba mengurangi probabilitas bahwa pemutakhiran akan menyebabkan kinerja yang buruk atau menyebabkan fungsionalitas aplikasi rusak. Tetapi bahkan seperti yang dikatakan poster itu, “Akan selalu ada masalah yang muncul dalam produksi setelah pemutakhiran karena tidak mungkin menguji 100% aplikasi Anda.” Sekali lagi, saya setuju 100% dengan apa yang dikatakan poster ini di sini. Tapi bagaimana dengan dampak untuk bisnis? Saya akan membahasnya sebentar lagi, tetapi pertama-tama saya harus sedikit menyimpang di paragraf berikutnya…
Saya baru-baru ini meningkatkan sistem produksi penting dari 11.2.0.4 ke versi 12.1.0.2. Di tempat saya bekerja, kami memiliki lebih banyak pengujian aplikasi daripada yang pernah saya lihat di pekerjaan saya yang lain. Kami memiliki tim QA lengkap yang melakukan pengujian untuk kami. Kami bahkan memiliki tim yang bertanggung jawab atas upaya pengujian otomatis kami. Kami memiliki robot otomatis yang menjalankan kode aplikasi kami setiap malam. Di atas semua itu, kami memiliki rutinitas otomatis lainnya yang setiap kali orang mendorong perubahan kode ke Test atau Prod, rutinitas ini melakukan pemeriksaan cepat terhadap jalur kode penting. Saya memutakhirkan lingkungan pengembangan (lebih dari 15 di antaranya) ke 12.1.0.2 dan kemudian menunggu satu bulan. Saya kemudian memutakhirkan Uji dan menunggu 3 minggu sebelum saya meningkatkan produksi. Ada masalah yang ditemukan dan diselesaikan sebelum kami mengupgrade produksi. Tetapi bahkan setelah semua itu, saya memiliki masalah besar setelah produksi ditingkatkan. Anda dapat mengunjungi posting blog saya pada pertengahan Oktober hingga pertengahan Desember untuk melihat beberapa masalah tersebut. Saya hampir saja menurunkan versi database ini, tetapi saya malah berhasil mengatasi masalah tersebut. Sekarang kembali ke poin yang saya buat…
Setelah upgrade selesai, database dibuka untuk bisnis. Pengguna aplikasi sekarang diizinkan untuk menggunakan aplikasi. Apa yang terjadi di dalam database saat ini? Transaksi! Dan transaksi berarti perubahan data. Pada saat DBA membuka database untuk bisnis setelah pemutakhiran selesai, perubahan data mulai terjadi. Setelah semua ini, itulah inti dari database, bukan? Catat perubahan data dan buat data tersedia bagi pengguna akhir aplikasi.
Jadi apa yang terjadi jika Anda berada di kapal saya Musim Gugur lalu dengan peningkatan basis data saya? Saya menemukan hal-hal yang tidak kami lihat di non-produksi, bahkan setelah semua pengujian kami. Dampak untuk bisnis itu TINGGI. Saya harus dapat mengurangi dampak ini pada bisnis. Aku punya tiga pilihan. 1) Perbaiki masalah, satu per satu. 2) Pulihkan dari cadangan yang saya ambil sebelum peningkatan sehingga saya bisa mendapatkan database kembali ke versi lama. 3) Turunkan database dan kembali ke papan gambar. Saya memilih opsi pertama. seperti yang selalu saya lakukan selama karir saya. Tapi bagaimana jika itu tidak cukup? Ini bisa memakan waktu untuk menyelesaikan masalah. Beberapa bisnis tidak mampu membayar waktu seperti itu dengan dampak negatif itu untuk bisnis. Berapa banyak situs web yang ditinggalkan karena kinerjanya buruk atau ada yang tidak berfungsi dengan benar? Dan untuk sebagian besar basis data produksi di luar sana, opsi 2 memiliki dampak yang sangat buruk untuk bisnis! Anda akan kehilangan transaksi setelah peningkatan selesai! DBA tidak akan dapat melanjutkan melewati pemutakhiran sambil mempertahankan basis data pada versi lama, sehingga data akan hilang dan untuk banyak basis data produksi, ini tidak dapat diterima. Bisnis mungkin dapat menanggung satu jam kehilangan data, tetapi berapa banyak orang yang akan memicu tindakan ini dalam satu jam setelah peningkatan? Kemungkinan besar, tindakan ini akan dilakukan beberapa hari setelah peningkatan versi dan dampak untuk bisnis untuk jenis kehilangan data jauh di atas SANGAT TINGGI. Sehingga meninggalkan opsi 3 sebagai opsi dengan dampak terendah kepada bisnis untuk membantu menyelesaikan dampak apa pun yang dialami bisnis setelah peningkatan versi.
Anda mungkin dapat mengetahui dari paragraf terakhir bahwa saya merasa penting bagi Oracle DBA untuk mengetahui cara menurunkan versi database mereka setelah pemutakhiran selesai. Saya akui bahwa probabilitas DBA yang perlu melakukan downgrade SANGAT RENDAH. Tapi dampak tidak menurunkan dapat menjadi bencana besar bagi bisnis. (Ada dua kata itu lagi). Karena probabilitas rendah, saya tidak sering berlatih downgrade, tetapi karena dampak karena tidak dapat menurunkan versi sangat tinggi, saya melatihnya sesekali.
Jadi sebagai penutup, saya akan kembali ke Hukum Murphy itu lagi. Alam semesta tidak berkonspirasi melawan saya, tetapi sebagai Penjaga Data, saya perlu mempraktikkan prinsip-prinsip manajemen risiko yang baik. Itu berarti menilai probabilitas dan dampak item risiko yang dikenakan oleh perubahan saya. Sementara alam semesta dan para dewa mungkin tidak membuat Hukum Murphy atau sepupunya bekerja, saya tidak akan membantu diri saya sendiri dengan mengurangi item risiko. Saya tidak mengurangi kemungkinannya sedikit pun.
