Ketahanan Aplikasi: Jaga Aplikasi Windows Tetap Tersedia

Pengantar

Aplikasi Windows sering kali bergantung pada lebih banyak hal daripada server yang menghostingnya. Basis data, layanan identitas, penyimpanan, gerbang, jaringan, dan titik akhir pengguna semuanya dapat mempengaruhi apakah sebuah aplikasi tetap dapat digunakan selama gangguan. Artikel ini menjelaskan bagaimana tim TI dapat menilai ketergantungan tersebut, merancang ketahanan di sekitar aplikasi Windows yang ada, memantau lapisan yang tepat, dan menguji apakah rencana pemulihan benar-benar mempertahankan fungsi bisnis yang diandalkan pengguna.

Apa itu Ketahanan Aplikasi?

Ketahanan aplikasi adalah kemampuan sebuah aplikasi dan infrastruktur di sekitarnya untuk terus menyediakan fungsi vital selama gangguan dan untuk pulih secara terduga setelah kegagalan.

Gangguan dapat bersifat kecil atau besar, dan penyebabnya dapat bervariasi mulai dari kegagalan perangkat keras atau sistem operasi, kerusakan aplikasi, pembaruan yang gagal, pemadaman basis data, gangguan jaringan, kegagalan otentikasi, kehabisan sumber daya, ketergantungan yang tidak tersedia, atau insiden keamanan.

Arsitektur yang tangguh mengakui bahwa kegagalan adalah hal yang tidak terhindarkan, dan alih-alih berusaha mencegah setiap insiden, organisasi TI berupaya membatasi dampak dari masing-masing insiden dan menetapkan prosedur pemulihan yang terkontrol untuk mempertahankan atau memulihkan layanan.

Ketahanan Aplikasi Lebih Dari Waktu Aktif Server

Kesalahan umum adalah menggunakan ketersediaan server sebagai proksi untuk ketersediaan aplikasi, yang berjalan di server.

Agar aplikasi bisnis benar-benar tersedia, sejumlah komponen perlu tersedia pada saat yang sama:

Infrastruktur → Sistem operasi → Aplikasi → Ketergantungan → Jalur akses → Sesi pengguna → Proses bisnis

Masalah dengan elemen mana pun dalam rantai ini dapat mengakibatkan aplikasi tidak tersedia secara efektif.

Misalnya, server aplikasi mungkin dalam keadaan sehat sementara basis datanya tidak dapat diakses. Aplikasi yang dipublikasikan mungkin berfungsi dengan baik tetapi kegagalan gateway membuatnya tidak mungkin bagi karyawan jarak jauh untuk mengaksesnya. Pengguna bahkan mungkin berhasil meluncurkan aplikasi tetapi terhalang untuk menyelesaikan transaksi karena lisensi, file, atau layanan backend tidak tersedia.

Ketahanan aplikasi, oleh karena itu, harus diukur berdasarkan kemampuan pengguna untuk melakukan tugas bisnis yang diperlukan, bukan pada apakah server dapat merespons pemeriksaan ketersediaan atau kesehatan.

Mengapa Ketahanan Aplikasi Berbeda untuk Aplikasi Windows?

Praktik ketahanan modern semakin fokus pada aplikasi berbasis cloud, kontainer, mikroservis, dan orkestrasi otomatis. Meskipun ini adalah pendekatan yang berharga, mereka tidak selalu dapat diterapkan pada setiap organisasi.

Banyak organisasi memiliki aplikasi bisnis berbasis Windows yang dikembangkan sebelum arsitektur berbasis cloud menjadi umum. Perangkat lunak ERP, aplikasi akuntansi, aplikasi manufaktur, aplikasi kesehatan, aplikasi rekayasa, dan aplikasi yang dikembangkan secara internal mungkin semuanya penting untuk operasi suatu organisasi.

Merekonfigurasi aplikasi ini sebagai mikroservis bisa sangat mahal, secara teknis menantang, atau bahkan sepenuhnya tidak dapat dilakukan jika organisasi tidak mengendalikan kode sumber.

