销售丢单，竟是IT运维“升级”惹的祸！

为了避免在正常上班时段进行系统升级影响企业的日常办公，某企业信息中心的系统升级工作一般都选择在周末进行。这个周末，信息中心软件部的小钱约了软件厂商的IT技术人员进行业务系统升级。小钱在上周五提前以mail形式通知整个公司，本周末业务操作系统即将关闭，建议业务部门避免在周末加班，提前安排好工作。随后，信息中心依照工作计划，关闭了整个业务操作系统，包括正在运行的服务器和中间件。

与此同时，正在外地出差的销售部小孙结束了和客户的沟通回到租住的宾馆，准备按照客户的要求，向客户的采购部提供报价单。在给客户采购部发邮件前，他需要得到销售总监的批准，小孙迅速登陆邮件系统，想将刚拟好的报价单提交销售总监进行审核，发现邮件系统登陆失败。公司明文规定要用内部邮箱进行沟通并存档，小孙联系现有的公司通讯录中信息中心设备部技术人员小李，试图解决自己的邮箱异地使用问题。

小李也觉得纳闷，今天就进行业务操作软件的升级工作应该不会影响邮件系统？小李在家测试登陆了一下邮件系统，也提示登陆失败，就给信息中心系统部小张去了电话。小张正在外面踢足球，也不知道具体原因，只好舍弃球赛临时去公司加班。这一耽误，销售部小孙答应给客户报价单的时间已经过去，客户等不及将其它几家厂商的报价提交给了采购部。

小张到了公司之后打开监控设备查看，发现业务操作软件系统和邮件系统都已经中断了，但是告警平台显示已经提供了告警信息，查看告警信息接受者发现是通过短信方式发给小钱了。小张想起小钱说周末要升级系统来着，就去机房找到了小钱，这时小钱的系统已经快升级完了，小钱说为了避免升级受到影响就将业务操作软件系统涉及到的设备都中断了，自己也确实收到告警短信，但是告警信息提示都是业务系统中断了，以为是同样的信息发送了两遍，所以没有予以重视。

由于一直以来信息中心都是分设备部、软件部、系统部等，各个部门各管一摊，所以软件部小钱也不知道业务操作软件系统和邮件系统共用同一个服务器。软件部小钱无意之中关掉的服务器导致系统部小张管辖的公司邮件系统中断了一个下午，销售部小孙没有按时向客户递交报价单，将造成失去订单的原因反映给了公司的领导。

通过这次事件公司领导发现现在的信息信息中心各部门之间无法打通，信息孤岛问题严重，信息中心与业务部门不能很好的融合，信息中心仍旧处于监控管理阶段，没有提高到主动预防提供服务阶段，同时信息中心没有很好的流程规范……公司领导决定根据IT服务标准——ITIL来规范信息中心现有的工作流程，争取提高信息中心的IT服务水平。但是，ITIL仅仅只是IT运维的事实标准，ITIL的流程和原则通过规章制度的方式定义和实现，通常要借助工具软件帮助其落实，在国内，这些工具软件被统称为IT运维管理平台。

北京广通信达科技有限公司提供的IT运维管理平台遵循ITIL标准规范定义了服务台、事件管理、问题管理、配置管理、变更/发布管理等在内的服务管理流程，能够为用户提供运维过程中的流程化处理的IT服务管理解决方案，通过各流程环节的工单形成IT服务的闭环管理，将人员、流程和技术有机地结合起来，将管理、监控和考核有机地结合起来，提升用户整体的运维管理水平。

那么通过IT运维管理平台提供的变更发布管理流程规范和cmdb配置管理管理库科学的结合，能够清晰的知道IT运维管理人员进行的操作会和其他什么资源或系统进行关联，同时又通过操作审核，来避免造成损失。比如此次变更发布之前，软件部的小钱需要提交申请审核，经过变更委员会的批准，核查方案的可行性，是否会因为升级造成其他的系统中断的情况，这样就能避免小钱在无意中关闭服务器导致邮件系统中断。

变更管理是指为了解决问题而需对生产环境进行变更的管理过程，用于控制和管理变更请求；目的是为了保证所有的生产环境变化内容都经过评估和记录；适用于硬件配置改变、支撑软件版本升级、配置文件改变、数据库修改、业务系统部署改变等情况；变更管理流程是较为特殊的一个流程，它往往由其他流程派生而出；包括变更请求、变更审批、变更实施、变更实施后的确认或拒绝、恢复管理、变更的控制和跟踪、发布变更结果，到最终形成变更管理的一系列管理过程和活动。

变更发布管理能借助详实的资产配置数据库，协助用户对变更请求做出合理的评估，降低变更与发布的风险。对变更风险进行有效评估，从而进行有效风险管理；避免无效变更，减少重复变更，提高工作效率；有效减少紧急变更, 从而有效保护生产系统；加强变更过程中的沟通, 提高IT服务的客户满意度。

转载：感谢您对网站平台的认可，以及对我们原创作品以及文章的青睐，非常欢迎各位朋友分享到个人站长或者朋友圈，但转载请说明文章出处。