75后运维总监分享：从传统到互联网，运维人员的学习与发展心得-瑞安招聘网

我今年75岁，在职场打拼20年了。早期是做主机服务器和数据库的，后来从事运维工作。现在入驻国内一家知名连锁餐饮公司，担任运维总监，负责DevOps。企业内部ToB、ToC侧的平台建设工作和容器云运维工作。从国企到民企，从传统企业到互联网企业，再到传统企业，我深深感受到技术发展的速度之快，快到人们对于更新迭代几乎不知所措。我想将技术趋势与我对当今时代如何运作的想法结合起来。谈谈你自己关于维护人员如何学习和发展的经验。

一、前言

过去几十年，科技发展面貌发生了翻天覆地的变化。

20世纪90年代，商业软件几乎成为技术的全部，IOE成为每一个想要登上职业巅峰的IT人员的最佳选择。 IOE也逐渐统治了那个时代的大部分IT领域。以Oracle为例，最初只是一个数据库软件，后来通过不断的并购，成为了前后端一体化的一站式解决方案提供商。从Java、JavaScript、简单的Web开发工具Oracle Application Express，到中间件weblogic，到数据呈现工具Obiee，到ERP领域的Sieble和peoplesoft，再到数据库的高可用RAC、容灾datagurad、replicationgoldengate ，最后，仅仅通过提供一体化的Exadata，Oracle就展现了其称霸IT上下游的野心和实力。其实当时IT人的方向比较明确，就是学习Oracle。这就像学习会计和参加注册会计师考试一样。方向很明确，不会有任何混乱。我当时也是这么想的，以为自己可以学Oracle一辈子，如果能在Oracle原厂工作，一定能成就大事。

但这个世界上唯一不变的就是变化。接下来的日子里，IT界发生了很多变化。首先，随着云的兴起，AWS出来了，然后Salesforce紧随其后，但甲骨文却忽略了它。甲骨文首席执行官拉里最初认为云无关紧要，因为云只是一堆使用根网线连接到互联网的机器。但事情的发展却远远超出了他的预料。云的发展彻底改变了IT世界，软件变成了SaaS和PaaS。后来，AWS的Aurora DB等数据库开始蚕食Oracle的数据库市场份额。虽然这种侵蚀每年只有0.3%左右，但很明显甲骨文的市场份额正在慢慢下降。对于IBM来说，其服务器和小型机的订单呈下降趋势。云IaaS让大家再也不用担心服务器的巨额投资。

其次，开源软件的广泛使用。以 Google 为代表的制造商正在积极在 github 上开放其软件的开源版本。可靠性要求不高的客户开始选择开源软件，而不是购买昂贵的IOE许可证。于是开源软件开始从前端到后端蚕食IOE市场。对于每个商业软件，总有一个开源替代品。

三是分布式应用。分布式应用的推广并不符合以Oracle为代表的厂商的商业利益，但历史的进步是不可阻挡的。当服务器水平线性性能扩展相对于垂直扩展的优势逐渐被认识到时，Oracle不得不低头，在Oracle 12c数据库中已经推出了分片特性。但不得不说，已经晚了。各种开源版本的分布式应用程序已经占据了大部分市场。

因为以上三点，作为一个技术人，我的工作学习轨迹发生了改变。我从专注Oracle数据库技术，到开发多个方面，从前端到后端，从应用到数据。学习、努力，才能在运维道路上走得长远。

2、运维技术之路

其实说实话，运维技术这条路并不好走。过去很难，因为学习成本很高。有过经历的同学一定知道，你要不断地参加认证考试。我参加了 OCM 考试。仅考试费就7000多元。现在的路更加艰难，因为开源技术发展太快，种类也很多。如果不知道学什么，很容易陷入“生命有限，学习无限”的尴尬境地。

