首页 > 其他分享 >架构优化与业务迭代,你会怎么选?

架构优化与业务迭代,你会怎么选?

时间:2022-11-11 23:03:47浏览次数:44  
标签:架构 迭代 系统 业务 紧急 重要 优化


引子

对于每个软件系统,我们都可以通过业务和架构两个维度来体现它的价值。

尤其是软件开发人员,应该确保自己的系统在这两个维度上的实际价值都能长时间维持在很高的状态。

不过很可惜,他们可能更多情况只关注一个维度,而忽略另一个;

假如关注了错误的维度,这导致了系统价值最终趋降为0,非常可惜。

本文大纲

1、业务与架构兼顾的难题

2、业务与架构哪个更重要?

3、研发更需要关注什么?

4、可供参考的实践方案

1、业务与技术兼顾的难题

在我们日常工作中,业务迭代支持与系统架构技术优化就如同鱼与熊掌一样,不可同时兼顾。

case1

当我们发现系统性能有些差,评估需要考虑优化一下,降低系统接口平响,同时提升用户体验...

但是这时候产品同学风风火火的跑过来说,最近有个业务改版需求/新业务功能需要紧急上线支持一下.....

Q:你会怎么办?

-- 要不技术优化的事,等这次需求完成后再说吧...

case2

我们的每到年初就要做得技术规划,是不是总感觉计划赶不上变化...

每到年中、年末复盘时候,现实总会与规划大相径庭,要么是规划的事没有做或者换了个低成本方案简单实现了,要么是中途出现了一些新的事情打乱了原来的规划计划。

Q:重新来一遍,你会怎么来避免?

-- 规划 vs 变化

以上的情况工作中大家应该挺常见的,那遇到类似的问题我们应该秉承什么原则呢?有没有有效解决的措施呢?

2、业务与技术哪个更重要?

美国前总统艾森豪威尔提出个经典的“紧急/重要矩阵”。

我有两种难题:紧急的和重要的,而紧急的难题永远是不重要的,重要的难题永远是不紧急的。

架构优化与业务迭代,你会怎么选?_算法

虽然有点老调重弹,但其中的道理依然成立。但实际情况确是:紧急的事情往往没那么重要,而重要的事似乎永远排不上优先级。

Q:哪个维度更重要?

在研发同学看来,重要级别一目了然:

重要的事:架构设计优化,让系统具有足够的“弹”性

紧急的事:业务迭代支持,让系统支撑业务持续发展

例如:日常业务迭代支持一贯紧急高优,但从架构设计合理性建设看来,似乎没有那么多关联;而系统技术优化看来很重要,但往往没有机会排的上期。

关于哪个更重要的讨论,当然仁者见仁智者见智

假如对于这个问题,由业务部门来回答,那就是业务更重要-系统支持业务迭代,保障业务正常发展很重要。

3、研发更需要关注什么?

我们可以试着将此四类情况做下排序:

1)重要且紧急

2)重要不紧急

3)不重要但紧急

4)不重要且不紧急

系统架构设计优化:重要(占据第1、2位)

业务迭代支持:紧急(占据第1、3位)。

但是我们日常工作中,业务部门与研发部门经常犯的错误就是将第三优先级的事情提到了第优先级去做。将重要的系统技术优化事项被业务迭代所排挤。

我们研发人员经常会抱怨,没有时间来做技术优化,自我调侃为:“又在搬砖...”、“又在加班写BUG了...”

似乎我们忘记了:业务部门就是只盯着业务的,对于系统架构的评估和优化,本来就是研发人员的工作职责!

如何平衡好这两者的工作,是研发人员的晋级修养之路。

不要忽略系统架构的价值,假如有一天系统难以维护到只能推翻重来的地步,可以说是系统技术优化跟不上业务快速迭代,同时侧面说明了研发同学的本职工作做得不够格。

4、可供参考的实践方案

上面说了很多技术架构优化与业务迭代支持两者难以平衡的难题。那有没有可以平衡的好方法呢?

我从自身工作实践中整理一些经验,主要就是“总-分-总”的原则,供大家试用参考:

1、【总】项目立项,评估目标收益

做事要有价值,尤其技术优化类项目,一定要想明白收益点是什么,同时搞清楚投入产出的性价比如何。

这个阶段建议多花点时间,多调研分析下,建议目标尽量可量化,可达成。

【项目目标制定-示例】

项目:XX系统性能优化

目标:系统服务平响 <= 200ms(90分位值 <= 500ms)

