INFOCHIEF ACADEMY · IT ADMINISTRATOR KNOWLEDGE SERIES

Xây dựng mô hình quản trị vận hành IT: Con người, quy trình, công nghệ và trách nhiệm.

Mô hình vận hành IT cần nối vai trò, quyền quyết định, luồng công việc và công cụ quanh dịch vụ. Điểm giao nhận rõ cùng bằng chứng thực hiện giúp các nhóm phối hợp ngay cả khi hệ thống hoặc nhân sự thay đổi.

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

Minh họa biên tập: đội vận hành IT thống nhất vai trò và luồng công việc trên bảng dịch vụ.

Một ứng dụng ngừng hoạt động giữa giờ làm việc. Nhóm hạ tầng kiểm tra và báo máy chủ bình thường; nhà cung cấp cho rằng lỗi nằm ở mạng; đội ứng dụng chờ người có quyền truy cập cơ sở dữ liệu. Mỗi bên đều có chuyên môn, nhưng dịch vụ vẫn chưa được khôi phục vì không ai điều phối toàn bộ chuỗi xử lý.

Tình huống quen thuộc này cho thấy vận hành IT không thể chỉ được thiết kế bằng sơ đồ tổ chức hoặc danh sách công cụ. Doanh nghiệp cần một mô hình kết nối con người, quy trình, công nghệ và trách nhiệm quanh các dịch vụ thực tế. Mô hình tốt phải trả lời được ai hành động, ai quyết định và bằng chứng nào xác nhận công việc đã hoàn tất.

Lấy dịch vụ làm điểm xuất phát

Nếu bắt đầu từ thiết bị, mô hình dễ chia thành các nhóm máy chủ, mạng và phần mềm đứng cạnh nhau. Cách chia đó cần cho chuyên môn, nhưng chưa đủ để quản lý trải nghiệm người dùng. Một dịch vụ thường phụ thuộc vào nhiều nhóm, nhiều nhà cung cấp và các quy trình nghiệp vụ bên ngoài IT.

Hãy chọn một dịch vụ quan trọng và mô tả đầu ra mà doanh nghiệp cần. Ví dụ, “nhân viên lập và xác nhận đơn hàng” rõ hơn “vận hành máy chủ ERP”. Phạm vi dịch vụ phải bao gồm người dùng, giờ hỗ trợ, thành phần phụ thuộc, trách nhiệm với dữ liệu và đường liên hệ khi có vấn đề.

Sau đó xác định chủ dịch vụ, tức người chịu trách nhiệm điều phối chất lượng dịch vụ trong phạm vi được giao. Người này không nhất thiết tự thao tác trên mọi hệ thống. Vai trò của họ là giữ một góc nhìn xuyên suốt, giải quyết khoảng trống phối hợp và đưa vấn đề vượt thẩm quyền lên đúng cấp.

Khi học hoặc áp dụng kỹ năng từ chương trình IT Administrator, doanh nghiệp nên đặt thao tác kỹ thuật vào bức tranh dịch vụ này. Nhờ vậy, kiểm tra máy chủ có thể được nối với kiểm tra giao dịch, lịch bảo trì và yêu cầu phục hồi thay vì tồn tại thành những công việc rời rạc.

Phân định quyền quyết định trước khi phân ca trực

Một bảng phân công ghi “IT xử lý” không đủ rõ khi sự cố xảy ra. Trong cùng một tình huống, có người tiếp nhận, người chẩn đoán, người thao tác, người phê duyệt thay đổi khẩn cấp và người xác nhận nghiệp vụ hoạt động lại. Những vai trò này có thể do một người đảm nhiệm ở tổ chức nhỏ, nhưng vẫn cần được gọi tên.

Quyền quyết định phải đi cùng trách nhiệm và giới hạn. Ai được cô lập thành phần đang gây lỗi? Ai có thể chấp nhận gián đoạn để khôi phục dữ liệu? Ai quyết định thông báo cho khách hàng? Nếu không thống nhất trước, đội thường mất thời gian xin ý kiến đúng lúc áp lực cao nhất.

Có thể dùng ma trận trách nhiệm đơn giản, nhưng không nên biến nó thành mục tiêu tự thân. Một ô “chịu trách nhiệm cuối cùng” cần tương ứng với quyền thực tế, khả năng tiếp cận thông tin và cơ chế thay thế khi người đó vắng mặt. Một tên trên bảng không giải quyết được việc người trực không có quyền truy cập cần thiết.

