共计 7703 个字符，预计需要花费 20 分钟才能阅读完成。
很高兴能在这儿跟大家做一个分享和交流。我叫梁鹏，来自魅族云平台，主要是负责魅族系统运维、平台建设和自动化的工作。很感谢听云邀请我过来，今天我分享的主题主要是魅族基础系统架构运维之路，主要分三个方面给大家做介绍：1、发展历程；2、运营现状；3、系统运维的未来。
在正式分享之前，先跟大家说一下公司的背景情况。魅族的互联网业务起步得比较早，2011 年就开始，到 2014 年真正转变为一家移动互联网公司，从 2014 年起，我们的业务呈迅猛式增长。截止到 2015 年，注册用户超过 3000 万，应用商店也超过 100 万的应用，整个应用商店的下载量超过了 100 亿，营业收入比同期增长了 12 倍。到 2016 年，我们跟很多游戏厂商合作发行了多款游戏，游戏平台累计超过了 3000 万用户，游戏月活跃超过 1200 万。
随着业务的增长，运维面临的挑战是越来越大，运维人员遇到的问题越来越多，运维架构也在不断的变更优化，服务器规模从 2011 年只有 5 台的规模到 2016 年超过了 6000 多台。右图也可以看见近两年魅族服务器规模的一个增长趋势。
这几年我们一直主要围绕着质量、效率、流程、成本来展开运维工作，并且发现我们运维遇到的问题，慢慢的由运维转化成技术营运，来优化我们的工作，提高运维人员的技术能力，这其中包括填坑、标准化，自动化、流程化和数据化，以及我们对未来混合云运营的一个展望。
下面给大家具体讲一下几个发展历程中的时代。我们在 2011 年初 -2011 年 12 月份这个时代叫做“远古时代”，我们的规模比较小，机柜只有一个，服务器只有 5 台，业务线 2 条，这个时代当然存在很多问题，我们说几个主要的问题：
- 机房稳定性，主要体现在服务器会经常宕机，系统需要重装，也就是说需要投入人力来支撑。
- 监控的损失，服务器上线之后没有及时的监控，出现故障之后不能及时解决，业务的稳定得不到保障。
- 架构单点，业务上线之后没有部署高可用架构，对我们业务的稳定性也是有影响。比如我们的官网、论坛等等。
针对这一系列问题，首先在稳定性方面方面，我们会有一些 IDC 的操作人员协助我们做一些管理和操作，另外，我们还会通过带外的管理口对服务器做一些操作，对系统进行重装。我们还有一些自动化的脚本，在自动监控方面早期部署了 NagiosCacti，主要是来监控系统稳定性，网络以及业务稳定性。在架构单点方面，主要还是靠人为来驱动，主要是推动业务部署高可用架构，提高业务的可用性这样的一个解决方案。
大家也可以看到随着这些问题的解决，我们就步入了另外一个时代，这个时代我们叫做“石器时代”，这个时候魅族也是逐步向移动互联网开始转型。看一下石器时代的架构：
这个时候我们的 IDC 还是 1 个，机柜增长了 30 个，服务器和虚拟机的数量增长了 800 台，业务线拓展到 100 个，人力方面运维人员也扩展到 12 个，但是这个时代还是存在什么问题呢？几个主要的问题说一下
1、这个时代机房还存在着很多 IBM 的刀箱、EMC 的存储，这就不符合互联网的思维了，另外运维成本也是非常高的，在虚拟化方面我们使用的是 VMwarevSphere 解决方案，管理和运维都给我们带来很多的成本，而且这一套解决方案的成本还是比较高的。面对这个问题我们是怎么解决的？其实我们跟大多数的互联网公司一样，逐步的使用 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，定时对线上运营中的机器做一个巡检，巡检到未加监控的机器就会定时给相关人员邮件通知来解决监控覆盖率低的问题。
6、最后的问题就是安全性低，主要体现在早期所有的业务员都可以登录线上所有机器，没有权限限制或者管理。另外一个是来自外网的攻击，针对这个情况我们部署 RSA 堡垒机结合帐户管理平台对用户做一些权限的划分。举一个例子某个用户在 CMDB 上只有几个业务，那么账户管理平台权限分配也只能看到这几个业务的业务，堡垒机只能登录这几台机器，所以这就在安全方面有一个大幅度的提升，而且还会对用户的操作进行审计和记录，后面还可以跟踪。
伴随着这些问题的解决，我们已经进入了青铜时代，来看看这个时代的规模，我们是两地三中心，机柜扩展到 150 个，服务器扩展到 4000 台，业务线也发展到 200 多条。在人力方面，我们有 35 个运维人员来支撑。
在青铜时代，我们还是有很多问题存在的：
1、线上服务器的标准化率低，比如系统层未做标准化，比如 yum 源未标准化，这样就可能会造成一些安装软件的兼容性问题或者一些其他的问题，我们对于标准化，主要也是从几个维度来做的，比如系统标准化方面，统一 yum 源服务器，其他的还有软件标准化、组件标准化、硬件标准化等等。在系统标准化方面，我们开发了巡检平台，主要从系统常规、系统安全、系统内核等几个维度定时进行巡检，对出现问题的机器进行整改，确保线上标准化覆盖率 100%。
2、关于业务架构单点的问题，这个时代业务发展比较迅速，架构单点的情况还是比较严重。解决方案是人工推动，先梳理现有的单点架构业务，然后去部署高可用架构。另外此时我们在架构上做冗余，部署两地三中心，当单个机房出现故障的时候，业务的可用性得以保障。此时的网络架构也随之升级到 3.0 架构，3.0 架构使用三网分离，DCI 增加了专线，流量优先专线，专线出问题后在转到 vpn。
3、第三个就是供应商比较单一，比如我们在采购服务器的时候，一些厂商的定制化要求无法满足，最明显的例子就是带外管理的一些功能无法定制化，此时就没有其他厂商可以选择，而且在成本方面也不能得到一个很好的成本控制。此时我们就引入多个供应商，按照测试标准进行测试，确认设备是否可以满足业务的需求，或者兼容性是否满足，亦或者是稳定性是否满足等等，测试通过后，确认设备可以正常引入。与此同时，也会制定 SLA 标准、定制化标准，如后续有新的采购需求，都需要按照此标准。
4、第 4 个在资源配置管理方面，准确性低服务器从上线到下线，它的状态改变，这个流程的管理没有一套很好的解决方案，导致现在的平台数据不准确。针对这个情况，我们首先建立一整套的服务器生命周期管理流程，从服务器的引入、生产、运营、下线一套管理流程来确保 CMDB 数据准确性，并且会结合工单平台，工单平台会跟 CMDB 进行对接，比如说开发提交需求的时候，会拉取 CMDB 平台的业务树，还有部门、产品线等等，最后当整个工单走完的时 CMDB 会自动去更改，状态也会由待营运状态改变为运营中，那么这个全部是全自动的，不需要人工参与的。
5、第 5 个问题就是业务的突增造成机房规模的突增，这个时代我们已经正式步入互联网时代，业务发展是突飞猛进的，此时面对业务的资源需求，不能及时的交付，此时我们的解决方案就是由原来的 cobbler 升级至装机平台，转化为无人职守安装，装机平台和 cmdb 对接，并没各个机房会保持一定的资源冗余率，以满足业务计划外的资源需求。后期我们也会使用容量管理对业务机器的资源使用情况进行审核。
6、最后一个问题就是故障多样性，在供应商多的情况下，由于每个厂商的配件可能不一样，故障后的日志收集方案不一样，导致故障发生时需要定义各个厂商的日志收集方式、维修人员授权等等操作，造成太多的沟通成本，这在效率维度也是一个痛点。针对这个问题，我们统一各厂商的日志收集方式，在业务高可用方面，部署高可用架构，当发生故障的时候，无需和业务进行沟通，直接关机进行硬件的维修操作。并按月对故障进行分析，并建立知识库，后续对这一类的故障可以快速进行处理。
随着这些问题的解决，可以说到了现在这个时代，我们称之为铁器时代，从 2016 年 1 月份到现在，我们的业务呈增长趋势。
来看一下现在的规模，IDC 有多个，机柜大约 200 个，服务器数量超过了 6000 台，业务线大约 200 个，平台运维人员增长到 43 个。
这个时代问题还是有很多的：
1、第一个问题就是对于监控和告警的数据一直没有量化数据，当然也不能达到可视化的一个效果，比如月度短信告警数量统计时，无法在平台维度直接统计数据和展示数据，进而折算短信成本，针对这个情况，我们做了统一的告警平台，基础监控和业务监控都会和告警平台结合，各个平台告警数据统一从告警平台进行收敛、匹配策略后，在发送给相应的用户，这样就告警数据对比各个平台单独的告警数据就会减少很多，一方面减少了告警风暴，一方面告警数据可以在平台进行展示和统计，提高了工作效率。
2、第二个问题就是机型套餐多，业务需求个性化。我们是怎么做的？根据线上的业务特性，比如说高 IO 类、一线、在线存储类、热点类，对线上的业务做一个分析，最后让机型跟业务的特性做整合。另外还会对 CMDB 占比比较小的做整合，比如说 A 业务 100 台，B 业务只有 2 台，对于这种占比小的，也可以根据业务特性做分析，划定为某一类业务的特性，然后根据不同的机型进行整合。
3、第三个问题业务的成本高，各个业务的 ROI 无法量化，比如某个业务投入的人力成本和开发成本远远大于他的产出成本这样的情况，针对这个问题，我们还是分两个维度：一是使用容量系统对资源进行使用率的考核，对于资源使用率较低的机器，推动业务进行业务混布，或者业务迁移至配置较低的机器上面。二是建立营收体系，搭建营收平台，统计各个业务的运营成本和营收成本。
4、第 4 个问题就是工作流程化，前面说我们建立了服务器生命周期管理一整套流程，但是我们没有一个很好的平台管理，很多事情还是靠邮件沟通，这带来的人力成本是很高的。我们解决方案是建立工单平台，工单平台完全遵循服务器生命周期管理的那一套流程，用于记录各个工单的流程、处理情况、处理人、耗时等等，同时也方便后续的工单跟踪情况，而且工单平台和 cmdb 对接，申请者提交需求的时候，会拉取 cmdb 业务树和部门进行填写，当工单完结的时候，会自动挂载业务以及修改服务器运营状态、还有对此业务的运维人员进行自动填写功能，大大的提高了工作效率。
5、第 5 个问题就是资源利用率的问题，前面也有讲过这个情况，就是使用容量平台来监控各个产品线的资源使用情况，然后对资源使用率较低的业务进行混布或者迁移方案。
6、最后一个问题就是预案管理，随着魅族现在业务线越来越多，特别是游戏，如果游戏服务器出问题，那么损失还是挺大的，比如收入的损失，玩家群体的损失等等，前面也有说到我们现在部署两地三中心，在多个数据中心部署业务，当单个数据中心出现故障的时候，可以快速切换到别的 IDC 服务器，确保服务正常的运行。另外也会对专线进行定时切换演练，以测试专线切换后是否有问题发生。
这 6 点大部分在发展历程中已经详细讲解了，这里在抽出两个描述一下：
一个就是基础设施的规划，从远古时代到铁器时代，这个业务突飞猛进的发展，服务器从 5 台到 6000 台，网络架构也升级到 3.0，这就很考验基础设施的建设。另外一个是很考验交付效率能力，我们使用装机平台来安装系统，并使用工单系统联动 CMDB 平台，降低我们的操作，提高工作效率。
另外一个就是成本控制方面，其实在一个海量互联网业务的公司来说，稍微优化就可以节省很多成本，此时控制成本也称为一项势在必行的工作。
我们从几个维度做：1、资源使用率；2、供应商方面；3、内部营收。从这三个方面进行成本控制。
魅族现在的运维体系跟大部分互联网公司一样，采用多级分层模式，所有业务和 DB 都部署高可用架构，我们的技术平台跟业务运维做了很多实用的系统，比如发布平台、监控平台等等。在自动化过程中我们根据遇到的情况，找出痛点，归纳整理出需求，并考虑如何实现。我们的思路是定义优先级，任务分解，先做最容易的，最能提高效率点，再做整合，通过各个子系统的整合，慢慢形成适合自己的自动化运维框架。
下面挑几个比较主要的系统跟大家说一下：
我们采用的是 server-proxy-client 架构，client 端的 agent 会定时主动上报数据至 proxy 中做临时缓存，proxy 会定时将临时缓存的数据上报给 server 端存储在数据库，进而讲数据展示在 zabbix 界面。
对监控模板标准化，针对不同的业务定义不同的模板，然后在 zabbix 平台定义告警匹配的动作，每个业务的运维 / 开发人员接收自己负责业务的告警。
监控覆盖率这个方面也是一样的，我们会先发邮件给相应的人员去处理这个情况，以保证我们的覆盖率，我们的覆盖率由早期比较低的一个百分比到达一个百分之百的状态，而且后续也会每天巡检，要一直维持百分之百的状态。
在没有告警平台之前，所有的告警信息都从 zabbix 平台发出，此时服务器出现故障后，短信和邮件告警就会很多，如果不处理，则会一直告警，出现短信轰炸的情况，针对此情况，我们开发了告警平台，说一下工作机制：
在统一告警平台中配置服务的匹配策略和故障合并，当告警信息从 zabbix 生成后，通过预先设定的脚本发送给告警平台，在触发策略，最后故障合并后，在触发告警升级策略，即告警首先接收人，如 10 分钟没处理，则升级给团队处理。
从上面可以看到，我们通过这个平台降低了运营成本，这是告警平台的一个截图，左边是应用级，应用级就包括 CPU、内存等等，下面是根据业务，哪个业务按月、按天，这也是后续需要优化的。下面是一个月的每天告警情况，哪天的告警比较多，可以根据这天的情况分析一下，保障后面的类似故障不会发生。
因为业务发展比较迅速，所以业务需求还是比较个性化、多样化的，当然还有比较紧急的。虽然我们有全生命周期管理来管理这一块，但是我们跟他们还是有很多的沟通成本。所以我们就研发了这个工单平台，工单平台会把服务器所有流程放在里面，而且还有一些自定义的功能，可以减少我们我们跟开发之间的沟通成本，开发只需要在平台提交需求，填写完成后，流程到达下一节点，根据不通流程的设计特点，到达不通的节点，比如领导审核节点、业务资源池审核节点，最后由 OP 审核，实现业务的上线，上线的同时，cmdb 的状态和业务树也会随之发生变化，无需人为操作。这样就可以减少人为沟通的一个成本，而且实现了生命周期管理自动化，并且流程方面也可以实现可视化、可追踪的一个情况。
早期我们出现过内核参数设置未生效的问题，iptables 处于打开状态，导致宿主机在大流量和高并发量的情况下网卡容易丢包，影响多个业务的稳定性。我们意识到在 OS 层，要做定制化和标准化，通过巡检系统发现非标准机器，定时整改。
系统巡检主要包括系统初始化检测、系统常规检测、系统内核检测、系统安全检测和下线检测。
这个是我们巡检平台的界面，可以按季、按月生成一个巡检标准率，第一点是建立标准体系，提升工作效率。我们这个巡检平台刚刚建立的时候，梳理了 15 个组件系统标准化，发现问题 96 个，服务器整改项目有 4000 多次，降低了线上系统的风险，有效的避免了因非标准因素导致的风险。
我们建立这个更安全的堡垒的初衷也是线上发生了一些安全事故，比如用户中心数据库会拖走，win 堡垒机密码有失窃的情况，安全隐患还是很大的。我们基于以上这些需求做了更安全的堡垒机。
我们的堡垒机架构是在不同机房部署主备堡垒机，两台堡垒机之间的数据是同步的，用户可以申请软件或者硬件的 Token，然后通过 RSA 认证登录到堡垒机，此时 IDC 账户管理平台会对登录用户进行审计把控，包括用户管理、登录记录、分配权限、操作记录等等，最后登录到服务器上。
我们的堡垒机体系是通过 RSA Token + 堡垒机模式实现角色管理与授权审批、信息资源访问控制、操作记录和审计、系统变更和维护控制。避免了登录账号管理混乱、运维权限划分不明、认证方式过于简单、对运维过程没有监控措施、对研发人员的运维次数没有合理的运维统计方式。
在流程管理这块，我们建立服务器生命周期管理。
服务器的引入、生产、运营、利旧、退役的生命周期闭环，需要高效的自动化流程支撑。通过流程设计建立每个流程的模型，一般每个流程都要涉及到多个部门角色和系统，需要确定关键环节、职责分工、系统间接口，为了降低流程开发成本，需要考虑原子流程 - 组合流程 - 业务流程的分级实现模式。
通过流程管理，我们各个团队之间节省沟通时间想比较之前已大于两倍，资产准确性 100%。
我们容量系统的数据来自于监控系统，监控系统会对服务器各个部件进行监控，目前我们容量系统服务器的计算能力，在服务器 cpu、内存、io、网络能力中取最大值，算作服务器的高负载情况。对资源使用率较低的机器，我们会驱动业务进行资源整合、或者迁移业务至低配置的服务器中，或者迁移至 docker 中。
另外，我们也会做业务成本的考核。这里的业务成本考核是做一个帮衬作用，主要是一个营收平台，我们做了一个内部营收平台，对内的各个业务做一些核算来关注每一个业务的运营成本和产出。这样每个部门的成本关注度也就提升了五倍。
最后是我们对未来的一个展望。其实魅族也希望内外兼修，来打造精益化运营，根据运营场景设计串接各个自动化节点，逐渐形成自动化运营的场景闭环。通过运维自动化、监控自动化、安全管理、流程管理，来提高服务质量。同时我们也会协同开放平台，大数据平台，为我们的业务提供更优质的服务。
文章来自微信公众号：运维帮
