INFOCHIEF ACADEMY · ITSM KNOWLEDGE SERIES

Bắt đầu xây dựng CMDB từ đâu để tránh tốn công thu thập dữ liệu vô ích?

CMDB có ích khi dữ liệu cấu hình giúp trả lời một quyết định cụ thể về dịch vụ. Bắt đầu từ phạm vi nhỏ, quan hệ cần thiết và trách nhiệm cập nhật giúp tránh xây một kho lớn nhưng thiếu độ tin cậy để sử dụng.

Biên soạn: Infochief Academy · Chuyên đề: Quản lý dịch vụ IT

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

Minh họa biên tập: chuyên viên cấu hình và chủ dịch vụ lập bản đồ phụ thuộc ứng dụng.

Một dự án CMDB có thể bắt đầu bằng việc quét mọi thiết bị và nhập hàng nghìn bản ghi. Đến lúc cần đánh giá tác động của một thay đổi, đội ngũ vẫn không biết ứng dụng phụ thuộc thành phần nào hoặc bản ghi đã được cập nhật lần cuối ra sao. Kho dữ liệu lớn đã được tạo; độ tin cậy để ra quyết định vẫn còn thiếu.

CMDB cần được xây từ câu hỏi sử dụng. Dữ liệu về các mục cấu hình và quan hệ có ích khi giúp xử lý sự cố, đánh giá thay đổi hoặc quản lý dịch vụ. Không phải mọi thông tin có thể thu đều đáng đưa vào phạm vi; mỗi trường và quan hệ tạo thêm công sức kiểm chứng cùng duy trì.

Điểm khởi đầu tốt là một dịch vụ và một quyết định cụ thể, với người sẵn sàng dùng kết quả. Từ đó doanh nghiệp biết cần dữ liệu nào, mức đúng ra sao và ai chịu trách nhiệm khi thông tin thay đổi.

Chọn một câu hỏi mà dữ liệu cấu hình phải trả lời

Có thể bắt đầu từ đánh giá tác động trước khi thay một thành phần, tìm đầu mối khi ứng dụng lỗi hoặc xác định những dịch vụ dùng chung một phụ thuộc. Chọn câu hỏi đang gây chậm hoặc quyết định thiếu căn cứ. Nếu chỉ đặt mục tiêu có CMDB, tổ chức khó biết một dữ liệu mới có tạo giá trị hay không.

Tình huống giả định, nhóm vận hành cần biết thay cấu hình máy chủ xác thực sẽ ảnh hưởng ứng dụng nào. Phạm vi ban đầu cần các dịch vụ liên quan, thành phần xác thực và quan hệ đã kiểm chứng. Thu thêm thông tin về thiết bị không tham gia luồng này có thể cần cho quản lý tài sản, nhưng chưa chắc cần cho câu hỏi thử nghiệm.

Xác định người dùng dữ liệu và cách họ sẽ dùng. Một sơ đồ phụ thuộc chỉ hữu ích khi người đánh giá Change có thể đọc, hiểu giới hạn và kiểm tra phần chưa chắc. Nếu dữ liệu được nhập nhưng quy trình quyết định vẫn không nhìn đến, cần sửa cách tích hợp sử dụng trước khi tăng phạm vi thu.

Các thực hành trong chương trình Quản lý Dịch vụ IT giúp nối cấu hình với quyết định. CMDB nên hỗ trợ Incident, Problem và Change theo nhu cầu rõ, tránh trở thành một kho đứng ngoài các luồng đang vận hành.

Phân biệt quản lý tài sản với quản lý cấu hình

Quản lý tài sản quan tâm vòng đời và giá trị của tài sản theo phạm vi tổ chức. Quản lý cấu hình quan tâm thông tin về các mục cần để cung cấp dịch vụ, gồm trạng thái và quan hệ. Hai phần có thể chia sẻ dữ liệu, nhưng không phải mọi trường tài chính đều cần trong mỗi quyết định tác động kỹ thuật.

Một mục cấu hình, hay CI, cần được chọn theo mức quản lý có ý nghĩa. Có thể là dịch vụ, ứng dụng hoặc thành phần, tùy mô hình. Nếu tách quá nhỏ, quan hệ và số bản ghi khó duy trì; nếu gộp quá lớn, dữ liệu không giúp biết tác động nằm ở đâu. Mức chi tiết phải phù hợp câu hỏi đã chọn.