Dalam kasus seperti itu, mungkin ada nilai signifikan dalam membuat operasi di sekitar aplikasi lebih tangguh, daripada mencoba membuat aplikasi itu sendiri lebih tangguh. Penerbitan aplikasi dapat menjadi bagian dari pendekatan ini dengan mempertahankan aplikasi Windows yang ada di infrastruktur terpusat sambil mengubah cara pengguna mengaksesnya. Ini dapat mencakup perubahan pada infrastruktur yang menghosting aplikasi, seperti menghilangkan batasan infrastruktur, menciptakan host aplikasi yang redundan, memungkinkan metode akses alternatif, dan menerapkan prosedur pemulihan yang lebih responsif untuk host aplikasi.

Dalam Kasus Apa Ketersediaan Aplikasi Windows Bisa Gagal?

Membangun ketahanan aplikasi dimulai dengan menemukan komponen yang diperlukan untuk berhasil mengirimkan aplikasi dari host mereka ke pengguna. Proses ini menyoroti titik-titik kegagalan potensial yang dapat menjatuhkan seluruh aplikasi.

Host Aplikasi

Aplikasi yang berjalan di satu server Windows memiliki satu titik kegagalan yang jelas.

Masalah perangkat keras, pembaruan Windows, kerusakan sistem operasi, kehabisan sumber daya, atau kegagalan aplikasi dapat mengganggu setiap pengguna yang bergantung pada mesin tersebut. Jika kebutuhan ketersediaan memerlukan, beberapa host aplikasi dapat diterapkan untuk mengurangi ketergantungan pada satu mesin dan menyediakan kapasitas ketika server menjadi tidak tersedia.

Basis Data, Penyimpanan, dan Ketergantungan Lainnya

Banyak aplikasi Windows bergantung pada layanan eksternal dari host aplikasi. Layanan ini dapat mencakup:

• basis data SQL
• berbagi file
• server lisensi
• Active Directory
• Sistem Nama Domain (DNS)
• sertifikat
• APIs
• perantara
• penyimpanan jaringan
• infrastruktur cetak

Memperkenalkan server aplikasi kedua memberikan ketahanan minimal jika mereka berbagi ketergantungan basis data atau penyimpanan yang umum yang tidak tersedia. Jelas bahwa pemetaan ketergantungan perlu diperluas melampaui infrastruktur aplikasi yang terlihat.

Autentikasi dan Identitas

Pengguna tidak dapat mengakses aplikasi yang sehat jika infrastruktur autentikasi yang diperlukan tidak tersedia.

Tim IT perlu mengidentifikasi layanan identitas yang bergantung pada aplikasi kritis mereka dan memastikan mereka memiliki rencana pemulihan yang siap ketika sumber daya ini tidak dapat diakses. Active Directory, platform identitas cloud, layanan otentikasi multi-faktor (MFA), dan gerbang otentikasi semuanya dapat diandalkan untuk menyediakan rantai ketersediaan bagi sebuah aplikasi.

Jaringan dan Jalur Akses Jarak Jauh

Untuk aplikasi Windows terpusat, konektivitas antara pengguna dan lingkungan aplikasi mewakili domain kegagalan lain yang mungkin terjadi.

Mari kita bayangkan seluruh rantai:

Perangkat pengguna → Internet atau LAN → gerbang → host aplikasi → layanan backend

Kegagalan di mana saja dalam rantai ini dapat menghalangi pengguna untuk melakukan pekerjaan mereka meskipun aplikasi berjalan dengan baik. Ini sangat relevan untuk organisasi terdistribusi di mana aplikasi mungkin berjalan di pusat data tetapi tidak dapat diakses oleh pengguna di lokasi lain.

Endpoints

Ketahanan aplikasi tidak selalu memerlukan workstation normal pengguna untuk tersedia.

Menawarkan pengguna yang berwenang cara untuk mengakses aplikasi yang dihosting secara terpusat dari perangkat alternatif atau melalui browser dapat memastikan akses, jika laptop tidak tersedia, kantor menjadi tidak dapat diakses, atau karyawan perlu bekerja dari lokasi yang berbeda.

Arsitektur pengiriman aplikasi dapat menjadi komponen dari strategi keberlangsungan bisnis yang lebih luas.

