作者：贺科学（晨末），毕业于北京科技大学，工作10年，在企业级应用架构及研发方面有长期积累。擅长分布式系统架构，擅长复杂业务的领域建模及开发落地，掌握领域驱动设计及开发相关方法论，有实际成熟线上产品案例；2014年入职阿里云，先后参与或主导过阿里云控制台、阿里云容器服务、资源编排服务、云分期等云服务的建设，目前带领小型团队负责新零售业务相关的研发工作。

除业务以外，个人精力也投入在“复杂业务系统落地过程数字化”这一命题上，目前有一定思考和实际积累。实际工作中有3年带团队全面独立负责复杂业务系统的经验，所以在技术一号位的工作方面有相关的实践和思考。

联系邮箱： kexue.hkx@alibaba-inc.com

技术一号位系列文章介绍

研发人员经过一段时间的成长和积累（3-5年），往往需要带领团队或者小组承担更大的责任。很多扮演了teamleader角色的“管理新人”在带人做事遇到困难的时候会陷入纠结：要不要放弃这个发展路线继续做一个单打独斗的技术“老人”？特别是在一些环境中，管理新人本身面临着陌生的领域和挑战，如果没有领路人，单纯依靠自己去实践感悟，往往会走很多弯路。所以本文作者结合多年实践经验，以及结合很多经典理论的输入，总结出了“技术一号位是什么”、“普通研发人员如何一步步成长为技术一号位”、“作为技术一号位需要掌握哪些理论工具来支撑日常工作”等一系列能够引导技术人员升级认知的理论工具。同时需要强调的是，技术一号位不是岗位，更多的是技术人员在公司中做事的一种心态，这个系列的文章适合所有想要对日常工作“知其然更知其所以然”的技术人，借助理论工具的指引，结合自己的实践经历，悟到自己的收获，从而加速成长的过程。大道理千千万万，有缘者得之真谛践于其行而非流于其表。

技术一号位方法论系列文章：

未来一段时间，阿里巴巴中间件公众号会持续发布系列文章，欢迎关注。

前言：什么是技术一号位、有哪些关注点、怎么做技术一号位

做了研发团队的技术leader以后，要处理的事情非常多，如果对自己扮演的角色没有一个清晰的认知，就会出现该做的事情没有做，不该做的事情投入了过多的精力，造成实际行动和结果既不匹配上级的要求，又不匹配下级的期望。特别是对于刚开始带领研发团队的新人leader而言，角色的转换和适应的过程，增加了认清自己的角色本质的难度。今天我们抛开纯技术团队的同学不谈（其实本质一样），只讨论业务研发团队的同学，如何以技术一号位的角色来做事。

一、如何识别自己是不是技术一号位

在开始谈如何做事之前，首要任务是判断自己是不是技术一号位，而要判断之前，首先要明确判断标准，跳出思维误区。这里我们列出一些常见的思维误区。

以下是常见认知误区：

以上的认知误区，错误地把是否带团队、技术等级的高低和是否为技术一号位关联起来。虽然事实上带团队的业务研发同学成为技术一号位的概率更大，但是本身这两者不是划等号的关系。

那么什么是区分是否为技术一号位的决定性因素呢？很简单：对一个具体的业务而言，你作为该业务的直接技术参与者，是否处在技术领域责任链的最顶端。这句话翻译过来就是，对一个明确的具体的业务而言，多种角色的同学一起合作的时候，你是否是技术序列的最终责任人，即：谁承担对应的责任，谁就应该扮演对应的角色。

当产品经理、运营、研发共同做一个业务的时候，某个研发同学独自，或者带领其他几个研发同学，或者带领跨BU的研发团队，共同支撑PD的业务需求。那么这个研发同学就是这个业务的技术一号位，不论他是否带不带人，也不论他带的人在行政上是否从属于他。一般来说，负责单一业务的研发团队leader一般就是这个业务的技术一号位；负责多业务线的研发团队的leader的D，是每个业务线的技术一号位，而研发leader本身是更高层面业务的技术一号位。

