Mục lục bài viết5 mục
Một website tin tức mất khoảng một nửa lưu lượng qua đêm và tìm ra nguyên nhân trong bốn mươi tám giờ nhờ một quy trình chẩn đoán nhanh đã chuẩn bị từ trước. Bài này dựng lại từng giờ họ làm gì và điều kiện để lặp lại.
Số liệu và kết quả trong ví dụ dưới đây là bản dựng cho một tình huống giả định, không phải bản ghi lấy từ một website cụ thể.
Sáu giờ đầu của quy trình chẩn đoán nhanh
Website trong tình huống này là trang tin chuyên ngành xây dựng, khoảng mười hai nghìn bài, xuất bản hai mươi bài mỗi ngày.
Cảnh báo tự động kêu lúc bảy giờ sáng: lưu lượng theo giờ của đêm trước thấp hơn năm mươi phần trăm so với cùng khung giờ tuần trước.
Bước đầu của chẩn đoán nhanh không phải điều tra mà là xác nhận. Người trực mở website bằng ba thiết bị khác nhau, kiểm nó tải được, hiển thị đúng, và không có thông báo lạ. Mất mười lăm phút.
Việc thứ hai là khoanh vùng. Xuất dữ liệu theo trang cho hai ngày, so mức thay đổi. Kết quả: nhóm bài đăng trong ba tháng gần nhất mất gần hết lưu lượng, nhóm bài cũ hơn không đổi.
Đặc điểm này là manh mối quan trọng nhất trong toàn bộ quá trình chẩn đoán nhanh. Mức tụt gắn với thời điểm xuất bản chứ không gắn với chủ đề hay với loại trang, nghĩa là vấn đề nằm ở khâu xử lý bài mới.
Trong sáu giờ đầu, đội không đưa ra giả thuyết nào về nội dung hay về thuật toán. Họ chỉ thu hẹp phạm vi.
Chẩn đoán nhanh giờ thứ sáu tới giờ hai mươi bốn
Manh mối chỉ về khâu xuất bản, nên phần chẩn đoán nhanh tiếp theo đi thẳng vào đó.
Họ lấy mười bài đăng trong tuần trước và chạy công cụ kiểm tra đường dẫn cho từng bài. Kết quả: cả mười đều báo không được index, lý do là có thẻ chặn index trên trang.
Mở mã nguồn một bài, thẻ chặn index nằm ngay trong phần đầu trang. Không ai chủ động thêm nó.
Tiếp theo là truy ngược thời điểm. Họ lấy một bài của bốn tháng trước, mở mã nguồn: không có thẻ đó. Lấy bài của ba tháng trước: có. Thu hẹp dần bằng cách chia đôi khoảng thời gian, sau khoảng một giờ họ xác định được ngày đầu tiên thẻ xuất hiện.
Ngày đó trùng với ngày đội kỹ thuật triển khai một bản cập nhật hệ thống quản trị nội dung.
Nguyên nhân cụ thể: bản cập nhật đổi giá trị mặc định của một trường trong biểu mẫu tạo bài, và trường đó điều khiển thẻ chặn index. Mọi bài tạo mới từ ngày đó đều mang thẻ này.
Giờ thứ hai mươi bốn tới bốn mươi tám: sửa và đẩy nhanh phục hồi
Phần chẩn đoán nhanh kết thúc ở đây, và việc sửa chính mất mười lăm phút: đổi lại giá trị mặc định của trường đó trong cấu hình.
Phần còn lại là xử lý ba tháng bài đã bị ảnh hưởng, khoảng một nghìn tám trăm bài.
Họ viết một đoạn mã chạy hàng loạt để gỡ thẻ chặn index khỏi toàn bộ nhóm bài đó. Việc này mất hai giờ gồm cả thử nghiệm trên môi trường phụ trước.
Sau đó là phần đẩy nhanh việc được ghi nhận lại. Họ sinh lại sitemap, gửi lại sitemap qua bộ công cụ quản trị, và gửi tay khoảng năm mươi bài quan trọng nhất qua công cụ kiểm tra đường dẫn.
Cuối cùng, họ đặt một kiểm tra tự động chạy hàng ngày: lấy ngẫu nhiên năm bài đăng trong hai mươi bốn giờ qua, kiểm chúng không có thẻ chặn index, báo động nếu có.
Kiểm tra này là phần giá trị nhất rút ra từ cả đợt chẩn đoán nhanh, vì nó biến một lỗi mất bốn mươi tám giờ để tìm thành một lỗi được phát hiện trong một ngày.
Kết quả và cách đọc con số
Lưu lượng bắt đầu phục hồi từ ngày thứ tư và trở về khoảng chín mươi phần trăm mức cũ sau ba tuần.
Con số này cần đọc kèm ba lưu ý. Thứ nhất, tốc độ phục hồi nhanh vì nguyên nhân thuộc nhóm kỹ thuật, tức chỉ cần trình thu thập quét lại là xong. Nhóm nguyên nhân về nội dung không phục hồi nhanh như vậy.
Thứ hai, khoảng mười phần trăm không quay lại, chủ yếu là các bài tin thời sự đã hết vòng đời trong ba tháng bị ẩn.
Thứ ba, thiệt hại thật lớn hơn con số lưu lượng, vì suốt ba tháng đó website mất luôn cơ hội xếp hạng cho các tin nóng, và các vị trí đó đã thuộc về đối thủ.
Chỉ số đáng chú ý nhất với đội là thời gian từ lúc lỗi phát sinh tới lúc phát hiện: ba tháng. Thời gian chẩn đoán nhanh chỉ là bốn mươi tám giờ, nhưng nó bắt đầu quá muộn.
Bốn điều kiện để lặp lại được
Điều kiện thứ nhất để chẩn đoán nhanh kịp là có cảnh báo theo giờ chứ không theo tuần. Nếu chỉ xem báo cáo hàng tuần, họ đã mất thêm nhiều ngày trước khi bắt đầu.
Điều kiện thứ hai là chẩn đoán nhanh phải bắt đầu bằng khoanh vùng chứ không bằng giả thuyết. Đội nào bắt đầu bằng việc bàn xem có phải bị phạt thuật toán không sẽ mất nhiều ngày cho một hướng sai.
Điều kiện thứ ba là có nhật ký triển khai của đội kỹ thuật. Không có nó, việc nối mốc thời gian với bản cập nhật hệ thống sẽ dựa vào trí nhớ và thường thất bại.
Điều kiện thứ tư là có quyền chạy mã hàng loạt trên kho bài. Sửa tay một nghìn tám trăm bài là việc không khả thi trong khung thời gian này.
Nghe xong chuyện này, câu đầu tiên người ta hỏi thường là một trong ba câu sau.
=== FAQ === Q: Nên đặt cảnh báo ở ngưỡng bao nhiêu để không bị kêu suốt? A: So lưu lượng theo giờ với cùng khung giờ của tuần trước và đặt ngưỡng ở mức giảm ba mươi phần trăm, cách này ít báo động giả hơn nhiều so với so với hôm qua. Q: Vì sao lỗi tồn tại ba tháng mà không ai phát hiện? A: Vì lưu lượng tổng giảm dần chứ không tụt đột ngột, các bài cũ vẫn kéo lưu lượng và che mất việc bài mới không được index. Q: Kiểm tra tự động hàng ngày nên kiểm những gì? A: Tối thiểu là thẻ chặn index và trạng thái lập chỉ mục của vài bài mới nhất, vì đó là nhóm lỗi âm thầm và gây thiệt hại tích lũy nhất.
Chẩn đoán nhanh không phải là điều tra giỏi mà là thu hẹp phạm vi trước khi đặt giả thuyết. Nên đặt cảnh báo theo giờ và kiểm tra tự động cho bài mới ngay trong tuần này, vì phần tốn kém của sự việc này không nằm ở bốn mươi tám giờ điều tra mà ở ba tháng không ai biết.
