Nhân dịp spriderum hiện cái màn hình huyền thoại, bảo trì không hứa trước thì mình ra bài viết này để khỏa lấp sự trống vắng cho cái hẹn lên bài hằng tuần của mình.
Bạn nghĩ một website hiện thông báo như vậy thì sẽ có những khả năng gì mà hệ thống không thể tiếp tục chạy được.
Đầu tiên phải nói là bất kỳ trang web nói chung và spiderum nói riêng thì chắc chắn sẽ có những thời điểm gặp trường hợp như vậy, kể cả facebook hay google đều xảy ra rất nhiều lần. Vậy nguyên nhân sâu xa thực sự là gì? 
Đây là một bài viết phỏng đoán dựa trên kinh nghiệm lập trình của bản thân mà thôi nhé, mình không nằm trong đội ngũ phát triển và cũng không biết chiến lược tương lai của spiderum nên nếu có gia cát dự bừa thì xin mọi người thứ lỗi.
Nguyên nhân thứ nhất có thể xảy ra là sắp ra mắt một tính năng mới. Thường thì một website một khi đã GoLive vận hành thực tế rồi thì luôn phát sinh những nhu cầu mới, dựa vào đó mà team phát triển sẽ có những kế hoạch chiến lược để triển khai những tính năng mới đáp ứng nhu cầu của người dùng. Bởi vậy mới nói khi thiết kế một hệ thống luôn phải chừa đường lui cho vấn đề này, làm sao thiết kế để dễ dàng thay thế và thêm mới nhất có thể. Các design patterns hay các mẫu kiến trúc sinh ra để đáp ứng những mục tiêu này mà. 
Quay trở lại với vấn đề triển khai tính năng mới thì nếu kiến trúc đủ tốt thì sẽ phân tách các cụm chức năng thành từng nhóm để đảm bảo triển khai độc lập và không ảnh hưởng đến chức năng khác đang sử dụng. Khi này có 2 cách triển khai đó là đánh version cho tính năng rồi triển khai theo version độc lập và thứ hai là triển khai theo từng services (theo mô hình microservices) khi đưa thay thế hoặc loại bỏ 1 service thì các service khác không bị ảnh hưởng.
Tuy nhiên đối với những tính năng mang tính ảnh hưởng toàn cục cần thay thế gần như toàn bộ versions hay services thì cần phải có thời gian downtime và chờ các thành phần sẵn sàng hết mới có thể đưa lên toàn bộ. Thế là một màn hình chờ với giao diện tĩnh được sinh ra tạm thời để tên miền người dùng đang truy cập điều hướng tới nhằm thông báo và tránh những lỗi phát sinh từ phía người dùng truy cập tới khi hệ thống chưa sẵn sàng.
Nguyên nhân thứ hai có thể xảy ra là lỗi hệ thống từ việc chưa kiểm thử phủ hết tất cả các trường hợp có thể xảy ra. Một hệ thống được vận hành thực tế có lẽ sẽ có những điều khó lường mà đội phát triển không nghĩ tới. Ví dụ như tính năng A ảnh hưởng tới tính năng B chỉ khi xuất hiện tác động C; Hay những trường hợp validate bị sót khi có một ai đó can thiệp qua middleware mà không sử dụng qua giao diện; dữ liệu người dùng thật khác xa với những mẫu kiểm thử; dữ liệu thật quá lớn khiến hệ thống quá tải vào bị sập khi lượng băng thông và request tới quá nhiếu… Có muôn vàn lý do cho những thứ như thế này, nhưng nếu hệ thống được triển khai chặt chẽ sẽ giảm thiểu những rủi ro này ít nhất có thể. 
Khi những lỗi này xảy ra, mới đầy team phát triển chưa xác định nguyên nhân ngay. Có một vài kỹ thuật có thể giúp đội ngũ có thể phát hiện và truy vết lỗi như Logging, Tracing, Debugging… Khi truy vết được nguyên nhân lỗi rồi thì họ mới có thể bắt tay vào vá lỗi đó. Quá trình này chắc chắn tốn thời gian dù ít hay nhiều. Để không ảnh hưởng đến người dùng thật thì phải sử dụng đến màn hình trên mà thôi.
Nguyên nhân thứ ba khách quan hơn là bị tấn công. Hách cơ đầy rẫy ngoài kia và tâm tà của họ lại ngó nghiêng website của bạn. Thế thời ngầm này thật sự rất phức tạp như kiểu tội phạm và công an ý, đội phát triển nhưng những người phòng thủ khi bị tấn công. Bên địch quá mạnh không thể phòng thủ nổi thì cách tốt nhất là tắt server đi ngủ giấc, thực hiện kế sách vườn không nhà trống và hi vọng ngày mai hacker không chọn web mình làm mục tiêu nữa =)))
Nói vui vậy thôi chứ một khi đã bị tấn công thì trước khi trách người thì cũng phải trách mình. Do mình bỏ sót những lỗ hổng về bảo mật thì mới tạo cơ hội cho đối phương tấn công được chứ. Vậy nên cố gắng xây dựng những hệ thống kiên cố và liên tục cập nhật những thủ thuật tấn công để biết mình biết ta mà có thể phòng thủ xuất sắc được chứ nhỉ. 
Khi bạn dành thời gian vá lỗ hổng hệ thống khi bị tấn công thì cũng lại cần thời gian downtime. Đây là một nguyên nhân nữa xuất hiện màn hình trên.
Nguyên nhân cuối cùng là tác động môi trường ngoại cảnh chẳng liên quan gì đến team dev cả. Ví dụ như hết tiền vận hành, không phát triển được nữa. Khi không có tiền nuôi nó thì bán đi thôi. Nhiều công ty cũng bị các cá mập thâu tóm mà. Hay dính đến phát luật, bản quyền, thương hiệu, chính trị khiến cho website buộc phải gỡ xuống tạm thời để giải quyết những vấn đề liên quan đó. Cho đến khi mọi thứ ổn thỏa hết thì sẽ trở lại thôi.
Bài viết phân tích sơ bộ những trường hợp có thể xảy ra mà mình thấy phổ biến dựa trên góc độ cá nhân. Hi vọng có thể giúp bạn hiểu hơn về quá trình vận hành và phát triển một hệ thống website.
#ntechdevelopers