译者序

译者序

在十几年的工作经历中,我见证了国内企业数据中心建设和发展的过程。大型企业的数据中心拥有几千台服务器和网络设备,拥有全套的监管控平台。当踱步于轰鸣的机架丛林里时,当与夜间奋战的变更团队一起凝视着命令执行出错的屏幕时,我们可以清晰地感受到IT运维组织里那种特有的恐惧感和紧张感。

这一切是不是都应该去埋怨墙另一侧的开发团队呢?在平日里,应用系统是被圈养的宠物;而在发生事故的那一刹那,它就变身为一头难以驯服的猛兽。从IT组织整体来看,当前运维人员的痛是深刻而明显的!而开发人员同样是深受夜班出租车司机喜爱的人群。相对于运维团队而言,他们的精神世界和现实世界要更加美好一些。开发团队实施了很多年的敏捷软件开发,有着自己的关于完成的定义。即使你现在去翻阅一本最新出版的Scrum敏捷开发指南,翻到关于完成的定义的章节时,还是可以看到类似这样的定义:“冲刺的目标是要产生一个潜在可发布的产品增量,达到大家一致认可的完成程度。”我对这样的定义感到非常忧虑:它能意味着每个冲刺的开发结果可以正常地运行在类生产环境中吗?能意味着可以按照业务人员的需要马上开展小范围的真实用户实验吗?运维人员能否在系统濒临崩溃之前自行关闭这个功能?

可以肯定的是,现在开发和运维还不能在统一的、为客户交付价值的目标下工作,他们像是生活在不同的星球上。这个问题并不是我国特有的。回顾一下从2009年开始的DevOps运动吧!这是一次能让开发和运维感到同样兴奋的技术实践变革,其中也充满了人文变迁。

我在不停地思索,应该怎样破解以上困境。在研究DevOps相关技术实践一段时间之后,各种答案终于陆续浮现。我很幸运地接受了本书的翻译工作。对我来说,这是一次深度的DevOps学习研究之旅,组织几个好友共同经历这个过程也非常难得。现在可以确定的是,DevOps的理论、原则和实践就一条“更好的道路”,就是我们需要的答案;它能让开发和运维深度地融合为同一支“球队”,使他们朝着“进球”这一共同目标协同努力,而不再是彼此对抗和怀疑。它将测试和信息安全工作一同融入了这个统一的框架当中,将保障质量和安全变为每个人日常工作的一部分。本书用DevOps“三步工作法”的形式展示了所有相关细节。它适用于IT组织里所有的级别和角色,值得任何拥有改进想法的人深入学习。

本书对开发和运维具有同样重要的意义,而且覆盖了传统的QA测试和信息安全工作;它是传统的敏捷开发、精益管理和ITSM管理等实践各自发展多年以后的首次IT管理实践大融合。本书和DevOps本身应该得到更广泛的应用和推广。本书的出版离不开翻译团队和图灵编辑团队的专业精神,以及双方的共同努力。在此我统一向所有合作者表示感谢。

此外,谨以此书献给我的妻子丽娜和女儿禹含,感谢她们在这13个月时光里的支持。特别让我欣慰的是,女儿不仅明白什么是图书翻译,而且在网络英语课上有很棒的表现,也感谢她能容忍我因此而减少了与她陪伴和玩耍的时间。

刘征

2018年2月14日(丁酉年腊月二十九)

 

2016年9月的一个周末,当时我正在参加EXIN举办的DevOps Master Trainer的培训,刘征向我推荐了这本书,并邀请我共同完成中文版的翻译工作。出于对Gene Kim的《凤凰项目》一书的喜爱,对能够参与本书的翻译工作,我非常期待。

一周后,当我第一次阅读本书的预览章节时,顿时被其中的内容所吸引。本书不仅将敏捷、精益和持续交付等理念的诠释上升到一个新的高度,而且剖析了在这个安全漏洞频发、交付周期不断缩短、技术大规模转型的时代,当技术领导者们面对安全性、可靠性和灵活性等诸多挑战时,为什么DevOps能够脱颖而出——它帮助组织缩短价值交付流程,打造高可靠性、高安全性的产品,并提高了企业竞争力和员工满意度。

