速来报名!AICon北京站鸿蒙专场~ 了解详情
写点什么

运维 2.0:危机前的自我拯救 | 高效运维最佳实践 (04)

  • 2015-05-07
  • 本文字数:4571 字

    阅读完需:约 15 分钟

“高效运维最佳实践”是 InfoQ 在 2015 年推出的精品专栏,由触控科技运维总监萧田国撰写,InfoQ 总编辑崔康策划。

前言

运维的今天,内忧外患。运维危机,已非盛世危言、或哗众取宠。

怎么办?暴风雨和奇点同时逼近,而运维的分化,或许只是时间的问题。

为此,我提出新观点:运维 2.0——这也是运维最后的机会。

运维好比是池塘里的鱼,不管水域大小,都有一块自留地。但某天,突然来了一头鲸鱼,目标不是鱼而是水…… 所以运维的任务需随之而变——在水被吸干之前,提前上岸。

运维 2.0,就是那个带我们跳出池塘投身大湖的武器。

本文根据我在 2015 QCon 北京大会的演讲提炼而成。本次大会的主题及期间的业内交流,给我极大的触动。因本文宗旨和专栏思想高度一致,故此发布。

挑战究竟何等凶猛?技术重要性不断下沉,新的核心竞争力何在?趋势不可逆转的话,怎么升级到运维 2.0?且听本文分解。

本文不是很长,依惯例放上目录,请享用。

1. 什么是运维 2.0
2. 为什么需要运维 2.0
2.1 公司内部的各种不满
2.2 公有云风起云涌
2.3 开源软件百花齐放
2.4 运维自动化
3. 运维 2.0 的落地
3.1 技术服务业务
3.2 能力双模式
3.3 开放的技巧
4. 拥抱变化
结语

好吧,我们正式开始。

1. 什么是运维 2.0?

运维 2.0 是指可依赖、懂业务、服务化的专业运维(或称服务运维)。也是本专栏所推崇高效运维的抽象和概括,即“专业、热情、方便、快”。

需要引起注意的是,技术不代表专业。相反,技术往往是专业的最大障碍。

运维 2.0 要求,从技术运维升级为服务运维,向公司提供可依赖的专业服务。

运维 2.0 强调服务交付能力,而不是技术能力。这也要求我们完成角色转换,成为懂业务的运维。具体而言,需要完成如下两个转换。

1)转换工作重心:从关注工作产能(技术的自我修养),变成关注工作产出(我们为公司做出多大贡献);

2)转换关注重心:从关注自我评价,变成关注外部评价。

2. 为什么需要运维 2.0?

伴随着 Web 2.0 的风潮,近年来,运维相关技术的发展也突飞猛进。

但同时,从内部来看,对运维的不满,日益突出;从外部来看,公有云来势凶猛,开源软件百花齐放,自动化运维降低了对人的依赖——众多运维人员,逐渐从技术的创造者(手艺人)沦为技术的使用者(装配员)。

2.1 公司内部的各种不满

对运维而言,来自内部各种不满的声音,从来就没消停过,而且越演越烈。从调查来看,貌似很少有公司对运维是相对比较满意的。

公司内部的典型不满,包括如下图所示种种。不知其中是否有大家的影子?最终公司和业务部门就像图中间这只小猫,抓心挠肺却又无可奈何。

运维本来就是个尴尬的行当。公司默认,不出故障是正常的。甚至有公司将开发、测试和运维并列,起评分为零分,每出一次故障,扣几分。

运维觉得自己的苦憋有多少,业务部门对运维的不爽就同等的有多少。

公司内部的不满,是运维危机的主要根源之一。

公司和业务部门长期积累的负面情绪,已积累多年,迟早有一天会突然爆发。

曾经有公司老板,在某一次运维严重人为事故后,准备把整个运维部端掉;类似情况也发生在,另一家公司出现严重的安全事故时。

2.2 公有云风起云涌

根据 RightScale 对国外 930 家公司在 2015 年第一季度的调查来看,目前 93% 的公司已经在使用云,其中公有云的使用者为 88%。如果包括传统企业,国内使用云的比例可能低些,但整体趋势已经非常明显。

