一.前言
运维的基础工作通常是针对现有系统及项目的，例如服务器、各类云产品，正在运行的项目、监控、账号权限管控，项目上线等等，是宽泛而繁琐的，少有建设性的内容。
那当我们接手一套新的系统，就有必要将它本身及周边进行完善。可能少数公司有较为全面的运维体系，有我们的桌面运维，网络运维，安全运维，研发运维、数据库运维以及系统运维或应用运维等专业团队，而更多的公司运维可能只有1-2个。以上的岗位工作都需要完成，但以下我们着重会聊到应用运维。
在接触新环境时，面对的是上任留下的坑，这比开发接手代码要更加严峻。交接的资料其实不应该只是账号密码、工作流程，工作注意事项，更重要的是操作维护文档，因为系统很少有简单的环境，即便有，也会存在一些微妙的项目逻辑关系，稍有不慎，就有可能酿成线上问题，现在大多都是微服务的结构，增加了系统维护的复杂性。
例如接手后领导要你部署使用docker部署一个java服务 , 从正式环境复制一个到测试环境，结果启动后出问题了，可能是启动参数与目前环境不匹配，可能是连接权限未放开，可能是启动后连接的是生产的数据库，如果程序启动后清空或者修改了一些历史数据，令人细思极恐。
这种问题很常见，就我目前就遇到不少，好多配置信息写的很模糊，项目与项目之间耦合度非常高，没准就牵扯到哪个系统了，牵一发而动全身，是关也不敢关，改也不敢改，作为一名运维工程师，我们居然会不敢动一个项目！
所以要打造一个铁桶出来，这是一个创造性的过程，也是我们深入项目的过程。只有更深入的了解项目，才能更好的去维护项目。
做好一个运维的基础:
- 对自己当前的环境和任何东西都应该非常清楚；
- 要有监控，切实有用的可以发现问题的监控；
- 任何东西都要有备份，可以用于快速恢复，也要做恢复演练。
进阶∶
- 针对系统做优化处理；
- 针对工作流程做优化处理
这就是上述大纲了，后续会详细说明的，其实也是大众路线，先标准化、流程化，再自动化。
二.基础
2.1 项目摸底
在接手系统后，先要确保能日常维护，对整套系统做一个摸底，一般包括以下几项：
- 项目简介
- 账号密码表
- 项目资源管理配置清单
- 各种结构流程图
- 部署维护文档
- 项目监控策略汇总表
- 项目应急操作手册
项目简介
我们可以从当前项目的业务范围，即项目的功能是什么？以及项目负责人及相关人员是谁，方便我们后面更好的项目对接。账号密码表
账号密码表中应详细记载各服务器、平台、系统的登录用户名及密码，另外还应该有权限记录表，记录给谁开过权限，登录账号又是什么，以上种种，此处仅是距离，需要记录的东西很多，切记一定要准确清晰。项目资源管理配置清单
这里面我觉得至少包含但不限于4个sheet表：服务器清单，项目域名信息，项目服务信息，第三方服务资源清单，每种信息都应该列出项目所有环境的信息，例如正式和测试环境等。各种结构项目流程图
例如此项目的网络拓扑图，系统架构图，从这个拓扑图中我们可以看到此架构使用了多少台服务器，整个逻辑流程是怎样的。例如我们可以从域名开始摸，域名对应的Ddos防护，下面是负载均衡，再下面是每个模块的服务。每个服务需要连接哪个库，又需要和哪个服务进行交互。部署维护文档
此文档可包含详细的安装步骤，配置文件中的数据库等地址指向都要写清楚，那么如何检验此文档的实用性呢？将此文档交接给另外的同事，可以达到迁移恢复，复制项目的目的。项目监控策略汇总表
主要包含目前的监控策略，可分为基础监控和业务监控。基础监控为CPU、内存、网络带宽等服务器基础资源监控；业务监控则是针对服务本身的监控，此监控可暴露出当前的项目问题。此表可方便与项目负责人对接项目监控问题，或方便以后查询监控是否有遗漏等。项目应急操作手册
项目已知的问题，经常发生的问题的处理方法，解决方案等。
可能很多小伙伴认为上面部分内容是业务上的东西了，觉得运维没必要去学，开发让扩展部署几个服务，部署就是了，反正这块是开发要负责的，出了业务问题开发排查即可。
2.2 做一个好辅助
那这根本没有体现运维的价值。相信很多人玩过LOL，当时也着迷其中，记得有句话，在LOL小队5人中，通常由队长来担任辅助。因为辅助空闲时间更多，可以看到全局的内容，这句话放到运维身上也同样适用。
开发、测试都忙着对禅道中满屏的任务清单进行工作，需求、测试任务源源不绝，相信很多程序员都面临过产品或者运营作死的需求，尤其是互联网公司，项目需要进行快速迭代，有多个需求归类到一个版本中，大约2周一个版本，要在12天内开发完成，2天内进行预发布环境的发版测试，这段测试期需要一边解决bug，一边完成新的需求。
项目版本需求的排期都到3个月后了，并不是开发写完就可以休息了，后面任务只不过稍微提前了而已。测试也是一样，紧跟着开发进行功能验证，也是忙得不行。
那出现问题后，其它岗位并没有太多精力排查和关注性能等方面，都着眼于当前任务的开发，赶工期。那运维其实可以作为一个指挥官，并非是可有可无的角色，现在不被重视只是因为大多数运维并没有意识到这个重要性。
开发除非是全栈业务都熟练，就一个小团队20开发2测试1运维来说，开发都只研究自己的模块，每当出现问题就很难定位具体点，需要运维对整体系统要了解，系统+业务才能更好管理和排查。
2.3 学习业务
对于具体业务如何清楚了解，最好的方式是直接顺着现有资料捋顺它，遇到不明白的地方去问开发，将相应结构进行画图和文档进行维护好，那在公司中你的价值会成倍增加的。相信也会让领导更多的看到你落地的工作，且也会让同事们愿意相信你的能力。专业精神比知识更加重要。
当然不仅是为了更好维护系统，也是为了未来优化做准备。不用明白代码方面的，只要知道整体流程。
我们现在就有这种问题，某个模块连接哪个库都不知道，有时候突然发现测试的服务器竟然连接着生产的某个库，还用的公网连接（环境间VPC或安全组隔离），这要不一开始搞清楚，不去主动了解，那带来的问题、安全隐患会在后面某个时刻让你难受。
一个简单例子是有个老旧的电商项目，几台应用服务机器+一个Mysql数据库，当时问了一圈人大家都说应该是不用了，已经到新的上面了。也没有去保存备份直接删除了，没过几天就有使用者联系说还在用。。。
这种盲区在我们快300台服务器里还有大量的存在，要是运维人员不主动去了解，那开发也没时间去看的，这个隐患会无限期搁置，还是上面说的，会在某个时刻咬你一口。
在我们大致了解整体结构后，以文档进行驱动，先建立好空白文档页。重点中的重点是我们的拓扑图、服务配置清单，起码项目的架构，是什么服务要了解清楚。
具体要了解哪些，我这里只能大致描述，再具体一些的地方应当根据你的项目情况再去统计。
- 了解域名走向，请求走向；
- 了解各服务之间的搭配，例如rabbitmq哪些程序在用，用来做什么；
- 每个模块程序之间如何通信的，需要如何进行交互；
- 了解各服务作用，当出现问题后，我们可以快速准确地判断出大概是哪个服务的原因。
但业务还是要了解的，流程图也依然要画，画图我目前用的在线工具：processon，如果你觉得免费的可用文件数量不够，上面可以付费购买团队模式，不是很贵。
2.4 标准与流程
做好图后，开始到系统里去整理，做标准化、流程化。建立好以下几个标准：
- 服务名称命名：可根据项目环境或用途进行命令
- 端口规范：可根据项目环境或用途进行划分
- IP地址规划：可根据项目环境及区域进行划分
- 服务部署目录
- 日志输出目录
- 备份存放目录
- 工具包存放目录
- 数据存放目录
- 脚本存放目录等其它常用目录固定位置
流程：
- 各服务资源预算制作流程
- 服务器购买交付流程
- 服务部署/上线/维护流程
- 账号&权限添加流程
- 备份定期恢复验证演练流程
- 定期检查项目资源使用流程
- 故障报告管理流程
其实凡是资源都做规范了，凡是要多次重复做的都流程化，防止遗忘。这两样也是为了后面自动化打基础，将重复操作自动执行。
这两块整完，说明对系统做维护没有任何问题了，只要不是新东西，起码现有项目都可以管理好。
简单画个思维导图，标准化的范畴主要包含但不限于以下内容：
2.5 维护
在项目不扩展优化的情况下，要维护好当前资源，需要用到监控与备份的帮助。有效的监控可以及时发现问题，避免人力重复巡检。完善的备份可以在出现任何系统问题的时候（非功能BUG），立刻进行恢复，简单方便快速有效。
监控具体可以针对业务做技术选型，一般是zabbix，容器或k8s就Prometheus，需要图形展示监控数据就grafana，另外还有小米的运维监控服务Open-Falcon。
备份如果用云服务就简单很多，可以使用脚本定时备份传到OSS里。物理机可可以写一些脚本，将任何有状态的东西都备份出来。例如数据库、配置文件、日常脚本、服务日志、等等和纯净系统有差异的东西。
三.进阶
3.1 系统&服务优化
系统或服务的优化比较常见，一般是更改配置文件，使得服务可以承接更多并发，可以抗更多压力。
这些有大把的文档可以看，这里不重复了，主要提几点注意的地方。
- 每次使用新服务器前，应进行系统初始化配置；
- 优化并不是改改配置就行，需要对每个参数及整套系统都有深入理解；
- 改配置的时候要慎重，不要想当然，很可能你这里为了减少图片的带宽占用开启了压缩，结果改完就崩溃了，线上的图片显示不完全了；
- 做优化方案的时候，要有层次，可以从最简单便宜的地方来。例如从结构上优化、去掉一些没用的模块，可以释放很多资源；
- 做安全方案也是，VPN+堡垒机（如jumpserver）可以解决99%日常安全隐患，而不是去从花费高、细节的地方先去实现。
3.2 工作流程优化
上面说了，其它岗位很繁忙，很难有精力做其它事，这里除了系统还有流程上的。他们遇到一些工作流程性问题，即使可以解决，但也很难停下脚步。
运维的用户是内部人员和服务器，所以工作可以分为可见和不可见（相对于部门）。所以在维护设备和服务器之余（服务器不会总出问题），可以将精力放到维护devops上，也就是工作方法。
例如当我们需要统计我们云服务资源时，如果我们使用人工采集，就需要单独一个人花费可能数天的时间进行统计。 那解决这个问题很简单，做一个自动采集云服务的工具，再由我们进行检查及表格美化即可。
再比如工作中大量的zabbix报警，可能相对没有那么紧急，会不会污染我们的报警工具，钉钉或微信等。那么对于业务不可用的情况做一个电话报警是不是更好呢，这样也不用时时刻刻盯着钉钉报警。
看着差别不大，盯着也不碍事，实际是运维价值的体现。再说几个例子，当前登录zabbix啊，jenkins、gitlab或禅道、OA或其他各种系统等都是单独账号，那搞LDAP是不是更好。或者做一个内部使用的常用网址导航页，这样会不会使用更加便捷。
SQL语句的执行，经常需要DBA在服务器中执行，那么做一个SQL审核平台，例如archer，随时随地都能审核开发人员提交的SQL进行执行。同样对于开发人员而言，测试或开发在正式或测试环境查询数据时用WEB版的数据库在线审计平台是不是比每个人用navcita更加安全和可控方便？
那jenkins发版后在钉钉加一个提醒是不是好点？开发提交代码后，自动发布更新项目是不是更加简单高效？
这些看似没有也没事，但当你发现某个开发遇到一些麻烦的影响时，你去解决，这就是内部的贡献，就像LOL中的辅助，在总揽大局，在推动devops的发展。
devops的概念炒了这么多年，更多人也在追求这种更高层次的工作方式，看内容基本都是运维的，开发的很少。这也和开发埋头工作不无关系，所以还是辅助最强！
当然人家用SVN好好的，你换gitlab当然不爱用，虽然SVN各种麻烦，但他熟悉了。如果大家不支持，可以去和领导谈，写一写计划书，整体运维体系规划这种。如果你真的有想法，领导也许真的 对你的想法有兴趣，但如果领导懒得看，那可以换下一家了，这家真的不值得付出，因为往后余生，都很痛苦。如果支持的不多，关注不到你（很常见，好多公司没运维主管，就CTO），那可以将计划书拆分几个小块，一点点改革，尽量和效果关联上。
例如现在要推广kubernets，那你首先要研究明白kubernets，也要懂docker，找到痛点才行。再去说这个kubernets的好处，找到kubernets的特点，例如它的资源调度、故障迁移更有利于项目运行，对公司效率的变化。或者往盈利方面贴。一套测试环境可以省下xxxx钱，那数十个项目，一个月就可以节省xxx钱，写的务实一点，效果还是很震撼的。
做任何工作不是只埋头做，还要和领导多交流，我们应该主动打破上下级之间的沉默，将我们的想法讲给里领导听，获得领导的想法，虽然很多事情小公司不注重，但你做了和没做是两码事。你比别的同事多提出了一些概念，你在公司就是先驱者，大家会觉得你挺厉害，技术大牛，一直在推动发展。这里讲开发他们也不是傻子，devops人家都听过的，随意你推动，大家都会欢迎的。职场之路困难与机遇并行。
3.3 规矩
开发人员写代码的时候，都会探讨一下怎么写，出一个方案，画一个流程图，用什么技术。新临时增加的需求也是如此，起码接到的个人会先想好思路。
但到运维这里好像就随意起来了，加安全组直接通知下就添加了，备注随意写写，当对方不用的时候也忘记了删除。“规矩”也是要建立的，这样才能让人信服，而不是谁都能指挥你，然后加出问题、改出问题了，锅又到你身上。
当然不能傻傻的和别人对着做，大家都讨厌规矩太多，那要在方便的基础上建立一些流程即可，例如申请白名单可以发一封申请邮件，备注一定要清晰明了，利用python脚本定时检查采集安全组规则进行检查，防患于未然。
3.4 运维管理平台
运维自动化平台的建设本质是运维团队服务化能力的变现过程，它让我们从大量重复无规律的人肉操作中解放出来，专注于运维服务质量的提升。
由于文章篇幅所限，就不和大家全面介绍整个自动化平台的设计思路，简单说一下我个人的一些心得：
第一是循序渐进的原则，在自动化运维体系建设过程中，我们首先可以构建一个基础的服务器批量操作平台，先把一部分需要重复执行的工作搬到平台上来，再依据运维的需求丰富这个操作平台的功能和提升效率，最后把周边的系统打通，相互对接，形成完整的自动化运维体系。
第二是考虑可扩展性。设计系统的时候，功能或者设计方面可能不用考虑那么多，但是要考虑当服务器数量发生比较大的扩张时，系统是否还能支撑，比如数量级从十到百，或者上千了，这个系统是否还是可用的。
第三是以实用为目的。这在我们系统中也是有体现的。可以考虑借鉴市面上比较成熟的工具进行自研。为什么不建议直接使用呢？因为目前常见的开源运维管理平台并不是有团队专人维护，如果使用过程中出现问题，排查难度将非常高。当然不可否认的是参考的价值。所以建议优先考虑开源方案加一部分二次开发。