Vận hành SSA: tìm đúng luồng xử lý

Runbook đề xuất, chưa được diễn tập trên hệ thống SSA. Chỉ áp dụng khi các chức năng tương ứng đã được triển khai, kiểm thử và bàn giao. Kế hoạch chuẩn nằm trong PLAN.md; không xem các bước dưới đây là bằng chứng hệ thống đã có sẵn công cụ hoặc đã an toàn.

Công cụ làm việc: nhân sự dùng Web Admin; phụ huynh dùng Zalo Mini App. Tính năng Web Admin và trách nhiệm nêu phần UI cần xây. Runbook này mô tả quy trình, không phải dashboard đã triển khai.

Bắt đầu từ dấu hiệu

Dấu hiệu	Mở hướng xử lý	Người nhận chính
Số buổi sai, file trễ, dữ liệu không đổi	Số liệu và nguồn	SSA vận hành + người duyệt
Job đồng bộ lỗi hoặc chờ lâu	Import và Airflow	Kỹ thuật; SSA xử lý nguồn/approval
Xem nhầm trẻ, PDF còn mở sau gỡ quyền	Quyền truy cập	Kỹ thuật + phụ trách dữ liệu SSA
Yêu cầu đã lưu nhưng email không tới	Giao dịch và gửi tin	Kỹ thuật; Sale/chăm sóc đối soát
Tiền bị trừ nhưng đơn pending, callback trùng	Thanh toán và hoàn tiền	Tài chính + kỹ thuật
Tiền về thiếu/thừa, không khớp báo cáo cổng	Đối soát nguồn thu	Kế toán + người duyệt
API ngừng, triển khai lỗi, mất dữ liệu	Khôi phục	Người trực kỹ thuật + SSA
Phụ huynh rút quyền hoặc yêu cầu xóa	Quyền dữ liệu	Phụ trách dữ liệu SSA
Sắp phát hành hoặc chuyển nguồn	Phát hành	Release owner + SSA

Ghi tên và kênh liên hệ của từng owner khi kickoff; vai trò trong bảng chưa thay danh sách người trực. Thời gian phản hồi, lịch trực và mức ưu tiên phải được ký trong phạm vi hỗ trợ. Ngưỡng và phân cấp đề xuất

Ghi bằng chứng trước khi sửa

Audit và truy vết

Từ số sai trên màn hình tìm lại nguồn thế nào? Mở sơ đồ tương tác

Một hồ sơ xử lý cần trả lời: ai bị ảnh hưởng, phạm vi nào, nguồn nào, ai quyết định và làm sao biết đã đúng?

Request: mã hỗ trợ/request ID, thời điểm, hành động và môi trường.
Dữ liệu: dataset/sân/lớp, source date, hash file, mapping version, batch/row và generation.
Tác vụ: DAG run/task hoặc event/delivery/provider ID, lần thử và trạng thái cuối.
Quyết định: người xử lý, người duyệt, lý do, thay đổi và kết quả đối soát.

Chỉ thu dữ liệu tối thiểu vào hồ sơ có quyền truy cập. Không dán token, secret, file Excel trẻ em hoặc câu trả lời khảo sát vào log/chat chung. Không coi HTTP 200 hay job xanh là bằng chứng số liệu đúng.

Số liệu sai hoặc nguồn trễ

Ưu tiên giữ bản dữ liệu đã biết đúng; dừng tin tự động dựa trên nguồn nghi sai. “8 buổi thành 2” là tình huống cần kiểm thử, chưa phải sự cố đã xác nhận.

Duyệt và publish MISA

Khi nào file mới được phép xuất hiện trên màn hình? Mở sơ đồ tương tác

Owner: SSA vận hành tìm nguồn; người duyệt xác nhận nghiệp vụ; kỹ thuật xử lý cơ chế import/publish.

Xác định phạm vi: mã trẻ nội bộ, sân/lớp, trường sai, thời điểm và request ID. Phân biệt sourceAsOf với importedAt: chạy lại file cũ không làm nguồn mới hơn.
Truy nguyên: từ generation đang đọc về batch, dòng Excel, mapping và diff. So số dòng nguồn = số chấp nhận + số từ chối; kiểm tra full snapshot hay delta.
Cô lập: giữ snapshot đang active nếu batch chưa publish; ngừng campaign liên quan nếu đã phát hiện sai. Không chữa bằng sửa trực tiếp để mất nguồn gốc.
Sửa có duyệt: chỉnh nguồn/mapping theo quy trình, đối soát lại rồi duyệt batch. Nếu đã publish sai, chuyển về generation đúng bằng cơ chế rollback có audit và correction.
Xác nhận: đối chiếu từng trường bị ảnh hưởng, phạm vi sân khác, lịch sử ngày trước và source date; người duyệt ký kết quả. Tin đã gửi sai cần xác định người nhận và correction được SSA duyệt.

