供销合作社的飞快运营之路,DevOps与价值观的同归于尽落地执行

新时代IT行业背景下,企业的高效运维之路

近年来信息技术的飞速发展为企业的业务模式带来了新的机遇,同时也对企业的IT运维带来了巨大的挑战。云计算带来的“池化”、虚拟化带来的抽象化、大数据带来的海量数据等等,都对传统IT运维的管理理念与管理模式带来了前所未有的挑战。

澳门网上正规赌场网址,传统IT运维的基本要求是能够对分散的资源进行统一管理,常规资源的日常检查与故障排除成为IT运维人员的主要工作,但是在当前行业背景下,原本看似合理的传统运维模式已经暴露出越来越多的问题,例如,技术储备不足、缺乏培训、管理混乱等等,运维工作逐渐变得混乱、低效、无序。那么,企业应该如何应对呢?

高效运维ITIL来“搭把手”

ITIL——IT服务管理领域最佳实践,目前已经成为事实上的行业标准。ITIL以服务的视角,结合流程、人员、工具,将IT管理中的各项活动进行梳理和整合,使IT与业务紧密集合在一起,极大的提高了企业运维的效率和质量,同时降低了企业运营成本。

东华网智运维产品总经理杨重阳介绍,不管是对传统的IT运维还是当前新时代下的IT运维,ITIL的管理理念和方法都具有普适性,在可以预见的未来,其最佳实践的地位不会被动摇。ITIL教给我们的最重要的内容不是技术而是管理思想。

谈到东华软件自主研发的IT服务管理系统,他提到,我们不希望卖给客户的仅仅是一个能够够灵活定制各个流程的工具,我们更关注的是在这基础之上的,能够为客户带来符合客户自身业务需求的最佳管理实践,能够帮助我们的客户从传统的IT管理向IT服务管理转变。杨重阳提醒到,流程在落地之后,效率的提高可能并不会立竿见影,相反,甚至会因为工作方式的改变,影响原来的工作效率,尤其对流程复杂的大型企业更是明显。但是随着时间的推移,业务流程的不断优化,各部门人员之间的磨合,效率会得到明显提升。

没有最好,只有最适合

起初,虽然ITIL在国外取得了巨大的成功,但在引入国内的前几年中,同其他从国外引进的管理理念一样,难免有些“水土不服”。在业界专家、ITIL厂商以及国内企业的共同努力下,IT服务管理成功的走上了本土化的道路,并取得了长足的发展。在落地的过程中,逐渐形成了“自上而下”设计、
“自下而上”建设的一般原则,帮助企业逐步搭建符合自身实际需求的IT服务管理平台。作为最早一批涉足IT服务管理的厂商之一,东华软件不断积累成功经验,与新老客户一起,为IT服务管理行业的健康发展贡献力量。杨重阳讲到,我们希望客户在ITIL落地的过程中,能够对自身的状况有一个清晰的认识,结合自己的实际,合理规划ITIL的落地。一定不要以为上一套ITIL的工具就算实施了IT服务管理,也不要寄希望于短时间内就能达到非常理想的效果。在规模较小或者IT成熟度不高的企业,先把事件流程、知识库落地可能会是一个比较好的选择。让企业习惯了在规范的流程下工作,积极促成IT运维人员从“救火队员”到“保健医生”角色的改变,从“正确的做事”到“做正确的事”的观念改变。然后在持续不断的改进优化当中,形成最适合企业自身的最佳实践。

杨重阳特意强调,虽然企业对提高运维效率的需求很迫切,但是不能操之过急,过犹不及。提高效率要从企业当前水平入手,制定并量化合理的目标水平,重视效率与客户满意度的平衡,最重要的是不能忘记保障是运维的初衷。

高效运维之路自动化有待考究

ITIL理论在IT基础架构的基础上,延展出了全面的运作体系,然而如何具体实施高效运维,业内人士纷纷提出自己的想法,近年来探讨最为火热的是既能降低成本又能实现高效的自动化运维。不过目前自动化运维多为“半自动”模式,往往不但没为运维人员减压,还徒增了些许疲惫,更不要说实现高效运维。

