Khả năng phục hồi ứng dụng: Giữ cho các ứng dụng Windows luôn sẵn có

Giới thiệu

Các ứng dụng Windows thường phụ thuộc vào nhiều yếu tố hơn là máy chủ lưu trữ chúng. Cơ sở dữ liệu, dịch vụ danh tính, lưu trữ, cổng, mạng và các điểm cuối của người dùng đều có thể ảnh hưởng đến việc một ứng dụng có vẫn sử dụng được trong thời gian gián đoạn hay không. Bài viết này giải thích cách các nhóm CNTT có thể đánh giá những phụ thuộc đó, thiết kế khả năng phục hồi xung quanh các ứng dụng Windows hiện có, giám sát các lớp phù hợp và kiểm tra xem các kế hoạch phục hồi có thực sự bảo tồn các chức năng kinh doanh mà người dùng dựa vào hay không.

Ứng dụng Resilience là gì?

Khả năng phục hồi ứng dụng là khả năng của một ứng dụng và hạ tầng xung quanh nó để tiếp tục cung cấp các chức năng quan trọng trong thời gian gián đoạn và phục hồi một cách dự đoán được sau một sự cố.

Sự gián đoạn có thể nhỏ hoặc lớn, và nguyên nhân có thể khác nhau từ sự cố phần cứng hoặc hệ điều hành, sự cố ứng dụng, cập nhật không thành công, sự cố cơ sở dữ liệu, gián đoạn mạng, lỗi xác thực, cạn kiệt tài nguyên, phụ thuộc không khả dụng hoặc sự cố bảo mật.

Một kiến trúc kiên cường thừa nhận rằng các sự cố là không thể tránh khỏi, và thay vì cố gắng ngăn chặn mọi sự cố, các tổ chức CNTT tìm cách hạn chế tác động của từng sự cố và thiết lập các quy trình phục hồi có kiểm soát để duy trì hoặc khôi phục dịch vụ.

Khả năng phục hồi ứng dụng không chỉ là thời gian hoạt động của máy chủ

Một sai lầm phổ biến là sử dụng sự sẵn có của một máy chủ như một đại diện cho sự sẵn có của ứng dụng, ứng dụng chạy trên máy chủ đó.

Để một ứng dụng doanh nghiệp thực sự có sẵn, một số thành phần cần phải có sẵn cùng một lúc:

Hạ tầng → Hệ điều hành → Ứng dụng → Phụ thuộc → Đường dẫn truy cập → Phiên người dùng → Quy trình kinh doanh

Một vấn đề với bất kỳ yếu tố nào trong chuỗi này có thể dẫn đến việc ứng dụng không khả dụng một cách hiệu quả.

Ví dụ, một máy chủ ứng dụng có thể hoạt động tốt trong khi cơ sở dữ liệu của nó không thể truy cập. Một ứng dụng đã được công bố có thể hoạt động bình thường nhưng một sự cố cổng khiến cho nhân viên từ xa không thể truy cập vào nó. Người dùng thậm chí có thể khởi động ứng dụng thành công nhưng bị ngăn cản hoàn thành giao dịch vì một dịch vụ cấp phép, tệp hoặc dịch vụ backend không khả dụng.

Khả năng phục hồi ứng dụng, do đó, nên được đo lường dựa trên khả năng của người dùng để thực hiện nhiệm vụ kinh doanh cần thiết, chứ không phải là liệu một máy chủ có thể phản hồi kiểm tra tính khả dụng hoặc tình trạng hay không.

Tại sao khả năng phục hồi ứng dụng lại khác biệt đối với các ứng dụng Windows?

Các phương pháp phục hồi hiện đại ngày càng tập trung vào các ứng dụng gốc đám mây, container, microservices và tự động hóa điều phối. Mặc dù đây là những cách tiếp cận có giá trị, nhưng chúng không phải lúc nào cũng áp dụng được cho mọi tổ chức.

Nhiều tổ chức có các ứng dụng kinh doanh trên nền tảng Windows cũ được phát triển trước khi kiến trúc đám mây trở nên phổ biến. Phần mềm ERP, ứng dụng kế toán, ứng dụng sản xuất, ứng dụng chăm sóc sức khỏe, ứng dụng kỹ thuật và các ứng dụng phát triển nội bộ có thể đều là rất quan trọng đối với hoạt động của một tổ chức.

