企业里真正的“将军”应该去做什么？

第一，顶层设计，系统驱动
从整个大的角度，你就把公司当成一个大产品，里边有几十个系统，公司所有的业
务都被系统接管，系统之间还有交互，我给它高度抽象为交易体系、协同体系、监控体
系、绩效体系。每个产品自己去干活，干不了的时候交给人，人干完了再交回来。这样
一来，系统知道人到底在干什么、干得怎么样、人干的事我能干吗，产品经理就要去关
注系统驱动。今天有多少公司是这样的？少之又少。我们公司之前不是这样，但我们已
经建设成这样，最后你会发现这是一个非常非常大的变化。
所以，我认为首先就要做好顶层设计，企业架构师把业务高度抽象，创始产品经理
才能把系统驱动的一整套体系设计出来。至于哪些自建，哪些购买，就是再往下一层的
事情。
这里我顺带讲一下，企业需要画一条线，线上的自建，线下的购买。哪些自建？让
你具备核心竞争力的要自建，毕竟这种让你绝对牛逼、超越竞争对手几十号排位的产品，
怎么可能会有厂商卖给你？而有的东西就没必要自建了，能买就买，所以越是偏技术性
2OGP2 卹匬䋗䎃剢
的越不要做。很多技术团队在公司里面去忽悠人，我们公司里面这样忽悠我的，都被我
干掉了，然后我自己下场干。人家外面有做得好的产品不拿过来，非要自己下场干是吧？
你这么牛逼怎么不像毕玄一样去创业？
你也可以选择自建，比如一个商业产品要价20万，而你可以很快自建出来满足公司
需要，并且只用花10万的研发成本。不过，现在IT的人力成本已经这么贵了，10万的成
本你能投入几个人？按照2万一个人来算，10万也只能让5个人做一个月，如果要做两个
月，那么就是2.5个人，这点人能做出什么像样的产品？
所以为什么过去中国的B端做得不好？我觉得B端创业最大的竞争者不是竞争对手，
是甲方的CTO和对应的团队，就是像我这样的CTO。
不管你想做成什么事，你都要找到最优解，首先就要掌控设计。
第二，技术上一定要关注模块化
既然要专业分工，那么模块化就要做好。很多人在这一步就直接从一个大单体应用
跳到微服务了。微服务是最终的结果，但我们能不能慢慢地过去？别一上来就依赖倒置、
接口分离，很多技术团队根本没那么高的水平。你只要把模块化做好，也就是说，这个
模块里的数据只有这个模块可以访问，其他人访问是不被允许的，至少能把这个守住，
你的架构就不会烂到家。
第三，要关注用户体验，一定要有监控体系
你的系统里边到底怎么样，服务响应时间怎么样，用户访问你，他有没有业务异常，
有没有系统异常？如果你连用户发生了什么都不关注，你怎么可能做好？所以你要有监
控体系，也要做好治理工作。我们公司的目标，今年6月30号以后，生产环境不允许有
一个异常，每天都要清理掉，不管任何服务，响应时间都不允许大于2秒，有定义SLA
（Service Level Agreement）的再说，如果确实有长于这个时长的，那也是被特批过的。
所以我觉得一定要有监控体系，否则生产环境已经烂得一塌糊涂了，IT根本不管，还在
那里吹牛，在整天做项目。
3⽷껷露
第四，要产生价值，一定要有目标管理
关于目标管理，第一个要谈的就是OKR，要有方向感。然后你的团队还要有周目标、
日目标，抓执行力，最后要抓人效数据。我们常常讲，团队要ᨀ高研发效能，但有没有
管理说过人效的问题？有人说，这是不是就是卷？你可以认为这是卷，那你说西点军校
卷不卷，企业就是要去竞争的，你要和企业一起去成功。另外，我觉得人尽量不要招多
了，尽量少招人，3到5人就是一个创业团队，具体的原因我会在后面讲到，分析一下大
家跟公司共存亡这个问题。很多员工其实自己在单位里上班也浑浑噩噩的，对自己来说
没有意义，对单位来说也吃亏，其实我觉得这都是管理层出了问题。
第五，数据驱动经营完善，一定要看数据
在今天，一个企业经营不看数据不就是扯淡吗？尤其是管理干部和领导，一定要意
识到数据特别重要，要用数据驱动内部进行完善。比如OKR里面都是数据，而且数据都
是系统统计出来的，做到多少就是多少，全公司人都能看见。目标和目标对应的数据管
理特别重要。
第六，只用一只眼睛盯着AI
当前的AI大多数时候没什么用，因为它还不是真正的人工智能，是傻人工智能。在
这个情况下要发挥AI的价值，需要有几个依赖。第一，你的数据得够多。第二，数据得
够准确。你们公司有数据吗？连数据都没有还谈什么AI？你说有数据，主数据管理都没
做好，最基础的数据都是垃圾数据，怎么可能做好人工智能？第三，上层的大数据做好
了吗？大数据没做好，AI怎么可能做好？所以AI到公司里面之后全是坑，最后你也被坑。
但是客观来讲，AI是不是就没用？还真不是。我去年就在盯AI的东西，我们在做销售的
智能报价，大概在今年9月份左右，我们公司的报价应该会全面地被系统完全接管，这
里其实就利用了很多产品的能力，再加上AI的辅助。
第七，三大效率
这里我会特别展开讲一下。你说这跟技术有关系吗？每一个都特别有。技术是为什 2 卹匬䋗䎃剢
么服务的？技术是为发展业务服务的。
研发效率
像CI/CD、云计算、分布式服务、DB缓存等等，有关基础平台和组件都要持续建设
完善，你投入两到三个人干这个活儿，就可以让一百多个人效率更高，何乐而不为呢？
我们做这个事情的目的就是让开发人员只写代码，测试人员只写测试案例，我们在各个
层面都持续观察、分析研发人员到底在忙什么，然后帮助他ᨀ升效率。
另外一个与研发效率相关的是要搭建一个SOA（Service Oriented Architecture）和EDA
（Event Driven Architecture）的架构。打个比方，我前面ᨀ到的交易体系，它是比较稳定
的，适合用SOA架构。那协同体系呢？我们今天需要应对各种各样的变化，所以搭建的
时候就需要用事件驱动的架构，也就是EDA架构。当你把有很多变化的东西放在EDA架构
上之后，你的研发效率会飞快ᨀ升。
此外，针对CI/CD而言，产品经理要跟开发有共同的语言，开发跟测试的工作要解耦，
开发发布到生产环境是不依赖于测试的，这其实是需要有一整套的体系和支持的能力，
比如说要有特性开关。你要想尽一切办法让大家都尽量不依赖地、快速地把自己的工作
做完，最大化地降低研发的半成品。什么叫半成品？没有投入到生产环境的就是半成品，
这是我们特别考核的一个指标。如果哪家公司不在这上面投入，那我觉得他们太傻了。
要么投入两三个人去做，要么去买，这件事绝对值得。
会议效率
大家很容易忽略会议效率，但我认为我们需要永无止境地关注会议效率。我有一句
话叫“两年之内，每周必须谈会议效率哪里要ᨀ升”，其实公司里大量的时间都是浪费
在会议上。当然，大量的有用的价值也都产生在会议中，但是你一定要持续地去优化它，
比如你要引入一些会议的工具，你要去观测，你要去教大家如何开会。
*决策效率
决策效率也特别重要，不要议而不决。我对团队说过一句话，中层干部要独挡一面，
不敢做决定的都要被干掉，不许拿A/B方案来跟我来汇报，不好意思，A还是B，你必须
选一个。 껷露
研发效率、会议效率、决策效率这三大效率要无限关注，这些东西在基础工具平台
上都有巨大的机会，值得去创业，如果全国中能有一家公司把它吃透了，那这家公司会
特别牛逼。但是在今天，这个领域还没有特别优秀的工具和产品。

