遷移到雲中託管其應用程序的公司了解到，儘管他們將應用程序託管外包給了第三方雲供應商（例如Amazon Web Services），但他們仍然需要自己監控和管理這些應用程序，通常使用應用程序性能監控解決方案或APM。 使用昨天的客戶端服務器計算應用程序部門幾乎可以完全控制服務器，網絡和最終用戶計算環境。但是，當今的雲環境變得更加複雜，移動的部件常常超出您的控制範圍。

一些公司已經著手進行數字化轉型，將客戶互動推向基於Web的關鍵應用程序中。現在，通過APM自動化解決方案快速響應任何應用程序性能和停機問題比以往任何時候都更為重要。

如何選擇APM解決方案

許多公司轉向應用程序性能管理解決方案，例如AppDynamics，Datadog，Dynatrace或New Relic的解決方案。APM解決方案應識別代碼中的任何性能瓶頸，並幫助您在用戶受到影響之前解決這些問題。

好的APM解決方案將讓您知道發生了什麼，為什麼以及如何防止它將來發生。當所監視的應用程序或系統滿足特定條件（負載，響應時間等）時，APM解決方案將向您發出警報。收到警報後，您應該能夠確定應用程序運行不正常的原因。有了這些信息，您便可以為開發團隊提供非常詳細的診斷信息，以使他們能夠解決問題並防止將來發生這種情況。

但是，您如何選擇正確的應用程序性能監視解決方案解決方案？在Google上快速搜索“雲APM解決方案”會返回5,830,000個結果！對於不熟悉該領域的任何人來說，這可能是不堪重負的。值得慶幸的是，另一個Google搜索還將為您提供有關如何選擇適合您的APM解決方案的大量建議和資源。您應該尋求第三方的非供應商建議，以幫助您確定需求並製定出滿足這些需求的選擇清單。Gartner一直在關注這一類別，並每年發布其APM魔力像限。當了解如何評估應用程序性能監視解決方案解決方案並提供頂級供應商的概述時，它是一個很好的資源。

自動將APM添加到您的修復要求列表中

在SIOS Technology Corporation，我們始終與將其應用程序遷移到雲的客戶合作。他們通常想知道如何保護其應用程序免受不必要的停機影響，並向我們尋求建議。如何保護其應用程序的選擇取決於這些應用程序的重要性（更關鍵的應用程序通常需要故障轉移解決方案等）。 但是，我們也幫助他們了解為什麼他們的應用程序可能容易受到攻擊。

過去，備份和數據保護是一項單獨的功能（僅當APM解決方案確定停機時才需要此功能）。但是，在當今復雜的雲環境中，我們認為組織在監視和管理關鍵應用程序時應該尋求一種整體方法。如果傳統的APM解決方案能夠識別出什麼時候發生並讓您診斷出為什麼發生，那麼為什麼不盡可能避免不必要的停機呢？

我們認為，自動化是大多數雲APM解決方案所缺少的要素。我們的許多客戶通過從APM解決方案中收到太多警報來告訴我們他們如何不知所措，每個警報都要求他們停止並了解發生了什麼以及為什麼。他們很快就會了解要忽略的內容和要注意的內容（好的APM解決方案可以幫助他們通過機器學習來做到這一點）。並且，如果它們的應用程序停止運行，並且何時停止運行，APM解決方案會提醒他們停機時間，並診斷出為什麼要防止再次發生這種情況。但是APM解決方案不會減少其立即停機時間。

那就是SIOS AppKeeper出現的地方。 AppKeeper監視在Amazon EC2上運行的客戶的應用程序，並在檢測到停機時自動重啟EC2上的服務，甚至重啟EC2實例。我們只有3個Amazon EC2實例的普通客戶每月至少要經歷一次停機。當關鍵的，通常面向客戶的應用程序不可用時以及在I.T.團隊必須放棄一切並做出回應。

AppKeeper的APM自動化解決方案使客戶能夠從超過85％的Amazon EC2停機情況中自動恢復。如果您希望AppKeeper發揮作用，請點擊此處鏈接到快速視頻。