Việc tái cấu trúc các ứng dụng này thành các microservices có thể rất tốn kém, thách thức về mặt kỹ thuật, hoặc thậm chí hoàn toàn không khả thi nếu tổ chức không kiểm soát mã nguồn.

Trong những trường hợp như vậy, có thể có giá trị đáng kể trong việc làm cho các hoạt động xung quanh ứng dụng trở nên bền bỉ hơn, thay vì cố gắng làm cho chính ứng dụng trở nên bền bỉ hơn. Xuất bản ứng dụng có thể là một phần của cách tiếp cận này bằng cách giữ các ứng dụng Windows hiện có trên hạ tầng tập trung trong khi thay đổi cách người dùng truy cập chúng. Điều này có thể bao gồm các thay đổi đối với hạ tầng lưu trữ ứng dụng, chẳng hạn như loại bỏ các ràng buộc hạ tầng, tạo ra các máy chủ ứng dụng dự phòng, cho phép các phương thức truy cập thay thế và thực hiện các quy trình phục hồi nhanh nhạy hơn cho máy chủ ứng dụng.

Trong trường hợp nào một ứng dụng Windows có thể không khả dụng?

Xây dựng khả năng phục hồi ứng dụng bắt đầu bằng việc khám phá các thành phần cần thiết để chuyển giao thành công một ứng dụng từ các máy chủ của chúng đến người dùng. Quy trình này làm nổi bật các điểm có khả năng thất bại có thể làm sập toàn bộ ứng dụng.

Máy chủ ứng dụng

Một ứng dụng chạy trên một máy chủ Windows duy nhất có một điểm thất bại rõ ràng.

Vấn đề phần cứng, cập nhật Windows, sự cố hệ điều hành, cạn kiệt tài nguyên hoặc lỗi ứng dụng có thể làm gián đoạn mọi người dùng phụ thuộc vào máy đó. Nếu yêu cầu về tính khả dụng cần thiết, có thể thiết lập nhiều máy chủ ứng dụng để giảm sự phụ thuộc vào bất kỳ máy nào và cung cấp dung lượng khi một máy chủ trở nên không khả dụng.

Cơ sở dữ liệu, Lưu trữ và Các phụ thuộc khác

Nhiều ứng dụng Windows phụ thuộc vào các dịch vụ bên ngoài máy chủ ứng dụng. Các dịch vụ này có thể bao gồm:

• Cơ sở dữ liệu SQL
• chia sẻ tệp
• máy chủ cấp phép
• Active Directory
• Hệ thống tên miền (DNS)
• chứng chỉ
• API
• middleware
• lưu trữ mạng
• hạ tầng in ấn

Giới thiệu một máy chủ ứng dụng thứ hai cung cấp độ bền tối thiểu nếu chúng chia sẻ một cơ sở dữ liệu hoặc phụ thuộc lưu trữ chung mà không khả dụng. Rõ ràng rằng việc lập bản đồ phụ thuộc cần mở rộng ra ngoài hạ tầng ứng dụng có thể nhìn thấy.

Xác thực và Danh tính

Người dùng không thể truy cập vào một ứng dụng khỏe mạnh nếu hạ tầng xác thực cần thiết không khả dụng.

Các nhóm CNTT cần xác định các dịch vụ danh tính mà các ứng dụng quan trọng của họ phụ thuộc vào và đảm bảo rằng họ có kế hoạch dự phòng cho khi các tài nguyên này không thể truy cập được. Active Directory, các nền tảng danh tính đám mây, dịch vụ xác thực đa yếu tố (MFA) và cổng xác thực đều có thể được tin cậy để cung cấp một chuỗi khả dụng cho một ứng dụng.

Mạng và Đường dẫn Truy cập từ xa

Đối với các ứng dụng Windows tập trung, khả năng kết nối giữa người dùng và môi trường ứng dụng đại diện cho một miền lỗi có thể xảy ra khác.

Hãy tưởng tượng chuỗi hoàn chỉnh:

Thiết bị người dùng → Internet hoặc LAN → cổng → máy chủ ứng dụng → dịch vụ backend

Một sự cố ở bất kỳ đâu trong chuỗi này có thể ngăn cản người dùng thực hiện công việc của họ ngay cả khi ứng dụng đang hoạt động bình thường. Điều này đặc biệt quan trọng đối với các tổ chức phân tán, nơi ứng dụng có thể đang hoạt động trong trung tâm dữ liệu nhưng không thể truy cập được đối với người dùng ở vị trí khác.

Endpoints

Khả năng phục hồi ứng dụng không nhất thiết yêu cầu máy trạm bình thường của người dùng phải có sẵn.

Cung cấp cho người dùng được ủy quyền phương tiện để truy cập các ứng dụng được lưu trữ tập trung từ một thiết bị thay thế hoặc qua trình duyệt có thể đảm bảo quyền truy cập, nếu một chiếc laptop không còn khả dụng, một văn phòng trở nên không thể truy cập hoặc nhân viên cần làm việc từ một địa điểm khác.

Kiến trúc phân phối ứng dụng có thể là một thành phần của chiến lược liên tục kinh doanh rộng hơn.

Quy trình xây dựng khả năng phục hồi ứng dụng cho các ứng dụng Windows là gì?

Không có công nghệ đơn lẻ nào làm cho ứng dụng trở nên bền bỉ. Thay vào đó, các nhóm CNTT phải giảm số lượng sự cố có thể làm hỏng hoàn toàn chức năng và chuẩn bị cho các cơ chế phục hồi có kiểm soát cho những sự cố còn lại.

1. Xác định các ứng dụng và quy trình kinh doanh quan trọng

Không phải tất cả các ứng dụng đều yêu cầu mức độ bảo vệ giống nhau. Hãy bắt đầu bằng cách xác định những ứng dụng nào hỗ trợ các hoạt động chính, người dùng nào phụ thuộc vào chúng và mức độ chịu đựng thời gian ngừng hoạt động của họ.

Hai mục tiêu phục hồi chuyển đổi yêu cầu kinh doanh thành các thông số kỹ thuật. Hướng dẫn lập kế hoạch ứng phó của NIST định nghĩa Mục tiêu Thời gian Khôi phục (RTO) và Mục tiêu Điểm Khôi phục (RPO) là các tham số chính để xác định yêu cầu khôi phục:

• Thời gian phục hồi mục tiêu (RTO): một khoảng thời gian ngừng hoạt động chấp nhận được trước khi dịch vụ được khôi phục.
• Mục tiêu điểm phục hồi (RPO): một khoảng thời gian mất dữ liệu chấp nhận được, được đo bằng thời gian.

Một ứng dụng được sử dụng nhiều để xử lý đơn hàng có thể có thời gian khôi phục mục tiêu (RTO) tính bằng phút, trong khi một ứng dụng báo cáo tài chính chạy một lần mỗi tuần có thể chấp nhận thời gian ngừng hoạt động tính bằng ngày.

RTO và RPO xác định loại bảo vệ cần thiết cho một ứng dụng: chuyển đổi tức thì, khôi phục dịch vụ nhanh chóng hoặc chỉ đơn giản là một quy trình phục hồi được tài liệu hóa.

2. Lập bản đồ toàn bộ chuỗi phụ thuộc ứng dụng

Ghi lại mọi thứ cần thiết để ứng dụng thực hiện công việc của nó.

Đừng dừng lại ở tệp thực thi hoặc máy chủ Windows. Đừng quên cơ sở dữ liệu, lưu trữ, xác thực, DNS, mạng, chứng chỉ, hệ thống cấp phép, cổng và dịch vụ bên ngoài.

Đối với mỗi cái, hãy hỏi:

Điều gì sẽ xảy ra với ứng dụng nếu điều này biến mất?

Bài tập này sẽ làm lộ ra những điểm thất bại đơn lẻ ẩn giấu và thiết lập thứ tự phục hồi. Khôi phục một máy chủ ứng dụng trước tiên không giúp ích nhiều nếu cơ sở dữ liệu, dịch vụ danh tính hoặc lưu trữ của nó chưa có sẵn.