蔡超：这八点架构师感悟，真的很干货 | 大道至简

一位资深架构师的肺腑之言，无限缩短你的架构晋升之路。

一、站在“提问题”角度来解决问题

技术人员常常吐槽产品团队需求不合理，不过建议技术团队去走进业务，不仅仅是去设计架构、实现产品的需求，同时也试着去实现客户的需求，甚至发现潜在的需求。这时我们就变成了在设计上提出问题的人，你会发现提出问题的同时，在很多时候也需要同样深入的思考。设计一个好的问题，甚至比解决问题更难。

二、“少”比“多”更困难

软件机构设计切实需要取舍，当大家都在往里面加东西的时候，架构师更应该来做这个说“不”的人。做“少”比做“多”困难百倍，希望你能掌握 CAP 原则做取舍。为了更好的取舍，保持架构风格的一致性，在一开始架构师就应该根据系统的实际需求来定义一些取舍的原则，如：数据一致性拥有最高优先级、提前发布核心功能优于完整发布等。

三、非功能性需求决定架构

非功能性需求决定架构，架构师要更加关注非功能性需求，常见的非功能性包括：性能，伸缩性，扩展性和可维护性等，甚至还包括团队技术水平和发布时间要求。

四、“简单”不容易

很多架构师都会常常提到保持简单，但是真正的一些简单的方法，来自于对问题和技术更深入的理解。这些方案往往不是容易获得的、表面上的方法。