Điểm quyết định	Vai trò cần làm rõ	Bằng chứng cần lưu
Xác nhận mức độ ảnh hưởng	Chủ dịch vụ phối hợp đầu mối nghiệp vụ	Dịch vụ, người dùng và thời điểm bị tác động
Thực hiện thay đổi có rủi ro	Người thao tác và người phê duyệt theo cơ chế đã giao	Phạm vi, điều kiện, quyết định và kết quả
Chấp nhận dịch vụ hoạt động lại	Đầu mối kỹ thuật cùng người xác nhận nghiệp vụ	Kiểm tra kỹ thuật và giao dịch đại diện
Chuyển việc cho nhà cung cấp	Đầu mối điều phối có quyền theo hợp đồng	Hồ sơ chuyển giao và xác nhận tiếp nhận

Sau khi chốt vai trò, mới nên xây lịch trực và kế hoạch dự phòng nhân sự. Cần tính đến nghỉ phép, ca ngoài giờ, giới hạn sức tải và kỹ năng khan hiếm. Một mô hình chỉ hoạt động khi người giỏi nhất luôn có mặt là mô hình đang mang rủi ro nhân sự.

Thiết kế luồng công việc có điểm giao nhận

Vai trò rõ vẫn có thể phối hợp kém nếu công việc đi qua các nhóm mà không có điều kiện chuyển giao. Một yêu cầu thiếu thời điểm lỗi, phạm vi ảnh hưởng hoặc thông tin liên hệ sẽ khiến nhóm nhận phải hỏi lại. Mỗi vòng hỏi lại kéo dài thời gian dù từng nhóm đều phản hồi nhanh.

Với luồng xử lý sự cố, hãy thống nhất dữ liệu tối thiểu khi tiếp nhận, cách xác định mức ưu tiên, điều kiện chuyển cấp và trách nhiệm cập nhật thông tin. Khi một nhóm chuyển việc, cần có xác nhận nhóm tiếp theo đã nhận; việc gán tên trong công cụ chưa chắc đồng nghĩa có người đang xử lý.

Với thay đổi, luồng phải nối nhu cầu, đánh giá tác động, phê duyệt, triển khai và kiểm chứng. Với cải tiến sau sự cố, luồng phải giữ được công việc còn lại sau khi dịch vụ đã phục hồi. Nếu cả hai loại việc đều bị trộn vào hàng đợi yêu cầu hằng ngày, những vấn đề dài hạn dễ mất chủ sở hữu.

Năng lực quản lý dịch vụ IT giúp thiết kế những điểm nối này. Điều cần đạt là một nhịp làm việc có đầu vào và đầu ra rõ, phù hợp quy mô tổ chức. Doanh nghiệp nhỏ có thể dùng ít bước hơn, nhưng không nên bỏ mất quyền quyết định hoặc bằng chứng bàn giao.

Cần quy định cả cách phối hợp khi công cụ chính không dùng được. Đường liên hệ khẩn cấp, nơi lưu thông tin dự phòng và cách đưa quyết định trở lại hồ sơ sau sự cố phải được thống nhất. Nếu mọi hướng dẫn đều nằm trong hệ thống đang hỏng, mô hình vận hành sẽ mất hiệu lực đúng lúc cần nhất.

Chọn công nghệ để hỗ trợ mô hình đã thống nhất

Công cụ quản lý phiếu, giám sát, quản lý cấu hình và tự động hóa có thể giảm công sức đáng kể. Tuy nhiên, triển khai công cụ trước khi rõ trách nhiệm thường chỉ làm khoảng trống quản trị xuất hiện nhanh hơn. Phiếu được tạo tự động vẫn có thể không có người nhận hoặc bị chuyển qua lại giữa các nhóm.

Nên xác định thông tin cần dùng để quyết định rồi mới chọn khả năng tích hợp. Cảnh báo cần gắn với dịch vụ và chủ sở hữu; thay đổi cần nối với thành phần cấu hình; hồ sơ sự cố cần tìm được lịch sử triển khai liên quan. Không nhất thiết đưa mọi dữ liệu vào một hệ thống, nhưng phải biết nguồn nào có thẩm quyền cho từng loại thông tin.

Tự động hóa cũng cần quyền hạn phù hợp, kiểm soát phiên bản và điều kiện dừng. Một thao tác tự sửa chỉ nên thực hiện trong phạm vi đã được kiểm chứng. Khi biểu hiện khác giả định ban đầu, hệ thống cần chuyển sang điều tra thay vì lặp lại vô hạn một hành động có thể làm mất bằng chứng.

