自动化运维时代，运维失去价值了吗？
最近一直在思考，大家又谈到运维苦逼，没有成就感的事情，也促使我更加的想表达一下运维价值方面的东西。
首先，之前所讲的专题是在运维自动化专场，后来一些交流下来，我们共同的感觉是，听众们都特别的关注运维自动化，恰恰说明了我们现在运维的现状是：有太多的公司还没有自动化或者自动化程度很低，还没有找到明确的自动化的方向和思路，所以大家才会有这样的需求。回想起会后，也有很多的同学联系到我，说没想到运维还可以做这么多的事情，能不能让我给点建议，运维应该怎么做起等等，也印证了这一点。那问题到底出在哪儿了？
这里先不谈运维自动化的问题，想先表达两个观点：
1、运维，不仅仅是自动化，还有很多方向值得我们发力;
2、运维，技术不是问题，重要的是思路上的转变。
第一个观点，运维，不仅仅是自动化，还有很多方向值得我们发力。
前两天在运维群里，针对运维价值应该怎么呈现，我们的机会在哪里，表达了一下自己的观点，大致意思是：一个公司对于开发这个角色的诉求，永远是怎么能更多更快的把业务需求和功能实现，并尽快发布到线上，从而让业务能够实现快速的流量引入和变现。如果一个公司的开发都跑去关注怎么提升资源分配的效率，怎么提升发布效率、怎么提升线上稳定性、安全，还要额外去考虑下成本问题，这本身就已经脱离了一个公司对开发的诉求。那这个时候暴露出来的，效率、稳定、安全、成本等等问题，谁来解决？
刚才已经提到，开发同学应该不是这些问题解决的主体，那一个技术团队，还有哪些角色适合？测试 or 项目经理 or运维 or XXX角色，貌似看来看去只有运维最合适，因为运维离线上业务最近，对线上的情况是最熟悉的，其他任何一个角色都很难从端到端的视角是看待这些问题，即使看到了，也很难能够有效（关键是很难有精力）的落地。所以这个时候，我觉得这些问题的解决就是运维同学的机会，而不要把他当成负担。
从技术团队和老板的角度来讲，对开发就是期望尽量多尽量快的完成需求开发，而对运维，可能很难提出明确的期望和要求，但并不意味着没有。那到底是什么呢？实际就是上面（效率、稳定、成本、安全和体验）这些隐性的期望，往往可能没有很显性地表达出来，运维自己又不能很好的领悟到这些事情的重要性时，一旦出现问题或线上故障，老板发现我们没有很好的达到以上期望，一腔的怒火就很容易就发泄到运维同学这里了。再进而，运维就越发的感觉到自己是背锅侠，越来越没有成就感。
所以，正着看，这些事情运维来做最合适，反着看，这些就是老板对我们的期望啊。正反我们都不跑不掉，那就不如主动做好。
最近朋友圈转的文章《不做伪工作者》，文章最主要表达的一个观点就是：要做对公司和业务最有价值的事情。运维确实做了很多事情（忙成狗），应急处理了很多线上故障（操着卖白粉的心），重大的变更必须放到凌晨操作（起的比鸡早，睡得比猪晚），真的是非常非常辛苦，但是这些事情真正创造了多少价值呢？可能这就需要我们好好思考一下了，这里我并不是否定我们运维在做的事情，这些事情说没法避免，肯定是要有人来做，由运维做也是应该的，但是我们千千万万不要陷在这些事情里面，自我感觉良好，自我认为做了很多苦劳的事情，就把这种状态当做常态了，如果是这个思路就是我们的问题了。我们得要寻求改变，往往这个改变的过程和结果，就是价值呈现的时候了。
通过以上可以看到，自动化只是一个技术手段而已，重要的是我们得要找到方向。下面是我总结的效率、稳定、安全、成本和体验的一些事情，这些跟GOPS上很多专题都相关，也说明运维可以有很多的方向去发展，期望对大家有用。
这块跟日常的运维例行工作紧密相关，如资源分配&回收、域名配置、VIP配置、持续集成&发布、应用部署、应用扩容&缩容等，这块是运维最基础的工作，通常提到的运维自动化，大多是集中在这些工作上，因为这些工作偏日常和重复，目前业界的自动化的解决方案也非常完善了，所以可以优先把这些问题解决掉，目标就是解放运维的生产力，提升运维效率，降低人为失误，让运维的同学可以有更多的精力去做更有价值的事情。
让业务运行更加稳定，监控、全链路、强弱依赖、限流降级、容量评估、预案平台等，这块需要有相对比较独立和专业的监控和稳定性平台来支持，目标是最大程度的保障系统的稳定和运行质量，即使出现问题，也能够快速发现、快速响应、快速（自动）恢复。
安全是与运维同等级别的一块专业领域，但同时又是跟运维紧密相关的，运维同样要关注安全，因为安全出现导致的问题，往往也会给运维带来沉重地防护和修复成本。我们经常提到的，各类主机安全、DB安全、Web安全、应用安全等等，与此相关的还有漏洞、DDos、CC等关键词。
这里提到的体验，指的是终端用户的访问体验，非功能或产品使用体验，对于运维来说就是要关注访问速度。作为开发的同学来讲，可能更多的注意力会放在自己负责的代码以及该部分的性能问题，不会关注到端到端全流程的性能和体验。但是运维可以站在全局的角度来审视和治理整个端到端全链路的性能情况，并给出对应的性能优化建议。
成本问题，也就是技术ROI（投入产出比）的问题，当系统规模和体量变大之后，掌控在运维手中的各类资源，将占整个研发团队支出的大头。如果没有很好的成本控制意识和策略，资源体量将会持续增大，甚至是翻倍或指数级的增长，对于公司成本会是非常大的负担和压力。
第二个观点，现在对运维来说技术不是问题，重要的是思路上的转变。
现在各种业务跟中开源工具，比如自动化的puppet、ansible、chef等，监控有nagios、zabbix、cacti等，虚拟化有kvm，openstack，以及等等各种开源技术，各类商业的软件也同样百花齐放，可供选择的余地非常大。所以，我觉得运维在技术上不是障碍。即使你觉得哪些工具不好使，你做一个比这些工具更牛逼的出来也可以，编程语言python、php、perl，也不是太难上手。
不过问题又来了，这些技术怎么用起来呢？真是个头疼的问题，说实话我也不知道该怎么用起来。但是如果一定要我来回答，我会先问这么几个问题：
a、你的技术团队现在存在的最大或者最让人头疼的TOP的问题是什么（3或5个都可以）？
b、这些问题哪些你认为是运维应该也可以解决的？
c、如果你认为有应该是运维解决的，那你觉得解决这个问题，应该采用什么样的方案？至少给出两个2备选
d、分别从方案的优劣和成本上评估那个方案最佳
e、到了这个问题上，貌似用什么技术已经不是问题了吧
回到运维自动化建设上，不要抛开实际问题和场景谈技术，这样的技术方案是没有意义的。一定是从问题和业务的角度出发，找到痛点所在，用合理的技术解决掉，而不是把技术强加到业务上，让业务来适配技术，这样出发点就错了，我聊下来，返现现在有太多的同学和团队都是因为这个问题跑偏掉了。比如，我举一个大家经常听到或见到的一类经验：《秒级启动（扩容）千台（万台）机器（容器）》，我试问一下，有几个公司是需要这种业务场景的？如果真的需要这种业务场景，是性能不行，得用机器来扛得吗，不做优化早干嘛去了？如果真的并发太高了，请问下，前面交换机、路由器和防火墙要不要也秒级扩容下？加了这么多机器，后面的DB扛得住不，是不是也得秒级扩容下?这千台万台的成本好像有点高吧，老板同意这么多的预算做buffer？
所以，单纯谈技术，是没有意义的，做事方法的思路上一定要转变过来。
就我个人来讲，刚接触互联网运维（之前是传统电信级业务的运维）时，一开始我连CMDB是个啥都搞不清楚，就互联网运维来说是个门外汉。但是我到新公司后，一直到现在都在做的事情，就是不断的跟开发和业务团队去沟通，你们有什么问题？痛点在哪里？然后不断的思考，问题背后的原因是什么？我们应该怎么解决？业界是怎么解决的？什么样的方案最适合我们？这些问题想清楚了，讨论清楚了，该做什么也就清晰了，这也是我在GOPS大会上分享的从0到1的内容，其实我们已经做了很多从1到100更有价值的事情。现在我们的运维团队从来没有刻意的去证明过什么，但是我们仍然可以获得整个技术团队的尊重，我们的绩效也从不比别的团队差，也从来不会随意背锅，是我们没有做好的，就是我们没有做好，我们考虑更多的是下次怎么才能避免和解决，但不是我们的问题，我们也要有理有据的表达出来，为的是促进整个技术团队的进步和改进，而不是把精力耗费在撕逼扯皮上，运维就是应该要站在这样的高度上来贡献价值才对。
以上，根据我个人和团队一路走来的一些经验和心路历程，分享给大家，为运维这个行业贡献一份力量。
写在最后：
本文作者谦益，现在负责蘑菇街运维团队的管理以及运维体系的建设工作。在运维行业中已经做了7年，之前有过5年左右的业务开发经历。加入蘑菇街之前在华为一直做电信级业务的开发和运维工作。
作者：谦益
来源：http://www.yunweipai.com/archives/10755.html
云计算免费课程火热抢先中，5天运维课程免费听，点击文末“阅读原文”即可免费听课！当然也有其他IT课程免费听（Java、前端、大数据、Python、设计、C++、嵌入式、网络营销），后台回复“姓名+联系方式+所在+课程名称”也可申请其他免费课程，火速抢先~~~~
PS:记得查收小编送你的免费大礼包呦~
福利 | 一万多套PPT模板等你免费来拿！无条件领取！
免费送 | 1000多套简历模板免费拿，附赠简历制作教程！
免费领 | 《Shell脚本 100例》电子书免费拿，运维必备干货~
▼▼点击【阅读原文】，免费听5天Linux运维干货分享课，火热开讲中，速来抢！