Ketahanan Aplikasi: Pastikan Aplikasi Windows Tersedia

Pengenalan

Aplikasi Windows sering bergantung pada lebih banyak daripada pelayan yang menghosnya. Pangkalan data, perkhidmatan identiti, penyimpanan, pintu masuk, rangkaian dan titik akhir pengguna semuanya boleh mempengaruhi sama ada aplikasi tetap boleh digunakan semasa gangguan. Artikel ini menerangkan bagaimana pasukan IT boleh menilai kebergantungan tersebut, merancang ketahanan di sekitar aplikasi Windows yang sedia ada, memantau lapisan yang betul dan menguji sama ada pelan pemulihan benar-benar mengekalkan fungsi perniagaan yang bergantung kepada pengguna.

Apa itu Ketahanan Aplikasi?

Ketahanan aplikasi adalah keupayaan aplikasi dan infrastruktur di sekelilingnya untuk terus menyediakan fungsi penting semasa gangguan dan untuk pulih dengan boleh diramal selepas kegagalan.

Gangguan boleh menjadi kecil atau besar, dan puncanya boleh berbeza-beza dari kegagalan perkakasan atau sistem operasi, keruntuhan aplikasi, kemas kini yang gagal, gangguan pangkalan data, gangguan rangkaian, kegagalan pengesahan, kehabisan sumber, ketergantungan yang tidak tersedia atau insiden keselamatan.

Sebuah seni bina yang tahan lasak mengakui bahawa kegagalan adalah tidak dapat dielakkan, dan bukannya berusaha untuk mencegah setiap insiden, organisasi IT berusaha untuk mengehadkan impak setiap satu dan menetapkan prosedur pemulihan terkawal untuk mengekalkan atau memulihkan perkhidmatan.

Ketahanan Aplikasi Lebih Dari Waktu Aktif Pelayan

Kesilapan biasa adalah menggunakan ketersediaan pelayan sebagai proksi untuk ketersediaan aplikasi, yang berjalan di pelayan.

Untuk aplikasi perniagaan benar-benar tersedia, beberapa komponen perlu tersedia pada masa yang sama:

Infrastruktur → Sistem operasi → Aplikasi → Kebergantungan → Laluan akses → Sesi pengguna → Proses perniagaan

Masalah dengan mana-mana elemen dalam rantaian ini boleh mengakibatkan aplikasi tidak dapat diakses dengan berkesan.

Sebagai contoh, pelayan aplikasi mungkin sihat sementara pangkalan datanya tidak dapat diakses. Aplikasi yang diterbitkan mungkin berfungsi dengan baik tetapi kegagalan pintu gerbang menjadikannya mustahil bagi pekerja jarak jauh untuk mengaksesnya. Pengguna mungkin berjaya melancarkan aplikasi tetapi dihalang daripada menyelesaikan transaksi kerana perkhidmatan pelesenan, fail atau backend tidak tersedia.

Ketahanan aplikasi, oleh itu, harus diukur berdasarkan kemampuan pengguna untuk melaksanakan tugas perniagaan yang diperlukan, bukannya sama ada pelayan dapat memberi respons kepada pemeriksaan ketersediaan atau kesihatan.

Mengapa Ketahanan Aplikasi Berbeza untuk Aplikasi Windows?

Amalan ketahanan moden semakin tertumpu kepada aplikasi asli awan, kontena, mikroservis dan orkestra automatik. Walaupun ini adalah pendekatan yang berharga, ia tidak selalu boleh digunakan untuk setiap organisasi.

Banyak organisasi mempunyai aplikasi perniagaan berasaskan Windows yang telah dibangunkan sebelum seni bina berasaskan awan menjadi biasa. Perisian ERP, aplikasi perakaunan, aplikasi pembuatan, aplikasi penjagaan kesihatan, aplikasi kejuruteraan dan aplikasi yang dibangunkan secara dalaman mungkin semuanya penting untuk operasi organisasi.

Merearchitect aplikasi ini sebagai mikroservis boleh menjadi sangat mahal, mencabar dari segi teknikal, atau bahkan tidak dapat dilaksanakan sama sekali jika organisasi tidak mengawal kod sumber.