本书从业务视角描述了DevOps的必要性,分析了为什么DevOps是基于精益、约束理论、丰田生产系统、学习型组织、康威定律等知识体系的集大成者。同时,它系统性地定义了DevOps“三步工作法”:流动原则、反馈原则、持续学习与实验原则,并阐述了DevOps实施需遵守的原则与最佳实践。

  • 流动原则:它加速了从开发、运维到交付给客户的正向流程。
  • 反馈原则:它使组织构建安全、可靠的工作体系,并获得反馈。
  • 持续学习与实验原则:它打造出一种高度信任的文化,并将改进和创新融入日常工作中。

DevOps对技术行业带来的变化,就如同精益在20世纪80年代对制造业的变革一样。那些拥抱DevOps的组织将构建出充满激情、持续进步的学习型组织,并能通过创新的方式表现得比竞争对手更加出色。在本书中,作者引入了大量的业界成功案例,包括谷歌、Etsy、塔吉特、LinkedIn等一流的互联网公司,描述了他们在DevOps转型过程中面临的挑战以及应对方式,指引读者站在巨人的肩膀上思考。

DevOps使价值流里的所有参与者都受益匪浅。无论你是开发人员、运维工程师、质量保证工程师、信息安全人员还是产品经理,它都能够带来开发伟大产品而产生的快感。它能使团队共同成长并持续获益。相信读过本书之后,你一定会产生强烈的共鸣。

感谢我的妻子晓丽和儿子锦熙,翻译本书占用了我大量业余时间,没有你们的支持,我不可能完成这项工作。感谢本书的其他几位译者——刘征、马博文、曾朝京,和你们的合作让我获益良多,也感谢图灵负责本书审校工作的编辑们,你们逐字逐句的检查、校对和修改提高了译文的质量,谢谢你们!

最后,祝读者们享受DevOps的实践之旅!

王磊

2018年2月20日

 

2011~2017年,我一直在为ThoughtWorks的一个海外交付项目工作。我们和客户一起,从持续集成、两周一次部署,做到了持续交付、随时部署,同时应用架构微服务化,也实现了上云以及容器化部署。

在这个过程当中,我们切实地采用和执行了业界的良好技术和工程实践,如微服务、蓝绿部署、不可变部署、基础设施即代码等。我也曾经阅读和翻译过DevOps的相关图书,但总觉得还是和我们的实践有点差距。

在这段时间中,我的角色也从开发者变为DevOps(我个人不太喜欢这个称呼,因为我认为DevOps更多的是实践而不是角色)。同时,我组织了西安DevOpsMeetup的活动,期望能通过社区分享更多关于DevOps的知识。每次活动时,总是有朋友问如何实现DevOps,我却发现即便亲身经历了这个过程,也无法给出更高层面的回答,而且也没有在别的文章和书籍中找到答案。

很幸运,因为社区活动而结识的刘征向我发出了翻译本书的邀请。在翻译的过程当中,我找到了如何系统性实现DevOps的答案。通过“三步工作法”铺平流程,选择合适的切入点,根据康威定律调整组织、持续交付、自动化、运维改善等。对于尚未实现DevOps的IT组织来说,这是一本不可多得的指南。

翻译本书,收获颇多。本书的作者Patrick、Gene、Jez和John确实贡献了一本集DevOps大成的著作。希望读者在阅读后也会有相同的感受,能够在团队中逐渐采用本书提供的工作法或者实践,改进交付速度、质量、软件可用性以及构建高可扩展的组织结构。

翻译是一件费时费力的工作。感谢我的妻子王嘉,能包容我放弃陪她的时间来完成这一项工作。感谢一起合作的几位译者——刘征、王磊、曾朝京,和你们一起合作非常愉快。感谢Trent、Cos等REA的朋友,是你们带我走上了DevOps之路。最后,祝各位读者在阅读完本书后,都能找到实践DevOps的方法,并且行动起来,开启DevOps的探险之旅并持续从中受益。

马博文

2018年3月4日

 

2012年,我第一次在公司的年度全球会议上接触到Dev+Ops的概念。那时候,IT服务管理的理念在国内IT运维领域已经深入人心,保障生产系统的可靠性和安全性仅仅是运维工作的基本内容,许多企业的IT部门越来越关注对业务部门需求的反应速度和给业务带来的实际成效,要求进一步提高IT服务的工作效率和工作质量。显然,要提高IT服务的整体绩效,不能仅仅局限于运维工作的范畴,也不是ITIL最佳实践就能够解决的问题。越来越多的IT人员都有相同的困惑,我也在一直思考:还有什么更好的方法能提高IT绩效?!