五、永远不要停止编码

架构师也是程序员，代码是软件的最终实现形态，停止编程会逐渐让你忘记作为程序员的感受，更重要的是忘记其中的“痛”，从而容易产生一些不切实际的设计。 Amazon 高级副总裁级别的 Distinguish Engineer，他们每年的编码量也非常大，常在 10 万行以上。

六、仔细识别非功能性风险

架构设计很重要的一点是识别可能存在的风险，尤其是非功能性需求实现的风险，如数据一致性要求、响应延迟要求等。这些风险不容易被发现，但是修正的代价非常大。我们应该通过原型或在早期的迭代中确认风险能够通过合理的架构得以解决。

七、从“问题”开始，而不是“技术”

技术人员非常乐于去学习新技术，更有激情去使用新技术，导致常常有一个通病——使用一些不适合的技术去解决问题，常常会导致简单问题复杂化。

八、过度忙碌使你落后，记得留点余闲给自己

加班已经成为习惯，但是忙碌的工作，常常会导致新知识的匮乏，进步维艰。这就像健身一样，光靠锻炼是不行的，营养补充和锻炼同样重要。个人技术成长也一样，实践和学习是一样重要的。

塑造团队，使众人行
打造一个奋进、卓越的团队需要对权利与责任有更清晰的认识，带好一个一线团队由浅入深可以拆分为四个阶段：
活水之源：昨日因今日果，招聘要凭良心。
换位思考：眼里要有事更要有人，多做 1v1 沟通，培养同理心（我懂你）、信任感（你懂我）与利他心态（能成事）。
榜样作用：我说你听，我做你看，你说我听，你做我看，带领团队赢一场大仗。
使命与愿景：沉淀共同的文化、目标与路径，攀更高的山，看更美的风景。
https://baijiahao.baidu.com/s?id=1682402107550076103&wfr=spider&for=pc
https://baijiahao.baidu.com/s?id=1724348851029636982&wfr=spider&for=pc