Dalam kes seperti itu, mungkin terdapat nilai yang signifikan dalam menjadikan operasi di sekitar aplikasi lebih tahan lasak, daripada cuba menjadikan aplikasi itu sendiri lebih tahan lasak. Penerbitan aplikasi boleh menjadi sebahagian daripada pendekatan ini dengan mengekalkan aplikasi Windows sedia ada pada infrastruktur terpusat sambil mengubah cara pengguna mengaksesnya. Ini boleh termasuk perubahan pada infrastruktur yang menjadi tuan rumah aplikasi, seperti menghapuskan sekatan infrastruktur, mencipta hos aplikasi yang redundan, membolehkan kaedah akses alternatif dan melaksanakan prosedur pemulihan yang lebih responsif untuk hos aplikasi.

Dalam Kes Di Mana Ketersediaan Aplikasi Windows Boleh Gagal?

Membangunkan ketahanan aplikasi bermula dengan menemui komponen yang diperlukan untuk menyampaikan aplikasi dengan berjaya dari hos mereka kepada pengguna. Proses ini menonjolkan titik-titik kegagalan yang berpotensi yang boleh menjatuhkan keseluruhan aplikasi.

Hos Aplikasi

Aplikasi yang berjalan di atas satu pelayan Windows mempunyai satu titik kegagalan yang jelas.

Isu perkakasan, kemas kini Windows, kerosakan sistem operasi, kehabisan sumber atau kegagalan aplikasi boleh mengganggu setiap pengguna yang bergantung kepada mesin tersebut. Jika keperluan ketersediaan memerlukan, beberapa hos aplikasi boleh disediakan untuk mengurangkan kebergantungan pada mana-mana satu mesin dan menyediakan kapasiti apabila pelayan tidak tersedia.

Pangkalan Data, Penyimpanan dan Kebergantungan Lain

Banyak aplikasi Windows bergantung pada perkhidmatan luar kepada hos aplikasi. Perkhidmatan ini boleh termasuk:

• pangkalan data SQL
• kongsi fail
• pelayan pelesenan
• Active Directory
• Sistem Nama Domain (DNS)
• sijil
• APIs
• perisian pengantara
• penyimpanan rangkaian
• infrastruktur cetakan

Memperkenalkan pelayan aplikasi kedua memberikan ketahanan minimum jika mereka berkongsi pangkalan data atau kebergantungan storan yang tidak tersedia. Ia menjadi jelas bahawa pemetaan kebergantungan perlu diperluas melebihi infrastruktur aplikasi yang boleh dilihat.

Pengesahan dan Identiti

Pengguna tidak dapat mengakses aplikasi yang sihat jika infrastruktur pengesahan yang diperlukan tidak tersedia.

Pasukan IT perlu mengenal pasti perkhidmatan identiti yang bergantung kepada aplikasi kritikal mereka dan memastikan mereka mempunyai pelan pemulihan yang sedia untuk digunakan apabila sumber ini tidak dapat diakses. Active Directory, platform identiti awan, perkhidmatan pengesahan pelbagai faktor (MFA) dan pintu masuk pengesahan semuanya boleh diharapkan untuk menyediakan rantaian ketersediaan bagi aplikasi.

Jalur Rangkaian dan Akses Jauh

Untuk aplikasi Windows yang terpusat, sambungan antara pengguna dan persekitaran aplikasi mewakili satu lagi domain kegagalan yang mungkin.

Mari kita bayangkan keseluruhan rantaian:

Peranti pengguna → Internet atau LAN → pintu gerbang → hos aplikasi → perkhidmatan backend

Kerosakan di mana-mana sahaja dalam rantaian ini boleh menghalang pengguna daripada melakukan tugas mereka walaupun aplikasi berfungsi dengan baik. Ini sangat relevan untuk organisasi teragih di mana aplikasi mungkin beroperasi di pusat data tetapi tidak dapat diakses oleh pengguna di lokasi lain.

Endpoints

Ketahanan aplikasi tidak semestinya memerlukan stesen kerja normal pengguna tersedia.

Memberikan pengguna yang diberi kuasa cara untuk mengakses aplikasi yang dihoskan secara pusat dari peranti alternatif atau melalui pelayar boleh memastikan akses, jika komputer riba tidak tersedia, pejabat tidak dapat diakses atau pekerja perlu bekerja dari lokasi yang berbeza.

Arsitektur penghantaran aplikasi boleh menjadi komponen strategi kesinambungan perniagaan yang lebih luas.

