提高下降的可用性
你的应用程序在线上运转正常，系统一如往常，团队高效运转。所有事情看上去都是那么好。你的流量持续增长，销售部门非常高兴。所有一切都很好。
然后出现了一些小意外。你的系统发生了一次预料之外的故障。但是这样还好，你的可用性到目前为止还是非常好的。一次故障并不是什么大问题。你的流量还在持续增加。每个人都对此不以为然—这只是“一件小事”罢了。
然后另一次故障又发生了。好吧，总体上来说，我们还是干得不错的。不用慌张，这只不过是另外“一件小事”罢了。
然后又出现了一次故障……
现在你的CEO开始有一点儿担心了。用户开始询问出了什么事情。你的销售团队也开始担心了。
然后又出现了一次故障……
突然，你曾经认为稳定且正常的系统正在变得越来越不稳定，你的故障正在被越来越多的人关注。
现在你遇到真的麻烦了。
发生了什么事？保持系统高可用是一件很难的事情。可用性开始下降时，你应该做什么？你的应用程序可用性已经下降或者正在开始下降，而你需要提高它来保证让用户满意，你应该做什么？
当可用性下降时，知道如何处理会帮助你避免陷入恶性循环。你需要如何来避免可用性下降？以下是一些关键的步骤：
测试并跟踪当前的可用性
将手动流程自动化
自动化部署过程
维护和跟踪管理系统中的所有配置
允许快速更改并进行实验，并且保证如果出现了问题可以轻松回滚
以不断改进应用程序和系统为目标
随着应用程序的变化和增长，将可用性作为一个核心问题来解决
下面几节将进一步详细介绍这些关键步骤。
测试并跟踪当前的可用性
要理解可用性发生的变化，你必须首先测量出当前的可用性是多少。通过跟踪系统可用及不可用的时间，计算出可用性百分比，可以帮助你了解一段时间内的可用性程度。通过这个值，你可以判断出可用性是在提高还是降低。
你应当不断地监控可用性百分比，并定期收集结果。此外，你需要覆盖系统中所有的关键事件点，例如，更改系统配置或者升级的时候，这样可以了解到系统事件和可用性问题之间的关系，也能够帮你确定系统的可用性风险。
接下来，你必须从可用性的角度出发来理解系统应当如何运行。服务分级是一个可以帮助你管理系统可用性的工具。服务分级指的是为各个服务打上一些简单的标签，表示该服务对于系统的关键程度。这使得你和团队能够区分出哪些是至关重要的服务，哪些是很重要但非必需的服务。我们将在第7章深入讨论服务分级。
最终，你需要创建并维护一个风险模型。通过这个工具，你可以了解当前的技术债务以及相关的风险。我们会在第9章来更加完整地介绍风险模型。
既然你已经知道了如何跟踪可用性，以及如何确定并管理你的风险，你需要定期审查你的风险管理计划。
除此之外，你应该建立并实施风险缓和计划来降低系统的风险。它可以为你和开发团队提供一系列具体的实施任务，解决掉系统中最危险的部分。我们会在第9章来详细讨论这部分内容。
将手动流程自动化
为了维护高可用性，你需要移除未知以及不可控的因素，而执行手动操作就是一个常见的为系统带来不可控或未知结果的原因。
你应该永远不要在生产环境中执行手动操作。
当你对系统进行了某项更改后，它对系统造成的影响可能有益，也可能有害。因此，仅允许使用可重复性的任务会给你带来如下好处：
在实施更改前进行测试的能力。在更改之前进行测试，对于避免因为失误造成的故障来说至关重要。
完全控制任务执行的能力。这使你可以在进行更改之前，对更改的内容和步骤进行完善。
由第三方审查更改任务内容的能力。这降低了更改任务产生未预期结果的可能性。
通过版本控制来管理任务的能力。版本控制系统可以让你清楚了解任务被更改的时间、人员以及原因。
对相关资源进行更改的能力。通过更改来提高一台服务器的能力是很不错，但是如果能够将相同的更改，完全一样地应用到所有受影响的服务器上，能够为我们带来更大的价值。
让所有相关资源保持一致的能力。如果你总是对资源（例如，服务器）进行临时的手动更改，那么它们之间会逐渐产生不同的行为方式。由于无法找到可比较的基准行为，这会增加诊断问题的难度。
实施重复性任务的能力。重复性任务都是可审计的任务。对于可审计的任务，可以事后从整个系统层面分析其影响是积极的还是消极的。
事实上，很多系统的生产环境没有任何人有权访问。唯一能够访问的方式就是通过自动化的程序。正是出于我们以上提到的几点原因，这些系统的管理员才将系统隔离了起来。
总而言之，如果你不能重复执行一个任务，那么这个任务就没什么用。事实证明，自动化执行更改可以保持系统和应用程序的稳定性。这其中包括服务器配置更改、性能调优、重启服务器、重启任务、改变路由规则，以及升级和部署软件包。现在我们来看一些你应该使用的可重复任务的例子。
自动化部署
通过自动化部署，可以确保整个系统中的更改都是一致的，并且下次再进行相似更改时，你可以知道它所带来的影响。除此之外，自动化部署系统可以帮助你更可靠地将系统回滚到已知的良好状态。
配置管理
对于服务器的内容，不要“临时手动地更改某个配置变量”，而要使用自动化的方式来进行更改。
至少，你可以编写一段进行更改的脚本，然后通过你的软件更改管理系统来检查该脚本。这样，你可以对系统中的所有服务器进行统一更改。此外，当需要向系统中添加新的服务器或者替换旧服务器时，使用已有的配置可以帮助你更安全地将新服务器添加到系统中，可将影响降到最低。
但是一种更好的、与现代化的最先进的配置管理最佳实践相一致的方法是，引入一个称为基础设施即代码（Infrastructure as Code）的概念。基础设施即代码包括，以一种标准的、机器可读的规范来描述你的基础设施，然后通过一个基础设施工具来传递该规范，该工具可以创建或者更新你的基础设施和配置以使其符合规范。Puppet和Chef等工具可以帮助你简化这个过程的管理。
然后你可以将该规范提交到版本控制系统中，这样就可以跟踪规范的变更，就像跟踪代码变更一样。只要有人对规范进行了更改，就可以通过基础设施工具来运行规范，从而更新你当前的基础设施，使其与规范相匹配。
如果有人需要对基础设施或者其配置进行更改，那么他们必须首先对规范进行更改，将更改提交到版本控制系统，然后通过基础设施工具来“部署”这次更改，从而更新当前的基础设施，使其与规范相匹配。通过这种方式，你可以：
1. 确保基础设施的所有组件都具有一个一致的、已知的以及稳定的配置。
2. 跟踪对基础设施的所有更改，以便在需要时回滚这些更改，或者用来帮助解决与系统事件和宕机相关的问题。
3. 允许结对评审过程—一个类似代码评审的过程，以确保对基础结构的更改是正确和适当的。
4. 允许创建重复的环境，以便使测试、准生产和开发环境保持与生产环境相同。
同样的流程适用于所有的基础设施组件。这其中不仅包括服务器及其操作系统配置，还包括其他的云组件、VPC、负载均衡器、交换机、路由器、网络组件，以及监控应用程序和系统。
为了让基础设施即代码的管理手段发挥作用，必须始终对所有的系统更改使用这个流程。无论何种情况，任何绕过基础设施管理系统进行更改的行为都是不可接受的。永远不能这样做。
你可能都想象不到，我接收到多少封像这样的运维更新邮件：“我们的服务器昨天晚上遇到了一个问题。我们遇到了操作系统最大打开文件数量的限制，于是我手动修改了系统变量，并增加了可允许打开的最大文件数量，服务器已经恢复正常。”
这意味着，一旦有人不小心覆盖了之前的更改，服务又会出现问题，因为没有任何文档记录了这次更改。或者，其他运行相同程序的服务器也会遇到这个问题，因为它们没有进行这个更改。
或者有人进行了另一个改动，这样就会破坏应用程序，因为它与你刚才所做的未记录的更改是不一致的。
一致性、可重复性以及对细节的专注，是成功执行配置管理流程的关键因素。我们这里所描述的标准的、可重复的配置管理流程，对于让你的大规模系统保持高可用性至关重要。
更改实验和高频次更改
拥有一个高可重复的、高自动化的更改和升级流程，带来的另一个好处是允许你对更改进行实验。假设你需要对服务器进行一次更改，并且你相信这会提高应用程序的性能。通过自动化的配置管理流程，你可以做到以下几点：
用文档记录你想要进行的更改。
让经验丰富的人来审查这次变更，他们可以提出建议和改进措施。
在一个测试或者预发布环境中进行测试。
快速、简单地部署更改内容。
快速检查结果。如果这次更改没有达到想要的结果，可以快速回滚到上一次的正常状态。
实现这个流程的关键是，拥有一个具有回滚能力的自动变更流程，以及对系统进行频繁、简易、小范围更改的能力。[1]前者可以让你对多台服务器进行统一更改，后者可以让你对更改内容进行实验，并且在失败的时候进行回滚，让用户几乎感觉不到影响。
自动化的变更完备性测试
当拥有自动化的变更和部署流程时，[2]你可以对所有更改实现一个自动化的完备性测试。你可以使用浏览器测试程序来测试Web应用程序，或者使用一个合成测试程序来模拟用户的交互。
当准备好将变更内容部署到生产环境时，你可以让部署系统先将它们自动部署到某个测试或者预发布环境上。然后，就可以运行这些自动化测试，并检验变更内容的正确性了。
如果通过所有测试，你可以将变更内容按照统一的方式部署到生产环境中。根据测试的不同情况，应该定期对生产环境进行测试，并验证变更的正确性。
通过让整个流程自动化，你会对每次更改更加有信心，知道它们不会对生产系统造成负面的影响。
改进你的系统
现在，你已经拥有了一个可以监控可用性的系统，一个可以跟踪风险和缓和风险的方法，以及一个简单、安全、统一进行变更的流程，可以将精力集中到如何提高应用程序的可用性这一点上了。
你需要经常检查你的风险模型以及恢复计划，将它们作为问题来复盘流程中的一个部分。执行那些能够降低风险模型中风险的计划。将这些变更通过自动化、安全的方式进行部署，并进行完备性测试。之后，你应当检查这些变更对可用性的提升效果。持续这个流程直到可用性达到你希望并且应该达到的程度。
时刻关注不断变化和发展中的应用程序的可用性
随着系统的发展，你需要处理越来越大的流量和越来越多的数据。本书中的大量内容可以帮助你解决不断变化和发展中的应用程序的可用性和伸缩性问题，尤其是在第2章讨论的如何管理失误和错误。还可以通过阅读第7章来确定影响可用性的关键服务的服务分级制度。此外，第8章会讨论的服务等级协议（SLA）的管理。
通常来说，你的应用程序会不断发生变化。因此，你的风险管理、风险缓和、应急方案以及恢复计划也需要不断进行相应的改变。
当可用性开始下降时知道该如何处理，可以帮助你避免进入恶性循环。