一个平台系统架构师的能力模型是啥

春哥叨叨

共 1580字,需浏览 4分钟

 ·

2021-03-27 00:38


之前的文章分享过我自己琢磨的一个技术高P的能力模型(参见:高P的能力模型),其中的一个方向是cover端到端解决的能力。那怎么叫端到端解决方案的能力呢?


我自己想了下,一种切入端到端解决方案能力的方式是涵盖:大前端(PC && APP && H5 && 小程序等)-> 服务端(通用的服务端系统架构)-> 数据端(端到端数据的治理与优化)。


我个人发展的方向应该是走这条线的,原因之一是另一种“领域专家”路线,对于业务复杂度是有一定的要求的,中小企业其实很难有这种横向领域挑战的规模的,而大厂这个方向的坑位也有限。


而这种端到端方案机会更多一些,一个不大的业务,如果通过这种端到端串联起来的话,其实能做的事情也不少。更重要的是,这种端到端能力的闭环,也更有助于完善业务能力,因为他某种程度上涵盖了“供给-需求”的全链路。


大前端


这种如果我take的话,肯定还是专业的人做专业的事,比如移动端、前端、Flutter等找到一些资深的同学,cover技术栈即可。我个人可能更多的是参与到一些技术选型评估、前后端协作成本、研发工具提效等工作,侧重点还是效能与协作,专业技术无需介入太多。


服务端


这部分我应该算是比较擅长的,毕竟做了这么多年。其实叫服务端并不能体现这种后端系统的涵盖范围,我更喜欢叫做“平台系统”。


什么意思呢?


就是说,不是简单的一个服务端系统,或几个微服务系统。而是多个微服务组合在一起,对外提供某种集成的能力。而这种能力,随着业务发展会承载多个业务线、多种品类在一起,某种意义上就变成了一个平台。


做好平台很重要的一点是边界与抽象。


边界是识别平台系统和一些服务能力使用方的边界,这种边界的识别,我一般以用户行为动线,或运营模式角度展开,找到边界,划定能力。


抽象是识别到变与不变的逻辑。变的部分是否搞个前台消息体收敛复杂度?不变的逻辑是否主要以配置化方式解决?


怎么做呢?


从业务场景出发,收集业务对SDK的需求,评估业界最佳实践方案,结合当前现状,从可落地、维护成本、实施成本等方面对平台方案进行评估。


为体现平台能力,需要做好一站式平台能力的维护、管理、可视化、操作等设计。


平台系统对所有业务赋能,需要保障其稳定性、可靠性、做好融合接入成本低、高可用的一些设计。


平台系统承接多业务,在完善了多业务接入之后,需要在容灾及成本角度做些考虑,如从节省成本、高效协作等角度,以租户方式实现个性化业务接入、隔离、快速部署、安全伸缩、自动化监控、故障自愈等技术动作。


当然做好统一的基础技术动作,比如限流、熔断。工程化手段优化、降低生产运行中低效、繁复的非标准化动作的设计也是一个考验。


一站式全链路监控平台,围绕于技术指标与业务指标做好诊断与波动感知。


看起来还是服务的基本动作。


数据端


如果想要做好端到端解决方案的话,数据端是必须有所关注的,它体现了你做的前面动作(大前端、服务端)的好坏。


我们做事情以目标为导向,而目标中很重要的一点就是以数据的方式体现收益与产出,缺少了这一环,你就很难量化你做的事情的意义。


还有一点就是,有了数据我们会知道我们哪些方面做得还有所欠缺,这样他就会变成我们下一阶段做事的指引和牵引。做规划一般以两个点切入:目标驱动、问题驱动。


现状与目标之间的gap就是存在的问题,对问题进行分析和定义之后,我们找到一个可落地、可演进的路径,就是我们做事情的主要动作,而数据可以很大啊程度上丰富这件事情,使得有理有据。


其他的后面想到再谈吧,完。

浏览 9
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报