DevOps实施经验分享.docx
- 文档编号:23593817
- 上传时间:2023-05-18
- 格式:DOCX
- 页数:17
- 大小:666.95KB
DevOps实施经验分享.docx
《DevOps实施经验分享.docx》由会员分享,可在线阅读,更多相关《DevOps实施经验分享.docx(17页珍藏版)》请在冰豆网上搜索。
DevOps实施经验分享
DevOps实施经验分享
当下只要搞开发的人,都在谈微服务,只要搞运维的人,都在谈DevOps,但对于大部小伙伴来说几乎没什么经验,对于大部分企业来说也只处于尝试阶段,虽说如此,可感觉大家在制定目标时,都不太喜欢给自己留余地,把规划写得很大,功能很全,甚至恨不得一夜之间所有问题都会通过微服务与DevOps的设想凭空消失。
而从本文起,我将通过一个系列向与大家聊一聊“我们在实施DevOps时遇到的挑战”。
挑战一:
敏捷文化
1、切换敏捷之前的过渡区
对于许多草根程序员来说,提到敏捷所能带来的收益,条件反射地会说“能快呀”、“不用写文档啦”。
不能说这种说法有问题,只是不够专业,在实际的工作中,我们是否经常会听到这样的对话?
行,就按照你说的做,我写个需求规格说明书给你
好的,写完别忘记给领导审批,然后我按照需求做个设计给你看下
……
开发结束啦,已经提测了,你问问测试吧
……
问问测试吧,什么时候可以发布仿真环境
……
又改需求了?
别忘记先改需求规格说明书,要不然代码和文档对不上了,改完我再开发
……
对于长期适应于「需求->设计->开发->测试->运维」的企业来说,直接切换至敏捷模式,无论对业务、技术及架构都是非常具有挑战的,这种挑战多半来自于业务场景与公司文化的限制,甚至是组织结构的局限性,不但不能快起来,甚至会带来一些意想不到的灾难。
(图:
职能化筒仓式组织结构)
先用迭代让业务快起来,敏不敏捷不着急
对于金融类企业来说,多半是业务驱动模式,业务关心的是“快上线”、“别出事”,至于技术是用什么实现,敏捷也好,糊上墙也罢,他们其实并不关心。
为了快速让业务获得收益,在采用敏捷之前我们选择迭代进行过度。
举例说明下迭代给业务带来的价值:
要计划制造一辆汽车,它最核心的功能是可以在路上跑,所以我们可以先制造一个踏板车,依次迭代为滑板车、自行车、摩托车、汽车。
(图:
正确理解迭代的方式)
瀑布-迭代-敏捷,三者的差异是啥呢?
(图:
瀑布与迭代的区别)
(图:
瀑布的特点)
(图:
迭代的特点)
(图:
迭代与敏捷之间的区别)
2、大家都缺乏敏捷文化
从某种角度来讲,目前我们还是按照「职能化筒仓式组织结构」进行分工协作的,开发和运维部门经常会坐在一起探讨,就运维流程如何改变、自动化能力如何建设等,然而自始至终无法突破的终极问题就是:
无论我们如何改变,如果万一生产环境出了问题,谁承担责任?
因为DevOps能力的建设需要一个过程,开发团队不敢承诺完全承担责任;而运维因为弱化审批和控制力,也认为不该为其承担责任。
最终不了了之。
其实,使用迭代过度也只是权宜之计,真正的问题出在文化上,旧有的组织治理模式产生了各扫门前雪的官僚文化,没有责任共担,以及出现问题必然问责的文化。
这种文化可能源自惯性的职能化思维,可能源自组织的绩效考评和激励制度。
(图文:
跨职能产品化的组织结构)
现代关于“系统论”的研究已经在很多著作中强调,一个组织就是一个由人构成的复杂系统,组织中每一个人所能获得的信息是有限的(包括最高管理者也是),每个人或团队都只能基于自己有限的经验、有限的信息做出决策和行动。
如果系统发生失败,例如生产环境出现问题,这必然是由于系统各个部分相互作用(从想法提出到软件投产各个环节的相互作用、系统与其它系统间的相互作用)产生的结果,对其中任何局部进行惩罚无非是寻找替罪羊,有害而无益。
这时候组织真正应该做的,是相信每一个人都已经做出了最大努力,将相关干系人拉到一起对问题的根因进行分析,找到能够有效避免类似问题再次出现的解决方案,并确保该方案得到实施,对其效果进行验证。
这是ThoughtWorks在一篇DevOps文章中所提到的,我觉得一针见血,不过对于大部分企业,尤其是金融类企业,实践落地所付出的周期与成本可能会更大一些。
再举个例子,在「讲个‘理论型’高可用架构的故事给你听」我曾经说过,我们的架构部模仿饿了么的“随机故障测试系统(Kennel)”自研了一套“混世魔王”,英文名叫“ChaosDevil”,这个 “魔王” 会根据策略每隔一段时间随机将生产环境服务器关闭,以此来测试生产环境的快速恢复能力,促使各团队提升系统的稳定性;
(图:
网络游戏-混世魔王形象照)
有趣的是被指定优先使用的团队口头全力支持,但实践起来却迟迟延误,当然大家都比较忙,这也是可以理解的。
不过我们可以设想下,如果没有这个“魔王”,大家可以给领导讲自己的系统很稳定(只要没出问题);
然而这个“魔王” 可能会随时暴露出自己的系统并不像自己所宣称的那样稳定,会降低自己在上级心目中的“有能力”印象,随之而来的可能就是问责、惩罚;
这样的文化下,大家真正关心的是如何给领导“表现”,而不是在真正的系统稳定性上追求卓越。
所谓敏捷文化是个啥?
抄袭一张图吧,简单点:
(图:
敏捷,乃至DevOps所需要的文化)
挑战二:
配置文件的困惑
1、没有DevOps之前,配置文件是怎么玩的呢?
在「群雄割据」的时代里,通常一个Jar或一个War就可以打天下,以Spring+properties为例,对配置文件的适用场景基本可分为两种类型:
配置文件位于classpath下
使用spring的org.springframework.beans.factory.config.PropertyPlaceholderConfigurer类加载Properties配置文件,通过源码可以知道,默认加载的是classpath下的文件,配置如下:
如果有多个配置文件加载,则:
配置文件位于外部目录
但是对于外部目录的配置文件,使用org.springframework.beans.factory.config.PropertyPlaceholderConfigurer也是可以加载的,不过要修改他的路径配置方式,如下:
这样就可以成功加载外部目录的配置文件了,${user.dir}是系统变量,指用户当前目录所在。
当我们从「群雄割据」来到「天下一统」的时期后,虽然DevOps提升了交付效率,越来越满足快速试错的原则,可随之而来的「技术污染」却与日体现:
▪…………
▪配置文件的版本如何与程序版本对应?
▪配置文件的管理如何更加简便?
▪配置文件的修改该有谁来操作?
▪配置文件的更新是否可以不影响正常服务?
▪…………
无论哪一项污染,只会与DevOps扯上关系,都是让人头痛不已。
撸起袖子,不要怂,咱们搞个配置中心吧。
2、有了DevOps之后,配置文件又是怎么玩的呢?
其实想通过DevOps获得业务收益,无论从哪个环节启动,都将是一场持久战。
随着系统产品化的改造,通过DevOps流水线的快速交付通道,任何一个交付版本都可以通过CI与CD环节后,利用自动化部署工具,轻松地完成升级或发布;
这段看似美妙的诱惑,首先挡住去路的,就是配置文件的使用与加载方式。
如果不将配置信息外移至配置中心,在DevOps中会出现哪些问题呢?
1.维护成本:
系统拆分了更细了,增添CI与CD环境后,每个应用在每个节点下,都需要在本地维护一套完整的配置文件;
2.操作风险:
配置修改随意,无操作痕迹,易出错;
3.版本需求:
一切皆产品,一切皆版本,配置文件如何解决版本化控制问题?
图:
配置中心在DevOps快速交付通道中
你不是常说你们的场景都是持续污染的吗?
谈谈如何在污染环境下接入吧。
的确,在整个接入过程中可以说是一波三折,原因很简单,之前「群雄割据」时期的每一位诸侯都有自己玩转配置的一套方案,现在你说统一就统一?
无法满足我要求的,我不接。
这话表面看起来有些生硬,不过想想挺有道理的,所以在配置中心的方案中,我们提出了“三种适配器,两种推进器”的理念。
三种适配器
图:
适配器Trade,满足原有使用Properites的诸侯们
图3:
适配器Native,满足已使用过自研独立配置服务的诸侯们
图4:
适配器Ccms,满足使用Key/Value的诸侯们
两种推进器
图:
希望采用“文件被动加载”的诸侯们
图:
希望采用“Key/Value实时推送” 的诸侯们
从某种角度来说,就算没有配置中心的存在,我相信DevOps的推进也会顺理成章,只不过相对不会如此平滑,或多或少给未来造成风险。
有了配置中心,诸侯们的确享受到了福利:
1.配置统一在服务端维护,同一环境下所有应用节点共享同一份配置;
2.配置控制台提供鉴权、操作日志等服务;
3.配置控制台实现了版本控制,修改的配置需要发布后生效,减少误操作;
4.配置发布后,实时通知应用端,无须重启即可使用;
5.配置版本支持一键回滚;
6.配置控制台实现了整体复制、导出、批量修改等功能;
3、小结
本章主要讲述围绕配置信息管理和使用在DevOps过程中的那点事,所以对配置系统自身的原理与技术实现并未做详细的描述,如对这块有兴趣,欢迎大家在留言区中提出,我将通过独立的整篇文章加以叙述。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- DevOps 实施 经验 分享