在10个鸡蛋上坐了3星期后，终于成功孵化出第一颗鸡蛋。
但礼仪小姐、导购小姐依然是场内的一道风景线。
声明：本文由入驻搜狐公众平台的作者撰写，除搜狐官方账号外，观点仅代表作者本人，不代表搜狐立场。
　　阿里巴巴对销售人员有一个硬性规定：每位销售人员每天必须要完成八个拜访。像北京这种交通拥堵严重的一线城市，几乎所有销售管理者都认为这是个不可能完成的任务，而阿里巴巴凭着这支执行力极强的队伍，快速获取了用户并抢占市场，造就了一系列奇迹：两千亿美金的市值、史上最大IPO、在杭州创造了一万个千万富翁……
　　阿里的运营、腾讯的产品、百度的技术都被津津乐道。阿里整套销售管理运营体系已被众多互联网公司作为标杆来学习。这支神奇的团队究竟是如何保证高效运作的？我们不妨从阿里销售军一天的工作说起。
　　阿里销售的一天
　　清晨伊始，阿里的销售团队即开始了充满挑战和机遇的一天。以北京为例，早晨八点，销售人员按照规定准时赶到公司。首先熟知当天的销售目标与客户信息等任务，半小时后，每个销售人员已经调整好状态，浩浩荡荡的销售团队开始踏上各种交通工具，群情激昂地散布到北京各个角落。
　　阿里对每日的销售拜访还有更深层次的要求，八个拜访中，至少有2~3个有效拜访，即销售人员必须要见到老板或其他高层，能够将有效商机很好的往前推进。另外，销售人员走进一座大厦或者一个办公楼园区完有效拜访后，还要在当前区域，尝试挖掘潜在客户进行陌生拜访，即销售体系中常说的“陌拜”、“扫楼”。在这一过程中，员工要努力获取客户的潜在信息，如相关负责人的联系方式、产品情况等。
　　下午六点，每位销售人员按要求回到公司，进行一小时的销售夕会――销售人员被分成若干小组，一同分享当天成果、得失和挑战。为提升团队的销售技巧，团队会对一些销售难点进行演练。
　　夕会结束，销售人员则要把八个拜访录入阿里的CRM系统，并标明客户访问状态，是有效拜访还是潜在客户。然而，如何保证销售录入的信息的真实性？阿里会有专门的品控团队会去抽查录入系统的信息的真实性，阿里的红线就是诚信。一旦发现某位员工信息造假，其立刻会被开除。接下来则是日报的提交等工作。做完这些工作后，已经是深夜，而每个销售还不能回家，而是搜索潜在客户资料，为第二天的拜访做好准备。
　　这是销售全天的工作，从早晨八点到晚上十点。因此在阿里内部有一个不成文的规定：所有的销售人员都住在公司附近，如此可以高效利用自己的时间；而且由于工作时间长，绝大多数销售都是单身汉。
　　如此，阿里的销售人员年复一年、日复一日在外面奔波，拜访无数的客户，每天重复相同的节奏紧凑工作……高压之下，阿里销售工资却并不高：2008年底薪约1500块，且公司不报销任何的交通费和通讯费，然而阿里巴巴“高提成”加独特的公司文化价值观的导致销售团队离职率并不高。
　　高效、精细的销售运作机制是铁军“利器”
　　全天紧凑且高效的工作，耐压性强以及激励机制营造了阿里充满挑战的销售文化和价值观体系，因此销售人员总能够热情澎湃去面对每一天的挑战。而巧妇难为无米之炊，阿里销售运作机制是怎么辅助销售人员完成高效任务的呢？
　　从销售与客户的初步接洽到合同回款，阿里将整个销售过程划分至十分精细的流程，销售人员只需按照步骤操作即可。首先，如何保证销售线索被高效跟进？阿里投下重金挖掘线索，阿里CRM系统将线索池中的销售线索分给销售后，若特定时间内销售并未跟进，线索则会被收回并分配给其他同事，如此无形之中就给一线销售施加压力，拿到线索后，必须尽快跟进：要么转换为客户，要么关掉销售线索。
　　其次，为保证线索分配合理性，管理层每天通过CRM为每个销售人员分得30~50个客户，若销售人员认为某条销售线索有更高的成单几率，可放进自己的私池，但同时需要从自己客户私池里退回相应数量的客户线索。这样做的好处是：一让销售人员集中精力到所分配到客户的身上，集中攻破最可能成单的潜在客户，提高成单几率；二是让没有任何资源积累的销售新人可以从销售线索池中提取线索，杜绝“销售大侠”大包大揽、而新人销售无处着手的现象。
　　遍地开花的阿里销售运营模式
　　也许很多人会疑惑，互联网公司需要销售团队干什么？比如，百度是搜索引擎公司，是以线上运作为主的B2C的公司，百度似乎不需要销售团队。事实上，百度销售团队由几千号天天打电话、拜访客户、接单的销售人员组成，也有着一套非常精细的运作机制的销售团队。若一个新公司刚注册，百度的销售团队便开始跟踪，一批销售人员会跟新公司进行推广方面的沟通，直到公司决定要在百度开账号。简言之，互联网公司B2C的一面是来获取用户的访问量，但只要是要向企业收费，就必然有B2B的一面。
　　从阿里销售铁军团队走里出来的人，经过严格销售管理运营机制培养出来的“铁人”离开阿里巴巴后也打造了销售奇迹。最典型的代表是美团的COO干嘉伟、滴滴出行创始人兼CEO程维。
　　地推之于团购类网站是命门所在，需要非常强大的线下团队的支撑。美团CEO王兴在美团成立之初，花了半年时间到杭州说服阿里当时B2B销售副总裁干嘉伟加入了创业团队，干嘉伟在阿里巴巴有着12年的销售经验。
　　干嘉伟许多打法带有阿里地推的影子，他大刀阔斧地进行销售团队改革，他将阿里整个的销售运作机制和体系带进美团。干嘉伟的加盟让美团在纷乱的团购大站中站稳脚跟，并迅速甩开对手。王兴也认为，美团销售团队的管理体系与信息系统的支撑结合在一起，形成了美团独特的销售管理运营机制，这是美团的核心竞争力。
　　滴滴出行创始人程维曾在阿里巴巴工作六年，一度是阿里最年轻的区域经理。在创业之初，做出“反其道而行之”的策略――以线下驱动为主要策略。在早期培养司机使用习惯、获取客户方面需要大量的销售工作，其通过地推团队邀请并帮助出租车安装滴滴打车客户端，并通过补贴激活司机使用滴滴打车。地推团队的高效工作迅速为滴滴出行建立起庞大的用户群体。2014年12月9日，滴滴出行宣布公司获得新一轮超过7亿美元的D轮融资。
　　众多互联网公司都有一个强大的销售团队，美团、滴滴的销售团队都是在阿里的这套销售运营和管理机制中快速打造出的行业领先的销售铁军，执行力极强的团队创造了一个个业界奇迹，强大的销售执行力是这个业务模式成功运作的关键。阿里的整个销售管理体系正在遍地开花，其模式给予B2B市场上销售管理者可借鉴销售经验的同时，创造了越来越多业界财富。
　　* 如果您对互联网现状及行业有不一样的见解，欢迎投稿至邮箱:
欢迎举报抄袭、转载、暴力色情及含有欺诈和虚假信息的不良文章。
请先登录再操作
请先登录再操作
微信扫一扫分享至朋友圈
搜狐公众平台官方账号
生活时尚&搭配博主 /生活时尚自媒体 /时尚类书籍作者
搜狐网教育频道官方账号
全球最大华文占星网站-专业研究星座命理及测算服务机构
本公众号定期推送互联网资讯热点、经典案例分析、各类干货下载...
主演：黄晓明/陈乔恩/乔任梁/谢君豪/吕佳容/戚迹
主演：陈晓/陈妍希/张馨予/杨明娜/毛晓彤/孙耀琦
主演：陈键锋/李依晓/张迪/郑亦桐/张明明/何彦霓
主演：尚格?云顿/乔?弗拉尼甘/Bianca Bree
主演：艾斯?库珀/ 查宁?塔图姆/ 乔纳?希尔
baby14岁写真曝光
李冰冰向成龙撒娇争宠
李湘遭闺蜜曝光旧爱
美女模特教老板走秀
曝搬砖男神奇葩择偶观
柳岩被迫成赚钱工具
大屁小P虐心恋
匆匆那年大结局
乔杉遭粉丝骚扰
男闺蜜的尴尬初夜
客服热线：86-10-
客服邮箱：1030人阅读
云栖大会上放出的观点成为这几日行业人士乃至社交网络上的热议话题，包括马云的主题演讲。马云在这场主题演讲中，只字未提“阿里云”，但这并不说明阿里云不重要，而是在某种意义上来讲，阿里云“从0到1”的阶段已经完成了。
在10月13日杭州云栖大会开幕当天，马云发表了就上一财年致股东信，信中提及，“阿里云承载了中国35%的网站并为之提供云计算和大数据的服务，而截至日的阿里财报显示阿里云拥有超过230万用户，其中云计算付费用户达50万。”
从2009年2月写下阿里云的第一段代码开始，阿里云上上下下的负责人们就一直在试图解释阿里云到底是什么。成立七年的阿里云的业务逻辑是什么？现任阿里云首席架构师唐洪、阿里云资深技术总监李津通过密密麻麻的图表清晰地做出了解析。
三句话道破阿里云的天机
阿里云的核心人物王坚最近出版了一本书《在线》。王坚自2008年9月加入阿里任阿里巴巴集团任首席架构师，2009年9月创建阿里云计算公司并任总裁，现任阿里巴巴集团技术委员会主席。
王坚和其团队自主研发的大规模分布式计算系统“飞天”，是阿里云的核心，建立了互联网规模的通用计算平台，完成了云计算公共服务的商业化。
阿里巴巴集团技术委员会主席王坚
《在线》一书中，王坚对过去8年自主技术创新道路进行了反思与总结。摘出书中三句话，就能从根本上说清楚阿里云的本质以及过去与未来：
1、从某种意义上来说，“飞天”就是一个操作系统，操作系统最重要的功能就是资源管理。
“飞天”的底层是数据中心，有成千上万台通用服务器，每台服务器都有CPU（中央处理器）、内存、存储，相互之间用以太网进行连接，这套系统简单说就是把所有资源抽象成一台计算机，并通过互联网提供计算服务。
2、这样的底层架构与亚马逊差别很大。
亚马逊对外提供的每一个服务都会直接对应一个或多个物理集群，比如A集群对于S3（亚马逊云存储服务），B集群对于EC2（亚马逊云弹性计算服务），它的功能和系统计算是垂直的。&而阿里云所有的服务对应的都是同一个系统内核、同一套分布式文件系统。&也就是说，无论对象存储、弹性计算、邮件、搜索等，都共用同一个底层。除阿里云外，世界上只有谷歌能够做到这一点。
3、“飞天”系统是一个规模很大的有机整体。
规模很大带来的最大挑战在于这台“超级计算机”每天都可能发生故障——硬盘会坏、风扇会坏、内存会坏，“可能自己买一台笔记本电脑用了5年之后依旧完好无损，但是在成千上万台服务器的‘飞天’集群里面，硬件故障时时刻刻都会发生。”
再进一步精炼总结的话，如果把全世界的计算资源看成是一台庞大的虚拟计算机的话，阿里云的核心“飞天”就是这台虚拟计算机的操作系统，而“内存”、“硬盘”、“显卡”等都是由巨大的通用服务器集群组成。阿里云除了核心“飞天”操作系统外，还向上提供云服务版本的中间件、安全、文件系统、数据库以及面向应用的通用API等高级服务。用户使用阿里云的方法却很简单，只需要通用浏览器或通用API简单调用即可。
除了谷歌外，微软云也是同样的思路。
阿里云就是这样一个永远“在线”的软硬一体的虚拟计算机，这个虚拟计算机庞大到了每个人都生活在其中却感觉不到它的存在——当然，这不仅仅是阿里云的终极梦想，亚马逊云、谷歌云、微软云三大巨头都在朝同一个方向实践。
描述下阿里云的规模：百万级服务器、单集群1万台的“有机体”
既然阿里云“飞天”系统是一个规模很大的有机整体，这个有机体目前到底有多大？综合今年杭州的“云栖大会”上阿里云提供的各种资料，可以初步描绘出这个有机体的规模：
百万台级服务器的连接能力，单集群可达1万台的规模，10万个进程达毫秒级响应；十亿级文件数，EB级别存储空间；全球15个数据中心区域；“飞天”全球用户数达到230万，遍布全球200多个国家和地区；提供面向22个行业的108个解决方案。
简单的对比，亚马逊云与微软云目前都是百万台服务器级别的规模，亚马逊云在全球有17个数据中心区域、35个可用区域（AZ），微软云有34个数据中心区域，而谷歌虽然自身达千万台服务器级别但只有一小部分对外提供公有云服务。
按阿里云资深技术总监李津在本届杭州云栖大会上的说法，从规模来看，阿里云与亚马逊云已经没有多大的差距。
飞天系统与PC系统的逻辑对比
因此，在过去的7年时间里，阿里云一直在发布这个庞大体系的不同组件，并且在把不同的组件连接起来形成一个有机体。
众所周知，传统操作系统在升级硬件的时候需要重启系统，而阿里云在升级飞天的时候却不能“重启”——这个很好理解，阿里云已经与社会经济息息相连，必须7*24小时不间断在线。
另外一个问题是：这样的一个有“生命”的有机是怎么自我调节、自我平衡、部分组织自我重生的呢？
根据唐洪的介绍，阿里云的生命机理就是阿里云的自动化运维系统“天基”。在“天基”看来，系统里每一台机器都无时无刻地处在部署、升级、迁移以及各个状态的转换中，“天基”在整个系统运行中精准地控制每个进程、每个组件的状态，从而控制每个系统的状态。
“天基”采用了一个面向恢复的计算模型。每台由“天基”管理的机器上会定期向“天基”发送自己的状态，而“天基”还维护一个系统预期的状态，“天基”会定期地比较预期状态和当前状态，根据其差别来制定出详细的执行计划并下发到“天基”的执行AGENT机器上，通过这样的过程迭代使得整个系统的状态逐步逼近到预期状态。
而在离线应用与在线应用的系统资源混合管理方面，阿里云会将离线应用和在线应用放在同一个集群上，当在线应用比较空闲时就将资源分配调度离线应用，当在线应用的负载比较高时就将资源从离线应用“抢占”过来。这样既可以保证整个系统资源的利用率，也可以确保在线服务的质量。通过这两个策略，可以将集群中日常资源的使用率从5%提升至54%、将集群峰值的利用率从22%提升至64%。
云的“生命机制”可以概括为从无到有、从小到大。为了保证用户业务的不间断以及阿里云的组织更新，阿里云曾经创造了全球首例整体机房带业务热搬迁，也就是说，“整个机房带着用户不停顿的业务搬迁到新址，形象的说法就是开着汽车换轮子、开着飞机换引擎。”
然而，一旦阿里云的所有必要组件全部都对外发布出来而且已经彼此互连成合体的话，这个有机整体就可以脱离人工的管理，而由机器自治。李津介绍说，目前他的团队已经在把深度学习等人工智能算法用于阿里云基础设施的自我管理，由机器自己探测并自动修复故障。
与社会化应用协同进化的逻辑
回顾阿里云7年的发展，还有一个重要的逻辑：不断用真实世界的应用来刺激阿里云的生长。
阿里云的早期阶段，由于大量用户把自己的应用架设到阿里云上，但早期的阿里云因为经常宕机而导致一片骂声，可以说阿里云就是被“炮轰”长大的，甚至有一个博客网站专门记录阿里云的各种问题。
在《在线》这本书中，&其实收录了不少“炮轰”阿里云的报道，包括阿里集团内部也一度因为是否要把核心应用搬到阿里云上而爆发激烈争吵。
到今天，尽管阿里云依然会出现问题，但出现问题的几率已经大幅降低。可以说明这一点的就是阿里巴巴正在把自己内部的核心应用、甚至每年的「双11」这样的高难度挑战，都逐渐迁移到了阿里云上。
当一个企业的云服务达到一定规模，产生了巨大的规模经济效益后，对于其使用者来说，最直接的好处就是获得了不小的降价空间。&阿里巴巴集团2016财报显示，过去一年里阿里云曾17次下调云服务的价格。
2016杭州云栖大会介绍了杭州城市大脑项目
国内开源界，阿里巴巴也是最大贡献者之一。在开源方面，本次杭州云栖大会上 AliSQL 正式开放了源代码的下载。AliSQL是阿里巴巴基于开源数据库MySQL官方版本的一个分支，应用于阿里巴巴集团业务以及阿里云数据库服务，目前由阿里云数据库团队维护。阿里云在AliSQL上进行了300多个改进，包括针对电商秒杀、物联网大数据压缩、金融数据安全等场景提供个性化解决方案。
随着阿里云在技术上的成熟，现有的阿里内部应用以及社会上的应用已经不能满足进一步“刺激”阿里云的未来成长的作用，如何通过社会化力量来反哺云服务呢？
阿里巴巴在杭州立项的“城市大脑”是其中一个尝试。“城市大脑”，&主要是把人工智能用于城市治理，成为整个城市的人工智能中枢，让城市能够自我调节、与人类更好的互动，交通道路优化与管理是第一个挑战的课题。
“城市大脑”由五大系统组成——超大规模计算平台、数据采集系统、数据交换中心、开放算法平台、数据应用平台；阿里云的人工智能引擎ET还为“城市大脑”其它四大系统提供人工智能内核。
举个例子来说，杭州城区内5万多路视频摄像头都将成为这个“城市大脑”的数据来源。从2016年3月开始，杭州交警、城管、建委等11个政府部门和西湖区，以及阿里巴巴、华三通信、富士康等13家企业的上百名人员，聚集在云栖小镇进行研发。
如此大规模的研发目前取得了一定成果。据悉，9月在杭州萧山区部分路段的初步试验中，城市大脑通过智能调节红绿灯，车辆通行速度最高提升了11%。
除了用人工智能优化和管理城市外，阿里云还在着力解决全社会物流挑战。阿里云和菜鸟网络合作推出的中国首个物流云平台“菜鸟物流云”就是在这方面的尝试。根据预测，未来的几年内中国日均包裹量很快突破1个亿，无法再依靠传统的人力劳动模式去送递包括，必须使用物流云来保证物流网络高效运转。因此，菜鸟网络 CTO 王文彬对媒体表示，未来物流行业的竞争力已经不是单纯依靠规模和价格的竞争了，技术竞争将成为关键。
目前阿里云平台上已经出现了单个ISV的年营收过千万人民币水平，李津则希望“能在不远的将来出现过亿元营收水平的软件企业”。而现在，正是企业级软件与服务创业的好机会，由于阿里云的成熟和230万使用者，再加上淘宝与天猫上数以亿计的活跃商户，任何SaaS软件都有机会触达这些潜在小企业用户，因此在未来很有可能出现中国自己的企业级软件巨头。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：795173次
积分：14386
积分：14386
排名：第698名
原创：689篇
转载：28篇
译文：16篇
评论：279条
(19)(40)(20)(26)(60)(53)(55)(46)(61)(58)(38)(47)(6)(3)(1)(18)(12)(4)(6)(13)(7)(3)(5)(5)(6)(2)(1)(2)(3)(4)(1)(21)(46)(38)(1)您所在的位置： &
前阿里员工技术分享：持续集成和“云”
前阿里员工技术分享：持续集成和“云”
本文作者在2009年至2015年4月曾就职于阿里，负责持续集成服务平台等相关技术工作。在本文中，他将对持续集成和“云”，就他的工作和个人对技术的思考进行分享。
今天的话题是，持续集成和&云&，主要部分是我之前两年的工作和我的一些个人思考。
这个话题我之前在中国的ruby大会上讲过，slides在这里 ，供参考，不过但是现在讲的内容根据最近多半年的工作进展又有所变化。
先自我介绍一下，我是软件工程师，从业13年，主要从事的领域都是应用系统开发，涉及OA、电信网管/增值业务、互联网等领域。
2009年底加入阿里，2015年4月离职，主要做的事情：广告应用系统 -& 运维自动化平台 -& 持续集成服务平台。
最后的持续集成服务平台是来自于实践需要，我最先在做广告业务系统的研发工作，广告系统虽然复杂，但是其中的应用系统从软件架构上看并没有什么特别的地方，所以希望将精力投在可以改进团队工作水平的地方。
一开始是一个运维自动化平台，由于团队人手有限，我基本是一个人做的，发现开发效率很好，软件质量也不错，所以在工作中总结了一些质量改进的实践，在团队中推广，这是我从研发进入QA的起点。
经过一段时间摸索，我们发现测试自动化搞不起来的原因之一是成本太高。
我之前习惯用ruby或者rails，所有的测试都可以单机完成，用cucumber这样的工具可以做BDD，用vagrant可以避免环境污染，所以自动化没问题。而java就没有这些条件了，数据库掌握在DBA手里，测试的linux是大家公用的，很容易引起冲突。
于是我和主管商量，决定搞一个平台，通过它降低研发成本，在本团队开展一段时间以后，又带着系统转到技术质量部，把CISE做大，测试部门成立了专门的团队，离职前已经开始在各bu和研发团队广泛运用
对CI的理解
持续集成平台究竟解决什么问题呢?
简单说，就是两个自动化：
构建自动化
测试自动化
测试自动化好理解，构建自动化比想象中要复杂一些，我一般用下面这张图来解释&&
我们手里的软件，总是可以进行不断地分解，从系统到模块，最后到类和方法。由于整体和部分的功能不能完全划等号，所以测试需要在各个层面上进行，但是这些测试的成本和收益有所不同。
如图，我之前感到java开发的痛苦，就源于工程师手中没有更上层的&武器&，所以只能在单测上用力。
所以，如果我们能做好更大尺度系统的自动化的构建，那么研发人员也就有机会使用&高层&的自动化测试，而避免在细节上写太多的用例。
但这个并不容易，我们的努力也只是起到了一部分作用。
下面说一下这个平台本身，由于涉及到阿里巴巴内部系统，有些是不能说的，不过还好，核心部分并没啥技术含量 :-)
很多人对CI的了解是基于jenkins，当然也有些人接触过travis CI或者circle CI，我们的系统更像后者，当然功能上要更强些。
平台的起点是公司的gitlab和svn服务，通过自动监控或者hook触发，每一次代码提交都会触发一个自动化过程，在这个过程中，平台负责分配虚拟机、数据库等必要资源，然后将代码编译打包构建运行。
编译打包构建运行看起来是一个自动化过程，但每个环节实际上都可以有验证&&这其实就是各种测试。
编译前可以做代码扫描(有的语言是编译后做代码扫描)
编译之后可以做单测
打包运行后可以做集成测试
和travis不同的是，如果目标涉及多个应用，之间存在服务调用，那么我们还会自动的将相关应用也部署好，然后在一个机器群里面做更接近真实场景的功能测试。
做过类似工作的同学一定知道这一点的代价有多大，但这样会有很大好处&&我们可以在一次commit后自动进行所有层面的测试&&从单测到系统交付测试。
当然这是理论上的，实际中可以根据研发团队需要进行选择。
总结一下，我们认为，CI平台应该能进行所有粒度的测试，最小针对函数，最大可以针对分布式系统。作为前提，CI平台需要支持整个系统的自动化构建。
这个大概是和travis CI之间最大的不同，下面再列几个不是很重要的区别。
1.使用云平台解决虚机问题，身在阿里巴巴，所以我们使用阿里云的ECS，需要资源是随时申请，用过以后立即释放重置。
这样可以解决环境污染的问题(即使是java应用，有些团队也会留下本地文件操作，这些东西会导致测试不可重复)。
2.数据库自动分配，我们构建了mysql集群，不过不是一般意义上的那种协作集群，而是一个数据库池，让数据库和虚机一样随用随取，用后重置。
这样做是为了让java程序员也可以像rails的db migration一样可以用到干净的数据库。
对这个平台的介绍就这些，下面讨论一些经验教训。
UI应该尽量轻
这个话题要和jenkins/hudson做对比，这两个系统我其实不是很熟，不过也知道它们都是很强大的自动化系统。但是，jenkins/hudson的最大问题是，它们的UI做的太多了，用户可以在UI上做很多事&&很多和CI没关系的事情。
举个例子：
jenkins的任务是可以排队调度的，而对于CI来说，排队是什么意思呢?研发工程师养成持续小步提交代码这个好习惯以后，又硬生生由于资源不足而被迫等待，最终可能会放弃这个好习惯，实在是不划算。
我们的办法是&&敞开供应，只要有代码提交就分配机器，当然有人会质疑，因为这会导致需要一个很大的资源后备池，不过这可能正是&云&时代的不同思考方式&&在&云&的时代，资源的使用毛刺应该通过大规模后备池来抹平。
当然，滥用资源还是要避免的，只是我们认为需要&后置惩罚&，比如通过审计，找出资源消耗大户，打他的板子 :-P
当我们把所有的额外功能都剥掉以后，发现UI其实就一个作用&&展现，因为CI需要的是完全的自动化，人工本来就不需要介入，只要最后被notify一下，或者偶尔过来在web上看看报表趋势什么的就够了。
CI是服务加最佳实践
我们理解的第二个经验就是，搞CI，是服务加最佳实践，所以一定要指导研发团队，而不能完全任由研发团队提要求，很多团队的工程师良莠不齐，对各种编程api比较熟悉，但是可能缺乏做事的好习惯，这时需要指导他们，当然前提是你也要对开发很了解才行，否则会被鄙视的
对CI来说，最大的常见麻烦是不写测试，这个一般是通过管理教育，比较简单。
另外一个隐藏的比较深&&开发人员对系统的运行并不了解，比如开发的系统运行在linux上，但是基本的命令都不会。
这个问题我们遇到了挑战，有人认为这涉及到分工，研发工程师不应该了解线上，但是这个观点是有问题的。
因为很多bug和环境相关，如果开发人员不能在&真&的环境中尝试，一旦系统报错，很难不发生扯皮&&这个扯皮可能发生在开发和测试之间，更可怕的是发生在线上，光定位就需要N多人参与，成本极大。
最后是插件的问题，这个说来简单&&插件能解决一些问题，不过插件设计之初实际上就限制了其使用，所以我总结的教训就是：先别急着做插件，想好了设计再动手。
先进一步谈谈对CI平台职责的理解，然后结合这些理解最后说说&云&和docker的作用
CI平台的职责
关于CI平台的职责，我上次已经提过，基本上就是这些：
构建自动化：提供环境
测试自动化：提供平台
构建工作主要产出两个东西：最终输出的软件包和待测的应用系统(有时后者会包含前者)，这两个产出的核心要点有所不同。
最终输出的软件包大多数公司都会做的，重点是构建过程环境无关而且可重复，因此需要提供配管服务，比如最好有yum、npm、gem等软件包服务。
但是这里有个问题&&间接依赖的软件包如何锁定的问题，ruby的bundle机制很不错，通过Gemfile.lock让依赖包都有明确的版本(而不是&最新版本&这种含糊的说法)，但是maven就没有这样的支持，目前没有很好地办法，只能让构建号和软件包号建立关联，便于回溯。
而待测的应用系统是比较难的地方，它也需要配管系统支持，同时还需要资源的就绪能力，一个关键要点是&&资源必须是隔离的，否则很难避免测试时互相干扰。
这个隔离应该做到什么程度呢?举个例子，我们为了进行系统联调，自动构建了一套涉及N个系统的集群，这个集群是为了进行自动的联调测试。而理论上我们如果需要，CI平台应该可以再构建另一个集群，各种架构细节和前一个集群完全相同，但这两个集群进行工作时应该互不影响。
这要求应用需要符合一些最佳实践的要求，比如12 factor里面说的不要硬编码ip地址等等
为什么要这样?因为持续集成是不断前进的工作节奏，一个人的工作有了阶段性结果后，需要进行验证，这种验证应该是独立的，如果和其他人共享测试环境，要么测试结果不稳定，要么变成我上次说到的排队，那就降低了效率。
这两张图说的就是这个意思，同一团队的两个程序员公用数据库进行测试，测试结果就会不稳定，同样，如果他们的应用依赖了另一个公共服务，那么测试依然不能稳定。
不知道第二种情况会不会难以理解，简单说就是那个公共服务也是有存储的，所以那个数据库里面的数据会造成干扰。
构建自动化比较复杂，而测试自动化相对来说简单一些，不过这里的重点是对各种测试的抽象和区分
根据上次分享的反馈，发现有相当多的人不太理解这张图。
我们把测试分为UT/FT/IT/ST等等，但其实它们可以抽象成一个东西&&都是对某个软件单元的验证，区别在于单元的粒度
补充说明一下上面说的一些名词：
UT：单元测试
FT：功能测试
IT：集成测试
ST：系统测试
所谓的&上层用例变化慢&，是相对的，因为应用系统常常是需求一变，整个推翻，所以上层需求用例的变化常常带来下层大量用例的变化，而反之则未必.
考虑到需求和测试用例直接联系很紧密，我们可以认为需求用例的变动频率和测试用例的变动正相关。
当然，测试自动化还有一个要做的工作是对结果的分析汇总，主要是各种测试手段的输出千差万别，需要进行数据汇总，这个和普通的数据处理没啥区别，我也不是这方面的专家，就不献丑了。
但是，作为CI平台，对结果数据的分析汇总要建立在测试阶段的界定上，简单说就是要明确区分UT、IT等环节阶段，这是后续报表很重要的信息，不能小看。
CI职责讲完了，我下面想说一下自己对&云&在CI方面价值的理解&&简单说就是标准化。
CI的自动化测试和普通测试一样，有天生就要面对的问题：
bug确认(可重现)
测试的真实性
先说bug确认的困难，在测试团队待过的人一般都能理解问题确认有多麻烦，很多的bug是辛辛苦苦发现的，结果被开发同学一句&环境不一样&就打发了。
所以测试非常需要标准的环境，而这正是&云&可以提供的，要是进一步考虑自动化测试，那是比普通测试更需要标准环境的场合，因为它是无人值守的，对意外的适应能力更弱。
代码覆盖也是测试的一个重要指标，几乎所有的开发语言和框架都有不止一个代码测试覆盖率统计工具，而代码覆盖其实是涉及到测试层次的，在上层测试一个系统，往往能够覆盖不少下层用例，如果能从多个层次测试系统，可以让工作事半功倍。
最后再说一下测试的真实性，这里是指对mock技术的使用。我们很多时候使用mock技术只有一个原因&&对方系统太难打交道了，所以做个mock先绕开(有时需要模拟对端错误，这种情况还是需要mock的)。
但是真实情况下我们访问的不是白板方法，这么做的有风险，最后还是要联调，所以这种情况是把测试推后了，是转移矛盾而不是解决矛盾。
我之前做的CI平台，正是想通过云技术，可以相对低成本的构建&全部系统&，因为(借助我们的平台)有时候这个做法比mock要简单，更重要的是，这种做法肯定比mock要真实。
以上都是云的价值，也是docker的价值，不过docker有个独特的价值，就是有可能将测试甚至运维工作变成服务。
这里说的服务不是那种在公司里某个部门为其它团队提供的服务平台，那很容易模糊边界(比如开发要求测试帮忙等等)。
这里的服务是指成立公司，把这些工作变成business的东西
当然，这块其实不稀奇，我之前说过的Traivs
CI、shippable、coding应该都在做，docker创业团队大多都在做这个，不过我想说的是&&为什么这事变得可行了?
这是由于标准化，一个应用应该是个什么样子?在docker的语境中是比较一致的，这为用户和服务平台提供了相对简单的协作边界。
举个例子，这是我们平台自己的一个模块在进行自动化构建时写到描述文件(相当于 .tavis.yml)中的内容：
prepare:&exec:&-&yum&remove&taobao-jdk&-q&-y&-&yum&install&-b&test&ali-jdk&-y&-q&-&echo&'export&PATH=/xxxxxx/bin:$PATH'&&&&/etc/bashrc&-&echo&'export&JAVA_HOME=/xxxxxx/java'&&&&/etc/bashrc&-&yum&install&jemalloc&-b&current&-y&-q&-&yum&remove&mysql*&ruby19&-y&-q&-&yum&install&mysql-devel&-y&-q&-&yum&install&ruby21&-b&test&-y&-q&-&echo&/usr/local/lib&&&&/etc/ld.so.conf.d/ruby21.conf&-&ldconfig&-v&-&gem&sources&-r&https:&
这么一大坨，我不相信会有人能受得了，但是如果在docker中呢?
prepare:&exec:&-&docker&build&-t&xxxxx&.&
这样还符合我之前说的原则&&开发人员自己管理环境
在这种变化下，我觉得我们做的东西可以大幅度简化，以至于变为一个对外服务的business，根据这个想法，我自己做了一点简单的尝试，不过是用青云做的，录了两段很短的视频，在这里：
/v_show/id_XODAzNzgyMjUy.html
/v_show/id_XODAzNzgxOTky.html
我要讲的基本上就这些，今天应该没超时，最后关于docker上的CI再多说两句，提个想法&&docker应该依靠但不依赖IAAS。
借助SDN，避免通过Docker来划分安全域：我看了一点最近docker大会的介绍，老实说，有一种观点是把vm废掉，我是不以为然的，所谓vm所带来的成本其实正是我们获得安全隔离的原因，这两者是一体的，我们直接拿来用vm做安全隔离最好，让docker解决安全问题应该是一条歧路。
深度依赖compose机制，建立联调/系统测试的构建标准：应该会有很多人和我想的一样&&将compose.yml作为重要信息来源，外部的系统通过它理解应用间的联系，即使不使用
docker compose 这个软件，也应该遵循 compose.yml
的规范，这样我们不但能让单兵(容器)的外部边界清晰，还能让战阵(分布式系统)也能被管控系统理解和支撑。
深度依赖compose需要让compose.yml目的变得纯粹些，我知道compose描述的内容很容易变成&不同环境&，其实这个想法也许不正确，我认为一个git分支就对应一种场景&&比如某些分支是用来开发局部功能的，它不需要系统测试和联调，而master必然要联调&&所以不用在代码中留下多份
compose_xxx.yml ，而应该在不同分支上编写不同的 compose.yml ，其内容由分支维护者负责。
分享人李建业，前阿里巴巴员工（花名：李福），2002年本科毕业，之后一直从事软件开发，涉及办公自动化、电信网管/增值业务系统以及互联网；2009年12月加入淘宝的广告应用开发团队；从2011年底开始，关注软件研发本身，主要工作包括运维自动化系统和持续集成服务平台。
原文链接：
【编辑推荐】【责任编辑： TEL：（010）】
关于&&&&的更多文章
本书介绍最新的VMware虚拟化与云计算软件VMware Workstation 9、
180天的Windows Server 2012试用版下载（标准版或数据中心版）
讲师： 789人学习过讲师： 4085人学习过讲师： 3451人学习过
甲骨文全球大会于日至26日在美国旧金山举
微软公司于今年8月23日正式宣布，CEO史蒂夫?鲍尔默将
日，IBM宣布与首都在线签署公有云长期战略
本书描述的是在逆向与反逆向之间展开的一场旷日持久的拉锯战。作者Eldad Eilam以一个解说人的身份为我们详尽地评述了双方使用的
51CTO旗下网站