干货：魅族基础架构运维之路

本文来自魅族云平台系统架构师梁鹏在听云应用性能管理大讲堂—《魅族基础架构运维之路》分享总结

 

很高兴能在这里跟大家做一个分享和交流。我叫梁鹏，来自魅族云平台，主要是负责魅族系统运维、平台建设和自动化的工作。很感谢听云邀请我过来，今天我分享的主题主要是魅族基础系统架构运维之路，主要分三个方面给大家做介绍：1、发展历程；2、运营现状；3、系统运维的未来。

 

在正式分享之前，先跟大家说一下公司的背景情况。魅族的互联网业务起步得比较早，2011年就开始，到2014年真正转变为一家移动互联网公司，从2014年起，我们的业务呈迅猛式增长。截止到2015年，注册用户超过3000万，应用商店也超过100万的应用，整个应用商店的下载量超过了100亿，营业收入比同期增长了12倍。到2016年，我们跟很多游戏厂商合作发行了多款游戏，游戏平台累计超过了3000万用户，游戏月活跃超过1200万。

 

随着业务的增长，运维面临的挑战是越来越大，运维人员遇到的问题越来越多，运维架构也在不断的变更优化，服务器规模从2011年只有5台的规模到2016年超过了6000多台。右图也可以看见近两年魅族服务器规模的一个增长趋势。

发展历程

这几年我们一直主要围绕着质量、效率、流程、成本来展开运维工作，并且发现我们运维遇到的问题，慢慢的由运维转化成技术营运，来优化我们的工作，提高运维人员的技术能力，这其中包括填坑、标准化，自动化、流程化和数据化，以及我们对未来混合云运营的一个展望。

 

 

远古时代

 

下面给大家具体讲一下几个发展历程中的时代。我们在2011年初-2011年12月份这个时代叫做“远古时代”，我们的规模比较小，机柜只有一个，服务器只有5台，业务线2条，这个时代当然存在很多问题，我们说几个主要的问题：

 

 

1、机房稳定性，主要体现在服务器会经常宕机，系统需要重装，需要人力来支撑。

 

2、监控的损失，服务器上线之后没有及时的监控，出现故障之后不能及时解决，业务的稳定得不到保障。

 

3、架构单点，业务上线之后没有部署高可用架构，对我们业务的稳定性也是有影响。比如我们的官网、论坛等等。

 

针对这一系列问题，首先在稳定性方面方面我们会有一些IDC的操作人员协助我们做一些管理和操作，另外，我们还会通过带外的管理口对服务器做一些操作，对系统进行重装。我们还有一些自动化的脚本，在自动监控方面早期部署了Nagios Cacti，主要是来监控系统稳定性，网络以及业务稳定性。在架构单点方面，主要还是靠人为来驱动，主要是推动业务部署高可用架构，提高业务的可用性这样的一个解决方案。

 

石器时代

 

大家也可以看到随着这些问题的解决，我们就步入了另外一个时代，这个时代我们叫做“石器时代”，这个时候魅族也是逐步向移动互联网开始转型。看一下石器时代的架构：

这个时候我们的IDC还是1个，机柜增长了30个，服务器和虚拟机的数量增长了800台，业务线拓展到100个，人力方面运维人员也扩展到12个，但是这个时代还是存在什么问题呢？几个主要的问题说一下

 

1、这个时代机房还存在着很多IBM的包箱、EMC的存储，这就不符合互联网的思维了，另外运维成本也是非常高的，在虚拟化方面我们使用的是VMware vSphere解决方案，管理和运维都给我们带来很多的成本，而且这一套解决方案的成本还是比较高的。面对这个问题我们是怎么解决的？其实我们跟大多数的互联网公司一样，逐步的使用X86服务器来代替，提高业务的稳定性。在管理方面起到比较大的作用，还节省了不少的成本。

 

2、第二个问题是机房资源不足，还有扩容难，以及资源管理问题，因为这个时代业务发展是比较快，所以业务需求比较多，而且都是比较紧急的。所以装机和交付的速度完全跟不上业务的需要。为了解决这个问题，我们部署了多个机房，并且把主要业务分多个机房部署，并且在各个机房部署冗余资源，除了满足业务需求的同时还满足一些计划外的需求。另外，在资源管理方面我们搭建了一个CMDB，来统一管理线上的一些资产。此时资源管理方面的效率大大的提升。

 

3、第三个问题是网络不稳定，活动日或者发布日的流量突增。面对这个问题，首先在硬件上就是更换核心网络设备，配置上有所提升，以至于在流量较大的时候，设备的承载方面没有问题，另外在带宽上做冗余，那么在网络流量突增的情况下，业务也不会因此造成影响。

 

