Debugging Production Issues at 2 AM: A Survival Guide [Tiếng Việt]

# Khắc phục sự cố sản xuất lúc 2 giờ sáng: Hướng dẫn sống sót 2:17 sáng. PagerDuty. Thông báo cho biết tỷ lệ lỗi 95% trên dịch vụ thanh toán. 847 giao dịch bị ảnh hưởng. Dạ dày bạn thắt lại. Bạn tỉnh dậy ngay lập tức—chất adrenaline đặc biệt mà chỉ xuất hiện từ những sự cố sản xuất. Điện thoại của bạn đã được mở khóa, laptop đang khởi động, máy pha cà phê sôi lên chỉ bằng trí nhớ cơ bắp. Đây là trang số 847 trong sự nghiệp của bạn. Đúng vậy, bạn theo dõi nó. Bạn bắt đầu đếm sau trang 200 khi nhận ra đây sẽ là một phần quyết định trong cuộc sống nghề nghiệp của bạn, và nếu bạn sắp bị đánh thức vào những giờ không thể tưởng tượng nổi, bạn có thể đến dữ liệu về nó. Dịch vụ thanh toán. Dĩ nhiên đó là dịch vụ thanh toán. Luôn luôn là dịch vụ thanh toán, hoặc lớp xác thực, hoặc một microservice mà ai đó đã thề là "chỉ là một lớp bọc đơn giản" ba năm trước và đã phát triển thành một phụ thuộc đường mòn quan trọng cho một nửa cơ sở hạ tầng của bạn. Bạn có thể có khoảng 90 giây trước khi trang thứ hai được gửi đến người quản lý của bạn. Có thể ba phút trước khi khách hàng bắt đầu tràn vào các kênh hỗ trợ. Có thể năm phút trước khi một người nào đó từ C-suite tỉnh dậy và bắt đầu hỏi han trong Slack. Đồng hồ đang điểm, tay bạn đang di chuyển, và não bạn đã bắt đầu chạy qua danh sách kiểm tra tâm lý mà bạn đã xây dựng qua hàng trăm sự cố như thế này. Đây không phải là lần đầu tiên của bạn. Nhưng đây là điều không ai nói với bạn về việc gỡ lỗi sản xuất lúc 2 giờ sáng: nó không bao giờ dễ hơn. Bạn chỉ trở nên nhanh hơn. Bạn xây dựng những công cụ tốt hơn. Bạn mắc ít lỗi ngớ ngẩn hơn. Bạn học cách tin tưởng vào bản năng của mình trong khi đồng thời nghi ngờ mọi thứ. Bạn phát triển một giác quan thứ sáu để phân biệt cái gì thực sự bị hỏng và cái gì chỉ trông có vẻ bị hỏng. Và điều quan trọng nhất là, bạn học rằng sự khác biệt giữa một sự cố 10 phút và một sự cố 4 giờ thường phụ thuộc vào 60 giây đầu tiên của phản ứng của bạn. Hướng dẫn này là tất cả những gì tôi ước ai đó đã nói với tôi trước khi đến trang số 1.

60 Giây Đầu Tiên: Triage Như Thể Công Việc Của Bạn Phụ Thuộc Vào Nó

Phút đầu tiên của bất kỳ sự cố sản xuất nào là quản lý hỗn loạn thuần túy. Não của bạn vẫn đang khởi động, có thể bạn không mặc quần, và bạn cần đưa ra những quyết định quan trọng sẽ xác định liệu sự cố này có được giải quyết trong vòng vài phút hay vài giờ. Dưới đây là những gì tôi làm, theo thứ tự, mỗi lần: Thừa nhận trang ngay lập tức. Đừng chờ để "điều tra trước." Hãy thừa nhận. Điều này dừng chuỗi leo thang và ra tín hiệu cho đội ngũ của bạn rằng có ai đó đang xử lý. Tôi đã thấy quá nhiều sự cố mà nhiều người bị gọi vì người phản ứng đầu tiên muốn "chỉ xem qua một chút" trước khi thừa nhận. Những 30 giây điều tra đó đã khiến bạn mất những phản ứng viên dự phòng có thể đã đang ngủ. Mở bảng điều khiển phản ứng sự cố của bạn. Không phải ứng dụng. Không phải nhật ký. Bảng điều khiển của bạn. Bảng cho bạn thấy tình trạng hệ thống ngay cái nhìn đầu tiên. Với tôi, đó là một bảng Grafana tùy chỉnh cho thấy tỷ lệ lỗi, phân vị độ trễ, bể kết nối cơ sở dữ liệu, độ sâu hàng đợi và CPU/ bộ nhớ trên tất cả các dịch vụ quan trọng. Tôi có thể thấy phạm vi vụ nổ trong dưới 5 giây. Kiểm tra xem nó còn đang xảy ra không. Nghe có vẻ hiển nhiên, nhưng tôi đã bị gọi cho những vấn đề đã tự giải quyết cách đây 30 giây trước khi cảnh báo vang lên. Hệ thống giám sát có độ trễ. Ngưỡng cảnh báo có khoảng thời gian đánh giá. Đôi khi vấn đề đã biến mất, và bạn cần biết điều đó trước khi bắt đầu lùi lại các lần triển khai hoặc khởi đông lại các dịch vụ. Đánh giá tác động lên khách hàng. Không phải tác động lý thuyết—tác động thực tế. Bao nhiêu người dùng đang bị ảnh hưởng ngay bây giờ? Nó có phải là 100% lưu lượng hay 5%? Có phải là chỉ tại một khu vực, một phân khúc khách hàng, một tính năng? Điều này xác định mức độ khẩn cấp trong phản ứng của bạn và liệu bạn có cần đánh thức thêm người nào nữa. Trong sự cố cụ thể này—dịch vụ thanh toán lúc 2:17 sáng—bảng điều khiển của tôi đã cho tôi biết mọi thông tin tôi cần biết trong 8 giây. Tỷ lệ lỗi: 94.7%. Yêu cầu bị ảnh hưởng: 847 trong 5 phút vừa qua. Phân bố địa lý: toàn cầu. Phân khúc khách hàng: tất cả. Độ trễ API nhà cung cấp thanh toán: bình thường. Kết nối cơ sở dữ liệu: bình thường. Vấn đề không phải ở phía trên hay phía dưới. Nó ở chúng tôi. Đó là khi tôi biết rằng tôi sẽ có một đêm dài.

