光纜故障測試

錯誤處理是軟件開發中最困難且被忽略的部分之一，而且如果系統是分布式的，那么這將變得更加困難。

不錯的論文寫在“ 簡單測試可以預防最關鍵的故障” 主題上。

每個開發人員都應該閱讀本文。 我將嘗試總結本文的主要內容，但建議閱讀該文章以獲取有關它的更多詳細信息。

分布式系統中斷很常見，最近的一些例子是

Youtube于2018年10月關閉約1小時以上

亞馬遜在2018年7月的黃金交易日下跌

Google服務（如Map，Gmail，Youtube）在2018年停運了無數次

Facebook還面臨著許多數據泄漏問題。

本文討論了在分布式系統（如Cassandra，Hbase，HDFS，Redis，Map Reduce）中發生的災難性故障。

根據紙張，大多數錯誤是由于2原因引起的

–由于復雜的事件順序而發生故障

–災難性錯誤是由于處理不當造成的

–我將在我在“ 設計壓力對工程團隊”的帖子中寫到關于“忽略設計壓力”的第三篇

HBase中斷的示例

1 –負載平衡器從從站A到從站的傳輸區域R

2 –從站B的開放區域R

3 –主從屬B擁有后，刪除當前的Zookeeper區域R

4 –從屬B模具

5 –將區域R分配給從屬C和從屬C打開區域

6 – Master嘗試刪除Zookeeper上的Slave B znode，并且因為錯誤的錯誤處理代碼，slave b關閉并且整個集群關閉。

在上面的示例中，事件序列對于重現問題很重要。

當不復制塊時，HDFS失敗。

在此示例中，事件序列也是如此，當新數據節點啟動時，它將暴露系統錯誤。

本文還有更多示例。

錯誤的根本原因

92％的災難性錯誤是由于錯誤處理而發生的。

這意味著扣除了錯誤，但錯誤處理代碼卻不好，這聽起來像您正在從事的許多項目！

1 –錯誤被忽略
這是25％失敗的原因，我認為在許多實時系統中，這個數字會很高。

eg of such error catch(RebootException e) { log.info("Reboot occurred....") }

是的，這種無害的日志語句忽略了異常，并且是錯誤處理的非常常見的反模式。

2 –追趕異常
這也很常見，例如具有通用的catch塊并導致整個系統崩潰

catch(Throwable e) { cluster.abort() }

3 –評論中的TODO / FIXME
是的，真正的分布式生產系統在代碼的關鍵部分也有很多TODO / FIXME。

錯誤處理的其他示例

} catch (IOException e) {?// will never happen ?}} catch (NoTransitionException e) {?/* Why this can happen? Ask God not me. */ ?}try { tableLock.release(); } catch (IOException e) { ?LOG("Can't release lock”, e); }?

4 –優先開發功能
我認為所有軟件工程師都會同意。 這也稱為技術債務，我想不出比Knight Capital破產更好的例子了，這是由于配置和實驗代碼所致。

結論

所有的錯誤都是很復雜的，但是重現更好的單元測試肯定會抓住這些錯誤，這也表明，在許多系統中進行的單元/集成測試不是在測試諸如服務中斷并再次返回以及如何影響系統的場景。

根據上面的示例，看起來所有錯誤都是由于Java檢查異常引起的，但是在其他系統（如C / C ++）中沒有檢查但未檢查所有內容的情況也沒有什么不同，開發人員有責任在各個地方進行檢查。

附帶說明一下，沒有像Python這樣的類型系統的語言使編寫在運行時中斷的代碼變得非常容易，如果您真倒霉，那么錯誤處理代碼將出現類型錯誤，并且將在生產中進行測試。

同樣，幾乎所有產品都將具有一些靜態代碼工具（findbugs）集成，但是這些工具并沒有更加重視這種錯誤處理反模式。

鏈接到論文中提到的問題

HDFS

MapReduce

HBase的

雷迪斯

卡桑德拉

請分享您在生產系統中看到的更多反模式。

直到快樂的單元測試。

翻譯自: https://www.javacodegeeks.com/2018/10/simple-testing-prevent-critical-failures.html

光纜故障測試

總結

以上是生活随笔為你收集整理的光缆故障测试_简单的测试可以防止最严重的故障的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。