IaaS 干掉了基础运维,公司不再需要人各地出差服务器上架了,机房值班更加不需要了。

PaaS 部分干掉了应用运维,甚至技术含量高的 DBA,需求量都将锐减。

SaaS 甚至干掉连研发都干掉了,使得公有云的使用更加傻瓜化,像 Office 365,谁不会呢?

有人甚至提出 OaaS——服务器运维的外包,也就是说,彻底不需要运维部门了。

2.3 开源软件百花齐放

开源软件从来没有像今天这样生机勃勃。随之,运维人员从技术的创造者沦为技术的使用者——好比调制鸡尾酒,能力的高低,取决于勾兑水平,但还都能喝。

不仅国外新的开源技术层出不穷,国内互联网公司也发布了诸多令人惊艳的作品,甚至包括之前大家认为相关封闭的大公司,近来也改变姿势,主动推出自家各种得意之作。

国内新晋大公司甚至规定:能用开源软件,就不自主研发。并且乐于成为开源软件的 committer,反馈并回报社区。

开源软件降低了相应系统运维的复杂度和技术要求,也即降低了对人的依赖。

前些年,精通 Shell 脚本编程的系统工程师,相比工资可能高出 50%。但随着 Puppet、SaltStack 等开源软件的出现,使得各个系统组件偏于积木化,操作也更加简便高效。

2.4 运维自动化

运维进化到今天,已非刀耕火种的时代。各种开源软件就好比武器和工具,使得运维自动化的实现,变得如此地得心应手、游刃有余。

只是,这会导致中级水平运维人员的需求锐减。

站在运维制高点的大公司,已经向我们传送阵阵凉意——山雨欲来风满楼。

某大型互联网公司,实现了游戏自动化运维的 PaaS 平台,通过简单的页面操作,可以完成新服、更新、合服、数据分析等几乎所有业务需求。这使得,在公司业务量增加 50% 的情况下,运维人员仅增加了 5%。

另外,运维自动化已深入运维的各个细分工种中,而不仅限于应用运维和系统运维。

某大型互联网公司,持续改进 IDC 自动化平台,使得服务器交付时间缩短为不到 6%,网络设备交付时间缩短为不到 15%。

某大型互联网公司,基于多年技术积淀,基本实现了数据库自动化运维。这使得单个 DBA 能维护的数据库服务器,增加 10 倍,然后呢……

或许不用太长时间,这股风潮将席卷盘踞山腰的中型公司,然后以暴风雨的形式,落在中小公司头上。

内忧外患!内外交困!新形势下,运维的价值何在?技术重要性不断下沉,还准备倚仗某些压箱底的技术活呢?

迷失的运维,出路在何方?运维的前途会怎样?我们能平安上岸么?

3. 运维 2.0 的落地

运维 2.0 是一个理论 + 实践的体系,内容较多,本文仅择要提及。关于如何落地的具体细节,我会在本专栏的系列文章中分别阐述。

运维 2.0 不是忽视技术,而是强调技术得适度,把我们的关注点从技术本身,转移到贡献上来。技术服务业务,与此同时,再搭配各种理论及方法技巧。

诚如前文所言,运维 2.0 即高效运维,亦即:专业、热情、方便、快。也就是说,向公司交付一种可依赖的专业服务。

其中“专业”的意思,包括减少故障发生次数,缩短故障时长(有公司甚至进一步提出,“不以故障多为耻,以恢复快为荣”),少犯人为事故,个人技术进步服从业务要求(少搞自研、多用开源)等。

另外,“热情、方便、快”见之前专栏文章,本文不做赘述。

运维 2.0 的实现,基于产出 / 产能平衡原则,只有完成如下三大类产能的投入,才会最终获得心仪的产出——运维 2.0。需要注意的是,这三大类投入,并非串行,相反,应同时修炼。

相信会有那一天,公司业务部门惊喜地说,“我们运维变化好大”。

3.1 技术服务业务

