[QCon讲稿实录]谈高质量架构产品化输出

本文是《2016 Qcon北京》运维专场开场讲稿实录，讲阿里聚石塔TAE团队如何做高质量架构产品输出

大家早上好，我是智宇，来自阿里巴巴商家业务事业部。很高兴能今天能在运维专场的开场给大家分享一下聚石塔容器系统运维。在进入正题前我先简单介绍一下聚石塔。聚石塔是阿里巴巴电商云平台，主要是面向整个阿里电商生态，提供带有电商属性的云服务。大家知道围绕着阿里电商生态有传统概念的买家，卖家之外，还有品牌商，服务商和ISV也就是独立软开发商等角色。除了阿里巴巴提供的基础的电商服务外，这些中小卖家，品牌商在运营中的一些个性化的需求其实是非常多样化的，举个例子，比如雅诗兰黛把他的天猫旗舰店和原有CRM系统做对接，比如优衣库希望通过游戏的方式给用户发优惠券，可以说是千奇百怪，这些多样化的需求单纯靠平台方是很难很好的满足。所以阿里生态中有开发能力的品牌商，服务商，以及ISV都需要开发软件，来和阿里的系统做对接，那这些软件，就是跑在聚石塔上面。目前聚石塔服务了几乎所有的淘宝商家，97%以上的订单都是跑在聚石塔上面。可以说聚石塔是商家业务的基石。
聚石塔作为阿里电商云平台，除了提供基于阿里云的基础IaaS云服务之外，主要提供了许多电商PaaS类服务，比如业务相关的电子面单，订单推送，比如数据相关的御膳房，当然也提供了PaaS容器服务，这个也是今天分享的主题，聚石塔容器服务EWS，那么为什么要做容器服务? 为什么要做EWS。EWS究竟是做什么的，这里面我想先讲讲需求和背景信息。
EWS是从TAE （Taobao AppEngine）演进过来的，最早TAE1.0定位为安全容器，用于解决聚石塔上的数据安全和站内安全问题。这里举个例子，大家知道淘宝上商家会产生很多数据，这个数据其实是属于商家自己的，那第三方软件开发商开发软件比如营销软件，签到软件是卖给很多商家使用，我即卖给ao史密斯，也卖给李宁。那么如何保证这些商家的数据不被第三方软件开发商滥用，或者只能在授权的情况下使用，这就是TAE1.0要解决的数据安全问题。再举个例子，很多开发商开发的软件，比如抽奖插件，这些都是运行在淘宝店铺页面上的，如果这些开发商开发的软件存在xss,sql注入等一些漏洞，那么就会被不法分子利用，这样就会对淘宝造成非常大的负面影响。所以TAE1.0主要在安全方面做了很多的工作。但主要还是针对一些Web程序。随着业务的发展，用户的系统架构也在升级，单纯的Web应用无法满足用户需求。用户的程序逐渐从2层架构，演进到了三层架构。数据库不光需要Mysql了，还需要缓存，还需要mongodb，通信也需要总线化，也需要消息队列。所以针对这种需求，TAE2.0主要是做了支持三层体系架构的PaaS，也就是全架构PaaS，TAE2.0全面的服务了阿里百川无线开放平台，就在昨天阿里百川也和InfoQ达成了战略合作。在去年的年中，我们发现用户的需求又发生了变化，PaaS形态的封闭性，已经不能适应用户的需求。比如对多机房容灾，异地多活，弹性计算有了更高的要求。尤其是去年发生了多起IDC故障，用户对高可靠系统架构的需求格外高。所以针对这种情况，我们又推出了EWS服务，目的让用户能够简单的获取高质量架构的能力。

