2011年蘑菇街上线时，它的主要业务是分享社区，就是买家买了商品以后，把这个商品分享出来给大家。2012年开始转型商品导购，早期业务比较简单，相对设备比较少，基本上是一套业务代码。运维都是由具体的开发同学自己去管理的，根本不需要专业的运维人员。

从2013年开始，我们开始自建电商平台，从下单到支付整条链路开始自主建设。业务发生了变化，但是整个架构没有太大的变化，只是把中间层，数据层脱离出来了。设备增加了不少，从原来个位数增加到三位数了，还有网络设备了。业务这一块是开发自己维护，运维这边主要建设了一些初级版的服务器管理系统、发布系统、监控系统。

2015年整个业务开始发生变化了，集团开始从原来的PHP开发，逐步转向了Java开发，从原来主站一套单一业务套代码拆分成各个子业务系统，整个架构发生改变。流量入口我们分成两块，无线端和PC端二块接入。MWP为无线网关。其他PC端的流量通过代理层分发到各个不同的子业务系统，部分系统实现前后端分离服务化，最底层为数据层。从原来业务再新加业务需求，逐渐演变成拥有目前1300多个应用系统。

业务快速发展对我们运维带来的挑战：

第一：1300多个应用如何进行管理，这是一个大的问题。不同业务如何区分？业务肯定要部署在具体服务器上面，不同业务部署不同服务器，业务和服务器之间的对应关系如何管理？还有业务部署环境，不同的业务运行的环境有可能存在差异的，所以我们需要把业务与环境之间的对应关系也要管理起来。

第二：早期业务之间可以依赖简单应用代码之间内部的调用，拆分演变成应用与应用之间的依赖关系，如何管理业务之间的上下游依赖？如何快速定位排查问题？这对我们排查工具带来了挑战和要求。

我们带着这些问题看一下运维体系建设的思路。

运维工作围绕这四个主题展开的：

• 稳定性。保证业务稳定快速地发展；

• 成本。成本涉及到两块：人力成本和系统资源成本，我们期望以最小的成本创造最大生产价值；

• 效率。运维工作自动化，提高工作效率，减少成本；

• 安全。

我们日常运维工作都是围绕这四块展开的，系统建设的时候也是围绕这四个主题展示；这四块主题优先等级我个人认为是：安全第一，如果系统存在安全问题，那肯定是第一时间处理；其次是稳定性、成本、效率。以上个人对运维的理解。

基于运维需求，我们逐步建设起目前的运维体系的架构。从最底层看，第一层基础的硬件环境，如IDC/服务器/网络设务。第二层为业务需要的底层基础服务，如DNS、NTP、YUM源、LVS等；第三层针对这些系统资源管理平台，虚拟化平台，DNS管理系统等。上面三层针对业务的，有我们应用管理系统、服务器管理系统、DBMS等；还有常用的系统，像发布系统、部署系统之类的。最顶层是开放给业务开发使用的统一运维平台。这些系统并不是说在我们建设当中一下就能建设好的，而是根据我们日常操作当中运维的需要逐步搭建而成。

如果一个系统业务要接入进来，第一步要做的是标准化。按照我们规范进行改造，符合我们要求才能接入进来。不然1300多个应用没有一个统一接入标准，让我们去做适配打造运维相关的系统，那是不可能的。我们总体的思路，先标准、后接入，只有按标准改造了，业务开发才能方便地使用我们的运维系统。

标准化到底要做哪些事情呢？主要分成三块：

• 基础环境。基础环境里面规范有哪些呢？我们可以分为两块：硬件、软件。硬件我们规范了使用的服务器硬件配置规格，目前虚拟机规格分成三类：2核4G内存的，4核8G内存的，8核16G内存的；目前要求都使用的是虚拟机。软件方面我们主要规范部署需要的软件的版本、管理方式和部署目录；

• 应用配置。这里规范了应用部署目录、应用包名和应用配置等。

• 技术架构。规范了业务对基础组件使用姿势，如流量接入层、ZK、Kafka等。

集团应用体系规范

