DevOps体系是原始运维发展到提高效率、解决沟通协作问题的阶段，其中重要的是规范和制度的建设，以及搭建一套自动化系统。运维人员需要逐渐转岗至业务运维，最终目标是以运维平台和业务运维为核心，实现技术运营。设计一套DevOps运维服务体系需要定业务规范、建工作制度、搭建DevOps系统。
DevOps体系是从传统的运维实践发展而来。传统运维可视为一本教科书，而DevOps和AIOps等则是对这本教科书的延伸和进一步优化，旨在提高效率、降低错误率，并进行流程优化。
以专业方式重新表达: 运维的职能规范通过创建章程和纲领来实现。在互联网的快速发展中，我们形成了应对变化和快速性的一套体系，并持续进行迭代升级。多年的工作经验让我明白，在千变万化的背后，我们始终坚守着不变的核心原则。运维工作一直以实现高SLA和低成本的业务目标为重点，不过所用工具在不断适应和改变这个体系。从开发者的角度来看，运维体系就像是一个算法，而用于实现算法的语言则是工具。而DevOps则是这些工具的升级。
工具的本质其实是一个基础支撑，有了这个支撑，一系列目标的实现才更科学、高效，简单示意如下。
在初始阶段，通过与各部门的磨合和探索，运维工程师慢慢建立起了一个初步的体系。这个体系以无形方式规范了运维工作和注意事项，工程师根据这个纲领进行日常工作，确保业务的健康发展。在这个阶段，系统化的运维平台还不存在，只存在一些零散的工具。各种工作基本上依靠人工、制度和约束来完成。虽然处在原始阶段，但这才是运维的真实面貌。工作非常繁忙，效率始终无法满足需求，制度执行总是跟不上。与开发部门的合作也常常陷入困境，需要大量的运维人员来支持工作。
随着时间的推移，为了提高工作效率并解决开发与运维之间的沟通协作问题，DevOps的概念被引入，并开始在各个组织中推行自动化和DevOps文化。 自动化的目标是将运维流程转化为一个或多个系统，并通过自动化系统来提高工作效率。同时，通过系统来实现规范化，使得开发和运维可以在同一个系统上进行协作，并遵循同样的规则。这种协作方式提高了效率。随着技术的发展，市场上出现了运维开发和SRE等概念，这些概念有效地解决了各种问题。当然，这种解决程度取决于具体的DevOps系统，有些系统可能表现不一致。但总的来说，这个方向的发展正在加速。
再向后发展，行业领头羊提出要进一步减少人工参与，用机器自动化替换人工自动化，进而出现了 AIOps。
随着时间的推移，从原始的运维模式向DevOps模式的过渡中，我们越来越重视技术解决问题的方法。这也使得人员需求相应减少，技术可以逐渐取代那些可以被自动化平台实现的岗位。随着自动化平台的不断发展和稳定性的提高，实际上最理想的终极状态将只剩下“运维平台+业务运维”，其他运维岗位将转向业务运维，而业务运维岗位则将变成技术运营岗位。
在考虑设计一套DevOps运维服务体系时，我们应该采用一种更专业的思维方式。简单总结起来，最小的模型包括制定业务规范、建立工作制度和搭建DevOps系统。然后，我们以此为最小单元进行循环迭代和升级。
一、定业务规范
以种地为例，美国在农场种地过程中引入标准化和流程化的操作方法，并采用了先进的农业工具，这使得几个人可以同时种植几百亩地，实现了高产量、低成本的收成，且耗费的体力较少。相比之下，中国的农民每个人只有几亩地可以自行作业，由于缺乏标准化流程和先进工具的支持，所以收成较少，成本较高，且付出了较多的体力劳动。
作为一名IT工程师，我认识到运维工作的重要性，实现批量化和高效率的运维作业需要制定规范和标准化各项服务。如果每个服务各自为战，将会导致团队忙碌但效果不佳。因此，我们需要确保团队协作，遵循统一标准，以提升工作效率。
那么我们通过 DevOps 要批量管理哪些东西呢，集中一下大概就是资源、服务、规范三类，资源包括像服务器、网络设备、负载均衡、证书、域名、代码、容器等，服务包括像围绕运维提供的服务监控告警、CI/CD、日志分析、服务预案、配置管理等，规范包括像流程、资源、服务的各种标准化等，简单示意如下。
所以规范是整个 DevOps 体系建设里非常重要的一环，每个规范也对应了一些最佳实践原则，整理了一些运维中的规范如下：
1、变更规范
- 上线变更：代码上线、回滚、扩缩容；
- 配置变更：系统配置、应用配置；
- 网络变更：网络割接、设备更换；
- 其它变更：流量调度、服务切换、服务下线…
原则：
- 制定变更审核流程；
- 制定变更相关方通知（群、邮件）；
- 制定变更回滚策略；
- 遵循测试、灰度、全量上线的规则；
下线变更要将服务器依赖处理干净，比如说挂着vip、有域名解析。
2、容灾规范
- 服务灾备：多机器、多机房；
- 数据灾备：多备份、异地备份；
- 网络灾备：多线路、多设备；
原则：
- 自动切换 好于 手动切换；
- 无状态 好于 有状态；
- 热备 好于 冷备；
- 多机房 好于 单机房。
3、容量规范
- 系统容量：木桶原理计算系统的全链路容量、用量、余量；
- 模块容量：模块的容量、用量、余量；
- 机房容量：分机房的容量、用量、余量；
- 单机容量：用于反向计算机房、模块容量；
原则：
- 制定模块单机容量指标（比如QPS、连接数、在线用户数等）；
- 容量要考虑下行（读）、上行（写），考虑存储增量；
- 计算当前模块总容量，收集当前的用量，并对比容量计算余量；
- 系统总容量可以根据木桶原理，找到短板模块后，反向计算出来。
4、巡检规范
- 用户核心指标；
- 服务核心指标；
- 基础资源指标：服务器；
- 依赖资源指标：依赖db、依赖接口；
- 自动化巡检报告；
- 值班oncall安排；
原则：
- DashBoard核心在于收敛、舍得；
- 自动化巡检的必要性在于异常侦测，预防故障。
5、告警规范
- 基础监控：CPU、内存、网络、IO；
- 应用监控：进程、端口；
- 业务监控：日志、业务埋点；
- 依赖监控：数据库、依赖接口……
原则：
- 核心监控收敛成告警，并对告警进行分级，备注告警影响；
- 核心监控形成可排查问题的DashBoard；
- 告警的价值在于实时发现故障。
6、预案规范
- 线路切换：移动、电信、联通线路切换；
- 机房切换：不同机房切换；
- 机器切换：机器故障时进行摘除；
- 服务降级：无法切换时，降低标准继续服务；
- 数据库切换：主从切换、读写切换；
- 网络切换：主备线路切换、链路切换；
原则：
- 域名切换 好于 更换IP；
- 自动摘除 好于 手动操作；
- 自动切换 好于 手动切换；
- 考虑好雪崩事宜。
7、故障管理规范
- 服务分级：确定各服务用户角度的影响；
- 故障定级：制定故障定级标准；
- 制定故障通知、处理规范；
- 制定故障复盘，改进措施按时保量完成的规范；
原则：
拥抱故障，同类故障不能重复发生。
8、权限安全规范
- 开发、运维、临时权限；
- 安全上符合安全审计标准。
9、文档、工具规范
- 统一共享知识文档；
- 统一共享各种脚本工具；
原则：
理想的情况是“一站式运维平台”，一个平台涵盖所有工具操作。
10、标准化规范：
- 主机名标准化；
- 日志存储标准化；
- 日志格式标准化；
- 域名使用标准化；
- 软件安装目录结构标准化；
原则：
- 主机名尽量能看出更多信息，比如服务、模块、机房等；
- 日志是排查问题的重要信息，一定要标准化，方便手工排查，更是为了以后用工具处理打下基础。
11、资源管理规范
- 服务器
- vip
- 域名
- 证书
- 代码
原则：
- 资源之间是有关系的，要建立有关系的资源管理。
- 这里只列了一些常见的业务规范，还有很多规范是要在业务实际问题中去制定的，规范代表了运维的最佳实践，在DevOps建设中非常重要。
二、建工作制度
制度是工作中的操作流程和方法，对组织的文化产生影响。制度建设的水平反映了问题解决能力的层次。优秀的制度应该具备系统化、工具化、可执行和可量化的特点，以便在后续运用DevOps时能够使制度在运维平台上友好落地。
制度的生成应该着眼于解决一类问题而非个案，并采取科学的方法。仅依赖人的主观自觉和自律无法保证制度的执行，因此应该尽可能地依赖技术手段来实现。
- 上线审批制度
- 合规部署制度
- 日志清理制度
- 容量管理制度
- oncall管理制度
- 服务巡检制度
- 故障管理制度
- 安全管理制度
- ……
在工作中，各种制度层出不穷，建立这些制度是一门需要技巧的艺术，也是体现运维人员能力的重要方面。这种能力如果能够持之以恒，就会逐渐成为一种文化。举例而言，考虑问题时能够看到本质，解决问题时能够着眼于根本原因，都是运维人员所应具备的能力。
另外，制度的建立要一定要本着长远的眼光，科学的态度，DevOps的思想（工具思维）。
三、搭 DevOps 系统
系统搭建的目的是通过技术手段将前期的业务内容数字化，利用科学的工具来管理零散的资源、规范操作。理想情况下，我们的目标是实现“一站式运维”，即工程师无需切换系统，只需要在一个平台上解决所有问题。
鉴于要处理的事项过多，为了提供更专业的解决方案，市面上迅速出现了针对单个问题的优秀方案，如zabbix和Jenkins等。然而，从用户的角度来看，这些解决方案就像是五行缺了一个环节，为了解决一个业务问题，用户需要打开多个系统并频繁地在系统之间切换，这样的使用方式令人感到沮丧。较为出色的大型企业尝试通过单点登录来解决账号混乱的问题，但仍然需要使用多个系统，用户体验不佳且操作效率低下。
这些单点解决方案在DevOps设计中扮演着重要的角色。为了实现高质量和低成本，我们需要巧妙地整合这些解决方案，将它们作为底层组件，建立在前人的基础上构建系统。我们要努力实现“一站式”应用，但同时也需要认识到将所有底层问题都依赖一个系统来解决是不现实的。下图形象地展示了这个概念。
工具体系可分为两层，底层为轮子层，用于解决单个主题问题，注重深度和系统性解决方案。上层为面向SRE的应用层，也可称为业务层。业务层通过封装底层轮子来管理资源、规范制度和运维服务，所有轮子通过统一的账号和权限体系连接在一起。
为了充分利用开源社区提供的优秀工具，尤其是小规模企业，我们不必重复开发，而是应该通过这些工具的API接口，将应用层的流程进行封装。通过集成应用层，我们可以实现一站式操作，使应用层成为SRE用户的界面，进一步体现了DevOps的用户体验。尽管这些工具可能非常复杂，但我们的目标是打造一个简洁、优雅的一站式运维平台。
DevOps体系是从原始运维发展而来，注重技术解决问题，减少人工参与，目标是通过规范和自动化系统提高效率。设计DevOps运维服务体系需要定业务规范、建工作制度、搭建DevOps系统。最终目标是构建一套“一站式运维平台”，通过整合各类轮子实现一站式操作，提供优雅的用户体验。
