遷移到雲？ 當您轉移到Amazon EC2時，這是應該如何更改DevOps優先級的

大多數遷移到雲或創建“雲原生”應用程序的公司都使用Amazon Web Services（AWS）進行了遷移。AWS提供了許多成本和功能優勢。那些採用行業標準的開發人員運營（“ DevOps”）最佳實踐來監視和管理內部部署環境的公司通常會問自己如何適應新的雲環境和應用程序。

從本地應用程序遷移到Amazon EC2時，DevOps優先級將如何變化？這是兩者之間的區別以及您應注意的事項的解釋。

雲中的DevOps優先級？相同。 但是不一樣。

我們經常聽到客戶說，當他們遷移到AWS時，操作會更容易。 我們告誡他們，遷移到雲（甚至是AWS）並不意味著他們不再需要監視和管理其應用程序。

遷移到Amazon AWS的公司可以在硬件採購，供應和維護方面利用較低的成本和人力資源。但是您需要考慮到，當您決定在Amazon EC2上託管應用程序時，操作系統層以上的任何事情都是您的責任。

當涉及到Amazon EC2環境的備份/可用性保證/安全措施等時，優先級與本地應用程序相同。 亞馬遜提供了一些本地工具和功能。但是您需要確定它們是否適合需求。

安全，備份… 管理Amazon AWS環境時需要了解什麼？

那麼，在遷移到Amazon EC2時需要牢記哪些特定於AWS的注意事項？而什麼是最適合您的工具？您在設計應用程序上投入的時間以及如何部署和管理應用程序將為您帶來回報。

首先要考慮的是如何保護Amazon EC2應用程序。必須以與本地應用程序相同的方式來考慮網絡設計，例如“打開哪些端口”和“從何處允許訪問”。可以在AWS中使用安全組和網絡ACL（訪問控制列表）進行配置。

您可以使用AWS Trusted Advisor功能*，該功能會自動檢查您的AWS環境並指出是否將其設置為建議的設置，從而可以檢查公司的AWS環境中的安全性問題。我們建議在實施時並定期與AWS Trusted Advisor進行檢查。

安全性的另一個基本方面是身份驗證和訪問權限的管理。AWS將所有這些整合到AWS Identity and Access Management（AWS IAM）中。除了控制哪些人可以訪問哪些EC2實例之外，您還可以使用AWS IAM設置從EC2實例到其他資源（例如DB）等的訪問權限。一旦遷移到AWS，您需要做的第一件事是為了在AWS IAM中正確設置帳戶和訪問限制。

下一個考慮因素是“如何在Amazon EC2上備份我的應用程序？” Amazon EC2提供了拍攝快照的功能，您可以執行此操作。此外，使用“ Amazon Data Lifecycle Manager”可以輕鬆設置定期快照以及增量備份。快照文件存儲在Amazon S3存儲服務上。您需要根據其容量收費，因此您需要了解所擁有的數據量，並設置諸如“通過增量備份減少容量”和“從舊數據刪除”這樣的設置。

需要事先考慮“可用性”。 關鍵是根據系統的優先級來操作系統。

最後考慮的是可用性。對於Amazon EC2應用程序以及本地應用程序，您應該根據成本和系統重要性來考慮所需的可用性級別。 但是，如果您使用Amazon的Multi-AZ部署功能，則可以在不同數據中心之間指定冗餘配置。但是，使用多可用區比使用單可用區配置要花費更多（儘管不如使用冗餘本地系統那樣多）。在設計應用程序時，您需要考慮是否需要多可用區以及應該在可用性上投入多少。

如果您不投資於故障轉移，那麼您至少應該監視您的應用程序併計劃在遇到宕機時如何恢復它們。 您可以使用Amazon CloudWatch輕鬆監視CPU，內存和磁盤等常規項目，還可以對Amazon EC2自動恢復功能進行編程，以在EC2中發生錯誤時自動恢復實例。

如果您的應用程序是關鍵任務，那麼您將需要對其可用性進行更多投資。您應該考慮許多出色的第三方解決方案，它們為AWS社區提供了寶貴的功能。一種選擇是SIOS AppKeeper，這是一種易於配置和使用的解決方案，可監控您的Amazon EC2實例並自動重啟服務或在遇到系統故障時重啟實例。這是有關AppKeeper工作原理的快速視頻

