架构师的技术领导力之路:看环信一乐聊些什么

简介:

小欧有话说:

全球技术领导力峰会(GTLC)30日【Tim会客厅】环节,迎来了EGO北京分会第2小组的3名成员——环信首席架构师梁宇鹏、爱因互动联合创始人兼CTO洪强宁、当当架构部总监史海峰,一起聊聊他们的技术领导力之路。

主持人(左一):杨卫华(Tim Yang),新浪微博研发副总经理

从技术人到领导者

Tim:大家先做一个简单的自我介绍吧!

梁宇鹏:在技术圈大家都叫我一乐,我来自环信,这是一家做即时通讯云服务和全媒体智能客服的公司,我是环信的首席架构师,同时也兼任IM事业部技术总监,负责即时通讯云服务产品线。

史海峰:我现在在当当负责架构部,之前在神州数码和亚信做电信业务系统集成,做过七年北京移动的项目,来到当当四年多,如果大家是北京移动的号码或者在当当买过书的话,都是我的衣食父母。

洪强宁:我之前在豆瓣网做首席架构师,2014年到了宜信做首席架构师,现在创业,和豆瓣首席科学家王守崑一起创办了爱因互动。

Tim:各位从刚毕业到目前的位置,其中有哪些难忘的事情或者关键的事情?怎么能够成为像你们这样的“老司机”?

梁宇鹏:

我在微博工作了几年,Tim是我的老领导,在微博负责聊天、通讯系统,一开始我也是一心钻研技术,当时整个IM系统即将到达千万级的时候,大家都想做一个酷一点的中间件,这个方案当时出了好几版,一到这儿被枪毙了。当时Facebook做了一个通讯中间件,我当时很不理解,每天拉着Tim讨论,“这个东西业界肯定还缺,而且我们一定需要,就想做这个东西,为什么不能做?”讨论了半天,后来Tim问我一句话,“你觉得现在的系统能不能搞得定?”我说“能搞定”,他其实也将信将疑,说“你证明一下现在的系统搞得定”,我证明完之后,这个中间件没有下文了,觉得现在系统没有问题了,不需要做中间件。

后来想起来这是对我影响比较大的一点,从那之后,不再单纯地去追求做一个能写很酷的中间件的技术人员,会换个角度来思考我们团队需要什么样的东西,或者当前的团队能做到什么样的程度,如果能做到足够好,那么就去想这是不是你最需要做的。我觉得这个事情对我触动很大,当时整个观念都变化了,中间的沟通过程也是比较痛苦的,因为当时我每天都觉得我有一个理想,我要去实现,然而并没有得到支持。

现在在环信做的通讯协议、IM协议,这是原来我们也想做的。2012年移动互联网来了之后,都要做面向移动互联网的IM协议。除了中间件,还有很多可以做,比如现在做的跨全球远距离数据同步的后端系统等等。我不觉得我放弃了追求,而应该是自身的一次蜕变,因为我知道有很多技术可以做,而且也可以跟业务结合起来。

Tim:从我的角度补充一下,作为一个技术人,在大部分环境里面,你要做的事情很多时候确实是够用就行了,大家可能听说过很多反面的情况,一些技术负责人做了不恰当的决策,导致整个技术团队陷在泥潭里面,最终产品没出来,而且大家很累,也没有成就感。

梁宇鹏:我们做微博的时候,Twitter天天宕机,技术体系转来转去,折腾了好多轮。在技术人员心中,大家就觉得技术氛围很好,也很愿意折腾。我觉得我们微博这块虽然技术上走得慢一点或者走得很稳健,但是在服务质量上业界都看得见。我现在比较理解了,我会告诉大家什么先不要做,先把最主要的事情做完。

史海峰:我说一点,希望对在座的各位有一点借鉴意义。因为我之前是做电信软件的,现在在当当,从传统IT转到互联网这个过程还是挺痛苦,也挺刺激的。刚到互联网公司,对于常用技术、架构、场景,包括电商这一套业务都不是特别了解。而且大家都知道,互联网公司人员流动大,没有什么文档,很难快速切入。我凭着一些坚持,找各种机会去了解,有时候厚着脸皮跟人聊,哪怕他不愿意搭理你,最后发现自己应该是有一些钝感力,就这样坚持下来,让大家认可了我,在当当也待了下来,还算是转型成功。总结一下,就是坚持做一些别人做不了或者说不愿意做的事情。

