大家好，我是今天主播的“主播” — 三疯，今天由我来给大家做《从应用运维到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框架其实就可以去写起来了。
