这里针对的是大中小型项目的业务系统运维架构的设计，非互联网型项目，一些个人经验和思路，抛砖引玉，供参考。

背景

对一般性的运维来说，自己应该是接触几年，一二三线多个城市，政务互联网行业等都有，服务器基数在几台以几百台不等，业务微服务规模在100到几千不等，本身并不是专业做运维的（比如数据库DBA、网络等，这些有专业人处理），偏向于业务服务模块的运维设计管理，以下为一些设计经验。

概述

对于长期运行的业务，有好的运维工具，更有利于业务的稳定。一般来说，业务性的运维管理从几个维度，主要是IaaS层，中间件层，业务层，运行状态层几个进行的监控管理，结合人工，手工，自动化能力角度进行设计，去掉重复的手工和低阶的运维，使业务运维偏向于高阶的思考，提升整个运维的管理能力，整体思路从以下几点，我有我思：

以上几个点为基础的能力，中间还有很多，这里偏向于设计，具体细节由专业工程师去实施即可。

架构设计

这里是整体运维管理的架构设计，从多个角度和自动化能力的管理，架构如下：

针对大的方向上面，不同的团队和业务场景会有不同的业务方案。

基本上当前主要用到工具为以下工具，其它主流性的，用起来并不觉得多顺手，比如蓝鲸，自己偏向于脚本型管理，相对比较方便，主要使用技术工具如下：

基础环境搭建

这里根据本身的业务场景需求进行取舍，并不是一下就要上全套，毕竟资源等各个方面会有一定的限制，这里基础环境是整体的基础，包括以下几个点：

上面的工具注意配置下unit自动启动，当然也可以使用容器，但是过程发现，有的时候容器并不是特别可靠。

自动化操作引擎搭建

自动化操作是所有的运维管理的基础能力，也是一个统一的管理思路。这里的需要安装好jenkins和gitea，这个是基础。

自动化操作主要是结合pipeline+Ansible进行管理，通过ansible的host进行的各个服务主机的操作，这里建议的变量是存放在host当中，针对不同的业务场景替换host即可，在下次另一个环境的时候，直接导入jenkins备份文件即可。

ansible的hosts可配置比较多的变量，这些方便多业务场景的改变和运维环境的迁移。

运维日志的可视化

所有的运维工具还有业务运行都需要把日志文件进行可视化统一管理显示，前期需要先搭建好日志平台，这里主要是偏向于ELK+Kafka，小项目PlumeLog替换掉kafka更合适，因为他也可以不使用kafka，比如redis等轻量型队列，不过还是比较推荐kafka，稳定性还有日志收集一流，装个单节点就可以。

也可以针对PlumeLog进行二次改造，之前就是进行了改造，毕竟Kibana的学习成本还有es的学习成本并不是每个运维人员会做的。

工单管理工具的安装

这里的管理工具指的是Zbox，即将各个工单进行安装配置和跟进，这里建议是结合Dingtalk一起，新版本Zbox对这块的支持挺好的，可实时跟进，便于项目经理和运维经理实时跟进工单的处理状态，这里比较推荐的，省去很多无谓的沟通成本。

当然，有些是不需要这个模块，比如一些比较小的项目，但是中大项目或者需要长期跟进的话，建议这块，也可以采购，之前采购过几款，费用不少，但是效果貌似还没有Zbox好。

规则引擎安装

这里规则引擎主要是prometheus（貌似目前还没有发现比这个更好的），比较轻量级，安装起来也比较快，也可以安装grafana，这里我自己不太喜欢grafana可视化，有空细调整的话也可以把grafana做得挺好的，但是自己一般是在它的官网上找到模板，没什么空去看这个“好看”的大屏，平台工具多就意味着入口很多，这也很麻烦，所以针对于自己来说，会更关注Dingtalk的信息，因为可以把这些状态统一发到上面，如果是内网不能使用Dingtalk的，Grafana是一个不错的选择，或者说Prometheus的Alerts也可以，预警信息也是一目了然的。

运维采集监控

监控采集功能即是上面工具的使用管理，主要的设计思路如下：

环境状态可视化

环境指的是服务器、中间件、容器，这里集成的主要是prometheus的功能和node-exporter等，这些使用起来较为方便，基本上会把服务器的基础状态进行采集管理，普通的状态基本上会满足，包括中间件层和容器层也一样，基于exporter进行采集， 输入到Prometheus当中即可，这里rule规则主要引用git进行版本管理，同时使用prometheus的热加载管理，结合jenkins+ansible脚本进行在线跟进更新发布。