洪强宁:坚持很重要。怎么成为“老司机”?我是足够老了,开始进入IT这个行业大概是上小学时,找了一本书开始自学,那时候就决定自己要做一个程序员。大学毕业后,终于找到了一个正式的程序员工作。最开始是做嵌入式系统,也是在那个时候接触到Python这个语言,也很喜欢,在Python社区也很活跃,2005年豆瓣的创始人给我发了封邮件,问我要不要一起干,我就过来了。随着豆瓣规模越来越大,我的重心慢慢转移到平台这个层面,在这个层面学到了很多东西,也得到了架构师的头衔。

另外一个转变,是我从豆瓣离职,到了宜信担任首席架构师,眼界得到了提高,看到了不一样的公司中不同的管理方法,从这个时候开始对管理产生了兴趣,也诞生了我要亲手创造一个伟大的公司的想法。今年6月份,终于开始创业,这对我来说是人生的一个大转变。但是不管怎样,最重要的是坚持。我一直觉得技术是能够改变世界的,我能够通过自己的手去让这个世界变得更美好一些,这是值得奋斗一生的事情。

Tim:从技术人到领导者,你们的心态发生了哪些变化?

梁宇鹏:原来觉得自己加一加班或者自己熬一下夜,这个程序就做完了,现在要调整自己,如果他们觉得做不完,你要不要接受这个状态,能不能补救,而不是推着他们一定要这样做。总之就是,知道什么不要做,知道什么你做不到。

史海峰:我来总结的话,就是“以德服人”。一乐说得特别好,以前面对的更多是机器,都是标准化的,现在面对的是一个团队,每个人都不一样,领导一个团队的话,不要求在每个技术领域都比团队成员强,最重要的是在最基本的素质和为人上超过他们,对自己的要求要比对他们的要求更高,要学会控制自己。

领导者有时候的一些方式方法,大家未必会接受的,这样实施起来会有一些抵触情绪,需要领导者更好地琢磨怎么去调整,最好的办法就是以身作则。


洪强宁:我给所有的技术人的建议是保持不断学习,但是如果是技术管理者这个群体,我的建议可能更加务实一点,就是做好授权这一件事情,不要把所有事情都把握在自己手上,把权力下放到团队去,给他们更多的自由度,创业公司效率为什么比大公司高很多,很重要的原因是创业公司几个人一碰头就可以把这个事情决定了,大公司要层层上报,最后可能就不了了之了。把权力下放,找到合适的人让他放手去做,团队成长得会更快,你也可以拥有一些得力的助手。

首席架构师之路

Tim:在座的几位都是非常优秀的架构师,你们典型的一天是怎么度过的?都做了哪些事情?

梁宇鹏:我一天最重要的两件事情,一是跟大家梳理架构,康威定律指出,公司的组织架构能够反映出公司产品的技术架构,如果我们的架构比较落后,那么瓶颈在我身上,因为只有我一个人能够把这个事情搞清楚,其他人都不明白,那么工作就没办法进行。所以我想的最多的事情就是组织尽量多的人,大家一起来讨论这个架构,最终大家就都了解这个架构,了解每个组件以及服务的权衡点在哪,就可以自己来设计这个服务。有很多创业公司的增长是非常快速的,如果没有一个很好的基础,那么流量来了的时候,大家压力就很大。架构能否撑得住,这个对我来说是最焦虑的。

Tim:作为首席架构师,跟其他架构师怎么分工呢?

梁宇鹏:为什么叫首席呢?因为每个人都有架构的思路和想法,我们团队至少一半以上可以做架构的,我来做的话,可能只是把大家的想法汇总起来,把大家不一致的观点组合起来找到一个一致的想法。

大家一定要达成一致,达不成一致这个架构其实没有任何价值,我觉得重要的是我让大家在有争执的时候,我们选择一个大家都能同意的点来开始做,这是我做的事情,还算比较重要的一部分。

史海峰:声明一下,当当还没有首席架构师,我主要的工作还是参与一些项目的架构设计,也会评审一些设计方案。我比较关注的问题是,如果在会议或者邮件中遇到一些不是特别了解的情况时,尽可能跟当事人当面沟通;技术债我都会记下来,很多东西都是我们来不及做或者说只是知道了然而怎么解决我们也不清楚,这种情况下,我就记下来,自己回头有时间再看一看。将来再遇到其他项目的时候,可能顺手能把这个事情解决了,这样能达到一石二鸟的效果,这是我比较关注的事情。

洪强宁:在豆瓣期间,刷豆瓣是我工作的一部分,因为豆瓣所有工程师,页面右上角会出现渲染时间,而且会有颜色标注。我每天关注的点就是一些关键的指标,我在豆瓣负责平台部门,我会关注性能指标、可用性指标,从中发现是不是存在问题。同时作为首席架构师,业务部门对于平台所有的需求,最后汇集到我这儿来,我会判断是否需要对架构做调整,更好地支持业务。在这个基础上,我会设计下一步的架构发展。我的原则是,作为架构师,可以超前设计一点,但是不要超前太多,有一定的冗余量,等到流量突然增加的时候,可以应付得了。

