Chia sẻ qua


Sự đánh đổi về độ tin cậy cho khối lượng công việc Power Platform

Một khối lượng công việc đáng tin cậy luôn đáp ứng được các mục tiêu về độ tin cậy đã xác định. Nó phải đạt được các mục tiêu phục hồi đã đề ra, lý tưởng nhất là bằng cách tránh các sự kiện ảnh hưởng đến độ tin cậy. Tuy nhiên, trên thực tế, khối lượng công việc phải chịu đựng và kiểm soát được tác động của những sự kiện như vậy và duy trì hoạt động ở mức đã định trước trong quá trình trục trặc đang diễn ra. Ngay cả trong thảm họa, khối lượng công việc đáng tin cậy phải phục hồi đến trạng thái cụ thể trong một khoảng thời gian nhất định, cả hai đều phải được các bên liên quan thống nhất. Một kế hoạch ứng phó sự cố cho phép bạn phát hiện và phục hồi nhanh chóng là rất quan trọng.

Trong giai đoạn thiết kế khối lượng công việc, bạn cần cân nhắc cách các quyết định dựa trên Nguyên tắc thiết kế độ tin cậy và các khuyến nghị trong Danh sách kiểm tra đánh giá thiết kế về độ tin cậy có thể ảnh hưởng đến mục tiêu và quá trình tối ưu hóa của các trụ cột khác. Một số quyết định có thể mang lại lợi ích cho một số trụ cột nhưng lại là sự đánh đổi cho những trụ cột khác. Bài viết này mô tả các ví dụ về sự đánh đổi mà nhóm khối lượng công việc có thể gặp phải khi thiết kế kiến trúc và hoạt động khối lượng công việc để đảm bảo độ tin cậy.

Sự đánh đổi độ tin cậy với bảo mật

Đánh đổi: Tăng diện tích bề mặt khối lượng công việc. Trụ cột Bảo mật ưu tiên thu hẹp và hạn chế diện tích bề mặt để giảm thiểu các hướng tấn công và giảm việc quản lý các biện pháp kiểm soát bảo mật.

  • Độ tin cậy thường đạt được thông qua quá trình sao chép. Sự sao chép có thể xảy ra ở cấp độ thành phần, cấp độ dữ liệu hoặc thậm chí ở cấp độ địa lý. Theo thiết kế, bản sao sẽ làm tăng diện tích bề mặt của khối lượng công việc. Theo quan điểm bảo mật, diện tích bề mặt được thu hẹp và hạn chế là giải pháp tốt nhất để giảm thiểu các nguy cơ tấn công tiềm ẩn và đơn giản hóa việc quản lý các biện pháp kiểm soát bảo mật.

  • Tương tự như vậy, các giải pháp phục hồi sau thảm họa, như sao lưu, sẽ làm tăng diện tích bề mặt của khối lượng công việc. Tuy nhiên, chúng thường bị tách biệt khỏi thời gian chạy của khối lượng công việc. Điều này đòi hỏi phải triển khai các biện pháp kiểm soát bảo mật bổ sung, có thể dành riêng cho giải pháp phục hồi sau thảm họa.

  • Vì mục tiêu về độ tin cậy, có thể cần thêm các thành phần bổ sung cho kiến trúc, giúp tăng diện tích bề mặt. Độ phức tạp gia tăng này làm tăng diện tích bề mặt của khối lượng công việc bằng cách thêm các thành phần mới cần được bảo mật, có thể theo những cách chưa được sử dụng trong hệ thống. Thông thường, các thành phần này đi kèm với mã bổ sung để hỗ trợ việc sử dụng hoặc các mẫu độ tin cậy chung, điều này cũng làm tăng diện tích bề mặt của ứng dụng.