首先来看一下EWS 的业务架构，EWS的全称是Enterprise Workstation,叫企业工作站。主要三个层次，底层是基于阿里云基础服务，中间是聚石塔和容器平台，包含御城河，云盾安全服务，主要做安全防护。提供多语言的容器服务。并且配套镜像服务，多Region弹性计算服务，以及可视化运维系统。整体构成了一套企业高质量架构产品化解决方案。最上面是业务。可以看到分成了两部分，左边是针对ISV的一些开放业务，这些业务都是第三方开发软件运行的淘宝环境，比如店铺模块儿，阿里百川，满天星。大家如果喝可乐的时候扫过上面的二维码，跳转到一些活动页面，就是满天星业务，就在EWS上面。当然，除了服务ISV,EWS也服务了很多淘宝内部的业务，右边的一部分是一些内部系统，比如多媒体服务，订单推送，APM服务等。

由于既服务站内业务，也服务ISV，这里我们就发现了一个很有意思的现象，就是内部系统的需求和外部系统需求不一样，我们满足需求的模式也不一样。首先看看ISV用户。一般ISV要开发一个工具，或者参加一个活动。他们的要求是快速开发，快速上线，投入也不多就是2，3个开发。系统架构也不标准化，什么语言都有，java，php，nodejs，c#非常多样化。另外呢本身他们的系统架构能力还是一般的。但对于平台方来讲，由于它是跑在淘宝环境，用户认为这是淘宝的服务，那么当然我们就要求这些服务有着淘宝系统的质量。一个希望又快又省钱，另一个希望又猛又持久，好像是天生的矛盾。再加上第三方开发人员水平参差不齐，这个怎么解？我们服务了这么多ISV后，总结了一下方法，归结成叫做“老中医模式”。用户来了之后，先看他系统架构，就像老中医号脉一样，手一搭脉，眉头就一皱，语重心长的说：“恩，年轻人，你得补补肾啊”。 ISV一听急了：“什么，我今晚就要入洞房，你现在让我补肾。” 老中医缕了一下胡须，淡定的说：“恩，莫慌，待老夫给你一剂猛药。” 然后就什么千年雪莲，万年人参统统用上了，最后结账的时候，ISV总说我五行缺钱。这个其实像极了ISV的接入过程。审架构就像号脉，ISV肾虚那就是性能压测过不了关。猛药就是加机器。但这种模型很难批量复制。那么怎么才能做成产品化的解决方案，不用老中医号脉了呢。我们先暂且不表。花开两朵，咱们再来看看内部业务需求如何满足。
EWS也服务了很多站内系统。比如订单推送。淘宝97%的订单跑在聚石塔上，就今天的具体情况来讲，淘宝97%的订单其实是跑在EWS上面的。针对这种内部大客户，我们总结叫“老鸨模式”，其实也就是经济人模式。好比一个歌手，身怀绝技，但就是没名气，形象没包装过，也没有粉丝，在这个年代光靠硬碰硬刚正面是不够的，所以还要立体化的包装。拿订单推送举例，在EWS之前，还是单Region模式，进入EWS之后就是多Region模式。在EWS之前整体的管控还是基于服务器包发布，到EWS后变成了可以支持容器标签发布。这样做按Region，按标签灰度就变得非常简单，镜像发布又让交付变的更加标准。所以这种经济人模式，就是把身怀绝技但不出世的高手包装成明星的模式。这个也有一个好处，你想ladygaga都是我旗下艺人，你过来吧，把你包装成国际巨星。对EWS也是一样，淘宝97%的订单都在EWS上了，那其他想成为Lady GAGA的业务不得蜂拥而至吗，那直播，APM，顽兔多媒体也都在EWS帮助下实现了异地多活，弹性计算的高质量，和高灵活运维。你只需要写高质量的程序，把高质量的架构交给EWS。
当既具备了老中医的能力，又具备了经纪人的能力后。我们就思考一件事情。就是一个系统是怎么一步一步从最简单的架构变成高质量架构的，这是我们在服务了上千开发者，以及服务站内大型用户的基础上总结出来的一套演进路线。由于成本，业务发展，人员素质等综合因素，一个业务系统基本上都会经历着5个步骤，典型的从最早两层裸奔，到最后具备单元化服务的路径。首先是一定是一个两层结构，第一阶段Web+数据库我们叫做两层裸奔。第二阶段增加了简单的负载均衡，数据库的灾备，并且接入CDN。第三步当业务发展到一定阶段，网络上纯http短链接的方式已经很难满足业务需求，那么会增加长连接，中间会增加缓存和消息队列。第四步由于业务高可用要求，基本会把各个功能性的服务，服务化。比如数据库增加DB Proxy 比如缓存增加Cache Proxy，这样可以做到不停服数据升级，包括阿里云的RDS 和 OCS核心也是基于一套Proxy的高可靠运维系统。第五阶段就是单元化，具备统一块存储能力，具备异地多活的能力，也就是淘宝现在具备的能力。
基于上面的铺垫，大家一定有这种感觉，如果每新建一个系统，都要这么演进，太费劲。能不能一步到位？能不能别一开始给我简易房，一步到位海景房。能不能让一个系统在建设初期就具备构建快速，发布灵活，运维简单。能不能直接具备多Region，负载均衡，弹性计算的能力。这个就是EWS的目标。最后我们把它总结为10个字。就是“高质量架构产品化输出”。输出的是什么，是能力，是内力，就像无崖子把一个甲子的功力给虚竹一样。在这里大家也肯定能想到，把自己系统建设成高质量已经是很难的事情了，那么把高质量架构作为一种能力输出，或者说把高质量架构做成一个产品，一定会更难。这个难事儿，就是EWS要做的事情。
那么EWS究竟要怎么做，才能做到高质量架构产品化输出呢？接下来我想讲一下EWS的技术实现。
开门见山，基于服务于阿里商家业务多年的经验，我们团队总结出了高质量架构系统在6个维度的20个能力。EWS正是基于这个方法论进行系统建设。这里面包含了“可靠性”：你的系统是不是具备异地多活，负载均衡的能力。“扩展能力”：是否具备弹性伸缩，海量扩展的能力。“性能”：是否在应用，链路，语言层面都有profile的能力。“可用性”：是否具备告警，健康检查，故障迁移，IP漂移，当然还有运维能力和安全能力。总共6个维度的20个能力。我在这里不一一讲每中能力怎么实现，但很明显，这20个能力中的每一个都是一个大命题，都不是开发一个两个模块儿就能实现的，都需要多系统配合来实现。那要怎么讲？先来看一下EWS的整体架构。

