运维体系的构建之做好一个纽带

一.前言

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

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

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

例如接手后领导要你复制一个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个月后了，并不是开发写完就可以休息了，后面任务只不过稍微提前了而已。测试也是一样，紧跟着开发进行功能验证，也是忙得不行。

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

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

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

学习业务

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

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

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

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

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

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

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

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

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

标准与流程

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

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

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

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

维护

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

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

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

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

三.进阶

系统优化

系统的优化比较常见，一般是更改配置文件，使得服务可以承接更多并发，可以抗更多压力。

这些有大把的文档可以看，这里不重复了，主要提几点注意的地方。
1.优化并不是改改配置就行，需要对整套系统都有深入理解

2.改配置的时候要慎重，不要想当然，很可能你这里为了减少图片的带宽占用开启了压缩，结果改完就崩溃了，线上的图片显示不完全了。

3.做优化方案的时候，要有层次，可以从最简单便宜的地方来。例如从结构上优化、去掉一些没用的模块，可以释放很多资源。

4.做安全方案也是，VPN+堡垒机可以解决99%日常安全隐患，而不是去从花费高、细节的地方先去实现。

工作流程优化

上面说了，其它岗位很繁忙，很难有精力做其它事，这里除了系统还有流程上的。他们遇到一些工作流程性问题，即使可以解决，但也很难停下脚步。

运维的用户是内部人员和服务器，所以工作可以分为可见和不可见（相对于部门）。所以在维护设备和服务器之余（服务器不会总出问题），可以将精力放到维护devops上，也就是工作方法。

例如产品经理采集到用户需求后，建立了一个jira（一个任务分配工具）任务，这时候需要去主动告知开发，不然开发只能去上面看是否有任务。

那解决这个问题很简单，上一个插件邮件提醒。但其实想想这个方法并不好，会污染邮箱。那钉钉提醒是不是更好呢，这样下班也不会打扰。

看着差别不大，邮箱也不碍事，实际是运维价值的体现。再说几个例子，当前登录jenkins啊、jira啊、confluence啊都是单独账号，那搞LDAP是不是更好。

那jenkins发版后在钉钉加一个提醒是不是好点？那测试或开发在uat环境查询数据时用WEB版的数据库在线审计平台是不是比每个人用navcita更加安全和可控方便？

这些看似没有也没事，但当你发现某个开发遇到一些麻烦的影响时，你去解决，这就是内部的贡献，就像LOL中的辅助，在总揽大局，在推动devops的发展。

实际devops炒了这么多年，看内容基本都是运维的，开发的很少。这也和开发埋头工作不无关系，所以还是辅助最强！

当然人家用SVN好好的，你换gitlab当然不爱用，虽然SVN各种麻烦，但他熟悉了。

如果大家不支持，可以去和领导谈，写一写计划书，整体运维体系规划这种。如果领导懒得看，那可以换下一家了，这家真的不值得付出，因为往后余生，都很痛苦。

如果支持的不多，关注不到你（很常见，好多公司没运维主管，就CTO），那可以将计划书拆分几个小块，一点点改革，尽量和效果关联上。

现在推广git，那你首先要研究明白git，也要懂一些SVN，找到痛点才行。再去说这个git的好处，对公司效率的变化，往盈利方面贴。每天节省30分钟的SVN使用时间，那40人的开发，一个月就可以节省xxx钱，写的务实一点，效果还是很震撼的。

做任何工作不是只埋头做，还要和领导多交流，后面沙龙等等都可以去公司名义参加（要想办法这么做带来效益），虽然很多小公司不注重，但你做了和没做是两码事。

你代表公司参加，拿会一些礼品（甚至可以互相印刷，当然这块见仁见智了）和对方的一些概念，你在公司就是先驱者，大家会觉得你挺厉害，技术大牛，一直在推动发展。这里讲开发他们也不是傻子，devops人家都听过的，随意你推动大家都会欢迎，觉得很好。

规矩

开发人员写代码的时候，都会探讨一下怎么写，出一个方案，用什么技术。新临时增加的需求也是如此，起码接到的个人会先想好思路。

但到运维这里好像就随意起来了，加防火墙直接就通知下就添加了，备注随意写写，当对方不用的时候也忘记了删除。

“规矩”也是要建立的，这样才能让人信服，而不是谁都能指挥你，然后加出问题、改出问题了，锅又到你身上。

当然不能傻傻的和别人对着做，大家都讨厌规矩太多，那要在方便的基础上建立一些流程即可，例如申请白名单搞一个jira工作流，让对方填写，即使是临时人员，我帮你填写也可以。

可以搭配python脚本检测jira的白名单问题，获得白名单开放时间信息，再查看防火墙列表是否还在，超出时间的可以自动删除并发钉钉提醒。

jira工单

jira是运维工作的一个体系，除了超小的随手任务（加白名单，加个权限），大致都要去建立内容。其实白名单这些有的大公司可能也要加入jira。

这对应的是未来的看板和工作展示（PV报表、故障报表），IT可能一个公司做3年都算是长的不行的了，所以不要觉得没用，对于多个运维的肯定会做这块的。

这样对运维的工作会曝光，将清晰透明，在多个运维当中可以看出谁在划水和偷懒。当然也可以方便任务分配和记录，运维干的是一个很杂的活，经常会出现做一半中断的情况，就需要jira这种东西去记录。

当忘了做什么了，可以去查看代办任务，防止忘记。结合一些脚本可以做看板，例如jira任务的完成数量。项目的一些进度等等。

同款的还有confulence，非常适合做文档方面的记录，对知识进行整理，对公司也有好处，可以有一个资料库，推荐公司大力推广。

在confluence上尽量不要记录可变化的数据，例如主机信息、域名对应表。这些东西最好用python去写一个动态脚本，不然会频繁于维护confluence，wiki将失去查看意义，每次查看还是去源头看（例如阿里云），而只是去维护它。