Cách để giảm thiểu rủi ro lỗi phần mềm hệ thống

Trước khi trả lời, hãy cùng xem xét tại sao chúng ta ngày càng phụ thuộc vào phần mềm của bên thứ ba và quá trình này diễn ra như thế nào.

Vòng đời phát triển phần mềm thời kỳ đầu

Cách đây không lâu, vòng đời phát triển phần mềm (SDLC) có thể kéo dài nhiều tháng, thậm chí là nhiều năm.

Phần mềm được cài đặt tại chỗ. Chúng ta chỉ triển khai phần mềm sau khi đã kiểm thử toàn diện và sâu rộng.

Khi muốn nâng cấp phần mềm lên phiên bản mới và ổn định hơn, chúng ta lại phải lặp lại quy trình tương tự. Một số tổ chức làm việc này hằng năm. Nhiều tổ chức khác lại đợi thêm nhiều năm nữa vì giá trị đầu tư thời gian và tài chính là quá lớn để có thể thực hiện thường xuyên.

Quá trình này không chỉ tốn kém mà còn kém hiệu quả. Mặt khác, chúng ta vẫn có thể tự kiểm soát hướng xử lý khi có vấn đề xảy ra.

Điều gì đã thay đổi?

Mỗi công ty đều là công ty công nghệ

Thực sự là, mọi thứ đã thay đổi.

Trước đây, một tổ chức có thể chỉ có duy nhất một hệ thống ERP.

Ngày nay, tất cả các hoạt động kinh doanh đều có công cụ phần mềm hỗ trợ. Chúng ta có hệ thống CNTT cốt lõi để 'duy trì vận hành'. Chúng ta cũng có các hệ thống CNTT dành cho các phòng ban hoặc đơn vị kinh doanh riêng lẻ  – từ ứng dụng sản xuất, công cụ thiết kế sản phẩm, cho đến cổng thông tin hỗ trợ khách hàng, v.v., và các hệ thống này đều có thể trao đổi thông tin với nhau.

Nói cách khác, ngày nay mọi công ty đều là công ty công nghệ.

Các doanh nghiệp kỳ vọng giám đốc thông tin CIO có thể giám sát được tất cả các công cụ đang sử dụng. Khối lượng công việc đã thay đổi đến mức không thể nhận ra. Đồng thời, các CIO còn phải đối mặt với nhiệm vụ hàng năm là đảm bảo đạt được cả ba mục tiêu tốt hơn, nhanh hơn và rẻ hơn.

Trong bối cảnh hiện nay, những cách làm việc thâm dụng thời gian và nguồn lực không còn là phương án khả thi. Không thể chỉ áp dụng cùng một quy trình cập nhật đơn nhất như khi doanh nghiệp chỉ có một số ít hệ thống.

SaaS giúp chúng ta đạt mục tiêu tốt hơn, nhanh hơn và rẻ hơn

Mô hình phần mềm dưới dạng dịch vụ (SaaS) là câu trả lời cần thiết, cho phép các tổ chức thuê bên thứ ba thực hiện công tác bảo trì và cập nhật phần mềm.

Mô hình này đã giúp các CIO hoàn thành những nhiệm vụ tưởng chừng bất khả thi, hướng tới mục tiêu tốt hơn, nhanh hơn và rẻ hơn. Đến năm 2022, các tổ chức thường có thể sử dụng tới 130 ứng dụng SaaS.

Do các bản cập nhật được tung ra hàng tháng, hàng tuần hoặc thậm chí hàng ngày nên các tổ chức luôn tận dụng được những lợi ích công nghệ tốt nhất.  

Mặt khác, chúng ta không còn có khả năng tự xử lý sự cố một cách nhanh chóng như trước đây.

Khi có lỗi, đội ngũ CNTT phải nhờ đến bên thứ ba để tìm lỗi, sửa lỗi và triển khai bản cập nhật đã sửa đổi.

Khi một bản nâng cấp gây ra xung đột với các hệ thống khác, đội ngũ CNTT hoàn toàn bị động trong xử lý sự cố, do vậy cần phải phát triển giải pháp để giải quyết xung đột này.

Khi một công cụ rất phổ biến trên thế giới gặp trục trặc, mọi thứ sẽ trở nên hỗn loạn, điều mà chúng ta vừa thấy gần đây.