这是EWS的整体架构图，分了两个部分。左边是用户访问的runtime系统，右边是运维系统。在runtime系统里又分为上中下三个层次。最上面是统一接入层负责安全和负载均衡。最下面是日志和监控系统，值得一提的是整个日志和监控系统带有APM的功能。中间是核心管控系统，包括容器，分区管控系统，功能系统，中心管控系统。右边是运维，整体两部分一部分是给用户的运维控制台，另一部分是管控系统的运维控制台。大家看这里面大大小小的方块儿得有几十个，每一个背后都是一个系统。所以说高质量架构产品化输出光从工作量上就已经是很大了。就像航天工程一样，你能制作零件还不行，你还得能把这些零件集成在一起，让他变成航天飞机。下面我想分别从多Region异地多活，统一接入和安全，Overlay网络虚拟化，以及应用模型和弹性计算几个方面来说说如何把零件，变成航天飞机，如果把孤立的功能点变成高质量架构6个维度的20种能力。

大家还记不记得去年有几次极端的IDC故障，比如有个云服务商机房被雷劈，导致大规模机器重启，但机器启动不起来。为啥起不来，太多机器一起重启电压不够。还比如光缆被挖掘机挖断，本来是城市环网，带热备的，结果两根光缆埋在了一起，一铲子下去也环不起来了。出了这种事情，究竟是谁的责任？作为服务提供商当然不能怨天尤人，尤其是淘宝，大家就是认为系统挂了。所以对于系统来讲要具备异地多活的能力。目前淘宝主链路基本异地多活了。但是刚才说了，那些部署在聚石塔的ISV的系统怎么办？怎么让他们具备异地多活的能力？首先，你得有多个机房，目前EWS在北京，杭州，青岛，深圳，包括上海都有机房。有了机房后，还有把多机房部署能力输出给ISV。我怎么方便的多机房发布，怎么回滚，怎么灰度，这些都要考虑。很多团队都选择在半夜发系统，这个是规矩，有规矩当然是好事，但是随时随地发版本是一种能力，能够随时随地多Region的发版本更是一种高级能力。除此之外，还需要具备快速新建Region的能力，比如我希望有海外节点，你不能说新建个Region需要三个月。目前EWS管控一个新的IDC，从资源准备，部署，到测试上线，只需要不到三天。