所以，做业务开发的技术同学，不论是什么层级，带不带人，都可能是某个具体业务的技术一号位的。这一点非常重要，只有认清这个事情以后，业务研发同学才能在做业务的时候，明确下来自己除了需要写代码以外还需要做什么，关注什么；这些关注点需要做到什么程度，才能对上满足期望，对下不让团队走弯路、不和下属抢功。

当你经过以上判断以后，确定自己是技术一号位时，恭喜你，你已经不再是一个仅仅需要写代码的研发同学了。很多P6甚至P7的研发同学，眼中还是只有写代码这一件事情，如果以这种方式做业务，那么就会发现业务过程会有各种没有做到位的事情，会在做业务的过程中“交很多学费”，甚至会因为自己的能力不够而拖慢业务发展。

虽然成熟的研发团队可以通过完备的研发过程管理，来避免个人能力不够而对业务产生太多负面影响，但是本质上强制的规定和“上级要求”只是在依靠行政管理手段在强制一个人做这些事情，并没有唤醒他的创造力和责任心，反而会被认为是“工作琐事”。这些“工作琐事”本质上是需要他扮演的角色来负责的，但是由于他没有意识到自己实际上已经是这样的角色了，而仅仅把自己停留在“研发”的定位上，把“写代码”当做核心任务，这样一来，会让研发同学对那些看起来 “和写代码无关但是是技术一号位必须做的事情” 非常抵触。这种抵触情绪发生的时候，leader再强调Ownership也都没有太多效果，因为不是他不负责任，而是他没有意识到，这是他应该负责的事情。当他的心态和认知转变以后，一些原来看起来不怎么负责的人会变得负责（不排除有人本身就是不负责的人，那么这样的人不是良好的技术一号位的候选人，主管要有识别能力）。

作为业务开发同学，一定要仔细认清辨别自己实质上是不是一个业务的技术一号位，而不用考虑自己的P级，不用管自己是不是业务其他参与者的leader。当你意识到自己是这个业务的技术一号位的时候，就要迅速切换角色，从原来自己给自己的定位 “写代码的、搞技术的” 转变为 “某个业务的技术一号位”，开始进入角色，发挥出你的价值。这也是很多研发同学通过做业务能迅速成长的原因，抛开技术上的成长之外，他比其他研发同学接触了很多 “做事情需要思考并为之行动” 的维度，这些维度的丰富是普通业务研发同学很难看到、很难感觉到，因此更难悟到的。不排除有悟性高的研发同学能够自己悟到，但本质还是由于他所处的环境、他面临的问题在逼迫他做出思考，然后为之实践。如果一开始就知道自己做事情要找准自己的角色和定位，那么就会少走很多弯路。

二、分析你所在环境的局势

当你意识到自己是一个业务的技术一号位的时候，不用过多怀疑自己究竟是还是不是，而是要本着“就当自己是”的心态来进行接下来的工作实践和思考。需要大家明确的一点是，任何一个工作角色，都有对应的责任，也都有履行对应责任的方法论。我们要做的，不能再像过往做普通研发的时候那样懵懵懂懂去做事，听“需求”指挥，而是要开始寻找或总结一些方法论，要自顶向下地对业务有一个清晰的认知，知道自己比过去多了哪些维度的事情要关心，知道接下来会面临什么样的挑战，要知道自己在挑战中应该扮演什么样的角色，采用什么样的手段去解决业务在不同阶段一定会出现的各种问题。

在开始所有的思考之前，先要做一件事情，就是分析你目前所处的环境的局势。

• 业务方面

• 协作方面

• 研发团队方面

如果你本身已经是P7+以上了，那么下面这些维度可能是需要你继续深入思考的：

• 业务方面：

• 业务的愿景是什么

• 业务的愿景在不同时间维度上拆解以后的关键业绩指标是什么

• 为了实现不同时间维度的关键业务指标，你准备投入什么样的资源？投入的资源之间相互怎么配合？相互配合的原则是什么？

• 这个业务现在做是否合适？现在做不合适的话，需要在什么时候做合适？

• 这个业务现在做不合适的情况下，哪些因素让你觉得现在做不合适？

