/03-templates/TMPL-OPS-RUNBOOK-001_runbook.md — Mẫu Runbook Vận hành

Tài liệu này là một artifact được kiểm soát thuộc corpus học liệu Nova Foods. Mọi thay đổi phải tuân thủ cơ chế quản trị phiên bản và lịch sử thay đổi được ghi nhận dưới đây. Việc sử dụng template này để tạo ra các runbook cụ thể phải tuân theo các hướng dẫn và ranh giới được định nghĩa trong các tầng (tier) của nó.

Metadata Quản trị Artifact

Bảng sau đây định nghĩa các thuộc tính quản trị cốt lõi của template này. Các thuộc tính này là nguồn chân lý (source of truth) cho định danh, phiên bản, và phạm vi kiểm soát của tài liệu.

Trường kiểm soát	Giá trị	Diễn giải và Ranh giới áp dụng
Artifact ID	TMPL-OPS-RUNBOOK-001	Định danh duy nhất, không thay đổi của template này trong toàn bộ corpus. Các tài liệu khác phải dùng ID này khi tham chiếu để đảm bảo tính toàn vẹn của traceability.
Tên tệp được kiểm soát	/03-templates/TMPL-OPS-RUNBOOK-001_runbook.md	Đường dẫn canonical của artifact. Mọi bản sao, bản xuất hoặc các phiên bản khác không thay thế được nguồn kiểm soát này.
Tiêu đề	Mẫu Runbook Vận hành (Operations Runbook Template)	Tên chính thức của template, được dùng cho mục đích hiển thị và tham chiếu.
Status	IN_REVIEW	Trạng thái hiện tại là đang trong quá trình xem xét có kiểm soát. Nó không đồng nghĩa với APPROVED (đã phê duyệt), BASELINED (đã chốt phiên bản), hoặc sẵn sàng cho sản xuất (production-ready).
Version	v0.9.0	Phiên bản hiện hành của template đang được xem xét.
Owner	Principal IT Business Analyst / Technical Curriculum Author	Vai trò chịu trách nhiệm duy trì tính toàn vẹn cấu trúc và quản trị của template, không phải nội dung nghiệp vụ cụ thể.
Trách nhiệm của Owner	Duy trì cấu trúc 4 tầng của template, quản lý phiên bản, ghi nhận lịch sử thay đổi, và đảm bảo các định danh và nhãn kiểm soát được bảo toàn theo TEMPLATE_MANIFEST.
Giới hạn thẩm quyền Owner	Owner là người bảo quản (custodian) của template. Vai trò này không có thẩm quyền phê duyệt nội dung nghiệp vụ, xác nhận tuân thủ pháp lý/kế toán, quyết định kiến trúc, hoặc cho phép sử dụng trong môi trường production.
Ngày cập nhật gần nhất	2026-08-07	Ngày gần nhất mà metadata hoặc cấu trúc quản trị của tài liệu được cập nhật.
Múi giờ quản trị	Asia/Ho_Chi_Minh	Múi giờ chuẩn để ghi nhận thời điểm của các thay đổi và bằng chứng quản trị.
Locale áp dụng	vi-VN	Bối cảnh mặc định là Việt Nam. Đơn vị tiền tệ mô phỏng trong các ví dụ là VND.
Case study	Nova Foods Trading & Manufacturing	Case study mô phỏng cho mục đích giáo dục.
Phân loại artifact	Controlled Template Artifact	Template có kiểm soát, được dùng để sinh ra các artifact vận hành khác.
Ranh giới dữ liệu mô phỏng	QUAN TRỌNG: Tất cả thông tin, quy trình, và dữ liệu liên quan đến Nova Foods trong template này (đặc biệt ở Tier 3) đều là dữ liệu tổng hợp (synthetic data) cho mục đích giáo dục. Chúng không đại diện cho hoạt động, quyết định, hồ sơ tài chính, hoặc tình trạng tuân thủ của bất kỳ tổ chức thực tế nào.

Lịch sử Thay đổi (Change History)

Mọi thay đổi đối với template này sau khi được khởi tạo phải được ghi nhận trong bảng này để đảm bảo tính minh bạch và khả năng truy vết.

Phiên bản	Ngày	Tác giả	Mô tả thay đổi
v0.9.0	2026-08-07	Principal IT Business Analyst / Technical Curriculum Author	Khởi tạo tài liệu ở trạng thái IN_REVIEW. Thiết lập H1, metadata quản trị, và lịch sử thay đổi ban đầu. Xác định các ranh giới kiểm soát và phạm vi dữ liệu mô phỏng cho template.

1. Tier 1 ? Metadata, Purpose, and Governance

Mục đích, Phạm vi và Quản trị Sử dụng

Bảng này xác định mục đích, các trường hợp sử dụng, các giới hạn và quy tắc quản trị cho template runbook. Việc tuân thủ các quy tắc này là bắt buộc để duy trì tính toàn vẹn của quy trình vận hành trong hệ sinh thái tài liệu Nova Foods.

Hạng mục Quản trị	Nội dung và Diễn giải
Mục đích	Cung cấp cấu trúc chuẩn hóa, có thể kiểm soát cho tài liệu Runbook (sách hướng dẫn vận hành). Mục tiêu: đảm bảo tính nhất quán, đầy đủ, giảm sai sót khi nhóm vận hành xử lý sự cố hoặc thực hiện tác vụ lặp lại. Mỗi runbook hoàn chỉnh phải mô tả một luồng vận hành hoặc một case study duy nhất, nhất quán từ kích hoạt, phân tích, thực thi, xác thực đến bằng chứng truy vết; không trộn nhiều sự cố không cùng phạm vi vào một bản ghi.
Khi nào sử dụng	Để tạo runbook mới cho quy trình vận hành có tính lặp lại, ví dụ quy trình đặt lại mật khẩu cho người dùng quản trị hoặc khởi động lại dịch vụ cụ thể sau triển khai. Để tài liệu hóa và chuẩn hóa quy trình hiện có nhưng chưa được ghi nhận chính thức, giảm phụ thuộc vào kiến thức cá nhân. Để ghi nhận một case study hoàn chỉnh cho một sự cố đã biết, trong đó actor thực hiện bước xử lý, artifact ghi bằng chứng, và authority ra quyết định được nêu rõ.
Khi nào KHÔNG sử dụng	Làm đặc tả yêu cầu: Sai mục đích. Runbook mô tả cách thực hiện tác vụ, không phải lý do tại sao và hệ thống nên làm gì. Sử dụng template đặc tả yêu cầu, ví dụ TMPL-BRD-001, cho mục đích đó. Định nghĩa quy tắc nghiệp vụ: Sai nguồn chân lý (source of truth). Runbook sử dụng quy tắc nghiệp vụ đã được định nghĩa trong /01-curriculum/CANONICAL_BUSINESS_RULES.md, không phải nơi tạo quy tắc mới. Chẩn đoán khám phá (exploratory investigation): Runbook dành cho quy trình đã biết. Hoạt động điều tra sự cố mới, chưa từng có phải được ghi trong ticket hoặc báo cáo sự cố. Gộp các case study khác nhau: Không dùng cùng một Tier 3 hoặc Tier 4 để trộn các sự cố có đối tượng, nguyên nhân, quyết định, bằng chứng hoặc authority khác nhau. Mỗi case study cần runbook hoặc bản ghi riêng để duy trì truy vết và trách nhiệm.
Owner (Chủ sở hữu)	Owner của Template (TMPL-OPS-RUNBOOK-001): Principal IT Business Analyst / Technical Curriculum Author. Chịu trách nhiệm về cấu trúc, siêu dữ liệu, tính toàn vẹn template và tính nhất quán giữa các tier. Owner của Runbook cụ thể (ví dụ: OPS-RUNBOOK-101_...): Thường là Operations Lead hoặc vai trò kỹ thuật cấp cao trong nhóm vận hành. Chịu trách nhiệm về tính chính xác, an toàn của bước thực thi, tính liền mạch của case study và bằng chứng của runbook cụ thể.
Người dùng (Consumers)	Operations Engineers (Kỹ sư Vận hành) / Support L1/L2: Thực thi bước trong runbook để giải quyết sự cố hoặc hoàn thành tác vụ. Team Leads: Rà soát và phê duyệt nội dung runbook cụ thể do nhóm mình tạo ra. Auditors (Kiểm toán viên) / Compliance Officers: Rà soát runbook để đánh giá tuân thủ quy trình đã được phê duyệt, tính đầy đủ của bằng chứng và liên kết truy vết.
Điều kiện tiên quyết	Một định danh (ID) cho runbook mới phải được đăng ký trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md để đảm bảo khả năng truy vết. Người tạo runbook phải có quyền truy cập đọc vào artifact tham chiếu như /01-curriculum/CANONICAL_BUSINESS_RULES.md và /01-curriculum/CANONICAL_DATA_DICTIONARY.md. Trước khi điền Tier 3 và Tier 4, người tạo phải xác định một sự cố hoặc case study duy nhất, cùng phạm vi, actor, object, outcome, authority và bộ bằng chứng. Nếu có sự cố thứ hai, phải tạo bản ghi riêng hoặc liên kết rõ đến artifact riêng.
Artifact phụ thuộc	Các tệp runbook cụ thể đã hoàn thiện, ví dụ /08-operations/OPS-RUNBOOK-XXX_...md. Báo cáo sự cố (Incident Report) có tham chiếu đến runbook ID đã được sử dụng. Yêu cầu thay đổi (Change Request) nếu thực thi runbook phát hiện lỗi tiềm ẩn trong hệ thống cần sửa ở cấp mã nguồn. Bằng chứng thực thi và quyết định phải liên kết với đúng case study của runbook; không dùng bằng chứng của sự cố khác để chứng minh outcome của case hiện tại.
Thẩm quyền	Thực thi runbook không trao quyền thay đổi mã nguồn, kiến trúc hệ thống, quy tắc nghiệp vụ, hay dữ liệu tài chính-kế toán cốt lõi. Runbook chỉ ủy quyền thực hiện bước đã được định nghĩa và phê duyệt trước đó. Mọi hành động có tác động tài chính, pháp lý, hoặc thay đổi dữ liệu nhạy cảm phải ghi rõ là "Điểm dừng - Yêu cầu phê duyệt từ <vai trò có thẩm quyền>" và không được tự động thực hiện. Người lập runbook không được suy diễn approval, authority hoặc quyết định nghiệp vụ từ case study khác. Authority phải được nêu trong bản ghi của case study đang xử lý.
Leo thang (Escalation)	Bước thực thi thất bại: Leo thang lên Support L2/L3 hoặc Owner của runbook cụ thể. Nội dung runbook sai hoặc lỗi thời: Tạo yêu cầu cập nhật và báo Owner của runbook. Sự cố nằm ngoài phạm vi runbook: Leo thang lên Incident Manager hoặc quy trình xử lý sự cố chung. Cần quyết định nghiệp vụ: Leo thang đến Business Owner hoặc vai trò có thẩm quyền được chỉ định trong runbook. Phát hiện nội dung trộn nhiều case study: Dừng sử dụng bản ghi làm bằng chứng đào tạo hoặc vận hành; Owner của runbook phải tách nội dung theo từng sự cố, bảo toàn ID, artifact nguồn, quyết định và bằng chứng của từng case trước khi tiếp tục rà soát.

Định danh Canonical, Liên kết và Nghĩa vụ Kiểm soát

Template này là artifact được kiểm soát trong kho tài liệu của corpus Nova Foods. Định danh không chỉ là tên tệp mà được đăng ký chính thức để đảm bảo tính duy nhất và khả năng truy vết. "Canonical" (kinh điển, chuẩn) nghĩa là đây là nguồn chân lý duy nhất cho định danh này. Mọi tham chiếu đến hoặc từ template này phải sử dụng định danh chính thức để phục vụ "traceability" (truy xuất nguồn gốc) — khả năng theo dõi yêu cầu từ lúc khởi tạo đến triển khai và vận hành. Việc này ngăn hỗn loạn do phiên bản tài liệu không chính thức gây ra.

Thuộc tính Định danh	Giá trị	Diễn giải
ID Template Canonical	TMPL-OPS-RUNBOOK-001	Định danh duy nhất, không thay đổi của template này trong toàn bộ corpus.
Đường dẫn tệp được kiểm soát	/03-templates/TMPL-OPS-RUNBOOK-001_runbook.md	Vị trí chính thức của tệp. Mọi bản sao hoặc tệp xuất ra không có giá trị thay thế.
Tham chiếu Manifest	/01-curriculum/TEMPLATE_MANIFEST.md	Sự tồn tại của template này được đăng ký trong Manifest Template, xác nhận đây là một phần của kế hoạch học liệu.
Mục đích trong Manifest	Cung cấp cấu trúc chuẩn để tài liệu hóa quy trình vận hành, hay "runbook" (sổ tay vận hành).	Runbook giúp đội kỹ thuật, ví dụ Vận hành và Hỗ trợ, thực hiện tác vụ lặp lại hoặc xử lý sự cố đã biết một cách nhất quán và an toàn.
Ranh giới case study	Một runbook hoàn chỉnh phải duy trì một case study duy nhất xuyên suốt các Tier 3 và Tier 4.	Actor, action, object, outcome, authority, artifact, trade-off, consequence, bằng chứng và truy vết phải thuộc cùng một sự cố. Case khác phải dùng bản ghi riêng.

Template này không tồn tại độc lập. Nó có liên kết quản trị chặt chẽ đến artifact lõi khác trong corpus để đảm bảo tính nhất quán và toàn vẹn của toàn bộ hệ thống tài liệu.