Tim:洪教授曾经是豆瓣的首席架构师,能不能介绍一个由你作为首席架构师发挥重要作用的产品或者技术?

洪强宁:

我在豆瓣主持的其中一个比较大的项目是豆瓣的服务化,豆瓣最早期的时候是一套代码,一个代码仓库,所有的产品都是应用这一套代码。随着业务的发展,这个代码量越来越大,峰值的时候50万行,会出现各种各样的问题,当时判断这种方式是不能持久的。我主持做了服务化的拆分,也设计了一些服务化的框架、辅助的工具,这差不多是我在豆瓣做的工作中,对于整个豆瓣的发展影响最大的事情。

技术与管理的平衡

Tim:对于技术领导者这样的角色,你们认为最重要的素质或者能力是什么?

梁宇鹏:对我来讲,心态特别重要,之前无论是做技术、做架构、还是写技术组件的代码,面对的都是机器,如果要做一个技术领导者,需要面对的是人,你就要调整自己好自己的状态,你面对的这帮兄弟们,他们的状态不像机器一样恒定,有些时候他的状态可能随着他的心情或者生活状态发生变化。

我经常用跑步来举例子,我跟团队很多兄弟一起跑,跑步这件事情,你会对自己能跑多远有一个期望,假设现在能跑10公里,那么跑马拉松就会有非常大的压力,对于技术人也一样,如果他自己觉得只能跑10公里,那么把他推到马拉松的级别,他可能会直接跟你决裂。所以最重要的是随时观察团队成员的状态,他们现在能到什么级别,你再去往前推动,而不是像机器一样,让他们发挥出100%的性能。

Tim:如何从一个写代码的角色转变到一个技术领导者的角色?怎么把握这两者之间的平衡?

梁宇鹏:我只能试着去平衡,因为我觉得写代码的时候应该是大多数技术人员心情最平静的时候,或者说最高兴的时候。真正去管人的时候,你会发现有太多的不确定性,可能相当于遇到了一段读不懂,但是永远有bug的代码,没办法,只能试着适应他,把他当成一个库来调用,我没有太好的经验。但是对我个人来讲,如果遇到问题,我会通过跑步去换一个环境,可能只是半个小时、1个小时,但回来之后能够静下心来。

史海峰:首先,一部分的同学是被动地被提到了一个管理岗位,很可能你的领导离职了或者去了更高的职位,由你来带团队。基本上最简单的是模仿,毕竟当过下属,你知道你的上级是怎么安排任务,怎么去跟踪,需要关注哪些点,这是最初的。

第二点,后来慢慢关注了一些方式方法,成熟的管理理论或者解决问题的方法论,你会发现很多东西有人已经琢磨得非常明白,只是自己之前没关注不了解。

第三点,做技术的人离开安全区的时候,都会有一个想法——我以后不能全天写代码了,我的竞争力在哪里。这要靠时间,靠团队协作,靠实践,慢慢去调整你的认识,你会发现团队能做更大事情的,你在其中做一个核心角色,这样才会更有价值。

洪强宁:我最开始的时候就是一个非常标准的程序员,什么事情都自己做,很快发现最后所有的事情都堆在你手上,忙得要死,你的团队其实工作并不饱和,这时你会逼迫自己去改变这个问题,我找到了方法,就是把自己的重心从实现变成设计,并且进行分解,分解出来的任务并行开发。从这个阶段开始,我的工作职责慢慢从实践者变成了管理者。

这个过程需要特别注意的是,要克制自己,比如你看到一个技术难题,特别想自己解决,结果陷入问题当中导致项目延期。另一方面,即使成为一个管理者,也不应该放弃技术,架构师还是要写代码的,因为这样才能知道你设计的东西是不是真正适合开发。随着管理的工作越来越多,真正写代码的时候,你给自己安排的代码任务不能成为别人的阻碍,像我现在写的代码更多的是一些偏研究性的代码,偏提升效率的工具,还有一些打杂性的工作,没人做的事情我来做,这样既可以不阻碍团队的开发效率,也不至于丧失对代码的理解。


本文转自d1net(转载)

