预录系统就像一顶帽子，是对DevOps运维的深度总结，写下工作中的感悟，希望对大家有所启发。DevOps体系从最初的运维，一步步走来。原来的运维就像地基。有了基础，想继续提高效率、减少错误、优化流程，发展到DevOps、AIOps……首先，运维的业务功能标准化后，形成了章程和程序.在互联网高速发展的特点下，形成了一套应对“快”和“变”的制度，并不断迭代升级。工作这些年，我发现千象的背后有一条不变的路，运维工作一直围绕着高SLA、低成本的业务目标在运转，但工具却在围绕着系统在变。从开发的角度来看，运维系统就像一个算法，实现算法的语言就像一个工具，而DevOps就是工具的升级。工具的本质其实就是一个基础支撑。有了这样的支持，一系列目标的实现更加科学高效。简要说明如下。在最初阶段，运维工程师和各部门共同努力，无数次探索，逐渐形成了初步的体系，无形中规范了运维的工作和注意事项。工程师通过这个程序进行日常工作，保证了业务的健康发展现阶段可以说是制度为王，制度规范。没有系统的运维平台，有的只是零散的大大小小的工具。各种东西基本上都是靠人工、靠制度、靠约束。魏最真实的模样，忙忙碌碌，效率永远跟不上需求，系统跟不上执行，与开发的合作总是难以同台，需要很多操作和维护人力。进一步发展，为了提高效率，解决与开发的沟通协作问题，DevOps被提出来，大家开始做自动化和DevOps文化。这种自动化的本质是把运维系统放在一个或多个系统上。用自动化系统提高工作效率，同时用系统来执行系统。开发和运维都在同一个系统上协同，遵循相同的规则，协同效率更高。现阶段，技术为王，平台规范上市。随着运维开发和SRE的出现，各种问题都得到了有效的解决。当然，解决的程度取决于DevOps系统的质量。这是不平衡的，但是这个发展方向已经出现了。进一步发展，行业大佬提出进一步减少人工参与，用机器自动化代替人工自动化，于是AIOps出现了。仔细观察就会发现，从原来的运维到DevOps的演进过程，是一个越来越重视技术解决问题的过程，需要的人员越来越少，可以被技术取代的岗位也在逐渐被取代。随着自动化平台的成熟和稳定，理论上理想的最终状态可能只是“运维平台+业务运维”，其他运维将转为业务运维，业务运维将转入技术操作。那么我们如何思考设计一个DevOps运维服务体系呢？总结起来，一个最小模型就是制定业务规范，构建工作体系，搭建DevOps体系，以此作为最小单位重复迭代升级。1.建立业务规范。先说美国和中国的农业。美国人建造农场，标准化耕作过程，引进工具。几个人种上百亩地，产量高，成本低，但并不累。但是，中国人每人独立耕种几亩地，收成低，成本高，反而很累。我觉得做运维的时候也是这样。要想批量化、高效化操作，就必须规范化，制定各种标准，形成规范。如果每个服务都独立工作，就会有一群真正忙碌的人。土地，但没有工作。那么我们需要通过DevOps来批量管理哪些东西呢？我们可以关注三类：资源、服务和规范。资源包括服务器、网络设备、负载均衡、证书、域名、代码、容器等，服务包括围绕运维提供的服务等。服务监控告警、CI/CD、日志分析、服务计划、配置管理等，规范包括流程、资源、服务等各种标准化，如下。因此，规范是整个DevOps体系建设中非常重要的一环。每个规范还对应一些最佳实践原则。运维中的一些规范整理如下：1.上线变更规范变更：代码上线、回滚、扩容缩容；配置变更：系统配置、应用配置；网络变更：网络割接、设备更换；其他变化：流量调度、服务切换、服务下线……邮件）；制定变更回滚策略；遵循测试、灰度、全量上线的规则；离线更改必须清理服务器依赖，例如挂vip和域名解析。2、容灾标准服务容灾：多台机器，多个机房；数据容灾：多点备份，异地备份；网络容灾：多条线路，多台设备；原则：自动切换优于手动切换；无状态优于有状态；热备优于冷备；多个机房比单个机房好。3.容量规格系统容量：基于木桶原理的系统全链路容量、使用量、余量；模组容量：模组容量、使用量、余量；机房容量：分机房的容量、使用率、余量；单机容量：用于反向机房和模块容量；原则：制定模块单机容量指标（如QPS、连接数、在线用户数等）；容量要考虑下行（读）、上行（写）、存储增量；计算当前模块的总容量，收集当前使用情况，比较容量计算余量；根据木桶原理找到短板模块后，可以逆向计算出系统的总容量。4、用户核心指标的巡查和规范；服务核心指标；基本资源指标：服务器；依赖资源指标：依赖db，依赖接口；自动检测报告；必要性在于异常检测和故障预防。5、告警指标基础监控：CPU、内存、网络、IO；应用监控：进程、端口；对告警进行分级，并注明告警的影响；核心监控形成DashBoard，可以排查问题；告警的价值在于实时发现故障。6、预案规格线路切换：移动、电信、联通线路切换；机房切换：不同机房之间的切换；机器切换：出现故障时移除机器；读写切换；网络切换：主备线路切换、链路切换；原则：换域名优于??换IP；自动清除优于手动操作；自动切换优于手动切换；考虑雪崩问题。7.故障管理标准服务分类：确定每个服务用户角度的影响；故障分类：制定故障分类标准；制定故障通知和处理规范；故障，同类故障不能重复出现。8、权限安全规范制定、运维、临时权限；安全性符合安全审计标准。9.文档和工具规范知识文档统一共享；各种脚本工具统一共享；原则：理想情况是“一站式运维平台”，一个平台涵盖所有工具操作。10、标准化规范：主机名标准化；日志存储标准化；日志格式标准化；域名使用标准化；软件安装目录结构标准化；问题的重要信息一定要标准化，方便人工排查，为以后用工具处理打下基础。11、资源管理规范服务器vip域名证书代码原则：资源之间是有关系的，必须建立有关系的资源管理。这里只列出一些常用的业务规范，还有很多其他的规范需要在实际业务问题中制定。规范代表运维的最佳实践，在DevOps建设中非常重要。2.建立工作制度制度对应工作流程和方法，会影响文化。制度的建设也体现了解决问题的水平。一个好的系统应该是系统化的、工具化的、可执行的、可量化的，这样后期才能和DevOps一起落地，并且系统对运维平台友好。一个系统的出现，不应该是解决一个案例，而是要科学地解决一类问题。如果制度的实施仅靠人的自觉和自律，是不可靠的，必须尽可能靠技术。上线审批系统、合规部署系统、日志清理系统、容量管理系统、oncall管理系统、服务巡检系统、故障管理系统、安全管理系统……工作中最不可或缺的就是各种系统，如何构建是有技巧的，同时也体现了一种运维的能力，如果这种能力坚持下去，就会成为一种文化，比如考虑问题看本质，解决问题，解决根源。另外，系统的建立必须要有长远的眼光、科学的态度、DevOps的思维（工具思维）。3、搭建DevOps体系搭建体系就是将之前的内容用技术手段信息化，用科学的工具实现分散的资源管理，规范系统，手工操作。理想的目标是“一站式运维”。需要切换系统，一个平台解决一切。但是要管理的东西太多了。为了专业起见，市面上最早出现了解决单点的优秀解决方案，比如zabbix、Jenkins……但是从用户的角度来看，就像是“五要素少了一根弦”，要解决一个业务问题，需要开N多个系统来回跳转。这种方法令人沮丧。比较好的大厂实现了单点登录，解决了账号混乱的问题，但是还是一堆系统，用户体验差，运行效率低。事实上，这些单点解决方案非常重要。我们在设计DevOps的时候，要想做到高质量低成本，就必须利用好这些解决方案，像搭积木一样整合资源，把它们当作底层的轮子，站在巨人的肩膀上构建系统，力求在应用层做到“一站式”。工作细分到这个层面，指望一个系统解决所有底层问题是不现实的。示意图如下。可以看出整个工具体系分为两层，一层是轮子的底层，这一层是面向单个题目的解决，关注解决一类问题的深度和系统，上层是SRE的应用层，也可以说是业务层。业务层被底层轮子封装后，对资源、标准体系、运维服务（运维提供的服务）进行管理。所有的轮子都通过一套账户和权限系统连接起来。我们要用好开源社区这个优秀的轮子，尤其是小工厂。无需重复施工。我们要通过轮子的API接口在应用层做好流程封装，通过应用层的集成实现一站式运行。应用层作为SRE的用户界面反映了DevOps用户体验。轮子可以很复杂，“一站式运维平台”要尽可能简单优雅。写到这里，希望对作为修行人的你有所启发。