Liên kết tới Artifact	Tên tệp Canonical	Mục đích và Trách nhiệm Liên kết
Bản đồ Nguồn	/00-research/00_SOURCE_MAP.md	Cung cấp danh mục nguồn ngoài (luật, tiêu chuẩn ngành) mà runbook hoàn chỉnh (Tier 3) có thể cần tham chiếu. Template này phải tuân thủ quy tắc trích dẫn nguồn.
Kiến trúc Curriculum	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Sự tồn tại của template này đáp ứng mục tiêu kiến trúc học liệu trong việc trang bị kiến thức về giai đoạn chuyển giao và vận hành (post-deployment).
Manifest Chapter	/01-curriculum/CHAPTER_MANIFEST.md	Template này là công cụ thực hành chính cho chương handbook liên quan đến Vận hành Hệ thống, Chuyển giao Triển khai, và Xử lý Sự cố.
Registry ID Truy vết	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Khi điền template này để tạo runbook cụ thể (Tier 3), người dùng phải dùng ID chính thức, ví dụ REQ-XXX, UC-YYY, từ registry để liên kết bước vận hành với yêu cầu nghiệp vụ tương ứng.
Quy tắc Nghiệp vụ Canonical	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Bước trong runbook phải tham chiếu quy tắc nghiệp vụ bằng ID canonical, ví dụ BR-INV-005, khi cần xác minh trạng thái hoặc logic hệ thống.
Từ điển Dữ liệu Canonical	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Khi bước vận hành liên quan kiểm tra hoặc sửa đổi dữ liệu, nó phải dùng tên trường và thực thể chính thức từ từ điển dữ liệu để tránh mơ hồ.

Mọi thay đổi đối với template này phải tuân thủ quy trình kiểm soát thay đổi nghiêm ngặt.

1. Đề xuất: Mọi thay đổi phải được đề xuất, không được sửa trực tiếp lên phiên bản hiện tại.
2. Đánh giá: Owner của template chịu trách nhiệm xem xét tác động thay đổi lên artifact liên quan, gồm rủi ro làm trộn case study, đứt liên kết bằng chứng hoặc sai authority.
3. Phiên bản: Mọi thay đổi nội dung làm tăng phiên bản, ví dụ từ v0.9.0 lên v0.9.1, và được ghi trong bảng Lịch sử Thay đổi của tài liệu này.
4. Trạng thái: Template này đang ở trạng thái IN_REVIEW. Nó chưa được "baseline" (thiết lập đường cơ sở), tức chưa được phê duyệt chính thức để trở thành phiên bản ổn định làm nền tảng cho công việc khác. Mọi thay đổi trong giai đoạn này chỉ mang tính dự thảo, không có giá trị áp dụng cho sản phẩm thật.

2. Tier 2 ? Blank Copy-Paste-Ready Template

A. Siêu dữ liệu và Quản trị (Metadata and Governance)

Bảng này chứa các thông tin định danh và quản lý vòng đời của runbook. Nó là bắt buộc để đảm bảo khả năng truy vết và quản trị.

Trường (Field)	Nội dung	Hướng dẫn & Quy tắc (Guidance & Rules)
Runbook ID	RUNBOOK-<YYYYMMDD>-<MÃ_DUY_NHẤT>	Bắt buộc. ID duy nhất, không thay đổi. Giúp liên kết với ticket và báo cáo. Định dạng: RUNBOOK-NămThángNgày-MãNgắn.
Tên Runbook	<Tên mô tả ngắn gọn, tập trung vào kết quả>	Bắt buộc. Phải rõ ràng, súc tích. Ví dụ: "Khởi động lại Dịch vụ Thanh toán NovaPay khi bị treo".
Hệ thống/Dịch vụ	<Tên hệ thống, ví dụ: NovaERP - Module Kho>	Bắt buộc. Liệt kê các hệ thống bị ảnh hưởng trực tiếp. Dùng tên chính thức được định nghĩa trong kiến trúc hệ thống.
Mức độ Ưu tiên	<Chọn một: P1, P2, P3, P4>	Bắt buộc. P1: Khẩn cấp, hệ thống ngừng hoạt động. P2: Nghiêm trọng, chức năng chính lỗi. P3: Trung bình. P4: Thấp, bảo trì.
Chủ sở hữu (Owner)	<Tên vai trò hoặc cá nhân chịu trách nhiệm>	Bắt buộc. Người cuối cùng chịu trách nhiệm về tính chính xác, an toàn và hiệu quả của runbook này.
Phiên bản (Version)	v1.0.0	Bắt đầu từ v1.0.0. Tăng phiên bản phụ (1.0.1) cho sửa lỗi nhỏ, tăng phiên bản chính (2.0.0) khi quy trình thay đổi lớn.
Lần cập nhật cuối	<YYYY-MM-DD HH:MM:SS (Asia/Ho_Chi_Minh)>	Dùng múi giờ chuẩn Asia/Ho_Chi_Minh để đồng bộ.
Trạng thái (Status)	<Chọn một: DRAFT, IN_REVIEW, APPROVED, DEPRECATED>	DRAFT: Đang soạn. IN_REVIEW: Chờ duyệt. APPROVED: Sẵn sàng sử dụng. DEPRECATED: Lỗi thời, không dùng.

B. Kích hoạt và Kiểm tra Sơ bộ (Trigger and Pre-checks)

Mục này xác định khi nào cần dùng runbook và các điều kiện tiên quyết phải được thỏa mãn để đảm bảo an toàn.

Trường (Field)	Nội dung và Hướng dẫn
Tác nhân kích hoạt (Trigger)	<Mô tả chính xác sự kiện hoặc điều kiện kích hoạt runbook. Ví dụ: "Cảnh báo từ Grafana: API_Gateway_5xx_Error_Rate > 5% trong 3 phút" hoặc "Yêu cầu hỗ trợ từ ticket JIRA: OPS-1234".>
Kiểm tra Sơ bộ (Pre-checks)	1. <Điều kiện 1 phải đúng. Ví dụ: "Xác nhận không có lịch triển khai (deployment) đang diễn ra trên môi trường Production."> 2. <Điều kiện 2 phải đúng. Ví dụ: "Tạo bản sao lưu (snapshot) cho cơ sở dữ liệunova_foods_inventory_db."> 3. <Thêm các điều kiện khác nếu cần. Mỗi điều kiện phải có thể kiểm tra được (checkable).>

C. Các bước Thực thi (Execution Steps)

Đây là phần cốt lõi, mô tả từng hành động cần thực hiện. Các bước phải tuần tự, rõ ràng, và không mơ hồ.

#	Hành động (Action)	Kết quả mong đợi (Expected Result)	Lệnh / Thao tác UI (Command / UI Interaction)
1	<Mô tả hành động đầu tiên. Ví dụ: "SSH vào server bastion-prod-01">	<Mô tả trạng thái hệ thống sau khi hành động hoàn tất. Ví dụ: "Đăng nhập thành công, thấy dấu nhắc lệnh shell.">	ssh operator@bastion-prod-01.novafoods.vn
2	<Mô tả hành động tiếp theo. Ví dụ: "Liệt kê các pod của dịch vụ thanh toán">	<Kết quả mong đợi. Ví dụ: "Hiển thị danh sách các pod đang chạy với trạng thái Running.">	kubectl get pods -n novapay
...	<Thêm các bước cần thiết. Mỗi bước là một hành động đơn lẻ, có thể kiểm chứng.>	<...>	<Dán lệnh shell, SQL query, hoặc mô tả các bước click trên giao diện người dùng.>

D. Kế hoạch Phục hồi (Rollback Plan)

Kế hoạch này chỉ được thực hiện khi một bước trong phần C thất bại và người thực thi được chỉ thị phải hoàn tác.

#	Hành động Phục hồi (Rollback Action)	Kết quả mong đợi (Expected Result)	Lệnh / Thao tác UI (Command / UI Interaction)
1	<Hành động đầu tiên để hoàn tác. Thường là đảo ngược bước thất bại cuối cùng.>	<Hệ thống quay về trạng thái trước khi thực hiện bước đó.>	<Dán lệnh rollback tương ứng, ví dụ: kubectl scale deployment/... --replicas=3>
...	<Thêm các bước cần thiết để quay về trạng thái ổn định ban đầu trước khi runbook bắt đầu.>	<Hệ thống hoạt động ổn định như trước khi bắt đầu runbook.>	<...>

E. Xác thực và Hoàn tất (Validation and Post-actions)

Sau khi hoàn thành các bước thực thi (hoặc rollback), cần xác thực kết quả và thực hiện các công việc cuối cùng.

Trường (Field)	Nội dung và Hướng dẫn
Bước Xác thực (Validation Steps)	1. <Hành động kiểm tra cuối cùng để xác nhận thành công. Ví dụ: "Thực hiện cuộc gọi thử đến APIPOST /api/v1/payments, nhận mã200 OK."> 2. <Kiểm tra log hệ thống trong 10 phút qua, xác nhận không có lỗi nghiêm trọng (ERROR, FATAL) mới phát sinh.>
Hoạt động sau khi hoàn tất (Post-actions)	1. <Thông báo cho các bên liên quan. Ví dụ: "Gửi thông báo trên kênh Slack #ops-alerts với nội dung: 'Dịch vụ NovaPay đã khởi động lại thành công.'"> 2. <Cập nhật và đóng ticket liên quan. Ví dụ: "Thêm bình luận và chuyển trạng thái ticket JIRA OPS-1234 sang 'DONE'.">

F. Leo thang và Truy vết (Escalation and Traceability)

Mục này cung cấp thông tin liên hệ khi có sự cố và liên kết runbook với các artifact khác.

Trường (Field)	Nội dung và Hướng dẫn
Liên hệ Leo thang (Escalation Contacts)	Cấp 1 (Thực thi thất bại): <Tên, Vai trò, Kênh liên hệ. Ví dụ: "Nguyễn Văn A, Trưởng nhóm Vận hành, @nguyenvana trên Slack"> Cấp 2 (Cấp 1 không xử lý được): <Tên, Vai trò, Kênh liên hệ. Ví dụ: "Trần Thị B, Kiến trúc sư Giải pháp, SĐT: 09... ">
Truy vết Yêu cầu (Requirements)	<Liệt kê ID yêu cầu từ registry, ví dụ: REQ-SALES-005, UC-ADMIN-010. Dùng 'Không áp dụng' nếu là tác vụ kỹ thuật thuần túy.>
Truy vết Quy tắc Nghiệp vụ (Business Rules)	<Liệt kê ID quy tắc nghiệp vụ từ catalog, ví dụ: BR-INV-001, BR-ACC-015. Giúp hiểu bối cảnh nghiệp vụ của hành động.>
Tham chiếu Ticket/Bằng chứng	<Link đến JIRA ticket, trang Confluence, email yêu cầu, hoặc cảnh báo gốc.>

G. Lịch sử Xem xét và Phê duyệt (Review and Approval History)

Bảng này ghi lại dấu vết ai đã xem xét và phê duyệt runbook, là bằng chứng cho việc kiểm soát chất lượng.

Phiên bản (Version)	Người xem xét (Reviewer)	Vai trò (Role)	Ngày (Date)	Kết quả (Outcome) & Ghi chú
<1.0.0>	<Tên người xem xét>	<Ví dụ: Senior DevOps Engineer>	<YYYY-MM-DD>	<APPROVED / REJECTED>. <Ghi chú ngắn gọn nếu có.>
<...>	<...>	<...>	<...>	<...>

Các cấu phần kiểm soát, truy vết và phê duyệt

Phần này chứa các bảng bắt buộc để quản lý vòng đời, chất lượng và tính tuân thủ của Runbook. Mọi trường phải được điền đầy đủ để đảm bảo Runbook được kiểm soát chặt chẽ.

Bảng 1: Ma trận truy vết (Traceability Matrix)

Ma trận truy vết chứng minh rằng Runbook này được tạo ra để đáp ứng các yêu cầu, quy tắc nghiệp vụ và trường hợp sử dụng đã được xác định. Điều này đảm bảo không có công việc nào được thực hiện tách rời khỏi mục tiêu kinh doanh. Mỗi hàng liên kết Runbook này tới một artifact nguồn.

Loại Liên kết	ID Truy vết Canonical	Mô tả ngắn gọn về liên kết
Yêu cầu nghiệp vụ	<RQ-NF-XXX>	<Mô tả yêu cầu mà Runbook này giúp thực thi>
Quy tắc nghiệp vụ	<BR-NF-XXX>	<Mô tả quy tắc nghiệp vụ được Runbook tuân thủ hoặc tự động hóa>
Trường hợp sử dụng	<UC-NF-XXX>	<Mô tả kịch bản sử dụng (use case) được Runbook này hỗ trợ>
Đặc tả kỹ thuật	<TS-NF-XXX>	<Tham chiếu đến tài liệu thiết kế hoặc đặc tả kỹ thuật liên quan>
Trường hợp kiểm thử	<TC-NF-XXX>	<Liên kết đến kịch bản kiểm thử (test case) xác minh Runbook hoạt động đúng>
Nguồn pháp lý/Tiêu chuẩn	<SRC-ID-XXX>	<Liên kết đến điều khoản luật hoặc tiêu chuẩn mà Runbook này phải tuân thủ>

Bảng 2: Nhật ký Quyết định (Decision Log)

Ghi lại các quyết định quan trọng được đưa ra trong quá trình thiết kế và phê duyệt Runbook để tham chiếu trong tương lai.