Mô hình SaaS chắc chắn sẽ mang lại lợi ích to lớn. Thiếu vắng mô hình này, thế giới kinh doanh hiện đại sẽ không thể tồn tại và phát triển. Tuy nhiên, sự phụ thuộc này cũng làm giảm khả năng chủ động và kiểm soát của các tổ chức như mong muốn.

Vậy giải pháp là gì? - Đó là khả năng phục hồi.

Theo chuyên gia Bla Sweeney, Keysight Technologies Chúng ta cần tập trung vào khả năng phục hồi trong CNTT và triển khai các quy trình cho phép giành lại quyền kiểm soát. Sau đây là bốn lời khuyên cho vấn đề này.

Chuyên gia Bla Sweeney, Keysight Technologies.

Hãy sẵn sàng ứng phó

Thực tế là, trong một thế giới phụ thuộc vào phần mềm, các lỗi phần mềm sẽ luôn xảy ra. Sự khác biệt duy nhất là mức độ nghiêm trọng của các lỗi phần mềm này.

Do đó, chúng ta phải hiểu được những lựa chọn của mình khi có sự cố.

Nếu bạn là một công ty phát hành phần mềm, chiến lược kiểm thử của bạn là gì? Chiến lược triển khai của bạn là gì? Làm thế nào để quay trở lại bản phát hành ổn định trước đó khi xảy ra sự cố?

Nếu công ty bạn vận hành bằng phần mềm, bạn có những lựa chọn nào khi xảy ra sự cố? Kế hoạch dự phòng của bạn là gì?

Hãy tìm người phản biện

Bất kỳ ai đều nhận thức được về rủi ro của hình thức tư duy tập thể. Do đó, hãy bảo đảm có người đóng vai trò phản biện trong mọi quyết định, bao gồm quyết định đầu tư phần mềm. Tại sao chúng ta cần phần mềm này? Có những giải pháp thay thế nào khác? Chúng ta đã thẩm định nhà cung cấp như thế nào?

Ưu tiên tính minh bạch

Sự cố CrowdStrike cho thấy rất rõ ràng rằng các hệ thống mà một tổ chức sử dụng có liên hệ chặt chẽ với nhiều hệ thống khác. Toàn bộ hạ tầng có thể phụ thuộc vào các modem nằm trong các trung tâm dữ liệu và hiếm khi được chú ý đến.

Chúng ta cần mức độ cởi mở và minh bạch mới, cho phép giám sát kỹ lưỡng thay vì chỉ tin tưởng để nhà cung cấp xử lý vấn đề.

Cần nhớ rằng “rẻ hơn” hiếm khi đồng nghĩa với “tốt hơn”. Chúng ta phải đảm bảo rằng việc cắt giảm chi phí không đi kèm với hạ thấp tiêu chuẩn.

Vai trò Kỹ thuật phục hồi chất lượng (QRE)

Cuối cùng, chúng ta cần một vai trò công việc hoàn toàn mới, đó là nâng cao chất lượng hệ thống và xây dựng kế hoạch dự phòng khi xảy ra sự cố.

Trong công việc hàng ngày, đội ngũ CNTT cần xây dựng năng lực phục hồi chất lượng nhờ sử dụng các bản sao số và các công cụ như Eggplant Monitoring, Eggplant Test để theo dõi chặt chẽ quá trình kiểm thử.

Ở cấp độ chiến lược, họ không chỉ cần tập trung vào vòng đời phát triển phần mềm và quản lý hoạt động CNTT mà còn hướng tới bức tranh toàn cảnh về tổ chức và các hệ thống của tổ chức đó.

Họ có trách nhiệm trao quyền kiểm soát trở lại cho các tổ chức. Không phải cách mới hay cũ, mà là cách khác

Thế giới công nghệ hiện đại của chúng ta phụ thuộc vào vô số hệ thống phần mềm. Chúng ta không thể quay lại thời kỳ trước đây để có toàn quyền kiểm soát - và thực tế chúng ta cũng không muốn như vậy. Tuy nhiên, chúng ta phải suy nghĩ về cách tích hợp khả năng phục hồi vào hệ thống và giảm thiểu rủi ro ở cả cấp độ hệ thống lẫn tổ chức. Tôi hy vọng bốn gợi ý này sẽ mang đến cách thức mới để bạn tham khảo trong quá trình thực hiện nhiệm vụ này.

Theo tạp chí Điện tử và Ứng dụng