Xử lý các lỗi không thể tái tạo

Giả sử nhóm của bạn viết một hệ thống phần mềm (khá ngạc nhiên!) Đang chạy tốt.

Một ngày nọ, một trong những kỹ sư chạy nhầm một số truy vấn SQL làm thay đổi một số dữ liệu DB, sau đó quên nó.

Sau một thời gian, bạn phát hiện ra dữ liệu bị hỏng / bị lỗi và mọi người đều gãi đầu xem phần nào của mã gây ra điều này và tại sao, không có kết quả. Trong khi đó, người quản lý dự án khẳng định rằng chúng tôi tìm thấy một phần của mã gây ra nó.

Làm thế nào để bạn đối phó với điều này?

Rõ ràng là không có người quản lý dự án sẽ đầu tư một lượng thời gian vô hạn vào một vấn đề như vậy. Họ muốn ngăn chặn tình trạng tương tự xảy ra lần nữa.

Để đạt được mục tiêu này, ngay cả khi người ta không thể tìm ra nguyên nhân gốc rễ của sự thất bại đó, thường có thể thực hiện một số biện pháp để

• Phát hiện những thất bại như vậy sớm hơn trong trường hợp chúng tái diễn
• Làm cho nó ít có khả năng thất bại tương tự sẽ xảy ra một lần nữa
• Làm cho hệ thống mạnh mẽ hơn chống lại các loại mâu thuẫn cụ thể

Ví dụ: ghi nhật ký chi tiết hơn, xử lý lỗi nghiêm trọng hơn hoặc báo hiệu lỗi ngay lập tức có thể giúp ngăn ngừa lỗi tương tự xảy ra lần nữa hoặc để tìm nguyên nhân gốc. Nếu hệ thống của bạn cho phép thêm trình kích hoạt cơ sở dữ liệu, có thể thêm trình kích hoạt cấm tính không nhất quán được đưa ra ở vị trí đầu tiên.

Hãy nghĩ về loại hành động thích hợp có thể là gì trong tình huống của bạn và đề xuất điều này với nhóm; Tôi chắc chắn người quản lý dự án của bạn sẽ hài lòng.

Một ngày nọ, một trong những kỹ sư chạy nhầm một số truy vấn SQL làm thay đổi một số dữ liệu DB, sau đó quên nó.

Như đã đề cập bởi những người khác, đó cũng là một ý tưởng tốt để cấm một thủ tục như vậy (nếu bạn có ảnh hưởng đến cách hệ thống được vận hành). Không ai được phép chạy các truy vấn đặc biệt không có giấy tờ làm thay đổi nội dung cơ sở dữ liệu. Nếu cần một truy vấn như vậy, hãy đảm bảo có chính sách lưu trữ truy vấn cùng với ngày thực hiện của nó, tên của người thực hiện nó và lý do tại sao nó được sử dụng, ở một nơi được ghi lại.

Đây không phải là một lỗi

Ít nhất là không phải trên mã của bạn. Đó là một lỗi trong quá trình của bạn . Người quản lý dự án của bạn sẽ lo lắng hơn rất nhiều về quy trình của bạn so với mã của bạn.

Làm thế nào để bạn đối phó với điều này?

Rất đơn giản, bằng cách không để các kỹ sư thay đổi cơ sở dữ liệu phát triển hoặc chia sẻ .

Giả sử đây là một cơ sở dữ liệu phát triển được chia sẻ:

Lý tưởng nhất, nếu có thể, tránh có một cơ sở dữ liệu được chia sẻ ở nơi đầu tiên . Thay vào đó, có cơ sở dữ liệu cho mỗi nhà phát triển tồn tại trong thời gian ngắn. Điều này nên được tự động hóa với các tập lệnh, nếu không, chi phí để kiểm tra trở nên quá lớn và có động cơ để không kiểm tra mọi thứ. Bạn có thể có các cơ sở dữ liệu này trên máy trạm của nhà phát triển hoặc trên máy chủ trung tâm.

Nếu, vì một số lý do, bạn hoàn toàn PHẢI có một cơ sở dữ liệu dùng chung, bạn nên sử dụng đồ đạc - về cơ bản, một cái gì đó đặt cơ sở dữ liệu về trạng thái đã biết mỗi khi bạn cần sử dụng nó. Điều này tránh cho các nhà phát triển bị cắn bởi những thay đổi của người khác.

