PEMBANGUNAN DISASTER RECOVERY PLAN UNTUK SISTEM INFORMASI MANAJEMEN

TERINTEGRASI ITB

LAPORAN TUGAS AKHIR

Disusun sebagai syarat kelulusan tingkat sarjana

oleh:

Sila Wiyanti Putri / 13504051

PROGRAM STUDI TEKNIK INFORMATIKA SEKOLAH TEKNIK ELEKTRO DAN INFORMATIKA

INSTITUT TEKNOLOGI BANDUNG 2008

ii

LEMBAR PENGESAHAN

Program Studi Sarjana Informatika

PEMBANGUNAN DISASTER RECOVERY PLAN UNTUK SISTEM INFORMASI MANAJEMEN TERINTEGRASI ITB

Tugas Akhir

Program Studi Sarjana Informatika ITB

oleh: Sila Wiyanti Putri / 13504051

Telah disetujui dan disahkan sebagai laporan Tugas Akhir Program Sarjana Teknik Informatika, Sekolah Teknik Elektro dan Informatika

Institut Teknologi Bandung di Bandung, pada tanggal <tanggal>

Pembimbing,

Ir. Kridanto Surendro, M.Sc, Ph.D NIP. 131933281

iii

DAFTAR ISI

LEMBAR PENGESAHAN ............................................................................................................ ii ABSTRAK ..........................................................................................Error! Bookmark not defined. KATA PENGANTAR........................................................................Error! Bookmark not defined. DAFTAR ISI................................................................................................................................... iii DAFTAR GAMBAR....................................................................................................................... v DAFTAR TABEL .......................................................................................................................... vi DAFTAR ISTILAH ...................................................................................................................... vii BAB I  PENDAHULUAN ..........................................................................................................I-1 

1.1  Latar Belakang ........................................................................................................... I-1 1.2  Rumusan Masalah ...................................................................................................... I-3 1.3  Tujuan......................................................................................................................... I-3 1.4  Batasan Masalah......................................................................................................... I-3 1.5  Metodologi ................................................................................................................. I-4 1.6  Sistematika Pembahasan ............................................................................................ I-4 

BAB II  TINJAUAN PUSTAKA.............................................................................................. II-1 2.1  Sistem Informasi ....................................................................................................... II-1 2.2  Bencana ..................................................................................................................... II-2 

2.2.1  Definisi Bencana..............................................................................................................II-2 2.2.2  Klasifikasi Bencana .........................................................................................................II-2 

2.3  Disaster Recovery Planning ...................................................................................... II-4 2.3.1  Tahapan Pembangunan Disaster Recovery Plan .............................................................II-5 

2.3.1.1  Risk Assessment ........................................................................................................II-6 2.3.1.2  Priority Assessment ...................................................................................................II-7 2.3.1.3  Recovery Strategy Selection ......................................................................................II-8 2.3.1.4  Plan Documenting......................................................................................................II-9 

2.4  Business Continuity Planning ................................................................................. II-10 2.4.1  Hubungan Business Continuity Planning dengan Disaster Recovery Planning ............II-10 

BAB III  ANALISIS.................................................................................................................. III-1 3.1  Sistem Informasi Manajemen Terintegrasi ITB.......................................................III-1 3.2  Analisis Risiko .........................................................................................................III-4 

3.2.1  Analisis Risiko dari Segi Teknis.................................................................................... III-5 3.2.1.1  Kerusakan Perangkat Keras ..................................................................................... III-6 

3.2.1.1.1  Kerusakan Alat ................................................................................................. III-6 3.2.1.1.2  Ketiadaan Daya................................................................................................. III-6 

3.2.1.2  Kerusakan Perangkat Lunak dan Data..................................................................... III-7 3.2.1.3  Faktor Manusia ........................................................................................................ III-7 

3.2.2  Analisis Risiko dari Segi Lokasi.................................................................................... III-8 3.2.2.1  Bencana Banjir......................................................................................................... III-8 3.2.2.2  Bencana Gempa ....................................................................................................... III-8 3.2.2.3  Bencana Gunung Meletus ........................................................................................ III-9 3.2.2.4  Bencana Kebakaran ............................................................................................... III-10 

3.2.3  Analisis Risiko dari Segi Sosial................................................................................... III-10 3.3  Analisis Tingkat Kebutuhan...................................................................................III-11 3.4  Hasil Analisis .........................................................................................................III-12 

BAB IV  PERANCANGAN ......................................................................................................IV-1 4.1  Risk Assessment...................................................................................................... IV-1 4.2  Priority Assessment................................................................................................. IV-5 

iv

4.2.1  Priority Assessment Segi Arsitektur .............................................................................. IV-5 4.2.1.1  Perangkat Keras ....................................................................................................... IV-7 4.2.1.2  Perangkat Lunak ...................................................................................................... IV-7 4.2.1.3  Jaringan.................................................................................................................... IV-8 4.2.1.4  Data.......................................................................................................................... IV-9 

4.2.2  Priority Assessment Segi Proses.................................................................................. IV-11 4.2.3  Priority Assessment Segi Lokasi ................................................................................. IV-14 

4.3  Srategy Selection................................................................................................... IV-14 4.3.1  Bencana dan Lokasi ..................................................................................................... IV-14 4.3.2  Strategi Pemulihan Bancana Lingkup A...................................................................... IV-17 4.3.3  Strategi Pemulihan Bencana Lingkup B...................................................................... IV-19 

4.3.3.1  Lokasi Mirror Site.................................................................................................. IV-19 4.3.3.2  Infrastruktur Mirror Site ........................................................................................ IV-21 4.3.3.3  Updating Data Mirror Site ..................................................................................... IV-22 

4.4  Plan Documenting ................................................................................................. IV-23 BAB V  PENUTUP.................................................................................................................. V-25 

5.1  Kesimpulan..............................................................................................................V-25 5.2  Saran........................................................................................................................V-25 

DAFTAR REFERENSI ................................................................................................................. xi DAFTAR PUSTAKA.................................................................................................................... xii FORM KUESIONER ........................................................................Error! Bookmark not defined. HASIL KUESIONER ........................................................................Error! Bookmark not defined. RANCANGAN DESAIN GEDUNG PARKIR ................................Error! Bookmark not defined. 

v

DAFTAR GAMBAR

Gambar 1 Siklus DRP dalam memulihkan operasi ...............................................................................II-5 Gambar 2 Atribut risiko bencana...........................................................................................................II-6 Gambar 3 Elemen Bisnis Terkait dengan BCP dan DRP....................................................................II-11 Gambar 4 SIMT ITB sebagai portal SI di ITB.................................................................................... III-1 Gambar 5 Pertukaran data antar unit kerja di ITB............................................................................... III-4 Gambar 6 Lalu lintas data setelah diimplementasikannya SITM ITB ................................................ III-5 Gambar 7 Rekaman Gempa: Bandung Utara, 13 April 2005, 05.50 - 12.08 WIB.Error! Bookmark not defined. Gambar 8 Posisi Tangkuban Perahu dan Kota Bandung.........................Error! Bookmark not defined. Gambar 9 Komplek Observatorium Boscha, Lembang...........................Error! Bookmark not defined. 

vi

DAFTAR TABEL

Tabel 1 Tabel perbandingan jenis strategi pemulihan data ...................................................................II-9 Tabel 2 Sistem informasi yang terintegrasi di dalam SIMT ITB ........................................................ III-2 Tabel 3 Deskripsi kegiatan akademis per titik waktu........................................................................ III-11 Tabel 4 Tabel atribut ancaman bencana .............................................................................................. IV-3 Tabel 5 Rincian penilaian atribut risiko .............................................................................................. IV-3 Tabel 6 Bencana terurut tingkat ancaman ........................................................................................... IV-4 Tabel 7 Skala atribut prioritas ............................................................................................................. IV-6 Tabel 8 Penyebab kerusakan data...................................................................................................... IV-10 Tabel 9 Hasil Priority Assessment segi arsitektur ............................................................................. IV-11 Tabel 10 Prioritas segi arsitektur (terurut)......................................................................................... IV-11 Tabel 11 SI yang terlibat dalam SIMT ITB berikut proses yang direpresentasikannya.................... IV-12 Tabel 12 Interval waktu terkait proses akademis .............................................................................. IV-12 Tabel 13 Interval waktu terkait proses non-akademis ....................................................................... IV-13 Tabel 14 Priority assessment per interval waktu akademis ............................................................... IV-13 Tabel 15 Priority assessment per interval waktu non-akademis........................................................ IV-13 Tabel 16 Distribusi lokasi infrastruktur SIMT ITB........................................................................... IV-14 Tabel 17 Tabel lingkup bencana........................................................................................................ IV-16 Tabel 18 Tabel nilai lingkup.............................................................................................................. IV-16 

vii

DAFTAR ISTILAH

No, Nama Istilah Definisi

I-1

BAB I PENDAHULUAN

1.1 Latar Belakang

Bisnis dan industri cenderung berkembang semakin kompleks dari masa ke

masa, baik dari segi proses bisnis yang terjadi, struktur organisasi yang berlaku,

hingga ukuran data dan jumlah personel yang terlibat di dalamnya. Begitu juga

dengan peranan unsur teknologi dalam mendukung operasi bisnis yang semakin lama

semakin besar. Sistem informasi, jaringan telekomunikasi, dan basis data misalnya,

sudah menjadi bagian yang tidak dapat dipisahkan dari suatu kelangsungan operasi

suatu badan bisnis. Namun tidak hanya itu, ancaman yang berpotensi menganggu

berfungsinya unsur-unsur teknologi pendukung bisnis ini pun semakin bervariasi

seiring dengan perkembangan zaman. Ancaman-ancaman ini antara lain mencakup

pembobolan keamanan jaringan, ketiadaan daya, pemogokan pegawai, dan banyak

lagi. Karena perannya yang cukup besar, ancaman bagi unsur teknologi ini dapat

dikatakan merupakan ancaman bagi keberlangsungan perusahaan juga.

Dalam keadaan darurat yang mungkin ditimbulkan oleh ancaman-ancaman

tersebut, pengambilan keputusan yang tepat sangatlah penting untuk kelangsungan

perusahaan. Apa yang harus dilakukan pertama? Bagaimana cara melakukannya?

Siapa yang harus diberitahu terlebih dahulu? Keputusan yang diambil perusahaan

terhadap pertanyaan-pertanyaan seperti tentunya akan sangat berpengaruh terhadap

dapat tidaknya perusahaan tersebut kembali memegang kontrol dalam keadaan darurat

[KEP07].

Tidak hanya tepat atau tidaknya, kecepatan pengambilan keputusan pun sangat

berpengaruh. Keputusan tepat yang dieksekusi terlambat tidak akan membantu sama

sekali. Hal ini dikarenakan perusahaan harus mampu mengembalikan fungsi-fungsi

pentingnya dengan sesegera mungkin. Semakin banyak waktu pemulihan yang

dibutuhkan, semakin tinggi pula tingkat kerugian yang diderita. Kerugian yang

dialami misalnya dapat berupa menurunnya tingkat kepuasan pelanggan, hilangnya

pelanggan, atau bahkan pembatalan transaksi penting [FUL05 dengan perubahan

seperlunya].

I-2

Menjawab pertanyaan dan menghindari kerugian seperti di atas akan lebih

mudah jika perusahaan memiliki rencana pemulihan. Rencana ini dapat berupa

runutan tahapan yang harus dilakukan jika suatu keadaan darurat terjadi. Rencana

yang tersusun dengan baik akan sangat membantu perusahaan dalam melewati

keadaan darurat dan kembali menjalankan fungsinya, namun jika rencana yang

digunakan sebagai pegangan ternyata tidak sesuai dengan kebutuhan sebenarnya,

maka yang terjadi kemungkinan besar justru merupakan kebalikannya.

Proses penyusunan rencana pemulihan ini disebut Disaster Recovery Planning.

Lebih lengkapnya, Disaster Recovery Plan adalah sekumpulan aksi dan proses yang

mendefinisikan rangkaian prosedur yang harus dilakukan suatu perusahaan, saat

terjadi keadaan darurat, untuk memastikan tercapainya suatu kondisi pulih dalam

waktu yang ditentukan sehingga perusahaan tersebut mampu melanjutkan fungsinya

dengan kerugian minimal [BAR01].

Disaster Recovery Planning adalah bagian dari rangkaian Business Continuity

Planning. Disaster Recovery Plan bersifat reaktif terhadap suatu bencana, berfokus

pada apa yang harus dilakukan untuk mengembalikan fungsi-fungsi yang terganggu

oleh bencana, sedangkan bagian-bagian lain dari Business Continuity Planning lebih

bersifat proaktif/preventif, yaitu berfokus pada apa yang dapat dilakukan untuk

mengurangi dampak bencana bila terjadi.

Dalam pelaksanaan tugas akhir ini, akan dilakukan studi kasus sebagai

permasalahan yang diangkat. Studi kasus akan dilakukan pada Unit Sumber Daya