我们发现，要把多Region能力输出给ISV，这是个哲学问题。你要让ISV的系统多Region，那么你自己的管控系统本身就得是多Region的。那你这套管控系统是不是要管控你自己呢，能不能管控你自己的？EWS多Region架构基本分了三层，最底层是中心管控，中间是分区管控，最上面是用户区管控。是一个典型的Master Slave架构。这里面所有的分区管控系统都是Region化部署，另外，由于分区和用户区之间有防火墙设置，EWS采用的长链的方式去做通信。这样保证能够穿透防火墙。长连接这种模式非常适合有公私网防火墙穿越要求的系统，比如直播，比如推送。我们所有系统在Region化的同时，也镜像化了。通过镜像来发布系统最大的好处是标准化。EWS镜像仓库也是主备模式，采用二级缓存和回原的方案，保证镜像的下载速度。针对海外Region，还提供了镜像加速。假如一个Region10个模块儿，每个模块儿2台机器，那么五个Region就100台机器，所以这种多Region的系统管理上也是非常大的挑战。这就要求又一个非常好用的发布系统。这里面又一个非常好玩的事情，就是EWS给用户提供的多Region发布系统，本身也是多Region发布的。又是一种鸡生蛋，蛋生鸡的感觉。EWS自己多Region发布通过镜像来做，这样标准化。之前又一个朋友在群里问我，你说我们用镜像发布好，还是用原来的发代码包的好。我说，如果你能够制定标准，你就镜像发布，如果你要服务ISV，还是要符合他们的习惯。现实情况是第三方开发商的需求就是多种多样了，EWS团队选择了满足他们，所以我们提供了包发布，Git发布，标签发布，回滚发布，镜像发布。这个在产品化上更贴心一些。

