Tại sao các trang web (thậm chí là trang này) đôi khi là Down Down để bảo trì?

Cá nhân tôi chưa bao giờ làm điều này. Tôi không hiểu tại sao rất nhiều trang web làm như vậy, nếu bạn phát triển trên một máy chủ phát triển thì tại sao bạn lại cần phải đóng cửa trang web sản xuất của mình?

Tôi đã luôn tự hỏi về điều này.

Họ đang làm gì trong thời gian này, những gì đòi hỏi phải làm điều này?

Cú hích lớn cho bất cứ điều gì với quy mô lớn là nếu một người đang thay đổi lược đồ cơ sở dữ liệu theo một cách nào đó, người ta thường có một số kịch bản bảo trì lớn, khó chịu để chạy.

Bây giờ, chúng có thể mất một giây hoặc lâu hơn để chạy với tập dữ liệu phát triển của bạn. Nhưng khi bạn bắt đầu đo dữ liệu bằng terabyte và petabyte, thậm chí việc thêm một cột vào bảng có thể mất nhiều giờ.

Vì vậy, cho dù triển khai nhanh và tự động như thế nào, bạn vẫn gặp phải các vấn đề về bảo trì dữ liệu. Nếu bạn có kế hoạch thực sự tốt, bạn có thể đưa ra một tấm gương chỉ đọc của trang web trong khi bạn đang trải qua quá trình, nhưng đối với nhiều trang web chỉ đọc là vô nghĩa và do đó không đáng nỗ lực.

Có một số lý do tại sao bạn có thể muốn đưa một trang web xuống để bảo trì. Đến tên một vài:

• Thay đổi cơ sở dữ liệu
• Thay đổi DAL
• Cập nhật dịch vụ

Về cơ bản, nếu trang web của bạn không tĩnh, khi thực hiện cập nhật logic, bạn muốn gỡ xuống nếu không mọi người nhấn trang web của bạn có thể nhận được lỗi hoặc hành vi không mong muốn.

Ngoài ra, nếu bạn sẽ chạm vào web.config (trong ASP.NET) cho trang web của mình, bạn nên gỡ nó xuống để bảo trì trước vì nó sẽ thổi ra phiên cho người dùng. Vì vậy, nếu họ ở giữa một cái gì đó, nó sẽ bị mất.

Vâng, đây là một câu hỏi trừu tượng - tôi thậm chí đã thấy các trang web sử dụng "Xuống để bảo trì" thay vì HTTP 500.

Đối với các trang web đôi khi bạn cần phải thực hiện một số nâng cấp. Ví dụ: nếu bạn đang thay đổi cơ sở dữ liệu, bạn không muốn bất kỳ người dùng nào khác chạm vào cơ sở dữ liệu trong thời gian đó. Nếu cơ sở dữ liệu ngoại tuyến, trang web cũng phải được tắt một cách duyên dáng vì hiển thị SqlException không đẹp lắm. Một lý do khác là một số lỗi CTNH hoặc lỗi hệ thống (như rò rỉ tài nguyên) đòi hỏi phải có ứng dụng hoặc thậm chí khởi động lại hệ thống.

Khi tôi tham gia nâng cấp hệ thống ngân hàng internet tại một trong những ngân hàng lớn nhất ở nước tôi. Toàn bộ quá trình nâng cấp các trang web, tầng trung gian và cơ sở dữ liệu mất ba ngày khi hệ thống ngoại tuyến cho khách hàng. Nó cũng bao gồm sao lưu toàn bộ mọi thứ để trong trường hợp thất bại, hệ thống có thể được hoàn nguyên về phiên bản cũ.

Máy chủ cần bản vá để được chạy và trên nhiều hệ điều hành, những bản vá đó yêu cầu khởi động lại. Vì vậy, đó là một loại thời gian xuống. Nhiều công ty lên lịch khởi động lại từ các bản vá cho thời gian sử dụng thấp, chẳng hạn như sáng Chủ nhật. Nếu không có bản vá, họ vẫn khởi động lại máy chủ vào thời gian bảo trì thường xuyên theo lịch trình (đây là thời gian chờ đợi từ ngày NT4 khi một số bộ đếm bị tràn mỗi tuần rưỡi, do đó, việc khởi động lại hàng tuần đã ngăn chặn các lỗi khác).

Một công ty tôi làm việc đã có một trang web thương mại điện tử trở lại vào cuối những năm 90 mang lại doanh thu hơn 1.000.000 đô la mỗi tháng. Ai đó đã quảng cáo bảng thuế sai cho máy chủ cơ sở dữ liệu sản xuất. Cách chữa là khôi phục máy chủ db từ bản sao lưu và áp dụng các giao dịch kể từ lần sao lưu cuối cùng. Điều này mất vài giờ, trong thời gian đó trang web không có sẵn để nhận đơn đặt hàng. Vì phần đơn đặt hàng và các tài liệu quảng cáo bán hàng tĩnh đang chạy trên cùng một trang và không thể tách rời, cả hai phải xuống.

Một công ty tôi làm việc đã đưa một số văn bản sai vào vị trí sai và CEO đã lật ra và đưa trang web ra khỏi dòng "để bảo trì" trong khi bố cục và văn bản bị "sửa" và nạn nhân thích hợp đổ lỗi và sa thải.

Trong khi các câu trả lời khác là chính xác, bạn hầu như luôn có thể tránh được thời gian chết bằng cách sử dụng các kiến ​​trúc đúng. Nhưng điều này có một chi phí, và chi phí này có thể không đáng: một giờ thời gian chết chi phí amazon hoặc cơ sở hạ tầng đằng sau NASDAQ rất nhiều. Dòng chảy chồng chất? Nhiều khả năng không quá nhiều.