3. Loại bỏ các điểm thất bại đơn lẻ quan trọng

Khi cây phụ thuộc được thiết lập, xác định các thành phần nào sẽ được làm dư thừa, dựa trên tầm quan trọng của doanh nghiệp và các mục tiêu phục hồi.

Trong trường hợp phân phối ứng dụng Windows, điều này có thể liên quan đến việc triển khai nhiều máy chủ ứng dụng thay vì dựa vào khả năng của một máy chủ duy nhất. Với một lớp cân bằng tải, các phiên có thể được phân bổ trên các phiên bản ứng dụng trong quá trình hoạt động bình thường. Trong trường hợp máy chủ gặp sự cố, các kết nối đến có thể được chuyển hướng đến các phiên bản máy chủ ứng dụng khỏe mạnh.

Kế hoạch dự phòng nên được thông báo bởi phân tích sự phụ thuộc, tuy nhiên. Nhiều máy chủ ứng dụng truy cập vào một cơ sở dữ liệu quan trọng, cổng mạng hoặc lớp lưu trữ duy nhất vẫn tạo ra một điểm thất bại duy nhất.

Thiết kế tính sẵn sàng cao do đó phải xem xét dịch vụ ứng dụng như một thực thể tích hợp. Đối với các môi trường Windows Server yêu cầu tính dư thừa ở cấp hạ tầng, Tài liệu về Clustering Dự phòng của Microsoft cung cấp thêm hướng dẫn về các cấu trúc có độ sẵn sàng cao và phục hồi thảm họa.

4. Tách ứng dụng khỏi các điểm cuối cá nhân

Cài đặt một ứng dụng quan trọng trực tiếp trên mỗi máy trạm của nhân viên có thể tạo ra một loại vấn đề về khả năng phục hồi khác. Nếu người dùng mất quyền truy cập vào máy tính thông thường của họ, họ cũng có thể mất quyền truy cập vào các ứng dụng mà họ cần để tiếp tục làm việc.

Tập trung ứng dụng trên các máy chủ Windows được quản lý và việc trình bày giao diện ứng dụng cho người dùng loại bỏ rủi ro này. Dữ liệu và trạng thái ứng dụng được lưu trữ trên máy chủ Windows được quản lý và được truy cập bởi các điểm cuối được ủy quyền.

Bằng cách này, chúng tôi làm cho ứng dụng có sẵn cho người dùng ngay cả khi họ thay đổi thiết bị hoặc vị trí. Mặc dù việc tập trung ứng dụng không loại bỏ các vấn đề hạ tầng, nhưng nó giúp di chuyển vào một môi trường mà IT có thể kiểm soát.

Cung cấp nhiều phương pháp truy cập thực tế hơn một.

Sự kiên cường cũng có thể đạt được bằng cách tránh sự phụ thuộc không cần thiết vào một loại điểm cuối hoặc phương thức kết nối duy nhất.

Tùy thuộc vào kiến trúc phân phối ứng dụng, người dùng có thể sử dụng khác nhau truy cập từ xa các phương pháp, bao gồm một khách hàng tương thích RDP, trình khởi động ứng dụng chuyên dụng, cổng thông tin web hoặc phiên trình duyệt HTML5.

Các phương pháp kết nối thay thế không nên bị nhầm lẫn với sự dư thừa hạ tầng. Nếu tất cả đều phụ thuộc vào cùng một máy chủ bị lỗi, ứng dụng vẫn không khả dụng.

Họ cung cấp khả năng phục hồi truy cập khi sự gián đoạn ảnh hưởng đến thiết bị bình thường của người dùng, khách hàng đã cài đặt hoặc vị trí thay vì dịch vụ ứng dụng tự nó.

6. Giám sát trước khi suy giảm trở thành sự cố

Khả năng phục hồi ứng dụng không chỉ là về việc khôi phục, mà việc phát hiện sớm có thể tránh được sự suy giảm thành một sự cố.

