领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
DevOps，一场更深入的敏捷文化变革
作者 乔梁 发布于 2010年12月5日
12月7日和8日，在北京世纪金源大饭店将举行《O'Reilly Velocity China 2010 ── Web 性能和运维大会》，这不禁让人联想起最近在业内流行的一个热词，即“DevOps”。从名字上不难想到是由“Development”和“Operations”两个英文单词合并而成。那么究竟什么是“DevOps”呢？业内人士对它的看法又是怎样的呢？
Wikipedia上对它的定义是：
DevOps是软件开发、运维和质量保证三个部门之间的沟通、协作和集成所采用的流程、方法和体系的一个集合。 它是人们为了及时生产软件产品或服务，以满足某个业务目标，对开发与运维之间相互依存关系的一种新的理解。 ...... DevOps并不仅仅关注软件部署，它是部门间沟通协作的一组流程和方法。
这个定义似乎并没什么特别新鲜的内容，您可能会说：“我们的日常工作中不是一直需要各部门间的紧密协作吗？”然而，就象很多敏捷实践（比如迭代开发、每日构建）一样，它们在“敏捷”一词出现之前就已被应用到工作中，但敏捷让这些实践有机地结合在一起，发挥出前所未有的作用。敏捷强调打破需求、开发和测试之间的隔阂，形成自组织的跨功能交付团队，而DevOps则又向前迈进一步，强调以业务目标为导向，推倒交付团队与运维团队之间那道墙，将敏捷开发理念延伸至运维领域，使我们在IT方面的投入可以快速地转化为业务价值，从而打通“需求提出”到“上线运行”之间的所有环节。正如Puppet Lib的运维总监Kartar所说：
DevOps就是试图避免重大失误，并更聪明且高效地工作。它是一种旨在促进开发和运维两个团队相互合作、学习的思想、原则和框架。在一个DevOps环境中，开发人员和系统管理员建立关系、流程和工具，让他们可以更好的交互，并最终为客户提供更好的服务。
作为DevOps的倡导者，独立IT咨询师Patrick Debois认为，DevOps对下述问题的解决有很大帮助：
- 对变更的恐惧。一旦软件应用正式上线以后，业务方面往往害怕变更。他们认为软件本身和它所依赖的软硬件平台都很脆弱。所以对于任何变更都可能需要一个冗长的流程来保证。
- 部署充满了风险。因为没有人对软件质量有信心，比如不能肯定它是否能够处理生产环境中那么多的负载。
- “它在我的机器上没有问题！”常常听说开发人员这么说，而运维团队的确遇到了麻烦。
- 部门壁垒。开发人员和运维人员认识世界的方法，以及各自所处的角色，存在根本性的差别。他们都认为自己的做法是正确的。开发和运维团队通常处于公司组织架构的不同部分，通常具有不同管理者的和竞争关系，而且通常工作在不同的地点。
敏捷开发现已渐成主流。而随着虚拟技术和云计算的成熟与发展，对原有的运维模式与要求也发生了变化。Joyent的系统部总监Ben Rockwood认为：
“Devops是下一代的ITIL，即大众ITIL。Devops说：‘运维要为业务服务，而不能在角落里做极客’或者‘运维需要度量所有方面，比如发布流程、变更管理和版本控制等’。而更多的人认为，ITIL再次火了起来，不只是ITILv3，还有CobiT, CMMI, ISO20K, ISO27K等。”
Thoughtworks敏捷发布管理工具GO的产品经理Jez Humber在其博文《持续交付与ITIL：变更管理》中指出，ITIL完全可以通过“持续交付”来实现一个轻量级的ITIL。Tripwire公司创始人Gene Kim写的《Visable Ops》中也阐述了如何用现实且合理的方式实现ITIL。
另外，目前也有工具链对DevOps提供了强有力的支持，它覆盖了监控、准备、配置管理以及控制等方面，逐渐形成该领域中流程及工具标准化的生力军。作为DevOps运动的实践者，ThoughWorks的IT主管Ajey Gore介绍说：
“在ThoughtWorks内部，我们已经在全球22个办公室的500多台服务器和虚拟机上安装了Puppet。在公司内部，我们现在
- 建立了Puppet的版本控制库。
- 每个Puppet服务器每30分钟会检查一次版本控制库。如果发现有变更，就会进行本地更新，并重新启动服务器。
- Puppet服务器也检查puppet脚本，反过来重新启动版本控制库。
- 如果有Puppet服务器出了问题，Nagios就会告诉我们那台服务器上的Puppet没有运行，我们就可以修复它了。
综上所述，在思想上，DevOps是敏捷理念向运维领域的延伸；在流程上，它是“需求”到“上线”全线贯通的关键；在工具及技术准备上，虚拟技术、云计算以及各类工具的日趋成熟，为这场变革奠定坚实的基础。
尽管大家对DevOps的看法不尽相同。但只要您把它看作是一种文化的演进，让交付团队与运维团队互相学习，互相帮助，成为真正的跨功能一体化团队，为客户提供更好的服务，最终也就达到了它的目标。
感谢张凯峰对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家加入到InfoQ中文站用户讨论组中与我们的编辑和其他读者朋友交流。
乔梁 有十多年软件开发及项目管理经验，专注于提高软件企业提高交付能力。现任百度项目管理部高级架构师。
工具不是关键
发表人
P. H
发表于
Re: 工具不是关键
发表人
qi lin
发表于
Re: 工具不是关键
发表人
乔 梁
发表于
目前团队就遇到这样的问题
发表人
朱 冬
发表于
工具不是关键
发表人
wu eric
发表于
敏捷推进就很难了，整合开发和运维，又是个挑战，且更大
发表人
Li Johnny
发表于
这样的改变目前来说太激进了
发表人
TH Evan
发表于
Re: 这样的改变目前来说太激进了
发表人
乔 梁
发表于
Re: 这样的改变目前来说太激进了
发表人
Teng Daniel
发表于
-
应该从文化的层面来看这个问题，两种角色由于职责分工不同很容易产生壁垒，由于某些企业文化的原因又容易造成相互指责推捼，如何协调好两者的关系使之发挥最大的效率同时又能保障业务质量和监管力度，关键还得看领导的智慧了。
-
靠领导，不靠谱
-
“让领导认同”也是每个人工作的一部分。
-
目前团队就遇到这样的问题，运维有自己的一套处理方法，而且权限由不下放，造成原本5分钟搞定的事情可能要花一个小时来处理
-
职权的划分是导致部门之间工作效率影响的主要原因。
过多的纠结流程中效率的体现往往会忽略操作失误的成本。
一切工具都不是关键，更多的是保证完整且合理的协作流程，权限和职责的划分和下放。 -
谢谢乔梁的分享。
第一次知道Devops是从徐昊哪里听到的，前几天又听郭总提到了这个概念。
开发和运维（部署）部门之间的隔阂，在我这里也是显而易见的。原来一直埋怨运维部门没有服务意识，很难合作，总感觉哪里不对劲。
敏捷推进就很难了，整合开发和运维，又是个挑战，且更大。 -
针对目前国内情况，DevOps还是很遥远。
我想也许只有行业顶尖的公司，或者新成立的公司会有这样的尝试。
大多数的企业还未开始进行敏捷的推进，传统的重重阻碍会使敏捷的推进进程遥遥无期。
可能会一代人以后吧。 -
Agile出现的时候也有人说“太激进”了，但总要向着目标前进。
-
Sai Venkat在敏捷全球之旅上海做过一关于DevOps的话题
agiletourchina.agilewizard.org/2010/12/15/sai-d...
9 条回复
关注此讨论 回复