重磅：8位老兵匠心力作，这份运维转型攻略不容错过！
在云计算遍及业界的趋势下，以及 DevOps 和 SRE 等先进运维理念的强势助推，运维已然成为驱动各大公司研发运维流程和理念变革的关键角色，同时慢慢承担起了稳定性保障、流程效率改进、性能优化、用户体验提升以及成本控制等关键职责。
更高的要求必然带来新的机遇和挑战！但这个挑战究竟何等凶猛？如今，技术重要性不断下沉，运维人员新的核心竞争力何在？在趋势不可逆转的情况下，如何怎么做到华丽转身、完美逆袭？
今天，我们将锁定运维工程师这一工种，通过定向采访的形式，汇集青岛航空-战学超、平安科技-汪洋、唯品会-王喜春、轻维软件-宋辉、山东移动-朱祥磊、美团点评-雷雨、天天拍车-李强、58集团-龚诚共8位运维老兵的智慧结晶，解决当下运维同学们的迷思与困惑。
认真读完本文，你可以了解到：
一、技能篇
1、如何摆脱装系统、拉网线等传统运维工作？
2、运维人应该掌握的编程语言
3、如何考虑开源软件的技术选型？
4、优秀运维人应具有的职业素养和软技能
5、运维好书推荐
二、发展篇
1、运维能做到40岁吗？
2、运维架构师的技术发展路线
3、运维与开发、测试、业务，真是敌人么？
4、新技术冲击下运维的发展方向和未来
三、杂谈篇
1、运维人的骄傲有哪些？
2、运维人员如何避免背黑锅？
Q1：传统企业运维工程师如何摆脱装系统、拉网线等尴尬局面？
汪洋：我认为安装系统和拉网线都是必须的工作，总要有人去做。装系统尚可通过自动化实现，但布线这种物理层面的活儿就很难了。机房布线听似简单，实则不然，里面有很多讲究，也是需要技术和经验的。这个问题的提出可能更偏向于运维工程师如何不断地突破自己，而不致陷于琐碎工作的泥沼之中。
我觉得首先要有主动学习、积极思考的意识。作为运维工程师，在完成本职工作的同时，也需要了解自己负责领域技术的发展趋势以及市场的需求，这样才能先人一步。当前大环境很好，各个企业求贤若渴，各种技术层出不穷。但同时也对运维工程师提出了更高的要求，不能再靠经验吃老本，要有快速学习新技术的能力，因为你现在掌握的技术很有可能在3、5年之后就会在市场上衰退甚至消失。所以要敢于改变，并且快速学习，这个过程可能会痛苦，但只有这样，才能是你从容应对这个快速变化的市场，保持竞争力。
王喜春：前段时间和业界的同行做了一些交流，发现运维的焦虑不仅仅是一两个公司的事情，而是整个行业的事情，而焦虑的核心就是两个字——转型。那么，问题来了，传统运维工程师应该转型到哪里，其次，如果才能做到转型？
我个人觉得，传统运维转型的出路有三条：
1、涉足一些开发的领域，前置业务需求的切入，通过系统的搭建，完成一些自动化的工作，把部分的运维技能变成页面操作，进而交给测试或者研发人员使用；同时，用敏捷管理的模式管理运维项目，最终达到测试、研发、运维通过系统迭代来做语言沟通，这也是我们所说的DevOpser或者DevOps Master。
2、继续深挖运维的知识，在某一个领域成为专家，这条路的发展方向是基础架构师。这条路本质是纵向深度挖掘，要具备：开源组件的使用和二次开发能力，例如LVS、HA等，操作系统的裁剪能力、网络知识、架构知识等。
3、从技术运维转技术运营，这条路是运用大数据的技术，把与运维相关的数据。例如服务器的配置信息、网络质量信息、监控信息等收集起来，通过数据的整合，模型建立，找到运维层面的优化点和业务上的薄弱点，促使开发做一些优化和改进。举个例子，用户在网站上购买东西，在哪一个环节最容易放弃，放弃的原因是什么，是体验不好还是图片加载过慢，这些数据其实是运维最容易获取到的，也是最有价值的，做好这一部分，运维就会和公司的营收直接挂钩。
那么，如何才能做到上面三个转型呢？
1、公司的企业文化要支持，尤其是DevOps的转型，要在KPI和组织架构上都要有所体现。
2、个人思想要做转变，跳出舒适区，了解公司业务，向研发、测试取经，有大局观，理解且包容不同职群人员的差异。
3、提高个人自主学习能力，要学会至少一门开发语言，学会项目管理，多读一些开源代码，例如k8s等。
当然，做到这三点，也不一定就能转型成功，但不做这三点，则很难转型成功。
宋辉：传统企业运维工程师相比互联网企业的运维工程师，本质上工作内容没有太大的区别，有区别的是公司的管理模式和体制问题。如有些国企的体制比较僵化，以求稳定为第一要素，对于运维工作只要不出事就好，对于技术创新、管理提升等比较谨慎。装系统、拉网线这些其实代表在传统企业的运维基础工作，因为管理体制的问题，在这些企业重要的就是要保障系统稳定，所以先把基础的工作做好了再考虑运维价值化的呈现。对于基础性的工作，可以考虑通过构建一些工具平台，提升自动化、数据化的水平，提升重复工作的效率与质量，这样可以有更多的精力去学习或接受新的技能。如果你处在这样的岗位，就一定要想办法把自已解放出来，如果一直在做同样的事情，就算是30年的工作经验也没有价值。
我很认可的一个观点就是，要想办法把自己空出来，看看有多少工作是可以自动化的，有多少工作是可以教给新人去做的，然后去学习新的技能，接受新的挑战，积极主动承担。
战学超：首先要对自己的运维生涯有一个清晰的规划，是在桌面运维方面继续深研（包括虚拟桌面搭建与管理、机房、数据中心建设和维护等方向）深入研究还是向系统运维Linux、Web架构、DevOps等方向发展；确定好方向之后，进行计划的制定，这个可以参考或是咨询成熟的技术专家寻求帮助，制定适合自己的发展之路；有了方向，有了计划，接下来就是坚持和回顾。坚持学习，不断总结，总有一天会摆脱IT低级运维走向IT技术大拿的。
朱祥磊：一是运维工程师也要分级分层，建立类似一线、二线、三线的梯队机制，层级高的工程师更多关注疑难问题解决、技术演进、能力提升等，低层次的工作由相对层级低的工程师来处理，并建立梯队流动机制，从而激活运维工程师的活力。二是实际工作应该注重标准化能力提升，比如装系统、拉网线等工作，应该实现标准化，如自动化安装部署系统、标准化拉网线，使运维工程师尽量减少繁杂的工作。
雷雨：装系统、拉网线描述运维工作的辛苦和枯燥比较形象，但只能作为工作内容和对象来看待，实际上需要深入理解资源部署交付链条上的每个步骤，并努力去实现摆脱人工介入的自动化流程，有这样的目标驱动，就实现了运维向运维开发的转型；更进一步，你需要了解装系统的软环境，比如需要安装的服务器都有哪些硬件配置，不同的配置都有怎样的业务场景？不同的配置优缺点在哪里？现在业界主流配置是怎样的？对网络而言，你需要从拉网线成长为理解网络结构、能排插定位网络问题，进而能给出网络建设及优化方案的优秀架构师。
李强：我个人认为装系统、拉网线虽然是简单的事情，而且运维工程师避免不了，主要是运维人员要由意识如何使用技术手段来提高效率，比如利用PXE自动化安装系统、拉网线有没有标准，没有标准即使企业运维将装系统、拉网线的事交给IDC来做，也会出很多问题。所以我认为首先就是建立安装系统、网络布线的标准，例如按照应用的分类深度定制操作系统+PXE就可以批量快速地部署系统；网线需要规划好颜色、标签等防止拉线造成的一些尴尬。
Q2：运维人需要会编程语言么？建议哪个语言好？
汪洋：我一直觉得作为运维人员，精通一两种编程语言是必须的，可以让你在日常工作中事半功倍，同时在编程过程中可以进一步加强逻辑化思维，保持头脑的灵活性。还可以让你在解决特别是应用相关问题时能站在开发的角度思考问题，能够更快地定位问题，并提出更加合理的解决方案。这也符合当前DevOps的理念，开发和运维相互渗透，加快需求或者价值交付的速度，提升问题解决的时效。
从现在运维行业的趋势看来，通用的语言我觉得Python、Java、Shell这些都是需要掌握的。具体到运维的某一具体领域，会有更加具体的需求，例如如果你是做Oracle运维的，那么最好掌握PLSQL；如果你是做PostgreSQL运维的，最好掌握pg/plsql。
战学超：首先个人认为 34 44078 34 15288 0 0 1452 0 0:00:30 0:00:10 0:00:20 2875维一定要懂开发，其次对开发语言要有了解，不一定有多个项目的经验，但最起码的排错技能要具备，可以根据错误日志快速锁定错误根源，跟开发一起赢得解决问题的时间。现在这个年代，只会脚本，只会部署是远远不够的，只能算是初级运维，也一定要懂编程、懂开发，这样才能做自己想做的运维系统。
语言方面，主要推荐：Java和Python。二者都比较简单且易入门，而且社区和技术生态圈很丰富很活跃。熟悉Java主要是有助于了解开发，学习Python，为自动化运维、自己研发DevOps平台打下基础。
王喜春：个人建议是Python，这个语言介于脚本语言和编程语言之间，往下可以和Shell紧密结合，往上可以做大型的项目，学习成本也很低，贴近于自然语言。部署环境比较简单，性能和跨平台性都比较不错。
朱祥磊：编程语言也是一种运维利器，作为运维人，掌握1-2种运维语言是锦上添花也是非常有必要的事情，比如如果会用Python、SQL、Shell等语言，将会对实际运维工作带来很大的便利。举个例子，批量运维离不开一些脚本语言，如果脚本语言不好，对运维能力的提升的影响不言而喻。
雷雨：基本要求应该是Shell，更灵活的就用Python，这几年Go比较火，但是要讲究实用，能快速优雅地解决问题为原则，哪种语言并不重要。
龚诚：需要精通Shell语言，做一些运维系统的开发建议使用Python、PHP，如果涉及到后端服务可以使用Go。
李强：对于做基础架构的运维最起码要懂Shell，能够用Shell完成一些重复度较高的工作；对于平台运维或者开发运维，建议使用Python；对于想专注玩Nginx的运维，建议深入研究Lua。
Q3：运维人员应从哪几个方面考虑进行开源软件的技术选型？
汪洋：拿我个人的经验来说，有以下几点：
1、开源软件和现有技术架构的兼容度。也就是说，当从现有技术架构迁移或者转换到该开源软件时，是否相对容易，投入较小，风险较低。
2、根据当前团队所具备技能学习该开源软件的难易程度。从当前组织人员包括开发、运营和运维人员所具备的技术栈、技术能力来看，学习该开源软件的学习曲线会否很长？开源软件并不是免费的，这些都是学习使用开源软件所带来的成本开销，应该纳入企业的TCO或者OpEx计算之内；
3、开源软件的成熟度。该开源软件是否已经比较成熟，能够运行企业级应用，是否满足需求场景、开发人员的需要，是否有成熟的高可用架构、备份恢复能力，性能和管理功能是否满足运维需要，不会给生产稳定带来风险。
4、开源软件的生态圈。是否围绕该开源软件有比较丰富的生态，基于该开源软件是否有较丰富的插件和衍生工具可供灵活地选择。
5、开源软件社区的活跃度。该开源软件是否一直保持稳定的发布周期，核心开发团队是否稳定，相关的讨论社区是否一直保持很高的热度，在所属领域的排名是否靠前等。
6、开源软件的用户案例。使用该开源软件的客户或者企业是否呈多样化，是否有很好的成功采用案例可供参考。
王喜春：运维人员可以通过以下五个方面考虑开源的选型：
1、是否能hold住，hold住是指出了问题，能够快速恢复故障，本组或者本部门内是否有这方面的专家。
2、是否有大公司使用过，尤其是国内的大公司使用，因为国外的环境和我们差异比较大。
3、网上的资料或者社区是否完善，活跃度是否高，当出现问题的是否，是否有完善的经验。
4、迭代的版本是否频繁，如果过于频繁，那么升级运维成本比较高。
5、是否安全，这个要经过安全部门的扫描。
Q4：优秀的运维工程师应该具备哪些职业素质和软技能？
宋辉：这个问题应分开来看，运维这个行业有很多细化的岗位，比如有专门做设备级或基础维护的，如DBA、硬件维护、网络等，这类岗位专注于软硬件设备或基础平台的专业性和深度。也有做平台级维护的，负责维护横向的系统平台，还有应用级维护，负责应用级的横向维护。每个不同类型的岗位对技能的要求有些不一样，总体来说分为两个方向：一个是专业深度方向，就是专才，一个是通用广度方向，就是通才。这两个方向都没有什么问题，看个人兴趣。
运维是一个大家看来有些苦逼的行业，如果做得不好，经常会有突发事件，加班重复劳动较多，工作比较零碎，很难有做工程或产品的成就感，但实际上运维也是一个很有挑战性的行业，是另一种起死回生、妙手回春、一夫当关万夫莫开的成就与挑战。
对于职业素质的要求除了技术方面个人认为主要包括：
1、运维工作经常要处理各种复杂问题，需要有清晰的思路，能抽丝剥茧快速找到问题根源，有点福尔摩斯的感觉；
2、需要有较好的抗压能力，能沉着冷静分析处理问题，当一堆人站在你后面指望你能成为英雄的时候，手可不能抖；
3、熟悉系统环境和应用，熟悉平台的一些运行特性；
4、除了主专业的深度，要能扩充自已的知识面，最好能有一些开发技能，理解开发的思路；
5、做事有规范，小心谨慎是基本要求，操作前准备好操作方案，不能打无准备的仗；
6、有好的职业操守，尤其是对于敏感数据；
7、有比较好的沟通协调能力、表达能力，对于问题能说得清楚，推动得了；
8、对于软技能就看各人的岗位需求及环境，主要包括运维开发能力、业务能力、开发能力、项目管理能力、沟通协调能力、文档能力、学习能力等。
战学超：老生常谈的：责任心、学习能力、沟通能力不在赘述，个人觉得还应具备一下几个方面：
1、提问的技术，可以参考《提问的艺术》这本书，很受用。
2、邮件书写规范。
3、主动执行能力，对于与自己相关的工作积极主动的推动，避免自己这一环节成为瓶颈。
4、乐于分享勤于写。有的时候，想象很复杂的一个技术方案或是计算点，写一写，可能会很简单，同时自己收获也很大。
5、小抱怨，大宽容。运维总是一个背黑锅的行业，可以偶尔的小抱怨，释放一下内心的不快，但前提是不要给同事带来负能量。大宽容是指的坦然背锅，多多总结和分析。很多时候，主动承担下来的黑锅，经过总结和分析，终会给自己和领导、同事一个科学的说法。
李强：
1、运维首先应该是一个有良好职业操守的人且具备良好的沟通能力，尤其是书面沟通能力；
2、优秀的运维需要能够熟练使用鱼骨图、PDCA原则、任务分解法等一些常见的做事方法来要求自己的运维工作；
3、需要具备一定的项目管理能力，例如对一件任务的时间管理、文档管理等；
4、具备较强的学习、钻研能力，在应对一些新领域新技术的时候能够通过快速的学习能够让任务进行下去；
5、信息检索能力，大部分的运维英文水平较差，而且学习新东西的时候往往都是百度，用谷歌以及阅读官方文档的运维少之较少，即便是通过搜索引擎查找资料，也因为不能使用合适的检索词导致查不到需要的信息；
6、对于公司业务所涉及到的开源软件，需要达到熟练运用的程度。
龚诚：工作细致，善于思考，具备很强的分析和解决问题的能力；强烈的责任心，良好的沟通能力和协调能力，极强的业务推动能力，善于接受挑战。
Q5：有哪些运维的好书值得推荐？
战学超：好书比较多，这个简单举例吧：《SRE：Google运维解密》、《防线：企业Linux安全运维理念和实战》、《凤凰项目：一个it运维的传奇故事》。另外建议书籍、微信公众号、技术网站、技术分享会等多渠道获取知识，比如DBAplus社群，就非常不错。
李强：书籍，我首推官方电子文档，比如互联网公司大量使用CentOS，那么优先需要看的是Red Hat Enterprise Linux 6的所有文档，这里面几乎包含了市面上一些书籍的大部分内容。
纸质书籍：《亿级流量网站架构核心技术》、《Linux性能优化》、《Linux防火墙（第4版）》、《海量运维运营规划之道》、《精通Nginx(第2版)》、《高性能MySQL（第3版）》、《MySQL运维内参》。
王喜春：《第五项修炼》、《Google的SRE实践》《项目管理知识体系指南》等。
Q1：运维能做到四十岁吗？运维工程师怎样干到退休？
汪洋：当然可以，我就是一个很好的例子，40多了还在运维岗位上打拼，并且暂时没有转行或者退出的计划。任何事情只要你有兴趣，就能够让你一直坚持下去，成为你发展的动力，年龄不是问题。我们不是经常看到国外很多工程师已经白发苍苍，还在IT的各个技术岗位上奋斗吗？运维我相信也在其中。
但如何能够干到退休？那就要求我们能够活到老，学到老。运维相对来说是一个比较依赖经验的行当，你解决的问题越多，经历过的架构变迁越多，经验也就越丰富。下一次问题发生时，也就处理得更加得心应手。虽然现在技术更新很快，但我们多年来累计下来的经验，养成的习惯和意识，总结出来的方法论是历久弥新的。我们所需要的学习是当新的技术出现时，能够主动和快速学习。也许随着年龄的变化，在某些学习能力上不如年轻人，但我们的经验会弥补这些不足，能够帮助我们快速理解和领会。而这些经验不是一朝一夕就可以积累的，需要时间的沉淀。
王喜春：我对这个问题是持有悲观态度的，我认为，在不转型的前提下，绝大多数人都做不到40岁，因为在体能上无法和年轻人相比，在经验上，没有太多的独特价值，如果想到40岁还从事运维的工作，甚至做到退休，那么就要在身上具备有不可取代的地方，比如对运维的理解，比如成为某一个运维领域的专家。需知，新人的工作热情比你高，薪资又比你低。
雷雨：看个人心态，四十岁的普通运维工程师，如果是从毕业就干运维，那么成长和贡献应该是比较低的，不是不能做，但被接受程度比较低。有学习成长心态的运维工程师，干到退休也没问题。
战学超：这个不好说，因为我也没到四十岁呢。但是我觉得实时关注运维技术前沿，综合自身技术水平和企业实际情况，不断将先进的运维技术应用到公司中，不断优化运维方法，提高运维水平，为公司节约成本，提高IT系统品质，干到退休应该问题不大。
IT自主创业也是一个不错的路子，但是本人没做过，不好说。在企业干运维到退休，一定得注意能够给企业创造价值，这样企业才会用你到退休。这个话题比较沉重啊。
李强：我认为运维可以做到四十岁，尤其是现在大多数运维心态都比较浮躁的现状下，有追求的运维完全可以做到四十岁，往资深的方向做。至于做到退休，我不认为做运维可以做到退休。
朱祥磊：运维完全能做到四十岁，刚才问题中提到过，运维人员需要分层分级，层级越高、经验越丰富的运维工程师，一般都是年龄较大，对运维工作做了很多年的耕耘，实际运维需要这样的人员。但是并不意味着可以吃老本，因为新技术层出不穷，老的运维工程师也需要不断研究新技术，掌握新东西，不然就会被淘汰。
Q2：对于运维架构师，你有什么推荐的技术发展路线？
宋辉：运维架构师是最近提出来的一个概念，更准确一点的理解就是能对IT软硬件系统平台、云计算、网络等进行整个规划与架构、平台设计，跟系统架构师类似，是运维工程师在技术领域发展的比较高层次的目标，要求具有丰富的实际维护经验，熟悉各种产品、技术的特性，熟悉应用特点，对海量数据处理、高并发等有丰富的经验。
对于如何才能成长为一名运维架构师，个人的建议是这样的：先专、再通、再上、后积，这么几个阶段。首先需要在个人这个专业领域做到专业和深入，做好本职工作是大前提，加深对于产品或系统的理解。然后开始涉猎平台体系架构，理解数据库、中间件、虚拟化、网络等各种专业技能，提高知识的广度。然后深入了解业务规则、应用特点，通过项目积累经验与能力。这样才能真正走到运维架构师的高度。其中对于主动学习、主动承担的要求是很高的。岗位的提升需要机会，但机会往往都只会留给有准备的人。
战学超：运维架构师或是系统架构师是一个杂而全的技术工作，我觉得可以延伸一下：Web系统相关的分布式系统架构；以数据中心为核心的数据中心架构；以数据库为核心的数据库架构、数据平台建设架构相关；私有云、容器等云技术相关架构；以ITIL、DevOps、AIOps为核心的运维管理体系等方面，我觉得都是运维架构可以发展的。当然前提是要对运维的基础（Linux、网络、机房、数据库）等基础知识有一定的了解。
王喜春：首先，先从传统的运维做起，了解运维各个方面的知识。其次，熟悉公司的业务，尤其是自己负责运维的业务。再次，参与业务的架构评审，在架构里提出运维的一些意见。再再次，选择某一个领域成为专家，比如云、操作系统、负载均衡等，形成钉耙的知识结构。最后，参与一些重要的项目的设计，在实践中打磨。
朱祥磊：有几个方向，一是从平台运维维度，可以从关注IaaS层运维（计算、存储、网络等）到关注PaaS（软件、服务）、SaaS（业务），二是从专业角度，可以关注服务器、数据库、大数据、缓存等各类技术组件，三是增值维度，如从应用性能分析、网络性能分析、客户体验分析等维度发展自己的技术路线。
李强：我觉得运维架构师，要么向DevOps的方向发展，要么就向基础架构这块发展，当然基础架构其实是更复杂的东西，要求运维架构师能够跟进现代数据中心的DCI技术、网络虚拟化技术、要熟悉硬件、要深入掌握现在常见的开源软件应用。
Q3：运维人员应如何平衡与开发、测试以及业务部门的关系？
王喜春：运维和开发、测试等的关系无外乎三种：第一，从属；第二，合作；第三，主导。我觉得比较健康的方式是合作的模式。能达到这个模式的基础是，大家的目标是一致的，都是想项目的收益最大。基于这个前提，开发或者测试在向运维提需求时，运维考虑的就是这样做是否对公司的业务有好处，而不是单单考虑风险。当然，公司的定责文化对于三者的关系是有一个积极或者消极的作用的。
宋辉：个人觉得这个问题要看各个企业的管理风格，有横向管理，有纵向管理，有的是按产品线分，业务、开发、测试、运维在同一个大部门，再按职能分小部门。有的是按业务、开发、测试、运维等职能分大部门、再按产品分小部门。
从组织效率上来讲，各有优劣势。但对运维来讲，基本上都需要跟各个部门打交道，很多人都认为运维就是一个背锅的部门，但实际上并不是这样，要平衡好与其它部门的关系，就需要把运维对其它部门的价值能发挥起来，让其它部门能感受到运维对于他们的帮助，如DBA可以帮助开发完善SQL的开发规范，与业务部门共同制定并完成业务保障目标，帮忙在测试阶段协助分析性能瓶颈等，总而言之就是要把运维的工作前移到业务、开发、测试阶段，体现运维的价值，提升运维部门的话语权。
战学超：重要的是主动沟通。运维作为与生产系统最近的工种，主要保障生产系统的稳定高效，但生产系统往往又不是运维提供的，很多时候开发更熟悉。这个时候，运维需要主动沟通开发和测试，对系统的功能、系统的重要程度、系统间的依赖和部署方式深入了解，这样才能更好的保障。生产出现故障，运维首先要做的是主动背锅，主动调查问题，主动联合开发、测试和业务部门一起排查问题，降低故障面前的争吵，共同处理问题。问题解决后，主动进行总结和分析，寻找根源，避免再犯。
积极配合开发、测试按照规范搭建各种环境，和进行各种问题的调查。配合开发、测试，配合业务部门，做生产环境的代言人。共同指的是与开发、测试和业务部门建立共同的目标，系统安全稳定和高效。为这个共同的目标而不断努力。
朱祥磊：我觉得运维工作应该前移，而不是事后被动维护。需求开发阶段，参与进行技术组件选型、业务量容量评估等，开发阶段关注压力测试结果，上线后关注运维和优化。运维很多工作也和业务相关，例如很多优化和业务流程、业务规则关系很大，通过优化业务规则可获得通过技术优化难以获得的优化效果，减少运维人员的工作难度。
李强：第一，运维需要扭转在这几个部门之间的劣势，在制定一些规则的时候测试、开发以及业务部门需要优先考虑运维的意见，必要的时候运维需要表现出强势（当然这个需要CTO或者技术VP/总监的大力支持才行），在我们公司一些新技术的上线、业务的上线是由运维来主导的，如果运维认为上线的东西有问题是可以驳回的，原因很简单，出了问题测试、开发及业务部门承担不起责任。
第二，一些重要事件，不能口头沟通就完事，一定要发正式邮件以书面的方式通知到相关部门负责人，邮件内容一定要书面化，切忌口语化表述。
Q4：在DevOps、AIOps、容器化、私有云、大数据等技术的冲击下，未来运维的主要发展方向有哪些？有什么IT技能需求和技术发展路线？
汪洋：这个题目太大了，正如前面所说，运维其实包含了众多领域，每一个领域都有自己的技术组成、发展趋势和路线。拿我所从事的数据库运维领域来讲，当前在市场上就存在几百种不同的数据库引擎。有RDBMS、IMDB、Key-Value、Document DB、Graph DB、Time Series DB、MPP等等不同的分类。如何选择，一方面是要看市场发展的趋势，另一方面是自己的工作环境中能够应用到的，还有就是适合自己或者自己有兴趣的产品。一般来说，我们所在的企业或者部门已经会根据市场趋势来制定3-5年的发展路线图，我们可以按照这个路线图来制定适合自己的发展路线，这样的好处是学以致用。运维是一项实践性很高的工作，如果没有环境让你去练习，让你去实际应用，很难取得进步。
从通用的运维角度来说，我认为AIOps也就是智能化运维是大有前途的。如何更加智能地对自己所在领域的技术运维进行管理，降低运维成本，提高单位产能，提前发现隐患，提升系统稳定性，这些都是很有意思的课题。而过去，我们并没有很好地利用这些运维过程中产生的大数据，还基本停留在被动的响应模式。
战学超：未来运维的主要发展方向，个人认为也正如问题所述：Devops、AIOps、智能运维、容器化、私有云混合云等发展方向。目前AIOps智能化运维更多的是借助大数据手段，结合科学算法优化运维，提高效率。个人观点，基础还是最重要的，即运维基础知识。在运维基础知识的基础上，结合公司实际情况有选择地调研流行的运维技术，为公司实现最大化的收益。
王喜春：未来运维的发展方向就是从技术运维转向技术运营，从成本部门转成利润部门，需要的IT技能很多，如果其中最重要的，就是数学知识和能够阅读论文的能力。
李强：个人认为运维人首先要确定自己想做平台运维还是基础架构运维，做平台运维要向DevOps/AIOps/大数据发展，而基础架构运维建议往容器化、私有云方向发展。
Q1：运维人的骄傲有哪些？
汪洋：作为运维人，骄傲有很多。每一次解决了生产系统中的一个异常复杂的问题，找到了问题的根因后，制定措施使得类似问题不会再次发生会感到成功感；每一次对系统进行了性能优化，使得响应时间降低几百甚至上千倍，吞吐量增加了几十倍之后会感到很骄傲；每一次将一个看似不可能完成的项目或者任务成功上线，并且得到领导认可的时候会感到很自豪。骄傲遍布在运维工作中的点点滴滴。
总的来说，运维人的骄傲来自于通过我们的努力，保障了系统的稳定、高效运行；降低了企业的OpEx；支撑了公司业务的高速发展。
王喜春：很认真想了想，运维人骄傲的事情真的不多，出故障时，会面临要你有什么用？不出故障时，还会面临要你有什么用？当然，运维人要创造自己的骄傲，我个人体验，就是一个人静静攻克故障和通过自己的努力，看到负责的应用QPS翻倍上涨。
李强：我认为对于运维人而言，晚上不加班，白天上班事少就是骄傲。当然，具体一些的话，值得骄傲的事情可能包括以下一些了：
1、成功处理了一次大规模的促销活动，系统平稳；
2、也可能是将运维基础架构进行了平滑升级；
3、也可能是通过一些技术手段发现了隐患为部门挣了一口气；
4、也可能是运维通过自己的努力让自己不在苦逼地加班了。
总之，让运维骄傲的事情还是挺多的。
战学超：运维人的骄傲恐怕更多的是系统安全稳定运行多久了吧？骄傲谈不上，只希望接下来的十一假期中，系统安全稳定，不出问题，不用接公司电话，可以放心地享受假期。
Q2：运维人员如何避免背黑锅？
王喜春：个人觉得，黑锅是不是坏事，取决于你背了黑锅后有没有能力驱动其他人做一些事情，如果可以，那么接下来你可以让事情变得更好，至少下次不会发生同样的故障；如果不可以，那这个就是个坏事的黑锅，而且背的除了显示个人品德高尚外，毫无价值，这类的黑锅才是运维要避免的。
那么，如何避免这类黑锅呢？
1、流程是一个很好的自我保护手段，例如一个变更需求，要提前24小时发起，重要的操作要业务研发老大审核等。
2、定好SLA，SLA虽然表面看起来是给自己带了枷锁，其实内在是在保护运维人员，有了数据，就不用出现一些感性的词语，比如因为运维操作得慢，导致故障扩大之类的。
3、最后，还是和研发或者测试打好关系吧，当出现三国混战时，找好你的盟国。
汪洋：和前面的问题类似，需要让开发、测试和业务人员认识到系统的稳定不是运维单方面的职责，也不是单方面就可以解决的，而是需要大家共同的努力，贯穿到系统设计、开发、测试（功能性和非功能性）、部署、上线等方方面面。
在问题发生后，为了避免背锅，需要有详细的诊断或者性能数据来证明我们的论点，能够清晰地说明问题发生的原因以及责任方。这就要求运维人员在解决问题的同时，也能够保存现场，收集到足够的数据，便于后面的分析。
很多时候，快速解决问题和收集诊断数据是一对矛盾，要在两者之间找到平衡，很考量运维人员的功力。当然，在有明确数据的情况下，沟通方面也是需要一定技巧的。不能生硬地指出不是我的责任，是应用设计或者开发导致的问题。需要一些耐心，比如告诉他们当前的设计在业务发展初期是没有问题的，架构随着业务的发展也需要不断优化甚至重构，在负载高时当前的设计会有哪些方面的问题，为了更好地支撑业务发展，我们的建议是怎样的，这样开发人员可能会更加容易接受一些。
李强：从我自身而言，一般从两个方面入手来尽量避免背锅：
1、技术手段，通过一些监控系统对当前的业务做到心中有数，出现代码发布造成的问题，一般都会从监控上展示出来；一些展示不出来的就需要与研发、测试甚至是业务部门来沟通，一起来发现问题。
2、非技术手段，一些重要功能上线、重大调整要由邮件，而且需要让相关部门必须留人，防止出现问题后得不到及时解决造成扯皮。
战学超：这……真的很难。运维是跟生产最近的人，你不先背锅，谁先背锅。关键是背锅之后的问题调查、总结和分析，这很重要。所谓吃一堑长一智，要深挖堑为何物。
读完这万字干货仍不过瘾？没关系！
9月15日 Gdevops全球敏捷运维峰会北京站
战学超&雷雨两位老师将现身运维管理专场
为你续说更多运维的那些事儿！
▼▼▼
运维界最远的距离，不是上线到宕机
而是Gdevops北京站候时已久
你却还没有报名！
社群福利：免费门票3张
（免费码：dbaplus）
快快抓住这个大好机会吧~
▼▼▼
最后，特别感谢本次专题主编战学超老师、打了鸡血干活最勤劳的小编，以及8位老师的无私分享，你们提出的每一个宝贵建议，都将成为运维同学们转型路上的一盏盏指明灯~
欢迎在本文微信订阅号（dbaplus）评论区留下你的职场看法、问题与答案，点赞数最多的1名可获得以下运维好书一本~截止时间：本周四（8月31日）中午12点。
特别鸣谢图灵教育为本次活动提供图书赞助。
大牛们都在这里等你！