大量开源新技术涌现。 VueJS已经出现在前端，并且有取代AngularJS的趋势。与此同时，React Native出现，并有取代VueJS的趋势，实现IOS和Android的统一代码； RabbitMQ和RocketMQ已经出现在中间件家族中，使得IT架构中除了Weblogic和Websphere之外，还有其他选择；数据库方面，除了开源的MySQl之外，还有MongoDB等NoSQL。数据库，还有MyCat、shardingJDBC，甚至OceanDB、TiDB等很多分布式解决方案；在数据分析领域，Kylin已经出现取代Oracle OBIEE、Python语言、Hadoop Mapreduce取代SPSS等分析软件的趋势；在存储领域，Ceph和超融合系统的出现，利用高速网络和SSD磁盘将本地磁盘组合成虚拟存储，大有取代EMC昂贵阵列的趋势。

那么如何走上维修工程师的道路呢？谷歌给了我们很好的启发。未来的运维工程师应该以发展成为拥有多种技术的SRE工程师为目标。 **我将在下面阐述我的观点。

2.1 技术选型

好吧，现在问题来了。面对如此多的技术，学什么、如何学、学到什么程度是摆在我们面前的难题。我这里提倡的是广度学习，也就是T字学习法。

2.1.1 深度选择——“T”表示“I”

学习的时候，首先要选择T字中的竖线，因为这是基础，会影响到你以后学习广度的很多方面。我主张发展是第一选择。对于运维来说，学习Python是最合适的。 Python被称为开发语言中的万能胶，因为它从前台到后端都可以使用。前端Python有自己的Django框架，可以编译一个临时的页面，有运维的包，有数据分析的包。人工智能也可以连接到张量流。它几乎是一种“万能油”。日本已将其纳入小学课程，其中就包括Python。如果你学得深入，你就不会出错。然后，选择mysql或Oracle中的一个进行精通，形成Python+Mysql或Python+Oracle的T形“竖条”。

一般来说，Python的迭代速度比较慢。虽然Python2到Python3的变化相当大，但目前以Python3为主。 Python2不再常见，很容易聚焦。从MySql5.7到MySql8.0，大多只是增加了一些新功能，几乎没有什么颠覆性的改变。他们也比较稳定，在时间上可以保证学得深入、精通。

2.1.2 宽度选择——“—”中的“T”

记得当我第一次进入一家公司的大数据部门时，我几乎被震惊了。为什么？因为经过详细分析，这个大数据部门生产的开源软件超过50种，而整个工程团队只有30人。追求新技术本质上没有错，但是学多了就很难掌握，而且新技术也很多。技术就像昙花一现。一开始就令人眼花缭乱。随着时间的推移而无人维护，它逐渐退出历史舞台或被取代。每个人的黄金学习时间只有十几年。如果选择了错误的方向，不仅会浪费时间，还会对你的IT职业生涯造成很大的打击。

首先，在选择学习广度时，必须遵守“从众”原则。也就是说，你学习的人越多，使用的公司越多，你就越需要将其添加到你的学习列表中。怎么知道？ Github为我们提供了很好的基础，以开源软件ceph为例，如图

正如你所看到的，它目前的提交数量高达 111,000 次，而 Stars 则有 7,800 次，这意味着它已经被点赞了 7,800 次。要知道Github上并没有“洪水军”职业（即使有也没有人发工资），所以这个数字基本反映了真实情况。并且4小时前就有更新，开发者正在积极更新。我们来比较一下另一个项目。

这也是一个分布式存储项目。 glusterfs 的 commit 数和 star 数比 Ceph 少很多。而且更新是昨天的事，开发者更新的积极性还不是很高。

2.1.3 实选——“T”字的整合

当今的技术正在快速发展。我们必须向外看，避免闭门造车。我们要根据外界的流行趋势不断调整方向，将“T”字融会贯通，应用到一起。

至于应用架构，一开始大家都熟悉三阶段架构。前端是应用层，多用tomcat来放置。中间是逻辑层，放置app和redis缓存，主要是jar包，后端是数据库层。然后出现了Duddo分布式框架，再后来演变成基于SpringCloud和Springboot的微服务框架。

至于托管架构，最初服务于物理机或vmware虚拟机。随后Openstack的崛起打破了vmware的垄断。然而Openstack毕竟是一个半成品，其自身的发展也存在很多问题。于是，容器化技术docker、Kubernetes技术就异军突起。。

