Truyện ma dân dev: Server chết ngày lên production

Bóng ma ám ảnh mọi coder: Đêm định mệnh trước giờ G

Với dân lập trình, có lẽ không có cảm giác nào vừa phấn khích vừa lo âu bằng đêm trước ngày release sản phẩm. Đó là kết quả của hàng tháng trời cày cuốc, của những ly cà phê đặc quánh uống vội, và của vô số những dòng code được viết, sửa, rồi lại xóa đi. Đội của chúng tôi cũng không ngoại lệ. Dự án “Phoenix”, đứa con tinh thần mà cả team đã dồn hết tâm huyết, cuối cùng cũng đến ngày được “chào đời” trên môi trường Production.

Không khí trong văn phòng lúc 22h đêm đặc quánh lại, chỉ còn tiếng lách cách đều đều của bàn phím và tiếng thở dài khe khẽ. Ai cũng có một nỗi lo sợ vô hình, một “con ma” mà chỉ dân dev mới hiểu. Con ma đó không hiện hình, không có âm thanh ghê rợn, nhưng nó luôn lởn vởn trong tâm trí: “Liệu mọi thứ có chạy ổn trên Production không?”. Chúng tôi đã tự trấn an nhau bằng hàng trăm lần kiểm thử thành công trên môi trường Staging. Nhưng ai cũng biết, Staging và Production là hai thế giới hoàn toàn khác biệt, như trần gian và địa ngục vậy.

Sự bình yên giả tạo: Mọi thứ hoàn hảo trên Staging

Trước khi bước vào cuộc chiến, chúng tôi đã chuẩn bị kỹ lưỡng đến từng chi tiết. Môi trường Staging được dựng lên gần như y hệt Production, từ cấu hình server, phiên bản phần mềm cho đến dữ liệu giả lập. Cả tuần cuối cùng, đội QA (Kiểm thử chất lượng) đã “hành hạ” hệ thống không thương tiếc.

• Test chức năng: Mọi nút bấm, mọi luồng xử lý đều được kiểm tra đi kiểm tra lại. Kết quả: Pass 100%.
• Test hiệu năng: Chúng tôi giả lập hàng ngàn người dùng truy cập cùng lúc. Hệ thống vẫn chạy mượt mà, CPU và RAM chỉ nhích nhẹ.
• Test bảo mật: Các lỗ hổng tiềm tàng đều đã được vá. Bức tường phòng thủ vững chắc như Vạn Lý Trường Thành.

Nhìn vào bảng dashboard xanh mướt với những dấu tick “Passed”, cả team thở phào nhẹ nhõm. Anh lead còn vỗ vai tôi cười nói: “Chuẩn bị tinh thần mai ăn mừng lớn thôi em ơi!”. Sự tự tin lên cao, và chúng tôi tin rằng “con ma” kia sẽ không có cơ hội xuất hiện. Một sự bình yên đến lạ thường, một sự bình yên mà sau này nghĩ lại, chúng tôi mới thấy nó đáng sợ đến mức nào.

Giờ G đã điểm: Cơn ác mộng mang tên Production

Đúng 00:00, thời điểm vàng để release vì lượng người dùng truy cập thấp nhất. Anh lead, với vẻ mặt trang trọng, thực hiện những cú click chuột cuối cùng để deploy mã nguồn lên server Production. Một thanh tiến trình màu xanh chạy trên màn hình, mang theo hy vọng của cả đội. 10%… 50%… 90%… 100%. Deploy success!

“Ok rồi anh em, vào check thôi!” – Giọng anh lead đầy phấn khởi.

Cả đội F5 trang web. Im lặng. Màn hình trắng xóa. F5 lần nữa. Vẫn là sự im lặng đến rợn người. Và rồi, nó xuất hiện. Dòng chữ mà không một lập trình viên nào muốn thấy trong đêm release: “500 Internal Server Error”.

Cả căn phòng như đông cứng lại. Nụ cười trên môi mọi người vụt tắt. Ly cà phê trên tay tôi bỗng trở nên nguội ngắt. Tim tôi đập thình thịch trong lồng ngực. Lỗi 500 – một lỗi chung chung, mơ hồ như một bóng ma không rõ hình thù. Nó báo rằng server đã gặp sự cố, nhưng lại không nói rõ là sự cố gì. Cơn ác mộng tồi tệ nhất đã trở thành sự thật. Server Production đã “chết” ngay khi vừa chào đời.

Cuộc săn lùng “con ma” trong bóng tối: Đào bới từng dòng log

Không khí hoảng loạn nhanh chóng được thay thế bằng sự tập trung cao độ. Cuộc săn lùng “con ma” bắt đầu. Chúng tôi chia nhau ra, mỗi người một nhiệm vụ. Tôi nhận trách nhiệm kiểm tra log của server. Hàng ngàn dòng log vô hồn hiện ra trước mắt, một mớ hỗn độn những thông tin kỹ thuật khô khan. Tôi căng mắt đọc từng dòng, hy vọng tìm thấy một dấu vết, một lời trăn trối nào đó mà server để lại trước khi “chết”.

