Bencana dapat berupa apa saja, sepanjang hal tersebut menghentikan layanan operasional bisnis. Downtime merupakan masalah besar bagi seluruh bisnis dan para pelanggan. Oleh karena itu akan lebih baik jika kita mempelajari contoh kasus disaster recover plan dari beberapa perusahaan.
Semakin besar perusahaan, semakin besar kompleksitas infrastruktur teknologi informasi mereka. Disaster recovery plan atau rencana pemulihan bencana memerlukan analisa terhadap aset kritis perusahaan. Strategi dibutuhkan sebagai salah satu langkah untuk mencapai tujuan disaster recovery plan yaitu keberlangsungan operasional bisnis.
Merupakan penyedia cloud terbesar di dunia yang pada 28 Februari 2017 yang lalu mengalami downtime selama 5 jam. Downtime yang terjadi pada layanan cloud AWS menyebaban Netflix, Tinder, Airbnb, Reddit dan IMDb menjadi offline.
Kejadian downtime tersebut disebabkan karena kesalahan coding konfigurasi pada salah satu sensor yang menyebabkan masalah katastropik. Namun, untuk perusahaan dengan sistem yang sangat kompleks, AWS mampu melakukan pemulihan dalam waktu 5 jam merupakan hal yang cukup baik. Tentunya hal ini tidak baik secara biaya dan kerugian para pelanggan.
AWS menggunakan lingkungan DevOps dan orkestrasi infrastruktur teknologi informasi. Sehingga segala masalah yang timbul dapat cepat mereka kembalikan normal. Ini disebut dengan istilah rollback. Hanya saja, semakin kompleks maka semakin lama waktu yang dibutuhkan untuk dapat kembali pulih.
Penyebaran dengan kode yang buruk merupakan faktor terbesar penyebab downtime di perusahaan manapun. Oleh karena itu, seluruh perusahaan wajib memiliki infrastruktur data center cadangan agar tetap dapat beroperasi. Kebutuhan akan Disaster Recovery Center ini akan semakin terlihat pada contoh kasus disaster recovery plan kedua dibawah ini.
Sayangnya Tokopedia, Bukalapak, dan JD.ID sepertinya tidak memiliki disaster recovery plan. Karena selama data center Biznet downtime, ketiga situs e-commerce tersebut tetap tidak dapat diakses.
Bisa jadi ini merupakan contoh kasus disaster recovery plan yang tidak didukung dengan strategi pemulihan bencana. Anda dapat melihat perbedaan rencana pemulihan bencana dengan rencana keberlangsungan usaha agar terbebas dari kesesatan yang dapat menempatkan perusahaan ada pada kondisi sulit.
Beberapa perusahaan maskapai penerbangan di AS juga mengalami downtime. Data center yang mereka pakai baik milik sendiri maupun pada fasilitas colocation data center dari pihak ketiga mengalami kegagalan pembangkit daya listrik cadangan. Kejadian downtime tersebut berlangsung beberapa hari, mereka hanya berfokus pada strategi pemulihan dengan penggantian perangkan UPS Fly Wheel (Geared UPS).
Tentunya kejadian downtime tersebut dapat kita ambil sebagai contoh kasus disaster recovery plan yang kurang memadai. Untuk dapat memastikan pemulihan bencana perusahaan berjalan sesuai rencana, jalan satu-satunya adalah dengan selalu melakukan pengujian. Hanya dengan kesiapan yang baik maka kejadian downtime dapat diatasi secepat mungkin. Semakin cepat downtime, maka semakin sedikit potensi kerugian dan kehilangan kepercayaan.
Kesimpulan:
Untuk dapat mengambil manfaat dari contoh kasus disaster recovery plan pada perusahaan besar tersebut diatas, para pimpinan perusahaan (CEO, CIO, CTO dan terutama CFO) harus merubah cara pandang mereka. Bahwa tidak ada satu perusahaan pun yang kebal terhadap downtime, dan downtime terjadi secara tak terduga.
Terutama pada beberapa perusahaan startup fintech. Serangan cyber yang ditujukan kepada beberapa aplikasi fintech yang semakin canggih dan meningkat intensitasnya telah memperbesar resiko downtime. Strategi pemulihan bencana harus di dukung dengan situs pemulihan bencana yang berbeda lokasi dan memiliki infrastruktur dan teknologi yang memadai.
Semakin besar perusahaan, semakin besar kompleksitas infrastruktur teknologi informasi mereka. Disaster recovery plan atau rencana pemulihan bencana memerlukan analisa terhadap aset kritis perusahaan. Strategi dibutuhkan sebagai salah satu langkah untuk mencapai tujuan disaster recovery plan yaitu keberlangsungan operasional bisnis.
Beberapa Contoh Kasus Disaster Recovery Plan
Sebuah kejadian downtime walau hanya 1 jam dapat mengakibatkan kerugian milyaran bahkan puluhan milyar rupiah. Memang sudah saatnya para pimpinan perusahaan untuk mengubah mindset yang tadinya biaya colocation untuk disaster recovery adalah mahal menjadi murah, jika dibandingkan dengan downtime yang tidak dapat di prediksi. Tidak ada yang kebal terhadap downtime, walau untuk perusahaan teknologi yang besar sekalipun. Mari kita simak beberapa contoh kasus disaster recovery plan berikut ini.Amazon Web Services (AWS)
Merupakan penyedia cloud terbesar di dunia yang pada 28 Februari 2017 yang lalu mengalami downtime selama 5 jam. Downtime yang terjadi pada layanan cloud AWS menyebaban Netflix, Tinder, Airbnb, Reddit dan IMDb menjadi offline.
Kejadian downtime tersebut disebabkan karena kesalahan coding konfigurasi pada salah satu sensor yang menyebabkan masalah katastropik. Namun, untuk perusahaan dengan sistem yang sangat kompleks, AWS mampu melakukan pemulihan dalam waktu 5 jam merupakan hal yang cukup baik. Tentunya hal ini tidak baik secara biaya dan kerugian para pelanggan.
AWS menggunakan lingkungan DevOps dan orkestrasi infrastruktur teknologi informasi. Sehingga segala masalah yang timbul dapat cepat mereka kembalikan normal. Ini disebut dengan istilah rollback. Hanya saja, semakin kompleks maka semakin lama waktu yang dibutuhkan untuk dapat kembali pulih.
Penyebaran dengan kode yang buruk merupakan faktor terbesar penyebab downtime di perusahaan manapun. Oleh karena itu, seluruh perusahaan wajib memiliki infrastruktur data center cadangan agar tetap dapat beroperasi. Kebutuhan akan Disaster Recovery Center ini akan semakin terlihat pada contoh kasus disaster recovery plan kedua dibawah ini.
Data Center Biznet
Pada tanggal 1 Maret 2017, salah satu data center Biznet di Jakarta mengalami kegagalan dalam membangkitkan sumber listrik cadangan. Hal ini mengakibatkan beberapa situs marketplace besar di Indonesia tumbang selama kurang lebih 6 jam.Sayangnya Tokopedia, Bukalapak, dan JD.ID sepertinya tidak memiliki disaster recovery plan. Karena selama data center Biznet downtime, ketiga situs e-commerce tersebut tetap tidak dapat diakses.
Bisa jadi ini merupakan contoh kasus disaster recovery plan yang tidak didukung dengan strategi pemulihan bencana. Anda dapat melihat perbedaan rencana pemulihan bencana dengan rencana keberlangsungan usaha agar terbebas dari kesesatan yang dapat menempatkan perusahaan ada pada kondisi sulit.
Beberapa Maskapai Penerbangan di Amerika Serikat
Beberapa perusahaan maskapai penerbangan di AS juga mengalami downtime. Data center yang mereka pakai baik milik sendiri maupun pada fasilitas colocation data center dari pihak ketiga mengalami kegagalan pembangkit daya listrik cadangan. Kejadian downtime tersebut berlangsung beberapa hari, mereka hanya berfokus pada strategi pemulihan dengan penggantian perangkan UPS Fly Wheel (Geared UPS).
Tentunya kejadian downtime tersebut dapat kita ambil sebagai contoh kasus disaster recovery plan yang kurang memadai. Untuk dapat memastikan pemulihan bencana perusahaan berjalan sesuai rencana, jalan satu-satunya adalah dengan selalu melakukan pengujian. Hanya dengan kesiapan yang baik maka kejadian downtime dapat diatasi secepat mungkin. Semakin cepat downtime, maka semakin sedikit potensi kerugian dan kehilangan kepercayaan.
Kesimpulan:
Untuk dapat mengambil manfaat dari contoh kasus disaster recovery plan pada perusahaan besar tersebut diatas, para pimpinan perusahaan (CEO, CIO, CTO dan terutama CFO) harus merubah cara pandang mereka. Bahwa tidak ada satu perusahaan pun yang kebal terhadap downtime, dan downtime terjadi secara tak terduga.
Terutama pada beberapa perusahaan startup fintech. Serangan cyber yang ditujukan kepada beberapa aplikasi fintech yang semakin canggih dan meningkat intensitasnya telah memperbesar resiko downtime. Strategi pemulihan bencana harus di dukung dengan situs pemulihan bencana yang berbeda lokasi dan memiliki infrastruktur dan teknologi yang memadai.
Komentar
Posting Komentar