Chúng ta có nên thiết kế chương trình để tự giết mình? [đóng cửa]

Tóm lại, chúng ta có nên thiết kế cái chết vào các chương trình, quy trình và luồng của chúng ta ở mức độ thấp, vì lợi ích chung của hệ thống không?

Thất bại xảy ra. Quá trình chết. Chúng tôi lên kế hoạch cho thảm họa và đôi khi phục hồi từ nó. Nhưng chúng tôi hiếm khi thiết kế và thực hiện cái chết chương trình không thể đoán trước. Chúng tôi hy vọng rằng thời gian phục vụ của dịch vụ của chúng tôi miễn là chúng tôi quan tâm để duy trì hoạt động của chúng.

Một ví dụ vĩ mô của khái niệm này là Chaos Monkey của Netflix , kết thúc ngẫu nhiên các trường hợp AWS trong một số tình huống. Họ cho rằng điều này đã giúp họ khám phá các vấn đề và xây dựng các hệ thống dư thừa hơn.

Những gì tôi đang nói là cấp thấp hơn. Ý tưởng là cho các quá trình chạy dài theo truyền thống để thoát ngẫu nhiên. Điều này sẽ buộc sự dư thừa vào thiết kế và cuối cùng tạo ra các hệ thống linh hoạt hơn.

Liệu khái niệm này đã có tên? Có phải nó đã được sử dụng trong ngành công nghiệp?

BIÊN TẬP

Dựa trên các nhận xét và câu trả lời, tôi e rằng tôi không rõ ràng trong câu hỏi của mình. Cho rõ ràng:

• vâng, ý tôi là ngẫu nhiên
• vâng, tôi có nghĩa là trong sản xuất, và
• không, không chỉ để thử nghiệm

Để giải thích, tôi muốn vẽ một sự tương tự với các sinh vật đa bào.

Trong tự nhiên, sinh vật bao gồm nhiều tế bào. Các tế bào tự ngã ba để tạo ra sự dư thừa, và cuối cùng chúng chết. Nhưng phải luôn có đủ các tế bào đúng loại để sinh vật hoạt động. Hệ thống dự phòng cao này cũng tạo điều kiện chữa lành khi bị thương. Các tế bào chết nên sinh vật sống.

Kết hợp cái chết ngẫu nhiên vào một chương trình sẽ buộc hệ thống lớn hơn phải áp dụng các chiến lược dự phòng để duy trì khả thi. Liệu những chiến lược tương tự này có giúp hệ thống duy trì ổn định khi đối mặt với những thất bại khó lường khác?

Và, nếu bất cứ ai đã thử điều này, nó được gọi là gì? Tôi muốn đọc thêm về nó nếu nó đã tồn tại.

Không.

Chúng ta nên thiết kế xử lý đường dẫn xấu thích hợp và thiết kế các trường hợp thử nghiệm (và các cải tiến quy trình khác) để xác nhận rằng các chương trình xử lý tốt các điều kiện đặc biệt này. Những thứ như Chaos Monkey có thể là một phần của điều đó, nhưng ngay khi bạn thực hiện "phải sụp đổ ngẫu nhiên", một sự cố ngẫu nhiên thực tế yêu cầu trở thành những thứ mà người kiểm tra không thể gửi là lỗi.

Quá trình giới thiệu các lỗi trong phần mềm hoặc trong phần cứng để kiểm tra các cơ chế chống lỗi được gọi là lỗi xử lý .

Từ Wikipedia:

Kỹ thuật tiêm lỗi có từ những năm 1970 khi nó lần đầu tiên được sử dụng để gây ra lỗi ở cấp độ phần cứng. Kiểu tiêm lỗi này được gọi là Lỗi thực thi phần cứng (HWify) và cố gắng mô phỏng các lỗi phần cứng trong một hệ thống. Các thí nghiệm đầu tiên trong quá trình xử lý lỗi phần cứng không liên quan gì đến việc rút ngắn các kết nối trên bảng mạch và quan sát hiệu ứng trên hệ thống (lỗi cầu nối). Nó được sử dụng chủ yếu như một thử nghiệm về độ tin cậy của hệ thống phần cứng. Phần cứng chuyên dụng sau này được phát triển để mở rộng kỹ thuật này, chẳng hạn như các thiết bị bắn phá các khu vực cụ thể của bảng mạch có bức xạ nặng. Người ta đã sớm phát hiện ra rằng các lỗi có thể được gây ra bởi các kỹ thuật phần mềm và các khía cạnh của kỹ thuật này có thể hữu ích để đánh giá các hệ thống phần mềm.

Đúng. Không chắc.

Chấm dứt định kỳ là con dao hai lưỡi. Bạn sẽ bị tấn công bằng một bên hay bên kia, và mức độ tệ hơn của hai tệ nạn phụ thuộc vào tình huống của bạn.

Một khía cạnh là độ tin cậy: Nếu bạn buộc chương trình kết thúc ngẫu nhiên (hoặc có thể dự đoán được) và theo cách có trật tự, bạn có thể chuẩn bị cho sự kiện đó và đối phó với nó. Bạn có thể đảm bảo rằng quy trình sẽ thoát khi không bận rộn làm việc gì đó hữu ích. Điều này cũng đảm bảo rằng các lỗi sẽ xuất hiện ngoài thời gian chạy bị xử phạt sẽ không hỗ trợ cho những cái đầu xấu xí của chúng trong sản xuất, đó là một điều tốt. Apache HTTPD có một cài đặt cho phép bạn điều chỉnh số lượng yêu cầu mà một tiến trình con (hoặc luồng trong các phiên bản gần đây hơn) sẽ phục vụ trước khi kết thúc.

Một khía cạnh khác cũng là độ tin cậy: Nếu bạn không cho phép chương trình chạy dài, bạn sẽ không bao giờ tìm thấy các lỗi xuất hiện theo thời gian. Khi cuối cùng bạn gặp phải một trong những lỗi đó, nhiều khả năng sẽ khiến chương trình trả lời sai hoặc không trả lời được. Tồi tệ hơn, nếu bạn chạy nhiều luồng của cùng một công việc, một lỗi do thời gian hoặc do đếm có thể ảnh hưởng đến một số lượng rất lớn các nhiệm vụ cùng một lúc và dẫn đến cả chuyến đi 3 giờ sáng trong văn phòng.

Trong cài đặt nơi bạn chạy nhiều luồng giống nhau (ví dụ: trên máy chủ web), giải pháp thực tế là thực hiện một cách tiếp cận hỗn hợp dẫn đến tỷ lệ thất bại chấp nhận được. Nếu bạn chạy 100 luồng, chạy tỷ lệ ngắn: 99: 1 có nghĩa là chỉ một lỗi sẽ xuất hiện các lỗi dài hạn trong khi những người khác tiếp tục làm bất cứ điều gì họ làm mà không thất bại. Ngược lại với việc chạy dài 100%, nơi bạn có nguy cơ cao hơn tất cả các luồng bị lỗi cùng một lúc.

Nếu bạn có một luồng duy nhất, có lẽ tốt hơn là cứ để nó chạy và thất bại, vì thời gian chết trong quá trình khởi động lại có thể dẫn đến độ trễ không mong muốn khi có công việc thực sự sẽ hoàn thành thành công.

Trong cả hai trường hợp, điều quan trọng là có một cái gì đó giám sát các quy trình để chúng có thể được khởi động lại ngay lập tức. Ngoài ra, không có luật nào quy định các quyết định ban đầu của bạn về việc một quá trình nên chạy trong bao lâu phải được đúc bằng đá. Thu thập dữ liệu vận hành sẽ giúp bạn điều chỉnh hệ thống của mình để giảm thất bại xuống mức chấp nhận được.

Tôi khuyên bạn không nên thực hiện chấm dứt ngẫu nhiên, vì điều đó làm cho việc khắc phục các lỗi liên quan đến thời gian trở nên khó khăn hơn. Chaos Monkey làm điều đó để đảm bảo phần mềm giám sát hoạt động, đây là một vấn đề hơi khác.

Bạn có thực sự có nghĩa là ngẫu nhiên? Có phần mềm của bạn ngẫu nhiên tự giết nó nghe có vẻ là một ý tưởng khủng khiếp. Điểm nào sẽ phục vụ?

Tôi đoán điều bạn thực sự muốn nói là chúng ta nên thực tế về các luồng / tiến trình chạy dài và chấp nhận rằng chúng càng chạy lâu thì càng có nhiều khả năng gặp phải một loại lỗi ẩn và gặp phải lỗi không hoạt động tiểu bang. Vì vậy, như một biện pháp hoàn toàn thực dụng, tuổi thọ của các quy trình và chủ đề nên được giới hạn.

Tôi tin rằng vào cuối những năm 90, máy chủ web Apache đã sử dụng một cái gì đó như thế này. Họ có một nhóm các quy trình công nhân (không phải các luồng) và mỗi quy trình công nhân sẽ bị giết sau một thời gian cố định. Điều này giữ cho máy chủ không bị độc quyền bởi các quy trình công nhân đã bị mắc kẹt trong một số trạng thái bệnh lý.

Tôi đã không làm việc trong khu vực một thời gian, vì vậy tôi không biết nếu đây vẫn là trường hợp.

Vấn đề tôi thấy là nếu một chương trình như vậy chết, chúng ta sẽ chỉ nói "Ồ, đó chỉ là một sự chấm dứt ngẫu nhiên khác - không có gì phải lo lắng". Nhưng nếu có một vấn đề thực sự cần khắc phục thì sao? Nó sẽ bị bỏ qua.

Các chương trình đã "ngẫu nhiên" thất bại do các nhà phát triển tạo ra các lỗi, lỗi khiến hệ thống sản xuất, lỗi phần cứng, v.v. Khi điều này xảy ra, chúng tôi muốn biết về nó để chúng tôi có thể khắc phục. Thiết kế cái chết thành các chương trình chỉ làm tăng khả năng thất bại và sẽ chỉ buộc chúng ta tăng sự dư thừa, gây tốn kém.

Tôi thấy không có gì sai khi giết chết các quá trình ngẫu nhiên trong môi trường thử nghiệm khi thử nghiệm một hệ thống dự phòng (điều này sẽ xảy ra nhiều hơn nó) nhưng không phải trong môi trường sản xuất. Chúng tôi sẽ rút một vài ổ đĩa cứng ra khỏi hệ thống sản xuất trực tiếp vài ngày một lần, hoặc tắt một trong các máy tính trên máy bay khi nó đang bay đầy hành khách? Trong một kịch bản thử nghiệm - tốt. Trong một kịch bản sản xuất trực tiếp - tôi không muốn.

Không cần thêm mã thoát ngẫu nhiên vào ứng dụng. Người kiểm tra có thể viết các tập lệnh giết ngẫu nhiên các quy trình của ứng dụng.

Trong mạng, cần phải mô phỏng một mạng không đáng tin cậy để kiểm tra việc thực hiện giao thức. Điều này không được tích hợp vào giao thức; nó có thể được mô phỏng ở cấp trình điều khiển thiết bị hoặc với một số phần cứng bên ngoài.

Không thêm mã kiểm tra làm chương trình cho các tình huống có thể đạt được bên ngoài.

Nếu điều này được dành cho sản xuất, tôi không thể tin nó nghiêm trọng!

Thứ nhất, trừ khi các quy trình thoát đột ngột để các giao dịch đang thực hiện và dữ liệu biến động bị mất, thì đó không phải là một triển khai trung thực của khái niệm này. Lối thoát có kế hoạch, duyên dáng, ngay cả khi được hẹn giờ ngẫu nhiên, không giúp chuẩn bị đầy đủ kiến ​​trúc để xử lý các sự cố thực sự, không duyên dáng.

Nếu các trục trặc thực tế hoặc thực tế được tích hợp vào ứng dụng, chúng có thể dẫn đến tổn hại kinh tế, giống như các trục trặc thực sự và tổn hại kinh tế có chủ đích về cơ bản là một hành vi tội phạm gần như theo định nghĩa.

Bạn có thể thoát khỏi các điều khoản trong thỏa thuận cấp phép từ bỏ trách nhiệm dân sự khỏi mọi thiệt hại phát sinh từ hoạt động của phần mềm, nhưng nếu những thiệt hại đó là do thiết kế, bạn có thể không từ bỏ trách nhiệm hình sự.

Thậm chí đừng nghĩ về những pha nguy hiểm như thế này: làm cho nó hoạt động một cách đáng tin cậy nhất có thể, và chỉ đưa vào các tình huống thất bại giả mạo vào các bản dựng hoặc cấu hình đặc biệt.

Bạn có thể muốn tìm kiếm " phục hồi chủ động " và " trẻ hóa " trong bối cảnh các hệ thống phân tán chịu lỗi, để xử lý các lỗi tùy ý (nghĩa là không chỉ các quá trình bị hỏng, mà cả dữ liệu bị hỏng và cũng có hành vi nguy hiểm). Đã có rất nhiều nghiên cứu về mức độ thường xuyên và trong những điều kiện nên một quá trình (theo nghĩa trừu tượng, thực sự có thể là VM hoặc máy chủ) được khởi động lại. Theo trực giác, bạn có thể hiểu những lợi thế của phương pháp này là thích đối phó với một quy trình chết hơn là một quy trình phản bội ...