杨重阳表示,真正的自动化运维必然会降低企业成本,降低对运维人员的技术要求,但自动化运维一旦出现问题,其影响面往往比较广、风险较高,所以一旦出现问题都不是小问题,从这个角度上讲,企业要完全依赖自动化是不现实的,所以企业目前对于自动化运维的态度还是比较谨慎的。对于运维人员来讲,自动化的监控手段,虚拟环境下的资源监控、网络监控、故障检测和恢复等技术,将成为运维人员转变的大方向。

不论现在还是未来,IT运维都将是企业必不可少的一部分,随着国家对信息化建设和信息安全的越来越重视,IT运维的重要性将日渐突出。在新时代背景下,企业应抓住云计算与大数据等带来的机遇,着眼制定适合自身发展的IT运维之路。


澳门网上正规赌场网址 1


近年来信息技术的飞速发展为企业的业务模式带来了新的机遇,同时也对企业的IT运维带来了巨…

IT运维持久战:理念与平台并进

随着信息技术的飞速发展,IT运维的工作量成倍增长,压力也愈发明显,传统的IT运维已不能支撑灵活的业务变动,企业管理者们纷纷关注并找寻实现高效运维的方法。

运维作为企业正常运行的基础,已在每个行业扎根。从运维管理发展的三大阶段(NSM,ITSM,BSM)来看,每个阶段都离不开一套成熟的理论体系作为强有力的支撑,而经过理论与实践考验的ITIL在其中的扮演的角色更显得尤为重要。ITIL是由国外兴起的,许多跨国大型企业诸如微软、宝洁与各大银行都已将这套体系完整的融合到运维工作中,达到了整个企业高效管理、降低成本的目的。然而,这一先进理念的引进在中国却遇到了来自管理架构、基础设施等各方面的问题,因此各厂商开始提倡ITIL的中国化之路。

高效运维是一场持久战

众所周知,IT管理中的主要矛盾来自于人和事。但由于国内外环境大不相同,ITIL的理念也是从国外引进而来,ITIL在国内的具体实施过程中因环境而产生的问题颇多。在近期Bkjia的一次活动中,笔者发现大多数运维人员都反映曾遇到过与开发人员观点不同、工作任务职责不清、分配工作流程不合理等问题。这也从侧面反映了运维管理更多靠的不是技术,而是对管理者的管理理念进行的正面挑战。

针对以上运维人员碰到的问题,笔者有幸采访到东华网智运维产品总经理杨重阳,他认为:“之所以运维会低效无序,与企业环境、制度、管理有必然的关系,要想改变确实很难,不是一时半会,也不是动动嘴皮子就能见效的,这是一场持久战。高效通常就意味着有流程,既然有流程,就有参与人、责任人,权责分明才能高效。”

IT运维时间长、成本比较高,企业正常运维需要打好提前量。正常的企业项目有百分之八十的时间与成本是投资于运维过程中,因此早早做好准备,不但会有时间应对麻烦,还可以细化运维具体事项,达到从细微处达到高效运维的目的。

国内运维起步晚,不少企业管理者对运维的认识还不够完善,目前运维市场中讨论火热的自动化运维更是让管理者们头晕目眩。在笔者看来,自动化运维时机还未成熟,对国内中小型企业也不是现阶段所必备。自动化运维必然会降低企业成本,似乎也对运维人员要求不高,但实际上却是对其提出了更高的要求,要求运维人员能处理在自动化运维过程中出现的高风险问题。现有的自动化技术并不成熟,笔者要对自动化运维成谨慎态度,想要实现自动化运维的企业不妨等等看。

“虽然企业对提高运维效率的需求很迫切,但是不能操之过急,过犹不及。合理的调高效率要从目前水平入手,制定不同方面的提高与量化,重视效率与客户满意度的平衡,最重要的是不能忘记保障是运维的初衷。”杨重阳诚恳的对企业提出建议。

规范的运维管理平台极其重要

运维之路上只有先进的理念是不完整的,想要高效运维离不开管理平台。高效运维主要依靠管理与工具和合理配合,如何结合ITIL理念打造适合企业发展的运维平台?东华网智是国内最早一批涉足IT服务管理的厂商之一,对运维管理平台有着独特的见解。

杨重阳表示“我们不希望卖给客户的仅仅是一个能够灵活定制各个流程的工具,我们更关注的是在这基础之上的,能够为客户带来符合客户自身业务需求的最佳管理实践,能够帮助我们的客户从传统的IT管理向IT服务管理转变。”