ID Quyết định	Ngày	Người quyết định & Vai trò	Nội dung quyết định	Lý do & Bối cảnh
<DEC-RBXXX-001>	<YYYY-MM-DD>	<Họ tên và vai trò>	<Mô tả ngắn gọn quyết định đã được đưa ra>	<Giải thích tại sao quyết định này được chọn thay vì các phương án khác>

Bảng 3: Xử lý Ngoại lệ (Exception Handling)

Mô tả các tình huống ngoại lệ đã biết và quy trình xử lý chuẩn đã được phê duyệt để đảm bảo vận hành ổn định.

ID Ngoại lệ	Điều kiện xảy ra (Trigger)	Các bước xử lý tuần tự	Vai trò chịu trách nhiệm	Kênh báo cáo/Escalate
<EXC-RBXXX-001>	<Mô tả rõ ràng tình huống lỗi hoặc sự cố có thể xảy ra>	<Liệt kê chính xác các hành động cần thực hiện để khắc phục>	<Ghi rõ vai trò, ví dụ: IT Operations L1, Finance Controller>	<Kênh liên lạc, ví dụ: email tới support@, kênh Slack #ops-alerts>

Bảng 4: Bằng chứng (Evidence)

Liệt kê các tài liệu, sơ đồ, biên bản họp hoặc các bằng chứng khác làm cơ sở cho nội dung của Runbook.

ID Bằng chứng	Loại	Tên / Đường dẫn truy cập	Ghi chú
<EV-RBXXX-001>	Sơ đồ quy trình (BPMN)	<Đường dẫn tới tệp sơ đồ hoặc trang Confluence>	<Sơ đồ mô tả luồng công việc được tự động hóa>
<EV-RBXXX-002>	Biên bản họp	<Đường dẫn tới biên bản họp phê duyệt quy trình>	<Ghi rõ ngày họp và người tham dự chính>
<EV-RBXXX-003>	Đặc tả API	<Tham chiếu đến đặc tả OpenAPI/Swagger cho các API được sử dụng>	<Phiên bản API được sử dụng>

Bảng 5: Lịch sử phiên bản (Version History)

Theo dõi tất cả các thay đổi được thực hiện đối với Runbook này. Không được phép sửa đổi mà không tạo một dòng lịch sử mới.

Phiên bản	Ngày cập nhật	Người cập nhật	Tóm tắt thay đổi
v0.1.0	<YYYY-MM-DD>	<Họ tên người khởi tạo>	Bản nháp đầu tiên của Runbook.
<vX.Y.Z>	<YYYY-MM-DD>	<Họ tên người cập nhật>	<Mô tả rõ ràng, ngắn gọn những gì đã được thêm, sửa hoặc xóa>

Bảng 6: Xem xét và Phê duyệt (Review and Sign-off)

Ghi nhận sự phê duyệt chính thức từ các bên liên quan có thẩm quyền. "Sign-off" là hành động xác nhận cuối cùng, có tính ràng buộc. Runbook không có hiệu lực cho đến khi tất cả các vai trò bắt buộc đã phê duyệt.

Vai trò	Người thực hiện	Ngày xem xét	Kết quả (Approved / Rejected / Comments)	Chữ ký / Ghi chú xác nhận
Business Owner	<Tên Business Owner>	<YYYY-MM-DD>	<Chưa xem xét>
Technical Lead / Architect	<Tên Technical Lead>	<YYYY-MM-DD>	<Chưa xem xét>
QA Lead	<Tên QA Lead>	<YYYY-MM-DD>	<Chưa xem xét>
Operations Lead	<Tên Operations Lead>	<YYYY-MM-DD>	<Chưa xem xét>
Compliance / Legal (Nếu cần)	<Tên người phụ trách>	<YYYY-MM-DD>	<Chưa xem xét>

Hướng dẫn điền trường, quy tắc xác thực và các mẫu áp dụng

Phần này cung cấp hướng dẫn chi tiết cho từng trường trong mẫu runbook. Tuân thủ nghiêm ngặt để đảm bảo tính nhất quán, an toàn và có thể kiểm tra được.

Bảng 1: Hướng dẫn cho các trường Metadata (Mục 1)

Tên trường	Hướng dẫn và Quy tắc Xác thực	Ví dụ / Giá trị cho phép
Runbook ID	Bắt buộc. Phải là định danh duy nhất được đăng ký trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Định dạng: RUNBOOK-NNN.	RUNBOOK-001
Tên Hệ thống/Dịch vụ	Bắt buộc. Tên canonical của hệ thống, dịch vụ hoặc ứng dụng bị tác động. Phải khớp với danh mục tài sản CNTT.	NovaFoods ERP - Module Quản lý Kho (WMS)
Tác vụ Vận hành	Bắt buộc. Mô tả ngắn gọn, rõ ràng theo cấu trúc [Động từ] [Danh từ]. Tóm tắt mục tiêu chính của runbook.	Dọn dẹp cache tồn kho sản phẩm hết hạn
Phân loại Rủi ro	Bắt buộc. Đánh giá mức độ ảnh hưởng tiềm tàng nếu tác vụ thất bại. Chỉ dùng các giá trị được định nghĩa trước.	THẤP, TRUNG BÌNH, CAO, CỰC CAO
Trigger/Lịch thực thi	Bắt buộc. Điều kiện kích hoạt runbook. Có thể là sự kiện, cảnh báo, hoặc lịch định kỳ. Dùng múi giờ Asia/Ho_Chi_Minh.	Hàng ngày lúc 02:00 AM hoặc Khi cảnh báo 'WMS_CACHE_OVERLOAD' được kích hoạt
Vai trò Thực thi	Bắt buộc. Chỉ định vai trò chịu trách nhiệm thực thi, không phải tên cá nhân.	L1 Ops Engineer, DBA on-call

Quy tắc về Phân loại Rủi ro và các Mục có Điều kiện

Hệ thống phân cấp rủi ro quyết định các phần bắt buộc phải có trong runbook.

• Rủi ro THẤP: Chỉ yêu cầu các mục cơ bản. Không cần quy trình rollback chi tiết hoặc phê duyệt trước khi thực thi.
• Rủi ro TRUNG BÌNH: Bắt buộc phải có Mục 6. Quy trình Rollback (Rollback Procedure).
• Rủi ro CAO: Bắt buộc có Mục 6. Quy trình Rollback và Mục 8. Phê duyệt (Approvals) phải được điền đầy đủ trước khi thực thi. Yêu cầu có người phê duyệt từ vai trò cấp cao hơn.
• Rủi ro CỰC CAO: Ngoài các yêu cầu của mức CAO, tác vụ phải được thực thi theo cặp (pair-ops), với một người thực thi và một người giám sát. Cả hai phải ký nhận vào bằng chứng thực thi.

Bảng 2: Hướng dẫn cho Quy trình Thực thi và Rollback (Mục 3 & 6)

Tên trường	Hướng dẫn và Quy tắc Xác thực
Bước (Step)	Mỗi bước phải là một hành động đơn lẻ, không thể chia nhỏ hơn. Đánh số thứ tự.
Lệnh/Hành động	Ghi chính xác lệnh cần chạy trong khối code. Đối với hành động trên giao diện (UI), mô tả rõ: "Nhấp vào nút 'Xóa Cache', id=btn-clear-cache". Lệnh phải có thể sao chép-dán.
Điểm kiểm tra	Sau mỗi lệnh quan trọng, phải có một bước kiểm tra. Nêu rõ kết quả mong đợi. Ví dụ: "Kiểm tra HTTP response trả về status 200 OK", "Xác nhận log ghi nhận Cache cleared successfully".
Bằng chứng cần thu thập	Chỉ định rõ bằng chứng cần lưu lại: screenshot, đoạn log, kết quả JSON từ API. Đặt tên tệp bằng chứng theo quy ước: EVIDENCE_[RUNBOOK-ID]_[YYYYMMDD]_[STEP_N].

Mẫu tham chiếu Bí mật An toàn (Safe Secret-Reference Pattern)

CẢNH BÁO AN NINH: Tuyệt đối không nhúng trực tiếp mật khẩu, API key, token, hoặc bất kỳ thông tin nhạy cảm nào vào nội dung runbook dưới dạng văn bản thuần. Việc này vi phạm chính sách bảo mật và tạo ra rủi ro nghiêm trọng.

• SAI: curl -u "admin:Password123!" https://api.novafoods.vn/inventory/sync
• ĐÚNG: curl -u "admin:$(cat [VAULT]/production/erp-api/admin-password)" https://api.novafoods.vn/inventory/sync

Luôn sử dụng một placeholder tham chiếu đến hệ thống quản lý bí mật (secret management vault) đã được phê duyệt. Placeholder phải có định dạng [VAULT]/<môi_trường>/<đường_dẫn_bí_mật>. Vai trò thực thi phải có quyền truy cập vào vault này. Runbook chỉ nêu vị trí, không nêu giá trị của bí mật.

3. Tier 3 — Fully Completed Nova Foods Case: Core Record

Đây là một ví dụ hoàn chỉnh, điền đầy đủ dữ liệu mô phỏng của Nova Foods vào mẫu ở Tier 2.

Metadata và Quản trị (Hoàn chỉnh)

Trường	Giá trị (Dữ liệu mô phỏng)
ID Runbook	RUNBOOK-OPS-031
Tên Runbook	Đồng bộ hóa tồn kho cưỡng bức từ WMS sang ERP cho một SKU
Hệ thống bị ảnh hưởng	ERP-CORE, WMS-ACCU-TRACK, API-GATEWAY
Owner nghiệp vụ	Trần Thị Bích Hạnh (Giám đốc Kho vận)
Owner kỹ thuật	Đội Vận hành Hạ tầng (Infrastructure Operations Team)
Phiên bản	1.0
Ngày hiệu lực	2026-08-15
Ticket liên quan	HELPDESK-2026-4815

Bối cảnh Nghiệp vụ (Hoàn chỉnh)

• Tình huống: Job đồng bộ tồn kho hàng đêm JOB_INV_SYNC_DAILY thất bại lúc 02:15 ngày 2026-08-15. Lỗi gây ra chênh lệch dữ liệu tồn kho cho mã sản phẩm (SKU) NF-DRI-SNK-0024 (Snack Mít Sấy Dẻo Nova Foods).
• Hành vi Hiện tại: Hệ thống ERP ghi nhận tồn kho là 1.500 đơn vị. Hệ thống quản lý kho WMS-ACCU-TRACK (được coi là nguồn tin cậy cho dữ liệu kho vật lý) ghi nhận tồn kho thực tế là 1.450 đơn vị. Chênh lệch là 50 đơn vị.
• Mục tiêu: Cập nhật cưỡng bức số liệu tồn kho trong ERP để khớp với số liệu thực tế từ WMS. Việc này đảm bảo tính chính xác cho hoạt động bán hàng và báo cáo tài chính.

Đánh giá Tác động (Hoàn chỉnh)

Lĩnh vực	Mức độ	Diễn giải (Nếu không thực hiện hoặc thực hiện sai)
Nghiệp vụ	CAO	Tồn kho ảo cao hơn thực tế dẫn đến bán hàng "âm" (bán hàng không có sẵn). Phải hủy đơn, ảnh hưởng uy tín thương hiệu và có thể phải đền bù cho đối tác.
Kỹ thuật	TRUNG BÌNH	Thao tác ghi đè trực tiếp vào bảng dữ liệu lõi của ERP (inventory_levels). Thực hiện sai SKU hoặc sai giá trị có thể làm hỏng dữ liệu, yêu cầu nỗ lực phục hồi lớn.
Tài chính	TRUNG BÌNH	Tồn kho là một hạng mục tài sản trên bảng cân đối kế toán. Sai lệch lớn và kéo dài có thể làm sai báo cáo tài chính.

Quy trình Thực thi (Hoàn chỉnh) Người thực thi: Kỹ thuật viên Vận hành CNTT Cấp 2. Thời gian ước tính: 15 phút.

