从5台服务器到两地三中心：魅族系统运维架构演进之路（含PPT）

导读：高可用架构 8 月 20 日在深圳举办了『互联网架构：从 1 到 100』为主题的闭门私董会研讨及技术沙龙，本文是覃军分享的魅族运维架构演进历程。
覃军，现任职于魅族 Flyme 平台研发部运维平台，负责 Flyme 基础平台系统运维工作，经历服务器数百到数千的发展规模。对魅族的基础网络，系统部署交付及资源运营成本核实方面有深入的了解，目前负责的 IaaS 平台服务器规模超过 6000 台，有效支撑 Flyme 系统的基础服务及游戏运行。

背景

魅族的互联网业务起步得比较早， 2011 年就开始，到 2014 年真正转变为一家移动互联网公司。从 2014 年开始，魅族互联网业务呈现爆发式增长，截至 2015 年底，Flyme 注册用户突破 3000 万，应用商店超过 100 万款应用，总下载量超过 100 亿，营收能力同比增长 12 倍。伴随着业务的高速发展，运维面临的挑战也越来越大，碰到的问题也越来越多，同时运维架构在不断的完善变更。

系统运维架构演进史

这几年我们主要围绕质量、效率、流程、成本维度对运维工作进行优化，慢慢的由运维转变为技术运营，提高自身的价值。

一、远古时代（ 2011.1 - 2011.12）

规模

• 机柜： 1 个
• 服务器： 5 台
• 业务： 2 个
• 人力：开发兼职运维

问题

• 机房稳定性
• 监控缺失
• 架构单点

二、石器时代（ 2012.1 - 2014.6）

规模

• IDC： 1 个
• 机柜 : 30 个
• 服务器 / VM： 800 台
• 业务： > 100 个
• 人力：运维 12 个

问题

• IBM 刀箱、 EMC 存储、 Vmware 虚拟化、硬件供应商单一 ⇨ 去 IOE
• 网络不稳定、活动日流量突增 ⇨ 搭建新网络架构，带宽冗余
• 机房资源不足扩容难 ⇨ 迁移机房，资源冗余
• 部分业务架构单点 ⇨ 去单点，保证可靠性
• 部署：手工操作，依赖于人 ⇨ 自动化运维工具
• 监控：覆盖率低 ⇨ 定时巡检
• DB 压力 ⇨ 使用 SSD
• 安全性较低 ⇨ RSA Token + 堡垒机，自研 WAF，出口 ACL 控制，采购 DDOS 流量清洗 服务

三、青铜时代（ 2014.7 - 2015.12）

规模

• IDC：多个
• 机柜 : > 150 个
• 服务器 / VM： > 4000 台
• 业务： > 200 个
• 人力：运维平台 35 个

问题

• 标准化率低，监控覆盖率低，维护成本高，有效性低 ⇨ 标准化巡检，监控巡检
• 机房扩容难，成本高 ⇨ 迁移，了解行业价格
• IOE、虚拟化方案 ⇨ 使用 X86 服务器，建立基于 KVM 的魅族云平台
• 部分业务架构单点 ⇨ 梳理单点业务，统一高可用架构
• 故障多样性 ⇨ 建立知识库，厂商技术支持
• 规模突增 ⇨ 容量管理
• 资源扩容效率低 ⇨ 资源冗余，自动化装机平台
• 配置管理，准确性低 ⇨ 流程化管理
• 业务可用性 ⇨ 架构冗余，两地三中心

四、铁器时代（ 2016.1 至今）

规模

• IDC：多个
• 机柜 : > 200 个
• 服务器 / VM： > 6000 台
• 业务： > 200 个
• 人力：运维平台 43 个

问题

• 监控问题：监控指标量化、可视化 ⇨ 统一告警平台，告警收敛
• 机器套餐多，业务需求个性化 ⇨ 根据容量情况整合同类型机型
• 运营成本高，各业务 ROI 量化 ⇨ 资源使用考核，建立内部营收体系
• 工作流程化 ⇨ 工单系统
• 资源利用率低 ⇨ 容量系统
• 预案管理 ⇨ 定时演练

回顾总结

基础设施规划 （业务爆发式增长）