我们的诸多行为背后都有动机(潜意识),这就是俗称的思维模式。我们不自知的是,往往不自觉地陷入各种思维模式(思维陷阱)中。在这些既定思维模式中,我们感觉到舒服,更难以体认到思维模式是可以改变的。

我们需要提升意识。就像这三个石匠的故事。

这个故事是如此的直白而又精准,我们仿佛看到管理学科创始人彼得ž德鲁克在讲述时,不无揶揄的表情。是啊,对公司业务而言,我们都是石匠,或者说凿石头的;而且,新的凿石神器已经在路上……

为什么技术服务业务?

运维不是销售,无法对公司产生直接价值(收入),我们的工作价值是通过外部门间接实现的。说得再直白些,我们本质上提供的是一种“服务”,仅此而已。

我们属于服务业(多么痛地领悟),需要深知技术只是我们的工具,仅此而已。

3.2 开启能力双模式

这里的能力,包括业务能力和技术能力。

我们需要主动学习业务,主动、定期和业务部门沟通,业务部门感受到我们的诚意后,也会释放他们的诚意,这样便有了愉快的工作环境,业务能力也会提升地更快。

我们需要主动拥抱公有云及新兴的开源软件,乐于分享,而不是把某些技术当做压箱底、保命的资本。

3.3 开放的技巧

技巧同样非常重要,除去在本专栏第 01 篇和第 02 篇讲述的那些之外,例如恰当的鼓励、及时的正向反馈,也往往能取得意料之外的效果。

不要再潜意识地觉得自家领导、外部门都是白痴,都无可救药。真诚地、平等的交流、倾听,改变迟早会来。

备注:因文章篇幅所限,运维 2.0 更多的各种细节,暂且不表。以后本专栏还会有多篇文章,详细阐述。

4. 拥抱变化

其实,我们有什么理由相信,自己就是那个独善其身的幸运者?——在我们看到互联网干掉一个又一个传统行业,而运维实际还处于初级阶段的时候。

同样,运维的进化,将导致中级运维人员的需求锐减,更多需要初级运维和高级运维(即工具的操作者和工具的建设者)。

这需要我们修炼新技能:从外部审视自己,懂业务,提升专业服务能力,树立公有云无法替代的优势。与此同时,加强技术能力,提升为高级运维人员,以实现提前上岸的目标。

因为运维的集约化,使得高端技术人才的需求更大。例如,像航天这种高度自动化的行业,飞机驾驶员就是一个高大上的岗位。

诸多开源软件需要二次开发,因此学些编程,成长为 DevOPS 或全栈工程师,也是一个好的选择。

【问】我确实没怎感觉到运维危机?你怎么说服我着手实践运维 2.0 呢?

【答】运维危机不因你个人是否感觉到,而不存在嘛。至少,咱也得居安思危,对不?况且实施运维 2.0,又不会让自己损失什么,早些总比晚些好。这就好比考驾照,觉得自己暂时不买车,就不去考。等有一天所在城市准备限号,那就哭都来不及了(驾照是排号的前提)。

【问】我修炼了运维 2.0,可公司不需要那么多人了,咋办?

【答】你的综合技能大大提升,都已内外兼修,还怕找不到更好的工作?

【问】看完你的文章,整个人的心情都不好了。能否说说运维的机遇?

【答】抱歉,请相信我这些文字只是善意提醒。而且,我对运维感情很深,十多年一直奋斗在这个行当。机遇在于,很多公司开始减少成见,并越来越重视运维。现状越是糟糕,改善越是能获得更高评价。运维 2.0 可帮助大家快速地提升软实力,实现飞越。

结语

暴风雨和奇点必将来临,区别只是时间上,早一些或晚一些。

运维 2.0,将重新定义运维。要求公司内部运维部门,从侧重“技术运维”升级到“服务运维”。这也是在变革时代中,运维重生的最后机会。

运维 2.0,要求运维从内而外的改造自己,这个过程痛苦,但也是我们唯一的机会,这甚至决定着我们是生存、还是死亡。

焦虑和恐慌不能解决问题,对事实和趋势的抗拒,顶多自欺欺人,对解决问题也没有任何帮助。认同趋势,顺应潮流,提前做好准备。