这里提到一点，随着这些改变，我们的网络架构也变成了2.0，1.0架构是单机房，网络层面没有做虚拟化，使用的是HSRP，2.0架构是多机房，在网络层面使用虚拟化，大二层架构。

 

4、第4个就是DB服务器的IO问题导致的业务压力，早期DB使用的是SAS磁盘，读写频繁的时候，就会带来一些io问题。 

 

针对这么一个问题，我们对ssd磁盘或者pciessd进行测试，针对业务的特性对不同的业务配备ssd或者pciessd来满足业务的IO的需求。

 

5、第五个问题是批量操作和监控不完善，以及监控的覆盖率问题。因为这个时候我们的发展比较快，资源包括服务器的规模都比较多，所以这个时候会有一些批量的操作带来很多的人力成本。我们部署的Ansible，这个软件大家都比较熟悉，用来做一些批量的操作。在监控这方面监控，会联动CMDB，定时对线上运营中的机器做一个巡检，巡检到未加监控的机器就会定时给相关人员邮件通知来解决监控覆盖率低的问题

 

5、最后的问题就是安全性低，主要体现在早期所有的业务员都可以登录线上所有机器，没有权限限制或者管理。另外一个是来自外网的攻击，针对这个情况我们结合帐户管理平台CMDB对用户做一些权限的划分。举一个例子某个用户在CMDB上只能访问哪几个业务，只能登陆这几个业务的机器，所以这就在帐号管理方面有一个大幅度的提升，而且有一个操作的审计，后面还可以跟踪。

 

青铜时代

 

伴随着这些问题的解决，我们其实已经进入了青铜时代，来看看这个时代的规模，我们是两地三中心，机柜扩展到150个，服务器扩展到4000台，业务线也发展到200多条。在人力方面，我们有35个业务人员来支撑。

 

1、我们面对标准化率低的问题，而且维护成本越来越高，针对这一点，我们对标准化进行梳理，这当中包括很多比如软件标准化、系统标准化、硬件标准化等等。在系统标准化方面，我们开发了巡检平台，主要从系统常规、系统安全、系统内核等几个维度定时进行巡检，对出现问题的机器进行整改，确保线上标准化覆盖率100%。

 

2、关于业务架构单点的问题，这个时代业务发展比较迅速，架构单点的情况还是比较严重。解决方案是人工推动，先梳理现有的单点架构业务，然后去部署高可用架构。另外此时我们在架构上做冗余，部署两地三中心，当单个机房出现故障的时候，业务的可用性得以保障。3.0架构使用三网分离，DCI增加了专线，流量优先专线，专线出问题后在转到vpn。

 

3、另外供应商比较单一，这个供应商就是服务器，还有网络设备供应商，供应商单一带来很多问题，比如说成本方面，定制化方面，如果我们想追求一些定制化产品，在对单个管理过程中就很被动，所以在这个时候我们是遵循自己的一套运维设置标准，引入多个厂商来检测它的兼容性、稳定性，以及业务系统也是联系多个厂商，来建立标准。与此同时，也会制定SLA标准、定制化标准，如后续有新的采购需求，都需要按照此标准。

 

4、配置管理方面准确性低，服务器从上线到下线，它的状态改变，这个流程的管理没有一套很好的解决方案，导致现在的梳理不准确。针对这个情况，我们首先有一整套的服务器生命周期管理流程，从服务器的引入、生产、运营、下线一套管理流程来确保CMDB数据准确性，并且会结合一个工单平台，工单平台会跟CMDB进行对接，比如说要开发的时候，我们会发起我们CMDB的业务数，还有部门、产品线，最后当整个工单走完的时CMDB会自动去更改，状态也会由待营运状态改变为运营中，那么这个全部是全自动的，不需要人工参与的。

 

5、第五个问题就是业务的突增造成机房规模的突增，这个时代我们已经正式步入互联网时代，业务发展是突飞猛进的，此时面对业务的资源需求，不能及时的交付，此时我们的解决方案就是由原来的cobbler升级至装机平台，转化为无人职守安装，装机平台和cmdb对接，并没各个机房会保持一定的资源冗余率，以满足业务计划外的资源需求。后期我们也会使用容量管理对业务机器的资源使用情况进行审核。

 

6、最后一个问题就是故障多样性，在供应商多的情况下，由于每个厂商的配件可能不一样，故障后的日志收集方案不一样，导致故障发生时需要定义各个厂商的日志收集方式、维修人员授权等等操作，造成太多的沟通成本，这在效率维度也是一个痛点。针对这个问题，我们统一各厂商的日志收集方式，在业务高可用方面，部署高可用架构，当发生故障的时候，无需和业务进行沟通，直接关机进行硬件的维修操作。并按月对故障进行分析，并建立知识库，后续对这一类的故障可以快速进行处理。

 

铁器时代

 

随着这些问题的解决，可以说到了现在这个时代，我们称之为铁器时代，从2016年1月份到现在，我们的业务呈增长趋势。

 

来看一下现在的规模，IDC有多个，机柜大约200个，服务器数量超过了6000台，业务线大约200个，平台业务人员增长到43个。

 

这个时代问题还是有很多的：

1、第一个问题就是对于监控和告警的数据一直没有量化数据，当然也不能达到可视化的一个效果，比如月度短信告警数量统计时，无法在平台维度直接统计数据和展示数据，进而折算短信成本，针对这个情况，我们做了统一的告警平台，基础监控和业务监控都会和告警平台结合，各个平台告警数据统一从告警平台进行收敛、匹配策略后，在发送给相应的用户，这样就告警数据对比各个平台单独的告警数据就会减少很多，一方面减少了告警风暴，一方面告警数据可以在平台进行展示和统计，提高了工作效率。

 

2、机型套餐多，业务需求个性化。我们是怎么做的？根据线上的业务特性，比如说高IO类、一线、在线存储类、热点类，对线上的业务做一个分析，最后让机型跟业务的特性做整合。另外还会对CMDB占比比较小的做整合，比如说A业务100台，B业务只有2台，对于这种占比小的，也可以根据业务网做一个业务特性，划定为某一个业务的特性，然后跟不同的机型进行整合。

 

3、第三个问题业务的成本高，各个业务的ROI无法量化，比如某个业务投入的人力成本和开发成本远远大于他的产出成本这样的情况，针对这个问题，我们还是分两个维度：一是使用容量系统对资源进行使用率的考核，对于资源使用率较低的机器，推动业务进行业务混布，或者业务迁移至配置较低的机器上面。二是建立营收体系，搭建营收平台，统计各个业务的运营成本和营收成本。

 

4、工作流程化，前面说我们建立了服务器生命周期管理一整套流程，但是我们没有一个很好的平台管理，很多事情还是靠邮件沟通，这带来的人力成本是很高的。我们建立了这个工单平台，工单平台完全遵循服务器生命周期感觉的那一套流程，用于记录各个工单的流程、处理情况、处理人、耗时等等，同时也方便后续的工单跟踪情况，而且工单平台和cmdb对接，申请者提交需求的时候，会拉取cmdb业务树和部门进行填写，当工单完结的时候，会自动挂载业务以及修改服务器运营状态、还有对此业务的运维人员进行自动填写功能，大大的提高了工作效率。

 

5、第五个问题就是资源利用率的问题，前面也有讲过这个情况，就是使用容量平台来监控各个产品线的资源使用情况，然后对资源使用率较低的业务进行混布或者迁移方案。

 

6、最后一个问题就是预案管理，随着魅族现在业务线越来越多，特别是游戏，如果游戏服务器出问题，那么损失还是挺大的，比如收入的损失，玩家群体的损失等等，前面也有说到我们现在部署两地三中心，在多个数据中心部署业务，当单个数据中心出现故障的时候，可以快速切换到别的IDC服务器，确保服务正常的运行。另外也会对专线进行定时切换演练，以测试专线切换后是否有问题发生。

讲了这么多，从2011年到现在，整个历程的问题跟我们是怎么解决的。再详细的说两点，这个业务的增长是从5台到6000台，速度很快，这就很考验基础设施的建设。另外一个是很考验交付效率能力，网络架构也升级到3.0，我们用装机平台解决我们的工单系统，跟我们的CMDB联动，降低我们的操作。

 

成本控制方面其实在一个海量互联网业务的公司来说，其实微优化可以节省很多成本，这个前几天和腾讯沟通的时候，他们的成本把控得比较严。所以成本这一部分做到最低的优化。我们从几个维度做：1、资源使用率；2、供应商方面；3、内部营收。从这三个方面进行成本控制。

运营现状

魅族现在的运维体系跟大部分互联网公司一样，采用多级分层模式，所有业务和DB都部署高可用架构，我们的技术平台跟业务平台也有很多的系统，比如发布平台、监控平台等等。在自动化过程中是根据遇到的情况，我们的思路是定义优先级，任务分解，先做最容易的，最能提高效率点，再做整合，通过各个子系统的整合，慢慢形成适合自己的自动化运维框架。

 

下面挑几个比较主要的系统跟大家说一下：

 

监控系统

我们采用的是server-proxy-client架构，client端的agent会定时主动上报数据至proxy中做临时缓存，proxy会定时将临时缓存的数据上报给server端存储在数据库，进而讲数据展示在zabbix界面。 