rule脚本的管理根据运维的需求进行调整更新即可，可定时在线更新。这里的rules注意下规则的管理，一不小心有可能会造成N多的信息爆炸，那也是很恐怖的事情。

这里注意一点是，kuernates内部一般也会安装1个prometheus会更好地管理，注意不要跟物理机上的prometheus冲突就可以，当然，你也可以只用1个，但是k8s里的规则更新貌似不太好处理，会比较麻烦，之前的处理思路是jenkinsfile重新发布一下proemtheus，然后日志数据持久化。

业务运行状态的监控采集

这里主要分为两部分，一部分是前端，另一部分是后端，还有一部分是关注的业务指标。

这里前端的采集主要是nginx的采集，处理好日志的json脚本，然后通过filebeat进行采集发送到kafka中，这里的数据量大的话，推荐kafka集群，同步通过elk进行展示，这里展示的效果因人而异，实际的效果可以很酷，但是我一般比较喜欢列表展示日志。

然后就是后端数据的处理，也可以使用filebeat进行容器采集，但是k8s也会带有日志系统进行发送也可以，之前没怎么用过，对于后端的数据，使用的是springboot的配置，进行动态的环境变量处理，即配置logback-spring.xml配置，添加多环境即可，这里有一些会考虑sky，可以结合链路跟踪还有前后端请求状态，这里也比较偏向于业务项目。

有的时候，工具太重了会比较影响，所以在业务日志采集这里，会采集关注的业务服务日志，并不是所有的都会采集。另一种方式是使用容器的nfs映射能力，映射到本地存储，进行二次转移，这些主要是看项目情况，大项目的采集会比较多，同时造成很多日志压力，配置也比较高。

最后有一部分是业务指标的问题，业务指标的产生并不像日志那样，会触发错误。这里推荐根据业务情况然后进行一定的逻辑判断，这里用得比较多的方式是定时的业务计算进行业务指标输出，放到中间库里面（比如mysql），触发自动化定时巡检获取到，业务指标的监控偏向于业务运行时的跟进。

运行状态巡检管理

运行状态巡检是一个每日进行的工具，比如异常容器有哪些，异常的nodes有些，异常的链接还有端口是否开通等，一些重复性的工作而且监控工具无法触达到部分，可以通过pipeline+ansible结合进行自定义处理，比较个性化，也是有必要的。

ansible运行的结果是可以输出json的，这个方式更好的汇总的集成平台上面（集成平台这个是基于springboot开发的一个集成系统，比如简单），用于收集一些运行时状态，包括异常的统计，巡检的情况反馈等，便于下面进行周日报的输出。

运维管理平台维护

维护主要包括脚本的管理和更新维护，巡检之后进行的数据汇总和汇报，还有过程工单的跟进管理。

脚本的管理和维护

这有点个人喜好，为什么不喜欢使用一些管理平台（比如蓝鲸、ansible tower）即是如此，没有统一的运维脚本管理，包括版本的管理，操作人员的审计，权限的配置管理等，对于上面的运行来说，过程有一套脚本可个性化的配置，是有这个必要的。

这里的维护主要是结合git版本管理进行，通过pipeline来进行脚本进行任务的编排管理，基于jenkins的调度和模块化处理，基本上是满足平时的90%的管理了，平时10%的可能遇到的机率比较少，另外可移交到人工管理上。

周日报的汇总管理

汇报机制和统计机制是运维改进的一个保障，通过统计发现问题频率高的地方和影响业务地方。在收集到json数据之后，进行数据的统计分析管理，然后通过springboot自定义开发，获取到统计结果，自定义周期发送出统计结果，可按天、周、季、年等方式。

这里的开发难度并不是特别大，实际也可以通过pipeline+groovy脚本进行统计处理，但是这个必要性并不是特别大，而且安全性不是很高，成本略高，建议写个集成平台程序就可。

过程工单的管理跟进

管理制度和过程主要还是看团队的习惯还有实际情况，这里提的一个能力是工单的跟进集成，主要是zbox+dingtalk处理，然后进行汇总。

但是这里注意的是建议不要使用外部邮箱，因为发送记录会存在外部邮箱一份，而且是运维内容，这比较不安全，当然也可以申请内部邮箱，这样会更安心一些。

总结

以上为业务系统进行的运维管理架构设计，偏向于应用层，主要目标是达到可跟进，可管理，自动化等能力。以上为一些经验参考设计。