Điều gì thay đổi khi MVP trở thành sản phẩm thật
Code thường gần như không đổi. Thứ thay đổi là giờ đây lỗi khiến ai đó mất mát gì đó.
Bước chuyển này thuộc về vận hành, không phải kiến trúc
Các đội thường nghĩ đưa lên production là phải viết lại. Thường thì không. Đoạn code phục vụ mười người dùng vẫn phục vụ vài trăm người mà không kêu ca mấy. Thứ thay đổi là một lần gián đoạn giờ có cái giá của nó, và phải có ai đó phát hiện ra trước khi khách hàng phát hiện.
Những thứ cần có sẵn
Bản sao lưu mà bạn đã từng phục hồi. Một bản sao lưu chưa test là một niềm tin, không phải bản sao lưu. Hãy phục hồi thử vào môi trường nháp và bấm giờ xem mất bao lâu.
Cảnh báo theo triệu chứng, không chỉ theo sập. Những lỗi đáng sợ thường không phải tiến trình chết. Đó là hàng đợi phình ra, tỷ lệ thành công tụt dần, hoặc một job âm thầm ngừng chạy.
Cách triển khai không gián đoạn, và cách quay lui. Vế thứ hai quan trọng hơn vế thứ nhất vào đúng ngày bạn cần đến nó.
Một người chịu trách nhiệm. Không phải lịch trực cho có, mà là câu trả lời rõ ràng cho việc ai sẽ vào xem khi có sự cố vào giờ bất tiện.
Thứ thường phải làm lại
Giới hạn tần suất, tính bất biến khi gọi lại với mọi thao tác trừ tiền, và kiểm soát truy cập nếu MVP từng giả định chỉ có một người dùng đáng tin. Ba thứ này xuất hiện trong gần như mọi danh sách.
Làm trước lần ra mắt quan trọng
Mỗi thứ kể trên đều rẻ hơn khi thêm vào trong một tuần yên ả, so với khi thêm giữa sự cố chứng minh rằng bạn đã cần nó.
ToolGo Team
Sản phẩm & Kỹ thuật
Chúng tôi xây dựng các công cụ SaaS thực tế và chia sẻ những gì chúng tôi học được — từ quyết định sản phẩm đến kỹ thuật chuyên sâu.