雖然為您的應用程序遷移到云非常有意義，但是您不能放棄DevOps最佳實踐。Amazon AWS為您提供了豐富的功能和工具，但是您仍然需要對應用程序的安全性，備份和可用性承擔主要責任。您如何執行此操作取決於您的技能和應用程序本身的重要性。

我們邀請您加入使用AppKeeper的數百個客戶中，通過註冊服務的14天免費試用來減少其Amazon EC2停機時間。

*注意：要使用AWS Trusted Advisor，需要獲得業務支持或更高級的合同。

經SIOS許可轉載

擴展您的高可用性指標

在技術領域，我們喜歡數據。我們喜歡有關數據的數據以及我們工具可以帶來的所有指標和度量。我們圍繞分析技術創建了行業，這些產品可以捕獲數千個已連接設備的每個細節。我們喜歡指標和措施。在更高可用性空間中的許多情況下，我們喜歡高可用性指標，這些指標告訴我們系統從故障中恢復的速度。我們計算並跟踪檢測和修復之間的時間，我們著迷於了解和衡量在災難，系統故障或磁盤崩潰中會丟失多少事務數據。

具有諷刺意味的是，在高可用性和災難恢復（HA / DR）系統中，有些指標沒有引起足夠的重視。

以下是管理環境時應注意的其他八個高可用性指標：

1。  安全警報

可用性不僅涉及應用程序監視和恢復。  公開可用的系統總是受到攻擊。  如果您不監視安全警報和警告，則您的應用程序可能會完美運行，而您的知識產權卻可以完美無缺地被轉移。

2。空閒連接

空閒的連接聽起來無害，但它們幾乎和南部草坪上的綠葉葛根一樣無害。  空閒連接會佔用資源，並有可能填滿數據庫池，擁塞網絡和窒息性能。  此外，空閒連接可能表明應用程序層或數據庫配置存在問題。

3。長期運行的查詢，命令或作業

這不僅適用於數據庫查詢或作業，還適用於命令和備份。  長時間運行的查詢，命令和作業可能表明系統運行狀況不佳，磁盤速度降低，CPU或其他資源爭用，或者係統，應用程序兼容性或操作系統存在更深層次的問題。

4。磁盤IO

磁盤IO通常是指與磁盤活動有關的系統的輸入/輸出操作。測量磁盤I / O可以幫助確定瓶頸，給定工作負載的硬件配置不正確，磁盤大小不正確或磁盤佈局調整不當。  監視磁盤I / O可以幫助您告訴您長時間運行的查詢是否是由於不良的sql語法，不良的應用程序編碼或延遲和訪問問題引起的。

5，記憶

我們都考慮要使用多少內存，但是內存監視不只是衡量和查看可用內存還是已使用內存。  監視內存可幫助您調查瓶頸，洩漏，識別大小不正確的系統，了解負載，平均負載和峰值。  此外，了解內存密集型模式可以幫助您調整可用性套件，以避免錯誤的故障。

6。磁盤空間

作為客戶體驗副總裁，我曾經有過一次很不幸的經歷，要在清晨醒來緊急呼叫。  停電後，客戶面臨停機生產系統。  當他們嘗試重新啟動系統時，受保護的應用程序無法啟動。  快速檢查錯誤日誌後，很明顯根驅動器已100％充滿。  該應用程序無法寫入任何文件系統。  磁盤空間監視有多種形式和方法，將其作為度量標準可以防止不必要的問題和增加更多成本的最後一刻爭奪。。

7 錯誤和警報

日誌中的錯誤，警報和恢復消息是要考慮的另一個很好的指標。  您的可用性解決方案可能會使您的客戶保持在線狀態並感到滿意，但也可能掩蓋了需要盡快引起您注意的問題。  為FATAL，PANIC和關鍵ERROR消息添加日誌監視可以幫助您確定可用性解決方案經常從中恢復的問題，例如數據庫崩潰，應用程序緊急情況或核心轉儲，或者需要冷重啟的致命錯誤。

8。恢復編號

與監視錯誤和警報類似，恢復編號可以告訴您很多有關係統可用性的信息。  如果您平均每週要進行一次以上的應用程序恢復，則可能會遇到比正常的可用性保護更多的事情。  儘管恢復成功地重啟了您的應用程序或系統，但這些錯誤甚至真實的恢復中有太多是不健康的。

我們可以監控的HA / DR指標列表以及用於監控它們的工具正在飛速發展。  確保您和您的團隊考慮擴展當前的數據捕獲和分析，以包括那些可能構成最佳更高可用性系統的數據。

—客戶體驗副總裁Cassius Rhue