Nếu bạn cần áp dụng các thay đổi vĩnh viễn cho cơ sở dữ liệu, bạn nên cam kết chúng với kiểm soát nguồn của mình . Thiết lập cơ sở dữ liệu của bạn sao cho các nhà phát triển không có quyền ghi trực tiếp vào cơ sở dữ liệu đó và có một chương trình lấy các thay đổi từ kiểm soát nguồn và áp dụng chúng.

Cuối cùng, từ mô tả của bạn về cách bạn gỡ lỗi mọi thứ, có vẻ như bạn không sử dụng CI . Sử dụng CI . Việc cài đặt hơi khó khăn một chút, nhưng về lâu dài sẽ tiết kiệm được rất nhiều SO, chưa kể đến việc ngăn bạn khỏi lo lắng về các lỗi cơ sở dữ liệu không thể khắc phục được. Bây giờ bạn sẽ chỉ phải lo lắng về heisenbugs !

Giả sử đây là một cơ sở dữ liệu sản xuất:

Nếu các nhà phát triển của bạn đang thay đổi cơ sở dữ liệu sản xuất, nhiều thứ đã trở nên sai lầm khủng khiếp, ngay cả khi những thay đổi đó là hoàn toàn chính xác.

Các nhà phát triển không bao giờ nên truy cập cơ sở dữ liệu sản xuất . Hoàn toàn không có lý do để, và rất nhiều điều có thể rất sai.

Nếu bạn cần phải sửa chữa một cái gì đó trong một cơ sở dữ liệu sản xuất, trước tiên bạn sao lưu, khôi phục rằng sao lưu trên một khác nhau (phát triển) chẳng hạn, và sau đó chơi xung quanh mà cơ sở dữ liệu phát triển. Khi bạn nghĩ rằng bạn đã có bản sửa lỗi (trên kiểm soát nguồn!), Bạn thực hiện lại việc khôi phục, áp dụng bản sửa lỗi và xem kết quả. Sau đó, sau khi sao lưu mọi thứ một lần nữa (và lý tưởng là ngăn chặn cập nhật đồng thời), bạn sửa lỗi sản xuất, lý tưởng là thông qua một bản vá phần mềm.

Nếu bạn cần kiểm tra một cái gì đó trong cơ sở dữ liệu sản xuất ... không, bạn không. Bất cứ thử nghiệm nào bạn cần làm, bạn nên làm trong một ví dụ phát triển. Nếu bạn cần một số dữ liệu để thực hiện các bài kiểm tra, bạn sẽ có được dữ liệu đó trong đó.

Một cơ sở dữ liệu sản xuất nên có nhật ký truy cập đầy đủ và kiểm soát truy cập dựa trên vai trò. Do đó, bạn nên có bằng chứng cứng rắn về việc WHO đã làm gì KHI NÀO vào cơ sở dữ liệu, do đó chuyển sự chú ý từ mã sang bảo mật hoạt động kém.

Trong trường hợp này, cuối cùng bạn đã tìm ra nguyên nhân, nhưng lấy giả thuyết của bạn rằng bạn đã không ...

Đầu tiên, phân tích những gì đã thay đổi. Nếu hệ thống đã hoạt động tốt trước đó, việc xem xét cẩn thận mọi thứ được thực hiện gần đây có thể tiết lộ sự thay đổi gây ra lỗi. Xem xét một cách có hệ thống kiểm soát phiên bản, CI / hệ thống triển khai và kiểm soát cấu hình của bạn để xem có gì thay đổi không. Chạy git bisect hoặc một cơ chế tương đương để thực hiện tìm kiếm nhị phân. Kiểm tra nhật ký. Săn lùng các bản ghi mà bạn không biết bạn có. Nói chuyện với mọi người có quyền truy cập vào hệ thống để xem họ có làm gì gần đây không. Đối với vấn đề của bạn, nếu bạn đủ kỹ lưỡng trong quy trình này, điều này hy vọng sẽ tiết lộ các truy vấn SQL bị lãng quên.