• 让你觉得现在做这个业务不合适的因素中，哪些因素是可以通过人为干预让它不再是阻碍性的，哪些是可以通过人为干预增加它对业务的积极作用？

• 业务的现状及瓶颈问题

• 业务问题的技术解法

• 业务发展趋势

• 业务竞合分析

• 业务发展策略

• 业务的终局畅享

• 团队方面

• 团队的使命是什么

• 团队推崇的价值观（做事原则）是什么？

• 当前团队的人才梯队是否合力？

• 当前团队的人才储备方向是否完备？

• 当前支撑业务的团队是否未来依然能够支撑业务的发展？

• 当前团队不能继续支撑业务的战略规划的情况下，需要做怎样的调整？

• 协作方面

• 业务是否可以向其他BU借力，或者借力于其他BU。

• 当前的业务是否和其他BU可以相互配合形成某种合力的优势？

• 当前业务和其他业务如何配合来完成未来的布局从而获取对应的优势？

• 未来的布局落地后，想要形成什么样的局势？

• 局势形成以后，对完成组织愿景，履行组织使命有什么决定性帮助？

三、找准自己的定位，明确自己的定位的含义

当理清楚自己所处的环境以后，知道业务是什么情况，和自己配合的人又是什么情况以后，需要知道自己扮演的角色究竟意味着什么。从我个人的经验来看，技术一号位是负责使用技术能力解决业务问题，提供稳定可靠的技术支撑，确保业务安全合规低风险地健康发展，并通过技术或业务创新来推动业务发展；负责向业务各方提供各种必要的技术支撑，通过合理的数据分析为业务决策提供依据；通过对技术领域的积累和发展，通过业务领域的理解和落地影响业务决策；负责构建梯队完整、能力全面、制度完善的技术团队来支撑业务发展。

四、应该有什么样的工作原则和要求

五、履行技术一号位的职责具体需要感知哪些事情及这些事情的要点

下面这张图从大方面上列出了一个技术一号位需要感知哪些方面的事情（图中未列出产品运营、售前售后等一系列其实很关键的方面，但是如果技术一号位负责的业务是有商业化需求的，则还是需要关注这些维度的事情的）

这些事情是必须知道，但不是必须亲自做的，要能够借助团队的力量完成该完成的事情。下面是具体从业务、技术、团队角度来详细理清楚技术一号位需要感知的事情及其要点：

业务方面 （后面会有单独的文章详细解释业务方面怎么做）

• 建大图

• 定方向

• 找打法

• 撑业绩

技术方面

技术选型

系统架构设计

• 一般而言，不同的业务场景会体现出不一样的技术特征，对技术反应出不同的需求

• 面向B端客户的传统企业级应用，通常情况下对稳定性要求高，对数据安全要求高，需要保证业务操作结果和实际数据匹配。业务流量不大，系统用户对用户体验不如C端用户敏感。针对这类系统，往往通过简单的单体应用做高可用部署即可，使用单一数据库并通过数据库保障业务数据变更的事务，界面契合客户业务。

• 面向C端客户的互联网应用，通常情况下对流量承载能力要求高，对数据安全要求高，对用户体验敏感，对稳定性要求高，业务流量巨大，特殊的业务场景会出现特殊的流量峰值。针对这类系统，往往需要构建分布式系统做大流量高并发高可用系统架构建设，自顶向下分层优化，从终端层的静态资源CDN化，到应用层的前后端分离，应用逻辑和底层服务分离，再到核心业务层的微服务架构建设，从服务发现服务治理，到无状态应用的规模化部署，从大量基础中间件的使用，到大量公共业务服务的构建，每一层都需要做好对应场景的优化和架构设计。

• 大流量高并发高可用系统架构

• 业务流程异步化

• 使用限流手段确保系统不被突发大流量压垮

• 使用降级手段确保下游系统不可用时能够快速失败避免请求堆积造成系统无法接受或响应外部请求

• 使用逻辑隔离或物理隔离手段确保多租户模式下各租户互不影响

• 使用合理的资源调度策略确保不同规模的租户享受同等技术服务水平

• 使用合理的资源使用策略确保成本维持在合理水平