企业部门之间的日常沟通与协调需要规范的管理工具,来从事件、问题、变更、发布、配置等基础流程实现规范的管理。笔者了解到东华网智运维产品以ITIL为基础架构,例如其综合运维服务管理系统提供图形化流程与表单设计工具的设定,让客户可定制从基础属性到处理权限等各种业务流程的服务。随着时间的推移,业务流程的不断优化,各部门人员之间的磨合,效率会得到明显提升。

不同于国外对IT运维管理服务的如火如荼之势,中国IT运维刚刚起步,不论是管理理念、体系都有待完善,企业当了解自我需求,择“良木”而建设适合自身发展的运维管理方式,乘着ITIL的“顺风车”,为日后的发展打下坚实的基础。


澳门网上正规赌场网址 2


随着信息技术的飞速发展,IT运维的工作量成倍增长,压力也愈发明显,传统的IT运维已不能支撑灵活的业务…

导读:5月6日,优维科技与数人云主办了【DevOps&SRE超越传统运维之道
·深圳站】,6月北京站敬请关注~本文是优维科技CEO王津银关于DevOps与传统的融合落地实践的精彩分享

王津银/优维科技创始人&CEO

中国开放运维联盟发起人,精益运维”理论提出者,中国第一批DevOpsMaster授权讲师,持续交付专家,业内人称“老王”。“互联网运维杂谈”公众号创办者。致力于互联网运维整体解决方案的产品化能力提升,缩短企业到达互联网运维的路径。

一直觉得华南这一片技术沙龙太少了,在DevOps、SRE理念大热的今天,我们希望能把一些先进的经验分享出来,让更多的企业能够受益。华南有很多优秀的业界从业者,比如说今天邀请到的大梁,腾讯内部关于DevOps还是有很多的经验值得分享的。

今天活动主题是DevOps&SRE,我来讲DevOps,王璞分享SRE,SRE是谷歌的DevOps实践,大梁把DevOps最后一棒——持续反馈跟大家分享,希望把这些链条全部的打通。

今天的演讲主要分为以下三个部分:第一个是DevOps全局的理解以及DevOps与ITIL的对比融合,第二个是DevOps落地经验14则,第三个是案例的分析。

DevOps全局的理解

其实讲DevOps特别的多,官方里面给了一个框架图,从计划需求、设计、开发、部署、运营、宗旨,持续交付到IT运营管理、经营管理,后来扩展了一下,大家看到这个全景图的时候的确有概念的认知,我觉得不够。做了以下几点改动:

☆ 第一: IT运营管理

以前叫IT服务管理,因为IT服务管理带来很多ITIL的认知,今天看IT运营范畴变得很多了。面向IT运营管理的实践,ITIL延伸出来的IT服务管理只是其中一部分,还有运营管理、性能管理、监控管理、分析管理等等。

☆ 第二: 扩展上层的实践和工具部分

同时给出一个从理念—工程与方法—过程—实践—工具的转换路径图。这样让我们更能清晰的看到DevOps的整体框架和落地实践及工具的关系。

今天看DevOps整体框架,其实也是一连串工程实践组合,包括敏捷工程、持续交付和IT运营管理及其精益实践等等。在过去IT组织中,或多或少都有敏捷管理和IT运营管理的实践,但IT的效率依然不高,为什么?今天似乎在持续交付中可以找到答案——IT如何成为业务的核心竞争力。

DevOps与ITIL的对比融合

DevOps跟ITIL对比,其实两个不属于同一个范畴,DevOps是属于IT全局的,ITIL是属于运维这块的,IT服务管理的,其实聚焦的领域不一样,但是还是有必要做一个对比。

因为我觉得在运维的行业,我觉得还是要把这两个理念做一个清晰的划分,比如说今天讲的以DevOps整个理念做平台,到底以ITIL做这个平台有什么样的不同。这里面是做一个对比。

首先ITIL是面向管理的过程,以这个目标规范优先,DevOps是面向IT运营过程,是执行的能力跟自动化,ITIL是离线任务管理为主要特征,而DevOps是以在线服务的。

可以看这里面有关键的作用力,我自己的理解把云计算、上层的框架模式拆分出来之后你会发现越接近上层应用,其实ITIL对它的作用力越来越小。

