階段 2：設計和實作

本節討論如何實現您的彈性目標。您已映射出對業務最重要的內容，現在是建置它的時候了。如何在不拖慢創新的情況下建置彈性？

將 AWS 受管服務視為彈性捷徑。使用 服務為您處理備援，而不是消耗寶貴的工程時數來維護基礎設施。例如，考慮 Amazon Simple Storage Service (Amazon S3)。它會自動將資料的多個副本存放在 中， AWS 區域 以提供耐久性。它不需要額外的程式碼或深夜分頁器職責。

您的核心應用程式元件呢？ 明智的選擇可能會使團隊的影響倍增。請考慮做為您服務骨幹的資料庫。請考慮使用自動處理容錯移轉的 Amazon Aurora，而不是建置您自己的複寫系統。這些功能可能成本更高，但它們會將團隊的焦點從維護基礎設施轉移到解決業務問題。此成本可以透過更快的功能交付來抵銷，並避免中斷時的收入損失。

有時，新創公司需要建置自訂解決方案。這就是創新新創公司的本質。當您這樣做時，請保持簡單但智慧。使用 Elastic Load Balancing 和 Amazon EC2 Auto Scaling 群組，將您的應用程式分散到多個可用區域。設定 Auto Scaling 群組最小容量，以處理基準流量，即使一個可用區域故障。這可為沒有複雜架構模式的局部故障提供彈性。隨著您的新創公司成長且客戶需要更高的彈性，您可以發展為更複雜的方法。

建議您將生產和開發環境保存在不同的 中 AWS 帳戶。當您快速移動時，混合它們很吸引人，但這個界限是您的安全網。它可防止意義良好的實驗縮減您的生產服務。將其視為「快速移動和破壞事物」開發文化的保險 - 破壞開發中的事物，保持生產穩定。

如果您的應用程式依賴第三方服務，請規劃其失敗。當您的付款處理器發生問題時，您的系統是否可以正常地處理它？ 建置簡單的斷路器和備用選項。可能將這些交易排入佇列，而不是顯示錯誤訊息。您的客戶會感謝您讓一切正常運作，即使 並不完美。

在建置時記錄 ，但請保持實用性。專注於記錄關鍵決策背後的原因，並建立簡單的復原手冊。當事件發生時，請務必備妥這些項目。

您並非為了完美恢復能力而建置；而是為了適當的恢復能力而建置。每個花費在過度工程彈性上的小時都是一個小時，不會花費在客戶要求的功能上。使用 AWS 受管服務作為您的基礎，在最重要的位置新增目標彈性，並建立明確的路徑以隨著業務成長擴展彈性。

下一章會討論如何驗證這些設計選擇，而不會消耗工程資源。對於新創公司，測試應該是合理提升和智慧型投資您應用程式的彈性。