• 使用合理的监控手段提前发现系统承载能力的变化，及时通过扩容或缩容来应对系统流量变化

• 使用分库分表或根据业务需求采用合适的NoSql数据库来支撑海量数据持久化

• 使用缓存抵挡大流量对数据库的压力

• 使用分布式锁处理高并发业务场景下的公共资源抢占问题

• 使用幂等服务屏蔽高并发场景下的重复请求

• 使用分布式事务服务确保业务数据的最终一致

• 使用负载均衡承接业务流量，分配给后端应用服务器，避免单点风险

• 使用同城双机房来规避单机房风险

• 使用异地多活技术来规避单个城市的不可抵抗风险

• 业务复杂的情况下，采用微服务架构

• 如果是单体复杂业务应用拆分为微服务，则应该按照业务领域来拆分，拆分后通过服务接口对外提供标准服务

• 如果是开始就确定要做成微服务架构，那么要先做领域划分和建模，然后大的复杂的领域单独形成业务服务，公共依赖的领域做成服务，使用合理的服务治理框架，选择合理的服务通信协议，构建业务系统。

业务建模

• 针对复杂业务，不需要最开始即按照完整的业务模型做落地，而是根据实际业务需求和时间进度合理定制业务模型的落地计划，既确保需求能按时完成，又确保代码落地始终在业务模型设计范围之内而没有腐化。

研发落地

• 略

项目管理

• 项目目标

• 完成时间

• 想要取得的结果

• 项目成员

• 关键里程碑

• 风险预警

• 多方协调沟通

• 日常进度追踪

• 项目复盘

质量保障

• 代码扫描

• 代码评审

• 研发单元测试

• 团队业务需求沟通及评审

• 测试用例编写

• 测试用例评审

• 基础功能测试验收

• 上线发布验证

• 灰度测试

• 线上验收测试

• 自动化冒烟测试

• 每日自动化测试

稳定性建设

• 关键业务流程日志打点

• 全业务链路跟踪

• 系统技术指标监控

• 系统业务指标监控

• 告警

• 自动化告警恢复

• 关键业务场景预案建设

• 关键业务场景预案执行

• 值班响应机制

风控建设

• 业务风险点定义

• 业务风险点识别

• 业务风险点级别定义

• 业务风险点分级处理

• 业务风险点报警

• 业务风险点触发趋势

• 实时业务风险控制

• 离线业务风险扫描

• 业务风险点诱因分析

团队方面

• 成员1v1沟通

• 成员优劣势分析

• 成员做事意愿分析

• 成员角色定位对焦

• 成员能力梯队聚焦

• 方法论的探讨与实践

• 帮助不同的人看到自身不足，定制不同的成长规划

• 根据不同人的优劣势和做事意愿，安排调整合理的事情和责任范围，激发做事的主动性，为其发挥出创造力营造良好的环境

• 业务大图的解读和KPI的设定

• 工作原则和工作要求达成一致认知

• 明确团队要什么，不要什么，推荐怎么做，不推荐怎么做

• 要创新不要墨守成规

• 要思考不要苦劳

• 要打破思维定式和束缚，不要自我设限

• 要Ownership，不要推脱

六、不是技术一号位的技术人，如何成长为技术一号位

目前还不是技术一号位的业务发开同学，虽然现在的岗位只负责一小部分，但是本质上来讲，只要你负责某个事情，那么不论这个事情大小，你都是这个事情的技术一号位，只是由于事情的难易程度和规模大小，导致很多可能需要做的事情其实并不需要做，但是这些问题并不妨碍你知道技术一号位要做什么，应该怎么做，更不妨碍你以技术一号位的心态去做事。

先确定好心态的问题以后，接下来就需要一些可以被实践检验的方法论来帮助大家打破自己层级的束缚，完成自我突破，从而在成长的基础上获得负责更重要的事情的机会，通过做好更重要的事情来获取更更重要的事情的机会，这样一定会在某个阶段，你负责的事情，需要完全以真正的技术一号位的角色去落地，那么那个时候扮演技术一号位的角色也就是水到渠成的事情了。