Cách xây dựng ứng dụng web theo dõi thiết bị và quyền truy cập

Xác định vấn đề và phạm vi cho Version 1

Trước khi chọn cơ sở dữ liệu hay phác thảo màn hình, hãy làm rõ bạn đang giải quyết vấn đề gì. Một ứng dụng theo dõi thiết bị nhân viên dễ biến thành dự án “theo dõi mọi thứ” — nên Version 1 nên tập trung vào những điều thiết yếu giảm thất thoát và ngăn sai sót truy cập.

Quyết định những gì phải theo dõi (và những gì có thể bỏ qua)

Bắt đầu bằng cách liệt kê các mục tạo rủi ro thực sự hoặc công việc lặp lại:

• Thiết bị: laptop, desktop, tablet, điện thoại
• Phụ kiện: màn hình, dock, sạc, tai nghe
• Giấy phép phần mềm: công cụ theo ghế cần lịch sử phân bổ
• Quyền vật lý: thẻ, chìa khóa, keycard, vé đậu xe

Với mỗi loại, ghi các trường tối thiểu bạn cần để vận hành. Ví dụ: với laptop, bạn có thể cần asset tag, serial number, model, trạng thái, người đang sử dụng và vị trí. Điều này giữ cho ứng dụng quản lý tài sản của bạn bám sát các quyết định hàng ngày thay vì dữ liệu "muốn có".

Xác định các bên liên quan và người ra quyết định

Quản lý thiết bị và quyền truy cập nằm giữa nhiều đội, nên làm rõ ai tạo, ai phê duyệt và ai kiểm toán các thay đổi:

• IT: tồn kho thiết bị, luồng phân bổ/thu hồi, trả sửa
• HR: ngày bắt đầu, thay đổi vai trò, kích hoạt checklist offboarding
• Facilities: chìa khóa, phòng, vị trí chỗ ngồi
• Security: cấp thẻ, nhóm truy cập, kỳ vọng tuân thủ
• Quản lý nhóm: lý do kinh doanh, phê duyệt, ngoại lệ

Bạn không chỉ thu thập yêu cầu — bạn đang quyết định ai chịu trách nhiệm khi có thứ gì đó bị mất hoặc quyền truy cập bị cấp sai.

Định nghĩa các chỉ số thành công có thể đo lường

Chọn vài chỉ số bạn có thể theo dõi từ ngày đầu, chẳng hạn:

• Ít tài sản “mất” hơn và truy hồi nhanh hơn
• Thời gian onboarding nhanh hơn (yêu cầu → được phân bổ → sẵn sàng)
• Ít trường hợp quên thu hồi quyền khi offboarding
• Nhật ký kiểm toán và bằng chứng tuân thủ rõ ràng (ai thay đổi gì, khi nào)

Khoá phạm vi v1 (và để phần còn lại lại sau)

Một v1 tốt cung cấp theo dõi tồn kho tin cậy cho nhân viên, RBAC cơ bản và nhật ký kiểm tra đơn giản. Lưu các tính năng nâng cao — quét mã vạch/QR, báo cáo sâu, và tích hợp HRIS/IdP/ticketing — cho các bản phát hành sau khi workflow lõi hoạt động và được chấp nhận.

Mô hình dữ liệu: Employees, Equipment, và Access Rights

Mô hình dữ liệu tốt khiến mọi thứ khác dễ dàng hơn: workflow, quyền, lịch sử kiểm toán và báo cáo. Ở phiên bản đầu, giữ số lượng thực thể nhỏ nhưng nghiêm ngặt về định danh và trường trạng thái.

Employees: chọn một định danh “nguồn tin cậy” duy nhất

Chọn một định danh nhân viên duy nhất mà sẽ không bao giờ được tái sử dụng. Nhiều đội dùng employee_id do HR cung cấp hoặc email công ty. Email tiện lợi nhưng có thể thay đổi; HR ID an toàn hơn.

Quyết định nguồn tạo bản ghi nhân viên:

• Đồng bộ hệ thống HR (tốt nhất về dài hạn): nhân viên được tạo/cập nhật tự động.
• Nhập tay (bắt đầu nhanh nhất): thêm quy tắc xác thực và cờ “inactive/terminated”.

Lưu những thông tin cơ bản cần cho phân bổ: tên, nhóm/phòng ban, vị trí, quản lý và trạng thái việc làm. Tránh nhúng danh sách quyền/thiết bị trực tiếp vào hồ sơ nhân viên; hãy mô hình hoá chúng như quan hệ.

Equipment: chuẩn hoá loại, thu thập thuộc tính để tìm kiếm

