运维蓝图思考

最近在做17年规划，思考运维到底应该干哪些事，得出如下图表一张，欢迎各位同仁一起讨论

运维蓝图

* 定标准

我们希望线上环境是统一的、干净的、规范的，所以就要定标准，比如：

• 机型：线上机型尽量少，省得光各种机型的备机就一大堆，浪费成本，针对少量机型做精，稳定性也更容易做
• OS：比如统一CentOS6.3，统一kernel，统一各种优化配置，更安全，更稳定
• 第三方软件：比如MySQL、Tomcat、Nginx，尽量统一版本，统一扩展，统一部署方式，统一监控方式
• 发布标准：比如启停脚本，启动账号，LOG格式、切分方式，部署路径，watchdog
• 监控标准：制定指标黄页，机器、网络、业务程序、中间件等等都要如何监控，程序如何吐出反应自身健康状况的指标均要定规范

* 资源管理

运维作为一个支撑性的部门，没办法赚钱，但可以省钱，把资源尽量合理利用起来，花更少的钱办更多的事

• 做好预算，容量规划，看业务增量得出预算机器量
• 各种机型需要备机配比，避免某机器坏了之后找不到备机可换
• 机器生命周期管理，流转流程，比如上线，下线，故障，借用等等
• 通过类似服务树这样的系统，分门别类的管理机器，知道每个机器的用途
• 通过类似Borg这样的统一调度系统，混部服务，提升资源利用率

* 监控

监控作为运维的眼睛，稳定性的必要保障，必须要做好，做全面，做稳定，所有服务都挂了，监控不能挂

• 监控系统自身构建，监控数据量比较大，是运维系统中一个非常有难度的系统，可以参考的比如Borgmon、Gorilla、OpenTSDB、Open-Falcon等等
• 机器性能监控、基础环境监控、日志监控、网络监控、访问质量监控、业务监控，等等等等，没有最全，只有更全
• 部分问题报警之后，处理步骤是重复的固化的，这样的场景可以考虑故障自愈，无人值守自动处理，即使无法自动处理，也可以自动抓现场，提供后续分析依据

* 安全

所谓安全无小事，安全直接关系到一个公司的存亡，有的公司会把安全团队放到运维部门下面，有的是单拎出来，不管组织结构怎么划分，安全都是运维一定要重点关注的

• 登录控制和操作审计，比如各个公司做的堡垒机、跳板机，控制哪些人可以登录哪些机器，而且所有操作均有记录，均可审计
• 安全接入，比如防DDOS，流量清洗，在公司所有服务之前，放置一道让人信赖的长城
• 服务安全，比如研发同学使用统一的框架，避免一些编码上的安全漏洞，再经常做一下漏洞扫描，扫扫更健康

* 灾难管理

线上服务稳定性是运维同学的第一要务，灾难管理，是其中重要一环

• 首先服务架构本身，上线之前就要考虑好怎么做容灾，有单点的系统显然是过不了准入的，运维同学不能接
• 重要数据必须做好备份，只备份没演练可能会步了gitlab的后尘，所以定期演练必不可少，另外提前找好擅长数据恢复的伙伴，省得临时抱佛脚
• 线上所有变更操作，故障处理，需求处理都要有完善的SOP，新人来了，看着SOP，就可以搞定
• 宕机演练，定期巡检要常做，预料外的故障是我们最不希望看到的

* 访问质量

公司做的业务如果是To C的，这块就重要了，互联网客户都没多少耐心，不要让客户感觉网站响应慢，这会直接导致客户流失

• 访问质量要做全国甚至全球监控，各个省市，各个主要链路，搞个大屏，全国用户访问质量清晰可见
• 通过CDN，图片优化，缓存策略，流量调度等等手段，让网站访问速度变成与友商竞争的一大优势

* 变更管理

对线上做变更，是导致线上问题的一大源头，这块要单独拎出来说说

• 系统组交付机器之后，首先要根据自身业务特点做一次初始化，对操作系统做一些配置，安装一些必要的软件，比如机器挂载到服务树自动触发初始化策略
• 大点的公司，每天几千次发布很正常，有个部署平台很重要，历史版本要可回溯，一键回滚，支持各种策略各种并发度上线，具备分发大文件到几万甚至几十万台机器的能力
• 关联关系类型的配置可以采用统一的名字服务解决，开关类的配置可以采用中心化配置中心或者采用一次发布解决，每个程序如果都支持reload配置倒是不错

* 编程框架

编程框架好像跟运维无关，实则不然。统一的编程框架会让运维复杂度降低，还可以在框架中嵌入运维逻辑，不考虑运维的架构师不是好架构师

• 统一RPC框架，统一重试策略，统一名字服务，统一配置管理，统一watchdog，统一监控方式，统一日志打印...
• 多环境支持：开发环境，单测环境，集测环境，小流量环境，线上环境...用同一个发布包上线，搞定配置不同的问题
• 服务治理方面，比如接口权限控制，接口版本管理，流控，路由规则，等等

* 自动化平台

运维这个行当，不是一个console一个pssh就万事大吉的，也需要相关系统的支持，提高工作效率，提高稳定性

• 发布之前：版本管理系统，比如gitlab、编译打包平台、制品管理仓库
• 发布中：机器管理分组系统，部署系统，大文件分发工具
• 发布之后：监控系统，资源利用率平台
• 日常工作：初始化平台来初始化操作系统，跳板机、堡垒机控制登录，工单系统等等

* 结语

如果一个公司注重服务稳定性、安全性，注重成本控制，那就应该注重运维，这群默默工作在服务背后的背锅侠，请珍惜！