Thứ hai, thiết bị đo đạc. Nếu bạn không thể trực tiếp tìm ra nguyên nhân gây ra lỗi, hãy thêm thiết bị xung quanh nó để thu thập dữ liệu về sự cố. Hãy tự hỏi mình "nếu tôi có thể tái tạo lỗi này trên lệnh, tôi muốn xem xét gì trong trình gỡ lỗi", và sau đó đăng nhập nó. Lặp lại khi cần thiết cho đến khi bạn hiểu rõ hơn về vấn đề. Như Doc Brown gợi ý, hãy thêm đăng nhập cho các trạng thái có liên quan đến lỗi. Thêm xác nhận phát hiện dữ liệu bị hỏng. Ví dụ: nếu lỗi của bạn là sự cố ứng dụng, hãy thêm cơ chế ghi nhật ký sự cố. Nếu bạn đã có, thật tuyệt, hãy thêm chú thích vào nhật ký sự cố để ghi lại trạng thái có khả năng liên quan đến sự cố. Xem xét liệu các vấn đề tương tranh có thể liên quan và kiểm tra để thực hiện an toàn luồng hay không .

Thứ ba, khả năng phục hồi. Lỗi là không thể tránh khỏi, vì vậy hãy tự hỏi làm thế nào bạn có thể cải thiện hệ thống của mình trở nên linh hoạt hơn để việc phục hồi từ lỗi dễ dàng hơn. Sao lưu của bạn có thể được cải thiện (hoặc tồn tại)? Giám sát tốt hơn, chuyển đổi dự phòng và cảnh báo? Dự phòng nhiều hơn? Xử lý lỗi tốt hơn? Decouple dịch vụ phụ thuộc lẫn nhau? Bạn có thể cải thiện các quy trình của bạn xung quanh truy cập cơ sở dữ liệu và truy vấn thủ công không? Tốt nhất, những điều này sẽ làm cho hậu quả của lỗi của bạn bớt nghiêm trọng hơn và tệ nhất, có lẽ chúng là những điều tốt để làm.

1. Giải thích cho người quản lý dự án của bạn rằng bạn nghĩ nguyên nhân rất có thể là truy cập cơ sở dữ liệu thủ công.
2. Nếu họ vẫn muốn bạn tìm mã gây ra điều này, hãy đi và có cái nhìn khác về mã.
3. Trở lại sau một vài giờ (hoặc một số thời điểm thích hợp khác) và nói rằng bạn không thể tìm thấy bất kỳ mã nào gây ra điều này, do đó bạn vẫn tin rằng nguyên nhân rất có thể là do truy cập cơ sở dữ liệu thủ công.
4. Nếu họ vẫn muốn bạn tìm mã, hãy hỏi họ muốn bạn dành bao nhiêu thời gian cho việc này. Khéo léo nhắc nhở họ rằng bạn sẽ không làm việc trên tính năng X, lỗi Y hoặc nâng cao Z trong khi bạn đang làm việc này.
5. Hãy dành nhiều thời gian như họ yêu cầu. Nếu bạn vẫn nghĩ nguyên nhân rất có thể là truy cập cơ sở dữ liệu thủ công, hãy nói với họ điều này.
6. Nếu họ vẫn muốn bạn tìm mã, hãy leo thang vấn đề vì điều này rõ ràng đã trở thành việc sử dụng không hiệu quả thời gian của nhóm bạn.

Bạn cũng có thể muốn xem xét nếu bạn nên thêm vào một quy trình bổ sung để giảm khả năng truy cập cơ sở dữ liệu thủ công gây ra loại vấn đề này trong tương lai.

Tôi đang làm việc trong nhóm phát triển cho một sản phẩm cơ sở dữ liệu máy tính lớn khi một khách hàng báo cáo rằng họ có cơ sở dữ liệu bị hỏng. Một tham nhũng theo nghĩa là trạng thái bên trong của các bit trên đĩa có nghĩa là cơ sở dữ liệu không thể đọc được thông qua phần mềm cơ sở dữ liệu. Trong thế giới máy tính lớn, khách hàng đang trả cho bạn hàng triệu đô la và bạn cần thực hiện việc này một cách nghiêm túc. Đây là những gì chúng tôi đã làm:

Bước 0: giúp khách hàng đứng dậy và chạy lại bằng cách sửa chữa cơ sở dữ liệu.

Bước 1: bằng cách kiểm tra tệp trên đĩa ở cấp hex, chúng tôi đã xác định rằng tham nhũng là có hệ thống: có nhiều trường hợp tham nhũng tương tự. Vì vậy, nó chắc chắn đã được gây ra ở cấp độ của phần mềm cơ sở dữ liệu. Thật vậy, nó đủ hệ thống để chúng tôi cảm thấy có thể loại trừ các vấn đề đa luồng.

Sau khi loại bỏ nhiều lý thuyết khác, chúng tôi đã tìm hiểu về một tiện ích có thể được sử dụng để sắp xếp lại cơ sở dữ liệu. Nó dường như là mã duy nhất có quyền truy cập vào dữ liệu ở mức phù hợp. Sau đó, chúng tôi đã phát hiện ra một cách để chạy tiện ích này, với các tùy chọn được lựa chọn cẩn thận, trong đó tái tạo vấn đề. Khách hàng không thể xác nhận hoặc phủ nhận rằng đây là những gì họ đã làm, nhưng vì đó là lời giải thích duy nhất chúng tôi có thể đưa ra, chúng tôi quyết định rằng đó là nguyên nhân có thể và họ có ít lựa chọn ngoài việc chấp nhận chẩn đoán của chúng tôi .

Bước 2: Sau đó, chúng tôi đã thực hiện hai thay đổi đối với phần mềm: (a) khiến việc vô tình gây ra hiệu ứng này khó khăn hơn thông qua giao diện người dùng "có Tôi biết tôi đang làm gì" và (b) giới thiệu tệp nhật ký mới để nếu nó đã từng xảy ra một lần nữa, chúng ta sẽ có một bản ghi các hành động của người dùng.

Vì vậy, về cơ bản (a) sửa chữa thiệt hại và khôi phục hoạt động trực tiếp, (b) tìm nguyên nhân gốc, (c) làm bất cứ điều gì cần thiết để ngăn chặn nó xảy ra lần nữa hoặc để cho phép chẩn đoán dễ dàng nếu điều đó xảy ra lần nữa.

Từ kinh nghiệm của tôi, những gì sếp của bạn muốn là một mức độ đảm bảo rằng điều này sẽ không tái diễn. Nếu đó là trường hợp không có mã nào là nguyên nhân, bởi vì điều đó được đảm bảo bằng thử nghiệm thống nhất, vì vậy, giả sử bạn đã có phạm vi kiểm tra trên cơ sở mã của mình, giải pháp nên thêm "thử nghiệm" vào cơ sở dữ liệu của bạn. Tôi sẽ trích dẫn Don Gilman, vì anh ta đóng đinh ở đó:

Một cơ sở dữ liệu sản xuất nên có nhật ký truy cập đầy đủ và kiểm soát truy cập dựa trên vai trò. Do đó, bạn nên có bằng chứng cứng rắn về việc WHO đã làm gì KHI NÀO vào cơ sở dữ liệu, do đó chuyển sự chú ý từ mã sang bảo mật hoạt động kém.

Nhưng ngoài ra, bạn nên có Quy trình hoạt động tiêu chuẩn về thay đổi dữ liệu trong sản xuất. Ví dụ, không có DBA nào nên thay đổi dữ liệu, không nhà phát triển nào nên tự thực hiện thay đổi và họ, như được định nghĩa trong SOP, yêu cầu lẫn nhau chính thức thay đổi bằng thư hoặc vé.

Phải có một trích dẫn như thế này ở đâu đó, nếu không bạn có thể trích dẫn tôi về nó:

Có một lý do hoàn toàn chính đáng để các đầu bếp không phải là người chịu trách nhiệm làm sạch nhà vệ sinh.

Có một số điều phải được thực hiện với các lỗi không thể tái tạo.

1. Tạo một vé cho nó