Apakah Proses Membangun Ketahanan Aplikasi untuk Aplikasi Windows?

Tiada satu teknologi pun yang menjadikan aplikasi tahan lasak. Pasukan IT sebaliknya perlu mengurangkan bilangan kegagalan yang boleh menyebabkan fungsi lengkap terhenti dan bersedia untuk mekanisme pemulihan terkawal bagi yang masih ada.

1. Kenal pasti Aplikasi dan Proses Perniagaan Kritikal

Tidak semua aplikasi memerlukan tahap perlindungan yang sama. Mulakan dengan menentukan aplikasi mana yang menyokong operasi utama, pengguna mana yang bergantung kepada mereka dan toleransi masa henti mereka.

Dua objektif pemulihan menterjemahkan keperluan perniagaan ke dalam spesifikasi teknikal. Panduan perancangan kontingensi NIST mendefinisikan Objektif Masa Pemulihan (RTO) dan Objektif Titik Pemulihan (RPO) sebagai parameter utama untuk menentukan keperluan pemulihan:

• Objektif Masa Pemulihan (RTO): tempoh waktu henti yang boleh diterima sebelum perkhidmatan dipulihkan.
• Objektif Titik Pemulihan (RPO): satu selang kehilangan data yang boleh diterima, diukur dalam masa.

Aplikasi yang digunakan secara intensif untuk memproses pesanan mungkin mempunyai RTO dalam beberapa minit, manakala aplikasi pelaporan kewangan yang dijalankan sekali seminggu boleh membenarkan beberapa hari waktu henti.

RTO dan RPO menentukan jenis perlindungan yang diperlukan untuk aplikasi: pemindahan segera, pemulihan perkhidmatan yang cepat atau sekadar prosedur pemulihan yang didokumentasikan.

2. Peta Rantaian Kebergantungan Aplikasi Sepenuhnya

Dokumenkan segala yang perlu ada untuk aplikasi menjalankan tugasnya.

Jangan berhenti pada executable atau pelayan Windows. Jangan lupa pangkalan data, penyimpanan, pengesahan, DNS, rangkaian, sijil, sistem pelesenan, pintu masuk dan perkhidmatan luaran.

Bagi setiap, tanya:

Apa yang akan berlaku kepada aplikasi jika ini hilang?

Latihan ini akan menonjolkan titik kegagalan tunggal yang tersembunyi dan menetapkan urutan pemulihan. Memulihkan hos aplikasi terlebih dahulu tidak banyak membantu jika pangkalan datanya, perkhidmatan identiti atau storan belum tersedia.

3. Buang Titik Kegagalan Tunggal yang Kritikal

Setelah pokok kebergantungan ditubuhkan, tentukan komponen mana yang perlu dijadikan redundan, berdasarkan kepentingan perniagaan dan objektif pemulihan.

Dalam kes penghantaran aplikasi Windows, ini mungkin melibatkan penyebaran beberapa pelayan aplikasi daripada bergantung pada keupayaan satu hos tunggal. Dengan lapisan pengimbangan beban, sesi boleh disebarkan merentasi contoh aplikasi semasa operasi biasa. Dalam kes kegagalan hos, sambungan masuk boleh diarahkan ke contoh pelayan aplikasi yang sihat.

Perancangan redundansi harus dipandu oleh analisis kebergantungan, namun. Beberapa pelayan aplikasi yang mengakses satu pangkalan data kritikal, pintu gerbang rangkaian atau lapisan penyimpanan masih menghadirkan satu titik kegagalan.

Reka bentuk ketersediaan tinggi oleh itu mesti mempertimbangkan perkhidmatan aplikasi sebagai entiti yang terintegrasi. Untuk persekitaran Windows Server yang memerlukan redundansi tahap infrastruktur, Dokumentasi Kumpulan Kegagalan Microsoft memberikan panduan lanjut mengenai topologi ketersediaan tinggi dan pemulihan bencana.

4. Pisahkan Aplikasi Dari Titik Akhir Individu

Memasang aplikasi kritikal secara langsung di setiap stesen kerja pekerja boleh mencipta isu ketahanan yang berbeza. Jika pengguna kehilangan akses kepada komputer biasa mereka, mereka mungkin juga kehilangan akses kepada aplikasi yang mereka perlukan untuk meneruskan kerja.

