本文是「学习方法与效率」系列第 2 篇，20 个问题讲清技术边界与风险管控，覆盖范围、权责、依赖、风险清单和止损线。可按目录跳读。
Q1. 什么是技术边界？
技术边界是一个系统、团队或方案能做什么、不能做什么、在什么条件下成立。它包括功能边界、性能边界、数据边界、权限边界和运维边界。
边界不是限制能力，而是让协作可预期。没有边界的系统会互相渗透，最后谁都说不清责任。
边界要写成可检查的条款，比如接口超时、数据保留、权限范围和故障回退，评审时逐条确认，不能只停留在口头共识。
项目里我会把边界写进设计文档：谁负责、输入输出是什么、失败怎么处理、超出边界怎么办。边界清晰，才有可能谈质量和效率。
Q2. 怎么划定系统边界？
先确定系统解决的核心问题，再明确外部依赖、用户角色和数据流向。把不属于本系统的东西排除出去，或者定义成外部接口。
系统边界要回答：哪些数据由本系统产生、哪些只读、哪些由别人负责。边界外的故障不能直接拖垮本系统。
系统上下文图要标出外部系统、数据流向、故障隔离点和责任方，边界外的问题要有明确的回退和升级路径。
项目里 LingShu 只负责医疗问答和证据溯源，挂号、支付、电子病历属于外部系统。边界清楚，接口和降级方案才好设计。
Q3. 怎么划定团队职责边界？
团队边界按业务域、技术域和交付责任划分。每个域要有明确的 owner，避免同一件事多人负责或无人负责。
边界要覆盖开发、测试、发布、值班和故障处理。不能只分开发任务，不分线上责任。
职责边界要写进团队公约并定期复盘，避免故障时互相等待。跨域需求走接口和契约，不能直接改对方代码。边界要有文档、有 owner、有评审，变更要走流程，不能靠默契。
项目里订单域归交易团队，推荐域归算法团队，网关归基础架构团队。边界清楚，协作才有稳定的接口。
Q4. 怎么划定接口边界？
接口边界要定义输入、输出、错误码、超时、幂等和版本。接口是契约，不是内部实现的暴露。
边界要限制调用方能看到什么，避免把数据库字段直接透出。接口变更要兼容，破坏性变更要版本化。
接口契约要版本化，限制调用方依赖内部字段，变更要兼容旧调用方，并且能测试、监控和回滚。契约要有示例、错误码和版本策略，调用方要能自助联调。
项目里内部服务用 OpenAPI 或 IDL 定义契约，网关做鉴权和限流。调用方只能依赖契约，不能依赖实现细节。
Q5. 怎么识别项目风险？
风险识别要从目标、范围、依赖、技术、数据和人员六个维度看。常见风险有需求不清、依赖延期、技术不成熟、数据质量差和关键人缺席。
可以用风险清单、预 mortem 和专家访谈。预 mortem 是假设项目已经失败，倒推可能原因。
风险清单要有人负责、有触发信号、有应对动作，定期更新；预 mortem 能挖出大家不愿说的问题。
项目里上线前会列风险矩阵：发生概率、影响程度、触发信号和应对措施。风险不怕多，怕没人管。
Q6. 怎么做风险分级？
风险分级看发生概率和影响程度，通常分高、中、低。高概率高影响的风险要优先处理，低概率高影响的风险要有预案。
影响要看业务、用户、资金、合规和声誉。技术风险还要看恢复时间和数据损失。
风险分级要结合业务阶段，高风险要有 owner、预案和演练，低风险也要有监控，分级结果要能追踪。分级要定期复核，业务变化后风险等级也会变。
项目里支付链路故障定为最高级，报表延迟定为中低级。分级不是为了贴标签，是为了分配注意力和资源。
Q7. 怎么处理需求蔓延？
需求蔓延通常从小口子开始，比如“顺便加个字段”“顺手改个流程”。要建立变更入口，所有新增需求走评估。
评估要看是否影响目标、排期、成本和风险。能拆到下一期的就拆，能不做就不做。
变更要有统一入口、影响评估、优先级和记录，不能群里一句话就插队；频繁变更要从源头治理。变更要透明，相关方要知道排期和影响。
项目里需求变更会记录在变更单，产品、技术和业务一起确认。没有记录的变更不排期，避免口头承诺变成技术背锅。
Q8. 怎么拒绝不合理需求？
拒绝不是说不，而是说清代价和替代方案。先确认需求背后的目标，再看是否有更简单的解法。
如果确实做不了，要给出原因、风险和可选方案，让业务做取舍。拒绝要有依据，不能靠情绪。
拒绝要基于事实和数据，给出替代方案、时间成本和风险，让业务做选择，并记录决策和复盘结果。拒绝后要跟进，确认业务是否接受替代方案。
项目里我会说“这个方案需要三周，且会影响稳定性；如果只做核心部分，一周可以上线，但覆盖不到长尾场景”。把选择权交回去。
Q9. 怎么设定非功能边界？
非功能边界包括容量、延迟、并发、可用性、数据保留和安全等级。要写成可验证的指标，不是形容词。
边界要说明在什么负载下成立，超出后怎么降级。比如支持多少 QPS、P95 多少、超时多少、失败怎么返回。
非功能边界要写进容量规划和压测方案，按峰值设计、留余量，并明确超载时的降级和扩容策略。边界要随着业务增长复盘，不能一年不变。
项目里核心接口会写“单实例 500 QPS、P95 300ms、超时 2s、降级返回缓存”。没有这些，容量规划就是空的。
Q10. 怎么处理依赖方风险？
依赖方风险包括接口变更、延迟、限流、故障和数据不一致。要先识别关键依赖，再定契约和降级方案。
依赖要有超时、重试、熔断和兜底。关键依赖要有备份方案或多供应商。
依赖方要有契约、SLA 和变更通知，关键依赖要有备选，定期演练切换，监控可用性并记录故障。依赖变更要提前通知，留出适配时间，关键依赖要压测，要留缓冲，要演练。
项目里模型 API 会配多供应商降级，支付依赖会配异步补偿和人工兜底。不能假设依赖永远可用。
Q11. 怎么设计降级和兜底？
降级是系统在异常时牺牲部分功能，保住核心链路。兜底是最终返回一个可用但可能不完整的结果。
降级要有开关、触发条件、影响范围和恢复方式。不能等故障了才临时想。
降级要有优先级，先保交易再保查询，开关支持按租户和流量比例控制，能自动触发也能人工接管。降级要区分读和写，写链路优先保证幂等和补偿。
项目里推荐服务挂了返回热门列表，模型超时返回缓存答案，支付回调失败进重试队列。降级要演练，不能只写在文档里。
Q12. 怎么划定数据边界和权限？
数据边界要分清谁产生、谁使用、谁负责、保留多久、能否出境。权限要按角色、租户和字段控制。
敏感数据要脱敏、加密和审计。跨边界传输要有协议和审批。
数据边界要写进数据字典和权限矩阵，能审计、脱敏、删除、导出和隔离，并定期评审责任人。要能回答谁能看、谁能改、谁能删，要留审计和追责记录，要定期演练，要留痕。
项目里医疗数据按租户和科室隔离，PHI 不出内网，日志脱敏。数据边界不是技术选择，是合规要求。
Q13. 怎么处理技术债边界？
技术债要分类：有意债、无意债、环境债和设计债。有意债要记录原因、利息和偿还计划。
技术债不能无限累积，也不能一刀切重写。要按影响面和修复成本排序。
技术债台账要写清影响、利息和偿还计划，有 owner 和预算，每个迭代留容量还债，防止新增。技术债要能量化，比如故障率、交付速度和维护成本，要定期复盘，要排优先级。
项目里我会给技术债建台账，标出影响模块、风险和计划。每个迭代留一部分容量还债，避免最后积重难返。
Q14. 怎么做变更管理？
变更管理要有唯一入口、影响评估、审批、灰度、回滚和记录。变更包括代码、配置、数据和架构。
高风险变更要双人复核，低风险变更可以自动化。变更窗口要避开业务高峰。
变更要分级，高风险双人复核，低风险自动化；要有窗口、灰度、回滚、记录、通知和审计。变更要有回滚包和回滚演练，不能只写步骤，要能快速回，要通知。
项目里数据库变更走迁移脚本和评审，配置变更走配置中心，代码变更走 CI 和灰度。变更可追溯，故障才能定位。
Q15. 怎么设定上线准入和准出？
上线准入看测试、评审、监控、回滚和容量是否就绪。准出看核心指标、错误率、延迟和用户反馈是否正常。
准入不达标不能上线，准出不达标要回滚。标准要提前定，不能上线后再说。
准入准出要写成检查单，覆盖测试、安全、容量、监控、回滚、数据和合规，逐项签字并留痕。检查单要版本化，按业务风险调整，要留证据，要复盘，要改进。
项目里上线检查单包括单测、集成测试、压测、安全扫描、监控面板、告警和回滚包。检查单要签字。
Q16. 怎么处理跨团队协作边界？
跨团队协作要定义接口、交付物、时间、责任人和升级路径。边界要写进协议或工单，不能只靠口头。
出问题先按契约定位，再走升级路径。不能一出问题就互相甩锅。
跨团队边界要有接口人、交付物、时间点和升级路径，建联调计划和契约，关键依赖要有备选。跨团队要有例会、风险清单和升级机制，要有接口人、备选、验收和记录。
项目里跨团队需求会建联调群、接口契约和联调计划。关键依赖要有备选方案和延期预案。
Q17. 怎么识别不可逆决策？
不可逆决策是做了很难回退的选择，比如数据库选型、公共协议、数据模型和重大架构。要慢一点，多评审。
可逆决策可以快，不可逆决策要谨慎。可以用“如果错了，多久能改回来”来判断。
不可逆决策要写清假设、备选和退出方案，做 PoC 和多轮评审；可逆决策要快，别过度纠结。不可逆决策要控制影响面，能隔离就先隔离，要留后路，要能迁移。
项目里选型会做 PoC、对比和退出方案。不可逆决策要记录假设和备选，避免一条路走到黑。
Q18. 怎么用契约和 SLA 约束边界？
契约定义输入输出、错误、版本和兼容策略。SLA 定义可用性、延迟、恢复时间和赔偿或责任。
契约要能测试和监控，SLA 要能度量。没有度量的 SLA 只是口号。
契约要版本化，SLA 要能监控、告警、追责和补偿，变更要评审，不达标要复盘和升级。契约要有测试和 mock，调用方能独立开发，SLA 要有报表、告警和追责。
项目里服务间用 OpenAPI 契约，关键链路有 SLA 和告警。契约变更要评审，SLA 不达标要复盘。
Q19. 怎么复盘边界失控？
边界失控通常表现为职责不清、接口频繁变、故障扩散和需求无限插队。复盘要找到最早的破口。
要区分个人问题、流程问题和架构问题。不能只处理表面，要改机制。
复盘要看时间线、决策点和边界变化，区分个人、流程和架构问题，行动项要有 owner 和截止时间。下次检查要跟踪关闭，形成闭环，要更新流程。
项目里复盘会看时间线、决策点和边界变化，最后落到接口、流程或组织调整。复盘不是追责，是防止再犯。
Q20. 项目里怎么实践边界与风险管控？
项目里先画系统上下文和职责边界，再定接口、数据和 SLA。每个边界都要有 owner 和失败处理。
风险要提前列，分级、定预案、演练。变更要走入口，上线要有准入准出。
边界要画图，风险要列表，变更要入口，上线要检查单；定期演练、复盘、更新和培训。边界和风险要进模板，新人按模板做，减少遗漏。
LingShu 的医疗问答把模型、检索、工具和护栏分层，SuGuangMall 把交易、推荐和秒杀拆域。边界清楚，风险才可控。