1.1
Apa itu Disaster?
Tujuan dari disaster
recovery adalah untuk me-restore system sehingga perusahaan dapat melanjutkan
meneruskan bisnis. Sebuah disaster adalah semua yang menghasilkan korupsi atau
kehilangan dari system R/3.
Contohnya termasuk:
- Korupsi database
- Contohnya saat tes data secara tidak
sengaja mengisi ke sistem produksi.
- Hal ini terjadi lebih sering dari yang
orang sadari.
- Kerusakan hardware yang berat
- Kerugian yang menyeluruh pada system dan
infrastuktur R/3
- Contohnya, kerusakan dari gedung karena
bencana alam.
Tanggung jawab pokok dari seorang system administrator adalah dengan
berhasil me-restore R/3 setelah sebuah disasater/bencana.
|
|
Akibat pokok dari
tidak me-restore system adalah perusahan anda tidak bisa melakukan bisnis
|
Sasaran dari
administrator adalah untuk menjaga system dari situasi yang pernah dicapai
dimana tanggung jawab utamanya adalah hal tersebut.
Perencanaan disaster
recovery adalah sebuah proyek besar. Bergantung pada situasi anda dan ukuran
dan kompleksitas dari perusahaan anda, perencanaan disaster recovery dapat
menggunakan waktu lebih dari setahun untuk menyiapkan, tes, dan memperbaiki.
Perencanaan dapat memenuhi beberapa volume. Pada bab ini membantu anda untuk
memulai berpikir tentang dan merencanakan disaster recovery.
1.2
Mengapa
Merencanakan sebuah Disaster?
- Seorang system administrator seharusnya
merencanakan untuk hal yang buruk, dan kemudian berharap untuk yang
terbaik.
- Selama disaster recovery, tidak ada
seharusnya yang dilakukan untuk kali pertama.
Kejutan yang tidak menyenangkan dapat menjadi fatal untuk proses
recovery.
Berikut ini adalah beberapa alas an untuk membangun sebuah perencanaan
disaster recovery:
- Apa operasi bisnis berhenti bila R/3
gagal?
- Berapa banyak pendapatan yang hilang dan
biaya akan diadakan untuk tiap jam saat system sedang down?
- Fungsi bisnis kritis mana yang tidak bisa
dilengkapi?
- Bagaimana pelanggan akan didukung?
- Berapa lama system akan down sebelum
perusahaan menjalankan bisnisnya?
- Siapa yang mengkoordinasi dan mengelola
disaster recovery?
- Apa yang akan pengguna lakukan bila R/3
sedang down?
- Berapa lama system akan down?
- Berapa lama waktu yang diperlukan sebelum
system R/3 tersedia untuk digunakan?
Jika anda merencanakan secara tepat, anda tidak akan tertekan, karena
anda mengetahui bahwa system akan direcover dan berapa lama recovery akan
dilakukan.
Jika downtime recovery tidak dapat diterima, manajemen seharusnya
berinvestasi pada:
- Perangkat, fasilitas dan personil
- Pilihan High Availability(HA).
Pilihan HA bisa jadi mahal. Ada
beberapa derajat perbedaan dari HA, jadi pelanggan perlu untuk memutuskan
pilihan mana yang sesuai dengan mereka.
HA adalah sebuah topik advance diluar ruang lingkup dari dokumen ini.
Jika anda tertarik pada topic tersebut, hubungi vendor HA.
1.3
Perencanaan
untuk Sebuah Disaster?
1 Pembuatan perencanaan
Pembuatan sebuah perencanaan disaster recovery adalah sebuah proyek
besar karena:
+ Hal ini akan memerlukan waktu lebih dari setahun dan waktu yang lama
untuk develop, tes dan mendokumentasikan.
+ Dokumentasi mungkin akan banyak (panjangnya beribu-ribu halaman) .
Jika anda tidak mengetahui bagaimana merencanakan untuk sebuah disaster
recovery, dapatkan asisten yang ahli. Perencanaan yang buruk(yang akan gagal)
adalah lebih buruk daripada tidak ada perencanaan, karena perencanaan tersebut
menyediakan keamanan yang gagal.
1.4
Apa
Persyaratan Bisnis untuk Disaster Recovery?
Siapa yang akan
menyediakan persyaratannya?
1 Senior management perlu untuk
menyediakan persyaratan global(atau strategis) dan pedoman.
- Kebutuhan unit bisnis membutuhkan
persyaratan detil yang lebih khusus.
Apa saja persyaratannya?
Tiap persyaratan seharusnya menjawab pertanyaan-pertanyaan berikut ini:
- Siapa yang memberi syarat?
- Apa persyaratannya?
- Apa departemen atau pelanggan berdampak
oleh persyaratan ini?
- Mengapa persyaratan penting?
- Saat R/3 offline, apa yang (tidak )
terjadi?
- Berapa biaya (pendapatan yang hilang)
perjam atau perhari saat R/3 downtime?
Justifikasi seharusnya sebuah nilai objektif yang nyata( seperti $20.000
perjam). Definisikan biaya(perjam, per hari, dll) saat system R/3 down.
|
|
Contoh 1
Ketidakmampuan
untuk membuat ulang transaksi yang hilang dapat menghasilkan penjualan hilang
dan pelanggan yang marah. Jika pesanan yang hilang adalah pesanan yang
pelanggan butuhkan secara cepat, kondisi ini bisa jadi kritis.
|
|
|
Apa : Sistem tidak
bisa offline lebih dari 3 jam
Mengapa : Biaya (rata-rata $25000 per jam)
adalah ketidakmampuan untuk memesan penjualan
|
|
|
Contoh 3
Apa : di saat disaster, seperti kerugian
bangunan yang berisi dengan data center R/3, perusahaan hanya dapat
mentoleransi 2 hari downtime.
|
1.5
Kapan
Seharusnya sebuah Prosedur Disaster
Recovery mulai?
Tanya pada diri anda
pertanyaan-pertanyaan berikut ini:
- Kriteria apa yang terdapat pada sebuah
disaster?
- Apa kriteria ini telah dipenuhi?
- Siapa yang perlu ditanyai?
Orang harus hati-hati pada efek dari disaster pada bisnis perusahaan dan
recovery alam kritis.
1.6
Downtime
yang Diharapkan atau Recovery Time
Downtime yang diharapkan
Downtime yang
diharapkan adalah hanya bagian dari biaya bisnis dari disaster recovery. Di
definisikan scenario, biaya ini waktu minimum yang diharapkan sebelum R/3 bisa
berproduksi lagi. Downtime dapat berarti bahwa tidak ada pesanan dapat diproses
dan tidak ada produk yang dikirimkan.
Manajemen harus
menyetujui biaya ini, jadi hal yang penting bahwa mereka memahami bahwa
downtime adalah biaya bisnis potensial.
Untuk membantu bisnis
berjalan, hal yang penting untuk mencari jika ada proses alternative yang bisa
digunakan saat system R/3 sedang di recovery.
Biaya-biaya berikut
ini terlibat dengan downtime:
1. Lama waktu R/3 down
- Semakin lama system down, semakin lama
system dikembalikan ke kondisi up. Transaksi dari proses alternative yang
ditempatkan selama disaster harus diaplikasikan pada system agar sesuai
dengan kondisi terkini. Situasi ini lebih kritis dalam sebuah lingkungan
yang high-volume.
- System yang down lebih mahal selama hari
kerja daripada akhir dari hari kerja saat semuanya telah pulang.
- Saat pelanggan tidak dapat dilayani atau
di support, mereka berpindah ke competitor
Durasi dari downtime yang dapat diterima bergantung pada perusahaan dan
karakter dari bisnis perusahaan.
Recovery
Time
Kecuali kalau anda tes prosedur recovery,
recovery time hanyalah sebuah perkiraan, atau buruknya, sebuah tebakan.
Skenario disaster yang berbeda memiliki recovery time yang berbeda, yang
didasarkan pada apa yang perlu dilakukan untuk beroperasional lagi.
Waktu untuk merecover harus bisa sesuai dengan
keperluan bisnis. Jika waktunya lebih lama dari keperluan bisnis,
ketidaksesuaian perlu dikomunikasikan ke manager atau eksekutif yang sesuai.
Menyelesaikan ketidaksesuaian ini termasuk:
o
Berinvestasi
pada peralatan, proses, dan fasilitas untuk mengurangi recovery time.
o
Merubah
persyaratan bisnis untuk menerima recovery time yang lebih lama dan menerima
akibatnya.
Sebuah contoh ekstrem(tapi mungkin): sebuah
perusahaan tidak mampu untuk membiayai dan kehilangan pendapatan bulanan hal
ini akan memerlukan seseorang untuk me-recover system. Selama waktu tersebut,
kompetisi akan mengambil pelanggan, pembayaran yang akan jatuh tempo ke vendor,
dan tagihan tidak akan dikumpulkan. Pada situasi ini, senior managemen perlu
untuk mengalokasikakn sumber daya untuk mengurangi recovery time ke level yang
dapat diterima.
Recovery group dan
role dari staf
Kita mendefiniskan
beberapa kunci role berikut ini:
1. Recovery manager
Mengelola seluruh recovery teknis. Semua aktivitas recovery dan
permasalahannya seharusnya dikoordinasikan melalui orang ini.
- Communication liaison
Menangani panggilan telepon pengguna dan memberikan informasi ke
manajemen puncak dengan status recovery yang up to date. Satu orang menangani
semua panggilan telepon memperkenankan group melakukan recovery teknis untuk
memproses tanpa interupsi.
- Tim recovery teknis
Melakukan recovery teknis secara nyata. Selama recovery dalam
perkembangan, perencanaan asli harus dimodifikasi. Role ini harus mengelola
perubahan dan mengkoordinasikan recovery teknis.
- Manager review dan sertifikasi
Mengkoordinasikan dan merencanakan percobaan dan sertifikasi
post-recovery dengan pengguna.
|
|
Untuk mengurangi
gangguan dari staf recovery, kami merekomendasikan anda untuk memelihara
papan status. Papan status seharusnya mendaftar poin kunci dalam perencanaan
recovery dan sebuah estimasi saat sistem akan direcovery dan siap digunakan
|
5. Jika disaster adalah sebuah kejadian geografis yang besar( seperti gempa bumi), staf lokal anda akan lebih perhatian pada keluarga mereka – bukan pada perusahaan.
- Bergantung pada disaster, personel kunci bisa terluka atau terbunuh
Anda seharusnya berharap dan berencana untuk
situasi ini. Perencanaan untuk staf dari daerah geografis lainnya untuk
menerbangkannya ke lokasi dan berpartisipasi sebagai anggota tim disaster
recovery.
|
Role staf yang terakhir adalah untuk
merencanakan paling sedikit satu anggota staf yang “tak tesedia”. Tanpa orang
ini, sisa dari departemen harus dapat untuk melakukan sebuah recovery yang
sukses. Permasalahan ini menjadi vital selama ada disaster sebenarnya.
1.7
Tipe-tipe
dari Disaster Recovery
Skenario disaster
recovery dikelompokkan menjadi 2 tipe:
1. Onsite
2. Offsite
Onsite
Recovery onsite adalah disaster recovery yang dilakukan dilokasi anda.
Infrastruktur biasanya tetap utuh. Skenario khusus terbaik adalah sebuah
recovery dilakukan pada hardware asli. Skenario terburuknya adalah sebuah
recovery dilakukan pada sebuah system backup.
Offsite
Recovery offsite adalah disaster recovery dilakukan pada lokasi sebuah
disaster recovery. Pada skenario ini, semua hardware dan infrastruktur hilang sebagai
sebuah hasil dari kerusakan fasilitas seperti kebakaran, banjir, atau gempa
bumi. Server baru harus dikonfigurasi mulai dari awal.
Pertimbangan besarnya adalah sekali fasilitas asli telah dibangun
kembali dan dites, restore kedua harus ditempatkan kembali ke fasilitas asli
pelanggan. Selama restore kedua ini bisa direncanakan dan terjadwal pada waktu
yang tepat untuk sesedikit mungkin menggangu pengguna. Pengaturan waktu sama
kritisnya dengan disaster. Selama sistemnya direcovery, sistemnya down.
1.8
Skenario
Disaster
Skenario disaster
tersusun dari:
1.Gambaran dari kejadian disaster
2.Perencanaan level atas dari tugas besar yang dilakukan
- Estimasi waktu untuk mendapatkan system
tersedia pada pengguna
Untuk membuat skenario
akhir anda:
- Gunakan 3 disaster scenario umum berikut
ini sebagai poin permulaan.
- Persiapkan 3 dari 5 skenario yang
melingkupi disaster yang akan dipergunakan.
- Buat sebuah perencanaan level atas(
tersusun dari tugas besar) untuk tiap scenario.
- Tes skenario yang terencana, dengan
membuat tes disaster yang berbeda dan menentukan jika( dan bagaimana)
scenario anda akan sesuai dengan disaster yang nyata.
- Jika tes skenario tidak sesuai, modifikasi
atau develop scenario lagi.
- Ulangi prosesnya.
Tiga skenario disaster umum
Tiga contoh berikut ini adalah dari
sebuah scenario dari terbaik ke terburuk secara berurutan:
|
|
Downtime pada contoh
berikut ini adalah hanya contoh. Downtime anda akan berbeda. Anda harus
mengganti contoh downtime dengan downtime yang sesuai dengan lingkungan anda.
|
Sebuah database yang korup
§
Sebuah
korup database dapat berasal dari:
o
Secara
tidak sengaja mengisi tes data ke system produksi
o
Transportasi
yang buruk ke produksi, yang hasilnya adalah kegagalan pada system produksi
§
Sebuah
disaster perlu recovery dari database R/3 dan file yang berhubungan dengan
system operasi.
§
Contoh
downtime adalah 8 jam.
Kerusakan hardware
§
Tipe item
berikut ini dapat gagal:
o
Sistem prosesor
o
Drive
controller
o
Multiple-drive
di sebuah array drive, sehingga drive array gagal
§
Skenario
disasternya memerlukan:
o
Memindahkan
hardware yang rusak
o
Membangun
kembali server(system operasi dan semua program)
o
Merecovery
database R/3 dan file-file yang berhubungan.
§
Contoh
downtime adalah 7 hari dan terdiri dari:
o
5 hari
untuk penggantian hardware
o
2 hari
untuk membangun kembali server NT( satu orang); 16 jam untuk hari kerja nyata.
Kerugian atau kerusakan menyeluruh dari
fasilitas server
- Item berikut ini dapat hilang:
- Server
- Semua infrastuktur pendukung
- Semua dokumentasi dan bahan-bahan di
dalam bangunan
- Bangunan
- Kerugian menyeluruh dari fasilitas dapat
dihasilkan dari tipe disaster berikut ini:
- Kebakaran
- Gempa bumi
- Banjir
- Badai
- Tornado
- Bencana buatan manusia, seperti
pengeboman
- Disaster tersebut memerlukan:
- Penggantian fasilitas
- Penggantian infrastruktur
- Penggantian hardware yang hilang
- Membangun kembali server dan lingkungan
R/3( hardware, system operasi, database, dll)
- Me-recover database R/3 dan file-file
yang berhubungan
Contoh downtime berlangsung
selama 8 hari dan terdiri dari:
- Paling sedikit 5 hari untuk mendapatkan
hardware.
Di regional disaster, pembeliannya dapat lebih lama jika penyuplai juga
terkena disaster.
|
|
Gunakan vendor
nasional dengan beberapa pusat distribusi regional dan , sebagai backup,
miliki sebuah alternatif penyuplai yang diluar area disaster
|
- 2 hari untuk membangun kembali server
NT(satu orang); 16 jam hari kerja nyata
- Saat hardware-nya didapatkan dan server
dibangun kembali, sebuah fasilitas alternative didapatkan dan jaringan
darurat(minimal) dibangun.
- Satu hari untuk mengintegrasikan ke
jaringan darurat.
- Kerugian dan kerusakan menyeluruh
memerlukan sebuah recovery kembali ke fasilitas baru.
1.9
Skrip Recovery
1. Apa
Sebuah skrip recovery adalah sebuah dokumen yang menyediakan instruksi
langkah perlangkah tentang:
+ Proses diperlukan
untuk merecover R/3
+ Siapa yang akan
menyelesaikan tiap langkah
+ Waktu yang
diharapkan
+ Kebergantungan
antar langkah
2.Mengapa
Sebuah skrip adalah penting karena skrip akan membantu anda:
+ Develop dan menggunakan ururan pembuktian dari langkah untuk
me-restore R/3
+ Mencegah kelalaian langkah
Kelalaian sebuah
langkah kritis memerlukan pengulangan kembali proses recovery dari permulaan,
yang menunda recovery.
Jika orang utama yang melakukan recovery tidak ada, sebuah skrip
recovery membantu orang backup untuk menyelesaikan recovery.
Pembuatan skrip recovery
Pembuatan sebuah skrip recovery memerlukan:
- Sebuah daftar untuk tiap langkah
- Sebuah dokumen dengan screenshot untuk
menjelaskan perintah-perintah, jika dibutuhkan
- Flowchart, jika aliran langkah-langkah
atau aktivitas adalah kritis atau membingungkan
Proses Recovery
Untuk mengurangi waktu recovery,
definisikan sebuah proses dengan:
- Menyelesaikan tugas sebanyak mungkin
secara parallel
- Penambahan jadwal untuk tiap langkah
Langkah-langkah utama
1.
Selama
sebuah disaster potensial, antisipasi sebuah recovery dengan:
- Pengumpulan fakta
- Penarikan kembali tape offsite terkini
- Penarikan kembali crash kit
- Menghubungi semua orang yang diperlukan
Orang-orang ini terdiri dari tim SAP internal, pengguna, infrastruktur
pendukung, IT, fasilitas, konsultan on-call dll.
Mempersiapkan fungsional organisasi ( penjualan, keuangan dan
pengiriman) untuk prosedur alternative untuk proses dan transaksi bisnis.
2.
Meminimasi
efek dari disaster dengan:
§
Memberhentikan
semua transaksi tambahan di system
o
Menunggu
terlalu lama dapat memperburuk permasalahan.
§
Pengumpulan rekaman transaksi yang harus
secara manual dimasukkan kembali.
3.
Memulai
perencanaan proses dengan:
·
Menganalisa
permasalahan
·
Menyesuaikan
disaster ke perencanaan scenario yang telah didefinisikan
·
Memodifikasi
perencanaan yang dibutuhkan
4.
Definisikan
saat memulai prosedur disaster recovery
·
Kriteria
apa yang menyatakan sebuah disaster, dan apakah mereka telah sesuai?
·
Siapa yang
akan membuat keputusan terakhir untuk menyatakan sebuah disaster?
5.
Mengumumkan
disaster
6.
Melakukan
system recovery
7.
Tes dan
mengakhiri system recovery
Pengguna utama, yang akan menggunakan sebuah daftar criteria untuk
menentukan bahwa system telah terecover dengan memuaskan seharusnya melakukan
tes.
8.
Catch up dengan transaksi yang telah ditangani
dengan proses alternative selama disaster.
Sekali terselesaikan, langkah ini seharusnya memerlukan sebuah akhir
tambahan.
9.
Pemberitahuan
pengguna bahwa system siap untuk operasi yang normal.
10. Lakukan sesi wawancara postmortem
Gunakan hasilnya dari sesi ini untuk meningkatkan perencanaan disaster
recovery anda.
Crash Kit
1. Apa
Sebuah crash kit berisi semua yang dibutuhkan untuk:
+ membangun kembali server R/3
+ menginstal ulang R/3
+ merecover database R/3 dan
file-file yang berhubungan
2.Mengapa
Selama disaster, semua yang dibutuhkan untuk merecover lingkungan R/3
diisi satu (atau beberapa) kontainer. Jika anda harus memindahkan lokasi, anda
tidak akan memiliki waktu untuk run around , mengumpulkan item pada menit terakhir, berharap bahwa anda
mendapatkan semua yang anda butuhkan.
Dalam sebuah disaster besar anda bahkan tidak akan memiliki kesempatan.
3.Dimana
|
|
Saat perubahan dibuat
pada komponen(hardware atau software) di server, gantikan item lama di crash
kit dengan item yang baru yang telah dites
|
Tinjauan secara periodic dari crash kit seharusnya
dilakukan untuk menentukan jika item perlu untuk ditambah atau dirubah. Sebuah
kontrak servis adalah sebuah contoh sempurna dari satu item yang memerlukan
tinjaua tipe ini.
Dimana meletakkan crash kit
Crash kit seharusnya
secara fisik dipisahkan dari server. Jika dilokasikan di ruang server, dan
ruang server hancur, crash kitnya juga hancur.
Beberapa area
penyimpanan crash kit terdiri dari:
§
Penyimpanan
data offsite komersial
§
Lokasi
perusahaan lain
§
Bagian
gedung lainnya yang aman
3.Bagaimana
Berikut ini adalah
daftar inventarisasi dari beberapa item utama yang masuk ke crash kit. Anda
akan membutuhkan untuk menambah atau menghapus item untuk lingkungan khusus
anda. Daftar inventarisasi di organisasikan ke kategori berikut ini:
§
Dokumentasi
§
Software
Dokumentasi
|
|
Sebuah inventory dari
crash kit seharusnya diambil oleh orang yang menyegel crash kit. Jika
segelnya rusak, item telah dipindahkan atau dirubah, membuat menjadi tidak
berguna crash kit di recovery
|
Daftar inventarisasi
berikut ini harus ditanda tangani dan diberi tanggal oleh orang yang memeriksa
crash kit. Dokumentasi berikut ini harus dimasukkan ke crash kit:
1. Skrip disaster recovery
- Perintah-perintah instalasi untuk:
- Sistem operasi
- Database
- Sistem R/3
- Perintah-perintah instalasi khusus untuk:
- Driver yang harus diinstal secara manual
- Program yang harus diinstal secara khusus
- Salinan dari:
·
Lisensi
SAP untuk semua instance
·
Perjanjian
layanan (dengan nomer telepon) untuk semua server
|
|
Pastikan bahwa
perjanjian pemeliharaan adalah masih valid dan pemeriksaan jika perjanjiannya
berakhir. Hal ini seharusnya menjadi bagian dari sebuah schedule task(tugas
terjadwal) biasa
|
- Perintah-perintah untuk penarikan kembali
tape dari penyimpanan data offsite
- Daftar dari personil yang diberi hak
untuk penarikan kembali tape dari penyimpanan data offsite.
Daftar ini harus sesuai dengan daftar terpelihara oleh perusahaan data
penyimpan.
- Daftar perangkat
Jika servernya rusak, daftar ini seharusnya cukup detil untuk membeli
atau minimal mengganti hardware. Lebih dari waktu yang disediakan, jika komponen asli tidak lagi
tersedia, daftar perangkat alternatif harus dipersiapkan. Pada poin ini, anda
harus mempertimbangkan ugrade perangkat anda.
- Layout system file
- Layout hardware
Anda perlu ketahui adalah:
·
Kartu ditempatkan
pada slot yang mana
·
Kabel
dipasang dimana(konektor dengan konektor)
Pelabelan kabel dan konektor sangat mengurangi kebingungan.
- Nomer telepon untuk:
·
Pengguna
utama
·
Personil
pelayanan informasi
·
Personil
fasilitas
·
Personil
infrastruktur lainnya
·
Konsultan(SAP,
jaringan, etc)
·
SAP
hotline
·
Penyimpanan
data offsite
·
Personil
atau departemen keamanan
·
Kontak
perjanjian layanan
·
Vendor
hardware
- Software
·
Sistem
operasi
1.
Perangkat
instalasi
2.
Driver
untuk hardware, seperti Network Interface Card(NIC) atau sebuah SCSI
Controller, yang tidak termasuk perangkat instalasi.
3.
Service
pack, update dan patch
·
Database
1.
Perangkat
instalasi
2.
Service
pack, update, dan patch
3.
Skrip
recovery, untuk mengotomasi recovery database
·
Untuk R/3
1.
Perangkat
instalasi
2.
Kernel
terinstal terkini
3.
File
system profile
4.
File
tpparam
5.
File
saprouttab
6.
Saplogon.ini
·
Program
R/3 terintegrasi lainnya(contoh paket pajak)
·
Software
lainnya untuk instalasi R/3:
1.
Utilitas
2.
Backup
3.
Program
control UPS
4.
Monitor
hardware
5.
Klien FTP
6.
Program
remote control
7.
Monitor
system
Kesinambungan Bisnis selama Recovery
Kesinambungan bisnis
selama sebuah recovery adalah sebuah proses alternative untuk melanjutkan
kegiatan bisnis selama me-recover dari disaster. Hal ini termasuk:
- Pengumpulan uang
- Pemrosesan pesanan
- Pengiriman produk
- Pembayaran tagihan
- Pemrosesan daftar gaji
- Lokasi alternative untuk kelanjutan
kegiatan bisnis
Mengapa
Tanpa proses alternative, perusahaan anda akan tidak bisa melakukan
bisnis.
Beberapa permasalahan anda akan hadapi termasuk:
- Pesanan tidak bisa dimasukkan
- Produk tidak bisa dikirimkan
- Uang tidak bisa dikumpulkan
Bagaimana
- Manual paper-based
- Produk PC stand-alone
Lokasi Offsite Disaster Recover
- Lokasi perusahaan lainnya
- Lokasi disaster recovery komersial
- Bagi pakai atau sewa ruang dari perusahaan
lainnya
1.10 Integrasi dengan Perencanaan Umum Disaster Perusahaan Anda.
Karena ada beberapa
kebergantungan, proses disaster recovery R/3 harus diintegrasikan dengan
perencanaan umum disaster perusahaan anda. Proses ini termasuk telepon,
jaringan, pengiriman produk, surat ,
dll.
Saat system R/3 kembali
Bagaimana transaksi
yang ditangani dengan proses alternative dimasukkan ke dalam R/3 saat R/3 nya
beroperasi?
Tes Prosedur Disaster Recovery Anda
|
|
Kecuali kalau anda
tes proses recovery, anda tidak akan mengetahui jika anda sebenarnya
me-recover sistem anda.
|
Sebuah tes adalah
simulasi disaster recovery yang menguji system recovery anda dan melatih setiap
tugas pada perencanaan dalam disaster recovery.
1. Tes untuk mencari tahu jika:
- Prosedur disaster recovery anda bekerja
- Sesuatu berubah, tidak terdokumentasi,
atau terupdate
Informasi yang jelas pada orang, prosedur terdokumentasi mungkin belum
jelas ke orang yang membaca dokumentasi.
- Hardware lama tidak lagi tersedia
Disini, perencanaan alternative diperlukan. Anda dapat melakukan upgrade
hardware anda menjadi kompatibel dengan perangkat tersedia terkini.
Karena banyak factor
berakibat pada recovery time, waktu recovery nyata dapat hanya ditetapkan
dengan melakukan tes. Sekali anda memiliki waktu nyata( tidak tebakan atau
perkiraan), perencanaan disaster anda menjadi lebih terpercaya. Jika prosedur
sering dipraktekkan, saat terjadi disaster, semya akan mengetahui apa yang dilakukan.
Dengan cara ini, kekacauan saat disaster akan berkurang.
Bagaimana
- Eksekusi perencanaan disaster recovery
anda pada sebuah system backup atau pada lokasi offsite
- Buatlah sebuah disaster recovery secara
acak
- Eksekusi perencanaan disaster anda untuk
mengetahui jika perencanaannya dapat menangani scenario
Kapan
Sebuah disaster
recovery penuh seharusnya dipraktekkan paling sedikit sekali setahun.
Dimana
- Tes disaster recovery seharusnya dilakukan
pada lokasu yang sama yang anda harapkan untuk me-recover. Jika anda
memiliki lokasi recovery banyak, lakukan sebuah tes recovery pada tiap
lokasi. Perangkat, fasilitas, dan konfigurasi dapat berbeda untuk tiap
lokasi. Dokumentasikan semua item khusus yang perlu diselesaikan untuk
tiap lokasi. Anda tidak ingin untuk menemukan yang tidak bisa anda recover
pada sebuah lokasi setelah sebuah disaster terjadi.
- Sebuah server backup onsite
- Lokasi perusahaan lainnya
- Perusahaan lainnya dimana anda memiliki
perjanjian pendukung yang saling menguntungkan
- Sebuah perusahaan yang menyediakan lokasi
dan layanan disaster recovery.
Siapa seharusnya yang Berpartisipasi
- Personil utama dan backup yang akan
melakukan tugas selama disaster recovery sebenarnya.
- Persediaan seharusnya dibuat bahwa
personil utama tidak tersedia selama disaster recovery. Prosedur tes dapat
melibatkansecara acak mengambil sebuah nama dan mengumumkan bahwa orang
tersebut tidak dapat berpartisipasi. Prosedur ini menduplikasi situasi
yang nyata yang orang utama secara serius terluka atau terbunuh.
- Personil pada lokasi lainnya
- Integrasikan orang-orang ini ke dalam tes,
karena mereka dapat diperlukan untuk melakukan recovery selama disaster
nyata. Orang-orang ini akan mengisi personil yang tidak ada saat disaster.
1.11 Pertimbangan-pertimbangan lainnya
Aplikasi downstream dan upstream lainnya
Sebagai fungsi dalam
perusahaan, aplikasi up( atau down) stream lainnya juga perlu untuk direcover
dengan R/3. Beberapa dari aplikasi ini berhubungan erat sekali dengan R/3.
Aplikasi seharusnya dihitung dan dilindungi dalam perencanaan perusahaan.
|
|
Aplikasi yang
terletak pada hanya satu orang komputer desktop harus di back up pada lokasi
yang aman.
|
Lokasi Backup
|
|
Memiliki kontrak
dengan sebuah lokasi disaster recovery tidak menjamin bahwa lokasi akan
tersedia. Pada disaster regional, seperti gempa bumi atau banjir, beberapa
perusahaan lainnya akan bersaing untuk lokasi disaster komersial lainnya.
Pada situasi ini, anda tidak akan memiliki lokasi untuk me-recover, jika yang
lainnya telah memesannya sebelum anda
|
Lokasi backup darurat
mungkin tidak memiliki perangkat yang memiliki level kinerja yang sama dengan
system produksi anda. Kinerja yang berkurang dan throughput transaksi yang
harus dipertimbangkan.
Contohnya:
- Pengurangan batch terjadwal hanya pada
tugas yang kritis
- Hanya tugas bisnis penting yang akan
dilakukan selama recovery system
Meminimisasi Kesempatan untuk Sebuah Disaster
Meminimisasi Kesalahan Manusia
|
|
Beberapa bencana
disebabkan oleh kesalahan manusia, seperti kesalahan atau operator yang
lelah. Jangan lakukan tugas yang berbahaya saat anda lelah. Jika anda harus
melakukan sebuah tugas berbahaya, dapatkan pendapat kedua(meminta saran)
sebelum anda mulai.
|
Tugas yang berbahaya seharusnya di catat dan diperiksa termasuk untuk
pengujian langkah-langkah.
Tugas tersebut termasuk:
- Menghapus tes database
- Memeriksa bahwa perintah delete ada di
Tes, bukan Produksi, database.
- Pindahkan file
- Verifikasi file target(ditulis kembali)
adalah yang lama, bukan yang baru, file.
- Memformat drive baru
- Verifikasi bahwa drive yang diformat
adalah drive baru, bukan sebuah drive yang ada dengan data didalamnya.
Meminimasi Kegagalan Poin Tunggal
Sebuah kegagalan poin
tunggal adalah saat kegagalan dari sebuah komponen menyebabkan semua system
gagal.
Untuk meminimasi
kegagalan pon tunggal:
- Identifikasi kondisi dimana sebuah
kegagalan poin tunggal dapat terjadi
- Antisipasi apa yang akan terjadi jika
komponennya atau prosesnya gagal
- Eliminasi sebanyak mungkin kegagalan poin
tunggal sebagai praktek.
Praktek didefinisikan sebagai sebuah level kerja atau perbandingan biaya
level dari risiko dan kegagalan.
Tipe-tipe kegagalan poin tunggal termasuk:
- Server backup R/3 dilokasikan pada data
center yang sama sebagai server produksi R/3.
- Jika data centernya hancur, server backup
juga hancur.
- Semua server R/3 ada pada sirkuit listrik
tunggal
Jika saklar pemutus terbuka, semua pada sirkuit tersebut kehilangan tenaga,
dan semua server akan crash(mati).
Kegagalan cascade
Kegagalan cascade
adalah saat satu kegagalan men-trigger kegagalan tambahan, yang meningkatkan
kompleksitas dari sebuah masalah. Recovery-nya melibatkan perbaikan
permasalahan yang saling berhubungan.
|
|
Contoh: sebuah
kegagalan cascade
Sebagai tambahan,
kelebihan panas dapat merusak sesuatu, seperti:
|
Recovery menjadi
komplek karena:
- Perbaikan satu masalah tidak mengatasi
masalah lainnya atau merusak perangkat.
- Item tertentu tidak dapat di tes atau
diperbaiki hnga perangkat lainnya beroperasi.
Pada kasus ini, sebuah
system yang memonitor system AC atau suhu di ruang server dapat memberi sinyal
pada karyawan yang sesuai sebelu suhu di ruang server menjadi terlalu panas.
No comments:
Post a Comment
silahkan membaca dan berkomentar