随便问一位技术从业者，他大概率都会告诉你：安全很重要。
然而，现实往往并不乐观。即使企业制定了大量安全需求清单，许多应用程序和技术框架依然漏洞频出；一些团队仍在使用早已停止维护的框架；关键组件也没有得到及时更新。与此同时，功能交付的压力几乎总是压过复杂而繁琐的安全流程。
但事情并非只能如此。本文将探讨如何让组织真正把安全融入软件工程实践，通过安全左移、威胁建模、CI/CD 安全扫描、生产监控和应急响应，让安全不再只是事后补救，而是成为软件交付中应有的优先事项。
安全左移：先上新闻，后知后觉
如今，很少有公司真正为安全漏洞带来的影响做好准备。事实上，许多公司第一次意识到自己发生了安全事件，竟然是通过新闻报道。
有研究显示，过去企业发现安全漏洞的平均时间曾长达数月。虽然这一指标近年来有所改善，但需要注意的是，我们谈论的是平均值。这意味着，在许多情况下，数据泄露可能已经发生多年，却始终无人察觉。
与此同时，网络攻击数量不断上升，而攻击者所需的技术门槛却在下降。更重要的是，企业的攻击面正在持续扩大：凡是可以从互联网访问的设备，包括灯泡、婴儿监视器、洗碗机等，都可能持续暴露在扫描和攻击风险之下。
我们都知道，一旦攻击者找到漏洞，后果可能非常严重：监管处罚、股价下跌、品牌受损、客户流失，甚至裁员。但现实中，大型科技公司很少会因为一次网络攻击而彻底倒闭。这也在某种程度上削弱了组织对安全投入的紧迫感。
当安全漏洞终于被发现，数字取证、环境隔离和审计工作随之启动。调查人员往往会发现一个令人尴尬的事实：团队内部其实早就有人知道系统存在问题。他们知道哪里需要修复，也曾发出过警告，但这些警告被忽视了。
我们真正需要的，是一种安全责任共担的模式。
过去十多年，有几类工程和产品实践深刻改变了技术行业：设计思维强调产品的可取性，精益创业强调产品与市场的契合度，DevOps 强调组织的响应能力。它们的共同点在于：都试图把关键目标更早地融入开发流程，而不是等产品完成后再进行补救。
今天，我们已经很容易理解：事后补安全，远比从一开始就把安全融入开发流程困难得多。通俗地说，这通常被称为“安全左移”或 DevSecOps。
软件安全风险评估：人人都想安全，但究竟要防范什么？
面对如此繁多的风险，团队该如何确定安全工作的重点？
许多组织会使用风险评估模型。这些模型通常采用某种“精算式”的思路，通过评估滥用行为的影响和严重程度来量化风险敞口。这类模型本身并没有问题。某些成熟的风险量化方法，也采用了类似思路。
不过，这些模型通常无法直接告诉工程团队应该如何落地控制措施，也很少给出具体的风险降低方案。它们更大的价值在于帮助团队理解自身面对的风险，从而为软件交付生命周期提供背景，并为后续安全实践奠定基础。
安全工作的核心任务，是在企业真实业务目标之下，尽可能确保系统以可靠、可信的方式运行。同时，团队还需要帮助安全专业人员和非安全专业人员建立共同语境：这件事在整体业务中到底有多重要？
为了明确精力应集中在哪里，并与管理层有效沟通，理解应用程序正在处理哪些资产至关重要。
所谓资产，是指具有价值的有形或无形事物，例如生产设备、订单数据、财务交易、个人身份信息、业务规则、算法模型、服务能力或用户体验。团队应结合即将构建的软件来评估这些资产。这样才能理解资产可能如何遭受攻击，应该在何处、何时、以何种方式进行防护，以及攻击成功后可能造成什么影响。
从这个意义上说，资产既可能成为内部或外部恶意攻击的目标，也可能因为疏忽、误操作或系统故障而受损。通常而言，资产对公司越重要，对攻击者也越有价值。
我们先来看资产的价值来源。在多数系统中，价值来自于对有形商品或现实世界行为的转换、索引、上下文化或展示。例如，电商系统中的下单流程，车队管理系统，仓储系统，用户交互分析，或者遥测数据。
另一种价值来自数字服务本身。在这种情况下，资产未必是某个单一对象，而可能是整个服务交付过程和用户体验，例如在线视频、在线协作或实时数据服务。工程团队的职责，是确保这些价值能够稳定、安全地实现。
风险分析的目标，是识别并理解软件攻击、意外故障或疏忽失误会对组织造成什么影响。理解资产，有助于团队进一步明确相应的安全目标。这些目标可能来自法律法规、监管要求，也可能来自业务经验。
常见安全目标包括：
- 保密性：防止数据被未经授权的第三方获取，是隐私保护的重要组成部分。
- 完整性：确保信息保持准确、一致，除非经过授权，否则不应被更改。它要求信息在传输、存储和使用过程中不会发生非预期变化。
- 可用性：确保信息和系统在需要时可访问、可获取、可使用。对任何信息系统而言，可用性都是其发挥业务价值的基础。
这三项目标通常被称为“CIA 三要素”。许多海外数据保护法规都广泛使用这些概念。违反这些安全目标，可能导致严重后果，并直接影响业务。这些风险共同构成了应用程序的风险画像。
灾难场景可以作为威胁模型的基础。它能帮助团队提前思考：攻击可能来自哪里？可能以什么形式发生？届时可能出现哪些问题？这样，团队就能更理性地讨论不同故障模式和攻击模式可能对业务造成的损害。
在软件开发生命周期中，这意味着业务利益相关者需要与交付团队坐下来共同讨论。这个共同任务，是在业务部门和交付团队之间建立安全责任共担机制的第一步。
一种可行的风险评估流程如下：
- 向参与者详细介绍即将构建的功能。
- 与利益相关者分享关于资产构成的背景信息。
- 请每位利益相关者列出若干资产，并将重复或密切相关的资产归类。
- 针对每一项资产或每一类资产，询问利益相关者：如果其保密性、完整性或可用性出现问题，业务会受到怎样的影响？如果可以，最好用货币价值衡量；如果不便量化，也可以使用从“小”到“大”的相对等级。
例如，一家电商平台可能会将订单履行系统视为一项资产。如果该系统不可用，就会造成收入损失。如果订单数据完整性遭到篡改，也会导致类似后果。
对一家健康保险公司而言，患者健康数据是一项必须严格保密的资产。一旦泄露，公司可能面临监管处罚、公众信任下降、保险费用上涨、身份盗窃风险，甚至可能牵涉欺诈行为。
虽然给灾难场景中的影响赋予货币价值并非必须，但这在后续讨论中往往非常有用。
资产库能够在业务团队和交付团队之间建立共同语言，使团队能够基于业务目标，在应用程序开发过程中做出与安全相关的决策。资产库通常以自然语言编写，是一份持续更新的动态文档，旨在回答一个核心问题：什么需要被保护，以及为什么需要被保护？
如果很难识别出具有明确业务影响的资产，例如有些团队正在构建偏底层的技术解决方案，可以从正在解决的问题入手，并思考这一过程中为业务提供了哪些保障。
例如，团队可能正在开发一款用于同步不同来源支付数据流的软件。单个数据点本身可能价值不高，也不一定包含机密信息。但公司依赖这套系统正确同步数据流，因此汇总后的数据对公司的持续运营至关重要。
用于量化灾难场景的依据，通常来自商业经验、司法管辖区要求，或其他公司类似事件中的经验教训。航空公司可以参考海外某些公司的系统中断事件，评估预订系统离线带来的影响。电商企业可以参考海外某些零售企业的案例，评估犯罪分子入侵收银终端的影响。保险公司和数据服务机构也可以参考海外某些大规模数据泄露事件。行业报告、数据泄露研究和安全媒体也能提供相关信息。
这样的案例并不稀缺，而且在可预见的未来只会越来越多。
然而，从工程实践角度来看，风险模型本身仍然无法直接告诉我们如何改进整体安全态势、应该实施哪些控制措施，以及应该在哪里实施。这需要在第二步中完成。
生产路径：安全保障在哪里发挥作用？
要回答安全在软件开发过程中究竟“发生”在哪里，我们需要先看看团队是如何创造价值的。
“生产路径”，也就是 Path to Production，简称 P2P，可以直观展示从讨论、业务需求或用户问题开始，到最终功能在生产环境中部署并运行的全过程。
生产路径的概念借鉴了精益价值流图。价值流图广泛应用于制造业，用于提升生产效率并分析延迟成本。绘制生产路径需要整个团队共同参与。产品开发过程中的每一项活动都会被记录下来，并按照逻辑顺序排列。
绘制时可以关注以下几类内容：
- 人员：团队、委员会、个人。
- 媒介：会议、固定日程、委员会、电话、电子邮件。
- 交付物：报告、分析、用户故事、代码提交、容器等。
- 安全控制：威胁建模、测试、日志记录、扫描器等。
敏捷软件开发生命周期通常大致如下：
利益相关者聚在一起讨论想法，这些想法会被记录在会议纪要和报告中。会议纪要和报告又会成为其他团队或委员会后续决策的依据。在某个阶段，这些讨论会被提炼成 Epic，用来粗略描述交付工作的范围。随后，Epic 会被拆分成用户故事，每个用户故事都有清晰的范围和验收标准。之后，这些用户故事会被逐一开发，并最终部署到生产环境。
在敏捷软件开发中，这条路径会持续吸收新的提案和洞察。通常，每个团队成员在任意时间点都会参与到 P2P 流程的某个环节。最终，团队会得到一份庞大的可视化文档。它虽然是抽象的，却真实而准确地呈现了团队的实际工作方式。
对于希望将这条生产路径真正落到日常研发管理中的团队，也可以借助 PingCode 这类智能化研发管理工具，把团队目标、客户反馈、需求清理、评审排期、开发、测试、发布上线和 Wiki 知识沉淀串联起来，并打通研发过程中使用的其他工具，让安全要求、风险记录和研发数据在同一条流程中自然流转，而不是停留在孤立文档里。
以下是一种生产路径研讨会的实际操作流程：
- 确保所有团队成员都到场。产品负责人和团队负责人必须参加，而不应只有开发人员参加。
- 准备一面空白墙或一张大纸，用来张贴便利贴。根据经验，大约需要 4 米长的可用空间。
- 准备四种颜色的便利贴，分别用于标记人员、媒介、交付物和安全控制。
- 首先，从产品需求的来源群体开始，例如市场、销售、专家组、指导委员会等。然后，重点关注谁负责落实这些群体的产出，以及这些信息如何流动。这些群体可能很多，而团队中不少人可能是第一次听说它们。
- 当你确认已经掌握这些需求来源后，接下来要更深入地了解团队实际参与的环节。通常会有一些需求细化会议，用于制定功能需求；也可能存在架构小组，负责定义公司内各团队开发软件时需要遵循的跨职能需求。
- 接下来，在看板上记录各个步骤：什么时候进入开发阶段？如何确定优先级？如何启动开发？
- 然后，记录持续集成和持续部署流水线中发生了什么。
- 最后，梳理系统如何启动、运行和维护。是否有专门的“救火”角色负责实时支持？是否使用日志记录或监控方案？如何将生产系统的运行信息反馈给开发团队？是否存在缺陷跟踪流程？
请务必预留至少 2 小时用于绘制生产路径，并另外预留 2 小时讨论后续步骤。时间安排应当严格控制。
P2P 机制能够在整个团队中建立共同责任感，并让团队成员理解彼此的工作。这种共同理解和同理心，是安全责任共担的关键。安全工作从最初的功能讨论就已经开始，远早于用户故事出现在看板上。
下一步，团队需要检查 P2P 中安全控制的空白点，例如：
- 用户故事从“分析中”流转到“准备开发”时，是否进行威胁建模？
- 是否有自动化测试？
- 是否有依赖、镜像或代码扫描？
- 是否有日志记录、监控和告警机制？
- 是否有清晰的应急响应流程？
分析阶段：把威胁建模纳入软件开发生命周期
在看板墙的分析阶段，团队会将高层业务需求拆解成用户故事。高层业务需求用于概述所需功能，而用户故事则是范围明确的工作单元。在此过程中，团队也会把应用程序的技术架构转化为跨职能需求。
能够将源自资产库、安全目标和灾难场景的安全问题加入验收标准，对于逐步构建安全软件至关重要。此阶段考虑的安全因素，会对后续开发产生重要影响。
威胁建模的目的，是主动识别应用程序技术设计中的潜在问题。这项实践包括发现威胁和管理威胁。威胁建模是一种非常有效的方法，可以帮助团队理解哪些跨职能需求需要被纳入用户故事，并整合到技术架构中。威胁建模建立在对事件后果的深入理解之上，而这些后果应当已经被记录在资产库中。
威胁模型将团队内部的交付工作和保障工作，与组织中参与风险分析的管理层连接起来。任何应对措施，包括选择不采取措施，都需要放在产品所支持的业务背景下进行考量，因为它可能影响人员、安全性、盈利能力、市值等多个方面。因此，应对措施的决策不应由产品团队孤立完成，而应与业务部门达成一致。
典型的风险应对措施有四种：
- 接受：已经识别、讨论并记录了风险，但选择不采取进一步行动。
- 规避：改变计划，从而避免风险。
- 转移：将风险管理责任转交给其他方。
- 缓解：限制风险影响，或者降低风险发生的可能性。
面对漏洞时，工程师的常见第一反应是尽可能缓解风险。但这并不总是必要的。根据具体情况，上述所有策略都可能是有效的。一个好的威胁模型，能够清楚呈现这些策略为什么有效、在什么条件下有效。
请注意，缓解风险与缓解后果同样重要。例如，DevOps 运动打破了系统管理员过去围绕“最大化正常运行时间”形成的许多固有观念。过去，服务器崩溃意味着停机，而机器资源十分宝贵。如今，在云环境中，机器可以动态配置。停机风险依然存在，但通常不再由单台机器崩溃直接导致。
无论如何，任何行动都需要得到业务部门，例如产品负责人的同意。如果某项决策会产生超出当前用户故事范围的深远影响，建议将其记录下来，例如采用轻量级架构决策记录的形式。
总之，在用户故事的准备检查中加入威胁建模，是将威胁建模引入软件开发生命周期的好方法。
这个流程应当从资产库中汲取输入，并审查是否已经设置了适当的控制措施，或者是否需要在当前用户故事的上下文中创建新的控制措施。
接下来，我们将介绍几种威胁建模方法。不同方法适用于不同预期结果。提前了解这些模型的优缺点非常重要，尤其是当你计划与安全专业人员合作时。
敏捷威胁建模
敏捷威胁建模的目标，是找到最有价值的安全工作，并立即将其纳入团队待办事项。为此，团队可以采用时间盒，以“少量多次”的方式进行威胁建模。
每次威胁建模时，团队都捕捉系统的一个新的、不同的局部视图，而不是陷入过度分析。随着时间推移，当团队持续从不同角度、不同缩放层级分析系统时，威胁建模就会成为一种敏捷的、持续进行的实践。
一种可行流程如下：
- 请参与者绘制约定范围内的技术图。
- 重点标出需要保护的内容，例如数据、服务和资产。
- 基于 STRIDE 进行“邪恶用户”式威胁头脑风暴。
- 通过投票确定风险最高的威胁。
- 围绕前三大威胁开展工作，并制定行动方案。
使用 STRIDE 进行头脑风暴既快速又灵活。它可以扩展现有工作方式，并帮助团队提出一个关键问题：可能会出什么问题？
STRIDE 分类法可用于检查当前迭代中的功能差异，并判断这些功能是否可能遭到以下攻击模式的攻击或破坏。STRIDE 是以下术语的缩写：
- 身份欺骗（Spoofing）：攻击者冒充他人，执行本不应由其执行的操作。关键概念包括身份和认证。
- 篡改（Tampering）：攻击者修改输入，例如修改提交到系统的数据，从而破坏信任边界，并改变系统中的代码执行路径或决策流程。关键概念包括验证、完整性和注入。
- 否认（Repudiation）：行为者利用模糊性，成功否认自己实施过某项操作，从而无需为自己的行为承担责任。关键概念包括不可否认性、日志记录和审计。
- 信息泄露（Information Disclosure）：信息被暴露或截获，并落入未经授权的个人或系统手中。关键概念包括保密性、加密、数据泄露和中间人攻击。
- 拒绝服务（Denial of Service）：攻击者通过大量请求、数据涌入、资源耗尽、数据擦除或其他方式破坏特定服务或系统，使其无法使用。关键概念包括可用性、僵尸网络和分布式拒绝服务攻击。
- 权限提升（Elevation of Privilege）：当授权边界缺失或不足时，用户可能获得超出其应有范围的权限。关键概念包括授权、隔离、影响范围和远程代码执行。
在构思攻击方案时，请务必保持理性。许多威胁建模框架都建议为威胁行为者命名。要理解威胁行为者的特征并构建画像，需要深入了解其身份、关系、动机、意图和能力。实践经验表明，这项工作相当困难且耗时，但并不一定带来更好的结果。除非你确实极有可能遭到国家级攻击组织的针对，否则请保持务实。
根据风险分析部分所述的影响程度，对发现的问题进行分类和排序。花点时间思考：如果这种情况真的发生，企业将面临什么后果？公司会因此倒闭吗？是否需要花一天时间恢复数据库？是否会失去关键竞争优势？或者，你精心设想的灾难场景最终可能只是一个小麻烦？
主要威胁可以转化为：
- 现有用户故事的附加验收标准；
- 在共享空间的信息看板上跟踪的安全债务；
- 对团队“完成定义”的修改；
- 限时技术探索，用于确认系统是否真的易受攻击；
- 用于实施关键安全保障措施的 Epic。
如果团队需要把这些安全债务、探索任务和跨角色协作事项持续跟进，也可以使用 Worktile 这类通用项目协作系统，将任务、项目、文档、目标、日历、工时和审批等信息集中管理，让安全问题有明确负责人、时间节点和进展记录。
桌面演练：用灾难场景检验安全响应能力
如果敏捷威胁建模方法不适合团队，桌面演练是经验不足的团队理解技术债务中安全风险的良好起点。
在类似桌面演练的威胁建模中，团队会面对一个或多个灾难场景，并列出所有必要应对措施，以覆盖网络安全事件管理的各个阶段：识别、保护、检测、响应和恢复。
这项技术借鉴团队成员在其他项目中积累的知识和经验，并尝试将其映射到当前技术栈和架构中。
情景分析可以基于以下内容：
- 系统之间的边界和接口可能被突破；
- 从配置错误导致的不可用状态中恢复；
- 从意外数据丢失中恢复；
- 在第三方服务不可用时实现服务的优雅降级；
- 检测来自外部攻击者的入侵和数据泄露。
桌面演练场景示例包括：
- 监控系统显示，大量持续的出站流量表明可能存在数据泄露。
- 加密勒索软件攻击已经发生，并感染了生产系统。
- 有人提交了云服务访问密钥，随后出现了大量加密货币挖矿活动。
- 一名员工喝咖啡时，未锁屏的笔记本电脑被盗，电脑中存有知识产权、数据和凭证。
- 一台未打补丁的服务器已被攻破，并成为僵尸网络的一部分。
- 云服务商发来滥用通知，指出你的云主机一直在对外发起 SSH 暴力破解请求。
- 信息安全部门通知你，你的用户账号在 24 小时内出现了超过 1000 次身份验证失败。
攻击树
对于高风险、高价值资产，以及数字取证中需要重点关注关键组件的场景，可以考虑使用攻击树。
攻击树是一种系统安全分析方法，允许团队以树状结构自上而下地发现攻击路径。攻击树非常耗时费力，需要专业知识，但收益并不总是与投入成正比。
在与安全从业人员交流时，一个常见观点是：攻击树更适合高保障环境中的瀑布式分析和前期设计，敏捷团队通常不应将其作为主要方法。
开发阶段：将安全控制融入 CI/CD 流水线
开发阶段的许多安全控制，都可以融入自动化 CI/CD 实践中，从而提升整个系统的稳定性。测试金字塔和功能开关等做法已广为人知，也有充分文档支持。然而，尽管依赖项、库和框架等在运行时通常占据代码库的绝大部分，对它们进行扫描却常常被忽视。
语义化版本控制描述了浮动依赖版本范围：新版本可以在该范围内自动集成。浮动版本范围背后的预期是，在下一次构建时，错误修复会自动从上游拉取，非破坏性更新也会自动集成，无需手动配置干预。
这是一个合理假设，尤其是在大多数开发者都采用“向前修复”而不是“向后移植”的情况下。
然而，盲目集成未经测试的新版本，会导致构建和运行时问题、构建结果不确定，以及“在我机器上没问题”这类典型困境。某些依赖自动更新工具表明，我们需要更加重视依赖项管理：如果持续集成执行的测试套件通过，这类工具就能自动集成新版本和错误修复。
CI 测试通过后，下一步就是部署。通常，可以通过蓝绿部署来验证其是否适合生产环境；如果出现错误，也可以轻松放弃或回滚部署。这种实践也常被称为金丝雀构建或金丝雀部署。如果你没有使用蓝绿部署，请确保已经实现自动回滚机制。
随着时间推移和新漏洞不断被发现，团队需要防范已有构建和生产系统中库与框架漏洞不断累积。海外某些公司因长期未修补开源框架漏洞而遭遇重大安全事件，就是典型案例。
依赖检查工具或包管理器审计工具可以扫描依赖项，查找已公开的常见漏洞与披露，也就是 CVE。团队还可以参考公开漏洞库、漏洞披露平台以及其他公开安全漏洞来源。
与库和框架一样，容器和运行时环境也存在漏洞，需要定期检查。容器镜像扫描工具可以扫描容器镜像中的各个层，查找 CVE 漏洞。扫描依赖项和组件已经被普遍接受为最佳实践，因此包管理器和制品仓库通常也会内置相关能力。各类安全扫描器也可以集成到 CI/CD 和生产环境中，持续提供相关信息。
定期检查依赖项是否过时、是否存在已知 CVE 漏洞，是一种良好实践，例如每天检查一次。建议将通知放在独立管道中，并通过定时任务执行，而不是只在部署流水线中运行。
如果某个生产问题的修复因为发现了 CVE 漏洞或新版本而无法部署，那将非常糟糕。
在定时任务中运行安全扫描还有另一个优势：某些微服务可能几个月都不会维护。此时部署流水线不会运行，也就无法及时发现新披露的漏洞。独立的定时扫描可以弥补这一空白。
至此，我们已经对开发阶段的安全状况有了大致了解。接下来，让我们看看生产环境中的支持机制。
部署与实时支持：从业务视角监控生产安全
在任何时候，团队都需要能够通过仪表盘直观看到系统运行状况。这里说的并不是响应时间或其他技术指标，而是系统服务业务的能力。
系统通常是围绕用户旅程或不同业务重点构建的，旨在为这些重点创造价值。团队需要将这些方面同时可视化地呈现在仪表盘上，每个方面对应一个图块。
例如，在电商场景中，团队可能想知道购物车交互次数。如果这个数字突然下降，就说明可能出现了尚未被发现的问题。
深入了解生产环境的基础是结构化日志。结构化日志不再记录自然语言字符串，而是记录可索引的数据结构。容器的日志输出会被收集器采集、集中聚合并建立索引。这样，一旦发生事件，团队就可以调取日志，并使用预先编写好的搜索查询来检查这些数据。
JSON Lines 是一种便于逐条处理结构化数据的格式。常见日志分析技术栈则可以帮助团队完成日志采集、存储、检索和可视化分析。
既然团队已经能够聚合来自不同系统的日志，接下来就需要了解如何跨系统关联这些日志。这可以通过跟踪 ID 实现。
团队可以为每个外部请求分配一个唯一请求 ID，例如通过 HTTP 请求头传递。这个 ID 会被传递给所有参与处理该请求的服务。跟踪 ID 也会包含在所有日志消息中。这样，团队就可以查看不同服务之间的交互情况，了解哪个请求导致了哪个操作或下游错误。
关键问题在于告警。更准确地说，是如何区分正常行为与异常行为。
通过仪表盘从业务角度展示系统运行状况，团队可以随着时间推移不断加深理解。这就像飞行员通过驾驶舱里的仪表安全驾驶飞机一样。当团队理解了服务的健康状态后，告警就变得尤为重要：当某项服务超出正常参数范围时，团队应当被自动通知。
收到告警后，团队需要立即采取行动。借鉴应急响应人员的工作方式，标准操作程序，也就是 SOP，可以帮助团队在紧急情况下保持有序。
SOP 是一份简明的操作手册或清单，其中包含处理事件所需的关键信息。SOP 的目的不是把问题简化到任何人都可以无脑操作，而是为响应人员提供必要指导。它可以包括重启服务的步骤、日志位置、数据处理流程等信息。
SOP 不是涵盖所有情况的完整服务手册，更像是飞机上的应急程序。它的目标是让人员尽可能不受资历、任职时间和经验差异影响，能够快速应对事件和故障。
最直观的例子是消防演习，因为它展示了人们如何从建筑物中撤离。SOP 可以采用多种形式，包括纸质文档、知识库文档、脚本、服务接口、维护端点等。
除了在实际支持工作中使用，还可以通过类似桌面演练的方式测试这些标准操作程序。这有助于确保这些规程被广泛理解、保持最新，并且确实可行。
此外，团队还应预留资源，主动偿还技术债务，因为技术债务是最常见的缺陷来源之一。
一个不错的做法是安排一名成员轮流担任“救火员”。当没有实际生产问题需要处理时，这个人就负责处理技术债务，完成那些很少被写进用户故事的小任务。
重点在于“一个人”。因为没有什么比让新加入团队的成员独自负责一天生产系统维护，更能让他们熟悉代码库中那些糟糕部分了。不要安排资深成员和初级成员结对，因为资深成员很可能在大多数时间主导工作。
让每个人都轮流维护系统一两天，无论经验和资历如何，都能迫使团队对所有代码承担集体责任：无论代码多旧、多糟糕，也无论是谁写的。
安全是一种文化，而不是上线前的检查项
即使组织内部通常欢迎安全方面的努力，也请注意，许多团队仍需要在这一领域持续探索。为了确保安全投入能够长期获得回报，与业务利益相关者密切合作至关重要。
只有当团队理解自身工作在业务背景下的意义时，才能解释、论证并达成共识，从而持续改进安全措施。当然，这也要求业务部门愿意在质量和安全方面进行投入。
安全不是某个阶段的检查项，也不是上线前的临时门禁。安全是一种持续实践，一种工程习惯，更是一种组织文化。
文章包含AI辅助创作，作者：liu，如若转载，请注明出处：https://docs.pingcode.com/baike/5243200
