26 结束语 | 一个架构师的一天
你好,我是李智慧。
时间过得真快,聊着聊着,这个专栏就到了尾声。恭喜你完成了这一阶段的学习,向架构师又迈进了一步!
在这里,我想问你一个问题:学完这个专栏,除了架构知识以外,你对“架构师”这个角色有了哪些新的认知呢?毕竟这个专栏的Slogan就是“附身”大厂架构师,我还是非常希望能为你代入架构师视角,体验这个角色的高光时刻。
我们这个专栏的案例,大多是一些庞大的系统,每个案例在真实世界中,都对应着一家数百上千亿美元市值的公司,需要数千名工程师开发,需要部署数万台服务器的系统。这样的系统不可能是由一个架构师设计出来的,正如开篇词所言,我们的设计是一种架空现实的设计。学习这种架空现实的设计,可以帮助你站在上帝视角,俯视一个个庞大系统的核心关键技术和整体架构,进而帮你构建起全局化的思维方式,而这正是架构师最重要的竞争力。
现实中,拥有一个庞大系统的公司通常有上百名的架构师,他们的日常工作也不是去设计整个系统,而是在自己负责的模块或者子系统内修修补补。所以在结束语里,相比于前面宏大的设计,我想做点“接地气”的内容,带你“穿越”成一位真正的架构师,感受架构师这个角色典型的一天。
我们以某大厂商家管理后台系统的架构师为例。商家管理后台是电商卖家的后台管理系统,卖家上下架商品、投放广告、查看运营数据等操作都在这里完成,是面向卖家的核心系统。商家管理后台开发部20多个人,分了4个开发小组。
9:20 到公司,翻看昨天的邮件和聊天记录,看看有没有遗漏的事情。昨天下午数据库连接阻塞,连累应用服务器响应超时,焦头烂额搞了一下午,很多聊天消息都没来的及处理。翻了一下还好,没有错过什么重要的事情。
9:30 开部门小组长晨会,开了10分钟会,今天晨会时间控制得不错。
9:45 作为主讲人主持“商家管理后台架构重构设计”部门评审会,这次重构是商家后台最近两年最大的一次重构。已经和几个开发小组长还有核心开发人员已经讨论过几次了,这次做部门评审,事实上是做重构宣导,要让所有开发人员都统一认识,所以会上争议不多,开得比较顺利。另外,这次重构设计画了很多UML模型图,评审的时候也趁机给大家再普及了下设计建模的重要性和方法。
11:00 参加另一个部门的架构评审会,会上他们部门的架构师和一个开发组长吵起来了。晕,自己内部还没统一意见,就不要拉别的部门的人来看戏了。开会是用来统一意见和思想的,不是用来解决问题的,问题要提前解决。趁他们吵的间隙,上极客时间看看有什么有意思的课程,发现《李智慧 · 高并发架构实战课》挺有意思,订阅了。
12:00 午饭。
13:30 这次架构重构引入DDD(领域驱动设计)方法,上午的评审主要从DDD战略设计的角度对架构进行重构。DDD战术设计感觉不太好掌控,先暂时不在部门推广了。自己先写个DDD代码Demo练练吧,用哪个功能做Demo呢?红包管理功能吧。上半年公司架构师委员会例会上,也有几个部门的架构师提出要搞DDD,结果没了动静,这个螃蟹看来还得自己吃。
15:11 一个开发同学过来讨论技术问题,聊了十来分钟,越聊越觉得不对劲,把产品经理也叫过来讨论,确定这个需求是有问题的,先暂时不开发,产品经理回去重新梳理需求。继续写Demo代码。
16:03 收到运维部门的会议邀请,明天上午10:30复盘昨天的数据库访问故障。麻烦,这个故障看起来是数据库失去响应,其实是个程序Bug,线程阻塞导致数据库连接耗尽。这个故障影响不小,责任主要在我们部门,看看会上怎么说,能不能让运维部门也承担一点故障分,毕竟他们数据库管理也没做到位。也不知道明天参加会议的运维是哪个,好不好说话?继续写Demo代码。
16:42 收到监控报警通知,商品上架数异常波动,低于正常值60%。是商品上架服务出问题了?赶紧打开监控系统,上架服务系统指标正常;打开日志系统,异常日志数正常。什么情况啊?问问运维。哦,原来是监控数据消息队列消费服务出了点问题,数据统计有误,触发报警,虚惊一场。继续写Demo代码。
17:08 公司负责培训的同事发来消息,问能不能做个性能优化方面的内部讲座,面向全公司的开发和测试人员。可以呀,什么时候讲?下周五。好的。时间有点紧啊,不做Demo了,先做讲座PPT,毕竟公司级的讲座,难得的提升技术影响力的机会。不过,性能优化这个话题有点大啊,从哪方面入手呢?对了,上午看到的李智慧的专栏里面有一篇性能优化的文章,看看他怎么讲。可以,就按这个文章的思路准备讲座大纲。离下班还有一个多小时,做PPT来不及了,先收集下PPT素材,案例部分用公司内部的,理论部分Google一下,不错,就这样……
上面就是这位架构师一天的经历,你认为他的工作怎么样呢?大部分人都希望工作轻松一点,你觉得文中这位架构师的工作是否轻松?以及什么样的工作是轻松的呢?
首先,清闲的工作未必是轻松的,工作不忙、无所事事,会让人觉得自己失去价值,进而产生焦虑,最后并不轻松。轻松的工作应该是自己做的事情有意义、有价值,还能在工作中不断获得进步;同时工作又游刃有余,自己可以掌控工作,而不是被工作驱赶着疲于奔命。
架构师最核心的事情是要控制技术局面,让事情有节奏地推进,不要鸡毛蒜皮,做决策的人越是忙忙碌碌,团队效率越低。文中这位架构师做到了这一点,他基本上掌控了他的工作,而不是让工作push他。大部分时间,他可以按照自己的节奏安排工作;突发的情况,他也能比较从容地应对。
他做事情看起来似乎毫不费力。事实上,他要处理的很多事情,都是一些既复杂又困难的事情,是别人搞不定了才到了他这里来的。他既要考虑各种人际关系,又要用技术做出判断,还要对判断结果负责,而且要有威望让别人听他的。此外,他还有时间学习、有时间写代码、有时间做设计、有时间扩展自己的影响力,还能按时下班。
其实,做事情要想看起来毫不费力,必须要在看不到的地方费很大力气,进行很多的积累。你也可以问下自己,自己现在每天都做些什么?多长时间用来学习,有没有帮助别人解决问题,有没有考虑积极做些分享扩展自己的影响力,还是只是低下头盯着自己脚下的这块巴掌大的地方呢?
当然,在工作中能达到这位架构师这样的境界并不容易,也不是成为架构师就可以这样工作。但是只要你想往上走,就需要不断学习,有目的地在工作中提升自己,并且主动找机会展示自己的综合能力,构建自己的影响力。相信最终你一定可以掌控自己的工作,还有人生。
希望这个专栏可以在你进步的路上提供帮助,使你对更宏观的知识和实践建立起感性的认知和清晰的目标,然后不断夯实自己的实践能力、拓宽自己的影响力,最后成为你想成为的自己。