Memusatkan aplikasi pada hos Windows yang diuruskan dan mempersembahkan antara muka aplikasi kepada pengguna menghapuskan risiko ini. Data dan keadaan aplikasi disimpan pada hos Windows yang diurus dan diakses oleh titik akhir yang diberi kuasa.

Dengan melakukan ini, kami menjadikan aplikasi tersedia kepada pengguna walaupun mereka menukar peranti atau lokasi. Walaupun memusatkan aplikasi tidak menghapuskan masalah infrastruktur, ia membantu untuk memindahkannya ke dalam persekitaran di mana ia dapat dikawal oleh IT.

5. Menyediakan Lebih Dari Satu Kaedah Akses Praktikal

Ketahanan juga boleh dicapai dengan mengelakkan kebergantungan yang tidak perlu pada satu jenis titik akhir atau kaedah sambungan.

Bergantung pada seni bina penghantaran aplikasi, pengguna boleh menggunakan yang berbeza Akses jauh kaedah, termasuk klien yang serasi dengan RDP, pelancar aplikasi khusus, portal web atau sesi pelayar HTML5.

Kaedah sambungan alternatif tidak boleh dikelirukan dengan redundansi infrastruktur. Jika semuanya bergantung pada pelayan yang sama yang gagal, aplikasi masih tidak tersedia.

Mereka menyediakan ketahanan akses apabila gangguan mempengaruhi peranti normal pengguna, klien yang dipasang atau lokasi dan bukannya perkhidmatan aplikasi itu sendiri.

6. Pantau Sebelum Kemerosotan Menjadi Gangguan

Ketahanan aplikasi bukan hanya tentang pemulihan, tetapi pengesanan yang cukup awal dapat mengelakkan kemerosotan menjadi gangguan.

Indikator yang berguna dalam persekitaran aplikasi Windows adalah penggunaan CPU, tekanan memori, kapasiti cakera dan I/O, penggunaan rangkaian, sesi aktif, proses aplikasi, masa respons, sambungan yang gagal dan ketersediaan perkhidmatan bergantung.

Pemantauan tren adalah penting, kerana pelayan yang berulang kali mendekati hadnya masih boleh dalam talian sementara pengalaman pengguna secara beransur-ansur merosot.

Amaran ambang membolehkan pentadbir menyiasat pendahuluan sesuatu insiden sebelum pengguna kehilangan akses.

7. Rancang untuk Lonjakan Kapasiti dan Kegagalan

Aplikasi yang bertahan daripada kegagalan peringkat perkakasan tetapi tidak dapat berfungsi sepenuhnya di bawah permintaan yang meningkat tidak benar-benar tahan terhadap kegagalan dalam apa jua bentuk.

Perancangan untuk kapasiti mesti mengambil kira bukan sahaja corak penggunaan harian tetapi juga mempertimbangkan puncak disebabkan oleh permintaan bermusim, perubahan syif, pertumbuhan, atau keperluan penghosan untuk aplikasi lain.

Terutama dalam persekitaran hosting pelayan pelbagai, kehilangan satu pelayan mesti diambil kira dengan memastikan bahawa nod hosting lain mempunyai kapasiti tambahan untuk menampung sebarang proses yang sebaliknya akan dilaksanakan pada nod yang gagal.

Jika tidak, prosedur fail-over mungkin hanya akan mengubah insiden terasing menjadi masalah prestasi sistem yang lebih luas.

8. Lindungi Data dan Konfigurasi

Pengganti pelayan Windows tidak berguna jika IT tidak dapat memulihkan komponen yang diperlukan untuk membuat aplikasi berfungsi.

Ini mungkin bermakna bahawa prosedur sandaran perlu merangkumi data aplikasi, pangkalan data, fail konfigurasi, sijil, tetapan aplikasi, profil pengguna, konfigurasi infrastruktur, skrip dan maklumat pelesenan.

Strategi akan berbeza bergantung kepada Objektif Masa Pemulihan (RTO) dan Objektif Titik Pemulihan (RPO) aplikasi.

Di atas segalanya, pastikan bahawa sandaran yang berjaya tidak sama dengan pemulihan yang berjaya. Pasukan IT harus menguji bahawa adalah mungkin untuk memulihkan keseluruhan perkhidmatan aplikasi daripada data dan konfigurasi yang dilindungi.

Kurangkan Radius Letupan Perubahan