• IDC 迁移，单个变多个，建设两地三中心
• 保留足够的机柜预留资源，保证快速部署需求
• 去 IOE，建设以 KVM 为基础的魅族云平台，引入 Docker 容器平台，实现微服务

监控告警与定位 （及时发现与定位）

• 告警分级：邮件、短信、钉钉
• 自动化添加监控设备，根据 CMDB 业务树进行巡检，保证监控覆盖率
• BI 告警，度量系统

成本控制

• 提高资源使用率：监控系统 + 容量管理平台
• 容器服务化
• 供应商管理，引入多家厂商
• Flyme 内部结算，建立内部营收体系

业务同质化与差异性（维护成本）

• 标准化： OS 标准化、硬件标准化、软件标准化、架构标准化、组件标准化、协议标准化
• 规范：日志规范、部署规范

手工重复操作，依赖人（效率）

• 运维自动化、平台化达到快速交付要求
• 上线流程 + 标准化打包 + 自助发布 + 灰度发布（持续交付）

预案

• 异地双活 + 快速切换措施
• 专线切换演练

运维整体架构

魅族的整体架构还是跟多数互联公司一样，采用多级分层模式，目前所有的业务全部有高可用方案，应用或 DB 至少 2 台以上。当然，具体业务要复杂很多，以上只是抽象出简单层面。

（点击图片可放大浏览）

魅族的运维平台和技术平台开发了很多实用的系统，这些系统组成了整体的运维体系。在自动化方面，我们也是摸着石头过河，根据实际出发，找出痛点，归纳整理出需求，并考虑如何实现。我们的思路是定义优先级，任务分解，先做最容易的，最能提高效率点，再做整合，通过各个子系统的整合，慢慢形成适合自己的自动化运维框架。

监控系统

接下来给大家介绍下我们的监控系统，魅族基础系统层监控采用的 zabbix，这也是当前规模比较适合的一套监系统。 zabbix 是基于 Web 界面提供分布式系统监视以及网络监视功能的企业级开源解决方案。 zabbix 能监视各种网络参数，保证服务器系统的安全运营；并提供灵活的通知机制以让系统管理员快速定位/解决存在的各种问题。

（点击图片可放大浏览）

我们采用的是 server-proxy-client 架构，其中 proxy 是 server、 client 之间沟通的一个桥梁， proxy 本身没有前端，而且其本身并不存放数据，只是将 agentd 发来的数据暂时存放，而后再提交给 server 。对监控模板标准化，针对不同的组定义不同的模板，每个组的运维/开发人员接收自己负责业务的告警。在 zabbix 后台定义匹配的动作，通过 hostname 匹配，当修改 CMDB 的状态为“运营中”， agent 就会根据 CMDB 主机的业务树自动上报分组并添加到 server 端，减轻了原来手动添加监控的工作量。同时 zabbix 会拉 CMDB 里面的主机数据进行比对，发现哪些主机未添加成功并定时发邮件给相应运维人员处理，保证了监控覆盖率。

统一告警平台

（点击图片可放大浏览）

告警收敛

通过 zabbix 告警信息接入统一告警平台，实现告警信息收敛。通过预先设定的不同级别场景下的不同阈值，进行批量告警收敛，避免瞬时突发告警对用户造成困扰，按业务模块进行批量收敛。

告警分级

1）在 zabbix 中配置 trigger 的 severity 的值，并配置 action 的 Default message 的内容

2）在统一告警平台中配置服务的故障分发功能

在告警平台上配置升级策略，每个升级策略配置配置不同的接收告警的方式，配置不同的接收人。然后在服务管理中配置故障分发，根据发送消息中 severity 的值进行匹配，匹配 Warning 和 High 两个级别的故障进行分发。

通过以上机制，原来每天由 zabbix 发出 5000 多条短信降低为现在的 800 多条，有效的减低短信成本。

OS 标准化巡检系统

去年我们出现过 net.netfilter.nf_conntrack_max 值设置未生效的问题， iptables 处于打开状态，导致 kvm 宿主机在大流量和高并发量的情况下网卡容易丢包，影响多个业务的稳定性。最后通过检查宿主机内核参数 net.netfilter.nf_conntrack_max 是否设置为 655350，关闭 iptables 解决。我们意识到在 OS 层，要做定制化和标准化，通过巡检系统发现非标准机器，定时整改。

系统常规检测

系统对时任务、 selinux 状态、 iptables 状态、 eth0 网卡链路状态、 eth1 网卡链路状态、 bonding 模式、网卡命名、 yum 源配置文件、 yum 源配置文件内容、 DNS 配置、 MFS 挂载检测

系统安全检测

检测拥有 root 权限用户、检测当前空口令用户、 passwd 文件读写权限、 shadow 文件读写权限、 group 文件读写权限、拒绝 .rhosts 文件存在、打开 tcp_syncookies、缓解 syn flood ***、防止 syn ***优化、单用户启动密码

内核检测

net.netfilter 检测、 nf_conntrack 检测

更安全的堡垒机

（点击图片可放大浏览）

我们的堡垒机体系是通过 RSA Token + 堡垒机模式实现角色管理与授权审批、信息资源访问控制、操作记录和审计、系统变更和维护控制。避免了登录账号管理混乱、运维权限划分不明、认证方式过于简单、对运维过程没有监控措施、对研发人员的运维次数没有合理的运维统计方式。

流程管理

服务器的引入、生产、运营、利旧、退役的生命周期闭环，需要高效的自动化流程支撑。通过流程设计建立每个流程的模型，一般每个流程都要涉及到多个部门角色和系统，需要确定关键环节、职责分工、系统间接口，为了降低流程开发成本，需要考虑原子流程 - 组合流程 - 业务流程的分级实现模式。

• 资源交付类流程：资源采购、日常申请、领用、上下线、自动验收检查、自动部署、预置环境调整
• 资源调度类流程：服务器搬迁、改造、回收、备件调拨等
• 生命周期末端流程：服务器退役、利旧拆解、报废处理等

Flyme 运维成本体系

（点击图片可放大浏览）

通过建立内部营收体系，能更有效的量化各业务的投入产出比，为领导决策提供依据。魅族主要通过成本控制、业务 ROI、业务资源容量、内部结算、资源提供能力、基础容量几个方面实现。

成本控制

建立精准的预算模型，根据业务量预估资源，包括机柜、 CDN、带宽、专线、服务器、网络设备、短信、安全服务、人力成本等。前期深入到业务，了解业务资源需求是否合理，对需求进行评估审核，控制不合理需求。同时借助容量系统对线上资源进行优化。

业务 ROI

统计各业务的单 PV / UV 成本、单用户成本、单位调用成本，生成报表，环比同比比较，促进各业务线关注投入产出比。

业务资源容量

考察业务资源池容量，业务运营容量，了解业务资源需求，对各业务申请资源进行信用考核，根据业务发展趋势进行预留。

内部结算

参考云厂商进行国内、海外定价，核算基础成本，对标云厂商进行结算，提高服务能力。

资源提供能力

建立容量模型，分析各业务容量瓶颈，过量容量，服务容量，在成本和业务需求的双重约束下，通过配置合理的服务能力使组织的 IT 资源发挥最大效能。

容量系统

（点击图片可放大浏览）

对于海量规模的互联网业务来说，稍微优化就能节省大量成本，所以已成本导向的驱动力是最大的。

魅族系统运维的未来

• 希望能内外兼修，打造精细化的运营体系；
• 根据运营场景设计串接各个自动化节点，逐渐形成自动化运营的场景闭环；
• 通过监控自动化，运维自动化，流程管理，安全管理多方面结合保证服务质量；
• 同时携同开放平台，大数据平台对业务提供更加优质的服务。

相关阅读

（点击标题可直接阅读）

• 从优化性能到应对峰值流量：微博缓存服务化的设计与实践
• 全国低于30ms响应速度:千万级魅族用户的异地多点网络架构如何优化

本文及本次沙龙相关 PPT 链接如下，也可点击阅读原文直接下载
https://pan.baidu.com/s/1geTJtZX

想更多了解高可用架构沙龙内容，请关注「ArchNotes」微信公众号以阅读后续文章。关注公众号并回复 城市圈 可以更及时了解后续活动信息。转载请注明来自高可用架构及包含以下二维码。

高可用架构

改变互联网的构建方式

标签：魅族,架构,运维,业务,监控,PPT,告警
来源： https://blog.51cto.com/14977574/2547430