接下来看一下具体的标准化定义内容。整个运维标准化体系是我们运维部牵头搞的。主要是刚才讲到的内容，定义了具体我们使用的应用和基础服务的接入、目录的规范。旁边可以看一下应用的管理规范，详细定义应用名命名规范、应用包名规范、应用目录、部署目录等内容，形成文件，在整个集团各个部门里面传达执行。

应用部署规范

我们按照开发语言不同，应用服务对服务器的部署环境要求也不同；我们先后制定Java版、PHP版、GO版和Node.js版等。每个版本的规范里面都基本上定义了这些内容：

第一：目录：基础软件部署目录和版本要求；

第二：应用运行的用户账号是什么、权限是什么。

（1）应用启停脚本

接下来我们还规范了启停脚本，还定义了这个脚本里面传的参数，可以支持哪些参数，启动或者重启。每条指令里面做什么事情都进行了说明和规范。

（2）规范应用上线标准

除此之外还定义了一个业务上线之前要遵循的标准，上线的标准和下线的标准。上线之前需要业务方提供标准的自检功能，要怎么知道你这个应用是成功还是失败的，那肯定需要有一个检测机制告诉我，脚本里面通过这个检测机制知道这个业务到底是否正常，这是一个强制性的规范。下线也是一样，上流根据定时检测指定这个URL，根据访问结果判断是否把流量自动地切掉。

标准化文档里面主要就是规范上述一些内容。这些内容为后面的运维系统做了规范。我们运维系统都是基于这个规范来做。

1300多个应用如何管理？在介绍应用管理之前需要重点介绍一下这几个概念，这作为蘑菇街应用运维核心概念。

第一：应用名代表在蘑菇街应用系统中具体业务功能，不同的应用名用于区分不同的业务，我们按照一套业务代码进行划分。

第二：应用名分组是管理服务器的，用来组织管理服务器的。

两者之间的关系是什么？一个应用下面可以对应多个应用分组；这个分组按照什么维度来划分的呢？可以根据环境，也可以根据稳定性的要求来拆分的。应用名作为应用运维的核心，运维系统都以应用名作为资源的组织方式。

系统里面主要管哪些内容呢？其中一块用于管理业务、部门、人员三者之间的关系。

可以看一下这个图，像这个业务是属于哪一个部门的，开发者是谁，代码review是谁，这个里面都会维护好。除此之外还会定义这个应用的部署特征，这个应用部署类型是什么，这个比较关键。后期的运维系统我们会拿着部署特征信息后面做判断应用于具体操作。应用管理系统中定义里面每一个字段在后面运维系统里面都会存在一定关联。

接下来服务器管理也有单独的系统，服务器管理系统前面说了，分组是作为管理服务器的，在这一层可以看一下我们整个层次结构分成两层：部门下面是具体的应用，应用下面是分组。应用分组默认有三个组：DEV代表线下测试环境，PRE代表预发环境，ONLINE代表生产环境。我们在分组上面建立了不同环境的标识；发布系统或其他运维系统就可以根据需求按应用的纬度获取不同环境的机器列表。

同一个应用目前我们只分了三套环境：测试环境、预发环境和线上环境，一般默认对应3个应用分组；但有时基于稳定性考虑，会把线上环境的服务器拆分成多个应用分组。假如某个应用是为其他应用业务提供基础服务的；如果调用服务不隔离管理的话，很容易出现稳定性的问题，如非核心业务调用量过大，导致核心业务调用失败或超时，基于上述问题，我们很容易想到解决方案就是把服务拆分成不同服务集群，让核心业务调用1个服务集群，让非核心业务调用另外一个集群。这个需求RPC服务管理控制台都可以实现IP与服务关系绑定；根据依赖业务重要程度区分出不同的服务集群，再根据不同集群调用量需求将服务器划到不同的应用分组中进行管理，这个拆分分组是比较好的一个解决方案；

既然RPC这边已经把服务逻辑分组，那服务器管理系统中是不是可以不用区分了，服务器放在同一个应用分组下进行管理，这样不是更简单吗？

