cesium 起火
我想我们大多数人都会分享一些恐怖的故事，以在生产环境中运行我们的应用程序。 事情没有按预期工作。 事情很快就失控了。 甚至是没有明显原因而停止工作的事物。 一本很棒的书， 上面写着很多这样的恐怖故事， 这是Michael T. Nygard撰写的 Release It !：设计和部署生产就绪软件（实用程序员） 。
要问自己一个合理的问题是：为什么毕竟在设计和开发软件上付出努力，生产系统的质量仍然很差。 归根结底，所有开发工作的结果就是我们构建的系统，如果该系统不能满足用户的期望，那么这项工作就没有多大意义了。
几乎每个系统/应用程序都有错误。 这篇文章的主题是工程师在系统上线时应该有的心态。 生产中总是会出现意想不到的情况，但最重要的是如何限制这些情况的数量，如何不引入新情况，最重要的是如何从错误中学习。
原因
无论我们的代码有多干净 ，或使用什么开发过程，生产中出现问题的原因通常是开发与生产之间存在差距。
在基础架构和工作负载方面，生产环境与开发环境不同。 通常，生产和开发环境之间的差距会随着我们系统的复杂性而增加。 登台和测试环境可以（部分）填补这一空白，但前提是它们可以反映生产环境，而通常情况并非如此。 （不幸的）事实是，建立和维护与生产环境相似的环境的成本很高，而且通常是第一个削减的成本。
在微服务中，被认为是在没有CI / CD的情况下开始开发服务的最佳选择。 微服务本质上是复杂的，因此经验已经证明，如果从一开始就没有CI / CD，那您将处于困境。
不幸的是，在设计和开发阶段，我们倾向于用假设来填补这一空白。 这些假设需要一些创造力和想象力，自然会降低信心。 我们希望把它们弄对 。 因此，如果我们没有办法验证这些假设，那么不可避免地，它们将在最糟糕的时刻被证明是错误的（相信我， 墨菲定律就是一回事）。
从分析到部署，软件的整个生命周期都应具有最低限度的假设。
格外小心对待生产
当事情失控时，我们需要立即采取行动。 我们的主要目标是解决问题并使系统恢复健康状态。 另外，我们应该能够收集数据以进行事后分析。
在使系统恢复到健康状态的过程中，我们可能会尝试进行一些手动操作。 这些黑客可能包括手动更改一些配置文件，重新启动正在运行的服务的实例，甚至更改代码/工件。 尽管这些黑客可以通过重新启动系统来拯救我们，但它们通常要付出一定的代价。 我们需要跟踪我们所做的一切； 否则，我们最终将在生产环境中运行未知的配置。
绝对应该避免这种可怕的情况 。 拥有一个配置未知的系统要比根本没有该系统更糟糕，因为没有人知道该系统的行为。 就像赌博一样，它损害了软件生命周期前期的所有努力。
请记住：流程的质量是所有子流程的最低质量。 如果我们不注意生命周期的一部分，那么最终整个生命周期将很糟糕。
如何处理生产问题
处理生产问题的最佳方法是事先进行一些分析，并确定发生问题时要遵循的流程。 使用错误跟踪系统记录已发生的问题。 有一个定义明确的过程来更改数据（如果需要）。 在系统处于问题状态时对其进行快照，以供日后检查。
但最重要的是，为您认为可能出现的所有事情制定一个流程。 无论听起来多么琐碎，多少疼痛都会导致程序不足，您会感到惊讶。 我们需要将问题和错误视为一级公民，而不是罕见的事件。 事情会出错，我们必须忍受！
生产系统中可能会发生两类问题：与业务相关的问题和运营问题。
与业务有关的问题
与业务相关的问题包括阻碍我们的用户完成工作的所有因素。 它们通常是由于系统中的错误或功能缺失而发生的，但并非总是如此，正如我们在下一段中看到的那样。
我们应该以支持更改的方式设计软件，这样就不必手动直接在数据库中编辑数据。 总是需要更改系统中的数据，如果直接在数据库中进行更改，则可能会使系统处于不一致状态。 例如，假设某个用户抱怨说，由于前端中的某些内容损坏，您无法手动添加商品，因此他们无法在购物车中添加商品。
我们需要特殊的端点/服务/工具来为我们做到这一点，并避免手动添加。 这样做有两个原因。 首先，在购物车中添加商品可能意味着不仅仅是数据库中的记录。 我们的应用程序可能会将消息发送到某个外部系统进行分析，等等。其次，这些特殊服务通常由支持工程师（SRE）使用，他们可能不了解系统内部，即使他们知道，也可能不知道。跟上系统的最新变化。 我们的系统中的操作越复杂，如果手动完成操作，就越容易出错。
运营问题
与操作相关的问题包括我们部署应用程序的计算机出现故障，网络问题等。我们的基础结构越复杂，手动处理问题就越困难。 想象一下，我们的基础架构中有数十或数百个节点，其中一些节点开始出现故障，几乎不可能一次处理所有节点并解决所有问题。 即使是简单的应用程序升级也可能需要数周的时间，并且容易出现可能非常严重的错误。
我们需要使用工具来自动化这些过程。 从简单的数据库迁移到大规模重新部署所有节点，我们需要尽可能地消除人为干扰。 值得庆幸的是，有许多工具和技术可以帮助我们应对这种情况。 我们应该使用CI / CD工具和实践来自动化应用程序的部署。 使用Kubernetes之类的工具来处理我们的基础架构的部署和管理的痛苦，通过使用蓝/绿部署等技术来减少部署的停机时间，使用ELK或New Relic之类的工具来跟踪系统中发生的一切。
当然，对于我们的情况，其中一些工具可能太复杂或太昂贵，我们可能会考虑创建自己的工具。 在开始构建自己的工具之前，我们需要考虑一些事项。 首先，这些工具的构建非常复杂。 它们在生产中已经发展了几年，而创造它们的人都是这一领域的专家。 其次，大多数开发定制工具的尝试都是这样的：一种工具使少数人知道它是如何工作的，并且它已经过时了，但是这些人负担了很多其他任务，他们没有时间去做。花在工具维护上。 由于它的重要性和缺乏文档，新人不敢接触此工具。 因此，我们系统生命周期的关键部分取决于一些没有能力的人。
有关操作问题的建议很简单。 除非开发此类工具要给您带来一定的竞争优势，否则请使用标准工具并雇用一些DevOps。 不要冒险尝试重新发明轮子而冒险。 如今是这样的。
从错误中学习
积极主动意味着要开发能够防止错误发生的流程和实践，但是总会有一些我们从未遇到过的新情况。 我认为这些情况很有价值，因为我可以向他们学习。 在这种情况下，我们需要做出React，拥抱失败并制定计划。
分流
报告错误后，我们必须能够评估其重要性和影响。 错误的严重性可能有所不同。 它们只能在极少数情况下出现，它们可以影响特定用户，或者可以导致整个服务崩溃和刻录。
故障排除
好的系统可以通过设计调试。 可调试意味着任何（支持）工程师都应具有必需的工具来检查系统的运行状况和状态。 这可以是日志，仪表板或调试API（微服务架构也应将请求关联起来，以便可以端到端地跟踪它们）。 当您尝试了解问题时，日志非常重要。 我们需要确保开发人员正确使用了不同的日志级别（错误，警告，信息等），并提供了有关发生的情况以及原因的有用见解。 仅记录堆栈跟踪是不够的。 服务器和框架公开有关内存/ CPU，请求数量，延迟等的指标。我们还应该提供有关系统的各种关键过程的调试仪表板或API。 如果我们有一个计划的关键作业必须定期运行，那么我们应该提供一个调试API，至少应提供运行作业的成功/失败率和进度。
验尸和历史
我们应该努力为生产中遇到的每个错误报告创建测试。 拥有一个自动化测试套件是积极主动的过程，可确保不会再次出现该错误（除非该套件具有一些偷偷摸摸的易碎测试 ）。 此外，撰写有关已发生事件的报告（ 事后分析 ）将有助于我们更详细地了解问题，原因和发生方式。
当出现问题时，我们应尽力找出其根本原因并防止其再次发生。 拥有一个由于某种我们无法理解的原因而偶尔失败的系统，是一场噩梦。
阅读Michael T. Nygard撰写的“发布！：设计和部署生产就绪型软件（实用程序员）” ，您将了解似乎无辜的许多不同事物可以使我们的系统崩溃。 阅读有关其如何处理问题的工程博客。 研究类似的系统。 从他人的经验中学习！
监控系统
如前几节所述，有很多工具可以监视我们的系统。 我们可以看到尖刻的工作负载如何给基础架构带来压力，在达到某些资源限制时发出警报，或者在应用程序日志中具有汇总视图。
我们应该始终注意这些监视工具，因为它们可以显示未来问题的迹象。 例如，如果由于某种原因数据库过载，但工作负载正常，则可能表明即将出现问题。
这些监视工具的数据应用于驱动系统行为的文档记录。
我们必须知道我们的系统容量是多少，以及它在特定配置下的行为以及系统的限制和问题。
结论
无论我们做什么，生产中总会有问题。 这是我们必须接受的真理。 我们唯一能做的就是教育自己使问题的风险降至最低，并以专业的态度对待系统。
“愿查询继续进行，寻呼机保持沉默。”
-传统的SRE祝福
进一步阅读
- 发布它！： Michael T. Nygard 设计和部署生产就绪型软件（实用程序员）
- 网站可靠性工程： Betsy Beyer，Chris Jones，Jennifer Petoff和Niall Richard Murphy的 Google如何运行生产系统
- 验尸的例子
cesium 起火
8348
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
