Làm cách nào để tiếp cận sửa lỗi không thể sửa chữa / xảy ra ngẫu nhiên?


11

Chúng tôi có một trang web đa ngôn ngữ trong đó một lỗi đã được phát hiện vài ngày trước. Nó đang hiển thị dữ liệu ngôn ngữ khác bằng ngôn ngữ khác và cũng là hỗn hợp dữ liệu như ngôn ngữ tiếng Anh đã được chọn nhưng nó cũng hiển thị dữ liệu ngôn ngữ khác trong trang và ngược lại. Nó đang làm điều đó không thường xuyên nhưng có mặt trong trang web. Đi qua mã cũng không giúp được gì vì điều này không phải lúc nào cũng xảy ra.

Bất kỳ đề nghị trong việc tìm ra vấn đề một cách kịp thời? Tôi đang yêu cầu chiến lược ở đây.


4
bắt đầu thăm dò mã cho các tình huống sẽ cho phép lỗi này xảy ra (thay vì thực hiện theo cách khác)
Imran Omar Bukhsh

Câu trả lời:


20

Bước đầu tiên là thử và mô tả những gì có thể gây ra loại vấn đề này. Vì điều này có liên quan đến việc chọn ngôn ngữ chính xác cho các phần của mã, hãy bắt đầu bằng cách xem xét các điều sau:

  • Ngôn ngữ được phát hiện như thế nào? Có dựa trên thông tin từ yêu cầu HTTP không? Nó dựa trên thông tin phiên?, Hay nó dựa trên các trường cơ sở dữ liệu? Về bản chất, đây có thể là một vấn đề liên quan đến cách ứng dụng của bạn chọn ngôn ngữ cho từng phần không?
  • Ngôn ngữ được hiển thị như thế nào? Bạn đang lấy từ một tệp thuộc tính, hoặc cơ sở dữ liệu? Có thể tham chiếu đến ngôn ngữ chính xác đang bị mất một số làm thế nào? Là hỗn hợp trong ngôn ngữ bạn thấy luôn luôn là mặc định cho trang web?
  • Có một mối tương quan với môi trường khách hàng? Điều này có liên quan đến viên đạn đầu tiên, nhưng đi xa hơn một chút. Tôi đã gặp vấn đề kết xuất lạ do các proxy lưu trữ hạ lưu. Thông thường, các loại sự cố đó là toàn bộ trang cũ hoặc đang phục vụ trang của một người cho những người dùng khác (điều đó thật đáng xấu hổ).
  • Bạn đang sử dụng một giá trị Thread Local? Nếu một yêu cầu được xử lý nhiều hơn một luồng, giá trị cục bộ của luồng sẽ có thông tin khác nhau dựa trên luồng đang hoạt động tại thời điểm đó. Trong môi trường máy chủ web, bạn không thể cho rằng luồng mà bạn bắt đầu xử lý sẽ giống với luồng bạn hoàn thành xử lý - trừ khi đó là một phần của thông số kỹ thuật cho nền tảng của bạn. Các nhà văn máy chủ đã phát hiện ra rằng nếu họ sử dụng lại một nhóm nhỏ các luồng và ghép kênh làm việc với họ theo từng khối, họ có thể xử lý nhiều yêu cầu hơn cùng một lúc. Ngay cả khi bạn có một luồng từ đầu đến cuối của một yêu cầu, máy chủ có thể được ghép nhiều yêu cầu khác vào luồng đó cùng một lúc. Thay vì các chủ đề cục bộ, hãy xem xét ràng buộc giá trị đó với các thuộc tính yêu cầu hoặc phiên.