Tách equipment items (tài sản cá thể) khỏi equipment types (laptop, điện thoại, badge reader). Mỗi item nên có asset tag duy nhất cùng các định danh nhà sản xuất.

Thuộc tính phổ biến nên có từ ngày đầu:

• Serial number, model, ngày mua, ngày hết bảo hành
• Tình trạng (ví dụ: mới/tốt/hỏng), và trạng thái vòng đời (in_stock/assigned/in_repair/retired)
• Vị trí hiện tại (văn phòng, kho, remote)

Access rights: coi quyền là tài sản hạng nhất

Định nghĩa loại quyền rộng: app SaaS, thư mục chia sẻ, VPN, cửa vật lý, nhóm/role bảo mật. Một mô hình thực tế là Access Resource (ví dụ: “GitHub Org”, “Finance Drive”, “HQ Door”) cộng với Access Grant liên kết nhân viên với tài nguyên đó với trạng thái (requested/approved/granted/revoked).

Workflow: biểu diễn chuyển trạng thái sớm

Trước khi xây màn hình, vẽ cách dữ liệu thay đổi cho các luồng chính: assign, return, transfer, repair, và retire. Nếu bạn có thể diễn tả mỗi luồng như một thay đổi trạng thái đơn giản cộng dấu thời gian và “ai làm”, ứng dụng sẽ giữ nhất quán khi mở rộng.

Thiết lập vai trò, quyền và quy tắc phê duyệt

Nếu ứng dụng của bạn theo dõi cả thiết bị và quyền truy cập, quyền không phải "muốn có" — chúng là phần của hệ thống kiểm soát. Định nghĩa vai trò sớm để xây màn hình, workflow và quy tắc kiểm toán quanh chúng.

Bắt đầu với vai trò theo công việc rõ ràng

Một tập v1 thực tế thường bao gồm:

• Admin: quản lý cấu hình (vị trí, loại thiết bị, hệ thống truy cập), tài khoản người dùng và ghi đè khẩn cấp.
• IT Technician: phân/thu hồi thiết bị, cập nhật trạng thái thiết bị, khởi tạo yêu cầu truy cập.
• Manager: phê duyệt yêu cầu truy cập cho trực thuộc và xác nhận bước offboarding.
• Auditor: quyền đọc lịch sử, báo cáo và bằng chứng (ai phê duyệt gì, khi nào, vì sao).
• Read-only: xem hồ sơ mà không sửa (helpdesk, security desk, HR partner).

Áp dụng nguyên tắc ít quyền nhất theo hành động, không theo trang

Tránh quyền “tất cả hoặc không có”. Phân quyền thành các hành động gắn với rủi ro:

• Xem hồ sơ nhân viên vs. sửa hồ sơ nhân viên
• Phân thiết bị vs. đánh dấu mất/loại bỏ
• Yêu cầu truy cập vs. phê duyệt truy cập vs. thu hồi truy cập
• Xuất báo cáo (thường nhạy cảm hơn bạn nghĩ)

Cân nhắc giới hạn theo trường: ví dụ, Auditor có thể xem log phê duyệt và dấu thời gian nhưng không thấy chi tiết liên hệ cá nhân.

Thêm phê duyệt khi rủi ro lớn hơn

Phân bổ thiết bị có thể do IT làm, nhưng quyền đặc quyền thường cần phê duyệt. Quy tắc phổ biến:

• Phê duyệt của quản lý cho truy cập nâng quyền (admin panel, hệ thống production, công cụ tài chính)
• Truy cập có thời hạn với ngày hết hạn cho dự án tạm thời
• Lý do bắt buộc cho các yêu cầu nhạy cảm (lưu cùng bản ghi phê duyệt)

Thực thi phân tách nhiệm vụ

Với hành động nhạy cảm, ngăn cùng một người tạo và phê duyệt:

• Người yêu cầu không thể tự phê duyệt.
• Người cấp quyền không thể là người phê duyệt duy nhất.

Điều này giữ tính tin cậy của nhật ký kiểm toán và giảm rủi ro "phê duyệt qua loa" mà không làm chậm công việc hàng ngày.

Thiết kế workflow cốt lõi và checklist

Workflow là nơi ứng dụng theo dõi thiết bị và quyền trở nên thực sự hữu ích. Thay vì chỉ lưu “ai có gì”, hãy tập trung hướng dẫn mọi người qua các bước lặp lại có trách nhiệm rõ ràng, hạn chót và một hành động tiếp theo duy nhất.

Bắt đầu với ba checklist cốt lõi