Điều này thực sự không khác gì thử nghiệm. Nếu bạn đang thiết kế một giải pháp chuyển đổi dự phòng luôn có sẵn (như Netflix), thì có - bạn nên thử nghiệm nó. Tuy nhiên, tôi không biết rằng các lối thoát ngẫu nhiên được rắc khắp cơ sở mã là một cách thích hợp để kiểm tra điều đó. Trừ khi bạn thực sự có ý định kiểm tra rằng thiết kế của bạn có khả năng phục hồi để tự bắn vào chân mình, thì có vẻ thích hợp hơn để kiểm tra nó bằng cách thao túng môi trường xung quanh mã và xác minh nó hoạt động phù hợp.

Nếu bạn không thiết kế hệ thống dự phòng, thì không - bạn không nên thêm tính năng đó vì bạn đã thêm một số lối thoát ngẫu nhiên. Bạn chỉ nên loại bỏ các lối thoát ngẫu nhiên, và sau đó bạn sẽ không gặp phải vấn đề đó. Môi trường của bạn vẫn có thể thất bại với bạn, tại thời điểm đó, bạn sẽ đánh dấu nó là không được hỗ trợ / sẽ không sửa chữa hoặc làm cứng mã của bạn chống lại sự thất bại đó và thêm một bài kiểm tra cho nó. Làm điều đó thường xuyên đủ và bạn sẽ nhận ra rằng bạn thực sự đang thiết kế một hệ thống dự phòng - xem kịch bản # 1.

Tại một số điểm, bạn có thể xác định rằng bạn không còn chắc chắn những gì thất bại hoặc không được xử lý. Bây giờ bạn có thể bắt đầu kéo ngẫu nhiên tấm thảm ra để phát hiện các điểm thất bại.

Điều thú vị duy nhất về ví dụ Netflix là họ chạy các thử nghiệm này trong sản xuất. Điều đó có ý nghĩa nhất định - một số lỗi thực sự chỉ tạo ra những thứ rất khó hoặc không thể mô phỏng trong một môi trường biệt lập. Tôi nghi ngờ rằng Netflix đã dành một thời gian dài trong môi trường thử nghiệm trước khi họ đủ thoải mái để làm điều này trong sản xuất. Và thực sự tất cả những gì họ đang làm là cố gắng để xảy ra sự cố trong giờ làm việc, điều này có ý nghĩa nhất định đối với thị trường của họ nhưng không phải cho nhiều người khác.

Thuật ngữ bạn đang tìm kiếm gần đây đã được đặt ra bởi Nassim Nicholas Taleb: Antifragility. Cuốn sách Antifragile của ông chắc chắn được khuyến khích. Nó hầu như không đề cập đến CNTT, nhưng những điều tương tự không rõ ràng, rõ ràng là truyền cảm hứng nhất. Ý tưởng của anh là mở rộng quy mô của <-> mạnh đến dễ vỡ <-> mạnh <-> chống đông. Phá vỡ mong manh với các sự kiện ngẫu nhiên, quản lý mạnh mẽ với các sự kiện ngẫu nhiên và lợi ích chống mong manh với các sự kiện ngẫu nhiên.

Nó phụ thuộc. Tôi đã nhận thấy rằng các lập trình viên có xu hướng tăng cường quá mức các kỹ thuật áp dụng cho miền cụ thể của họ mà bỏ qua tất cả các kỹ thuật khác. Ví dụ, việc chương trình được phát hành với chi phí sửa tất cả các lỗi có thể tốt ... trừ khi bạn lập trình bộ điều khiển máy bay, lò phản ứng hạt nhân, v.v. "Không tối ưu hóa - chi phí lập trình viên lớn hơn thì chi phí chạy chương trình" là không cần thiết hợp lệ cho HPC vì có chương trình tương đối đơn giản có thể chiếm cụm trong nhiều tháng, v.v. (hoặc thậm chí là một chương trình phổ biến được sử dụng bởi số lượng lớn người dùng). Vì vậy, ngay cả khi công ty X đang làm Y vì lý do rất chính đáng, bạn không cần phải theo bước chân của họ vì tình huống của bạn có thể khác.