Bước	Lệnh/Hành động	Điểm kiểm tra	Bằng chứng cần thu thập
1	Kiểm tra tồn kho trên ERP (trước khi chạy): Lấy số liệu hiện tại để xác nhận trạng thái ban đầu. bash<br>curl -X GET -H "Authorization: Bearer $(cat [VAULT]/production/erp-api/read-token)" https://api.novafoods.vn/erp/v1/inventory/sku/NF-DRI-SNK-0024<br>	Phản hồi HTTP 200 OK. Nội dung JSON phải chứa "quantity": 1500.	EVIDENCE_RUNBOOK-OPS-031_20260815_STEP_1.json (Lưu lại toàn bộ phản hồi JSON)
2	Kiểm tra tồn kho trên WMS (trước khi chạy): Lấy số liệu từ nguồn tin cậy. sql<br>psql -h wms-db.prod.novafoods.internal -U readonly_user -d wms_db -c "SELECT quantity FROM stock_items WHERE sku = 'NF-DRI-SNK-0024';"<br>	Kết quả từ psql phải trả về duy nhất một dòng với giá trị 1450.	EVIDENCE_RUNBOOK-OPS-031_20260815_STEP_2.log (Lưu lại output của terminal)
3	Thực thi đồng bộ hóa: Gửi yêu cầu buộc ERP cập nhật từ WMS. bash<br>curl -X POST -H "Authorization: Bearer $(cat [VAULT]/production/erp-api/write-token)" -H "Content-Type: application/json" -d '{"sku": "NF-DRI-SNK-0024", "source": "WMS-ACCU-TRACK", "force": true}' https://api.novafoods.vn/erp/v1/inventory/force-sync<br>	Phản hồi HTTP 202 Accepted. Nội dung JSON trả về một jobId. Ghi lại jobId này.	EVIDENCE_RUNBOOK-OPS-031_20260815_STEP_3.json (Lưu lại jobId và phản hồi)
4	Kiểm tra trạng thái job: Chờ cho đến khi job hoàn tất. Thay [jobId] bằng giá trị từ bước 3. bash<br># Chờ 30 giây trước khi kiểm tra<br>sleep 30<br>curl -X GET -H "Authorization: Bearer $(cat [VAULT]/production/erp-api/read-token)" https://api.novafoods.vn/erp/v1/jobs/[jobId-from-step-3]<br>	Trạng thái status trong JSON phải là COMPLETED. Nếu là RUNNING, chờ 15 giây và thử lại. Nếu là FAILED, dừng ngay và chuyển sang quy trình Rollback.	EVIDENCE_RUNBOOK-OPS-031_20260815_STEP_4.json (Lưu phản hồi JSON cuối cùng với status COMPLETED)
5	Kiểm tra tồn kho trên ERP (sau khi chạy): Xác nhận số liệu đã được cập nhật đúng. bash<br>curl -X GET -H "Authorization: Bearer $(cat [VAULT]/production/erp-api/read-token)" https://api.novafoods.vn/erp/v1/inventory/sku/NF-DRI-SNK-0024<br>	Phản hồi HTTP 200 OK. Nội dung JSON phải chứa "quantity": 1450.	EVIDENCE_RUNBOOK-OPS-031_20260815_STEP_5.json (Lưu lại toàn bộ phản hồi JSON)
6	Thông báo: Gửi email đến Trần Thị Bích Hạnh và kho-van@novafoods.vn với tiêu đề [THÀNH CÔNG] RUNBOOK-OPS-031: Đồng bộ tồn kho cho SKU NF-DRI-SNK-0024. Đính kèm tất cả bằng chứng.	Email đã được gửi thành công.	EVIDENCE_RUNBOOK-OPS-031_20260815_STEP_6.eml (Lưu bản nháp hoặc screenshot của email đã gửi)

Quy trình Rollback (Hoàn chỉnh)

Bước	Lệnh/Hành động	Điểm kiểm tra	Bằng chứng cần thu thập
1	Không có lệnh rollback tự động.	Hành động force-sync là ghi đè dữ liệu, không thể hoàn tác bằng một lệnh tương đương.	Không áp dụng.
2	Khi thất bại (ví dụ: job FAILED ở Bước 4 hoặc kết quả sai ở Bước 5): TUYỆT ĐỐI KHÔNG CHẠY LẠI RUNBOOK. Ngay lập tức tạo một ticket khẩn cấp trên Jira cho đội L3-ENGINEERING.	Ticket được tạo với độ ưu tiên Highest.	ID của ticket Jira mới (ví dụ: ENG-7891).
3	Chuyển giao thông tin: Đính kèm tất cả bằng chứng đã thu thập từ Bước 1 đến bước thất bại vào ticket Jira.	Ticket Jira chứa đầy đủ các tệp EVIDENCE_....	Screenshot của ticket Jira đã được cập nhật đầy đủ.
4	Sửa lỗi thủ công: Việc điều chỉnh dữ liệu sau thất bại sẽ được thực hiện bởi đội L3 Engineering theo quy trình PROC-DATA-ADJ-004 (Quy trình Điều chỉnh Dữ liệu có Giám sát).	Quy trình này nằm ngoài phạm vi của runbook này.	Không áp dụng.

Bản ghi chính và Phân tích ban đầu (Core Record & Initial Triage)

Đây là bản ghi đầy đủ, đã được điền dữ liệu mô phỏng cho case study Nova Foods. Mọi trường đều được hoàn thiện để làm mẫu tham khảo cho người học khi tự tạo một runbook thực tế.

Trường thông tin	Giá trị (Case study Nova Foods)
ID Runbook	RUNBOOK-AP-003
Tên Runbook	Xử lý sự cố Job tính ngày đến hạn thanh toán NCC thất bại
Hệ thống/Dịch vụ	ERP-FIN-AP (Phân hệ Kế toán phải trả của Nova Foods)
Chủ sở hữu (Owner)	Đội Hỗ trợ ERP Cấp 1 (ERP Support L1)
Mức độ ưu tiên	P1 - Cao
Ngày hiệu lực	2026-08-07

Bối cảnh và Tác động	Chi tiết (Case study Nova Foods)
Điều kiện kích hoạt	Cảnh báo tự động Alert ID: MON-605-20260807-001 từ hệ thống giám sát lúc 02:05 AM ICT. Tên cảnh báo: ERP-FIN-AP-NightlyPaymentDueDateCalc-Failure.
Tóm tắt vấn đề	Job xử lý theo lô (batch job) NF-JOB-FIN-AP-DUE-DATE-CALC-01 chạy hàng đêm đã thất bại. Job này có nhiệm vụ quét các hóa đơn nhà cung cấp (NCC) mới trong bảng ap_invoices và tính toán due_date (ngày đến hạn thanh toán) dựa trên điều khoản thanh toán (payment_terms) của mỗi NCC. Log hệ thống ghi nhận lỗi timeout do không thể ghi khóa (lock) trên bảng dữ liệu.
Tác động nghiệp vụ	Các hóa đơn từ NCC sẽ không được cập nhật ngày đến hạn thanh toán. Điều này chặn quy trình tạo Lệnh thanh toán của Phòng Kế toán. Các NCC chiến lược như NCC-4015 (Bao bì An Phát) và NCC-2108 (Rau sạch Đà Lạt) có thể không nhận được thanh toán đúng hạn.
Hậu quả nếu sai	Nếu không giải quyết trong 4 giờ: Gián đoạn chuỗi cung ứng do NCC có thể ngưng giao hàng vì thanh toán trễ. Nếu xử lý sai (ví dụ, hủy nhầm giao dịch quan trọng): Gây mất mát hoặc sai lệch dữ liệu tài chính, đòi hỏi quy trình đối soát và phục hồi dữ liệu phức tạp. Rủi ro chung: Chịu phạt hợp đồng, mất uy tín với NCC, ảnh hưởng dòng tiền.

Các bước xác minh sự cố (Verification Steps)
1. Xác minh cảnh báo: Truy cập dashboard giám sát (ví dụ: Splunk) và xác nhận cảnh báo MON-605-20260807-001 đang ở trạng thái FIRING.
2. Kiểm tra trạng thái Job: Đăng nhập vào công cụ lập lịch (ví dụ: Control-M) và kiểm tra trạng thái của job NF-JOB-FIN-AP-DUE-DATE-CALC-01 cho lần chạy gần nhất. Trạng thái mong đợi: FAILED.
3. Phân tích Log: Đọc file log tại đường dẫn /var/log/erp/jobs/NF-JOB-FIN-AP-DUE-DATE-CALC-01/2026-08-07.log. Tìm chính xác dòng lỗi sau: 2026-08-07 02:04:15 UTC \| FATAL: Cannot acquire lock on table 'ap_invoices'. Lock held by transaction ID 98752. Timeout expired.
4. Kiểm tra khóa CSDL: Chạy truy vấn chỉ đọc (read-only) sau trên cơ sở dữ liệu để xác định giao dịch (transaction) đang giữ khóa. SELECT pid, mode, granted, usename, query FROM pg_locks l JOIN pg_stat_activity a ON l.pid = a.pid WHERE relation = 'ap_invoices'::regclass; Kết quả mong đợi: Một dòng kết quả cho thấy một pid đang giữ khóa ExclusiveLock (hoặc tương tự) trên bảng ap_invoices.

Quyết định và Phân loại ban đầu (Initial Triage)
Nguyên nhân gốc (phỏng đoán)
Phân loại sự cố
Hành động tức thì
Điều kiện leo thang

Phân tích và Quyết định Khắc phục Sự cố

Bối cảnh sự cố là PROB-SLS-TAX-004: Sai thuế suất GTGT cho nhóm khách hàng "Nhà phân phối Cấp 2".

1. Sự thật, Hiện trạng và Nhu cầu

Hạng mục	Mô tả chi tiết	Bằng chứng / Nguồn tham chiếu (ID)
Sự thật Quan sát được (Fact)	Phòng Kế toán báo cáo các đơn hàng bán ra (Sales Order) cho khách hàng loại CUST-TYPE-DIST-02 xuất từ ngày 2026-08-01 bị áp thuế GTGT 8% thay vì 10%.	Email from: an.le@nova-foods.vn (Kế toán trưởng) Subject: [URGENT] Lỗi tính sai thuế GTGT trên ERP
Hành vi Hệ thống Hiện tại (Current Behavior)	Module Sales của ERP tự động lấy thuế suất từ bảng cấu hình tax_rate_rules khi tạo đơn hàng. Rule RULE-TAX-DIST02 đang có giá trị tax_rate = 0.08 cho điều kiện customer_type = 'CUST-TYPE-DIST-02'.	LOG-ERP-QUERY-20260807T091500Z Truy vấn DB: SELECT tax_rate FROM tax_rate_rules WHERE rule_id = 'RULE-TAX-DIST02';
Nhu cầu Nghiệp vụ Cốt lõi (Underlying Need)	Đảm bảo 100% đơn hàng và hóa đơn tuân thủ quy định thuế hiện hành. Việc xuất hóa đơn đúng là yêu cầu pháp lý bắt buộc để tránh rủi ro tài chính và pháp lý cho Nova Foods.	Luật Kế toán 88/2015/QH13 Nghị định 123/2020/NĐ-CP Verification required: Kế toán trưởng xác nhận mức thuế suất 10% là chính xác.

2. Phân tích Phương án và Ma trận Quyết định

Phương án	Mô tả	Ưu điểm	Nhược điểm
1. Sửa trực tiếp DB	Kỹ sư IT chạy lệnh UPDATE trên production database (cơ sở dữ liệu).	Nhanh nhất.	Rủi ro cao (gõ sai lệnh WHERE). Không có audit trail (dấu vết kiểm toán) trong ứng dụng. Vi phạm quy trình quản lý thay đổi.
2. Dùng UI Quản trị	Sử dụng chức năng "Quản lý Quy tắc Thuế" có sẵn trên giao diện người dùng (user interface - UI) của ERP.	An toàn, có validation (kiểm tra hợp lệ). Hệ thống tự ghi log (nhật ký) thay đổi. Tuân thủ quy trình.	Yêu cầu tài khoản có quyền. Chậm hơn sửa DB vài phút.
3. Viết Script	Viết một script (kịch bản) SQL để cập nhật. Script được review, phê duyệt rồi mới chạy.	Có thể tái sử dụng. Được review trước khi chạy.	Mất thời gian viết và review. Vẫn có rủi ro nếu script không đủ chặt chẽ.

Ma trận Quyết định Trọng số: 1 (Kém) - 5 (Tốt)

Tiêu chí	Trọng số	PA 1: Sửa DB	PA 2: Dùng UI	PA 3: Viết Script
An toàn & Giảm rủi ro	5	1	5	3
Khả năng truy vết (Traceability)	4	1	5	4
Tốc độ khắc phục	3	5	4	2
Tuân thủ quy trình	5	1	5	4
Tổng điểm		39	68	53

3. Đề xuất, Thẩm quyền và Hậu quả

• Quyết định ID: DEC-SLS-TAX-001
• Phương án được chọn: Phương án 2: Dùng UI Quản trị.
• Lý do: Đạt điểm cao nhất về an toàn và tuân thủ, là các yếu tố quan trọng nhất khi xử lý dữ liệu tài chính. Hệ thống tự ghi lại bằng chứng thay đổi, đáp ứng yêu cầu về truy vết.
• Thẩm quyền:
  • Xác nhận nghiệp vụ: Trưởng phòng Kế toán (an.le@nova-foods.vn) phải xác nhận bằng văn bản rằng mức thuế 10% là đúng.
  • Thực thi: Quản trị viên ERP (erp.admin@nova-foods.vn) thực hiện thay đổi trên UI theo yêu cầu đã được phê duyệt.
• Hậu quả nếu sai hoặc không hành động:
  • Tài chính: Nova Foods đối mặt rủi ro bị truy thu thuế, phạt chậm nộp và phạt hành chính từ cơ quan thuế.
  • Vận hành: Phải thực hiện quy trình phức tạp để xuất hóa đơn điều chỉnh cho tất cả các giao dịch đã bị sai, tốn thời gian của phòng Kế toán và gây ảnh hưởng xấu đến quan hệ với nhà phân phối.
  • Pháp lý: Vi phạm Nghị định 123/2020/NĐ-CP về hóa đơn, chứng từ.

4. Tier 3 — Fully Completed Nova Foods Case: Evidence and Traceability

Phần này ghi lại các giả định, các mục cần xác minh, các ngoại lệ, luồng tiêu cực, bằng chứng và đường lối leo thang (escalation) liên quan đến quyết định DEC-SLS-TAX-001. Việc ghi nhận này đảm bảo mọi rủi ro đã được nhận diện và có kế hoạch xử lý, đồng thời cung cấp bằng chứng cho việc kiểm toán sau này. Đây là bước quan trọng để đảm bảo tính minh bạch và có kiểm soát của quy trình vận hành.

Giả định (Assumptions)

