Dùng checklist bàn giao này để đóng gói môi trường, secret, giám sát, backup và runbook, giúp ops có thể triển khai và chịu trách nhiệm vận hành ứng dụng khi tự-host.
Bàn giao sẵn sàng cho sản xuất nghĩa là ops có thể vận hành ứng dụng mà không phải đoán mò. Họ có thể triển khai một phiên bản đã biết, xác nhận nó khỏe mạnh, phản ứng với cảnh báo và khôi phục sau một release lỗi hoặc sự cố. Nếu bất kỳ phần nào trong đó phụ thuộc vào trí nhớ của một developer duy nhất, thì bàn giao chưa hoàn thành.
Hãy coi bàn giao như một gói tài liệu trả lời một câu hỏi: nếu những người xây dựng biến mất một tuần, ops có thể vẫn giữ hệ thống an toàn và sẵn sàng không?
Một gói tốt thường bao gồm mô tả ứng dụng làm gì, thế nào là “khỏe”, quy trình release (deploy, xác minh, rollback), nơi lưu cấu hình, cách xử lý secret, và cách giám sát, backup, và phản ứng với sự cố.
Quan trọng không kém là những gì nó không bao phủ. Bàn giao không phải là lời hứa sẽ thêm tính năng, refactor, thiết kế lại giao diện hay “dọn dẹp sau này.” Những việc đó là dự án riêng với phạm vi riêng.
Trước khi gọi là hoàn tất, hãy thống nhất về quyền sở hữu và thời hạn phản hồi. Ví dụ: ops chịu trách nhiệm uptime và deploy; đội product chịu roadmap; đội dev cung cấp một khoảng thời gian hỗ trợ sau bàn giao để sửa lỗi và trả lời câu hỏi.
Ops chỉ có thể sở hữu những gì họ nhìn thấy. Một inventory một trang đơn giản tránh việc suy đoán khi deploy, xử lý sự cố và kiểm toán. Giữ bằng tiếng thường, cụ thể.
Liệt kê mọi phần đang chạy và vị trí của chúng: backend API, web app, worker nền, job theo lịch, và cách mobile kết nối. Ngay cả khi iOS/Android được phân phối qua store, chúng vẫn phụ thuộc vào cùng backend.
Bao gồm các dịch vụ bên ngoài mà ứng dụng không thể chạy thiếu. Nếu bạn dùng PostgreSQL, một queue, object storage hoặc API bên thứ ba (thanh toán như Stripe, nhắn tin, email/SMS, Telegram), ghi rõ tên dịch vụ và mục đích sử dụng.
Ghi lại yêu cầu mạng để việc hosting không trở thành thử sai: các domain cần thiết (app, api, admin), cổng và giao thức, ai gia hạn TLS, nơi quản lý DNS, và bất kỳ danh sách cho phép inbound/outbound nào.
Cuối cùng, ghi lại tải mong đợi bằng số thực: requests/ phút đỉnh, người dùng hoạt động, kích thước payload điển hình, kích thước database hiện tại và tăng trưởng dự kiến. Ngay cả khoảng ước lượng cũng giúp ops đặt giới hạn và cảnh báo.
Nếu bạn phát triển với AppMaster, inventory backend sinh, web app và các tích hợp để ops biết phần nào phải triển khai cùng nhau.
Cấu hình là phần thường khiến triển khai production thất bại: config chỉ nằm trong đầu ai đó. Hãy coi cấu hình như một sản phẩm bàn giao. Ops cần thấy các thiết lập tồn tại, khác nhau theo môi trường ra sao và cách thay đổi an toàn.
Bắt đầu bằng cách đặt tên mọi môi trường đang có hôm nay, kể cả tạm thời. Hầu hết đội có dev, staging và production, và có thể các bản sao như “production-eu” hoặc “staging-us.” Ghi môi trường dùng để test release, chạy migration dữ liệu và diễn tập sự cố.
Cung cấp một tham chiếu cấu hình duy nhất liệt kê tên biến và giá trị ví dụ an toàn (không bao giờ dùng credential thật). Để placeholder dễ thấy.
Gói bàn giao của bạn nên bao gồm:
Thêm quy trình thay đổi đơn giản. Ví dụ: yêu cầu qua ticket, review bởi owner service, áp dụng ở staging trước, rồi promote lên production trong cửa sổ đã định với kế hoạch rollback nếu tỷ lệ lỗi tăng.
Nếu bạn export và tự-host một app từ AppMaster, giữ nguyên quy tắc: gửi kèm một bộ khóa config sạch, có tài liệu cùng mã nguồn sinh ra để ops chạy nhất quán trên các môi trường.
Secret là con đường nhanh nhất để một bàn giao gọn gàng trở thành sự cố bảo mật. Mục tiêu đơn giản: ops phải biết mọi secret ứng dụng cần, nơi lưu, ai được đọc và cách thay đổi mà không gây downtime.
Bắt đầu bằng một danh sách secret ngắn để ops có thể quét trong một phút. Với mỗi mục, ghi nó mở khóa gì (database, SMTP, Stripe, JWT signing key), nơi lưu (vault, cloud secret store, Kubernetes Secret, file mã hóa), và ai chịu trách nhiệm xoay vòng.
Viết bước xoay vòng như công thức, không phải chính sách. Bao gồm thứ tự chính xác, thời gian cần giữ secret cũ hợp lệ và một kiểm tra duy nhất chứng minh việc xoay thành công.
Dùng mẫu này cho mỗi secret:
Rõ ràng về mong đợi mã hóa. Secret nên được mã hóa khi lưu trong kho và bảo vệ khi truyền (TLS) giữa app và phụ thuộc. Tuyệt đối không đặt secret trong source control, artifact build hay tài liệu chia sẻ.
Định nghĩa quyền truy cập khẩn cấp (break-glass). Nếu sự cố chặn truy cập bình thường, nêu rõ ai có quyền phê duyệt truy cập khẩn cấp, thời hạn truy cập và những gì phải được audit sau đó.
Ops chỉ có thể sở hữu thứ họ có thể tái tạo. Một gói triển khai tốt làm cho ba câu hỏi trở nên dễ trả lời: chính xác chúng ta đang chạy cái gì, làm sao để triển khai lại, và làm sao quay trở lại nhanh nếu có sự cố?
Bao gồm “danh mục thành phần” rõ ràng cho build. Ghi loại artifact và cách xác thực nó, không chỉ nơi lưu:
Thêm một ví dụ nhỏ, cụ thể. Ví dụ: “Deploy v1.8.2 bằng cách cập nhật image tag, chạy migration, rồi restart web worker. Nếu health check thất bại trong 10 phút, revert về v1.8.1 và dừng job migration.”
Kế hoạch rollback nên đọc như hướng dẫn có thể làm theo lúc 2 giờ sáng. Nó nên nêu:
Nếu app được xây dựng với AppMaster và export dưới dạng source để tự-host, bao gồm phiên bản mã sinh, hướng dẫn build và mong đợi runtime để ops có thể rebuild cùng một release sau này.
Bàn giao chưa hoàn tất cho tới khi ops nhìn thấy ứng dụng đang làm gì và được cảnh báo trước khi người dùng phàn nàn.
Thống nhất các logs cần có và nơi chúng đến (file, syslog, nền tảng log). Đảm bảo logs đồng bộ thời gian và có request hoặc correlation ID để truy vết sự cố end-to-end.
Thông thường bạn cần log ứng dụng (sự kiện chính và lỗi), log lỗi (stack trace và job thất bại), access log (request và status code), audit log (hành động admin và export) và log hạ tầng (restart, áp lực node, lỗi ổ đĩa).
Tiếp theo, định nghĩa một tập nhỏ metric phản ánh tác động người dùng và sức khỏe hệ thống. Nếu chỉ chọn năm: độ trễ (p95/p99), tỷ lệ lỗi, độ bão hòa (CPU/ram/disk), độ sâu hàng đợi và kiểm tra availability từ ngoài mạng.
Quy tắc cảnh báo nên rõ ràng: điều gì kích hoạt, mức độ (page vs ticket), ai trực, và khi nào phải leo thang. Thêm snapshot dashboard “đã biết tốt” và ghi chú ngắn mô tả bình thường trông như thế nào (phạm vi độ trễ điển hình, tỷ lệ lỗi mong đợi, độ sâu hàng đợi thường thấy). Ngữ cảnh đó giảm cảnh báo ồn ào và giúp người phản ứng mới hành động nhanh.
Backup không phải là thứ bạn “có.” Đó là thứ bạn có thể restore khi cần, theo yêu cầu.
Ghi rõ phạm vi: database, lưu trữ file (uploads, báo cáo, hoá đơn) và những phần hay quên như config không nằm trong code và khóa mã hóa cần để đọc dữ liệu được bảo vệ.
Giữ mục tiêu bằng thuật ngữ đơn giản. RPO là bao nhiêu dữ liệu bạn có thể mất (ví dụ 15 phút). RTO là bao lâu bạn có thể bị downtime (ví dụ 1 giờ). Chọn con số doanh nghiệp đồng ý, vì chúng ảnh hưởng chi phí và nỗ lực.
Bao gồm:
Nếu bạn export và tự-host một app từ AppMaster, bao gồm bước restore PostgreSQL và bất kỳ bucket lưu trữ ngoài nào cùng các khóa dùng cho trường mã hóa.
Lên lịch diễn tập restore. Ghi lại thời gian, những gì hỏng và bạn đã thay đổi gì để lần sau restore nhanh hơn và ít căng thẳng hơn.
Bàn giao chưa thực sự hữu dụng cho đến khi ai đó có thể bị page lúc 2 giờ sáng và sửa sự cố mà không phải đoán mò. Runbook biến kiến thức truyền miệng thành các bước mà người trực có thể làm theo.
Bắt đầu với các sự cố bạn dự kiến xảy ra trước: toàn bộ dịch vụ sập, request chậm, và deploy làm hỏng chức năng. Giữ mỗi runbook ngắn. Đặt các kiểm tra nhanh nhất lên đầu để người ứng cứu có tín hiệu trong vài phút.
Giữ cấu trúc nhất quán để dễ đọc khi căng thẳng:
Nếu app được export hoặc tự-host từ AppMaster, bao gồm nơi các service sinh ra chạy, cách restart an toàn và giá trị config mong đợi theo môi trường.
Giữ một checklist hậu sự cố ngắn. Ghi lại timeline, thay đổi gần nhất, thông báo lỗi chính xác, người dùng bị ảnh hưởng và hành động đã khắc phục. Sau đó cập nhật runbook khi thông tin còn mới.
Ops chỉ có thể sở hữu hệ thống nếu rõ ai có thể thao tác gì và cách truy cập được theo dõi.
Ghi lại các vai trò bạn thực sự dùng. Với nhiều đội, những vai trò này là đủ:
Tài liệu “chính sách cửa” theo các bước rõ ràng: ai cấp quyền, nơi cấp (SSO, cloud IAM, user DB, CI/CD, admin panel), ai thu hồi và cách xác nhận đã thu hồi khi offboarding.
Đừng quên truy cập không phải người dùng. Liệt kê mọi service account và token dùng bởi job, tích hợp và monitoring, kèm ghi chú quyền tối thiểu cho từng mục (ví dụ “chỉ đọc từ bucket X”). Nếu bạn export source từ AppMaster để tự-host, bao gồm biến môi trường hoặc file config định nghĩa các identity này, nhưng không bao giờ dán giá trị bí mật vào tài liệu bàn giao.
Cũng đặt kỳ vọng về audit log: phải ghi gì (login, deploy, thay đổi config, hành động DB admin), ai có thể đọc log, thời gian giữ, nơi lưu và cách yêu cầu log khi có sự cố hoặc kiểm tra.
Ghi chú bảo mật nên đọc được cho người không chuyên nhưng đủ cụ thể để ops hành động. Thêm một trang tóm tắt trả lời: chúng ta lưu loại dữ liệu gì, nó nằm ở đâu và ai truy cập được?
Bắt đầu với loại dữ liệu: hồ sơ khách hàng, ticket hỗ trợ, metadata thanh toán, file. Nêu rõ các hạng mục nhạy cảm như PII (tên, email, số điện thoại), credential và bất kỳ dữ liệu điều chỉnh nào công ty quan tâm. Nếu bạn export source để tự-host (bao gồm từ AppMaster), nêu nơi dữ liệu đó nằm trong DB và dịch vụ nào có thể đọc nó.
Rồi viết chính sách lưu giữ và xóa dữ liệu theo cách thực tế. Nêu giữ gì, giữ bao lâu và cách xóa hoạt động (soft delete vs hard delete, xóa trì hoãn, backup). Nếu có giữ pháp lý hoặc audit, ghi ai phê duyệt ngoại lệ.
Logs thường rò rỉ nhiều hơn database. Rõ ràng nơi PII có thể xuất hiện (access log, error log, analytics event) và cách giảm hoặc che dấu. Nếu một trường không được ghi log, nêu rõ quy tắc đó.
Giữ các phê duyệt rõ ràng:
Nếu chỉ thêm được một thứ, thêm ghi chú bằng chứng: nơi lưu audit log và cách xuất chúng khi ai đó yêu cầu bằng chứng.
Ops tiếp nhận một cổng khách hàng do một đội product nhỏ xây dựng và chuyển nó lên hạ tầng tự-host mới. Mục tiêu không chỉ là “nó chạy”, mà là “ops có thể chạy mà không gọi người xây dựng”.
Ngày 1: Ops làm một deploy sạch trong môi trường mới chỉ bằng gói bàn giao. Ứng dụng lên, nhưng login lỗi vì thiếu biến môi trường của nhà cung cấp email. Biến đó được thêm vào mẫu env, và deploy lặp lại cho đến khi hoạt động từ đầu.
Ngày 2: Cảnh báo đầu tiên được kích hoạt có chủ ý. Ops gây lỗi kiểm soát (dừng một service hoặc chặn outbound email) và xác nhận: metric phản ánh vấn đề, cảnh báo tới đúng kênh và thông báo ghi rõ hành động tiếp theo.
Ngày 3: Một token hết hạn trong sandbox thanh toán. Vì vị trí credential và bước xoay vòng đã được tài liệu hóa, ops thay thế mà không đoán mò hoặc để lộ secret.
Ngày 4: Chuyển DNS. Một bản ghi sai trỏ tới IP cũ khiến một số người dùng thấy portal bị lỗi. Ops dùng runbook để kiểm tra DNS, TLS và health check theo đúng thứ tự.
Ngày 5: Thử restore backup đầu tiên. Ops restore vào database mới và chứng minh portal tải dữ liệu thực.
Ứng dụng đã chạy 7 ngày mà không cần sửa bí ẩn, một lần restore thành công, cảnh báo rõ ràng và deploy có thể lặp lại mà ops tự thực hiện.
Cách nhanh nhất để biến một bàn giao bình tĩnh thành đống lửa lúc 2 giờ sáng là cho rằng “chúng tôi đã nói hết mọi thứ cho ops” giống với “ops có thể chạy mà không cần chúng tôi.”
Mô thức thất bại phổ biến sau bàn giao tự-host gồm: secret chia sẻ trong spreadsheet hoặc chat, rollback phụ thuộc developer, backup có tồn tại nhưng chưa bao giờ test restore, cảnh báo rung cả ngày vì threshold chưa tinh, và chi tiết môi trường chỉ nằm trong đầu ai đó (cổng, tên DNS, lịch cron, quyền cloud).
Ví dụ: bạn export source từ AppMaster để tự-host, lần deploy đầu chạy. Hai tuần sau một thay đổi config làm login hỏng. Nếu secret được truyền qua chat và rollback cần người xây dựng gốc, ops mất nhiều giờ chỉ để quay lại trạng thái “hoạt động hôm qua”.
Trước khi đóng ticket, làm một diễn tập khởi động mới. Giao gói bàn giao cho một engineer ops và một môi trường sạch (VM mới, namespace Kubernetes mới, hoặc project cloud trống). Nếu họ có thể deploy, quan sát và phục hồi app trong thời gian định trước (ví dụ 2 giờ), gần như xong.
Dùng các kiểm tra này:
Nếu bạn export mã nguồn sinh ra để tự-host, cũng xác nhận ops biết nơi lưu inputs build, phiên bản và tag release để release tương lai có thể lặp lại.
Chạy một buổi walkthrough cuối cùng với những người sẽ cầm pager. Xem nó như một buổi diễn tập. Chứng minh deploy, rollback, restore và cảnh báo đều hoạt động với chính gói bạn bàn giao.
Buổi walkthrough thường bao gồm: deploy vào môi trường test rồi production theo cùng bước, rollback về phiên bản trước và xác nhận app vẫn hoạt động, restore backup vào môi trường sạch và kiểm tra một chức năng cơ bản (login, tạo bản ghi, gửi tin), kích hoạt một cảnh báo thử an toàn, và xác nhận nơi tìm log và dashboard khi có sự cố.
Làm quyền sở hữu rõ ràng. Gán owner tên cho từng runbook (deploy, incident, restore) và cho mỗi route cảnh báo (on-call chính, dự phòng, hành vi ngoài giờ). Nếu không ai sở hữu một cảnh báo, nó sẽ bị bỏ qua hoặc đánh thức nhầm người.
Viết một kế hoạch Day 2 ngắn để ops biết điều gì cần cải thiện sau tuần đầu: tinh chỉnh threshold, kiểm tra chi phí, dọn dẹp artifact cũ và rà soát truy cập. Giữ nhỏ và giới hạn thời gian.
Nếu bạn xây dựng với AppMaster (appmaster.io), bao gồm source code export hoặc chi tiết mục tiêu triển khai chính xác (cloud, region, cài đặt build, dịch vụ cần thiết) để ops tái tạo app mà không phụ thuộc workspace gốc. Thiết lập nhịp cập nhật đơn giản cho gói khi yêu cầu thay đổi, để runbook không lệch khỏi thực tế.
What does “production-ready handoff” actually mean?Một bàn giao sẵn sàng cho môi trường sản xuất có nghĩa là ops có thể triển khai phiên bản đã biết, xác nhận nó hoạt động, phản ứng với cảnh báo và khôi phục khi có sự cố mà không phải phụ thuộc vào ký ức của một developer cụ thể. Nếu một tuần không có người xây dựng mà uptime bị đe dọa, thì bàn giao chưa hoàn tất.
What should be included in a basic system inventory?Bắt đầu bằng một inventory một trang đơn giản liệt kê mọi thành phần chạy và nơi nó nằm: API, web app, worker, job theo lịch, database, lưu trữ, và các dịch vụ bên thứ ba bắt buộc. Thêm thông tin về domain, cổng, ai quản lý DNS/TLS và ước tính tải để ops có thể vận hành mà không phải suy đoán.
How do we hand off environment configuration without leaking secrets?Cung cấp một tài liệu cấu hình duy nhất liệt kê từng khóa cấu hình, kiểu dữ liệu và một giá trị ví dụ an toàn, cùng những khác biệt giữa dev/staging/prod. Giữ các thông tin đăng nhập thực ngoài tài liệu; ghi rõ nơi lưu config và cách áp dụng trong quá trình deploy để thay đổi có thể lặp lại.
What’s the minimum we should document for secrets and credential rotation?Tạo một danh sách ngắn các secret nêu rõ mỗi secret dùng để làm gì, nơi lưu, ai có thể đọc và ai chịu trách nhiệm xoay vòng. Viết bước xoay vòng như một danh sách kiểm tra với một bước xác minh rõ ràng, và bao gồm quy trình 'break-glass' cho trường hợp khẩn cấp cùng với kỳ vọng về ghi nhật ký (audit).
What makes a deployment package “reproducible” for ops?Ops cần biết chính xác những gì đang chạy và cách tái tạo nó: tên/thẻ artifact, phiên bản, ngày build, checksum và tham chiếu nguồn dùng để build. Bao gồm môi trường triển khai đề xuất, thứ tự deploy, thời gian deploy dự kiến và cách các migration database chạy và được xác minh.
What should a rollback plan include so it’s usable at 2 a.m.?Xác định các tín hiệu kích hoạt rollback (chẳng hạn health check thất bại hoặc tỉ lệ lỗi tăng), phiên bản cuối cùng được biết là ổn và các bước cụ thể để quay lại nhanh. Ghi rõ migration database có đảo ngược được không và phương án an toàn nếu không, để rollback không trở thành ứng biến.
Which monitoring signals should we prioritize during handoff?Chọn một tập nhỏ các metric phản ánh trải nghiệm người dùng: độ trễ (p95/p99), tỉ lệ lỗi, độ bão hòa (CPU/ram/disk), độ sâu hàng đợi và check uptime từ bên ngoài. Đặt cảnh báo rõ ràng về ngưỡng, mức độ nghiêm trọng, ai được gọi trực ban và mô tả ngắn về trạng thái “bình thường”. Đảm bảo logs được đồng bộ thời gian và có correlation ID để truy vết sự cố.
How do we make backups and restores genuinely reliable?Ghi rõ những gì được backup, nơi lưu, thời gian giữ bản sao và ai có thể thực hiện restore. Bao gồm quy trình khôi phục từng bước với bước xác minh, và lên lịch diễn tập restore; backup chỉ có ý nghĩa nếu bạn có thể khôi phục được khi cần vào môi trường sạch.
What should an on-call runbook look like for common incidents?Giữ runbook ngắn gọn và nhất quán: triệu chứng, kiểm tra ban đầu, các kiểm tra tiếp theo, các điểm quyết định và cách leo thang. Tập trung vào các sự cố xảy ra thường xuyên nhất (toàn bộ dịch vụ sập, chậm, deploy lỗi) và cập nhật runbook ngay sau sự cố khi thông tin còn tươi để tri thức không bị trôi đi.
How should we document access control and permissions for ops ownership?Ghi rõ các vai trò bạn đang dùng (deployer, DB admin, read-only, incident commander), cách cấp và thu hồi quyền, và những gì cần được ghi nhật ký để phục vụ kiểm toán. Đừng quên các tài khoản dịch vụ và token; liệt kê quyền tối thiểu của chúng và nơi định cấu hình những identity đó mà không đưa giá trị bí mật vào tài liệu bàn giao.
21 thg 1, 2026
8 phút
20 thg 1, 20268 phút
20 thg 1, 20268 phútThử nghiệm với AppMaster với gói miễn phí.
Khi bạn sẵn sàng, bạn có thể chọn đăng ký phù hợp.