Dev+Ops提出将开发和运维团队的工作紧密结合起来,建立持续交付和持续反馈闭环,这个思路让人耳目一新。但是彼时DevOps还在实践中探索,各种阐述DevOps的文章还是比较片面的,甚至有一些见解是相悖的。关于如何开展DevOps,应该做什么、如何做,业内一直缺乏形成体系的说明。

随着DevOps的概念越来越受到关注,我对开展DevOps的困惑也越来越多。当我看到本书英文版时,虽然只有一个样章,但是它已经能让我确信,关于如何开展DevOps的很多问题都会在其中找到答案。于是,我欣然接受刘征的邀请,参与了本书的翻译工作。

翻译本书的过程就是学习和思考DevOps实践方法的过程。在这个过程中,我经常会经历作者在文中描述的“啊哈”时刻:疑惑解决了,思路豁然开朗。我相信本书的每一位读者都会经历这样的顿悟时刻。

在这本书的翻译过程中,翻译团队也实践了“三步工作法”中的第二步——反馈原则。反馈原则的核心思想是:虽然复杂的系统不可避免地存在错误,但是可以通过采取安全措施确保在质量问题出现之前,快速发现和处理错误。4个译者在分别翻译了不同的章节之后,都发现了在初稿中有诸多对原文理解的分歧和名词翻译不统一的问题。大家商议后决定,遵照“三步工作法”的反馈原则,全组集中从第一个章节开始交叉审阅、按序检查;发现问题及时在小组范围内讨论;形成一致意见后,分别回到自己负责的章节中修改。这个过程正是在PDCA中识别问题、群策群力解决问题、构建新知识并将局部知识应用到全局的过程。在这个过程中,每一个人也对DevOps实践有了更深刻的认识。

本书用大量真实的案例描述了DevOps实践产生的过程。他们所遇到的问题和困境,很多IT团队都曾经经历、正在经历,甚至在未来不可避免地即将经历。希望本书能在你感到困惑之时,对你有所启发、有所帮助。

经过13个月,本书终于出版在即了。翻译工作占用了我大量的业余时间,感谢我的父亲、母亲、丈夫和儿子,他们让我在翻译文章的那些夜晚和周末,只做一个繁忙的影子。

感谢一起翻译此书的伙伴们——刘征、王磊和马博文,以及图灵公司的编辑们。

曾朝京

2018年3月3日

 

特别感谢EXIN国际信息科学考试学会为本书提供的DevOps Professional认证考试样题及解析。《DevOps实践指南》是EXIN国际信息科学考试学会指定的DevOps Professional国际认证核心教材。

目录

  • 版权声明
  • 推荐语
  • 译者序
  • 序言
  • 前言
  • 导言:展望DevOps新世界
  • 第一部分 DevOps介绍
  • 第 1 章 敏捷、持续交付和三步法
  • 第 2 章 第一步:流动原则
  • 第 3 章 第二步:反馈原则
  • 第 4 章 第三步:持续学习与实验原则
  • 第二部分 从何处开始
  • 第 5 章 选择合适的价值流作为切入点
  • 第 6 章 理解、可视化和运用价值流
  • 第 7 章 参考康威定律设计组织结构
  • 第 8 章 将运维融入日常开发工作
  • 第三部分 第一步:流动的技术实践
  • 第 9 章 为部署流水线奠定基础
  • 第 10 章 实现快速可靠的自动化测试
  • 第 11 章 应用和实践持续集成
  • 第 12 章 自动化和低风险发布
  • 第 13 章 降低发布风险的架构
  • 第四部分 第二步:反馈的技术实践
  • 第 14 章 建立能发现并解决问题的遥测系统
  • 第 15 章 分析遥测数据以更好地预测故障和实现目标
  • 第 16 章 应用反馈实现安全部署
  • 第 17 章 将假设驱动的开发和A/B测试融入日常工作
  • 第 18 章 建立评审和协作流程以提升当前工作的质量
  • 第五部分 第三步:持续学习与实验的技术实践
  • 第 19 章 将学习融入日常工作
  • 第 20 章 将局部经验转化为全局改进
  • 第 21 章 预留组织学习和改进的时间
  • 第六部分 集成信息安全、变更管理和合规性的技术实践
  • 第 22 章 将信息安全融入每个人的日常工作
  • 第 23 章 保护部署流水线
  • 行动起来——本书总结
  • 附加材料
  • 附录
  • 参考资源
  • 致谢
  • EXIN DevOps Professional认证备考指南 & 模拟题