对于一个架构师，除了更加优秀的代码能力和trouble shooting能力外，需要构建当前技术领域的知识体系，需要有体系化的思维能力，需要对技术所服务的业务要有非常深入的了解。
体系化的思维能力，来源于两个方面。一方面是在日常工作中，对每一个接口设计，每一个逻辑，每一个模块，子系统的拆分和组织方式，每一个需求的技术方案，每一个系统的顶层设计，都要反复思考和推敲，不断的复盘。另一方面，需要大量广泛的学习行业内相似系统的架构设计，这其实就是开天眼，只是技术相对来说，行业内的交流更加频繁，淘宝、美团、百度、Google、Facebook、Amazon等各个公司介绍系统架构的论文和PPT铺天盖地，需要带着问题持续学习。
除了技术领域本身外，架构师需要非常了解业务上是如何使用我们的系统的，否则非常容易over design，陷入技术的自嗨中，这也是为什么我说Amazon Dynamo论文里讲的Vector Clock是个over design的原因。另一方面，很多时候技术上绕不过去的坎，可能非常复杂的实现，往往只需要上层业务稍微变通一下，就完全可以绕过去，这也是为什么我说GFS论文里，多个Writer同时Append同一个文件是个根本没用的设计（实际上Google内部也把这个功能去掉了）。这也是为什么我在咱们部门内反复强调大家需要深入了解业务，因为达到同样的业务目标，可能稍微改一下产品方案就可以让需求的技术实现变得无比简单。
只有真正知道上层业务是如何使用系统的，才可能真正做好架构。 深入了解业务并不难，对于每个同学，只要对于每一个接到的需求，对于每一个需求评审中的需求，对于周边同学或团队要做的需求，都深入思考为什么业务要提出这个需求，这个需求解决了业务的什么问题，有没有更好的方案。遇到不明白的多和周边同学、产品、运营同学请教。最怕的是自己把自己限定为纯粹的研发，接到需求就无脑做，这等于放弃了主动思考。衡量一个人是不是好的架构师，也有一个方法。对于一个需求，如果他给出了好几个可行的方案，说这些方案也可以，那些方案也可以，往往说明他在架构师的路上还没有完全入门。架构师的难点不在于给出方案，而在于找到唯一的那一个最简单优雅的方案。
总结起来看，行动中思考，就是始终保持好奇，不断从工作中发现问题，不断带着问题回到工作中去；不断思考，不断在工作中验证思考；不断从工作中总结抽象，不断对工作进行复盘，持续不断把工作内容和全领域的知识交叉验证，反复实践的过程。