HRM đúng, nhưng mình vẫn chưa cho phép nó sửa Active Directory

Khi dữ liệu HRM và Active Directory không khớp nhau, vấn đề không chỉ là xác định bên nào đúng. Quan trọng hơn là automation đã đủ đáng tin để được quyền thay đổi identity production hay chưa.

Có một bài toán nhìn qua khá đơn giản.

HRM có thông tin nhân viên. Active Directory cũng có thông tin nhân viên. Một số application lại cần Manager, Job Title, Employee ID và các thuộc tính identity khác để hiển thị hoặc phân quyền đúng.

Nếu HRM là nguồn dữ liệu chính thức, cách tự nhiên nhất có vẻ là:

Về mặt kỹ thuật, làm như vậy không khó.

Nhưng mình không muốn bắt đầu ở đó.

Câu hỏi đầu tiên không phải là “Làm sao sync HRM sang AD?”

Source of Truth không đồng nghĩa với Write Authority

HRM có thể là authoritative source cho Employee ID, Manager, Title, trạng thái nhân sự hoặc một số thuộc tính tổ chức. Khi hai hệ thống không khớp, đó là nơi mình quay lại để đối chiếu.

Nhưng điều đó chưa tự động dẫn đến kết luận rằng một integration được phép viết trực tiếp vào Active Directory.

Source of Truth trả lời: dữ liệu nào được xem là đúng.

Write Authority trả lời: thành phần nào được phép thay đổi production identity.

Nếu gộp hai câu hỏi thành một, architecture rất dễ đi thẳng từ HRM sang AD write-back. Nhanh, gọn, nhưng cũng tạo ra một đường thay đổi khá mạnh. Một record sai ở source, một mapping sai hoặc một identity match nhầm có thể trở thành production change trước khi con người kịp nhìn thấy.

Đầu tiên chỉ đọc

Luồng đầu tiên mình thích là một chiều: HRM → Middleware → Consumer. Middleware đọc dữ liệu cần thiết từ HRM, normalize và transform, nhưng không thay đổi ngược về HRM. Consumer cũng không trở thành một nơi khác để business sửa dữ liệu nhân sự.

HR vẫn sở hữu dữ liệu nhân sự. Integration chỉ đọc và đối chiếu. Active Directory chưa bị thay đổi chỉ vì hệ thống phát hiện ra một difference.

Ở bước này, mismatch vẫn chỉ là một observation. Nó chưa phải là một change.

Detect trước, Remediate sau

Khi bắt đầu so HRM với AD, sẽ xuất hiện những trường hợp như Manager khác nhau, Title chưa cập nhật, Employee ID thiếu hoặc một identity không map được chắc chắn với employee record.

Nếu automation ngay lập tức sửa mọi difference, mình sẽ mất đi một giai đoạn rất có giá trị: giai đoạn nhìn xem rule của mình có thật sự đúng không.

Trong detect-only mode, hệ thống có thể nói: HRM đang nói A, AD đang nói B, hai bên không giống nhau. Nhưng nó chưa tự quyết định rằng AD phải trở thành A.

Chính giai đoạn này giúp lộ ra những case mà một câu query đơn giản không nói được: account không map an toàn, một record là intentional exception, identifier chưa đủ chắc hoặc context business nằm ngoài thứ automation nhìn thấy.

Detect-only không phải trạng thái tạm

Một cách rất dễ hình dung automation là Detect → Review → Remediate. Nhưng flow đó không có nghĩa mọi rule cuối cùng đều phải đi tới remediation.

Có những mismatch có logic đủ rõ, identifier đủ chắc và mức ảnh hưởng đủ kiểm soát để automation có thể sửa.

Cũng có những nhóm dữ liệu mà giá trị lớn nhất của hệ thống chỉ là phát hiện → cảnh báo → đưa cho đúng người review.

Một thuộc tính có nhiều business exception, phụ thuộc context mà hệ thống không nhìn thấy hoặc có downstream impact khó dự đoán thì detect-only có thể là trạng thái vận hành lâu dài — không phải một phiên bản “chưa hoàn thiện” của automation.

Một rule detect-only nhưng phát hiện đúng, ít false positive, có owner rõ và tạo ra signal hữu ích có thể giá trị hơn một rule tự remediation nhưng phải dựa trên quá nhiều assumption.

Vì vậy remediation không phải destination mặc định. Nó chỉ là một trong các outcome sau detection.

Match được chưa chắc đã được phép sửa

Một employee record có thể chứa employee code, corporate email, manager, title và các thông tin tổ chức khác. AD cũng có UPN, mail, Employee ID và account metadata.