Các chỉ số hữu ích trong môi trường ứng dụng Windows bao gồm mức sử dụng CPU, áp lực bộ nhớ, dung lượng đĩa và I/O, mức sử dụng mạng, phiên hoạt động, quy trình ứng dụng, thời gian phản hồi, kết nối thất bại và khả năng sẵn có của các dịch vụ phụ thuộc.

Giám sát xu hướng là rất quan trọng, vì một máy chủ thường xuyên tiếp cận giới hạn của nó vẫn có thể trực tuyến trong khi trải nghiệm của người dùng dần dần xấu đi.

Cảnh báo ngưỡng cho phép quản trị viên điều tra các yếu tố tiền đề của một sự cố trước khi người dùng mất quyền truy cập.

7. Lập kế hoạch cho các đỉnh công suất và chuyển đổi dự phòng

Một ứng dụng có thể tồn tại qua các sự cố ở cấp độ phần cứng nhưng hoàn toàn không thể hoạt động dưới áp lực tăng cao thì không thực sự có khả năng phục hồi trước bất kỳ loại sự cố nào.

Kế hoạch cho công suất phải tính đến không chỉ các mẫu sử dụng hàng ngày mà còn phải xem xét các đỉnh điểm do nhu cầu theo mùa, thay đổi ca, tăng trưởng hoặc yêu cầu lưu trữ cho các ứng dụng khác.

Đặc biệt trong các môi trường lưu trữ đa máy chủ, việc mất một máy chủ đơn lẻ phải được tính đến bằng cách đảm bảo rằng các nút lưu trữ khác có dung lượng dự phòng để tiếp nhận bất kỳ quy trình nào sẽ được thực hiện trên nút bị lỗi.

Nếu không, các quy trình chuyển đổi dự phòng có thể đơn giản biến một sự cố cô lập thành một vấn đề hiệu suất hệ thống rộng lớn.

8. Bảo vệ Dữ liệu và Cấu hình

Một máy chủ Windows thay thế sẽ ít có giá trị nếu IT không thể khôi phục các thành phần cần thiết để làm cho ứng dụng hoạt động.

Điều này có thể có nghĩa là các quy trình sao lưu cần bao gồm dữ liệu ứng dụng, cơ sở dữ liệu, tệp cấu hình, chứng chỉ, cài đặt ứng dụng, hồ sơ người dùng, cấu hình hạ tầng, kịch bản và thông tin cấp phép.

Chiến lược sẽ thay đổi tùy thuộc vào Mục tiêu Thời gian Khôi phục (RTO) và Mục tiêu Điểm Khôi phục (RPO) của ứng dụng.

Trên hết, hãy đảm bảo rằng một bản sao lưu thành công không đồng nghĩa với việc phục hồi thành công. Các nhóm CNTT nên kiểm tra rằng có thể khôi phục toàn bộ dịch vụ ứng dụng từ dữ liệu và cấu hình được bảo vệ.

Giảm bán kính tác động của các thay đổi

Không phải lúc nào cũng là một thảm họa không lường trước gây ra sự gián đoạn. Chúng cũng có thể do những cải tiến đã được thực hiện. Do đó, các bản vá Windows, nâng cấp ứng dụng và trình điều khiển, thay đổi chính sách bảo mật và cấu hình cũng có thể ảnh hưởng tiêu cực đến tính khả dụng của ứng dụng. Nên tránh thực hiện những thay đổi tương tự trên tất cả các máy chủ sản xuất cùng một lúc nếu có thể.

Trong một cấu hình nhiều máy chủ, có thể thực hiện các thay đổi cải tiến theo từng giai đoạn, từ đó cho phép quản trị viên đảm bảo mọi thứ hoạt động đúng cách. Khả năng hoàn tác các thay đổi đã thực hiện cũng rất quan trọng.

Do đó, khi thiết kế các quy trình dự phòng, các tùy chọn khôi phục cũng nên được xem xét. Quy trình này nên được ghi chép đầy đủ, và nhân viên nên biết phải làm gì nếu một thay đổi không thành công, thay vì chỉ để tùy ý họ quyết định.

10. Thiết kế cho sự suy giảm thanh lịch

Khả năng phục hồi không phải là việc duy trì 100% các chức năng bình thường hoạt động liên tục mọi lúc.

