题目由网友回忆整理而成，因此部分叙述可能与原题有出入，且部分题目有缺失，如有更准确版本，欢迎在评论区补充~
【案例分析】
试题一（共25分）
【问题1】
详细调研的步骤？
【问题2】
前端服务器配置8vcpu,32GRAM300个虚拟机实例,当前使用率50%,应用服务器配置16vcpu,32GRAM，200个虚拟机，当前使用率60%，目标是三年后，业务翻倍，三年后要求cpu使用率为80%，云上主机的规格保持不变，仍然分别是8C32G、16C32G。要求cpu使用率均为80%，假设，三年后，业务规模翻倍，资源和业务线性增长，再不考虑单实例类型，请计算 vcpu和虚拟机数量（版本一）
前端层300个实例，8vcpu，32GRAM，资源利用率50%应用层200个实例，16vcpu，32GRAM，资源利用率60%三年后业务增长100%，资源利用率不超80%，分别算出两个的实例数和cpu数（版本二）
【问题3】
计算资源规划常用方法有，填空，（1）（2）（3）（4）：
（1）一种基于历史数据和趋势分析的方法，用于预测未来的计算资源需求。通过收集和分析工作负载数据、性能指标和业务需求，可以确定所需的计算资源规模和配置。
（2）通过优化计算资源的配置和使用，以提高系统性能和效率，包括调整资源分配、优化算法、改进网络和存储性能等措施，以满足业务需求，并提高响应时间、吞吐量等性能指标。
（3）一种将工作负载分布到多个计算资源上的方法，以确保资源利用的均衡和高效。
（4）一种动态调整计算资源的方法，根据实际需求的变化自动扩展或收缩资源。
【问题4】（6分）
简答题（题目没收集到）
【问题5】（5分）
判断题，共5题。
【参考答案】
【问题1】
详细调研的步骤：
（1）收集信息
（2）系统需求建模
（3）需求的优先级划分
（4）构建系统原型，检验可行性并发现问题
（5）产生和评估候选方案
（6）和管理部门一起复查各种建议
【问题2】
已知条件，当前业务情况下，前端服务器CPU使用率50%，应用服务器CPU使用率60%。当前，前端CPU资源使用量=8*300*50%=1200vcpu，应用服务CPU资源使用量=16*200*60%=1920vcpu。
三年后业务量翻倍，资源和业务线性增长，不考虑单实例类型。也就是说，三年后：前端CPU资源使用量=1200*2=2400vcpu，应用服务CPU资源使用量=1920*2=3840vcpuCPU利用率为80%，所以，前端CPU资源需求量=2400/0.8=3000vcpu应用服务CPU资源需求量=3840/0.8=4800vcpu实例类型不变，所以，前端实例数量=3000/8=375台，应用服务实例数量=4800/16=300台。
前端服务器
当前状态：
配置：8 vCPU，32G RAM
虚拟机数量：300个
CPU使用率：50%
总vCPU：300×8=2400 vCPU
实际使用：2400×50%=1200 vCPU
三年后需求：
业务翻倍，资源线性增长
实际需要的vCPU：1200×2=2400 vCPU
目标使用率：80%
所需总vCPU：2400 ÷80%=3000 vCPU
所需虚拟机数量：3000÷8=375台
应用服务器
当前状态：
配置：16 vCPU，32G RAM
虚拟机数量：200个
CPU使用率：60%
总vCPU：200×16=3200 vCPU
实际使用：3200×60%=1920 vCPU
三年后需求：
业务翻倍，资源线性增长
实际需要的vCPU：1920×2=3840 vCPU
目标使用率：80%
所需总vCPU：3，840÷80%=4800 vCPU
所需虚拟机数量：4，800÷16=300台
| 服务器类型 | 当前虚拟机 | 三年后虚拟机 | 增加数量 | 当前总vCPU | 三年后总v CPU | 增加vCPU |
| 前端服务器(8C32G) | 300 | 375 | 75 | 2400 | 3000 | 600 |
| 应用服务器(16C32G) | 200 | 300 | 100 | 3200 | 4800 | 600 |
| 合计 | 500 | 675 | 175 | 5600 | 7800 | 2200 |
【问题3】
（1）容量规划（2）性能优化（3）弹性伸缩（4）负载均衡
问题3，4题目没收到，答案略。
试题二（共25分）
项目背景描述：
活动1:组织进行XX分析活动,活动2-5没收集到。
场景1:业务发展较快，需要大量基础设施
场景2:开发人员写代码，方便开发部署
场景3:需要性能较高的计算资源
场景4:需要文档上传功能场景5:需要文档协作平台
【问题1】
应用系统规划的过程，以及各个过程用的方法或者产出物？
【问题2】
信息系统规划的三种框架，各自特点及使用场景，结合案例说明该企业选择哪种框架？
【问题3】
案例中的五个场景适合哪种云计算模式，说明理由和原因。
（1）业务发展较快，需要大量基础设施
（2）开发人员写代码，方便开发部署
（3）需要性能较高的计算资源
（4）需要文档上传功能
（5）需要文档协作平台
【问题4】
应用系统分类分级后5步是什么?
【参考答案】
【问题1】
应用系统规划的内容：生命周期选择、体系结构定义、接口定义、数据定义、构件定义。
生命周期选择的产出物:生命周期模型
体系结构定义的产出物:整体视图
接口定义的产出物:通信方法、协议、接口调用方法、功能内容、输入/输出参数、错误/例外机制等
数据定义的产出物:数据模型和信息模型
构件定义的产出物:数据结构和构件
【问题2】
信息系统规划的三种框架：
（1）以应用功能为主线的框架
（2）以平台能力为主线的框架
（3）以互联网为主线的框架
在企业信息化与数字化架构的规划中，通常存在三种不同的建设主线，分别适用于不同发展阶段和规模的组织：
其一，以应用功能为主线的框架，核心关注点在于信息系统的软件功能。该类框架在规划与实施上通常采取“统一规划、分步实施”的策略，即根据实际业务需要逐步部署相应功能模块。该模式适用于中小型工业企业，或处于信息化、数字化初级阶段的制造企业。
其二，以平台能力为主线的框架，源于云计算技术与服务能力的不断成熟。其核心理念在于将传统“竖井式”信息系统的组成部分进行解构，转向“平层化”的建设方式。该框架适用于组织规模逐步扩大、数字化成熟度提高的阶段，企业可借鉴行业最佳实践，并逐步构建自主知识体系与创新能力。在这一阶段，业务个性化、特色化需求日益显著，同时更强调跨业务体系的协同融合，信息系统也需依托数据共享，提升数据集成的灵活性与便捷性。
其三，以互联网为主线的框架，强调将信息系统功能最大限度地实现“App化”（即微服务化）。不同App的组合方式与实施路径，可依据组织的数字化能力成熟度进行定制。该框架适用于已发展至产业链或生态链运营阶段的大型集团企业，或业务结构复杂多元的集团化公司。
| 特点 | 以应用功能为主线 最基础的模式 | 以平台能力为主线 适合业务发展到需要灵 活制阶段 | 以互联网为主线 最高级形态 |
| 适用对象 | 信息化发展初级阶段企业 | 数字化转型能力成熟度 提升企业 | 产业链/生态链/集团化企业 |
| 核心理念 | "拿来主义“采购成套软件 | “竖井式”转“平层化” 建设 | 信息系统功能App化(微服务 ) |
| 建设特点 | 以部门职能为单元 | 平台化基础，弹性定制 | 基于能力成熟度的动态适配 |
| 集成方式 | 系统软件接口 | 标准化接口与中间件 | 云边端融合与动态编排 |
| 实施策略 | 统一规划、分步实施 | 双态IT(敏态与稳态) | 业务细化拆分，数字化封装 |
【问题3】
（1）IaaS（2）SaaS（3）IaaS（4）FaaS（5）PaaS
结合案例，理由和原因如下：
1、IaaS的优点包括：①灵活性。②可扩展性。③高可用性和可靠性。④成本效益。适用场景包括：①Web应用程序部署。②大规模数据处理。③备份和灾难恢复
2、PaaS的优点包括：①灵活性。②简化部署和管理。③可扩展性。④高可用性和可靠性。适用场景包括：①Web应用程序开发。②移动应用程序开发。③物联网应用程序开发。④大数据和人工智能应用程序开发。
3、SaaS的优点包括：①方便性。②可靠性。③可扩展性。④成本效益。适用场景包括：①办公软件。②客户关系管理（CRM）。③人力资源（HR）管理。④供应链管理（SCM）。
4、FaaS的优点包括：①灵活性。②可伸缩性。③可靠性。④高效性。适用场景包括：①微服务架构。②事件驱动架构。④云原生应用。
试题三（共25分）
A公司和医院签了3年服务合同，安排了一个项目管理小王，一个运维工程师小李。运行4个月，服务台报核心系统HIS出现问题，已有3次相同的登录失败问题。小李说自己在忙，过1小时后去发现是相同的问题，前端简单的解决了。第6个月，HIS系统中断运行，小李前去发现是电源部件故障，联系供应商协调换部件，时间来不及，影响了医院挂号。医院投诉A公司，回溯发现，客户1个月前反馈过电源部件闪灯异常，但服务台没有记录。小王去汇报问题，医院生气了。
【问题1】
服务中存在的问题?
【问题2】
流程绩效评估指标体系中，平衡计分卡的四个维度?
【问题3】
服务质量检查的活动？
【问题4】
判断题，具体内容没有收集到。
【参考答案】
【问题1】
一、 流程机制问题
-
事件管理流程缺失或执行不力：
-
重复事件未被识别：连续3次相同的登录失败问题，只被当作独立事件处理，没有升级为“问题”进行根本原因调查。这说明缺乏对重复事件的关联和分析机制。
-
优先级判断错误：小李因“忙”而延迟处理，表明他对该事件的紧急性和影响度判断不足，也可能缺乏明确的SLA（服务级别协议）来指导优先级排序。
-
解决方案不彻底：前端“简单地解决”属于临时性修复（Workaround），而非根治。这为后续更严重的故障埋下了伏笔。
-
-
问题管理流程完全缺失：
-
这是本案例中最核心的缺失。“事件”是单次的干扰，“问题”是导致事件发生的根本原因。A公司只有被动响应“事件”的环节，没有主动调查“问题”的流程。
-
如果在前3次登录失败时启动了“问题管理”流程，很可能提前发现系统底层的隐患（可能与硬件、网络或软件配置相关），从而避免第6个月的重大中断。
-
-
服务请求/事件记录流程失效：
-
客户反馈未记录：医院在一个月前就反馈过电源部件闪灯异常，但服务台没有记录。这是致命的失误，使得一个宝贵的预警信息被完全忽略，无法触发任何预防性行动。
-
信息传递断裂：客户反馈的信息停留在口头，未能转化为服务台的可追踪记录，导致技术团队（小李）和管理层（小王）对此预警一无所知。
-
二、 资源管理问题
-
人力资源配置不足且不合理：
-
一个项目经理和一个运维工程师支持一个医院的“核心系统”，人力显然单薄。运维工程师小李“在忙”，表明他可能忙于处理各种杂务，无法专注于核心系统的稳定性和预防性维护。
-
职责不清：小李似乎同时负责一线响应和后台运维，没有分离，导致他经常处于“救火”状态，无法进行深层次的系统优化和监控。
-
-
运维人员技能与意识不足：
-
小李缺乏主动服务和风险意识。他对重复事件不敏感，对客户的非正式反馈（闪灯异常）没有主动追踪和记录的意识和习惯。
-
可能缺乏处理复杂硬件问题的授权或培训，导致在发现电源故障时，只能被动联系供应商，而没有应急方案。
-
三、 供应商与合同管理问题
-
供应商管理被动：
-
在发生关键硬件故障时，联系供应商协调更换部件“时间来不及”，说明：
-
可能没有与供应商签订明确的、带有惩罚条款的支持合同（如4小时上门备件更换）。
-
没有在本地储备关键备件。
-
没有对关键部件的生命周期进行管理。
-
-
四、 沟通与服务意识问题
-
沟通机制不健全：
-
在发生重大中断（影响挂号）前，没有向医院进行主动的风险告知或进展通报。
-
项目经理小王是在问题发生后才去汇报，属于被动沟通，而不是在问题处理过程中保持透明。
-
-
客户关系管理缺失：
-
整个服务过程显得被动和迟钝。医院已经“生气了”，表明累积的不满（多次登录问题、最终重大中断、预警被忽视）终于爆发。A公司缺乏主动管理客户期望和满意度的机制。
-
【问题2】
流程绩效评估指标体系中，平衡计分卡的四个维度是（财务）、（客户）、（流程）、（学习）。
财务目标、客户目标、流程目标、学习目标（目标两字加不加都可以）
【问题3】
常见的质量实施和检查活动包括：
（1）满意度调查
（2）项目质量保证工作
（3）内审
（4）管理评审
（5）日常检查
（6）质量文化培训
【问题四】
2×3√
【论文写作】
持续改进与监督活动贯穿信息系统服务的全生命周期，且是持续性的，不存在明显的起止时间。系统规划与管理师应依据服务级别协议及信息技术服务标准对信息系统服务进行评价，并对服务供方的服务过程、交付结果实施监督和绩效评估，确保实现预定的服务要求，从而提升客户满意度和服务质量。
请以“论信息系统服务持续改进与监督”为题，分别从以下三个方面进行论述：
1、概要叙述你参与过的或者你所在组织开展过的某信息技术服务项目的基本情况（背景目的、组织结构、服务对象，服务内容、交付成果等），并说明你在其中承担的工作。
2、结合项目实际，论述你对信息系统服务持续改进与监督的认识，可以包括但不限于以下方面：
（1）服务改进与监督的主要活动和目标。
（2）结合你的项目，设计服务过程测量的指标。
（3）结合你的项目，按照人员、资源、技术、过程四个方面介绍你的服务改进的活动。
3、请结合论文所提到的信息系统服务项目，介绍你是如何进行信息系统服务持续改进与监督的，包括具体做法和经验教训。
【论文解析】
【写法1】
背景500-600字左右
过渡段100~200字左右
子题目1：理论阐述
要求纯理论介绍五个核心活动，并分别依据教材内容或个人理解，用2至4句话简要说明每个活动的目标。整体篇幅建议在200–300字之间。
子题目2：理论与指标结合
偏向理论部分，可先文字列举教材中关于服务管控与服务执行的关键指标，再以表格形式系统汇总。也可结合实际案例进行说明，例如通过测量某一指标发现具体问题，并简述后续解决方案。本部分可控制在200字左右；如采用“理论+实践”的展开方式，则可扩展至约500字。
子题目3：实践应用分析
偏向实践操作，建议围绕四个要素展开：首先介绍每个要素所涵盖的内容，然后针对每个要素选取2–3个重点内容，结合具体项目实例进行说明。举例时应包含“发现问题”与“解决问题”的过程。本部分建议不少于800字。
收尾部分
撰写300–400字的总结，对全文内容进行归纳，并适当延伸思考或提出建议。
【写法2】
背景（500–600字）
本部分将阐述项目背景，包括信息化现状、核心系统运行环境、待解决的服务问题及其对业务的影响，为后续分析提供上下文基础。
过渡段（100–200字）
在明确问题背景的基础上，为系统提升服务质量与管理水平，需建立一套完整的服务管理机制。该机制应涵盖风险识别、绩效测量、质量评估、定期回顾与持续改进等环节，从而形成闭环管理。
一、服务风险管理（约100字）
服务风险管理旨在系统识别、评估并控制IT服务过程中可能影响稳定运行的各类不确定性。其目标在于提前预见潜在故障与业务中断，通过预防性措施降低发生概率与影响，保障服务连续性与可靠性。
二、服务测量（重点撰写）
本部分将围绕人员、过程、技术与资源四个要素，系统构建服务测量的指标体系。重点聚焦于过程要素，通过设置关键绩效指标（KPI）监控服务流程的执行效率与规范性。以下为建议的呈现方式：
-
首先文字说明各要素的测量重点；
-
随后以表格形式汇总过程类指标，如事件解决时长、变更成功率、SLA达成率等；
-
可结合实例说明指标如何反映问题并引导优化。
三、服务质量管理（约100字）
服务质量管理致力于确保服务设计、交付与支持的全过程符合预定标准与客户期望。其核心目标是通过建立质量基准、实施质量评估与纠正偏差，持续提升服务的一致性、可用性与用户满意度。
四、服务回顾（约100字）
服务回顾是周期性评估服务绩效与客户反馈的机制。其目标在于系统总结服务成效与不足，识别改进机会，强化与客户的沟通对齐，确保服务方向与业务目标保持一致，并为下一周期计划提供输入。
五、服务改进（重点撰写，不少于800字）
本部分将围绕服务改进的四个要素（如人员、过程、技术、资源）展开：
-
分别介绍各要素所涵盖的主要内容；
-
针对每个要素，选取2–3项关键内容，结合真实项目案例进行阐述；
-
每个案例需包括“发现问题—分析原因—实施改进—验证效果”的完整逻辑，体现从问题识别到解决的实际过程。
收尾（300–400字）
总结全文观点，强调服务管理机制整体性与持续性的重要意义，并可就如何在组织中系统落地相关实践提出展望或建议。
扫一扫
429
到【灌水乐园】发言