Đánh đổi: Bỏ qua kiểm soát bảo mật. Trụ cột Bảo mật khuyến nghị rằng mọi biện pháp kiểm soát đều phải được duy trì trong cả hệ thống bình thường và hệ thống căng thẳng.

  • Khi khối lượng công việc gặp phải sự cố về độ tin cậy đang được giải quyết theo phản hồi sự cố chủ động, tính cấp bách có thể tạo áp lực cho các nhóm khối lượng công việc bỏ qua các biện pháp kiểm soát bảo mật được tối ưu hóa cho quyền truy cập thường xuyên.

  • Các hoạt động khắc phục sự cố có thể khiến nhóm phải tạm thời vô hiệu hóa các giao thức bảo mật, khiến hệ thống vốn đã căng thẳng lại càng có nguy cơ gặp thêm các rủi ro bảo mật. Ngoài ra còn có nguy cơ là các giao thức bảo mật sẽ không được thiết lập lại kịp thời.

  • Việc triển khai chi tiết các biện pháp kiểm soát bảo mật, như phân công kiểm soát truy cập dựa trên vai trò hoặc quy tắc tường lửa, sẽ làm tăng tính phức tạp và nhạy cảm của cấu hình, làm tăng nguy cơ cấu hình sai. Việc giảm thiểu tác động tiềm ẩn đến độ tin cậy này bằng cách sử dụng các quy tắc chung sẽ làm xói mòn cả ba nguyên tắc của kiến trúc Zero Trust.

Đánh đổi: Phiên bản phần mềm cũ. Trụ cột Bảo mật khuyến khích cách tiếp cận "cập nhật và duy trì cập nhật" đối với các bản vá bảo mật của nhà cung cấp.

  • Việc áp dụng các bản cập nhật đợt phát hành hoặc cập nhật cho các thư viện của nhà cung cấp, như các giải pháp hoặc thành phần của bên thứ ba, có khả năng làm gián đoạn thành phần mục tiêu, gây ra tình trạng không khả dụng trong quá trình thay đổi. Việc trì hoãn hoặc tránh vá lỗi có thể tránh được các rủi ro tiềm ẩn về độ tin cậy, nhưng nó khiến hệ thống không được bảo vệ trước các mối đe dọa đang phát triển.

  • Những cân nhắc trước đó cũng áp dụng cho mã khối lượng công việc. Ví dụ, điều này áp dụng cho mã ứng dụng sử dụng các thư viện và thành phần cũ. Nếu việc cập nhật và triển khai mã ứng dụng được coi là rủi ro về độ tin cậy chưa được giảm thiểu, thì ứng dụng sẽ phải đối mặt với các rủi ro bảo mật bổ sung theo thời gian.

Sự đánh đổi về độ tin cậy với Hoạt động xuất sắc

Đánh đổi: Tăng tính phức tạp trong hoạt động. Hoạt động xuất sắc, giống như Độ tin cậy, ưu tiên sự đơn giản.

  • Việc có một chiến lược giám sát toàn diện cho khối lượng công việc là một phần quan trọng để đạt được sự xuất sắc trong vận hành. Việc đưa thêm các thành phần vào kiến trúc để triển khai các mẫu thiết kế độ tin cậy sẽ tạo ra nhiều nguồn dữ liệu hơn để quản lý, làm tăng tính phức tạp của việc triển khai theo dõi và khả năng quan sát phân tán.

  • Việc sử dụng nhiều vùng để khắc phục hạn chế về năng lực tài nguyên của một vùng và/hoặc triển khai kiến trúc chủ động/chủ động sẽ làm tăng tính phức tạp của việc quản lý vận hành khối lượng công việc. Sự phức tạp này xuất phát từ nhu cầu quản lý nhiều vùng và nhu cầu quản lý việc sao chép dữ liệu giữa các vùng.

Đánh đổi: Tăng cường nỗ lực để tạo ra kiến thức và nhận thức của nhóm. Trụ cột Hoạt động xuất sắc khuyến nghị việc lưu giữ và duy trì kho lưu trữ tài liệu cho các quy trình và cấu trúc.

  • Khi khối lượng công việc trở nên mạnh mẽ hơn thông qua việc bổ sung các thành phần và mẫu độ tin cậy, sẽ mất nhiều thời gian hơn để duy trì các quy trình vận hành và tài liệu hiện vật.

  • Việc đào tạo trở nên phức tạp hơn khi số lượng thành phần trong khối lượng công việc tăng lên. Sự phức tạp này ảnh hưởng đến thời gian cần thiết để đưa người dùng vào sử dụng và làm tăng kiến thức cần thiết để theo dõi lộ trình sản phẩm và hướng dẫn về mức độ dịch vụ.