Tạo một vé và ghi nhật ký mọi thứ bạn có thể nghĩ trong vé. Đồng thời kiểm tra xem "lỗi" này đã được ghi lại trước đó chưa và liên kết các vé với nhau. Cuối cùng, bạn có thể nhận được đủ vé để thiết lập một mô hình về cách tái tạo lỗi. Điều này bao gồm các công việc xung quanh được sử dụng để cố gắng tránh nó. Ngay cả khi đây là trường hợp duy nhất, nếu có lần đầu tiên, cuối cùng sẽ có lần thứ hai. Khi bạn tìm ra nguyên nhân, hãy đóng vé với lời giải thích về nguyên nhân là gì để bạn có ý tưởng mạnh mẽ về những gì đã xảy ra nếu nó xảy ra lần nữa (sửa lỗi bị mất trong hợp nhất xấu)

2. Làm một phân tích cứng

Nhìn vào hệ thống, những gì thất bại, và làm thế nào nó thất bại. Cố gắng tìm khu vực của mã có thể được cập nhật để giảm khả năng thất bại. Vài ví dụ...

• Thay thế mã ad-hoc bằng một cuộc gọi chuyên dụng (như execute(<query>)vớiexecuteMyStoredProcedure(<params>)
• Chạy các kịch bản xác minh hàng đêm để xác minh tính toàn vẹn dữ liệu (để có thể phát hiện ra điều này trong vòng 24 giờ tới)
• Thêm / cải thiện việc ghi nhật ký và lưu trữ (sao lưu).
• Thay đổi giới hạn bảo mật không phù hợp (ví dụ: người / chương trình chỉ đọc dữ liệu không có quyền ghi; Không cho phép các nhà phát triển không chịu trách nhiệm sản xuất có thể đăng nhập vào máy chủ sản xuất)
• Thêm xác minh dữ liệu / vệ sinh nơi thiếu

Điều này có thể không khắc phục được lỗi, nhưng ngay cả khi không có, hệ thống hiện đã ổn định / an toàn hơn nên nó vẫn được đền đáp.

3. Thêm cảnh báo hệ thống

Một phần của 2, nhưng điều gì đó đã xảy ra, và bạn cần biết khi nào nó lại xảy ra. Bạn nên tạo một số tập lệnh / chương trình kiểm tra sức khỏe để theo dõi hệ thống, để quản trị viên có thể được cảnh báo trong vòng 24h kể từ khi xuất hiện lại lỗi (càng ít trễ, càng tốt, trong lý do). Điều này sẽ làm cho việc dọn dẹp dễ dàng hơn nhiều. (Lưu ý rằng ngoài nhật ký của cơ sở dữ liệu, HĐH cũng nên ghi nhật ký người đăng nhập vào đó và mọi hành động không đọc mà họ thực hiện. Ít nhất, nên có nhật ký lưu lượng truy cập mạng cho máy đó)

Vấn đề của bạn không phải do lỗi trong phần mềm của bạn mà do ai đó làm hỏng cơ sở dữ liệu. Nếu bạn gọi mọi thứ là sai "lỗi", thì lỗi của bạn có thể dễ dàng tái tạo: Mọi thứ sẽ luôn sai khi ai đó làm những điều ngu ngốc với cơ sở dữ liệu. Và có nhiều cách để tránh "lỗi" này, bằng cách không cho phép cơ sở dữ liệu được sửa đổi bằng tay hoặc sử dụng phần mềm chưa được kiểm tra và bằng cách kiểm soát chặt chẽ ai có thể sửa đổi cơ sở dữ liệu.

Nếu bạn chỉ gọi lỗi trong cơ sở dữ liệu của mình là "lỗi", thì bạn không có lỗi không thể sửa chữa được, bạn không có lỗi gì cả. Bạn có thể có một báo cáo lỗi, nhưng bạn cũng có bằng chứng cho thấy vấn đề không phải do lỗi. Vì vậy, bạn có thể đóng báo cáo lỗi, không phải là "không thể sửa chữa", mà là một cái gì đó khác như "cơ sở dữ liệu bị hỏng". Không có gì lạ khi có báo cáo lỗi trong đó điều tra cho thấy không có lỗi, nhưng một người dùng đã sử dụng phần mềm sai, kỳ vọng của người dùng là sai, v.v.

Trong trường hợp đó bạn vẫn biết có một vấn đề mà bạn không muốn lặp lại, vì vậy bạn có hành động tương tự như trong trường hợp đầu tiên.