Quyền truy cập và tài khoản dịch vụ là phần quan trọng của thiết kế. Nội dung trong quản trị an toàn thông tin giúp đội xem xét việc phân quyền, lưu dấu thao tác và bảo vệ thông tin nhạy cảm. Trách nhiệm vận hành rõ nhưng quyền truy cập quá rộng vẫn tạo một mô hình thiếu kiểm soát.

Kiểm chứng bằng một ca vận hành giả định

Giả sử doanh nghiệp dùng ứng dụng quản lý kho do đối tác triển khai, chạy trên hạ tầng nội bộ và kết nối dịch vụ định danh thuê ngoài. Trong một ca giả định, nhân viên kho không đăng nhập được. Mục đích diễn tập là kiểm tra mô hình, không phải chứng minh một công nghệ cụ thể bị lỗi.

Đầu mối tiếp nhận xác nhận phạm vi và thời điểm ảnh hưởng; kỹ sư mạng kiểm tra đường kết nối; quản trị ứng dụng kiểm tra log xác thực. Chủ dịch vụ điều phối các nhóm, còn người có thẩm quyền nghiệp vụ xác định kho có thể chuyển sang phương án tạm thời hay không.

Nếu cần thay đổi cấu hình, nhóm thực hiện trình phương án cùng khả năng quay lui. Nhà cung cấp nhận hồ sơ gồm bằng chứng đã thu thập, không chỉ thông báo “hệ thống không chạy”. Sau khi xử lý, nhân viên kho kiểm tra đăng nhập và một giao dịch đại diện trước khi thông báo dịch vụ trở lại bình thường.

Buổi diễn tập có thể phát hiện quyền truy cập thiếu, đầu mối đối tác không liên hệ được hoặc người phê duyệt ngoài giờ chưa có phương án thay thế. Đây là kết quả hữu ích. Chúng cho thấy những điểm phải sửa trước khi tình huống thật xảy ra, thay vì chỉ đánh giá đội thao tác nhanh hay chậm.

Sau diễn tập, mỗi khoảng trống cần thành một công việc có hạn hoàn thành. Nếu một nhóm nhận trách nhiệm mới, phải kiểm tra họ có năng lực và nguồn lực để thực hiện. Chuyển tên trên bảng mà không chuyển quyền, thông tin và thời gian chỉ làm rủi ro đổi địa chỉ.

Duy trì mô hình bằng nhịp rà soát thực tế

Mô hình vận hành không đứng yên. Dịch vụ mới, nhà cung cấp mới, thay đổi nhân sự và chuyển hệ thống lên cloud đều có thể làm trách nhiệm cũ không còn phù hợp. Vì vậy, rà soát mô hình nên được gắn vào những thay đổi đáng kể, cùng một nhịp kiểm tra định kỳ do doanh nghiệp lựa chọn.

Các chỉ số nên phản ánh điểm giao nhận: thời gian chờ chuyển cấp, phiếu bị chuyển nhiều lần, công việc chưa có chủ sở hữu và tỷ lệ khôi phục có xác nhận nghiệp vụ. Dữ liệu này giúp nhận biết vấn đề phối hợp mà chỉ số số lượng phiếu hoàn thành không thể hiện.

Người quản lý cần dành năng lực cho ba nhóm việc: duy trì dịch vụ, thực hiện thay đổi và cải tiến cách vận hành. Tỷ lệ phân bổ tùy nhu cầu, không có con số chung cho mọi doanh nghiệp. Nếu đội luôn bị ngắt bởi yêu cầu khẩn cấp, phải xem lại khối lượng công việc và chất lượng các cơ chế phòng ngừa.

Ở cấp điều phối, năng lực IT Manager giúp đưa vấn đề nguồn lực và quyền quyết định ra khỏi phạm vi kỹ thuật thuần túy. Một dịch vụ cần hỗ trợ ngoài giờ phải có cam kết nhân sự, nhà cung cấp và ngân sách tương ứng; đội vận hành không thể tự tạo những điều kiện đó bằng nỗ lực cá nhân.

Doanh nghiệp có thể bắt đầu bằng một dịch vụ quan trọng thay vì triển khai toàn bộ mô hình cùng lúc. Khi đường trách nhiệm, luồng công việc và công cụ đã được kiểm chứng, những bài học được áp dụng sang dịch vụ tiếp theo. Mô hình trưởng thành từ khả năng thực hiện nhất quán, chứ không từ số lượng quy trình được ban hành.

Khi con người biết vai trò của mình, quy trình có điểm giao nhận và công nghệ cung cấp đúng bằng chứng, việc vận hành trở nên dễ điều phối hơn. Đó là nền tảng để đội IT giữ dịch vụ ổn định ngay cả khi thành phần kỹ thuật và đội ngũ tiếp tục thay đổi.