运维体系之做好一个纽带（上）

一.前言

运维的工作通常是针对现有系统的，例如服务器、在运行的服务、监控、添加白名单、添加权限等等，是宽泛而繁琐的，少有建设性的内容。

那当接手一套新的系统，就有必要将它完善好的。除了大公司有5个运维以上的专业团队，有对应的运维体系，而更多的公司运维只有1-2个。

file

在接触新环境时，面对的是上任的坑，这比开发接手代码要更加严峻。交接的资料其实不应该只是账号密码、安装目录，更重要的是操作维护文档，因为系统很少有简单的环境，现在大多微服务的结构，增加了系统复杂性。

例如接手后领导要你复制一个tomcat , 从prod环境复制一个到uat环境，结果启动后出问题了，tomcat被修改过，启动后连接的是生产的数据库，程序启动后清空了一些历史数据。

这种问题很常见，就我目前就遇到不少，好多配置信息写的很模糊，没准就牵扯到哪个系统了，是关也不敢关，改也不敢改。

所以要打造一个铁桶出来，这是一个创造性的过程，也是成长学习的过程。

做好一个运维的基础: 1.对自己当前的环境和任何东西都应该清楚 2.要有监控，切实有用的可以发现问题的监控 3.任何东西都要有备份，可以用于快速回复，也要做恢复演练

进阶∶ 1.针对系统做优化处理 2.针对工作流程做优化处理

这就是上述大纲了，后续会详细说明的，其实也是大众路线，先标准化、流程化，再自动化。

二.基础

在接手系统后，先要确保能日常维护，对整套系统做一个摸底，一般包括以下几项： 1.账号密码 2.服务部署表 3.各种结构流程图 4.部署维护文档

首先是从流程图开始，例如是网页，就要从域名开始摸，域名对应的waf，下面是负载均衡，再下面是每个模块的tomcat。

那一个非首页的请求，而是一个下单请求该怎么走呢？当点击了下单，这个对应的域名该是什么，下单模块需要连接哪个库，又和谁做交互。

这就是业务上的东西了，可能好多运维觉得没必要去学，开发让扩展安装几个tomcat，安装就是了，反正这块是开发要负责的，出了业务问题开发排查即可。

做一个好辅助

那这根本没有体现运维的价值。相信很多人玩过LOL，当时也着迷其中，记得有句话，在LOL小队5人中，通常由辅助来担任队长。因为辅助空闲时间更多，可以看到全局的内容，这句话放到运维身上也很符合。

开发、测试都忙着对满屏的任务清单进行工作，需求、测试任务源源不绝，就我们来说jira上的版本任务，有多个需求归类到一个版本中，大约2周一个版本，要在12天内开发完成，2天内进行UAT环境的发版测试，这段测试期开发又要完成新的任务。

现在jira的版本需求都排到3个月后了，并不是开发写完就可以休息了，后面任务只不过稍微提前了而已。测试也是一样，紧跟着开发进行功能验证，也是忙得不行。

那出现问题后，其它岗位并没有太多精力排查和关注性能等方面的，都着眼于当前任务的开发，赶工期。

file

那运维其实可以作为一个指挥官的，并非是可有可无的角色，现在不被重视只是因为大多数运维并没有意识到这个重要性。

开发除非是全栈业务都熟练，就一个小团队40开发5测试1运维来说，开发都只研究自己的模块，每当出现问题就很难定位具体点，需要运维对整体系统要了解，系统+业务才能更好管理和排查。

学习业务

对于具体业务如何清楚了解，最好的方式是直接顺着现有资料捋顺它，遇到不明白的地方去问开发，将相应结构进行画图和文档进行维护好，那在公司中你得价值会成倍增加的。

不仅是为了更好维护系统，也是为了未来优化做准备。不用明白代码方面的，只要知道整体流程。

我们现在就有这种问题，某个模块链接哪个库都不知道，有时候突然发现测试的服务器竟然链接着生产的某个库，还用的公网连接（环境间VPC隔离），这要不一开始搞清楚，不去主动了解，那带来的问题、安全隐患会在后面某个时刻让你难受。

一个简单例子是有个老旧的打票服务，一台机器+一个Mysql数据库，当时问了一圈人大家都说应该是不用了，已经到新的上面了。也没有去保存备份直接删除了，没过几天就有使用者联系说还在用。。。

这种盲区在我们快300台服务器里还有大量的存在，要是运维人员不主动去了解，那开发也没时间去看的，这个隐患会无限期搁置，还是上面说的，会在某个时刻咬你一口。

file

在大致了解整体结构后，以文档进行驱动，先建立好文档空白页。例如整体结构图、网络走向图、单个模块走向图等等，不需要写详细的IP防止维护疲劳，起码架构要了解清楚。

具体要了解哪些我这里只能大致描述，再具体一些的地方只能根据你的资源再去统计。 1.了解域名走向，请求走向 2.了解各服务之间的搭配，例如kafka哪个程序在用，用来做什么 3.每个模块程序之间如何通信的，谁和谁要进行交互

其实这块用APM可以监控起来去发现问题，它可以监控从前端页面请求到后端、再到数据库的整条链路。BUT，业务了解还是需要的，后面也可以针对性做监控，防止服务没挂，但其实页面已经很慢。

画图我目前用的processon，在线画的，上面可以付费购买团队模式，一年一个人200多块，也不是很贵。

file

标准与流程

做好图后，开始到系统里去整理，做标准化、流程化。建立好以下几个标准 1.命名 2.服务部署位置 3.日志输出位置 4.其它常用目录固定位置

流程： 1.服务器添加流程 2.服务部署/维护流程 3.新人权限添加流程 4.备份定期恢复验证流程 5.定期抒写系统压力PV报告流程

其实凡是资源都做规范了，凡是要多次重复做的都流程化，防止遗忘。这2样也是为了后面自动化打基础，将重复操作自动执行。

这2块整完，说明对系统做维护没有任何问题了，只要不是新东西，起码现有都可以管理好。

维护

在不扩展优化的情况下，要维护好当前资源，需要用到监控与备份的帮助。有效的监控可以发现即使发现问题，避免人力重复巡检。完善的备份可以在出现任何系统问题的时候（非功能BUG），立刻进行恢复，这样对技能要求最低了。

具体可以针对业务做技术选型，一般是zabbix，机器多就夜莺，容器就Prometheus，需要图形展示监控数据就grafana。

备份如果用云就简单很多，可以快照备份传到OSS里。物理机最好写一些脚本，将任何有状态的东西都备份出来。

例如数据库、配置文件、日常脚本、ansible的hosts清单、等等和纯净系统有差异的东西。