内容简介:合异以为同,散同以为异。——《庄子》曾说过,运维开发是IT运维的未来发展趋向之一,但具体啥叫“
合异以为同,散同以为异。
——《庄子》
曾说过,运维开发是IT运维的未来发展趋向之一,但具体啥叫“ 运维开发 ”?
一、说文解字
第一个层面,浅层意义,是指“ 运维 工具 的开发 ”。曾经确实如此,例如在HP(Service Manager)和IBM(Tivoli)等国外企业级解决方案为王的时代。那时,实施一套运维工具集,就像在实施SAP的ERP,全过程从咨询到落地实施,不但复杂得很,而且各位运维管理人员、运维工程师就像小学生那样好学(bei dong),毕竟领导说了,上运维系统就要走“固化-僵化-优化”的正路,但理想与现实的鸿沟,还是如此鸿沟:
-
不强迫不用:一堆运维专业工程师,用系统就像在“做作业”,有种智慧被污辱的赶脚,哪还有积极主动性哉,于是大家都推一步做一步(不考核不做);
-
用了自己也改不动:这些大工具,做到这么有普适性,肯定用得不就手,偶尔有积极主动性时,工具又改不动(原厂没啥开放性可言);
-
叫人也改不动:成熟套装工具在建设之初,肯定先做一大轮所谓“需求调研分析”。当运维工程师讲干口水、咨询顾问们拍拍屁股之后,一堆书名号报告倒是如期形成了,但运维工具却还是那个样子,运维工程师的想法很多都没有落实(“报国无门”)。
表象千千万万,但如此易于失败的原因究竟何在?此刻,柯南突然降临:
(图:采自网络图片)
【解】:IT运维工具的受众和其他MIS系统的用户不同,他们自己本来就是IT人员,是 最懂IT运维管理和技术的从业者 ,而不是不懂IT的业务人员(况且现在各行各业的业务人员,也越来越懂IT了)。所以, IT运维工具的开发实施方法论,不能照搬其他业务系统的方法论。
二、时代解读
针对新时代的“运维开发”含义,个人认为,应该是“ 有运维特色的开发 ”、“有运维特色的开发”、“有运维特色的开发”(重要事情重复三次)。是开发,但又不是普通的开发,这是我们所要高举的旗帜:
1、 无名无利 的开发:作为底线保障的部分,运维开发怎么说都不可能在聚光灯之下。在腾讯,估计做微信、游戏的,怎样都比做蓝鲸和织云的要光鲜,至少在相亲时向美女介绍自己工作,不用解释一听就明白。光天化日之下,除了超人是底裤外穿之外,就没有见过第二个。
(图: 采自网络图片 | 艰苦奋斗,一直是运维的优良传统)
2、 要求全栈 的开发 :就像相声《报菜名》的节目一样,运维工具要涉及的软硬件类别多不胜数,关键最痛苦的还不在于多,而在于“隔行如隔山”,每种东西的脾气都各不相同,要能做到数据打通的“大同世界”,必须祭出神秘全栈武器——“攞你命3000”:
(图:采自网络图片 | 每一样武器都独当一面,但加起来就……?)
3、 要求可DIY 的开发 :运维工具的使用者都是天天窝在机房“搞机(基)”的暗黑神秘高手、段数高,肯定不满足于一体成型的工具,而且未来的自动化和智能化时代,运维更需要大量的脚本或者算法模型,这些都是在实际工作中按需灵活编制的(无法提前在系统需求调研分析阶段就全部梳理完毕)。现在好多高大上的IT名词,都要冠个“软件定义的XX”来装潢自己,也就是意味着,工具要有持续的延伸性和可塑性,运维工程师可以不断对它赋能,这样才能赢取他们的青睐。
(图:采自网络图片 | 向客户展示DIY神技,甜过初恋)
三、我的运维开发方法论
除了第一个要求是精神层面之外,其余两点,都是技术层面。但很明显,传统的“烟囱式”运维工具系统,已无法再满足要求。硬是要针对传统系统再去优化完善,恐也会积重难返、事倍功半,唯有大刀阔斧,想起IT人最常用的两大招数(重启、重装),“华山一条路”,全部推到重来,用全新架构来完成“有运维特色的开发”任务,或许是一条可行的路径。
基于过去的经验教训,结合对业界动态的粗浅学习,本人在运维开发方法论方面,有一些想法,不成熟,但尽可抛砖求玉,以供各位方家大神讪笑。总体而言,可概括为“ 一简、两化两微、三同步、四全 ”:
(图:某ppt大神的贡献)
-
一简 : 简约 ,而不简单;不用多解释了,这句话早已被智能手机的广告洗脑。既然运维工具,无论是大的平台系统,还是小的应用脚本,主要目的都是工具,既然是工具,就要追求实用,删繁就简,直接对接功能核心。一方面,别将普通汽车的中控台设计成大飞机的控制室这么复杂,同时简约不代表简陋和缺失,也不能将大飞机的控制室按钮强行砍成普通汽车的中控台。总之,除了演示场景或者汇报场景之外,一律以最终需求为依归、以解决核心痛点为宗旨。
-
两化两微 :(1)两化,指的是自动化+智能化,意思是要搞运维工具,目标就应该直接指向 自动化 和 智能化 ,传统的流程类功能(规范化)不是说不做,而是说不是重点难点了,如果连普通的规范化功能都做不好,那就算了,回家去“采菊东篱下”吧。(2)两微,指的是 微小开发团队 + 微服务架构 ,一定要用上敏捷的研发模式,不能再用传统瀑布式过程了,迭代周期太长,另外,一定要用上灵活可扩展的技术架构,不能再做烟囱系统出来(去系统化),谨慎拥抱新技术潮流(前提是开发团队要hold得住微服务架构)。
-
三同步 :是我认为的运维开发方法论核心。因为有运维特色的开发与传统MIS不同,受众自己需要DIY,所以切不可做出一体成型的工具出来。于是,我将工具划分为“ 平台-应用-脚本 ”,这三者是神圣三位一体的,三者即可同步推进、又相互交织渗透,是我心中的“ 铁三角 ”。
(图:周英耀)
(1) 厚平台 :运维平台一定要做大做强,包括CMDB、流程引擎、自动化作业编排、数据处理等等,都应该在平台层得以科学合理地解决。当然,各运维开发组织可以根据自身条件和策略,选择不同的构建平台路线:既可以采购成熟商用平台(如腾讯蓝鲸、优云等),也可以自己利用开源世界的代码来研发/整合(如Ansible与Zabbix的串联),甚至不采购不自研,直接用社区版的平台(如直接用Ansible,不改了,只做配置实施),丰俭由人。总之,因为这个平台层的能力,决定了所有“上层建筑”的成长上限,具有关键性的影响,所以选择的机会成本很高,技术债需要做好记录和分析。
(2) 轻应用 :应用是介于平台和脚本中间的一种形态,在研发速度上,要相对较快,同时要兼顾一定的非功能性需求,可以独立自成体系,也可以依托于平台的开发框架研发(需要平台能提供开发框架及环境),一般来说,研发应用的子团队要更为微小,用的技术架构要更为轻量级。通过研发及实施各种、各类运维应用,经实践检验,如果应用具有一定的成熟度以及可复用前景的话,最终还可以整合入平台层,丰富平台层的能力,但这个是水到渠成的过程,在运维人员构思应用的时候,无需担负太多的整体考虑,需要轻装上阵,单独体系的小应用并不丢人,并非每把小刀都需要整合到瑞士军刀中。
(3) 灵脚本 :我们要面对这么多复杂的运维对 象和场景, (i)对于自动化 场景而言,要采集并控制这么底层的设备或软件平台,脚本是怎样都绕不开的存在,语言就包括shell+python+go+c……(一堆神兽飘过),还未完,协议包括ipmi+snmp……(又一堆神兽飘过),没有两三把vi功力的神侠在,自动化就是空谈;
(ii)对于智能化场景而言,一堆数学算法,什么分类+聚类+关联+自学习……(还是一堆神兽飘过),如数学建模竞赛一样,不弄些算法分析模型,谈何智能化?这些脚本级的工作,可以是实验性质的,没有所谓,最紧要的是要以最快的速度完成任务,非功能性需求(如交互友好性等方面)可以先晾在一边暂不考虑。
当然这些脚本,可以依赖于平台运行,也可以依赖于应用运行,也可以直接运行,看情况而定。最后,脚本可以慢慢越做越大变成应用或者整合入平台,都是极可能发生的场景。
-
四全 :个人认为,要做好运维开发工作,必须贯彻“四全方针”:(1) 全栈 ,针对对象而言;(2) 全过程 ,针对系统阶段而言,例如运维要参与开发阶段,就必须要有DevOps的工具支撑;(3) 全息展示 ,需要全面提升可视化的广度和深度,但要注意,这里不是说要用美工来雕琢界面效果,要的数据信息的有效表达;(4) 全员参与 ,没有运维工程师可以独善其身,不参与任何运维工具的研发设计,若只安静地做运维工具的使用者,那是没有前途的。
(图:采自网络图片)
四、运维开发的收益
啰嗦了这么多,似乎说明了,有运维特色的开发是这么难做、要这么花心思和资源,但为啥还要去做?我们是雷锋吗?靠堆人头,一样能做日常运维工作,何必呢?no zuo no die,万一运维开发工作做得不好,失败了,那不是更糟糕?
是时候,祭出我自己瞎扯的“ 运维四化图 ”出来了。
其实,从Lv2“标准化+可视化”阶段起,运维工具系统的重要性已经不言而喻,但还是可以依靠外部成熟套装产品,由第三方公司完成运维开发工作,其中部分问题已在本文开篇说过,此阶段另外一个最大的问题是,脱离不了“人肉运维”的痛苦——运维效率低。于是,大家都想要跃迁到Lv3-Lv4的自动化和智能化阶段,而这种跃迁,却不能单靠外力。如果自身运维团队不转型、不自觉投身运维开发的洪流,即使外部有多不胜数的运维平台,连具体脚本都不会写,这样的团队,乖乖地继续呆在原地吧,终有一天将被历史的大浪淹没。
简言之,运维开发不算风光(是与业务系统开发相比较而言的),也很难,但此神功却实实在在是改变人肉运维搬砖的必要条件。 团队自身拥有运维开发能力,才有希望跃迁到Lv3-Lv4 ,才有可能像某电商所称的,6人管理1000+的机器。
更简言之,运维是背锅侠,英雄世界有两位也是背锅侠,其一是忍者神龟,其二是美国队长。 能自主可控掌握运维开发能力的,才能去做美国队长 。因为,美国队长背上的锅,除了可以背之外,还可以潇洒地 甩 ,锅也能成为武器。
(图:采自网络图片)
五、小结
迄今为止最严肃的一篇IT文章(因为写不出段子了,
),但依然是一篇没有创新干货的IT文章(因为个人水平所限,
),如果看官能顺序看完全文看到这一段,那么请收下本人的膝盖,除此之外,本人发不出任何福利,
。
作者:周英耀 作者单位:南方电网鼎信科技公司。本文经作者同意授权转载。
原文链接: 运维开发 | 有运维特色的开发
运维开发是IT运维的未来发展趋势之一,做有特色的运维开发,来 DevOps 国际峰会 2019 · 北京站看看,7月5日~6日,DevOps 的技术盛宴,点击下方视频了解更多。
点击 阅读原文 ,了解 DevOps 国际峰会更多精彩内容
以上所述就是小编给大家介绍的《深度好文:什么是真正的运维开发》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- 深度系统rust开发环境搭建
- 深度学习软件开发环境搭建
- 跨端开发框架深度横评(2020 版)
- AI开发面临碎片化 深度学习框架要统一
- 视频演讲: 敏捷开发:API网关与SCF深度结合应用
- 深度解读华为云 AI 开发平台 ModelArts 技术架构
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
The Mechanics of Web Handling
David R. Roisum
This unique book covers many aspects of web handling for manufacturing, converting, and printing. The book is applicable to any web including paper, film, foil, nonwovens, and textiles. The Mech......一起来看看 《The Mechanics of Web Handling》 这本书的介绍吧!