比如说之前大梁给我的数据,他的部门两个星期发布9000次,这个不可能针对每一次的发布建立强流程,这样流程太多带来成本非常高,达不到那种的效率。

我们在底下可以看到,在底层基础设施这块的,硬件基础能力还没有达到软件定义这种SDX化,它的作用力依然存在的,但是未来随着软件定义化的能力越来越强,这波浪潮也会改变。NetDevOps的兴起就是一个极好的例子。

DevOps自动化与ITIL规范之间的融合

DevOps可以看到在线服务管理里面,可以兼顾质量效率和成本规划,上图就是DevOps自动化与ITIL怎么融合,极力避免形成OA流程在IT部门的应用。这是按照优维的实践,在传统的行业做交付的过程中我们的产品怎么跟ITIL流程思想对接得出来的模式:

☆第一种模式:申请ITIL流程的时候可以直接调动DevOps的工具

典型的特征,比如说第一种在线服务开通流程,我要把我的防火墙开通了,这时候申请一个表单,审核通过了立马调用DevOps的工具执行。

但以前是离线的IT服务目录,我提一个表单、需求单,这个需求单审核通过同意之后,方案管理人员再跑去设备去开通,今天不一样,让流程变成立即可以执行的模式。

今天举例:资源申请流程,在CMDB整个资源申请里,这是国信证券的典型案例,比如说以前资源申请,我从库房拿一个设备,这个设备拿出来我要分配网络重组,以前是各个角色分配完了填写回复,今天不是这样的,把这个流程在线化,所有的资源通过CMDB资源层拿出来直接在表单里执行。

☆ 第二种模式:重大变更的流程

这个流程在华南很大的银行总结出来的案例,我们把所有的变更流程、审批流程做完之后,立马启动执行流,对于高稳定性服务保障流程非常的重要。

比如说对于银行基础设施的网络等等非常重要的,这里有一个问题,这个流程我在审批的时候是A方案,到审核之后方案有可能会被人为改变,怎么办?这种情形有改进的措施,我们把DevOps调度流作为审批流方案一部分,审批通过了这个流程可以去进行执行,这个保证了流程审批完了以后和在线的流程是一致的。

☆第三种模式:敏捷发布的流程,或者是DevOps变更的流程

因为今天很多的流程不再依赖ITIL完成的,比如说敏捷的发布流程JIRA管理,这是一个新的研发管理工具,不可能再回到ITIL提一个发布单,这里面我总结的是红绿灯机制。当我进入到某一个环节,比如说测试环节不符合的时候,我看到基于什么样的状态?如果通过了就开始的执行。

今天讲的DevOps,还可以从另一个维度看,叫软件研发的模式去看。我们经历了几种模式的变化,第一种是waterfall的模式,比如说研发、测试、运维间彼此是割裂的,独立的,中间有一个墙存在的,这里面有严格的输入输出在进行传递。

往下面走就是敏捷研发的模式,这里面讲的TDD的测试研发,在每一次的版本可以做很多的小迭代,比如说今天我们做easyops平台,我们规定两个星期出一个小版本,这两个星期出一个小版本的时候,内部还经历一个小迭代,内部很多的小迭代做这个事情。

但是这里面依然有问题,研发跟测试是一体化的,测试驱动研发,这块运维、operation还是被隔离在外了,但是随着新的业务形态出现后,比如说互联网的模式出现了之后,要强调端到端能力的整合。

DevOps软件研发模式就出现了,在和客户交流的时候,不断的触发思考一个点,实施了敏捷和IT服务管理,为什么IT依然看成成本中心而不是业务的核心竞争力,为什么还是对业务需求响应很慢?在前面讲的持续交付就是来解决这个问题的。

可以看在几种研发模式中,比如说这个Develop以前测试的时候占的70%,详细的设计占比重越来越大,但是到小迭代、小设计的时候Design工作变得越来越小,研发居多了,再往下看测试的工作量变得越来越少,变成自动化的工具。这是我们总结的数据,可以看到随着研发模式的变化,各个角色在里面承担了工作量的配比也在发生变化,研发越来越重要,很多工作也前置到研发阶段。

Post Author: admin

发表评论

电子邮件地址不会被公开。 必填项已用*标注