DevOps 与开发者转型

DevOps 并不是什么新的概念，落地国内开发社区已经有几年时间了，但是关于 DevOps 如何真正帮助开发者实现转型、为企业真正创造价值的话题，一直都在持续讨论。最近，IBM Rational 产品开发和用户支持全球副总裁 Salvatore Vella 在 IBM 2014 技术峰会上针对这个话题进行了深入的阐述和分析。

现在的开发周期变得越来越快，其推动力来自于客户的反馈，同时要兼顾速度和信息的平衡，有时候更新速度越开越好，但对于银行来说，可能 3 个月一次就够了。这里涉及到评价 DevOps 的两个维度:

第一个是效率，如何在这个系统中消除冗余的部分。你可以思考一下一些项目，在每一个迭代之后你能不能够把这个应用到生产上面去或者有没有这样的人工的工作，我们要把人工的工作全部去除，全部自动化。

另外一点要问我们是不是在做正确的事情，我们需要得到反馈，反馈可以来自于绩效评估工具，也有可能是情感的分析。同时还有一些可能是客户在使用过程中宕机报告等等，它都可以给你一个方向，就是怎么样来做正确的事情。

Salvatore 指出，企业的持续能力，能够让企业实现交付，让企业获得市场机遇，减少获得客户的反馈时间，持续的软件交付、持续的开发部署，能够看到市场机遇，而且能够减少获得客户反馈的时间，客户的反馈能够帮助开发者走到下一步。

我们有四个 DevOps 要素，我们把 DevOps 看作是端到端的流程，是整个开发过程，所以首先是领域，我们必须了解下一步要做什么，将其视为你对于从客户那获得反馈的一种反应，它告诉你下一步该怎么做。我们还有开发测试，这里主要是指协作式的团队合作。我们意识到可能会有业务伙伴这里参与到开发过程中，不仅仅是一个团队的竖井式的工作，还有高度自动化的测试。还包括生产系统。实际上来说这个领域，也许你做的很糟，当然你有机会去改善。因为有很多的手工工作并不需要人工做。还有运维，包括监测、灾难恢复、反馈信息，然后是一个环路过程。

这里有几个情况，首先，DevOps 有两点，一个就是效率，就是能够更好的做我们的工作，剔除那些手工工作，使得它更为简单，能够让我们更好地提高工作质量。这里还有一些年度规划，基于产品、基于事实的回馈。还有开发测试，不是一种流程密集型的，而是更多关注自动化部署，手工部署。遗憾的是，今天很多手工部署都已经进入自动化了。这是很幸运的一点。我们可以试一下将基础设施当做代码来用，从竖井式的环境中很多团队彼此独立的工作，要让他们彼此之间协作。在下一步会看到，就是为了能够增加生产效率高的工作，减少浪费。

IBM 内部也在进行 DevOps 的转型和变革，Salvatore 指出：“在整个公司中我们都会做自己的开发，这里确实很多机遇帮助我们改进，进行协同式的工作。有效性也是很重要的一点。持续的反馈是很重要的一点，有了云应用，就能够实时获得关于应用的反馈，我们有这样的机会建立一些假设，不同的设计，并且进行不同的试验，这是很好的机会，我们应该应用。但持续的回馈还是很重要的，能够帮助我们持续的开发。你需要从现在开始做 DevOps，我们需要一个路线图。很多的材料都已经在网络上可以提供给大家。它的起点是将技术业务进行融合，进行转变，包括运维、业务。如何做我们的工作，我们应该要这些团队合作，在变革中达成一致的意见。第二，对目前的状态进行分析。我们有在线的工具，你可以去进行评估，你和你的团队进行这个工作，我把它认为是我们做的一个全面工作，这可以帮助我们很好地了解我们目前所做的工作质量如何。还有其他的一些元素，有哪些元素是我们浪费的，有哪些没有被自动化，哪些是手动的。有多少进行了部署，有多少手动工作可以进行自动化，这都是工作重点。然后还要实施，在 IBM 内部进行变革转型的时候我们开始做这个工作，我们认为必须要强迫人们做这个工作，但发现结果并不是这样，其实大家非常希望改进他们自己的工作质量，我们有一万员工加入这个行动当中，所以并不是说人们不知道他们遇到的问题，实际上需要公司帮助他们做这个工作，我也鼓励大家启动这个程序。”

关于转型中的挑战，Salvatore 给出了自己的经验：

如果你在一个大企业工作的话，你也会意识到这样的挑战。比如复杂性的挑战，因为现在有来自于不同的人或者是不同部门的各种各样的功能，这非常复杂。第二就是团队的挑战，因为现在有团队在地理上是各地分布的。还有流程的挑战，我们希望一个团队能够思考实验的方法，然后把这种实验应用到实际中去，这对我们来说是很大的挑战。我们还面临工具方面的挑战，工具的挑战非常有意思，我有责任开发各种各样的工具。实际上工具非常有意思。我们现在看到的就是一个工具箱，也就是我们所准备的一系列的工具，包括一些脚本和开源工具。他们可能在第一天的时候很好，到一千天或者两千天的时候就出现了问题，独特的工具就变成了债务，因为人们开始有新的岗位，产品也变化了，所以我们提供的工具也作为服务来提供，这样内部团队就可以使用一系列的共同的工具，你不需要担心这个工具不能更新。我们有一些 DevOps 的服务在 Bluemix 当中得到应用，在功能方面是提供更多，我们把它作为一系列的、一套的工具来使用。

最后，Salvatore 举了一些改进的例子，包括 STG、Watson 等部门：比如，STG 是我们的硬件部门，它们有很多内嵌的软件，我们可以看一下它带来的进展。在使用了相关的工具和技术之后，我们得到的结果。我们的集成测试从每两个月变成一天一次，我们的构建到内部使用的周期从过去的 14 天到现在的 3 小时，部署时间从 5 小时降低到 5 分钟。这是非常重大的、可见的益处，很多人工工作消除了，所以效率提高了很多。大家都听说过 Watson，我们在不断地改进 Watson 的流程。我们一开始做 Watson 的时候，它的迭代时间是 9 周，9 周才能迭代一次。我们就采用了一些我们管理的工具把它降到了 3 周。我们又去努力，把它变成了 1 天时间。所以巨大的进展，迭代时间变得更短、速度变得更快，也消除了很多浪费的节点。