也即人工创建，人工调度，人工配置的集中管理模式已经成为瓶颈，应该变为租户自助的管理，机器自动的调度，自动的配置。
自动调度代替人工调度，区域可用区抽象对机房机架交换机的感知。
云提供租户概念，有账号子账号体系，有quota，可以让租户在管理员许可的范围内自助操作，加快环境部署速度。
4.3、数据架构：统一指标体系，建设数据仓库，支撑管理决策
服务化之后，各个系统的业务数据格式统一了，制定了统一标准，并且上游系统设计的时候会考虑到下游的使用，下游系统设计的时候，会考虑到和上游兼容，统一的客户ID，订单ID等能够将整个业务流程串起来，有利于建设统一的指标体系。
有了这个基础，就可以建设统一的数据仓库了。数据仓库的构建不能像第一阶段一样再数据库里面，或者业务系统里面直接进行分析，需要通过数据接入，将数据抽取出来，经过一定的处理，放到数据仓库里面来。
这就需要建设大数据的技术平台
第一个步骤叫数据的收集。数据的收集有两个方式，第一个方式是拿，专业点的说法叫抓取或者爬取，例如Nutch就是这样爬取全网的数据的，建设数据中台，你需要融合外部数据，为经营做决策，就需要通过爬取的方式。另外一个方式就是推送，有很多终端可以帮我收集数据，比如硬件终端的推送，应用系统的埋点等，这些是融合内部数据。还有数据是从数据库里面抽取出来的，就要用到DataX等数据交换工具。
第二个步骤是数据的传输。一般会通过队列方式进行，因为数据量实在是太大了，数据必须经过处理才会有用，可是系统处理不过来，只好排好队，慢慢的处理。例如Kafka就是常用的队列，有时候传输的过程中要对数据做预处理，这就是常说的ETL，Extract-Load-Transform。
第三个步骤是数据的存储。存储的数据量比较大，需要使用大容量的存储，可以使用分布式文件系统 HDFS，对象存储OSS，以及Hbase, MongoDB等NoSql的数据库。
第四个步骤是数据的处理和分析。这里主要分离线处理，例如Map-Reduce, Hive, Spark，也有实时流处理，例如Flink, Spark Streaming, Storm等。
第五个步骤就是对于数据的检索和挖掘。检索多用ElasticSearch，可以做即席分析，例如Kylin, Impala, ClickHouse, Hawk，也会有一些算法可以进行数据挖掘，例如Spark ML里面的分类，聚类等。
数据平台的建设，还只是建设了一个技术平台，作为中台，还应该有业务属性，也即数据仓库，也即从业务领域的角度建立一些表，方便进行业务角度的分析。
咱们前面服务化的时候，梳理了业务领域的划分以及业务流程，这在数仓建设中也是很有用的。如图所示，里面有商品域，采购域，物流域，交易域，这些都是和服务相对应的。我们建设数仓的时候，里面的指标设计也是按照业务流程来的，这也是和服务相对应的。
4.4、研发流程：发布模式平台化，构建持续集成流程，质量和绩效看板
我们再来看研发流程，云平台的建设提供了统一的接口，这使得发布模式可以更容易的对接资源，实现平台化，并基于平台构建持续集成流程。
因为如果云计算不管应用，一旦出现扩容，或者自动部署的需求，云平台创建出来的虚拟机还是空的，需要运维手动上去部署，根本忙不过来。因而云平台，也一定要管理应用。基于云计算OpenStack的虚拟机分层镜像发布和回滚机制，构建发布平台，可实现大规模批量部署和弹性伸缩。
基于虚拟机的PaaS托管中间件，简化租户创建，运维，调优中间件的难度。云平台的PaaS负责创建的中间件的稳定，保证SLA，当出现问题的时候，会自动修复，从而业务方不用管PaaS中间件的部署和SLA了。
发布平台提供基于虚拟机镜像+PaaS中间件，做完整的应用的部署和上线，称为编排。基于编排，就可以进行很好的持续集成，例如每天晚上，自动部署一套环境，进行回归测试，从而保证修改的正确性。
要求业务对于高可用性设计要在应用层完成，而不能完全依赖于基础设施层的能力了。每一个服务都有实现良好的无状态化处理，幂等服务接口设计。每个服务都要设计有效探活接口，以便健康检查感知到服务状态。通过制定良好的代码检查规范和静态扫描工具，最大化限制因为代码问题造成的系统不可用。
4.5、组织架构：成立中台组/架构师组，衔接研发和运维
上面的技术问题说完了，接下来说一说组织问题，根据康威定理，组织方面就需要有一定的调整。
上面说过，中台是为了能够集团军作战，能够协调各种力量为业务快速迭代服务，要建设腰部力量，除了上面所说的各种系统，人当然是最重要的，人不能调度起来，系统建设的再好也白搭。
所以不能再运维组和开发组隔离了，而要成立架构师组，或者就像前面图中的架构委员会，当然这个架构组一开始试点不用很大，试点阶段一定要有这个角色，来横向协调各种资源，并且挂在CIO下面，有一定的话语权。