今年上半年我曾经做过一个关于如何做架构设计的分享，其中有个很重要的话题是
“如何更好地做技术决策“，针对我们的前端团队，我整理了5条做技术决策的原则。
原则0：遵守公认的好的设计原则
• _DRY - Don’t Repeat Yourself（不要重复自己）
• KISS - Keep It Simple,Silly（让设计尽可能的简单）
• YAGNI - You aren’t gonna need it（只做刚刚好的设计，不要过度设计）
• 其他
原则1：找出最本源的需求，而不应该局限于当前的技术实现和资
源
很多时候我们很容易被表面需求所误导，就像乔布斯的名言：“如果亨利福特在发
明汽车之前去做市场调查，他得到的答案一定是大家想要一辆更快的马车”，如果我们
在做设计和技术决策的时候，没有找出用户的真实需求，就会很容易在错误的方向上狂
奔，做很多无用功。
要找出本源的需求，就需要多问为什么，多和干系人沟通，少考虑技术细节，少被
现有的技术所误导或局限。
案例：设计部门希望设计系统支持Angular
我们设计部门最近希望我们的设计系统ᨀ供Angular版本，因为当前只支持React版
本。
从这个需求来看，表面上是要我们开发Angular版本，如果仔细追问他们到底为什么
需要Angular版本，是因为有一个团队还在用Angular。他们希望这个团队能使用我们的设
计系统，但是对方表示用不了。
其实本源的需求是希望有更多的团队使用我们的设计系统，而不是要单纯支持
Angualr。
那要满足团队的这个需求，是不是非要做一个Angular版本不可呢？当然不需要。如
果我ᨀ供一个类似于BootStrap的HTML和CSS版本，他们一样能用起来，而这么做成本不
高，并且其他的团队也可以用。
（更多案例可参考下图）⽷껷露
原则2：聚焦于 “收益”、“成本”和“风险”三者之间的平衡，
而不是技术本身
每一次技术决策，其实本质上就是一次取舍（Trade-Offs）。
每一次取舍（Trade-Offs），本质上就是在“收益”、“成本”和“风险”三者之间
的平衡。
既然每一个决策都涉及到收益成本风险，那么就不能只看收益而无视成本和风险。
就像前一个案例中ᨀ到的，设计部门考虑的是Angular版本带来的收益，但是他们却忽略
了打造一套Angular版本的设计系统所需要的成本，以及可能带来的巨大风险。
45
OGP2 卹匬䋗   䎃   剢
所以在做技术决策的时候，理性考虑一下决策背后的收益、成本和风险的关系是很
必要的，而不是仅靠喜好或者直觉来做决策。
原则3：选择某个技术背后的生态系统而不是某个技术
这条原则特别适用于前端领域，在前端，各种新技术、框架、工具层出不穷，如果
总是追新，或者被某个软文吸引轻易选择了某个技术，往往最终会带来巨大的成本。
案例：我们为什么从Preact迁移到React
在早些年的时候，我们前端选择了Preact作为UI渲染技术，这有早年React License的
原因，也有Preact体积更小、性能更好的原因。
然而在这几年的使用过程中，发现很多不足的地方，核心原因其实都是生态不够好。
比如说Preact调试很麻烦，它不像React有一个强大的DevTools；比如说我们遇到过
Preact在服务端渲染的内存泄漏问题，如果像我们这样大规模访问量的用户多一点，可
能早就有人踩过坑了，不需要我们去花很长时间定位并最终去解决这个问题；再比如最
近我们在集成Nextjs，Nextjs是完全为React设计的，对Preact兼容性并不好。
这样的案例还很多（如下图），所以选择技术，它背后的生态和社区活跃度很重要。⽷껷露
*原则4：不仅要考虑如何构建，还要考虑如何维护
这是一个常见的问题，很多人只管搭建新项目的时候爽，而不管后续维护是不是困
难，用了一堆自己喜欢的新技术，最后难以维护。下一个人接手了，搞不好会推翻重写
一遍，这样的循环一次又一次。
这样的错误我也常犯，比如2年前React Hooks刚出的时候，我就迫不及待用它来替
代Redux。结果上线后发现不好维护，有Bug也不好定位，不像以前Redux，数据流特别
清晰，借助工具非常方便重现和定位问题，最终上线没多久就改回去了。
所以现在在做技术决策的时候，我们很注意的一个问题就是将来的维护会不会很麻
烦。包括我在做代码审查的时候，有时候看到一些功能能运行得很好的PR、但是代码写
得比较难懂的，或者说没有遵守最佳实践的，但只要会给未来的维护带来麻烦的，我都
会毫不犹豫要求重写，尽可能避免增加日后的维护成本。
最后简单总结一下上面就是我们现在实践的五个技术决策原则：
• 原则0：遵守公认的好的设计原则；
• 原则1：找出最本源的需求，而不应该局限于当前的技术实现和资源；
• 原则2：聚焦于 “收益”、“成本”和“风险”三者之间的平衡，而不是技术本
身；
• _原则3：选择某个技术背后的生态系统而不是某个技术；

• 原则4：不仅要考虑如何构建，还要考虑如何维护。
这些原则绝大部分时候都可以很好地帮助我们做出正确的决策，避免踩坑。我也会
一直在反思曾经做过的决策，对于不太好的决策，会反过来考虑是否要修订这些原则，
最终通过不断完善决策原则，帮助我和团队更好地做出技术决策