Thông thường các thói quen xử lý lỗi là phần được kiểm tra tồi tệ nhất của mã - trong khi có vẻ đơn giản, thật khó để mô phỏng rằng không có đủ bộ nhớ hoặc một số tệp quan trọng không có ở đó. Vì lý do đó, tôi đọc các văn bản được đề xuất cho hạt nhân Unix để ngẫu nhiên thất bại một số cuộc gọi hệ thống. Tuy nhiên, nó sẽ làm cho một chương trình đơn giản khó viết hơn (nếu tôi cần cắm 3 thư viện C ++ lại với nhau để chạy một chương trình trên 2 tệp một khi tôi không muốn xử lý lỗi). Ngay cả với các trường hợp ngoại lệ, GC bạn cần đảm bảo rằng bạn để lại trạng thái nhất quán phía sau (tưởng tượng ngoại lệ ở giữa thêm nút vào danh sách được liên kết).

Càng nhiều dịch vụ phân tán, bạn càng có nhiều thất bại là câu hỏi về "mức độ thường xuyên" sau đó "nếu" hoặc "khi nào". Trong trung tâm dữ liệu, việc thay thế đĩa trong RAID là một phần của các hoạt động thông thường từ những gì tôi biết - không phải là một sự cố bất ngờ. Nếu bạn hoạt động ở quy mô lớn, bạn cần tính đến nó ngay cả khi xác suất thất bại của một thành phần là nhỏ, rất có thể điều gì đó sẽ thất bại.

Tôi không biết chính xác những gì bạn đang làm nhưng để biết liệu nó có đáng không, bạn cần phải suy nghĩ nếu thất bại là điều bạn cần phải tính đến (vì bỏ qua chi phí) hoặc đó là một cái gì đó quá tốn kém để phân tích (như nhận lỗi vào tài khoản chi phí thời gian phát triển).