Không đảo ngược đơn, consent, quan hệ giám hộ hoặc khảo sát khi rollback dữ liệu MISA. Quy tắc nguồn và hợp nhất / Rollback theo loại sự cố

Import hoặc Airflow dừng giữa chừng

Tiếp tục cùng batch; không tạo đợt mới chỉ để làm trạng thái xanh. Airflow điều phối, backend giữ quyền validation và publish.

Airflow và lineage

Lịch đồng bộ nối tới generation ra sao? Mở sơ đồ tương tác

Owner: kỹ thuật xử lý task/lease/connector; SSA cung cấp file đúng và approval.

Trạng thái cần phân biệt	Cách xử lý dự kiến	Bằng chứng kết thúc
Chưa có file	SSA kiểm tra lịch xuất và kênh nhận; giữ source freshness đúng thực tế	File đúng ngày/scope, hash và source date
Quarantine/validation lỗi	Sửa nguồn hoặc mapping đã duyệt; không bỏ qua hard error	Counts cân, không hard error, diff được giải thích
Chờ approval	Người có quyền SSA xem đối soát rồi duyệt	Approval reference hợp lệ; service principal không tự duyệt
Worker/sensor timeout	Tra batch/checkpoint và trạng thái publish trước khi retry cùng key	Một batch hợp lệ; resume không trùng dòng
Generation đã thay đổi	Hợp nhất và đối soát lại trên base mới trước publish	CAS đúng; không mất dữ liệu của batch vừa công bố
Scheduler cần restore	Dùng bản sao metadata/config đúng môi trường; kiểm soát catchup/backfill	Không publish/gửi tin trùng; run ID nối được với batch

Chạy thử T04/T16 với file trùng, crash giữa chunks, concurrent scope và backfill. Log/XCom chỉ chứa reference/hash/ID. Thiết kế Airflow và proxy

Nghi truy cập sai quyền

Xem được dữ liệu sau revoke là dấu hiệu cần cô lập ngay theo quy trình sự cố. Không đổi thành lỗi UI để tiếp tục phục vụ.

Xác thực và quyền trẻ

Điều gì cho phép một phụ huynh xem một trẻ? Mở sơ đồ tương tác

Owner: người trực kỹ thuật cùng phụ trách dữ liệu SSA. SSA quyết định phạm vi thông báo sau khi xác minh.

Thu bằng chứng tối thiểu: actor nội bộ, resource ID, thời điểm, request ID, role và phiên bản quyền; không sao chép toàn bộ hồ sơ trẻ vào ticket chung.
Cô lập: thu hồi phiên/quyền bị tác động hoặc ngừng endpoint trong phạm vi cần thiết; giữ evidence và báo SSA. Không bypass auth để “khôi phục nhanh”.
Truy nguyên: kiểm quan hệ guardian-student hiện hành, session, quyền file/deeplink, cache và request đi tắt origin. SĐT khớp không thay bằng chứng giám hộ.
Sửa và xác minh: thử đổi child/report/order ID, link đã revoked và tài khoản thường; không tài nguyên ngoài scope nào được trả về. Kiểm chứng lại origin từ chối request bỏ qua proxy.
Mở lại có kiểm soát: lưu bản sửa, kết quả T01-T03/T08/T15, người duyệt và phạm vi ảnh hưởng đã xác định; tiếp tục theo dõi.

Không phục hồi link đã thu hồi bằng import contact. Ma trận quyền / Threat model

Yêu cầu đã lưu nhưng tin chưa đến

Một email lỗi không làm mất đơn hoặc tạo lý do ghi đơn mới. Trạng thái được nhà cung cấp nhận, giao tin và đọc trong app là ba việc khác nhau.

Outbox và gửi tin

Gửi thất bại hoặc mơ hồ được xử lý thế nào? Mở sơ đồ tương tác

Owner: kỹ thuật theo event/delivery; Sale hoặc chăm sóc xử lý công việc còn tồn trong admin.

Tra kết quả ghi: dùng order/consultation/submission ID hoặc idempotency key. Timeout có thể xảy ra sau commit; tra trạng thái trước khi gửi lại.
Theo đường gửi: từ outbox đã commit đến queue, attempt, provider ID và trạng thái. Phân biệt chưa đến giờ, bị hủy, hết quyền, quota/template lỗi và timeout.
Xử lý đúng loại: lỗi tạm thời retry theo policy; lỗi quyền/template/recipient phải sửa nguyên nhân; DLQ cần owner. Trước gửi lại kiểm consent, quyền hiện hành, nguồn và trạng thái cancelled.
Kết quả không rõ: nhà cung cấp có thể đã nhận trước timeout. Tra trạng thái/idempotency của provider nếu có; nếu không, chuyển người xử lý thay vì hứa không gửi trùng.
Đóng hồ sơ: chứng minh giao dịch vẫn tồn tại đúng một lần, công việc có người nhận, kết quả gửi hoặc trạng thái chưa rõ được ghi trung thực.

