99% 情境
這些工作負載對業務有幫助, 但只有在無法使用時 才會造成不便。這類工作負載可以是內部工具、內部知識管理或專案追蹤。或者,這些可以是實際面向客戶的工作負載,但由實驗性服務提供,且內含可視需要隱藏服務的功能切換。
可以在一個區域和一個可用區域中部署這些工作負載。
監控資源
我們將進行簡單的監控,以指示服務主頁是否返回 HTTP 200 OK 狀態。當出現問題時,我們的程序手冊將指出可使用來自執行個體的記錄來確定根本原因。
適應需求變更
我們將提供有關常見硬體故障、緊急軟體更新和其他破壞性更改的程序手冊。
實作變更
我們將使用 AWS CloudFormation 定義我們的 Infrastructure as Code,特別是在發生故障時加快重建速度。
我們將使用執行手冊手動執行軟體更新,並需要停機才能安裝和重啟服務。如果部署期間發生問題,請參閱執行手冊,了解如何回復到以前的版本。
錯誤的任何糾正措施都是透過營運和開發團隊的日誌分析來完成,而且會在排定修正的優先順序並完成修正之後部署糾正措施。
備份資料
我們將使用供應商或特定目的的備份解決方案,以使用執行手冊將加密的備份資料傳送到 Amazon S3。我們將透過使用執行手冊還原資料,並確保能夠定期使用資料來測試備份是否能正常工作。我們在 Amazon S3 物件上設定版本控制,並移除備份的刪除許可。我們將根據要求使用 Amazon S3 儲存貯體生命週期政策,來存檔或永久刪除。
彈性架構師
在一個區域和一個可用區域中部署工作負載。我們將應用程式 (包括資料庫) 部署到一個執行個體中。
測試彈性
新軟體的部署管道已排程好,並測試了一些單位,但大多數是對組裝工作負載的白箱/黑箱測試。
災難復原 (DR) 計畫
在故障期間,我們將等待故障完成,可以選擇透過執行手冊來使用 DNS 修改,進而將請求路由到靜態網站。此操作的復原時間取決於基礎設施的部署速度,以及資料庫還原到最新備份的速度。如果使用執行手冊的可用區域發生故障,則此部署可以位於相同的可用區域中,也可以位於不同的可用區域中。
可用性設計目標
假設我們部署到新的可用區域,並假設可以在 30 分鐘內還原資料庫,我們需要 30 分鐘的時間來理解並決定執行復原,在 10 分鐘內將整個堆疊部署到 AWS CloudFormation 中。這意味著從故障中復原大約需要 70 分鐘。假設每季度發生一次故障,我們估計全年的影響時間為 280 分鐘,即四小時 40 分鐘。
這表示可用性的上限為 99.9%。實際可用性還取決於實際故障率、故障持續時間以及每個故障實際復原的速度。對於這種架構,我們要求應用程式離線處理更新 (估計每年 24 小時:每次變更四小時,每年六次) 以及實際事件。因此,根據本白皮書前文有關應用程式可用性的資料表,我們發現我們的 可用性設計目標 是 99%。
總結
主題 | 實作 |
---|---|
監控資源 | 僅現場運行狀態;沒有提醒。 |
適應需求變更 | 透過重新部署垂直擴展。 |
實作變更 | 用於部署和還原的執行手冊。 |
備份資料 | 用於備份和還原的執行手冊。 |
彈性架構師 | 完成重建;從備份還原。 |
測試彈性 | 完成重建;從備份還原。 |
災難復原 (DR) 計畫 | 加密的備份,如果需要,還原到其他可用區域。 |