Máy chủ IIS có một tính năng có thể định cấu hình, tự động tái chế các tiến trình của nhân viên sau khi họ đã sử dụng một lượng bộ nhớ nhất định hoặc sau khi phục vụ một số lượng yêu cầu nhất định hoặc sau khi chúng tồn tại trong một khoảng thời gian xác định. ( http://msdn.microsoft.com/en-us/l Library / ms525804 ( v = vs.90 ) .aspx ) và ( http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/L Library / IIS / 1652e79e-21f9-4e89-bc4b-c13f894a0cfe.mspx? Mfr = đúng )

Khi một CONTAINER như IIS làm điều đó, sẽ có ý nghĩa để bảo vệ máy chủ khỏi các quy trình giả mạo. Tuy nhiên tôi muốn tắt nó đi, bởi vì nó không có nghĩa gì nếu bạn đã kiểm tra đầy đủ mã của mình.

Chúng tôi đã làm việc trên các lớp không đáng tin cậy (phần cứng, mạng) vì vậy tôi sẽ không bao giờ viết bất kỳ mã nào ngẫu nhiên giết chủ đề hoặc quy trình của nó. Giết ngẫu nhiên cũng là một ý tưởng tồi từ góc độ kinh tế - không ai sẽ sử dụng API của tôi nếu họ cho rằng tôi đã lập trình nó để sụp đổ ngẫu nhiên. Cuối cùng, nếu tôi sử dụng API hoặc sử dụng hệ thống với các luồng bị sập ngẫu nhiên, tôi sẽ phải chi rất nhiều tiền để tạo ra một cơ chế giám sát đủ mạnh mẽ để nó có thể ngủ yên vào ban đêm.

Thay vào đó, nếu tôi đang phát triển một hệ thống hoặc API, tôi sẽ viết các tập lệnh hoặc sử dụng một khai thác để thực hiện điều này hoàn toàn để kiểm tra khả năng phục hồi của hệ thống. Và tôi sẽ thực hiện một thử nghiệm như vậy trên tất cả các bản dựng để xác định các bản dựng xấu. Tuy nhiên, trong khi đây sẽ là một thử nghiệm cần thiết, nó không bao giờ có thể là một thử nghiệm "đủ".

Có một tài liệu liên quan đến ý tưởng này, nó được gọi là phần mềm Crash-Only (cũng là Máy tính hướng phục hồi) và bạn có thể bắt đầu với bài báo usenix này của Candea & Fox từ năm 2003. Thay vì giết chết ngẫu nhiên, tác giả cho rằng bạn chỉ có thể cải thiện độ tin cậy của hệ thống không bao giờ dừng các chương trình của bạn bằng cách giết chúng, do đó, có một nút tắt duy nhất là nút tắt và một con đường khởi động được thực hiện tốt để phục hồi.

Mặc dù tôi không chắc ý tưởng bắt được tốt như thế nào, một số kỹ thuật cụ thể vẫn hữu ích. Ví dụ: không tin tưởng phần mềm của bạn có thể tự tắt khi được yêu cầu và vì vậy sử dụng các chương trình giám sát chuyên biệt (ví dụ: giám sát, v.v.), và cũng suy nghĩ cẩn thận về trạng thái chương trình nào là thiết yếu và đảm bảo phần mềm được ghi lại vào thời điểm thích hợp trong kho lưu trữ dữ liệu được thiết kế để cho phép phục hồi (ví dụ: cơ sở dữ liệu sql).

Thực sự ngẫu nhiên, không. Nhưng có lẽ đó là một ý tưởng tốt cho các quy trình / luồng chạy dài để thoát / khởi động lại trong một khoảng thời gian nhất định hoặc sau khi không sử dụng trong một thời gian nhất định (nhưng phụ thuộc vào một số tiêu chí nhất định) hoặc sau khi thực hiện một loại tác vụ cụ thể. Các quá trình chạy dài tạo nên trạng thái chắc chắn bao gồm cả những thứ cũ kỹ, có lẽ có thể bám vào bộ nhớ ngăn không gian trao đổi được giải phóng, tất cả đều được (hoặc phải lấy) được dọn sạch khi chúng thoát ra, cải thiện sự ổn định của hệ thống nói chung.

Nó phụ thuộc vào loại ứng dụng mà bạn đang thiết kế.

Sự cố ngẫu nhiên là một cách tuyệt vời để kiểm tra và cải thiện sự mạnh mẽ của các hệ thống phân tán (nối mạng).

Trong ví dụ về Netflix, khi chương trình của bạn phụ thuộc vào các dịch vụ từ xa có thể không thành công vì nhiều lý do ngoài tầm kiểm soát của bạn (đĩa cứng bị hỏng, mất điện, sao băng rơi vào trung tâm dữ liệu, v.v.). Dịch vụ của bạn cần phải tiếp tục chạy bằng cách nào đó mặc dù.

Làm thế nào để bạn làm điều đó? Thêm vào sự dư thừa và nhân rộng là một giải pháp phổ biến.

Ví dụ: nếu chuột nhai qua cáp nguồn của máy chủ thì dịch vụ của bạn sẽ có một số giải pháp để tiếp tục chạy. Ví dụ, nó có thể giữ các máy chủ dự phòng dự phòng mà nó sẽ bắt đầu sử dụng thay thế.

Tuy nhiên, nếu chương trình của bạn là một ứng dụng quy trình duy nhất không hoạt động trong mạng, thì việc nó tự giết nó sẽ không kiểm tra bất cứ điều gì vì không có cách nào để phục hồi từ đó.

Dưới đây là một số nhận xét bổ sung về khái niệm Chaos Monkeys http: //www.codinghorror.com/blog/2011/04/usiness-with-the-chaos-monkey.html

Có thể là một cú lật ngẫu nhiên xảy ra do bức xạ vũ trụ . Vấn đề này đã được công nhận và các kỹ thuật khác nhau đã được phát triển để ngăn chặn việc lật bit xảy ra.

Tuy nhiên, không thể khắc phục 100% và hỏng bộ nhớ vẫn có thể gây ra sự cố và những sự cố này vẫn đang xảy ra ( với xác suất rất thấp ).

Bây giờ để trả lời câu hỏi của bạn. Việc bạn có cần thiết kế một hệ thống rất mạnh mẽ hay không, nó phụ thuộc vào những gì bạn đang làm. Nếu bạn cần tạo ra một tàu vũ trụ, tốt hơn hết là bạn nên làm cho nó siêu mạnh mẽ, và sau đó bạn sẽ cần phải tính đến mọi vấn đề có thể.

Nếu bạn cần thiết kế một ứng dụng máy tính để bàn bình thường, thì bạn nên xem các sự cố ngẫu nhiên là lỗi trong mã của mình.

Điều này dường như không phải là vô lý của một ý tưởng.

Hệ điều hành Android giết ngẫu nhiên và khởi động lại ứng dụng / dịch vụ người dùng mọi lúc. Theo kinh nghiệm của tôi, nó chắc chắn đã giúp tôi suy nghĩ sâu hơn về các điều kiện lỗi cũng như thiết kế các kiến ​​trúc mạnh mẽ hơn.