VPS

Đọc log crash và sửa lỗi cùng Claude Code

Thanh Nguyễn Đăng 9 phút đọc 3 khối lệnh

Đọc log crash và sửa lỗi cùng Claude Code
Mục lục bài viết
  1. Chuẩn bị dấu vết cho đọc được
  2. Đưa đủ bối cảnh
  3. Bắt giải thích trước khi sửa
  4. Bốn bước gỡ lỗi có kỷ luật
  5. Khi nhật ký quá dài
  6. Bốn thứ phải có trong một báo cáo sự cố
  7. Vì sao phải bắt giải thích trước khi sửa
  8. Tái hiện, thu hẹp, xác nhận rồi mới sửa
  9. Khi nhật ký quá dài để đọc hết
  10. Câu hỏi thường gặp
  11. Bài viết liên quan

Trả lời nhanh: Agent gỡ lỗi tốt khi bạn đưa đủ ba thứ: dấu vết lỗi đã được giải mã chứ không phải chuỗi ký tự rối, bối cảnh xảy ra gồm phiên bản ứng dụng và loại thiết bị, và đoạn code liên quan. Thiếu cái đầu thì nó đoán mò. Nguyên tắc quan trọng nhất: bắt nó giải thích nguyên nhân trước khi cho sửa, vì sai lầm phổ biến nhất là sửa chỗ báo lỗi trong khi nguyên nhân nằm ở nơi khác.

Lỗi trên máy người dùng khó hơn lỗi trên máy bạn ở chỗ bạn không tái hiện được. Tất cả những gì có là dấu vết lỗi và vài dòng nhật ký. Bài này nói cách dùng agent cho hiệu quả trong tình huống thiếu thông tin đó.

Chuẩn bị dấu vết cho đọc được

Dấu vết lỗi từ bản phát hành thường bị rút gọn thành chuỗi ký tự vô nghĩa, vì mã nguồn đã được làm rối để giảm dung lượng. Đưa nguyên chuỗi đó cho agent thì nó chỉ đoán.

Bạn cần giải mã bằng file ánh xạ được sinh ra lúc đóng gói. Việc bắt buộc: lưu file ánh xạ của mỗi bản phát hành, kèm theo mã phiên bản. Không có nó thì mọi dấu vết từ bản đó vĩnh viễn không đọc được.

Hãy đưa việc này vào luồng phát hành tự động: mỗi lần tạo bản phát hành thì lưu file ánh xạ vào nơi an toàn cùng với bản đó, theo cách trong bài về tự động hóa phát hành.

Đưa đủ bối cảnh

Một dấu vết trơ trọi cho rất ít thông tin. Bốn thứ nên kèm theo:

TerminalĐưa đủ bối cảnhbash
Loi xay ra tren ban 3.2.1, Android 14, dong may pho bien o VN.Tan suat: khoang 40 lan moi ngay, deu tren nhieu thiet bi.Bat dau xuat hien tu ban 3.2.0. Dau vet da giai ma:[dan dau vet o day] Man hinh lien quan: lib/screens/orders.dartLuong dan toi: mo danh sach don, keo xuong de tai them

Dòng bắt đầu xuất hiện từ bản nào giá trị nhất trong cả khối: nó thu hẹp phạm vi xuống đúng những thay đổi giữa hai bản. Rất nhiều lần bạn tìm ra nguyên nhân chỉ bằng cách xem phần khác biệt giữa hai phiên bản đó.

Dòng tần suất cũng quan trọng: lỗi xảy ra đều trên nhiều thiết bị là lỗi logic, còn lỗi chỉ trên một dòng máy thường là chuyện tương thích.

Bắt giải thích trước khi sửa

Đây là bước quyết định chất lượng. Cách yêu cầu:

TerminalBắt giải thích trước khi sửabash
Doc dau vet nay va giai thich nguyen nhan.Chua sua gi ca. Tra loi ba y:1. Cho nao trong code nem ra loi nay2. Vi sao gia tri o do lai khong hop le3. Nhung duong nao dan toi trang thai do Neu chua du thong tin, noi ro can them gi.

Ý thứ ba là phần giá trị nhất và cũng là phần agent hay bỏ qua nếu bạn không hỏi. Chỗ báo lỗi và nơi sinh ra lỗi thường khác nhau: một giá trị rỗng nổ ở màn hình hiển thị, nhưng nó rỗng vì lớp gọi dữ liệu trả về sai từ mấy bước trước.

Sửa ở chỗ nổ là thêm một lần kiểm tra rỗng, và lỗi biến mất. Nhưng dữ liệu vẫn sai, và nó sẽ nổ ở chỗ khác vào tuần sau.

Bốn bước gỡ lỗi có kỷ luật

  1. Thu thập: dấu vết đã giải mã, tần suất, phiên bản bắt đầu xuất hiện.
  2. Thu hẹp: xem phần khác biệt giữa bản không lỗi và bản có lỗi. Đây là bước cắt giảm phạm vi mạnh nhất.
  3. Giải thích: bắt agent nêu nguyên nhân và đường dẫn tới trạng thái đó, chưa sửa.
  4. Sửa và chứng minh: sửa đúng nguyên nhân, rồi viết một ca kiểm thử tái hiện tình huống đó để nó không quay lại.