不拆分出应用分组，对于业务访问是没有影响的，因为应用分组的作用只是管理服务器，不会影响线上正常访问；但是运维系统是不知道应用业务内部逻辑访问分组是什么样，那些机器属于同一个服务集群，操作时需要必须一起操作；如果同一个集群一起操作的话，那线上的服务就挂完了；所以必须把这个体现出来，管理起来；

应用分组这个管理方式是比较灵活的，可以根据不同业务的特征建立不同的分组。比如说机房纬度、地域纬度等。分组可以理解为是一个集群的概念，同一个应用分组下提供服务和服务对象都是相同的。这是服务器管理这一块。

同一类开发语言开发出来的业务应用对于部署环境依赖大致都是相同的。基于这个特征，我们基于应用部署类型制定应用部署模板，用于管理同类应用部署服务器环境的需求。我们基于不同部署类型建立对应的应用部署模板，如Java版、C++、GO等。在这个模板里面我们定义了：部署的软件和常规配置文件等内容。举个例子，Java开发业应用，一般部署服务器环境所需要的包括一个JDK，容器我们使用Tomcat，Nginx作为Web代理服务器；除此之外，我们还有可能需要启停脚本和配置文件，用于保证环境正常运行。

部署模板的用途用是什么呢？它主要为应用基线提供服务的。应用基线我们建立的维度按照应用分组维度建立的。

应用基线建立的维度我们是按照应用分组维度来建立的。一般情况下应用基线部署的内容配置都是从部署模板里面导过来的，基本上都能满足相应的应用部署环境的需要；当个别应用需要个性化的环境配置或软件时，我们就可以针对相应的应用分组的应用基线进行修改补充，已满足业务方的需求；

应用基线产生时间点是在应用申请流程结束后，根据应用申请时选择的部署类型自动地把应用模板相应配置信息导入到该应用下的所有应用分组下面。

通过前面几个系统，我们基本上把环境、应用都管理起来了。但如何实现环境的自动化部署？我们建立了应用的部署系统，应用部署系统里面定义什么呢？就是我们定义了部署环境的执行步骤。

如第一步，部署安装软件；第二步配置文件；第三步初始化等等。根据我们应用的部署类型建立不同的部署需要执行的步骤，按照定义执行步聚能完整地构建起一个应用的运行环境。

最后缺一个触发的场景，能把上面各个相关系统串联起来的系统。像申请服务器、扩容，新应用申请，因为这些都是业务开发提出了需求，如何组织在一起，跟我们的环境部署系统组织在一起呢？通过运维工单的方式，需要业务开发提相应的工单，根据不同的工单把我们前面运维的步骤总的综合在一起。

目前我们工单的范围比较多，覆盖了我们运维当中常见的一些运维需求，像服务器申请、新应用申请之类的。这些步骤里面，每个工单里面都包含两部分：第一部分是流程审批，因为有的人很反对流程，但流程是为了保证稳定性的手段而已。还有一部分是我们的工单，具体做的事情。工单系统里面是这两部分组成。

接下来说一下整个过程，当运维开发提交一个工单给我们的时候，假设新应用申请，从新应用里面根据这个应用里面定义的内容获取应用的配置信息。应用的审核人员是谁，根据这个审核人员审批流程通过以后，会获取对应系统里面部署的机器列表，根据部署列表拿到以后，把数据传给应用部署系统里面部署环境。部署环境里面，部署哪些软件、同步哪些配置文件，这些数据从哪取？从应用基线里面取。应用基线里面如果是空的，就从应用模板里面获取。当环境部署完成以后或者出了异常以后把具体信息返回给工单系统，工单系统可以做一次重试任务或者结单。

（1）应用运维自动化实现-工单实例

这边是具体使用的工单实例场景——新应用申请。有流程审批，流程审批结束以后，运维系统里面做的第一步，应用的基本信息插入到应用管理系统里面，同时设备管理系统里面自动的创建分组，分配机器。机器分配完以后去部署环境，同时添加相应责任人的权限。这几个步骤基本上都是全部自动的。有问题的时候会停留在具体工单上面，运维人员会做这一块的重试或者查看工单详情，看哪一块出了问题。