Các giả định là những điều kiện được cho là đúng khi đưa ra quyết định mà không có bằng chứng xác thực tại thời điểm đó. Chúng cần được ghi lại để nhận diện rủi ro.

ID	Giả định	Lý do / Bối cảnh	Rủi ro nếu giả định sai
ASM-OPS-TAX-001	Hệ thống ERP có bật sẵn tính năng ghi log kiểm toán (audit log) cho các thay đổi cấu hình hệ thống.	Cần có bằng chứng thay đổi để tuân thủ quy trình và phục vụ kiểm toán.	Không có bằng chứng về việc ai đã thay đổi, thay đổi gì và khi nào, vi phạm nguyên tắc truy vết.
ASM-OPS-TAX-002	Tài khoản erp.admin@nova-foods.vn có đủ quyền để thay đổi cấu hình thuế suất trong phân hệ Bán hàng (Sales).	Đây là tài khoản quản trị, thường có quyền cao nhất.	Người thực thi không thể hoàn thành công việc, gây chậm trễ và cần quy trình leo thang để xin cấp quyền.
ASM-OPS-TAX-003	Việc thay đổi thuế suất chỉ ảnh hưởng đến các đơn hàng mới tạo sau thời điểm thay đổi.	Hệ thống ERP chuẩn thường bảo vệ dữ liệu lịch sử, không tự động tính toán lại các giao dịch đã hoàn tất.	Gây sai lệch hàng loạt dữ liệu tài chính trên các hóa đơn đã xuất, dẫn đến rủi ro pháp lý và tài chính nghiêm trọng.

Yêu cầu cần xác minh (Verification Required)

Đây là các điểm chưa chắc chắn và phải được một người có thẩm quyền kiểm tra và xác nhận trước hoặc sau khi hành động.

ID	Nội dung cần xác minh	Người xác minh (Vai trò & Email)	Bằng chứng cần có
VRF-OPS-TAX-001	Mức thuế suất 10% là chính xác và tuân thủ quy định pháp luật hiện hành cho các nhóm hàng hóa liên quan, có hiệu lực từ ngày dự kiến áp dụng.	Trưởng phòng Kế toán (an.le@nova-foods.vn)	Email hoặc ticket có xác nhận bằng văn bản. ID tham chiếu: Jira:TKT-4591.
VRF-OPS-TAX-002	Kiểm tra và xác nhận log hệ thống ERP có ghi lại đầy đủ: giá trị cũ (8%), giá trị mới (10%), tài khoản thực hiện (erp.admin) và dấu thời gian (timestamp).	Trưởng nhóm IT/ERP (erp.lead@nova-foods.vn)	Trích xuất file log hoặc ảnh chụp màn hình giao diện xem log.
VRF-OPS-TAX-003	Sau khi thay đổi, tạo một đơn hàng thử nghiệm để xác nhận hệ thống áp dụng đúng mức thuế 10%. Đồng thời, kiểm tra một đơn hàng cũ đã xuất hóa đơn để đảm bảo nó vẫn giữ mức thuế cũ.	Chuyên viên kiểm thử (QA) (qa.tester@nova-foods.vn)	Báo cáo kết quả thực thi test case TC-SLS-TAX-005 trong hệ thống TestRail.

Ngoại lệ và Luồng tiêu cực (Exceptions and Negative Paths)

Đây là các kịch bản có thể xảy ra khi quá trình thực thi không diễn ra như mong đợi (luồng tiêu cực) và cách xử lý tương ứng.

ID	Kịch bản ngoại lệ / Lỗi (Negative Path)	Cách xử lý được đề xuất	Người chịu trách nhiệm xử lý
EXC-OPS-TAX-001	Tài khoản erp.admin đăng nhập nhưng giao diện không cho phép sửa hoặc báo lỗi "Permission Denied" (Từ chối quyền truy cập).	Dừng thực thi. Báo cáo ngay cho Quản lý IT để yêu cầu cấp quyền theo quy trình. Tham chiếu tới DEC-SLS-TAX-001.	Quản trị viên ERP (erp.admin@nova-foods.vn)
EXC-OPS-TAX-002	Giao diện quản trị thuế bị lỗi kỹ thuật, không thể truy cập hoặc không lưu được thay đổi.	Dừng thực thi. Ghi nhận lỗi (chụp màn hình), báo cáo cho bộ phận hỗ trợ kỹ thuật ERP (vendor). Xem xét kích hoạt Phương án 3 (Viết script) nếu lỗi kéo dài.	Quản trị viên ERP (erp.admin@nova-foods.vn)
EXC-OPS-TAX-003	(Nghiêm trọng) Sau khi thay đổi, kiểm tra thấy các hóa đơn cũ bị tự động tính lại thuế sang 10%.	HÀNH ĐỘNG KHẨN: 1. Hoàn tác (revert) thay đổi ngay lập tức nếu có thể. 2. Nếu không thể hoàn tác, liên hệ IT để tạm ngưng các tác vụ tự động liên quan đến tài chính. 3. Leo thang khẩn cấp tới các bên liên quan.	Quản trị viên ERP, Trưởng phòng Kế toán

Bằng chứng và Truy vết (Evidence and Traceability)

Đây là danh sách các "vật chứng" kỹ thuật số hoặc tài liệu cần được thu thập và lưu trữ để chứng minh quy trình đã được thực hiện đúng.

ID Bằng chứng	Mô tả bằng chứng	Liên kết tới Yêu cầu / Quyết định	Nơi lưu trữ được kiểm soát
EV-OPS-TAX-001	Ticket Jira TKT-4591 với bình luận xác nhận từ an.le@nova-foods.vn về mức thuế 10%.	VRF-OPS-TAX-001, DEC-SLS-TAX-001	Hệ thống Jira: https://jira.nova-foods.vn/browse/TKT-4591
EV-OPS-TAX-002	Tệp erp_audit_2026-08-15.csv trích xuất từ hệ thống ERP, chứa dòng log về việc thay đổi cấu hình thuế.	ASM-OPS-TAX-001, VRF-OPS-TAX-002	Network drive: \\nas01\erp-logs\audit\change-runbooks\RB-023\
EV-OPS-TAX-003	Báo cáo thực thi Test Case TC-SLS-TAX-005 trên TestRail, trạng thái PASSED.	VRF-OPS-TAX-003, ASM-OPS-TAX-003	TestRail: https://testrail.nova-foods.vn/cases/view/C678

Ghi nhận leo thang (Escalation Records)

Leo thang (escalation) là quy trình chuyển một vấn đề lên cấp quản lý cao hơn hoặc bộ phận có chuyên môn hơn khi người hiện tại không thể giải quyết.

ID	Điều kiện leo thang (Trigger)	Kênh liên lạc	Người nhận leo thang (Vai trò & Email)	Thời gian phản hồi mong đợi (SLA)
ESC-OPS-TAX-001	Kích hoạt bởi EXC-OPS-TAX-001 (thiếu quyền).	Email với tiêu đề [URGENT-PERMISSION]	Quản lý IT (it.manager@nova-foods.vn)	Trong vòng 4 giờ làm việc.
ESC-OPS-TAX-002	Kích hoạt bởi EXC-OPS-TAX-002 (hệ thống lỗi).	Tạo ticket trên cổng hỗ trợ của nhà cung cấp.	ERP Vendor Support (support@erpvendor.com)	2 giờ làm việc (Severity 2).
ESC-OPS-TAX-003	Kích hoạt bởi EXC-OPS-TAX-003 (sai lệch dữ liệu nghiêm trọng).	Gọi điện thoại trực tiếp, sau đó gửi email tóm tắt.	1. Trưởng phòng Kế toán (an.le@nova-foods.vn) 2. Giám đốc IT (it.director@nova-foods.vn) 3. Giám đốc Vận hành - COO (coo@nova-foods.vn)	Tức thì (Immediate).

Ma trận Truy vết Yêu cầu (Requirements Traceability Matrix)

Ma trận Truy vết Yêu cầu (Requirements Traceability Matrix - RTM) là một công cụ để đảm bảo các yêu cầu được liên kết từ nguồn gốc (nhu cầu nghiệp vụ, quy định pháp lý) đến các sản phẩm cuối cùng (chức năng phần mềm, ca kiểm thử, tài liệu). Việc này đảm bảo không có yêu cầu nào bị bỏ sót và cung cấp khả năng phân tích tác động khi có thay đổi. Bảng dưới đây trình bày ma trận truy vết cho quy tắc nghiệp vụ BR-NF-ACC-003 trong bối cảnh mô phỏng của Nova Foods.

ID Nguồn	Loại Artifact	Mô tả ngắn gọn (Tiếng Việt)	Liên kết đến ID Đích
NEED-NF-FIN-001	Business Need	Tuân thủ các quy định về hóa đơn, chứng từ và thuế của Việt Nam để đảm bảo hoạt động kinh doanh hợp pháp và tránh rủi ro pháp lý.	REQ-NF-ERP-FN-015
REQ-NF-ERP-FN-015	Functional Requirement	Hệ thống ERP phải có khả năng tạo và quản lý hóa đơn điện tử bán hàng tuân thủ Nghị định 123/2020/NĐ-CP, bao gồm việc tính và hiển thị đúng thuế GTGT.	BR-NF-ACC-003
BR-NF-ACC-003	Business Rule	Hệ thống phải tự động tính thuế GTGT đầu ra trên hóa đơn bán hàng dựa trên thuế suất được cấu hình cho từng mặt hàng.	AC-NF-ACC-003-01, AC-NF-ACC-003-02, AC-NF-ACC-003-03, DATA-API-NF-INV-005
AC-NF-ACC-003-01	Acceptance Criterion	Khi một dòng hàng (line item) có thuế suất > 0 được thêm vào hóa đơn, hệ thống phải tính toán giá trị thuế GTGT cho dòng đó.	TC-NF-ACC-003-P-01
AC-NF-ACC-003-02	Acceptance Criterion	Khi một dòng hàng có thuế suất = 0 hoặc không chịu thuế được thêm vào, giá trị thuế GTGT phải bằng 0.	TC-NF-ACC-003-N-01
AC-NF-ACC-003-03	Acceptance Criterion	Tổng số tiền thuế GTGT của hóa đơn phải bằng tổng thuế của tất cả các dòng hàng, và được lưu trữ trong trường invoice.totalVatAmount.	TC-NF-ACC-003-P-02
DATA-API-NF-INV-005	Data/API Element	Endpoint POST /api/v1/invoices và các trường dữ liệu liên quan: lineItems.taxRate, lineItems.vatAmount, invoice.totalVatAmount.	REQ-NF-ERP-FN-015
TC-NF-ACC-003-P-01	Test Case (Positive)	Kịch bản kiểm thử: Tạo hóa đơn với 1 mặt hàng (giá 1,000,000 VND, thuế suất 10%). Xác minh lineItems.vatAmount là 100,000 VND và invoice.totalVatAmount là 100,000 VND.	AC-NF-ACC-003-01
TC-NF-ACC-003-N-01	Test Case (Negative)	Kịch bản kiểm thử: Tạo hóa đơn với 1 mặt hàng không chịu thuế (thuế suất 0%). Xác minh lineItems.vatAmount và invoice.totalVatAmount đều là 0 VND.	AC-NF-ACC-003-02, DEF-10923
DEF-10923	Defect (Closed)	Lỗi được phát hiện trong quá trình kiểm thử: Hệ thống tính sai thuế khi số tiền có phần thập phân do làm tròn không đúng quy tắc. Lỗi đã được khắc phục và xác minh.	TC-NF-ACC-003-N-01
CR-801	Change Request	Yêu cầu thay đổi: Cập nhật hệ thống để hỗ trợ thêm mức thuế suất 5% cho các mặt hàng nông sản theo quy định mới, có hiệu lực từ Quý 4/2026.	NEED-NF-FIN-001

Ma trận này cho thấy một chuỗi liên kết hoàn chỉnh, đi từ nhu cầu tuân thủ pháp luật, qua yêu cầu chức năng, quy tắc nghiệp vụ cụ thể, tiêu chí chấp nhận, đến các ca kiểm thử và cả các thay đổi phát sinh. Việc duy trì ma trận này giúp đội ngũ quản lý phạm vi, xác định ảnh hưởng của thay đổi và chứng minh sự tuân thủ trong các đợt kiểm toán.

Bảng Quyết Định: Xử Lý Lô Hàng Nguyên Vật Liệu Đầu Vào

Bảng quyết định (tiếng Anh: Decision Table) là một kỹ thuật phân tích nghiệp vụ dùng để mô hình hóa các quy tắc logic phức tạp một cách rõ ràng và không mơ hồ. Thay vì viết các câu văn dài dòng, chúng ta sử dụng một bảng có cấu trúc để ánh xạ các kết hợp điều kiện khác nhau tới các hành động tương ứng. Bảng này đặc biệt hữu ích khi một quyết định phụ thuộc vào nhiều yếu tố.

Đối với kịch bản của Nova Foods, bảng quyết định DT-QC-001 này chuẩn hóa quy trình xử lý của Bộ phận Quản lý Chất lượng (QC) khi một lô hàng nguyên vật liệu thô được giao đến kho. Bảng này xác định chính xác hành động nào cần thực hiện trên hệ thống ERP, ai cần được thông báo và quy trình tài chính tiếp theo là gì, dựa trên kết quả kiểm tra chất lượng, loại nhà cung cấp và tầm quan trọng của nguyên vật liệu. Dữ liệu và quy tắc trong bảng là mô phỏng cho mục đích học tập.

