团队无线路由器哪个品牌好

让运维参与DevOpsIBM限量版作者:DennisNilsDrogseth和SudhakarV.
Chellam让运维参与DevOpsForDummies,IBM限量版出版商:JohnWiley&Sons,Inc.
111RiverSt.
Hoboken,NJ07030-5774www.
wiley.
comCopyright2018byJohnWiley&Sons,Inc.
未经出版商事先书面许可,不得以电子、机械、复印、录制、扫描等任何形式或任何方式将本出版物的任一部分复制、存储到检索系统或者传送,但1976年《美国版权法》第107条或108条规定的除外.
出版商的许可申请可发送至JohnWiley&Sons,Inc.
许可部门,地址:111RiverStreet,Hoboken,NJ;邮编:07030;电话:(201)748‐6011;传真:(201)748‐6008;网址http://www.
wiley.
com/go/permissions.
商标:Wiley、ForDummies、DummiesMan标识、TheDummiesWay、Dummies.
com、MakingEverythingEasier以及相关商业外观是JohnWiley&Sons,Inc.
和/或其位于美国和其他国家或地区的关联公司的商标或注册商标.
未经书面许可,不得使用.
IBM和IBM标识是InternationalBusinessMachinesCorporation的注册商标.
所有其他商标均为各所有者的财产.
JohnWiley&Sons,Inc.
与本书中提到的任何产品或供应商无关.
责任限制/免责声明:出版商和作者不担保本作品内容准确、完整,不作任何担保,包括但不仅限于特定用途的适用性,特此声明.
销售或宣传材料不构成或扩展任何保证.
本书中的建议和策略并不适用于所有情况.
在本书的销售过程中,出版方不提供法律、会计或其他专业服务,请周知.
如果需要专业帮助,可向具有相关资质的专业人员寻求帮助.
出版方和作者均不对因本书而起的损失负责.
本书中所引用的组织或网站仅作为附加信息的来源,并不表示作者或出版商认可该组织或网站所提供的信息或建议.
此外,读者应注意,在本书撰写后至被阅读前的这段时间,书中列出的互联网站可能已变更或消失.
有关我们其他产品和服务的信息或者如何为贵公司或组织创建一本自定义的"傻瓜系列"书籍,请联系我们的美国业务开发部.
电话:877-409-4177,邮箱:info@dummies.
biz,或者访问www.
wiley.
com/go/custompub.
有关为产品或服务购买傻瓜书品牌使用许可的详细信息,请联系:BrandedRights&Licenses@Wiley.
com.
ISBN:978-1-119-52346-8(pbk);ISBN:978-1-119-52348-2(ebk)美国印制10987654321出版商致谢感谢以下人员为将本书推向市场提供大力帮助和支持:项目编辑:CarrieA.
Burcheld编辑部经理:RevMengle策划编辑:SteveHayes业务开发代表:SueBlessing制作编辑:AntonySami导言1导言"让运维参与DevOps"对于不同的读者可能有着不同的认识.
对于关注于"非运维"模式的某些读者而言,可能觉得这是多此一举,毫无必要.
而对另一些读者,尤其是运维领域的人员而言,本书可能成为他们迫切需要的好帮手.
对于那些有着更广泛的需求,致力于实现IT与业务部门步调一致的读者而言,本书可能让他们看到了实现目标的希望.
本书旨在满足上述全部三类读者的需求,尽管第三类读者会认为本书对其帮助最大.
DevOps概念的起源可追溯到高效IT服务管理和服务交付的奠基阶段.
然而在当今时代,云计算、微服务和容器开始唱主角,而主要采用移动平台的服务使用者群体表现得越来越没有耐心,这些因素导致DevOps演变成充满创新和争议的舞台.
敏捷计算和持续交付的概念对DevOps思想的兴起起到了巨大的推动作用,现在,流程执行速度和动态相关性已经达到了十年前无法想象的程度.
此外,数字化转型的出现开始慢慢地重新定义对IT组织进行建模和评估的方式,在这种IT转型中,不断发展演变的DevOps方法发挥着关键作用.
随着越来越多的IT组织开始将IT基础架构库(ITIL)概念、非中断式变更管理流程与Scrum中固有的更为流畅敏捷的方法结合起来,应用于更为激进的DevOps计划之中,导致最佳实践方法和流程也随之发生变化.
最后,IT性能以及变更和容量管理技术的变化,也起到了一定的积极推动作用—提高了动态预测和自动化水平,并且借助更具吸引力的基于角色的方法,提高了数据可视化与数据共享程度.
认识到上述所有问题,以及拨开营销宣传和技术乱象的云雾后,我们就会发现,其实核心要务就是让运维参与DevOps,以及更广泛地开展有效的DevOps宣传.
2让运维参与DevOpsForDummies,IBM限量版本书简介《傻瓜系列之让运维参与DevOps》IBM限量版旨在深入探索技术趋势、流程和最佳实践的组合,尤其是影响整体运维和DevOps的IT组织架构和职能角色的变化.
我们希望本书能够帮助您清晰地了解如何优化从应用程序/基础架构行为以及相关业务成果中获得的运维洞察,并帮助您拨开营销宣传的迷雾,了解IT组织的真实情况.
更重要的是,本书提供了具体建议,帮助提升运维职能在DevOps方法中的作用,令DevOps能给运维和开发工作以及IT所服务的业务职能带来裨益.
本书中的图标全文中使用以下图标指出重要信息:"提示"用于指出DevOps中的最佳实践或者有助于节省时间和成本的方法.
这些图标指出应当注意的内容.
例如,该图标指示的信息说明如何从运维角度或更普遍的角度避免DevOps中的常见错误.
该图标强调必须牢记的重要信息.
该图标表示此处的信息对于学习DevOps的基础知识并非必要,但您可能会对这些信息感兴趣.
有许多DevOps用例可帮助您将DevOps应用于现实场景之中.
该图标指出来自实施DevOps的企业的真实用例或直接评价.
第1章让运维重回舞台中央3让运维重回舞台中央IT运维的角色一直在变.
但它是如何变化的这通常是个见仁见智的问题.
当然,这种变化肯定和独特的业务与IT组织环境密不可分.
本章将从各种角度研究IT运维的变化方式,探索每种角色在让运维参与DevOps的过程中所发挥的作用.
您可能会觉得本章的内容不太好理解,但这些观点不仅为本书其余部分奠定了基础,而且还能帮助各种职务的人员参与到与运维相关的计划之中,包括高管级IT管理人员、中级IT管理人员或资深的IT专业人员等.
了解数字化转型对IT运维和DevOps的影响数字化转型的定义是通过投资于数字化服务,优化业务绩效和组织效率.
当然,长久以来,企业和其他组织机构一直都在依靠有效的IT服务支持日常工作场所功能以及某些业务拓展工作.
但数字化转型则更进一第1章本章概要了解数字化转型对IT运维和DevOps的影响探索运维管理的各种角色4让运维参与DevOpsForDummies,IBM限量版步,以更具创造性的方式实现业务和IT成果.
数字化转型不仅在于提高业务效率,还包括建立全新业务模式,甚至逐步创造全新业务,在这方面,互联网创新企业的总体战果便是最直接的证明.
超过75%的数字化转型计划中都包含对DevOps或敏捷计算的支持,大多数人都认为这些方法对实现更广泛的数字化转型计划非常重要或至关重要.
运维转型是数字化转型的公认基础.
运维转型旨在优化IT绩效,更有效地满足业务或组织需求,或实现预期成果.
运维不仅在纠正常见错误方面发挥核心作用,还在整合与协调企业计划、确保整个IT职能部门保持正轨方面发挥关键作用.
为此,运维组织需投入资源和资金,一方面增强流程可视性,一方面部署先进技术,例如更高水平的自动化技术以及更为动态的多用途服务建模功能,当然,最重要的是为整个运维和IT组织部署高级分析功能.
大多数情况下,运维转型比数字化转型更长久,这是件好事,也在我们的意料之中.
数字化转型完全依赖于一定程度的有效运维转型,包括有效的DevOps(毕竟,如果人们无法及时获得所需的服务,又何谈"转型"呢).
业务领导越来越希望IT领导(包括IT高管和专业人员)帮助他们做出创造性的业务决策.
鉴于运维转型可为DevOps和转型计划提供更广泛的支持,因此,在实施运维转型时需考虑以下几点:打破条块分割,携手开展合作:这是运维转型的核心,通常需要关注流程、技术和组织变化.
我们可以就这个主题另外编写一本傻瓜书,而本书的大部分内容则在DevOps上下文中探讨这一需求.
第1章让运维重回舞台中央5在打破组织条块分割以及处理各自为政的工具方面,美国的一家中层医疗保健服务提供商谈了自己的体会:"我们企业中各个职能部门所使用的工具基本属于'各扫门前雪'的性质,因此流程呈现碎片化.
服务器团队不与网络团队沟通,网络团队也不与存储团队交流.
我们的人员没有接受过共享信息方面的培训.
因此,就连部署临时修补程序也成了难题,更不用说有效解决持续或反复出现的问题了.
"更动态:运维组织需要更快响应业务需求,同时消化吸收用于满足这些需求的新技术.
更透明:在数字时代,IT作为一个整体,需要更加透明,在运营模式上向业务部门靠拢.
运维职能可以并且应当起到核心作用,为实现这种IT透明度提供支持,帮助IT效率更上一层楼,并记录成功经验,同时就IT服务的使用方式和使用原因提供更深刻的洞察.
更具技术意识:运维组织不仅需要增强流程可视性,还需要部署先进技术,例如更高水平的自动化技术以及更为动态的多用途服务建模功能,当然,最重要的是为整个运维和IT组织部署高级分析功能.
高级运维分析,也就是EMA所说的"高级IT分析"(AIA),逐渐成为希望提高工作主动性的IT组织的秘密武器—不满足于被动响应事件,还要能够提前洞见并解决问题.
更具服务意识:有效的运维并非只是管好各个孤立的组件,而是要深入理解云环境和传统环境中各种应用程序服务的相互依赖性.
一家总部位于美国的国际游戏公司试图消除"想当然"的习惯:"我们必须消除'想当然'的习惯,不能光凭一通电话,就开始猜想问题出在哪里—到底是断电故障,还是网络问题,亦或服务提供商的差错,每个人都靠各自的猜测行事,结果是四面出击,到处扑空.
"6让运维参与DevOpsForDummies,IBM限量版更具业务意识:要想提高IT专业人员的业务意识,一开始会令他们感到手足无措,甚至有点置身惊涛骇浪之中的感觉.
但是,如果IT知道他们与业务不再是各自为政的关系,而是业务中不可分割的组成部分,对于推进DevOps以及整体数字化转型而言都是至关重要的.
探索IT运维的各种角色IT运维的角色因业务和组织环境而异,这是不争的事实.
某些情况下,由于企业重点投资于公共云以及以业务线(LoB)为中心的模式,使得IT运维逐渐丧失重要性,成为拖后腿的"累赘".
而在其他一些环境中,IT运维则占据较为核心的领导地位,他们负责协调所有IT组织的技术和流程效率,这些组织不仅包括以业务线为核心的团队,还逐渐包括开发和安全团队.
尽管在让运维参与DevOps这件事上,IT运维可通过扮演更加强势的角色来发挥最大价值,但本书旨在为所有级别的运维团队提供指导.
核心IT运维,或以业务线为中心的运维核心IT运维以及由业务线驱动的运维均可成为"让运维参与DevOps"计划的战略核心.
运维能否参与DevOps,很大程度上取决于自身规模、投资水平以及与其他团队的协同效应,这既包括与应用程序开发团队和应用程序所有者团队合作,也涉及到与IT服务管理(ITSM)团队的有效整合,唯有此,才能确保所有团队在应用程序问题的解决流程、监管机制以及洞察分享方面都充分发挥自己的价值.
对于选择让核心IT运维还是由业务线驱动的运维发挥领导作用,应考虑以下几点:必须负责管理整个应用程序/基础架构组合,这是关键因素.
运维团队应与应用程序开发团队、应用程序所有者团队以及应用程序管理团队紧密合作.
所有这些团队与业务线的关系都越来越紧第1章让运维重回舞台中央7密.
但是,单独考察应用程序性能和基础架构性能似乎是不可能的,尤其是在新版本发布之前需要动态实时地了解复杂基础架构依赖关系的云时代.
此外,当今大多数IT环境的组成极为复杂,既有大笔投资部署的内部原有基础架构、虚拟化基础架构以及公共云中不断增加的相关组件,又有互联网和越来越多的第三方服务提供商.
因此,无论是核心IT运维团队还是以业务线为中心的运维团队,都必须在整个混合IT的大背景下负责管理完整的基础架构组合.
需要同时与业务利益相关方和IT高管层建立密切合作关系.
DevOps的作用不仅仅是在将应用程序和系统部署到生产环境的过程中解决问题.
我们越来越多地看到一些既定趋势,比如数字化转型,是需要IT高管与运维团队、开发团队以及业务利益相关方通力合作.
虽然以业务线为中心的运维团队可能更贴近业务利益相关方,但核心IT运维团队则更靠近IT高管层,因此更有可能参与总体IT治理工作.
但二者缺一不可,最终对于优化运维的DevOps工作都具有不可或缺性.
为实现增长做好准备也是加分项.
要优化运维在DevOps中发挥的作用,通常需要投资部署先进技术(我们将在第3章详细讨论).
例如,投资于大数据和高级IT分析、更先进的服务建模方法,以及高级工作流程和自动化技术,以便支持与业务线相关的运维以及所有IT运维.
此外,还需要投资建立最佳实践,以及改进可在运维与开发团队间共享的流程.
先进的技术可促成具备以下特点的全新工作方式:体现社交化性质,所有参与方达成共识,并且至少在一定程度上形成正式文档.
为迁移到云端做好准备也是关键.
DevOps逐渐转变为以云为中心.
事实证明,涵盖所有IT领域的统一云优化方法通常要比个案化的特殊方法有效得多,安全风险也更低.
另一方面,以业务线为中心的运维团队通常起到引领作用,为其他IT团队开辟前进道路.
8让运维参与DevOpsForDummies,IBM限量版因此,DevOps领导层可能来自以业务线为中心的运维团队和/或核心IT运维团队.
以下核对表可帮助您根据自身IT组织的具体情况,做出合理的选择.
运维和应用程序管理高效的运维团队借助更先进的管理软件和分析能力,逐步在应用程序性能与基础架构性能的可视性之间架起桥梁.
鉴于和云计算相关的环境复杂又多样,因此这种能力变得愈发重要.
这令IT运维团队的工作范围延伸到通常属于以业务线为中心的团队传统领地的应用程序开发工作,以及通常属于集中化团队传统领地的应用程序支持工作,这对于DevOps以及总体应用程序性能管理都是至关重要的.
实现数字化运维并不只是在于基础架构,而是应当动态洞悉与完整的IT基础架构相互依赖关系有关的变化、异常和关键事务延迟.
运维和ITSM运维团队的各种定义均适用,但通常至少需要在某种程度上与ITSM团队实现整合.
从组织角度而言,运维团队比任何其他团队都更有可能负责ITSM(排名第二的应该是IT高管层).
ITSM团队和运维人员之间的沟通应当是双向的,因为只有相关的事故和事件是由运维团队通报的,而工作流程、治理和流程需求通常都经由ITSM传达.
借助运维专业知识和领导能力以及高级分析等技术的支持,ITSM团队可以发挥诸多作用,例如支持各种孤岛式系统的性能和变更管理,开展容量优化、端点管理以及产品组合规划,以及最为重要的工作—为DevOps提供支持.
第1章让运维重回舞台中央9作为运维的一部分,ITSM团队通常起到所有IT职能(包括开发)的沟通枢纽作用,而且这一趋势近年来呈现飞速发展的态势.
最后,ITSM逐渐帮助运维成为所有IT职能的治理、项目管理和工作流程控制的中心—所有这些因素都直接推动运维参与DevOps.
安全与运维(SecOps)鉴于企业迫切需要将安全能力整合到绩效管理、变更管理和审计相关活动中,因此,安全运维(SecOps)以及反欺诈/合规部门需要更加积极地与IT部门合作.
重视安全运维能给企业带来诸多裨益,包括最大程度减少关键IT服务的中断、提高IT运维效率,以及在某些情况下显著提高成本效率.
IT运维团队几乎在所有的SecOps计划中都扮演着重要角色,尤其是当IT运维团队整合了ITSM团队时.
实际上,只有当ITSM参与协调工作流程与对话时,SecOps才算是最成功的.
更完善的流程和更高的效率当ITSM与运维团队开展合作时,能够创造更完善的流程,实现更高的效率,就像两家不同类型的企业合作一样,比如一家全球互联网零售企业和一家实体零售店合作:"首先,我们借助单一平台整合了整个运维领域的变更、事件和问题管理流程.
我们还更深入地了解了变更对服务性能及可用性的影响,因此能够更快地找到变更所导致的许多问题的根源,并开始以更为一致的方式自动修复这些问题.
"10让运维参与DevOpsForDummies,IBM限量版SecOps通过以下方式支持DevOps:最大程度降低从开发到运维的交接过程中的风险创建出色的工作流程,支持开发团队和DevOps提高与安全/合规相关的效率就安全需求对DevOps进行培训通过确保开发环境合规与安全,为开发工作提供直接支持通过确保环境安全,支持Q/A测试工作尽量减少开发人员解决与安全相关的生产问题的时间第2章将DevOps与持续交付联系起来11将DevOps与持续交付联系起来术语DevOps、持续交付和敏捷开发经常联系在一起,这是有充分理由的.
它们结合在一起,有助于加速在生产环境中发布和更新应用程序,既不会造成业务运行中断,又可最大程度提高整个IT环境的运维效率.
然而,尽管某些IT人员认为敏捷方法等同于DevOps,并且二者均与持续交付有关,但这几个术语至少有三点不同之处:DevOps:DevOps的历史最悠久.
从某种意义上说,DevOps并不是什么新生事物.
将应用程序从开发环境成功交接给生产环境的历史和IT本身一样悠久.
高效DevOps的核心理念在于实现开发环境与生产环境之间的顺利交接,同时确保不影响应用程序性能.
这需要共享流程以及共同的观点和洞察.
"DevOps"既适用于开发周期较长的传统应用程序,也适用于由多个小型组件构成、因此更有可能开展持续交付的新型云应用程序.
第2章本章概要探讨DevOps应用程序组合在整个应用程序生命周期中使用工具认识DEM的强大威力12让运维参与DevOpsForDummies,IBM限量版敏捷软件开发:敏捷方法旨在利用适应力强大的规划和持续改进功能,帮助加速推出关键应用程序,实现预期的业务成果.
敏捷方法能够最大程度减少文档记录以及较为僵化的传统项目管理流程,支持更为灵活、能够感知变更、以对话为中心的工作方式.
敏捷方法也不是新事物,其历史可以追溯到几十年前.
但敏捷方法在过去十年间经历了迅猛发展.
持续交付:持续交付是以团队为中心的软件开发方法,旨在缩短新版本发布到生产环境的周期.
持续交付可能意味着每天以最短时间间隔对单个应用程序进行多次迭代.
完整的应用程序组合当然,运维团队所管理的许多应用程序并非主要来自开发团队.
近期开展的一项调研表明,在各种规模的企业中,平均约有40%的IT应用程序是由内部开发的(无论企业规模如何,都在这个比例上下浮动).
换句话说,从应用程序的角度看,运维团队不得不担心剩下的60%应用程序不一定与DevOps相关.
毋庸置疑,这些平均百分比可能会因具体情况而存在很大差异,但加速推进内部开发的应用程序的作用乃是大势所趋,这通常也是实现业务成果的最关键因素.
正如第三方应用程序在选择面和设计上呈现出多样化一样,内部开发的解决方案也可采用多种形式.
例如,DevOps应用程序组合可能包含:传统Web应用程序针对移动平台优化的Web应用程序针对多种终端优化的全渠道应用程序Web服务应用程序云原生应用程序(针对在虚拟化环境中运行而进行优化)云原生应用程序(微服务和容器)第2章将DevOps与持续交付联系起来13包含多个组件的API驱动型应用程序定制的商业应用程序,例如用于ERP的应用程序富媒体应用程序和流视频Java、VPN、基础架构即服务(IaaS)、平台即服务(PaaS)、软件即服务(SaaS)和无线传输等潜在的DevOps环境都具有独特的需求和相互依赖关系,因此运维团队必须为支持各类应用程序团队和需求做好准备.
他们必须为由传统应用程序/基础架构和更敏捷的应用程序类型构成的混合环境(业界有时称之为"双模IT",详见第5章)提供前所未有的大力支持.
内部开发的应用程序的优先级因具体情况而异,但它们还是具备一些最常见的共同目标,包括:外部客户满意度:企业必须接触自己组织以外的大量客户,这包括合作伙伴、供应商、顾客以及最明显的客户—"购物者".
内部开发的应用程序通常借助创造性的设计来满足这些独特需求,从而在以下几个方面创造价值:业务竞争力客户维系力新产品开发业务转型(创新)内部客户满意度:企业和组织依赖于心情愉悦、工作高效的专业人员.
内部开发的应用程序可针对业务流程需求进行精细调整,从而在以下几个方面创造价值:工作场所效率员工队伍士气组织架构转型14让运维参与DevOpsForDummies,IBM限量版总之,内部开发的应用程序既能塑造外部业务环境或组织环境,又可以决定内部工作场所的复杂性和特点.
DevOps还包含人性化因素,因此了解并管理好这方面的价值对于运维和开发团队而言至关重要性—当然这方面的能力远远不止自动配置路由器或者了解服务器的CPU利用率.
数字化体验管理(DEM)在帮助开发和运维团队将人性化因素融入DevOps方面,可以起到关键的桥梁作用.
有关DEM的更多信息,请参阅"了解DEM日益重要的作用"章节.
敏捷方法如何实现敏捷您可能希望了解许多企业用于衡量代码开发工作的标准.
以下是一些统计数据:大约25%的企业每天平均多次交付新代码.
大约20%的企业每天交付一次新代码.
大约20%的企业每周多次交付新代码.
大约25%的企业每周、每两周、每月或在某些情况下每两个月交付一次新代码.
这些平均值当然只是平均值,无疑取决于受访对象.
与运维或ITSM团队相比,开发团队趋向于更频繁地审视日常代码交付情况,但最终的百分比并未受此影响.
另一方面,超过70%的IT组织为某些应用程序定义了快速通道.
这些快速通道应用程序和将ITSM团队融入DevOps一样重要,因为这些应用程序每天会持续更新多次,并且经常会绕过ITSM.
这也强调了构建重叠团队(详见第5章),以便在开发和运维团队之间直接进行简单交接的重要意义.
第2章将DevOps与持续交付联系起来15探索整个应用程序生命周期中使用的工具在整个应用程序生命周期中,通常会使用许多种工具和技术,而且通常有多个团队参与.
表2-1概述了运维和开发团队如何在DevOps流程的不同阶段协同工作.
表2-1整个应用程序生命周期中使用的工具阶段领导者参与者工具设计开发团队业务利益相关方运维团队应用程序生命周期管理需求管理建模项目管理(PM)开发开发团队运维团队业务利益相关方集成开发环境调试存储库错误扫描构建自动化DEM高级分析和成式故障与性能管理测试开发/QA团队运维团队业务利益相关方测试管理测试数据管理API测试集成测试(服务虚拟化)DEM高级分析和成式故障与性能管理(continued)16让运维参与DevOpsForDummies,IBM限量版阶段领导者参与者工具部署/发布开发团队运维团队业务利益相关方流程统筹配置管理软件发布自动化管理运维团队开发团队业务利益相关方运行手册自动化系统管理应用程序管理高级分析和成式故障与性能管理DEM服务台/故障凭单评估业务利益相关方开发团队运维团队服务级别管理DEM高级分析和成式故障与性能管理表2-1(continued)归功于和DEM相关的数据,运维团队有机会在设计和评估阶段发挥越来越大的作用,这也是"让运维参与DevOps"过程中出现的令人兴奋的趋势之一.
了解DEM日益重要的作用如果要问,哪种方法对于提高运维团队在支持DevOps方面的作用和价值最重要,那么答案毫无疑问是不断发展、高效而共享的DEM战略.
DEM采用统一的方法开展内部最终用户体验管理和外部客户体验管理,对于DevOps以及整个IT职能取得成功至关重要.
实际上,未来发展趋势表明,DEM在应用程序生命周期的所有阶段(包括应用程序设计阶段)都扮演着重要角色.
第2章将DevOps与持续交付联系起来17通过帮助各种IT团队开展研究、工作和咨询活动,DEM可实现以下价值,而且所有这些价值都反映DevOps的需求:业务影响:基于用户互动和业务成果监控和优化IT提供的业务服务性能:根据应用程序性能,监控并优化提供给最终使用者的业务服务变更管理/DevOps:验证变更的影响,包括迁移至云、推出新版本或发布变更所带来的影响设计:监控并优化应用程序设计和内容对面向客户和内部最终用户的业务服务的影响用户生产力:监控并优化最终用户与业务服务的互动,包括面向内部或外部客户服务的关键业务流程服务使用情况:监控关键应用程序服务的使用频率和结果,以便更深入地了解服务的价值和相关性通常情况下,DEM需要像DevOps一样开展团队合作.
高效的DEM团队通常能为运维团队在战略层面更为普遍地参与DevOps奠定最坚实的基础.
DEM的强大威力为了进一步强调DEM的诸多优点,我们摘录了美国一些热门行业中受访者的评论,用于证明其广泛的价值.
借助DEM提高主观能动性"实施DEM计划之前,公司IT部门基本采取被动应对的方法.
我们对于DEM没有具体的衡量指标,仅凭基本的了解—例如,衡量服务热线(continued)18让运维参与DevOpsForDummies,IBM限量版来电的问题解决率.
我们只有在用户投诉时才能发现问题,并因此经常陷于困境.
现在,我们建立试点,希望能在部署之前开展负载测试和基准评测.
这样,我们就能获得衡量指标,从而更好地了解产品在投入生产环境后会达到怎样的指标和性能.
"—一家总部位于美国的医疗耗材供应商借助DEM提高业务影响力"我们现在衡量的指标不再是简单的互联网访问率,而是完成'决定性'交易的数量,也就是签下的实际订单数,这涵盖了完整的客户体验:比如购物、结账及信用卡验证等.
我们希望首先衡量服务可用性,然后衡量性能,当然,在这过程中最终用户的实际体验始终是关注重点.
"—一家美国电子商务提供商通过DEM发现应用程序设计问题"有些问题可能你我一眼就能看到,但浏览网站的普通用户却不一定能够发现.
我们的应用程序开发人员可能会说:'纠正错误太简单了,任何人都能做到!
'而正是这些他们满不在乎的东西最终导致大量交易以失败告终.
"—一家总部位于美国的全球媒体集团通过DEM确保开发和运维团队步调一致"我们的团队通过初级分类来评估应用程序和业务影响.
如果需要,我们还将与基础架构和应用程序团队共同开展更深入的评估,并将评估结果酌情上报给治理团队,以帮助事件管理部门向关键基础架构和应用程序专家拨打技术求助电话.
除其他方式的沟通外,我还通过多种不同的方法对数据进行每天和每月趋势分析,从而更清晰地揭示问题,例如,反常的高延迟情况.
换句话说,我力争确保运维和开发团队不会游离于数字化体验管理指标之外.
"—一家北美大型金融机构的服务交付重叠团队(continued)第2章将DevOps与持续交付联系起来19无论是运维团队还是开发团队,许多IT组织的实际情况并不像某些示例中展现的那样乐观.
例如:开发团队通常只有在收到帮助台故障凭单和用户投诉后才了解到实际应用程序体验很糟糕.
即使在发布前测试完成后,许多开发团队仍继续将存在DEM故障迹象的应用程序部署到生产环境.
支持DEM的关键高级分析工具经常无法使用,即使能够使用,也经常无法在运维和开发团队之间共享.
在某些组织中,开发团队仍然孤立、封闭地开展工作,以至于运维工程师不得不偷偷监视开发环境,只是为了提前了解开发团队将带来怎样的应用程序.
即使DEM计划已经实施,但如果没有适当的技术,根源分析等基本挑战仍可能继续普遍存在.
运维与开发团队以及IT与业务部门之间各个层面的沟通交流对于DEM取得成功至关重要.
但这要求大多数IT组织部署先进技术,改变组织文化和业务流程.
了解真正的最终用户或客户体验不仅是技术问题,还涉及到每个具体个人.
每个人都各不相同,因此,如果在提供数字化体验时停留在大众化层面,无疑会以失败告终.
鉴于此,企业需要通过持续开展大量对话来了解用户的真正需求,不仅要参考业务分析师的意见,还要包括分析驱动的DEM数据、与ITSM团队的对话内容,以及社交媒体中最终用户和客户的意见.
因此,建议企业聚焦以下方面:优良的技术(见第3章)良好的组织模式(见第4章)前瞻性的趋势预测,用于帮助满足未来需求(见第5章)20让运维参与DevOpsForDummies,IBM限量版第3章了解技术如何发挥独特的作用21了解技术如何发挥独特的作用技术本身并不具备实施运维转型的能力,更不用说转变整个IT职能了.
但是,如果没有出色技术的帮助,"让运维参与DevOps"可能会以失败告终.
庆幸的是,当开发团队借助各类新工具享受应用程序创建、修改和交付等方面的革命性体验时,运维团队也开始通过几个关键领域的技术进步,品尝到类似的甜头.
提高DevOps水平的三项核心技术如果运维团队能够发挥更为积极主动的战略作用,那么,企业在自动化、服务建模和分析等方面的投资将产生不可限量的回报.
但如果企业不在这些新领域投资,那么,碎片化的技术将继续加剧碎片化的工作方式,新应用程序的发布会更频繁地冲击生产环境基础架构,最终演变成一波接一波的故障潮.
第3章本章概要利用三项核心技术加速实施DevOps借助整合的事件管理功能,统一各种洞察22让运维参与DevOpsForDummies,IBM限量版自动化技术在面向DevOps的三项统一技术中,自动化是当今大多数DevOps计划中应用最充分的一种技术.
因此,我们从自动化技术开始谈起.
开发和运维团队都依赖于自动化工具,无论是用于自身团队的工作,还是用于两个团队之间的工作交接.
平均而言,运维和开发团队估计大约有30%-50%的DevOps任务由自动化技术提供支持;在将来,随着任务执行速度和内容最新程度变得空前重要,这种趋势只会有增无减.
DevOps中较为普遍的自动化类型包括:高级工作流程自动化:工作流程用于定义和加速执行IT职能领域中的各种流程.
通过实施工作流程,您就可以规定谁负责解决问题,以及如何将问题与有关非预期事务行为的事件、警报、故障凭单或分析洞察等关联起来.
这样,工作流程就能够促进协作,对修复问题以及管理变更起到至关重要的作用,防止将存在缺陷的新版本引入到生产环境基础架构中.
为此,工作流程应在运维团队、ITSM团队和开发团队之间起到桥梁纽带作用.
运行手册或IT流程自动化(ITPA):运行手册自动化的基础是您了解在关键情况下如何有效处理性能、可用性和变更管理问题.
传统上,运行手册记录的都是例行规程,但是,如果能通过分析为运行手册提供更多洞察,并通过工作流程以及其他类型的自动化能力加速运行手册运行,运行手册就会变得更明确、更精准,还肯定能更迅速地运行.
例如,运行手册或ITPA功能可以成为集成其他自动化例程(如配置自动化或自动诊断)的中心.
新应用程序发行版配置自动化:这是实现高效DevOps的核心基础,需要您始终站在同一角度审视开发和运维团队的应用程序使用情况.
但速度并不是这项工作的唯一目标.
应用程序蓝图,甚至API驱动的合并,在开发环境中都能正常工作,但当它们触及第3章了解技术如何发挥独特的作用23到真实世界中的各种相互依赖关系时(包括不同地理区域的数据中心、电信和终端之间的依赖关系),可能会迅速暴露出各种缺陷.
这时,就需要DEM、揭示整个应用程序/基础架构组合的运维洞察的分析以及服务建模等技术发挥作用.
服务建模正如上世纪90年代早期到中期出现的先进拓扑掀起了网络管理热潮一样,以内容最新性和动态相关性为标准建立完整应用程序/基础架构组合方面的进步,也在开始改变DevOps规则.
尽管许多服务建模系统距离云环境以及以API为中心、与云相关的应用程序环境的动态性质尚存差距,但也无法改变这一事实.
但请不要灰心.
服务建模规则也在发生变化,并且是以令人惊讶的方式发生着显著变化—同时支持持续发现和持续可用性.
实际上,服务建模存在多种不同的形式和风格,当研究在哪些领域实施服务建模时,可考虑以下几个选项:配置管理数据库或配置管理系统(CMDB或CMS):CMDB和CMS用于提供单一事实来源.
然而,由于数据很难真正做到完整或最新,所以"单一事实来源"有点名不副实.
规划CMDB时不仅仅要关注数据,还应关注相关性.
虽然CMDB可以提供非常有价值的背景信息,但仍必须确定并投资建立更为动态的应用程序/基础架构相互依赖关系版本,以保持CMDB或CMS最新;或者,在某些情况下,需要使用更为动态的建模系统取代传统的CMDB.
但无论在哪种情况下,建模都能提供有价值的背景洞察,比如具体服务所在位置以及如何受到变更的影响.
用于变更和性能管理的应用程序发现与依赖关系映射(ADDM):许多最初的ADDM创新者都将主要精力集中在资产和变更管理上面,不太关心性能管理.
这些解决方案经过不断发展演变,24让运维参与DevOpsForDummies,IBM限量版开始支持更复杂、更动态的混合云需求.
但只有少数解决方案能够提供有关事务性能的实时洞察.
用于变更和性能管理的ADDM主要来自于提供应用程序性能管理(APM)解决方案的新型供应商,这些ADDM经过优化,能够实时或接近实时地监控应用程序/基础架构的相互依赖关系.
嵌入高级IT分析(AIA)的ADDM:目前市场上新兴的最大创新之源或许是高级IT分析与更为动态的服务建模之间的"联姻".
动态服务建模帮助您了解各项服务的状况及其关联方式,而高级IT分析则通过提供传统监控方法无法企及的独特深入洞察,帮助您了解影响DevOps表现的各种相关因素.
将两者动态结合起来虽然有一定难度,但这能够成为开发和运维团队在DevOps实践中取得成功的标志.
在投资于服务建模或任何先进技术时,请考虑您自己的环境和独特的DevOps需求.
贵公司的核心资产可能是大型机,也可能相反,开发团队已将工作重心转向了微服务.
或者,需要同时为大型机和微服务提供支持.
因为任何IT环境都有其各自的特点,所以这个问题没有固定答案.
您首先要明确自己的需求,然后对各种选项进行评估.
高级IT分析(AIA)不断发展的IT分析市场是科技行业中最令人兴奋的领域之一.
之所以令人兴奋,是因为供应商不断推出大量IT分析创新成果,为数据共享和联合决策提供有力支持,令运维团队、开发团队乃至整个IT职能以及业务利益相关方都能获益.
我们认为AIA是非常出色的统一工具.
对于通过AIA实现运维与开发团队的统一,一家跨国互联网娱乐服务提供商的看法是:"转向高级分析使我们能够统一应用程序开发和运维团队,从而获得一致的洞察,更有效地共享信息.
过去,我们只能主动解第3章了解技术如何发挥独特的作用25决3%的问题.
现在这个比例已上升到88%.
平均修复时间从原来的几小时缩短到12分钟,而且已经能够自动解决已知问题.
"AIA和DevOpsAIA能够以多种方式满足DevOps需求.
这些用例可以证明,让运维参与DevOps后,通过共享数据和共享洞察可以结出最丰硕的成果.
用例包括:由生产团队向开发团队快速提供反馈,从而优化应用程序性能尽量减少开发人员用于解决性能问题的时间一旦就应用程序就绪情况达成共识,即可在开发与运维团队之间实现平稳交接在部署之前运用有关应用程序/基础架构问题的共享洞察,直接为开发团队提供支持,这也可以帮助运维团队更好地为即将部署的应用程序做好准备为开发团队提供反馈,帮助优化应用程序设计这些数据通过分析得出,借此已从Q/A测试或实际部署中获得DEM相关洞察.
数字化体验分析与开发和运维团队、IT高管以及业务利益相关方(如业务线高管或数字营销主管)都有关系.
一家欧洲金融服务公司表示,涉及范围远远超出基本监控的整体分析解决方案帮助企业显著提升了主动出击的能力.
借助AIA和DevOps,该企业能够更高效地管理事件流,将一系列事件汇聚到单一界面中,从而在推出新版本或执行其他变更时能够更清晰地掌控全局.
现在,该金融服务机构能够提前发现不良苗头,真正做到防患于未然.
26让运维参与DevOpsForDummies,IBM限量版找到适合自己的AIAAIA是业界新的创新领域,而非传统意义上具有严格界线的市场.
但对于那些希望进行明智投资的人来说,它还是有一些共同标准可循.
如果只为IT投资大数据,或者只投资某些分析工具,往往无法实现期望的效果.
许多IT组织都创建了大型数据库用于搜索和分析功能,并没有为用例或相关性分配严格的优先顺序.
这种做法在过去已经对CMDB部署造成了灾难性后果,对于不断发展的AIA也将如此.
不具有严格相关性的大数据往往弊大于利.
为避免造成灾难性后果,请遵循以下提示:寻找通用用例.
涉及到DevOps时,这一点尤其重要.
这些用例可能包括性能和可用性管理、变更影响管理和变更感知,甚至包括与原有基础架构、大型机、云及混合环境的成本和性能相关的容量规划洞察.
实际上,相同的数据在不同的用例中往往具有不同的含义,因此,只有分析和优化洞察,才能使数据发挥应有的价值.
分析不同的指标可以发现异常情况并预测停运.
位于斯堪的纳维亚的一家金融服务企业通过使用AIA,在应用程序部署到生产环境的前三个月中将重大事故率大幅减少了85%.
利用多个数据源.
分析解决方案应当能够将整个应用程序/基础架构组合中种类繁多、数量巨大的数据汇集在一起.
借助通常与服务建模结合使用的分析解决方案,就能够全面了解应用程序/基础架构中的相互依赖关系.
数据类型可能包括事件数据、时间序列数据、日志、配置洞察和事务洞察,等等.
消化吸收,而非剥离排斥.
事实证明,许多AIA工具都与现有监控工具以及其他工具集进行集成.
集成度低的只有5-6%,高的则有50%或更高.
事实上,无论是开发团队还是运维专业人员,都相当排斥更换自己习惯使用甚至是职业基础的工具.
第3章了解技术如何发挥独特的作用27因此,对分析技术的投资应当提供通用的洞察和主动认知层,实现并促进新型协作与对话,而不是被员工视为让人讨厌的强行干预.
但这并不是说初始集成一旦开始便无法再回头,无法再为工具集整合奠定共同基础,这种做法通常会显著节省成本.
需要真正分析的并非只有大数据.
只进行数据搜索固然也不错.
但是,考虑到DevOps、敏捷方法和持续交付的动态性质,您需要采用以分析为中心的更加稳固的方法,这不仅有助于实时保持数据最新性,还能提前预测问题,防患于未然.
有时,可能需要开展假设情况分析,以预测应用程序的新版本变更会引发哪些问题,或者,可能需要开展规定性分析以获得具体行动建议.
但在这之前,首先必须精心设计方法,确保系统能够以有意义、相关而且可触发行动的方式,提醒您整个应用程序基础架构中的异常(反常)行为.
确定所需的覆盖范围.
就像服务建模一样,您可以将关注点集中在大型机、传统数据中心或者云和微服务上.
关键的业务应用程序甚至可以分布于所有这三个环境中.
如果分析投资只覆盖部分关注领域,则不会有太大的帮助.
应确保分析投资能够覆盖与DevOps相互依赖关系有关的所有方面.
分析工具需要采集众多不同来源的指标,以便发现异常情况.
投资于正确的团队.
AIA有助于促成全新工作方式.
但要开展进一步的优化工作,就需要了解哪些人应当从事以及如何从事"让运维参与DevOps"的工作.
欲知详情,请参阅第4章.
28让运维参与DevOpsForDummies,IBM限量版投资于高级事件管理AIA提供极具前瞻性的洞察,助您实现IT转型.
但是,IT组织仍需将通过分析和服务建模揭示的整合事件与作为最终中央通知和警报系统的其他来源结合起来.
从众多来源不断涌入的事件数据很快就会让IT人员不堪重负,造成IT工作停滞不前,不仅会导致员工之间相互推诿,还会引发长期得不到解决的问题.
有效的事件管理解决方案拥有以下共同点:1.
减少"噪声".
发生任何问题或中断时,包括应用程序监控工具、基础架构监控工具、事务分析工具以及社交媒体和分析工具在内的大量工具所捕获的故障或异常会产生大量事件"噪声".
您需要根据这些故障和异常对特定事件的影响,对它们进行关联和分组.
2.
动态分配适当的应用程序/基础架构背景信息.
这对于帮您找到正确的补救点以及适当的主题专家(SME)来指挥补救工作都是至关重要的.
3.
向适当的SME发出提醒.
有时候,分散在世界各地的专家团队需要处理不同时区内发生的问题.
在发生停运或问题时,找到适当的主题专家至关重要—他们最有可能运用适当的自动化和分析工具助您快速正确地解决问题.
虽然事件管理本身并不是什么新鲜事物,但却是至关重要的,因为如果不能减少"噪声",工作团队可能会因处理太多的故障凭单或事件而无法执行核心任务.
此外,动态关联的CMDB或CMS对于帮助您发现与变更、服务影响及SME所有权相关的问题也是非常有价值的.
第4章DevOps团队—谁是真正的领导者,为什么29DevOps团队—谁是真正的领导者,为什么事实上,DevOps团队正在IT行业不断发展.
其现有和未来的构成方式因历史、文化、技术、需求和IT策略而异.
因此,本章并不打算就如何创建DevOps团队提供"放之四海而皆准"的固定答案,而是研究在准备让运维参与DevOps时,DevOps团队建设计划中应当考虑的四个主要类别.
但最终决策取决于准备程度、领导能力以及企业意愿的最佳组合.
首先实现个小目标,然后朝着更宏大的愿景迈进,这才是行之有效的方法.
本章还将介绍运维团队的变化趋势,并就规模越来越小的DevOps叠加团队需要哪些信息提供洞察.
运维与开发团队开展合作当前,运维与开发团队间的合作无疑存在一些共同趋势.
但是,在运维团队朝着DevOps迈进时,首先应考虑本节中阐述的几个要点.
第4章本章概要探索运维与开发团队的合作趋势了解高效DevOps实践所需的领导能力探索DevOps团队的流程和最佳实践了解沟通需求30让运维参与DevOpsForDummies,IBM限量版多个团队还是单个团队虽然整合了运维与IT服务管理(ITSM)团队的组织建立了一致的核心能力,能够借助共享技术、通用流程和最佳实践来满足DevOps需求,因此可以实现非常高的价值,但并非所有应用程序都相同,而且组织通常需要采用不同的工具来管理由微服务和容器驱动的应用程序,以及基本上由API驱动的应用程序.
叠加团队日益增长的作用(详见第5章)也促使企业采用多团队方法.
虽然见仁见智,但我们推荐采用中心辐射式方法,对人员、技术以及明确定义的叠加团队进行持续的共同投资,从而满足各种应用程序的需求.
临时团队还是专门团队最近开展的调研表明,在建立临时还是专门DevOps团队这个问题上,受访IT人员的回答几乎平分秋色.
同样,我们的答案依然是二者兼顾—例如,建立专门的DevOps核心团队,辅以一些临时人员.
如果是这样,那么,专门团队在提高技能、改进流程和优化工具以及构建一致的最佳实践等方面具有明显优势.
DevOps还是其他称谓DevOps团队的称谓也是五花八门,并不总是叫做"DevOps",有时也称作应用程序管理/支持、基础架构服务、IT服务管理、IT架构、卓越中心及数字化体验管理等.
运维和开发团队可通过多种不同方式开展合作在一种场景中,开发团队在云端交付解决方案.
运维团队则根据开发团队的部署策略,了解应用程序组件的依赖关系.
运维团队还接收来自应用程序和其他来源的事件,他们借助运行手册和解决方案,解决遇到的各种问题.
开发和运维团队需要共同全面而深入地了解发生的事件并采取行动.
但是,不同的团队针对同一个事件可能会采取不同的行动.
第4章DevOps团队—谁是真正的领导者,为什么31例如,开发团队可能想要压制事件,但运维团队却不希望这样做.
如果运维和开发团队能借助工具,通过两种不同的方式来管理同一事件,效率便会得到提升.
那么,这对于"让运维参与DevOps"意味着什么呢切勿尝试为非通用的情况提供通用的答案.
每个IT组织都有自己的优势和劣势以及组织文化特征.
您是准备采用中心辐射型模式,组建专门团队或临时团队,还是同时建立这两种团队,主要取决于自身的独特环境—包括您打算如何宣传DevOps计划,以加强运维团队在DevOps中发挥的作用.
组织基层推动还是高管发挥领导作用虽然人们倾向于将DevOps视为半自发性质的基层活动,但自上而下的各级领导的支持也不可或缺.
DevOps是决定IT运维效率和企业商机命脉的核心,所以应当由IT和业务线主管或企业营销高管负责监督.
平均而言,超过60%的DevOps计划都得到了最高管理层自上而下的支持,这包括首席信息官、首席技术官、首席执行官及其他最高层主管.
这种支持架构在许多方面与基本上由IT高管所推动的数字化体验管理(DEM)团队并行运行.
但这并不意味着所有创新都必须来自高管层.
也可能来自中层管理人员,甚至来自多才多艺的专业技术达人.
但是,如果希望让运维在战略层面上更积极地参与DevOps,那么,IT高管层必须主动参与,了解情况并提供大力支持.
北美一家大型金融服务机构的一位执行副总裁负责领导销售和服务部门.
她在参加某次季度评审会议时故意放大招,直言不讳地指出因为公司未能提供其部门员工所需的服务质量,而导致他们未能实现销售目标,她借此告诉大家,用户体验才是DevOps计划的重中之重.
她给出了具体的统计数据,说明由于服务质量不理想,每小时销量的损失以及由此造成的经济损失,这可能是该公司有关IT如何影响业务成果的最具说服力的数据集.
32让运维参与DevOpsForDummies,IBM限量版充当问题修复者,还是更具战略意义的运维角色您可能需要根据DevOps需求,调整变更和发布管理以及可用性和绩效管理等流程,具体取决于营运团队的组织架构.
以下有关运维/ITSM整合团队如何与开发团队携手实施DevOps计划的简短措施清单,可以帮助您了解所需的技能组合:最大程度缩短开发团队在生产级故障排除方面所花的时间从生产前到生产再到此后阶段,持续评估用户体验质量管理基础架构变更,以支持应用程序发布需求和开发团队一起创建通用工作流程,确保工作能够顺利交接给生产环境做好发布计划安排,确保应用程序顺利部署到生产环境就应用程序/服务质量建立积极的反馈循环与开发团队一起,针对应用程序的使用和需求建立积极的反馈循环通过有效的服务建模和自动化技术,支持开发团队积极参与生产前环境的配置活动组建集中式运维团队,全面深入地了解发生的事件当环境中出现问题时,了解开发团队中哪些主题专家可以提供帮助确保开发团队可以根据需要使用运行手册来解决简单的问题DevOps团队的领导作用即使出现了像容器和微服务这样更为自给自足的新技术,但大多数业务应用程序仍需依赖于复杂的基础架构,因为它们分散在多个地理位置,第4章DevOps团队—谁是真正的领导者,为什么33与各种数据源和终端进行互动,并且依靠不断增加的支持性应用程序功能(其中许多可能来自第三方).
虽然开发团队需要更强大的支持,还需要以更灵活更迅速的方式开展工作,但他们也希望不被全球基础架构的各种变数所困扰.
这显然是运维团队应当带头开展的一项工作,包括当实际情况与应用程序设计无法有效吻合时,向开发团队发送反馈.
参与者名单DEM和有效DevOps团队的利益相关方的名单大致相同,这使您能够轻松制定"让运维参与DevOps"的计划.
贵公司可能参与DevOps计划的利益相关方包括:应用程序支持/管理网络运维系统/数据中心运维云管理(专门团队)ITSM跨域服务管理团队Q/A测试卓越中心架构/工程桌面/移动支持业务线利益相关方电子商务利益相关方和数字化营销流程管理与合规数字化或用户体验管理团队开发34让运维参与DevOpsForDummies,IBM限量版运维团队还可以在另一个领域发挥领导作用—帮助开发团队了解他们所开发的应用程序和服务的实际运用情况和价值.
有关应用程序质量、使用情况和价值的反馈循环,则由积极参与的整合式运维团队以及业务利益相关方和应用程序/服务使用者共同负责—因此,DEM在推动运维团队提高战略性作用方面扮演着重要角色.
探索流程和最佳实践的价值要让运维参与DevOps,可能还需要以创造性的方式同时采用多种最佳实践.
要考虑的最主要相关最佳实践应包括:敏捷/Scrum:日益受到开发团队青睐的敏捷方法更大意义上是一种运动,而非纯粹的最佳实践.
敏捷方法并不遵循传统形式的项目管理,而是最适合于由许多小型组件构成的现代化应用程序,这是因为敏捷方法的工作节奏更快、流程更短,旨在促进针对结果的即时对话和反馈.
例如,敏捷方法明显有别于传统的瀑布式应用程序设计流程.
Scrum是与敏捷计算密切相关的方法论或框架,适合于开发或冲刺周期大约为两周、10人左右的开发团队.
Scrum需要开展大量的持续沟通,如果项目团队分散在不同地理位置,或者应用程序比较复杂或陈旧,需要大量回归测试的话,这种方法并不总是最适合的.
IT基础架构库(ITIL):ITIL通常被认为无法满足敏捷方法的速度要求,因为其变更咨询委员会(CAB)以及自身的关注点都集中于小心谨慎的评审流程.
然而,当出于做出集体决策以及实现共同的工作方式的目的,评估如何将更广泛的IT流程整合在一起时,ITIL仍不失为非常有用甚至是大家梦寐以求的资源.
最有效的ITIL实施并非将ITIL作为标准来使用(它本身也不是标准),而是将其作为一种高级评估方法,用于评估IT作为一个整体(包括运维和开发职能)需要运行哪些流程.
在许多环境中,要让运维参与DevOps,可能需要为以Scrum为中心的应用程第4章DevOps团队—谁是真正的领导者,为什么35序建立快速通道,同时对较为传统的应用程序采用以ITIL为中心的流程.
IT4IT:IT4IT是OpenGroup的一种参考架构,旨在创建IT职能模型,以支持IT像业务部门那样更高效地运行.
它补充了ITIL和其他最佳实践,并创建了敏捷、DevOps、云外包和服务代理等特定用例.
随着IT组织逐渐发现可以证明自己在推动业务成果方面的贡献以及透明地展示自身的业务效率,IT4IT越来越受到欢迎.
长名单:与DevOps相关的最佳实践选项包括:IT均衡计分卡,用于更有效地确保团队或组织绩效与战略性的业务或IT成果保持一致六西格玛,旨在通过逐渐减少错误或风险几率,改善IT或业务流程COBIT(信息及相关技术控制目标),这是一种IT管理和治理框架TOGAF(OpenGroup架构框架),这是一种企业架构框架,包括用于设计、规划、实施和治理企业信息架构的方法CMMI(能力成熟度模型集成),这最初是一项培训计划,旨在提高CMMI研究所管理的IT流程的有效性,由卡内基梅隆大学最先开发虽然就像必须遵从某些人预先设计好的建议那样(至少将其作为出发点),多少会让人感到不爽,但最佳实践始终能够展现出对DevOps以及整个数字化转型计划的价值.
最普遍的价值莫过于提高IT生产力了.
但还存在许多其他显著的优点,例如提高IT服务(包括应用程序服务)的质量;提高IT服务的业务相关性—这对改进业务成果起到最关键的作用;也许还有最重要的一点—提高服务配置的敏捷性、灵活性和反应速度.
此外,最佳实践还有助于降低IT成本以及促进IT团队内外部的协作.
36让运维参与DevOpsForDummies,IBM限量版所有这些选项都有助于直接推动DevOps取得成功,并且有机会确保开发和运维团队形成合力,以更为统一一致的方式向前迈进.
开展对话非常必要但是,如果运维和开发团队都迷失在自己的组织架构"孤岛"之中,专业人员无意分享自己的工具和数据甚至是肯定会对关键应用程序交付产生影响的变更,那么,即便采用最佳实践,作用也不大.
对话(沟通)是Scrum的一大特色.
但对于几乎所有的DevOps计划而言,对话也都是至关重要的.
通过开展对话,一方面可以借助分析和服务建模等先进技术获得通用参考框架,另一方面可推动高管们扫除不良习惯和过往做法带来的障碍,这两方面的作用都非常关键.
当生产环境出现问题时,运维和DevOps团队必须进行协作与沟通.
叠加团队的出现进一步凸显出对话的重要性,甚至会改变DevOps的游戏规则.
有关叠加团队的信息,请参阅第5章.
第5章左移37左移左移是一种软件开发方法,用于在应用程序生命周期早期阶段开展测试.
也可比喻为从右手(传统工作方式)转变为左手(敏捷工作方式).
事实上,DevOps和敏捷方法的"风向"在不断发生变化,由于方向不定,一时很难追踪.
当然,对于未来方向,仁者见仁,智者见智.
随着DevOps的不断重新定义,有些人开始习惯微服务、容器和API驱动的应用程序等技术.
有些人则重点关注Scrum需求,旨在加速开发周期.
还有一些人抱怨缺乏总体模式,导致他们不知道如何针对所有应用程序类型和需求,通过一致的方式将所有流程和工作流程整合在一起,也不知道应该从哪里入手.
当然,所有这些都只是大型"拼图"的一个个组成部分—即使在本文撰写之际,这个大"拼图"本身仍在不断拼接和重新拼接.
本章并不打算预测DevOps的总体未来趋势,而是首先评估在DevOps及相关领域中建设叠加团队的明显趋势.
然后,会介绍一些关键DevOps指标,涉及衡量应用程序质量和相关性,以及通过促进持续评估来实现改进.
本章最后将介绍从DevOps相关研究和访谈中总结的几点建议.
第5章本章概要了解叠加团队日益重要的作用优化记录系统和互动系统评估DevOps成功与否了解DevOps的实际运用38让运维参与DevOpsForDummies,IBM限量版叠加团队到底有何作用叠加团队可以帮助小型团体开展更高水平的沟通,从而达到事半功倍的效果.
与多个IT领域中的叠加团队一样,DevOps叠加团队呈现增长趋势,在涉及内部开发的应用程序时尤其明显.
和DevOps团队关系最密切的也许就是数字化体验管理(DEM)叠加团队了,二者具有许多相同的成员,包括业务利益相关方,但DEM存在朝着运维方向转移(左移或右移)的趋势.
DEM团队负责提供有关应用程序需求的洞察,但并非应用程序开发蓝图阶段的中心,通常占到应用程序开支的50%.
其他相关的叠加团队包括服务交付团队或跨职能的服务管理团队等.
从本质上说,DevOps叠加团队的人数很可能是对应的DEM团队的几倍,而且团队中开发利益相关方的比例要高于运维利益相关方.
尽管如此,朝着叠加团队方向的转变仍需遵循适用于总体DevOps团队的许多规则.
尽管业务和IT部门的高管并不是各个团队的正式成员,但仍需要和他们建立密切联系.
仍应给予运维重要的地位,仍需持续实时地深入了解可用性、服务质量、用户和客户体验,并将使用情况、价值、业务影响及相关性方面的洞察及时反馈给团队.
换句话说,DevOps叠加团队的最佳工作方法不是把自己封闭在孤立的"真空"环境中,而是与DEM、服务交付以及应用程序组合规划相关团队开展清晰的对话,建立明确的合作流程.
从运维以及整个IT的角度来看,这意味着叠加团队需嵌套在一系列更大规模的对话和流程之中,即使对于可能会绕过某些传统的发布管理条款和条件的快速通道应用程序也不例外.
实际上,在理想的DevOps环境中,开发过程中用来跟踪问题和项目的系统"Jira"需要与运维和IT服务管理(ITSM)团队的IT工作流程结合起来.
要实现这一目标,主要依赖于自动化、分析及DEM等先进技术,帮助在一致性、相关性、质量和速度之间实现最佳平衡.
第5章左移39双模IT:记录系统与互动系统双模IT是一种方法,它让叠加团队(左手)与核心团队(右手)联手,并且让传统工作方式与云原生等应用程序所需的"短平快"工作方式之间实现握手.
双模IT支持传统模式和敏捷模式同时发挥作用,最终借助更大规模的计划将两者更紧密地集成在一起.
传统模式主要针对内部部署的应用程序和支持云的应用程序,通常涉及较长、较复杂的DevOps周期,有时需要数年才能完成,并需要采用较为集中的治理体系.
传统模式强调运维卓越.
敏捷模式主要针对云原生应用程序,开发周期一般为两到三个月,变更更为频繁,通常作为许多小型项目进行管理,采用较为分散的治理方法.
敏捷模式强调转型和差异化.
与传统模式相关的是记录系统,包括典型的变更管理方法,如配置管理系统(CMS)和ITIL最佳实践等.
与敏捷模式相关的是互动系统,注重速度以及最终用户使用移动应用程序和API驱动的应用程序的访问体验,不出我们所料,该系统非常适合Scrum和敏捷方法.
评估DevOps成功与否速度始终非常重要.
但是,DevOps要想取得成功,还需从提高运维效率和应用程序服务质量等方面进行考虑—无论您重点关注的是传统模式还是敏捷模式,亦或是可与这两种模式完美配合的中心辐射方式.
与DevOps相关的某些较为关键的速度和效率指标包括:发行版或软件包(文件和相关信息)交付数量的增加程度发行版或软件包交付频率的加快程度交付的代码行数的增加程度缺陷数量的减少与开发团队相关的积压事项(仍在等待交付给运维团队的软件)的减少40让运维参与DevOpsForDummies,IBM限量版与运维团队相关的积压事项(仍在等待运维团队完整交付给生产环境的软件)的减少新代码引起的事故及其他不良影响的减少在没有主题专家参与的情况下解决问题的效率—定义自动化起到一定作用在开发阶段为应用程序定义安全模型的效率—利用应用程序扫描及Web扫描等技术与应用程序相关(因此也与DevOps质量相关)的某些技术指标包括:可用性(最好是持续可用性)以单个事务为单位的响应时间以多个事务为单位的响应时间,目的是衡量业务服务完成情况第三方组件与内部开发的应用程序进行交互的响应时间被丢弃的事务数可操作性—用户是否真的了解如何使用应用程序与安全相关的风险最小化与技术相关的任何服务级别协议(SLA)针对应用程序质量的任何关联社交媒体,或与ITSM相关的用户反馈平均问题解决时间,用于了解如何缩短平均修复时间(MTTR)平均响应时间,用于了解问题何时由相关人员接管与应用程序价值、相关性和成本相关的某些较为重要的业务指标包括:使用情况和相关性—谁在使用特定应用程序及其使用原因用户生产力—完成的事务数与特定业务应用程序相关的收入方面的指标第5章左移41业务活动指标—特定应用程序对业务流程的影响品牌影响指标—应用程序对品牌价值的影响,包括从竞争对手网站吸引客户的转化率IT职能(运维和开发团队)总体运营节省或实现的运营支出效率社交媒体针对与应用程序相关的业务成果的反馈任何与业务相关的SLA(可以体现应用程序的成本或产生的业务价值)DevOps的实际运用运维及叠加团队中的IT利益相关方希望与开发团队的同事更高效地开展合作.
本节将介绍一些有关高效DevOps协作的真实案例.
医疗保健一家医疗保健企业希望确保应用程序在投入生产环境之前进行基准测试.
在建立试点项目时,该公司希望在Q/A测试期间开展负载测试和基准测试.
这样,该公司就能获得衡量指标,从而更好地了解产品在投入生产环境后会达到怎样的指标和性能.
金融服务一家大型金融服务企业的叠加团队负责向运维和开发副总裁报告性能下降和其他性能问题.
这可以帮助他们熟悉这两个组织的管理架构.
他们在全球拥有大约7.
5万名员工,其中包括许多封闭的技术团队.
通过将这些广泛的组织衔接起来,他们提高了DevOps在应用程序性能以及DevOps效率方面的表现.
42让运维参与DevOpsForDummies,IBM限量版电子商务与不同利益相关方分享适当的数据是DevOps取得成功的关键要素,可以帮助运维团队发挥更具战略性的作用.
在一家电子商务公司,运维组织首先将合成交易的成败信息与实时监控的所有参与者分享.
然后,他们再通过报告与开发团队、客户、首席信息官以及数据仓库团队共享更广泛的可用性和性能信息.
接着,他们使用这些数据来确认产品是否符合签署的服务级别协议,这些信息还将和公司的财务部门以及客户进行共享,以供评估.
医药耗材一家医药耗材公司的DevOps叠加团队负责人向运维和开发团队的利益相关方提出以下建议:"DevOps的实施所涉及的不仅仅是工具,在规划DevOps活动时切记要将沟通流程等细节考虑在内.
还应让用户群体尽快参与其中,争取获得他们对应用程序使用方式的支持,即使这样做可能会减慢项目速度也在所不惜.
"第6章让运维参与DevOps的十大最佳实践43让运维参与DevOps的十大最佳实践要让运维参与DevOps,就必须关注组织、流程、技术以及相应的目标设置和指标.
本章介绍的最佳实践旨在帮助您规划和推进DevOps计划.
认识到运维职能不断变化的角色要让运维在DevOps计划中发挥更为核心的作用,他们必须为此做好准备,使IT部门的运行方式更像是个业务部门,无论是通过以业务线(LoB)为核心的团队,还是通过中心IT运维团队,亦或二者兼用.
如能实现有关数字化体验管理(DEM)、集成式IT服务管理(ITSM)团队以及加速使用先进技术等方面的承诺,运维团队不仅能为DevOps团队提供出色的补救能力,还能提供有关应用程序使用情况、相关性、价值和成本的信息.
第6章本章概要了解运维和开发职能不断变化的角色支持数字化体验管理研究分析和指标了解沟通的重要性44让运维参与DevOpsForDummies,IBM限量版此外,运维团队还应帮助开发团队了解应用程序/基础架构性能方面的常见问题.
要实现这一目标,除了开展其他必要工作外,运维团队还需分享事件、时间序列数据及共享分析等方面的信息,以支持开发团队做出基于角色的明智决策.
最后,运维团队必须足够灵活,能够帮助DevOps叠加团队自行解决问题,而无需中心IT运维团队介入.
认识到开发职能不断变化的角色开发团队也在不断发展,变得行动越来越迅速、越来越敏捷,而且在某些情况下,变得越来越高效.
但是,这种趋势并不是永恒的.
现在,许多开发团队都面临着云原生应用程序与传统应用程序混杂的挑战,这些应用程序具有各种不同的依赖关系、开发窗口和最终用户需求.
面对业界这种从单一化向多样化选择转变的复杂局面,运维团队必须做好充分准备.
这种转变还需要各利益相关方共享有关工具集的洞察,借助一致的数据洞察帮助一线应答人员更主动地解决问题–最好能够提前发现并解决问题,以防造成真正的服务中断.
支持DEM要让运维参与DevOps,最重要的一点也许就是持续投资、不断践行DEM了—这需要同时关注客户体验和内部最终用户体验.
通过在生产部署前后持续提供有关应用程序质量的洞察,DEM团队能为DevOps计划取得成功开辟出坦途.
一旦应用程序投入生产环境,DEM团队还可以就实际用户体验、应用程序相关性、应用程序设计和应用程序影响为开发团队提供重要的反馈循环.
第6章让运维参与DevOps的十大最佳实践45重新评估自动化和服务建模选项自动化和服务建模都是对于DevOps计划至关重要的行业创新领域(更多信息,请参阅第3章).
应当为自动化制定集成战略,以便将生产部署前后的需求联系在一起,并采用服务建模和服务发现领域的创新成果,为变化多端的应用程序环境提供完全动态的洞察.
切勿忘记分析如果说有一种技术平台在让运维参与DevOps方面发挥核心作用的话,那么,非高级IT分析平台(更常用的名字是"运维分析")莫属.
您需要将来自许多不同工具的指标采集到分析工具中,以帮助发现异常情况.
此类平台可作为统一工具,将数据收集和数据表示统一起来,还能以前瞻性和预测性的方式深入洞察应用程序性能和漏洞、变更影响,甚至还包括在优化DevOps方面起关键作用的业务成果的趋势.
寻找适当的组织模式IT组织各不相同.
因此,对于运维团队甚至DevOps团队的组织方式,没有标准答案可循.
一般来说,专门团队比临时团队做得更好,而打破多个传统孤岛的叠加团队的兴起也是不无理由的.
对于同时在多个方向实施DevOps计划的大型组织(例如,为某些应用程序单独开辟了"快速通道"),也许可以选择中心辐射模式,也就是说,借助日常专门中心来支持辐射到DevOps"轮子"的多个"团队辐条".
投资于最佳实践,关注于衡量指标无论是敏捷计算本身还是更为传统的工作方式方面的最佳实践,都能为DevOps团队带来真正的价值.
说明价值的最佳方式是采用共享指标,这有助于评估速度和运维效率、服务质量以及业务影响和相关性等.
46让运维参与DevOpsForDummies,IBM限量版切勿忽视对话和沟通的重要性DevOps团队在共享重要洞察、流程和价值方面的进步喜人.
尽管自动化和分析洞察能够最大程度缩短补救活动以及其他活动所需的时间,但它们最终还是应当作为平台,推动运维与开发团队之间开展更明智的战略性对话.
选对切入点找到最合适的切入点,开始让运维参与DevOps,帮助他们建立全新愿景,焕发新的活力.
首先,可能需要加大践行DEM的力度,努力打造专注于核心的叠加团队,或者更关注于运维与开发团队交流思想.
甚至可以采用新技术作为平台,推动实现这一目标.
请确保一开始只针对少数几个挑选的应用程序,首先对这些应用程序制定DevOps计划.
抵御诱惑,切莫幻想毕其功于一役本书虽然篇幅不大,但是,如果您从头到尾读完本书,肯定可以从中获得很多知识.
这正是我们撰写本书的目的—帮助您从多个角度思考DevOps需求.
但是,切勿幻想在一天内建成罗马城.
虽然我们都认识到实施DevOps计划需采取多维方法,但要构建这种方法,并让所有相关利益相关方都熟悉,可着实要花费些功夫.
WILEYENDUSERLICENSEAGREEMENTGotowww.
wiley.
com/go/eulatoaccessWiley'sebookEULA.