企业运维架构的角色转变和价值体现Word文件下载.docx
- 文档编号:21053773
- 上传时间:2023-01-27
- 格式:DOCX
- 页数:7
- 大小:84.68KB
企业运维架构的角色转变和价值体现Word文件下载.docx
《企业运维架构的角色转变和价值体现Word文件下载.docx》由会员分享,可在线阅读,更多相关《企业运维架构的角色转变和价值体现Word文件下载.docx(7页珍藏版)》请在冰豆网上搜索。
(2)上面做不到,没有统一的标准和概念,各个平台之间就很难集成和打通,所谓的持续集成、持续发布、持续部署、持续交付等这些环节仍然靠大量的人肉动作去做,还谈不上持续,效率自然上不去;
(3)稳定性保障无从下手,大量的服务化应用,错综复杂的调用依赖,海量链路日志,问题排查困难,一个请求下来,到底跑到哪个应用去了都不知道;
故障持续时间长,出现流量激增或基础部件故障,无法快速隔离、降级和恢复;
(4)效率跟不上,还经常出问题,进而团队协作效率降低,相互信任下降,就开始经常听到下面的言论:
开发抱怨:
“运维做得不到位,申请个机器老半天,发布效率也提不上去,代码都写好了,上线咋这么费劲,严重降低了我们的工作效率,再有,出了问题还得我们上去定位,运维什么都帮不上……”
运维抱怨:
“开发的架构这么烂,配置五花八门,还得手工维护,我咋知道这些配置干嘛的,配错一个就出故障,让我怎么自动化发布;
日志放哪儿也不知道,一会这里,一会那里,出问题你说我咋定位……”
(5)好了,出了问题,就开始撕逼扯皮、相互推诿了,背了责任的一方又开始甩出背锅言论,感觉没有被公平对待。
团队的氛围也开始出现badsmell。
3、问题的根源
其实从开发和运维单独的角度来看,双方的表达都没有问题,做的事情也都没有问题。
但是双方都是只站在了自己的角度表达问题和情绪,恰恰都忽略了很重要的一点:
运维和开发不是相互割裂的两个组织,运维的技术体系和全站整体的技术体系更是不可分割的,越是把它们割裂开看,越是站在各自的角度看问题,上面说的这些情况就越是无解,整个团队也会限于这种没完没了的、毫无意义的纠缠中,从长期看对团队和个人的发展都是很不利的。
所以,根本原因在于将开发和运维在技术和管理两个层面给割裂开了,详细描述如下:
∙运维阶段要面临的问题没想清楚,从一开始架构设计上就没有考虑清后续的运维阶段要面临的问题和事情,比如这么多应用,资源应该如何分配、发布的效率如何保障等,而都是在考虑开发自身的需求和问题。
不考虑运维面临的问题,这样实际就是把运维割裂在整个架构设计之外了。
(这个责任在谁呢?
)
∙运维团队的职责定位不清晰,整个技术架构朝着服务化的方向演进后,整个组织架构对于运维团队的定义也是模糊的,也就是运维到底要做什么,要承担什么样的职责,因为一个合理的架构落地,必然要有合理的组织架构去对应支撑才可以。
运维定位不清晰,就相当于将运维团队给割裂在研发团队之外了。
谈谈架构标准化的问题(跟运维有关系?
第一部分提到一个问题,运维架构和技术架构的脱节这个问题到底出在哪了?
到底谁应该承担这个责任?
一开始,我个人第一反应,承担这个责任的或许应该是架构师这样的角色吧,毕竟这不是个单纯的技术问题。
但仔细考虑过后,我觉得这样也会有问题。
因为从服务化之后,整个架构就已经是去中心化的了,我们可以看一下自己的周边,现在架构师的角色已经更多的往垂直领域发展了,如业务架构师(交易、支付、商品、营销、类目等),或者某个技术领域的专家,如分布式服务、消息、缓存和DB,更大的方向上如大数据、搜索等方面。
我想这也是去中心化之后的必然结果,大家都是朝着某个更加聚焦、更加专业的方向发展。
因为每个专业方向的特点又不相同,这时就很难再出现能把全站的架构讲清楚的人了。
所以,我们如果只是想当然的认为应该是xxx角色要承担责任,这样难免会片面。
1、怎么解决呢?
现实情况下,既然靠单个人或角色解决不了的问题,那就靠团队,靠良好的组织协作、靠共同遵守的架构契约来完成。
这里我是从运维的角度来考虑架构契约,可能更多的还有前后端架构契约、接口设计契约等,这个更偏向开发内部自行遵守,就不班门弄斧了。
2、架构契约中的运维部分—架构标准化
上面提到的团队和团队协作,这不多说了,组织定期的例会讨论,多参加彼此技术方案会议,随时随地的交流,这个只要保持开放的心态和合作模式都是可以做到的。
还是想再说一下,千万不要出现,开发说这个应该是运维考虑的事情,跟我们无关,运维说这个应该是开发的事情,开发想不清楚让我们怎么办?
如果都是这种心态就完蛋了,建议双方都往前走一步,大家要有共赢的心态才可以。
但是沟通讨论及会议只是形式,最关键和重要的是各方要能制定出共同遵守的架构契约来。
简单来说,就是要遵循统一的标准,并使其横向延伸到运维阶段的平台中去,一脉相承,比如发布系统、监控、稳定性等平台系统,从而使得运维的体系能够更好地支持业务架构体系。
而不是我们之前所说的,每个运维的平台都是一个个孤岛,无法形成体系。
重点谈谈关于架构标准化,之前提到的标准,更多的还是偏运维层面的标准,比如硬件资源标准、应用标准、部署标准等。
但是架构标准就很少有提到了,直观看上去这一点跟运维并没有很大的关系。
但事实正好相反,我们可以一起分析下。
按照我们自己的经验,在做业务服务化的早期,我们也没有意识去关注架构标准,结果就会出现以下几个场景:
(1)分布式服务化框架,虽然绝大部分团队用Java,但因为有的团队对PHP特别熟悉,所以就用PHP去做服务化,后面遇到的问题就是Java的服务化接口和PHP的服务化接口该怎么相互调用,所以到了后来我们的服务化框架还要提供PHP-Proxy来适配PHP的服务化接口;
(2)分布式DB中间件,有的团队觉得我们自研的分布式DB框架不好用,对分库分表的支持不够友好,就去自研一套出来,或者去引入其它的开源的框架进来。
平时使用没问题,但是到了后期要做一些统一的策略就很难搞,比如DB访问策略、账号密码管控、路由策略优化、慢SQL统计和优化等;
(3)分布式的缓存,有的直接使用Redis,Redis可能还会有主备或者Cluster,有的搞个开源的Codis方案等;
(4)接入层上,有的期望用Nginx直接做7层负载,版本上有期望用TEngine,有的期望用Openresty,还有的期望用LVS有个VIP就够了;
(5)稳定性上,比如全链路,如果要做统一的Trace打点,本来在一套框架上就可以实现的,结果要再多个框架上实现。
对于开关、限流、降级这些策略也一样,很难统一。
实际上为后续的体系建设增加了很多额外的工作;
(6)上线后的日志采集,因为跟其它团队使用的框架不一样,自己在搞一套日志采集的系统,说白了都是ELK,但是因为太个性化不统一,只能自己搞个;
(7)……
以上还不包括之前提到的类似于Java版本、启停方式、web容器类型、各种部署目录等。
所以到了运维阶段,不统一不标准,压根就没法玩下去了。
这时我们就不难理解,架构的标准对于运维阶段的建设其实是有决定性的意义的。
可能有的人会说我们做得low,管理上有问题,我不否认,现在回过头来看,当时确实是low了,管理上确实无意识没经验。
不过在当时的情况下,特别是在初期,除非团队中能有一个技能和经验非常全面的角色,端到端hold住全局,否则只能是靠摸爬滚打摸索出来。
现实情况,我之前经历的多个项目,包括在华为的大型的电信和互联网项目,以及当前我接触到的很多的队也仍然还是这种玩法,必然得走很长一段分久必合的道路才能走到正道上来,而且这种能力超群的牛人,我不敢说没有,但是我能遇到的真的凤毛麟角。
根本上,还是经验意识上的缺失,而且在这一块,架构的资料中貌似很少有涉及到这一部分的内容。
当然,最终期望这样的经验能够给到业界一些帮助和指导。
所以这时,运维必须要有意识参与进去制定架构标准,并强势地约束,所谓的约束是要体现在技术平台上的,比如在发布系统和安装部署上做约束,以Java举例,只支持固定1-2个Java版本,目录都约定好,容器约定好,服务化的框架约定好,这些约定好之后,如果线上要做变更,做发布,必须接入这套体系,否则坚决不让你上线,而且到了后面随着集群规模的增大,开发想绕都绕不开,因为完全靠手工已经是不可能的事情了,比如下图,是一个应用单机的发布部署过程,如果这个应用有100台机器怎么办?
再比如,稳定性上,我们做全链路,我们只针对标准的分布式框架做打点(当然精力有限,也不可能支持所有的框架),如果你选择的不是标准框架,而是自研或自己引入的,抱歉,打点只能自己做。
这时遇到性能瓶颈或链路上的异常,如果使用的是标准框架,有全链路根据平台的支持,日志采集、分析和报表呈现就很方便,问题定位过程相对高效一些,如果不是,抱歉,只能手工地去定位了,一个请求分布那个应用的那台机器上去了,在这样一个分布式的环境中,效率可想而知。
同样的,开关、限流、降级策略下发等,一样会有相同的问题。
作为线上资源的控制者,稳定性的Owner,运维,你有权利SayNo!
当然,历史原因造成的架构标准不统一的问题,是需要Dev和Ops共同合作去改造的,而不是很强势、单纯地去提要求,这个涉及双方合作方式的问题,后面再单独写篇文章。
运维需不需要懂产品和运营?
1、架构实施和架构运维
我们制定或约定了架构标准,接下来就是架构的实施过程,架构实施应该怎么理解呢?
我大致列一下过程应该就比较清晰了:
(1)业务分析过程中,职责明确的业务模块从整体中拆分出来,比如用户、商品、交易、支付等业务逻辑;
(2)从服务化的角度拆分,这样一个大的业务逻辑可以拆分出更细的服务化模块,以商品为例,会有商品详情、库存、评价、价格、标签等,如果继续细分可能还会有各种读写逻辑的功能化服务拆出来,拆分的原则我们这里不细说,这个基本取决于业务架构师的判断标准;
这个阶段拆出来的一个个模块,就是我们所说的应用了,这时就要开始应用名的定义,至此,一个应用的生命周期开始启动。
(3)应用生命周期启动后,应用相关的信息就需要在运维系统内生成了,也就是我们所说的CMDB和应用配置管理相关的信息。
重要的跟运维相关的如应用对应的Gitlab地址、基础软件模板和配置、以及对应的开发、测试和线上的资源需求;
(4)根据上面拆分出来的应用,开发同学就要根据我们之前约定的架构标准,开始选择标准化的框架了,比如分布式服务化、消息、缓存、DB中间件、稳定性和一些第三方的SDK包等;
熟悉开发的同学都很清楚,上面这些框架选定好之后,按照SpringBoot的模式,可以自动生成整套的代码框架,就省去了手工引入各种二方包、三方包和一些固定的配置,也就是SpringBoot的“约定大于配置”的思路。
这个也是目前绝大部分团队的选择的微服务的应用模式。
这样开发同学可以把更多的精力放到业务逻辑的实现上,而不是各种各样的框架引入和配置上面。
所以,不仅仅是运维自动化,代码开发也一样在朝着更加自动化的方向发展。
(再进一步,SpringCloud的体系则更加完善)
(5)启动业务代码开发后,就该进入到持续交付阶段了,不过前提是得先有持续交付的体系;
(6)业务上线后,就进入持续运维和反馈阶段,如监控数据的分析、稳定性保障、核心应用和链路的容量评估、应急预案的制定和演练、强弱依赖的分析,以及从用户提交角度的数据分析和保障措施等;
(7)应急事件和故障的响应、处理及回溯机制,因为故障没有办法100%的避免(但是应该杜绝低级的人为失误和重复错误),我们要做的是故障的快速甚至是提前发现、业务的快速恢复,以及故障后的回溯和改进。
按照《聊聊架构》书中的架构生命周期的划分,上述过程,我们认为是架构的实施阶段,不过1-4,更多的可以看成是开发为主进行实施的,5-7阶段则应该更多的是运维为主的阶段(如果持续交付做的好,其实5也是可以以开发为主)。
不过,我的理解应该将5-7这个阶段拆分出来,定义成架构运维或架构看护阶段。
图示下来,就是如下过程:
从上图我们就可以看出,运维应该要体现的作用和价值了。
2、运维的角色转变和价值体现
(1)技术产品
产品是指能够提供给市场,被人们使用和消费,并能满足人们某种需求的任何东西,包括有形的物品、无形的服务、组织、观念和他们的组合。
(摘自XX百科)
整个运维过程中,运维一定要转变被动响应式的工作方式,要主动求变,其中最重要的就是树立起产品意识,将日常的人肉、繁琐重复的工作不断地总结和提炼。
比如,是不是能够把自己原本靠人工完成的很多工作转化成需求?
是不是能够把日常工作中运维和开发的痛点转化成需求?
是不是能够把当前系统存在的问题和隐患找出来,在解决的过程中,经过分析总结提炼成需求?
当需求提炼出来之后,是否能够准确的传递给工具开发团队,并跟工具开发团队一起把需求真正的落地实现?
以上过程,就是将运维的人肉能力转化为平台能力的过程,比如持续发布,没有发布系统之前,完全靠人肉堆,开发、测试和运维一起上,还经常出问题。
但有了发布系统,将人做的事情转交给平台自动化去做,最终满足开发快速将代码发布上线的需求。
结合上面对产品的定义,看看我们上面做的事情,是不是就是一个技术产品的工作呢。
当我们具备了这个意识,能有更多的工具做出来,逐步形成体系,我们的工作是不是变得更轻松了呢?
(2)技术运营
运营的目的,和产品经理核心的不同是,要实现扩散,爆发,增长,收益等等。
(摘自知乎)
通过上面技术产品的工作,如果可以做出一些有针对的工具和平台来,但是仅仅有工具和平台就够了吗?
不过,远远不够,为啥这样说呢?
(1)推广落地,工具做出来了是第一步,得要有人用,这就需要去推动落地。
(跟业务上做出一个产品来,要去找渠道推广,要吸引流量过来,并最终产生经济收益是一个道理。
)当然,我们在内部倒不必吸引用户来用,因为我们的技术产品更多地是标准、流程和规范的载体,既然大家之前都遵守了这套标准体系,那就必须使用(使用之前做些小范围的试用还是必须的),所以这个过程是可以强势一点的。
比如线上仅保留发布系统一个变更入口,其它变更权限全部收回等。
(2)线上运行数据分析,应用上线或者每次变更上线后,线上运行的情况咋样,容量有没有降、RT有没有上涨、监控有没有异常,业务量上是否有激增、用户体验有没有下降,用户和客服的反馈如何等。
以上这些维度和指标就需要一张张的数据报表呈现出来,通过数据分析来指导我们要做出哪些优化和调整。
(想想看,业务运营是不是也非常关注业务数据报表的)
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 企业 架构 角色 转变 价值 体现