通過AppKeeper的API，客戶可以通過其APM解決方案的警報觸發AppKeeper自動重啟受影響的Amazon EC2服務或在必要時重啟實例，從而以編程方式擴展其APM解決方案的價值。

應用程序性能監視和自動修復。比花生醬和果凍好嗎？

在許多情況下，AppKeeper客戶可以輕鬆管理Amazon EC2環境，其中Amazon EC2實例少於8個。對於他們來說，AppKeeper的本機監視和自動修復功能足以讓他們在晚上安然入睡，因為他們知道，如果有的話，他們可以主動減少停機時間。

但是我們認識到許多客戶擁有更複雜的雲環境，並且已經投資了APM解決方案，例如來自New Relic，Datadog，Dynatrace，LogicMonitor或Zabbix的解決方案。他們已經期望即時警報和豐富的數據集可以幫助他們診斷發生了什麼以及為什麼。對於這組客戶，我們認為將AppKeeper的自動修復功能添加到他們的APM工具包中可以為他們提供兩全其美的優勢：控制其應用程序的性能並減少停機時間。

在接下來的幾個月中，SIOS Technology將與多家領先的APM供應商合作，在其APM解決方案和AppKeeper之間提供打包和認證的集成。使用這些與AppKeeper的集成，這些用戶現在將享受一個閉環系統，在該系統中，他們將收到檢測到的Amazon EC2停機時間以及AppKeeper採取的補救措施的警報。

因此，請繼續關註一些令人振奮的消息。同時，如果您想親自嘗試SIOS AppKeeper，請隨時註冊AppKeeper的14天免費試用版。 AppKeeper的起價為每個實例每月40美元。

經SIOS許可轉載

您需要SIOS Protection Suite（適用於Linux或Windows）或SIOS DataKeeper群集版才能為關鍵業務應用程序提供高可用性保護。

除非

1.您只喜歡免費的解決方案。

我知道了。 肯定有些時候，當我需要學習新技能，快速獲得技巧，投入幾磅或進行快速演示時，我會做同樣的事情。 我沒有註冊訂閱，購買許可證或投資兩者的組合，而是免費了。

然而，俗話說得對，您付的錢就可以得到。 免費試用是可以的。 永久免費的高可用性就像加油站壽司一樣-風險真的值得嗎？ 確保免費不會妨礙您利用可用的充裕性來優化正常運行時間和提高可用性。 確保您沒有通過價格合理的高可用性解決方案，該解決方案已被證明可以保護您的關鍵任務應用程序。

2.作為單一解決方案商店解決方案比滿足您的HA需求更為重要。

幾十年來，我們一直是“福特強硬”家族。 說真的 我了解成為一個解決方案商店的感覺。 我父親擁有一輛福特卡車用於工作，一輛福特野馬用於休閒，一輛福特3600拖拉機用於農場以及一輛福特小型貨車用於家庭旅行。 甚至有一個季節，我們還收到了帶有藍色橢圓形的模型玩具車。

但是，當我和妻子根據自己的家庭需求擴展時，我們放棄了單一解決方案來解決福特駕駛室（當時）無法滿足的需求。 您可能是一家商店的購買者，但是如果您的需求發生了變化並且HA提供商或解決方案沒有跟上，請考慮擴展解決方案集將消除風險，提高成功率，還是值得為那些補充解決方案進行投資新需求。 當我們需要可靠，省氣，時尚，家庭友好且經濟實惠的解決方案時，我們向本田Odyssey補充了福特Tough。 如果您是一站式服務商，並且您不擔心供應商鎖定好運。

3.您更像是自己動手做的編碼器。

您喜歡編碼。 您喜歡編寫許多腳本，並且不介意拔出bash，ksh，perl，python，powershell，批處理或命令工具包並自行進行連接。 您重視靈活性和增加自己的調整帶來的樂趣。