对监控模板标准化，针对不同的业务定义不同的模板，然后在zabbix平台定义告警匹配的动作，每个业务的运维/开发人员接收自己负责业务的告警。

 

监控覆盖率这个方面也是一样的，我们会先发邮件给相应的人员去处理这个情况，以保证我们的覆盖率，我们的覆盖率由早期比较低的一个百分比到达一个百分之百的状态，而且后续也会每天巡检，要一直维持百分之百的状态。

 

统一告警平台

在没有告警平台之前，所有的告警信息都从zabbix平台发出，此时服务器出现故障后，短信和邮件告警就会很多，如果不处理，则会一直告警，出现短信轰炸的情况，针对此情况，我们开发了告警平台，说一下工作机制：

 

在统一告警平台中配置服务的匹配策略和故障合并，当告警信息从zabbix生成后，通过预先设定的脚本发送给告警平台，在触发策略，最后故障合并后，在触发告警升级策略，即告警首先接收人，如10分钟没处理，则升级给团队处理。

从上面可以看到，我们通过这个平台降低了运营成本，这是告警平台的一个截图，左边是应用级，应用级就包括CPU、内存等等，下面是根据业务，哪个业务按月、按天，这也是后续需要优化的。下面是一个月的尾天，哪天的告警比较多，可以根据这天的情况估计一下，保障后面的故障不会发生。

 

 

工单平台

因为业务发展比较迅速，所以业务需求还是比较个性化、多样化的，当然还有比较紧急的。虽然我们有全生命周期管理来管理这一块，但是我们跟他们还是有很好的沟通。另外还有就是常规性操作的，所以我们就研发了这个工单平台，并且我们工单平台会把服务器所有流程放在里面，而且还有一些自定义的功能，可以减少我们我们跟开发之间的沟通成本，开发只需要我们工作人员提需求，不同的需求，不同的节点，比如说OP审核节点，以及他们的开发审核节点，最后整个工单流程完成之后，所有的产品都自动化了。生命周期管理自动化，工单流程的可视化、可追踪。以前用邮件沟通，你根本无法去追踪这个单处理到什么进度了，有这个工单平台，在这个平台上就可以直接查看，查看工单的处理状态。

巡检平台

 

 

早期我们出现过内核参数设置未生效的问题，iptables处于打开状态，导致宿主机在大流量和高并发量的情况下网卡容易丢包，影响多个业务的稳定性。我们意识到在OS层，要做定制化和标准化，通过巡检系统发现非标准机器，定时整改。系统巡检主要包括系统初始化检测、系统常规检测、系统内核检测、系统安全检测和下线检测。

 

这个是我们巡检平台的界面，可以按季、按月生成一个巡检标准率，第一点是建立标准体系，提升工作效率。我们这个巡检平台刚刚建立的时候，梳理了15个组件系统标准化，发现问题96个，服务器整改项目有4000多次，降低了线上系统的风险，有效的避免了因非标准因素导致的风险。

 

更安全的堡垒机

 

 

这个还是基于之前早期系统，早先的用户中心数据库会拖走，win堡垒机密码有失窃的情况，安全隐患还是很大的。我们基于以上这些需求做了更安全的堡垒机， 

 

我们的堡垒机架构是在不同机房部署主备堡垒机，两台堡垒机之间的数据是同步的，用户可以申请软件或者硬件的Token，然后通过RSA认证登录到堡垒机，此时IDC账户管理平台会对登录用户进行审计把控，包括用户管理、登录记录、分配权限、操作记录等等，最后登录到服务器上。最后可以提高安全，提高线上系统的安全情况。 

 

流程管理

我们建立了整套服务器生命周期管理，从产品，服务器的引入，生产、运营、下线，分为几类：资源交付类、资源调动类还有一个生命周期末端流程。结合工单平台现在已经正式线上运行了，这一套流程建立之后，OP跟开发之间的沟通成本，节约的时间已经大约2倍多了。

 

容量系统

 

 

我们所有数据都来自于监控系统，CPU、内存、IO能力，我们通过容量系统取数据作一些分析，对使用率比较低的这些又做一些整改，上面那个图形可以看到阅读，或者按天资源使用率的情况。

 

另外，我们也会做业务成本的考核。这里的业务成本考核是做一个帮衬作用，主要是一个营收平台，我们做了一个内部营收平台，对内的各个业务做一些核算来关注每一个业务的运营成本和产出。这样每个部门的成本关注度也就提升了五倍。

展望

最后是我们对未来的一个展望。其实魅族也希望内外兼修，来打造精益化运营，通过运维自动化、监控自动化、安全管理、流程管理，来提高服务质量。同时我们也会协同开发平台，大数据平台，为我们的业务提供更优的服务。

转载于:https://my.oschina.net/u/2969313/blog/1510785