Bảng DT-QC-001: Xử lý Lô hàng Nguyên vật liệu thô tại Nova Foods

	Quy tắc 1 (R1)	Quy tắc 2 (R2)	Quy tắc 3 (R3)	Quy tắc 4 (R4)
ĐIỀU KIỆN
BR-QC-001: Kết quả kiểm tra chất lượng (QC)	Đạt	Lỗi nhỏ	Lỗi nhỏ	Lỗi nghiêm trọng
BR-PUR-004: Phân loại nhà cung cấp	-	Chiến lược (Tier 1)	Tiêu chuẩn (Tier 2)	-
BR-INV-005: Tầm quan trọng nguyên vật liệu	-	Thiết yếu	-	-
HÀNH ĐỘNG
Hành động trên hệ thống ERP	ACCEPT_SHIPMENT	ACCEPT_SHIPMENT	QUARANTINE_SHIPMENT	REJECT_SHIPMENT
Thông báo nội bộ	Không yêu cầu	Email cho Quản lý QC và Trưởng phòng Mua hàng	Email cho Quản lý QC	Email cho Quản lý QC và Trưởng phòng Mua hàng
BR-FIN-012: Xử lý tài chính	Xử lý thanh toán 100%	Tạm giữ 30% thanh toán, chờ xử lý	Tạm giữ 100% thanh toán	Yêu cầu Ghi chú Tín dụng (Credit Note)

Ghi chú Diễn giải: * Dấu gạch ngang (-): có nghĩa là điều kiện đó không ảnh hưởng đến kết quả của quy tắc, giúp đơn giản hóa bảng. * Quy tắc 1: Lô hàng đạt chất lượng sẽ được chấp nhận và thanh toán đầy đủ, bất kể nhà cung cấp hay loại nguyên vật liệu. * Quy tắc 2: Lỗi nhỏ từ nhà cung cấp chiến lược đối với mặt hàng thiết yếu vẫn được chấp nhận để không gián đoạn sản xuất, nhưng thanh toán sẽ bị giữ lại một phần để làm cơ sở đàm phán. * Quy tắc 3: Lỗi nhỏ từ nhà cung cấp tiêu chuẩn sẽ bị cách ly để kiểm tra thêm và thanh toán bị giữ toàn bộ. * Quy tắc 4: Bất kỳ lỗi nghiêm trọng nào cũng dẫn đến việc từ chối toàn bộ lô hàng và yêu cầu nhà cung cấp phát hành Credit Note (chứng từ điều chỉnh giảm công nợ).

Bảng quyết định này đảm bảo tính nhất quán, giảm thiểu sai sót do con người và cung cấp một cơ sở rõ ràng để kiểm thử (test basis) cho các trường hợp kiểm thử liên quan.

Bảng Truy vết Nguồn gốc cho Bảng Quyết định

Bảng này xác nhận mối liên kết giữa bảng quyết định và các artifact khác trong hệ thống tài liệu.

ID Bằng chứng	Loại Bằng chứng	Tham chiếu đến Quy tắc Nghiệp vụ (BR)	Tham chiếu đến Trường hợp Kiểm thử (TC)	Ghi chú và Ranh giới Trách nhiệm
DT-QC-001	Bảng Quyết định	BR-QC-001 BR-PUR-004 BR-INV-005 BR-FIN-012	TC-QC-PROC-001 TC-QC-PROC-002 TC-QC-PROC-003 TC-QC-PROC-004	Bảng này là nguồn chân lý (source of truth) cho logic xử lý lô hàng tại thời điểm 2026-08-07. Mọi thay đổi về quy tắc phải được cập nhật tại đây trước khi áp dụng vào kiểm thử hoặc cấu hình hệ thống. Việc phê duyệt các giá trị ngưỡng (ví dụ: "lỗi nhỏ" là gì) thuộc về Business Owner của bộ phận QC.

5. Tier 4 — Senior BA Quality Gate

Mục này định nghĩa danh sách kiểm tra chất lượng (quality checklist) và các tiêu chí quyết định cho Senior Business Analyst (BA). BA dùng checklist này để rà soát các artifact đã hoàn thiện (ví dụ: bản điền đầy đủ của template này cho một case study cụ thể) trước khi đề xuất baseline. Mục đích là đảm bảo tính toàn vẹn, nhất quán, và tuân thủ các ranh giới thẩm quyền đã được xác định trong corpus.

5.1. Bảng Tiêu chí Đánh giá Chất lượng

Bảng sau đây là công cụ chính cho cổng chất lượng. Mỗi hạng mục phải được đánh giá là Đạt (Pass). Bất kỳ hạng mục nào Không Đạt (Fail) đều phải dẫn đến một hành động cụ thể.

Mã hạng mục	Khu vực kiểm tra	Nội dung kiểm tra chi tiết	Tiêu chí Đạt (Pass)	Tiêu chí Không Đạt (Fail)	Hành động khi Fail
Tính đầy đủ (Completeness)
QG-CPL-01	Hoàn thiện Template	Mọi trường dữ liệu trong mẫu Tier 3 đã được điền, không còn giá trị giữ chỗ.	Không còn placeholder <...>, TBD, TODO hoặc trường bắt buộc bị bỏ trống.	Còn placeholder hoặc trường bắt buộc trống.	REWORK
QG-CPL-02	Phạm vi nội dung	Tất cả các mục nội dung yêu cầu theo hợp đồng của artifact đã được giải quyết.	Mọi mục trong required_content của document contract đều có nội dung tương ứng.	Thiếu nội dung cho một hoặc nhiều mục yêu cầu.	STOP
Tính nhất quán (Consistency)
QG-CON-01	Thuật ngữ	Thuật ngữ nghiệp vụ có nhất quán với CANONICAL_DATA_DICTIONARY và 05-glossary/GLOSSARY.md không?	Mọi thuật ngữ chuyên ngành đều khớp với định nghĩa đã được chuẩn hóa.	Sử dụng thuật ngữ không xác định, sai định nghĩa, hoặc mâu thuẫn.	REWORK
QG-CON-02	Định danh (ID)	Các định danh (ví dụ BR-, REQ-, TC-) có tuân thủ quy tắc trong TRACEABILITY_ID_REGISTRY.md không?	Tất cả ID đều hợp lệ, duy nhất, và được đăng ký đúng cách.	ID sai định dạng, bị trùng lặp, hoặc chưa được đăng ký.	REWORK
QG-CON-03	Quy tắc nghiệp vụ	Các quy tắc nghiệp vụ được nêu có mâu thuẫn với CANONICAL_BUSINESS_RULES.md không?	Các quy tắc được áp dụng nhất quán và không tạo ra xung đột logic với catalog trung tâm.	Quy tắc tại chỗ mâu thuẫn hoặc diễn giải sai quy tắc gốc.	STOP
Tính khả kiểm (Testability)
QG-TST-01	Tiêu chí chấp nhận	Mỗi yêu cầu hoặc quy tắc có tiêu chí chấp nhận (Acceptance Criteria) rõ ràng, cụ thể, đo lường được không?	Tiêu chí chấp nhận không mơ hồ, có thể dùng để viết ca kiểm thử (test case) với kết quả rõ ràng (pass/fail).	Tiêu chí mơ hồ, chủ quan (ví dụ: "dễ sử dụng"), hoặc không thể kiểm chứng.	REWORK
QG-TST-02	Cơ sở kiểm thử	Artifact có cung cấp đủ thông tin để trở thành cơ sở kiểm thử (Test Basis) theo định nghĩa của ISTQB không?	Từ artifact này, một Tester có thể tạo ra các test case mà không cần phải suy diễn thêm quy tắc nghiệp vụ.	Thiếu thông tin về điều kiện, dữ liệu đầu vào, hoặc kết quả mong đợi.	REWORK
Tính truy vết (Traceability)
QG-TRC-01	Truy vết nguồn gốc	Mọi yêu cầu, quy tắc, và quyết định có được truy vết ngược về nguồn gốc (ví dụ: nhu cầu nghiệp vụ, luật định) không?	Bảng truy vết (traceability matrix) đầy đủ và chính xác. Mọi ID nguồn đều hợp lệ.	Yêu cầu "mồ côi" không rõ nguồn gốc, hoặc liên kết truy vết bị sai.	STOP
QG-TRC-02	Truy vết xuôi	Mọi yêu cầu có được truy vết xuôi đến các artifact khác (ví dụ: test case, user story) không?	Các liên kết xuôi được thiết lập, đảm bảo không yêu cầu nào bị bỏ sót trong quá trình phát triển và kiểm thử.	Thiếu liên kết xuôi, cho thấy yêu cầu có thể bị bỏ quên.	REWORK
Thẩm quyền & Ranh giới (Authority & Boundaries)
QG-BND-01	Ranh giới pháp lý	Artifact có tự diễn giải luật (ví dụ: Luật Kế toán, Luật BV Dữ liệu Cá nhân) không?	Các yêu cầu liên quan đến luật chỉ trích dẫn điều khoản và ghi rõ "Cần xác minh bởi Legal Owner".	Artifact đưa ra kết luận pháp lý hoặc diễn giải luật thay cho bộ phận pháp chế.	ESCALATE
QG-BND-02	Ranh giới kế toán	Artifact có tự đưa ra quyết định về hạch toán hoặc quy trình tài chính không?	Các yêu cầu liên quan đến kế toán chỉ nêu quy trình và ghi rõ "Cần xác minh bởi Accounting Owner".	Artifact định nghĩa cách hạch toán, xử lý thuế, hoặc các nghiệp vụ tài chính chuyên sâu.	ESCALATE
QG-BND-03	Ranh giới kiến trúc	Artifact có định nghĩa giải pháp kỹ thuật, thiết kế database, hoặc lựa chọn công nghệ không?	Yêu cầu chỉ mô tả "cái gì" (what), không phải "như thế nào" (how). Các vấn đề kỹ thuật được chuyển cho Architect.	Artifact chứa sơ đồ triển khai, đặc tả API chi tiết, hoặc các quyết định kiến trúc khác.	ESCALATE
QG-BND-04	Ranh giới nghiệp vụ	Artifact có tự phê duyệt các ngưỡng vận hành (ví dụ: % lỗi chấp nhận được, hạn mức công nợ) không?	Các giá trị ngưỡng được ghi là placeholder hoặc ghi rõ "Cần phê duyệt bởi Business Owner".	Artifact tự ấn định một giá trị nghiệp vụ quan trọng mà không có sự phê duyệt từ người chủ sở hữu quy trình.	ESCALATE
An ninh, Bảo mật, Pháp lý & Kế toán (Security, Privacy, Legal, Accounting)
QG-SPLA-01	Nhận diện PII	Dữ liệu định danh cá nhân (PII - Personally Identifiable Information) có được xác định và xử lý theo Luật 91/2025/QH15 không?	Mọi trường PII được đánh dấu, và các yêu cầu liên quan đến chúng phải bao gồm các biện pháp bảo vệ.	Xử lý PII mà không nhận diện, hoặc không có yêu cầu bảo vệ tương ứng.	STOP
QG-SPLA-02	Yêu cầu bảo mật	Các yêu cầu có xem xét đến các rủi ro bảo mật phổ biến (ví dụ: OWASP API Security Top 10) không?	Các yêu cầu liên quan đến API, xác thực, phân quyền có đề cập đến các khía cạnh bảo mật cơ bản.	Bỏ qua hoàn toàn các yếu tố bảo mật ở những chức năng nhạy cảm.	REWORK

5.2. Định nghĩa các hành động

• REWORK (Làm lại): Lỗi có thể được khắc phục bởi tác giả của artifact mà không cần sự can thiệp từ các vai trò khác. Tác giả sửa lại và gửi lại để review. Ví dụ: điền nốt thông tin còn thiếu, sửa lỗi chính tả, sửa ID sai định dạng.
• STOP (Dừng): Lỗi mang tính hệ thống hoặc cấu trúc, vi phạm các quy tắc quản trị cốt lõi của corpus. Toàn bộ quy trình baseline bị dừng lại. Vấn đề phải được giải quyết ở cấp độ cấu trúc trước khi tiếp tục. Ví dụ: thiếu một section quan trọng, mâu thuẫn với artifact nguồn chuẩn.
• ESCALATE (Leo thang): Artifact đã vượt qua ranh giới thẩm quyền. Vấn đề phải được chuyển lên cho vai trò có thẩm quyền quyết định (ví dụ: Legal Owner, Accounting Owner, Architect, Business Owner). Senior BA có trách nhiệm đóng gói vấn đề và chuyển đi, nhưng không tự đưa ra quyết định thay cho họ. Quá trình baseline bị tạm dừng cho đến khi có phản hồi từ vai trò được leo thang.

Tiêu chí Đánh giá Chất lượng Chi tiết

Bảng này định nghĩa các hạng mục kiểm tra chất lượng mà một Senior BA phải áp dụng cho tài liệu Runbook trước khi xem xét baseline. Mỗi hạng mục có tiêu chí đạt, ví dụ lỗi và điều kiện dừng (STOP) hoặc leo thang (escalate) để đảm bảo tính toàn vẹn và khả thi của tài liệu.

