Phải làm gì khi app do AI tạo của bạn hỏng lúc 2 giờ sáng (và bạn không phải lập trình viên)
App của bạn hôm qua còn chạy. Giờ đã nửa đêm và có gì đó trục trặc. Đây là một cẩm nang bình tĩnh, không thiên về kỹ thuật về việc thực sự cần làm gì — mà không cần biết đọc code.
Bạn đã xây một app mà không viết một dòng code nào. Nó chạy ngon suốt cả tuần. Rồi một người dùng nhắn cho bạn lúc 1 giờ 47 phút sáng nói nút đăng ký bấm không có gì xảy ra, và bạn tỉnh giấc với chiếc điện thoại sáng rực trên đầu giường.
Nếu bạn chưa bao giờ phải sửa một app đang chạy thật, khoảnh khắc này có thể cảm thấy kinh khủng. Bạn không đọc code. Bạn không biết “cơ sở dữ liệu” thật sự nghĩa là gì. Bạn không chắc nó hỏng-hẳn hay chỉ-hơi-lạ, và những người bình thường sẽ giúp bạn thì đang ngủ.
Đây là một cẩm nang bình tĩnh, có thứ tự về việc cần làm khi một app do AI tạo bị hỏng còn bạn thì không viết được code. Phần lớn của nó là về việc không làm cho mọi thứ tệ hơn, và đó chính là phần không ai cảnh báo bạn.
Trước tiên: đừng triển khai lại
Có một cái nút đâu đó trong công cụ tạo app bằng AI của bạn ghi đại loại như “đăng lại”, “triển khai lại”, hay “ship”. Bạn sắp sửa muốn nhấn nó. Khoan đã, đừng.
Nhấn triển khai lại trên một app đang hỏng dở có thể khóa cứng trạng thái hỏng, xóa sạch mọi thông tin gỡ lỗi đang còn lưu lại, và khiến cho bất kỳ ai — kể cả chính công cụ tạo app bằng AI — khó tìm ra điều gì đã sai hơn.
Nước đi đầu tiên luôn là quan sát, chứ không phải hành động. Bạn còn chưa xác nhận được cái gì đang hỏng cơ mà.
Bước 1 — Tự mình tái hiện lại sự cố
Mở app trong một cửa sổ trình duyệt mới — chế độ ẩn danh hoặc riêng tư là tốt nhất, vì nó loại bỏ mọi phiên đăng nhập cũ hay bộ nhớ đệm có thể khiến mọi thứ hoạt động khác đi với bạn so với người dùng của bạn.
Hãy cố làm đúng cái việc mà người dùng đã báo. Nếu họ nói nút đăng ký không chạy, hãy thử đăng ký. Nếu họ nói bảng điều khiển trống trơn, hãy thử đăng nhập và xem bảng điều khiển.
Bạn đang tìm một trong ba điều:
- Nó hỏng với tất cả mọi người. Bạn gặp đúng sự cố đó. Đây thực ra là loại dễ sửa nhất vì nó nhất quán.
- Nó chạy được với bạn. Đây là tình huống khó nhất, vì có điều gì đó thuộc về hoàn cảnh cụ thể của người dùng (trình duyệt của họ, tài khoản của họ, dữ liệu của họ) mới là vấn đề.
- Nó lúc được lúc không. Một lần thì chạy, lần sau thì hỏng. Đây là loại căng thẳng nhất nhưng cũng nhiều thông tin nhất — nó thường có nghĩa là có thứ gì đó đang hết giờ chờ hoặc cạn kiệt một tài nguyên nào đó.
Hãy ghi lại bạn thấy cái nào trong ba cái. Bạn sẽ cần nó khi đi nhờ trợ giúp.
Bước 2 — Kiểm tra những thứ bên ngoài hiển nhiên trước khi đổ lỗi cho app
Một lượng đáng ngạc nhiên các khoảnh khắc “app của tôi bị hỏng” hóa ra không phải do app. Trước khi bạn lặn sâu vào công cụ tạo app bằng AI, hãy kiểm tra:
- Bản thân internet có ổn không? Mở vài trang web khác. Nếu wifi của bạn chập chờn, có thể app vẫn ổn còn bạn mới là cái bị hỏng.
- Bản thân công cụ tạo app bằng AI có bị gián đoạn không? Hầu hết công cụ tạo app bằng AI đều có một trang trạng thái (hãy tìm tên sản phẩm kèm chữ “status”). Nếu họ đang có một đêm tồi tệ, bạn không phải tìm hiểu gì khác cả.
- Một trong các công cụ bạn kết nối có bị sập không? Nếu app của bạn dùng Stripe để thanh toán, một dịch vụ email để gửi thông báo, hay một dịch vụ cơ sở dữ liệu để lưu dữ liệu, bất kỳ cái nào trong số đó cũng có thể gặp sự cố. Mỗi cái có trang trạng thái riêng. Hãy kiểm tra những cái mà app của bạn phụ thuộc vào.
Cứ khoảng một trong năm lần, câu trả lời là “thật ra không phải do app của tôi”, và bạn có thể quay lại ngủ.
Bước 3 — Hãy nhìn vào thông báo lỗi, ngay cả khi nó làm bạn sợ
Nếu app của bạn hiện ra một màn hình có chữ trên đó — kể cả thứ chữ trông như vô nghĩa — hãy đọc nó. Chụp một ảnh màn hình. Nhất là nếu có một chuỗi dài chữ và số (người ta gọi cái này là “stack trace”; nó trông như cháo chữ nhưng lại là thứ hữu ích nhất bạn có thể có khi đi nhờ trợ giúp).
Hầu hết công cụ tạo app bằng AI cũng có một nơi để xem những lỗi vừa xảy ra. Nó có thể được gọi là Logs, Activity, Errors, hay Console. Hãy mở nó ra. Bạn không cần hiểu phần lớn những gì bạn thấy — bạn đang tìm dòng chữ đỏ gần nhất hoặc lỗi gần nhất, và thời điểm nó xảy ra. Thời gian quan trọng: một lỗi từ sáng hôm qua có lẽ không phải là lý do người dùng của bạn không đăng ký được vừa nãy.
Hãy sao chép lỗi đó lại. Một lát nữa bạn sẽ dán nó vào một chỗ hữu ích.
Bước 4 — Hỏi công cụ tạo app bằng AI xem có gì đã thay đổi
Đây là nước đi mà hầu hết người xây app không rành kỹ thuật dùng chưa đủ. Hãy mở khung chat với công cụ tạo app bằng AI và nói, bằng ngôn ngữ đời thường:
“App của tôi bị hỏng. Người dùng không đăng ký được — cái nút bấm không làm gì cả. Đây là lỗi từ logs: [dán vào]. Có gì đã thay đổi trong 24 giờ qua, và điều gì có thể đang gây ra chuyện này?”
Một công cụ tạo app bằng AI tốt sẽ cho bạn biết thay đổi gần đây nào nhiều khả năng là thủ phạm nhất. Đôi khi bạn sẽ nhận ra ngay (“à, hôm qua tôi nhờ nó làm cho biểu mẫu trông đẹp hơn và chắc là cái đó làm hỏng logic gửi đi”). Đôi khi nó chỉ vào một thứ bạn không nhớ là mình đã đụng tới, mà điều này cũng hữu ích — nó có nghĩa là có cái gì đó tự động đã thay đổi, như một công cụ kết nối tự cập nhật.
Đừng để công cụ tạo app bằng AI bắt đầu sửa vội. Bạn vẫn đang ở chế độ chẩn đoán. Cách phổ biến nhất mà tôi từng thấy người ta biến một sự cố nhỏ thành lớn hơn là để cho AI bắt đầu “sửa” mọi thứ trước khi có ai hiểu cái gì đang hỏng.
Bước 5 — Quyết định có quay về phiên bản cũ hay không
Gần như mọi công cụ tạo app bằng AI đều cho phép bạn quay về một phiên bản cũ hơn của app. Đôi khi nó được gọi là “history” (lịch sử), “versions” (phiên bản), “checkpoints” (điểm lưu), hay “rollback” (quay lui).
Nếu bạn nhớ rõ một giờ hay một ngày khi app còn chạy được, quay về phiên bản đó là nước đi đáng tin cậy nhất. Nó khiến bạn mất đi những thay đổi đã làm ở giữa (mà bạn có khi cũng chẳng còn muốn nữa), và nó cho bạn một app chạy được để thức dậy cùng.
Một quy tắc hay: nếu thứ bị hỏng là cái mà người dùng làm hàng ngày (đăng ký, đăng nhập, thanh toán), hãy quay lui trước rồi sửa tiếp sau. Chạy-được-nhưng-cũ luôn hơn hỏng-nhưng-mới.
Nếu thứ bị hỏng là một tính năng bạn vừa thêm hôm nay mà chưa ai phụ thuộc vào, bạn có thể cứ để nó hỏng tới sáng và sửa với một cái đầu tỉnh táo.
Bước 6 — Nếu buộc phải để công cụ tạo app bằng AI sửa
Nếu không thể quay lui, hoặc bạn đã quyết định không quay, thì hãy để công cụ tạo app bằng AI đề xuất một cách sửa. Có hai điều cần ghi nhớ trong khi nó làm:
Hãy đọc xem nó định thay đổi cái gì trước khi phê duyệt. Bạn sẽ không hiểu hết, nhưng bạn có thể nhận ra liệu nó đang chỉnh sửa một thứ tập trung hay đang viết lại nửa cái app. Những thay đổi nhỏ, tập trung an toàn hơn nhiều so với những thay đổi tràn lan lúc 2 giờ sáng.
Hãy kiểm thử bản sửa theo cách nhàm chán nhất có thể. Đừng chỉ hỏi “sửa xong chưa?” rồi tin câu trả lời. Hãy thật sự tự mình vào app trong một cửa sổ ẩn danh và làm cái việc đã bị hỏng. Nếu bản sửa có hiệu quả, thì thứ vốn hỏng giờ chạy được. Nếu không, đừng chấp nhận thay đổi chỉ vì công cụ tạo app bằng AI bảo là nó chạy rồi.
Bước 7 — Nhắn lại cho người dùng, kể cả khi bạn chưa sửa xong
Người dùng nhắn cho bạn lúc 1 giờ 47 phút sáng không trông đợi bạn đang online. Nhưng nếu bạn có online, một lời hồi đáp ngắn còn quan trọng hơn cả việc sửa xong:
“Cảm ơn bạn đã báo — tôi đang xem ngay đây. Tôi sẽ nhắn bạn ngay khi nó chạy lại được.”
Nếu họ là người dùng trả tiền, một tin nhắn đó là khác biệt giữa việc họ kể với mọi người rằng bạn phản hồi nhanh và việc họ kể rằng bạn lặn mất tăm. Việc sửa có thể đợi tới sáng. Lời hồi đáp thì không.
Bài học lớn hơn: hãy xây app như thể nó có thể hỏng
Nếu bạn thấy chuyện này căng thẳng, thì điểm sáng là trải nghiệm ấy sẽ định hình lại cách bạn xây dựng. Sau sự cố 2 giờ sáng đầu tiên, bạn sẽ bắt đầu làm mọi thứ khác đi:
- Bạn sẽ thêm một trang kiểm tra trạng thái. Một trang đơn giản cho bạn biết liệu những phần quan trọng của app có đang chạy không, để bạn không phải đăng nhập vào mới biết.
- Bạn sẽ giữ một bản sao lưu dữ liệu người dùng. Hầu hết công cụ tạo app bằng AI sẽ xuất dữ liệu của bạn khi được yêu cầu. Làm việc này mỗi tuần một lần tốn 30 giây và cứu bạn trong tình huống xấu nhất.
- Bạn sẽ ghi lại những gì app của mình phụ thuộc vào. Một danh sách ngắn mọi công cụ được kết nối (thanh toán, email, cơ sở dữ liệu, lưu trữ), để khi có gì hỏng lúc 2 giờ sáng, bạn có một danh mục kiểm tra thay vì những phỏng đoán.
- Bạn sẽ thay đổi từng thứ một. Khi bạn làm 10 thay đổi cùng lúc và app hỏng, bạn chẳng biết thay đổi nào làm hỏng nó. Khi bạn thay đổi từng thứ một, bạn biết.
Bạn có thể xây một app mà không cần code. Bạn cũng có thể duy trì cho nó chạy mà không cần là lập trình viên — nhưng những kỹ năng liên quan khác với kỹ năng xây dựng. Bạn học chúng phần lớn theo cách khó nhằn, thường là vào một giờ giấc bất tiện.
Tin tốt: mỗi lần nó xảy ra, nó lại bớt đáng sợ đi. Đến lần thứ ba, nó phiền phức thay vì đáng sợ. Đến lần thứ mười, nó chỉ là một ngày thứ Ba bình thường.