Informasi Institut Teknologi Bandung (USDI ITB. USDI ITB dipilih sebagai tempat

studi kasus karena dalam operasinya memiliki kebergantungan erat yang cukup

merata pada elemen-elemen bisnis yang mencakup: sumber daya manusia, teknologi,

infrastruktur, dan proses. Pemilihan USDI ITB sebagai tempat studi kasus juga

dipengaruhi faktor kemudahan akses dalam memperoleh informasi dan data yang

diperlukan dalam pelaksanaan Disaster Recovery Planning.

Unit Sumber Daya Informasi ITB membawahi banyak proses dalam

menjalankan fungsinya di ITB. Untuk menjaga pengerjaan Tugas Akhir ini tetap

fokus, penulis hanya akan menitikberatkan pembahasan pada pembangunan Disaster

Rcovery Planning pada Sistem Informasi Manajemen Terintegrasi ITB yang saat ini

berada dalam kewenangan Unit Sumber Daya Informasi ITB.

I-3

1.2 Rumusan Masalah

Berdasarkan latar belakang masalah yang telah diungkapkan, permasalahan

utama yang akan dikaji dalam tugas akhir ini adalah bagaimana bentuk Disaster

Recovery Plan yang paling sesuai untuk diterapkan pada Sistem Informasi

Manajemen Terintegrasi ITB.

Berikut ini adalah rincian masalah yang akan dikaji dalam tugas akhir ini :

1. Apa itu Disaster Recovery Plan?

2. Bagaimana mengidentifikasi faktor-faktor yang mempengaruhi pembangunan

Disaster Recovery Plan?

3. Bagaimana Disaster Recovery Plan yang paling sesuai untuk diterapkan pada

SIMT ITB?

1.3 Tujuan

Tujuan utama dari Tugas Akhir ini adalah melakukan Disaster Recovery

Planning dan menghasilkan Disaster Recovery Plan yang dianggap paling sesuai

untuk diterapkan di instansi yang menjadi tempat studi kasus. Untuk mencapai tujuan

tersebut, perlu dilakukan:

1. Pemahaman konsep Disaster Recovery Planning.

2. Identifikasi faktor-faktor yang mempengaruh pembangunan Disaster Recovery

Plan pada SIMT ITB.

3. Perancangan Disaster Recovery Plan yang paling sesuai untuk diterapkan

pada SIMT ITB.

1.4 Batasan Masalah

Dalam pelaksanaan Tugas Akhir ini terdapat beberapa batasan masalah yang

perlu diperhatikan, yaitu:

1. Hasil akhir yang diharapkan adalah rancangan Disaster Recovery Plan yang

dianggap sesuai untuk diterapkan pada SIMT ITB berdasarkan proses analisis

kebutuhan dan perancangan yang dilakukan.

I-4

2. Studi kasus dalam Tugas Akhir ini adalah Sistem Informasi Manajemen

Terintegrasi ITB yang berada di bawah kewenangan Unit Sumber Daya

Informasi Institut Teknologi Bandung (USDI-ITB)

1.5 Metodologi Dalam penyusunan Tugas Akhir ini akan digunakan metodologi sebagai berikut:

1. Studi Literatur

Studi literatur dilakukan terhadap berbagai macam jenis buku, makalah, dan

halaman situs internet. Hal yang dikaji dalam studi literatur ini diantaranya :

a. Konsep umum Disaster Recovery Planning.

b. Metodologi penyusunan sebuah Disaster Recovery Plan.

2. Studi Kasus

Studi kasus yang akan dilakukan akan berbentuk wawancara dan atau

mempelajari dokumentasi-dokumentasi terkait mengenai Sistem Informasi

Manajemen Terintegrasi ITB yang didapatkan melalui bantuan USDI ITB.

3. Analisis

Melakukan analisis kebutuhan dan identifikasi faktor-faktor yang

mempengaruhi tahap perancangan sesuai dengan hasil studi kasus.

4. Perancangan

Melaksanakan pembangunan rancangan Disaster Recovery Plan sesuai dengan

berdasarkan metode yang didapatkan dari studi literatur dan menggunakan

hasil analisis.

1.6 Sistematika Pembahasan Sistematika laporan tugas akhir ini adalah sebagai berikut :

1. BAB I – Pendahuluan

Bab Pendahuluan membahas mengenai latar belakang penulisan tugas akhir,

rumusan persoalan, tujuan tugas akhir, ruang lingkup dan batasan masalah,

metodologi yang digunakan serta sistematika pembahasan dari laporan tugas

akhir.

2. BAB II – Landasan Teori

I-5

Bab Landasan Teori memuat berbagai pengetahuan yang didapat melalui studi

literatur. Pengetahuan yang dibahas meliputi konsep umum Disaster Recovery

Planning, dan pengetahuan-pengetahuan lain yang mendukung.

3. BAB III – Analisis

Bab analisis akan membahas proses analisis kebutuhan pada instansi. Hasil

dari proses analisis kebutuhan kemudian akan digunakan sebagai masukan

pada tahap perancangan.

4. BAB IV – Perancangan

Pada bab perancangan akan dilakukan Disaster Recovery Planning sesuai

dengan hasil pada bab Analisis. Disaster Recovery Planning dilakukan sesuai

dengan tahapan yang dipelajari dari studi literatur.

5. Bab IV – Kesimpulan dan Saran

Bagian ini akan membahas kesimpulan dan saran terhadap hasil pelaksanaan

tugas akhir.

II-1

BAB II TINJAUAN PUSTAKA

2.1 Sistem Informasi Manusia dalam beraktivitas dan menjalankan fungsinya tidak dapat lepas dari

sistem. Sistem adalah kesatuan banyak elemen yang saling berkoordinasi satu sama

lain untuk menjalankan sebuah fungsi spesifik. Seiring dengan berkembangnya

teknologi, manusia mulai merancang sistem berbasis komputer untuk melengkapi,

memperluas atau menggantikan aktivitas manusia sedemikian sehingga aktivitas

tersebut dapat terlaksana lebih cepat atau lebih baik. Sistem ini disebut sistem

informasi.

Sistem informasi adalah rangkaian perangkat keras, perangkat lunak, dan

jaringan komunikasi yang dirancang untuk menghasilkan, memproses,

mengumpulkan, mendistribusikan dan menggunakan data sehingga menjadi informasi

yang berguna. Setiap elemen dalam sistem informasi, termasuk manusia, data hingga

kepada aplikasi dan perangkat lunak harus saling berkoordinasi dengan baik, efisien

dan seefektif mungkin dalam menjalankan fungsinya. Tujuan dari sistem informasi

adalah menyediakan data yang berguna bagi penggunanya, baik berupa pengguna

akhir maupun sistem informasi lain.

Sistem informasi tidak sama dengan teknologi informasi. Sistem informasi

menerima data sebagai masukan, memproses data tersebut, dan menghasilkan produk

manipulasi data tersebut keluaran, sedangkan teknologi informasi menyediakan

mengkonstruksikan aspek-aspek sistem informasi baik dalam perangkat keras, lunak,

penyimpanan data, dan komunikasi. Singkatnya, dapat dikatakan bahwa teknologi

informasi merupakan bagian dari sistem informasi dan berperan sebagai alat bantu.

Secara praktis, dasar dari sistem informasi tidak bergantung pada teknologi

yang dipakai dalam sistem aktual, tetapi kini perlu dipikirkan untuk mengaitkan

sistem informasi dengan teknologi informasi, karena perkembangan teknologi yang

pesat mampu menawarkan kemungkinan jenis sistem informasi baru di luar batas

kemampuan teknologi sebelumnya, hal ini kemudian memungkinkan aktivitas baru,

II-2

cara baru untuk mengerjakan sesuatu, dan cara pikir baru yang mustahil dilakukan

tanpa teknologi baru.

2.2 Bencana

2.2.1 Definisi Bencana Bencana dalam hubungannya dengan Disaster Recovery Planning adalah segala

sesuatu yang menggangu berjalannya proses bisnis sehingga menghambat suatu

organisasi dalam menjalankan fungsinya [BAR01]. Bencana umumnya dianggap

melumpuhkan jika bencana tersebut meniadakan salah satu atau lebih sumber daya

berikut:

1. Sumber daya manusia

2. Fasilitas

3. Komunikasi

4. Daya

5. Akses Informasi

2.2.2 Klasifikasi Bencana Berdasarkan penyebabnya, bencana dapat dikelompokkan menjadi dua, yaitu:

bencana alam, dan bencana non-alamiah. Klasifikasi ini akan dijabarkan dengan lebih

jelas sebagai berikut:

1. Bencana alam (natural disaster)

a. Bencana alam endogen

Bencana alam endogen disebabkan oleh gaya-gaya yang

berasal dari bagian dalam bumi, atau yang juga dikenal dengan sebutan

gaya endogen (geologis). Yang termasuk dalam bencana alam endogen

adalah gempa bumi, letusan gunung berapi, dan tsunami.

b. Bencana alam eksogen

Bencana alam eksogen merupakan bencana alam yang

disebabkan oleh faktor angin dan hujan (klimatologis). Contoh

bencana alam eksogen adalah banjir, badai, angin puting beliung,

kekeringan, dan kebakaran alami hutan.

c. Bencana alam ekstra-terestrial

Bencana alam ekstra-terestrial adalah bencana alam yang

terjadi di luar angkasa, contoh: hantaman meteor. Benda-benda langit

II-3

yang terjatuh mengenai permukaan bumi akan menimbulkan pengaruh

yang cukup besar pada kondisi bumi.

d. Bencana environmental

Bencana environmental adalah bencana yang disebabkan oleh

perubahan kondisi lingkungan sehingga menyulitkan pengerjaan hal-

hal yang sebelumnya dapat dilakukan. Bencana jenis ini mencakup

pencemaran lingkungan (air, udara, tanah, suara), dan penyebaran

wabah penyakit (epidemi).

2. Bencana non-alamiah (unnatural disaster)

a. Bencana sosial

Adalah bencana yang disebabkan oleh ketidakstabilan kondisi

sosial masyarakat di suatu tempat pada suatu waktu. Bencana sosial

mencakup peperangan, kerusuhan, aksi anarki, pemogokan pegawai,

konflik budaya, dan lain sebagainya.

b. Bencana teknikal (technical failure disaster)

Adalah bencana yang berkaitan dengan malfungsi teknologi.

Bencana jenis ini mencakup kerusakan data, sistem informasi, alat dan

perlengkapan, dan lain-lain.

c. Bencana antropogenikal

Selain dari berbagai macam bencana yang sudah dijabarkan

sebelumnya, bencana juga dapat disebabkan oleh faktor manusia, baik

secara sengaja maupun tidak. Bencana jenis ini sangat beragam dan

dapat dikatakan lebih kerap terjadi dibandingkan dengan jenis bencana

lainnya. Contoh bencana karena manusia misalnya, ancaman bom,

cyber attack, penghapusan data secara tidak sengaja, pencurian, dan

lain sebagainya.

Sedangkan berdasarkan dampaknya, bencana dapat dibedakan menjadi

tingkatan risiko yang berbeda-beda. Tingkatan risiko ini juga dikenal sebagai The

Five Layer of Risk [WAL04], yang didefinisikan sebagai berikut:

1. Layer 1: External Risks

Dampak bencana yang timbul tidak hanya mempengaruhi fasilitas, aset, dan

lokasi organisasi tetapi juga lingkungan sekitar organisasi. Umumnya

disebabkan karena bencana alam, seperti banjir, gempa, dan lain sebagainya.

2. Layer 2: Facility Wide Risks

II-4

Dampak bencana yang timbul hanya mempengaruhi organisasi saja secara

lokal. Umumnya disebabkan karena tidak tersedianya utilitas dasar yang

diperlukan oleh organisasi tersebut, seperti listrik, jaringan telepon, dan

lainnya.

3. Layer 3: Data System Risks

Dampak bencana yang timbul mempengaruhi ketersediaan dan integritas dari

data dan sistem informasi yang digunakan oleh organisasi tersebut. Umumnya

disebabkan karena faktor kerusakan atau intrusi pada sistem keamanan

jaringan/data yang digunakan.

4. Layer 4: Departemental Risks

Dampak bencana yang timbul hanya mempengaruhi satu atau beberapa bagian

dari organisasi, sehingga organisasi hanya mengalami dampak tidak langsung,

seperti tidak tetapi juga lingkungan sekitar organisasi. Umumnya disebabkan

karena bencana sosial seperti, demonstrasi karyawan di suatu

cabang/departemen, dan lain sebagainya.

5. Layer 5: Desk Risks

Dampak bencana yang timbul hanya mempengaruhi tingkat individu/personel,

tidak mempengaruhi organisasi secara langsung maupun besar. Contoh

bencana dengan risiko ini antara lain: terhapusnya berkas di komputer pekerja,

mengakibatkan pekerjaannya tidak dapat selesai tepat waktu.

2.3 Disaster Recovery Planning

Disaster Recovery Plan adalah suatu acuan berisikan prosedur untuk merespon

kejadian yang mengakibatkan hilangnya sumber daya sistem informasi secara

bermakna (bencana), menyediakan operasi cadangan selama sistem terhenti, dan

mengelola proses pemulihan serta penyelamatan sehingga mampu meminimalisir

kerugian yang dialami oleh organisasi. Tujuan utama dari Disaster Recovery Plan

adalah untuk menyediakan kemampuan atau sumber daya untuk menjalankan proses

vital untuk meminimalisir kerugian organisasi. Karena bertindak sebagai pegangan

saat terjadi keadaan darurat, Disaster Recovery Plan tidak dapat disusun secara

sembarangan. Disaster Recovery Plan yang tidak sesuai dapat berakibat lebih buruk

bagi keberlangsungan organisasi daripada bencana itu sendiri. Proses pembangunan

Disaster Recovery Plan disebut Disaster Recovery Planning.

II-5

Gambar 1 Siklus DRP dalam memulihkan operasi

Memiliki Disaster Recovery Plan yang baik dan dapat diandalkan

mendatangkan banyang keuntungan. Keuntungan tersebut diantaranya adalah:

1. Mengurangi kemungkinan terjadinya kerugian secara ekonomi karena

terjadi bencana.

2. Mengurangi kemungkinan tergangunya kegiatan operasional yang

penting.

3. Meningkatkan stabilitas organisasi.

4. Memberikan rencana pemulihan yang teratur dan terukur.

5. Menurunkan premi asuransi.

6. Menghindari terjadinya ketergantungan terpusat pada satu atau

sekelompok personel.

7. Melindungi aset organisasi, termasuk keselamatan personel di

dalamnya.

8. Mengurangi intensitas pengambilan keputusan saat terjadi keadaan

darurat.

2.3.1 Tahapan Pembangunan Disaster Recovery Plan

II-6

Disaster Recovery Planning merupakan proses bertahap yang tersusun secara

metodikal. Tahapan pembangunan sebuah Disaster Recovery Plan tidak selalu sama,

karena sangat bergantung pada kebutuhan dan tujuan pembuatannya. Namun secara

garis besar, tahapan tersebut dapat dirangkum sebagai berikut:

1. Risk assessment

2. Priority assessment

3. Recovery strategy selection

4. Plan documenting

2.3.1.1 Risk Assessment Risk Assessment adakah proses identifikasi ancaman-ancaman yang mungkin

terjadi, baik yang berasal dari dalam, maupun dari luar. Bencana yang dianalisa

termasuk bencana alam, bencana kegagalan teknis, maupun ancaman-ancaman faktor

manusia. Risk Assessment berperan penting untuk keberlangsungan pembangunan

keseluruhan Disaster Recovery Planning karena dapat dianggap sebagai landasan

awal yang akan mempengaruhi tahapan-tahapan selanjutnya. Risk Assessment

biasanya diikuti dengan Impact Analysis, dimana kemungkinan-kemungkinan bencana

yang sudah teridentifikasi kemudian dianalisis dampaknya.

Gambar 2 Atribut risiko bencana

Pada fase ini, setiap ancaman bencana yang sudah diidentifikasi akan diberi

nilai pada setiap atributnya. Nilai atribut-atribut ini dapat diperoleh melalui dua

pendekatan yang berbeda yakni secara kuantitatif dan kualitatif. Pendekatan

II-7

kuantitatif risiko menggunakan data nilai finansial yang diformulasikan dengan

menggunakan metode tertentu. Pendekatan ini biasanya akan sulit untuk mengukur

nilai intangible yang ada. Sedangkan pendekatan kualitataif risiko lebih condong

menggunakan intuisi dan pengalaman terhadap risiko yang dihadapi sistem.

Pendekatan ini relatif simpel karena tidak membutuhkan data finansial yang detil

namun akan sulit memberikan gambaran presisi secara finansial terhadap sistem dan

risiko yang ada. Setelah fase ini diharapkan dapat ditentukan bencana mana yang dianggap

paling mengancam, yang paling mungkin terjadi, dan lain sebagainya.

2.3.1.2 Priority Assessment Saat suatu bencana terjadi dan mengganggu berbagai macam proses bisnis dan

operasi, sangatlah penting untuk memiliki urutan prioritas proses yang jelas. Prioritas

dapat diurutkan berdasarkan banyak hal. Dari segi arsitektur misalnya, server/ router

manakah yang menjadi prioritas dalam dipulihkan? Data mana yang harus lebih

dahulu diselamatkan?

Begitu juga dengan proses, prioritas pemulihan harus terurut dengan jelas.

Proses yang dianggap paling vital untuk keberlangsungan sistem nantinya akan

mendapatkan alokasi perhatian paling besar untuk dipulihkan kembali sebelum

proses-proses lainnya. Dengan demikian tujuan dari pembangunan Disaster Recovery

Plan, yaitu untuk memastikan sistem dapat berfungsi sebaik mungkin secepat

mungkin setelah gangguan suatu bencana, dapat terlaksana.

Priority Assessment untuk proses biasanya sangat relatif terhadap waktu dan

tempat terjadinya suatu bencana. Suatu sekolah misalnya, jika bencana terjadi pada

saat penerimaan murid baru, proses yang pertama kali harus dipulihkan mungkin

adalah proses terkait tes masuk dan pembayaran. Tidak demikian jika bencana terjadi

saat liburan, dimana kebanyakan proses akan berada dalam kondisi statis, dan

mungkin hanya akan berfokus pada penyelamatan data saja. Karena penentuan

prioritas pada tahap ini sangat krusial dan berkaitan dengan eksekusi Disaster

Recovery Plan di lapangan nantinya bila terjadi bencana, tahapan ini harus dilakukan

dengan hati-hati dan melalui berbagai macam pertimbangan yang matang.

II-8

2.3.1.3 Recovery Strategy Selection Pemilihan strategi pemulihan haruslah dipertimbangkan dengan seksama.

Strategi pemulihan yang baik harus memenuhi beberapa kriteria, yaitu:

1. Strategi pemulihan harus memenuhi key requirement yang sudah

didefinisikan di tahap sebelumnya.

2. Strategi pemulihan harus cost effective berbanding dengan risiko dan

prioritasnya.

3. Strategi pemulihan harus dapat diterapkan dengan kondisi yang terdapat

sekarang dan memungkinkan untuk ditingkatkan jika teknologi atau bisnis

yang terkait berkembang di masa depan.

Strategi pemulihan yang sudah dirancang kemudian harus dituangkan ke

dalam Disaster Recovery Plan yang terdokumentasi secara baik sehingga dapat

dengan mudah dilaksanakan jika suatu saat terjadi bencana.

Terdapat beberapa strategi pemulihan yang umum digunakan saat ini, masing-

masingnya memiliki kekuatan dan kelemahannya sendiri tergantung dari kebutuhan.

Inti dari strategi-strategi pemulihan ini adalah sama yaitu menyiapkan sistem dan data

cadangan sehingga proses yang terganggu dapat berjalan kembali.

Strategi pemulihan tersebut diantaranya adalah:

1. Hot site

Strategi pemulihan dengan cara mengadakan lokasi duplikat dari lokasi asli.

Lokasi tersebut dilengkapi dengan segala perangkat, system, dan

infrastruktur yang diperlukan. Data yang tersimpan pun adalah data yang

ter update secara real time, sehingga selalu persis sama keadaannya dengan

lokasi asli. Hal semacam ini menguntungkan untuk bisnis yang sangat

bergantung pada jaringan komputasi atau telekomunikasi, karena dapat

mengembalikan kontrol akan jaringan dengan cepat. Strategi ini

menawarkan cara yang cepat untuk menjalankan bisnis kembali, namun

juga dapat dikatakan sebagai strategi yang paling mahal. Biaya yang

dikeluarkan dikatakan besar karena perangkat-perangkat yang dimiliki oleh

lokasi asli juga harus diadakan di lokasi cadangan, begitu juga dengan lalu

lintas data yang sangat besar di antara kedua lokasi untuk menjaga data

tetap update.

Hot site yang diadakan di dalam lingkungan bisnis itu sendiri dinamakan

in-house recovery site, sedangkan hot site yang berada di tempat yang

II-9

berbeda, cukup jauh untuk menghindarkan dari terkena bencana yang sama,

disebut mirrored site.

2. Warm site

Strategi ini menggunakan lokasi yang memiliki sistem dan jaringan

komunikasi yang siap digunakan, cukup untuk menjalankan kembali proses

bisnis. Namun data dan informasi elektronis lainnya tidak ter-update

sehingga harus di restore sebelumnya.

3. Cold site

Strategi ini hanya menyediakan lokasi saja. Perangkat dan jaringan yang

tersedia sangat minim jika tidak ingin dikatakan tidak ada. Keuntungan dari

strategi semacam ini adalah biaya yang ringan dalam mengadakan dan

merawat lokasi, namun di lain pihak, pada saat bencana datang, strategi ini

membutuhkan biaya inisiasi yang cukup besar karena harus mengadakan

berbagai perangkat, sistem, dan jaringan agar dapat mendukung berjalannya

bisnis. Strategi ini juga dikenal dengan sebutan shell site, backup site, atau

alternate site.

Strategi-strategi di atas dapat dirangkum menjadi seperti pada Tabel 1.

Tabel 1 Tabel perbandingan jenis strategi pemulihan data No. Jenis Strategi Biaya Perangkat Jaringan Waktu Dibutuhkan 1. Hot Site Tinggi Lengkap Lengkap Sangat singkat 2 Warm site Menengah Sebagian Sebagian Menengah 3 Cold site Rendah Minim Minim Cukup lama

Ketiga strategi di atas dalam implementasinya dapat dimiliki secara

independen oleh organisasi, ataupun menggunakan jasa vendor penyedia layanan.

Lokasinya pun dapat berupa lokasi permanen (gedung atau bangunan) maupun semi

permanen (truk, trailer, dan lainnya). Jika perusahaan memilih untuk menggunakan

jasa vendor, harus dipastikan vendor yang dikontrak memahami kebutuhan organisasi

secara menyeluruh, sehingga saat terjadi gangguan bencana vendor tersebut dapat

menyediakan segala keperluan organisasi dengan baik

2.3.1.4 Plan Documenting Hasil analisa dan rancangan strategi yang sudah dihasilkan dari tahapan-

tahapan sebelumnya tidak akan berarti apa-apa jika tidak terdokumentasi dengan baik.

Saat terjadi bencana, personel-personel yang mengerti benar akan Disaster Recovery

II-10

Plan yang sudah dirancang mungkin tidak akan sepenuhnya tersedia, atau bahkan

sudah tidak aktif di organisasi tersebut. Karena itu Disaster Recovery Plan haruslah

didokumentasikan dengan terstruktur sehingga mudah dipahami saat dibutuhkan.

Tersedia berbagai macam standar untuk mendokumentasikan sebuah Disaster

Recovery Plan. Toolkit dan pedoman-pedoman penyusunan dokumen Disaster

Recovery Plan pun banyak tersedia. Dalam pengerjaan tugas akhir ini, Disaster

Recovery Plan yang dirancang akan didokumentasikan sesuai dengan kebutuhan

SIMT ITB.

2.4 Business Continuity Planning

Jika berbicara mengenai Disaster Recovery Planning (DRP), tentunya tidak

akan dapat lepas dari Business Continuity Planning (BCP). Kedua hal ini berkaitan

sangat erat satu sama lain sehingga umumnya dipandang sebagai hal yang sama,

namun dalam kenyataannya tidak selalu demikian. Perbedaan dan persamaan antara

dua hal ini akan dijelaskan dalam sub bab ini.

Business Continuity Planning adalah sekumpulan proses otomatis atau pun

manual yang dirancang untuk mengurangi ancaman terhadap fungsi-fungsi penting

organisasi, sehingga menjamin kontinuitas layanan bagi operasi yang penting

[SOL05]. Business Continuity Planning dirancang untuk melindungi proses bisnis

yang dianggap penting dari kerusakan atau bencana yang terjadi secara alamiah atau

perbuatan manusia, dan kerugian yang ditimbulkan dari tidak tersedianya proses

bisnis normal.

Tujuan utama dari Business Continuity Planning adalah untuk meminimalisir

efek dari kejadian atau bencana dalam sebuah perusahaan atau organisasi. Manfaat

utama dari Business Continuity Plan adalah untuk mereduksi risiko kerugiaan

keuangan dan meningkatkan kemampuan perusahaan untuk memulihkan diri dari

bencana atau gangguan sesegera mungkin. Perencanaan keberlangsungan bisnis juga

harus dapat membantu meminimalisir biaya dan mengurangi risiko sehubungan

dengan kejadian bencana tersebut.

2.4.1 Hubungan Business Continuity Planning dengan Disaster Recovery Planning

Bisnis dalam pengertiannya adalah suatu organisasi yang melakukan aktivitas

bersifat komesial yaitu menyediakan jasa atau barang yang dibutuhkan konsumennya

II-11

dengan bertujuan mencapai profit [INV07]. Bisnis merupakan sesuatu yang sangat

kompleks dan luas, karena itu terdapat banyak cara untuk melakukan klasifikasi

elemen-elemen penyusunnya. Namun dengan kaitannya terhadap Business Continuity

Planning dan Disaster Recovery Planning, elemen-elemen bisnis dapat dibedakan

secara sederhana menjadi tiga, yaitu: sumber daya manusia, proses, dan teknologi.

Ketiga hal ini berkaitan dengan erat dan saling berinteraksi dalam berjalannya suatu

bisnis [SNE07].

Gambar 3 Elemen Bisnis Terkait dengan BCP dan DRP

Penjelasan mengenai masing-masing elemen di atas adalah sebagai berikut:

1. Sumber Daya Manusia

Sumber daya manusia dalam konteks ini mengacu pada personel-

personel yang terlibat sebagai pelaku dalam suatu proses bisnis. Dalam

Business Continuity Planning dan Disaster Recovery Planning, faktor sumber

daya manusia berperan sangat penting. Dalam fase perancangan misalnya,

untuk menghasilkan Business Continuity Plan dan Disaster Recovery Plan

yang sesuai, diperlukan masukan-masukan dari orang-orang yang memahami

bidang kerjanya dengan baik. Mengumpulkan personel kunci dari setiap

proses bisnis dan meminta masukan mereka adalah cara paling sederhana dan

efektif untuk mendapatkan gambaran apa saja yang harus dipertimbangkan

dari masing-masing proses bisnis.

Hal lain yang membuat elemen sumber daya manusia harus

mendapatkan perhatian adalah, faktor ketidakpastian respon masing-masing

saat terjadi keadaan darurat. Respon seseorang dalam menghadapi keadaan

II-12

darurat tidak dapat diharapkan sama dengan reaksi orang lainnya. Orang yang

sama pun mungkin akan memberikan respon yang berbeda jika dihadapkan

dengan keadaan darurat yang berbeda. Demikian pula jika ia dihadapkan pada

keadaan darurat yang sama untuk kali berikutnya, reaksi yang diberikan belum

tentu sama.

2. Proses

Proses bisnis adalah rangkaian aktivitas terkoordinasi yang bertujuan

mencapai suatu tujuan spesifik dalam suatu badan bisnis [ROS06]. Setiap

bisnis memiliki proses bisnisnya masing-masing sesuai dengan fungsi apa saja

yang dibutuhkan oleh badan bisnis tersebut dalam beroperasi.

Setiap proses yang terjadi dikembangkan berdasarkan aktivitas yang

terjadi secara berulang dalam badan bisnis tersebut. Hal-hal yang terjadi di

luar proses, biasanya ditangani sebagai pengecualian (exception). Jika suatu

pengecualian terjadi cukup kerap, maka umumnya terbentuk suatu proses baru

yang dikhususkan untuk menanganinya.

Dalam Business Continuity Planning dan Disaster Recovery Planning,

sangatlah penting untuk mengetahui dengan baik proses-proses bisnis yang

terjadi di suatu badan bisnis. Hal ini diperlukan karena proses-proses tersebut

akan dievaluasi, dikelompokkan, dan ditentukan prioritasnya. Penentuan

prioritas inipun tidak bisa sembarangan karena sangat tergantung pada

berbagai faktor dari keadaan darurat, misalnya jenis keadaan darurat yang

terjadi, waktu kejadian, keadaan bisnis saat terjadi keadaan darurat, dan lain-

lain.

3. Teknologi

Hampir setiap bisnis menggunakan teknologi dalam menjalankan dan

menunjang proses bisnisnya, karena itu, teknologi merupakan elemen yang

tidak dapat dipisahkan dari bisnis. Setiap teknologi yang digunakan akan

dianalisa untuk ditentukan kekurangan, kelebihan, kemungkinan teknologi

pengganti atau alternatif, dan reliabilitasnya dalam suatu keadaan darurat

Seluruh elemen bisnis di atas dan interaksi yang terjadi di antara ketiganya

adalah objek dari Business Continuity Planning, sedangkan Disaster Recovery

Planning menitikberatkan fokusnya pada elemen teknologi saja. Selain itu,

Disaster Recovery Plan adalah prosedur yang dijalankan saat Business

Continuity Plan berlangsung (in action), yaitu berupa langkah-langkah untuk

II-13

penyelamatan dan pemulihan yang teknologi, sistem informasi, dan data.

Tujuan akhir dari Business Continuity Plan dan Disaster Recovery Plan

adalah sama yaitu untuk menjamin keberlangsungan proses bisnis penting atau

utama. Disaster Recovery Plan merupakan bagian atau subset dari strategi yang

ada pada Business Continuity Plan dalam menghadapi bencana yang

mengancam keberlangsungan proses bisnis penting.

III-1

BAB III ANALISIS

3.1 Sistem Informasi Manajemen Terintegrasi ITB ITB dalam menjalankan kegiatan operasionalnya, membagi tanggung jawab ke

dalam badan kerja-badan kerja. Masing-masing badan kerja tersebut memiliki sistem

informasi untuk membantu mereka dalam melakukan fungsinya. Dalam menjalankan

fungsi dan tanggung jawabnya masing-masing, unit kerja tersebut seringkali

membutuhkan data atau informasi yang dimiliki oleh unit kerja lainnya. Karena itu,

pertukaran data antar sistem informasi badan kerja tidak dapat dihindari.

Sistem Informasi Manajemen Terintegrasi ITB (SIMT ITB) adalah sebuah

sistem informasi yang dirancang dengan tujuan utama untuk memfasilitasi kebutuhan

data antar badan kerja di ITB. SIMT ITB menyediakan standarisasi data dan

pengaturan kewenangan masing masing badan kerja atas data tersebut. Gambar 4

mengilustrasikan posisi SIMT ITB sebagai portal sistem informasi-sistem informasi

di ITB.

Gambar 4 SIMT ITB sebagai portal SI di ITB

III-2

Elemen-elemen yang terlibat di dalam sistem informasi tersebut dapat dilihat

pada Tabel 2 di bawah ini. Tabel 2 Sistem informasi yang terintegrasi di dalam SIMT ITB No. SI Badan Kerja Tanggung Jawab 1. SILOG UPT Logistik Melaksanakan kegiatan pengadaan,

penyimpanan, pengawasan, pengelolaan, distribusi barang/ jasa sesuai dengan kebutuhan unit-unit kerja di ITB

2. SI-X Direktorat Pendidikan Memelihara data mahasiswa, pemrosesan transkrip, verifikasi pendaftaran, penjadwalan dan pendaftaran kelas, pendaftaran wisudawan, dan pelayanan lainnya terkait proses pendidikan di ITB

3. SISKEU Direktorat Keuangan Menyediakan laporan keuangan sebagai alat pertanggungjawaban dan pengambilan keputusan

4. SIMA Biro Sarana Prasarana Memberikan pelayanan terkait pengadaan, pemeliharaan, pengelolaan sarana dan prasana berhubungan dengan proses perkuliahan, layanan kebersihan, transortasi, dan utilitas di ITB

5. HR-SID Biro Kepegawaian Bertanggung jawab mengenai masalah sumber daya manusia di ITB, termasuk masalah kontrol kualitas, pelayanan pegawai, penggajian, dan lain sebagainya

6. SISPRAN Biro Perencanaan Menangani masalah rencana kerja dan anggaran kerja ITB

7. SIMAWA Biro Kemahasiswaaan Bertanggung jawab di lingkungan kegiatan mahasiswa di bidang non kurikules, pengembangan karakter, kesejahteraan, dan komunitas

8. SIPPM Lembaga Penelitian dan Pengabdian Masyarakat

Berperan sebagai mediator yang mengkoordinasikan penelitian kegiatan pengembangan ilmu pengetahuan teknologi dan seni untuk kepentingan masyarakat.

9. SI sekolah/ fakultas

Unit Kerja Sekolah/ Fakultas

Memfasilitasi layanan administratif di tingkat sekolah/ fakultas, menjembatani kebutuhan data dan informasi dari tingkat sekolah/ fakultas ke ITB.

III-3

Sebelum SIMT ITB diimplementasikan, lalu lintas pertukaran data antar sistem

informasi di ITB dapat dikatakan tumpang tindih dan tidak efisien, seperti yang dapat

dilihat pada Gambar 5. Terlihat bahwa beban kerja (work load) bagian unit kerja

administratif di Sekolah/ Fakultas dalam lalu lintas data sangat tinggi. Dari gambar

tersebut juga bisa disimpulkan terjadi permintaan data yang sejenis dan berulang-

ulang dari berbagai macam pihak kepada bagian unit kerja administratif di Sekolah/

Fakultas, hal ini dapat dihindari jika terdapat sebuah portal yang menangani

permintaan dan translasi data.

Gambar 6 memetakan lalu lintas data yang terjadi setelah pengimplementasian

SIMT ITB. SIMT ITB akan berperan sebagai sebuah portal yang memfasilitasi

permintaan data antar elemen di ITB dan mengelola kewenangan setiap elemen

terhadap data-data tersebut. Dengan demikian, tidak terjadi beban kerja berlebih pada

sistem informasi (karena banyak terjadi permintaan translasi data dari berbagai sisi).

III-4

Gambar 5 Pertukaran data antar unit kerja di ITB

3.2 Analisis Risiko

Analisis risiko yang akan dilakukan bertujuan untuk menentukan apa saja

bencana yang mungkin mengancam SIMT ITB berikut dengan sebesar apa

kemungkinan kerusakan yang dapat ditimbulkan oleh bencana-bencana tersebut.

Langkah ini juga penting untuk memberikan gambaran tingkat kebutuhan Sistem

Informasi Manajemen Terintegrasi ITB akan Disaster Recovery Plan.

Analisis risiko akan dilakukan dengan memandang sistem dari berbagai macam

sudut pandang yang berbeda. Hal ini dilakukan untuk mendapatkan analisis risiko

yang menyeluruh. Sudut pandang yang akan digunakan antara lain adalah sudut

pandang teknis, lokasi dan sosial.

III-5

Gambar 6 Lalu lintas data setelah diimplementasikannya SITM ITB

3.2.1 Analisis Risiko dari Segi Teknis Seperti yang sudah dijelaskan sebelumnya, Sistem Informasi Manajemen

Terintegrasi ITB merupakan sistem informasi yang melibatkan berbagai macam

sistem informasi di ITB. Sistem informasi-sistem informasi ini dihubungkan dengan

menggunakan arsitektur client/server berbasis web. Web service akan terkoneksi

dengan basis data masing-masing sistem informasi melalui jaringan intranet ITB.

Jaringan intranet yang sama juga menghubungkan antar muka sistem informasi-sistem

III-6

informasi tersebut dengan pengguna, karena itu ketersediaan jaringan intranet ITB

adalah mutlak untuk SIMT ITB dapat berjalan dengan baik. Analisis risiko dari segi

teknis akan berdasar pada hal-hal teknis apa saja yang dapat mengakibatkan

terjadinya gangguan pada perangkat keras, perangkat lunak, dan data yang terlibat

dalam arsitektur tersebut.

3.2.1.1 Kerusakan Perangkat Keras

3.2.1.1.1 Kerusakan Alat

Jaringan intranet ITB, seperti jaringan intranet pada umumnya, memiliki

komponen-komponen seperti server, router, switch, gateway, dan lainnya. Agar

jaringan dapat berjalan dengan baik, keseluruhan komponen tersebut harus dalam

keadaan bekerja. Jika satu atau lebih komponen tersebut tidak tersedia, misalnya

karena rusak, kinerja jaringan akan terpengaruh secara langsung. Untuk menghindari

kelumpuhan jaringan karena hal semacam ini, umumnya jaringan memiliki lebih dari

satu buah untuk masing-masing komponen tersebut. Router misalnya, ITB memiliki

tiga buah router utama yang berfungsi sebagai simpul-simpul jaringan, terletak di

gedung PAU, gedung Labtek V, dan gedung Labtek VIII.. Ketiga router ini

diletakkan di tempat yang berbeda-beda untuk menghindari kelumpuhan secara

bersamaan.

Kerusakan alat adalah salah satu gangguan teknis yang paling umum terjadi,

karena itu hal ini perlu untuk diperhatikan. Waktu kelumpuhan dapat ditekan jika saat

terjadi gangguan, sudah dimiliki nomor atau alamat kontak personel yang dapat

memperbaikinya, supplier yang dapat menyediakan alat yang sesuai dengan cepat dan

terjamin ketersediaannya, dan lain sebagainya yang termasuk dalam Disaster

Recovery Plan.

3.2.1.1.2 Ketiadaan Daya Bagaimanapun juga, kelumpuhan tidak dapat dihindari dalam beberapa kasus.

Ketiadaan daya misalnya, akan melumpuhkan jaringan secara total. Hal ini tentunya

mengakibatkan SIMT ITB tidak dapat menjalankan fungsinya. Ketiadaan daya dapat

diakibatkan oleh berbagai macam hal, namun yang paling umum adalah oleh

pemadaman listrik dari pihak PLN. Kota Bandung sendiri tercatat cukup sering

mengalami pemadaman listrik, puncaknya adalah pada bulan Mei sampai Juli tahun

III-7

2008 sebanyak 112 kali di berbagai daerah yang berbeda (berdasarkan hasil survey

JCC)

3.2.1.2 Kerusakan Perangkat Lunak dan Data Perangkat lunak di sini mengacu pada masing-masing sistem informasi yang

menyusun SIMT ITB. Termasuk di dalamnya tampilan antar muka, modul-modul

pengolah data, dan modul-modul koneksi. Tidak seperti perangkat keras yang dapat

diperbaiki ataupun digantikan dengan perangkat yang baru dengan cepat jika rusak,

perangkat lunak memiliki proses perbaikan dan instalasi yang cukup memakan waktu

dan relatif lebih rumit.

Kerusakan perangkat lunak sangat mungkin terjadi, misalnya saat dilakukan

upgrade dari satu versi ke versi yang lebih baru, umumnya dengan tujuan

menyesuaikan sistem informasi dengan perubahan yang terjadi di dunia nyata,

meningkatkan performa, mengganti tampilan dengan yang lebih baik, dan lain

sebagainya. Instalasi perangkat lunak baru, baik seluruhnya maupun modular, tidak

akan pernah lepas dari proses debug dan penyesuaiaan dengan modul-modul lain.

Walaupun umumnya perbaikan tidak dilakukan langsung pada server,

melainkan pada repository sementara dulu, dan baru kemudian dipindahkan ke server

setelah melalui serangkaian tes, namun tetap tidak menutup kemungkinan terdapat

bug yang baru ditemukan kemudian. Pada fase inilah, perangkat lunak menjadi rentan

akan kesalahan operasi. Kesalahan pada perangkat lunak juga dapat mempengaruhi

data yang tersimpan, dan mengakibatkan kerusakan data.

3.2.1.3 Faktor Manusia Selain hal-hal yang telah dijabarkan di atas, masih terdapat faktor kesalahan

manusia yang dapat mengganggu operasional SIMT ITB. Misalnya kesalahan pada

saat melakukan konfigurasi server, tidak sengaja merestart router, dan hal-hal lain

yang mungkin tidak diperhitungkan sebelumnya. Demikian juga dengan faktor

keamanan jaringan. Selalu terdapat kemungkinan akan adanya serangan dari luar,

seperti defacing, manipulasi (menghapus, menambahkan, maupun mengubah) data,

pengalihan rute jaringan, dan berbagai macam jenis serangan lainnya. Tidak hanya

serangan melalui jaringan, serangan langsung sepeti pencurian ataupun perusakan alat

juga bukan hal yang baru lagi. Karena itu, faktor manusia layak diperhitungkan

sebagai potensi gangguan.

III-8

Dengan ancaman-ancaman yang telah disebutkan di atas, adalah tidak

mungkin untuk mengatakan SIMT ITB memiliki reliabilitas 100% ditinjau dari segi

teknis.

3.2.2 Analisis Risiko dari Segi Lokasi Server dan basis data Sistem Informasi Manajemen Terintegrasi ITB terletak

di berbagai lokasi di ITB dan sekitarnya. Server web service yang digunakan berada

di ruang server Labtek V ITB, sedangkan server LDAP yang menangani Single Sign

On User untuk manajemen pengguna sistem berada di PAU ITB. Basis data masing-

masing Sistem Informasi dimiliki oleh badan kerja terkait sistem informasi tersebut,

dan karenanya berada di berbagai lokasi di ITB dan sekitarnya. Karena berada di

lingkungan ITB, analisis risiko dari segi lokasi akan menggunakan ITB sebagai acuan

lokasi

3.2.2.1 Bencana Banjir ITB berada di kota Bandung daerah utara yang secara geografis cukup baik

karena sangat jarang terkena bencana alam. Banjir misalnya, karena lokasi yang

relatif cukup tinggi dibandingkan dengan daerah sekitarnya, ITB hampir tidak

mungkin mengalami bencana banjir yang membahayakan. Namun kemungkinan

terjadinya banjir tetap ada, walaupun mungkin bukan merupakan banjir besar. Asumsi

ini didasarkan pada observasi keadaan daerah Dago, Sumur Bandung, Taman Sari dan

Siliwangi saat terjadi hujan deras yang berlangsung cukup lama. Jalan raya dengan

cepat tergenang dan mengalir ke bawah dengan deras, umumnya disebabkan karena

meluapnya saluran air sepanjang jalan raya tersebut. Sifat bencana banjir yang cukup

merusak, baik data maupun fisik, dan tidak dapat ditanggulangi dengan cepat jika

sudah terjadi, merupakan alasan mengapa bencana banjir akan diperhitungkan dalam

pembuatan Disaster Recovery Plan ini.

3.2.2.2 Bencana Gempa Untuk kasus bencana gempa, Kota Bandung memiliki lokasi yang cukup unik.

Bandung mungkin termasuk kota yang jarang dilanda gempa, yaitu lima kali dalam

kisaran tiga tahun terakhir, 2005 sampai dengan 2008 (Research Center for

Geotechnology LIPI). Dari kelima gempa tersebut, empat gempa yang terjadi hanya

III-9

berkekuatan di bawah 3,5 skala Richter, yaitu tergolong gempa kecil yang tidak

membahayakan. Satu yang cukup terasa adalah gempa pada bulan April 2005.

Namun Bandung sebenarnya merupakan daerah yang memiliki risiko gempa

besar cukup tinggi. Hal ini dikarenakan lokasi Bandung berada di atas lempeng

patahan Cimandiri-Lembang, yaitu salah satu patahan terbesar di Indonesia. Patahan

ini terdiri dari lima segmen batuan yang melintang di sepanjang Pelabuhan Ratu

sampai Maribaya dan menyimpul di daerah Bandung-Cimahi. Jika satu saja dari

kelima segmen tersebut bergerak, gempa yang ditimbulkan di daerah Bandung-

Cimahi akan mencapai kekuatan paling tidak 7 skala Richter. Gempa dengan skala

tersebut tergolong besar dan sangat merusak, cukup untuk meretakkan aspal dan

mengguncang gedung-gedung tinggi.

Pergeseran patahan Cimandiri-Lembang yang satu dengan yang lain memiliki

interval waktu cukup panjang, mencapai berpuluh-puluh tahun. Gempa di atas 7 skala

Richter yang pernah menggucang Kota Bandung tercatat terjadi pada tanggal 5

Januari 1699, 10 Oktober 1834, 28 Maret 1879, dan 14 Januari 1900. Kealpaan gempa

besar selama seratus tahun belakangan, diramalkan akan menjadikan gempa

Cimandiri-Lembang berikutnya lebih kuat dari yang sebelum-sebelumnya.

Karena faktor-faktor tersebut, untuk pembangunan Disaster Recovery Plan ini,

bencana gempa akan turut disertakan sebagai salah satu ancaman potensial terhadap

SIMT ITB.

3.2.2.3 Bencana Gunung Meletus Propinsi Jawa Barat memiliki paling tidak tujuh buah gunung berapi aktif.

Ketujuh gunung tersebut adalah: Gunung Salak, Gunung Gede, Gunung Tangkuban

Perahu, Gunung Guntur, Gunung Papandayang, Gunung Galunggung, dan Gunung

Ciremai. Tujuh buah gunung tersebut sampai sekarang masih berstatus normal aktif,

yaitu dapat meletus kapanpun. Gunung berapi dapat menimbulkan berbagai macam

bahaya sekaligus jika meletus, diantaranya adalah, aliran lava, aliran lumpur, gempa

akibat letusan, hujan abu, dan gas beracun.

Gunung berapi paling dekat dengan Bandung adalah Gunung Tangkuban

Perahu, yang terletak hanya 28 km di utara Kota Bandung. Setelah tahun 1990,

tercatat sudah dua kali terjadi aktivitas yang dapat dikategorikan membahayakan

(gempa dengan kekuatan menengah, gas beracun, dan hujan abu), yaitu pada

September 1992 dan April 2005. Efek dari kedua insiden tersebut memang hanya

III-10

mempengaruhi kawasan utara Bandung, namun bukan berarti di masa depan tidak

akan terjadi aktivitas yang skalanya lebih besar lagi yang bahkan mungkin akan

mempengaruhi lingkungan ITB.

3.2.2.4 Bencana Kebakaran Bencana kebakaran merupakan salah satu yang dianggap paling merusak. Jika

terjadi kebakaran, tidak hanya terdapat kemungkinan kerusakan alat dan jaringan

melainkan juga kehilangan data. Kebakaran dapat terjadi hampir dimana saja, ruangan

server yang dipadati dengan kabel dan peralatan elektronik tentunya tidak akan luput

dari kemungkinan terjadinya kebakaran.

3.2.2.5 Kerusakan Gedung Hampir seluruh perangkat pendukung SIMT ITB diletakkan di dalam ruangan,

karena itu, faktor kerusakan gedung juga harus diperhitungkan sebagai salah satu

potensi bencana. Hal-hal seperti kebocoran pada ruang server atau mungkin gedung

roboh dapat mengancam kesinambungan kerja SIMT ITB. Terutama jika mengingat

kebanyakan bangunan di ITB merupakan bangunan yang cukup berumur ditinjau dari

segi konstruksi.

3.2.3 Analisis Risiko dari Segi Sosial ITB merupakan sebuah institusi pendidikan yang terdiri dari berbagai elemen

dalam lingkungan sosialnya, seperti mahasiswa, dosen pengajar, pegawai, rektorat,

dan masyarakat sekitar. Elemen-elemen ini saling terkait dan saling membutuhkan

dalam menjalankan fungsinya dan mencapai tujuannya masing-masing. Karena itu,

ITB memiliki sistem untuk mengatur bagaimana setiap elemen tersebut berinteraksi.

Namun sebaik apapun suatu sistem dirancang, bukan berarti dalam penerapannya

akan selalu berjalan sesuai dengan yang diinginkan. Sekecil apapun, selalu terdapat

kemungkinan terjadi sesuatu yang mengganggu berjalannya sistem tersebut.

Dalam kasus sistem sosial ITB sebagai lingkungan kampus juga terdapat

kemungkinan terjadinya hal-hal yang dapat berpotensi sebagai ancaman atas

berjalannya SIMT ITB. Misalnya unjuk rasa mahasiswa, pemogokan pegawai, dan

aksi protes masyarakat. Hal-hal tersebut dapat mengganggu berjalannya SIMT ITB

baik secara langsung maupun tidak langsung.

Gangguan secara langsung yang dapat terjadi misalnya seperti aksi perusakan

sarana dan peralatan pendukung SIMT ITB, sedangkan gangguan secara tidak

III-11

langsung misalnya adalah pemogokan administrator atau tenaga kerja lain yang terkait

SIMT ITB. Gangguan dari segi lingkungan sosial seperti itu juga dapat menimbulkan

gan ancaman yang sama.

3.3 Analisis Tingkat Kebutuhan Setelah memahami betul ancaman-ancaman apa saja yang mungkin terjadi dan

memiliki potensi untuk mengganggu SIMT ITB, akan dilakukan analisis untuk

mengetahui tingkat kebutuhan SIMT ITB terhadap sebuah Disaster Recovery Plan.

Hal ini dilakukan dengan cara mempertimbangkan tingkat ketergantungan ITB

kepada SIMT ITB dari waktu ke waktu.

Seperti yang sudah dijelaskan pada bab sebelumnya, Disaster Recovery Plan

bertujuan untuk meminimalisir dampak gangguan yang terjadi terhadap

kesinambungan berjalannya sebuah badan bisnis. Jika ITB dipandang sebagai sebuah

badan organisasi, dapat dikatakan bahwa tujuan utama ITB adalah menjalankan

proses edukasi, kegiatan-kegiatan non akademis yang dilakukan oleh ITB seluruhnya

adalah sebagai penunjang berjalannya kegiatan akademis ITB. Dalam sub bab ini

akan ditinjau sejauh apa SIMT ITB berperan dalam mendukung ITB menjalankan

kegiatan-kegiatan akademik dan kegiatan-kegiatan penunjangnya.

Kegiatan akademis yang dilakukan ITB dapat dikatakan berpola serupa tiap

tahunnya, namun jika dilihat lebih jauh dalam kaitannya dengan sistem informasi

yang mendukung dengan kegiatan-kegiatan tersebut, akan terdapat beberapa interval

waktu berbeda sesuai dengan sistem informasi apa yang menjadi prioritas up and

running. Untuk mengetahui lebih jelas mengenai hal ini, dilakukan wawancara dan

observasi mengenai kegiatan akademik yang berjalan pada setiap interval waktu

berikut sistem informasi yang menjadi prioritas. Tabel 3 Deskripsi kegiatan akademis per titik waktu No. Interval Waktu Deskripsi Kegiatan SI Terkait 1. Penerimaan

Mahasiswa Baru 1. Pendaftaran peserta USM 2. Penyelenggaraan USM 3. Pendaftaran ulang mahasiswa

baru 4. Pembayaran biaya pendidikan

SI-X SISKEU

2. Masa Perkuliahan 1. Pengaturan jadwal kelas dan mata kuliah

2. Konfirmasi pengambilan kelas 3. Pembayaran biaya pendidikan 4. Pendaftaran ulang mahasiswa

lama

SI-X SISKEU SIMA SI sekolah/ fakultas

III-12

5. Koreksi rencana studi 6. Masa perkuliahan 7. Pemrosesan nilai kuliah

3. Masa Liburan Jika diselenggarakan semester pendek, maka kegiatan akademik yang berjalan tidak jauh berbeda dengan pada masa perkuliahan.

SI-X SISKEU SIMA SI sekolah/ fakultas

Seperti yang sudah disebutkan sebelumnya, ITB juga memiliki kegiatan-

kegiatan pendukung yang bersifat non-akademis. Kegiatan-kegiatan tersebut

merupakan kegiatan administratif yang bersifat lebih rutin dan teratur, seperti

penggajian pegawai, inventarisasi logistik, rekapitulasi laba rugi, dan lain sebagainya.

Tanpa kegiatan-kegiatan pendukung semacam itu, tidak mungkin ITB dapat

menjalankan fungsi utamanya sebagai institusi pendidikan. Seperti halnya kegiatan-

kegiatan akademis, kegiatan-kegiatan pendukung tersebut juga bergantung pada

sistem informasi (seperti yang dapat dilihat pada Tabel 1).

Jika satu atau lebih sistem informasi di atas tidak berfungsi , atau jika terjadi

gangguan dalam pertukaran data antar sistem informasi, maka kegiatan yang

bersangkutan akan terganggu, atau bahkan tidak dapat berjalan sama sekali. Karena

setiap kegiatan di atas merupakan bagian penting dari ITB, gangguan pada kegiatan-

kegiatan tersebut tentunya akan mengganggu ITB dalam beroperasi. Dengan

demikian, dapat dikatakan bahwa SIMT ITB merupakan bagian penting dari

berjalannya proses bisnis ITB.

3.4 Hasil Analisis Dari penjabaran di atas, dapat disimpulkan bahwa terdapat banyak ancaman

yang dapat berubah menjadi gangguan bagi SIMT ITB. Selain itu, dapat diketahui

bahwa ITB memiliki tingkat ketergantungan yang cukup besar terhadap SIMT ITB,

terutama pada waktu-waktu tertentu. dengan berbagai macam ancaman yang dapat

berubah menjadi gangguan kapan saja. Mempertimbangkan dua hal di atas,

disimpulkan bahwa ITB membutuhkan sebuah Disaster Recovery Plan untuk SIMT

ITB. Dengan Disaster Recovery Plan yang baik, jika suatu gangguan bencana terjadi,

SIMT ITB dapat kembali beroperasi secepat mungkin sehingga ITB hanya akan

mengalami kehilangan/ kerugian minimal.

Berikut ini adalah beberapa kebutuhan yang ingin dipenuhi dengan Disaster

Recovery Plan yang akan dibangun:

III-13

1. Disaster Recovery Plan akan menangani paling tidak ancaman-ancaman

bencana yang sudah dijabarkan pada analisis resiko.

2. Disaster Recovery Plan yang cost effective, sedapat mungkin

menggunakan apa yang sudah dimiliki oleh ITB (untuk tempat, teknologi,

tenaga manusia, dan aset lain yang mungkin dibutuhkan).

3. Disaster Recovery Plan yang akan dibangun harus didokumentasikan

dengan baik dan mudah dipahami.

Disaster Recovery Plan harus mudah diperbaharui/ disesuaikan jika terjadi

perubahan pada SIMT ITB.

IV-1

BAB IV PERANCANGAN

4.1 Tahap Pembangunan Tahapan pembangunan sebuah Disaster Recovery Plan tidak selalu sama,

karena sangat bergantung pada kebutuhan dan tujuan pembuatannya. Dalam

pembangunan Disaster Recovery Plan untuk SIMT ITB, tahapan yang akan dilakukan

adalah sebagai berikut:

1. Risk assessment

Merupakan tahap identifikasi ancaman-ancaman yang mungkin

terjadi, baik yang berasal dari dalam, maupun dari luar. Bencana yang

dianalisa antara lain adalah bencana alam, bencana kegagalan teknis,

maupun ancaman-ancaman faktor manusia. Pengukuran akan

dilakukan secara kualitatif dengan pendekatan scoring.

2. Priority assessment

Tahap dilakukannya pembobotan setiap elemen dari berbagai

aspek berdasarkan skala prioritasnya sebagai pendukung sistem. Aspek

yang akan ditinjau adalah aspek arsitektur, proses, dan lokasi.

Pengukuran prioritas juga akan dilakukan dengan metode scoring

secara kualitatif.

3. Recovery strategy selection

Hasil yang didapatkan dari tahap risk assessment dan priority

assessment kemudian akan digunakan sebagai masukan untuk

menentukan strategi pemulihan seperti apa yang sebaiknya disusun.

Strategi pemulihan akan mencakup isu seperti lokasi cadangan dan

metode pemulihan yang akan dilakukan.

4. Plan documenting

Tahap penyusunan dokumen Disaster Recovery Plan, dimana

setiap hasil yang didapatkan dari tahapan-tahapan sebelumnya

dituangkan dalam suatu dokumentasi yang terstruktur. Dengan

IV-2

dokumentasi yang baik, diharapkan dapat lebih mudah dan cepat untuk

melakukan langkah yang perlu diambil saat terjadi ancaman.

4.2 Risk Assessment Tahap pertama dari pembangunan Disaster Recovery Plan adalah Risk

Assessment. Pada tahap awal ini, bencana-bencana yang sudah dianalisis pada BAB

III akan ditentukan nilai ancamnya terhadap SIMT ITB. Setiap bencana memiliki

atribut-atribut yang dapat diboboti untuk menentukan nilai ancam, atribut bencana

yang akan digunakan dalam pembahasan ini adalah Likelihood, Restoration Time,

Predictability.

Likelihood merupakan nilai kekerapan terjadinya ancaman bencana tersebut

dalam suatu kurun waktu yang terukur. Nilai Likelihood harus nyata, yaitu

merupakan hasil dari yang sudah terjadi (record) dan bukan merupakan ramalan

(prediction).

Restoration Time merupakan nilai panjangnya jangka waktu yang dibutuhkan

oleh sistem untuk kembali pulih (beroperasi kembali) jika suatu gangguan terjadi.

Nilai Restoration Time dapat berasal dari hasil observasi yang sudah pernah terjadi

(record) atau berdasarkan standar operasional yang disepakati (contohnya, terdapat

kontrak dengan pemasok mengenai jangka waktu dari pemesanan ke penyediaan alat,

dan lain sebagainya).

Predictability merupakan nilai dapat diprediksi atau tidaknya suatu bencana.

Hal ini penting karena semakin panjang jangka waktu suatu bencana dapat diprediksi,

semakin banyak tindakan yang dapat dilakukan untuk menghindarinya, sehingga

semakin sedikit kerusakan/ kerugian yang diderita. Nilai Predictability tidak dapat

ditentukan dengan skala kuantitatif karena tidak memiliki nilai ukuran yang pasti.

Pembobotan nilai Likelihood, Restoration Time, dan Predictability dalam

analisis ini dilakukan dengan metode wawancara, studi dokumentasi, dan observasi.

Wawancara yang dilakukan antara lain dengan pihak keamanan ITB, Biro Sarana dan

Prasarana ITB, Unit Sumber Daya Informasi ITB, Pusat Vulkanologi dan Mitigasi

Bencana Geologi (Jl. Diponegoro, Bandung).

Pembobotan atribut bencana berdasarkan wawancara, observasi, dan studi

dokumentasi yang sudah dilakukan dapat dilihat pada Tabel 2 di bawah ini.

IV-3

Tabel 4 Tabel atribut ancaman bencana

No. Ancaman Likelihood (0-10)

Restoration Time (0-10)

Predictability (0-3) Score

1. Kerusakan alat 4 5 3 60 2. Ketiadaan daya 6 5 2 60 3. Kerusakan perangkat

lunak/ data 4 5 1 20

4. Kesalahan Manusia 5 3 3 45 5. Serangan jaringan/data 1 3 3 9 6. Pencurian/perusakan alat 3 5 3 45 7. Kerusakan gedung 3 5 2 30 8. Banjir 1 6 2 12 9. Gempa (ringan) 4 2 1 4 10. Gempa (besar) 1 7 1 7 11 Gunung meletus 1 6 2 12 12. Kebakaran 1 6 3 18 13. Bencana sosial 1 5 2 10

1. Likelihood (0-10), nilai yang semakin tinggi pada kolom ini

menunjukkan bahwa ancaman tersebut semakin tinggi

kemungkinan terjadinya

2. Restoration time (0-10), nilai yang semakin tinggi pada kolom ini

menunjukkan semakin lamanya waktu yang dibutuhkan untuk

mengembalikan sistem beroperasi lagi seperti semula setelah

gangguan terjadi

3. Predictability (0-3), nilai yang semakin tinggi pada kolom ini

menunjukkan semakin sulitnya memprediksi datangnya bencana

tersebut, sehingga semakin sedikit waktu dan usaha yang dapat

dialokasikan untuk menghindari kerugian karenanya.

4. Score, merupakan hasil perkalian dari nilai pada kolom-kolom yang

berada di sebelah kirinya, nilai pada kolom ini merepresentasikan

skala ancaman bencana tersebut terhadap SIMT ITB.

Rician keterangan nilai pada Tabel 2 dapat dilihat pada Tabel 3.

Tabel 5 Rincian penilaian atribut risiko

Kolom Nilai Likelihood Restoration Time Predictability

0 Tidak mungkin terjadi Tidak ada Dapat diprediksi dengan

IV-4

Kolom Nilai Likelihood Restoration Time Predictability

pasti bahkan sebelum bencana terjadi

1 Terjadi > 5 tahun sekali 1-4 menit Prediksi dapat dilakukan sebelum bencana terjadi, namun dengan tingkat kepercayaan yang lemah

2 Terjadi 2 - 5 tahun sekali 5menit-1 jam Prediksi hanya dapat dilakukan setelah terjadi tanda-tanda awal bencana

3 Terjadi 1 - 2 tahun sekali 1-6 jam Tidak dapat diprediksi 4 Terjadi 6 - 12 bulan

sekali 6-12 jam

5 Terjadi 2 – 6 bulan sekali

12-24 jam

6 Terjadi 1- 2 bulan sekali 1-4 hari 7 Terjadi 2 - 4 minggu

sekali 5-9 hari

8 Terjadi 1 - 2 minggu sekali

10-14 hari

9 Terjadi 1 - 7 hari sekali 15-30 hari 10 Terjadi beberapa kali

dalam 24 jam Membutuhkan waktu > 1 bulan

Dengan melihat hasil penilaian pada Tabel 2, dapat disimpulkan bencana

mana yang memiliki tingkat ancaman tinggi sehingga patut diwaspadai, dan mana

yang dapat diletakkan di prioritas yang lebih rendah. Untuk mempermudah, di bawah

ini adalah daftar bencana terurut sesuai dengan tingkat ancaman yang dimilikinya.

Tabel 6 Bencana terurut tingkat ancaman

No. Bencana Likelihood (0-10)

Restoration Time (0-10)

Predictability (0-3) Score

1. Kerusakan alat 4 5 3 60 2. Ketiadaan daya 6 5 2 60 3. Pencurian/perusakan alat 3 5 3 45 4. Kesalahan Manusia 5 3 3 45 5. Kerusakan gedung 3 5 2 30 6. Kerusakan perangkat

lunak/ data 5 4 1 20

7. Kebakaran 1 6 3 18 8. Banjir 1 6 2 12 9. Gunung meletus 1 6 2 12

IV-5

No. Bencana Likelihood (0-10)

Restoration Time (0-10)

Predictability (0-3) Score

10. Bencana sosial 1 5 2 10 11. Serangan kemanan 1 3 3 9 12. Gempa (besar) 1 7 1 7 13. Gempa (ringan) 2 2 1 4

4.3 Priority Assessment

4.3.1 Priority Assessment Segi Arsitektur Dari segi arsitektur, Sistem Informasi Manajemen Terintegrasi ITB tersusun

atas berbagai elemen penyusun, yaitu: perangkat keras, perangkat lunak, jaringan, dan

data. Jika suatu bencana terjadi dan mengakibatkan elemen-elemen tersebut terancam,

yang manakah yang sebaiknya diutamakan dalam usaha penyelamatan/ pemulihan

kembali? Untuk mengetahui urutan prioritas elemen-elemen tersebut, tentunya

terdapat beberapa atribut yang harus ditinjau. Atribut-atribut tersebut antara lain:

necessity, recoverability, dan replaceability.

Necessity merupakan derajat seberapa tinggi elemen tersebut diperlukan agar

sebuah sistem dapat berfungsi. Jika sistem tetap dapat berfungsi, atau hanya sedikit

terganggu dengan ketiadaan suatu elemen, maka elemet tersebut dikatakan memiliki

derajat necessity yang rendah. Sebaliknya jika kinerja sistem terhenti total, atau tidak

dapat beroperasi karena ketiadaan suatu elemen, maka elemen tersebut dikatakan

memiliki derajat necessity yang tinggi. Dalam kasus SIMT ITB dan keempat elemen

arsitektur yang sudah disebutkan di atas yaitu perangkat keras, perangkat lunak,

jaringan, dan data, sangatlah jelas bahwa keempat elemen tersebut seluruhnya

memiliki derajat necessity yang setara, yaitu seluruhnya sangat tinggi. Tidak mungkin

SIMT ITB dapat beroperasi jika salah satu dari keempat elemen tersebut tidak ada.

Karena hal itu, derajat necessity akan diabaikan dalam pembahasan mengenai analisis

prioritas segi arsitektur.

Recoverability merupakan derajat mudah tidaknya suatu elemen diperbaiki

jika terjadi kerusakan padanya saat terjadi bencana. Karena pada tabel prioritas

nantinya nilai-nilai dari atribut-atribut akan dikalikan untuk mendapatkan bobot

prioritas, maka elemen yang dapat dengan mudah diperbaiki dikatakan memiliki

derajat recoverability yang rendah, sedangkan elemen yang sulit diperbaiki akan

mendapatkan nilai recoverability yang tinggi (terbalik).

IV-6

Replaceability merupakan derajat mudah tidaknya menggantikan hal yang

rusak tersebut dengan hal yang lain untuk menjalankan fungsi yang sama. Contoh,

mudah tidaknya suatu sistem operasi yang rusak digantikan dengan sistem operasi

lainnya. Karena pada tabel prioritas nantinya nilai-nilai dari atribut-atribut akan

dikalikan untuk mendapatkan bobot prioritas, maka elemen yang dapat dengan mudah

digantikan dikatakan memiliki derajat replaceability yang rendah, sedangkan elemen

yang sulit digantikan akan mendapatkan nilai replaceability yang tinggi (terbalik).

Tabel 7 Skala atribut prioritas

Nilai Necessity Recoverability Replaceability 1 Sistem tetap dapat

berfungsi sempurna walaupun elemen tidak ada.

Elemen dapat dengan mudah diperbaiki, tenaga ahli sangat mudah ditemui, dengan waktu perbaikan sangat singkat.

Elemen dapat digantikan dengan mudah tanpa biaya maupun usaha yang berarti

2 Sistem mengalami hambatan/ delay dalam menjalankan fungsinya jika elemen tidak ada.

Elemen dapat dengan mudah diperbaiki, tenaga ahli cukup mudah ditemui, namun dengan waktu perbaikan yang berdampak pada sistem.

Elemen dapat digantikan dengan yang lain namun tetap membutuhkan biaya dan atau usaha yang cukup besar.

3 Sistem hanya dapat menjalankan fungsi-fungsi vital jika elemen tidak ada.

Elemen cukup sulit diperbaiki, tenaga ahli cukup sulit ditemui, dan dengan waktu perbaikan yang dapat mengganggu sistem.

Elemen dapat digantikan dengan yang lain dengan biaya dan atau usaha yang besar.

4 Sistem hanya dapat menjalankan fungsi-fungsi non vital jika elemen tidak ada.

Elemen sangat sulit diperbaiki, tenaga ahli sangat sulit ditemui, dan membutuhkan waktu perbaikan yang sangat panjang.

Elemen dapat digantikan dengan yang lain, namun membutuhkan biaya dan atau usaha yang sangat besar.

5 Sistem tidak dapat berfungsi sama sekali jika elemen tidak ada.

Elemen hampir tidak mungkin untuk diperbaiki

Elemen bersifat unik dan tidak dapat digantikan dengan apapun.

IV-7

4.3.1.1 Perangkat Keras SIMT ITB tidak dapat dipisahkan dari berbagai perangkat keras yang

memungkinkan SIMT ITB menjalankan fungsinya. Perangkat keras yang menyusun

SIMT ITB diantaranya adalah: router, switch, gateway, server.

1. Necessity

Seperti yang sudah dijelaskan di atas, perangkat keras memiliki nilai necessity

sangat tinggi karena tanpa salah satu perangkat lunak penyusun jaringan,

SIMT ITB tidak akan dapat beroperasi (nilai necessity 5).

2. Recoverability

Perangkat keras tergolong cukup mudah diperbaiki jika mengalami kerusakan.

Untuk memperbaikinya pun terdapat tenaga ahli dalam jumlah cukup banyak

dan mudah ditemui di daerah sekitar ITB. Begitu juga dengan suku cadang

yang mungkin diperlukan untuk memperbaikinya, walaupun mungkin

dibutuhkan waktu kirim dan waktu tunggu jika suku cadang tersebut harus

dipesan terlebih dahulu. Walaupun demikian, proses perbaikan dapat

memakan waktu cukup lama tergantung dari derajat kerusakan yang diderita

perangkat keras tersebut. Karena alasan-alasan tersebut, maka perangkat keras

memiliki nilai recoverability menengah (nilai recoverability 3).

3. Replaceability

Perangkat keras yang rusak hingga tidak dapat lagi diperbaiki, atau yang

memiliki cost perbaikan lebih mahal daripada cost perangkat keras pengganti,

dapat dengan mudah digantikan dengan perangkat keras lainnya. Supply

perangkat keras yang digunakan oleh SIMT ITB tergolong sangat mudah

ditemui di ITB dan wilayah sekitarnya (daerah Bandung).

Isu penggantian seperti instalasi, masalah kompabilitas, konfigurasi, dan lain

sebagainya juga dapat dikatakan sangat minim untuk perangkat keras. Karena

hal-hal tersebut, perangkat keras tergolong mudah untuk digantikan dengan

yang lainnya (nilai replaceability 2).

4.3.1.2 Perangkat Lunak Seperti yang sudah diketahui, SIMT ITB terdiri dari berbagai macam SI yang

mendukung berbagai macam proses bisnis ITB. Masing-masing SI tersebut memiliki

arsitektur yang berbeda-beda sesuai dengan kebutuhan dan proses pengembangan SI

IV-8

tersebut. Bagitu juga dengan sistem operasi yang digunakan, dan berbagai perangkat

lunak perantara lainnya.

1. Necessity

Perangkat lunak merupakan salah satu dari elemen vital penyusun SIMT ITB.

Tanpa perangkat lunak, SIMT ITB tidak akan dapat menjalankan fungsinya,

karena itu perangkat lunak memiliki nilai necessity yang sangat tinggi (nilai

necessity 5).

2. Recoverability

Perangkat lunak tergolong cukup sulit untuk diperbaiki, apalagi bila terdiri

dari berbagai sitem majemuk dengan arsitektur yang berbeda-beda. Tenaga

ahli yang berkemampuan memperbaiki perangkat lunak memang terdapat

dalam jumlah cukup banyak dan mudah ditemui di daerah sekitar ITB, namun

umumnya terdapat selang waktu untuk melakukan pembelajaran terhadap

perangkat lunak tersebut. Tenaga ahli yang benar-benar mengerti suatu

perangkat lunak yang spesifik umumnya mereka yang terlibat dalam proses

pengembangan/ pemeliharaan perangkat lunak tersebut, sehingga dapat

dikatakan cukup terbatas. Waktu dan usaha juga diperlukan untuk melakukan

serangkaian tes dan proses debug, baik pada repository maupun server. Karena

alasan-alasan tersebut, perangkat lunak dikatakan cukup sulit untuk diperbaiki

(nilai recoverability 3).

3. Replaceability

Mengganti suatu perangkat lunak yang satu dengan perangkat lunak yang lain

(misalnya diterapkannya SI atau ERP yang baru) merupakan proses yang

sangat rumit dan karenanya membutuhkan usawah, waktu dan biaya yang

sangat besar. Hal ini dikarenakan oleh banyaknya yang harus dikerjakan untuk

melakukan transisi tersebut, ditambah lagi dengan beragamnya isu yang harus

dipertimbangkan selama masa penyesuaian dengan perangkat lunak yang baru.

Karena hal-hal tersebut, dapat dikatakan bahwa perangkat lunak sangat sulit

untuk digantikan dengan yang baru (nilai replaceability 4).

4.3.1.3 Jaringan Jaringan adalah rangkaian perangkat keras dan perangkat lunak dalam

konfigurasi tertentu sehingga memungkinkan terjadinya komunikasi data antar elemen

penyusunnya.

IV-9

1. Necessity

Keberadaan perangkat keras dan perangkat lunak yang lengkap tidak akan

dapat memberikan pelayanan terhadap SIMT ITB jika tidak terhubungkan satu

dengan yang lainnya oleh jaringan. Jaringan berfungsi sebagai sarana lalu

lintas komunikasi data, karena SIMT ITB pada dasarnya adalah portal dalam

komukikasi data antar sistem informasi, maka keberadaan jaringan adalah

primer (nilai necessity 5).

2. Recoverability

Jika suatu jaringan mengalami gangguan di luar faktor kerusakan perangkat

keras dan atau perangkat lunak yang terlibat, maka kemungkinan besar

gangguan tersebut disebabkan oleh kesalahan pada konfigurasi/ pengaturan

jaringan. Berdasarkan penuturan admin-admin yang bertanggung jawab atas

jaringan di ITB, untuk mencari letak kesalahan dan melakukan langkah-

langkah perbaikan pada jaringan dengan skala seperti yang dimiliki ITB, akan

memakan waktu antara satu jam hingga satu hari tergantung gangguan yang

terjadi. Karena itu, jaringan memiliki nilai recoverabilty yang cukup rendah

(nilai recoverability 2).

3. Replaceability

Batas suatu jaringan dapat dikatakan ‘digantikan’ dengan jaringan lain

tidaklah sejelas seperti pada perangkat keras atau perangkat lunak. Beberapa

literatur menyatakan, suatu jaringan dikatakan berubah menjadi sebuah

jaringan yang berbeda, jika susunan topografinya berbeda. Dalam proses

perbaikan jaringan, sering kali dijumpai situasi dimana perubahan kecil pada

topografi jaringan harus dilakukan. Perubahan-perubahan kecil semacam ini

tidak akan dimasukkan sebagai faktor pertimbangan nilai replaceability. Yang

akan dipertimbangkan adalah penyusunan ulang sebagian besar atau seluruh

topografi jaringan.

Perubahan besar semacam itu membutuhkan usaha dan waktu yang tergolong

sangat besar, untuk itu nilai replaceability jaringan di ITB cukup tinggi (nilai

replaceability 4).

4.3.1.4 Data 1. Necessity

IV-10

Seperti halnya perangkat keras, perangkat lunak, dan jaringan, data juga

merupakan bagian vital dari SIMT ITB. Jika tidak terdapat data untuk diolah,

maka SIMT ITB tidak akan dapat menjalankan fungsinya, karena itu nilai

necessity data sangat tinggi (nilai necessity 5).

2. Recoverability

Data yang rusak sebagian masih mungkin dapat diperbaiki, walaupun

membutuhkan waktu, tenaga dan biaya yang cukup besar. Pendekatan yang

dapat dilakukan pun bermacam-macam sesuai dengan apa yang menjadi

penyebabnya. Di bawah ini merupakan data penyebab-penyebab utama

terjadinya kerusakan data berdasarkan hasil survey ONTRACK Data

Recovery Inc (1996-2000).

Tabel 8 Penyebab kerusakan data

No. Penyebab Kerusakan Data Frekuensi Kejadian 1. Hardware or system malfunction 44% 2. Human error 32% 3. Software program malfunction 4% 4. Viruses 7% 5. Natural disaster 3%

Untuk kerusakan data yang disebabkan oleh faktor fisik, dapat dilakukan

metode-metode seperti: RAID recovery method, disk imaging, dan lain

sebagainya.

Selain itu, juga terdapat metode logical untuk mengatasi kerusakan data yang

disebabkan oleh faktor kerusakan data secara logical seperti kehilangan daya

saat proses, kesalahan program dalam memanipulasi data, dan lain sebagainya.

Metode pemulihan data untuk kerusakan semacam ini misalnya seperti

consistency checking, data carving ataupun dengan menurunkannya dari data

lain yang masih dimiliki. Contoh, data mahasiswa yang lulus pada suatu

semester dapat diadakan kembali dengan meninjau data pembayaran uang

semester. Mahasiswa yang tidak lagi melakukan pembayaran dan bukan

merupakan mahasiswa yang dikeluarkan, adalah set mahasiswa yang sudah

lulus.

Metode-metode tersebut di atas tidak akan dibahas secara lebih mendetil pada

tugas akhir ini. Menggunakan metode manapun, tidak terdapat jaminan 100%

IV-11

data akan dapat diperbaiki. Hal ini tentunya akan mempengaruhi tingkat

kepercayaan dan kebenaran data. Usaha seperti pengecekan ulang data akan

memakan waktu dan biaya yang tinggi, sehingga. Karena itu, data dianggap

memiliki nilai recoverability yang tinggi (nilai recoverability 5).

3. Replaceability

Data bersifat unik dan tidak dapat digantikan dengan data lain. Jika suatu data

hilang, hal tersebut merupakan bentuk kerugian yang sangat besar karena tidak

dapat diperoleh kembali jika tidak terdapat salinan dari data itu. Karena

sifatnya yang unik dan tidak dapat digantikan tersebut, data memiliki nilai

replaceability yang sangat tinggi (nilai replaceability 5).

Hasil dari Priority Assessment segi arsitektur yang telah dijabarkan di atas

dapat dirangkum dalam bentuk tabel seperti yang dapat dilihat pada Tabel 7. Tabel 9 Hasil Priority Assessment segi arsitektur No. Elemen Necessity Recoverability Replaceability Priority Value 1. Perangkat keras 5 3 2 30 2. Perangkat lunak 5 3 4 60 3. Jaringan 5 2 4 40 4. Data 5 5 5 125

Berdasarkan nilai prioritas yang didapatkan pada Tabel 7, dapat diurutkan

bahwa prioritas elemen dari segi arsitektur pada SIMT ITB adalah sebagai berikut. Tabel 10 Prioritas segi arsitektur (terurut)

Prioritas Elemen Priority Value 1. Data 125 2. Perangkat lunak 60 3. Jaringan 40 4. Perangkat keras 30

4.3.2 Priority Assessment Segi Proses

Proses yang terkait dalam SIMT ITB sangatlah banyak dan rumit jika

dideskripsikan satu persatu secara mendetil. Untuk menjaga proses analisis tetap

berfokus pada SIMT ITB dan menjadikan pembahasan mudah dipahami, setiap sistem

informasi yang terlibat dalam SIMT ITB akan dianggap mewakili sebuah proses

tunggal sesuai dengan peran sistem informasi tersebut dalam fungsi operasi ITB.

IV-12

Seperti yang telah dijabarkan pada Tabel 2, SIMT ITB terdiri dari sembilan

sistem informasi, jika setiap sistem informasti tersebut dianggap mewakili suatu

proses tunggal, maka kurang lebih proses yang terdapat dalam SIMT ITB adalah

sebagai berikut:

Tabel 11 SI yang terlibat dalam SIMT ITB berikut proses yang direpresentasikannya No. SI Badan Kerja Proses 1. SILOG UPT Logistik Logistik 2. SI-X Direktorat Pendidikan Akademis 3. SISKEU Direktorat Keuangan Keuangan 4. SIMA Biro Sarana Prasarana Sarana Prasarana 5. HR-SID Biro Kepegawaian Kepegawaian 6. SISPRAN Biro Perencanaan Perencanaan 7. SIMAWA Biro Kemahasiswaaan Kemahasiswaan 8. SIPPM Lembaga Penelitian dan

Pengabdian Masyarakat Penelitian

9. SI sekolah/ fakultas

Unit Kerja Sekolah/ Fakultas

Administratif Fakultas

Nilai prioritas akan ditentukan dari peringkat diperlukannya sistem informasi

tersebut dalam keadaan up and running dibandingkan dengan sistem informasi

lainnya dari waktu ke waktu. Peringkat tersebut dapat berbeda-beda dari suatu interval

waktu ke interval waktu lainnya, karena setiap interval waktu memiliki

karakteristiknya masing-masing. Di bawah ini adalah daftar interval waktu yang

terjadi di ITB.

Tabel 12 Interval waktu terkait proses akademis Kode Interval waktu Keterangan

AK-1 Penerimaan mahasiswa baru

1. Pendaftaran peserta USM 2. Penyelenggaraan USM 3. Pendaftaran ulang mahasiswa baru 4. Pembayaran biaya pendidikan

AK-2 Pendaftaran ulang mahasiswa lama

1. Entri rencana studi 2. Pembayaran biaya pendidikan 3. Pendaftaran ulang mahasiswa lama 4. Perwalian 5. Perubahan rencana studi

AK-3 Masa Perkuliahan 1. Pengaturan jadwal kelas dan mata kuliah 2. Pencetakan transkrip nilai 3. Ujian Tengah Semester 4. Ujian Akhir Semester

IV-13

5. Pemrosesan nilai kuliah AK-3 Wisuda 1. Pendataan buku

2. Pendaftaran wisudawan 3. Pembayaran wisuda 4. Pencetakan ijazah 5. Penyelenggaraan wisuda 6. Pencetakan transkrip

AK-5 Liburan 1. Pelaksanaan semester pendek (jika diadakan)

Tabel 13 Interval waktu terkait proses non-akademis Kode Interval waktu Keterangan

NA-1 Waktu normal 1. Kegiatan administratif umum NA-2 Akhir Tahun 1. Laporan keuangan tahunan

2. Laporan pengadaan barang tahunan NA-3 Akhir Bulan 1. Penggajian karyawan ITB

2. Rekap keuangan bulanan 3. Rekap pengadaan barang bulanan

Nilai 9 (sesuai dengan banyaknya proses yang akan ditinjau) akan diberikan

pada proses yang dianggap paling vital pada waktu itu, nilai yang diberikan akan

berkurang dengan semakin rendahnya tingkat urgensi proses tersebut.

Tabel 14 Priority assessment per interval waktu akademis SI\Waktu AK-1 AK-2 AK-3 AK-4 AK-5 SILOG 5 4 4 5 4 SI-X 9 9 8 8 9 SISKEU 8 7 6 7 6 SIMA 7 6 7 6 7 HR-SID 4 5 3 2 3 SISPRAN 3 2 1 1 1 SIMAWA 2 3 5 4 5 SIPPM 1 1 2 3 2 SI sekolah/ fakultas 6 8 9 9 8

Tabel 15 Priority assessment per interval waktu non-akademis SI\Waktu NA-1 NA-2 NA-3 SILOG 7 8 4 SI-X 4 3 3 SISKEU 9 9 8 SIMA 8 7 2 HR-SID 1 6 9

IV-14

SISPRAN 5 2 6 SIMAWA 6 4 5 SIPPM 2 1 1 SI sekolah/ fakultas

3 5 7

4.3.3 Priority Assessment Segi Lokasi Infrastruktur SIMT ITB secara umum terkonsentrasi pada dua lokasi, yaitu

Gedung Rektorat ITB/ Annex dan lingkungan kampus ITB. Gedung Annex

merupakan lokasi sebagian server basis data sistem-sistem informasi yang tergabung

dalam SIMT ITB, sedangkan lingkungan kampus ITB merupakan lokasi server basis

data sistem informasi administratif sekolah/ fakultas dan lokasi sebagian besar

infrastruktur perangkat keras dan jaringan yang menyusun SIMT ITB.

Tabel 16 Distribusi lokasi infrastruktur SIMT ITB No. Nama Lokasi Alamat Lokasi Fokus Perhatian 1. Gedung Rektorat ITB (Annex) Jl. Tamansari 64 Data, repository

perangkat lunak 2. Lingkungan Kampus ITB Jl. Ganeca 10 Infrastruktur perangkat

keras dan jaringan

Berdasarkan priority assessment segi arsitektur yang telah dibahas

sebelumnya, disimpulkan bahwa nilai prioritas data dan perangkat lunak adalah jauh

lebih besar dari nilai prioritas perangkat keras dan jaringan. Karena itu, Gedung

Rektorat ITB dapat dianggap barada dalam prioritas yang lebih tinggi dibandingkan

dengan lingkungan kampus ITB dalam kaitannya dengan kelangsungan SIMT ITB.

Bagaimanapun juga, kedua lokasi tersebut berada dalam jarak yang relatif

dekat (kurang lebih 500 m), sehingga dapat dikatakan berada dalam area yang sama.

Hal ini merupakan suatu kekurangan, karena menempatkan SIMT ITB dalam posisi

sangat rapuh saat menghadapi bencana dengan lingkup luas seperti banjir, gempa, dan

lain-lain.

4.4 Srategy Selection

4.4.1 Bencana dan Lokasi

IV-15

Pada tahap Risk Assessment telah didapatkan daftar berbagai macam jenis

ancaman terhadap SIMT ITB berikut dengan nilai atribut-atribut bencana tersebut.

Selanjutnya pada tahap Priority Assessment didapatkan dua jenis lokasi penting bagi

SIMT ITB, yaitu Gedung Rektorat ITB dan lingkungan kampus ITB. Untuk

menentukan strategi pemulihan yang sebaiknya dilakukan, akan dilakukan klasifikasi

tambahan terhadap bencana-bencana dengan mempertimbangkan lingkup kerusakan

yang dapat disebabkan olehnya. Di bawah ini adalah istilah yang akan digunakan

untuk melakukan klasifikasi tersebut.

1. Lingkup A: digunakan untuk menandai ancaman bencana yang jika terjadi

hanya akan mempengaruhi salah satu lokasi vital SIMT ITB (baik sebagian

maupun seluruh lokasi tersebut).

2. Lingkup B: digunakan untuk menandai ancaman bencana yang jika terjadi

akan mempengaruhi kedua lokasi vital SIMT ITB dan lingkungan sekitarnya.

Apabila sebagian besar ancaman yang telah didaftar merupakan ancaman

dengan lingkup A, maka kebutuhan SIMT ITB akan sebuat mirror site (lokasi

cadangan) dapat dikatakan rendah. Jika diinginkan pun, mirror site dapat diletakkan

di bagian yang berbeda dari lokasi tersebut, misalnya, meletakkan server repository

SI-X cadangan di lantai yang berbeda dengan repository utamanya. Ataupun

meletakkan lokasi cadangan yang satu pada lokasi yang lainnya, misalnya, mirror

server basis data yang terdapat di Gedung Annex dapat diletakkan di lingkungan

kampus ITB.. Alternatif ini adalah yang paling murah dan mudah dalam

diimplementasikan, karena sumber daya seperti lokasi, daya, tenaga ahli yang

diperlukan dalam melakukan instalasi, operasi, dan perawatan yang digunakan oleh

mirror site masih merupakan sumber daya yang sama dengan yang digunakan lokasi

utama.

Jika ternyata lingkup B yang mendominasi, berarti terdapat kemungkinan yang

cukup besar akan ketidaktersediaan kedua lokasi tersebut dalam satu waktu. Hal ini

membuat alternatif membuat mirror site lokasi yang satu di lokasi yang lainnya

seperti pada kasus lingkup A menjadi tidak relevan. Untuk menghadapi ancaman

bencana dengan lingkup B, mirror site harus diadakan di lokasi baru.

Di bawah ini adalah tabel lingkup dari ancaman-ancaman yang sudah

didapatkan pada tahap Risk Assessment:

IV-16

Tabel 17 Tabel lingkup bencana No. Ancaman Risk Assessment Score Lingkup 1. Kerusakan alat 60 A 2. Ketiadaan daya 60 B 3. Pencurian alat 45 A 4. Kesalahan Manusia 45 A 5. Kerusakan gedung 30 A 5. Kerusakan perangkat

lunak/ data 20 A

6. Kebakaran 18 B 7. Banjir 12 B 8. Gunung meletus 12 B 9. Bencana sosial 10 B 10. Serangan kemanan 9 A 11. Gempa (besar) 7 B 12. Gempa (ringan) 4 B

Dari Tabel 17 dapat dilihat bahwa bencana lingkup A umumnya merupakan

bencana yang bersifat teknis, sehingga pengaruh dari bencana tersebut tidak akan

terlalu luas. Di lain pihak, bencana yang ditandai dengan lingkup B merupakan

bencana-bencana lokasi (bencana alam) dan bencana sosial. Bencana-bencana lingkup

B merupakan bencana yang tidak terkait langsung dengan eksistensi dan operasi

SIMT ITB, namun jika terjadi, dampaknya akan mempengaruhi kedua lokasi vital

SIMT ITB dan bahkan lingkungan sekitarnya.

Jika setiap lingkup yang ada diboboti dengan jumlah nilai Risk Assessment dari

bencana-bencana yang memiliki lingkup tersebut, didapatkan nilai sebagai berikut: Tabel 18 Tabel nilai lingkup

No. Lingkup Bencana Nilai Risk Assessment Total Nilai

Kerusakan alat 60 Pencurian alat 45 Kesalahan manusia 45 Kerusakan gedung 30 Kerusakan perangkat lunak/ data

20 1. A

Serangan keamanan 9

209

Ketiadaan daya 60 Kebakaran 18

2. B

Banjir 12

143

IV-17

Gunung meletus 12 Bencana sosial 10 Gempa (ringan) 7

Gempa (besar) 4

Tabel 18 menunjukkan bahwa lingkup A memiliki nilai lebih tinggi yaitu 209,

sedangkan lingkup B mendapatkan nilai 143. Dapat diamati juga bahwa bencana-

bencana yang mendapatkan nilai Risk Assessment tinggi, umumnya merupakan

bencana lingkup A. Karena itu, strategi pemulihan untuk bencana lingkup A akan

dibahas terlebih dahulu dan akan mendapatkan prioritas lebih tinggi dalam

pertimbangan strategi mana yang akhirnya akan digunakan nanti. Namun hal ini tidak

berarti kita akan mengacuhkan bencana lingkup B, karena variasi dari bencana yang

terdapat di bawah golongan lingkup B lebih beragam daripada lingkup A. Selain itu

juga patut diingat bahwa bencana lingkup B merupakan bencana-bencana yang

berpotensi membawa kerusakan dan kerugian yang sangat besar jika terjadi.

4.4.2 Strategi Pemulihan Bancana Lingkup A Bencana-bencana yang tergolong dalam lingkup A umumnya merupakan

bencana yang mendapatkan nilai cukup tinggi dalam Risk Assessment, dengan

demikian dapat disimpulkan paling mengancam. Kerusakan alat dan pencurian alat

misalnya, tidak memerlukan keberadaan sebuah mirror site untuk menangani

pemulihannya, sesuai dengan deskripsi bencana lingkup A. Kedua bencana di atas

dapat ditangulangi dengan perbaikan ataupun penggantian komponen. Untuk

menekan waktu pemulihan yang dibutuhkan, dapat diadakan pencadangan perangkat

keras yang rawan rusak atau dicuri, seperti router, access point, dan lain lain. Alat-

alat cadangan ini dapat disimpan di tempat yang tidak jauh (masih dalam lokasi yang

sama), maupun dicadangkan pada pihak ketiga selaku supplier.

Alternatif pertama sedikit lebih mahal dalam hal biaya, karena alat-alat yang

dicadangkan juga harus dibeli walaupun dalam kondisi sebenarnya belum tentu akan

dibutuhkan. Selain itu, juga harus dilakukan pencatatan alat apa saja yang

dicadangkan, disimpan dimana, dan siapa penanggung jawabnya. Di lain pihak,

alternatif semacam itu akan menekan waktu pemulihan menjadi sangat cepat bila

diterapkan secara baik, karena jika terjadi sesuatu pada suatu alat, tidak perlu

dilakukan banyak usaha, hanya tinggal mengambil dari tempat alat cadangan untuk

menggantikan alat yang lama.

IV-18

Alternatif kedua, yaitu mencadangkan alat pada pihak ketiga (supplier) relatif

lebih murah, karena alat hanya akan ‘dibeli’ jika sudah dibutuhkan. Untuk hasil

terbaik dari metode ini, sebaiknya disusun semacam kontrak antara ITB dengan

supplier, memastikan bahwa alat-alat dengan spesifikasi tertentu harus dapat

disediakan dalam kurun waktu tertentu setelah pemesanan. Alternatif ini juga tidak

memerlukan usaha ekstra dari pihak ITB, misalnya untuk melakukan perawatan

terhadap alat-alat cadangan, melakukan pendataan alat cadangan, dan lain sebagainya.

Namun cara ini juga memiliki beberapa kekurangan, misalnya jika pemesanan

dilakukan saat harga alat sedang tinggi, maka harga yang dibayar juga akan lebih

tinggi dibandingkan dengan jika menerapkan alternatif pertama. Kasus lain adalah

mengenai waktu, bahkan jika supplier dapat mengadakan alat yang dibutuhkan saat

itu juga, proses antar juga harus diperhitungkan, apalagi jika kerusakan bertepatan

dengan hari libur supplier, maka mau tidak mau pemulihan baru dapat dilakukan

setelah hari kerja.

Bencana ketiga adalah kerusakan perangkat lunak/ data. Untuk hal semacam

ini, strategi yang paling umum digunakan adalah dengan melakukan duplikasi data /

mirroring. Terdapat beberapa jenis metode mirroring seperti yang sudah dibahas

sekilas pada BAB II. Masing-masingnya memiliki kekuatan dan kelemahannya

sendiri tergantung dari kebutuhan. Spesifik untuk kasus kerusakan perangkat lunak/

data yang bukan disebabkan oleh bencana-bencana lain yang lingkupnya lebih besar,

yang paling mudah dan murah adalah dengan mengadakan duplikasi server repository

perangkat lunak dan basis data yang ditempatkan di lokasi yang masih terbilang sama,

misalnya diletakkan di lantai yang berbeda, atau di gedung lain yang tidak terlalu

jauh. Dengan lokasi yang dekat, jaringan yang diperlukan untuk melakukan proses

update data pun tidak terlalu rumit dan mahal, sehingga proses update basis data

dapat dilakukan secara kerap, atau bahkan mungkin realtime.

Untuk kasus perangkat lunak, kerusakan umumnya terjadi saat melakukan

update, misalnya penambahan modul, mengubah antar muka, dan lain sebagainya.

Saat berkas perangkat lunak pada repository utama dimanipulasi, mirror repository

tidak hanya melakukan duplikasi, namun juga akan menyimpan versi terakhir yang

dikatakan up and running dari perangkat lunak. Dengan begitu, jika versi perangkat

lunak yang baru mengalami bug atau kerusakan lain, versi sebelumnya akan

digunakan kembali sambil melakukan perbaikan ulang.

IV-19

4.4.3 Strategi Pemulihan Bencana Lingkup B Bencana-bencana yang tergolong dalam Lingkup B merupakan bencana yang

bersifat destruktif dan memiliki lingkup luas. Bencana-bencana semacam ini

umumnya ditanggulangi dengan alternatif pembuatan mirror site di lokasi yang

berada di luar area lokasi vital. Diharapkan dengan demikian, saat lokasi-lokasi vital

terpengaruh oleh terjadinya bencana dan mengalami kerusakan/ gangguan operasi,

lokasi cadangan yang diletakkan di luar area akan tetap aman, lebih baik lagi jika

lokais cadangan juga dapat mengambil alih tanggung jawab yang harus dilakukan

oleh lokasi vital.

Terdapat beberapa hal yang harus ditentukan dalam membangun lokasi

cadangan, yaitu lokasi, infrastruktur, dan frekuensi updating data. Selanjutnya akan

dibahas mengenai masing-masing hal tersebut yang dianggap paling sesuai untuk

diterapkan pada lokasi cadangan SIMT ITB.

4.4.3.1 Lokasi Mirror Site Untuk lokasi, yang harus diperhatikan adalah jarak dari lokasi utama,

ketersediaan sumber daya yang dibutuhkan, dan terlindung atau tidaknya lokasi

cadangan tersebut dari bencana yang mengancam lokasi utama (keduanya tidak boleh

terganggu oleh bencana yang sama dalam satu waktu). Selain hal tersebut, jarak juga

harus diperhatikan, karena jarak yang jauh dari lokasi utama berarti tambahan alokasi

dana untuk melakukan perawatan. Jarak yang terlalu jauh juga akan menyulitkan jika

suatu saat lokasi tersebut dibutuhkan untuk menjadi lokasi operasional pengganti

sementara saat lokasi utama mengalami gangguan bencana.

Terdapat alternatif untuk menyewa pihak ketiga yang berpengalaman untuk

mengelola dan menjaga lokasi cadangan. Bagi organisasi yang hanya memiliki lokasi

induk yang terpusat, alternatif ini jauh lebih murah dan terjamin dibandingkan dengan

mencari lokasi baru, membeli/ menyewa tempat tesebut, membangun infrastruktur

yang dibutuhkan disana, mengalokasikan sumber daya manusia yang diperlukan

untuk mengelolanya, dan banyak lagi. Namun dalam kasus ITB, sepertinya akan lebih

baik jika alternatif ini tidak diambil, melainkan tetap mengelola lokasi cadangan

sendiri. Hal ini antara lain karena:

1. ITB memiliki banyak lokasi yang belum dimanfaatkan secara maksimal,

baik di dalam kota Bandung maupun di luar kota.

IV-20

2. Data yang ditangani oleh SIMT ITB merupakan data-data dengan

tingkat sensitifitas cukup tinggi, sebisa mungkin tetap dikelola oleh ITB.

3. Belum terdapat pengelola mirror site yang terpercaya dan menangani

client dengan lokasi utama di Bandung. Kebanyakan merupakan

perusahaan penyedia mirror site internasional dengan client di Jakarta.

Lokasi yang dimiliki ITB di daerah Bandung dan sekitarnya sangatlah banyak

dan tersebar di berbagai macam area. Lokasi yang dijadikan asrama mahasiswa

misalnya, sangatlah banyak dan tersebar di pusat kota. Selain itu terdapat juga tanah-

tanah kosong di lingkar luar kota bandung yang belum termanfaatkan, seperti di

daerah sekitar Dago Atas, Cigadung, dan banyak lagi. Lalu tentu saja masih terdapat

daerah yang lebih jauh lagi, seperti Lembang (Boscha), dan bahkan Bekasi. Dengan

sekian banyak kandidat lokasi cadangan, harus dilakukan pertimbangan secara matang

dan jeli, karena jika salah mengambil keputusan, maka manfaat yang diharapkan dari

suatu lokasi cadangan tidak akan didapatkan, malah hanya akan menjadi beban

pengeluaran biaya dan usaha.

Faktor pertama adalah faktor ketersediaan infrastruktur. Pengadaan

infrastruktur akan lebih sulit dan memakan biaya jika memilih lokasi yang masih

merupakan tanah kosong tanpa bangunan. Beberapa organisasi memilih membangun

lokasi cadangan mereka mulai dari nol, karena dengan demikian lokasi dan bangunan

tersebut akan dapat disesuaikan dengan kebutuhan mereka. Bagaimanapun, sepertinya

hal tersebut terlalu berlebihan dan memakan biaya dalam kasus ITB, terutama karena

lokasi-lokasi lain yang menjadi pilihan juga masih memiliki bangunan yang layak.

Dengan pertimbangan ini, pemilihan lokasi cadangan akan difokuskan pada lokasi

yang sudah memiliki bangunan.

Faktor kedua adalah jarak. Jarak yang terlalu dekat dengan lokasi utama tidak

akan membantu sama sekali karena terdapat kemungkinan lokasi cadangan tersebut

juga tertimpa bencana yang sama dan tidak dapat berfungsi saat dibutuhkan. Dengan

mempertimbangkan hal tersebut, maka pilihan untuk meletakkan lokasi cadangan di

dalam kota menjadi dipertanyakan. Jika bencana seperti gempa atau kerusuhan terjadi,

maka besar kemungkinannya lokasi cadangan akan terkena juga. Di lain pihak, lokasi

yang terlalu jauh akan menyulitkan dalam hal instalasi dan perawatan. Bekasi

misalnya, walaupun dari segi keamanan akan lebih terjamin (kecil kemungkinan

terkencana bencana yang sama dalam satu waktu), namun akan membutuhkan

IV-21

penanganan lebih terutama dalam hal tenaga ahli. Hal ini kembali mempersempit

pilihan dalam menentukan lokasi. Alternatif yang menengahi kedua permasalahan di

atas dan sejauh ini tampak merupakan pilihan paling bijaksana, adalah menempatkan

lokasi cadangan tersebut di area lingkar luar kota Bandung, cukup jauh untuk

menghindari bencana yang sama, namun cukup dekat untuk mempermudah alokasi

tenaga ahli bila diperlukan dengan cepat.

Menggabungkan kedua hal di atas, lokasi yang berada di daerah lingkar luar

kota Bandung, dan sudah memiliki bangunan yang layak, mengerucutkan pilihan yang

tersedia menjadi tinggal beberapa pilihan saja. Kandidat yang paling tepat dengan

berbagai pertimbangan tersebut adalah Kompleks Observatorium Boscha di daerah

Lembang.

Jarak Boscha yang tidak terlalu jauh dari lokasi utama, yaitu sekitar kurang

lebih 60 menit perjalanan, menjadikannya tempat yang ideal untuk lokasi cadangan.

Tenaga ahli yang dibutuhkan untuk melakukan instalasi maupun perawatan dapat

dengan mudah dan cepat didatangkan dari ITB, hal ini berarti tidak perlu ada

tambahan alokasi dana untuk melakukan hal tersebut. Lokasinya yang cukup jauh dari

pusat kota juga menghindarkannya dari bencana-bencana sosial yang mungkin terjadi

seperti demostrasi mahasiswa, aksi protes masyarakat, ataupun kerusuhan massa.

Masih terdapat beberapa pilihan tempat yang juga memenuhi pertimbangan-

pertimbangan di atas dan karenanya juga dapat dijadikan alternatif lokasi cadangan.

Boscha dikemukakan hanya sebagai saran dan gambaran mengenai bagaimana lokasi

cadangan yang ideal bagi SIMT ITB.

4.4.3.2 Infrastruktur Mirror Site Setelah menentukan lokasi yang sesuai, hal yang selanjutnya harus

diperhatikan adalah infrastruktur, yaitu apa saja yang dibutuhkan terdapat di lokasi

cadangan. Apakah lokasi tersebut hanyalah tempat untuk menyimpan duplikasi data

saja, atau lokasi tersebut juga harus dapat menjadi tempat operasional sementara

dengan peralatan lengkap?

Komplek Observatrium Boscha memiliki bangunan yang masih kokoh berdiri

dan cukup besar. Selain itu jalan menuju lokasi tersebut juga memiliki jalan masuk

yang cukup lebar dan dalam keadaan baik, hal ini penting untuk mempermudah

proses transfer infrastruktur dan hal-hal lainnya yang diperlukan pada masa instalasi

dan perawatan.

IV-22

Infrastruktur yang dapat dikatakan primer untuk diadakan di lokasi cadangan

adalah server basis data, server repository perangkat lunak, dan perangkat keras

pendukung jaringan yang memungkinkan terjadi lalu lintas data dari lokasi utama ke

lokasi cadangan. Untuk infrastruktur lain seperti meja, bangku, dan alat-alat fasilitas

operasional, tidak perlu diadakan karena lokasi cadangan ini hanya akan

diperuntukkan untuk menyimpan server basis data dan repository perangkat lunak.

Jika nantinya terjadi hal yang membuat suatu lokasi operasi harus diadakan,

pengadaan perlengkapan kantor juga tidak akan terlalu sulit meninjau letak dari lokasi

cadangan.

4.4.3.3 Updating Data Mirror Site Dari sisi frekuensi updating data, harus ditentukan seberapa sering data yang

berada pada server mirror diperbaharui sesuai dengan data pada server data utama.

Jika aktivitas yang terjadi sangat sering dan atau tingkat ancaman yang mungkin

mengganggu besar, maka frekuensi updating harus tinggi. Namun cost untuk

melakukan hal semacam itu tentunya tidak murah baik dari sisi biaya maupun lalu

lintas data yang harus terjadi, karena itu, sebaiknya frekuensi updating disesuaikan

dengan kebutuhan sistem.

SIMT ITB sebagai portal berbagai macam sistem informasi dapat dibilang

unik karena memfasilitasi berbagai macam tingkat kekerapan lalu lintas data dalam

interval waktu yang berbeda-beda pula. Lebih detil mengenai hal ini sudah dijelaskan

dalam BAB III yaitu pada bagian Priority Assessment dari segi proses.

Menimbang hal tersebut, metode paling bijak adalah dengan melakukan

pengaturan waktu updating sesuai dengan hasil Priority Assessment yang sudah

dilakukan. Sistem informasi yang sedang mengalami masa sibuk, dapat melakukan

updating data secara lebih kerap, sedangkan sistem informasi yang sedang berada

dalam masa kerja biasa tetap melakukan updating dengan frekuensi normal.

Frekuensi normal yang umum digunakan oleh sistem yang tidak tergolong

rapid system (seperti bank atau bursa saham) adalah per 12-24 jam. Untuk SIMT ITB,

satu minggu sekali mungkin adalah jangka waktu yang sesuai karena skalanya yang

tidak terlalu besar dan transaksi yang terjadi tidak terlalu kerap (kebanyakan

perubahan besar terjadi dalam kurun semester atau tahun). Namun untuk sistem

informasi yang sedang berada pada interval waktu sibuk (seperti yang telah dibahas

pada bagian Priority Assessment) dapat melakukan updating lebih sering, sampai

IV-23

dengan satu jam sekali. Misalnya pada saat pendaftaran ulang mahasiswa baru, data

pada SI-X dan SISKEU berubah dengan cepat, maka kedua SI ini dapat melakukan

update data ke lokasi cadangan dengan lebih kerap.

4.5 Plan Documenting

Segala hal yang sudah didapatkan pada analisis dan tahapan-tahapan

pembamungan selanjutnya akan dituangkan dalam sebuah Disaster Recovery Plan.

Tidak terdapat pedoman yang mengikat mengenai bagaimana Disaster Recovery Plan

harus dibangun. Karena itu setiap organisasi memiliki bentuk Disaster Recovery Plan

yang berbeda-beda sesuai dengan kebutuhan organisasi tersebut. Perbedaan dapat

ditemukan dalam segi tingkat detil yang disajikan, format penyajian, istilah yang

digunakan, urutan penanganan, dan banyak lagi.

Terdapat banyak pilihan toolkit yang tersedia, masing-masingnya dengan cara

penyajian dan sudut pandang yang berbeda-beda. Disaster Recovery Plan akan

mengambil beberapa yang dinilai paling sesuai dengan SIMT ITB dan mencoba

menggabungkan beberapa aspek untuk mendapatkan hasil yang dianggap terbaik.

Disaster Recovery Plan sebagai produk dari tugas akhir ini akan diletakkan pada

bagian Lampiran.

Dokumentasi Disaster Recovery Plan yang akan disusun akan terdiri dari

bagian:

1. Lingkup Dokumen dan Penjabaran Aset

Berisi penjelasan mengenai batasan Disaster Recovery Plan yang

dibangun dengan mengacu pada keadaan sistem saat proses pembangunan.

Jika saat terjadi ancaman bencana keadaan sistem sudah mengalami

perubahan, maka Disaster Recovery Plan yang terdapat pada dokumen

tidak valid dan perlu disesuaikan ulang sebelum diterapkan.

2. Penilaian dan Penjelasan Risiko

Bagian ini menyajikan hasil dari tahapan Risk Assessment. Pada bagian

ini ditampilkan ancaman seperti apa saja yang patut diwaspadai, dan karena

itu ditangani dalam Disaster Recovery Plan ini.

3. Penilaian Prioritas

Merangkum apa yang didapatkan pada tahap Priority Assessment,

termasuk didalamnya adalah penlaian prioritas segi arsitektur, penilaian

IV-24

prioritas segi lokasi, dan penilaian prioritas segi proses. Langkah-langkah

penyelamatan dan pemulihan yang akan dilakukan nantinya sangat

bergantung pada hasil analisis prioritas ini.

4. Lokasi Cadangan

Berisi penjelasan tentang lokasi-lokasi cadangan yang dimiliki oleh

SIMT ITB, berikut keterangan mengenai tanggung jawab kerja setiap

lokasi, kelengkapan yang terdapat di lokasi, dan lain-lain.

5. Langkah Pemulihan

Bagian ini tardiri dari rangkaian langkah-langkah yang harus dilakukan

jika terjadi ancaman yang mengganggu kinerja SIMT ITB. Mencakup

bencana-bencana yang sudah dideskripsikan pada bagian penilaian risiko

dan menggunakan hasil penilaian prioritas sebagai acuan.

6. Tabel-Tabel Pendukung

Berisi tabel-tabel yang diperlukan dalam melakukan langkah-langkah

pemulihan yang dijabarkan pada bagian sebelumnya.

V-25

BAB V PENUTUP

Dalam bab ini akan dijelaskan sejumlah kesimpulan yang diperoleh selama

pelaksanaan tugas akhir dan saran untuk pengembangan lebih lanjut terhadap topik

yang dikaji.

5.1 Kesimpulan

Kesimpulan yang diperoleh terkait dengan topik yang dikaji dalam tugas akhir

ini dapat dirumuskan sebagai berikut:

1. Kesimpulan

Kesimpulan

2. Kesimpulan

Kesimpulan

3. Kesimpulan

Kesimpulan

4. Kesimpulan

Kesimpulan

5.2 Saran Beberapa saran yang dapat diberikan untuk pengembangan lebih lanjut dari

substansi yang dikaji dalam tugas akhir ini dapat diuraikan sebagai berikut:

1. Saran

2. Saran

3. Saran

xi

DAFTAR REFERENSI

[BAR01] Barnes, James C. (2001). A Guide to Business Continuity Planning. John

Wiley & Sons.

[FUL05] Fulmer, Kenneth L. (2005). Business Continuity Planning: A Step-by-Step

Guide with Planning Forms, Third Edition. Rothstein Associates.

[INV07] Investor World, http://www.investorwords.com/623/business.html, diakses

tanggal 18 Mei 2008.

[KEP07] Kepenach, Richard J. (2007). Business Continuty Plan Design. IEEE

2007.

[ROS06] Ross, Christine Ferrusi & Connie Moore. (2006). Business Process

Definition, Improvement, and Management, Forrester.com.

[SNE07] Snedaker, Susan. (2007). Business Continuty and Disaster Recovery For

IT Professionals. Syngress.

[SOL05] Solehudin, Usep. (2005). Business Continuty and Disaster Recovery Plan.

Magister Universitas Indonesia.

[WAL04] Wallace, Michael and Lawrence Webber. (2004). The Disaster Recovery

Handbook: A Step-by-Step Plan to Ensure Business Continuty and Protect

Vital Operations, Facilities, and Assets.

xii

DAFTAR PUSTAKA

[ALT02] Alter, Steven. (2002) Information System (The Foundation of

e-Bussiness). 4th edition. Prentice-Hall.

[CAN04] Cangara, M.Sc., Dr. H. Hafied, (2004) Pengantar Ilmu Komunikasi,

Rajawali Pers.

[BAR01] Barnes, James C. (2001). A Guide to Business Continuity Planning. John

Wiley & Sons.

[FUL05] Fulmer, Kenneth L. (2005). Business Continuity Planning: A Step-by-Step

Guide with Planning Forms, Third Edition. Rothstein Associates.

[ISD05] Information Services Division (2005). Business Continuity Planning

Guidelines. www.dem.state.az.us/bussines%20continuity/ADOA-BC-

GUIDELINE.pdf -

diakses tanggal 8 Maret 2008.

[KEP07] Kepenach, Richard J. (2007). Business Continuty Plan Design. IEEE

2007.

[OLI07] Olive, Antoni. (2007). Conceptual Modeling of Information Systems.

Springer.

[SNE07] Snedaker, Susan. (2007). Business Continuty And Disaster Recovery For

IT Professionals. Syngress.

[WAR07] Ward, Susan. (2007). Business Continuity Planning.

http://sbinfocanada.about.com/od/businessplanning/g/bizcontinuity.htm

diakses tanggal 8 Maret 2008.

A-1

LAMPIRAN A – ALAT PENGAMBILAN DATA

I. Risk Assessment

1. Lakukan brainstorm mengenai seluruh kemungkinan bencana yang

mungkin terjadi. Tabel A. 1 Tabel bencana umum

No. Golongan Bencana Bencana Keterangan

1. Bencana Alam

2. Bencana Manusia

3. Bencana Teknis

4. Bencana Sosial

A-2

2. Tentukan atribut bencana apa saja yang akan dijadikan alat ukur penilaian

bencana, sesuai dengan kebutuhan sistem dan ketersediaan data yang

mendukung.

3. Lakukan pembobotan pada setiap bencana pada Tabel A.1 terhadap

atribut-atribut bencana yang digunakan. Urutan validitas sumber yang

digunakan untuk melakukan pembobotan risiko adalah sebagai berikut:

a. Catatan tertulis/ dokumentasi resmi

b. Hasil wawancara dengan pihak yang berwenang/ mengerti

c. Hasil observasi

Tabel A. 2 Tabel penilaian bencana

Atribut 1 Atribut 2 Atribut 3 Ancaman skala skala skala

Score

Bencana Alam

Bencana Manusia

Bencana Teknis

Bencana Sosial

A-3

4. Urutkan ancaman yang ada berdasarkan nilai ancam yang diperoleh pada

Tabel A.2. Tabel A. 3 Tabel penilaian bencana (terurut)

No. Bencana Atribut 1 (skala)

Atribut 2 (skala)

Atribut 3 (skala) Score

5. Setelah pengurutan nilai, tinjau kembali Tabel A.3. Jika terdapat bencana

yang memiliki nilai ancam yang tidak terlalu signifikan, bencana tersebut

dapat diabaikan untuk tahapan-tahapan selanjutnya.

A-4

II. Priority Assessment

1. Penilaian Prioritas Segi Arsitektur

e. Definisikan arsitektur apa saja yang terlibat sesuai dengan batasan

Disaster Recovery Plan. Arsitektur dapat menyangkut perangkat

keras, perangkat lunak, jaringan, data, bangunan, saluran

komunikasi, transportasi, dan lain sebagainya. Tabel A. 4 Tabel elemen arsitektur

No. Elemen Arsitektur Keterangan

f. Tentukan atribut apa saja yang akan dijadikan alat ukur penilaian

prioritas, sesuai dengan kebutuhan sistem dan ketersediaan data

yang mendukung.

g. Lakukan pembobotan pada setiap elemen arsitektur pada Tabel A.4

terhadap atribut-atribut bencana yang digunakan. Urutan validitas

sumber yang digunakan untuk melakukan pembobotan prioritas

adalah sebagai berikut:

i. Catatan tertulis/ dokumentasi resmi

ii. Hasil wawancara dengan pihak yang berwenang/

mengerti

iii. Hasil observasi

A-5

Tabel A. 5 Tabel penilaian prioritas elemen arsitektur

Atribut 1 Atribut 2 Atribut 3 No. Elemen Arsitektur skala skala skala

Score

h. Urutkan elemen arsitektur berdasarkan nilai prioritas yang diperoleh

pada Tabel A.5. Tabel A. 6 Tabel penilaian prioritas elemen arsitektur (terurut)

No. Elemen Arsitektur Atribut 1 (skala)

Atribut 2 (skala)

Atribut 3 (skala) Score

i. Setelah pengurutan nilai, tinjau kembali Tabel A.6. Jika terdapat

elemen arsitektur yang memiliki nilai prioritas yang tidak terlalu

signifikan, elemen arsitektur tersebut dapat diabaikan untuk

tahapan-tahapan selanjutnya.

A-6

2. Penilaian Prioritas Segi Lokasi

a. Penilaian prioritas segi lokasi perlu ditentukan jika terdapat lebih dari

satu lokasi yang terlibat dengan sistem. Definisikan lokasi apa saja

sesuai dengan batasan Disaster Recovery Plan. Tabel A. 7 Tabel lokasi

No. Nama Lokasi Keterangan

b. Tentukan atribut apa saja yang akan dijadikan alat ukur penilaian prioritas,

sesuai dengan kebutuhan sistem dan ketersediaan data yang mendukung.

Prioritas lokasi juga dapat ditentukan dengan menggunakan hasil penilaian

prioritas segi arsitektur yang sudah terlebih dahulu ditentukan.

c. Lakukan penilaian pada setiap lokasi pada Tabel A.7 terhadap atribut-atribut

yang digunakan. Urutan validitas sumber yang digunakan untuk melakukan

penilaian prioritas adalah sebagai berikut:

i. Catatan tertulis/ dokumentasi resmi

ii. Hasil wawancara dengan pihak yang berwenang/ mengerti

iii. Hasil observasi

Tabel A. 8 Tabel penilaian prioritas lokasi

Atribut 1 Atribut 2 Atribut 3 No. Lokasi skala skala skala

Score

A-7

d. Urutkan elemen lokasi berdasarkan nilai prioritas yang diperoleh pada

Tabel A.8. Tabel A. 9 Tabel penilaian prioritas lokasi (terurut)

No. Lokasi Atribut 1 (skala)

Atribut 2 (skala)

Atribut 3 (skala) Score

e. Setelah pengurutan nilai, tinjau kembali Tabel A.9. Jika terdapat

lokasi yang memiliki nilai prioritas yang tidak terlalu signifikan,

lokasi tersebut dapat diabaikan untuk tahapan-tahapan selanjutnya.

A-8

3. Penilaian Prioritas Segi Proses

a. Penilaian prioritas segi proses diawali dengan melakukan identifikasi

proses apa saja yang terlibat dalam cakupan Disaster Recovery Plan. Tabel A. 10 Tabel proses

No. Proses Keterangan

b. Proses umumnya berlangsung dinamis dalam hubungannya dengan waktu.

Lakukan identifikasi interval-interval waktu yang menjadi titik kemungkinan

perubahan nilai prioritas proses-proses. Tabel A. 11 Tabel interval waktu

No. Interval Waktu Keterangan

A-9

c. Lakukan penilaian pada setiap proses pada Tabel A.10 terhadap interval-

interval waktu pada Tabel A.11. Urutan validitas sumber yang digunakan

untuk melakukan penilaian prioritas adalah sebagai berikut:

i. Catatan tertulis/ dokumentasi resmi

ii. Hasil wawancara dengan pihak yang berwenang/ mengerti

iii. Hasil observasi

Tabel A. 12 Tabel penilaian prioritas proses

No. Proses Interval Waktu 1

Interval Waktu 2

Interval Waktu 3

Interval Waktu 4

C-1

LAMPIRAN B – DISASTER RECOVERY PLAN

DOKUMEN DISASTER RECOVERY PLAN SISTEM INFORMASI MANAJEMEN TERINTEGRASI

INSTITUT TEKNOLOGI BANDUNG I. LINGKUP DOKUMEN DAN PENJABARAN ASET (DRP SCOPE AND ASSET LISTING)

I.1. Lingkup Dokumen (DRP Scope)

Disaster Recovery Plan yang dijabarkan pada dokumen ini merupakan Disaster Recovery Plan untuk Sistem Informasi Manajemen Terintegrasi ITB (SIMT ITB). Dokumen ini dibuat berdasarkan data yang didapat melalui observasi, studi lapangan, dan wawancara pada tahun 2008-2009. Jika terdapat perubahan pada SIMT ITB setelah jangka waktu tersebut, maka sebaiknya dilakukan peninjauan ulang dan melakukan penyesuaian yang dianggap perlu sebelum menerapkan Disaster Recovery Plan pada dokumen. I.2. Penjabaran Aset (Asset Listing) Penjabaran aset yang dimiliki oleh SIMT ITB dilakukan untuk mengetahui aset yang terlibat sehingga proses pembangunan DRP memiliki batasan yang jelas dan dan terfokus. Aset dalam konteks ini mencakup perangkat, aplikasi, dan koneksi yang digunakan oleh SIMT ITB.

No. Unit/ Dept SI Aplikasi Perangkat Keras Jaringan

1. UPT Logistik SILOG PHP/ MySQL Perangkat keras terlibat

LAN

2. Direktorat Pendidikan

SI-X PHP/ MySQL, Java/ MySQL

Perangkat keras terlibat

LAN

3. Direktorat Keuangan

SISKEU Oracle Finance Perangkat keras terlibat

LAN

4. Biro Sarana Prasarana

SIMA PostGist/ PostgreSQL

Perangkat keras terlibat

LAN

5. Biro Kepegawaian HR-SID PHP/ MySQL Perangkat keras terlibat

LAN

6. Biro Perencanaan SISPRAN PHP/ Oracle Perangkat keras terlibat

LAN

7. Biro Kemahasiswaaan

SIMAWA Microsoft Access Perangkat keras terlibat

LAN

8. Lembaga Penelitian dan Pengabdian Masyarakat

SIPPM PHP/ MySQL Perangkat keras terlibat

LAN

9. Unit Kerja Sekolah/ Fakultas

SI sekolah/ fakultas

PHP/ MySQL Perangkat keras terlibat

LAN

II. PENILAIAN DAN PENJELASAN RISIKO (RISK ASSESSMENT AND BREAKDOWN) II.1. Penilaian Risiko (Risk Assessement)

C-2

Penilaian risiko dapat dilakukan dengan dua pendekatan yang berbeda yakni secara kuantitatif dan kualitatif. Pendekatan kuantitatif risiko menggunakan data nilai finansial yang diformulasikan dengan menggunakan metode tertentu. Pendekatan ini biasanya akan sulit untuk mengukur nilai intangible yang ada. Sedangkan pendekatan kualitataif risiko lebih condong menggunakan intuisi dan pengalaman terhadap risiko yang dihadapi sistem. Pendekatan ini relatif simpel karena tidak membutuhkan data finansial yang detil namun akan sulit memberikan gambaran presisi secara finansial terhadap sistem dan risiko yang ada.

Penilaian risiko dalam pembangunan DRP pada SIMT ITB dilakukan dengan menggunakan pendekatan kualitatif dengan alasan keberadaan data finansial mendetil yang diperlukan untuk pengukuran kuantitatif sulit didapatkan. Selain itu, batasan pembangunan DRP ini tidak perlu memperhitungkan efek finansial yang mendetil karena DRP yang diharapkan terbatas pada ruang lingkup keberlangsungan sistem, jaringan, dan aplikasi pada SIMT ITB sebagai penunjang proses bisnis yang sedang berjalan.

Risk Assessment Form

Tanggal: Februari 2009

Likelihood Restoration

Time Predictability Score Ancaman 0 – 10 0 - 10 0 - 3

Bencana Alam

Gempa (ringan) 4 2 1 4

Gempa (besar) 1 7 1 7

Banjir 1 6 2 12

Gunung Meletus 1 6 2 12

Bencana Manusia

Perusakan/ pencurian alat 3 5 3 45

Serangan jaringan/ data 1 3 3 9

Kesalahan manusia 5 3 3 45

Bencana Teknis

Kerusakan alat 4 5 3 60

Ketiadaan daya 6 5 2 60

Kerusakan perangkat lunak/ data 6 5 2 60

Kerusakan gedung 3 5 2 30 Kebakaran 1 6 3 18

Bencana Sosial

Pemogokan pegawai 1 5 2 10

Unjuk rasa masyarakat 1 5 2 10

Demonstrasi mahasiswa 1 5 2 10

C-3

No. Ancaman Likelihood (0-10)

Restoration Time (0-10)

Predictability (0-3) Score Scope

1. Kerusakan alat 4 5 3 60 A 2. Ketiadaan daya 6 5 2 60 B

3. Kerusakan perangkat lunak/ data

4 5 1 20 A

4. Kesalahan Manusia 5 3 3 45 A

5. Serangan jaringan/data 1 3 3 9 A

6. Pencurian/perusakan alat 3 5 3 45 A

7. Kerusakan gedung 3 5 2 30 B

8. Banjir 1 6 2 12 B

9. Gempa (ringan) 4 2 1 4 B

10. Gempa (besar) 1 7 1 7 B

11 Gunung meletus 1 6 2 12 A

12. Kebakaran 1 6 3 18 B

13. Bencana sosial 1 5 2 10 B

Keterangan: 1. Likelihood (0-10): kemungkinan terjadi bencana 2. Restoration time (0-10): waktu yang dibutuhkan untuk mengembalikan sistem beroperasi lagi

seperti semula setelah gangguan terjadi 3. Predictability (0-3): dapat diramalkan atau tidaknya suatu bencana. 4. Score: hasil perkalian dari nilai pada kolom-kolom yang berada di sebelah kirinya.

Rician nilai yang diberikan pada pada Tabel XXX dapat dilihat pada Tabel XXX.

Tabel 19 Rincian penilaian atribut risiko Kolom Nilai

Likelihood Restoration Time Predictability 0 Tidak mungkin terjadi Tidak ada Dapat diprediksi dengan pasti

bahkan sebelum bencana terjadi

1 Terjadi > 5 tahun sekali 1-4 menit Prediksi dapat dilakukan sebelum bencana terjadi, namun dengan tingkat kepercayaan yang lemah

2 Terjadi 2 - 5 tahun sekali 5menit-1 jam Prediksi hanya dapat dilakukan setelah terjadi tanda-tanda awal bencana

3 Terjadi 1 - 2 tahun sekali 1-6 jam Tidak dapat diprediksi

4 Terjadi 6 - 12 bulan sekali 6-12 jam

C-4

Kolom Nilai Likelihood Restoration Time Predictability

5 Terjadi 2 – 6 bulan sekali 12-24 jam

6 Terjadi 1- 2 bulan sekali 1-4 hari 7 Terjadi 2 - 4 minggu sekali 5-9 hari

8 Terjadi 1 - 2 minggu sekali 10-14 hari 9 Terjadi 1 - 7 hari sekali 15-30 hari

10 Terjadi beberapa kali dalam 24 jam

Membutuhkan waktu > 1 bulan

II.2. Penjelasan Risiko (Risk Breakdown) Tiap risiko yang sudah dirinci pada bagian penilaian risiko, jika terjadi akan mengakibatkan

jenis kerusakan yang berbeda-beda pada aset yang berbeda pula. Penjabaran lebih lanjut sebagai berikut:

1. Bencana Alam a. Gempa

Gempa dengan kekuatan menengah dapat mengguncang peralatan, sehingga dapat mempengaruhi alat-alat yang sensitif seperti server basis data. Gempa juga dapat mengakibatkan kerusakan pada infrastruktur jaringan dan gedung.

b. Banjir Banjir dapat merusak peralatan terutama yang terletak pada lantai bawah, dan memutus akses menuju peralatan-peralatan lainnya. Banjir yang berlangsung cukup lama berpotensi mengakibatkan kerusakan pada jaringan antar lokasi yang dihubungkan dengan kabel bawah tanah.

c. Gunung meletus Mememutus akses dan atau merusak peralatan.

2. Bencana Manusia a. Pencurian/ perusakan alat

Kerusakan alat dapat dibagi menjadi dua, alat yang berkaitan dengan jaringan atau dengan server dan basis data. Cukup jelas akan mematikan proses yang berkaitan dengan server/ jaringan yang bersangkutan.

b. Serangan keamanan jaringan Dapat merusak jaringan, perangkat lunak, atau data.

c. Kesalahan manusia Cukup jelas.

3. Bencana Teknis

a. Ketiadaan daya SIMT ITB tidak akan dapat beroperasi tanpa ketersediaan daya. Gagal daya secara tiba-tiba dapat merusak server dan data yang terlibat dalam transaksi yang sedang berlangsung.

b. Kerusakan alat Kerusakan pada alat dapat dibagi menjadi dua, alat yang berkaitan dengan jaringan atau dengan server dan basis data. Cukup jelas akan mematikan proses yang berkaitan dengan server/ jaringan yang bersangkutan.

C-5

c. Kerusakan perangkat lunak/ data Mengganggu proses yang bergantung terhadap perangkat lunak/ data tersebut.

d. Kerusakan gedung Cukup jelas.

e. Kebakaran Cukup jelas.

4. Bencana sosial Bencana-bencana sosial dapat memicu terjadinya bencana-bencana yang sudah disebutkan di atas, seperti kebakaran, pencurian/ perusakan alat, serangan keamanan, dan banyak lagi.

III. PRIORITY ASSESSMENT (PENILAIAN PRIORITAS) III.1. Penilaian Prioritas Arsitektur

Ditinjau dari sisi arsitektur, SIMT ITB terdiri dari empat elemen penyusun yaitu perangkat

keras, perangkat lunak, jaringan, dan data. Urutan penyelamatan saat terjadi bencana, atau perbaikan sesudahnya, sebaiknya dilakukan terurut hasil analisis prioritas arsitektur sebagi berikut.

No. Elemen Necessity Recoverability Replaceability Priority Value

1. Data 5 5 5 125

2. Perangkat lunak 5 3 4 60

3. Jaringan 5 2 4 40

4. Perangkat keras 5 3 2 30

Keterangan: 1. Necessity (1-5): kemungkinan terjadi bencana 2. Recoverability (1-5): waktu yang dibutuhkan untuk mengembalikan sistem beroperasi lagi

seperti semula setelah gangguan terjadi 3. Replacability (0-3): dapat diramalkan atau tidaknya suatu bencana. 4. Priority Value: hasil perkalian dari nilai pada kolom-kolom yang berada di sebelah kirinya.

Rician nilai yang diberikan pada pada Tabel XXX dapat dilihat pada Tabel XXX.

Nilai Necessity Recoverability Replaceability

1 Sistem tetap dapat berfungsi sempurna walaupun elemen tidak ada.

Elemen dapat dengan mudah diperbaiki, tenaga ahli sangat mudah ditemui, dengan waktu perbaikan sangat singkat.

Elemen dapat digantikan dengan mudah tanpa biaya maupun usaha yang berarti

2 Sistem mengalami hambatan/ delay dalam menjalankan fungsinya jika elemen tidak ada.

Elemen dapat dengan mudah diperbaiki, tenaga ahli cukup mudah ditemui, namun dengan waktu perbaikan yang berdampak pada sistem.

Elemen dapat digantikan dengan yang lain namun tetap membutuhkan biaya dan atau usaha yang cukup besar.

3 Sistem hanya dapat menjalankan fungsi-fungsi vital jika elemen tidak ada.

Elemen cukup sulit diperbaiki, tenaga ahli cukup sulit ditemui, dan dengan waktu perbaikan yang dapat mengganggu sistem.

Elemen dapat digantikan dengan yang lain dengan biaya dan atau usaha yang besar.

C-6

Nilai Necessity Recoverability Replaceability 4 Sistem hanya dapat

menjalankan fungsi-fungsi non vital jika elemen tidak ada.

Elemen sangat sulit diperbaiki, tenaga ahli sangat sulit ditemui, dan membutuhkan waktu perbaikan yang sangat panjang.

Elemen dapat digantikan dengan yang lain, namun membutuhkan biaya dan atau usaha yang sangat besar.

5 Sistem tidak dapat berfungsi sama sekali jika elemen tidak ada.

Elemen hampir tidak mungkin untuk diperbaiki

Elemen bersifat unik dan tidak dapat digantikan dengan apapun.

III.2. Penilaian Prioritas Lokasi

Infrastruktur SIMT ITB secara umum terkonsentrasi pada dua lokasi, yaitu Gedung Rektorat ITB/ Annex dan lingkungan kampus ITB. Gedung Annex merupakan lokasi sebagian server basis data sistem-sistem informasi yang tergabung dalam SIMT ITB, sedangkan lingkungan kampus ITB merupakan lokasi server basis data sistem informasi administratif sekolah/ fakultas dan lokasi sebagian besar infrastruktur perangkat keras dan jaringan yang menyusun SIMT ITB.

Tabel 20 Distribusi lokasi infrastruktur SIMT ITB No. Nama Lokasi Alamat Lokasi Fokus Perhatian 1. Gedung Rektorat ITB (Annex) Jl. Tamansari 64 Data, repository perangkat

lunak 2. Lingkungan Kampus ITB Jl. Ganeca 10 Infrastruktur perangkat

keras dan jaringan Berdasarkan priority assessment segi arsitektur yang telah dibahas sebelumnya, disimpulkan

bahwa nilai prioritas data dan perangkat lunak adalah jauh lebih besar dari nilai prioritas perangkat keras dan jaringan. Karena itu, Gedung Rektorat ITB dapat dianggap berada dalam prioritas yang lebih tinggi dibandingkan dengan lingkungan kampus ITB dalam kaitannya dengan kelangsungan SIMT ITB.

III.3. Penilaian Prioritas Proses

Pada analisis prioritas arsitektur sudah disebutkan urutan prioritas tiap elemen arsitektur.

Lebih jauh mengenai perangkat keras apa, perangkat lunak apa, data apa, yang harus diprioritaskan pada saat terjadi bencana, sangat tergantung dari waktu terjadinya bencana tersebut. Hal ini disebabkan karena dalam interval waktu yang berbeda, proses yang berlangsung berbeda-beda pula. Di bawah ini adalah interval waktu yang akan digunakan sebagai acuan.

Kode Interval waktu Keterangan

AK-1 Penerimaan mahasiswa baru

1. Pendaftaran peserta USM 2. Penyelenggaraan USM 3. Pendaftaran ulang mahasiswa baru 4. Pembayaran biaya pendidikan

AK-2 Pendaftaran ulang mahasiswa lama

1. Entri rencana studi 2. Pembayaran biaya pendidikan 3. Pendaftaran ulang mahasiswa lama 4. Perwalian 5. Perubahan rencana studi

AK-3 Masa Perkuliahan 1. Pengaturan jadwal kelas dan mata kuliah 2. Pencetakan transkrip nilai 3. Ujian Tengah Semester 4. Ujian Akhir Semester

C-7

Kode Interval waktu Keterangan 5. Pemrosesan nilai kuliah

AK-3 Wisuda 1. Pendataan buku 2. Pendaftaran wisudawan 3. Pembayaran wisuda 4. Pencetakan ijazah 5. Penyelenggaraan wisuda 6. Pencetakan transkrip

AK-5 Liburan 1. Pelaksanaan semester pendek (jika diadakan)

Kode Interval waktu Keterangan NA-1 Waktu normal 2. Kegiatan administratif umum

NA-2 Akhir Tahun 3. Laporan keuangan tahunan 4. Laporan pengadaan barang tahunan

NA-3 Akhir Bulan 4. Penggajian karyawan ITB 5. Rekap keuangan bulanan 6. Rekap pengadaan barang bulanan

Nilai 9 (sesuai dengan banyaknya proses yang akan ditinjau) akan diberikan pada proses yang dianggap paling vital pada waktu itu, nilai yang diberikan akan berkurang dengan semakin rendahnya tingkat urgensi proses tersebut. Proses penyelamatan atau pemulihan yang akan dilakukan sebaiknya sesuai dengan urutan sebagai berikut:

Tabel 21 Priority assessment per interval waktu akademis SI\Waktu AK-1 AK-2 AK-3 AK-4 AK-5

SILOG 5 4 4 5 4

SI-X 9 9 8 8 9

SISKEU 8 7 6 7 6

SIMA 7 6 7 6 7

HR-SID 4 5 3 2 3

SISPRAN 3 2 1 1 1

SIMAWA 2 3 5 4 5

SIPPM 1 1 2 3 2 SI sekolah/ fakultas 6 8 9 9 8

Tabel 22 Priority assessment per interval waktu non-akademis

SI\Waktu NA-1 NA-2 NA-3 SILOG 7 8 4 SI-X 4 3 3 SISKEU 9 9 8 SIMA 8 7 2 HR-SID 1 6 9 SISPRAN 5 2 6 SIMAWA 6 4 5 SIPPM 2 1 1

C-8

SI sekolah/ fakultas 3 5 7

Tabel-tabel di atas menampilkan urutan prioritas tiap sistem informasi pada suatu kurun

waktu, Jika suatu bencana terjadi pada interval AK-1 misalnya, yang menjadi prioritas dalam penyelamatan dan pemulihan adalah SI-X, dengan urutan sesuai dengan hasil analisis prioritas arsitektur, yaitu data SI-X, perangkat lunak SI-X, diikuti dengan jaringan yang mendukungnya, dan perangkat keras. IV. MIRROR SITE (LOKASI CADANGAN) IV.1 Spesifikasi Lokasi Cadangan

7. Definisi

Lokasi cadangan adalah tempat operasional alternatif dimana tersimpan salinan SIMT ITB. Salinan dalam hal ini terdiri dari back up data, perangkat-perangkat lunak yang terlibat, perangkat keras pendukung, dan jaringan yang memungkinkan terjadinya lalu lintas pertukaran data dari lokasi utama untuk kepentingan update dan refetch.

8. Daftar lokasi cadangan <Tergantung dari ketersediaan dana dan alokasi sumber daya, dapat terdapat lebih dari satu lokasi cadangan. Lokasi-lokasi tersebut dapat memiliki distribusi tanggung jawab yang berbeda-beda tergantung kebijakan.>

Kelengkapan No. Nama

Lokasi Tanggung

jawab Alamat

Lengkap

Person in

charge

Nomor kontak Hardware Software Jaringan Infrastruktur

V. LANGKAH PEMULIHAN (RECOVERY MEASURE) V.1. Langkah Pemulihan Bencana Teknis

1. Ketiadaan daya

a. Periksa sekring listrik yang berkaitan dengan area yang mengalami ketiadaan daya

(lihat daftar lokasi penyimpanan peralatan darurat di bagian VI.3).

i. Jika sekring dalam keadaan turun, nyalakan kembali.

ii. Jika tidak, maka nyalakan genset (lihat daftar peralatan darurat di bagian

VI.3).

1. Jika genset tidak dapat menyala, lakukan panggilan darurat sesuai

dengan daftar penanggung jawab peralatan darurat (bagian VI.3)

C-9

2. Jika genset menyala, lakukan pengecekan terhadap perangkat

keras, perangkat lunak, jaringan dan data sesuai dengan skala

prioritas saat itu (lihat tabel analisis prioritas bagian III.3)

a. Jika terdapat kerusakan, lakukan langkah pemulihan

bencana teknis sesuai dengan jenis kerusakan (bagian

V.1)

b. Isi catatan kejadian (bagian VI.1)

2. Kerusakan perangkat keras

a. Identifikasi perangkat keras apa saja yang mengalami kerusakan

b. Lakukan panggilan darurat sesuai dengan daftar penanggung jawab perangkat keras

(bagian VI.2)

c. Penanggung jawab akan melakukan penilaian apakah:

i. perangkat keras dapat diperbaiki,

ii. atau harus diganti. Untuk pengadaan perangkat keras baru, lihat tabel

vendor dan supplier (bagian VI.3)

d. Isi catatan kejadian (bagian VI.1) dan catatan kerusakan perangkat keras (bagian

VI.1)

3. Kerusakan perangkat lunak

a. Identifikasi perangkat lunak apa yang mengalami kerusakan

b. Lakukan panggilan darurat sesuai dengan daftar penanggung jawab perangkat lunak

(bagian VI.2)

c. Penanggung jawab akan melakukan penilaian apakah:

i. perangkat lunak dapat tetap digunakan,

ii. dapat digantikan dengan versi yang terdapat di repository cadangan sesuai

dengan tabel kelengkapan lokasi cadangan (bagian IV.1),

iii. atau perlu dilakukan perbaikan.

d. Jika diperlukan perbaikan, operasi-operasi akan dialihkan penanganannya kepada

versi perangkat lunak yang masih baik yang tersimpan pada repository cadangan

selama masa perbaikan berlangsung. Perangkat lunak yang masih baik dapat di

refetch ke repository utama, atau jika tidak memungkinkan, maka lalu lintas operasi

akan dialihkan ke lokasi cadangan untuk ditagani di sana.

e. Isi catatan kejadian (bagian VI.1) dan catatan kerusakan perangkat lunak (bagian

VI.1)

4. Kerusakan jaringan

a. Identifikasi bagian jaringan mana yang mengalami kerusakan

C-10

b. Lakukan panggilan darurat sesuai dengan daftar penanggung jawab kerusakan

jaringan (bagian VI.2)

c. Penanggung jawab akan melakukan penilaian apakah kerusakan jaringan

disebabkan oleh:

i. kerusakan perangkat keras/ lunak. Jika ya maka lihat langkah pemulihan

kerusakan perangkat keras/ lunak (bagian V.1).

ii. atau oleh kesalahan konfigurasi jaringan. Jika ya lakukan perbaikan.

d. Isi catatan kejadian (bagian VI.1) dan catatan kerusakan jaringan (bagian VI.1).

5. Kerusakan data

a. Identifikasi data apa yang mengalami kerusakan

b. Lakukan panggilan darurat sesuai dengan daftar penanggung jawab kerusakan data

(bagian VI.2)

c. Penanggung jawab akan melakukan penilaian apakah kerusakan data disebabkan

oleh:

i. kerusakan perangkat keras/ lunak. Jika ya, maka lihat langkah pemulihan

kerusakan perangkat keras/ lunak (bagian V.1).

d. Jika diperlukan, lakukan refetch terhadap data cadangan yang tersimpan pada

repository cadangan sesuai dengan tabel lokasi cadangan (bagian IV.1).

e. Isi catatan kejadian (bagian VI.1) dan catatan kerusakan data (bagian VI.1).

V.2. Langkah Pemulihan Bencana Lain Bencana-bencana jenis lain seperti bencana alam atau bencana sosial memiliki beberapa

kemungkinan kejadian kasus. Bencana-bencana tersebut dapat mengakibatkan kerusakan teknis, mengisolasi (memotong akses) terhadap suatu lokasi, atau bahkan keduanya. Karena kemungkinan tersebut selalu ada dalam setiap kemungkinan bencana, maka langkah penanganan akan dijabarkan sesuai dengan dampak apa yag disebabkan oleh bencana alam atau sosial tersebut terhadap kedua lokasi utama.

1. Bencana mengakibatkan kerusakan teknis yang tidak menyeluruh pada salah satu atau

kedua lokasi utama tanpa melakukan isolasi terhadap keduanya

a. Identifikasi kerusakan teknis apa saja yang terjadi

b. Lakukan langkah-langkah pemulihan kerusakan teknis (bagian V.1)

2. Bencana mengakibatkan kerusakan teknis yang menyeluruh atau isolasi terhadap salah

satu dari lokasi utama

a. Bencana mengakibatkan kerusakan teknis menyeluruh dan atau isolasi terhadap

Gedung Rektorat ITB

i. Lakukan penilaian kebutuhan sistem pada waktu tersebut sesuai dengan

tabel analisis prioritas proses (bagian III.3)

C-11

ii. Lakukan pengalihan penanganan proses dari server-server yang berlokasi

di Gedung Rektorat ITB ke lokasi cadangan sesuai dengan kelengkapannya

masing-masing seperti yang tercantum pada tabel kelengkapan lokasi

cadangan (bagian IV.1).

iii. Lakukan pengalihan fungsi operasional pendukung sistem ke lokasi

lingkungan Kampus ITB jika diperlukan.

iv. Isi catatan kejadian (bagian VI.1).

b. Bencana mengakibatkan kerusakan teknis menyeluruh dan atau isolasi terhadap

Lingkungan Kampus ITB

i. Lakukan penilaian kebutuhan sistem pada waktu tersebut sesuai dengan

tabel analisis prioritas proses (bagian III.3)

ii. Lakukan pengalihan penanganan proses dari server-server yang berlokasi

di Lingkungan kampus ITB ke lokasi cadangan sesuai dengan

kelengkapannya masing-masing seperti yang tercantum pada tabel daftar

lokasi cadangan (bagian IV.1).

iii. Lakukan pengalihan fungsi operasional pendukung sistem ke lokasi

Gedung Rektorat ITB jika diperlukan.

iv. Isi catatan kejadian (bagian VI.1).

3. Bencana mengakibatkan kerusakan teknis yang menyeluruh atau isolasi terhadap

kedua lokasi utama sekaligus

a. Lakukan penilaian kebutuhan sistem pada waktu tersebut sesuai dengan tabel

analisis prioritas proses (bagian III.3)

b. Lakukan pengalihan penanganan proses dari server-server yang dianggap diperlukan

ke lokasi cadangan sesuai dengan kelengkapannya masing-masing seperti yang

tercantum pada tabel daftar lokasi cadangan (bagian IV.1)

c. Lakukan penyesuaian jaringan sehingga server-server tersebut dapat di akses

menggunakan jaringan luar (internet), karena kedua lokasi utama tidak dapat

difungsikan

d. Lakukan pengalihan penangalihan fungsi operasional pendukung sistem ke lokasi

cadangan yang memiliki kelengkapan sebagai lokasi operasi sesuai dengan tabel

kelengkapan lokasi cadangan (bagian IV.1)

e. Isi catatan kejadian (bagian VI.1)

C-12

VI. TABEL-TABEL PENDUKUNG VI.1 Daftar Penanggung Jawab

1. Daftar Penanggung Jawab Perangkat Keras

Daftar Penanggung Jawab Perangkat Keras Nomor Kontak

Perangkat Keras Keterangan Nama

Penanggung Jawab Jam Kerja Luar Jam

Kerja

Terakhir

diperbaharui: Diperbaharui

oleh:

C-13

2. Daftar Penanggung Jawab Perangkat Lunak

Daftar Penanggung Jawab Perangkat Lunak Nomor Kontak

Perangkat Lunak Keterangan Nama

Penanggung Jawab Jam Kerja Luar Jam

Kerja

Terakhir

diperbaharui: Diperbaharui

oleh:

C-14

3. Daftar Penanggung Jawab Jaringan

Daftar Penanggung Jawab Jaringan Nomor Kontak

Jaringan Keterangan Nama

Penanggung Jawab Jam Kerja Luar Jam

Kerja

Terakhir

diperbaharui: Diperbaharui

oleh:

C-15

4. Daftar Penanggung Jawab Data

Daftar Penanggung Jawab Data Nomor Kontak

Data Keterangan Nama

Penanggung Jawab Jam Kerja Luar Jam

Kerja

Terakhir

diperbaharui: Diperbaharui

oleh:

C-16

VI.2 Catatan Kejadian dan Kerusakan

1. Catatan Kejadian

Catatan Kejadian Sistem: Tanggal: Jam:

Nama: Lokasi:

Deskripsi masalah (Apa, Siapa, Dimana, Kapan, Mengapa, Bagaimana)

Kritik dan Saran

C-17

2. Catatan Kerusakan Perangkat Keras

Catatan Kerusakan Perangkat Keras Sistem: Tanggal: Jam:

Nama: Lokasi:

Penilaian Kerusakan

Langkah yang Diambil

Waktu Pemulihan

Sumber Daya yang Digunakan

Kritik dan Saran

C-18

3. Catatan Kerusakan Perangkat Lunak

Catatan Kerusakan Perangkat Lunak Sistem: Tanggal: Jam:

Nama: Lokasi:

Penilaian Kerusakan

Langkah yang Diambil

Waktu Pemulihan

Sumber Daya yang Digunakan

Kritik dan Saran

C-19

4. Catatan Kerusakan Jaringan

Catatan Kerusakan Jaringan Sistem: Tanggal: Jam:

Nama: Lokasi:

Penilaian Kerusakan

Langkah yang Diambil

Waktu Pemulihan

Sumber Daya yang Digunakan

Kritik dan Saran

C-20

5. Catatan Kerusakan Data

Catatan Kerusakan Data Sistem: Tanggal: Jam:

Nama: Lokasi:

Penilaian Kerusakan

Langkah yang Diambil

Waktu Pemulihan

Sumber Daya yang Digunakan

Kritik dan Saran

C-21

VI.3 Lain-Lain

1. Nomor Telepon Darurat

Daftar Nomor Telepon Darurat Internal Nomor Telepon

Keamanan <tuliskan nomor telepon instansi terkait di sini>

Listrik <tuliskan nomor telepon instansi terkait di sini>

Air <tuliskan nomor telepon instansi terkait di sini>

AC <tuliskan nomor telepon instansi terkait di sini>

Legal <tuliskan nomor telepon instansi terkait di sini>

External

Pemadam Kebakaran <tuliskan nomor telepon instansi terkait di sini>

Kepolisian <tuliskan nomor telepon instansi terkait di sini>

Ambulans <tuliskan nomor telepon instansi terkait di sini>

Rumah Sakit <tuliskan nomor telepon instansi terkait di sini>

Ahli kunci <tuliskan nomor telepon instansi terkait di sini>

PLN <tuliskan nomor telepon instansi terkait di sini>

Telkom <tuliskan nomor telepon instansi terkait di sini>

Internet Service Provider <tuliskan nomor telepon instansi terkait di sini>

Pemulihan

Perusahaan asuransi <tuliskan nomor telepon instansi terkait di sini>

Lokasi cadangan <tuliskan nomor telepon instansi terkait di sini>

Kontraktor <tuliskan nomor telepon instansi terkait di sini>

Terakhir diperbaharui:

Diperbaharui oleh:

C-22

2. Lokasi Peralatan Darurat

Daftar Lokasi Penyimpanan Peralatan Darurat Peralatan Gedung Lantai Ruang

Penyimpanan

Kunci lemari penyimpanan

Saklar sirkuit listrik

Keran air utama

Kontrol utama alarm kebakaran

Tabung pemadam kebakaran

Kotak P3K

Generator Listrik

Terakhir

diperbaharui: Diperbaharui

oleh:

C-23

3. Penanggung Jawab Peralatan Darurat

Daftar Penanggung Jawab Peralatan Darurat Nomor Kontak

Peralatan Keterangan Nama

Penanggung Jawab Jam Kerja Luar Jam

Kerja

Terakhir

diperbaharui: Diperbaharui

oleh: