马哥金牌分享 | 三疯:从应用运维到Devops你只差一点点》

大家好,我是今天主播的“主播” — 三疯,今天由我来给大家做《从应用运维到Devops你只差一点点》分享,希望期间大家保持安静,有问题我们在分享结束后统一有Q&A环节,Let’s begin。

个人简介:

我是马哥教育的三疯老师,之所以取名“三疯”,是因为“三疯”有着独特的含义,也算是激励自己趁着年轻“疯狂一把”

* “疯狂”的学习

* “疯狂”的总结

* “疯狂”的提升,所以“三疯”又蕴含着“野蛮生长”。

年轻人要对自己狠点,如果你按照平常的步伐就输了。本人7年Linux一线经验,历任我图网,百胜,阿里巴巴开发运维相关工作,目前主要负责移动互联网技术及运维平台开发;

个人对于自动化运维、Linux系统架构、MySQL数据库管理、集群、缓存系统、移动互联网技术、电商业务架构、运维体系建设略有研究,能独立运维的开发,会写点代码的运维。

上图是我今天分享的主要内容。

这六部分其实也是一个运维人员逐步转为运维开发的过程,最后通过一定的方式来践行DevOps,DevOps大家都不陌生了,这几年一直比较火热,其实对于DevOps一出来,大家都最直观的感觉是“开发&运维”综合体,其实从我个人理解他更像一种文化。

任何概念和事物的出现都有其背后的含义。

举个简单例子:

- 四流的企业卖苦力;

- 三流的企业卖产品;

- 二流的企业卖品牌;

- 一流的企业卖标准;

而DevOps出来其实只是出了个标准,然后各家公司借助这个概念在自己内部公司实现,这也和Java里面的接口和实现关系。很多公司也在极力的去追随,尤其是一些小公司连CI/CD都还未解决的,就在往概念上靠拢,其实是有些为时过早,甚至不切实际,而对于中等以上规模的公司他其实是一项新挑战,毕竟对于运维来说,他们的痛苦也只有自己知道,他们也需要自我救赎,即使你找个没干过运维的开发来,虽然能短暂的解决运维的痛,但是长久的苦还需要运维自己去吞咽。当然开发也是一样,他们也必须知道运维体系,毕竟在一个有着道德底线的社会时代,还是要“有娘生就要养”的。

好的,接下来开始正式的分享,回顾一下我们做应用运维的都干了点什么?时间都花费在什么地方?自己在这些地方又有哪些成长?未来你去下一家又有哪些东西可以让你在日益竞争激烈的社会中获得更多的机会。

这张PPT上的我相信大家都做过,而且还不止一次的做,基本上大部分时间都消耗在这上面,因为这部分算是运维日常工作中最占时间的部分,有些人甚至70-90%的时间都在这上面,然而这些事情对你自己来说又有什么成长呢?这也是很多做运维时间长的会觉得没有成就感,甚至认为没有价值的地方,这也就给运维带来了很多痛苦。

从图中可以看到其实时间被打断,半夜还在处理故障,个人的收获有哪些呢?

- 机械重复

- 繁琐无趣

- 没时间学习

- 没时间陪女票,甚至没时间找女票

- 没时间休息

- 没有成就感

ROI太低,那如何摆脱现状,寻求新的突破呢?

对于传统运维来说,他更像是照顾研发开发产物的线上维护的“后妈”,原本是谁生谁养,但是规模变大后就有了专人维护,对于这个“后妈”,他养活的可不只是一个两个小孩,而是一群,甚至几百上千的,要想管理好他们怎么办呢?所以运维不能算是一个工种,他应该算是一种立足线上规范、稳定,而以一种新的方式来驱动研发,提高研发效率,业务发展速度的“助推剂”

发个小图调侃一下。

设想:如果你负责的东西没有一个规范,没有约束,十条业务线都难管理,所以这里就显得运维制度,规范化,自动化,标准化的重要性了,很多小公司没有标准化,因为他们没有遇到海量运维的场景,随便一个应用几千台服务器,如果还停留在单台维护的阶段,那基本上没得玩,毕竟2%的宕机率也够你好好的“喝一壶了”,所以个人理解运维应该具备“四像两学”的能力。“四像两学”是什么?

“四像两学”

* 像PD一样指导开发

*运维不是一个工种,而是一种文化,他是照顾线上业务的“后妈”

*既然要批量照顾,就要彻头彻尾的按照运维的规范来,否则自己养。

* 像运营一样数据化运维

*关注线上核心数据指标和链路依赖关系

* 像PM一样统筹全局

*关注稳定性,容量,成本,效率,性能

* 像商人一样“贩卖”技术能力

*技术服务化,产品化

* 学会懒人思想去自动化

*运维从机器启动开始就已经不需要人为介入

* 学会庸人模式去规范化

* 简单即是美,简单反而更容易管理

简单来说应该把运维日常的能力综合起来,并能对外提供服务,那么除了日常运维工作,还有哪些是运维需要经常去做的呢?

大家先看半分钟上图,然后结合自己的工作看看自己实际情况。我将稍后分享我个人体会。

好了,我们继续,与其说运维是一个工种,倒不如说运维是一种文化,而这种文化其实贯穿着整个线上服务运行甚至运营周期,比如:故障梳理和日常自动化这算是运维基本必备能力,当然这背后不只是运维经验的沉淀,还需要借助工具平台来支撑。再比如对于业务梳理、资源成本、应用稳定,这部分算是一名高级运维必备技能,如果想做好一名应用运维,这部分是必不可少的,毕竟在这个过程中才能逼迫一名普通的系统运维熟悉整个业务流程和服务稳定性;对于服务化、数据化运营,这部分就要求我们具有全局意识,并能结合我们负责的业务提供必要的产品改进支撑,做到数据驱动运维,数据驱动业务,数据驱动产品。当然从运维角度来讲,终极目标是:“运筹维幄,决胜千里”。

好了,这些是我对运维的理解,接下来我将选择几个主要的关键点详细说明一下。

首先,梳理业务:把负责的业务想象成一个人,那么硬件就是支撑起这个人的骨架,网络就是血管,各个应用就是人身上的各种器官,各个器官间存在着某种联系,只有各个器官都工作的正常,人才会健康,业务的整体结构也一样,各个系统间存在千丝万缕的联系,理清各个系统间的关系,这个是运维最重要的事情,也是很多工作的前提,并且这个工作开发做起来很麻烦,大部分的开发只是了解自己编写的部分而没有一个系统的概念。

其次,故障处理:解决线上的问题首先是要了解业务逻辑,如果线上业务不熟悉,你的监控覆盖率就更难提高,进而故障发现率也很低,解决线上问题根本无从下手。那么运维面对故障该怎么做呢?

1、运维思路转变:由出问题了找报警 转变为 任何一个报警都会出什么问题。

2、功夫在平时:平时多思考每个报警的意义和想象着可能出现什么问题?出问题了怎么解决。

3、必要的业务日志是否完善?

解决故障的能力是一项基本的必备能力,其中有自己的套路和方法,我们之前的公开课也做过分享,这边就不再累赘了,后期大家感兴趣的话可以再做分享。

然后,自动化和服务产品化:技术能力的输出需要有服务平台产生,这样一方面能借助平台规范操作,规范平台架构,甚至定义标准,另一方面自动化的前提是先标准化,所以标准的规则定义其实是由运维来主导的,这也对运维提出了新的挑战,毕竟未来“养娃”的活要靠自己,你想怎么带就要先制定标准。

最后,稳定和性能优化:这部分其实主要发力点在强弱依赖,容灾方案,降级方案,限流,业务解耦,监控完善方面,很多同学找到我然我帮看简历,写了很多关于性能优化的东西,简单的描述了几个参数就觉得是优化了,其实不然,优化遵循:监控—>分析—>优化—>监控,整个是一个闭环,你的任何变动都是需要有数据支撑的,否则谈优化那就有点牵强了。

由此可见,随着工具平台,自动化,包括现在比较火热的DevOps概念的发展,甚至包括AIops的发展,传统运维的发展道路越来越受限,当然很多人也借助DevOps去做一些事情,毕竟“站在互联网的风口上,猪也能飞起来”嘛,所以瞅准时机,紧跟潮流,并能果断涉足进去也不至于英雄末路,中道崩殂,如果有机会还是去做一次转型,毕竟运维经验是单纯的开发不可替代的。

既然提到单纯的开发,那我们来看看单纯的开发他们究竟在做什么?

- 方案

- 代码

- 改BUG

- 优化

其实开发来说更关注业务的发展,而如果让一个业务开发来写运维平台,工具平台写出来通常会有两种情况:

一、自我感觉是这么回事,但是实际操作不太像样;

二、不懂运维的整体操作流程,写的工具平台不符合运维使用习惯,最终被吐槽,然后运维还是回到最原始的方式,打开Terminal,shell脚本处理。

鉴于以上的情况,一个运维平台必然是具备运维,研发能力的人去承担,而不是单一方面的人去处理,自然运维做运维开发貌似成了顺理成章的事情了,那这时候就需要我们运维同学去跨界学习一项新的技能—“研发能力”。

对于一门语言的学习,这里我就不再累赘,毕竟“程序=算法+数据结构”这个大家都知道,数据结构通常指表结构,对象等,而算法也通常是指业务处理流程,对于运维平台的业务处理流程,其实更多的是运维的经验流程化。所以,对于新学开发的运维同学来讲,通常看看基础语法和一个简单的web框架其实就可以去写起来了。

这时就有很多同学开始问:我究竟学什么语言呢?什么语言更适合运维入门呢?

每一门语言入门都不难,语言类的学习,其实就是基础语法+后期多练习,很多同学写Python,Java,Go,Ruby这些后端语言学习的知识点都差不多,当然还有一些像BootStrap,React,VUE.js,AngularJS前端框架语言等,虽然前端的东西比较多,但是认真对比其实可以和后端一起通学的。不管哪门语言,只要即刻着手,写起来,不要等到需要了你才现学,时间不我待,抓紧时间。

好了,鉴于开发学习方法各异,我就不在此过多描述,如果后期有关于开发学习理论的需要,可以再做分享,那我们今天最后一个主题是DevOps的赋能,究竟什么是DevOps呢?

大家有了解java的同学都知道接口和实现的关系,DevOps就相当于接口,然后各家公司根据自己的情况去实现,实现的过程和方式其实是不同的,比如说对于一些连CI/CD都没有的,也想去借助DevOps去建立运维流程,其实是有一些盲目的,毕竟未来是没有单纯的运维和单纯的开发,有的是这两者的结合,运维的对开发的支撑方式由原来的手工支持编程了平台能力支持,开发由原来委托式维护变成借助现有的运维工具平台去自助运维。

如果说对于DevOps赋能,其实从我个人角度来讲前期模式就是“运维会开发,开发会运维”,这是所有的先决条件,当然两个角色侧重方向不一样,对于开发来讲能把基础的操作搞明白,比如简单的shell,常用的服务,知道DNS,LVS,Nginx等的管理和维护,而对于运维来说就需要懂开发,懂产品,懂交互,懂设计,当然如果懂一点用户体验就更好了。

DevOps终极目标其实就是他的实践,提高综合能力,打破职业边界,让公司技术迭代的速度更快,当然也能让自己的人生更有价值。“挣钱是你追着钱跑,值钱是钱追着你跑”,所以不管什么概念出来,建议大家透过现象去看本质,趁着年轻去拿到该拿到的东西,每个人的时间都是一样的,但是时间利用率就取决于自己,如果要个DevOps附能的话,我觉得两个维度:

* 个人维度:时刻保持激情提升自己的技能,对新生事物的保持好奇并坚持学习。

* 公司维度:把运维的技能产品化并服务化的方式提供出来,让运维的文化普及到公司,让每个研发同学都有自我运维的意识。


原文发布于微信公众号 - 马哥Linux运维(magedu-Linux)

原文发表时间:2017-09-02

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏罗超频道

微信,3亿用户之后的默然演进

笔者之前的一篇文章《2012年互联网十大滥用》曾经说过微信的未来在2012年被评论家说太多了。但随着1月21日将发布的微信4.5版测试包的爆出的——新增...

335110
来自专栏DevOps时代的专栏

浅谈海量平台的质量管理

47030
来自专栏爱原型爱设计

专访杨翰深先生 | Mockplus企业版为什么能获得贵州银行的青睐?

2017年里,Mockplus推出了全新的3.2版本可谓是匠心独运诚意满满,举办了国内首届原型设计大赛也不失为一场开拓创新。然而最让广大用户出乎意料的,想必定是...

429170
来自专栏速成应用小程序

微信小程序开发门槛这么低,你还在犹豫吗?

从 2017 年 1 月 9 日正式开放算起,小程序上线也不过一年多,而在这短短的时间里,它已经发展出了较为完整的生态,月活用户数超过 3 亿,上线的小程序达 ...

494130
来自专栏Thinks

用户体验杂谈(1)

最近三年一直服务于一个商业产品——腾讯云的用户体验工作。前2年是专门负责UI开发团队,最近1年半负责平台、建站、计费、运营、渠道的用户体验设计团队。这几年中有一...

7510
来自专栏CSDN技术头条

推荐系统正成为所有领域的一种标配

近段时间团队在扩建算法小组,首当其冲的岗位就是推荐算法工程师,然而历经一、两个月的招聘后,却发现一个事实,推荐算法工程师太难招了。

10930
来自专栏华章科技

《阿里巴巴全域数据建设》(实录/PPT干货)

近日,在2017杭州•云栖大会-阿里大数据分论坛上,阿里巴巴数据技术及产品部高级技术专家张磊发表了主题为《阿里巴巴全域数据建设》的演讲,分享了阿里在大数据领域沉...

1.8K30
来自专栏大数据文摘

面向产品经理的十款最佳分析工具

22940
来自专栏EAWorld

DevOps是MindSet:工具也好,文化也罢,人员才是关键

任何变革都需要时间,DevOps亦然。在经过数年的蛰伏期之后,DevOps终于成为了业界聚焦点;不过,从知其然到知其所以然,再到最终完美实现DevOps,依然前...

344130
来自专栏云计算D1net

不要仅仅将云计算当成一项技术

现代企业数据中心对云计算基础设施的采用,为CIO们提供了一个机会,挪动悬在头上的几把利剑与最经常被引用(而往往成绩不佳)的IT目标:更短的新产品上市与服务时间,...

33960

扫码关注云+社区

领取腾讯云代金券