Apa Proses Membangun Ketahanan Aplikasi untuk Aplikasi Windows?

Tidak ada teknologi tunggal yang membuat aplikasi tahan banting. Tim TI sebaliknya harus mengurangi jumlah kegagalan yang dapat menghentikan fungsi secara keseluruhan dan mempersiapkan mekanisme pemulihan terkontrol untuk yang tetap ada.

1. Identifikasi Aplikasi dan Proses Bisnis Kritis

Tidak semua aplikasi memerlukan tingkat perlindungan yang sama. Mulailah dengan menentukan aplikasi mana yang mendukung operasi utama, pengguna mana yang bergantung pada mereka, dan toleransi waktu henti mereka.

Dua tujuan pemulihan menerjemahkan kebutuhan bisnis menjadi spesifikasi teknis. Panduan perencanaan kontinjensi NIST mendefinisikan Recovery Time Objective (RTO) dan Recovery Point Objective (RPO) sebagai parameter kunci untuk menentukan kebutuhan pemulihan:

• Objective Waktu Pemulihan (RTO): durasi waktu henti yang dapat diterima sebelum layanan dipulihkan.
• Recovery Point Objective (RPO): interval kehilangan data yang dapat diterima, diukur dalam waktu.

Aplikasi yang digunakan secara intensif untuk memproses pesanan mungkin memiliki RTO dalam hitungan menit, sedangkan aplikasi pelaporan keuangan yang dijalankan sekali seminggu dapat mentolerir waktu henti selama beberapa hari.

RTO dan RPO mendefinisikan jenis perlindungan yang diperlukan untuk sebuah aplikasi: failover instan, pemulihan layanan yang cepat, atau sekadar prosedur pemulihan yang terdokumentasi.

2. Peta Seluruh Rantai Ketergantungan Aplikasi

Dokumentasikan semua yang harus ada agar aplikasi dapat menjalankan fungsinya.

Jangan berhenti di executable atau server Windows. Jangan lupakan basis data, penyimpanan, otentikasi, DNS, jaringan, sertifikat, sistem lisensi, gateway, dan layanan eksternal.

Untuk setiap, tanyakan:

Apa yang terjadi pada aplikasi jika ini hilang?

Latihan ini akan mengungkap titik kegagalan tunggal yang tersembunyi dan menetapkan urutan pemulihan. Memulihkan host aplikasi terlebih dahulu tidak banyak membantu jika basis datanya, layanan identitas, atau penyimpanannya belum tersedia.

3. Hapus Titik Kritis Kegagalan Tunggal

Setelah pohon ketergantungan ditetapkan, tentukan komponen mana yang harus dibuat redundan, berdasarkan pentingnya bisnis dan tujuan pemulihan.

Dalam kasus pengiriman aplikasi Windows, ini dapat melibatkan penyebaran beberapa server aplikasi daripada mengandalkan kemampuan satu host. Dengan lapisan penyeimbang beban, sesi dapat dibagikan di antara instance aplikasi selama operasi normal. Dalam kasus kegagalan host, koneksi yang masuk dapat diarahkan ke instance server aplikasi yang sehat.

Perencanaan redundansi harus diinformasikan oleh analisis ketergantungan, namun. Beberapa server aplikasi yang mengakses satu basis data kritis, gerbang jaringan, atau lapisan penyimpanan masih menghadirkan satu titik kegagalan.

Desain ketersediaan tinggi harus mempertimbangkan layanan aplikasi sebagai entitas terintegrasi. Untuk lingkungan Windows Server yang memerlukan redundansi tingkat infrastruktur, Dokumentasi Failover Clustering Microsoft memberikan panduan lebih lanjut tentang topologi ketersediaan tinggi dan pemulihan bencana.

4. Pisahkan Aplikasi Dari Titik Akhir Individu

Menginstal aplikasi kritis secara langsung di setiap workstation karyawan dapat menciptakan masalah ketahanan yang berbeda. Jika pengguna kehilangan akses ke komputer reguler mereka, mereka mungkin juga kehilangan akses ke aplikasi yang mereka butuhkan untuk melanjutkan pekerjaan.

Memusatkan aplikasi pada host Windows yang dikelola dan menyajikan antarmuka aplikasi kepada pengguna menghilangkan risiko ini. Data dan status aplikasi disimpan di host Windows yang dikelola dan diakses oleh titik akhir yang berwenang.

Dengan melakukan ini, kami membuat aplikasi tersedia untuk pengguna meskipun mereka mengganti perangkat atau lokasi. Meskipun memusatkan aplikasi tidak menghilangkan masalah infrastruktur, ini membantu untuk memindahkannya ke dalam lingkungan di mana dapat dikendalikan oleh TI.

5. Sediakan Lebih Dari Satu Metode Akses Praktis

Ketahanan juga dapat dicapai dengan menghindari ketergantungan yang tidak perlu pada satu jenis endpoint atau metode koneksi.

Bergantung pada arsitektur pengiriman aplikasi, pengguna dapat menggunakan berbagai remote access metode, termasuk klien yang kompatibel dengan RDP, peluncur aplikasi khusus, portal web atau sesi browser HTML5.

Metode koneksi alternatif tidak boleh disamakan dengan redundansi infrastruktur. Jika semuanya bergantung pada server yang sama yang gagal, aplikasi tetap tidak tersedia.

Mereka memang menyediakan ketahanan akses ketika gangguan mempengaruhi perangkat normal pengguna, klien yang terinstal, atau lokasi daripada layanan aplikasi itu sendiri.

6. Monitor Sebelum Penurunan Menjadi Gangguan

Ketahanan aplikasi tidak hanya tentang pemulihan, tetapi deteksi yang cukup awal dapat menghindari penurunan menjadi gangguan.

Indikator yang berguna dalam lingkungan aplikasi Windows adalah pemanfaatan CPU, tekanan memori, kapasitas disk dan I/O, pemanfaatan jaringan, sesi aktif, proses aplikasi, waktu respons, koneksi yang gagal, dan ketersediaan layanan yang bergantung.

Pemantauan tren sangat penting, karena server yang berulang kali mendekati batasnya masih dapat online sementara pengalaman pengguna secara bertahap memburuk.

Peringatan ambang memungkinkan administrator untuk menyelidiki pendahulu dari suatu insiden sebelum pengguna kehilangan akses.

7. Rencanakan Lonjakan Kapasitas dan Failover

Sebuah aplikasi yang bertahan dari kegagalan tingkat perangkat keras tetapi tidak dapat berfungsi sama sekali di bawah tuntutan yang meningkat tidak benar-benar tahan terhadap kegagalan dalam bentuk apa pun.

Perencanaan kapasitas harus mempertimbangkan tidak hanya pola penggunaan sehari-hari tetapi juga memperhitungkan puncak akibat permintaan musiman, perubahan shift, pertumbuhan, atau kebutuhan hosting untuk aplikasi lain.

Terutama dalam lingkungan hosting multi-server, kehilangan satu server harus diperhitungkan dengan memastikan bahwa node hosting lainnya memiliki kapasitas cadangan untuk mengakomodasi proses apa pun yang seharusnya dijalankan di node yang gagal.

Jika tidak, prosedur fail-over dapat dengan mudah mengubah insiden terisolasi menjadi masalah kinerja sistem yang luas.

8. Lindungi Data dan Konfigurasi

Pengganti server Windows tidak ada gunanya jika TI tidak dapat memulihkan komponen yang diperlukan untuk membuat aplikasi berfungsi.

Ini bisa berarti bahwa prosedur cadangan perlu mencakup data aplikasi, basis data, file konfigurasi, sertifikat, pengaturan aplikasi, profil pengguna, konfigurasi infrastruktur, skrip, dan informasi lisensi.

Strategi akan bervariasi tergantung pada Tujuan Waktu Pemulihan (RTO) dan Tujuan Titik Pemulihan (RPO) aplikasi.

Di atas segalanya, pastikan bahwa cadangan yang berhasil tidak sama dengan pemulihan yang berhasil. Tim TI harus menguji bahwa mungkin untuk memulihkan seluruh layanan aplikasi dari data dan konfigurasi yang dilindungi.

9. Mengurangi Jangkauan Ledakan Perubahan

Tidak selalu merupakan kasus bencana yang tidak terduga yang menyebabkan gangguan. Mereka juga dapat disebabkan oleh perbaikan yang diterapkan. Oleh karena itu, patch Windows, peningkatan aplikasi dan driver, kebijakan keamanan, dan perubahan konfigurasi juga dapat berdampak negatif pada ketersediaan aplikasi. Disarankan untuk menghindari melakukan perubahan serupa pada semua host produksi sekaligus jika memungkinkan.

Dalam pengaturan multi-server, dimungkinkan untuk melakukan perubahan perbaikan secara bertahap, sehingga memungkinkan administrator untuk memastikan semuanya berfungsi dengan baik. Kemampuan untuk membatalkan perubahan yang dilakukan juga sangat penting.

Oleh karena itu, saat merancang prosedur kontingensi, opsi rollback juga harus dipertimbangkan. Proses tersebut harus didokumentasikan dengan baik, dan staf harus tahu apa yang harus dilakukan jika suatu perubahan gagal, alih-alih hanya menyerahkannya kepada kebijaksanaan mereka.

10. Desain untuk Degradasi yang Anggun

Ketahanan bukanlah tentang menjaga 100% fungsi normal tetap berjalan setiap saat.

Dalam beberapa kasus, mempertahankan operasi untuk pengguna atau aplikasi kunci mungkin lebih penting daripada menjaga semua layanan tersedia untuk semua pengguna. Prioritas dapat ditetapkan sebelum insiden terjadi oleh tim TI.

Jika ada kapasitas yang tersedia yang dapat digunakan, mungkin masuk akal untuk mengalokasikannya terlebih dahulu untuk produksi, layanan pelanggan, keuangan, atau fungsi lainnya.

Itu adalah degradasi yang anggun: mempertahankan kemampuan untuk menjalankan fungsi yang menghasilkan nilai bisnis terbesar, alih-alih membiarkan kegagalan elemen yang kurang kritis membuat seluruh sistem gagal.

Bagaimana Tim IT Harus Memantau Ketahanan Aplikasi?

Memantau server individu mungkin berguna, tetapi pemantauan ketahanan harus mencerminkan total layanan aplikasi seperti yang dipersepsikan oleh pengguna.

Model yang realistis terdiri dari beberapa lapisan:

Lapisan	Apa yang Harus Dipantau	Contoh Kegagalan
Host	CPU, RAM, disk, ketersediaan OS	Server kelebihan beban atau offline
Aplikasi	Status proses dan layanan	Aplikasi macet
Ketergantungan	Database, DNS, identitas, penyimpanan	Aplikasi diluncurkan tetapi tidak dapat beroperasi
Akses	Gerbang, portal, jalur jaringan	Pengguna tidak dapat terhubung
Sesi	Pengguna aktif, kegagalan, latensi	Aplikasi sedang online tetapi tidak dapat digunakan
Fungsi bisnis	Selesai menyelesaikan alur kerja	Pengguna tidak dapat menyelesaikan tugas yang diperlukan

Lapisan fungsi bisnis adalah salah satu yang paling sederhana untuk diabaikan.

Dasbor infrastruktur dapat menunjukkan semua server, layanan, dan jalur jaringan sebagai sehat, sementara alur kerja pengguna yang sebenarnya terganggu. Oleh karena itu, penting bagi aplikasi kritis untuk memantau kesehatan mereka dari perspektif operasi yang mereka dirancang untuk mendukung.

Bagaimana Seharusnya Ketahanan Aplikasi Diuji?

Arsitektur ketahanan yang belum pernah mengalami kegagalan terkontrol mengandung asumsi yang belum teruji.

Gunakan pengujian untuk mengevaluasi respons sistem ketika komponen kunci menjadi tidak tersedia. Pengujian harus mencakup mengambil host aplikasi offline, menghentikan layanan aplikasi, mensimulasikan kehilangan rute jaringan, memverifikasi perilaku gateway atau penyeimbangan beban, memulihkan dari cadangan, dan mengakses aplikasi dari titik akhir alternatif.

Proses pengujian harus melampaui aspek teknis pemulihan. Tim TI harus meninjau apakah peringatan dikirim ke personel administratif yang tepat, langkah-langkah pemulihan dilakukan dalam urutan yang benar, dan pengguna dapat melakukan tugas bisnis yang sebenarnya setelah layanan dipulihkan.

Prosedur operasional adalah bagian integral dari sistem yang tangguh. Prosedur eskalasi peringatan: siapa yang menerima peringatan? Siapa yang memiliki wewenang untuk memulai failover? Di mana dokumentasi pemulihan dan kredensial disimpan? Ketergantungan mana yang perlu diaktifkan terlebih dahulu?

Redundansi teknis memberikan sedikit manfaat jika proses untuk mendapatkan kembali akses belum diuji.

Apa yang Bisa Menjadi Daftar Periksa Ketahanan Aplikasi?

Sebelum memulai aplikasi Windows yang kritis dan tahan banting, tim TI harus dapat menjawab pertanyaan berikut:

• Proses bisnis mana yang bergantung pada aplikasi tersebut?
• Apa RTO dan RPO-nya?
• Server, basis data, dan layanan eksternal apa yang dibutuhkan?
• Di mana saja titik kegagalan kritisnya?
• Bisakah host aplikasi lain menerima pengguna jika satu host gagal?
• Bisakah pengguna terhubung jika endpoint atau lokasi normal mereka tidak tersedia?
• Apakah ada cukup kapasitas cadangan untuk operasi yang terdegradasi?
• Apakah masalah infrastruktur, ketergantungan, dan sesi dipantau secara aktif?
• Apakah administrator diberi tahu sebelum ambang batas penting menjadi gangguan?
• Apakah data aplikasi dan konfigurasi dilindungi?
• Apakah pemulihan benar-benar telah diuji?
• Bisakah perubahan yang bermasalah dibatalkan?
• Apakah urutan pemulihan didokumentasikan?
• Apakah pengguna dapat menyelesaikan proses bisnis yang diperlukan setelah pemulihan?

Tidak semua jawaban memerlukan infrastruktur ketersediaan tinggi yang mahal. Tingkat perlindungan yang tepat tergantung pada biaya dan dampak operasional dari waktu henti.

Yang penting adalah bahwa keputusan tentang ketersediaan, redundansi, dan pemulihan dibuat dengan sengaja, bukan diasumsikan.

Bagaimana TSplus Dapat Membantu Menjaga Aplikasi Windows Tetap Tersedia?

Untuk organisasi yang mengandalkan aplikasi Windows yang ada, kami dapat membantu meningkatkan ketersediaan dengan memusatkan aplikasi di server Windows yang dikelola dan menyampaikannya kepada pengguna melalui klien yang kompatibel dengan RDP, akses gaya RemoteApp, atau portal web HTML5. Ini mengurangi ketergantungan pada titik akhir pengguna individu dan memberikan tim TI lebih banyak fleksibilitas ketika pengguna perlu terhubung dari perangkat atau lokasi lain.

TSplus Remote Access juga dapat mendukung penyebaran multi-server dengan penyeimbangan beban dan akses berbasis gateway. Ketika digabungkan dengan basis data yang tangguh, penyimpanan, layanan identitas, dan jaringan, arsitektur ini dapat mengurangi ketergantungan pada satu host aplikasi dan membantu mempertahankan akses ke aplikasi Windows kritis selama gangguan infrastruktur.

Kesimpulan

Ketahanan aplikasi bergantung pada pemahaman jalur lengkap antara infrastruktur dan penggunaan bisnis. Redundansi, pemantauan, cadangan, perencanaan kapasitas, dan prosedur pemulihan paling efektif ketika dirancang berdasarkan ketergantungan aplikasi dan tujuan pemulihan yang didefinisikan dengan jelas.

Untuk aplikasi Windows yang ada, ketahanan sering kali berasal dari memperkuat lingkungan di sekitar perangkat lunak daripada membangun kembali aplikasi itu sendiri. Uji kunci tetap sederhana: ketika gangguan terjadi, dapatkah pengguna terus bekerja, atau dapatkah TI memulihkan fungsi bisnis yang diperlukan dalam jendela pemulihan yang disepakati?