· Johnny Mai · 29 min read
使用案例：Staff工程师在银行交易系统中部署LLM容灾方案
使用案例：Staff工程师在银行交易系统中部署LLM容灾方案
一句话总结
银行交易系统的LLM容灾不是技术选型问题，而是一场关于如何在合规约束下做技术决策的权力博弈——真正决定项目生死的，不是模型有多强，而是你能不能在48小时内让风控、法务和业务三方同时点头。
适合谁看
这篇文章的预设读者不是来学LLM容灾方案的。你是来学怎么在高度监管的行业里做一个活下来的技术决策者的。
具体来说：工作3-8年、准备从Senior升Staff或从Staff升Principal的工程师；已经在金融、支付、保险等强监管行业工作的技术人；在互联网公司做基础设施但未来可能需要与金融客户打交道的架构师；以及那些发现自己的技术方案总是被业务方否决、不知道问题出在哪里的工程师。
如果你现在面临的问题是“为什么我的技术方案评审总是被延期”或者“为什么风控部门有权力否决我的技术选型”，这篇文章是写给你的。如果你在面试银行科技岗时发现他们问的问题跟互联网公司完全不一样——不问系统设计而问合规影响、不问性能指标而问审计日志——这篇文章更是写给你的。
但如果你只是想了解LLM容灾的技术细节，我建议你直接去看AWS或Azure的官方文档。那部分内容他们写得比我好。
核心内容
为什么银行的技术决策从来不只是技术问题
你在互联网公司做容灾方案，决策链路是清晰的：技术团队评估 → 架构评审 → 上线。银行不一样。银行的核心系统每笔交易都有合规留痕，任何变更都需要经过“技术评审+业务确认+风控复核+合规备案”四道关卡。这意味着你作为Staff工程师，在银行推动一个LLM容灾方案，你的角色定义必须改变。
不是技术负责人，而是“合规环境下的技术推销员”。
这不是贬义。你在银行做的每个技术决策，都是在向非技术人员解释一个技术选择的商业影响和法律风险。我见过最优秀的架构师，在互联网公司呼风唤雨，进了银行第一年寸步难行。不是能力问题，是角色转换失败。他们以为技术方案够好就能推进，不知道在银行环境中，你需要先让合规团队相信这个方案不会让他们在审计时被问责。
具体场景：假设你设计的LLM容灾方案需要调用外部API做模型推理。在互联网公司，这只是一个架构选择。在银行，合规团队会问：这个API服务商是否通过了SOC2认证？数据传输是否加密？模型输出的决策依据能否被审计？如果监管机构要求你解释为什么某个交易被错误处理，你能不能追溯到模型的具体推理过程？
每个问题都是合理的，每个问题都需要你提前准备答案。你不能在评审现场说“让我回去查一下”。
不是性能优先，而是审计优先
银行交易系统的容灾方案，优先级排序跟互联网完全不同。互联网公司的容灾逻辑是：RTO（恢复时间目标）和RPO（恢复点目标）越短越好，99.99%的可用性是标配。银行不是。银行的容灾逻辑是：任何决策必须可解释、可追溯、可审计。性能差一点可以接受，出了一起事故解释不清楚，不行。
这不是保守，这是行业的本质差异。互联网公司的容灾失败，损失的是用户和收入。银行交易系统的容灾失败，损失的是信任，而信任是银行存在的根基。
具体来说，你在设计LLM容灾方案时，互联网思维会这样思考：主模型响应时间50毫秒以内，容灾模型可以放宽到200毫秒，整体P99控制在250毫秒以内。银行思维会这样思考：模型输出的每个决策必须附带完整的推理链路日志，容灾切换时必须保证日志的连续性，任何一笔交易的模型决策都必须能在7年内被追溯查询。
这不是技术限制，是监管要求。中国银保监会的《商业银行信息科技风险管理指引》、美联储的SR 11-7、欧盟的GDPR（部分场景适用）都明确要求金融机构必须能够解释自动化决策。LLM的不确定性天然与这个要求冲突。你必须解决这个冲突，才能让你的方案有生存空间。
面试银行科技岗时，他们真正在考什么
如果你正在面试银行科技部门的技术岗位，你会发现他们的面试问题跟互联网公司完全不同。互联网公司的系统设计面试，考察的是你怎么设计一个高可用、可扩展的系统。银行科技岗的面试，考察的是你怎么在一个约束系统里做决策。
这不是同一件事。
互联网公司的约束主要是技术约束：流量多大、延迟要求多少、预算多少。银行的技术决策还包含非技术约束：监管要求、合规边界、业务连续性计划（BCP）、灾难恢复计划（DRP）。这些约束不是可以优化掉的，是必须内化进方案的。
具体面试场景：面试官问，“如果监管机构要求你解释LLM模型的每个决策，你会怎么设计日志系统？”这不是在考你日志系统的技术实现。在考你是否有“合规意识”——你能不能理解银行环境里，审计日志不是“锦上添花”，是“生死线”。
另一类典型问题：“如果业务部门要求你牺牲模型精度换取更好的可解释性，你怎么处理？”这是在考你的沟通能力和优先级判断。你不能简单说“我会说服业务部门接受高精度方案”，因为在银行环境里，可解释性往往真的是优先级更高的那个。你需要展示的是：你理解这个权衡，你有能力评估两个方案的风险收益比，你能在必要时做痛苦的取舍。
薪资结构：银行科技岗的Staff工程师到底能拿多少
银行科技岗位的薪资结构跟互联网公司有显著差异。不是更低，是结构不同。
Base salary方面，国内银行科技部门Staff工程师的base通常在60万到120万人民币之间。国有大行偏低，股份制银行和外资银行在华科技中心偏高。具体来说，工商银行、建设银行等国有大行的科技岗位base可能在60-80万；招商银行、浦发银行等股份制银行在80-100万；摩根士丹利、高盛等外资银行在国内的技术中心可以达到100-120万甚至更高。
Signing bonus方面，银行科技岗的signing bonus通常在base的15%到30%之间。国有大行的bonus往往以“红包”形式发放，金额相对固定；外资银行和部分股份制银行会明确给出signing bonus数字，通常在15-30万之间。需要注意的是，国有大行的“年终奖”虽然总额可能更高，但受限于薪酬体系，一次性signing bonus往往偏低。
RSU方面，这是银行跟互联网差距最大的地方。纯国内银行基本没有RSU概念，薪酬以base+bonus为主。外资银行在华科技中心会提供RSU，但数量通常比硅谷同级别岗位少很多。举例来说，同级别岗位，Google可能给价值100万的RSU四年总包，外资银行可能只给30-50万的RSU。但外资银行的其他福利（补充公积金、高端医疗、子女教育补贴）往往可以弥补这个差距。
总体包来看，国有大行Staff工程师总包可能在70-100万，股份制银行在90-130万，外资银行科技中心在120-180万。这个数字比互联网大厂同级别岗位低20-40%，但银行工作的稳定性、wlb（工作生活平衡）和退休保障是互联网公司无法提供的。
你需要想清楚自己要什么。
不是追求技术最优，而是追求“合规可行的最优”
很多工程师在设计容灾方案时犯的错误是：把“技术最优解”当成目标。银行环境里，没有“技术最优解”，只有“合规可行的最优解”。这两个东西有时候是同一个，有时候不是。
具体场景：你的主方案是使用GPT-4做实时的交易风险评估，容灾方案是切换到本地部署的开源模型做降级处理。技术团队认为这个方案很合理。合规团队的问题来了：GPT-4是第三方服务，你的客户数据会不会出境？本地开源模型的训练数据是什么，有没有潜在的偏见风险？如果模型对某个群体的交易做出了不同的风险评估，你能不能证明这不是歧视？
每个问题都需要你给出技术层面的回应。你不能说“模型没有偏见”，你得说“模型的决策逻辑可以追溯到以下特征变量，这些变量是根据历史违约率计算的风险指标，不是人口统计学变量”。你不能假设合规团队会接受你的说法，你得准备好证据。
这不是技术问题，是沟通问题。你需要把你的技术方案翻译成合规语言。
LLM容灾方案的核心挑战：不是技术，是信任
LLM容灾的核心挑战不是模型切换的速度，不是数据同步的一致性，是信任——业务部门信任不信任模型决策，风控部门信任不信任模型决策，监管机构信任不信任模型决策。
具体来说，业务部门担心的不是技术细节，是“模型会不会出错，出了错谁负责”。风控部门担心的不是性能，是“模型决策能不能被审计，审计的时候你能不能给我一个说得过去的解释”。监管机构担心的不是商业价值，是“这个技术应用符不符合现有的监管框架，如果出了问题我能不能追溯到责任方”。
你的技术方案必须解决这三个信任问题。不是通过技术本身解决，而是通过技术+文档+流程+培训来解决。
这不是你在互联网公司会遇到的问题。互联网公司你可以上线后再迭代，用户反馈会帮你修正。银行不行。银行的任何变更都需要提前论证、事后验证。LLM容灾方案必须在部署前就解决信任问题，否则你上不了线。
准备清单
系统性拆解银行科技岗面试的结构——银行科技面试通常分技术面、行为面、合规面三类，每类考察重点不同。技术面看的是你的架构能力和系统设计思维，行为面看的是你的沟通能力和跨部门协作能力，合规面看的是你是否有合规意识。PM面试手册里有完整的银行科技岗面试复盘可以参考，里面有真实的面试题库和回答框架。
准备5-7个具体的LLM应用场景案例——面试官喜欢问“讲一个你用LLM解决的实际问题”，你需要准备的不只是技术细节，还要准备合规考量、跨部门沟通、风险评估。STAR法则（Situation, Task, Action, Result）在这里同样适用，但你需要在T和A部分加入合规和风控的考量。
深入了解目标银行的监管环境——如果你面的是工行，你需要了解人民银行和银保监会的相关规定；如果你面的是外资银行，你需要了解其全球合规框架和中国本地监管的结合点。不是背条文，是理解监管逻辑。
准备一个“失败案例”——银行面试官喜欢问“你遇到过什么挫折，你怎么处理的”。不是要听你诉苦，是要看你有没有自我反思能力。准备好一个真实的失败案例，重点放在你从中学到了什么。
练习“非技术问题”——比如“如果业务部门和风控部门对技术方案有分歧，你怎么办”。这类问题没有标准答案，考的是你的判断力和沟通能力。
了解银行科技部门的技术栈——不同银行的技术选型差异很大。国有大行很多还在用大型机+COBOL，外资银行可能用更现代的技术栈。你不需要精通每一套，但需要了解你目标银行的技术现状。
准备“技术方案的可解释性版本”——针对你准备的每个技术方案，准备一个用非技术语言解释的版本。银行面试官经常要求你向“业务部门”解释一个技术决策，你得能用他们听得懂的语言说清楚。
常见错误
BAD版本：面试时只讲技术细节，不讲合规影响
面试互联网公司，你可以花15分钟讲你的系统设计、用的什么框架、怎么优化延迟、怎么保证一致性。面试银行科技岗，这样讲大概率会被打断。
BAD例子：面试者花了10分钟讲他的LLM容灾方案用了什么架构、怎么实现模型热切换、延迟从200毫秒优化到80毫秒。面试官问了一个问题：“如果监管机构要求你解释模型为什么给某笔交易打了高风险标签，你怎么回答？”面试者愣住了，说“模型有自己的判断逻辑”。面试结束。
GOOD版本：面试者讲完技术架构后，主动提到合规考量。“这个方案的日志系统设计满足了银保监会的可追溯要求，每个模型决策都会记录输入特征、模型版本、推理结果和置信度。如果需要解释，可以追溯到具体的时间戳、交易ID和模型推理链路。同时我们设计了置信度阈值，低于阈值的决策会自动转人工复核，满足监管对高风险决策必须有人工介入的要求。”
前者展示的是技术能力，后者展示的是“银行环境下的技术能力”。后者才是银行科技岗需要的人才。
BAD版本：以为“技术最强”就能推进技术方案
在互联网公司，技术方案够好，团队会采纳。在银行，不一定。
BAD例子：Staff工程师设计了一个非常优雅的LLM容灾方案，技术上领先行业两年。他信心满满地去技术评审会，结果发现会议有一半时间是法务和合规的人在提问。他们不关心你的架构有多精妙，他们关心的是“数据合规吗”、“决策可审计吗”、“出了问题谁负责”。技术方案被要求修改，因为合规团队认为风险不可控。
GOOD版本：同一位工程师，在设计之初就邀请合规团队参与。他花了两周时间跟合规团队沟通，了解他们的担忧，然后把合规要求内化进技术方案。他的方案里，日志系统、审计接口、人工复核机制都是标配。技术评审会上，合规团队主动为他的方案背书。方案通过。
技术能力在银行是必要条件，不是充分条件。你还需要合规能力、沟通能力、政治能力。
BAD版本：把银行当成“保守的互联网公司”
很多从互联网跳到银行的工程师，会觉得银行“太保守”、“技术太落后”。他们试图用互联网的方式改变银行，结果碰壁。
BAD例子：工程师觉得银行的LLM应用太保守，建议直接上线一个“更先进”的方案。他没有充分考虑监管要求，结果方案在合规审查阶段被否决。他抱怨“银行太落后了，不懂新技术”。
GOOD版本：同一位工程师，意识到银行的技术保守主义背后有合理的逻辑。他开始学习监管框架，理解为什么银行对新技术有这些要求。然后他找到了一个平衡点：技术方案既满足监管要求，又比现状有实质提升。他花了更多时间沟通和文档，但方案最终上线了。
银行不是“落后的互联网公司”，银行是“有不同约束系统的技术环境”。你需要适应这个系统，而不是抱怨它。
FAQ
Q：银行科技岗面试跟互联网公司面试最大的区别是什么？
最大的区别是，银行面试会花大量时间考你的“合规意识”和“非技术判断力”。互联网公司的面试主要是技术面试，系统设计、算法、编程题占了大部分比重。银行科技岗的面试，技术问题只占一半左右，另一半是情景题和判断题。比如：“如果业务部门要求你跳过某个合规流程先上线，你怎么处理？”这类问题没有标准答案，考的是你能不能在压力下做出符合银行价值观的判断。我面试过一位候选人，技术问题回答得很好，但情景题暴露了他对合规流程的不理解——他说“可以先上线再补流程”。这个回答在互联网公司可能不算大问题，在银行直接导致他被拒。银行的合规不是“可选的”，是“刚性的”。你需要让面试官相信你理解这一点。
Q：没有金融行业背景，能进银行科技岗吗？
能，但需要提前准备。银行科技岗招聘时，专业背景不是硬性门槛，但“你为什么想进银行”是必问题。你需要给出一个真实的理由，而不是说“互联网太累了想换个稳定的地方”。面试官想听到的是，你理解银行环境跟互联网环境的差异，并且你有信心适应这个差异。具体准备建议：第一，深入了解你目标银行的业务逻辑。银行的核心业务是“经营风险”，不是“经营流量”。理解这一点，能帮你回答很多“为什么银行这么做”的问题。第二，提前学习基础的合规知识。你不需要成为法律专家，但需要知道什么是KYC（了解你的客户）、AML（反洗钱）、GDPR在中国的对应规定等。第三，准备一个“技术改造”的故事。比如你之前做的某个方案，在互联网公司是标准做法，但需要哪些改动才能符合银行的合规要求。这能展示你不是在逃避互联网，而是主动选择了银行。
Q：在银行做技术，职业天花板在哪里？
职业天花板取决于你选择的银行类型和你的能力组合。纯技术路径的天花板在银行是存在的——银行的技术序列通常比业务序列的晋升通道更窄。但银行给了另一条路：技术+业务的复合路径。具体来说，在银行做到Staff或Principal级别后，你有几个选择：第一，继续走技术专家路线，负责核心系统的架构设计，薪资可以到很高的水平，但影响力主要在技术团队内部。第二，转型为“技术型业务负责人”，比如负责某个业务线的产品和技术，能直接看到技术对业务的影响，晋升空间更大。第三，走管理路线，带团队，这需要你把技术能力转化为组织能力。我见过最成功的案例，是一位从互联网跳过来的架构师，用了五年时间从Staff升到技术VP。他的成功不是因为技术最强，而是因为他同时做到了：技术方案合规可行，业务部门信任他，合规团队认可他。他成了一个“技术翻译者”，能把技术的价值用业务和合规的语言讲清楚。在银行，这个能力比写出最优雅的代码更值钱。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。