Mọi bản sao lưu của trang bạn đang đọc đang nằm trên đúng con máy mà chúng sao lưu. Máy đó chết thì chúng chết theo. Mình biết chuyện này, viết nó ra trong ghi chép lúc dựng, rồi để nguyên nhiều tuần. Tự vận hành VPS cho doanh nghiệp nhỏ là như vậy: bạn quyết mọi thứ, và cũng chỉ còn mình bạn để quên một việc.
Cái bạn mua không phải con máy
Con máy là phần rẻ nhất và dễ hiểu nhất. Mười đô một tháng, một nhân, 2 GB RAM, đặt ở Singapore. Mình cộng từng dòng ở bài chi phí chạy website một tháng.
Thứ đáng tiền không nằm ở cấu hình. Nó nằm ở chỗ bạn được đặt luật riêng lên từng thao tác ghi vào dữ liệu.
Luật của mình vỏn vẹn một dòng: con bot AI được tạo draft, và không được publish. Nghe nhỏ, nhưng không nền tảng dựng sẵn nào cho mình một ô để gõ dòng đó vào. Muốn có nó thì phải có chỗ để chạy code của mình, ở tầng dưới cả admin panel.
Nếu bạn không có một dòng luật như thế, phần còn lại của bài này là chi phí không đổi lấy gì.
Bốn thứ hoá ra không tốn tiền
Mấy khoản mình tưởng phải trả mà cuối cùng không:
- HTTPS. Lớp proxy phía trước tự xin chứng chỉ và tự gia hạn, xem tài liệu Caddy.
- Database. Postgres chạy trên chính con máy đó, không thuê dịch vụ riêng.
- DNS và CDN. Bậc miễn phí đang đủ cho lượng truy cập hiện tại.
- Bộ chấm điểm nội dung trong admin panel. Nó là code, không phải thuê bao.
Cái mình trả cho bốn dòng này là công dựng và công nuôi. Đổi tiền thành công sức là hình dạng chung của mọi quyết định trong bài.
Việc bạn nhận về
Đây là phần các trang bán máy không viết. Tự vận hành VPS cho doanh nghiệp nhỏ nghĩa là bạn nhận nguyên một danh sách việc không ai nhắc.
Bạn vá hệ điều hành. Bạn gia hạn tên miền. Bạn dọn ổ khi nó gần đầy. Bạn dựng lại tiến trình chết. Bạn là người duy nhất biết cụm này gồm những gì.
Và bạn là ca trực. Site hỏng lúc ba giờ sáng thì nó nằm im tới khi bạn mở máy lên xem. Nền tảng dựng sẵn thu tiền cao hơn để làm hộ đúng những việc vừa kể, và với phần lớn người thì đó là món rẻ.
Bảy bản sao lưu nằm sai chỗ
Đây là chỗ mình làm sai lâu nhất, và nó đáng kể lại đúng như nó đã xảy ra.
Mỗi đêm máy tự dump database, gói ảnh lại, ghi một bản kê nội dung, mã hoá cả ba, rồi dọn thứ quá bảy ngày. Nghe như một quy trình sao lưu đầy đủ. Mình đọc dòng ghi chép đó và tick xong trong đầu.
Tất cả nằm trên chính con máy vừa được sao lưu. Chỗ chứa bên ngoài chưa bật, và mỗi đêm script tự in ra đúng câu đó trong log.
Nên thứ mình đang có không phải sao lưu. Nó là mấy bản chép thêm, chống được đúng một loại tai nạn: mình tự tay xoá một row trong database. Ổ hỏng, máy bị thu hồi, nhà cung cấp khoá tài khoản, hoặc mình gõ sai một lệnh xoá ở tầng máy: tất cả đi cùng nhau.
Ban đầu mình tưởng cái thiếu là một dòng cấu hình trỏ ra chỗ chứa ngoài. Hoá ra chỗ thiếu nằm ở tầng khác, và mình chỉ thấy khi đọc lại ghi chép của chính mình.
Một bản đã được diễn tập thật: giải mã trên máy cá nhân, nạp lại vào database, đếm bài, băm nội dung, soi từng ảnh bìa. Nó pass. Nên nói mình không biết mấy file kia có dùng được hay không là nói quá.
Cái mình thật sự chưa làm là dựng lại từ đó thành một site chạy được, có ảnh, mở lên xem bằng mắt. Giữa "dump nạp được" và "site quay lại được" còn một khoảng, và mình chưa đi qua khoảng đó.
Không có máy thứ hai để thử
Mình chưa có máy staging. Mọi thay đổi thử ở máy cá nhân rồi đụng thẳng bản thật.
Cách này chạy được vì bản thật của mình chỉ có một con máy và ít người đọc. Nó sẽ không chạy được với một công ty có khách trả tiền. Chỗ này mình đang thiếu, không phải đang tối giản.
Đổi container, chứ không phải khởi động lại
Một lần hỏng cụ thể, đo được, hôm nay.
Mình có bước nhập bài chạy trong một container riêng. Nhập xong, mình khởi động lại app, rồi mở site ra xem bài mới. Site vẫn trả nội dung cũ.
Mình mất gần một buổi cho chỗ này. Phần lớn thời gian đó là ngồi nhập lại rồi khởi động lại thêm vài lượt, vì mình tin là mình thao tác thiếu. Chỉ tới lúc mở thẳng vào trong container xem cái đĩa nó ghi gì thì mới ra.
Lý do: app giữ bản nội dung dùng chung giữa các lượt truy cập, và nó ghi bản đó xuống đĩa bên trong lớp ghi của container. Khởi động lại thì tiến trình mới đọc lại đúng lớp đó, tức đọc lại đúng bản cũ. Phải thay hẳn container mới bắt đầu từ con số không.
Cái giá của việc thay container thì mình đo được. Lượt truy cập đầu tiên sau đó tốn khoảng 0,7 giây phần máy. Khi bản nội dung đã ấm, con số đó là khoảng 0,09 giây.
Ba phần tư giây không ai chết vì nó. Nhưng đó là giá thật của mỗi lần đổi container, và nó rơi đúng vào lượt của người đọc đầu tiên.
Migration tự chạy, và mình tưởng ngược lại
Chỗ này mình vừa phát hiện hôm nay, khi đi kiểm một câu chính mình đã viết ra.
Mình đinh ninh bản deploy thường không đụng tới migration, vì cái container chuyên chạy migration nằm sau một cờ riêng và lệnh deploy bỏ qua nó. Ghi chép vận hành của mình chép đúng câu đó suốt nhiều tuần.
Sai. Cái container chuyên trách thì đúng là bị bỏ qua. Nhưng chính app lại tự chạy migration đang chờ, ngay lúc nó khởi động ở chế độ production. Mình mở mã nguồn thư viện ra đọc mới thấy dòng đó.
Bốn migration trên máy thật nằm ở bốn đợt khác nhau, mỗi đợt trùng một lần deploy. Bằng chứng nằm ngay trong database của mình, và mình chưa từng mở nó ra xem.
Khác biệt không nhỏ. Theo bản mình tưởng, một bản deploy mang migration mà quên chạy tay thì app gặp một cột không tồn tại và chết. Theo bản thật, app tự chạy migration đó, và cái chết chỉ xảy ra nếu migration hỏng, chẳng hạn nó thêm ràng buộc mà dữ liệu cũ vi phạm.
Cả hai bản đều kết thúc bằng site chết trong khi con trỏ vẫn trỏ vào release cũ. Nhưng cách phòng thì ngược nhau. Cái mình cần không phải nhớ chạy tay, mà là kiểm xem dữ liệu cũ có vi phạm ràng buộc mới không, trước khi đẩy code đi.
Bài học mình rút: một câu trong tài liệu vận hành mà chưa ai đối chiếu với mã nguồn thì nó chỉ là tin đồn nội bộ. Quy trình deploy đầy đủ và bốn cái bẫy mình đã dính nằm ở bài deploy Next.js lên VPS.
Mất việc dễ hơn mất máy
Trong bốn lần mình mất công việc đã làm, không lần nào do con máy. Cả bốn đều do quy trình của chính mình: code chưa commit bị bản build sau ghi đè, hai phiên làm việc chung một branch xoá lẫn nhau.
Máy chủ hỏng là loại tai nạn ai cũng chuẩn bị. Loại làm mình mất nhiều nhất lại là loại không có tiếng động. Mình kể từng lần và cái khoá gắn sau đó ở bài mất code khi deploy.
Ai không nên tự vận hành VPS cho doanh nghiệp nhỏ
- Người chỉ cần một trang chữ, không database, không tác vụ chạy nền. Bậc miễn phí của một nền tảng dựng sẵn gần như chắc chắn là đủ.
- Đội chưa có ai nhận trách nhiệm lúc nửa đêm. Tiền thuê máy rẻ, ca trực thì không.
- Việc dính tiền của khách mà chỉ có một người đọc chéo. Một mình bạn là quá ít mắt.
- Người chưa từng thử phục hồi một bản sao lưu. Hãy thử trước, rồi hẵng bàn tới chuyện tự nuôi máy.
Mình nằm trong nhóm nên tự nuôi vì đúng một lý do: cái luật một dòng ở đầu bài. Nếu bỏ nó ra, mình sẽ chọn nền tảng dựng sẵn mà không cần suy nghĩ.
Cách tự quyết trong mười phút
- Viết ra dòng luật mà nền tảng dựng sẵn không cho bạn gõ vào. Không viết ra được thì dừng ở đây.
- Đếm số người sẽ dựng lại máy lúc ba giờ sáng. Số đó là 0 thì bạn chưa vận hành được.
- Tra giá đúng bậc bạn cần, tham khảo bảng giá Vultr, rồi cộng thêm dòng công cụ và dòng thời gian.
- Trước khi đưa dữ liệu thật lên, dựng lại một bản sao lưu thành site chạy được. Một lần, đủ để biết nó thật.
Mấy ghi chép cùng loại mình gom ở chủ đề Vận hành.
Con máy mười đô là phần mình lo ít nhất. Thứ mình còn nợ chính mình là một lần dựng lại nguyên cái site từ bản sao lưu, và một chỗ chứa nằm ngoài căn nhà này.
