开篇
腾讯SNG（社交网络事业群，后简称“SNG”）事业群担负着QQ、Qzone、QQ音乐和相册等核心社交产品运营，从运营的这些产品就能看出部门的历史。笔者没有进入腾讯前在北京工作过多年，记得在2010左右北京的各种IT大会风起云涌当时可以看到各大公司分享自己的架构与运维理念但很少能看见腾讯的分享，当时很纳闷为什么看不到腾讯分享，多年后走进腾讯当年很多疑惑慢慢揭开了神秘的面纱。
从架构层级上腾讯和很多公司相同即接入、逻辑和存储但腾讯BG(Bussiness Group 事业群，后简称“BG”)制，外人可以理解BG为腾讯内部子公司，彼此有独立的方向、业务与架构，不同的BG架构不同（接入、逻辑和存储）， 与其他公司不同的是，腾讯在各BG架构上又多了一层“大存储”即（接入、逻辑、存储（短期）、存储（长期） ），这里大存储指各BG数据最终落到统一的BG下，即TEG(技术工程事业群)。以SNG为例接入使用qzhttp（web服务）逻辑之间调用关系用了l5（名字服务），程序开发有spp框架， 数据间传输使用了私有协议，存储使用了MySQL和一些自研的数据存储，可以看到腾讯这里走出了一条有自己特色的道路，它更多使用的是自研组件和私有协议，这也就解释了之前笔者的疑惑为什么很少看见腾讯的分享原因。相比很多公司使用开源组建在基础上做二次开发，但腾讯更多是学习开源组建再开发，区别是后者配置文件些许区别维护学习上有一定成本，但优势更加适合业务使用，足够的轻量级和安全，但问题是业务的需求量有限很多自研组建放慢迭代脚步，甚至停滞迭代。
那为什么腾讯内部的工具不走开源路线呢？ 开源接受的市场更多的需求，需要持续的打磨与迭代， 这问题也是笔者在入职腾讯后一直的疑惑 直到一次公司技术分享A同事的一个问题，A同事大概问的意思是腾讯现在在互联网行业内有一定的影响力与同等公司相比开源做的并不是很好，这是为什么？ 当时公司CTO(首席技术官，英文Chief Technology Officer，即企业内负责技术的最高负责人)张志东是这样回答的。首先对A同事问题的肯定，也介绍了这里的背景，早年腾讯业务爆发式增长工程师更多的精力是应对需求以及当业务发生故障时去救火，再者考虑的就是开源软件对数据安全的问题，如果本身能力未达到应用开源软件后遇到风险不能快速解决结果是致命性的。 这两点笔者身有体会特别是随着互联快速发展，网络安全很重要往各种暴库（csdn 索尼）等事件，做过一个公司的CTO需要更加关注用户数据的安全，这也是我们公司的底线用户安全置上。但Tony也说随着腾讯各个业务步入正轨我们也逐渐考虑去做一开源的工作，鼓励各BG开源。老板的一句话给我们带来更多的思考是如何去开源？ 而开源的前题也是如何更好的使用开源的工具在基础上有机会再开源，所以当时笔者也在想自己的业务上去寻找一些场景适合开源工具的解决方案。
Docker缘
2014年什么最火，相信很多人会说是Docker ，它诞生于2013年，感觉它的诞生就是一鸣惊人且有不断蔓延趋势，国内很多技术分享也谈了很多Docker的发展趋势应用案例等。2014年底笔者接手了一些长尾业务，由于部门对机器低负载考核比较严格，所以当时也试着将一些高负载业务与低负载业务进行混合部署，混合部署、虚拟化是很多公司解决成本问题的一些手段，像网上经常看到Google很早之前就在用容器技术来实现业务间的混合部署， 当时公司也有很多BG以各种方式实现了不同业务间的混合部署，而由于SNG历史背景的原因很多业务还没有实现混合部署。笔者当时负责系统运营情况，在没有隔离情况下的这种混合部署方案并不好，因为高负载与低负载的业务混部在一起特别是晚高峰期一个大CPU毛刺就会影响到低负载业务从而导致线上投诉，所以在2014底和2015年初借鉴了其他BG的玩法，在部分场景下我们开始通过Docker来实现我们业务间的混合部署，实践证明这种混部要比前者更好，经过2015年一整年系统的开发与迭代初见规模，我们内部称呼为“琥珀离线系统”把高负载业务与低负载业务混部同时，也将高负载业务部署到了部门与公司的Buffer、数据库备机和低负载等资源上，如果业务使用Buffer资源系统，通过建设的系统能力可以将业务请求迅速的从Buffer上调走， 就这样我们把部分业务迁移到了Docker上。
2015年下半年到2016上半年社交类业务出现了很多转码的需求，转码是用户从PC上传视频通过服务器进行格式与码率的转换在其他终端（ipad，手机）上都能看到，通过我们Docker + buffer 、低负载形式再次解决了这类业务的需求，为部门解决了大量的成本，Docker离线再一次进入应用的小高峰。
这时老板们也提出了更高的要求，是否可以实现在线的Docker化，毕竟离线底层用的是Buffer 、低负载资源是有一定天花板的，因为在海量运维中这些资源占比可能连10%都不到，2016年上半年我们开始做在线Docker研究。
我们做了内部的研究与需求调研，在过程中也经过N轮的PK有人同意有人反对，记得有次一位同事说我们的运营效率可以在分分钟扩容千台机器，什么上Docker？
答：因为，Docker宣称（Build， Ship and Run Any App， Anywhere!） 它通过镜像串联了开发的整个路径，并保障线上的一致性，你可以把镜像看作App，它可以运行在内部云和公有云上，方便业务以后在各种云上快速的拓展。
同事：那织云（内部运营系统）在打磨一下也可以实现类似的这功能，为什么还要上Docker？
答： 额。。。。
其实当时笔者心里的想法是，是啊其实我们早实现这功能再稍改造就可以，但为什么火的不是我们而是Docker呢？ 值得思考。。。
最终还是决定试探性的来用Docker管理在线服务，Docker这么火而且已经有成功的内部案例，但为什么是试探性这么没底气？
开篇的时候讲过我们有很重的历史背景，在这种历史背景下没有最牛逼的工具，只有最适合我们的工具，很多创业公司把Docker玩得转因为没有任何历史的包袱，所以这里我们只能说是试探性来玩Docker，看它是否符合业务需求，还有另外还有一些原因：
刚的对话中已经说明了，内部运营系统早就支持了类似镜像功能，为什么还火的不是织云而是Docker ? 3分产品7分也运营，我想这也是Daocloud（Docker母公司）把Docker当作产品去做，所以这是我们值得学习的。
很多公司都在搞Docker，当一个新员工入职，你和他说织云，他会问什么是织云，但你说docker很多人会知道，所以不管什么技术，如果他能形成一套“协议”就会让彼此间更好的去沟通。
内部虚拟化也应用了Kvm，做弹性扩缩容Docker比Kvm更加的轻量级，在社交类业务中镜像有突发流量增长和计算的场景都很适合用Docker。
部门的运维的质量、效率、成本和安全都做的非常好，如果能以得分衡量应该是98分，但是对追求极致的我们需要的是100分，所以我们要关注开源产品、使用开源产品来寻找自研产品的不足
笔者曾经看过一篇文章《 为什么要探索宇宙》 文章大意：
1970年，赞比亚修女 Mary Jucunda 给 Ernst Stuhlinger 博士写了一封信，他因在火星之旅工程中的原创性研究，成为 NASA（美国航空航天局）Marshall 太空航行中心的科学副总监。信中，Mary Jucunda 修女问道：目前地球上还有这么多小孩子吃不上饭，他怎么能舍得为远在火星的项目花费数十亿美元。结论是探索宇宙可以带来相关产业的发展，太空探索就像一面人类审视自己的镜子，利远大于弊。
相信探索在线Docker与为什么要探索宇宙是一样的。
探索在线Docker起航
设定短期的目标准备起航了，但在起航前就像这幅小漫画（图1 ），看着很简单的目标其实有很多深水区，我们需要做好一定的心里准备。
从中心下各组抽了一些热心同事，2016年4月份开工在线Docker。 作为运维最不好管控的就是时间前一秒在做项目，突然一个故障立即处理，处理完回过来忘记从哪开始做起刚有头绪又收到新的需求，所以我们需要一套管控手段来保证项目的目标与进度。首先，时间上每个人每天拿出30%来搞项目，其次我们引入了Scrum(敏捷开发框架) 来管理项目， 它的好处就是能在一段时间内，有一个共同目标，大家向着目标不断的跟进持续打磨，信息尽量的彼此间透明，最终保障短期目标与质量。
前期很多事物在探索阶段整体看Scrum带来的收益还是不错的，我们发现了很多问题，这里有Docker本身问题、还有也有部门运营系统问题，低层系统的问题，在线系统上线了300+ 容器运行过程中Docker本身并没有太大的问题。 一个小插曲一台母机上运行了多个容器，其中有的容器是测试机有的容器是在线服务器，某工程师登录测试容器修改了系统时间，由于Docker隔离型不是十分的好，导致整个母机时间都被更改影响各业务，这并不影响在线Docker持续探索，但也提醒我们如果拿整套在线Docker技术方案来做一个产品的化，我们需要一个产品的准入的规则，譬如小明家买了一个洗衣机，洗衣机对小明来说是一个产品，小明并没有看洗衣机的说明说就把衣服放入洗衣机，最终衣服大于洗衣机承载重量导致洗衣机的报废，同样在线Docker也需要一套说明书即准入规则、注意事项、测试过程中发现的问题、案例和潜在风险等，如果超出了准入规则的不准许接入，否则与洗衣机的结局是差不多的。
运营了一段时间Scrum我们也发现了一些问题， Scrum可以解决一个小团队的问题，但我们需要依赖其他团队时从效率上看就没那么好了，如果Scrum两周为一周期，小团队在一周期内可以解决10件事，而涉及到依赖就只可能解决一件事，因为每个团队有自己的重点及KPI，遇到这种情况Scrum也是无能为力 。
小团队作战
像Scrum应用中发现他解决不了的问题的案例，在一个大的公司中更多的讲究是团队作战群策群力一个需求来了后对他做需求分析，并拆分需求分给不同团队提升需求的效率和质量。每个部门，每个团队，每个人都是有KPI （关键绩效指标 ，英文全称 “Key Performance Indicator”），KPI的优势是不同环节认同一个目标并持续推进保证收益， 团队与团队之前的协作如果KPI是一致的那事情推进会非常顺利反之只能像Linux进程一样陷入中断状态。
在这样背景下Scrum可以很好的解决小团队KPI目标、进度、质量，但与其他部门合作交集太多就无能为力了。在线Docker正是这样情况，当你申请其他团队资源时，在KPI的背景下首先被问的目标与收益是否明确，也正因为是探索型项目这些问题很容易被挑战，更多的时间在PK目标与收益。但要知道Google的GFS最初也只有三个人设计开发出来的，所以这种探索型产品前期需尽量少的人参与，与其他团队尽量的解耦 ，短期带来的问题可能是系统的重复建设，长期的收益是整个生态链质量的提升是值得的。笔者也在想Docker离线为什么会成功？ 原因也是开始团队比较小很多问题在内部可以很快的解决，时间上保障项目进度，同时也令大家的成就感更愿意去投入。
设立项目目标及流程负责人
经过一个月的试探，到5月底我们大概掌握了业务Docker在线相关系统的一些问题，解决问题同时也在并行实现Docker在线系统的产品化。 开始讲过参与Docker在线同学来自不同组，结合自己的业务大家从不同的视角希望Docker能带来更多的改善。其实大家的目标是一致的做Docker在线，但过抵达目标的过程却有很多分歧，有分歧是好事做一个产品如果连分歧都不没有就太没成就感了，但此项目就是分歧太多了且都有道理，怎么办？
解决分歧更好的方式是拿案例来表明自己的想法正确的。PK案例：
现有流程 ： 测试-> pkg (软件包管理系统) ->预发布 -> 线上系统
改造流程: 测试机-> pkg ->预发布 （构建镜像机） -> 镜像仓库 -> 线上系统
旧系统问题：历史原因导致 od未分离，开发可以任意登录线上系统导致系统配置不一致，当预发布环境有问题时，可以任意选择线上机器配置反录入到pkg系统再次发布，相当于给od为分离打了一个补丁。
改造后流程 ： 预发布构建镜像后，由镜像保持整体链条环境一致性 。但历史原因导致我们的用户（运维/开发）习惯，扩容时是任意选择一台参考机来发布的，分歧就是改造后流程省略了选择这一步，而且首次选预发布机器后为了保障镜像里垃圾信息最少，后续不可以更改预发布机器， 有的同学就会疑问为什么不保持原有习惯？预发布机故障怎么办？ 就这样一个案例PK了多次，最终还是保持改造后的流程方案。
PK是有必要的，但多次PK就会拉长战线和时间，再加上各种需求就会导致小团队每天很忙接需求，PK需求一段时间过去并没有什么起色，大家对项目的成就感也会打折。Docker在线项目成员来自不同的组，大家一起搞Docker在线形成了虚拟组，其实开始我们就忽略了虚拟组的技术负责，经常出现意见不一致开会PK没有结果再PK浪费时间的情况。有了技术负责人后，它来帮我们屏蔽不合理需求，当遇到问题不断PK时能及时站出给出方向加以解决，保障短期目标，同时提升大家项目中的成就感。
每天晚上5:00大家都需要碰头沟通Docker在线的进度与问题，有意思的是经过一段时间大家都认为自己负责的环节已经OK了，但整体串联起来就有问题。我们分析了一下原因原来是这样，我们每个人负责的是在线Docker生产链上的一个环节如图2，一个在线Docker包含了多个环节，当自己负责的环节流程1没有问题也就确认自己是没有问题的，结合之前的结果看并没有什么问题。 但成功并仅仅需要自己的成功还要确保自己下游、下游的下游全部成功才可以，所以需要每个人对系统的流程负责，当自己的环节或自己下游环节出现问题需要主动把问题抛出来，同时尽快推进问题的解决。
用数据来证明
5-6月底我们通过运营系统在逐步小规模上量验证Docker玩法的可行性，但是随着时间推移发现量并没有快速的上升，原因是资源有限每天在串行的上量，系统的扩容流程一旦发生问题只能停滞待问题解决后再继续。开始感觉经过一段时间量没有上去，没有上去的原因自己也说不清楚，所以当时一直在思考为什么自己也说不清楚，因为流程不稳定错误每天都在发生，每天发生完当时解决完就完了，没有沉淀数据也看不到全局数据能看到哪里的问题比较多。 邮件是一个很好的工具针对这种情况，我们沉淀了所有的日问题数据，并在每周5进行分类汇总，对分类后的结果进行排序，并根据排序的原因设定负责人推进。 经过一段时间数据的沉淀大概能分析出一些问题主要分两类：
运营系统设计的目标和准入标准
1.1 部门之前一直在提一键运维，从这个目标上看运营系统确实已经达到了，但Docker的扩缩容目标更多的是无人值守运维，目标显然是与目前项目不契合的导致在上量过程中遇到了很多问题。
1.2 我们运营系统设计过程中的一个重要环节借鉴了Unix设计哲学中的思路，即一切接文件，通过管道来串联文件的输入和输出关系，这也说的是我们运营系统中的流程系统。由于历史原因导致流程系统的环节很长通常扩容一批机器需要16+以上步骤，而流程长就会间接导致成功率的低，从Docker小规模上量过程中期表象更多是运营系统的问题因为他直接暴露给用户，但实际更多是后端错综复杂的逻辑没有接入标准导致流程系统的不稳定。在一个大的系统中需要保证自己成功率的同时，依赖系统也要有严格的准入标准，并通过数据来找出问题，设定责任人并推进优化改善，同时尽量的减少流程环节。
“是业务符合架构还是架构符合业务”
笔者时常在思考这个问题，有意思的是笔者在部门中两个角色都做，相信站在不同的角度的答案也是不一样的，笔者之前做过业务所以站在业务的角度希望更多的是架构来符合业务，因为部门负责业务产品比较多每个产品都有快速发展的时候，如果跟不上发展将会被淘汰所以更希望架构来符合业务，实际上从运营系统发展历程上也能看到很多历史的影子 。 而目前笔者从事的是架构，更多希望是业务来符合架构，原因是在实际运营过程中发现运营系统和架构在符合各自产品标准上已经慢慢没有了自己的标准，导致系统臃肿与效率的下降， 另外很多人已经习惯了这种架构符合业务的方式，而最难改变的就是用户习惯，我们能做到的只能是增加架构与业务间彼此沟通，制定架构的准入标准，尽量满足业务的需求，并持续的完善与迭代，这里有一个模式可以借鉴就是微软的windows系列，推翻老的系统不断的更新操作系统的大版本，在实际运营过程中，发现问题再打补丁，同时系统尽量向下兼容，满足客户的需要。
参考
1）Docker历史 http://www.oschina.net/news/57838/docker-dotcloud
2） 为什么要探索宇宙 https://www.douban.com/note/321442729/
3）Google 全球研发总监访谈 http://news.cnblogs.com/n/542090/