魅族运维进化史：从“远古时代”到“铁器时代”的艰难蜕变

魅族的互联网业务起步较早，从 2011 年开始，到 2014 年才真正转变为一家移动互联网公司。随着业务的增长，魅族的运维架构在不断的变更优化，运维团队面临着越来越大的挑战，服务器规模从 2000 年只有 5 台的规模扩展到 2016 年超过了 6000 多台。

建网站原本是网站策划师、网络程序员、网页设计师等，应用各种网络程序开发技术和网页设计技术配合操作的协同工作。成都创新互联公司专业提供网站建设、做网站,网页设计,网站制作(企业站、响应式网站设计、电商门户网站)等服务,从网站深度策划、搜索引擎友好度优化到用户体验的提升,我们力求做到极致!

下面主要从三个方面介绍魅族基础架构的运维之路：

• 发展历程;
• 运维体系实践;
• 运维的未来展望。

魅族运维的艰难蜕变

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

下面按照发展历程中的各个时代进行说明：

远古时代

2011 年，公司规模比较小，只有机柜 1 个，服务器 5 台，业务线 2 条，主要存在的问题有：

• 机房稳定性差。服务器经常宕机，系统要重装，这些需要人力支撑。

相应的解决方法：在稳定性方面，运维团队有 IDC 的操作人员协助工程师做一些管理和操作，另外通过带外的管理口对服务器做一些操作，对系统进行重装。

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

相应的解决方法：一些自动化的脚本，在自动监控方面早期部署了 Nagios Cacti，来监控系统稳定性，网络以及业务稳定性。

• 架构单点。业务上线之后没有部署高可用架构，对业务的稳定性有影响，比如官网、论坛等等。
• 相应的解决方法：在架构单点方面，主要靠人为来驱动，推动业务部署高可用架构，提高业务的可用性。

石器时代

魅族逐步向移动互联网开始转型，架构如下：

IDC 还是 1 个，机柜增长了 30 个，服务器和虚拟机的数量增长了 800 台，业务线拓展到 100 个，人力方面，运维人员扩展到了 12 个，存在的主要问题有：

• 机房存在着很多 IBM 的包箱、EMC 的存储，运维成本很高。在虚拟化方面，运维团队使用的是 VMware vSphere 解决方案，它的管理和运维成本比较高。

如何解决这个问题呢?跟大多数的互联网公司一样，魅族逐步使用 X86 服务器来代替，提高业务的稳定性，节省了成本。

• 机房资源不足，扩容难，以及资源管理问题。因为业务发展比较快，相应的业务需求多且紧急，所以装机和交付的速度完全跟不上业务的发展需要。

为了解决这个问题，运维团队把主要业务分到多个机房部署，并且在各个机房部署冗余资源，除了满足业务需求的同时还满足一些计划外的需求。另外，运维团队在资源管理方面搭建了一个 CMDB，来统一管理线上的资产，使得资源管理效率获得很大提升。

• 网络不稳定，活动日或者发布日的流量突增。面对这个问题，解决办法首先是在硬件上更换核心网络设备，配置上有所提升，保证在流量较大的时候，设备的承载方面没有问题。

另外，在带宽上做冗余，这样在网络流量突增的情况下，业务也不会因此造成影响。同时，网络架构也变成了 2.0 架构，即多机房，在网络层面使用虚拟化，大二层架构。1.0 架构是单机房，网络层面没有做虚拟化，使用的是 HSRP。

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

针对这一问题，运维工程师对 ssd 磁盘或者 pciessd 进行测试，根据业务的特性为不同的业务配备 ssd 或者 pciessd 来满足业务的 IO 需求。

批量操作和监控不完善，以及监控的覆盖率问题。因为业务发展快，资源使用包括服务器的规模增多，给一些批量的操作带来很大的人力成本。这时，工程师通过部署 Ansible 来做一些批量的操作。

而且监控会联动 CMDB，定时对线上运营中的机器做一个巡检，巡检到未加监控的机器就会定时给相关人员发邮件，通知他们来解决监控覆盖率低的问题。

• 安全性低，主要体现在早期所有的业务员都可以登录线上所有机器，没有权限限制或者管理。另外一个是来自外网的攻击。

针对这个情况，工程师结合帐户管理平台 CMDB 对用户做一些权限的划分。比如某个账号在 CMDB 上只能访问哪几个业务，只能登陆这几个业务的机器。而且还有一个操作的审计，后面还可以跟踪。

青铜时代

伴随着上述问题的解决，魅族进入了青铜时代：两地三中心。具体是机柜扩展到 150 个，服务器扩展到 4000 台，业务线也发展到 200 多条。在人力方面，系统有 35 个业务人员来支撑。主要问题包括：

• 标准化率低，维护成本越来越高。针对这一点，运维团队对标准化进行了梳理，包括软件标准化、系统标准化和硬件标准化等。
• 在系统标准化方面，工程师开发了巡检平台，主要从系统常规、系统安全、系统内核等几个维度定时进行巡检，对出现问题的机器进行整改，确保线上标准化覆盖率 100%。
• 业务架构单点的问题。因为业务发展比较迅速，架构单点的情况比较严重。解决方案是人工推动，先梳理现有的单点架构业务，然后去部署高可用架构。
• 此时，运维团队在架构上做冗余，部署两地三中心，当单个机房出现故障的时候，业务的可用性可以得到保障。这时架构进入 3.0 架构，使用三网分离，DCI 增加了专线，流量优先专线，专线出问题后再转到 VPN。
• 供应商单一。这个供应商就是服务器供应商，还有网络设备供应商，因为供应商单一会带来成本和定制化方面的问题。
• 所以，运维团队先建立了一套自己的运维设置标准，然后引入多个厂商来检测它的兼容性、稳定性，以及业务系统也是联系多个厂商，来建立标准。
• 与此同时，也会制定 SLA 标准、定制化标准，如后续有新的采购需求，都需要按照此标准执行。
• 配置管理准确性低。服务器从上线到下线，它的状态改变在流程管理中没有很好的解决方案，导致现有的梳理不准确。
• 针对这个情况，运维团队首先建立了一整套的服务器生命周期管理流程，从服务器的引入、生产、运营、下线等来确保 CMDB 数据准确性，并且会结合一个工单平台，该工单平台会跟 CMDB 进行对接。
• 比如启动开发的时候，工程师会发起 CMDB 的业务数，还有所在部门、产品线，最后当整个工单走完时，CMDB 会自动去更改，状态也会由待运营状态改变为运营中，整个过程全部是全自动的，不需要人工参与。
• 业务的突增造成机房规模的突增。因为魅族正式步入互联网时代，业务发展迅猛，此时面对业务的资源需求，不能及时交付。
• 解决方案是由原来的 cobbler 升级至装机平台，转化为无人职守安装，装机平台和 CMDB 对接，并在各个机房保持一定的资源冗余率，以满足业务计划外的资源需求。后期，工程师使用容量管理对业务机器的资源使用情况进行审核。
• 故障多样性。在供应商多的情况下，由于每个厂商的配件可能不一样，故障后的日志收集方案不一样，导致故障发生时需要定义各个厂商的日志收集方式、维修人员授权等等操作，造成太多的沟通成本，这在效率维度也是一个痛点。
• 针对这个问题，工程师统一了各厂商的日志收集方式，在业务高可用方面，部署高可用架构;当发生故障的时候，无需和业务进行沟通，直接关机进行硬件的维修操作。接着，工程师按月对故障进行分析，并建立知识库，后续对出现的这一类故障可以快速进行处理。

铁器时代

铁器时代从 2016 年 1 月份到现在，魅族的业务仍呈增长趋势。现在的规模，IDC 有多个，机柜大约 200 个，服务器数量超过了 6000 台，业务线大约 200 个，平台业务人员增长到 43 个。这个时代，问题还是有很多：

• 对于监控和告警的数据，一直没有量化数据。当然也不可能达到可视化的一个效果，比如月度短信告警数量统计时，无法在平台维度直接统计数据和展示数据，进而折算短信成本。

针对这个情况，运维团队做了统一的告警平台，并与基础监控和业务监控结合。各个平台告警数据统一从告警平台进行收敛、匹配策略后，在发送给相应的用户，这样告警数据对比各个平台单独的告警数据就会减少很多，一方面减少了告警风暴，另一方面告警数据可以在平台进行展示和统计，提高了工作效率。

• 机型套餐多，业务需求个性化。根据线上的业务特性，比如说高 IO 类、一线、在线存储类、热点类，工程师对线上的业务做一个分析，最后让机型跟业务的特性做整合。

另外，工程师还会对 CMDB 占比较小的业务做整合，比如说 A 业务 100 台，B 业务只有 2 台，对于这种占比小的 B 业务，可以根据业务网做一个业务特性，划定为某一个业务的特性，然后跟不同的机型进行整合。

• 业务成本高，ROI无法量化，比如某个业务投入的人力成本和开发成本远远大于它的产出成本这样的情况。

针对这个问题，工程师的处理方式分为两个维度：一是使用容量系统对资源进行使用率的考核，对于资源使用率较低的机器，推动业务进行业务混布，或者业务迁移至配置较低的机器上面。二是建立营收体系，搭建营收平台，统计各个业务的运营成本和营收成本。

• 工作流程化。前面提到建立了服务器生命周期管理的一整套流程，但是运维团队没有一个很好的平台管理进行任务进度查看，很多事情还是靠邮件沟通，这带来的人力成本很高。

所以，建立了工单平台，它完全遵循服务器生命周期的那一套流程，用于记录各个工单的流程、处理情况、处理人、耗时等等，同时也方便后续的工单跟踪情况。

而且工单平台和 CMDB 对接，申请者提交需求的时候，会拉取 CMDB 业务树和部门进行填写，当工单完结的时候，会自动挂载业务以及修改服务器运营状态，还有对此业务的运维人员可以进行自动填写的功能，大大提高了工作效率。

• 资源利用率，就是使用容量平台来监控各个产品线的资源使用情况，然后对资源使用率较低的业务进行混布或者迁移方案。
• 预案管理。运维团队部署两地三中心，在多个数据中心部署业务，当单个数据中心出现故障的时候，可以快速切换到别的 IDC 服务器，确保服务正常的运行。另外也会对专线进行定时切换演练，以测试专线切换后是否有问题发生。

上面讲述了从 2011 年到现在，整个历程中出现的问题，运维团队是如何解决的。还需要详细说明两点，一个是业务的增长从 5 台到 6000 台，速度很快，这很考验基础设施的建设。

另外一个是很考验交付效率能力，网络架构从 1.0 升级到 3.0，用装机平台解决工单系统，跟CMDB联动，降低我们的操作频率。

在成本控制方面，对于一个有海量互联网业务的公司来说，微优化可以节省很多成本，运维团队主要从三个方面进行成本控制：

• 资源使用率;
• 供应商方面;
• 内部营收。

魅族运维体系实践

魅族的运维体系跟大部分的互联网公司一样，采用多级分层模式，所有业务和 DB 都部署了高可用架构，技术平台跟业务平台也有很多的系统，比如发布平台、监控平台等等。

在自动化过程中，运维团队根据遇到的情况定义优先级，进行任务分解，先做最容易的，能提高效率的点，再做整合，通过各个子系统的整合，形成适合自己的自动化运维框架。下面挑选几个比较主要的系统谈一下：

监控系统

监控系统采用 server-proxy-client 架构，Client 端的 Agent 会定时主动上报数据至 proxy 中做临时缓存，proxy 会定时将临时缓存的数据上报给 server 端存储在数据库，进而将数据展示在 Zabbix 界面。

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

监控覆盖率方面会先发邮件给相应的人员去处理问题，以保证覆盖率由早期比较低的一个百分比到达一个百分百的状态，后续也会每天巡检，让覆盖率一直维持在百分之百的状态。

统一告警平台

之前，所有的告警信息都从 Zabbix 平台发出，服务器出现故障后，短信和邮件告警就会很多，如果不处理，则会一直告警，出现短信轰炸。针对此情况，运维团队开发了告警平台。

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

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

工单平台

工单平台包括服务器所有流程，和自定义功能，可以减少跟开发同事的沟通成本，开发只需要运维人员提需求，不同的需求使用不同的节点，直接查看工单的处理状态。

比如说 OP 审核节点，以及开发审核节点，最后整个工单流程完成之后，所有的产品实现自动化。生命周期管理自动化，工单流程的可视化、可追踪。

巡检平台

早期，运维团队出现过内核参数设置未生效的问题，iptables 处于打开状态，导致宿主机在大流量和高并发量的情况下网卡容易丢包，影响多个业务的稳定性。

工程师意识到在 OS 层，做定制化和标准化，通过巡检系统发现非标准机器，定时整改。系统巡检主要包括系统初始化检测、系统常规检测、系统内核检测、系统安全检测和下线检测。巡检平台可以按季、按月生成一个巡检标准率，建立标准体系，提升工作效率。

更安全的堡垒机

如上图的堡垒机架构是在不同机房部署主备堡垒机，两台堡垒机之间的数据是同步的，用户可以申请软件或者硬件的 Token，然后通过 RSA 认证登录到堡垒机。

此时 IDC 账户管理平台会对登录用户进行审计把控，包括用户管理、登录记录、分配权限、操作记录等等，最后登录到服务器上。这样可以有效提高线上系统的安全。

流程管理

运维团队建立了整套的服务器生命周期管理，从产品，服务器的引入，到生产、运营、下线，分为几类：资源交付类、资源调动类还有一个生命周期末端流程。

结合工单平台，它已经正式线上运行了，这一套流程建立之后，OP 跟开发之间的沟通成本，节约的时间已经大约是之前的 2 倍多了。

容量系统

所有数据都来自于监控系统，比如 CPU、内存、IO 能力，工程师通过容量系统调取数据作一些分析，对使用率比较低的功能做一些整改，从上面可以看到阅读或者按天的资源使用率情况。

另外，工程师也会做业务成本的考核，算是一个附加功能，主要是做了一个内部营收平台，对内的各个业务通过一些核算来关注每一个业务的运营成本和产出。这样每个部门的成本关注度也相应提升了五倍。

魅族运维未来展望

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

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

梁鹏

魅族云平台系统架构师梁鹏

来自魅族云平台，主要负责魅族系统运维、平台建设和自动化的工作。

网页标题：魅族运维进化史：从“远古时代”到“铁器时代”的艰难蜕变
网页地址：http://www.shufengxianlan.com/qtweb/news41/231041.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联