相关文章
|
20天前
|
Kubernetes Cloud Native 微服务
探索云原生技术:容器化与微服务架构的融合之旅
本文将带领读者深入了解云原生技术的核心概念,特别是容器化和微服务架构如何相辅相成,共同构建现代软件系统。我们将通过实际代码示例,探讨如何在云平台上部署和管理微服务,以及如何使用容器编排工具来自动化这一过程。文章旨在为开发者和技术决策者提供实用的指导,帮助他们在云原生时代中更好地设计、部署和维护应用。
|
1月前
|
运维 Kubernetes Cloud Native
云原生技术:容器化与微服务架构的完美结合
【10月更文挑战第37天】在数字化转型的浪潮中,云原生技术以其灵活性和高效性成为企业的新宠。本文将深入探讨云原生的核心概念,包括容器化技术和微服务架构,以及它们如何共同推动现代应用的发展。我们将通过实际代码示例,展示如何在Kubernetes集群上部署一个简单的微服务,揭示云原生技术的强大能力和未来潜力。
|
13天前
|
监控 安全 API
使用PaliGemma2构建多模态目标检测系统:从架构设计到性能优化的技术实践指南
本文详细介绍了PaliGemma2模型的微调流程及其在目标检测任务中的应用。PaliGemma2通过整合SigLIP-So400m视觉编码器与Gemma 2系列语言模型,实现了多模态数据的高效处理。文章涵盖了开发环境构建、数据集预处理、模型初始化与配置、数据加载系统实现、模型微调、推理与评估系统以及性能分析与优化策略等内容。特别强调了计算资源优化、训练过程监控和自动化优化流程的重要性,为机器学习工程师和研究人员提供了系统化的技术方案。
133 77
使用PaliGemma2构建多模态目标检测系统:从架构设计到性能优化的技术实践指南
|
1月前
|
运维 持续交付 API
从零构建微服务架构:一次深度技术探索之旅####
【10月更文挑战第28天】 本文记录了作者在从零开始构建微服务架构过程中的深刻技术感悟,通过实战案例详细剖析了微服务设计、开发、部署及运维中的关键要点与挑战。文章首先概述了微服务架构的核心理念及其对企业IT架构转型的重要性,随后深入探讨了服务拆分策略、API网关选型、服务间通信协议选择、容器化部署(Docker+Kubernetes)、以及持续集成/持续部署(CI/CD)流程的设计与优化。最后,分享了在高并发场景下的性能调优经验与故障排查心得,旨在为读者提供一套可借鉴的微服务架构实施路径。 ####
64 3
|
1月前
|
存储 分布式计算 关系型数据库
架构/技术框架调研
本文介绍了微服务间事务处理、调用、大数据处理、分库分表、大文本存储及数据缓存的最优解决方案。重点讨论了Seata、Dubbo、Hadoop生态系统、MyCat、ShardingSphere、对象存储服务和Redis等技术,提供了详细的原理、应用场景和优缺点分析。
|
20天前
|
运维 Cloud Native 持续交付
云原生技术深度探索:重塑现代IT架构的无形之力####
本文深入剖析了云原生技术的核心概念、关键技术组件及其对现代IT架构变革的深远影响。通过实例解析,揭示云原生如何促进企业实现敏捷开发、弹性伸缩与成本优化,为数字化转型提供强有力的技术支撑。不同于传统综述,本摘要直接聚焦于云原生技术的价值本质,旨在为读者构建一个宏观且具体的技术蓝图。 ####
|
27天前
|
Cloud Native 持续交付 云计算
云原生技术在现代IT架构中的转型力量####
本文深入剖析了云原生技术的精髓,探讨其在现代IT架构转型中的关键作用与实践路径。通过具体案例分析,展示了云原生如何赋能企业实现更高效的资源利用、更快的迭代速度以及更强的系统稳定性,为读者提供了一套可借鉴的实施框架与策略。 ####
24 0
|
27天前
|
运维 Kubernetes Docker
深入理解容器化技术及其在微服务架构中的应用
深入理解容器化技术及其在微服务架构中的应用
57 1
|
1月前
|
监控 Java 微服务
从零构建微服务架构:一次深度技术探索之旅####
本文作为一篇深度技术分享,引领读者踏上自底向上搭建微服务架构的征途,旨在通过实战经验剖析,揭示微服务转型背后的技术挑战与解决方案。不同于常规摘要仅概述内容,本文摘要将直接以故事化手法,简述作者从单体应用困境出发,逐步迈向微服务化的心路历程,涵盖关键决策点、技术选型考量及实践收获,激发读者对微服务架构设计与实现的浓厚兴趣。 ####
|
1月前
|
Cloud Native 持续交付 云计算
深入理解云原生技术及其在现代IT架构中的应用
在数字化浪潮的推动下,云原生技术已成为企业转型的关键。本文将通过浅显易懂的语言和生动的比喻,带领读者探索云原生的核心概念、优势以及如何在企业中实现云原生架构。我们将一起揭开云原生的神秘面纱,了解它如何助力企业快速适应市场变化,提升业务的灵活性和创新能力。