信息系统运维管理工作之我见
作者:易隐者 发布于:2014-8-26 11:45 Tuesday 分类:IT 服务
前段时间,在某个场合遇到某专家的一个问题:你对信息系统运维的理解是什么?这是一个非常开放性的问题,当时现场时间紧、任务重,未来得及回答,这几天将我的理解大致总结如下:
1,信息系统的运维工作应围绕用户核心业务展开
用户的信息系统的构建主要目的不是为了单纯的互联网访问需求,而更多的是为用户的核心业务提供基础支撑服务,如财务系统、OA、CRM、ERP、电子商务、网游、工控系统等,如下图所示:
正是因为信息系统与业务系统逐步趋于融合的特性,决定了信息系统运维管理工作的终极目标是保障用户的核心业务系统能够稳定、高效、安全的运行。
基于这个目标,我们在运维管理信息系统的时候,绝大部分的工作需要围绕核心业务来展开。跟核心业务关联的信息系统组成元素(任何元素出现异常都会导致业务系统出现异常)是我们需要重点关注的对象,跟核心业务无关的信息系统组成元素则因其无关业务大局,在运维资源、运维人员时间精力等限制的条件下,大可等而次之。
2,利用工具的目的是“简化工作,提高效率”而非其反面
使用运维管理工具的出发点是“简化运维管理工作,提高运维管理效率”,基于这个出发点,运维管理工具应站在大部分运维管理者的角度,以简单、直观、明了的方式展现出用户最为关心的部分——与核心业务系统相关联的信息系统“健康”状态,所谓业务系统的健康状态主要包括“可用性、稳定性、安全性”等三大方面,简单阐述如下:
可用性——业务系统连接正常吗?可正常访问吗?常规应用操作正常吗?
稳定性——业务系统是否稳定?是否存在缓慢、丢包等现象?是否时通时断?
安全性——是否存在被入侵的痕迹?系统或业务重要文件是否被篡改?
运维管理工具不应单纯追求功能上的大而全、细而精,若如此则必然导致运维管理工具偏离其“简化工作,提高效率”的出发点,如当今绝大部分的运维、SOC产品最终变成了仅适用于少数具有大量专业技术人员的行业单位(如电信、银行等),而让绝大部分其他行业的信息系统运维管理者望而却步——产品本身的专业性和复杂性就已经成为了运维管理工作的门槛和障碍!
每个人都喜欢简单,简单让我们更有效率,如果能够使用点点鼠标就可以解决的问题,我们就不会通过敲一长串命令去解决,不是吗?
好的运维管理工具应该具备以下几点基本要求:
1、实时、自动、不间断监测业务关联的信息系统组成元素的运行数据
2、 围绕核心业务的运行健康情况做简单、直观的关联展示,不是多个信息系统组成元素的单个松散的展示
3、能够及时主动发现异常并做出预警
4、为常见异常预警问题智能提供解决思路,协助用户解决常见异常问题
5、与专业服务团队关联,实现产品自动关联主动应急响应服务
6、大胆摒弃大而无当、给运维效率带来反作用的功能
如何实现它?很简单,把大部分的运维管理者当成不具有专业知识的普通用户即可。可惜目前市面上所有的运维、网管、SOC产品类均因偏离了使用工具的初衷而不具备以上特点。
3,运维工作远非单纯工具可解决,离不开专业支撑团队
工具目的在于简化运维工作,提高运维效率,即使工具平台做的“更智能、更简单”,但由于信息系统本身的复杂性和不同用户环境的差异,总有一些疑难问题需要借助精专的技术服务团队,在用户现场帮助用户解决。
专业技术服务团队的以下基本要求:
1、全面的信息技术领域覆盖,不可存在技术短板
2、具有专业的技术水准,这是解决疑难问题的基础
3、站在用户立场设计解决方案,客观公正,不推销产品
4、服务本地化,保障及时应急响应
5、服务与工具自动关联,实现主动应急响应
6、依赖“技术团队”而非个人,个人不具备全面的专业技术素养
4,运维工作应形成体系而非单纯产品和服务的结合
运维体系涉及到的对象应包括业务、用户、服务团队等,运维体系的构建应包括以下几个基本内容:
模式:服务经费来源保障,具体合作方式、服务级别要求等
人员权责:用户方、服务方具体人员的分工和权责
管理制度:考核、相关管理制度
接口:用户与服务团队的对接方式等等
流程:巡检流程、应急处置流程、故障处理流程等主要事件的处理流程
运维体系因需而设,因用户而异,但需“简单、实用、可操作”。
5,运维是长期的、持续的、动态的、不断完善的过程,而非一劳永逸的
用户的业务在不断的变化、用户信息系统的组成元素在不断变化、各种信息系统的突发事件、系统的优化完善升级改进等实际情况,决定了运维管理工作是一个长期、持续、动态、完善的过程,无法做到一劳永逸。
6,因信息技术专业性以及运维资源的限制,信息系统的运维管理工作全面外包是大势所趋
将越来越精专、分工越来越细化的信息系统运维管理工作交给专业的服务团队,对用户而言,花少量的资金就可以很好解决复杂专业的问题。将用户解放出来,用户有更多的时间和精力专注于自己的核心业务及管理工作,这对用户及服务团队来说是双赢的局面。
从这些层面来说,信息系统的运维管理工作全面外包是大势所趋。
以上为我个人关于信息系统运维管理工作的一己之见,欢迎讨论。
标签: 运维管理 运维 服务外包 信息系统运维 运维服务外包
电子政务系统运维管理方法和理念
作者:易隐者 发布于:2014-6-19 19:37 Thursday 分类:我的PPT
应用层保活行为
作者:易隐者 发布于:2012-12-17 10:53 Monday 分类:网络分析
我之前专门针对TCP保活撰写了一篇较为详细的说明文章——《TCP保活(TCP keepalive)》,在传输层主要通过TCP的保活功能来实现连接的保持,当时我也提到应用层的保活功能,但是应用层的保活功能在实际工作中较为少见,因为如果TCP能够提供保活功能的话,应用层一般就可以利用TCP的保活功能来实现连接的保活,但是毕竟应用层跟传输层是有区别的,一方面并不是所有的应用层会话都需要实现保活功能,另一方面TCP是针对传输层的,一旦开启TCP保活功能,将对所有基于TCP的应用产生影响,这些影响可能会是负面的,如我博客里的案例:《由TCP保活引起的业务访问故障案例》,这也是运维管理者不愿意看到的,因此,有些应用自行设计自己的应用层保活行为。
近期在用户的工作环境中,看到了如下图所示的应用层交互行为:
大家可以清晰的看到,这个交互过程具有以下行为特征:
1, 客户端每间隔固定时间(30秒)发出同样的请求;
2, 每次交互的报文都是一致的(客户端的请求、服务器的响应、报文长度等);
个人认为这些行为特征足以证明该交互过程是应用层设置的应用连接保活探测行为。
标签: TCP 明文 故障 运维管理 保活 行为特征 TCP保活 应用保活
IT
作者:易隐者 发布于:2012-9-8 22:20 Saturday 分类:个人观感
说说你看到下图时的感觉
我说说我的感觉:
1,IT已经成为承载各行各业核心业务必不可少的基础设施,是保证核心业务高效、稳定、安全运行的中流砥柱;
2,ITer压力山大,这些压力来自哪里?来自与跟核心业务高效、稳定、安全运行有关的各种潜在的、可能的威胁,包括业务系统
性能问题、网络性能问题、网络业务安全问题、各种故障问题等等
从《复仇者联盟》看可视的重要性
作者:易隐者 发布于:2012-8-23 20:58 Thursday 分类:其 他
刚才看复仇者联盟,在刚开场的片段中出现下面一幕的对白:
独眼龙长官问:情况有多糟?
手下小弟答:最糟的是,长官,不知道情况
这一幕已经把信息系统运维管理工作中可视的重要性淋漓尽致的表现出来了,你认为呢?
日历
最新日志
链接
分类
最新碎语
- 如果一个人想要做一件真正忠于自己内心的事情,那么往往只能一个人独自去做"——理查德·耶茨
2019-06-25 21:34
- 日后我们知道,真正的人生道路是由内心决定的。不论我们的道路看上去如此曲折、如此荒谬地背离我们的愿望,它终归还是把我们引到我们看不见的目的地。(茨威格《昨日世界》)
2019-03-16 21:27
- 如果你渴望得到某样东西,你得让它自由,如果它回到你身边,它就是属于你的,如果它不会回来,你就从未拥有过它。——大仲马《基督山伯爵》
2018-10-09 22:07
- 人生有两大悲剧:一个是没有得到你心爱的东西;另一个是得到了你心爱的东西。人生有两大快乐:一个是没有得到你心爱的东西,于是可以寻求和创造;另一个是得到了你心爱的东西,于是可以去品味和体验。——弗洛伊德
2018-09-25 18:06
- 一个人越有思想,发现有个性的人就越多。普通人是看不出人与人之间的差别的——布莱兹·帕斯卡尔
2018-08-30 18:44
存档
- 2020年11月(2)
- 2018年1月(1)
- 2017年12月(1)
- 2017年11月(6)
- 2017年6月(1)
- 2017年5月(1)
- 2017年4月(1)
- 2017年3月(1)
- 2016年11月(1)
- 2016年4月(1)
- 2015年7月(2)
- 2015年6月(1)
- 2015年5月(5)
- 2014年12月(1)
- 2014年11月(1)
- 2014年10月(1)
- 2014年8月(1)
- 2014年7月(1)
- 2014年6月(1)
- 2014年5月(1)
- 2014年4月(3)
- 2014年2月(2)
- 2014年1月(2)
- 2013年12月(1)
- 2013年11月(1)
- 2013年10月(2)
- 2013年9月(1)
- 2013年8月(1)
- 2013年7月(3)
- 2013年6月(2)
- 2013年5月(1)
- 2013年4月(3)
- 2013年3月(1)
- 2013年2月(2)
- 2013年1月(2)
- 2012年12月(11)
- 2012年11月(12)
- 2012年10月(12)
- 2012年9月(26)
- 2012年8月(29)
- 2012年7月(18)
- 2012年6月(2)
- 2012年5月(25)
- 2012年4月(16)
- 2012年3月(13)
- 2012年2月(6)