Trong một số trường hợp, duy trì hoạt động cho người dùng hoặc ứng dụng chính có thể quan trọng hơn việc giữ cho tất cả các dịch vụ có sẵn cho tất cả người dùng. Các ưu tiên có thể được thiết lập trước khi một sự cố xảy ra bởi các nhóm CNTT.

Nếu có dung lượng khả dụng có thể sử dụng, có thể hợp lý khi phân bổ nó trước tiên cho sản xuất, dịch vụ khách hàng, tài chính hoặc các chức năng khác.

Đó là sự suy giảm duyên dáng: giữ lại khả năng thực hiện các chức năng tạo ra giá trị kinh doanh cao nhất, thay vì để sự cố của các yếu tố kém quan trọng hơn làm cho toàn bộ hệ thống sập.

Các nhóm CNTT nên giám sát khả năng phục hồi của ứng dụng như thế nào?

Giám sát các máy chủ riêng lẻ có thể hữu ích, nhưng giám sát độ bền nên phản ánh tổng thể dịch vụ ứng dụng như được người dùng cảm nhận.

Một mô hình thực tế bao gồm nhiều lớp:

Lớp	Những gì cần giám sát	Ví dụ thất bại
Máy chủ	CPU, RAM, đĩa, khả dụng hệ điều hành	Máy chủ quá tải hoặc ngoại tuyến
Ứng dụng	Trạng thái quy trình và dịch vụ	Ứng dụng bị treo
Phụ thuộc	Cơ sở dữ liệu, DNS, danh tính, lưu trữ	Ứng dụng khởi động nhưng không thể hoạt động
Truy cập	Cổng, cổng thông tin, đường dẫn mạng	Người dùng không thể kết nối
Phiên làm việc	Người dùng hoạt động, lỗi, độ trễ	Ứng dụng đang trực tuyến nhưng không thể sử dụng được
Chức năng kinh doanh	Hoàn thành quy trình làm việc thành công	Người dùng không thể hoàn thành nhiệm vụ yêu cầu.

Lớp chức năng kinh doanh là một trong những lớp dễ bị bỏ qua nhất.

Bảng điều khiển hạ tầng có thể hiển thị tất cả các máy chủ, dịch vụ và đường mạng là khỏe mạnh, trong khi quy trình làm việc của người dùng thực tế bị ảnh hưởng. Do đó, điều quan trọng là các ứng dụng quan trọng phải theo dõi sức khỏe của chúng từ góc độ của hoạt động mà chúng được thiết kế để hỗ trợ.

Làm thế nào để kiểm tra khả năng phục hồi của ứng dụng?

Một kiến trúc phục hồi chưa bao giờ trải qua một sự cố kiểm soát chứa những giả định chưa được kiểm tra.

Sử dụng kiểm tra để đánh giá phản ứng của hệ thống khi các thành phần chính không còn khả dụng. Các bài kiểm tra nên bao gồm việc đưa một máy chủ ứng dụng ngoại tuyến, dừng một dịch vụ ứng dụng, mô phỏng mất kết nối mạng, xác minh hành vi của cổng hoặc cân bằng tải, khôi phục từ bản sao lưu và truy cập ứng dụng từ một điểm cuối thay thế.

Quy trình kiểm tra nên mở rộng ra ngoài các khía cạnh kỹ thuật của việc phục hồi. Các nhóm CNTT nên xem xét liệu các cảnh báo có được gửi đến đúng nhân sự quản lý hay không, các bước phục hồi có được thực hiện theo đúng trình tự hay không, và người dùng có thể thực hiện một nhiệm vụ kinh doanh thực tế sau khi các dịch vụ đã được khôi phục hay không.

Các quy trình vận hành là phần không thể thiếu của một hệ thống bền vững. Quy trình leo thang cảnh báo: ai nhận cảnh báo? Ai có thẩm quyền để khởi động chuyển đổi dự phòng? Tài liệu phục hồi và thông tin xác thực được lưu trữ ở đâu? Sự phụ thuộc nào cần được khởi động trước tiên?

Sự dư thừa kỹ thuật mang lại ít lợi ích nếu các quy trình để khôi phục quyền truy cập chưa được kiểm tra.