（2）集成发布系统

对于运维开发还有一块需要关注的是集成发布系统。集成发布系统的功能就是把代码部署到线上服务器。当我们把一个应用包编译打包完成以后，需要将这个应用包发布到具体的服务器到应用部署发布完成经过以下几个步骤：

首先检查一下环境完整不完整，发布系统检测一下目前机器上面的部署环境是否完整。确认部署环境没有问题后，发布系统把应用包同步到对应的服务器上面；接下来通过监控系统接口关闭相应服务器上监控项；接下来执行应用目录下的应用启停脚本，通知RPC调用方或Web代理该服务器即将下线；暂停一定时间后，再执行应用启停脚本中停止指令，停掉Nginx和Web容器；确认应用服务停止后，将应用包同步到运行目录里面解压、启动应用。

启动应用时如何知道应用是否启动成功了呢？通过我们前面定义的，每个应用里面上线必须要遵循的规则自检的程序来判断（发请求/status检测）。如果请求返回SUCCESS时，则说明应用启动成功了，否则认为失败；确认成功后，通知RPC调用方和WE代理该服务器可以正常服务了。

（3）监控系统

还有一块是监控系统，当我们应用上线完了应用都启动成功了，把应用服务器状态调整成Online，这样可以把监控系统自动触发针对该应用进行监控。我们会根据部署类型，部署不同类型定义不同的监控模板，当然业务方也可以自定义监控项。

（4）全链路跟踪分析

当从原来一个单一的应用演变成多个应用，之间的业务依赖关系如何进行管理，针对这块需求，我们跟稳定性团队共同开发了一套“全链路跟踪分析系统”。在我们流量的入口把全链路的功能模块嵌入进去，要求所有标准化的应用都引用了全链路的二方包，流量入口到底端构成了整个链路，通过这个链路分析对应的应用依赖关系。

在全链路跟踪分析系统中，可以看到应用自身提供的服务和依赖的服务，以及各个服务后端依赖的链路；当我们出现问题的时候，在这个系统里面直观地可以定位到哪一个业务出了问题和哪个服务出了问题。

除了应用整体的依赖关系以外，还可以根据具体的链路分析出来整条链路上下游依赖关系，这条链路的这个请求进来以后依次经过哪些系统，而且系统与系统的调用关系是多少，在全链路分析系统里面我们都可以看得到。全链路分析系统是我们运维这边比较重要的一个定位排查的系统。

（5）运维一站式管理平台

我们前期做了很多运维系统，如应用管理的、域名管理的、服务器管理等，涉及到各个运维资源管理。但这种分系统部署管理给业务开发会带来问题，需要一个信息以后，需要在不同的系统之间进行切换去察看相应的信息，这对开发来说是比较痛苦的。因此我们目前正在做一站式的运维管理平台，希望以业务的维度把所有的运维资源都展示在一起，并结合相应的运维工。

这一套系统里面分成两块：第一块是部门维度的。我们基于部门可以看这个部门下面所有的业务有哪些业务以及相应的人员，除此之外还可以看到这个部门消耗的资源有哪些。旁边这一块有服务器利用率统计里面可以看到整个资源的消耗，这个部门下面有多少个业务，每个业务消耗的服务器资源有哪些、利用率是多少。

第二块应用的详细信息，应用里面会把所有应用相关的资源都定义好，在这里面展示出来。我们可以在这个平台里面综合的看到这个业务整体的情况。目标是想打造一套NOOPS运维平台，当然这是基于稳定性和安全的情况下，把运维操作让业务同学自主的去完成的，不需要运维同学过多参与，提高开发的工作效率。

我们目标是NOOPS，目前正在路上，谢谢大家！

Q1：内部Ops平台已经成型了。我想问一下PE蘑菇街这边的历程，现在是怎样的？

A1：蘑菇街前期PE主要是负责业务稳定性这一块，资源分配、环境管理这一块。慢慢的iPaas这个平台上线，日常运维工作逐步减少后，以后我们PE会更多关去心使用服务器资源使用率和成本。

PPT下载链接：http://pan.baidu.com/s/1eSP8zBW