Hạng mục Kiểm tra	Mục tiêu & Tiêu chí Đạt (Pass)	Ví dụ Lỗi & Tiêu chí Dừng/Leo thang (Stop/Escalate)
Tính đầy đủ (Completeness)	Tất cả các mục trong template Tier 2 đã được điền đầy đủ trong bản sao Tier 3 của Nova Foods. Không còn placeholder như <điền thông tin> hoặc TBD. Mọi phụ thuộc được liệt kê đều có artifact tương ứng tồn tại.	Lỗi: Trường Owner của một bước bị bỏ trống. Tiêu chí Dừng: Bất kỳ trường bắt buộc nào thiếu dữ liệu làm cho quy trình không thể thực thi hoặc không thể kiểm soát.
Tính nhất quán (Consistency)	Thuật ngữ, định danh (ID), và quy tắc nghiệp vụ (business rule) sử dụng trong runbook phải khớp 100% với các nguồn chính thức: CANONICAL_DATA_DICTIONARY, CANONICAL_BUSINESS_RULES, và TRACEABILITY_ID_REGISTRY.	Lỗi: Runbook dùng mã SP-00123 trong khi CANONICAL_DATA_DICTIONARY định nghĩa là PRODUCT-00123. Tiêu chí Dừng: Mâu thuẫn với nguồn chính thức (source of truth) có thể gây ra lỗi dữ liệu hoặc sai lệch quy trình.
Khả năng kiểm thử (Testability)	Mỗi bước trong quy trình vận hành phải có kết quả đầu ra có thể xác minh được. Các tiêu chí chấp nhận (acceptance criteria) phải cụ thể, đo lường được và không mơ hồ.	Lỗi: Mô tả một bước là "đảm bảo hệ thống chạy ổn định". Tiêu chí Leo thang: Một yêu cầu không thể được kiểm thử viên viết test case để xác minh. Cần làm rõ với Business Owner.
Khả năng truy vết (Traceability)	Mọi quy tắc, yêu cầu, hoặc ràng buộc dữ liệu phải có ID tham chiếu rõ ràng, cho phép truy ngược về nguồn gốc nghiệp vụ hoặc pháp lý của nó. Ví dụ: tham chiếu BR-INV-011 hoặc REQ-FN-002.	Lỗi: Một quy tắc "Chỉ xuất hàng khi đã thanh toán" xuất hiện mà không có ID BR-... liên kết. Tiêu chí Dừng: "Quy tắc ma" (magic rule) không rõ nguồn gốc có thể là hiểu sai yêu cầu, gây rủi ro tuân thủ hoặc vận hành.
Thẩm quyền nguồn (Source Authority)	Nguồn của một quy tắc phải hợp lệ và có thẩm quyền. Ví dụ, quy tắc kế toán phải xuất phát từ Legal/Accounting Owner, không phải từ một giả định của đội phát triển.	Lỗi: Một quy tắc tính thuế GTGT được ghi là "theo yêu cầu của anh A bên kho". Tiêu chí Leo thang: Quy tắc có ảnh hưởng pháp lý/kế toán/bảo mật nhưng nguồn gốc không phải từ vai trò có thẩm quyền. Cần xác minh với Owner tương ứng.
Quyền sở hữu (Ownership)	Mỗi quy trình, quyết định, và bước thực thi trong runbook phải được gán một Owner (người sở hữu) có vai trò và trách nhiệm phù hợp.	Lỗi: Gán Developer làm Owner cho bước "Phê duyệt chiết khấu cho nhà phân phối". Tiêu chí Leo thang: Sai lệch về quyền sở hữu có thể dẫn đến quyết định sai hoặc trì trệ. Cần điều chỉnh theo ma trận phân quyền (RACI matrix) nếu có.
Ranh giới Bảo mật, Pháp lý, Kế toán (Security, Legal, Accounting Boundaries)	Runbook phải nhận diện và tôn trọng các ranh giới. Các bước xử lý dữ liệu cá nhân (PII - Personally Identifiable Information) phải tuân thủ Luật 91/2025/QH15. Các bước liên quan tài chính phải tuân thủ Luật Kế toán.	Lỗi: Một bước yêu cầu nhân viên hỗ trợ ghi lại số thẻ tín dụng của khách hàng vào file log. Tiêu chí Dừng: Vi phạm rõ ràng về bảo mật, quyền riêng tư hoặc quy định pháp lý. Dừng ngay lập tức và leo thang cho Security/Legal Owner.
Tác động thay đổi (Change Impact)	Tài liệu phải phân tích và ghi nhận các tác động của quy trình này đến các hệ thống, quy trình, hoặc phòng ban khác.	Lỗi: Runbook đề xuất thay đổi quy trình nhập kho mà không đề cập ảnh hưởng tới hệ thống kế toán và báo cáo tồn kho. Tiêu chí Leo thang: Thiếu phân tích tác động có thể gây gián đoạn vận hành ở các khu vực liên quan. Cần bổ sung phân tích.

Kết quả Áp dụng Checklist Chất lượng cho Case Study Nova Foods

Ghi nhận này áp dụng checklist chất lượng cho ví dụ Nova Foods được điền tại Tier 3 của artifact TMPL-OPS-RUNBOOK-001_runbook.md (phiên bản v0.9.0, trạng thái IN_REVIEW). Các kết quả này không cấu thành phê duyệt baseline.

Hạng mục kiểm tra	ID Tham chiếu / Vị trí	Kết quả tìm thấy	Trạng thái	Hành động đề xuất
Tính đầy đủ (Completeness)	Tier 3, Mục 3.2, Bảng "Thông tin Nhà cung cấp"	Thiếu trường Mã số thuế của nhà cung cấp. Dữ liệu này là bắt buộc cho việc tạo hóa đơn tài chính theo Nghị định 123/2020/NĐ-CP.	KHÔNG ĐẠT	Bổ sung cột "Mã số thuế" vào bảng và điền dữ liệu mô phỏng. Đảm bảo mọi bản ghi nhà cung cấp đều có giá trị này.
Tính nhất quán (Consistency)	Tier 3, Mục 3.4, "Quy trình Nhận hàng"	Quy trình mô tả bước "ghi nhận đơn vị" nhưng dùng thuật ngữ Đơn vị kiện, trong khi CANONICAL_DATA_DICTIONARY.md định nghĩa trường chuẩn là Đơn vị tính (Unit of Measure).	CẢNH BÁO	Đồng bộ thuật ngữ trong runbook với Từ điển dữ liệu Canonical. Sử dụng Đơn vị tính để đảm bảo nhất quán toàn hệ thống.
Tính có thể kiểm thử (Testability)	Tier 3, Mục 3.5, Tiêu chí chấp nhận cho REQ-NF-INV-005	Tiêu chí "Hệ thống phải xử lý nhanh" là mơ hồ, không thể đo lường và kiểm thử khách quan. Thiếu ngưỡng cụ thể.	KHÔNG ĐẠT	Viết lại tiêu chí chấp nhận theo định dạng có thể kiểm thử. Ví dụ: "Hệ thống phải hoàn tất giao dịch nhập kho trong vòng 500ms ở mức tải 50 người dùng đồng thời."
Khả năng truy vết (Traceability)	Tier 3, Mục 3.1, Yêu cầu nghiệp vụ REQ-NF-PO-011	Yêu cầu REQ-NF-PO-011 ("Tự động gửi email cảnh báo khi hàng sắp hết hạn") không có liên kết ngược về mục tiêu nghiệp vụ hoặc rủi ro cụ thể trong Business Case.	CẢNH BÁO	Bổ sung liên kết truy vết từ yêu cầu này tới mục tiêu "Giảm thiểu thất thoát hàng tồn kho do hết hạn sử dụng" được nêu trong tài liệu chiến lược.
Thẩm quyền nguồn (Source Authority)	Tier 3, Mục 3.6, "Diễn giải tuân thủ"	Ghi nhận "Quy trình truy xuất nguồn gốc tuân thủ Luật An toàn thực phẩm" nhưng không trích dẫn điều khoản cụ thể và không có nhãn "Cần xác minh bởi Legal Owner".	KHÔNG ĐẠT	Gỡ bỏ khẳng định tuân thủ. Thay bằng mô tả quy trình và thêm nhãn VERIFICATION_REQUIRED: Legal Owner để làm rõ đây là diễn giải, không phải kết luận pháp lý đã được phê duyệt.
Ranh giới pháp lý/kế toán	Tier 3, Mục 3.2, Bảng "Thông tin Nhà cung cấp"	Dữ liệu nhà cung cấp có liên quan trực tiếp đến Luật Kế toán 88/2015/QH13 nhưng không có ghi chú về việc cần xác minh bởi vai trò Kế toán trưởng (Accounting Owner).	CẢNH BÁO	Thêm ghi chú vào phần metadata của bảng dữ liệu nhà cung cấp: VERIFICATION_REQUIRED: Accounting Owner.
Bảo mật & Quyền riêng tư (Security/Privacy)	Tier 3, Mục 3.2, Dữ liệu Người liên hệ	Dữ liệu mô phỏng chứa Số điện thoại và Email, là Dữ liệu Cá nhân theo Luật 91/2025/QH15. Template không đề cập đến yêu cầu phân loại hay che giấu (masking) dữ liệu.	CẢNH BÁO	Bổ sung một mục con về "Phân loại dữ liệu và xử lý", tham chiếu tới CANONICAL_DATA_DICTIONARY.md và ghi rõ các trường PII phải được che giấu trong môi trường UAT và staging.
Phân tích tác động thay đổi	Tier 3, Mục 3.7, "Tác động thay đổi"	Chỉ phân tích tác động đến người dùng Kho. Bỏ qua tác động đến các hệ thống khác như hệ thống Báo cáo (BI) và Kế toán (ERP-FIN) khi thay đổi logic tồn kho.	CẢNH BÁO	Mở rộng mục phân tích tác động, bổ sung các dòng cho hệ thống BI (cập nhật báo cáo tồn kho) và ERP-FIN (ghi nhận bút toán giá trị kho).

Tóm tắt kết quả review: Trạng thái tổng thể REVIEW_PENDING_CHANGES. Ví dụ Nova Foods chưa đủ chất lượng để làm mẫu chuẩn. Cần xử lý các điểm KHÔNG ĐẠT và CẢNH BÁO trước khi xem xét baseline.

6. Cross-File Checks, Open Issues, and Escalation

6.1. Kiểm tra chéo Tính nhất quán giữa các Artifact

Mục này ghi nhận kết quả kiểm tra tính nhất quán của tài liệu TMPL-OPS-RUNBOOK-001_runbook.md (phiên bản v0.9.0) với các artifact quản trị trung tâm của corpus. Mục tiêu là đảm bảo không có mâu thuẫn về metadata, định danh, quy tắc hoặc dữ liệu trước khi chuyển giao. Mỗi artifact được xem là một Source of Truth (Nguồn Chân lý) cho một phạm vi cụ thể. Việc kiểm tra đảm bảo Traceability (khả năng truy vết) được bảo toàn.

Bảng dưới đây tóm tắt các điểm kiểm tra và kết quả. Mọi kiểm tra đều được thực hiện vào ngày 2026-08-07.

Artifact được kiểm tra chéo	Điểm kiểm tra chính	Kết quả	Bằng chứng & Ghi chú
/01-curriculum/TEMPLATE_MANIFEST.md	Tính nhất quán Metadata: Kiểm tra sự phù hợp của Status, Version, và Owner của runbook này với bản kê khai template.	NHẤT QUÁN	Cả TEMPLATE_MANIFEST và runbook này đều ở trạng thái IN_REVIEW, phiên bản v0.9.0. Vai trò Owner (Principal IT Business Analyst / Technical Curriculum Author) cũng đồng nhất.
/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Tuân thủ định dạng ID: Kiểm tra xem Artifact ID TMPL-OPS-RUNBOOK-001 và các ID ví dụ trong Tier 3 (ví dụ REQ-INV-001) có tuân thủ quy tắc đặt tên được hoạch định trong sổ đăng ký ID hay không.	NHẤT QUÁN	ID TMPL-OPS-RUNBOOK-001 tuân thủ cấu trúc TMPL-<AREA>-<SEQ>. Các ID yêu cầu nghiệp vụ (REQ-), quy tắc nghiệp vụ (BR-), v.v... được sử dụng trong ví dụ Nova Foods tuân thủ mẫu định danh đã hoạch định, đảm bảo không có ID "mồ côi".
/01-curriculum/CANONICAL_BUSINESS_RULES.md	Phân tách trách nhiệm định nghĩa Quy tắc: Xác minh rằng runbook này không tự định nghĩa các quy tắc nghiệp vụ cốt lõi, mà chỉ tham chiếu đến CANONICAL_BUSINESS_RULES hoặc ghi nhận các quy tắc ở mức ví dụ có nhãn xác minh.	NHẤT QUÁN	Phần Tier 3 của runbook mô tả quy trình dựa trên các quy tắc giả định cho Nova Foods, nhưng các quy tắc này không được trình bày như một nguồn chân lý mới. Runbook này hoạt động như một người tiêu thụ (consumer) quy tắc, không phải người định nghĩa (definer).
/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Phân tách trách nhiệm định nghĩa Dữ liệu: Xác minh rằng runbook không tự định nghĩa các trường dữ liệu cốt lõi (ví dụ: supplier_id, inventory_status), mà chỉ sử dụng chúng trong bối cảnh ví dụ.	NHẤT QUÁN	Các trường dữ liệu trong ví dụ Nova Foods (Mục 3) được sử dụng nhất quán với mục đích của một từ điển dữ liệu trung tâm. Runbook này không tạo ra một từ điển dữ liệu cạnh tranh.
/01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Phù hợp kiến trúc: Kiểm tra xem mục đích và cấu trúc của runbook (bao gồm các Tier và các mục kiểm tra chất lượng) có phù hợp với kiến trúc tổng thể của chương trình học và các luồng chuyển giao được định nghĩa hay không.	NHẤT QUÁN	Runbook này đóng vai trò là một công cụ kiểm soát chất lượng và vận hành, phù hợp với yêu cầu về "Handoff sang testing và delivery rõ" được nêu trong kiến trúc. Cấu trúc 4-tier của nó cũng tuân thủ mô hình template đã được định sẵn.
Downstream Consumers (Bên sử dụng đầu cuối)	Tính hữu dụng cho QA và Ops: Đánh giá xem cấu trúc của runbook, đặc biệt là các mục về ghi nhận sự cố và leo thang (escalation), có cung cấp đủ thông tin cho các vai trò QA và Vận hành (Operations) hay không.	NHẤT QUÁN	Cấu trúc của Mục 6 (mục hiện tại) cung cấp một khuôn khổ rõ ràng để ghi lại các vấn đề mở và quy tắc leo thang. Điều này đáp ứng nhu cầu của các đội ngũ tiếp nhận sau giai đoạn phân tích để xử lý các điểm chưa rõ ràng một cách có kiểm soát.