一起加油,百万运维兄弟们!!!

当然咯,本专栏《高效运维最佳实践》也是运维 2.0 最佳实践,值得您的持续关注 。

本文得到腾讯赵建春先生(@coati)、新浪微博杨卫华老师(@Tim Yang)及老友董伟(@董伟)的斧正。谨表谢意。

另外,InfoQ 创始人兼 CEO 霍太稳先生亲自创建了微信群“InfoQ 高效运维群”,专为互联网中高端运维人才而打造。目前采取邀请制,如需入伙,请添加萧田国个人微信号 xiaotianguo,注明申请加入“InfoQ 高效运维群”。并请事先准备红包(丰俭由君),以做“投名状”,呵呵。

感谢崔康对本文的策划,丁晓昀对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们,并与我们的编辑和其他读者朋友交流(欢迎加入 InfoQ 读者交流群)。

2015-05-07 03:0211083

评论

发布
暂无评论
发现更多内容

HIVE3 深度剖析 (上篇)

明哥的IT随笔

大数据 hie

「码」力集结!他们用作品为FinClip黑客松打造出一道靓丽的风景线

Speedoooo

小程序 hackathon 黑客马拉松 黑客松 小程序容器

拿起手中的键盘做公益侠客,让你的第一个低代码应用为公益发光发热!

InfoQ写作社区官方

低代码 公益 大学生 热门活动 码上公益

CountDownLatch、CyclicBarrier和Semaphore区别及底层原理

爱好编程进阶

Java 程序员 后端开发

hive踩过的小坑

爱好编程进阶

Java 程序员 后端开发

萌新看过来,你还学不懂VScode插件吗?

葡萄城技术团队

报表

还在写SQL做SAP二开?通过RFC调用NetWeaver,让HANA数据库操作更可靠

葡萄城技术团队

ERP 全套信息化系统 二开

centos7离线安装mysql5

爱好编程进阶

Java 程序员 后端开发

IO流详细解答,博主亲自手敲代码,快速上手

爱好编程进阶

Java 程序员 后端开发

C++类和对象详解

爱好编程进阶

Java 程序员 后端开发

Day346&347&348&349

爱好编程进阶

程序员 后端开发

docker下kibana搭建

爱好编程进阶

Java 程序员 后端开发

Eclipse中查看源代码

爱好编程进阶

Java 程序员 后端开发

idea启动tomcat报错,org

爱好编程进阶

Java 程序员 后端开发

ansible 模块:set_fact

ghostwritten

ansible

ansible 模块:script

ghostwritten

ansible

企业文档爆炸,如何管?

小炮

企业文档管理工具

Day177

爱好编程进阶

Java 程序员 后端开发

ansible 模块:add_host

ghostwritten

ansible

ansible template jinja2 渲染

ghostwritten

ansible

基于 FFI 的 PyFlink 下一代 Python 运行时介绍

Apache Flink

大数据 flink 编程 流计算 实时计算

容器化 | 构建 RadonDB MySQL 集群监控平台

RadonDB

MySQL 数据库 容器化 RadonDB KubeSphere

Batman+joker乱谈

爱好编程进阶

Java 程序员 后端开发

“银行家算法”大揭秘!在前端表格中利用自定义公式实现“四舍六入五成双”

葡萄城技术团队

银行家算法 纯前端表格技术

ansible 模块:blockinfile

ghostwritten

ansible

无形资产管理系统解决方案

低代码小观

资产管理 CRM 财务审核系统 CRM系统 企业管理软件

IntelliJ IDEA开发最佳配置

爱好编程进阶

Java 程序员 后端开发

CentOS7各个版本镜像下载地址

爱好编程进阶

Java 程序员 后端开发

Cloud-借助消息队列解决分布式事务

爱好编程进阶

Java 程序员 后端开发

Day274

爱好编程进阶

Java 程序员 后端开发

当.Net撞上BI可视化,这3种“套路”你必须知道

葡萄城技术团队

看板 数据大屏 BI数据分析

运维 2.0:危机前的自我拯救 | 高效运维最佳实践 (04)_安全_萧田国_InfoQ精选文章