我也喜歡編寫代碼，但是有時候我想做的最後一件事就是花時間編寫大量代碼和腳本來解決已解決，已證明並已準備就緒的問題。 對於自己動手的管理員來說，現成的不是您的首選，而是考慮是否應為您的企業重新利用和重新構建20年的專業知識和經驗。 但是，如果您必須獲得代碼編寫修復程序，那麼高可用性軟件SIOS會為您提供通用應用程序恢復工具包，以獲取編碼修復程序。

4.您需要Ubuntu支持（或Solaris）。

您的環境是獨一無二的。 您的客戶已經在Solaris上投入了很多心血，並一直堅持不懈地追求生命。 或者，您已經完全擁抱了Linux領域並遷移到了Ubuntu。 無論哪種情況，您都可以查看SIOS產品矩陣，而Ubuntu目前不適合您的SIOS版本。 mm！

儘管這是事實，但請考慮仍然可以使用的豐富而廣泛的功能和支持風格。 雖然您的企業中有一部分已經在Solaris上進行了研究，而其他部分已經在爭相使用Ubuntu和Linux的較新版本，但您更有可能需要一種能夠支持RHEL，OEL，SuSE，CentOS以及Windows的解決方案好。 確保不要通過高可用性解決方案所沒有提供的東西來選擇它，而要考慮它所提供的深度。

5.您不會在環境中混合使用任何東西。

我上週在電影中聽到了。 主角評論了前進的想法，提出了一個新的想法，那就是老闆過於興奮。 經典的話：“有時候榨汁不值得。”在您看來，您沒有在運行混合環境。 您的應用程序很關鍵，但並不復雜。 活動部分很簡單-數據庫，前端和支持應用程序。 您可能不想將其他流程，產品，解決方案或服務“複雜化”，這很有意義，您可能會覺得榨汁不值錢。

在對高可用性軟件做出最終決定之前，請評估非混合環境是否與簡單環境相同。 考慮一下活動部件是否像您想像的那麼簡單，或者採用故障轉移編排的解決方案是否對降低總體RTO和增加RPO有益。

6.醫管局專家的認可和經驗無關緊要。

我在4月中旬在線購買了一套耳機。 我懷疑，我發現任何人都可以做藍牙耳機。 但是，並不是每個人都能做好。 從人體工程學角度講，“新上市”耳機是一場噩夢。 配對是一件輕而易舉的事，但意外的配對卻是一場持續的戰鬥。 音質令人驚嘆，但是當耳機為系統聲音或在歌曲結尾隨機大聲清晰地鳴叫時，這會增加我的煩惱。

您可能會相信任何人都可以完成高可用性和應用程序監視，並且經驗無關緊要。 但是，請考慮您自己的經驗並進行挖掘，並詢問您是否真的想將您的企業環境信任於剛剛開始考慮混合環境的複雜性或您最常使用的應用程序所需的依賴關係和以應用程序為中心的知識的團隊。經常。

在為您的環境選擇合適的高可用性軟件時，請仔細考慮是否要缺少許多一流的功能，經過嚴格測試的解決方案，知識淵博的專家，廣泛的受支持的應用程序和環境以及行業領先的經驗和數十年的洞察力。 然後，經過仔細考慮，明智地選擇。

-SIOS客戶體驗副總裁Cassius Rhue

減少Amazon EC2上託管的WordPress網站的停機時間

使用SIOS AppKeeper從無知變成幸福

WordPress是一個開放源代碼的內容管理系統（CMS），數百萬公司使用它來創建網站，博客或應用程序。據估計，如今有超過7500萬個使用WordPress的網站，許多公司開始在WordPress實例上託管Amazon EC2。 用戶喜歡WordPress的靈活性和創建和修改佈局的便捷性。如果您在網站上使用WordPress，那麼您的公司就很好。

如此眾多的用戶依靠WordPress來驅動其網站，您可以想像有一套旨在滿足這些用戶需求的豐富的第三方工具（插件和服務）。其中一些插件用於添加安全功能，例如用於探測漏洞的掃描儀。因為更多的插件可能導致更多的漏洞。

