Fery Ferdiansyah Manajemen Resiko A

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

management

SAN Drive



(none)

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

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

2. Dependencies

Pada bagian ini perusahaan memiliki dependencies dalam mengelola disaster recovery plan yang memungkinkan terjado pada perusahaan mereka :

Dependency Assumptions

User Interface / Rendering

Presentation components

 User dan administrator dapat melakukan aktfitas bisnis nya dengan normal

 Setiap infrastruktur IT dan system back-end dapat berjalan dengan lancar

Business Intelligence / Reporting

Processing components

 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.

Network Layers

Infrastructure components

 Konektivitas ke network resource sering ada gangguan

 Asumsi dari internal perusahaan bahwa terminal koneksi mereka masih berfungsi dengan normal dan ternyata sebaliknya.

Storage Layer

Infrastructure components

 Kehilangan baca data storage pada local area storage.

Database Layer

Database storage components  Data yang ada didalam database sering terjadi corrupt dan tidak ada sama sekali / _{terhapus oleh gangguan lain.}

Hardware/Host Layer

Hardware components  Komponen fisik rentan terjadinya kerusakan jika disebabkan oleh bencana alam _{dan human error.}

Virtualizations (VM's)

Virtual Layer _ Komponen virtual tidak tersedia _{Hardware dan hosting dapat diakses}

Administration

Infrastructure Layer  Menonaktifkan support system, sehingga fungsi-fungsi lain tidak dapat berjalan _{dengan normal}

Internal/External

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

[Perusahaan IBM]

Major Incident Report

Major incident title : Penanganan resiko pada data center Major Incident date : date

Report Author fery

Date of Report 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 :

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.

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.

•Mengatur data pemulihan bencana dengan menggunakan konfigurasi IBM Business Process Manager sebagai pemulihan pusat data

Response Phase: Melakukan konfigurasi terhadap bencana yang terjadi dengan menggunakan system back up data.

•SAN drive merupakan jaringan data yang menyalin data ke data center pusat server yang stand by.

Resumption Phase: Melakukan back up data menggunakan SAN drive

•Melakukan log tranksasksi kedalam database sehingga dapat mereplikasi data ketika terjadi bencana Menyimpan Log tranksaksi kedalam data base

•Jika bencana menyerang data primer maka dilakukan pengalihan data ke gudang data yang lain.

Restoration Phase: Melakukan 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

melakukan recovery data

DR TEAM 5minutes  Operasional

 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, communicator

Komunikasi antar team dalam mencari strategy pemulihan data.

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

terjadi

DR TEAM 10 menit  Bencana telah diprediksi 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

data tidak berjalan

DR TEAM 30 menit  Data recovery system Pemulihan Jaringan terputus,

membuat sulit komunikasi antar perusahaan

DR TEAM 45 menit  Komunikasi stakeholder

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

status pada tim recovery.

DR TEAM As needed  Mengirimkan selalu tentang

update informasi kepada petinggi perusahaan mengenai status Data center

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] Name of Person

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