Người phụ trách nghỉ, không ai hiểu hệ thống: 30 ngày đầu
Tóm tắt: Khi người duy nhất hiểu hệ thống nghỉ việc, 30 ngày đầu nên đi theo thứ tự: giữ quyền truy cập và thông tin đăng nhập, kiểm kê hệ thống, chặn các rủi ro đang chảy máu, dựng tài liệu hiện trạng (AI đọc mã nguồn hỗ trợ), đối chiếu với người dùng nghiệp vụ, rồi quyết định giữ, sửa hay thay thế. Chưa nên viết lại hệ thống ở giai đoạn này.
Mục lục
- Người phụ trách hệ thống nghỉ việc thì việc đầu tiên là gì?
- 30 ngày đầu nên đi theo thứ tự nào?
- Tuần 1: giữ quyền truy cập và kiểm kê những gì đang có
- Không ai viết tài liệu thì lấy hiện trạng ở đâu?
- Vì sao tài liệu AI dựng từ mã nguồn vẫn phải hỏi người dùng?
- Giữ, sửa hay thay thế: quyết định dựa vào đâu?
- Khi nào cách làm này chưa phù hợp?
- Câu hỏi thường gặp
1. Người phụ trách hệ thống nghỉ việc thì việc đầu tiên là gì?
Việc đầu tiên là giữ quyền truy cập, chưa phải sửa hay hiểu hệ thống. Hệ thống đang chạy thì cứ để chạy. Thứ mất đi cùng người nghỉ việc thường không phải mã nguồn, mà là những thứ nằm ngoài mã: tài khoản đứng tên cá nhân, mã xác thực hai lớp gắn với điện thoại của họ, và những việc họ vẫn làm tay mỗi tháng mà chưa ai ghi lại.
Tình huống này phổ biến hơn người ta nghĩ ở doanh nghiệp vừa và nhỏ. Một người dựng hệ thống từ vài năm trước, chạy ổn, nên không ai hỏi. Ngày họ nghỉ, cả công ty mới nhận ra không ai biết hệ thống nằm trên máy chủ nào, tên miền gia hạn ở đâu, và ai nhận email cảnh báo khi có lỗi.
Nếu người đó còn liên lạc được, hãy xin họ 1 đến 2 giờ trước ngày cuối. Một câu hỏi đáng giá hơn cả bản bàn giao dài: "Hệ thống hay hỏng ở chỗ nào, và lúc đó bạn làm gì?" Nếu họ đã đi rồi, phần còn lại của bài vẫn áp dụng được, chỉ chậm hơn.
2. 30 ngày đầu nên đi theo thứ tự nào?
Quy trình tiếp quản hệ thống trong 30 ngày gồm 6 việc, đi theo thứ tự từ rủi ro mất hẳn sang rủi ro hiểu sai. Bảng dưới là danh sách kiểm tra bạn có thể dùng làm khung. Bạn tự làm được phần lớn các dòng đầu mà không cần kỹ sư.
| Khoảng thời gian | Việc | Đầu ra | Phần hay bị quên |
|---|---|---|---|
| Ngày 1 đến 3 | Giữ quyền truy cập | Danh sách tài khoản, người đứng tên, cách khôi phục | Xác thực hai lớp gắn điện thoại cá nhân; tài khoản đám mây trả bằng thẻ của người đã nghỉ |
| Ngày 3 đến 7 | Kiểm kê hệ thống | Sơ đồ thô: máy chủ, tên miền, cơ sở dữ liệu, dịch vụ bên thứ ba, việc chạy định kỳ | Tác vụ chạy tự động (cron, Task Scheduler); chứng chỉ SSL sắp hết hạn |
| Ngày 1 đến 10 | Chặn rủi ro đang chảy máu | Bản sao lưu đã thử khôi phục, người nhận cảnh báo, quy tắc "chưa sửa gì khi chưa hiểu" | Sao lưu có chạy nhưng chưa ai khôi phục thử lần nào |
| Ngày 8 đến 18 | Dựng tài liệu hiện trạng | Tài liệu mô tả hệ thống đang làm gì, danh sách màn hình và dữ liệu | Việc xử lý tay bên ngoài hệ thống (Excel, macro, gửi mail tay) |
| Ngày 15 đến 25 | Đối chiếu với người dùng nghiệp vụ | Mỗi mục trong tài liệu được xác nhận đúng, sai hoặc "không ai dùng nữa" | Người dùng ít hỏi nhưng dùng hằng tháng (kế toán, kiểm kê cuối kỳ) |
| Ngày 26 đến 30 | Quyết định giữ, sửa hay thay thế | Một trang quyết định kèm lý do và rủi ro | Chi phí duy trì thực tế, tính cả người phải ở lại trực |
Các khoảng thời gian chồng lên nhau, và nên như vậy. Giữ quyền truy cập và chặn rủi ro không chờ nhau.
3. Tuần 1: giữ quyền truy cập và kiểm kê những gì đang có
Trong tuần đầu, doanh nghiệp cần lấy lại toàn bộ quyền quản trị và lập danh sách mọi thành phần của hệ thống, kể cả những thứ trông không quan trọng. Chưa cần biết hệ thống hoạt động ra sao, chỉ cần biết nó gồm những gì và ai đang giữ chìa khoá.
Đi theo từng nhóm:
- Tài khoản và quyền. Máy chủ hoặc dịch vụ đám mây, kho mã nguồn, quản lý tên miền, email gửi tự động, công cụ giám sát. Với mỗi cái, ghi ai đứng tên và khôi phục bằng cách nào. Nếu tài khoản đứng tên cá nhân người đã nghỉ, chuyển sang tên công ty ngay khi còn liên lạc được.
- Ngày hết hạn. Tên miền, chứng chỉ SSL, giấy phép phần mềm, hợp đồng thuê máy chủ. Hệ thống sống nhiều năm thường chết vì một ngày hết hạn không ai nhớ, chứ ít khi chết vì lỗi mã.
- Việc chạy định kỳ. Gửi báo cáo cuối tháng, đồng bộ dữ liệu ban đêm, sao lưu. Chúng thường nằm trong cấu hình máy chủ chứ không nằm trong mã nguồn, nên đọc mã không thấy.
- Kết nối với hệ thống khác. Phần mềm kế toán, cổng thanh toán, hệ thống của đối tác, tệp trao đổi qua FTP.
Song song, áp dụng một quy tắc đơn giản: chưa ai được sửa hệ thống khi chưa hiểu. Một lần "sửa nhanh cho gọn" khi chưa nắm cấu trúc dễ biến một hệ thống chạy được thành hệ thống không ai dám chạm.
4. Không ai viết tài liệu thì lấy hiện trạng ở đâu?
Khi không có tài liệu, mã nguồn là nguồn sự thật duy nhất về việc hệ thống đang làm gì, và AI đọc mã nguồn giúp dựng tài liệu hiện trạng nhanh hơn nhiều so với đọc tay. Công cụ như Claude Code đọc được toàn bộ thư mục mã của dự án và trả lời câu hỏi về nó, theo tài liệu công khai của Anthropic.
Với tài liệu hiện trạng, chúng tôi nhờ AI trả lời những câu cụ thể: hệ thống có những màn hình và chức năng nào, dữ liệu nào được lưu ở đâu, quy tắc tính toán nằm ở file nào, hệ thống gọi dịch vụ bên ngoài nào. Kết quả là bản nháp để người kiểm tra, không phải bản cuối.
VAON đã làm việc này trên dự án thật, tức là dựng bản mô tả hiện trạng từ mã nguồn rồi mới tính chuyện sửa hay làm mới. Chúng tôi chưa có số đo thời gian tiết kiệm được, nên không đưa ra con số. Điều chúng tôi chắc chắn là thứ tự: có bản mô tả hiện trạng trước, sau đó mới nói được chuyện chi phí và phạm vi một cách có căn cứ. Đây cũng là nội dung của lối vào A trong 仕様確定フェーズ (giai đoạn chốt đặc tả) của VAON, đọc mã, phỏng vấn người vận hành và đo lường.
Một lưu ý trước khi đưa mã vào bất kỳ công cụ AI nào: kiểm tra quy định nội bộ và hợp đồng xem có cho phép không. VAON không đưa mã của khách vào công cụ AI khi khách chưa cho phép.
5. Vì sao tài liệu AI dựng từ mã nguồn vẫn phải hỏi người dùng?
Tài liệu dựng từ mã nguồn cho biết hệ thống đang làm gì, nhưng không cho biết vì sao, nên mỗi mục đều phải đối chiếu với người dùng nghiệp vụ. Mã chỉ là một phần của hệ thống mà họ đang dùng hằng ngày.
Có năm chỗ tài liệu từ mã hay lệch:
- Lý do. Mã cho thấy "đơn trên 500.000 yên cần quản lý duyệt", không cho thấy vì sao con số đó.
- Quy tắc đã chết. Một nhánh xử lý vẫn nằm trong mã dù nghiệp vụ đã bỏ từ lâu. AI sẽ ghi nó như thể đang hoạt động.
- Logic nằm ngoài mã. Dữ liệu gốc trong cơ sở dữ liệu, cấu hình của môi trường thật, thao tác tay, hệ thống bên thứ ba.
- Lỗi lâu năm. Một bug tồn tại nhiều năm có thể bị ghi lại thành "đặc tả". Người dùng quen với nó đến mức tưởng đó là cách hệ thống vận hành.
- Thứ không ai mở ra nữa. Một màn hình tồn tại trong mã nhưng không ai dùng.
Cách đối chiếu đơn giản: chọn 2 đến 3 người dùng thật, mở từng mục trong tài liệu và hỏi "việc này bạn còn làm không, làm như thế này đúng không?" Ghi kết quả ngay cạnh mục: đúng, sai, hoặc không còn dùng. Một buổi 60 phút với người vận hành thường lộ ra những điều mã nguồn không bao giờ cho thấy.
6. Giữ, sửa hay thay thế: quyết định dựa vào đâu?
Quyết định giữ, sửa hay thay thế nên dựa vào ba thứ có thể kiểm chứng: hệ thống còn phục vụ đúng nghiệp vụ hiện tại không, rủi ro duy trì nó là gì, và chi phí khi để nguyên. Cảm giác "mã này cũ quá" chưa đủ để thay thế.
| Hướng | Phù hợp khi | Điều cần chấp nhận |
|---|---|---|
| Giữ nguyên, chỉ lập tài liệu và quy trình vận hành | Nghiệp vụ ổn, hệ thống chạy ổn, vấn đề duy nhất là không ai hiểu | Vẫn dùng công nghệ cũ; cần người nắm tài liệu |
| Sửa và hiện đại hoá từng phần | Phần lõi còn đúng, một số phần đã lỗi thời hoặc không an toàn | Cần thời gian chạy song song và kiểm tra từng phần |
| Thay thế bằng hệ thống mới | Nghiệp vụ đã khác nhiều, công nghệ không còn được hỗ trợ, chi phí sửa vượt chi phí làm mới | Cần chốt đặc tả cho hệ thống mới; có giai đoạn chuyển đổi dữ liệu |
Với hệ thống lớn, cách tiếp cận không dừng hệ thống cũ khi thay từng phần có mô tả trong bài về hiện đại hoá CMS không ngừng hoạt động. Nếu chọn làm mới và giao cho đội offshore, hãy đọc thêm về offshore không phụ thuộc vào một BrSE (Bridge System Engineer). Bước dựng tài liệu hiện trạng được trình bày kỹ hơn trong bài về dựng đặc tả hiện trạng từ mã nguồn bằng AI.
7. Khi nào cách làm này chưa phù hợp?
Cách làm này chưa phù hợp khi hệ thống đang hỏng tại chỗ, khi không còn truy cập được mã nguồn, hoặc khi mã không được phép đưa vào công cụ AI. Ba trường hợp, ba hướng xử lý khác nhau.
- Hệ thống đang sập hoặc sai dữ liệu. Lúc này việc đầu tiên là khôi phục, không phải làm tài liệu. Dựng tài liệu chờ sau.
- Không còn mã nguồn. Chỉ còn bản đã biên dịch, hoặc mã nằm trên máy cá nhân đã bị xoá. Khi đó phải dựng lại từ hệ thống đang chạy và dữ liệu, tốn thời gian hơn và độ chắc chắn thấp hơn.
- Mã chưa được phép đưa vào AI. Bước AI sẽ không chạy, đọc mã quay về làm bằng tay. Vẫn làm được, chỉ chậm hơn.
Ngoài ra, 30 ngày là mốc cho hệ thống cỡ vừa phải. Hệ thống có nhiều module và nhiều năm lịch sử có thể cần lâu hơn ở bước đối chiếu với người dùng, và bạn nên chấp nhận điều đó thay vì rút ngắn bước này.
8. Câu hỏi thường gặp
Người phụ trách đã nghỉ, việc đầu tiên nên làm trong ngày đầu là gì? Lập danh sách mọi tài khoản liên quan đến hệ thống (máy chủ, tên miền, kho mã, email, giám sát) và xác định ai đứng tên từng cái. Nếu người cũ còn liên lạc được, nhờ họ chuyển quyền hoặc cung cấp cách khôi phục trước khi tài khoản của họ bị khoá.
Có nên viết lại toàn bộ hệ thống ngay không? Không nên. Khi chưa có tài liệu hiện trạng, bạn chưa biết hệ thống đang làm những gì, nên bản viết lại dễ thiếu những chức năng mà người dùng cần mà chưa ai nhớ. Hãy dựng tài liệu và đối chiếu với người dùng trước, rồi mới quyết định.
AI đọc mã nguồn rồi viết tài liệu có đáng tin không? Đủ tin để làm bản nháp, chưa đủ để dùng như bản cuối. AI cho biết hệ thống đang làm gì, nhưng không biết vì sao, và có thể ghi cả bug lâu năm thành đặc tả. Mỗi mục cần người dùng nghiệp vụ xác nhận đúng hoặc sai.
Nếu mã nguồn không được phép đưa vào AI thì sao? Vẫn làm được. Bước AI đọc mã không chạy, việc đọc mã chuyển sang kỹ sư làm tay và mất thời gian hơn. VAON chỉ đưa mã vào công cụ AI khi khách đã cho phép.
VAON có thể giúp ở bước nào? Ở bước dựng tài liệu hiện trạng và quyết định giữ, sửa hay thay thế, qua lối vào A của 仕様確定フェーズ. Giai đoạn kéo dài 1 đến 2 tuần, giá cố định báo trước, và khách được dừng sau giai đoạn này.
Hệ thống của bạn đang nằm trong đầu một người đã rời công ty? Buổi trao đổi 60 phút đầu tiên có CEO tham dự, không cần chuẩn bị tài liệu và không ràng buộc. Chúng tôi nghe hiện trạng và chỉ ra bước đầu tiên nên làm. Đặt lịch trao đổi 60 phút miễn phí
Tài liệu tham khảo
- Anthropic, Claude Code overview (Claude Code đọc mã nguồn dự án, chỉnh sửa tệp, chạy lệnh): https://code.claude.com/docs/en/overview (kiểm tra 17/10/2026)