Làm thế nào để tránh thời gian chết:

• tắt các trang phục vụ phần cứng: nếu bạn có proxy trước trang web của mình, thay vào đó bạn có thể đặt chúng ngoại tuyến mà không có bất kỳ tác động nào đến người dùng
• cấu hình lại máy chủ: giống như trên
• cập nhật / thay đổi dữ liệu trong cơ sở dữ liệu: bạn có thể đặt trang web của mình ở chế độ chỉ đọc, v.v ...

Nói chung, trong một kiến ​​trúc phân lớp, bạn càng ở gần "đỉnh", bạn càng khó tránh khỏi thời gian chết, tương tự đối với trạng thái (máy chủ web so với cơ sở dữ liệu).

Một trang web có thể lên lịch ngừng hoạt động thường xuyên ngay cả khi không có gì để làm mỗi khi thời gian ngừng hoạt động theo lịch trình xuất hiện. Bằng cách làm như vậy, họ có được người dùng sử dụng với ý tưởng rằng các trang web sẽ xuống trong một khoảng thời gian nhất định tất cả vì vậy thường để khi công việc không cần thiết phải được thực hiện, người dùng sẽ không phàn nàn rất nhiều.

Ngoài ra còn có một khía cạnh tâm lý và tiếp thị cho điều này. Trong một số trường hợp (tôi dám nói hầu hết các trường hợp nhưng tôi không in đậm * g *) khi đọc "Xuống để bảo trì" cũng có thể có nghĩa là "Máy chủ đã bị sập hoặc hết dịch vụ vì bất kỳ lý do nào khác".

Tôi đã thấy điều này khá thường xuyên. Thông thường, với tư cách là nhà phát triển, bạn sẽ muốn có một thông báo lỗi "thực sự" có nội dung như "Rất tiếc, chúng tôi hiện đang tải rất cao và không phải tất cả các yêu cầu đều có thể được xử lý" nhưng một số người từ tiếp thị sẽ nói với bạn "anh bạn, bạn không thể nói với khách hàng rằng chúng tôi đang gặp sự cố. Hãy nói với họ rằng chúng tôi đang bảo trì theo lịch trình - điều này sẽ tốt hơn rất nhiều ".

Vì vậy, "Xuống để bảo trì" thường chỉ là một thuật ngữ khác cho "hết dịch vụ".

Không cần máy chủ để xuống bảo trì. Bạn có thể tránh làm như vậy cho bất cứ điều gì, ở bất kỳ quy mô nào, thay đổi DB, cập nhật máy chủ, v.v.

Vấn đề là một hệ thống thời gian chết 0, ở một quy mô nhất định, rất tốn kém để tạo và duy trì. Bạn cần dự phòng ở mọi nơi, cân bằng tải ở mọi nơi, sao chép dữ liệu, đồng bộ hóa. Đó là những vấn đề khó khăn.

Về cơ bản, bạn cần đạt đến mức có thể phát hành Netflix Chaos Monkey để đảm bảo nó hoạt động ngay cả khi một phần trong hệ thống của bạn bận với bản cập nhật hoặc không đồng bộ hóa. Điều này chắc chắn là có thể làm được. Nó cũng rất tốn kém, đòi hỏi nhiều thời gian và nhiều chuyên gia để giải quyết vấn đề.

Đặt một trang web ở chế độ bảo trì có thể là một nền tảng trung gian bạn chọn, bởi vì bạn không muốn đầu tư nhiều như vậy chỉ để tránh làm mất trang web của bạn trong một thời gian ngắn.

Kinh tế học.

Tất nhiên, nếu bạn chọn con đường thời gian 0down, trang web của bạn sẽ đạt được nhiều thứ hơn là chỉ có sẵn, nó cũng sẽ có được độ tin cậy, vì những thực tiễn tốt nhất đó phục vụ cả hai mục đích.

Tôi không hiểu tại sao rất nhiều trang web làm như vậy, nếu bạn phát triển trên một máy chủ phát triển thì tại sao bạn lại cần phải đóng cửa trang web sản xuất của mình?

Chết tiệt xảy ra. Trừ khi bạn đang thực hiện một số hình thức xác minh toán học của các sản phẩm của bạn ( và thông số kỹ thuật của bạn là hợp lệ ), cho dù bạn có cẩn thận đến đâu đi chăng nữa, shit vẫn xảy ra.

Ngoài ra, đôi khi bạn có thể phải thay đổi một phần chính của cơ sở hạ tầng của mình (giả sử thay đổi cấu trúc cơ sở dữ liệu của bạn) đòi hỏi phải có thời gian ngừng hoạt động.

Trừ khi bạn đang phát triển một hệ thống quan trọng (giả sử là hệ thống năm chín hoặc sáu chín ), điều có trách nhiệm và hiệu quả về chi phí phải làm là xây dựng một hệ thống với sự chấp nhận xuống cấp như một phần của thực tế.

Hơn nữa, bạn thực hiện nguyên tắc đó hơn nữa bằng cách giảm thời gian quản lý và có thể tuân theo lịch trình (hoặc ít nhất là có thể phát hiện được) với sự hiểu biết rõ ràng và quy trình để phục hồi hiệu quả.

Khi trang web của chúng tôi bị tấn công (máy chủ IIS6 và Windows 2003 cũ cách đây vài năm). trong khi chúng tôi đang tiến hành khôi phục, chúng tôi đã đặt trang "đang bảo trì" trong vài giờ ....