然后将应用架构和托管架构整合起来，形成基于容器的微服务架构istio。所有应用程序都加载在容器的Pod中，Pod中还有sidecar来控制东西向的流量，形成服务网格（Service Mesh）。

当大家都以为这就是架构演进的最终形态时，Serverless模式又出现了，无服务架构。这种服务架构更加节省资源。容器仅在 Pod 使用时构建，在不使用时销毁。

针对这样的变化，你不需要很快地改变，但是你需要知道外面的技术情况是什么样的。根据外部情况，可以及时修改自己的学习方向和计划。学习永无止境。学习是一辈子的事情，无论如何。无论你的年龄，无论你的职位如何。

2.2 学习方法

我们在学校学习的时候，都是按照大纲和书本一步步学习的。但如果想在工作之余学习IT技术，就没有这么“好的”条件了。

2.2.1 文档学习

首先，“好”书并不存在，因为技术变化如此之快。记得两年前，我“下定决心”学习大数据，一年前买了一本hadoop大数据的书。没想到网上的信息和书上的不一样。原来书上的hadoop版本早就被淘汰了。

因此，我们必须依靠最新的资料来学习。开源软件最好的学习资料是文档文档，而且大部分文档都是英文的。您可以使用翻译软件来阅读和学习。

2.2.2 实践学习

光说不练总是不对的，所以建立自己的实践平台是很有必要的。这里我们可以使用vmware或者vbox虚拟机平台。当然，如果条件允许，我们也可以使用公有云上的资源。总之，从事运维的IT人员必须有一个可以实际操作的环境。

每个文档基本上都是该软件的最佳实践。最好在自己的虚拟机环境中运行最佳实践，形成自己的初步经验。

2.2.3 学以致用

很多时候，如果你不运用所学的东西，过一段时间你就会忘记。因此，在工作中学习就显得尤为重要。从事运维的IT人员在工作时要努力将所学运用到工作中。比如，在很日常的工作中，你要思考如何自己学习。 Python让它自动化，也就是学以致用。这样，一来你会有成就感，二来也不容易忘记所学的东西。

2.2.4 以教代学

虽然有练习的实验环境，并且我们在工作中尝试使用它，但是总有一些软件我们无法保持联系，那么我们该怎么办呢？我们可以把学到的东西整理一下，放到博客或者知乎上。有时候这不是给别人看的，而是给自己学习的。你要把事情总结、组织起来，很有逻辑性，有逻辑性的事情给人留下深刻的印象。

更进一步，你可以尝试将所学的内容整理成ppt教材，并尝试在镜子面前讲述。我的经验是，只有在传授知识的过程中，你才能发现自己理解上的不足。说几遍之后，就完全是你自己的了。某物。

2.2.5 不要要求彻底的解释

很多人在学习时常犯的错误之一就是“期望过高”。他们常常在阅读文档之前立下远大的抱负，但很快就发现有些东西很难理解而半途而废。知识体系的复杂性有时是相互关联的，而文档又不是学校教科书，不可能一步步进行。因此，正确的学习姿势应该是先读透，再精读。当遇到不懂的事情时，先在百度或谷歌上搜索，尽力理解。如果不行就暂时放弃，看后面的章节。通读完成后，精读的时候，可以回去解决之前不明白的事情。

2.3 “懒人”优先

在做运维工作的时候，一定要有一个懒人的意识，就是尽可能的“减少”自己的工作量。当然，我们绝对不是鼓励大家逃避工作、推卸责任；相反，我们鼓励大家使用先进的工具和技术来提高工作效率，避免重复不必要的工作。

2.3.1 ITIL流程规范

没有规则就没有规则。有些企业运维表现不好，不是技术不好，而是没有好的标准。我个人知道这一点。我经历过一家内部运维岗位基本被滥用的公司。他们每天都很忙碌，要实时承担老板安排的工作。他们基本上都是随叫随到的。这导致运维电力消耗巨大，运维工作难以开展。

