Mục đích
Di động, web, chi nhánh, kiosk và xác minh có hỗ trợ theo kiến trúc tích hợp.
NỀN TẢNG · CHECKID
Mô hình triển khai
Di động, web, chi nhánh, kiosk và xác minh có hỗ trợ theo kiến trúc tích hợp.
NGHIỆP VỤĐầu vào → Xử lý → Đầu ra
KIỂM SOÁTChính sách · rủi ro · tiêu chuẩn
BẰNG CHỨNGKết quả · truy vết · phạm vi
NỀN TẢNG
Mô hình triển khai
Di động, web, chi nhánh, kiosk và xác minh có hỗ trợ theo kiến trúc tích hợp.
Ranh giới tin cậy
Năng lực chỉ được công bố trong phạm vi có nguồn/bằng chứng.
Tích hợp cho nhà phát triển
SDK · REST API · bằng chứng đặc tả
↗THAM CHIẾU KỸ THUẬT
Triển khai & NFR: công bố theo mô hình được hỗ trợ, không theo khẩu hiệu
Mô hình triển khai → trách nhiệm → NFR → bằng chứng → giá trị theo hợp đồng
Mô hình triển khai
Nội dung hiện hành phân biệt SaaS, private cloud và triển khai tại chỗ như các mô hình cần được xác nhận theo offering/đặc tả. Việc website nhắc một mô hình không đồng nghĩa mọi khách hàng đều được hỗ trợ mô hình đó.
Lớp nền tảng
Kubernetes/OpenShift, multi-zone, multi-site, HSM, external cơ sở dữ liệu/đối tượng store hoặc khả năng quan sát stack chỉ được nêu như đã triển khai khi kiến trúc triển khai xác nhận. Không suy luận kiến trúc từ công nghệ quen thuộc.
Tính sẵn sàng & DR
Tính sẵn sàng, RTO, RPO và sao lưu chính sách là đặc tả/NFR giá trị. Khi nguồn không cung cấp con số công khai, website dùng `Xác lập theo hợp đồng` thay vì gắn SLA giả.
Quy mô & năng lực xử lý
API thông lượng, thông lượng sinh trắc học, xử lý đồng thời và kích thước gallery phải gắn cấu hình kiểm thử. Không lấy nhà cung cấp benchmark hoặc laboratory kết quả ngoài phạm vi làm năng lực xử lý của CheckID.
Vận hành
Một triển khai guide CTO-grade phải xác định giám sát/ghi nhật ký/tracing, bảo trì window, upgrade/backward khả năng tương thích, chứng chỉ/key vòng đời và phụ thuộc health ở mức được phép công bố.
Trách nhiệm ranh giới
Mobile-ID, khách hàng và nhà cung cấp bên thứ ba có trách nhiệm khác nhau với mạng, điểm kết nối, thông tin xác thực, dữ liệu, nguồn có thẩm quyền, sao lưu/DR và giám sát. Ma trận trách nhiệm phải theo triển khai cụ thể, không dùng một mẫu cho mọi mô hình.
TRIỂN KHAI · NFR · VẬN HÀNH
Công khai kiến trúc và đặc tả NFR là hai lớp khác nhau
CTO cần biết thông số được xác lập ở đâu ngay cả khi không công khai. Website không tạo số HA/DR/RTO/RPO/TPS.
| Tiêu chí | Công khai công bố | Ranh giới đặc tả/thẩm định |
|---|---|---|
| Mô hình triển khai | Chỉ mô hình có sản phẩm/triển khai nguồn | Kiến trúc/sizing cần đã phê duyệt kiến trúc |
| HA / DR | Không tạo kiến trúc giả | Cần triển khai đã phê duyệt/NFR nguồn |
| RTO / RPO / tính sẵn sàng | Không công bố số khi thiếu nguồn | Thuộc SLA/NFR nếu được cung cấp |
| Năng lực xử lý / quy mô | Không suy từ tiếp thị/lab khác | Benchmark phải có đầy đủ bối cảnh kiểm thử |
| Khả năng quan sát | Phân biệt vận hành/an ninh/kiểm toán signals | Chỉ số/nhật ký/tracing cần SRE nguồn |
Trách nhiệm
Mạng, điểm kết nối, ứng dụng khách hàng, dịch vụ CheckID, nguồn dữ liệu có thẩm quyền và hệ thống hạ nguồn có trách nhiệm khác nhau; ma trận phải theo mô hình triển khai thực tế.
Phụ thuộc bên ngoài
Thẩm quyền/gián đoạn bên thứ ba là lỗi phụ thuộc, không tự là không khớp danh tính. Cơ chế thử lại/phương án dự phòng chỉ được mô tả khi đặc tả có.
Đưa vào vận hành chính thức
Tiêu chí cho môi trường vận hành thực tế gồm thông tin xác thực, mạng, điểm kết nối, hành vi xử lý bất đồng bộ, giám sát, kiểm thử lỗi, dự phóng lưu lượng tải, hỗ trợ và nghiệm thu.
Mức độ công bố
NFR có thể công khai, theo hợp đồng hoặc NDA; trạng thái công bố nội bộ không được để lộ ra trang công khai.