如何预防和管理技术风险
“...见微以知萌，见端以知末，故见象箸而怖，知天下不足也。”
《韩非子》
一切线上问题的发生都是有代价的，包括可衡量的直接商业损失，也包括不可衡量的用户或合作方口碑、社会舆情风险、乃至国家监管要求。与普通研发者不同的是，做好技术风险管理需要管理者从技术本身造成的系统风险的视角，延伸至业务影响因素来综合考量，用合理的成本、有效的方法保障业务的连续性。
一、掌握全貌，坚守底线
要做好技术风险管理，管理者必需先掌握技术风险的全貌，而要了解全貌就必需建立风险的明确分级、标准化的管理、以及统一分析度量。
建立明确的风险定级标准，与标准化风险管理流程
首先需要梳理业务视角的风险等级标准，清晰定义在各场景下的风险应对策略。一般建议在一个业务内统一定义，在跨业务中遵循就高原则，以保障实际运行时针对上下游的业务间对风险分级的标准能够自适应的不断对齐，这样有助于后续标准化管理和流程跑的更加顺畅。级别的定义除了从系统功能影响程度评价，也应综合考量业务影响因素，对高敏感、高风险业务进行适当提高定级标准。
围绕风险分级标准，就可以建立配套的预防、应急、定责问责等管理流程和制度。如：针对高等级风险，要求必要的防控能力、应急响应时效、各级干系人参与标准，以及更详尽的事件复盘及事后责任评估等。在这些标准化流程约束和执行要求下，能够很快的将风险日常管理在团队内建立起来。
建立统一且持续的度量策略，关注定期深度分析及持续改进
在风险管理标准化后，就能对其进行统一度量及固定频率的周期性分析。一般建议根据历史分析、或接下来的软件工程重点，针对性设计标准统一，且持续一定时长的度量策略。这样的度量策略，能够帮助管理者的前置设定目标、并可进行横纵对比，更好的了解风险全貌、评价风险防控工作成果、识别关键突破点。同时要针对多发共性问题、重点风险设定可横向推进的改进策略，保证整体风险管理是从定义管理，到改进预防，人员意识和系统防控能力都是螺旋上升的。
效率和稳定性常常需要平衡，技术风险防控也需要考虑投入产出。在阿里过去技术风险的规则上，采用了“漏斗”式的分层过滤机制：“鼓励建设 -> 规范运行 -> 警示风险 -> 问责结果”，帮助各研发团队建立逐层风险防御要求，同时可在不同层次投入不同的资源。
鼓励更前置的建设投入，预防为主，防微杜渐
更前置的投入风险防控建设往往需要投入的资源更少，但技术风险上的投入对研发而言往往相对业务交付，更不易衡量产出。这就需要从管理者角度，结合对稳定性过程度量，对前置建设投入给与更多的鼓励。在团队中树立典型标杆，以帮助团队中在技术风险相关的优秀工程实践能够被看见，从而能够引导研发在软件研发的前期就更多思考“面向失败的设计”。
低风险重在治理，高风险明确底线
风险一定会发生，在技术风险管理实施过程中，管理者不应过度关注责任，而应将管理重点放到对风险改进的要求上。过度的责任意识，容易使风险管理的执行扭曲变形，导致风险信息的失真，这可能导致更大的风险被隐藏。在技术风险管理策略上，我们针对单次低等级风险事件，建议将重点放在预防、发现、恢复能力的要求上，同时应回归自身，从自身业务风险出发，不断提升上下游能力水位。
虽然不应过度关注责任，但仍然需要设定底线要求，来帮助尽可能规避不可接受的问题发生，这是风险过滤的最后一道防线。底线要求可以考虑两方面，一是人员意识不足，二是灾难性结果。对意识的要求，可以放在频率最高且风险最高的流程节点，如技术风险针对性设定“变更红线” 来规避意识问题，且这类底线设定需要根据实际水位进行定期调优，以满足持续性和适应性。对灾难性结果，底线设定的要点则是提前声明哪些技术风险影响是不可接受的，如：大额资金损失、严重舆情及品牌风险、国家监管导致的业务关停风险等。
二、从“人”的经验不断抽象，演进为“系统能力”
人是流动的，依靠制度与流程约束达到持续有效的结果是不现实的。这需要管理者在日常就将对人的技术风险管理实践，逐步转移到系统能力建设要求上来。
必要的基础运维流程、规范的系统化
基于技术风险规范管理者可以引导团队逐步建立基础运维流程的系统化管理能力。如：业务监控部署、变更灰度过程管控、预案覆盖及保鲜、常态化攻防演练等都是可标准实施的基础运维动作，将这些基础运维流程通过系统化管理，可以更好的保障技术风险相关工作的延续性、有效性。
建立高可用容灾能力，自动化、白屏化的运维能力
为了避免容易产生误差的手工操作，应尽可能地将标准化运维工作自动化、白屏化。这既能降低因人员交替带来的经验差，也能帮助在故障处理中实现更快速的处置恢复。同时在系统设计中，需要提前考虑避免单点的容灾、容错等机制，这些都需要技术管理者在团队要求上予以明确。
三、技术风险度量实践参考
借助标准化的风险管理流程、周期数据分析，往往最先也最易建立结果度量，而易衍生为管理工具。但度量的目标应该是帮助管理者了解现状、引导团队改进，并根据自身发展阶段设计模式，逐步建立过程改进与结果达成的相关性。下面简单介绍，阿里安全生产如何通过度量模式设计引导改进与能力提升，供大家参考。
1. 结果度量：通过目标牵引、统一度量、分解引导三步，使度量更综合，结果更宏观，并具备对比性和引导性。
- 目标牵引：相对单一问题管理者应更关注总体趋势，这一要求上至 CTO 下至末级团队 TL 应有一致认知。通过一致性的目标定义，可以帮助管理者更好的关注到全局状况和趋势变化。
- 统一度量：对结果的度量往往有较多指标，如：故障数、E 级故障数、MTTR、客诉量、资损金额等等，诸多因素使得从横向管理角度很难了解整体趋势。为解决这一问题，我们建立了评价单个故障综合状况的统计算式：故障分，通过这一算式综合评价单个故障。
- 分解引导：有了单个故障综合评价的统计值，再结合单例故障分对团队的分解策略，可起到引导团队改进的效果。如上图所示的分解模式，就定义了对发现和恢复能力建设方面，较原因因素（或通常意义上的责任因素）有更高的要求。
2. 过程度量：关于建立过程度量的要点，我总结为全面丰富的指标、结合工具的改进能力、灵活选择治理重点。
- 全面丰富指标：根据面向工具、研发者调研，我们发现各 BU 均有自己策略来推动过程建设，这是非常棒的最佳实践，如能横向借鉴将有更好的效果。因此我们建立了，围绕研发运维生命周期中风险治理要求的可拓展的指标框架，并提出“指标市场”概念，“市场”意味着开放接纳与竞争择优。通过“指标市场”的长期建设，能帮助管理者选择更优的指标来推进改进。
- 结合工具改进：对于指标的基础要求是数据必须是可通过工具系统采集的，其背后的目的是度量的结果是应是可以结合工具进行改进的，这也搭建起了工具使用者与维护者的关联，帮助工具面向风险治理可以不断完善。
- 灵活选择重点：相较结果度量，过程度量应具备更多的灵活性，来帮助团队发挥自身能动性。选择符合自身场景的指标并应用于改进。
3. 建立二者的联系
最好的结果，是能够逐步建立起两个维度的度量强关联，以保障过程建设与结果的达成直接关联。事实上我们也正朝着这个方向逐步演进，如下的形式已经逐步开始建立链接。
小结
在技术风险预防及管理角度，与研发者不同的是技术管理者应该有更加横向的视角，这体现在掌握全局风险、建立标准管理流程、鼓励前置建设、明确底线要求，同时不断促进经验转化的系统能力建设的管理策略中。
- 技术管理者应帮助团队关注到技术风险带来的业务影响的综合评估；
- 技术管理者应要求团队建立标准且统一的风险管理策略，尽可能掌握风险的全貌。结合持续度量与分析了解风险变化趋势，识别关键改进点，持续跟踪闭环；
- 在团队中更多鼓励前置的建设，以最低成本获取最佳的风险规避结果。同时明确底线要求，不断强化来规避不可接受结果的发生；
- 除了管理策略外，技术管理者更应对“将日常技术风险管理的经验、规则，转化为系统流程、能力”提出明确要求，以规避人因风险，也能在在故障应急时保障更自动、更快速的恢复，进而大大提升系统稳定性；
- 综合以上基础要求，管理者应用好度量实践中建议的度量工具，并根据自身发展阶段设计模式，逐步建立过程改进与结果达成的相关性。