Danh sách kiểm tra khả năng phục hồi ứng dụng có thể là gì?

Trước khi bắt tay vào một ứng dụng Windows quan trọng, các nhóm CNTT nên có khả năng trả lời các câu hỏi sau:

• Các quy trình kinh doanh nào phụ thuộc vào ứng dụng?
• Thời gian khôi phục mục tiêu (RTO) và thời gian khôi phục dữ liệu mục tiêu (RPO) của nó là gì?
• Các máy chủ, cơ sở dữ liệu và dịch vụ bên ngoài nào là cần thiết?
• Nơi nào là những điểm thất bại quan trọng của nó?
• Một ứng dụng máy chủ khác có thể chấp nhận người dùng nếu một máy chủ gặp sự cố không?
• Người dùng có thể kết nối nếu điểm cuối hoặc vị trí bình thường của họ không khả dụng không?
• Có đủ dung lượng dự phòng cho hoạt động suy giảm không?
• Các vấn đề về cơ sở hạ tầng, phụ thuộc và phiên có được theo dõi tích cực không?
• Các quản trị viên có được thông báo trước khi các ngưỡng quan trọng trở thành sự cố không?
• Dữ liệu ứng dụng và cấu hình có được bảo vệ không?
• Khôi phục có thực sự được kiểm tra không?
• Có thể khôi phục lại những thay đổi có vấn đề không?
• Quy trình phục hồi có được tài liệu hóa không?
• Người dùng có thể hoàn thành quy trình kinh doanh cần thiết sau khi phục hồi không?

Không phải tất cả các câu trả lời đều yêu cầu cơ sở hạ tầng có sẵn cao đắt tiền. Mức độ bảo vệ phù hợp phụ thuộc vào chi phí và tác động hoạt động của thời gian ngừng hoạt động.

Điều quan trọng là các quyết định về tính khả dụng, dự phòng và phục hồi được thực hiện một cách có chủ đích, chứ không phải được giả định.

TSplus có thể giúp giữ cho các ứng dụng Windows luôn sẵn có như thế nào?

Đối với các tổ chức dựa vào các ứng dụng Windows hiện có, chúng tôi có thể giúp cải thiện tính khả dụng bằng cách tập trung các ứng dụng trên các máy chủ Windows được quản lý và cung cấp chúng cho người dùng thông qua các khách hàng tương thích RDP, truy cập theo kiểu RemoteApp hoặc một cổng web HTML5. Điều này giảm sự phụ thuộc vào các điểm cuối của người dùng cá nhân và mang lại cho các đội ngũ CNTT nhiều sự linh hoạt hơn khi người dùng cần kết nối từ một thiết bị hoặc vị trí khác.

TSplus Remote Access cũng có thể hỗ trợ triển khai đa máy chủ với cân bằng tải và truy cập dựa trên cổng. Khi kết hợp với cơ sở dữ liệu, lưu trữ, dịch vụ danh tính và mạng bền vững, kiến trúc này có thể giảm sự phụ thuộc vào một máy chủ ứng dụng duy nhất và giúp duy trì quyền truy cập vào các ứng dụng Windows quan trọng trong thời gian gián đoạn hạ tầng.

Kết luận

Khả năng phục hồi ứng dụng phụ thuộc vào việc hiểu rõ toàn bộ con đường giữa hạ tầng và việc sử dụng kinh doanh. Sự dư thừa, giám sát, sao lưu, lập kế hoạch năng lực và quy trình phục hồi sẽ hiệu quả nhất khi chúng được thiết kế dựa trên các phụ thuộc ứng dụng và mục tiêu phục hồi được xác định rõ ràng.

Đối với các ứng dụng Windows hiện có, khả năng phục hồi thường đến từ việc củng cố môi trường xung quanh phần mềm thay vì xây dựng lại chính ứng dụng đó. Bài kiểm tra chính vẫn rất đơn giản: khi xảy ra gián đoạn, người dùng có thể tiếp tục làm việc hay không, hoặc IT có thể khôi phục chức năng kinh doanh cần thiết trong khoảng thời gian phục hồi đã thỏa thuận hay không?