INFOCHIEF ACADEMY · IT ADMINISTRATOR KNOWLEDGE SERIES

Xây dựng kế hoạch bảo trì phòng ngừa cho hạ tầng IT.

Bảo trì phòng ngừa cần ưu tiên theo dịch vụ, tình trạng và thời gian chuẩn bị. Kết hợp lịch định kỳ với tín hiệu sớm, cửa sổ phù hợp và bằng chứng kết quả giúp đội IT dùng nguồn lực vào những rủi ro đáng xử lý.

Biên soạn: Infochief Academy · Chuyên đề: Quản trị vận hành IT

← Trở về thư viện bài viết

Nhóm hạ tầng kiểm tra thiết bị và kế hoạch bảo trì phòng ngừa
Minh họa biên tập: nhóm hạ tầng kiểm tra thiết bị và kế hoạch bảo trì phòng ngừa.

Một kế hoạch bảo trì dày đặc chưa chắc làm hạ tầng ổn định hơn. Nếu mọi thiết bị được kiểm tra theo cùng lịch, đội có thể dành nhiều thời gian cho những việc ít rủi ro nhưng bỏ lỡ một chứng thư sắp hết hạn hoặc một bộ lưu trữ đang tăng lỗi. Phòng ngừa cần đúng ưu tiên, không chỉ nhiều đầu việc.

Kế hoạch tốt nối tình trạng hạ tầng, yêu cầu dịch vụ, hướng dẫn nhà cung cấp và năng lực thực hiện. Nó xác định việc nào cần làm trước, khi nào được thao tác và bằng chứng nào chứng minh kết quả. Nhờ đó, bảo trì trở thành một cách giảm rủi ro có kiểm soát, thay vì một loạt thao tác định kỳ theo thói quen.

Phân loại hạ tầng theo hậu quả khi không bảo trì

Bắt đầu bằng dịch vụ thiết yếu và các thành phần trực tiếp hỗ trợ. Với từng thành phần, xem tác động nếu lỗi, khả năng dự phòng, thời gian thay thế và mức độ nhìn thấy tình trạng. Một thiết bị dùng chung cho nhiều dịch vụ có thể cần ưu tiên cao dù giá trị mua không lớn.

Cần tách việc có hạn rõ với việc dựa trên xu hướng. Gia hạn chứng thư hoặc hợp đồng hỗ trợ có mốc thời gian; kiểm tra tài nguyên và lỗi phần cứng phụ thuộc tình trạng. Hai loại việc có thể cùng nằm trong lịch nhưng cần căn cứ khác nhau để xác định lúc hành động.

Không nên coi mọi thao tác can thiệp đều là phòng ngừa có lợi. Khởi động lại định kỳ có thể làm biểu hiện biến mất nhưng che một vấn đề chưa giải thích. Vệ sinh hoặc thay linh kiện không theo hướng dẫn phù hợp có thể tạo hỏng hóc mới. Mỗi việc phải có lý do và điều kiện thực hiện.

Kiến thức quản trị vận hành IT giúp đội xác định những điều kiện đó theo loại hệ thống. Kế hoạch cần phản ánh kiến trúc đang có và khả năng thực, không sao chép một lịch chung rồi áp vào mọi doanh nghiệp.

Kết hợp lịch định kỳ với tín hiệu tình trạng

Lịch định kỳ hữu ích với việc cần rà thường xuyên hoặc có chu kỳ được xác định. Tuy nhiên, nó cần được bổ sung bằng tín hiệu như tốc độ tăng dung lượng, lỗi thiết bị, nhiệt độ, tác vụ thất bại hoặc thời gian xử lý tăng. Nếu tình trạng xấu đi nhanh, chờ đến kỳ tiếp theo có thể không phù hợp.

Đường cơ sở phải có ngữ cảnh: tải, thời điểm nghiệp vụ, môi trường và thay đổi gần đây. Một tín hiệu tăng có thể do nhu cầu hợp lệ hoặc cơ chế lỗi. Kế hoạch nên ghi bước xác minh trước hành động, tránh biến mọi bất thường thành lệnh bảo trì tự động.