Bây giờ, một khi bạn đã mô tả các khả năng của những gì có thể sai, đã đến lúc đảm bảo bạn có dữ liệu bạn cần thử và tìm hiểu những gì đã sai.

  • Sử dụng đăng nhập dồi dào xung quanh các khu vực vấn đề. Đây là nơi mà một công cụ như Log4J hoặc Log4Net có thể thực sự tỏa sáng. Khung ghi nhật ký đó và các khung khác giống như vậy, cho phép bạn bật nhật ký cho một số danh mục nhất định trong khi vẫn giữ tiếng ồn cho mọi thứ khác - tất cả bằng cách thay đổi tệp cấu hình. Bạn muốn giới thiệu các báo cáo đăng nhập mới để tìm hiểu xem những gì bạn nghi ngờ có thể là vấn đề. Ngoài ra, hãy đảm bảo nhật ký truy cập HTTP của bạn có tất cả thông tin bạn muốn về từng yêu cầu (cookie, tham số tiêu đề http, v.v.)
  • Cố gắng mô phỏng vấn đề. Vì điều này xảy ra không thường xuyên, tải như thế nào trên máy chủ tại thời điểm nó xảy ra? Bạn có nhận được một số yêu cầu đồng thời từ một hỗn hợp các ngôn ngữ? Nếu vậy, hãy thử mô phỏng loại tải đó trong môi trường thử nghiệm của bạn. Một công cụ tương tự như JMeter có thể là những gì bạn cần. Bạn cũng muốn có thể giả mạo địa chỉ IP cho các khách hàng giả của mình. Hãy nhớ rằng các địa chỉ IP được chia ra để bạn có thể tìm ra quốc gia / khu vực mà IP dựa trên hai phân đoạn đầu tiên của địa chỉ.
  • Vấn đề sẽ được chỉ là lẻ tẻ trong môi trường thử nghiệm của bạn, nhưng khi bạn thu hẹp vào nguyên nhân thực sự của bạn, bạn có thể nghiêng kết quả để làm cho nó xảy ra nhiều hơn thường xuyên hơn nó trong tự nhiên. Ngoài ra, bạn có thể dễ dàng xem lại các tệp nhật ký và cố gắng học hỏi từ chúng.
  • Đó là một quá trình lặp đi lặp lại, vì vậy hãy kiên nhẫn. Bạn phải tạo ra loại tải mà bạn nghĩ sẽ tái tạo lỗi, kiểm tra nhật ký và tinh chỉnh các bài kiểm tra của bạn dựa trên những gì bạn tìm thấy. Điều quan trọng là xác định vấn đề , vì vậy hãy chống lại sự thôi thúc thực hiện một số sửa chữa đơn giản chỉ có thể làm cho vấn đề thực sự xảy ra ít thường xuyên hơn.

Cuối cùng, một khi bạn đã thu hẹp vấn đề đến mức bạn biết cách tái tạo nó và nguyên nhân gây ra nó, hãy viết bài kiểm tra tự động nhỏ nhất bạn có thể để buộc vấn đề trong mã. Nếu bạn đã thu hẹp vấn đề xuống một lớp hoặc một cặp lớp không hoạt động chính xác với nhau, hãy tạo lại nó ở cấp đó. Bạn không cần phải sinh ra 100 luồng để làm điều đó, chỉ cần thực hiện thử nghiệm nhỏ nhất có thể khiến vấn đề xảy ra 100%.

Bây giờ bạn có thể sửa nó và tự tin một cách hợp lý rằng nó sẽ không quay lại cắn bạn lần nữa.


10

Các lỗi không phải là không thể sửa chữa. Bạn chưa tìm ra cách tái tạo nó.

Không có lỗi là ngẫu nhiên trừ khi bạn đưa ra một ngoại lệ dựa trên giá trị trả về của một số câu lệnh Random ().

Tôi biết điều này có vẻ giống như ngữ nghĩa nhưng nó yên tâm về mặt tinh thần để nói điều này với chính mình.

Thật khó khăn và bực bội khi tìm ra cách khắc phục một lỗi chỉ xảy ra do điều kiện chủng tộc phức tạp hoặc như vậy.

Về cách tìm nó, tôi sẽ bật / thêm một số đăng nhập vào ứng dụng ở những nơi có thể cung cấp cho bạn thêm thông tin.

Tiếp theo, hãy nói với những người đang nhìn thấy lỗi (khi họ là Dev, QA, người dùng cuối) báo cáo ngay khi họ thấy nó với thời gian xảy ra và sau đó tham khảo nhật ký của bạn. Yêu cầu họ cung cấp thông tin khác cũng như lỗi chỉ có thể xảy ra do sự tương tác của một số hệ thống khác nhau hoặc do điều kiện cuộc đua

Hy vọng bạn sẽ có thể tìm thấy một khách hàng tiềm năng.


ngay cả các cuộc gọi Random () cũng không thực sự ngẫu nhiên trừ khi chúng được lấy từ một bộ tạo nhiễu trắng phần cứng. Chúng là psuedo-Random, có nghĩa là các số được phân phối theo toán học theo thứ tự ngẫu nhiên nhất có thể. Nhưng nếu bạn bắt đầu từ cùng một giá trị "hạt giống", bạn sẽ nhận được cùng một câu trả lời mỗi lần.
Berin Loritsch

1
@Berin: Tôi biết.
Gilles