Phương Pháp Gỡ Lỗi Thực Sự Hiệu Quả Dưới Áp Lực

Mọi người đều có một phương pháp gỡ lỗi khi họ bình tĩnh, được caffein, và làm việc trên một môi trường phát triển vào lúc 2 giờ chiều. Rất ít người có một phương pháp đảm bảo hiệu quả khi bạn đang buồn ngủ, Giám đốc điều hành đang ở trong kênh sự cố, và mỗi giây ngừng hoạt động đang tiêu tốn tiền thực. Tôi sử dụng cái mà tôi gọi là phương pháp "Phạm vi vụ nổ đến Nguyên nhân gốc rễ". Nó không cầu kỳ, nhưng nó hoạt động khi não bạn đang chạy ở 60% công suất. Bắt đầu với phạm vi vụ nổ, không phải nguyên nhân gốc rễ. Điều này có vẻ phản trực giác. Mọi bản năng đều bảo bạn phải tìm kiếm nguyên nhân gốc rễ ngay lập tức. Hãy kiềm chế bản năng đó. Trước tiên, hãy hiểu chính xác cái gì bị hỏng và cái gì không. Vạch ra ranh giới của sự cố. Điều này phục vụ hai mục đích: nó ngăn bạn đuổi theo những thứ sai lệch trong các hệ thống khỏe mạnh, và nó thường chỉ ra nguyên nhân gốc rễ thông qua quy trình loại trừ. Đối với sự cố dịch vụ thanh toán, tôi đã dành 90 giây để vạch ra phạm vi vụ nổ: - Khởi tạo thanh toán: thất bại - Kiểm tra trạng thái thanh toán: thất bại - Webhook thanh toán: thất bại - Xử lý hoàn tiền: hoạt động tốt - Truy vấn thanh toán quản trị: hoạt động tốt Mô hình đó đã cho tôi biết điều gì đó quan trọng: các thao tác đọc là ổn, các thao tác ghi đang thất bại. Đó là một vấn đề về cơ sở dữ liệu, một vấn đề về hàng đợi, hoặc một vấn đề về quyền. Ba khả năng thay vì ba mươi. Thực hiện theo luồng dữ liệu, không theo luồng mã. Khi bạn đang gỡ lỗi vào lúc 2 giờ sáng, bạn không có thời gian để theo dõi mã. Hãy theo luồng dữ liệu. Yêu cầu thanh toán vào hệ thống từ đâu? Nó đi đâu tiếp theo? Nó thất bại ở đâu? Tôi đã kéo lên phân tích phân phối của chúng tôi (cảm ơn Chúa chúng tôi đã có) và theo dõi một yêu cầu duy nhất đi qua hệ thống. Nó đã qua xác thực, qua giới hạn tốc độ, qua xác thực và chết ngay khi nó cố gắng ghi vào cơ sở dữ liệu. Cơ sở dữ liệu. Nó ở đó. Kiểm tra những thứ nhàm chán trước. Không gian đĩa. Bộ nhớ. Bể kết nối. Bộ mô tả tệp. Hết hạn chứng chỉ. DNS. Những thứ nhàm chán giết chết nhiều hệ thống sản xuất hơn là các lỗi thông minh. Tôi đã được gọi vào lúc 2 giờ sáng vì công việc cron của ai đó đã chiếm không gian đĩa. Tôi đã được gọi vì một chứng chỉ đã hết hạn. Tôi đã được gọi vì ai đó đã thay đổi TTL DNS và không chờ đợi để nó truyền tải. Trong trường hợp này, bể kết nối cơ sở dữ liệu đã đạt 100%. Mọi kết nối đều đang được sử dụng. Nhưng tại sao? Lưu lượng không tăng vọt. Mẫu truy vấn không thay đổi. Có điều gì đó đang giữ các kết nối mở. Tin tưởng vào giám sát của bạn, nhưng xác minh mọi thứ. Các hệ thống giám sát có thể sai. Không phải với ý định xấu—đó chỉ là phần mềm, và phần mềm có lỗi. Tôi đã thấy các hệ thống giám sát báo cáo dịch vụ khỏe mạnh mà thực sự lại hoàn toàn xuống. Tôi đã thấy chúng báo cáo lỗi không tồn tại. Luôn xác minh đường đi quan trọng một cách thủ công. Đối với hệ thống thanh toán, tôi giữ một thẻ tín dụng kiểm tra và một lệnh curl sẵn sàng. Tôi có thể xác minh toàn bộ quy trình thanh toán trong 10 giây. Tôi đã chạy thử nghiệm thanh toán của mình. Nó bị treo trong 30 giây và hết thời gian. Hệ thống giám sát không sai. Chúng tôi thực sự đã xuống.

