背景
魅族的互联网业务起步得比较早， 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 运维成本体系
通过建立内部营收体系，能更有效的量化各业务的投
