COMPANY Disaster Recovery Plan (DRP) Pada Data Center Perusahaan IBM. Pada Dokumen ini akan menjelaskan pada pengelolaan Disaster Recovery Planning yang terjadi pada Data Center Perusahaan IBM pada database department produksi. Fery Ferdiansyah 5210100705 Manajemen Resiko A Plan and related Business Processes Business Process Feature Relevant Technical Components Production data SAN Drive (none) management January 19, 2014
Daftar Isi 1. Purpose and Objective... 3 Scope... 3 2. Dependencies... 4 3. Disaster Recovery Plan Framework ISO 27301 dan 22031... 5 3.2 Konsep implementasi DRP menggunakan standart ISO 22301... 6 4. Disaster Recovery Strategies... 8 5. Disaster Recovery Procedures... 8 Melakukan Disaster Recovery Sesuai dengan Kebutuhan Procedure... 9 Response Phase... 9 Resumption Phase... 9 Data Center Recovery... 9 Appendix A: Disaster Recovery Contacts - Admin Contact List... 11 Appendix B: Document Maintenance Responsibilities and Revision History... 11 Appendix C: Glossary/Terms... 12
1. Purpose and Objective Perusahaan raksasan IBM telah menerapkan konsep disaster recovery dalam mengelola pusat data dari lingkungan produksi IT berasal dari berbagai system seperti ERP, CRM, dan Manajemen Sumber Daya Manusia (MSM). Strategi disaster recovery harus menentukan dari sudut padang yang tinggi dan rinci terhadap system. Berikut beberapa klasifikasi data pada konsep disaster recovery pada IBM. Pada konsep yang saya tawarkan berupa bagaimana Pada perusahaan IBM dalam menerapkan Konsep DRP dan BCP dalam memanage terhadap segala resiko-resiko yang terjadi pada perusahannya. Pemeliharaan yang dilakukan pada pusat data atau Data center yang merupakan pusat dari keseluruhan datadata penting perusahaan Scope Ruang lingkup yang akan dibahas didalam dokumen DRP ini yaitu mengenai bagaimana perusahaan IBM dalam mengelola resiko yang rentan terjadi pada data center perusahaan. Dengan dibantu dengan proses Disaster Recovery Center untuk mendukung segala kebutuhan DRP yang akan dibahas selanjutnya. Konsep yang saya gunakan dengan menngimplementasikan Disaster Recovery Planning dan Business Contuinity Plan dalam memanaje resiko pada perusahaan. Scope pada dokumen ini juga membahas sebatas terhadap pemeliharaan data pada lingkungan produksi pada perusahaan IBM yang mana perusahaan IBM hanya perlun memback-up data dengan menggunakan resource IBM bisnis proses maanger dan IBM Bisnis Monitor configuration terhadap semua data, data customer, aplikasi, proses, template dan lainnya. Didalam Disaster Recovery Plan ini ada beberapa hal yang mungkin akan dibahas didalam sekitar dokumen ini : - Pedoman dalam melakukan perencanaan - Teknis aliran respon resiko dan strategy pemulihan bencana - Pedoman pada prosedur pemulihan - Manajemen insiden yang terjadi Tujuan utama pada disaster recovery plan : - Menetapkan proiritas secara teknis dalam melakukan pemulihan bencana - Meminimalisir dampak yang terjadi pada fitur dan proses bisnis - Menetapkan pemulihan secara operasional dalam pemulihan data center
2. Dependencies Pada bagian ini perusahaan memiliki dependencies dalam mengelola disaster recovery plan yang memungkinkan terjado pada perusahaan mereka : Dependency User Interface / Rendering Presentation components Business Intelligence / Reporting Processing components Network Layers Infrastructure components Storage Layer Infrastructure components Database Layer Database storage components Assumptions User dan administrator dapat melakukan aktfitas bisnis nya dengan normal Setiap infrastruktur IT dan system back-end dapat berjalan dengan lancar Penyampaian informasi kepada end user tidak sampai sehingga sering terjadinya miss komunikasi Standar proses back up data tidak mempengaruhi kinerja, bisa dikatakan system back up tidak berfungsi dengan baik. Banyak gangguan yang dapat mempengaruhi system pelaporan data. Konektivitas ke network resource sering ada gangguan Asumsi dari internal perusahaan bahwa terminal koneksi mereka masih berfungsi dengan normal dan ternyata sebaliknya. Kehilangan baca data storage pada local area storage. Data yang ada didalam database sering terjadi corrupt dan tidak ada sama sekali / terhapus oleh gangguan lain. Hardware/Host Layer Hardware components Virtualizations (VM's) Virtual Layer Administration Infrastructure Layer Internal/External Dependencies Komponen fisik rentan terjadinya kerusakan jika disebabkan oleh bencana alam dan human error. Komponen virtual tidak tersedia Hardware dan hosting dapat diakses Menonaktifkan support system, sehingga fungsi-fungsi lain tidak dapat berjalan dengan normal System interface dan inter system nya rusak
3. Disaster Recovery Plan Framework ISO 27301 dan 22031 Banyak organisasi yang berusaha untuk menentukan sebuah metode yang terbaik untuk menangani resiko yang mungkin terjadi dengan harapan bisnis mereka khususnya dibidang IT dalam berjalan dengan baik berdasarkan dengan system pemulihan bencana yang baik. ISO 27301 merupakan sebuah panduan pada BCP dan DRP terhadap pemulihan bencana IT bagaimana merencanakan keberlangsungan IT sesuai dengan konsep BCMS. BCMS itu sendiri merupakan Business Contuinity Management System. Merupakan standarisasi yang mengidentifikasi kebutuhan terhadap ICT Information and Communication Technology untuk menerapkan strategi-strategi tertentu untuk mengurangi gangguan resiko serta dapat merespon dan memperbaiki gangguan yang terjadi pada ICT. ISO 27301 merupakan pendekatan system manajemen dalam menangani resiko yang rentan terjadi pada ICT untuk mendukung kelangsungan bisnis yang lebih luas. Berdasarkan pengamatan saya ISO 27031 memiliki kaitan yang sangat erat dengan ISO 22301 yang menangani terhadap kesiapan ICT untuk focus terhadap IT Disaster Recovery dengan menggunakan model PDCA, yaitu Plan-DO-Check-Act. System ini bertujuan untuk menerapkan strategi untuk mengurangi gangguan resiko terhadap layanan ICT dan merespon serta memperbaiki segala kerusakan-kerusakan yang terjadi. Konsep PDCA merupakan model yang digunakan pada Business Continuity Management System. ISO 22301 merupakan standart interasional pada societal security Business Conyuinity Management System yang dikenalkan pada tahun 2012 merupakan standarisasi yang digunakan untuk konsep manajemen resiko pada Disaster Recovery. Standart ini digunakan untuk menilai kemampuan organisasi untuk memenuhi kebutuhan fungsional bisnis perusahaan dan menyediakan kerangka kerja untuk menerapkan konsep bisinis dan penanganan resiko secara efektif.
3.2 Konsep implementasi DRP menggunakan standart ISO 22301 Implementation Guidance Purpose of this document Tujuan pada pembuatan dokumen ini yaitu dapat menjadi sebuah panduan dalam penerapan Disaster Recovery pada perusahaan. Dimana banyak resiko yang sangat riskan terjadi, namun untuk mengatasinya dibutuhkan sebuah dokumen DRP dengan menggunakan standart ISO 22301untuk memberikan solusi dalam recovery data pada data center. Areas of the standart addressed Adapun area/lingkup pada dokumen ini berupa sebagai berikut : a. Sebagai prosedur dalam mengatasi resiko yang terjadi b. Mengimplementasikan konsep DRP dan BCP dalam menangani resiko c. Mengunakan standarisasi ISO 22301 dan 27301 pada penerapan konsep Disaster Recovery d. Sebagai manajemen review e. Melakukan back-up data dalam mengatasi kehilangan data pada data center General Guidance Dokumen ini menjadi sebagai pedoman pada perbaikan dengan menggunakan BCMS, menganalisis terhadap resiko yang mungkin terjadi serta menentukan strategi apa saja dalam menangani resiko tersebut. Review Frequency Dokumen ini direkomendasi bahwa dokumen ini ditinjau pada 1 bulan sekali Template version number ISO 22301 Templates Version 1 @Public IT Limited.
[Perusahaan IBM] Major Incident Report Major incident title : Major Incident date : Report Author Date of Report Penanganan resiko pada data center date fery date Chronology of the incident Terdapat beberapa jenis ancaman yang memungkinkan dapat menyerang server database pada perusahaan IBM, Server database merupakan asset yang terpenting pada IBM dimana mereka meload keseluruhan data mereka kedalam data center. Ketika bencana terjadi dan dapat menyerang keamanan database mereka, maka IBM satu-satunya cara yang pernah dilakukannya adalah meload semua dari data center ke server data cadangan. Data dapat diload kembali ketika data center kembali normal seperti semula. The impact of the incident Kehilangan data sangat berdampak tidak baik bagi perusahaan IBM, karena dapat menganggu aktivitas bisini pada setiap department perusahaan The underlying cause if known Bencana alam Human error Keamanan database Recommendation to lessen the likelihood of the incident recurring - Mengidentifikasi konsep resiko yang mungkin teradi - Melakukan back up data - Memperbaiki system yang rusak/terkena bencana dengan prosedur yang diterapkan Lessons learned Melakukan continual improvement Melakukan maintenance server setiap minggu Melakukan back up data
4. Disaster Recovery Strategies Penjelasan mengenai strategi apa saja yang akan dilakukan pada disaster recovery untuk melindungi pusat data perusahaan, gambaran strateginya sebagai berikut : Identifikasi gangguan terhadap data center Mencari alternatif pada kesalahan pada data center Mengalihkan data center ke tempat gudang data lain Melakukan cek operasional pada data layanan Take no action Ketergantungan significant pada Internal dan external melakukan back up dan pemindahan data Melakukan konsep recovery data secara strategies Menunggu system restorasi data kembali pulih dan melakukan komunikasi terhadap stakeholder Issue resiko yang terjadi pada Network Melakukan pemulihan terminal konektivitas internal perusahaan agar dapat mendukung proses bisnis Melakukan restorasi dan back up dengan melibatkan stakeholder atau menunggu tindakan teknis dalam mengelola resiko. 5. Disaster Recovery Procedures Pada disaster recovery sebenarnya terdapat 3 fase yang seharusnya ada pada procedure disaster recovery. 3 fase itu adalah response phase, resumption phase, dan restoration phase. Response Phase: Melakukan konfigurasi terhadap bencana yang terjadi dengan menggunakan system back up data. Mengatur data pemulihan bencana dengan menggunakan konfigurasi IBM Business Process Manager sebagai pemulihan pusat data Resumption Phase: Melakukan back up data menggunakan SAN drive SAN drive merupakan jaringan data yang menyalin data ke data center pusat server yang stand by. Menyimpan Log tranksaksi kedalam data base Melakukan log tranksasksi kedalam database sehingga dapat mereplikasi data ketika terjadi bencana Restoration Phase: Melakukan Restorasi data Jika bencana menyerang data primer maka dilakukan pengalihan data ke gudang data yang lain. Melakukan verifikasi restorasi data Setelah melakukan penyalinan data ke gudang data yang lain, ketika bencana berhasil dipulihkan maka data dari gudang dikembalikan ke pusat data primer, kemudin system memverifikasikan data sah apa tidak.
Melakukan Disaster Recovery Sesuai dengan Kebutuhan Procedure Response Phase Berikut ini adalah kegiatan yang diperlukan untuk merespon DR (Disaster Recovery) yang berkaitan pada fase ini. Prosedur ini menjelaskan atas kejadian yang memicu pada kerusakan data center (pusat data). Response Phase Recovery Procedures All DR Event Scenarios Step Owner Duration Components Identifikasi resiko yang tejadi DR TEAM 5 minutes Issue yang diidentifikasi Identiffikasi team dalam DR TEAM 5minutes Operasional melakukan recovery data Disaster Recovery Team Melakukan prosedur secara teknis dalam melakukan pemulihan DR TEAM or Ops 10 minutes Primary bridge line: 1 Secondary bridge line: 1 Alternate / backup communication tools: email, Komunikasi antar team dalam mencari strategy pemulihan data. communicator DR TEAM 15 minutes Melakukan dokumentasi terhadap resiko Melakukan transfer data pada pusat data gudang Resumption Phase Melakukan back up data menggunakan jaringan SAN drive yang bertujuan untuk memiliki konsep data yang sama dan mudah terhubung kedalam data center dan server yang sedang stabdvy. Data Center Recovery Full Data Center Failover Step Owner Duration Components Initiation failover DR TEAM TBD Melakukan prosedurrestorasi Risk terdetek dengan dilakukannya prosedur Mendefenisikan resiko Proses komunikasi issue dalam membahas solusi recovery data. Complete Failover DR TEAM TBD Melakukan tahap eksekusi, yaitu melakukan recovery data Test Recovery DR TEAM TBD Melakukan laporan hasil akhir dari verifikasi resiko. Failover deemed successful DR TEAM TBD Recovery sukses dilakukan. Berikut ini adalah contoh dalam penjadwalan penanganan resiko yang memungkinkan terjadi pada recovery data center. Reroute critical processes to alternate Data Center Step Owner Duration Components Memprediksi kerusakan yang DR TEAM 10 menit Bencana telah diprediksi terjadi Identifikasi bencana DR TEAM 15 menit Bencana teridentifikasi Pemulihan bencana DR TEAM 15 menit Bencana dapat diatasi Melakukan back up data DR TEAM 25 menit Back up data ke gudang data
Operate at deprecated service level prioritize critical feeds Step Owner Duration Components Pemulihan System recovery DR TEAM 30 menit Data recovery system data tidak berjalan Pemulihan Jaringan terputus, DR TEAM 45 menit Komunikasi stakeholder membuat sulit komunikasi antar perusahaan Pemulihan Data pada databse corrupt dan terhapus disebabkan oleh virus DR TEAM 1 jam Manajemen database Take no action monitor for Data Center recovery Prosedur pemulihan ini hanya akan menjadi alternatif yang dipilih dalam hal tidak ada pilihan lain yang tersedia untuk (misalnya penyebab dan pemulihan Data Center sepenuhnya dalam kendali departemen atau vendor lain). Step Owner Duration Components Melacak komunikasi dan DR TEAM As needed status pada tim recovery. Mengirimkan selalu tentang update informasi kepada petinggi perusahaan mengenai status Data center DR TEAM As needed
Appendix A: Disaster Recovery Contacts - Admin Contact List The critical team members who would be involved in recovery procedures for feature sets are summarized below. Feature Name Contact Lists For the key internal and external dependencies identified, the following are the primary contacts. Dependency Name Contact Information In addition the key BCP individuals are: Appendix B: Document Maintenance Responsibilities and Revision History This section identifies the individuals and their roles and responsibilities for maintaining this Disaster Recovery Plan. Primary Disaster Recovery Plan document owner is: Primary Designee: Alternate Designee: Name of Person Updating Document [NAME] Date Update Description Version # Approved By
Appendix C: Glossary/Terms Standard Operating State: Production state where services are functioning at standard state levels. In contrast to recovery state operating levels, this can support business functions at minimum but deprecated levels. Presentation Layer: Layer which users interact with. This typically encompasses systems that support the UI, manage rendering, and captures user interactions. User responses are parsed and system requests are passed for processing and data retrieval to the appropriate layer. Processing Layer: System layer which processes and synthesizes user input, data output, and transactional operations within an application stack. Typically this layer processes data from the other layers. Typically these services are folded into the presentation and database layer, however for intensive applications; this is usually broken out into its own layer. Database Layer: The database layer is where data typically resides in an application stack. Typically data is stored in a relational database such as SQL Server, Microsoft Access, or Oracle, but it can be stored as XML, raw data, or tables. This layer typically is optimized for data querying, processing and retrieval. Network Layer: The network layer is responsible for directing and managing traffic between physical hosts. It is typically an infrastructure layer and is usually outside the purview of most business units. This layer usually supports load balancing, geo-redundancy, and clustering. Storage Layer: This is typically an infrastructure layer and provides data storage and access. In most environments this is usually regarded as SAN or NAS storage. Hardware/Host Layer: This layer refers to the physical machines that all other layers are reliant upon. Depending on the organization, management of the physical layer can be performed by the stack owner or the purview of an infrastructure support group. Virtualization Layer: In some environments virtual machines (VM's) are used to partition/encapsulate a machine's resources to behave as separate distinct hosts. The virtualization layer refers to these virtual machines. Administrative Layer: The administrative layer encompasses the supporting technology components which provide access, administration, backups, and monitoring of the other layers.