Sự Cố Đã Dạy Tôi Tất Cả Về Kết Nối Cơ Sở Dữ Liệu

Hãy để tôi kể cho bạn về trang số 312. Nó là 3:47 sáng vào một ngày thứ Ba tháng Ba, và nó đã thay đổi cách tôi nghĩ về quản lý kết nối cơ sở dữ liệu mãi mãi. Chúng tôi đang tổ chức một đợt giảm giá Flash. Lưu lượng truy cập cao nhưng không phải là chưa từng có—chúng tôi đã xử lý những cú sốc lớn hơn. Rồi bỗng nhiên, mọi dịch vụ liên quan đến cơ sở dữ liệu bắt đầu bị hết thời gian. Bể kết nối mất hiệu lực. Triệu chứng cổ điển. Phản ứng hiển nhiên: tăng kích thước bể kết nối. Vì vậy, chúng tôi đã làm vậy. Chúng tôi đã gấp đôi nó. Sau đó chúng tôi đã gấp ba lần. Vấn đề trở nên tồi tệ hơn. Đó là khi tôi học được rằng đôi khi giải pháp làm vấn đề trở nên tồi tệ hơn. Mỗi kết nối mà chúng tôi thêm vào bể là một kết nối khác cố gắng thực hiện truy vấn trên một cơ sở dữ liệu đã quá tải. Chúng tôi đang tự DDoS chính mình. Vấn đề thực tế? Một nhà phát triển đã thêm một tính năng mới thực hiện quét toàn bộ bảng trên một bảng có 50 triệu hàng. Không có chỉ mục. Truy vấn mất 45 giây để hoàn thành. Mọi yêu cầu chạm vào mã đó giữ một kết nối cơ sở dữ liệu trong 45 giây. Với đủ lưu lượng, chúng tôi đã làm cạn kiệt bể kết nối không phải vì chúng tôi không có đủ kết nối, mà vì mỗi kết nối đều bị mắc kẹt chờ đợi truy vấn tồi tệ đó hoàn thành. Giải pháp không phải là thêm nhiều kết nối. Mà là dừng truy vấn đó, thêm một chỉ mục và thực hiện thời gian chờ truy vấn ở cấp độ ứng dụng. Sự cố đó đã dạy tôi ba điều: Mất kết nối bể không phải là một bệnh mà chỉ là triệu chứng. Khi bạn thấy điều này, đừng lập tức tăng kích thước bể. Hãy hỏi tại sao các kết nối không được giải phóng. Có phải truy vấn chậm? Có phải có tình trạng deadlock không? Có điều gì đó đang giữ giao dịch mở không? Bể kết nối đang cho bạn biết có vấn đề ở nơi khác. Thời gian chờ truy vấn nên có khắp nơi. Mỗi truy vấn cơ sở dữ liệu nên có thời gian chờ. Mỗi yêu cầu HTTP nên có thời gian chờ. Mỗi thao tác hàng đợi nên có thời gian chờ. Thời gian chờ không phải là tùy chọn. Chúng là sự khác biệt giữa một dịch vụ bị suy giảm và một dịch vụ hoàn toàn chết. Khi có điều gì đó sai, thời gian chờ giúp bạn thất bại nhanh hơn thay vì tích lũy các kết nối bị chặn cho đến khi toàn bộ hệ thống sụp đổ. Giám sát mức sử dụng bể kết nối không đủ. Bạn cần theo dõi thời gian sống của kết nối. Kết nối trung bình được giữ bao lâu? P99 là gì? Nếu thời gian sống trung bình của kết nối của bạn đột ngột tăng từ 50ms lên 5 giây, bạn có một vấn đề ngay cả khi bể của bạn chưa bị cạn kiệt. Đó là hệ thống cảnh báo sớm của bạn. Quay trở lại sự cố dịch vụ thanh toán lúc 2:17 sáng. Tôi đã kiểm tra thời gian sống của kết nối. Trung bình: 8 giây. P99: