第一篇：运维服务项目管理心得—质量管理
运维服务项目管理心得—质量管理
2016年11月有幸承接了广州市花都区某局信息化设备及系统运行维护项目的实施工作，为了保证客户能得到有质量保障的运维服务，我公司建立了完善的服务制度和拥有专业的运维服务团队。我公司整合运维服务资源，规范运维行为，确保服务质效，形成统一管理、集约高效的一体化运维服务质量保障体系，从而保障客户的设备及业务系统能安全、稳定、高效、持续的运行。
在日常运维服务支持过程中，为了有效保障项目的实施质量，我按照IT服务管理的运行服务是“持续不断提高与改进”的服务原则，按照PDCA循环持续对运维服务的质量进行优化提升。我主要从如下几个方面来保证项目的服务质量：
首先，制定运维服务操作标准，要求实施团队严格按照公司相关服务标准为客户提供服务；
其次，我在项目小组中将服务台兼任运维服务质量监督岗，有服务台对每次的服务工单进行客户回访，了解客户对我司运维服务的满意度；
第三，我还邀请公司的质量管理团队每月对项目实施的服务质量进行监督检查，然后出具第三方的项目运维服务质量报告；
第四，每月组织质量评审会，邀请公司质量部门、客户共同参加，会对上月的运维服务质量、客户满意度及存在问题进行全面总结，针对项目中碰到的质量问题，会现场讨论解决办法，会后形成解决方案；
第五，提出质量整改方案后，交由客户和质量部门确认，再由项目组实施，实施完成后由公司质量部门进行重新评估，评估通过后出具整改报告给到客户、质量部门和公司高层。
通过上述五个方面，有效的保障整个项目的服务质量，在2017年项目验收时，客户给予了我们五星服务的评价。
慧翔天地广州学员黄贤裕
第二篇：IT运维心得分享范文
360公司运维心得分享
在很多“外人”的眼中，运维工程师的工作不过是搬机器、调网络、装软件、处理故障、7×24小时值班，简单而又枯燥至极。但事实并非如此，运维工作涵盖很多技术领域，运维工程师要掌握硬件、软件、操作系统、开发等多方面的知识，核心目标是为亿万用户使用的产品保驾护航。
当今互联网行业的发展日新月异，新技术层出不穷。为了适应发展趋势，运维工程师只有提升技术能力才能更好地完成艰巨的运维任务，必须要对传统运维发出自我挑战。
在360，运维团队由基础运维团队、网络运维团队和应用运维团队三部分组成。我们将运维从技术支持领域升级，进行产品化改进，核心目标是为了降低运维成本、缩短研发周期、让产品试错更廉价。理想很丰满，现实很骨感，从最初服务少量项目、几十台服务器，发展到大量具有数亿用户的项目，我们也在不断摸索，在试错中成长。在这个过程中，我们经历了两次重要的升级。第一次升级：运维工具化
运维工作中有很多琐碎的、重复的事情，初期我们只有两个IDC，服务器数量有限，项目数量也较少，靠纯手工劳作还可以应付。但随着时间的推移，项目暴增，随之IDC和服务器的数量也成倍增长，同时360各项目都是小团队在做，开发风格不同、习惯各异，但极致要求响应速度，如果运维工作按照之前方式进行，很难满足需求。大势所趋，我们必须进行工具化升级，将重复的事情自动化。
在工具化过程中，我们秉着低成本、拿来即用的原则，借鉴业界成型的方案，同时将精力用在对开源软件的研究中，有开源工具就绝不自己凭空创造。初期，我们只围绕开源软件做周边脚本开发，不动核心代码，在实践中总结经验。例如，在最基础的部署软件环境中，我们基于YUM搭建了自己的包管理系统，将常用软件打包，同时根据项目做成模板，这样无论是初始安装还是扩容都能在分分钟完成。配置文件管理利用Puppet完成，服务器批量操控依赖SaltStack。就这样 我们的运维兵器谱在不断地丰富。
另外，运维工作离不开监控报警，这是一件让无数运维人苦不堪言的事情。而会休息才会工作，监控体系必须优化。
我们的监控大概分为系统级、应用级、项目逻辑和用户体验四部分。系统级主要监控硬件和网络等；应用级主要监控常用软件的健康状况；项目逻辑监控主要模拟用户行为探测项目功能点是否运行正常；用户体验监控主要联动博睿和基调等第三方监控一起优化用户体验。我们用过的工具很多，开源工具有Nagios、Cacti、Ganglia、Zabbix等，同时自己也开发了一些针对项目场景的监控工具，但万变不离其宗，都是围绕上述几个维度进行监控，然后再进行分级预警和报警。
为了减少报警骚扰，我们分级处理，将报警分为邮件预警、短信报警和疯狂短信报警。以磁盘空间监控为例：每天下午6点，统计 磁盘使用率超过80%的机器，发出邮件预警，下班前解决；在预警的基础上，超过85%触发短信报警；超过90%就要持续报警，避免事故的发生。此外，随着 服务器数量的增多，硬件故障在所难免，架构设计需要考虑高可用方案，冗余范围内的服务器故障会以邮件预警的方式发出，避免对运维工程师的骚扰。
有了监控工具和分级机制，还需要有好的制度。为了大部分人可以安心休息，我们每天有专人负责处理常规报警，遇到无法解决的问题才要求他人协助。第二天的负责 人要针对第一天的报警找出根本原因，并尽力解决，因为如果无法根治，困扰将持续发生。所谓线上无小事，实际工作中复杂场景引发的问题数不胜数，所以可以宽 容第一次错误，但不能接受同样问题发生第二次，要不断地总结和完善。
工具化是运维的必经之路，是向更高层发展的基础，面对运维这样复杂的学科，这样一个极其磨炼人意志的工种，运维工程师需要用聪明的方式解决复杂的问题，节省时间，去做更有意义的事情。
第二次升级：运维产品化
我刚提出运维产品化时，有朋友开玩笑说，你做后端运维吃苦受罪这么多年，看着产品经理吃香的喝辣的，羡慕嫉妒也想转行做产品吧。也有人说，你是在偷换概念，不就是做自动化运维平台嘛。其实提出这个概念，一方面是源于有了足够的工具化积累；另一方面是想换一种思路做运维，培养产品观，站在用户的角度思考问题，让处于后端的运维工程师主动挖掘需求，围绕运维做更多的探索，提升团队技术能力，解决海量用户带来的问题。有了这个想法，就需要将无形的技术转变为有形的产品形态，同时要赋予它好的寓意。我们的产品取名为HULK——绿巨人，意在让小伙伴们借助巨人的肩膀成长，轻点鼠标，运筹帷幄。
想到做这个平台，源于对实际工作需求的观察。产品经理有了创新点之后，开发工程师就想以最快的速度上线，但又会很痛苦，因为产品就好比宝塔明珠，塔基需要一 层层地盖。而开发工程师是与运维工程师合作最紧密的兄弟，“兄弟有难得拔刀相助”，因此我们明确了开发工程师就是运维平台的用户，运维工程师在平台的建设 中扮演了多重角色，是建设者也是使用者，但目标是为用户解决问题，让我们的用户有极致的用户体验。基于这些想法，我们勾画出了宏伟蓝图，提供一个塔基，第一层提供核心基础服务，如Web、RDB、NoSQL等；第二层提供通用基础服务，构造一个完美的平台，让开发工程师受益。但勾画的平台功 能大而全，需求都是我们替用户假想的，这样做的后果就是进展缓慢，但做出的功能没人用。我们在失败中反思，意识到需求还得从日常工作中去挖掘，平台上每个功能模块都必须解决用户的痛点。互联网精神唯快不破，要围绕“快”找痛点。早期开发和运维的合作中，更多的是邮件、IM及当面沟通，跨团队的沟通成本是第 一个痛点。初期平台建设中，我们从加速流程开始进行摸索，以“需求任务流”为核心，将通用需求规范流程，统一需求提交页面，同时尽量为用户提供选项，而不是随意填写，尽量减少沟通成本，同时为完全自动化打好基础。由于完整的自动化流程开发成本比较高，初期我们还“投机取巧”，用户提交需求以后，只是把格式 化的邮件发送给运维工程师。运维工程师使用半自动化工具干活，完成后再通过平台任务流告知用户结果，手工操作的部分是隐藏在平台后面的，用户不得而知。就 用这种方式，我们的平台积累了不少用户和口碑。之后我们将日常需求分层、分类：主机类包括主机申请、账号授权、软件部署等；Web类包括配置文件管理、域名管理等；DB类包括建库、建表、SQL审核、授权等。再攻克技术难点将一个个需求实现完全自动化，点点鼠标解决问题。
关于需求任务流，还有个小插曲，标准的任务流由提交、审核、驳回/通过组成。但这个流程太死板，例如用户提交的一个需求，在审核的过程中有待商榷，运维工程师会和开发工程师 沟通，最终达成一致意见即可，而如果按标准流程需要驳回再提交。为了让用户少一次操作，我们增加了管理员可编译功能。有些同事反对这样做，觉得不符合常 理。不过有时候常理是需要结合实际场景打破的，就为了让用户使用更简单。
近期为了进一步提升项目试错阶段的速度，我们在平台上推出了一个新功能：“项目孵化器”。以典型的Web业务为例，以往，申请Web Server、账号、数据库实例、负载均衡等是提给运维最基本的需求，每一步都是时间成本。使用“项目孵化器”可以最大限度解决这个痛点，只需在平台上进 行两个步骤：第一步填写业务名称，预估峰值QPS；第二步选用MySQL、MongoDB、Redis等相关数据库资源。两步之后，Web Server、数据库实例等所需资源会瞬间展示在用户面前，同时包管理、配置文件管理、代码发布系统、监控系统等配套辅助功能随之开通。
与之前的模式相比，效率和规范化都有明显提高。说起来很神奇，但实现理念很简单，我们提炼日常项目中的通用方案，构建资源池，在项目发展初期最小量匹配资源。在孵化器的设计阶段，我们听到了很多不同的声音。例如，让用户填信息不够全面，架构太简单不满足全部需求，诸如此类问题，让人头痛欲裂。经过过往项目 分析及用户调研，发现项目尚处于试错阶段，快速试错是首要需求。至于项目发展中衍生出来的需求，可以再用平台扩展功能去解决。当利用孵化器建立一个试错项目之后，用户进入平台想看见什么？展现形式如何？还能做什么？这些问题随之而来。
众所周知，项目中的关联关系是个复杂的问题，解决不好，就像一盘散沙无法联动。为了解决此问题，首先我们确定平台各功能模块以项目名为主键，将项目的域名、负载均衡、Web Server、数据库、通用基础服务等相关联。项目后期各功能模块的扩容可以借助关联关系自动化完成。例如增加一台Web Server，即可自动部署软件环境，完成相关节点授权、上传代码、测试上线。
展现形式上我们借鉴社交网站的实现方案，以“我的项目”为中心，用户进入平台以后默认页展示项目在平台中用到的各功能模块信息，例如域名、主机数量、数据库实例和监控指标等。做到信息清晰可见，操控简单易用。
在平台建设中，我们一直遵循两个准则：第一，把事情由复杂变简单；第二，给用户极致的用户体验。所谓极致，就是要超出用户的预期，但只有挖掘用户潜在的需求，才能做出超出预期的功能。传统的运维模式，大多是开发工程师提需求，运维工程师满足需求，运维工程师主动推进的意识不够。360的文化中有很重要的一点是Ownership，一个项目的成功与失败，运维工程师是有责任的，因此需要在日常工作中时刻提醒自己“这个项目是我的，为了让项目变得更好，我们需要主动思考，为开发工程师提供更多的增值服务”。例如一个项目上线前，会默认部署日志收集模块，收集汇总后进行访问日志自动化分析，以时间维度展示访问量走势，同时辅以IP地址分析模块展示地域及运营商分布。同时基于访问日志状态码做进一步的页面分析，然后以日、周、月维度生成一份体检报告，以及应对方案推送给开发工程师。这些增值服务是超出预期的，拉近了开发工程师和我们的距离，一起去探讨、改进，做出更多有利于项目发展的功能。结束语
运维工作在一家公司中至关重要，但传统的运维模式一定程度上限制了运维工程师的技术发展，更抑制了创新思维，我们需要利用运维“宽泛技术”定位的优势开拓思路。例如运维工作需要和很多开发团队合作，协助架构设计，在这个过程中会接触到很多开发团队的技术积累，可以把各家之所长进行聚合，将一些基础服务进行平台化改造，资源共享。也可以根据项目的需要，主动做技术研究，将基础服务做成一个个小产品，提供给开发团队使用，帮助项目缩短研发周期，稳定发展。在当今技术背景下，运维工程师应该在红海中寻找蓝海的思维模式，培养产品观，由外至内地思考，突破传统运维的壁垒，开拓创新。
第三篇：ITSM运维服务项目需求书
ITSM运维服务项目需求书
一、宁波市财税局信息化服务管理系统简介
宁波市财税局信息化服务管理系统（以下简称IT服务管理系统）是宁波市财税局提升信息化运维服务管理水平的重要项目。系统共分为监控平台和流程系统两大块，其中监控平台由OVO基础架构监控、BAC业务监控和NNM网络监控等系统组成，流程系统主要是HP Service Manager流程平台软件（以下简称SM流程平台）构成。
IT服务管理系统项目一期自2009年12月启动，借鉴国际先进的运维管理经验，逐步建立起一套与财税信息化建设相匹配的制度化、规范化的运维服务管理系统，实现了以下的基本目标：
1、制定了切实可行的IT服务管理制度和规范；
2、建立了统一的IT服务管理支持平台和高效的、集中统一的监管平台；
3、奠定了IT服务管理从分散向集中、从无序到有序、从被动到主动转变的基础。
IT服务管理系统经过三年多的建设，目前流程系统已经覆盖宁波市财税局各部门及所属各县（市）财税局各部门和基层单位、各区财政局信息中心及各区地税局各部门和基层单位。与此同时，对原有分散的运维管理工作进行了重新整合，切实提高了我市财税信息化的运维服务水平，为信息系统运维的规范化、制度化奠定了基础。经过项目建设、运行和优化，系统的核心功能已经基本具备。
二、招标内容
运维服务内容：
1、IT服务管理系统查询模块维护优化
投标方应按招标方要求，对综合查询模块进行维护优化，保证综合查询模块的正常使用，并对招标方提出的合理化需求进行功能优化和调研开发。
2、优化完善运维系统流程 1）系统优化完善
投标方需对项目已实施的工作内容进行优化完善，具体如下：
A）监控平台的调整改进
监控平台自2010年底部署以来，招标方的组织架构和IT基础环境都发生了较大的改变，投标方必须针对现有实际情况对整个监控平台进行调整和优化。B）配置管理优化整合
投标方需对项目已建立的基本配置信息库完善配置管理流程，充分发挥配置管理的优势和作用。C）问题流程实施
投标方应按招标方要求，部署推广IT服务管理系统的问题流程，让问题流程在全市财税系统发挥其应有的作用，体现问题流程的效果。
2）系统驻场维护
投标方需派驻3名专业的运维人员负责招标方IT服务管理系统的日常运维工作，具体工作内容如下：
A)投标方需负责操作系统环境和软件运行方面的维护工作： 保证运维软件平台的操作系统及其运行环境的正常稳定运作。 保证运维软件平台的正常运作。 运维软件BUG修正：
软件固有BUG，采用官方补丁等手段修正。
设计流程等修改操作产生的软件BUG，分析研究修正。
B)投标方需负责SM流程平台管理、设计实施和功能修改等工作： SM流程平台系统管理，如用户权限设定和用户界面设计等。 SM流程平台功能修改，改变部分软件功能。 错误数据修改，对用户输入的错误数据进行改正。
配合完成一些涉及到SM流程平台的集成开发工作，如提供SM流程平台的接口等。
参与部分流程的具体工作，如事件重分配、变更阶段修改等。C)投标方需负责需求访谈、流程推广和指导培训等工作：
定期进行SM流程平台的访谈调研工作，听取招标方用户的意见和建议，了解用户对SM流程平台的感受，为下一步的工作提供参考。
需求跟进开发，对用户提出的问题或解决问题过程中产生的新需求进行研究，征求招标方的意见，进行相应开发工作。
流程优化，投标方需适时地根据SM流程平台运行情况提出优化建议，与招标方讨论研究，使SM流程平台更贴近招标方用户需求。
投标方应按招标方要求对招标方用户提供现场或非现场的指导服务。 投标方应按招标方要求对招标方用户提供定期或不定期的培训服务。D）投标方需负责系统相关文档工作： 投标方应在每月底提供系统运行报告。
投标方需协助招标方完成与SM流程平台有关的规章制度的建立工作。 投标方需适时对整个SM流程平台进行评估，提出可行性方案。
3、全市财税系统IT服务管理系统运维服务
投标方应按招标方要求，通过SM流程平台建立全市统一的基于一体化系统的全程技术服务体系，形成责任清晰的问题逐级上报和反馈机制。
投标方应遵循“全市运维问题有记录，办理过程有跟踪，处理结果能反馈”的原则来设计开发县（市）区运维流程，保证SM流程平台的高质量、高效率。
如招标方需要，投标方还需完成以下工作：
1）对县（市）、区单位进行访谈调研，确定流程需求，根据实际情况调整流程。
2）对开发设计好的流程进行电子化实施。
3）对县（市）、区单位人员进行流程理念宣导和操作培训等工作。4）对县（市）、区单位人员的合理咨询和提问予以答复和改进。
4、Oracle软件和相关存储设备的维护
投标方需配备专门的工程师对招标方采购的Oracle GoldenGate软件和相关存储设备进行售后维护工作，包括日常使用、故障处理等方面的咨询答疑、远程支持、现场支持等工作。
三、其他内容和要求
1）在本项目的执行过程中，投标方需提供固定数量的经招标方认可的工程师全职服务。未经招标方许可，此部分人员工作时间内不得参与本合同以外的其它工作。
2）在本项目的执行过程中，投标方的工作人员必须遵守招标方相关的规章制度，遵守保密协议，与招标方签订相关保密协议。投标方须与投标方聘用的此项目的工作人员签订保密协议，并交由招标方备案。
3）在本项目的执行过程中，投标方需建立一套经招标方认可的、切实有效的运维机制，并在本项目的执行过程中严格按照该运维机制进行系统完善与维护。
4）项目中产生的所有源程序和文档版权属招标方所有。服务到期验收时，投标方需提交项目涉及的所有源程序、设计开发过程中的所有相关文档。
5)投标方需在投标文件中列出项目所需的
第四篇：IT运维项目管理心得—风险管理
IT运维项目管理心得—风险管理
过在PMP的学习，结合多年的IT运维项目实施管理工作经验，我对项目管理中的风险管理有了进一步的学习和认识，我真正认识PMP项目管理在现实生活中的运用。
风险管理是预防、规避项目风险的主要手段，是完成项目计划内的期限、预算内费用、规定的技术指标等的重要保障。在每个风险管理周期都应该做好从设计、合同、进度、质量、费用、沟通等管理工作中收集相关信息，并将这些信息反映在风险管理过程中的各环节工作中，并及时进行反馈。
现将我对项目风险管理的理解总结如下：
1、做好风险识别
在项目启动阶段，将对项目需求及项目实施过程中可能面对的风险进行全面的识别，结合公司已有的风险评估表，对识别出来的风险进行评分。
2、做好风险管控
在项目实施阶段，对前期已识别的风险，按照不同的风险等级进行管控，针对高危等级的风险（如：客户关键业务系统宕机）通过外包（购买原厂服务）或采取一定措施降低风险值的方式解决（提供专业人员提供24小时值班监控）；针对中等级的风险，则制定相应的风险解决方案（如：巡检、定期保养、设备实时监控），来减少或缓解风险的发生概率；针对低等级风险，则采取定期监控方式。
3、做好风险监测
风险监测是持续不间断进行的过程，主要包含跟踪已识别的风险，监测残余风险和识别新的风险，形成风险管理监控报告，对重新识别的风险进行排序形成风险评估表，为管理人员提供决策的量化依据。通过对风险的良好监测和控制并形成风险管理监控报告，在风险发生前做出有效决策，减少风险造成的损失。（慧翔天地广州学员黄贤裕）
第五篇：信息化设备运维服务项目合同
第一章 合同要求说明
投标人必须响应并承诺以下所附合同主要条款。
合同登记编号：
中国共产党广州市委员会办公厅计算机机房和会议系统设备运维服务项目合同
甲方：中国共产党广州市委员会办公厅 乙方：
甲、乙双方根据中国共产党广州市委员会办公厅计算机机房和会议系统设备运维服务项目（采购编号：）招标的结果，经双方友好协商，签订下列条款：
一、服务范围
此次中共广州市委办公厅计算机机房和会议系统设备运维服务项目包括办公厅所属各个机房的环境设备和会议系统设备两大部分。其中计算机机房包括办公厅所属14个机房及配线间的UPS、精密机房空调设备、以及相关机房及配线间的环境监控设备；会议系统设备分为会议系统设备维护和会议现场支持两部分。
二、下列文件均为本合同书的组成部分
1、招标文件。
2、供方中标的投标文件。
3、在实施过程中双方共同签署的补充文件。
以上文件与合同附件具有同等法律效力，若以上文件与本合同有差异的，以本合同内容为准。
三、服务内容：
对中共广州市委办公厅14个机房及配线间（含2号楼2楼会议室机房）的UPS不间断电源设备、机房空调设备以及相关环境监控设备进行维护；对办公厅8个会议室（总值班室）的会议系统设备进行检查、保养和维护，对8个会议室提供会议现场技术支持（2个是视频会议室）。
四、提供服务的时间和地点
1、提供服务的时间：签订合同后起一年内。
2、提供服务的地点：甲方指定地点
五、合同金额
合同总价： 元，（人民币大写：）。其中会议系统设备零配件维修所需总费用，采用实报实销方式，此项费用按维护期内实际发生费用进行结算，维护期结束后将账务统一移交甲方。
六、款项支付
（一）合同签订后15个工作日内，按合同总价的50%办理支付手续。
（二）运维服务期满6个月后，中期验收合格之日起15个工作日内，按合同总价的20%办理支付手续。
（三）运维服务期满验收合格之日起15个工作日内，按合同总价的30%办理支付手续。
（四）乙方须在甲方办理付款手续前10个工作日内，提供等额的正式发票给甲方，以便甲方及时办理付款手续。
七、甲方的权利和义务
1、甲方有权随时检查乙方的服务履行情况，并向乙方提出修改。
2、当发生服务违约时，则甲方有权按“服务违约处理标准”在支付乙方工程款项中进行扣款。
3、在乙方提供服务时，如对甲方的设备造成了损坏，甲方有权要求乙方赔偿。
4、甲方应按合同规定向乙方支付服务费用。
八、乙方的权利和义务
1、乙方应按招标文件的要求和投标文件的承诺进行服务，发生任何服务的变更均须向甲方提出交书面报审报告。
2、乙方有权要求甲方按时支付服务费用。如甲方不按时支付乙方有权要求甲方支付滞纳金。
3、乙方在提供服务时如损坏了甲方的设备，乙方应照价赔偿或更换同等设备。若因设备的损坏而引起其它损失的，乙方应作出合理赔偿（以甲乙双方协商或行政仲裁的结果赔偿）。
九、保密条款
见附件一 《保密协议》。
十、合同纠纷的解决
在履行合同的过程中，甲、乙双方如产生合同纠纷，协商不成的情况下，可向合同履行地人民法院提起诉讼。
十一、合同书的有效期间
本合同书一式四份，具有同等法律效力，甲、乙双方各执一份，广州公共资源交易中心一份、广州市财政局一份。合同自双方签字的最后一个签字之日起生效。
十二、约定事项的变更
由于出现不可预见的情况，影响项目工作的如期完成，甲乙双方可要求变更约定事项，但应及时通知对方，并由双方协商解决。
十三、本合同书未尽事宜，由甲乙双方依照《中华人民共和国合同法》协商处理。
十四、签约地点为：
甲方： 乙方： 地址： 地址： 法定代表人： 法定代表人： 委托代理人： 委托代理人：： 开户银行： 开户银行： 银行帐号： 银行帐号： 项目负责人： 联系人： 电话：
电话：
签订日期：20 年 月 日 签订日期：20 年 月 日
点击咨询 