Bước bốn hay bị bỏ vì lỗi đã hết và mọi người muốn đi tiếp. Nhưng một ca kiểm thử tái hiện đúng lỗi vừa sửa là thứ ngăn nó tái xuất sau ba tháng, khi ai đó sửa một chỗ khác. Cách viết kiểm thử cho ứng dụng di động nằm ở bài về test tự động.

Khi nhật ký quá dài

File nhật ký hàng nghìn dòng là tình huống thường gặp và cũng là chỗ tốn ngữ cảnh nhất. Ba cách xử lý:

  • Lọc trước khi đưa vào. Chỉ lấy phần quanh thời điểm lỗi, hoặc lọc theo từ khóa.
  • Giao cho phiên con. Bảo nó đọc cả file rồi trả về tối đa mười dòng phát hiện, theo cách trong bài về subagent.
  • Gom lỗi theo loại trước. Nếu có hàng trăm dòng lỗi, hãy đếm và nhóm chúng lại rồi mới phân tích nhóm lớn nhất.

Điểm cuối đáng làm thành thói quen: rất nhiều lần một loại lỗi chiếm chín mươi phần trăm số lượng, và sửa nó là giải quyết gần hết vấn đề. Nhìn vào từng dòng riêng lẻ thì không thấy được điều đó.

Bốn thứ phải có trong một báo cáo sự cố

Thành phầnKhông có thì hậu quả gì
Dấu vết lỗi đầy đủ, còn nguyên tên tệp và số dòngChỉ đoán mò được nguyên nhân
Phiên bản ứng dụng và phiên bản hệ điều hànhKhông phân biệt được lỗi cũ đã sửa với lỗi mới
Các bước dẫn tới lúc văngKhông tái hiện được thì không kiểm chứng được bản sửa
Tỷ lệ xảy ra trên tổng số phiênKhông biết nên sửa ngay hay xếp hàng chờ

Báo cáo thiếu ba trong bốn mục trên thì việc đầu tiên không phải là sửa lỗi mà là bổ sung ghi nhận, nếu không bạn sẽ sửa mò rồi lại chờ lỗi tái xuất hiện.

Vì sao phải bắt giải thích trước khi sửa

Khi nhận một dấu vết lỗi, cách làm dễ sai nhất là hỏi ngay cách sửa. Bạn sẽ nhận về một bản vá che triệu chứng: thêm một phép kiểm tra rỗng ngay chỗ văng, lỗi biến mất, dữ liệu vẫn sai ở tầng dưới. Hãy yêu cầu nêu nguyên nhân trước, rồi tự đọc lại đoạn mã được chỉ ra để xác nhận, sau đó mới bàn cách sửa. Bước xác nhận này tốn hai phút và loại được phần lớn bản vá che triệu chứng.

Tái hiện, thu hẹp, xác nhận rồi mới sửa

TerminalTái hiện, thu hẹp, xác nhận rồi mới sửabash
# 1. TAI HIEN duoc truoc da#    Neu chua tai hien duoc thi moi ban sua deu la doan # 2. THU HEP pham vigit log --oneline -20                  # lan cuoi con chay tot la luc naogit bisect start                       # tim dung lan thay doi gay loi # 3. XAC NHAN nguyen nhan bang mot phep thu#    Vi du: thu voi dung du lieu dau vao do o mot doan ma nho rieng # 4. SUA roi VIET BAI KIEM THU cho dung truong hop vua roi#    Khong co bai kiem thu thi loi nay se quay lai sau vai thang # Ghi lai vao mo ta cua lan gop ma: nguyen nhan la gi, khong chi sua gi

Khi nhật ký quá dài để đọc hết

  • Cắt theo mốc thời gian quanh lúc văng, thường ba mươi giây trước là đủ.
  • Lọc theo mã định danh phiên hoặc mã người dùng để bỏ nhiễu từ các phiên khác.
  • Đếm tần suất từng loại dòng lỗi trước, sửa loại xuất hiện nhiều nhất, thường một nguyên nhân sinh ra nhiều dòng khác nhau.

Câu hỏi thường gặp

Vì sao dấu vết lỗi đọc không hiểu?

Vì bản phát hành đã được làm rối tên để giảm dung lượng. Bạn cần file ánh xạ sinh ra lúc đóng gói để giải mã. Hãy lưu file đó cho mỗi bản phát hành, không có nó thì dấu vết vĩnh viễn không đọc được.

Agent có tự tìm được nguyên nhân không?

Thường tìm được hướng đúng nếu bạn đưa đủ dấu vết đã giải mã và bối cảnh. Nhưng hãy bắt nó giải thích trước khi sửa, vì nó có xu hướng vá ngay chỗ báo lỗi thay vì tìm nơi sinh ra lỗi.

Lỗi chỉ xảy ra trên một dòng máy thì sao?

Thường là chuyện tương thích với bản hệ điều hành tùy biến của hãng đó. Hãy nêu rõ dòng máy trong mô tả, và nếu có thể thì mượn một máy thật để tái hiện, vì máy giả lập không dựng lại được khác biệt này.

Có nên để agent tự sửa lỗi trên nhánh chính không?

Không. Cho nó đề xuất bản sửa trên nhánh riêng để bạn xem lại. Với lỗi ở bản đang phát hành thì càng phải cẩn thận, vì một bản vá sai còn tệ hơn lỗi ban đầu.

Chia sẻ:Facebook

Thanh Nguyễn

TND

Tư vấn bản quyền, VPS và máy chủ kèm hóa đơn VAT, hợp đồng đầy đủ cho doanh nghiệp.