前记：所谓干一行爱一行，人生处处是《围城》这是人性，但在改变那一刻之前，自应全心全意研究本行，全心投入，不计回报，用心在当下，写到体系就像是前面所有博客的一个帽子，现在把他总结整理出来，希望对你有所启迪。
任何岗位都有其业务职能，全部职能梳理后形成章程、纲领和体系，运维亦然，互联网最大的特点是“快”和“变”，但不代表没有固定的体系，恰巧有的是应对"快"和"变"的体系，从事一线运维这些年，边干边体会，千象背后是有恒道的，所谓万变不离其宗，运维工作一切围绕高SLA和低成本为目标运转，只是工具在围绕运维体系变来变去而已，从开发的角度理解服务体系就像是算法，实现算法的语言和方式就像是工具。
运维的发展首先有了体系，体系是个系统、立体和全面的东西，而不是具体片面的几个点，在初期，运维人员通过体系来保障业务的健康发展，并且摸索体系的范围，这个阶段可以说是制度为王、制度规范，没有系统的自动化运维平台，有的只是零散的一些小工具，各种事物基本靠人工、靠制度、靠约束，虽是原始阶段，但也是运维最真实的样子，忙碌而又忙碌，效率总跟不上需求，制度总跟不上执行，与开发的协作总难同一频道，需要大量的运维人力。
再向后发展，为了提高效率的同时解决与开发间的沟通协作问题，提出了DevOps，大家开始做自动化，这个自动化其本质是把运维体系落在一个到多个系统上，通过自动化的系统来提高工作效率，同时用系统来实现制度，开发和运维都在一个系统上协作，遵守同样的规则，协作上也高效多了，这个阶段到了技术为王、平台规范，市场上出现了运维开发，出现了SRE，各种问题得到了有效的解决，当然解决的程度取决自动化系统做的优劣，这个就参差不齐了，但出现了这个发展方向。
再向后发展，出现了AiOps......
个人感觉，有两个维度变化很明显，越来越注重技术解决问题，人员需要越来越少，能用技术工具替代的岗位在慢慢被替代，理论上理想的终极状态可能只留"运维平台+应用运维"，其他运维转岗应用运维，应用运维转岗技术运营。
那么如果你恰好接到一个从零开始建设的运维工作，运维服务体系的建设要怎么做呢？下面我们把他拆开看一看。
● 规范工作，形成运维服务体系（制度为王）
1、变更规范
- 上线变更：代码上线、扩容；
- 配置变更：系统配置、应用配置；
- 网络变更：网络割接、设备更换；
- 其它变更：流量调度、服务切换、服务下线...
- 原则：a、制定变更审核流程；
b、制定变更相关方通知（群、邮件）；
c、制定变更回滚策略；
d、遵循测试、单机灰度、机房灰度、全量上线的规则；
e、下线变更要将服务器依赖处理干净，比如说挂着vip、有域名解析。
2、灾备规范
- 服务灾备：多机器、多机房；
- 数据灾备：多备份、异地备份；
- 网络灾备：多线路、多设备；
- 原则：a、自动切换 > 手动切换；
b、无状态 > 有状态；
c、热备 > 冷备；
d、多机房 > 单机房。
3、预案规范
- 线路切换：移动、电信、联通、BGP等多线路切换；
- 机房切换：不同机房切换；
- 机器切换：不同机器切换、故障机器自动摘掉；
- 服务降级：无法切换时，如何降低标准继续服务；
- 数据库切换：主从切换、读写切换；
- 网络切换：主备线路切换、链路切换；
- 原则：a、域名切换 > 更换IP；
b、自动摘掉 > 手动操作；
c、自动切换 > 手动切换；
d、考虑好雪崩事宜。
4、容量规范
- 系统容量：木桶原理计算系统的上、下行容量、用量、余量；
- 模块容量：模块的上、下行容量、用量、余量；
- 机房容量：分机房的容量、用量、余量；
- 单机容量：压测单机的容量，一般用于反向计算机房、模块容量；
- 原则：a、制定模块单机容量指标，并记录文档（比如QPS、连接数、在线用户数等），
b、容量要考虑下行（读）、上行（写），考虑存储增量；
c、计算当前模块总容量，收集当前的用量，并对比容量计算余量；
d、系统总容量可以根据木桶原理，找到短板模块后，反向计算出来。
5、告警规范
- 基础监控：CPU、内存、网络、IO；
- 应用监控：进程、端口；
- 业务监控：日志、业务埋点；
- 依赖监控：数据库、依赖接口...
- 原则：a、核心监控收敛成告警，并对告警进行分级，备注告警影响；
b、核心监控形成可排查问题的DashBoard；
c、告警的价值在于实时发现故障，是事中和事后的。
6、巡检规范
- 系统核心指标DashBoard；
- 分模块核心指标DashBoard；
- 基础资源核心指标DashBoard：服务器；
- 依赖资源核心指标DashBorad：依赖db、依赖接口；
- 自动化巡检报告；
- 值班oncall安排；
- 原则：a、DashBoard核心在于收敛、舍得；
b、自动化巡检的必要性在于异常侦测，预防故障，是事前的。
7、权限安全规范
- 开发、运维、临时权限；
- 安全上符合安全审计标准。
8、故障管理规范
- 服务分级，确定各服务用户角度的影响；
- 制定分级后各服务SLA，制定问题、故障分级标准；
- 制定故障通知、处理规范；
- 制定故障覆盘，改进措施按时保量完成的规范；
- 原则：a、拥抱故障，但同一故障解决后，不应重复出现。
9、文档、工具规范
- 统一共享知识文档；
- 统一共享各种脚本工具；
- 原则：a、理想的情况是“一站式运维平台”，一个平台涵盖所有工具操作。
10、标准化规范：
- 主机名标准化；
- 应用软件安装结构标准化；
- 日志存储标准化；
- 日志格式标准化；
- 域名使用标准化；
- 原则：a、主机名尽量能看出更多信息，比如服务、模块、机房等；
b、日志是排查问题的重要信息，一定要标准化，方便手工排查，更是为了以后用工具处理打下基础。
● 建设"自动化运维平台"，技术实现制度（技术为王）
有了第一阶段的运维体系为基础，就可以考虑用平台工具来实现零散的手工操作、制度规范，理想的情况是“一站式运维平台”解决所有事情，平台后端集成使用开源技术方案作为支撑，对于用户优雅而统一，目前开源项目中尚未找到很好的“一站式运维”产品，下面罗列一下常用的解决某类问题的技术方案。
1、监控告警方案
- Zabbix：https://www.zabbix.com
- OpenFlcon：https://github.com/open-falcon/falcon-plus
- Prometheus：https://prometheus.io
- Grafana：https://grafana.com
2、日志分析方案
- ELKB：https://www.elastic.co
3、安全堡垒机方案
- JumpServer：http://www.jumpserver.org
4、持续集成部署CI/CD方案
- jenkins：https://jenkins.io
- GitLab：https://about.gitlab.com
5、容器技术方案
- Kubernetes：https://kubernetes.io
6、配管自动化方案
- Puppet：https://puppet.com
- Salttack：https://www.saltstack.com
- Ansible：https://www.ansible.com
8、一些运管集成方案
- SaltShaker：https://github.com/yueyongyue/saltshaker_api
- 腾讯蓝鲸：https://github.com/Tencent/bk-cmdb
- OpsManage：https://github.com/welliamcao/OpsManage
......
后附：文章导航
一、运维体系、技术杂谈
5、应用运维角度分析大型互联网应用架构设计与优化的“4要素”
二、Linux自动化运维知识栈
- Linux基础
- 监控告警
3、轻量级流式日志计算分析plog+（zabbix+grafana)
4、zabbix_sender主动上传k/v监控nginx日志状态码
5、基于etcd+confd对监控prometheus的服务注册发现
- 日志分析
1、玩儿透围绕ELK体系大型日志分析集群方案设计.搭建.调优.管理
6、logstash结合filebeat进行多套日志的分离清洗
7、filebeat6.2.4多套日志采集并入不同kafka小记
8、kafka与zookeeper管理之kafka-manager踩坑小记
9、logstash中timestamp的转换及json日志的解析
11、ELK之ES2.4.1双实例平滑升级调优至5.2.1踩坑并supervisor管理记
- 容器技术
1、步步为营实践总结kubernetes1.8.2安装配置部署
2、kubernetes1.8.2安装配置calico2.6.6（附4种网络模式性能数据）
3、基于etcd+confd通过nginx对docker服务注册发现详解
三、网络TCP/IP/HTTP协议
2、弄清TIME_WAIT彻底解决TCP:time wait bucket table overflow
3、大并发下TCP内存消耗优化小记（86万并发业务正常服务）
四、WebService架构及性能优化
1、记一次HttpDns业务调优——fastcgi-cache容量提升5倍
2、WebService之nginx+(php-fpm)结构模型剖析及优化
3、详解nginx的原生被动健康检查机制&灾备使用（含测试）
4、小记解决nginx500错误之could not allocate node in cache keys zone ＂cache_one＂
5、tengine2.0.1升级到2.2.2彻底消灭SSL_shutdown() failed...报错
9、nginx多条件if判断后rewrite，减轻后端php工作压力（随笔）
11、老nginx集群向tengine的升级改造，性能提升数倍
五、CDN架构及cache节点性能优化
- CDN业务结构
- Cache缓存节点
1、Nginx/tengine做cache时缓存机制—存不存、存多久、用不用方法论
查看更多请到博主原创站：运维网咖社（www.net-add.com）