韧性文化

规划弹性存在一些问题。

一方面，我们知道这是必要的。如果说COVID大流行没有教会我们其他任何东西，我们了解到意想不到的重大干扰可能会而且将会发生。这些中断不仅涉及技术，在某些情况下，还涉及业务流程、人员、沟通，甚至供应和需求的基本市场特征。然后是规模较小（或看似较小）的干扰：船只封锁运河航道、与勒索软件相关的中断以及工厂火灾。

下一个破坏性事件可能是一种截然不同的疫情。或者它可能根本不是大流行。这可能是全球变暖、战争、贸易战或僵尸启示录的结果。韧性并不是要为 其中 之一 做好计划。它旨在增强应对 任何 未知中断的能力，或者至少是异常广泛的可能性。考虑到当今大大小小的颠覆发生的速度，我们知道我们必须将弹性融入到我们所做的一切中。我们知道这一点，现在我们有工具可以更接近实现的目标。

但是，你如何证明投资弹性是合理的呢？我最近写了一 篇关于优先事项的 博客文章 ，在这篇文章中，我试图表明，对投资优先事项进行排名并只选择其中的最高子集进行执行是有问题的。职能优先事项清单总是太长——公司需要做的事情才能继续运营或以增加利润的方式发展和改进。在治理流程中，理所当然的是，IT工作的需求永远多于供应。正如人们所想，必须根据预期回报对这些收益进行优先排序。

现在说实话：对弹性（或敏捷性）的投资没有 “回报”。 可能 有 回报。我知道。 之所以会有预期的回报，是因为你可以将中断的可能性乘以中断发生时弹性所保持的业务价值，即灾难发生时利润 的增加。 但我说的是针对真正意想不到的干扰进行设计，这种干扰是你无法合理分配概率的。我说的是将增强抵御能力作为一项一般原则或长期战略。那么，你怎么知道它在优先级排序中的位置呢？

我认为在规划弹性时实际上存在一个更深层次的问题。当今的企业以数据为导向，专注于可量化的目标和对照这些目标进行衡量。激励或至少激励员工实现具体、具体的目标。这些目标几乎总是与盈利能力增长保持一致。哪家公司为员工设定了提高应变能力的目标？而且我们知道这些目标将推动员工的行为；这就是我们首先设定目标的原因。

另一个问题是，增加传统系统的弹性似乎是在承认过去做错了事。为什么这些系统一开始不是为了具有弹性而建造的？谁搞砸了？为什么我们突然被迫在已经完成的事情上花更多的钱？

从长远来看，弹性的好处会显现，但公司有强烈的动机来实现短期业绩。在短期内，随着美元的流出，对弹性的投资可能会产生负面影响，但经济基本面并未改变。对弹性的投资是防御性的。

的确，经理和员工可能因为不确保应变能力而承担个人风险。但是人们通常无法很好地管理或评估风险。而且风险很可能不是真正的个人风险。当事情陷入混乱时，就会被归咎于不可避免和意想不到的情况，这是无法预测的罕见因素组合。

简而言之，阻碍弹性的唯一因素是我们对公司治理和人类动机的了解。

我太夸张了。有一些方法可以对弹性进行投资。我们只需要以不同的方式考虑优先级排序的过程即可。

我喜欢将韧性视为质量的一个方面。在 IT 的早期，我们对弹性的标准和需求较低，因此提供不具备真正弹性的 IT 能力是可以接受的。如今，情况并非如此。正如提供存在安全漏洞或扩展能力不足的 IT 功能已变得不可接受一样，交付无法承受小规模或大规模中断的系统已不再是可以接受的。在这种情况下，弹性成本仅包含在新的IT能力的交付中；令人高兴的是，弹性成本也会更低，因为增强弹性比以后再增强弹性要便宜。我们的质量标准已经提高了。复原力不再是一个必须与职能优先事项一起优先考虑的项目。

然后，韧性成为文化问题。抗灾文化要求每个人都将其作为工作的一部分，将任何不具有抗灾能力的东西视为质量差，并共同解决潜在的故障条件并努力缓解这些情况。这与其说是一个目标，不如说是一个不折不扣的做事标准，工作团队会强化这一标准，并由经理进行审查。弹性是持续风险评估的主题，缺乏弹性被视为缺陷。

但这并不能解决遗留系统的问题。我们如何投资以提高他们的应变能力？在某些情况下，这很简单：许多仍在使用的遗留系统都在积极更新。而且，部署的任何新更新都需要满足这个新的质量标准。从逻辑上讲，这需要一些重构（对遗留代码的改进）。这将是有代价的，有时还会减缓新功能的交付，但是当今的最佳做法包括部署未知缺陷为零的新代码（即通过所有测试的代码）。弹性可以简单地成为该质量门槛的一个方面。

提高弹性的第二种技术是降低成本。云是你的朋友，良好的 DevOps 实践所带来的自动化也是如此。找出最适合您的弹性架构和设计模式（例如，多个可用区、集群微服务、数据复制、备份到低成本存储等）你用来提高敏捷性和可用性的许多技术将兼作弹性增强剂。

当你正在使用时，在停用不再使用或不经常使用的系统方面，可能会有一些轻而易举的成果。这样做可以减少成本和维护工作，并提高弹性。为什么不呢？

考虑优先考虑与复原力相关的活动的第三种方法是风险方面。如今，由于其弹性标准未得到满足，该组织到处都面临风险。无论是否必须向股东披露，其中一些都是企业面临的重大风险。董事会审计委员会、风险主管和首席财务官应被告知这些风险，并应考虑积极投资以降低这些风险。降低风险的治理（可能）与按预期回报对项目进行排名的治理是分开的。

要做到这一点，IT 组织必须善于界定和解释风险，以便做出正确的决策。并非所有风险都需要立即解决，但风险会累积。实际上，具有多种弹性风险来源的组织在市场上处于不利地位，有些风险需要迅速解决。IT 领导者应以平衡的方式让其组织意识到风险，显示其潜在影响和可能激活风险的情景，并制定良好的应对计划。根据我的经验，除了提及一些听起来像是IT部门抱怨预算不足的技术债务外，这种对话的频率还不够高。

风险讨论是超越技术危险的机会。如今，许多老牌企业面临的一个风险是，它们依赖一两位掌握旧技术或系统的专家，而且不可能找到可以接管他们的新员工。在某些情况下，这种看似微小的风险可能会对业务产生巨大的影响。另一个被忽视的风险类别与业务管理层变得不可用有关。是的，可能会有一项连续性计划，让其他人担任这些管理职务。但是，替代经理能否获得他们需要的数据，是否有能力在必要时投入资金？

有才华的首席信息官与才华横溢的首席财务官合作，可以通过识别这些风险对弹性的影响、决定要解决的问题以及想办法为这项工作投入资源，为其组织增加可观的长期价值。

现在有个好消息——投资于提高弹性，作为副作用，通常也会提高敏捷性和灵活性。