徐磊，英捷创软 LEANSOFT 创始人兼首席架构师，专注于软件工程、DevOps 方面解决方案咨询。有超过 10 年的软件研发项目管理经验，曾任 SSW 中国研发中心总经理。是资深 ALM 顾问和解决方案专家，微软最有价值专家和大中华区域社区技术总监，认证 ScrumMaster 和敏捷教练。
StuQ 工作坊：您拥有多年 DevOps 实战经验，曾担任京东商城、华为、中国农业银行、百威英博等多个项目的高级 ALM/DevOps 顾问。您怎么理解 DevOps？在您看来， DevOps 的核心竞争力是什么？
徐磊：核心竞争力就是两个字：效率。
IT 行业非常擅长发明新名词，其实过去的 10 年中我一直都在做软件工程相关的工作，一路走来撞上了很多这样的名词：SDLC（软件开发生命周期），ALM（应用生命周期管理），敏捷，精益等等，到了 2012 年第一次听说 DevOps。开始的时候也很迷惑，到后来发现这 10 多年都只做了一件事情，就是提高效率。DevOps 不能帮你直接解决业务问题，它只能帮你更快更好的交付业务需求，这就是效率。
这么多年，其实软件工程行业的关注点经历了一个从微观到宏观，再回归微观的过程。比如一开始的 SDLC 就是一个关注软件开发过程本身的方法论，后来发现这不够，只关注开发本身解决不了问题，就开始向更大的范围延展，也就是出现了 ALM。
其实 ALM 和 DevOps 所关注的问题领域很接近，只是前者更关注管理，而后者又开始向技术回归，更加关注具体的实践和落地的方案。而敏捷和精益在整个过程中则起到了价值观引导和方向性指导的作用。
说的更直白一点，软件工程行业做的就是效率的工作，我们虽然不能帮你写代码，做测试，但是我们会让你写的代码体现出更多的价值，让你的交付过程更加顺畅，让管理人员更有信心，让技术人员在单位时间创造更多价值。
StuQ 工作坊：可否用一个您之前的案例，说说应用 DevOps 给开发团队带来哪些改变？
徐磊：案例很多，都可以和 DevOps 扯上关系，DevOps 其实就是一顶帽子，只要你做的是软件工程领域改进效率的工作其实都可以说自己在做 DevOps。所以，不应该说 DevOps 这顶帽子给开发团队带来那些改变，而是 DevOps 下面的实践给开发团队带来哪些改变。
我做的案例中金融行业比较多，比如：农行，兴业银行，博时基金等等。这个行业有一个普遍的特点，就是监管很严，造成的结果就是企业内部流程繁琐，审批多，部门墙很严重。
我个人比较看重的改变其实是团队士气上的改变，比如之前给其中一家引入了用户故事地图和影响地图实践，协助他们完成了需求梳理过程。参与的成员普遍的反应是业务人员和技术人员可以开始对话了，而且效率很高，以往可能需要几个月才能完成的需求梳理和设计，这次仅仅用了 2 周时间，项目就可以启动了。而这种对话所带来的默契在后续的开发过程中让沟通更加顺畅。
另外一家，我为他们的 iOS 开发项目定制了一套在 TFS 上面的集中自动化构建系统，这个事情让他们的开发人员不再需要每个月抱着电脑到构建管理员那里拷贝代码才能发布版本。这里解决的其实是 AppStore 证书的问题，因为企业证书是不能拷贝给开发人员的，而发布正式版本又需要这个证书，所以以前是靠人来管理，现在可以靠自动化系统。这个事情其实做的就是持续集成，但是解决的却是流程问题。
引入 DevOps 实践最重要的是要能带来效率提升，让涉及到的人员感受到价值。
StuQ 工作坊：您觉得哪一类企业适合 DevOps？如何评估一个企业适不适合，以及什么时候适合实施 DevOps？
徐磊：我觉得没有不适合 DevOps 的企业，只有不适合 DevOps 的人。企业都要盈利，没有一家企业会认为效率提升对它没有价值，所以都适合做 DevOps，而且都应该做。但是具体到人的个体，就不一定了。
这里还是个案例，我的一家银行客户，一直希望能够做到全生命周期的软件工程管理，就是用需求把整个过程串起来，一直不能落实。2016 整个行里把互联网金融作为战略级决策，由副行长出面协调组织了一个跨部门跨职能的虚拟团队来做这个事情，这个项目里终于做到了全生命周期管理。
我在这里不想探讨为什么要做全生命周期管理，我只想说为什么之前的 10 年都做不到，这次做到了。我参与了这个项目整个过程，我觉得最大的区别就是这个组织架构的调整。以前的人员都属于各个部门，各自的 KPI 都是对部门的，没有人会觉得全生命周期管理对自己有任何的好处，因为自己做的都是其中一段，做多了也没有人会说你好。这次采用这种虚拟团队的组织架构，让这些人的思想一下子从做好自己这一段转变成了做好这个项目。这个事情就成了，就是这么简单。
DevOps 从来都不能把它当成一个项目来说，虽然时机很重要（比如上面这个案例），但是 DevOps 的实践可以随时开始。没有前期的铺垫和探索，上面这家银行业也不可能在这个项目中顺利实施 DevOps 实践。所以我们要做的是：持续改进，时刻准备着。
StuQ 工作坊：很多企业都有“想实施 DevOps 又不知道从何入手”的困境，您认为在实施 DevOps 过程中需要注意什么问题？有哪些关键点设计？
徐磊：关键点是 3 句话：
自上而下的文化转变
自下而上的实践支撑
贯穿中间的工程落地
其实以上的案例已经印证了这 3 点，没有企业领导者对 DevOps 价值的认知，下面的人再怎么努力也没有用，企业的方向性战略还是靠几个人的思路决定的，没有他们脑子里面的转变，下面人做再多也是跑偏。这部分的改变需要敏捷和精益思想的导入。但无论领导们如何认知这个问题，软件研发的效率问题都是客观存在的，所以务实的各种实践都还是要做的。
这部分的实践要靠 Scrum，Kanban，持续集成，持续交付等等方法和实践的支撑。而企业需要的只是一个时机，所有的努力都会被聚集在一个点上爆发。上下的思路碰撞会带给企业量变到质变的机会。而贯穿这整个过程的是软件工程系统和工具的落地，系统和工具中所承载的是企业的制度和流程，这些是保证企业在铁打营盘流水兵的现实下确保持久发展的核心竞争力的基础。
StuQ 工作坊：您是怎样一步步成为 DevOps 大牛的？这个过程中有过什么瓶颈么？又是怎么克服的？
徐磊：一个事情做的够久了，自然有些心得。我常和客户说的一句话就是：我不比你们高明多少，但是我掉的坑肯定比你们多，从坑里爬出来的次数多了，就知道哪些坑能爬得出来，哪些坑爬不出来。别把人往坑里面带，这就够了。
瓶颈还是有的，放在 5 年前其实没有什么人关心软件工程，DevOps 也远远没有今天那么火，很多人甚至都不觉得这是个正经行业，就连应聘来的人都要解释半天我们是做什么的。所以有一段时间这个事情其实做起来很苦逼，也一度想转行做其他的。这应该算是瓶颈吧，估计很多做这个行业的人在中间都撤了，最后坚持下来的就算是大牛了吧。
StuQ 工作坊：您如何看待 DevOps 的发展现状以及未来发展趋势？
徐磊：DevOps 的现状用方兴未艾来形容是最形象不过的，2008 年这个词出现到 2012 年被行业认可，到 2013 年 docker 出现再一次推波助澜。现在的状况是从管理方法论和工程方案上都已经很完整，但是企业中的实施成功案例还比较少，特别是传统 IT 企业。
现况是，新兴行业（互联网企业）凭借着轻装上阵，无历史包袱和相对简单的业务模型，天生就具备 DevOps 的优势，而且他们作出了很多非常漂亮的实践，分享到社区；但是传统企业 IT 的复杂度其实比新兴行业要高的多，这些实践确实具备借鉴意义，但是如何真正引入到传统企业的 IT 并产生价值这就是最近几年的主要趋势了。
作为 IT 行业从业者，其实很容易被满天飞的各种公众号文章，博客，宣传所误导；好像互联网的玩法才是好的。其实我们真的要认清形势，互联网在整个 IT 业里面的体量恐怕连 10% 都不到，绝大多数软件开发从业人员是在为各种企业的 IT 部门工作的，真正解决他们的痛点才是 DevOps 应该关注的问题。
StuQ 工作坊：可否推荐一些您用过的好用的 DevOps 工具？
徐磊：DevOps 的范畴很大，从工具角度来说可以分成这样几类，这些工具都是我在工作中常用的，所以不全，只是我比较了解的。
1、全生命周期管理平台：这类工具的重点是在企业研发中形成端到端的管理能力，建立整个研发流水线（这里的流水线包括需求，开发，测试，交付整个过程，不仅仅是自动化流水线）。
微软 Visual Studio Team Service / Team Foundation Server 平台：这是微软支撑自己产品研发和为企业提供的研发管理平台，提供了包括需求管理，项目管理，配置管理，测试管理，自动化构建／发布和数据分析的完整研发管理平台，也是我最熟悉的平台。
Atlassian 的系列产品，包括：Jira（需求，项目，过程管理）,BitBucket（代码和配置管理）,Confluence（知识库和文档管理），Bamboo（自动化／持续集成和发布）。Atlassian 是一家专注于软件工程管理平台多年的公司，产品线随着这么多年的发展也日趋完善和完整。我的客户中有很多在使用这个平台。
2、自动化引擎：这类工具主要解决 DevOps 中的自动化过程的管理和执行。自动化工具一般都是提供一个引擎 各种插件。
Jenkins：这应该算是最常见也是最受欢迎的自动化引擎了，引擎简单可靠，可扩展性好，具备大量好用的插件，社区支持完善。
TeamCity：非常好用的企业级自动化平台，是老牌软件工具厂商 JetBrians 旗下的自动化引擎。我曾经非常喜欢 TeamCity 对单元测试的支持，因为它是第一个做到将测试信息聚合显示并做时间线跟踪的工具。
3、代码度量工具：这类工具一般被独立使用或者集成在以上的自动化引擎中，为团队提供持续的代码质量度量信息，帮助团队持续得到反馈。这类工具又可以可以分成静态检查工具和运行时检查工具。
SonarQube：一体化的代码度量平台，支持多种语言，大量可定制的度量数据采集器和规则。
Coverity：特别擅长 C/C /C# 等语言的静态代码检查工具，当然对其他主流语言也有很好的支持，内置的代码相似度检查非常有用。主打安全性检查。https://www.synopsys.com/software-integrity/security-testing/static-analysis-sast.html
Parasoft dottest：主流语言支持都很棒，包括：C/C /Java/.net。包括代码覆盖率和单元测试支持等运行时检查工具。
.NET Compiler Platform (Roslyn)：内置于.net 编译器中的动态代码分析引擎，可以在编程的同时对代码进行动态分析并给出建议。而且此工具也是开源的
FxCop/StyleCop：内置于 Visual Studio 中的静态代码检查工具。
CheckStyle/FindBugs/PMD：专注于 Java 平台的代码检查工具，非常多团队的默认选择，和 Jenkins 集成的非常多。
4、自动化测试工具：这类工具可以按照层次分成单元测试，自动化功能测试和性能测试这样 3 类。
单元测试框架：Junit, Nunit, Google Test，Xunit，Mocha，Jasmine 等。这类工具其实是编程框架，是开发人员用来快速创建单元测试代码的基础。
自动化功能测试：Selenium 和类似的 Appium 等工具。这类工具从 GUI 界面入手，模拟用户的行为并通过验证界面元素的状态来完成测试。
性能测试：Jmeter，LoadRunner，VisualStudio Load Test 等。这类工具一般通过对后端服务的 api 模拟用户行为，并配合一定 pattern 的压力模拟来完成对应用性能的测试。
5、环境和应用编排工具：其实这是两类解决不同层面问题的工具，一个是解决基础设施编排的，一类是解决应用编排的，但是从 DevOps 的角度来说，它们都一样，因为我真正需要的是应用，而不是基础设施。
Docker：这个不用解释了，DevOps 的兴起其实很大程度上是被 Docker 的热度带起来的。最近 Docker 发布了 LinuxKit 工具，其实已定程度上进入基础设施编排领域了，再加上 DockerSwarm 的成熟，其实已经是一个从集群管理，操作系统和应用的全面解决方案了。
Kubernetes(k8s)，ApacheMesos(dc/os) 和 Service Fabric：这几个加上 Docker Swarm 就构成了最近几年非常火热的编排平台阵营。从云平台的兴起到应用编排平台的火热，其实代表了 IT 界回归应用本身的过程。这些平台给企业带来了集群环境的统一化管理方案，对现代应用运维有非常巨大的推动作用，是每一个 IT 从业者都应该了解和熟悉的工具。
Chef/Puppet/PowerShell DSC：这些工具应该说和 Docker 解决了同样的问题，但是采用了不同的思路。类似的工具在 2010 年左右开始出现，极大的推动了 DevOps 实践中“环境获取能力”的提升，可以说是 DevOps 领域中第一批非常有价值的工具。
6、虚拟化和云平台：这类工具无需解释了，云平台是过去几年火热的话题。但是今天各大公有 / 私有云都已经成熟的环境下，企业怎样最大化云平台的价值才是重点。
公有云：微软 Azure, AWS，阿里云，青云等
私有云：微软 System Center/Azure Stack，OpenStack，vmware，KVM 等
最后想说的是，这里工具繁多，但没有任何一个工具可以说自己是 DevOps 的工具，就算是全生命周期管理平台也无法涵盖企业和团队的所有 DevOps 诉求。所以 DevOps 的工具选型永远是要搭建最适合自己的工具链，而这些工具的开放性就是最应该关心的问题。
StuQ 工作坊：我看到您是一位活跃的分享者，在 InfoQ 上发表过多篇备受欢迎的文章，6 月份也将和 StuQ 合作推出经典课程《DevOps 实战》，您通过这门课程想解决学员面临的哪些问题？这个课程的与众不同之处在哪里？
联系客服
