今天翻了翻以前的笔记，偶然发现这篇《腾讯最赚钱的部门是怎么做运维的？》读后感，恰如其分的解答了当年面临的运维困惑，为后续的运维道路扫清了思想上的障碍。下面我就来分享下吧。
运维工作的经历及变化
「刚干运维的前二年」，觉得运维只要做到故障处理、业务稳定运行就可以了；
「干运维的第三年」，知道监控对于运维的重要性，通过可视化监控了解服务器、数据库等的运行状况，报警通知及时处理故障，保证业务的稳定运行；但随着管理服务器增多，手动操作使得运维倍感吃力；通过同事了解到pssh等工具，可以进行批量远程操作；也自行简单使用puppet自动化工具，因此算是误打误撞对自动化运维的入门吧；
「干运维的第四、五、六年」，通过对公司内一系列开源组件的进一步熟悉，运维工作算是进入正规；之后通过对外项目，使用ansible自动化工具的经验，完全打开了运维自动化的这扇门。
「干运维的第七、八年」，通过对devops、敏捷开发等概念的了解，对运维工作的意识又更进一步，因此在运维管理工作中做了如下工作：
运维管理框架，即基础设施、系统应用服务、平台服务；
运维标准化，根据框架生产不同层次的标准；
运维自动化，jenkins（devops工具）+ansible（配置管理工具）实现版本发布、自动化测试、 系统上线、服务器上线等一系列自动化；
运维可视化，通过zabbix、grafana、elk等工具，实现系统监控、数据分析、日志分析等功能；
运维管理工作的新认识
「第八年9月中旬」，看了《腾讯最赚钱的部门是怎么做运维的?》其中有一选段是关于运维服务化的摘抄：
「运维的本质到底是什么？」
小编从2002年开始做运维，一直到现在，都算是在运维行业里摸爬滚打，以前，小编觉得做好发布变更、故障处理，让业务保持运行稳定就是运维的价值，但通过这几年的思考和实践，小编觉得那是不够的。那么运维的本质到底是什么呢？小编觉得是服务，是「服务于业务，因为运维是用技术解决业务问题，运维的价值要依托于业务才能体现。」
运维不是因为技术高深，或者管理了几万台服务器而很牛逼，也不是能玩转很多开源工具而很牛逼，这都不是运维的关键。
小编提一个观点：「对于运维来说，服务第一，技术第二。运维技术再牛，如果不能服务于业务，帮助业务取得成功，那价值也是有限的。」 那么怎样服务业务呢？小编们总结了四点：
贴近业务
小编们一定要与业务走得比较近，保持信息的畅通。
理解业务
要知道业务目标是什么，用户群是什么，商业模式是什么样的。之前小编见过很多运维，甚至在公司做了半年、一年，还不知道所运维的业务的商业模式是什么，这样的话，小编们怎么能有针对性地提供服务，去帮助业务成功呢？ 理「解业务还意味着要站在业务运营的角度思考问题，而不仅仅站在运维的角度思考。」
挖掘需求背后的价值
小编们经常会收到运营人员提出的需求，在理解业务的基础上，小编们要挖掘这些业务需求背后的价值，比如说运营人员让发一个版本，做为运维，小编们是不是把这个版本发布完就OK了呢？
肯定是不够的，「小编们还要去看业务发这个版本的目的是什么？」 可能是为了拉新用户，也有可能是做个活动去拉收入，或者是修复bug。每一个版本的目的不一样，运维所做的事情是可以不同的。比如这个版本是拉新用户，小编们把版本发布完以后，还可以采集更多的数据，去帮助运营人员分析，看是不是达到了拉新用户的目的。或者协助运营人员分析，这个版本的用户体验对于拉新用户是不是有瓶颈。这都是运维可做的事情，也是业务运营很需要的事情。
扩展服务价值
着眼于业务和服务，小编们可以不断挖掘到新的价值点，扩展运维服务的价值。当然了，这里绝不是说技术不重要，「优秀的运维服务需要强大的技术来支持」。举个例子，你想协助运营人员做用户体验的分析，这需要较强的技术能力来支撑。因为像上述的版本数据分析对实时性的要求很高，如果你没有及时分析出来，错过了运营时机可能就来不及调整了。
可以说，业务视角和服务意识决定了运维服务可以拓展到哪里，而技术能力则决定了这些服务最终可以实现多少。
总结
看完后，结合自己的运维工作，可以说基本是脱离业务的，也就是作者说的”不知道对所运维的商业模式、用户群、业务目标“，真是自惭形秽。
当前运维管理工作主要是三化，即标准化、自动化、可视化；这三化不是固定了，随着运维工作的不断拓展，一定会出现更新。至于下一步阶段性目标，是可以围绕”服务化“展开的。
1.运维思索系列
2.运维管理系列
3.运维监控之路
4.蓝鲸之路
5.CI/CD之路
6.Ansible之路
札记：他强由他强,清风拂山岗；他横由他横,明月照大江。
— 金庸
喜欢这篇文章，记得点赞+在看哦~
声明：文中观点不代表本站立场。本文传送门：http://eyangzhen.com/164601.html
