基础设施即代码的一些通用实践
发布时间: 2020-09-03 10:30:02文章作者: 网站编辑阅读量: 235
小的变更，而不是批量变更
当我第一次参与 IT 系统开发时，直觉告诉我：真正发布之前，需要实现一个完整的任务。等到工作“完成”之后再测试和整理，做好发布的准备，这种方式不无道理。这些收尾工作往往需要花费大量的时间和精力，为什么不在真正需要的时候再做呢？基础设施即代码的一些通用实践
然而，我慢慢地体会到了小变更的价值。即使针对较大的任务，一个一个地找出可以独立开发、测试和发布的增量变更也是很有帮助的。我们有很多理由选择小的增量变更，而不是大的批量变更。
小的变更更容易测试和确认可靠性，且工作量更少。
与大批量变更相比，小的变更出现问题更容易找到原因。
小的变更修复和回滚起来更迅速。
大批量变更中的一个小问题会造成变更中的所有内容都延迟发布，即使变更中的绝大部分内容都没问题。
问题的修复和改进会鼓舞士气，而堆积如山的待完成工作会让士气低落。
正如许多良好的工作实践一样，一旦拥有了这个习惯，就很难不去做正确的事情。这个习惯会让你在发布变更时做得更好。现在，如果在一项任务上花了一个多小时还没有进行发布，我会感到很不舒服。
让服务持续可用 基础设施即代码的一些通用实践
无论基础设施发生了什么，服务总是能够响应请求，做到这一点很重要。如果某台服务器消失，其他服务器应该继续正常运行，新的服务器也应该能快速启动，从而保证服务不会中断。这在 IT 领域并不是新鲜事，不过虚拟化和自动化可以让它变得更简单。
广义上的数据管理可能更棘手。不管服务器发生了什么，服务数据都需要保持完整。这个目标可以通过数据复制和其他一些已经存在了数十年的方法来达到。当设计基于云的系统时，重要的是拓宽“需要留存的数据”的定义，通常包括应用程序配置、日志文件等。
反脆弱性：超越“稳健性”
稳健的基础设施是 IT 的典型目标，这意味着系统需要很好地应对诸如故障、负载峰值和攻击等异常情况。然而，基础设施即代码使得基础设施不只有稳健性，还有“反脆弱性”。
Nassim Nicholas Taleb 在《反脆弱：从不确定性中获益》一书中创造了这个词，用以描述那些在压力下变得更加强大的系统。此书的主题不是 IT 系统（主要关注点是金融系统），但他的想法与 IT 架构是相通的。
身体压力对人体的影响是反脆弱性的一个实际例子。锻炼给肌肉和骨骼带来压力，本质上是在破坏它们，但反而使它们变得更强壮。通过避免身体压力和锻炼来保护身体，实际上会让身体变得脆弱，更容易在极端压力面前出现问题。
同样，通过减少变更次数来保护 IT 系统，并不会使它更稳健。相反，那些持续变更和改善系统的团队则能更好地应对灾难和事故。
反脆弱 IT 基础设施的关键是，保证对突发事件的默认响应动作是改善。当系统出现问题时，当务之急并不是修复它，而是提高系统在未来对类似事故的响应能力。
反脆弱IT系统的秘诀 基础设施即代码的一些通用实践
人是系统的一部分，能够应对意外情况并修改系统的其他元素，以便下次可以更好地处理类似的情况。这意味着，运行系统的人需要非常理解且能够持续修改系统。
这与自动化的思想并不契合。自动化是指自动运行系统而无须人类参与。也许将来有一天，只要采购标准的企业级 IT 基础设施并直接运行即可，无须查看其内部状态。然而，这在今天仍然是不可能的。IT 技术和方法都在不断演变，甚至在非技术行业中，最成功的企业也都是那些持续改变和改善其 IT 系统的企业。
持续改善 IT 系统的关键在于那些构建并运行它的人，所以要设计可适应变化的系统，秘诀就是围绕人进行设计。
高效基础设施团队的标志在于，它能够很好地处理不断变化的需求。高效团队会将需求分解成小的任务，并在低风险、低影响的快速变更流中流转这些任务，从而轻松地处理变更和新需求。
以下迹象标志着团队做得很好。
基础设施的每一个元素都可以迅速且毫不费力地重建。
所有系统都持续打了补丁，并保持一致和最新。
在没有基础设施团队成员的参与之下，标准的服务请求（包括置备标准的服务器和环境）都可以在几分钟内完成。SLA 不是必要的。
很少需要维护窗口。在工作时间执行包括软件部署和其他高风险活动在内的变更。
团队跟踪平均恢复时间（mean time to recover，MTTR），并重点关注如何改善它。尽管也可以跟踪平均故障间隔时间（mean time between failure，MTBF），但团队并不依赖于它去避免故障。
团队成员觉得他们的工作给组织增加了可衡量的价值。