Với thành phần có thời gian chuẩn bị dài, mốc cảnh báo cần tính cả phê duyệt, mua sắm và triển khai. Báo khi gần cạn nhưng không còn đủ thời gian mở rộng sẽ chỉ giúp đội biết sớm rằng mình đã muộn. Đây là phần quan trọng của dự báo phòng ngừa.

Nhóm việcCăn cứ chọn thời điểmKết quả cần xác nhận
Gia hạn và vòng đờiHạn sử dụng, thời gian chuẩn bị, mức hỗ trợThành phần vẫn hợp lệ và dịch vụ kiểm tra đạt
Tài nguyên và hiệu suấtXu hướng tải, dung lượng và giới hạnNăng lực phù hợp yêu cầu đã xác định
Thiết bị và môi trườngTình trạng, lỗi và hướng dẫn phù hợpSai lệch đã xử lý, không tạo tác động mới
Khả năng phục hồiMức quan trọng, thay đổi và khoảng trống kiểm chứngDữ liệu và dịch vụ phục hồi được trong phạm vi thử

Những nhóm việc này cần người sở hữu và mốc rà lại. Nếu một tín hiệu chưa đủ rõ, có thể mở việc điều tra với hạn cụ thể. Không nên để mục “theo dõi thêm” tồn tại vô thời hạn mà không xác định ai theo dõi và điều kiện nào dẫn đến quyết định.

Đặt bảo trì trong cửa sổ dịch vụ có thể chấp nhận

Cửa sổ kỹ thuật thuận tiện chưa chắc thuận tiện cho doanh nghiệp. Cần đối chiếu lịch giao dịch, xử lý theo lô, chốt số liệu và hoạt động của đối tác. Một dịch vụ ít người dùng ban đêm vẫn có thể đang chạy tác vụ quan trọng không thể gián đoạn.

Mỗi công việc cần phạm vi, thời gian dự kiến, phụ thuộc, điều kiện sẵn sàng và khả năng phục hồi. Nếu cùng lúc làm nhiều thay đổi, khi có lỗi sẽ khó xác định nguyên nhân và quay về. Gom việc có thể tiết kiệm một lần gián đoạn, nhưng phải xét khả năng kiểm chứng và giới hạn đội thực hiện.

Kế hoạch nhân sự cần gồm người thao tác, người xác nhận và người có quyền quyết định khi lệch. Cũng cần kiểm tra khả năng liên hệ nhà cung cấp và người thay thế. Đặt lịch ngoài giờ không tự tạo nguồn lực hỗ trợ ngoài giờ nếu các cam kết đó chưa tồn tại.

Trong quản lý dịch vụ IT, bảo trì được nối với thay đổi, giao tiếp và xác nhận dịch vụ. Người dùng cần biết phạm vi ảnh hưởng và cách liên hệ; đội vận hành cần có tiêu chí kết thúc trước khi thông báo mọi thứ đã trở lại bình thường.

Kiểm chứng công việc, không chỉ ký xác nhận đã làm

Trước thao tác, xác nhận đúng môi trường, trạng thái ban đầu và khả năng phục hồi. Trong thao tác, lưu bước và kết quả cần thiết. Sau thao tác, kiểm tra thành phần cùng dịch vụ liên quan, đặc biệt các chức năng có thể bị tác động nhưng không xuất hiện trong biểu đồ hệ thống.

Một checklist nên chứa điều kiện và bằng chứng thay vì chỉ tên công việc. “Kiểm tra backup” cần biết đã kiểm tra phạm vi, lỗi hay khả năng phục hồi. “Kiểm tra thiết bị” cần xác định tín hiệu nào được xem và kết quả nào mở việc tiếp theo. Nếu các từ quá rộng, người thực hiện sẽ đánh dấu theo cách hiểu riêng.

Khi kết quả khác dự kiến, cần dừng hoặc chuyển cấp theo kế hoạch. Không nên tăng thêm thao tác ngoài phạm vi để cố đưa tất cả chỉ số về xanh. Những thay đổi phát sinh cần được đánh giá và lưu trong hồ sơ; nếu có tác động mới, người quyết định phải biết.

Quyền thao tác và dữ liệu bằng chứng cần được bảo vệ theo quản trị an toàn thông tin. Tài khoản tạm, quyền đối tác và tệp xuất cấu hình phải được xử lý sau công việc. Bảo trì chưa khép nếu để lại một đường truy cập không được quản lý.