Tóm tắt: Tất cả các kiểm tra chéo với các artifact quản trị trung tâm của corpus đều cho kết quả NHẤT QUÁN. Tài liệu TMPL-OPS-RUNBOOK-001_runbook.md tại phiên bản v0.9.0 không tạo ra mâu thuẫn về mặt cấu trúc hay quản trị. Điều này xác nhận trạng thái ổn định, có kiểm soát của tài liệu, sẵn sàng cho các bước tiếp theo trong quy trình xem xét là ghi nhận các vấn đề mở và định nghĩa quy tắc chuyển giao.

Danh sách các Vấn đề Mở, Giả định và Yêu cầu Xác minh

Bảng sau đây ghi nhận mọi hạng mục chưa được giải quyết dứt điểm tại thời điểm 2026-08-07 cho tài liệu này. Việc ghi nhận này là một cơ chế kiểm soát bắt buộc để đảm bảo việc bàn giao có kiểm soát và mọi rủi ro tiềm ẩn được quản lý trước khi chuyển sang giai đoạn tiếp theo. Một hạng mục không thể được đóng lại nếu không có bằng chứng giải quyết và xác nhận từ Owner được chỉ định.

• Vấn đề Mở (Open Issue): Một mâu thuẫn, rủi ro, hoặc khiếm khuyết đã được xác định cần một giải pháp cụ thể.
• Giả định Dự án (Project Assumption): Một điều kiện được tạm thời chấp nhận là đúng khi chưa có bằng chứng xác thực, cần được kiểm chứng để tránh rủi ro cho dự án.
• Yêu cầu Xác minh (Verification Required): Một diễn giải hoặc quy tắc nghiệp vụ cần sự phê duyệt từ một vai trò có thẩm quyền chuyên môn (ví dụ: Pháp lý, Kế toán, An ninh) trước khi được coi là yêu cầu chính thức.

ID Vấn đề	Loại	Mô tả Vấn đề và Tác động	Artifact/ID bị ảnh hưởng	Owner (Chịu trách nhiệm)	Hành động Tiếp theo & Hạn chót	Trạng thái
ISSUE-RUNBOOK-001-01	Yêu cầu Xác minh	Mô hình dữ liệu trong CANONICAL_DATA_DICTIONARY chưa phân loại rõ ràng các trường dữ liệu nào là dữ liệu cá nhân nhạy cảm theo định nghĩa của Luật 91/2025/QH15. Tác động: Rủi ro pháp lý về tuân thủ bảo vệ dữ liệu cá nhân; không thể thiết kế các biện pháp kiểm soát bảo mật phù hợp.	CANONICAL_DATA_DICTIONARY TRACEABILITY_ID_REGISTRY	Legal Owner	Legal Owner phải xem xét, cung cấp ma trận phân loại dữ liệu chính thức cho các thực thể liên quan đến khách hàng và nhân viên. Hạn chót: 2026-08-21	OPEN
ISSUE-RUNBOOK-001-02	Giả định Dự án	Quy tắc nghiệp vụ BR-ACC-004 (Ghi nhận doanh thu) đang giả định doanh thu được ghi nhận tại thời điểm giao hàng cho đơn vị vận chuyển ("FOB Shipping Point"). Tác động: Rủi ro sai lệch báo cáo tài chính nếu Luật Kế toán hoặc hợp đồng mẫu của Nova Foods yêu cầu ghi nhận tại thời điểm khách hàng nhận hàng ("FOB Destination").	CANONICAL_BUSINESS_RULES	Accounting Owner	Accounting Owner phải xác nhận thời điểm ghi nhận doanh thu chuẩn áp dụng cho các luồng kinh doanh chính của Nova Foods (mô phỏng). Hạn chót: 2026-08-28	OPEN
ISSUE-RUNBOOK-001-03	Vấn đề Mở	Đặc tả API cho đối tác logistics (API-EXT-LOGISTICS-01) thiếu các yêu cầu phi chức năng về giới hạn tần suất truy cập (rate limiting) và ghi log truy vết chi tiết (audit logging) theo chuẩn OWASP API Security Top 10. Tác động: Rủi ro an ninh, hệ thống có thể bị tấn công Từ chối Dịch vụ (Denial of Service) và thiếu bằng chứng để truy vết sự cố an ninh.	API-SPEC-EXT-LOGISTICS-01 (dự kiến) NFR-CATALOG-001 (dự kiến)	Technical Architect, Security Owner	Technical Architect cập nhật đặc tả API với các yêu cầu rate limiting và audit logging. Security Owner xem xét và phê duyệt. Hạn chót: 2026-08-28	OPEN
ISSUE-RUNBOOK-001-04	Yêu cầu Xác minh	Yêu cầu truy vết lô sản phẩm REQ-TRACE-007 để thu hồi chỉ dựa trên mã lô (lot number) của thành phẩm. Quy trình chưa làm rõ cách xử lý các lô con (sub-batch) hoặc truy vết khi nguyên liệu từ nhiều nguồn được trộn lẫn. Tác động: Rủi ro thu hồi sản phẩm không triệt để, không tuân thủ Luật An toàn thực phẩm, ảnh hưởng đến an toàn người tiêu dùng và uy tín thương hiệu.	REQUIREMENTS_CATALOG CANONICAL_BUSINESS_RULES	Business Owner (Operations), QA Owner	Business Owner (Operations) phải định nghĩa mức độ chi tiết cần thiết cho việc truy vết. QA Owner xác nhận yêu cầu có thể kiểm thử được. Hạn chót: 2026-09-04	OPEN

Tài liệu này không được phép chuyển trạng thái từ IN_REVIEW sang BASELINED hoặc APPROVED cho đến khi tất cả các hạng mục trong bảng trên được đóng với trạng thái RESOLVED hoặc CLOSED. Việc đóng một hạng mục phải kèm theo bằng chứng (ví dụ: tham chiếu đến artifact đã cập nhật, email xác nhận) và được ghi nhận trong lịch sử thay đổi của Runbook này.

Quy tắc Chuyển giao, Lan truyền Thay đổi, và Ranh giới Thẩm quyền

Phần này thiết lập các quy tắc quản trị cuối cùng cho tài liệu Runbook này trong khi nó vẫn ở trạng thái IN_REVIEW (đang xem xét). Mục đích là đảm bảo một quy trình chuyển giao có kiểm soát, xử lý nhất quán các thay đổi, và bảo toàn tuyệt đối ranh giới thẩm quyền giữa các vai trò. Mọi hoạt động phải tuân thủ các quy tắc này để duy trì tính toàn vẹn của bộ tài liệu và tránh việc sử dụng sai mục đích các thông tin mô phỏng.

Chuyển giao (Handoff) là hành động chính thức bàn giao một artifact đã hoàn thành việc soạn thảo và tự kiểm tra sang cho một vai trò hoặc quy trình tiếp theo, ví dụ như để xem xét phê duyệt chính thức. Hành động này phải được ghi nhận và có bằng chứng.

1. Định nghĩa Trạng thái và Ranh giới Sử dụng

Trạng thái IN_REVIEW của tài liệu này (phiên bản v0.9.0) không phải là sự phê duyệt. Nó chỉ xác nhận rằng tài liệu đang được soạn thảo và xem xét. Bảng dưới đây định nghĩa rõ các hành động được phép và bị cấm.

Trường Quản trị	Định nghĩa và Giới hạn
Trạng thái Hiện tại	IN_REVIEW (Phiên bản v0.9.0 ngày 2026-08-07)
Diễn giải	Đây là bản nháp có kiểm soát, chưa được phê duyệt, và chưa được thiết lập làm đường cơ sở (baseline). Một baseline là một phiên bản của artifact đã được thống nhất chính thức, dùng làm điểm tham chiếu cho các công việc sau này. Tài liệu này chưa đạt đến trạng thái đó.
Hành động Bị cấm	Sử dụng nội dung để thực hiện các thao tác vận hành thực tế trên hệ thống ERP. Trình bày tài liệu này với các bên liên quan như một yêu cầu nghiệp vụ, quy trình, hoặc quyết định đã được Nova Foods phê duyệt. Bỏ qua các vai trò có thẩm quyền (vd: Legal, Accounting, Security, Business Owner) bằng cách trích dẫn nội dung từ tài liệu này. Thay đổi trạng thái từ IN_REVIEW sang APPROVED hoặc BASELINED mà không thông qua quy trình phê duyệt chính thức được ghi nhận trong metadata của phiên bản sau.
Hành động Được phép	Sử dụng cho mục đích học tập và mô phỏng trong phạm vi của chương trình đào tạo IT BUSINESS ANALYST — ZERO TO DELIVERY READY. Đối chiếu chéo với các artifact nguồn như /01-curriculum/CANONICAL_BUSINESS_RULES.md và /01-curriculum/CANONICAL_DATA_DICTIONARY.md để tìm mâu thuẫn. Ghi nhận các vấn đề tìm thấy vào mục "Vấn đề Mở" (Open Issues) của tài liệu này. Đề xuất thay đổi hoặc làm rõ thông qua kênh giao tiếp chính thức (ví dụ: bình luận trên hệ thống quản lý phiên bản).

2. Quy trình Lan truyền Thay đổi (Change Propagation)

Bất kỳ thay đổi nào đối với các quy tắc, dữ liệu, hoặc quy trình nguồn đều có thể ảnh hưởng đến nội dung của Runbook này. Lan truyền thay đổi (Change Propagation) là quy trình đảm bảo một thay đổi được áp dụng một cách nhất quán và có truy vết trên tất cả các artifact bị ảnh hưởng.

Bước	Mô tả Hành động	Vai trò Chịu trách nhiệm	Artifacts Liên quan (Ví dụ)
1. Phát hiện	Một thay đổi cần thiết được xác định. Ví dụ: quy tắc nghiệp vụ BR-ORD-011 trong catalog nguồn được cập nhật.	Bất kỳ người xem xét nào.	/01-curriculum/CANONICAL_BUSINESS_RULES.md
2. Ghi nhận	Yêu cầu thay đổi được tạo ra chính thức, mô tả rõ lý do, nguồn gốc, và tác động dự kiến.	Người phát hiện.	Một mục mới trong phần "Vấn đề Mở", hoặc một bình luận được gán cho Owner.
3. Phân tích Tác động	Owner phân tích để xác định tất cả các artifact bị ảnh hưởng bởi thay đổi.	Owner (Principal IT Business Analyst / Technical Curriculum Author).	TMPL-OPS-RUNBOOK-001_runbook.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md
4. Thực thi	Owner thực hiện các cập nhật cần thiết trên tất cả các artifact bị ảnh hưởng.	Owner (Principal IT Business Analyst / Technical Curriculum Author).	Cập nhật nội dung trong các tệp Markdown liên quan.
5. Xác minh	Các thay đổi được xem xét lại để đảm bảo tính nhất quán và tuân thủ các quy tắc quản trị.	Owner và/hoặc một người xem xét được chỉ định.	So sánh các phiên bản trước và sau của các tệp đã thay đổi.
6. Đóng	Yêu cầu thay đổi được đánh dấu là hoàn tất. Lịch sử phiên bản của các artifact được cập nhật.	Owner (Principal IT Business Analyst / Technical Curriculum Author).	Lịch sử commit trên hệ thống quản lý phiên bản.

3. Điều kiện Chuyển giao để Phê duyệt

Tài liệu này chỉ có thể được chuyển giao (handoff) cho quy trình phê duyệt chính thức khi tất cả các điều kiện sau được thỏa mãn: 1. Tất cả các mục trong phần "Kiểm tra Chéo" (Cross-File Checks) đã được thực hiện và có kết quả "Đạt". 2. Không còn "Vấn đề Mở" (Open Issues) nào có trạng thái khác "Đã đóng" hoặc "Đã giải quyết". 3. Tất cả các mục trong bảng "Bằng chứng và Truy vết" (Evidence and Traceability) đều có tham chiếu hợp lệ. 4. Owner đã thực hiện một lần rà soát cuối cùng để đảm bảo tính nhất quán về định dạng, mã định danh và metadata quản trị.

Việc chuyển giao là một đề xuất, không phải là sự phê duyệt. Việc phê duyệt để thiết lập baseline v1.0.0 là một hành động riêng biệt, phải được thực hiện bởi vai trò có thẩm quyền và được ghi nhận rõ ràng trong metadata của phiên bản đó. Owner của tài liệu này có trách nhiệm điều phối và chuẩn bị gói chuyển giao, không có quyền tự phê duyệt nội dung.