1. 定義：組織錯誤發展成故障，把錯誤影響限制在一定範圍內，使系統恢復成為可能。
2.一般場景生成
在去除伺服器維護時間以外，基本可以保證每天24小時均是可用。伺服器的維護時間，每次維護從檢測到伺服器故障到服務重啟進行正常提供服務。
3.分類
戰術分為：錯誤檢測、錯誤恢復、錯誤預防。
① 錯誤檢測
命令/響應：乙個構件發出乙個命令，並希望在預定義的時間內收到乙個來自審查構件的響應，例如遠端錯誤的檢測。
心跳（計時器）：乙個構件定期發出乙個心跳訊息，另乙個構件收聽到訊息，如果未收到心跳訊息，則假定構件失敗，並通知錯誤糾正構件。
異常：當出現異常時，異常處理程式開發執行。
② 錯誤恢復
表決：通過冗餘構件（或處理器）與表決器連線，構件按相同的輸入及演算法計算輸出值交給表決器，由表決器按表決演算法（如多數規則）確定是否有構件出錯，表決通常用在控制系統中。
主動冗餘（熱重啟、熱備份）：所有的冗餘構件都以並行的方式對事件做出響應。它們都處在相同的狀態，但僅使用乙個構件的響應，丟棄其餘構件的響應。錯誤發生時通過切換的方式使用另乙個構件的響應。
被動冗餘（曖重啟/雙冗餘/三冗餘）：乙個構件（主構件）對事件做出響應，並通知其他構件（備用的）必須進行的狀態更新（同步）。當錯誤發生時，備用構件從最新同步點接替主構件的工作。
備件：備件是計算平台配置用於更換各種不同的故障構件。
狀態再同步：主動和被動冗餘戰術要求所恢復的構件在重新提供服務前更新其狀態。更新方法取決於可以承受的停機時間、更新的規模及更新的內容多少。
檢查點/回滾：檢查點就是使狀態一致的同步點，它或者是定期進行，或者是對具體事件做出響應。當在兩檢查點之間發生故障時，則以這個一致狀態的檢查點（有快照）和之後發生的事務日誌來恢復系統（資料庫中常使用）。
1.錯誤檢測——try/catch模組**的應用
在系統開發時要注重更多的使用try/catch模組，當出現宜昌市要及時進行捕獲並給出提示，避免在系統執行時出現一些404、500等不好的介面，系統崩潰，
比如在資料庫進行連線時，運用try/catch檢測連線資料庫部分是否成功。
2.錯誤預防
視覺化展示中的錯誤預防，我覺得就是避免展示介面不完整，資料展示出錯等的錯誤預防，在這一部分，在編寫**時可以在資料從資料庫傳值時判斷是否正確並輸出，然後再傳到介面進行展示。
3.自動恢復
關於這個視覺化展示的自動恢復，我覺得應該就是在展示介面使用者進行重新整理等問題，想到了12306系統崩潰得最主要原因就是訪問得使用者數量過多，請求重新整理傳值得次數太多，造成系統崩潰，而在網課學習期間，不少學習軟體也出現了這樣得情況，所以，在自動恢復方面，我覺得如果把這個服務搭建在遠端伺服器上首先考慮的就是這個問題，要展示乙個十分友好的錯誤提示耐心等待介面，然後進行系統的恢復。
在自動恢復中，本系統我覺得最應該注意的就是資料庫或系統**的備份工作，以防發生意外是進行恢復
可用性可修改性戰術分析
通過閱讀 大型 技術架構 核心原理與案例分析 的第 五 六 七章，對 的可用性和修改性戰術有了進一步的理解，接下來就來談談我的認識。的可用性描述 可有效訪問的特性。相比於 的其他非功能特性，的可用性更牽動著人們的神經，大型 的不可用事故直接影響公司形象和利益，許多網際網路公司都將 可用性列入了工程師...
質量屬性 可用性戰術
戰術就是影響質量屬性響應控制的設計決策，共包括六種戰術 可用性戰術 可修改性戰術 效能戰術 安全性戰術 可測試性戰術 易用性戰術 戰術的集合稱為 構架設計策略 可用性與系統故障及其後果相關。當系統不再提供其規範中所說的服務時，就出現了系統故障。系統使用者可以觀察到此類故障。可用性是指系統正常執行時間...
可用性和可修改性戰術分析
可用性和可修改性戰術 分析 的可用性描述 可有效性訪問的特性。有好多時候不能訪問，比如，dns會被劫持，cdn服務可能會掛掉，伺服器可能會失靈，程式會有 bug，黑客會攻擊，會引來大量訪問，第三方合作夥伴的服務會不可用 所以，要保證乙個 永遠完全可用幾乎是不可能完成的任務。的高可用性，要求萬無一失，...