发表于 2020-2-28 16:54:14

深度好文:什么是真正的运维开发

曾说过,运维开发是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+的机器。更简言之,运维是背锅侠,英雄世界有两位也是背锅侠,其一是忍者神龟,其二是美国队长。能自主可控掌握运维开发能力的,才能去做美国队长。因为,美国队长背上的锅,除了可以背之外,还可以潇洒地甩,锅也能成为武器。
页: [1]
查看完整版本: 深度好文:什么是真正的运维开发