嘉宾 | 张铎
在翻朋友圈的时候，看到张铎老师去年策划的 Apache Pegasus Meetup 活动，然后我给他留言，邀请他来 ArchSummit 全球架构师峰会北京站上分享架构师的成长经验，结果他很爽快的答应了。
张铎是在小米待了 5 年多后，于 2021 年 4 月进入神策数据的。用张铎自己的话说，在大公司卷不动了，就换个小公司试试。
在神策数据，张铎担任神策数据基础研发部负责人 & 首席架构师，主要负责整个基础研发部，大部分的精力用在团队管理，和研发技术选型上。
从 ToC 到 ToB 服务行业感受到的差异
在搭建大集群的情况下技术挑战是很多的，面对几千上万台机器，一个中控节点就有可能变成瓶颈了。而对于神策数据的情况，私有化部署是业务模式上的必然选择，并且会采购神策数据的客户，通常是不会有需要单独搭巨大集群的业务需求的，因为有这个需求且能负担起的公司，自己的技术能力也很强，通常数据分析系统就不会外采了。来神策数据之后，张铎就知道面对的形态是一大片小集群，相对应地技术挑战也变了，不再是每天上千亿的 QPS 情况，反而是部署在客户端的小集群环境是否能足够稳定，各类监控指标和报警体系是否足够完善，处理效率是否足够高。在这些方面做不好，那维护大量小集群的成本会变得巨高无比。
张铎来神策数据之后，做的第一件事就是跟所有团队说，一定要先把监控报警进一步完善起来，更详细了解系统的运行状况，第一时间知道问题出在哪，同时也能帮助神策数据的技术人员更好地知道系统运行的状况。
在 ToB 私有化部署的行业，张铎说，让你惊讶的地方还很多，例如把集群部署在客户那里，客户什么时候用，用的好不好是很难第一时间了解到的。曾经就有集群部署一年了，客户从来没用过。这不像在互联网公司，应用上线后随时能看到真实的数据。ToB 行业的客户类型多种多样，这就是业务常态。
为了更好地了解客户场景需求，神策数据内部提了一个 SDAF 数据闭环方法论，具体指 Sense、Decision、Action、Feedback，通过客户数据来做一个决定，决定之后会做出一些具体的动作，动作会反馈新的数据回来，再做新的优化，相当于一个闭环。
对数字化的理解
这次去采访张铎老师，进入神策数据的大门，就看到正对大门的墙上写着“帮助中国三千万企业重构数据根基，实现数字化经营”。怎么理解数字化？张铎认为数字化转型最主要的目的是帮助客户提高效率。经济增速在慢慢下降，劳动力人口也在下降，这种情况下所谓数字化转型，其实就是要慢慢做精细化管理，去挖掘数据价值。
神策数据一直在做用户行为分析，实现更精准的用户运营决策，目前也做得较为领先。而数字化营销是一个更广阔的的市场，需要深入到行业中，如零售行业、金融行业等，去真正了解他们复杂的业务场景，甚至是帮助传统企业去挖掘他自己都不知道的数据价值。
私有化部署的难度和挑战
私有化部署单纯的从常规技术方面来看挑战没那么大。但从业务方面来考虑，搭一大堆小集群的运维成本会高到无法接受。所以最终的挑战在于怎么能用有限的人力把这么多集群管理起来。尤其是现在很多小客户就 5 万、10 万的预算，最后包括售后成本，算下来在商业上肯定是亏的。对于架构师的挑战主要就是怎么能把维护成本降下来。
业务架构思维
关于架构师的业务思维，张铎说，大部分的架构师业务 sense 都是很好的，这里他举了一个例子，从搜狗过来的架构师，思路转变的很快。神策数据的 SCMS（内容管理，可以通俗的认为就是帮客户管理素材，快速实现一个活动页面，比如大转盘抽奖等等）业务需要一个对象存储来保存和访问素材，在互联网公司选一家云就好，但在神策数据显然不一样。这个搜狗来的资深架构师很自然的对架构做了调整，在评审时要求业务团队一定要注意多云的适配，并且给出了合理的抽象层次和接口建议等等，并且考虑到甚至有客户会买商用的对象存储服务自己搭，一定不要轻易就加需求，万一遇到一个商用对象存储没有的功能就抓瞎了。
其实好的架构师，不管你到哪，手里拿的锤子是一样的，掌握的技术是一样的，关键看你怎么用。在神策数据做私有化部署和在互联网公司做高并发架构，它只是约束场景，条件变了，搭出来的架构样子就变了，但底层用的技术是比较类似的。
所以说，好的架构师知道底层有哪些技术，到了一个不同的环境之后，用不同的方式把这些技术拼起来。张铎也会在 3 月 18 日 ArchSummit 全球架构师峰会北京站上的演讲中，提到架构师变与不变的话题。因为从大的层面来说，不管是什么行业，所有的人类社会发展过程中，分工会越来越细，专业性会越来越强。从公司层面来看，肯定需要那些在某些方向上钻很深的，专业性比较强的研发人员。而好的架构师除了在某个方向上钻研之外，还需要有更广义的知识面，职位越高，就需要对业务越了解。
张铎也会参加公司的管理层会议，通过会议能了解公司现在业务发展大概方向是什么，这样才能明确技术该做什么，不可能脱离业务去安排技术工作。
对待开源的态度——务实
张铎作为开源圈的 KOL，加入到神策数据后，也很清楚的认识到，神策数据在开源上不可能像大公司一样投大量的资源做贡献，小公司目前主要还是先解决业务上的问题为主。
这种情况下，张铎平时也会给公司里的技术人讲一讲开源文化之类的内容，也鼓励大家在业余时间贡献一些代码，并提供帮助。更重要的是说清楚不要老想着自己造轮子。此外呢，还会在内部普及一些开源的基础知识，比如哪些 License 能用哪些不能用，在用的时候有哪些注意事项等等。
总体上来说还是比较实用主义的，即便一个小公司，他只是在用开源，往回贡献的代码不多，但至少它遵守 License 在使用，这其实也是在做贡献，因为使用的过程也是在帮忙做宣传。小公司根据自己的实际情况来，只要合理合规使用，不需要有什么心理压力或者道德负担。
团队管理最好的方法——真诚
用张铎自己的话来说，管理基础技术架构部是一件比较纯粹的事，和管理业务部门有一些区别，例如业务部门的负责人可以不懂技术，只要懂管理就行，把研发节奏、资源都安排好，团队往前做就行了。但基础架构部通常不是按照业务方向来划分，而是按照技术方向划分的，像云计算部门，存储部门，中间件部门，几乎所有公司基础架构部都是这样划分的。所以在这种情况下，最顶层的那个人如果完全不懂技术，是很难管理这样的团队的，可能那些技术大牛都懒得听你的，你也根本指挥不动，就算他糊弄你，你也听不出来。
所以，越是基础技术部门的管理者越需要懂技术，一方面在技术问题上可以和团队沟通，可以互相听懂，同时也需要能在一定程度上判断项目的风险和周期，更合理的做出决策。
那作为技术管理者，如何保持自己的技术敏感度，不断的提升自己的技术能力，张铎说他加入神策数据之初，面临的主要挑战是 OLAP 引擎方面的技术难题，因为之前没接触过，但这难不倒搞编译器出身的张铎，在他看来，底层的技术本质上差距不太大。底层技术的存储、大数据、云原生这些也都是很了解。平时在公司写的代码不会很多，但是开源的 HBase 里的代码平时还在写，也是为了保持对代码的感觉。
正如张铎在开源使用上的务实态度一样，在技术团队管理上，张铎的管理方法还是一味的真诚朴实，到新的团队，尊重大家，静静地听大家讲目前团队的问题，然后会挑一个大家都认为是问题同时也比较快能出成绩的点，自己上手把这个问题解决掉，建立信任。随后会和团队的主要骨干再深入沟通一遍，一起列出团队的重点工作和目标，确保在几个关键点上都能出成果。这个做到了，大家通常都很高兴，后面你再想根据自己的想法做一些调整，就比较好办了。总体上没什么很复杂的很深的套路，就是初期一定要自己冲在前面，并且始终把成事放在第一位。
嘉宾介绍
张铎，神策数据基础研发部负责人 & 首席架构师。
清华大学计算机科学与技术系本硕，长期从事开源软件的开发与维护。2015 至今历任 Apache HBase 项目的 Committer、PMC 成员、主席。2020 年成为 Apache 软件基金会的 Member。2018 年，在 Apache 软件基金会全球近 7000 名 Committer 中，贡献数量排名第三。曾任小米开源委员会主席，负责小米整体开源工作的规划与推进。
活动推荐
3 月 17 日 -18 日，ArchSummit 全球架构师峰会（北京站）即将落地。来自百度、京东、华为、腾讯、斗鱼、中国信通院等企业与学术界的技术专家，将就数字化业务架构、低代码实践、国产化替代方案、分布式架构等主题展开分享讨论。
直接到云上做开发？先等等，这个方案还“半生不熟”
“干净”的代码，贼差的性能
一场向应用交付标准的“冲锋”
没有 NGINX 和 OpenResty 的未来：Cloudflare 工程师正花费大量时间用 Rust 重构现有功能
