如何为现代软件团队创建一个风险矩阵

最重要的古器物之一站点可靠性在New Relic工作我们称之为风险矩阵。从本质上讲，风险矩阵是团队识别出的可能出现服务和组件问题的列表。然后，团队根据风险的可能性和影响对这些风险进行分类。

在里面斯特拉报告，研究小组SNAFUcatchers确定处理系统相同部分的团队成员通常具有系统所需的不同心理模型。团队的每个成员如何考虑其系统的工作原理，而不是它实际上如何工作，可以随着成员提交对系统代码库的各种更改，快速摆脱同步。常常，这是一种正常的事态。

不要错过:有效应对突发事件的4大经验教训[视频]

调整服务和组件的内在风险可以帮助我们的团队同步我们生态系统的实际形状。实现这种对齐也使可靠性工作的优先级更容易——实际上也更容易完成。更重要的是，这种清晰性将转化为对组织其余部分的业务价值。

因此，创建和审查风险矩阵有助于我们的团队：

• 同步我们飘忽不定的心智模式
• 新团队成员
• 在我们的系统中识别和地址热点或意外的GOTCHAS
• 当事情发生变化时，看到新的风险
• 优先考虑可靠性工作以避免未来的灾难

New Relic发布了一个内部的“风险矩阵指南”，旨在帮助团队创建和维护他们自己的矩阵。以下四个创建风险矩阵的步骤改编自该指南。

步骤1:风险矩阵建模

我们用威胁评估和修复分析（塔拉）方法该系统最初的设计目的是帮助工程团队“通过应用减少网络攻击易感的对策来识别、确定优先级，并对网络威胁做出反应。”更通俗地说，TARA是“转移、避免、减少和接受”的缩写。虽然我们在New Relic没有使用转移类别，但我们的风险矩阵的设计是让团队确定他们将如何采取步骤来避免、减少或接受风险。

避免:这里划分的风险是那些团队可以完全修复的风险。例如，如果团队在其服务中使用库或其他依赖项，那么团队可能需要安排定期维护窗口，在此期间可以升级这些库或依赖项。

减少:这些是团队无法完全避免的风险，但是团队可以通过额外的工程工作来减少此类风险的影响或可能性。例如，网络中断对所有团队来说都是一个风险，但是我们可以通过确保我们的服务在中断后正常恢复来降低这个风险。

接受:在某些情况下，团队可能会接受风险;这些都是团队知道的风险，但却几乎无法预防。例如，团队必须担心网络宕机，但是如果它的系统在网络宕机之后能够正常恢复，那么团队就可以将该风险归类为它所接受的风险。(但是系统在中断后无法正常恢复的风险属于“减少”类别。)

第2步：建立风险矩阵

有很多方法可以建立风险矩阵。在新的遗物，我们使用aKanban董事会在贾拉。黑板上有三列避免,减少， 和接受类别。我们沿着两个轴对风险进行分类:影响和可能性;每个轴有三个层次:高的,媒介， 和低(详见下文)。

为了构建一个有效的风险矩阵，团队需要关注他们的系统能力，以及他们的客户(内部的或外部的)对这些能力的期望。询问什么会降低或中断这些能力的交付，可以帮助团队关注重要的风险，而不是试图通过处理每一个可能的风险来“煮沸海洋”。

如果团队的风险少于10个风险，它可能希望更深入地思考其系统。相反，如果它已经确定了50个或更多风险，可能需要更严格地减少范围，并更严格地对威胁到提供客户面向客户能力的能力的风险。在大多数情况下，我们建议团队抛弃过于普遍的风险。

最后，我们要求团队识别其上游和下游依赖项以及服务之间的链接中固有的风险。团队还应该对这些风险进行分类，并将它们添加到看板板中。

当一个团队准备好建立它的董事会/风险矩阵时，我们要求这个团队制定时间表至少一个小时的时间——团队的工程经理和产品经理必须出席演习。下表中的问题是为指导这些讨论而设计的:

危险区域	问题
事件	●您的积压中有多少后续事件罚单? ●有哪些服务有最多的事件，为什么？ ●依赖服务恢复后是否需要重新启动服务? 团队事件之间有共性吗?
过程	团队是否有容易出错的手工工作? ●团队是否可以每天部署到登台和生产? 团队的运行手册和文档是什么状态?
代码	●团队是否拥有任何遗留代码，如果有，是否理解这些代码? ●团队拥有多少继承的服务/系统，它们是否被理解? ●代码库中包含多少种语言?
测试	●测试范围是否足够全面? ●回归测试是否自动化并保持最新？ ●误报的数量是多少? ●是否有意义和可操作的失效模式？
依赖关系	●上游依赖项是什么，它们都得到了很好的支持？ ●即将到来的更改API兼容，或者是否存在任何依赖项的生活结束计划？ ●下游依赖项是什么？ ●图书馆是否最新，长期支持？ ●是否依赖于第三方工具?该工具还被支持吗?
意想不到的用户交互	●请求速率有限，易于配置，记录，合适吗？ ●是否检查传入请求的准确性，以确保它们是格式良好的，以防止滥用? 是否对系统吞吐量进行监控和报警? ●请求被验证了吗?
能力和扩展	●系统的设计是否考虑了容量和可伸缩性? ●当吞吐量始终保持在预期容量的75%时，是否设置警报以发出警报? 团队是否参与季度能力计划活动?
监测和报警	●真正警报的误报的比例是多少？ ●团队多久了解支持或最终用户的事件，而不是通过页面提醒？ ●是否为分段和生产设置了相同的监视警报? ●该团队最近是否证实其监控警报仍处于活动状态? ●对系统的故障模式是否有足够的可见性，这些模式是否有警报?

我们希望团队从这些风险中产生真正的工作;减少风险减少工作量需要管理，因此团队实际上是填写它的机会。

对于每个风险，团队创建一个“风险”类型的Jira票据，并将其分配给一个影响和可能性评分，每个从1(高)到3(低)。

让我们仔细看看我们如何定义可能性和影响。

定义风险的可能性

为了避免对可能性的主观评估，我们要求团队编写适合团队的低、中和高可能性的具体定义;在任何时候，用同样的方式使用这些定义。

例如：

• 高的可能性:造成这种风险的事件发生在过去六个月。
• 媒介的可能性:创造风险的活动发生在去年。
• 低可能性:可能引发风险的特定事件尚未发生，但研究小组预测该事件可能发生。

定义风险影响

定义影响也可以是滑溜和主观的。在这种情况下，我们将团队提交给新的遗物事件严重程度：如果发生风险，事件的严重程度会导致什么？例如，潜在事件持续时间的团队因素是通过评估服务的恢复能力，如果依赖性失败并重新恢复服务，或者如果团队的监控和警报足够全面。

此表显示了我们如何将事件严重性应用于影响：

事故严重程度	影响
4或5:涉及到影响但不妨碍客户的小bug或小数据滞后，或者只是为了提高对高风险服务部署等问题的认识	低
3:数据延迟或特性不可用	媒介
1或2:针对产品短暂、全面停机的情况	高的

第三步:克服风险

在一个团队建立了看板/风险矩阵之后，它与它的产品和工程经理一起工作，以优先级工作在避免和减少列。任何标记为高可能/高影响的风险都应该得到最高的优先级。We expect that all teams will have one sprint (work a team can do in one to three weeks that stands on its own, delivers durable business value, and could be shipped to its intended audience when it’s complete) per quarter to reduce the risk count in the避免列。在sprint期间，团队应该包括一个gameday为了测试关于它所解决的风险的假设，并确保团队的心智模型与系统的现实相一致。

需要注意的是，这个计划好的工作可能不能完全消除所有最紧急的风险，但工作应该拨打风险的概率或影响。

第4步：审查风险矩阵

New Relic希望每个团队至少每8个月，或者每当有新的团队成员加入，或者发布新的服务或产品时，都要重新评估其风险矩阵。

如果团队存在风险，并且不确定这些风险是否仍然相关，那么团队应该遵循以下规则:

• 风险是否太过模糊?是，请删除。
• 这个风险实际上属于另一个团队吗?是，请转移。
• 这个风险是安全问题而不是可用性问题吗?如果是，移交给安全组。
• 团队是否控制了这种风险，或者是否做了尽可能多的工作来减轻这种风险?如果是，审查风险的影响和可能性，并放入接受列。
• 如果团队不能修复风险，它是否有监控风险的计划，这样团队就不会使风险变得更糟?如果是，审查风险的影响和可能性，并放入减少列。
• 团队可以安排努力减轻这种风险吗？如果是，审查风险的影响和可能性，并放入避免列。

定期审查风险矩阵使团队诚实地努力保持其系统的可靠性。

可靠性是一个特点

风险矩阵提高了风险的可见性，矩阵将这些风险暴露给整个组织，以便在优先考虑工作时可以做出更好的决策。我们试图使这个过程尽可能简单 - 而且，理想情况下，团队应该看到更少的物品减少和避免列每季度。

如果这种改进没有发生，那么团队可能会挣扎于确定可靠性工作的优先级。这应该能让你和团队的人谈谈网站可靠性冠军。能够优先考虑在服务中减少记录的风险的工作意味着我们认识到可靠性提供业务价值。