2、【分】拆分细化,评估优化改造范围

确定目标后,需要将目标进行动作拆解,并评估每项动作的目标达成占比以及优先级。

功能点拆分注意要以终为始,保障不要偏离目标。

具体的方法可参考:

1)按流程逻辑拆分

2)按工作模块拆分

3)按数据流拆分

可能前期对于各个点的评估并不一定太准,允许后期调整,但不应该大幅度调整,否则需要重新做下考量。

【项目细化拆分-示例】

并发、服务依赖优化、cache、表结构拆分、表索引优化、逻辑优化(循环套循环)、Redis 大Key优化、资源隔离 等等

3、【总】归类收敛,规划可行的项目里程碑

功能评估按同一类型进行归类,将各子优化项拆分到日常业务迭代中去,或者穿插到各需求开发间隙中去,小步快跑,保障项目稳步推进。

【归类收敛-示例】

架构优化与业务迭代,你会怎么选?_敏捷开发_02

4、【保障】汇报跟进,项目迭代进度推进

可建立以每周为单位的项目汇报制度,召集相关同学定期例会跟进,项目进度&问题持续Review,保障项目整体推进进度。

项目进度汇报主要关注点:

架构优化与业务迭代,你会怎么选?_算法_03

总结:

很多人将业务与技术之间理还乱的关系称为“相爱相杀”,其实技术与业务并不是对立的,而是相辅相成的。

技术作为理论基础,业务作为实践去检验落地。我们所学的技术,业务是我们的落地点,业务成功了同样能反衬体现出技术价值。



架构优化与业务迭代,你会怎么选?_敏捷开发_04


标签:架构,迭代,系统,业务,紧急,重要,优化
From: https://blog.51cto.com/u_15107509/5845527

相关文章

  • 【深入浅出 Yarn 架构与实现】2-4 Yarn 基础库 - 状态机库
    当一个服务拥有太多处理逻辑时,会导致代码结构异常的混乱,很难分辨一段逻辑是在哪个阶段发挥作用的。这时就可以引入状态机模型,帮助代码结构变得清晰。一、状态机库概述一......
  • 92-《P7云原生架构师2期》09-云原生架构体系-负载均衡器_ev 看到这集,看不懂
             ......
  • 网站架构 (转载)
    网站架构一:硬架构1:机房的选择:在选择机房的时候,根据网站用户的地域分布,可以选择网通或电信机房,但更多时候,可能双线机房才是合适的。越大的城市,机房价格越贵,从成本的角......
  • .net 大型分布式电子商务架构说明
    构建具备高可用,高扩展性,高性能,能承载高并发,大流量的.net分布式电子商务平台的架构说明。其中包含基础框架沉淀,分库分表,基础服务架构(消息队列,任务调度......
  • Linux性能优化和内核观测 - 内存篇(一)
    内存虚拟内存Linux采用的是​​虚拟内存​​机制,每个进程都有自己的虚拟内存地址空间,仅当实际使用内存的时候才会映射到物理内存地址之上。这种设计提供了物理内存的超额分......
  • EBI、DDD及其演变架构史
    一、引子聊架构总离不开“领域驱动架构”,大多能聊到DDD(Domain-DrivenDesign),实际上早期思想EBI架构1992年就诞生了。核心价值点在于:关注核心业务领域(高内聚),分离实现层(低......
  • MySQL优化常用的19种有效方法(推荐!)
    关于数据库优化,网上有不少资料和方法,但是不少质量参差不齐,有些总结的不够到位,内容冗杂,下面这篇文章主要给大家介绍了关于MySQL优化常用的19种有效方法,需要的朋友可以......
  • 实现企业混合云架构两大关键能力​
    混合云的实现涉及异构系统的连接与整合,与具体业务场景相关,技术实现都需要比较高的复杂度。构建混合云的核心思想就是保证混合云产品拥有连接一切​一、连接一切IT设备的能力......
  • SEO内链作用是什么,seo内链优化怎么做?
    在做网站优化过程中,我们需要对网站进行SEO内链优化。内部链接优化是SEO优化的一个重要部分,对网站来说,做好自己,把内部链接做顺,做透,价值会更大。那么,SEO内链作用是什么,作为新......
  • 拓端数据|R语言代写解决最优化运营研究问题-线性优化(LP)问题
    使用R中的线性编程工具来解决优化问题。优化通常用于运营研究领域,以解决生产计划,运输网络设计,仓库位置分配和调度等问题,我们尝试最大化或最小化具有决策变量和约束数量的线......