Ia bukan selalu kes bencana yang tidak dijangka yang menyebabkan gangguan. Ia juga boleh disebabkan oleh penambahbaikan yang dilaksanakan. Oleh itu, tampalan Windows, peningkatan aplikasi dan pemacu, dasar keselamatan dan perubahan konfigurasi juga boleh memberi kesan negatif terhadap ketersediaan aplikasi. Adalah disyorkan untuk mengelakkan membuat perubahan serupa kepada semua hos pengeluaran pada masa yang sama jika boleh.

Dalam persediaan pelayan berganda, adalah mungkin untuk melaksanakan perubahan peningkatan secara berperingkat, dengan itu membolehkan pentadbir memastikan semuanya berfungsi dengan betul. Kebolehan untuk mengembalikan perubahan yang dibuat juga penting.

Oleh itu, semasa merancang prosedur kontingensi, pilihan pemulihan juga harus dipertimbangkan. Proses tersebut harus didokumentasikan dengan betul, dan kakitangan harus tahu apa yang perlu dilakukan jika perubahan gagal, bukannya hanya membiarkannya kepada budi bicara mereka.

10. Reka Bentuk untuk Penurunan yang Anggun

Ketahanan bukan tentang memastikan 100% fungsi normal beroperasi dan berjalan pada setiap masa.

Dalam beberapa kes, mengekalkan operasi untuk pengguna atau aplikasi utama mungkin lebih penting daripada memastikan semua perkhidmatan tersedia untuk semua pengguna. Keutamaan boleh ditetapkan sebelum insiden berlaku oleh pasukan IT.

Jika terdapat kapasiti yang tersedia yang boleh digunakan, adalah wajar untuk mengagihkannya terlebih dahulu kepada pengeluaran, perkhidmatan pelanggan, kewangan atau fungsi lain.

Itu adalah pengurangan yang anggun: mengekalkan keupayaan untuk menjalankan fungsi yang menghasilkan nilai perniagaan yang paling tinggi, bukannya membiarkan kegagalan elemen yang kurang kritikal menyebabkan keseluruhan sistem terhempas.

Bagaimana Pasukan IT Perlu Memantau Ketahanan Aplikasi?

Memantau pelayan individu mungkin berguna, tetapi pemantauan ketahanan harus mencerminkan keseluruhan perkhidmatan aplikasi seperti yang dilihat oleh pengguna.

Model yang realistik terdiri daripada beberapa lapisan:

Lapisan	Apa yang Perlu Dipantau	Contoh Kegagalan
Host	CPU, RAM, cakera, ketersediaan OS	Pelayan terlalu banyak beban atau tidak dalam talian
Aplikasi	Status proses dan perkhidmatan	Kejatuhan aplikasi
Kebergantungan	Pangkalan Data, DNS, identiti, penyimpanan	Aplikasi dilancarkan tetapi tidak dapat beroperasi
Akses	Gerbang, portal, laluan rangkaian	Pengguna tidak dapat menyambung
Sesi	Pengguna aktif, kegagalan, latensi	Aplikasi dalam talian tetapi tidak boleh digunakan
Fungsi perniagaan	Penyelesaian aliran kerja yang berjaya	Pengguna tidak dapat menyelesaikan tugas yang diperlukan

Lapisan fungsi perniagaan adalah salah satu yang paling mudah diabaikan.

Papan pemuka infrastruktur mungkin menunjukkan semua pelayan, perkhidmatan dan laluan rangkaian sebagai sihat, sementara aliran kerja pengguna sebenar terjejas. Oleh itu, adalah penting bagi aplikasi kritikal untuk memantau kesihatan mereka dari perspektif operasi yang mereka direka untuk menyokong.

Bagaimana Ketahanan Aplikasi Harus Diuji?

Sebuah seni bina ketahanan yang tidak pernah mengalami kegagalan terkawal mengandungi andaian yang belum diuji.

Gunakan ujian untuk menilai respons sistem apabila komponen utama tidak tersedia. Ujian harus merangkumi mengambil hos aplikasi dalam talian, menghentikan perkhidmatan aplikasi, mensimulasikan kehilangan laluan rangkaian, mengesahkan tingkah laku gerbang atau pengimbangan beban, memulihkan dari sandaran dan mengakses aplikasi dari titik akhir alternatif.

