作者介绍
李建业，前阿里巴巴员工（花名：李福），2002年本科毕业，之后一直从事软件开发，涉及办公自动化、电信网管/增值业务系统以及互联网；2009年12月加入淘宝的广告应用开发团队；从2011年底开始，关注软件研发本身，主要工作包括运维自动化系统和持续集成服务平台。
写在前面
几个月之前，偶然看到了老庄的一篇博客——《如何评价一个新技术 》，讨论了docker是一个什么级别的发明：
上次与霍炬聊天，霍炬提到他在跟陈皓抬杠，陈皓认为Docker与Java是一个级别的发明，第二年就吸引了所有热门公司的加入。而霍炬认为这太夸张了，毕竟就是个配置管理器嘛！而我的评价，可能会比陈皓的更高，我认为Docker比Java的级别还要高。而且，这与有多少公司参与无关。甚至可以反过来说：因为Docker极为重要，才会有那么多的公司，在***时间加入进来。
当时我发了一条微信朋友圈用来备忘：
看来还是要写篇文章才能讨论docker的价值，先说个基本思路——分析这个问题，至少要从“人与人的协作方式”这个角度来谈才算到位，docker对此的改变甚至超过java，起码达到linux的水平…详细讨论稍后再写。
然而真打算写点东西的时候，却发现这个问题是个大坑，如果从头讲起并交代细节，那远不是一篇文章能涵盖的，加上我又是个懒惰的人，所以拖延至今。
不过，讨论的困难主要在于建立一个客观合理的评估框架，因此本文的很大篇幅都是在做这件事，欢迎读者对这个评估框架本身提出意见。
当然，如果读者没有耐心，也可以跳过前面几节，直接看***一节。
1. 明确重点
我们从一个问题说起——分析一个技术的价值，应该怎么入手？
我们所说的价值，其核心是商业价值（在现代社会，所有的价值最终都会由市场从商业角度来体现），而商业活动是否成功，无非是两个角度：
- 寻找正确的市场需求
- 用低于同行的成本效益比在竞争中获胜
技术对角度二的意义很好理解，因为它可以帮助提升效率或者降低成本。不过，技术对角度一也有帮助——本质上，商业活动是一种对未来需求的预测，但是我们并不能真的未卜先知，而先进的技术可以帮助我们尽早而廉价的实现一个商业雏形，便于尽早获得市场的反馈。
因此，这两个角度中，技术的作用都是在提升效率或者降低成本。
ok，现在明确讨论重点——
- 提升效率
- 降低成本
2. 效率问题
说到效率，会有一些人想到软件的执行效率，然而这不是我关注的地方：
软件的执行效率最多只是用户要关心的非功能需求，而且它的影响只是一部分软件和系统（甚至对这些软件和系统而言，也不是所有用户都关注执行效率），不是全局性质的问题。
而另外一种效率，生产效率，则不然，这是影响所有软件和系统研发的问题，是全局性的（这也符合我们上面对商业成功的讨论）。当然，在软件和互联网企业，我们说的生产效率一般就是研发效率。
因此，能够直接提升研发效率的技术就显得特别有价值。例如：
语言的自动内存管理减轻了程序员的工作量，以及各种抽象技术成倍甚至在数量级上减少了开发同样功能所需的代码行数，这些都是很好的例子。
Docker在这方面能做什么呢？无能为力，因为这不是Docker的发力点。
Docker这种技术，不能直接提升研发效率，它的价值是间接体现的，重点在对研发流程上各环节的优化整合。
记得刚用Rails的时候我震惊于它的开发效率，曾经和前公司（不是阿里）老板有过一次讨论（老板是做技术出身，对研发很了解）。
这次讨论中，老板和我一起分析了一个功能从需求到用户使用的各个环节。***结果低于预期。我同时意识到：
软件开发环节只是所有工作的一部分，即使这块提升效率，对总时间的提升比例也并没有我想得那么大。
这并不是说Rails这样的技术没有用。但是，这确实启发我考虑研发的整个流程，从这个角度看效率才能更全面，判断才更清楚。
本系列前几篇文章中已经提到过，开发、测试、运维三个主要环节存在信息不一致的情况，Docker对此有比较好的解决办法。
现在我们从提升研发效率的角度再看这件事，你会发现，解决了信息不一致的问题以后，下一步改进的重点会很自然的是：加强研发测试。
因为之前的开发没有动力做太多的测试，没有条件进行更大粒度的测试，更不可能推进自动化联调。
而由于Docker的出现，开发一方面需要了解线上环境，另一方面则可以借助新的变化直接进行原来只有测试才会进行的一些大粒度的自动化测试，更由于已经转变为devops，线上变更变得更简单可信，上线周期也能得到压缩。
测试前置的结果就是提升研发流程整体效率，线上变更周期缩短更是能显著影响软件特性的交付效率。
上面说的内容很容易会让人想到“精英团队”、“全栈工程师”甚至是“个人代替团队”这些话题，不过也有人对此不感冒：
因为并不是任何时候我们都能用小团队解决问题，有些场景的分工是不可避免的。
这时候我们有可能借助技术来提升个体的工作效率吗？
很遗憾，分工导致的单个成员效率下降是个普遍规律，理论上就不太可能用技术的手段改变它。
不过，对于分工的场景，技术却能在另一个方面发挥价值——降低边界上的开销，也就是我们下面要说的——
#p#
3. 成本问题
说起成本，人们一般都会想到机器、房租、员工工资等等，但是这些东西要么差别不大，要么不会成为竞争优势（因为借鉴起来比较容易），所以不是关键。
真正可以成为企业核心竞争力的成本，是企业为了发挥每个人的价值而需要付出的代价：
有时，企业通过技术革新可以降低某些方面的成本——比如优化算法降低机器数量，但是这里的竞争优势并不是机器成本，而是企业的持续创新能力，说白了，是员工持续的创造力，因此我把这种竞争优势归为员工能力，此时的关键依然是发挥员工价值。
企业是什么？是将一个一个思想不同、看法各异、技术习惯不同的人凝聚起来的组织。而人与人的相互配合、密切协作，往往需要一些（广义上的）管理手段，这都需要人力物力投入。
另外，某些管理手段还会对个人生产力产生压制，这些是要付出的代价，在经济学上一般称之为“管理费用”：
这个“管理费用”基于一个根本问题——“一个企业用什么方式将人凝聚起来”，回答这个问题会受限于每个企业的不同风格（也有人称之为企业文化），很难借鉴和仿效，因此可以成为企业的竞争优势。
听起来这是个纯粹的组织和管理问题，其实不然，人与人之间的协作，***的困难就在于边界不清，信息费用高昂，而这是技术可以有所发挥的地方。
这包括纵横两个方面：
- 纵向：软件研发的链路上，至少包括三个主要环节——开发、测试、运维，分工以后，这些环节之间的扯皮和信息不畅就是增加管理费用的一大原因，因此标准化这些环节，将有机会降低沟通成本，提升沟通效率。
- 横向：即团队协作，软件和系统扩张的过程中必然发生团队分裂，这时就会产生团队间信息不充分的问题。这个问题甚至比纵向更严重，因为至少从目前看来，纵向的问题还有全栈团队这条路可以走，而横向基本无解，如果能够降低这个费用，那么总的管理费用将被有效控制。
4. 小结
根据上面的分析，我们可以简单把技术在软件系统开发中的全局性价值归纳为三条：
- 整合流程，减少生产环节，提升个人的控制范围，以提高单个人在总流程上的生产效率；
- 标准化流程上各环节之间的协作，降低沟通成本；
- 减少横向团队间需要传递的信息，降低沟通成本。
5. 对比几种技术的价值
基于上面的讨论框架，我们下面看看几种技术：
强调一下，一个技术的价值是多样的，在其发展的不同阶段还会有变化，而本文目前讨论的仅限于“全局性”的和主要发展阶段中体现的价值。
Java(tm)
java的全局性价值来自于它的跨平台能力，当它出现以后，程序员可以很容易在windows上开发一些运行在linux上的软件系统。
关于跨平台
其实很多语言都可以进行某种角度的跨平台，但代价不同(比如c/c++需要重新编译)，而且在java之前，几乎所有的语言都遇到不同OS的库不同的情况，这为跨平台设置了很大的障碍。
java是***个“一次编译，到处运行”的工程语言，并且自带的jdk与平台无关（由于jni很难用加上java社区语言纯洁性的文化影响，各种第三方的java库也是平台无关）
在java出现的年代，windows平台上有很多优秀的IDE，形成了对其它OS平台的压倒性优势，加上windows GUI对新手的友好性，很多人的工作平台都是windows。
而另一方面，unix/linux在server端的优势也很明显，这使得研发工作和软件运行的基础平台产生了割裂。
在此背景下，java的跨平台就导致了一个结果——整合了（在windows上进行的）开发活动和（在linux上进行的）运维活动。
但是java平台一开始没能做到跨语言，因此对横向的团队协同帮助有限（协作主要局限在同样采用了java技术栈的团队间，基于J2EE应用服务器规范，适用范围较窄），所以java的全局性价值仅仅是第二条（标准化流程上各环节之间的协作）。
GNU/Linux
通常所说的Linux应该是包括GNU的（Linux内核补上了GNU计划的短板），不过我们这里简称为Linux，它使得各种UNIX的差异逐渐退出市场，在服务端领域，程序员只要开发兼容它的代码即可。
各种linux发布版也会有差异，但是这些差异已经不是难以克服的了
这个变化的好处是，不同的服务端开发团队可以比较容易的交流，本团队培养的工程师理解其它团队的线上环境也简单了很多。
此时，Linux的价值是体现在上述全局价值的第三条（减少横向团队间需要传递的信息）。
接着，Linux/GNU进一步发展，甚至在一部分程序员群体中开始成为主要工作平台，对于开发、测试、运维三环节开始有了一体化支持的征兆，这样让Linux的价值又扩展到了上述的第二条全局价值。
然而这个价值要打折扣：
- 各种服务端技术虽然都使用Linux作为基准的OS，但是运维和管理方法还是有很多差异，导致有时横向协作还是会有影响。
- 使用Linux作为开发平台的程序员还是比较有限，而且有一部分工程师并没有掌握这个平台，用Linux做桌面并没有改善对测试和线上环境的熟悉程度，因此各环节的沟通成本依然较高。
因此总的来说，Linux占据了全局价值的后两条，但有不足。
docker
说到这里，其实已经不必再对Docker浪费过多的笔墨，它算是秉承了Linux的灵魂。同时，它的标准化为多应用协作提供了方便，多应用背后是多团队，这就在实质上是为团队间合作建立了方便之门。
因此，它先天就占据了全局价值的后两条，并且比Linux做的还要好。
与此同时，Docker提升了个人的能力覆盖范围，由于线上和开发环境有可能一致，因此工程师可以用较低的代价实现devops，这一点对应了全局价值的***条（整合流程，减少生产环节）。
因此我们的结论是，Docker的价值不是在于某个点上的突破，它改变的是人与人之间的协作方式，这包括：
- 个人：Docker提高了个体战斗力，使个人有可能结合云技术实现以前需要多人完成的工作，消除部分协作。
- 纵向：Docker对软件研发三环节建立了协作基础，通过标准化，环节之间的扯皮被降低，节省了沟通成本，提升了沟通效率。
- 横向：由于Docker对各种技术栈提供了统一的管控方式，降低了团队间协作成本。
综上，***再重复一下我的结论——
Docker研发的价值超过java，起码达到Linux的水平。
如何一起愉快地发展
高效运维系列微信群是国内高端运维圈子、运维行业垂直社交的典范。现有会员1000余名，其中运维总监及以上级别会员300多名。
“高效运维”公众号值得您的关注，作为高效运维系列微信群的唯一官方公众号，每周发表多篇干货满满的原创好文：来自于系列群的讨论精华、运维讲坛线上/线下活动精彩分享及部分群友原创。“高效运维”也是互联网专栏《高效运维***实践》及运维2.0官方公众号。
提示：目前高效运维两个微信主群仅有少量珍贵席位，如您愿意，可添加萧田国个人微信号 xiaotianguo 为好友，进行申请；或申请加入我们技术交流群（技术讨论为主，没有主群那么多规矩，更热闹）。
重要提示：除非事先获得授权，请在本公众号发布2天后，才能转载本文。尊重知识，请必须全文转载，并包括本行及如下二维码。