Tình huống giả định: lịch bảo trì không theo kịp tăng trưởng dữ liệu

Giả sử doanh nghiệp rà dung lượng lưu trữ mỗi tháng. Sau một thay đổi nghiệp vụ, số tệp phát sinh tăng nhanh và tài nguyên gần cạn trước kỳ rà tiếp theo. Đây là ví dụ minh họa cho việc lịch định kỳ không đủ khi điều kiện sử dụng thay đổi.

Đội trước hết xác nhận dữ liệu tăng do nhu cầu hay do lỗi tạo trùng, log hoặc chính sách lưu giữ. Không tự xóa dữ liệu chỉ để kéo dài thời gian nếu chưa có quyền và căn cứ. Kết quả xác minh quyết định phương án: xử lý cơ chế lỗi, điều chỉnh lưu giữ hợp lệ hoặc mở rộng năng lực.

Kế hoạch được bổ sung theo dõi tốc độ tăng cùng thời gian dự kiến chạm giới hạn. Mốc hành động tính cả thời gian phê duyệt và triển khai. Đồng thời, thay đổi nghiệp vụ được đưa thành điều kiện rà lại kế hoạch, tránh tiếp tục dùng giả định của giai đoạn trước.

Nếu mở rộng lưu trữ, cần kiểm tra hiệu suất, sao lưu và thời gian phục hồi sau thay đổi. Tăng dung lượng có thể làm khối lượng bảo vệ và khôi phục lớn hơn. Một công việc phòng ngừa ở tài nguyên vì vậy có thể yêu cầu cập nhật kế hoạch ở dịch vụ liên quan.

Đội theo dõi qua các chu kỳ có tải đại diện rồi đánh giá lại. Không tuyên bố đã loại bỏ rủi ro chỉ vì tài nguyên còn trống ngay sau mở rộng. Tình trạng mới phải được dùng làm đầu vào cho dự báo và lịch tiếp theo.

Duy trì danh sách ưu tiên có nguồn lực thực hiện

Kế hoạch nên thể hiện công việc, căn cứ, mức ưu tiên, hạn, người sở hữu và bằng chứng. Công việc quá hạn cần được rà theo tác động, không chỉ gửi nhắc tự động. Nếu thiếu cửa sổ hoặc nguồn lực kéo dài, phải đưa thành quyết định quản lý với lựa chọn rõ.

Năng lực IT Manager giúp cân đối bảo trì, yêu cầu hằng ngày và cải tiến. Đội không thể thực hiện mọi việc phòng ngừa bằng thời gian còn lại sau xử lý khẩn cấp. Cần phân bổ năng lực theo dịch vụ và giải thích rủi ro khi một việc bị trì hoãn.

Đo kết quả bằng công việc quan trọng quá hạn, lỗi lặp lại, phát hiện trước gián đoạn và tỷ lệ việc có kiểm chứng. Các chỉ số cần bối cảnh: số sự cố giảm có thể do tải giảm hoặc cách ghi nhận thay đổi. Không nên quy toàn bộ biến động cho kế hoạch bảo trì nếu chưa có bằng chứng liên quan.

Một vòng rà thực tế có thể bắt đầu từ dịch vụ quan trọng, chọn vài rủi ro có căn cứ và đưa vào lịch cùng tín hiệu kích hoạt sớm. Sau một chu kỳ, xem việc có được làm đúng điều kiện, có phát hiện sai lệch và có tạo thêm công việc cần giải quyết không. Kế hoạch được sửa bằng những kết quả ấy.

Phòng ngừa không bảo đảm hệ thống sẽ không bao giờ lỗi. Nó tạo thời gian và lựa chọn trước khi lỗi gây tác động lớn. Khi lịch, tín hiệu tình trạng và trách nhiệm được nối với nhau, đội IT có thể dùng nguồn lực vào những việc thực sự làm dịch vụ bền vững hơn.

Nguồn tham khảo

  1. NIST SP 800-128 — Guide for Security-Focused Configuration Management of Information Systems
  2. Google SRE — Monitoring Distributed Systems
  3. NIST SP 800-53 Rev. 5 — Security and Privacy Controls for Information Systems and Organizations