正确的方法是按照ITIL规范将工作和职责分配给不同的部门。所有的工作都要按照相对固定的流程来处理，建立发布流程、变更流程、事件处理流程、问题处理流程等，这样才有章法。跟随。记得安排好自己的工作，有合适的工作量，这也是一种能力。

2.3.2 DevOps概念和工具

DevOps的目的是把一个项目的启动、设计、开发、质量测试、安全检查、部署等流程完全标准化、自动化、流程化，让运维、开发、项目管理人员紧密配合、无缝衔接，最终实现端到端的应用交付。这是当前运维领域比较流行的概念。运维人员必须理解、认识和接受这一点，将自己从一个纯粹的运维者转变为一个运维开发者。也就是说，未来的运维人员不会像消防队一样每天解决问题；相反，他们将构建和维护一个平台来执行项目管理、持续集成和持续部署、自动化质量测试等任务。

3 未来运维展望

运维的未来是什么？事实上，DevOps的出现给了大家一个很好的启示。未来运维一定要在DevOps的基础上继续下去。

3.1 人才方向——SRE转型

传统Ops模式的主要问题是过于关注如何解决常规和紧急问题，而不是找到根本原因并减少紧急事件的数量。

SRE是Google提出的运维工程师的概念，是一套方法论体系。全称是站点可靠性工程师。一个SRE工程师基本上需要掌握很多知识：算法、数据结构、编程能力、网络编程、分布式系统、可扩展架构、故障排除。这些是我上面给大家提供的技术选型和学习路径。

SRE工程师必须做以下四件事：

3.1.1 拥抱风险

识别风险，利用SLI/SLO对其进行评估、衡量和量化，最终达到消除风险的目的。

3.1.2 质量目标

一般来说，你可能会认为，如果没有故障，那就很正常，一切都会好起来的。 SRE需要明确定义SLI和SLO，并定量分析某项服务的质量。监控系统是SRE团队监控服务质量和可用性的主要手段。通过设立这样的指标，我们可以量化质量，让我们有能力PK业务研发，也可以和老板对话，获得更大的话语权。

3.1.3 减少琐事

SRE理念强调50%左右的时间用于工程研发，剩余50%的时间用于资源准备、变更、部署、查看等日常运维以及处理监控、紧急事务处理、事后总结等应急响应工作。如果一个屏幕上有十几个窗口，并且通过各种方式刷新屏幕，但问题还没有完全解决，那么你需要使用更好的方式——自动化的、系统的、基于工具的方式，甚至一种自主的方式来处理这些问题。 “琐事”。

这里对传统的运维思维也有一些挑战，因为我们每天做最多的工作在SRE中被定义为低价值的琐事。运维不是操作。 “运维”是一个工作内容，无论是手工还是软件。这是可以做到的。

在Google，SRE被要求具备开发自动化工具的能力，对各种技术进行研究，使用自动化软件完成运维工作，并使用软件制定和管理合理的SLI/SLO。

3.1.4 工程研发

我个人对工程研发工作的理解包括三个方面：

一个。推动产品研发改进架构，经常与研发讨论架构、集群、性能问题。

b.引入新的运维技术，必须持有基础组件，比如TSDB、Bosun、Consul、Zipkin等。

c.自主研发的工程技术、平台、工具、系统、基础组件、框架。

3.2 运维方向——AIOps之路

AIOps自2016年Gartner提出以来，已经成为运维的方向已有一段时间了，目前已在多家顶级互联网和电信公司落地，主要包括：精准智能报警、智能异常检测、智能趋势预测、智能决策等。故障处理。以下是智能故障处理功能的两个示例。

3.2.1 自愈功能

运维系统将与人工智能相结合，利用深度学习算法，使系统架构变得“聪明”，并实现自愈功能。比如现在在百度，如果有几台服务器宕机了，不需要立即更换。系统会自动判断出异常的服务器，然后通过算法避开这些服务器，然后尝试重启并重装系统。方法，自动尝试恢复这些服务器，恢复后可以自动加入集群。

3.2.2 自动工单