信任但要驗證。為什麼監視WordPress正常運行時間很重要。

部署未在WordPress上運行的網站或應用程序而沒有對其進行正確監控，就像讓您的車在外面運行並帶有鍵。您需要保護自己的投資。對於管理WordPress網站（或其他任何應用程序）的公司，有三個主要的監視原因：

1. 了解訪客並優化他們的體驗；
2. 監視站點的速度並確保其符合預期的服務水平協議（SLA）；和
3. 為確保您最大限度地延長正常運行時間。停機可能意味著（嚴重）失去了在WordPress上運行的任何電子商務網站的收入。

您相信自己的WordPress網站可以正常運行，但是您確實想知道發生了什麼。監視的目標應該是快速了解發生的情況和原因，以便您快速響應任何問題。

有各種各樣的工具可以幫助WordPress用戶監視其網站。其中一些非常專注於WordPress，例如ManageWP和JetPack，而另一些則是適用於許多不同CMS和應用程序的行業標準解決方案。有些“深入”並專注於監視的一個要素，例如Google Analytics（分析）及其對訪問者分析的關注，而其他一些則試圖“廣泛”並解決監視的所有三個關鍵方面。您決定使用什麼取決於您的預算，需求和技術能力。

在SIOS，我們相信最好的育種方法是有道理的。我們專注於監視應用程序，並確保我們的客戶在使用這些應用程序時所經歷的停機時間盡可能短。今天，我們的許多客戶正在使用SIOS AppKeeper來監視和保護其在Amazon EC2上運行的WordPress網站。

SIOS AppKeeper –簡單但功能強大的WordPress網站監控和自動修復

許多WordPress監控解決方案（從免費插件到低成本的免費增值服務）都會告訴您WordPress網站何時關閉。並且取決於監視解決方案的複雜程度（和成本），它可能會告訴您為什麼您的WordPress網站已關閉。但是，它會幫助您減少停機時間並在遇到停機時間時自動重新啟動服務或重新啟動實例嗎？

許多公司使用Apache或NGINX Web服務器將其WordPress網站託管在Amazon EC2上。SIOS AppKeeper是一項SaaS服務，可以將其配置為自動發現Amazon EC2實例及其服務上運行的WordPress網站或應用程序，然後在遇到停機時自動採取任何行動。因此，您不僅會收到發生某事的通知，而且會自動得到解決，而不僅會收到發生問題的警報。

停機時間很重要。如果您正在使用WordPress運行電子商務網站，則停機將導致收入損失。多少收入？只需將您的年收入除以365天和24小時（年收入/ 365/24），即可了解您的每小時收入。2013年，Google經歷了5分鐘的停運，這使他們損失了545,000美元的收入。 現在，您可能不是Google，但您確實希望盡可能地減少停機時間。

現在，想像一下當您收到WordPress網站已關閉的警報時會發生什麼。您準備好立即回應了嗎？您知道如何解決並恢復WordPress網站正常運行嗎？根據我們的客戶研究，僅使用三個Amazon EC2實例的普通客戶每月至少會經歷一次停機。

SIOS AppKeeper會監控Amazon EC2並提醒您任何停機時間，並通過重新啟動Amazon EC2服務或重新啟動實例來採取措施糾正這種情況。

AppKeeper會自動解決超過85％的客戶的Amazon EC2停機問題。這意味著您可以通知您已識別並解決了故障，而不必丟掉所有東西或損失任何可觀的收入。

如今，數百家公司依靠AppKeeper來保持其云環境正常運行。 我們邀請您觀看下面的視頻，了解安裝和使用AppKeeper多麼容易。

視頻：安裝AppKeeper並從AWS EC2故障演示中恢復

如果您喜歡自己所看到的內容，請隨時註冊AppKeeper的14天免費試用版。 AppKeeper的起價為每個實例每月40美元。

遷移到雲？ 當您轉移到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