概述

干运维的这些年，我做过业务实施、写过需求说明书、做过运维、也研究过dba和开发，也干过阿里云、搞过自动化、研究过直播、学过python和go，总的一句话：杂而不精，哈哈~

下面聊聊我对运维的一些看法。

01.思想

做个有思想的运维

很多事情，例如发版部署，第一次发是学习、一直发就是重复性的工作了，重点是每天还是做这类型的工作，不去思考，可能每天已经习惯了这些重复性的工作，说起来也很闲，没事吹吹水，大多数每天就是这种状态，不去思考的人生，不尝试着跳出去是很没意思的人生。

决定你发展上限的是50%的技术水平+50%思想深度，但这50%的思想深度远比你想的重要

没有经历披星戴月，怎会有积累沉淀？

闲谈几个点：

1、安装部署某个服务或者研究某个知识点时，宁可花大量时间，也需要尽量将该服务搞透，做运维不要局限于单单干完手上的活，适当保持一颗对技术专注的心。

2、安装部署时，做好记录，发本地记录并发表博文，一直都有一个做笔记的习惯，善于总结，可以更容易也更快的帮助你成长。

3、乐于分享，把自己学的东西试着说出来，当别人问你的时候你才知道还有其他地方是没有考虑到，也可以锻炼下你的思考逻辑。

4、多听听其他大牛的思路，之前很长时间只是单纯的做技术，每天忙于解决问题的过程中，没有自己去做思考，有一次面试，听了位大牛的想法后茅塞顿开，要么做底层技术研究，要么跳出来去设计思考，哈哈，果然多交流还是有好处的。

5、自学、积极性，一直觉得我最大优势可能就是自学能力了，没有前辈，一个人一点一点去摸索，可能这也是我在中软学到的一项重要技能~

02.运维标准化

很多公司实际上都属于运维无序化的阶段，特别是那些单纯做外包的~

标准化和流程化的建设思路一般是包括三大部分：日常工作梳理、标准化和流程化制定、日常工作标准化和流程化执行。

讲的简单点就是文档、流程 ^_^

包括发版运维、日常巡检、故障处理、漏洞升级、系统监控等等实际上都应该有个标准，有个运维的流程，有自己的运维规范可以提高容错率，减少很多不必要的精力，也可以提高整体的效率。

标准运维应该是拥有可视化的图形界面，并进行任务流程编排和执行的系统。

很遗憾我们部门并没有做到这一步，可能领导也只是有想法，毕竟这社会还是看钱干活啊，这些吃力不讨好的事并没有多少人去做。

闲谈几个标准运维：

1、日常运维服务相关的标准化和流程化主要是标准化部署、配置以及流程化的处理如发布、变更等，这其中还包括数据库的数据处理流程、生产账号管理流程、以及备份和监控的标准规范等。

2、IT资源运维主要对涵盖系统基础设施的计算、存储、网络、安全四个基础部分的运维其中着重偏向于硬件以及硬件配置相关运维工作。

3、日常运维过程中出现的事件进行规范化和流程化管理与指导

标准化和流程化作为运维管理体系的基石和运维自动化的第一步，在进行运维管理工作中必不可少，而且要实现彻底的标准统一。在进行落地的过程中，要适当的与运维自动化并行，加快自动化的脚步，只有这样才能最大程度的减少人为失误，减少人力成本，提高运维的效率和质量。

03.运维自动化

不想再干重复性的工作，不想去跟开发扯皮，不想天天重复性加班，也就有了运维自动化。坐着喝咖啡，思考性的运维才是正确的人生。

运维自动化跟标准化实际上是不冲突的，当然包括目前的运维智能化。在做自动化的过程中可以规范流程，有自己的一套标准，很多公司是可以两者并行去做的~

做这个事情还是有意义的，也值得花时间去研究，注意切合实际，不搞花里胡哨的东西。

实现运维自动化有时候单枪匹马真的不好做，这个相对比较适合有团队一起去研究，或者社区网站之类的去做，也是这方面原因我还是偏向去研究了一些dba该干的活~

适合团队去做更大原因是因为这是理念性的东西，不是通过自动化工具实现其中一部分就算，还是要有闭环，从开发、部署到测试缺一不可，一个人的不叫devops。

开发团队 -> 源代码编码（开发语言）-> 代码版本控制（Gitlab） -> Docker 构建（创建镜像）-> 静态代码分析（白盒测试）-> 自动化单元测试 -> 代码覆盖率（覆盖率测试）-> Docker 版本（发布到容器）-> 提供部署到测试环境 -> 自动化功能测试 -> 发布报告 -> 生产部署

吐槽：这么多鬼东西，一个人咋干的来

仰望星空，脚踏实地，生活还是要继续，努力搬砖！

风雨哈佛路：愿你吞下了委屈，却喂大了格局。愿你吃掉苦难，却酿成蜜糖。愿你看透生活的真相，却依然深爱着它。我们都生活在阴沟里，但依然有人仰望星空。

大家觉得运维是什么呢？