Ruankao System Analyst (Senior) case studies
Ruankao System Analyst (Senior) · Put your knowledge to work in context.
The System Analyst (系统分析师) is the senior-tier credential in China's Computer and Software Professional Qualification Exam (软考), a national examination administered by the Ministry of Industry and Information Technology with certification handled through the China Institute of Electronics. It sits above the mid-level Software Designer and is aimed at people who shape systems rather than just build them: requirements analysts, solution architects, technical leads, and consultants who must translate fuzzy business goals into workable designs. The exam rewards breadth. You are expected to reason about computer architecture and operating systems, software engineering process models, requirements elicitation and modelling, architecture styles and design patterns, database design and normalisation, network and security fundamentals, project and quality management, and current topics such as cloud, big data and enterprise integration. Topics on this exam: Computer Systems Fundamentals and Architecture, Software Engineering and Development Methods, System Analysis and Requirements Engineering, System Design and Architecture, Data Management and Database Systems, Networks, Security, and Information Assurance, Project Management and Quality Assurance, Emerging Technologies and Enterprise Applications, and Professional English and Technical Writing. The Ruankao System Analyst (Senior) case studies are 5 cases and about 412 words.
1医保智能审核系统：三方冲突下的需求基线如何建立
某市医保局委托承建方开发医保智能审核系统，合同工期10个月、预算1200万元，需支持峰值2000并发、单笔审核响应不超过2秒。第3个月末提交的需求规格说明书共1863条条目，其中功能需求1710条，非功能需求仅43条，且多为“响应快”“界面友好”等定性表述。需求调研只访谈了12名业务骨干，未覆盖地市经办窗口人员。文档以Word章节组织，条目无唯一编号，测试组无法据此设计用例。评审会上，经办、稽核与定点医院三方对“审核规则可配置”理解不同：经办要求业务人员在界面维护规则并即时生效；稽核要求变更留痕并经法制部门审批；医院要求规则调整提前30天公示。项目组用两周做了规则配置原型，三方仍各执一词。项目经理提出“先开发、后确认”，被监理书面否决。系统还需对接省医保平台、医院HIS与银行支付，三份接口规范均未冻结，省平台文档只有字段清单、无错误码定义。合同为固定总价，双方对“需求理解偏差”是否属于变更范围存在分歧。当前进度滞后2周，变更请求累计47项，未关闭38项，系统上线前还需通过等保三级测评，而安全需求尚未写入需求文档。. 按阶段对号入座（结论必须挂在案例事实上） 获取 ：只访谈12名业务骨干，遗漏地市窗口，导致“规则公示期”“离线补录”等场景缺失；省医保平台、HIS、银行三方未纳入干系人清单，接口需求自然无法冻结。 分析 ：三方把“权限、审批、公示”三件事塞进同一条需求，语义未拆解，冲突无法收敛；安全需求（等保三级）完全缺席。 规格化 ：1863条中非功能仅43条且不可度量；条目无唯一编号、无来源、无优先级，实际上不具备基线资格。 验证 ：原型只演示界面，未验证规则冲突检测、审批流、生效时间窗等关键行为；测试组无法从文档派生用例，需求缺陷只能在下游暴露。 管理 ：47项变更、38项未关闭，说明既无CCB也无影响分析；“先开发后确认”本质是放弃基线。 建立基线的步骤 1. 每条需求分配唯一ID，记录来源、优先级（MoSCoW）、验收标准、关联用例与设计元素，形成双向追溯矩阵。 2. 把定性描述改写为可测指标：审核P95≤2s、规则发布生效延迟≤5分钟、年可用性≥99.9%。 3.
62 words, under 1 min2零售订单域微服务拆分：一致性方案与组织约束的取舍
某连锁零售企业计划把单体ERP中的订单域重构为微服务。现状：Oracle单库，订单主表4.2亿行，日订单80万，大促峰值3000 TPS，大促期间订单库QPS约1.2万、写占比35%。下单需同时扣减库存、核销优惠券、发起支付，客户对订单查询的P99要求为500ms。业务规则是：库存允许短暂超卖，但必须在30分钟内冲正；支付渠道回调可能重复、可能乱序到达；优惠券严禁超发，一旦超发将引发客诉与赔付。订单状态现由数据库status字段维护，有12个状态和40余条if-else分支，缺少状态机约束，历史数据中存在状态回退记录。库存与订单当前共用同一数据库账号，跨表JOIN较多。IT部门共6人，其中2人没有分布式系统经验；运维仍以虚拟机和人工发布为主，没有容器平台，也没有自动化流水线。第三方支付渠道有3家，接口协议各不相同，回调验签逻辑被重复实现。此前两次重构尝试均因上线后对账不平而回滚。管理层要求6个月内完成拆分，且下一次大促期间不得停机；财务要求订单金额与支付流水每日对账，差异必须当日查清。. 为“下单-扣库存-支付”链路选择一致性方案（本地消息表/Saga/TCC），并说明补偿与幂等设计。. 结论：不可行，应按绞杀者模式渐进拆分。 依据不在技术，而在组织：6人团队中2人无分布式经验、无容器平台、无自动化发布、无链路追踪，故障定位平均4小时；而“大促不停机”恰恰要求最强的灰度与回滚能力。历史上两次重构都因对账不平回滚，说明团队尚未掌握跨服务数据一致性的验证方法。此时全面拆分，是把架构风险叠加在能力短板上。 边界划分依据 ：按业务能力与限界上下文，而不是按技术分层。三个核心不变量决定了边界--库存是“可售量不被超卖”，优惠券是“券不被重复核销”，订单是“交易状态机”。支付渠道协议各异、验签逻辑重复，应下沉为防腐层（ACL）统一封装，而不是自建一个支付微服务去承担资金状态。 拆分顺序（按风险与收益排序） 1. set 可售=可售-n where 可售 =n 原子条件更新，杜绝超卖；30分钟未确认由定时任务释放生成冲正单，正好对上业务允许的窗口。 优惠券 不放进Saga ：在优惠券库内用唯一索引（券ID+订单ID）由单库本地事务核销，失败即整单回滚，用数据库的强约束解决“严禁超发”，比补偿可靠。 支付回调：建回调流水表，以渠道流水号+渠道标识为唯一键做幂等；用状态机版本号丢弃乱序的过期事件，回调只驱动状态迁移，不直接改金额。 补偿与兜底 ：每个正向动作必须有可重复执行的逆向动作；补偿以业务单号+动作类型做唯一键保证幂等；补偿失败进人工干预队列并告警；每日对账核对订单、库存、支付三方流水，差异超阈值即冻结相关账户。 不选TCC的理由 ：三个服务都要实现Try/Confirm/Cancel，Confirm失败仍需兜底，开发与运维成本对6人团队过高；TCC适合资源预留语义强、响应时间敏感的短事务，而这里是长流程。.
71 words, under 1 min3计费详单库：分库分表之前该做什么
某电信运营商计费详单库保存13个月在线数据，主表12亿行、约2.1TB，按日分区但历史分区从未清理，冷热数据混在同一张表，备份窗口已达6小时。日增详单2000万条，营业厅需按手机号码查询近13个月详单，当前平均响应8秒、超时率12%。现有索引为（号码，起始时间），但统计类SQL普遍带函数转换，导致索引失效。报表团队每日6次直连生产库执行聚合SQL，业务高峰期数据库CPU持续95%以上。架构为一主两从，binlog为ROW格式，高峰期从库延迟最高达90秒，部分前台查询已读到过期数据。曾尝试把报表迁到从库，因延迟被迫回退。运维尝试加索引后写入性能下降，大促期间出现过一次大事务导致的复制中断。管理层倾向直接分库分表，但客户明确要求查询界面与操作习惯不得改变，改造后详单查询P95不超过2秒，预算只够一轮改造，且改造期间系统不停机。系统还承担每月一次的监管数据报送，需按全省维度做全量统计，须在每月5日前完成。运维团队5人，无专职DBA，缺乏分库分表运维经验。. 在主从延迟90秒的前提下，说明读写分离策略、缓存一致性处理以及应写入SLA的业务妥协。. 看等待事件与执行计划 ：若8秒均值主要来自 db file scattered read 、全分区扫描或大量回表，则属于访问模式问题（分区裁剪失效、函数转换导致索引失效），而不是数据量问题。 2. 看SQL来源分布 ：报表每日6次直连跑聚合，CPU 95%，这是典型的混合负载互相干扰，属于架构问题（OLTP与OLAP未隔离）。 3.
75 words, under 1 min4医院集团混合云安全：从弱口令到横向移动的整改设计
某省属医院集团下设三个院区，采用混合云：核心HIS与影像库部署在本地机房，互联网挂号与在线复诊部署在公有云，两端通过IPSec VPN打通。去年发生一起入侵事件：外网VPN账号因弱口令被撞库攻破，攻击者进入办公网后，利用多台服务器共用的本地管理员口令横向移动到影像库服务器，最终约3万份影像文件被加密，业务中断两天。事后调查发现：办公网与服务器区之间没有访问控制；关键服务器日志仅保存在本地且保留7天；全网没有集中的身份认证系统；200余台医疗设备使用固定IP、无法安装安全Agent。现有账号由各系统自行管理，同一员工在不同系统有3至5套账号口令，离职账号回收依赖人工通知，平均滞后11天。集团有员工2000余人、互联网患者账号约50万，挂号高峰并发约1200。运维由信息科4人承担，7×24小时值班仅1人。院区之间通过两条专线互联，带宽分别为200Mbps和100Mbps。去年事件后已上防火墙与IPS，但规则两年未更新，误报率高，运维常直接放行。集团要求一年内通过等保2.0三级测评，员工端需支持多因素认证，患者端支持短信与微信登录；影像科提出跨院区会诊调阅影像延迟不得超过3秒，单次检查约80MB，跨院区调阅占比约15%。安全改造不得影响临床业务，核心系统每月停机窗口仅2小时。. 按攻击链分析横向移动得逞的根本原因，并给出网络分区与微隔离方案，包括无法安装Agent的医疗设备如何处理。. 入口 ：VPN仅凭账号口令、无MFA，弱口令撞库即破门。 2. 凭据 ：多台服务器共用本地管理员口令，抓取哈希即可Pass-the-Hash复用，这是横向移动成功的直接原因。 4.
74 words, under 1 min5政务云平台项目：挣值偏差与质量成本的联合判断
某政务云平台项目工期6个月、预算800万元，采用固定总价合同，项目组12人分4个小组，采用两周一个迭代，但同时被要求按CMMI三级提交23类文档，迭代评审经常因文档返工延期。第4个月末项目经理汇报：PV=560万元，EV=420万元，AC=490万元。关键路径上的接口联调因第三方厂商延迟2周，该厂商由甲方指定分包、与承建方无合同关系，其接口文档在验收后才定稿。质量数据显示：缺陷密度3.8个/千行代码，返工工时占总工时28%，集成测试发现的缺陷中62%可追溯到需求评审阶段未被发现的歧义。测试环境只有一套，集成测试与性能测试争抢环境，性能测试已排队11天。团队已连续加班两个月，近一个月离职2人，其中1人是核心模块开发。客户方3个业务处室分别提出优先级，无统一出口；项目前期未设CCB，变更由项目经理口头同意。客户在例会上口头表示“可以先上线再补功能”，但未提交变更申请，也未确认哪些功能可延后。合同约定需求变更超过总价10%需重新审批，目前累计变更工作量估算为62万元，但尚无一份双方签字的变更单。预算中风险准备金30万元已用去21万元。系统还需通过三级等保测评，整改工作量尚未计入进度计划。监理要求两周内提交纠偏方案。. 计算SV、CV、SPI、CPI并解读其含义，预测完工成本与工期，并判断“增加人力赶工”是否可行。. 用质量成本（COQ）分析返工根因，说明为什么“加强测试”不是有效对策，并给出改进措施与度量。. 计算 SV = EV − PV = 420 − 560 = −140万元 （进度落后） CV = EV − AC = 420 − 490 = −70万元 （成本超支） SPI = 420/560 = 0.75 CPI = 420/490 ≈ 0.857 EAC = BAC/CPI = 800/0.857 ≈ 933万元 ，预计超支约133万元 按当前速率推算工期 ≈ 6/0.75 = 8个月 解读 ：SPI与CPI同时小于1，说明不是“多花钱把进度追回来了”，而是钱花了、活没出来--这与28%的返工工时、3.8个/千行的缺陷密度互相印证，属于典型的返工型偏差。若CPI<1而SPI 1才是赶工有效，本案相反。 赶工可行性 ：关键路径被第三方接口卡住2周，对关键路径加人无效（布鲁克斯法则），新增人力还要承担沟通与培训成本，而团队已连续加班两个月、一个月离职2人。可行路径只有三条：把非关键路径任务并行或外包；压缩范围；就第三方延迟主张工期顺延（该厂商是甲方指定分包，责任不在承建方，应发正式函件留证）。 结论 ：“加人赶工”不可行，应改为“范围裁剪+关键路径压缩+书面顺延”，并把EAC 933万元与8个月作为与客户谈判的基线数据，而不是继续用原承诺硬撑。.
130 words, under 1 min