Không nên coi danh sách có mã tài sản và địa chỉ thiết bị là đủ CMDB phục vụ tác động. Quan hệ và bối cảnh dịch vụ mới giúp hiểu các phần nối nhau. Ngược lại, không phải mọi hệ thống quan hệ đều cần chứa toàn bộ hồ sơ mua sắm nếu có nguồn khác quản lý đúng và cách tham chiếu rõ.

Một nguồn xem chung không có nghĩa phải sao chép mọi dữ liệu vào một nơi. Có thể nối hoặc tham chiếu đến nguồn có trách nhiệm, tùy khả năng công cụ và thiết kế. Điều cần rõ là trường nào lấy từ đâu, ai có quyền sửa và cách xử lý khi các nguồn không thống nhất.

Thiết kế mô hình tối thiểu với quan hệ có ý nghĩa

Với mỗi loại CI, chọn định danh, tên, trạng thái, người sở hữu và các thuộc tính phục vụ câu hỏi. Định danh phải giúp nhận ra cùng một mục qua nhiều nguồn, tránh mỗi lần quét tạo một bản mới. Không nên chỉ dựa vào tên hiển thị nếu tên có thể đổi hoặc dùng trùng.

Quan hệ cần có loại và hướng rõ. Ứng dụng phụ thuộc một dịch vụ xác thực khác với hai ứng dụng cùng nằm trên một máy chủ. Nếu mọi quan hệ chỉ được ghi là “liên quan”, người đọc khó dùng để đánh giá tác động. Nêu điều quan hệ khẳng định và mức chi tiết của nó.

Dữ liệu ban đầu	Mục đích sử dụng	Điều kiện để tin cậy
Định danh và loại CI	Nhận diện đúng mục qua các nguồn	Quy tắc tránh trùng và xử lý đổi tên
Trạng thái cùng người sở hữu	Biết mục còn dùng và hỏi ai	Trách nhiệm cập nhật được nhận
Quan hệ phụ thuộc	Đánh giá ảnh hưởng dịch vụ	Loại, hướng và phạm vi đã kiểm chứng
Nguồn cùng lần kiểm chứng	Biết dữ liệu đúng đến mức nào	Cách cập nhật và phần giới hạn rõ

Bảng là mô hình gợi ý, không phải bộ trường bắt buộc cho mọi công cụ. Có thể bắt đầu bằng ít loại CI và quan hệ nhưng dùng được. Chỉ thêm thuộc tính khi biết quyết định nào cần nó và có nguồn duy trì phù hợp, tránh ghi mọi dữ liệu đang tìm thấy rồi chờ người khác nghĩ cách sử dụng.

Thông tin nhạy cảm cần được phân loại. Mật khẩu, khóa truy cập và mã khôi phục không phải thuộc tính để lưu trong bản ghi cấu hình thông thường. Người đánh giá tác động có thể cần bối cảnh hệ thống nhưng không cần đọc mọi thông tin đặc quyền phía sau.

Chọn nguồn và giải quyết mâu thuẫn trước khi nhập rộng

Công cụ discovery có thể phát hiện một số trạng thái kỹ thuật, nhưng không tự biết mọi quan hệ kinh doanh hoặc quyền sở hữu. Danh mục dịch vụ, nguồn quản lý thiết bị và người vận hành có thể cung cấp các phần khác nhau. Cần xác định nguồn phù hợp cho từng trường, tránh coi một công cụ quét là câu trả lời đầy đủ.

Nếu hai nguồn báo khác nhau, thiết kế quy tắc đối chiếu và người xử lý. Không nên chọn bản cập nhật gần nhất một cách máy móc nếu nguồn đó không có quyền xác định giá trị. Một trường chủ dịch vụ không tự đổi chỉ vì dữ liệu kỹ thuật mới được quét sau.

Nhập thử một phạm vi nhỏ, kiểm trùng, trạng thái và quan hệ trước khi chạy rộng. Dữ liệu lỗi được nhập hàng loạt có thể tốn công sửa hơn công sức thu ban đầu. Giữ khả năng theo dõi nguồn và lần kiểm chứng, để người dùng biết phần nào đáng tin và phần nào cần xác nhận thêm.

Năng lực quản lý cấu hình và vận hành trong chương trình IT Administrator giúp đánh giá những giới hạn này. Dữ liệu tự động vẫn cần mô hình và trách nhiệm, nhất là với môi trường có nhiều nền tảng hoặc vòng đời ngắn.

Cập nhật phải đi cùng vòng đời và thay đổi thực

