以下是可以在任何环境中完成的四件简单的事情，以帮助改善部署过程。这些将使您获得更好的见解和信心，使您的应用程序正确运行和配置。
- 应用程序运行状况检查
- 事件注释
- Pod：尽量减少影响
- 蓝绿部署
应用程序运行状况检查
改善应用程序的部署和管理的第一步是了解您的应用程序是否运行正常（正在运行并能够执行其预期任务），可以与下游服务进行对话并运行正确的版本。显然，监控是至关重要的，但是我们的监视方式是将其用于自动化部署的关键。在我工作过的所有地方，我们都对应用程序和数据库进行了某种形式的监控，但并非所有人都进行了应用程序运行状况检查。
最近，在Kountable，我们在所有应用程序上都设置了*/public/health点。此健康检查将告诉我们有关应用程序的信息。首先，应用程序是否正常运行*（已启动并准备就绪）。其次，应用程序正在运行什么版本的代码（commit）。第三，应用程序正常运行时间，最后是connection_status。该connnection_status告诉我们，应用程序是否可以连接数据库或下游服务。如果不能，那么我们可以查看这是网络问题，密码问题还是下游服务离线的问题？这有助于缩短应用程序故障时的时间和关注范围。这是一个运行状况检查输出示例。
- {
- "healthy": true,
- "commit": "1e98e46",
- "uptime": "05:22:47:21",
- "connection_status": true
- }
此运行状况检查不仅可以用来监视服务，还可以用作部署过程的一部分。运行状况检查可用于在蓝绿色部署期间验证安装的版本（commit）以及运行状况和连接状态。如果所有这些都通过，再加上其他综合测试，我们可以自动将该部署升级为生产。
在此设置的早期，我们已将运行状况检查失败的服务部署到AWS ECS。提交ID与要部署的ID不匹配。如果您已运行ECS服务，则知道AWS可以出色地完成工作，允许您以对当前正在运行的服务影响最小的方式部署ECS任务的新版本。ECS将启动新任务，验证目标组中配置的运行状况检查终端节点，并且只有当它通过时，它才会耗尽旧任务并启用新服务。过去，我多次看到部署了新的ECS任务，然后始终处于启动和失败的循环中。任务部署上没有AWS错误。唯一的选择是查看CloudWatch日志，您会看到您的服务每分钟启动和停止。可能要花一些时间
通过具有提交ID或版本的应用程序运行状况检查，以及进行蓝绿色部署，我们能够捕获部署失败。部署工具对要部署的提交ID和运行状况检查提交ID进行了验证。当它们不匹配时，部署将停止。这一简单的设置节省了30多分钟的时间来确定问题，并避免了问题投入生产。
事件注释
我一遍又一遍地看到的一个趋势是，当对系统，应用程序或环境没有任何更改时，几乎没有任何问题或中断。当我在Apigee工作时，早期的时候，我们的客户增长很快，并且代码不断发布。在快速开发和持续部署的这段时间内，我们将在生产应用程序中遇到很多问题。在安静的时期，当没有生产部署时，问题将几乎消失或几乎没有。
在不断变化的环境中，很难跟踪所有变化。发生变更时，需要花费一些时间来缩小范围，尤其是随着时间的推移以及在全球范围内推出变更时。我发现易于实现且非常有帮助的一件事是记录更改事件并将该事件添加到您的监控系统。使用部署工具轻松完成此操作，以使用部署事件更新监控系统。
这是一个示例，其中我们最近部署了应用程序，响应时间立即增加。grafana批注标记部署时间，然后您会看到响应时间达到峰值。
除了帮助快速确定原因外，我还发现易于实施的任何部署过程或其他自动化过程的记录事件。我认为需要对环境的所有更改（从配置管理工具运行，修补，备份甚至非自动更改）进行更改。
我发现添加备份事件,通过将备份窗口覆盖到系统资源使用情况（CPU，内存等）而有所帮助。这是查看备份过程是否是导致CPU和内存高峰的罪魁祸首的快速简便的方法。
Pod：尽量减少影响
Pods的概念有许多不同的迭代，从数据中心设计，VMware Pods到Kubernetes Pods。Pod有多种使用或设计的方式。关键是设计应用程序和基础架构，以减少任何故障对部分组件，客户或服务的影响。
当我们在Apigee一起设计应用程序和基础结构时，我们实现了这个概念。从操作方面与Engineering一起工作，我们设计了多租户应用程序，以在2个或更多应用程序Pod上运行客户。对我们而言，Pod是一组应用程序服务，其中有1到X个客户分配给特定Pod。例如，您可能有用于核心应用程序的Pod，有另一个用于分析或日志记录的Pod。在AWS设置中，您可以按AWS区域拥有应用程序Pod，然后可以将客户分配给全球所有或几个区域中每个区域的Pod。其他示例包括Google的gmail如何基于用户的默认位置或FaceBook如何将新功能推出给部分用户。
如果由于云故障，部署问题或其他因素导致特定区域中的Pod出现问题。该问题的影响将仅隔离到该区域中该Pod上的客户。通常，将客户部署到多个区域后，他们将永远不会注意到该问题。
通过一起设计应用程序和基础架构，减少问题影响/爆炸半径的可能性越大，最终的结果就越好。
蓝绿部署
蓝绿部署使您可以运行两个不同版本的应用程序，而一个运行实时流量。您可以通过几种不同的方式进行设置。过去，我在ECS中运行过两个版本的应用程序，都指向同一个数据库。
您的应用程序和数据库需要向前和向后兼容。兼容性的关键是您的数据库架构更改。您需要确保将列删除延迟到两个版本都不需要它为止。
为了在v1.0.3或v1.0.5之间进行切换，AWS ALB设置了两个规则，一个规则用于蓝色，另一个规则用于绿色。ALB将侦听器规则从蓝色切换为绿色，然后耗尽所有旧的（蓝色）连接。