Nếu chỉ cần “tìm một account trông giống người này”, việc match khá dễ. Nhưng tiêu chuẩn để thay đổi account nên cao hơn tiêu chuẩn để hiển thị một candidate match.

Với detect-only, mình có thể chấp nhận mức confidence thấp hơn và flag record để review. Với remediation, mình muốn chắc hơn nhiều.

Một mapping sai trên portal là lỗi dữ liệu. Một automation sửa nhầm Manager hoặc thuộc tính identity trong AD có thể tiếp tục đi qua Entra ID và ảnh hưởng những hệ thống khác.

Phạm vi ảnh hưởng đã khác.

Exception không phải lúc nào cũng là lỗi

Một automation rất dễ rơi vào giả định: nếu dữ liệu không đúng rule thì dữ liệu đang sai.

Thực tế không phải lúc nào cũng vậy.

Có những account hoặc record được xử lý riêng có chủ đích. Nếu hệ thống không có khái niệm exception, mỗi lần chạy automation sẽ tiếp tục phát hiện cùng một “lỗi” và cố sửa nó.

Mình thích việc intentional exception trở thành một phần chính thức của rule: có lý do, có owner và có thể review lại. Không phải một thứ chỉ nằm trong trí nhớ của engineer.

Fail closed quan trọng hơn chạy hết

Khi automation có quyền sửa identity, mình không muốn philosophy của nó là “cố chạy càng nhiều càng tốt”. Mình muốn nó thiên về: không chắc thì dừng.

Nếu một employee record map được nhiều account, thiếu identifier quan trọng hoặc trạng thái source không đủ rõ, safest action có thể là không làm gì cả.

Một false negative — chưa sửa một record đáng ra có thể sửa — thường có thể review sau. Một false positive — sửa nhầm identity — có thể khó giải thích hơn nhiều.

AD chưa phải điểm cuối

Trong môi trường hybrid identity, thay đổi trong on-premises AD chưa chắc đã dừng ở đó. Một số thuộc tính tiếp tục được đồng bộ lên Entra ID, rồi application khác lại dùng Entra làm identity source.

Vì vậy mình không chỉ hỏi: “AD có cập nhật đúng không?”

Mình hỏi tiếp: “Sau khi AD đúng, downstream identity có trở thành trạng thái mình mong muốn không?”

Một change được xem là thành công chỉ vì PowerShell trả về exit code 0 là chưa đủ.

Audit trail không nên là thứ làm sau cùng

Khi automation bắt đầu thay đổi production identity, mình muốn trả lời được: process nào thực hiện thay đổi, before value là gì, after value là gì, dữ liệu mới đến từ đâu, rule nào quyết định record đủ điều kiện và sau thay đổi đã verify gì.

Nếu những câu đó chỉ có thể trả lời bằng cách đọc lại source code thì audit trail chưa đủ tốt.

Remediation nên tạo ra bằng chứng ngay trong flow: detected value, proposed value, action taken, result và validation.

Rollback phải được nghĩ trước khi mở Write

Với script read-only, rollback gần như không phải câu hỏi lớn. Với script thay Manager, Title hoặc Employee ID thì khác.

Nếu change sai, mình cần biết giá trị trước đó. Nếu chạy hàng loạt, mình cần biết record nào đã thay đổi thành công trước khi job dừng. Nếu downstream sync đã chạy, rollback AD cũng cần được verify lại ở trạng thái cuối.

Trước khi mở write permission, mình muốn remediation có ít nhất ba thứ: before value, after value và result.

Khi nào một rule đủ điều kiện để remediation?

Không phải toàn bộ hệ thống cần chuyển từ detect-only sang remediation. Quyết định nên nằm ở từng rule.

Một attribute có mapping rõ, identifier đủ chắc, exception đã được hiểu và validation/rollback đầy đủ có thể được tự động sửa. Một attribute khác vẫn có thể tiếp tục detect-only lâu dài.

Automation không cần phải là all-or-nothing.

Với mình, thời điểm mở write không nằm ở việc script đã chạy được. Nó nằm ở việc mình đã hiểu đủ mismatch, có guardrail cho case không chắc chắn và biết cách kiểm chứng trạng thái cuối.

Điều mình giữ lại

Trước bài toán này, cụm từ Source of Truth nghe khá dứt khoát: có một hệ thống đúng, những hệ thống khác phải theo nó.

Sau khi làm sâu hơn với identity, mình thấy còn một câu cần thêm vào phía sau:

Khoảng cách giữa hai việc đó là nơi mình đặt detection, validation, exception handling, audit và rollback.

Và với identity, khoảng cách đó đáng để giữ.

Automation tốt không chỉ biết phải sửa gì. Nó còn phải biết khi nào chưa nên sửa.