Atomic write và outbox / OA, ZBS và webhook

Hệ thống ngừng hoặc cần khôi phục

Chọn cách phục hồi theo thứ hỏng; không quay toàn bộ database về quá khứ cho mọi lỗi.

Phục hồi và đối soát

Khôi phục mà không mất giao dịch mới thế nào? Mở sơ đồ tương tác

Owner: người trực kỹ thuật; SSA chứng kiến đối soát dữ liệu và ký mở lại.

Phạm vi hỏng	Hành động đề xuất	Điều phải bảo vệ
VPS ingress	Kiểm health/TLS/cấu hình; dùng standby hoặc quy trình restore đã được chốt	Origin vẫn chặn bypass; không tự retry POST chưa tra kết quả
UI/Worker regression	Tắt tính năng theo cơ chế đã có hoặc redeploy artifact/config trước còn tương thích	Mini App live vẫn dùng được API; schema không bị đảo tùy tiện
Import sai	Chuyển active generation đúng, audit và correction	Orders/links/consent/survey mới
Migration sai	Freeze writes theo runbook, giữ bookmark/backup, ưu tiên forward fix	Không mất giao dịch phát sinh sau migration
DB corruption/xóa lớn	Restore biệt lập từ bản sao đủ điều kiện; đối soát rồi mới chuyển phục vụ	Replay deletion/revocation ledger; kiểm file references và side effects đã gửi

Bộ xác nhận trước mở lại: counts/checksums, mẫu nghiệp vụ từng sân, private PDF đúng quyền, phiên đã revoke vẫn bị chặn, đơn mới được reconcile, gửi tin không bị chạy lại vô điều kiện. Đo RPO/RTO trong lần thử; mục tiêu trong PLAN là đề xuất, không phải số đã đạt.

Không có standby đã kiểm chứng thì ghi rõ rủi ro một VPS. Backup cùng tài khoản không thay bản sao độc lập tách quyền. Kế hoạch sao lưu và chuyển đổi

Rút quyền và yêu cầu xóa

Thu hồi quyền bị tác động và xử lý đúng phạm vi chủ thể. Xóa tài khoản phụ huynh không mặc nhiên xóa hồ sơ trẻ mà người khác còn quyền hợp lệ.

Thu hồi và xóa dữ liệu

Yêu cầu dữ liệu đi qua những nơi nào? Mở sơ đồ tương tác

Owner: phụ trách dữ liệu SSA duyệt nghĩa vụ và phạm vi; kỹ thuật thực hiện và lưu bằng chứng tối thiểu.

Xác minh phiên/người yêu cầu và loại yêu cầu; tạo mã theo dõi, thời hạn và audit.
Thu hồi quyền/consent bị tác động; chặn sends không còn căn cứ; không yêu cầu gửi lại toàn bộ PII qua email.
Lập phạm vi DB, file, logs, queue, exports, backup và bên xử lý; tách phần phải giữ có căn cứ với phần phải xóa.
Thực hiện theo policy đã duyệt; ghi deletion ledger và hạn truy cập/expiry backup. Khi restore, áp lại ledger trước mở phục vụ.
Kiểm tra không hồi sinh quyền/dữ liệu; thông báo kết quả và phần giữ lại có lý do cho chủ thể.

Ngừng dịch vụ cần runbook riêng về hoàn trả/xóa, ngoại lệ và bằng chứng nhà cung cấp. Không coi tombstone là bằng chứng đã xóa không thể phục hồi trong mọi bản sao. Phạm vi và điều kiện dữ liệu

Phát hành và bàn giao

Backend chạy được chưa đồng nghĩa Mini App đã live.

CI và phát hành Zalo

Bằng chứng nào cho phép phát hành? Mở sơ đồ tương tác

Owner: release owner phối hợp SSA, QA và người phụ trách dữ liệu.

Trước dữ liệu thật: đóng G0/G1/G4 theo phạm vi; xác nhận môi trường, chủ tài khoản và credentials đúng nơi.
Trước deploy: lưu artifact/config/schema version, backup/bookmark, kết quả tương thích; có phương án quay lui phù hợp từng lớp.
Trước mở người dùng: Zalo xét duyệt và Publish, quyền chạy với tài khoản thường, thiết bị iOS/Android, domain và OA entry được kiểm tra.
Trước ký nghiệm thu: source counts được SSA ký; T01-T21 có evidence; restore được đo; người trực nhận runbook và biết kênh báo lỗi.
Sau mở: theo dõi cohort, source freshness, đơn/lead, DAG, DLQ và backup; lưu incident/correction, bàn giao source/tài khoản và chi phí hỗ trợ.