EWS提供的另外一个重要的功能，是统一接入层。统一接入层主要提供四方面的功能，第一域名管理，第二负载均衡，第三安全防护，第四健康检查。这四条其实是密不可分的。另外想要做优雅发布，弹性计算，发布系统和弹性计算系统也需要和接入层做紧密的对接。由于EWS服务的第三方程序都是运行在淘宝里面，所以一个统一的域名就很关键比如登录态保持，比如一些安全扫描，都是从统一的域名这个入口来的。接入层的负载均衡，最重要是避免了ISV自己搭建Nginx，这是架构标准化很关键的一环。架构标准化了才能够动态扩容。这样才能更好的支持双11这种场景。其实很多ISV不知道安全防护的重要性，我们有一个ISV他的一个工具在EWS部署了一套，站外还有一套，他一开是就抱怨，为什么要搞两套。结果被DDOS, 站外挂了不说，还损失了不小的一笔钱。所以统一接入层不光保护淘宝自己，更是在保护ISV。
目前EWS接入层支持http，和https。并且能够防DDOS，CC攻击，也能够对页面漏洞做扫描。整个集群可以支持到比较高的Qps访问量，具体数据不说了，不过昨天我看朋友圈说Uber接入层支持17wQps，EWS的接入层还是比Uber高了那么一点点。另外在发布，动态扩容，故障迁移等场景，接入层能做到域名到容器的路由毫秒级生效，这样其实是弹性计算能力的一个最基本的保障。否则你弹性扩容了10台机器，结果域名生效要10分钟，那这个就不叫具备弹性扩容的能力。另外，整个接入层也是Docker化的，我们进行扩容也是分钟级的。当现有容量撑不住的时候，可以在1个小时之内能将接入层能力提升一倍。当然现在的容量已经非常大了，但还是那句话，弹性计算是一种能力，只能你系统的每个环节都能弹性计算的，才叫具备了弹性计算的能力。弹性计算不是加机器这么简单的事儿。
那么什么样的系统才叫具备弹性计算的系统。我们总结最起码涉及三个方面“弹性扩容和缩容”，“系统编排和混部”，“健康检查和迁移”。弹性扩容和缩就包括：“优雅发布和不停服升级、垂直扩容和水平扩容、手动弹性和自动规则弹性”。系统编排和混部包括：“系统构建、多应用混部、多维度的编排”。健康检查迁移包括：“机器故障检查，应用故障检查、有状态迁移和无状态迁移、手动故障恢复以及自动故障恢复”。每一个都是一个大命题，没有个需要多兵种配合完成。所以我将，现在对外宣传的通用弹性计算，基本都是伪弹性计算，因为没有业务语义的弹性计算只能扩机器而已。

要支持弹性计算，最重要是什么？我们觉得，首先要有一个好的系统模型。这个是EWS系统模型架构图，EWS系统模型在运维维度分为Region,Zone,App 在开发维度分为 Service，Node，每个Node里面是Container，Container里面的行为一直的程序。Contaienr可以分布在不同的Host上。其中不同的Node，可以组成类似Kubernetes POD概念。

Kubernetes的模型设计是被人津津乐道的，尤其是Pod的概念。但EWS整体的模型还是从需求来的，每一个模型角色都在现实中有对应的场景。并且一定是已经生产化的场景。最后总结下来EWS和Kubernetes在很多方面有异曲同工的意思，很多角色能一一对应上，比如Node,比如Service，比如支持Pod概念（在Pod的行为上EWS有一定的取舍，比如EWS要求Pod里面的行为是固定的），虽然在细节上有区别，但整体理念上是处于同一层次。我的理解，一个武当，一个少林罢了。但核心区别上我觉的有三点，EWS在调度层面以Contianer为主，以Node为辅。 EWS引入了运维段模型，就是Region，Zone，和App的概念。另外，EWS不强调块儿存储，不强调Volume，强调有状态服务化，比如存储都用RDS，OCS，OSS。孰优孰劣不评价，但EWS是目前生产环境使用比较广泛，我们支持了淘宝97%的订单，支持了所有无线第三方软件并服务了几百万的淘宝商家。在做的各位，只要你用过淘宝，我相信EWS也间接服务过你们。

刚才讲到弹性计算，弹性计算有一个很大的命题就是网络虚拟化。这里面又有一个IP漂移的命题。就是当服务器down掉了，或者硬件过保了。你势必会涉及到迁移的问题。无状态的服务还好说，那么那些有状态的服务怎么办。IP地址变了是不是代码也要跟着变？这是个很大的问题。如果没有这个问题，Docker原有的Host和Nat模式已经能很好的服务了。但什么才叫真正的弹性计算，能够把IP、端口、域名这些网络资源变成无状态资源。才叫真正的弹性计算，才能达到真正的弹性计算。现有的网络设备的大二层方案其实已经有了设备层的IP漂移方案，但现实问题是，一个机房的建设一定会有很多历史包袱，他一定有很多批次的交换机，路由器，况且在国内的网络环境下，很难构建一个真正的大二层网络。基本都是三层网络结构。那么这种IP漂移就变的非常难，也非常奢侈。所以在现有网络基础上，建立一个Overlay的网络，在某些场景下就变的自然成为刚需。当你需要考虑如何让现有业务无缝的迁移的时候，那你就需要Overlay的网络。