Xây các checklist từng bước cho các khoảnh khắc vòng đời thường gặp:

• Onboarding: yêu cầu laptop và phụ kiện, phân điện thoại (nếu cần), cấp app chuẩn, xác nhận hoàn thành và lưu chữ ký.
• Thay đổi vai trò: rà soát quyền hiện tại, thêm/bỏ công cụ cho vai trò mới, tùy chọn hoán đổi thiết bị và ghi nhận người phê duyệt.
• Offboarding: khoá/chuyển tài khoản, lên lịch trả thiết bị, xác nhận tiếp nhận, wipe/reimage và đóng case.

Mỗi mục checklist nên có: một chủ sở hữu (IT, quản lý, HR, nhân viên), một trạng thái (Not started → In progress → Done → Blocked), và một trường bằng chứng (bình luận, tệp đính kèm hoặc tham chiếu).

Xử lý ngoại lệ mà không phá vỡ luồng

Thực tế hiếm khi theo đường thẳng, nên thêm “hành động ngoại lệ” có thể kích hoạt từ bất kỳ case nào:

• Thiết bị mất: ghi lại người sở hữu cuối cùng, đánh dấu mất, tạo task thay thế và lưu chi tiết sự cố.
• Truy cập khẩn cấp: cấp truy cập có thời hạn kèm lý do bắt buộc và tự động hết hạn.
• Cho mượn tạm thời: bắt đầu khoản cho mượn với ngày trả, tình trạng kỳ vọng và bước check-in nhẹ.

SLA, nhắc nhở và rà soát định kỳ

Đặt kỳ vọng dịch vụ đơn giản: trả thiết bị trong X ngày sau khi nghỉ việc, xác nhận cho mượn trong 24 giờ, v.v. Thêm ngày đến hạn vào mục checklist và gửi nhắc nhở cho chủ nhiệm hiện tại.

Với quyền truy cập, lên lịch tác vụ định kỳ như “xem lại quyền mỗi 90 ngày” cho hệ thống nhạy cảm. Kết quả là một quyết định rõ: giữ, loại bỏ hoặc chuyển cao hơn.

Giữ trạng thái và “hành động tiếp theo” rõ ràng

Thiết kế workflow sao cho người dùng không phải đoán. Mỗi case nên hiển thị:

• trạng thái hiện tại (ví dụ: “Chờ trả từ nhân viên”)
• hành động tiếp theo (một câu duy nhất, có thể thực hiện)
• ai chịu trách nhiệm và hạn chót

Điều này giữ tiến trình mà không biến app thành công cụ quản lý dự án.

Chọn tech stack và kiến trúc tổng quan

Ứng dụng này sẽ chạm đến dữ liệu nhạy cảm (ai có thiết bị gì, ai có quyền truy cập nào), nên "tech stack tốt nhất" thường là cái nhóm bạn có thể vận hành tự tin trong nhiều năm — đặc biệt lúc 6 giờ chiều và ai đó cần cập nhật offboarding khẩn cấp.

Chọn stack nhóm bạn có thể hỗ trợ

Chọn framework phù hợp kỹ năng đội và hệ sinh thái hiện tại. Các lựa chọn phổ biến cho công cụ nội bộ theo dõi thiết bị:

• Node.js + Express (hoặc NestJS): tốt nếu tổ chức dùng TypeScript và muốn API linh hoạt.
• Django: công cụ admin mạnh, phát triển CRUD nhanh và mặc định an toàn chín muồi.
• Ruby on Rails: hiệu quả khi xây công cụ nội bộ nặng workflow nhanh.
• Laravel (PHP): quy ước tốt và nguồn nhân lực rộng ở nhiều công ty.

Dù chọn gì, ưu tiên: thư viện xác thực tốt, migrations cho thay đổi DB và cách rõ ràng để triển khai RBAC.

Nếu muốn nhanh hơn cho bản nội bộ đầu, bạn cũng có thể prototype (và sau đó tăng cường) hệ thống này bằng Koder.ai — nền tảng vibe-coding nơi bạn mô tả workflow bằng chat và tạo giao diện React hoạt động cộng backend Go + PostgreSQL. Nó hữu dụng để dựng khung CRUD, RBAC và luồng phê duyệt nhanh, trong khi vẫn có tuỳ chọn xuất mã nguồn khi bạn sẵn sàng nắm codebase trực tiếp.

Quyết định triển khai: VM, nền tảng quản lý hay container

Lựa chọn triển khai ảnh hưởng đến bảo trì hơn là tính năng:

• Cloud VM (đơn giản): bạn quản lý cập nhật OS, scale và backup.
• Nền tảng quản lý (vận hành nhanh nhất): kiểu Heroku hoặc dịch vụ app cloud xử lý hầu hết ops.
• Containers (Docker + Kubernetes/ECS) (linh hoạt nhất): tốt nếu bạn đã có hạ tầng container và muốn môi trường lặp lại.

Với nhiều đội, nền tảng quản lý là con đường nhanh nhất để có ứng dụng quản lý tài sản ổn định.

Lên kế hoạch cho môi trường (dev, staging, production)

Thiết lập ba môi trường ngay từ đầu:

• Dev cho công việc hàng ngày (local + shared dev).
• Staging phản chiếu production để test luồng phê duyệt và tích hợp.
• Production khoá chặt hơn với backup và giám sát.

Giữ cấu hình trong biến môi trường (DB URL, SSO settings, storage buckets), không lưu trong code.

Phác thảo sơ đồ kiến trúc tối thiểu

Ghi lại sơ đồ đơn giản để mọi người có cùng mô hình tư duy:

• UI: frontend web (server-rendered hoặc SPA) cho dashboard và tìm kiếm.
• API: logic nghiệp vụ cho phân bổ, trả và thay đổi quyền.
• Database: store quan hệ (thường Postgres) cho employees, equipment, access grants.
• File storage: tuỳ chọn cho hóa đơn, ảnh, form ký.

Bản đồ nhỏ này ngăn phức tạp vô ý và giữ kiến trúc ứng dụng web cho công cụ nội bộ dễ hiểu khi mở rộng.

Thiết kế UI: Dashboard, Tìm kiếm và Trang chi tiết

Một app theo dõi sống hoặc chết bởi mức độ nhanh người dùng trả lời các câu đơn giản: “Ai đang giữ laptop này?”, “Cái gì đang thiếu?”, “Quyền nào cần thu hồi hôm nay?” Thiết kế UI xoay quanh những khoảnh khắc hàng ngày đó, không phải bảng dữ liệu trong DB.

Bắt đầu với bốn màn hình chính

Xây những màn này làm trang “home base”, mỗi màn có mục đích rõ và bố cục dự đoán được:

• Hồ sơ nhân viên: nơi duy nhất để xem thiết bị được giao, quyền đang hoạt động, yêu cầu mở và timeline thay đổi gần đây.
• Danh sách thiết bị: bảng tồn kho cho tất cả tài sản với trạng thái (assigned/available/retired), vị trí và lần cập nhật/gặp gần nhất.
• Danh sách quyền: hệ thống và nhóm (ví dụ: GitHub org, VPN, payroll) với ai có gì, cùng ngày hết hạn/đánh giá.
• Hàng đợi yêu cầu: các phê duyệt và hành động cần chú ý (thiết lập nhân viên mới, chuyển giao, offboarding), sắp theo độ ưu tiên.

Làm tìm kiếm và bộ lọc thành tính năng chính

Đặt ô tìm kiếm toàn cục ở thanh điều hướng và làm nó dễ chịu: tên, email, serial number, asset tag và username đều nên tìm được.

Trên các trang danh sách, coi bộ lọc là chức năng cốt lõi, không phải phụ. Bộ lọc hữu ích:

• Người, phòng ban, quản lý
• Serial number / asset tag
• Trạng thái (assigned, pending return, lost, revoked)
• Khoảng ngày (ngày phân bổ, lần kiểm toán gần nhất, ngày offboarding)

Giữ trạng thái bộ lọc trong URL để người dùng chia sẻ view với đồng đội và dễ quay lại.

Thiết kế form tránh lỗi

Hầu hết lỗi xảy ra ở nhập liệu. Dùng dropdown cho phòng ban và model thiết bị, typeahead cho nhân viên, và trường bắt buộc cho những gì bạn cần khi kiểm toán (serial number, ngày phân bổ, người phê duyệt).

Xác thực thời gian thực: cảnh báo nếu serial đã được phân, nếu quyền xung đột với chính sách, hoặc nếu ngày trả nằm trong tương lai.

Hỗ trợ thao tác nhanh (không phải đi tìm)

Trên trang chi tiết nhân viên và thiết bị, đặt một bộ hành động chính nhỏ ngay trên fold:

• Assign thiết bị
• Return thiết bị
• Revoke quyền
• Generate receipt (PDF hoặc trang in để giao/nhận)

Sau hành động, hiển thị xác nhận rõ ràng và trạng thái cập nhật ngay. Nếu người dùng không tin vào thông tin hiển thị, họ sẽ quay lại lập spreadsheet.