阿里、蚂蚁、晟腾、中科加禾精彩分享 AI 基础设施洞见,现购票可享受 9 折优惠 |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:0210478

评论

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

android 中DrawerLayout实现抽屉

android 程序员 移动开发

Android SpannableString详细解析

android 程序员 移动开发

Android Zygote 从何而来?揭开Android系统启动的面纱

android 程序员 移动开发

Android OpenCV(三十七):轮廓外接多边形

android 程序员 移动开发

Android Studio安装更新终极解决方式

android 程序员 移动开发

Android 使用讯飞语音SDK

android 程序员 移动开发

Android 原生控件ViewFlipper实现淘宝头条垂直滚动广告条

android 程序员 移动开发

Android 图像处理

android 程序员 移动开发

Android P 适配指南

android 程序员 移动开发

Nebula 分布式图数据库介绍

Se7en

Android UI--ViewPager扩展Tab标签指示

android 程序员 移动开发

Android View 绘制流程

android 程序员 移动开发

Android 多渠道打包配置

android 程序员 移动开发

Android Switch控件修改样式

android 程序员 移动开发

Android SDK 网络模块解析

android 程序员 移动开发

Android Studio 4

android 程序员 移动开发

Android WebView常见问题

android 程序员 移动开发

【译】TypeScript的Record类型说明

废材壶

typescript

Android Studio 教程:入门开发第一个程序

android 程序员 移动开发

Android _ 从 Dagger2 到 Hilt 玩转依赖注入(一)

android 程序员 移动开发

Android 主流通用常用框架汇总(持续更新)

android 程序员 移动开发

[ CloudWeGo 微服务实践 - 06 ] 服务发现(1)

baiyutang

golang 微服务 11月日更

Android Studio 插件

android 程序员 移动开发

Android TextView的属性与应用

android 程序员 移动开发

android 三级级联筛选列表

android 程序员 移动开发

android 五大应用开发框架

android 程序员 移动开发

Android SDK 网络模块解析(1)

android 程序员 移动开发

Android 三类框架的理解以及MVVM框架的使用

android 程序员 移动开发

Android 中高级核心复习面试题整理,备战年后金三银四!

android 程序员 移动开发

android 图表基本属性方法设置

android 程序员 移动开发

Android VideoPlayer

android 程序员 移动开发

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