本文改编自白海强先生的主旨演讲《蘑菇街应⽤运维体系建设及运维⾃动化实践》。本次分享的内容主要分为以下三个方面：蘑菇街技术架构与运维演进应用运维系统构建思路应用运维自动化实践过程蘑菇街技术架构与运维演进导购期（2011-2012）2011年蘑菇街上线时，主营业务是分享社区，即买家购买商品后，将商品分享给大家。2012年开始转型产品导购。早期业务比较简单，设备比较少，基本就是一套业务代码。运维全部由具体开发同学自己管理，根本不需要专业的运维人员。过渡期（2013-2014）从2013年开始，我们开始搭建自己的电商平台，从下单到支付的整个环节做起。业务变了，但是整个架构没有太大变化，只是中间层和数据层分离了。设备增加了不少，从原来的个位数增加到三位数，还有网络设备。业务部分自行开发维护。运维端主要搭建服务器管理系统、发布系统、监控系统的一些初级版本。社交电商（2015-至今）2015年整个业务开始发生变化，集团开始从原来的PHP开发转为Java开发，将代码从原来主站的单一业务集拆分成各个子业务systems，整个模式发生变化。我们把流量入口分成两部分，无线端和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版。这些内容在各个版本的规范中基本都有定义：Catalog：基础软件部署目录和版本要求。应用程序运行的用户帐户和权限是什么。应用标准化规范文档-示例应用启停脚本接下来我们也对启停脚本进行了规范，定义了脚本中传入的参数，哪些参数可以支持，启动或者重启；每个命令的作用都有解释和规范。除了规范线上标准的应用，它还定义了业务上线前需要遵循的标准，线上标准和线下标准。上线前，业务方需要提供标准的自检功能。如何知道你的申请是成功还是失败？肯定有一个检测机制告诉我，脚本就是通过这个检测机制来知道业务是否正常。这是一个强制规范。离线也是如此。上游根据定时检测指定这个URL，根据访问结果判断是否自动断流。标准化文档主要是对上述部分内容进行标准化，这些内容为后续的运维系统提供规范。我们的运维系统就是基于这个规范。如何以应用运维自动化的核心理念管理1300多个应用？在介绍应用管理之前，我们需要重点关注这些概念，它们是蘑菇街应用运维的核心概念：应用名称代表蘑菇街应用系统中特定业务的功能。不同的应用名称用于区分不同的业务。我们根据一套业务代码进行划分。应用程序名称分组用于组织和管理服务器。两者之间是什么关系？一个应用可以对应多个应用组。这个群体是按照什么维度来划分的？可根据环境和稳定性要求拆分。应用名称是应用运维的核心，运维系统以应用名称作为资源组织方式。应用管理系统的主要内容有哪些？其中之一用于管理业务、部门和人员之间的关系。大家可以看看这张图，比如这个业务属于哪个部门，谁是开发者，谁是codereviewer，都会维护的很好。此外，还将定义此应用程序的部署特征。这个应用的部署类型是什么比较关键。在后期的运维系统中，我们会根据部署特征信息进行判断，并应用到具体的操作中。应用管理系统中定义的各个字段，在后续的运维系统中都会产生一定的关系。服务器管理接下来，服务器管理也有一个单独的系统。前面提到的服务器管理系统，分组是作为管理服务器的。在这一层，我们可以看到我们整个层级结构分为两层：部门下面是具体的应用，应用下面是分组。默认的应用组有3个：DEV代表离线测试环境。PRE代表预发行环境。ONLINE代表生产环境。我们在分组上建立了不同环境的标识，发布系统或者其他运维系统可以根据需要根据应用的纬度获取不同环境的机器列表。目前我们只是把同一个应用分成三套环境：测试环境、预发布环境和线上环境，一般默认对应三个应用组。但有时基于稳定性的考虑，会将线上环境中的服务器拆分成多个应用组。假设一个应用为其他应用业务提供基础服务。如果调用服务没有被隔离和管理，很容易出现稳定性问题，比如非核心业务调用过多，导致核心业务调用失败或超时。基于以上问题，我们很容易想到解决方案就是将服务拆分成不同的服务集群，让核心业务调用一个服务集群，让非核心业务调用另一个集群。这就需要RPC服务管理控制台能够实现IP与服务关系的绑定，根据依赖业务的重要性区分不同的服务集群，然后根据不同集群调用量的需求，将服务器划分到不同的应用组进行管理.分组是更好的解决方案。既然RPC端已经对服务逻辑进行了分组，难道服务器管理系统就不能区分了吗？管理同一个应用组下的服务器不是更方便吗？如果不拆分应用组，对业务访问没有影响，因为应用组的作用只是管理服务器，不会影响正常的在线访问。但是运维系统并不知道应用业务内部的逻辑访问分组是什么。这些机器属于同一个服务集群，在运行时必须一起运行。如果同一个集群一起运行，将暂停在线服务；所以这必须得到反映和管理。应用分组的管理方式比较灵活，可以根据不同业务的特点，如机房纬度、地理纬度等，建立不同的组。分组可以理解为集群的概念。同一个应用组下提供的服务和服务对象都是一样的，就是服务器管理部分。应用部署类型模板管理采用同类型开发语言开发的业务应用，对部署环境的依赖一般是相同的。基于此特性，我们根据应用部署类型制定应用部署模板，以管理类似应用部署服务器环境的需求。我们根据不同的部署类型，如Java版本、C++、GO等，创建对应的应用部署模板。在这个模板中，我们定义：部署的软件和通用的配置文件等。例如，Java开发应用一般需要一个JDK用于服务器环境部署，Tomcat为容器，Nginx为web代理服务器；此外，我们可能还需要启停脚本和配置文件来保证环境的正常运行。应用程序基线管理部署模板的用途是什么？它主要服务于应用程序基线。应用基线建立的维度是根据应用分组维度建立的。一般来说，应用基线部署的内容配置是从部署模板中导入的，基本可以满足对应应用部署环境的需要。当个别应用需要个性化的环境配置或软件时，我们可以修改和补充相应应用组的应用基线，以满足业务方的需求。生成应用基线时，应用申请流程完成后，根据应用申请时选择的部署类型，自动将应用模板的相应配置信息导入到该应用下的所有应用组中。应用部署系统通过前面的系统，我们基本上是对环境和应用进行管理。但是如何自动化部署环境呢？我们建立了一个应用程序部署系统。应用部署系统中定义了什么？即我们定义部署环境的执行步骤。例如，第一步是部署和安装软件；第二步是配置文件；第三步是初始化等等。根据我们应用的部署类型，我们需要建立不同的部署步骤，并根据定义执行这些步骤，从而完整地搭建一个应用运行环境。运维工单管理在端部缺少一个触发场景，一个可以串联以上相关系统的系统。比如服务器的申请，扩容，新的应用申请，因为这些都是业务发展的需求，怎么把它们组织起来，和我们的环境部署系统一起组织起来？通过运维工单的方式，业务开发需要提交相应的工单，根据不同的工单，我们之前运维的步骤一般会集成在一起。目前我们的工单种类繁多，涵盖了我们运维中一些常见的运维需求，比如服务器应用、新应用应用等。在这些步骤中，每个工单包含两个部分：流程审批，因为有些人非常反对流程，但流程只是一种确保稳定的手段。工单是具体要做的事情。应用运维自动化实现总结接下来说说整个过程。当运维开发向我们提交工单时，假设有一个新的应用程序应用，根据应用程序中定义的内容，从新的应用程序中获取该应用程序的配置信息。谁是申请的审核人？通过审核人的审批流程后，会得到对应系统部署的机器列表。获取部署列表后，将数据传输到应用部署系统中的部署环境。在部署环境中，部署了哪些软件，同步了哪些配置文件，这些数据从何而来？取自应用程序基线。如果应用程序基线为空，将从应用程序模板中获取。当环境部署完成或出现异常时，将具体信息返回给工单系统，工单系统可以重试任务或关闭订单。应用运维自动化的实现——工单实例下面介绍工单实例的具体使用场景——新建应用应用。有流程审批。流程审批通过后，运维系统第一步就是将应用的基本信息录入到应用管理系统中。同时，设备管理系统自动创建分组和分配机器。分配好机器后，进入部署环境，同时添加相应负责人的权限。这些步骤基本上都是自动的。当出现问题时，它会留在具体的工单上。运维人员会重试这部分或者查看工单详情，看是哪部分有问题。集成发布系统运维开发中另一个需要关注的地方就是集成发布系统。集成发布系统的作用是将代码部署到线上服务器。当我们编译打包了一个应用程序包之后，我们需要将应用程序包发布到特定的服务器上，这样就完成了应用程序的部署和发布。经过以下步骤：首先检查环境是否完整，发布系统检查当前机器部署环境是否完整。发布系统确认部署环境没有问题后，将应用包同步到对应的服务器。接下来通过监控系统界面关闭对应服务器上的监控项；接下来，在应用目录下执行应用启动和关闭脚本，通知RPC调用者或Web代理服务器即将下线。暂停一定时间后，在应用启停脚本中执行stop命令，停止Nginx和Web容器；确认应用服务停止后，同步应用包到运行目录解压启动应用。启动应用时如何知道应用是否启动成功？通过我们前面定义的每个应用程序必须遵守的规则自检程序来判断（发送请求/状态检查）。如果请求返回SUCCESS，则表示应用启动成功，否则视为失败；确认成功后，通知RPC调用者和WE代理服务器可以正常服务。监控系统的另一部分是监控系统。当我们的应用启动，应用启动成功后，将应用服务器的状态调整为Online，这样就可以自动触发监控系统对应用进行监控。我们会部署不同的类型，根据部署类型定义不同的监控模板。当然，业务方也可以自定义监控项。全链路跟踪分析当单应用从单应用演化为多应用时，如何管理应用间的业务依赖关系？为了满足这个需求，我们和稳定性团队共同开发了一套“全链路跟踪分析”。系统”。在我们的流量入口嵌入全链路的功能模块，要求所有标准化的应用都引用全链路的二方封装。整个链路从流量入口到底部形成，对应的通过这个link.relation来分析应用的依赖关系，在全链路跟踪分析系统中，可以看到应用本身提供的服务和依赖的服务，以及各个服务后端依赖的链接。当我们有一个问题，我们可以很直观的定位这个系统是哪个业务有问题，哪个服务有问题，除了应用的整体依赖，还可以根据具体的环节来分析整个链路的上下游依赖。我们可以在全链路分析系统中看到这个链路的请求依次经过哪些系统，系统与系统之间的调用关系是怎样的。全链路分析系统是我们运维的重要定位和排查系统。运维一站式管理平台我们前期做了很多运维系统，比如应用管理、域名管理、服务器管理等，涉及到各种运维资源的管理。但是，这种子系统的部署管理会给业务发展带来问题。在查询一条信息时，需要在不同的系统之间切换才能查看到对应的信息，这对于开发来说是比较痛苦的。因此，我们目前正在搭建一站式运维管理平台，希望将所有的运维资源在业务维度集中展示，并结合相应的运维工作者。这个系统分为两部分：第一部分是部门维度的信息，以部门为单位，可以看到这个部门下的所有业务都有哪些业务和对应的人员。另外，我们还可以看到这个部门消耗的资源有哪些。旁边是服务器利用率统计，里面可以看到整个资源的消耗情况，这个部门下有多少业务，每个业务消耗了多少服务器资源，利用率是多少。第二条应用详情，所有与应用相关的资源都会在应用中定义并显示在这里。我们可以在这个平台全面的看到业务的整体情况。目标是搭建一个NOOPS运维平台。当然，这是建立在稳定性和安全性的基础上，让业务同学自主完成运维。是的，不需要运维同学过多参与，提高了开发效率。我们的目标是NOOPS，目前正在路上，谢谢大家！作者：白海强（昵称：朴智）简介：目前在蘑菇街平台技术部从事应用运维体系等建设工作，与团队共同推进业务应用运维标准化和自动化系统建设.加入蘑菇街之前，曾在淘宝工作，负责淘宝商品详情等业务的运维工作。