当你具备了，统一接入层，当你具备了良好的系统该模型，当你具备了Overlay网络虚拟化，那么真正的弹性计算时代就来了。你就有动态伸缩，系统编排混部，你就有健康检查和故障迁移。在这些基础设施都完备的基础上，那么通过弹性规则引擎，故障规则引擎，系统编排引擎。你就可以灵活的想怎么弹就怎么弹，想怎么迁就怎么迁。我们管这种系统叫金箍棒系统。目前EWS无状态迁移可以做到分钟级，有状态不停服迁移可以做到5分钟级，有状态存储（10G）迁移可以做到10分钟级。目前EWS的弹性计算还是处于一个早期阶段，到真正我们心目中的弹性计算，到心目中的弹性计算能应用到生产环境，我们还有很长的路要走。还是那句话，弹性计算如果只增加机器的话，那是伪弹性。
高质量架构还有两点不得不说，那就是高稳定性和高性能。高稳定性靠监控，一个系统是监控能力强不强很关键的，讲一个段子：有一天用户访问页面出了500，用户抱怨的时候，开发同学那边马上收到了告警，然后赶紧跟老板汇报：“老大，刚才发了个版本，可能出故障了。”老板大怒：“什么？你尽然发版本竟然我不知道。”开发同学委屈的说：“你不是老跟我们说随时随地想发就发是一种能力么。” 老板一听颇为尴尬：“少废话，赶紧看啥问题”。结果一看，哦，刚才发的代码手一抖URL少了一个斜杠，马上打开在线IDE修改发布。从发先问题到解决花了2分钟。这时候用户还不放弃，不停的刷新也，大惊：“恩？好！” 这时候用户心里就嘀咕了：“都4G了，怎么移动还老掉线。”。这虽然是个段子，但这代表了什么，代表了这只团队有先于用户发现问题的能力。这个可是钱啊，一个故障你5分钟解决，还是2个小时解决直接决定了故障等级的。5分钟解决顶多一个P4故障，2个小时直接变成P1，今年的奖金没了。所以先于用户发现问题的能力，也是确保你能拿到奖金的能力。
高性能靠APM。你是否有Apm能力，你是否知道你系统的20w的访问请求里面，那个请求是慢请求，这个慢请求是从哪里来的，是广东来的，还是内蒙古来的。这就是你对系统了解的深度的问题。 APM能力有时候是钱啊。比如你有一个图片URL经常的400，那你就悲催了，大家都知道很多图片CDN 400了是要回原的，耗流量的，流量耗在死链上那是多么悲催的一件事。所以你对整个链路的APM能力也是很关键的。EWS和aliAPM深度融合，只要你部署在EWS上，无需修改一行代码，就自然具备了监控和APM功能。

以上就是我们觉得一个做一个提供高质量架构输出的产品需要做的事情，以及EWS中的一些实现。当然很难在这么短的时间里讲的更加细致。提纲挈领的讲了一下，其实里面的每一个命题都可以单独拿出来做一个专题来讲。但相信大家对EWS做的这件事儿，也就是高质量架构产品化输出这件事应该有了一个了解。如果有对高质量架构感兴趣的，也可以下来交流。
（准备鼓掌）大家是不是以为要结束了，其实没有呢？这么结束我觉得还少了点儿什么。其实我还想讲讲一个做高质量架构团队的素质，想讲讲EWS团队和DevOps。