Không dùng demo endpoints, tài khoản dùng chung hoặc bỏ kiểm quyền để reviewer truy cập. Checklist phát hành / Bộ hồ sơ bàn giao

Điều kiện để dùng runbook này

Các điều sau còn là đầu việc triển khai: tên người trực, quyền thực hiện từng action, công cụ/query được duyệt, môi trường rehearsal, fixture ẩn danh, các bước rollback thật và bằng chứng người thứ hai kiểm tra. Không bổ sung lệnh production giả khi repo chưa có ứng dụng.

Bằng chứng cần thu	Người xác nhận	Tham chiếu
Import retry/publish/rollback không mất lịch sử	SSA vận hành + kỹ thuật	T04, T09, T16
Thu hồi và resource authorization đúng	QA + phụ trách dữ liệu	T01-T03, T08, T15
Gửi lại và lỗi provider được kiểm soát	Kỹ thuật + người xử lý nghiệp vụ	T05-T07
Notification, Checkout, tồn, hoàn và đối soát nguồn thu	QA + nghiệp vụ + tài chính	T17-T21
Restore, RPO/RTO và mở lại có đối soát	Kỹ thuật + SSA chứng kiến	T12
Release đúng môi trường, tài khoản thường hoạt động	Release owner + SSA	T10, T13, T14

Đọc tiêu chí kiểm thử / Quyết định còn mở / Thư viện sơ đồ

Thanh toán và hoàn tiền

Hủy đơn và hoàn tiền

Ai yêu cầu, ai duyệt và khi nào xác nhận đã hoàn? Mở sơ đồ tương tác

Runbook cho module mới, chưa có công cụ production. Phạm vi và trạng thái. Không coi ảnh chuyển khoản hoặc client SDK callback là kết luận paid.

Tra order/attempt/provider transaction/merchant và số tiền; nếu pending/unknown, truy vấn nhà cung cấp trước khi cho thu lại. Ghi thời điểm và evidence; giữ nguyên trạng thái chưa rõ.
Webhook giả, sai merchant/số tiền hoặc replay không được đổi trạng thái tiền. Sự kiện hợp lệ đến trễ phải xử lý idempotent; nếu hàng đã hết thời gian giữ, mở ngoại lệ fulfillment/hoàn.
Thu trùng hoặc hủy đơn sau thu: người tài chính lập đề nghị hoàn, người khác duyệt, backend gửi với idempotency key; xác nhận từ provider rồi mới đánh dấu refunded. Thu thủ công nếu được phép cũng cần chứng từ và duyệt.
Thông báo gửi thất bại: retry delivery theo policy, không tạo lại đơn/thu tiền/hoàn tiền. Inbox và trạng thái tiền vẫn lấy từ dữ liệu nghiệp vụ.
Đóng hồ sơ khi payment/refund, đơn và khoản đối soát có liên kết; ghi actor, reason, số tiền, kết quả và phần chưa rõ. Không xóa giao dịch để làm khớp số.

Đối soát nguồn thu

Tiền thu, phí, hoàn và khoản thực nhận khớp thế nào? Mở sơ đồ tương tác

Owner: kế toán/tài chính lập, người kiểm soát duyệt; kỹ thuật hỗ trợ truy vết. AD-14 khác AD-04 đối soát dữ liệu MISA học viên.

Kiểm tra	Bằng chứng và cách xử lý
Nguồn thu	Kênh/phương thức, merchant, tài khoản nhận đã che, order → transaction → settlement/sao kê
Matching	Khớp ID/reference và amount/currency; nhập lại file không sinh dòng thứ hai; khoản chưa rõ vào unmatched
Thiếu/thừa/trùng	Tạo reconciliation case với owner; kiểm phí, hoàn, chuyển kỳ hoặc thu ngoài cổng; không tự sửa giá đơn
Tiền ròng	Gross trừ refund/fee cộng trừ adjustment hợp lệ bằng net nhận theo kỳ; mọi khoản chuyển kỳ được theo dõi
Duyệt và khóa kỳ	Người lập khác người duyệt; lưu evidence/report hash, rule version, before/after; mở lại có lý do và audit

Bộ nghiệm thu T21 cần cả sai lệch cố ý và dữ liệu khớp, chứng minh truy tới từng đơn/nguồn tiền. Báo cáo “đã thanh toán” không thay báo cáo “đã về tài khoản”. Quy trình này không tự bao gồm AML, hóa đơn điện tử hay hạch toán MISA API.