共计 7317 个字符，预计需要花费 19 分钟才能阅读完成。
前言
什么是技术一号位、有哪些关注点、怎么做技术一号位？
做了研发团队的技术 leader 当前，要解决的事件十分多，如果对本人表演的角色没有一个清晰的认知，就会呈现该做的事件没有做，不该做的事件投入了过多的精力，造成实际行动和后果既不匹配下级的要求，又不匹配上级的冀望。特地是对于刚开始率领研发团队的新人 leader 而言，角色的转换和适应的过程，减少了认清本人的角色实质的难度。明天咱们抛开纯技术团队的同学不谈（其实实质一样），只探讨业务研发团队的同学，如何以技术一号位的角色来做事。
如何辨认本人是不是技术一号位
在开始谈如何做事之前，首要任务是判断本人是不是技术一号位，而要判断之前，首先要明确判断规范，跳出思维误区。这里咱们列出一些常见的思维误区。
以下是常见认知误区：
- 带人的是技术一号位，不带人的不是技术一号位。
- 级别高的是技术一号位，级别低的不是技术一号位。
以上的认知误区，谬误地把是否带团队、技术等级的高下和是否为技术一号位关联起来。尽管事实上带团队的业务研发同学成为技术一号位的概率更大，然而自身这两者不是划等号的关系。
那么什么是辨别是否为技术一号位的决定性因素呢？很简略：对一个具体的业务而言，你作为该业务的间接技术参与者，是否处在技术畛域责任链的最顶端。这句话翻译过去就是，对一个明确的具体的业务而言，多种角色的同学一起单干的时候，你是否是技术序列的最终责任人，即：谁承当对应的责任，谁就应该表演对应的角色。
当产品经理、经营、研发独特做一个业务的时候，某个研发同学单独或者率领其余几个研发同学，或者率领跨 BU 的研发团队，独特撑持 PD 的业务需要。那么这个研发同学就是这个业务的技术一号位，不管他是否带不带人，也不管他带的人在行政上是否从属于他。一般来说，负责繁多业务的研发团队 leader 个别就是这个业务的技术一号位；负责多业务线的研发团队的 leader 的上司，是每个业务线的技术一号位，而研发 leader 自身是更高层面业务的技术一号位。
所以，做业务开发的技术同学，不论是什么层级，带不带人，都可能是某个具体业务的技术一号位的。这一点十分重要，只有认清这个事件当前，业务研发同学能力在做业务的时候，明确下来本人除了须要写代码以外还须要做什么，关注什么；这些关注点须要做到什么水平，能力对上满足冀望，对下不让团队走弯路、不和上司抢功。
当你通过以上判断当前，确定本人是技术一号位时，祝贺你，你曾经不再是一个仅仅须要写代码的研发同学了。很多研发同学眼中还是只有写代码这一件事件，如果以这种形式做业务，那么就会发现业务过程会有各种没有做到位的事件，会在做业务的过程中“交很多学费”，甚至会因为本人的能力不够而拖慢业务倒退。
尽管成熟的研发团队能够通过齐备的研发过程治理，来防止集体能力不够而对业务产生太多负面影响，然而实质上强制的规定和“下级要求”只是在依附行政管理手段在强制一个人做这些事件，并没有唤醒他的创造力和责任心，反而会被认为是“工作琐事”。
这些“工作琐事”实质上是须要他表演的角色来负责的，然而因为他没有意识到本人实际上曾经是这样的角色了，而仅仅把本人停留在“研发”的定位上，把“写代码”当做外围工作，这样一来，会让研发同学对那些看起来“和写代码无关然而是技术一号位必须做的事件”十分冲突。这种抵触情绪产生的时候，leader 再强调 Ownership 也都没有太多成果，因为不是他不负责任，而是他没有意识到，这是他应该负责的事件。当他的心态和认知转变当前，一些原来看起来不怎么负责的人会变得负责（不排除有人自身就是不负责的人，那么这样的人不是良好的技术一号位的候选人，主管要有辨认能力）。
作为业务开发同学，肯定要认真认清分别本人本质上是不是一个业务的技术一号位，而不必思考本人的层级，不必管本人是不是业务其余参与者的 leader。当你意识到本人是这个业务的技术一号位的时候，就要迅速切换角色，从原来本人给本人的定位“写代码的、搞技术的”转变为“某个业务的技术一号位”，开始进入角色，施展出你的价值。这也是很多研发同学通过做业务能迅速成长的起因，抛开技术上的成长之外，他比其余研发同学接触了很多“做事件须要思考并为之口头”的维度，这些维度的丰盛是一般业务研发同学很难看到、很难感觉到，因而更难悟到的。
不排除有悟性高的研发同学可能本人悟到，但实质还是因为他所处的环境、他面临的问题在逼迫他做出思考，而后为之实际。如果一开始就晓得本人做事件要找准本人的角色和定位，那么就会少走很多弯路。
剖析你所在环境的局势
当你意识到本人是一个业务的技术一号位的时候，不必过多狐疑本人到底是还是不是，而是要本着“就当本人是”的心态来进行接下来的工作实际和思考。须要大家明确的一点是，任何一个工作角色，都有对应的责任，也都有履行对应责任的方法论。咱们要做的，不能再像过往做一般研发的时候那样懵懵懂懂去做事，听“需要”指挥，而是要开始寻找或总结一些方法论，要自顶向下地对业务有一个清晰的认知，晓得本人比过来多了哪些维度的事件要关怀，晓得接下来会面临什么样的挑战，要晓得本人在挑战中应该表演什么样的角色，采纳什么样的伎俩去解决业务在不同阶段肯定会呈现的各种问题。
在开始所有的思考之前，先要做一件事件，就是剖析你目前所处的环境的局势。
业务方面
• 你的大团队的业务大图是什么
• 你负责的业务的大图是什么
• 你负责的业务大图是否和大团队的业务策略匹配
• 你负责的业务和大团队的业务看似没有契合点的时候，你的 leader 跟你对焦当前的论断是什么
• 这个业务对客户的价值是什么
• 这个业务对组织的价值是什么
• 这个业务对你集体的价值是什么
• 这个业务是否会在将来承当社会责任，会有怎么的社会价值
• 这个业务目前处于什么阶段，是刚开始，还是曾经成型期待倒退，还是曾经倒退一段时间须要业务规模
• 这个业务目前存在最大的问题是什么
合作方面
• 谁在配合你一起做这个业务
• 和你一起做业务的同学中，别离有哪些角色，他们会在哪些方面和你有交加
• 和你一起做业务的其余角色的同学，是否对业务大图的了解和你统一
• 和你一起做业务的其余角色的同学中，谁是业务的负责人；或者要害角色的人员是否对本人是业务负责人有感知
• 业务上下游的同学段位怎么样，是否能在理论落地过程中跟上你的节奏
• 业务一号位的 KPI 是什么，你的 KPI 是什么，你们两人的 KPI 是否方向统一，你的 KPI 是否能撑持他的 KPI
团队研发方面
• 当初是否有一个研发团队反对你一起做这个业务
• 和你一起做业务的研发团队是否在行政上从属于你
• 你带的团队人员每个人的特点是什么，有什么短板，在这个业务外面负责什么事件
• 研发团队外面谁是你的接班人
• 研发团队外面谁能补充你的短板
• 研发团队外面，每个人做事都有什么集体的想法？集体的成长目标
• 研发团队外面的每个人对业务大图是否理解，认知是否统一，指标是否统一
如果你自身曾经是专家级别以上了，那么上面这些维度可能是须要你持续深刻思考的：
业务方面
• 业务的愿景是什么
• 业务的愿景在不同工夫维度上拆解当前的要害业绩指标是什么
• 为了实现不同工夫维度的要害业务指标，你筹备投入什么样的资源？投入的资源之间互相怎么配合？相互配合的准则是什么
• 这个业务当初做是否适合？当初做不适合的话，须要在什么时候做适合
• 这个业务当初做不适合的状况下，哪些因素让你感觉当初做不适合
• 让你感觉当初做这个业务不适合的因素中，哪些因素是能够通过人为干涉让它不再是妨碍性的，哪些是能够通过人为干涉减少它对业务的踊跃作用
• 业务的现状及瓶颈问题
• 业务问题的技术解法
• 业务发展趋势
• 业务竞合剖析
• 业务倒退策略
• 业务的终局畅想
团队方面
• 团队的使命是什么
• 团队推崇的价值观（做事准则）是什么
• 以后团队的人才梯队是否正当
• 以后团队的人才储备方向是否齐备
• 以后撑持业务的团队是否将来仍然可能撑持业务的倒退
• 以后团队不能持续撑持业务的战略规划的状况下，须要做怎么的调整
合作方面
• 业务是否能够向其余 BU 借力，或者借力于其余 BU
• 以后的业务是否和其余 BU 能够相互配合造成某种合力的劣势
• 以后业务和其余业务如何配合来实现将来的布局从而获取对应的劣势
• 将来的布局落地后，想要造成什么样的局势
• 局势造成当前，对实现组织愿景，履行组织使命有什么决定性帮忙
找准本人的定位，明确本人的定位的含意
当理分明本人所处的环境当前，晓得业务是什么状况，和本人配合的人又是什么状况当前，须要晓得本人表演的角色到底意味着什么。从我集体的教训来看，技术一号位是负责应用技术能力解决业务问题，提供稳固牢靠的技术撑持，确保业务平安合规低危险地衰弱倒退，并通过技术或业务翻新来推动业务倒退；负责向业务各方提供各种必要的技术撑持，通过正当的数据分析为业务决策提供根据；通过对技术畛域的积攒和倒退，通过业务畛域的了解和落地影响业务决策；负责构建梯队残缺、能力全面、制度欠缺的技术团队来撑持业务倒退。
应该有什么样的工作准则和要求
1、以业务一号位的视角思考，辅助业务一号位构建正当的业务大图。
2、以技术一号位的角色保障业务落地，帮助业务一号位实现业务的客户和组织价值。
3、把握和业务建设过程中各种角色的上下游协作者单干的业余能力：
• 在产品方面具备根底的产品布局和设计能力；
• 在业务方面具备有肯定深度的畛域常识，或者具备相干的方法论能够疾速向领域专家实现畛域常识的学习。
• 在商业化方面可能提供正当的商业化模型设计，蕴含提供正当的计费维度和技术老本清单。
• 在产品经营方面可能理解常见的根底经营伎俩和方法论，可能联合经营策略给经营同学提供精确的专业知识的撑持。
• 在客户沟通方面，可能有良好的聆听能力，了解客户的诉求，辩证地转换为零碎改良的能源。
• 在技术方面在公共技术服务的根底上实现全维度技术能力建设，思考技术的投入产出比，不能只做架构或只做外围代码的实现。
• 在团队方面可能建设正当的人才梯队，储备必要的技术畛域人才，推广组织文化，确保成员对做事的格调和准则了解统一，有卓有成效的方法论帮忙不同档次的同学找到成长的突破口。
履行技术一号位的职责具体须要感知哪些事件及其要点
上面这张图从大方面上列出了一个技术一号位须要感知哪些方面的事件（图中未列出产品经营、售前售后等一系列其实很要害的方面，然而如果技术一号位负责的业务是有商业化需要的，则还是须要关注这些维度的事件的）。
这些事件是必须晓得，但不是必须亲自做的，要可能借助团队的力量实现该实现的事件。上面是具体从业务、技术、团队角度来具体理分明技术一号位须要感知的事件及其要点：
业务方面（前面会有独自的文章具体解释业务方面怎么做）
• 建大图
• 定方向
• 找打法
• 撑业绩
技术方面
1、技术选型
• 业务须要什么样的技术能力撑持
• 须要的技术能力团体或其余 BU 团队曾经具备了并且能够被你复用
• 如果不能复用，差别点在什么中央
• 如果不能复用，差别点不是方向上的基本问题，是否能够通过共建或提出正当需要来实现复用
• 如果不能复用，不能共建，是否能够应用开源我的项目
• 如果不能复用，不能共建，须要自研，须要集体具备什么样的技术背景，须要团队具备什么样的技术积攒
• 团队或组织是否曾经有了相干的根底框架或效力晋升工具
• 业务是否须要思考数据安全问题，组织或团队是否有平安防护相干的积攒能够复用
• 业务是否须要思考业务危险问题，组织或团队是否有业务危险管制的积攒能够复用
• 业务个别状况下都须要数据服务做业务运行期的运行状况的监控和前期业务决策的撑持，组织或团队是否有相干的积攒能够复用
• 技术投入产出比
2、零碎架构设计
1）业务场景在技术侧映射进去的特色是什么，对技术侧的影响是什么？
• 一般而言，不同的业务场景会体现出不一样的技术特色，对技术反馈出不同的需要。
• 面向 B 端客户的传统企业级利用，通常状况下对稳定性要求高，对数据安全要求高，须要保障业务操作后果和理论数据匹配。业务流量不大，零碎用户对用户体验不如 C 端用户敏感。针对这类零碎，往往通过简略的单体利用做高可用部署即可，应用繁多数据库并通过数据库保障业务数据变更的事务，界面符合客户业务。
• 面向 C 端客户的互联网利用，通常状况下对流量承载能力要求高，对数据安全要求高，对用户体验敏感，对稳定性要求高，业务流量微小，非凡的业务场景会呈现非凡的流量峰值。针对这类零碎，往往须要构建分布式系统做大流量高并发高可用零碎架构建设，自顶向下分层优化，从终端层的动态资源 CDN 化，到应用层的前后端拆散，应用逻辑和底层服务拆散，再到外围业务层的微服务架构建设，从服务发现服务治理，到无状态利用的规模化部署，从大量根底中间件的应用，到大量公共业务服务的构建，每一层都须要做好对应场景的优化和架构设计。
2）如果业务会在某个倒退阶段波及到大用户流量，对应的零碎技术架构是什么样的？
• 大流量高并发高可用零碎架构
• 业务流程异步化
• 应用限流伎俩确保零碎不被突发大流量压垮
• 应用降级伎俩确保上游零碎不可用时可能疾速失败防止申请沉积造成零碎无奈承受或响应内部申请
• 应用逻辑隔离或物理隔离伎俩确保多租户模式下各租户互不影响
• 应用正当的资源调度策略确保不同规模的租户享受等同技术服务水平
• 应用正当的资源应用策略确保老本维持在正当程度
• 应用正当的监控伎俩提前发现零碎承载能力的变动，及时通过扩容或缩容来应答零碎流量变动
• 应用分库分表或依据业务需要采纳适合的 NoSql 数据库来撑持海量数据长久化
• 应用缓存抵御大流量对数据库的压力
• 应用分布式锁解决高并发业务场景下的公共资源抢占问题
• 应用幂等服务屏蔽高并发场景下的反复申请
• 应用分布式事务服务确保业务数据的最终统一
• 应用负载平衡承接业务流量，调配给后端应用服务器，防止单点危险
• 应用同城双机房来躲避单机房危险
• 应用异地多活技术来躲避单个城市的不可抵制危险
3）如果业务非常复杂，畛域泛滥，那么采纳什么样的架构更适合？
• 业务简单的状况下，采纳微服务架构
4）如果确定要采纳微服务架构来撑持简单业务，那么畛域划分和每个微服务是否匹配，微服务拆分粒度是否适合？
• 如果是单体简单业务利用拆分为微服务，则应该依照业务畛域来拆分，拆分后通过服务接口对外提供规范服务。
• 如果是开始就确定要做成微服务架构，那么要先做畛域划分和建模，而后大的简单的畛域独自造成业务服务，公共依赖的畛域做成服务，应用正当的服务治理框架，抉择正当的服务通信协议，构建业务零碎。
3、业务建模
• 业务畛域常识学习。
• 业务领域建模，应用畛域驱动设计实现策略设计（畛域上下文的划分和上下文之间的合作模式的确定）和战术设计（畛域内的实体、值对象、畛域服务、实体工厂、仓储层、数据长久化层的设计）。
• 业务建模是否正当，是否采纳了适合的方法论来应答不同简单规模的业务？
• 面对简单业务，是否有残缺的畛域设计和匹配以后阶段的落地门路？
针对简单业务，不须要最开始即依照残缺的业务模型做落地，而是依据理论业务需要和工夫进度正当定制业务模型的落地打算，既确保需要能按时实现，又确保代码落地始终在业务模型设计范畴之内而没有腐化。
4、研发落地
略
5、项目管理
• 我的项目指标
• 实现工夫
• 想要获得的后果
• 我的项目成员
• 要害里程碑
• 危险预警
• 多方协调沟通
• 日常进度追踪
6、我的项目复盘
1）品质保障
• 代码扫描
• 代码评审
• 研发单元测试
• 团队业务需要沟通及评审
• 测试用例编写
• 测试用例评审
• 根底功能测试验收
• 上线公布验证
• 灰度测试
• 线上验收测试
• 自动化冒烟测试
• 每日自动化测试
2）稳定性建设
• 要害业务流程日志打点
• 全业务链路跟踪
• 零碎技术指标监控
• 零碎业务指标监控
• 告警
• 自动化告警复原
• 要害业务场景预案建设
• 要害业务场景预案执行
• 值班响应机制
3）风控建设
• 业务危险点定义
• 业务危险点辨认
• 业务危险点级别定义
• 业务危险点分级解决
• 业务危险点报警
• 业务危险点触发趋势
• 实时业务危险管制
• 离线业务危险扫描
• 业务危险点诱因剖析
团队方面
• 成员 1v1 沟通
• 成员优劣势剖析
• 成员做事志愿剖析
• 成员角色定位对焦
• 成员能力梯队聚焦
• 方法论的探讨与实际
• 帮忙不同的人看到本身有余，定制不同的成长布局
• 依据不同人的优劣势和做事志愿，安顿调整正当的事件和责任范畴，激发做事的主动性，为其施展出创造力营造良好的环境
• 业务大图的解读和 KPI 的设定
• 工作准则和工作要求达成统一认知
• 明确团队要什么，不要什么，举荐怎么做，不举荐怎么做
• 要翻新不要按部就班
• 要思考不要苦劳
• 要突破思维定式和解放，不要自我设限
• 要 Ownership，不要推卸
如何成长为技术一号位
目前还不是技术一号位的业务发开同学，尽管当初的岗位只负责一小部分，然而实质上来讲，只有你负责某个事件，那么不管这个事件大小，你都是这个事件的技术一号位，只是因为事件的难易水平和规模大小，导致很多可能须要做的事件其实并不需要做，然而这些问题并不障碍你晓得技术一号位要做什么，应该怎么做，更不障碍你以技术一号位的心态去做事。
先确定好心态的问题当前，接下来就须要一些能够被实际测验的方法论来帮忙大家突破本人层级的解放，实现自我冲破，从而在成长的根底上取得负责更重要的事件的机会，通过做好更重要的事件来获取更更重要的事件的机会，这样肯定会在某个阶段，你负责的事件，须要齐全以真正的技术一号位的角色去落地，那么那个时候表演技术一号位的角色也就是瓜熟蒂落的事件了。
作者介绍：
贺迷信（晨末），毕业于北京科技大学，工作 10 年，在企业级利用架构及研发方面有长期积攒。善于分布式系统架构，善于简单业务的领域建模及开发落地，把握畛域驱动设计及开发相干方法论，有理论成熟线上产品案例；2014 年入职阿里云，先后参加或主导过阿里云控制台、阿里云容器服务、资源编排服务、云分期等云服务的建设。目前率领小型团队负责新批发业务相干的研发工作，累计 C 端用户过亿，承接阿里巴巴团体内外泛滥流量业务的积分兑换实物商品业务。
除业务以外，集体精力也投入在“简单业务零碎落地过程数字化”这一命题上，目前有肯定思考和理论积攒。理论工作中有 3 年带团队全面独立负责简单业务零碎的教训，所以在技术一号位的工作方面有相干的实际和思考。
原文链接
本文为阿里云原创内容，未经容许不得转载。