去年到今年特别流行的就是DevOps，我也查了不少资料，也参加了不少DevOps的分享。发现了一个问题，就是DevOps没有一个标准的定义，如果说的更有文化味儿一点儿就是：“每一个人心里，都有一个哈姆雷特”。在跟做DevOps的团队交流的时候发现了一个特别有意思的现象，我总结成一句话：“听到的是官方正品，设计成淘宝高仿，执行成九块九包邮”。
DevOps的目的是什么，这是一个国外同行总结的，我觉得挺对：“work it harder , make it better, do it faster, make us stronger”，就是奥林匹克精神：“更高，更快，更强”。更通俗的解释刚才也说过了就是：“又快又省钱，又猛又持久”。那么要达到这个目标，我觉得会涉及到三个方面：“业务和团队，工具和流程，人和文化”。
首先说业务和团队。有一句话叫“做正确的事，而不是正确的做事”，我觉得太有道理了，放到DevOps这件事情上就更应景了。这什么意思，解释一下，就是首先你这个事儿得对，事儿不对，姿势再好看也没用。但是现在就是有很多团队在做事的时候，对姿势的追求大过了事情本身。讲什么"PK发型不乱"。说到这里我又想起一个段子：2000年初的时候特别流行一个软件开发标准叫CMMI，业内有一个调侃，说是怎么判断一个软件到CMMI几级呢。如果软件有开发文档，那就是CMMI1,如果软件的开发文档有文档记录，那就是CMM2,如果软件文档的文档有文档记录，那就是CMMI3，直到五层嵌套，OK了。你是CMMI5。有那么点儿“正确的做事”的味道，当时有不少企业都是为了过CMMI而过CMMI的。DevOps也要做正确的事儿，而不是正确的做事。或者说，用正确的方法做错误的事儿。
另外，做DevOps，团队最好是全建制的野战军团队。全流程的DevOps。否则你要做个特性，先产品团队排期，再UED团队排期，最后再开发排期。有时候真是快不起来，DevOps效率优先。总结成一句话就是：“业务和团队是有质量DevOps的前提”。
最后是DevOps和团队的文化是分不开的，这个文化其实不是企业文化，而是开发团队内部的一些文化，一些做事儿的准则，这里我总结了几条EWS团队的做事准则分享给大家。
“大系统小做，看中阶段性成果。刚性完成，柔性运营”。这是说你的目标是个大系统，但别一下子搞一个航天飞机，先一个一个零件的做。否则一个项目搞个半年一年，然后没有阶段性成功，其实是很危险的。每个阶段都要刚性的完成，到了点儿那就拿阶段性成果，然后根据业务情况不断调整，这就是柔性运营。
“不抱怨和就事论事”。这个也非常重要，问题大家要充分讨论，但一定要就是论事，关起门来怎么争论都可以，开开门必须是一股绳。
“Deadline 是生产力，但不是第一生产力” 这句话我特别喜欢，就是任何项目必须有个Deadline，但Deadline不是决定因素。
“保持适当的前瞻性，但绝不杜撰需求”。要能看得清方向，但不能YY，做太早了就是先烈了。
“能力是个人的，更要沉淀在团队上”。不能牛人化，不能说这个模块儿的人请个价，没人能搞的定，这个还是要把能力变成团队的能力。
“对焦，Review，DoubleCheck”。Leader的三大法宝，谁用谁知道。
“对结果负责，结果一定是功力的，但要用享受的心态去体会过程”。这句话也特别喜欢，结果这件事一定是功力的，没结果再辛苦也是白搭。拿结果是个人那结果，更是团队拿结果。但是就个人来讲，你得用享受的心态去体会过程，不是说了么，“生活不只眼前的苟且，还有诗和远方”
以上这7条，就是EWS总结的一些团队做事上的一些文化，这个其实也不是第一天就刻意做的，而是在团队发展过程中自然形成的。对开发团队来讲，好的开发文化对开发本身是有很大帮助的。那再总结成一句话就是“DevOps需要文化赋能”。
好，今天的分享就是这样，谢谢大家。