devops是一种文化运动,会改变个人对其工作的想法,重视所做工作的多样性,支持加快企业实现价值的过程,以及度量社会和技术改变带来的影响。这是一种思维方式,也是一种工作方式,会促使个人与组织发展和维护可持续的工作实践。这也是个分享故事和培养同理心的文化框架,允许人们和团队以有效和持续的方式实战运用。
文化处方
devops是一个文化处方。任何一个文化运动都不可能存在于真空中:社会结构与文化紧密交织在一起。组织中的层次结构、行业关联以及全球化都会影响文化,还会影响价值观、标准、信念以及反映这些方面的工件。我们创建的软件不能脱离使用和创建这些软件的人独立存在, devops就是要找出方法来调整和变革社会结构、文化和技术,从而能更有效地工作。
DevOps是多方面的综合
实现devops并没有一种唯一正确的方法,也不是这样一个“单一处方”,尽管我们会介招常见的误区和反模式,不过更有兴趣描述成功的devops文化看上去是怎样的,会有怎样的表现,以及这些原则如何应用到各种不同的组织和环境。
尽管devops这个词本身是“ developmen”(开发)和“ operations”(运维)合成的一个词,但 devops的核心概念可以(而且应当)应用到整个组织,一个可持续的、成功的企业井不只有开发和运维团队。如果加以限制,只考虑具体写软件或者在生产环境部署软件的团队,这会对整个企业带来危害。
DevOps作为大众模式
在很多方面,devops已经成为一个大众模式,这个词有不同的含义,相应地也存在一些误解。在认知科学领域,大众模式往往作为一个抽象用来表述更具体的想法,而且通常会替代具体想法,与最后讨论的概念相比,这个抽象更容易理解。情境意识就这样一个例子,这通常用来表示更特定的概念,如感知和短期记忆。大众模式不一定不好,但是不同的组织使用同一个术语却有着不同的内涵时,这就会很成问题人们常常花更多的时间争论“devops是指什么(用来表示怎样的大众模式),而不是花更多时间关注他们真正想要讨论的想法。有时,为了绕开如何定义devops的问题,人们讨论具体的概念和原则时,会夸大“不好的”行为,由此强调哪些才是devops”的“好”行为。例如,为了讨论有效的团队间协作,有人可能会用一个漫画例子来说明,展示在一个建立了devops团队的公司中, devops团队只是作为开发和运维团队的中间人(就像我们在前言中所提到的),这是一个极端的例子,但是这会让人们讨论比定义更有意义、更实用的内容。
devops组合
devops的核心是人,人们不仅作为小组,更是作为需要相互理解的团队来工作。这可以描述为一个组合,团队要一起工作,沟通他们的想法以及遇到的问题,并动态地做出调整,朝着共同的组织目标努力。
组合示例
通过分析两个攀援者的沟通、澄清和相互信任,可以形象地描述这个重要的组合,攀援活动要求攀援的人在天然岩石或合成墙上向上、向下或左右攀行。共同目标是到达顶端或者到达某个特定路线的终点,通常攀援过程中不能掉落。这是体力和脑力的结合,一方面要有攀爬所需要的耐力,另一方面还要有理解能力及做好下一步准备的敏锐判断力。
在某些攀援活动中,一个人(即攀援者)会用一个绳子和一个背带作为保护措施防止掉落。第二个人(即保护者)会监视绳子的张力,要为攀援者提供足够的张力,一方面防止掉落幅度太大,另一方面还要提供足够的松驰度,使他在攀援时有灵活机动的空间。
要提供适当而安全的保护,不仅要求对工具和过程有共同的理解,还需要持续不断地沟通,攀援者要安全地打好背带,保护者则要确保他的保护设备与攀援者的攀援背带正确连接,开始攀援之前,每个人都要信任对方,不过还要检查另一个人的工作状攀援有一套自己的口头提示,可以在攀援前指示准备情况,攀援者问“ on belay?(保护就绪了吗?),保护者回应“ belay on”(保护就绪),然后攀援者再回应climbing(准备攀援)来表示他已经准备好。最后,保护者回应“ climb on”(开始攀援)作为确认保证这个组合有效工作的原则包括:
> 明确定义的共同目标
> 持续不断的沟通
> 对理解的动态调整和修正
接下来我们会谈到,这些原则不仅对攀援者很有意义,对于具体实现devops的人也具有同样的意义。
Devops组合示例
青蓝公司的两个员工分别在不同的团队里工作, Zora是一个高级开发人员,工作背景很丰富,有很多不同的工作经历,他在青蓝公司已经任职两年,Loco是一个运维工程师,有一些经验,在 青蓝公司里还算是一个新员工他们所在的两个团队要为依靠青蓝公司网站开展创新活动的全球用户社区提供支持。他们的共同目标是实现一个新特性,提升最终用户的价值,而且希望不要影响这个网站。
由于在公司里更有经验,Zora要向Loco明确青蓝公司的预期、价值观和目前的流程。反过来,Loco要向Zora明确他什么时候需要帮助或者不能理解流程的哪部分。在继续接下来的步骤之前, Zora和Loco要迁入彼此的工作,这正是攀援过程中描述的信任但确认( trust-but-verify)模型的一个例子。
Zora和Loco对他们的目标有共同的理解:
> 实现一个新特性,增加对青蓝公司客户的价值
> 在相互沟通中保持安全和信任
在一个非 devops的割据环境中,往往缺乏共同的理解,这可能表现为Zora打算开始编写代码,但未能确保Loco确实理解需求,也许最后可以实现这个新特性,但是由于对目标没有沟通,前景可能不容乐观。
一个组织在发展过程中肯定会遇到意外的问题或阻碍,不过如果有共同的理解,认识到每个人都是这个组合的一部分,就会采取行动完成一系列的修正。对于谁完成某个特性或者什么时候完成我们可能有一些误解,首先要修正这些误解。另外对于软件表现如何我们有自己的理解,可能存在一些bug会影响我们的理解,因此需要修正这些bug。如果生产环境中的实际工作与我们预期的不同,还要修正流程和相应的文档。
青蓝咨询将采用这种devops组合的观念,介绍如何利用devops的技术和文化来发展和维护这种共同的相互理解。
青蓝老师带您理解devops运动的关键。这种观点鼓励我们分享故事,因为所有情况是学习机会。
分享故事可以:
> 增进团队中的透明度和信任
> 指导同事避免成本很高的错误,而不需要他们亲身体验这个错误
> 增加解决新问题的可用时间,从而可以有更多创新
通过在全行业中分享这些故事,我们会影响整个行业,创造新的机会,知识和共同理解。
DevOps更多资讯
深圳青蓝咨询服务有限公司
电 话:0755-86950769
官 网:www.shzhchina.com
邮 箱:peixun@shzhchina. com
地 址: 深圳市南山区高新南一道06号TCL大厦B座3楼309室
深圳地铁1号线高新园站C出口