devops开发运维一体化流程,devops平台搭建
前言系统就像一顶帽子，是对DevOps运维的深入总结。写下你在工作中的感受，希望对你有所启发。DevOps系统是从最初的运维一步步走过来的。原来运维就像一本书。有了这本书，我们想继续提高效率，减少错误，优化流程，然后我们发展成DevOps和AIOps…….首先，运维的业务功能规范后，形成了章程和程序。在互联网快速发展的特点下，形成了一套应对“快”和“变”的系统，我们不断迭代升级，在这些上面努力。从开发的角度来看，运维系统就像一个算法，实现算法的语言就像一个工具，DevOps就是工具的升级。工具的本质其实是一个基础支撑。有了这个支撑，一系列目标的实现更加科学高效。下面是一个简单的示意图。在原始阶段，经过运维工程师和各部门之间无数次的磨合和探索，逐渐形成了一套初步的制度，无形中规范了运维工作和注意事项。工程师通过这一计划开展日常工作并确保业务的健康发展。这个阶段可以说是
制度为王、制度规范
，没有系统的运维平台，有的只是零散的工具。一切基本靠人力，靠制度，靠约束。虽然是原始阶段，但也是运维最真实的样子。忙来忙去，效率跟不上需求，系统跟不上执行，与开发的协作始终难以共享同一个渠道，需要大量运维人力。进一步发展，为了提高效率，同时解决与开发的沟通合作问题，提出了DevOps，大家开始做自动化和DevOps文化。这种自动化的本质是把运维系统放到一个或多个系统上，通过自动化系统提高工作效率，同时用系统实现系统。开发和运维都在一个系统上协调，遵循相同的规则，协作效率要高得多。这个阶段市场上出现了技术为王、平台规范
，运维开发，SRE，各种问题得到有效解决。当然，解决的程度取决于DevOps系统的优劣，参差不齐，但这个发展方向已经出现。经过进一步发展，行业领导者提出进一步减少人工参与，用机器自动化代替人工自动化，这就导致了AIOps的出现。仔细观察，从最初的运维到DevOps的演变，就是越来越重视技术问题解决的过程。人员越来越少，能被技术替代的岗位逐渐被替代。随着自动化平台的成熟和稳定，理论上理想的终极状态可能只是“运维平台+业务运维
”，其他运维会转移到其他运维，业务运维会转移到技术运营
。那么我们如何考虑设计一个DevOps运维服务系统呢？综上，一个最小型号是定业务规范、建工作制度、搭 DevOps 系统
，作为循环迭代升级的最小单位。首先，设定业务规范。让我们来谈谈美国人和中国人之间的农业。美国人建立农场，将耕作过程标准化，然后引进工具。几个民族都有几百亩地，收成高、成本低反而不累
。中国人每个人都在几英亩的土地上工作，但由于收成低和成本高，他们都很累。运维我也有同感。我要做批量生产，高效率运营，就需要标准化，制定各种标准，形成规范。如果每个服务各行其是，就会有一群人真的很忙，但是就是干不了。那么，我们需要通过DevOps批量管理什么呢？可以分为三类：资源、服务、规范
。资源包括服务器、网络设备、负载平衡、证书、域名、代码、容器等。服务包括服务监控警报、CI/CD、日志分析、服务计划、配置管理等服务。围绕操作和维护提供。规格包括因此，规范是整个DevOps系统构建中非常重要的一部分，每个规范也对应着一些最佳实践原则。运维中的一些规范整理如下：1 .在线改规范：代码在线，回滚，伸缩；配置：系统配置和应用配置；网络变更：网络割接和设备更换；其他变更：流量调度、业务切换、业务下线……原理：制定变更审核流程；制作变更相关方的通知(群发、邮寄)；制定变更回滚策略；遵循测试、灰度和全在线的规则；离线时要清理服务器依赖，比如vip挂，域名解析。2.规范容灾服务和容灾：多机、多机房；数据容灾：多备份和异地备份；网络容灾：多线路、多设备；原理：自动切换比手动切换好；无状态比有状态好；热备用比冷备用好；电脑室比单间好。3.容量规格系统容量：康尼金定律计算系统的全链路容量、使用量和余量；容量：模块的容量、用途和余量；房间容量：分房间的容量、使用量和余量；单机容量：用于反向机房和模块容量；原理：设置单个模块的容量指标(如QPS、连接数、在线人数等。);容量要考虑下行(读)、上行(写)和存储增量；计算当前模块的总容量，收集当前使用量，比较容量计算余量；在找到短板模块之后，可以根据坎尼金定律计算出系统总容量。4.巡视并规范用户核心指标；核心服务指标；基础资源索引：服务器；依赖指标：依赖db、依赖接口；自动检查报告；Oncall排列；原理：DashBoard的核心在于收敛和愿意；自动巡检的必要性在于异常检测和故障预防。5.告警规范基础监控：CPU、内存、网络、IO；监控：进程和端口；业务监控：日志、业务埋点；依赖性：数据库，依赖性接口.原理：核心监控汇聚成告警，告警分级，注意告警的影响；核心监控形成仪表板；用于解决问题；报警的价值在于实时发现故障。6.方案规范线路切换：中国移动、中国电信、中国联通线路切换；机房切换：不同机房之间的切换；机器切换：机器出现故障时，将其移除；服务降级：无法切换时，降低标准继续服务；数据库切换：主从切换，读写切换；网络切换：主备线切换和链路切换；原理：域名切换比IP更换好；自动移除优于手动操作；自动切换优于手动切换；想想雪崩。7.故障管理规范服务分类：确定每个服务用户观点的影响；断层的分类：制定断层的分类标准；制定故障通知和处理规范；制定故障恢复和改进措施的规范，并按时保质完成；原则：拥抱失败，类似的失败不能重复。8.权限安全规范开发、运行和维护以及临时权限；安全性符合安全审计标准。9.文档和工具标准化，以统一的方式共享知识文档；统一各种脚本工具；原理：理想情况是“一站式运维平台”，一个平台覆盖所有工具运营。10.标准化规范：主机名标准化；存储标准化；日志格式的标准化；域名使用的标准化；软件安装目录结构的标准化；原则：主机名尽量能看到更多的信息，比如服务、模块、机房等。日志是解决问题的重要信息。必须要标准化，方便人工排障，更重要的是为以后用工具处理打下基础。1.资源管理规范：服务器的vip域名证书代码原理：资源是相关的，相关的资源管理应该b
第二，工作制度的建立与工作流程方法相对应，会影响文化，制度的建设，也体现解决问题的水平。一个好的系统应该是系统化的、工具化的、可执行的、可量化的，这样后期才能用DevOps实现，系统才能以友好的方式放到运维平台上。制度的出现不应该是为了解决一个案件，而是为了科学地解决一类问题。如果制度的执行只靠人的自觉自律，那是靠不住的，必须尽可能地陷入技术。在线审批系统、合规部署系统、日志清理系统、容量管理系统、在线呼叫管理系统、服务检查系统、故障管理系统、安全管理系统.工作中最不可或缺的就是各种制度。如何搭建它们是有技巧的，也体现了运维的能力。这种能力坚持下去，就会成为一种文化，比如
考虑问题看到本质，解决问题解决根本。
。另外，系统的建立必须以长远的眼光，科学的态度，DevOps的思想(工具思维)。
为基础。三、设置DevOps系统设置系统是通过技术手段使以前的内容信息化，用科学的工具实现分散的资源管理、标准化的系统和人工操作。理想的目标是“一站式运维
”。工程师不需要切换系统，一个平台就能解决一切。但是要管理的事情太多了。出于专业的考虑，首先市场上有解决单点的优秀方案，比如zabbix和Jenkins….但站在用户的角度，就像“五行缺一弦”。解决一个业务问题，需要打开N个多系统，来回跳转。这个方法是崩溃的。比较好的厂商做单点登录，解决了账号混乱的问题，但还是一堆用户体验差，运行效率低的系统。其实这些单点解都很重要。当我们在考虑设计DevOps时，我们希望实现高质量和低成本。我们一定要利用好这些解决方案，像搭积木一样整合资源，把它们当成底层的轮子，站在巨人的肩膀上做系统，努力做到应用层做到“一站式
”。指望一个系统解决所有底层问题是不现实的。图表如下。可以看到，整个工具系统分为两层。第一层是底层的轮子层，侧重于单个题目的解决方案，侧重于深度和系统性的解决方案。上层是面向SRE的应用层，也可以说是业务层。业务层通过底层的轮子封装后，管理资源、规范制度和运维服务(运维提供的服务)。所有的轮子都是通过一套账号和权限体系连接起来的。要利用好开源社区的优秀轮子，尤其是小工厂，没必要重复建设。我们要通过轮子的api接口把应用层的流程打包，通过应用层的集成实现一站式操作。作为SRE的用户界面，应用层体现了DevOps用户体验。轮子可以很复杂，“一站式运维平台”也要尽量简洁优雅。写到这里，希望对你有所启发。来源：微信官方账号魏云网吧，点击查看原文。GOPS 2020 深圳站刚刚结束，GOPS 2020 上海站要来啦，11月27-28日，相聚上海，专场图先献上~
近期好文：
从小到大，透彻理解cookie、session、token之间的关系，轻松理解全球上网流量下降3.5%仅仅是因为一个配置错误？百年IBM宣布拆分！10月的编程语言Python，预计第二！谁是一周IT资讯的行业领袖？ 2020 IT技术领袖颁奖典礼与你同在！”高效运维”微信官方账号诚邀技术人员投稿。邮箱是jiachen@greatops.net，或者联系人是微信：greatops1118。点击“看”一年不停机。
