| 编辑推荐: |
| 本文来自于网络，文章主要介绍主要介绍了美图的
DevOps 实践，如何提升团队的效能以及美图的监控体系建设等相关知识。 |
|
我在运维这个领域做了十多年，2011 年我从海南去到了北京新浪微博，2016年从微博离开。
在微博六年多时间里，我几乎见证了微博整个发展，当时主要是做微博的运维，微博整个后端服务的建设以及各种运维的经验都是亲身经历，像微博我刚开始去的时候只有一百多台服务器，走的时候是几万台服务器，发展还是非常迅猛的。2016年底我就去了美图，主要负责美图的运维，例如应用运维、大数据运维，DBA，监控、成本、质量。
我今天分享的主题是“基于DevOps打造高效运维团队”。分享的主题主要四个方面：
第一，讲一下美图DevOps的实践；
第二，从关注效能的角度讲如何打造高效的运维团队；
第三，持续集成实践；
第四，如何做好监控体系建设；
一. 美图的 DevOps 实践
我们首先看一些场景，传统产品交互模式如下图中所看的这样，基本上从产品开发、测试、最终上线的整个流程的交互，安全团队会在开发阶段就介入做各种评估，一直到测试上线估，包括安全体系落地等。其实当
DevOps 加入了安全这个领域，整体会变的比较复杂。
1.1 传统模式的特点
传统模式如果没有比较好的高效的方式，这种交付整个过程间的流转、时间会非常长。它的特点是什么？
第一个就是非自动化，我们看到部门之间其实是分隔的，很多东西需要相互之间沟通，而且很多标准也不一样，环境也不一样，很难打通链路上的自动化，这是很大的难点。
第二个就是迭代慢，没有自动化的流程迭代会比较慢。
第三个是环境一致性差，团队内部都有很多部署的标准不一样，现在都往容器化方面去做，我们也建设了整套容器平台，所有线上交付都通过容器镜像标准交付。在新浪的时候是一起推进容器平台
DCP 的建设，它是做整个容器的自动扩容，甚至和公有云打通做混合云的体系，这些经验也在美图做了一些落地。
那么新的方式我们如何做比较好？刚才说的是传统模式的交付模式，还有一个配合模式。
从上面可以看到交付会涉及到很多的部门，很多流程和标准都不统一，这个时候就有点像植物大战僵尸一样，没有统一的目标，自己所做的事情很简单，就朝自己的方向去做，但是整体的目标是一样的，这样看起来没什么问题，实际上最大的问题就是效率的问题。
它的特点是团队各自规划目标，很难达成所有团队的共识，共识非常重要。很容易存在的结果就是重复建设，这在互联网公司非常多，几乎稍微大一点的团队，超过千人的团队重复建设会非常得多。
如果不能把偏公共的东西都统一起来，这时候对人力的成本、服务器资源的成本都构成了很大的损失。
所以，公司尤其是技术的管理者有必要看到这些问题并且推进解决。
第三个特点也是非常重要的，也就是团队之间不够信任，像区块链它最终解决的就是共识的问题，传统的团队也是这样，团队之间很难达成大家都认同的共识，这些都是一些很实在的问题。
有些 DevOps 项目，没有二三十人的团队是很难落地的，这样各自来做的话，很容易项目做着做着就夭折了，这些特点在每个公司都是很常见的。
1.2 DevOps 能解决什么?
如何解决这些核心问题，回到DevOps本身，DevOps能够解决什么问题？
两个维度来看，第一个维度就是关注组织，也就是我们的组织结构。我们的团队如何协同？如何配合？这个层面如果有比较好的方式，其实是可以提升效率的。
其次就是关注整个软件交付生命周期，从产品的想法以及线下落地和最终维护，产品如何达到很快、很高效的模式？其实
DevOps 就是解决这两个问题，这两个问题也是引入一些思想的关键。
但是在整个行业里，你跟一百个人交流，甚至跟非常熟悉的人交流观点都是不一样的，很多人理解的思路、理解的方式，或者所切入的经验等等都不一样，所以理解也都是不一样的。
我也关注 DevOps 很久了，在网上交流的过程中也学到了很多东西，我个人目前来看有两方面东西是非常好的。
第一方面台湾有一个人叫陈正玮，这个人分享了非常多的 DevOps 体系，他的思维和理念都非常超前，大家可以看他对
DevOps 的理解。
国内目前做的比较好的就是 GOPS 大会主办方，他们在 DevOps 标准这一块做的比较好，并且很成体系，而且发布了很多的标准也是在指导整个行业去朝着更高效的方式去做。
那么美图到底是怎么应用 DevOps 的理念让团队更高效呢？我们也是从刚才讲到的两个点去做。
第一个点就是从团队效能。比如说我们同组织结构上如何调整会比较好？什么样的组织结构以什么样的模式适合推行
DevOps，有运维开发能力的就是 DevOps？肯定不是。
其次就是如何和开发更好的结合。包括测试以及安全团队，这就是从组织结构和敏捷两个方面去做。其次我们
DevOps 具体实践过程中，怎么在项目中去落地？
二. 打造高效团队
如何提升团队的效能，我从三个结构上来讲：
第一，组织结构；
第二，敏捷团队；
第三，工程师文化；
2.1 组织结构
组织结构是比较重要的，我看了很多互联网公司以及传统公司的组织结构，无外乎是这么几种。
第一张图是层次很清晰的结构，第二张图是类似于腾讯BG+BU这种，各个团队都有自己的技术产品线，BG有产品、有测试、有运维。
其实这两种方式每个公司都有自己所谓的基因，这些基因有时候会决定它所在公司的组织结构，并没有哪个好哪个不好。
从 DevOps 这一块，我们觉得比较好的理念就是这种组织结构，就是把不同角色的人聚集在一起做事，这个东西很重要。
第一个强调扁平，很多东西不需要太复杂。其次能把所有人、所有团队的目标达成一致。这个东西怎么解决呢？你不可能一下子大变，把所有组织结构调整在一起。
我们有一种方式，就是关注如何提升团队的执行力，我们从这个维度切入，我们怎么做呢？可以看一下我们的方式很简单，就是采用虚拟化的方式去做。
我们把一个大的项目做成、落地并且推进，而且推进的很好，这样的团队结构非常重要，就是虚拟化的团队。
我们很多团队都是虚拟化团队在做，你在管理上是隶属于开发团队的，但是项目上会有PMO的介入，PMO会把这个团队打造成虚拟团队，所有的人相当于在项目上是同等汇报的，既向团队汇报，也会向项目汇报，而且每周也会有敏捷上的推进。
比如说我们要推进容器化的东西，这时候它涉及到的职能是非常多的，这些职能都拉进团队在做，而且还会给予预期，以后成果也是共享。所以这个东西也很重要，你在共识上要达到一致的一点是比较好的。
我们现在都在虚拟团队上做，虚拟团队我们会有股东的结构，就相当于各个团队的股东会参与一些决策，剩下就是各个团队涉及到的非常核心的人员参与进来做一些事情。
从公司层面我们也做了比较大的调整，之前我们的工作组织结构非常简化，比较散，没有比较好的结构。
我们在去年的时候也是参考了腾讯的组织结构，把所有的产品从公司战略上去做BG、BU的模式。从公司实体层面是BG、BU的模式，从公司项目上是虚拟化团队，基本上由这些维度调整我们公司主力结构，相对来说在这种环境下比较好落地，而且让我们很多项目能够高效的运转。
2.2 敏捷团队
产品从开发到测试再到运营以及线上都采用敏捷性的管理，我们每个产品都会有PMOGL在做，我们的任务都是采用Kaban管理。
我们海外的项目，它推进项目的就是敏捷化的管理，技术也会参与到产品决策中来，以前更多的是产品提一个需求我就完成了，什么时候排期就
OK了，这种产品就要求技术前期就探讨如何做好这些功能，这里面有没有新的思考或者功能点？使用看板可以缩短整个前期的沟通，总结出来产品要做的事情，在一些相关的讨论上也都是主要的人在做，每天会形成任务的列表。
根据这样的方式来做，我们在效率上的提升非常明显。具体在做的过程中肯定需要配套一些工具，因为光有模式和思路还不行，工具用什么在做？
我们分为两类工具，一类是跨大部门的工具，主要是Confluence，所有公司都会用这个，这也是运维来部署、由高层支持。在项目内部我们还会有更轻量级的工具，比如说Slack、Trello。由PMO跟进整体的进度，整体效率就会提升很多。
这些基本能够解决让我们之前的项目很高效的运转，我们从组织结构、敏捷、工具、文化、思路各个方面去切入，去提升我们产品的交付。
2.3 工程师文化
我们要求的不止是运维内部的项目高效，更多是想看技术怎么样对产品有帮助，看的层面会更高、更大，从产品的交付流程来看，这个是我觉得非常重要的。这其实也有自己的思路，每个公司有自己的情况。在公司内部有这样的环境其实也可以按照这样的方式去做。
另外我们会有各种塑造工程师文化的活动，比如说我们会定期有美图互联网沙龙，还有很多人到外面去做分享等，内部有各种奖励机制，写文章、写分享体现你的价值，个人在自己能力的提升上也能为公司去赢得一些东西，这都是双向的东西。
在公司内部很多技术团，比如说测试、运维、产品、开发，这里会有很多问题，比如说如何量化？
工程师文化是比较虚的东西，这里我们提出一个新的东西叫“故障文化”。
产品交付的过程当中永远高效会产生问题和故障，这时候通过这样的维度去做是可以的，我们制定了非常详细的故障管理制度，这个制度可以评估到每一个问题和故障。
每一个问题最终怎么样去提前发现问题？解决问题？在问题之后怎么样去跟进并且改进，改进有时间点、人，这套体系框住了问题之前、问题之后涉及到的人，怎么样去考核和关注。
前面说到我们会定非常详细的故障制度，故障制度其中有一个点就是评估每一个问题和故障。
怎么评估？比如说影响维度、影响时长、影响比例、影响用户数、问题所处的时间段，问题所处的产品是核心功能还是非核心功能等等，我们从五六个维度做核心评估，会有一个公式，比如说会影响什么，这个公式会对于每个问题和故障上会有一个分值，这个分值出来之后就可以评估，然后所有的东西都可以考核到团队，它是非常等量化、非常数据化的评估。
每一个问题发生的时候会有故障小组的人员跟进协调故障，在之后会形成详细的故障报告，这包含了一些要素。不要看非常简单，实际上它的体系非常丰富，它涵盖的面都有。
这里还有一些实际的问题，比如说每个产品评估标准是不是不一样？这里也做了通用评估和自定义评估，通用评估提到了通用维度的评估，还有些产品把金钱的维度纳入了进来。
所以我们在越来越细的过程中，也会深入每个产品，每个产品都会制定自己的故障评估制度，这个故障之后会有公式，公式计算出分值，所以这套体系制度非常重要，A级故障、B级故障、C级故障多少个，再做月报、半年报的分析。
这是故障制度里的东西，我们强调的是故障文化，你出问题不用怕，这时候你监控层面做的比较好的话，能提前监控和解决也是OK的。
故障文化我们通过培训来做，你不用害怕，该发生的问题发生也OK，我们更多强调后面如何改进，比如说这个故障发生了就列出来三个部门要改进什么样的东西，随着改进越来越多，整个服务的体系以及稳定性会得到极大的提升，这整体收益是非常大的，一方面有有效的制度，一方面有故障文化。
三. 持续集成实践
前面讲到了从团队组织结构包括一些敏捷和文化上，怎么样让我们团队保持很高效的运转，而且也有数据化、量化的评估，这些东西非常重要。在这种团队结构或者氛围下我们如何做项目落地？
美图大家熟知的产品就像美颜像机、美图秀秀、美图手机。我们的产品是非常多的，从硬件产品、软件产品、电商、PC端、移动端，我们在海外和国内都有很大的用户量，以前人们号称美图有十亿的用户，整体我们的产品是非常丰富的，覆盖的国家也是非常广的。
在这么多的产品矩阵里，我们会有一个问题，我们除了核心业务之外，业务非常多，但是量不是非常大。
这个时候会造成一个问题，我们很难用一套持续集成完成所有的需求，所以我们也做了一些退步和思考，我们把业务做了切分，我们物理机基于部署往容器里迁，但是迁的过程中还有一部分服务还是跑在物理机上，我们从物理机、容器、公有云在做。
物理机是基于Jekins Pipeline，容器基于Gitlab ci。首先看一下物理机，物理机之前有研发基于Jenkins
Pipeline 一体化。我们现在要求这些东西都以接口流通，比如说开发代码、集成测试以及到线上的环境等。
整体对于交付是统一的，这里我们分为五套环境。
第一个Dev环境，就是开发自己维护的环境。Dev-Common开发的环境可能依赖一些公共的服务，这些公共环境会由运维部署一套Dev公共服务的东西，这个环境需要稳定，就叫Dev-Common。
前面两个环境解决开发和自测。自测完了之后会跑入Pre 环境，最后就是Beta和Release，我们把五类完全打通通过自动化方式去运转。支持的发布模式也就这几种。
这是传统基于物理机的模式，我们从2017年开始做了差不多快大半年了，整个平台基于K8S，容器平台物理机的模式还是需要的。
第二部分基于容器的模式，我们基于K8S封装了一套复杂的系统，这套系统也会分这样的环境。我们所在的事业部叫做美图云事业部，我们在内部做私有云的模式，根据K8S做的。它主要就是这样的结构。
在这里可以看一下大概的页面情况，每一个服务所有的部署和功能都是这样的，容器是基于K8S。容器里也是可以的，我们把K8S所有的接口都封装起来，做出来的平台比K8S自带的东西好用很多。
在容器这个环境下，怎么做交付？这一块要跟测试达成一致的意见，都是基于Gitlab+CI这样的模式，它也是相对比较成熟的模式。
除了这种我们在海外也有很多的业务量，基本上都是用 DevOps。那么AWS跟国内的 IDC 如何互通？通过拉通专线互通，然后能用内部IDC的工具栈，直接低成本接入使用；不能用的，我们直接用云上自己的工具栈，云上的工具栈是比较丰富的，基本能完成各项DevOps需求。
四. 监控体系建设
最后介绍一下监控体系，因为我们有物理机、容器以及云和各种各样的场景，我们的环境非常多，一开始我们哪里有需求，监控团队就实现，最后我们会发现有很多套工具出来了，很难统一，并且维护成本也比较高，所以我们设计成了美图一体化监控。
底层有指标采集层和存储层。我们根据你的监控需求来看适合哪个层级就用哪个，这些成果要对外去展示，也就是说包括指标的访问还有数据代理，还有基于指标的数据分析。
这上面的应用画像怎么做？智能运维怎么做？要有一套这样的设计模式或者设计思路，你在做监控团队以及开发时，要去思考这样的东西，整体不能跨过这个东西。具体对接到我们的业务模式，后端的业务API、后端的资源、大数据、存储等。
美图我们在用户端也做了很多，比如说一个APP都是接入CDN的，之前做的过程中会发现CDN的覆盖过程中经常会有边缘节点的问题，我们做了非常多的APM去检测，有了数据之后就可以做融合调度；
一个业务在某个CDN节点覆盖，某个运营商和地区，当有问题的时候我们可以调度到另外一家CDN，而且要跟CDN厂商沟通好，融合调度之类的模式，避免自动切换失效问题，这样APP看起来问题会变少很多。这是我们整体很宏观的结构。
基本是上从用户端到服务端去看如何做好监控。拆开来看就是用户端要检测的数据，像美拍都是短视频直播类的，它的监控比较多，除了用户端的监控还要监控流媒体的东西，我们有质量调度还要做CDN监控和打分，这些东西怎么做？
我们之前用的第三方APM系统，当时博睿和听云都有用过，现在完全可以自研。流媒体及CDN打分机制都是自研来做的，APM也是一样的。
这些维度都可以覆盖到用户端的所有问题，这时候团队可以真正打造成从用户团队思考问题，如何提升用户体验，这个维度很重要的。
很多运维团队只是要完成需求的话，没有太大的价值。当然怎么样想做得更多，怎么样让老板看到你的团队有更大的价值，是有很多的思路的。
服务端的话业务层监控、服务层监控、基础资源，它在行业里都是非常成熟的经验。
这里有一个非常重要的点，我前面提到了所有的数据不管是用户端、服务端都收集起来了，我们指标都可以看了，我们还需要在告警层面做一些事，我们接入的系统越来越多，我们的告警越来越复杂，所以我们专门做了统一的告警平台，把所有的告警都接入这里去，发告警都从这里发，最终也可以发到具体的人和项目，这里主要实现统一告警平台，我们内部叫UAP。
它的思路很简单，从监控的数据出来，包括老的容器和物理机的数据，这些告警信息都到统一的告警平台里去，要怎么告警都有规则，包括做标准化也很重要。
最终再去基于一些用户组、用户等，与项目的关联关系去报给相应的人或者团队，每个告警还要有相应的平台，我们要知道告警现在的状态，告警发生了，持续了多久，告警的事件和机制是要有的，我们目前都是基于这样的一套结构。
这也是我们借鉴 open-falcon 的思路，然后自研的一套东西。一旦有这样的工具，就可以在更上层看问题，而且还可以和其他的东西集成，如果要没有这些东西的话还是原有的模式，各自发各自的，相互之间就没有关联关系。
这个逻辑非常简单，所有的监控告警都有对应的告警接口，所有告警的地方都按照相应的标准去发告警，这个告警会调度到我们的告警库里去，这里会有相应的任务模块，再加上规则和分析，确认告警如何去报？报给谁？由什么样的事件机制去做。而且它有相应的基础平台的人与项目关系，就可以帮助我们更好去发送告警，发送到最终的用户，逻辑非常简单。
在最终发送告警的时候，它收敛的维度我们会有很多方式，也会涉及到用什么样的方式去发。
我们用的是企业微信，这里有很多有用的东西，比如说我们几千台机器都会有磁盘的问题，这个时候我们有相应处理的群在企业微信里，这个时候作为应用运营、大数据运维都不用关心了，它会有相应的人生成工单。
但是这个东西要服务上下线的时候才会相应管理。我们支持很多告警渠道以及多种模式，最终才能做到比较好的“收敛”。
除了这些维度的收敛还要基于时间维度，这个告警是不是首次发？没人处理是不是不重要？这时候是不是把它组合在一起？多长时间发送一次？这个主要是讲我们怎么样去做告警收敛和告警风暴的，相当于所有监控之上做的平台。
另外一个维度就是可视化，我们前面可以看到我们设计思路里尽量用开源，数据可视化的东西我们尽量以Grafana的指标。
开源的工具大部分都支持，它在数据源上做改造都可以做。不管是前面提到的用户端等所有维度都可以在上面展示，我们可以做非常多的图谱来，这里只是举了一个物理机的基础资源监控。
他们都有关心的指标和大屏，所以这些可视化非常重要。这个核心点就是怎么样让这些东西统一起来，因为如果不统一的话，这些问题很难放在一起。
我今天主要分享就是这些，如何打造高效的运维团队，更好的驱动一些公司项目的交付和落地等。未来以来，预告一下，团队已逐步转向
SRE 团队的工作模式和思维方式，期待明年和大家分享如何在国内打造真正的 SRE 团队！ |