Một bản ghi đúng lúc thu có thể sai sau lần triển khai kế tiếp. Cần nối cập nhật với Change, cấp mới, chuyển giao và ngừng sử dụng theo phạm vi. Các trường có thể tự đồng bộ cần cơ chế kiểm tra lỗi; các trường thủ công cần người cùng thời điểm cập nhật rõ.

Khi ngừng một CI, giữ lịch sử hoặc quan hệ theo nhu cầu được phê duyệt, nhưng trạng thái phải tránh bị hiểu là còn hoạt động. Khi đổi cấu hình hoặc phụ thuộc, phần thông tin liên quan phải được rà. Không nên chỉ sửa một bản ghi rồi để sơ đồ dịch vụ tiếp tục dùng quan hệ cũ.

Kiểm tra định kỳ giúp tìm sai lệch, nhưng không thay cơ chế cập nhật theo sự kiện. Có thể chọn các CI quan trọng và quan hệ hay dùng để rà trước. Không cần cố kiểm mọi trường với cùng tần suất; mức kiểm cần theo rủi ro cùng khả năng thay đổi.

Trưởng nhóm giữ việc cập nhật trong công việc thường lệ và giải quyết bản ghi chưa có người sở hữu. Các năng lực điều phối trong chương trình IT Supervisor giúp phân công và rà dữ liệu có mục tiêu, thay vì xem cập nhật CMDB là một việc làm thêm sau ca.

Kiểm chứng bằng quyết định thực, không chỉ bằng số bản ghi

Thử dùng mô hình để đánh giá một thay đổi và xử lý một ca sự cố trong phạm vi chọn. Người dùng có tìm được CI, dịch vụ ảnh hưởng và đầu mối không? Phần dữ liệu có làm thay đổi quyết định hoặc giảm một vòng tìm kiếm không? Câu trả lời giúp biết cần sửa mô hình, nguồn hay cách đưa dữ liệu vào luồng.

Tình huống giả định, sơ đồ cho biết một ứng dụng phụ thuộc dịch vụ xác thực nhưng người đánh giá chưa biết quan hệ đã được xác nhận lúc nào. Họ phải kiểm lại trước khi quyết định. Đây là tín hiệu bổ sung thông tin kiểm chứng hoặc sửa cơ chế cập nhật, không nhất thiết là lý do thu thêm nhiều CI ngoài phạm vi.

Đo tính đầy đủ theo câu hỏi, độ đúng qua mẫu kiểm và thời gian dữ liệu được cập nhật sau thay đổi. Số bản ghi lớn chỉ phản ánh quy mô, chưa phản ánh khả năng dùng. Một tỷ lệ đầy đủ cao cũng có thể thiếu quan hệ quan trọng nếu danh sách trường được tính chưa khớp mục tiêu.

Dữ liệu có giới hạn cần thể hiện giới hạn. CMDB không tự bảo đảm đánh giá tác động chính xác nếu có phụ thuộc chưa biết. Người quyết định phải kiểm phần còn thiếu và chọn hành động phù hợp. Công cụ hỗ trợ căn cứ, không thay trách nhiệm chuyên môn hoặc quyền cho phép thay đổi.

Mở rộng khi lợi ích đủ rõ và năng lực duy trì đủ thật

Sau thử, chọn dịch vụ hoặc câu hỏi tiếp theo dựa trên tác động và khả năng duy trì. Không nên mở rộng chỉ vì discovery có thể quét thêm. Mỗi phạm vi mới cần nguồn, chủ sở hữu và cách kiểm. Nếu đội chưa giữ được mô hình nhỏ đúng, tăng quy mô có thể chỉ tăng nợ dữ liệu.

Vai trò ưu tiên và nguồn lực trong chương trình IT Manager liên hệ với quyết định mở rộng. Báo cáo nên cho thấy quyết định nào đã được hỗ trợ, công sức duy trì và phần rủi ro chưa giải quyết, để lãnh đạo chọn đầu tư bằng giá trị thực.

Bước đầu tiên là viết một câu hỏi về dịch vụ, chọn các CI và quan hệ tối thiểu để trả lời, rồi thử bằng một quyết định thực. Khi dữ liệu được dùng và được giữ đúng qua thay đổi, CMDB mới trở thành nền tảng đáng tin. Doanh nghiệp tránh lãng phí bằng cách thu những gì có người cần và có người duy trì, thay vì bắt đầu từ tham vọng lưu tất cả những gì có thể tìm thấy.