Proses ujian harus melampaui aspek teknikal pemulihan. Pasukan IT harus menyemak sama ada amaran dihantar kepada kakitangan pentadbiran yang betul, langkah pemulihan dilaksanakan dalam urutan yang betul, dan pengguna dapat melaksanakan tugas perniagaan sebenar setelah perkhidmatan dipulihkan.

Prosedur operasi adalah integral kepada sistem yang tahan lasak. Prosedur peningkatan amaran: siapa yang menerima amaran? Siapa yang mempunyai kuasa untuk memulakan failover? Di manakah dokumentasi pemulihan dan kelayakan disimpan? Ketergantungan manakah yang perlu dalam talian terlebih dahulu?

Redundansi teknikal memberikan sedikit manfaat jika proses untuk mendapatkan semula akses tidak telah diuji.

Apakah Senarai Semak Ketahanan Aplikasi?

Sebelum memulakan aplikasi Windows yang kritikal dan tahan lasak, pasukan IT harus dapat menjawab soalan-soalan berikut:

• Proses perniagaan manakah yang bergantung pada aplikasi tersebut?
• Apakah RTO dan RPO-nya?
• Server, pangkalan data dan perkhidmatan luaran manakah yang diperlukan?
• Di manakah titik kegagalan tunggal kritikalnya?
• Bolehkah hos aplikasi lain menerima pengguna jika satu hos gagal?
• Bolehkah pengguna menyambung jika titik akhir atau lokasi biasa mereka tidak tersedia?
• Adakah terdapat kapasiti simpanan yang mencukupi untuk operasi terjejas?
• Adakah masalah infrastruktur, kebergantungan dan sesi dipantau secara aktif?
• Adakah pentadbir diberi amaran sebelum ambang penting menjadi gangguan?
• Adakah data aplikasi dan konfigurasi dilindungi?
• Adakah pemulihan sebenarnya telah diuji?
• Bolehkah perubahan yang bermasalah dipulihkan semula?
• Adakah urutan pemulihan didokumentasikan?
• Bolehkah pengguna menyelesaikan proses perniagaan yang diperlukan selepas pemulihan?

Tidak semua jawapan memerlukan infrastruktur ketersediaan tinggi yang mahal. Tahap perlindungan yang betul bergantung kepada kos dan impak operasi waktu henti.

Apa yang penting adalah bahawa keputusan mengenai ketersediaan, redundansi dan pemulihan dibuat dengan sengaja, bukannya diandaikan.

Bagaimana TSplus Boleh Membantu Menjaga Aplikasi Windows Tersedia?

Bagi organisasi yang bergantung pada aplikasi Windows yang sedia ada, kami dapat membantu meningkatkan ketersediaan dengan memusatkan aplikasi pada pelayan Windows yang diurus dan menyampaikannya kepada pengguna melalui klien yang serasi dengan RDP, akses gaya RemoteApp atau portal web HTML5. Ini mengurangkan kebergantungan pada titik akhir pengguna individu dan memberikan pasukan IT lebih fleksibiliti apabila pengguna perlu menyambung dari peranti atau lokasi lain.

TSplus Remote Access juga boleh menyokong penyebaran pelayan pelbagai dengan pengimbangan beban dan akses berasaskan pintu gerbang. Apabila digabungkan dengan pangkalan data yang tahan lasak, penyimpanan, perkhidmatan identiti dan rangkaian, seni bina ini dapat mengurangkan kebergantungan pada hos aplikasi tunggal dan membantu mengekalkan akses kepada aplikasi Windows kritikal semasa gangguan infrastruktur.

Kesimpulan

Ketahanan aplikasi bergantung kepada pemahaman tentang laluan lengkap antara infrastruktur dan penggunaan perniagaan. Redundansi, pemantauan, sandaran, perancangan kapasiti dan prosedur pemulihan adalah paling berkesan apabila mereka direka berdasarkan kebergantungan aplikasi dan objektif pemulihan yang ditakrifkan dengan jelas.

Bagi aplikasi Windows yang sedia ada, ketahanan sering datang daripada mengukuhkan persekitaran di sekitar perisian daripada membina semula aplikasi itu sendiri. Ujian utama tetap mudah: apabila gangguan berlaku, bolehkah pengguna terus bekerja, atau bolehkah IT memulihkan fungsi perniagaan yang diperlukan dalam tempoh pemulihan yang dipersetujui?