2026年系统分析师考试案例分析及试题及答案

2026年系统分析师考试案例分析及试题及答案一、案例分析题（每题15分，共75分）1.阅读以下关于供应商协同平台需求分析的说明，回答下列问题。某大型装备制造企业拟建设供应商协同平台，与500余家供应商通过Web和移动端完成采购订单、发货、质量协同等业务。现有ERP采购模块基于C/S架构，数据模型混乱；供应商交付状态依赖电话和邮件核实；WMS、QMS系统由不同厂商建设，接口标准不统一。（1）请从功能需求、非功能需求、业务规则和接口需求四类中，各列出2条该平台应明确的需求。（6分）（2）请确定该平台用例模型中的4个主要参与者和5个用例，并说明参与者与用例之间最基本的“关联”关系。（5分）（3）为消除多系统中供应商主数据不一致问题，请给出系统分析师在需求阶段应完成的数据需求分析工作。（4分）2.阅读以下关于保险理赔系统微服务改造的说明，回答下列问题。3.阅读以下关于电商系统容量规划的说明，回答下列问题。4.阅读以下关于用户经营分析平台的数据架构设计说明，回答下列问题。5.阅读以下关于医院信息系统容灾设计的说明，回答下列问题。参考答案与解析一、案例分析题1.答案：（1）•功能需求：采购订单在线下发、确认与变更；发货单创建、跟踪与签收确认。•非功能需求：平台全天候运行，年度可用性不低于99.9%；普通网络下页面响应时间不超过3秒，关键数据加密传输并留有审计日志。•业务规则：订单变更金额或数量超过阈值时必须双方重新确认；质检不合格批次自动锁定并通知供应商。•接口需求：与ERP同步采购订单和供应商主数据；与WMS、QMS分别同步收货和质检结果，并为移动端提供RESTAPI。（2）主要参与者：供应商、采购员（或计划员）、质检员、系统管理员。主要用例：供应商主数据维护、采购订单协同、发货协同、质量协同、对账结算。关联关系：参与者位于系统边界之外，通过与用例之间的关联关系发起或参与系统功能；一个参与者可以关联多个用例，一个用例也可以被多个参与者使用。（3）•梳理供应商主数据从创建、变更、冻结到注销的生命周期，明确统一业务标识，如统一社会信用代码。•确定权威数据源，通常以ERP中的供应商编码为唯一可信来源，并绘制多系统间的数据流图或CRUD矩阵。•制定数据清洗、去重、编码转换规则，明确缺失字段的补齐方式。•定义主数据分发机制和变更审批流程，建立完整性、一致性、时效性等数据质量指标，并将其纳入平台验收标准。解析：需求分析不能只关注功能界面，还必须识别非功能约束、业务规则和数据所有权。供应商主数据属于典型的企业主数据，必须建立单一可信源，并通过明确的接口和数据流设计避免多系统重复维护导致不一致。2.某保险公司核心理赔系统为早期J2EE单体架构，理赔申请、审核、定损、支付等流程集中在一个应用中，数据库采用Oracle。业务部门频繁调整核赔规则，传统发布周期约1个月；线上理赔渠道高峰时应用服务器CPU接近满负荷。公司决定在不替换核心账户系统的前提下，将理赔系统改造为微服务架构。（1）请基于限界上下文原则，给出至少5个建议拆分的微服务，并说明拆分边界的主要依据。（5分）（2）在线理赔“申请—审核—定损—支付”链路跨多个微服务。请比较2PC（XA）、TCC、Saga、本地消息表4种分布式事务方式的要点，并说明本场景宜采用哪种方式。（6分）（3）微服务改造后，理赔状态需要被内部多个服务和外部渠道查询。请从幂等性和链路追踪两个方面给出技术对策。（4分）2.答案：（1）建议拆分：•理赔受理服务：负责报案、单证上传、查勘任务分配；•智能审核服务：负责规则引擎、自动核赔；•定损核价服务：负责定损、报价、核价；•理赔支付服务：负责生成支付指令、对接账户和第三方支付、执行对账；•客户资料服务：负责客户、保单、银行账户等主数据；•消息通知服务：负责短信、App推送和邮件通知。拆分边界的主要依据：•按业务能力和聚合边界划分，一个服务对应一个相对独立的业务能力或业务聚合；•每个微服务拥有自己的数据存储，不能直接读写其他服务的数据库表；•按变更频率隔离，核赔规则变化更快，应独立成服务，便于独立发布；•按外部系统边界划分，对支付、账户等外部依赖增加防腐层；•结合组织团队结构和交付边界，减少跨团队协调成本。（2）四种方式比较：•2PC/XA：数据库XA协议提供强一致性，但事务过程中资源锁定时间长，协调者故障会导致阻塞，扩展性差，不适合跨异构系统和长流程业务。•TCC：将分布式事务拆成Try、Confirm、Cancel三段，业务最终一致，控制灵活，但每个参与方都要实现三套接口，补偿逻辑复杂。•Saga：将长事务分解为多个本地事务，失败时执行逆向补偿操作，无全局锁、扩展性好，适合跨微服务的长业务流程，但需要专门设计补偿逻辑和处理隔离性问题。•本地消息表：业务操作和消息写入同一个本地事务，通过MQ异步消费，实现简单，最终一致，但要求消费者幂等并处理消息积压。本场景推荐采用Saga方式，并结合本地消息表（Outbox模式）保证事件可靠发布。理赔链路长，支付、通知等环节通常无法参与XA事务；Saga不持有全局锁，最终一致，且每一步都有审计记录，适合保险理赔的异步长流程。（3）幂等性对策：•外部渠道请求必须携带唯一业务流水号，服务端使用唯一索引或去重表判重。•对理赔状态采用状态机管理，重复请求不允许改变已推进状态；例如同一案件不能从“已审核”重新触发“待初审”。•支付指令以paymentId作为幂等键，支付失败重试时不再重复扣款。•异步消息消费时记录messageId，避免重复消费导致重复操作。链路追踪对策：•在网关生成全局TraceID，并随HTTPHeader透传给所有下游服务。•每个服务创建SpanID，记录服务名、开始时间、结束时间和处理结果。•集成OpenTelemetry，将调用链路上报至Jaeger或Zipkin，最终实现按TraceID查询一次理赔请求的完整调用链路及耗时。解析：微服务拆分必须遵循限界上下文，将业务内部高内聚、业务之间低耦合。分布式事务没有通用银弹，强一致、最终一致和实现成本需要平衡；对保险理赔这样跨多个业务域的长流程，Saga比2PC更适用，但必须通过消息可靠投递和消费幂等来兜底。3.某电商平台使用Nginx对Web服务器集群做负载均衡。大促期间每台Web服务器的请求到达率预计为400请求/秒，单请求平均服务时间为2ms。已知请求到达和服务时间可近似为泊松流和负指数分布，可按M/M/1排队模型估算性能。（1）请写出M/M/1模型的利用率ρ、系统响应时间W、排队等待时间Wq、排队长度L（2）若大促峰值到达率上升为600请求/秒，请分析单台服务器能否满足“平均响应时间不超过20ms”的要求；若增加一台相同服务器并平均分担负载，估算此时单台服务器的平均响应时间。（5分）（3）除增加服务器外，请从应用架构、数据访问、代码层面分别提出一条降低响应时间的具体措施。（5分）3.答案：（1）设到达率λ=400请求/秒，服务率μ=1/0.002=500请求/秒。利用率：$（2）当λ=600请求/秒时：$$\rho=\frac{600}{500}=1.2>1$$此时排队系统不稳定，请求队列会无限增长，单台服务器无法满足平均响应时间不超过20ms的要求。增加一台服务器并平均分担负载后，每台服务器到达率$\lambda'=300$请求/秒：$$\rho'=\frac{300}{500}=0.6$$$（3）•应用架构层面：将短信通知、对账单生成等非核心操作改为消息队列异步处理，缩短同步调用链路，同时使服务无状态化，便于水平扩展。•数据访问层面：热点商品信息、用户会话等放入Redis缓存；对数据库慢查询优化索引，必要时采用读写分离或分库分表。•代码层面：避免在循环中逐条查数据库，改用批量查询；减少JSON序列化和反序列化次数，对热点方法进行性能剖析和优化。解析：M/M/1排队模型可以帮助估算系统在随机到达条件下的平均响应时间。当利用率接近1时，排队时延会迅速变大；超过1时系统进入不稳定状态。容量规划时不仅要关注平均响应时间，还要关注峰值突发流量和排队模型的适用条件。4.某电信运营商计划建设用户经营分析平台，数据源包括计费详单、CRM客户资料、网络信令、营业厅和App渠道日志，每日新增约20TB。业务需要：①月度经营分析报表；②每2小时更新的实时营销指标；③按用户维度查询最近90天消费与上网行为。（1）请按数据域划分方法，给出该平台的4个主题域及每个主题域应包含的核心数据实体（各2个）。（5分）（2）从离线与实时统一处理的角度，比较Lambda架构与Kappa架构的优缺点，并为该平台选择一个可落地的架构方案。（6分）（3）请给出支撑“用户90天行为秒级查询”的物理存储设计建议。（4分）4.答案：（1）•客户主题域：客户档案、客户账户、客户标签。•收入主题域：账单明细、缴费记录、收入汇总。•业务使用主题域：语音话单、流量详单、位置信令、业务订购记录。•渠道与营销主题域：渠道触点日志、营销活动、营销响应结果。（2）Lambda架构：•优点：批处理层适合处理海量离线数据和复杂ETL，数据可以全量回溯和重新计算；速度层负责实时增量计算，能够满足2小时级实时指标要求。•缺点：需要维护两套处理逻辑和代码，批、流指标口径可能不一致，运维和开发成本较高。Kappa架构：•优点：所有数据统一进入消息队列，通过流处理引擎统一处理，离线计算通过数据回放完成，只维护一套处理逻辑，架构更简洁。•缺点：长时间重放海量数据的成本和存储开销高，复杂即席SQL和月结类批量计算能力相对弱，对消息队列的稳定性和数据保留期要求高。本平台推荐采用Lambda架构落地。原因：每日20TB的批处理量以及月度经营分析报表更适合使用Spark/Hive离线计算，实时营销指标由Flink实时计算；为降低两套口径不一致的风险，公共维度和指标口径必须统一，后续可逐步引入Hudi/Iceberg等流批一体表格式，向Kappa架构平滑演进。（3）•明细存储：使用HBase或Hudi，按用户ID分桶；RowKey设计为用户ID前缀加事件时间倒序，使单个用户最近90天的数据尽量落在连续的存储区域。•文件组织：离线文件使用Parquet或ORC格式，按日期分区，再按用户ID散列分桶，避免扫描全量数据。•预聚合：预先计算“用户日行为汇总”“用户月费用汇总”等聚合表，查询页面优先读取汇总结果，明细数据仅在下钻时访问。•缓存与分层：最近7天热数据放入Redis或内存；90天内的详情保存在高性能存储，超过90天的历史数据迁移至冷存储并设置TTL。解析：电信行业数据量大、维度多，先按主题域规划数据仓库有助于数据复用。Lambda架构更适合“批量报表+实时指标”同时存在的场景，但必须关注离线与实时结果的指标一致性。用户维度的秒级查询依赖合理的RowKey设计、文件分区和预聚合，不能直接对全量明细做全表扫描。5.某三甲医院新建HIS（医院信息系统），需承载挂号、医嘱、检验检查、电子病历等核心业务。系统要求RPO不超过15分钟，RTO不超过2小时。生产机房与同城灾备中心相距约30km，专线带宽500Mbps，每天新增数据量约50GB。技术团队提出三种方案：-方案A：每日全量备份到备份介质，每4小时增量备份，备份介质分别存放于生产机房和灾备中心；-方案B：存储层异步复制+数据库DataGuard备库，生产故障时切换至灾备中心；-方案C：两地三中心双活数据中心，应用双活、数据实时同步。（1）请解释RPO和RTO的含义；通过计算判断在理想带宽条件下，500Mbps专线能否在15分钟内传完50GB日增数据。（5分）（2）请结合RPO/RTO指标，从三个方案中选择合适的容灾方案，并说明理由。（5分）（3）容灾系统建成后，请给出容灾演练的组织要点及每年演练频次建议。（5分）5.答案：（1）RPO指灾难发生后允许丢失的最大数据量所对应的时间长度，即系统可恢复到灾难发生前的最远时间点；RTO指从灾难发生到业务服务恢复所允许的最长中断时间。按1GB=109字节计算，理想带宽下传输时间为：$$T=\frac{50\times10^9\times8}{500\times10^6}=800\\text{s}\approx13.3\\text{分钟}$（2）方案A不满足要求。每日全量加每4小时增量备份，RPO至少为4小时，恢复时需要按顺序恢复最近全量和多个增量，RTO也很难控制在2小时内。方案C能够满足RPO和RTO，但需要双活数据中心、实时同步链路和更强的运维能力，建设与运营成本很高，对三甲医院HIS场景而言并非必