+1 cho "bạn chưa tìm ra cách tái tạo nó." Tất cả các lỗi có nguyên nhân gốc rễ nếu không chúng sẽ không xảy ra.
Mike S

1
Không cần phải tắt Random (), những thứ phụ thuộc vào thời gian, đặc biệt là những thứ liên quan đến việc truy cập không đúng vào tài nguyên được chia sẻ có thể rất khó để tạo lại.
Loren Pechtel

2
@Gilles: Ngoại trừ họ có thể không xác định bất cứ điều gì bạn có thể đo lường hợp lý. (Nói, chính xác là khi một số nhiệm vụ khác phát hành, đó là lát cắt thời gian.)
Loren Pechtel

5

Bạn có thể cố gắng tìm các vị trí trong mã của mình, nơi bạn có thể nhận ra rằng sự cố đã xảy ra (ví dụ: các tham số không nhất quán trong một phương thức), thêm các kiểm tra vào mã của bạn và để chúng thêm thông tin bổ sung vào nhật ký gỡ lỗi (như dấu vết ngăn xếp, các đối tượng được thêm vào phiên, v.v.)

Làm điều này với một chút may mắn, bạn có thể nắm bắt thông tin về các sự cố và suy luận về cách trở lại vấn đề.


2

Tự động hóa sẽ giúp, nếu đó là các bước tương tự để tái tạo đôi khi thất bại, tự động hóa nó và đặt nó trong một vòng lặp. Chạy trong 50.000 lần và nó rất có thể xảy ra.


Sự kiện này không phải là ngẫu nhiên, nó chỉ có vẻ ngẫu nhiên. Làm điều này có thể khiến nó xuất hiện, nhưng sẽ cung cấp cho bạn rất ít thông tin về lý do tại sao nó xuất hiện.
Josh K

1
@Josh - Nếu anh ta không thể tái tạo nó, đây có thể là một cách tốt để làm điều đó và lấy dấu vết ngăn xếp với các biểu tượng gỡ lỗi, ví dụ. Tôi nghĩ rằng đó là một bước đầu tiên tuyệt vời - tận mắt nhìn thấy nó
Kieren Johnstone

Bạn đang giả định rằng có một ngăn xếp và nó có thể đạt được. Anh ấy đã không cung cấp cho chúng tôi bất kỳ thông tin kỹ thuật nào về ứng dụng hoặc khả năng truy cập để gỡ lỗi theo loại tải này. Đây không phải là một chiến lược gỡ lỗi , đây là một cái búa cố gắng nắm bắt chính xác thời điểm nó bị phá vỡ.
Josh K

@Josh - kinh nghiệm trong thế giới thực của tôi cho tôi biết điều duy nhất có giá trị nhất trong việc điều tra / sửa lỗi là tận mắt nhìn thấy nó. Cho dù đó là thứ gì đó với thời gian bạn có thể nhìn thấy, dấu vết ngăn xếp, thứ gì đó trong nhật ký hoặc bất cứ thứ gì khác. Nếu có thể, có những vấn đề dường như xảy ra ngẫu nhiên được thử nghiệm trong một vòng lặp đã đưa tôi đến đó rất nhanh. Nếu bạn có một ý tưởng khác, hãy đăng nó dưới dạng câu trả lời vì lợi ích của christ - đây là một phương pháp hợp lệ và một câu trả lời hợp lệ.
Kieren Johnstone

Tôi không đồng ý và tôi tin rằng câu trả lời của Berin là cách chính xác để giải quyết vấn đề này.
Josh K

1

cố gắng tìm các mẫu để xác định các điều kiện khiến vấn đề này tự biểu hiện. Điều đó sẽ chỉ cho bạn các phần trong mã của bạn bị lỗi (hoặc hành xử không nhất quán).


Không chết tiệt ..............
theringostarrs

0

Bạn có thể phát hiện khi vấn đề đang xảy ra? Nếu vậy, bạn có thể bỏ thông tin đáng tin cậy về trạng thái của hệ thống tại thời điểm đó không?

Nếu câu trả lời cho cả hai câu hỏi này là có, hãy sử dụng mã của bạn để ghi lại càng nhiều thông tin càng tốt khi lỗi thực sự xảy ra, sau đó chờ đợi.

Đây không phải là sự thay thế cho những gì người khác đã đề xuất (bạn vẫn sẽ cần suy luận về cách mã có thể vào trạng thái bạn đang thấy), nhưng miễn là bạn không thể tái tạo lỗi theo ý muốn, đó là một ý tưởng tốt để không lãng phí những dịp nó xuất hiện.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.