Nhưng không. Log file sạch đến đáng ngờ. Không một dòng báo lỗi, không một cảnh báo bất thường. Cứ như thể hệ thống chưa từng được khởi chạy. “Con ma” này quá tinh vi, nó ra tay mà không để lại bất kỳ dấu vết nào.

Cả team bắt đầu đưa ra các giả thuyết, những “nghi phạm” tiềm năng nhất trong thế giới lập trình:

• Sai cấu hình môi trường: Liệu có một biến môi trường nào đó trên Production bị thiếu hoặc sai giá trị so với Staging không?
• Vấn đề kết nối Database: Chuỗi kết nối đến cơ sở dữ liệu có đúng không? Tường lửa có chặn kết nối không?
• Phân quyền file/thư mục: Liệu user chạy ứng dụng có đủ quyền đọc/ghi trên các thư mục cần thiết?
• Phiên bản thư viện khác biệt: Một thư viện nào đó trên server Production có phiên bản khác với Staging, gây ra xung đột âm thầm?

Chúng tôi kiểm tra từng thứ một. Mọi thứ đều có vẻ đúng. Áp lực ngày càng đè nặng. Các sếp bắt đầu gọi điện. Mồ hôi túa ra trên trán dù điều hòa trong phòng vẫn chạy vù vù.

Ánh sáng cuối đường hầm: Sự thật trần trụi đến không ngờ

Sau gần 3 tiếng đồng hồ vật lộn trong vô vọng, khi mọi người gần như đã kiệt sức và tính đến phương án rollback (quay lại phiên bản cũ), một cậu thực tập sinh bỗng rụt rè lên tiếng:

“Anh ơi… em thấy cái file cấu hình .env trên Production… nó có tên là .env.example ạ…”

Cả team sững người trong một giây, rồi như bừng tỉnh. Chúng tôi vội vàng SSH vào server. Đúng vậy. Do một sai sót trong kịch bản deploy tự động, thay vì đổi tên file `.env.example` (file cấu hình mẫu) thành `.env` (file cấu hình chính), hệ thống đã bỏ qua bước này. Điều đó có nghĩa là toàn bộ ứng dụng đang chạy mà không có bất kỳ cấu hình nào: không kết nối được database, không đọc được các khóa API, không có gì cả. Nó “chết” là điều tất yếu.

Thủ phạm không phải là một lỗi code phức tạp hay một vấn đề hạ tầng cao siêu. “Con ma” ám ảnh chúng tôi suốt mấy tiếng đồng hồ chỉ là một lỗi sai tên file ngớ ngẩn. Một sự thật trần trụi và có phần hài hước. Anh lead chỉ mất 10 giây để đổi lại tên file. F5 trang web. Logo của Phoenix hiện ra rực rỡ. Hệ thống chạy mượt mà.

Rút ra bài học xương máu từ “bóng ma” production

Đêm đó, chúng tôi không ăn mừng. Chúng tôi ngồi lại, nhìn nhau và rút ra những bài học đắt giá. Câu chuyện này, dù có phần xấu hổ, nhưng lại là một kinh nghiệm không thể nào quên. Để tránh gặp lại “con ma” tương tự, đây là những gì bạn nên làm:

• Tự động hóa tối đa: Quy trình deploy nên được tự động hóa hoàn toàn bằng các công cụ CI/CD. Việc can thiệp thủ công càng ít, sai sót của con người càng giảm.
• Xây dựng Health Check: Ứng dụng của bạn nên có một endpoint (đường dẫn) “health check” để kiểm tra nhanh tình trạng của các dịch vụ liên quan (database, cache,…). Sau khi deploy, hệ thống sẽ tự động gọi vào đây để xác nhận mọi thứ ổn thỏa.
• Luôn có kế hoạch Rollback: Trước khi release, hãy chuẩn bị sẵn một quy trình để quay lại phiên bản cũ một cách nhanh chóng nếu có sự cố. Đây là chiếc phao cứu sinh của bạn.
• Checklist trước khi release: Tạo một danh sách kiểm tra chi tiết tất cả các bước cần thực hiện và các điểm cần xác nhận trước, trong và sau khi deploy. Đừng tin vào trí nhớ.
• Ghi log chi tiết hơn: Cấu hình hệ thống để ghi lại log ngay từ những bước khởi tạo đầu tiên, kể cả khi đọc file cấu hình thất bại. Log càng chi tiết, việc săn “ma” càng dễ dàng.

Không chỉ là một câu chuyện, đó là một phần của nghề dev

Câu chuyện về “con ma” .env đã trở thành một giai thoại trong công ty chúng tôi. Mỗi khi có một dự án mới sắp release, mọi người lại nhắc lại nó như một lời cảnh tỉnh. Những sự cố như thế này, dù căng thẳng và mệt mỏi, nhưng chính chúng lại khiến chúng tôi trưởng thành hơn, cẩn thận hơn và trở thành những lập trình viên giỏi hơn.

Nếu bạn cũng là một người làm trong ngành công nghệ, có lẽ bạn cũng có những câu chuyện “truyện ma” của riêng mình. Đó không phải là điều gì đáng xấu hổ, mà là một phần không thể thiếu trên con đường sự nghiệp. Bởi vì sau mỗi lần “săn ma” thành công, chúng ta lại có thêm kinh nghiệm để đối mặt với những thử thách lớn hơn trong tương lai.