Sự đánh đổi về độ tin cậy với Tối ưu hóa trải nghiệm

Đánh đổi: Giảm sự nhanh nhẹn. Trụ cột Tối ưu hóa trải nghiệm ưu tiên hiệu quả của người dùng.

  • Việc nhấn mạnh vào việc thử nghiệm nghiêm ngặt có thể làm chậm việc phát hành các tính năng trải nghiệm cần thiết cho việc áp dụng.

  • Việc tối ưu hóa độ tin cậy có thể tập trung quá mức vào việc giảm thiểu sự phức tạp, làm giảm mức độ ưu tiên cho các tính năng dành cho trải nghiệm người dùng hấp dẫn hơn, chẳng hạn như các thành phần tùy chỉnh và tích hợp.

Sự đánh đổi độ tin cậy với hiệu suất hiệu quả

Đánh đổi: Độ trễ tăng lên. Hiệu suất Hiệu quả đòi hỏi một hệ thống đạt được mục tiêu hiệu suất cho luồng dữ liệu và người dùng.

  • Các mẫu độ tin cậy thường kết hợp sao chép dữ liệu để tồn tại khi bản sao bị lỗi. Sao chép sẽ tạo thêm độ trễ cho các hoạt động ghi dữ liệu đáng tin cậy, làm tiêu tốn một phần ngân sách hiệu suất cho một người dùng hoặc luồng dữ liệu cụ thể.

  • Độ tin cậy đôi khi sử dụng nhiều hình thức cân bằng tài nguyên khác nhau để phân phối hoặc phân phối lại tải cho các bản sao khỏe mạnh. Một thành phần chuyên dụng được sử dụng để cân bằng thường ảnh hưởng đến hiệu suất của yêu cầu hoặc quy trình đang được cân bằng.

  • Việc phân phối các thành phần trên khắp các ranh giới địa lý hoặc vùng khả dụng để tồn tại sau tác động có phạm vi sẽ gây ra độ trễ mạng trong quá trình giao tiếp giữa các thành phần nằm trong các ranh giới khả dụng đó.

  • Các quy trình mở rộng được sử dụng để theo dõi tình trạng của khối lượng công việc. Mặc dù giám sát rất quan trọng đối với độ tin cậy, nhưng thiết bị đo lường có thể ảnh hưởng đến hiệu suất của hệ thống. Khi khả năng quan sát tăng lên, hiệu suất có thể giảm xuống.

Đánh đổi: Tăng cường cung cấp quá mức. Trụ cột Hiệu quả hoạt động không khuyến khích việc cung cấp quá mức, thay vào đó khuyến nghị sử dụng vừa đủ tài nguyên để đáp ứng nhu cầu.

  • Hoạt động mở rộng quy mô tự động không diễn ra tức thời và do đó không thể xử lý đáng tin cậy nhu cầu tăng đột biến và không thể định hình hoặc làm phẳng. Do đó, việc cung cấp quá mức thông qua các phiên bản lớn hơn hoặc nhiều phiên bản hơn là một chiến thuật đảm bảo độ tin cậy quan trọng để giải quyết độ trễ giữa tín hiệu nhu cầu và việc tạo nguồn cung. Công suất không được sử dụng sẽ đi ngược lại mục tiêu về hiệu quả hoạt động.

  • Đôi khi một thành phần không thể được mở rộng theo nhu cầu và nhu cầu đó không thể dự đoán hoàn toàn. Việc sử dụng các phiên bản lớn để giải quyết trường hợp xấu nhất sẽ dẫn đến lãng phí khi cung cấp quá mức trong những tình huống nằm ngoài trường hợp sử dụng đó.