- 博客(699)
- 收藏
- 关注
RSS订阅原创 成为会带团队的技术人（二十）接手新团队：士气低、交付迟、事故多发，如何下手解决？
一晃两个多月的时间过去了，坦白说这几个月的写课经历比我预想得要困难许多，因为需要不断打磨稿件，思考怎么写才最能让你有所收获，再加上我最近在创业，写稿时间都是一点点挤出来的，熬心又熬力。最开始思考课程定位时，我并没有把它完全定位成“管理课程”，所以在最初几讲，和你聊了一些我认为技术 Leader 必须做好的事情，比如稳定性，而不是所谓的管理方法论，因为再好的方法论只有结合实际的场景发挥作用之后你才会觉得有价值，不然就仅仅是无意义的说教了。
2025-11-24 23:44:40
736
原创 成为会带团队的技术人(十九） 做规划：除了交付和稳定性，还要规划什么？
如果公司本身就会制定季度规划/半年规划，并要求每个部门和团队都要做，在这种情况下，所得出的规划有一定作用，但是大部分是为了与上一级目标保持一致；反之，如果公司并没有硬性要求，但技术团队负责人主动去做，说明愿意长期去完成一些事情，是好的习惯。而有意识地做团队规划价值很高，你可以通过做规划，严肃、完整地重新审视团队的情况和问题；
2025-11-23 21:17:25
652
原创 成为会带团队的技术人(十八） 跨团队：没有汇报线的人和事就是推不动？
在“05 | 大项目：把握关键点，谋定而后动”和“11 | 勤沟通：在信任的基础上，让沟通简单”两讲中，我提过“跨团队”这件事，很多同学带团队之后，无法回避的一个问题就是“跨团队协作”，对于技术 Leader 这是一件日常工作：在指定的时间与约束规范内，不同部门之间（产品、运营、技术、业务……）或者与外部团队的个人之间，通过配合完成一项明确目标的独立的任务。
2025-11-23 20:33:53
833
原创 成为会带团队的技术人（十七） 晋升：是不是技术到位、项目做好就够了？
回到我们这一讲的核心问题“晋升：是不是技术到位、项目做得好就够了？”在我看来并不是的，晋升与其说是一个机会或者一件事，不如说是一套完整的人才梯队建设体系，从业绩到能力和潜力，缺一不可。好的晋升机制可以让团队越来越强，优秀的人承担更多的职责，发挥更大的作用；反之，糟糕的晋升体系会让好的人才流失，糟糕的人“留下”，最终团队肯定是越来越弱的。本节课内容的脑图如下：留个作业吧：你上次晋升是一个什么情形，对你有哪些触动？欢迎在留言区分享你的看法，我们下一讲见。
2025-11-22 16:22:10
1013
原创 成为会带团队的技术人(十六） 升级汰换：“心要慈，刀要快”
总的来说，技术 Leader 要正确对待升级汰换，从团队的角度出发，正视而不回避。要知道，招聘厉害的人，会出现鲇鱼效应，解聘一个不合格的人，也会有类似的效果，对团队发展的影响也是极强的，相当于刮骨疗伤，虽然短期很痛，但是长期来看，团队会得到更好的发展。留个作业：你认为什么样的人一定要离开团队，为什么？欢迎在留言区分享你的经验，我们下一讲见。
2025-11-22 15:54:22
459
原创 成为会带团队的技术人（十五） 能落地：90 天试用期，转正时我们要考察什么？
总的来讲，招聘到落地其实是生与养的关系，大部分情况下，我们招聘是因为缺少对应的角色或者人力不足，可新同学想要转化为团队的战斗力并不等于简单到岗。这一过程也是一个漏斗，只有让新同学更快、更好的落地，真实发挥作用，在招聘时付出的精力和时间才有价值。与此同时，新同学能否与团队建立情感连接在这一阶段也很重要，好的落地Landing 不仅对新同学更有帮助，同时也会增加他对团队的认可，极大增加团队的凝聚力。最后，分享一下你作为新人落地时印象深刻，或者觉得最有用的动作都有哪些，为什么？
2025-11-22 15:34:02
969
原创 成为会带团队的技术人 找到人：(十四）招聘是 Leader 的责任，不是 HR 的
从今天开始，我会用三讲的时间和你聊一聊。，今天咱们就先来学习怎么才能找到人。过去几年，招聘一直在我的工作中占据很大的比重，在这个过程中，我发现这样一个现象：很多 Leader 认为招聘是 HR 的责任，HR 把控着筛选简历、找候选人、安排面试、谈薪以及 Offer 发放的整个环节，自己只做技术面试，通过专业能力“判断”候选人是否符合团队需要，不会参与其余环节。这种想法在公司初期扩张阶段并没造成什么不好的问题，不过在 2017、2018 年还是有了比较大的改变。
2025-11-22 01:43:06
817
原创 171. 生产经验：真实生产环境下的数据库机器配置如何规划？
所以一台机器能抗下每秒多少请求，往往是跟你每个请求处理耗费多长时间是关联的，但是大体上来说，根据我们大量的经验观察而言，4核8G的机器部署普通的Go应用系统，每秒大致就是抗下几百的并发访问，从每秒一两百请求到每秒七八百请求，都是有可能的，关键是看你每个请求处理需要耗费多长时间。这还在4核的能力范围内。我们主要关注的是有一定并发量的互联网类的系统，对数据库可能会产生每秒几百，每秒几千，甚至每秒上万的并发请求量，对于这类场景下，我们应该选择什么样的机器去部署数据库，才能比较好的抗下我们的系统压力。
2025-11-22 01:17:59
681
原创 成为会带团队的技术人(十三） 知人善用：借事修人，借人成事
上一讲，我带你学习了建机制的相关内容，如果想将机制落地，你首先要建立足够的认知，明确机制的作用以及好机制具备的三个必要条件：规则统一、简单有效便于增减、对整体结果有利。。所以这一讲，我们就来学习“建团队”的最后一个动作：知人善用。拿结果三要素：定目标、追过程、奖优罚劣建团队三要素：勤沟通、建机制、知人善用直白点儿说，知人善用就是指技术 Leader 怎么用对人？用好人？核心在于怎么给事情安排对的人？怎么给人安排合适的事情？
2025-11-22 00:05:20
843
原创 成为会带团队的技术人（十二） 建机制：规则流程越建越多，为何效果却越来越差？
希望团队内所有成员都按照统一的方式去合力解决一个问题非常困难，而建机制在某种程度上就是为了解决“群策而不群力”的问题。另外，每一个机制的创建都存在成本，如果一个组织内名存实亡的机制过多，那么大家对机制的认识和执行都会越来越差，最终团队会一盘散沙、毫无凝聚力。反之，设计良好的机制会让团队整体的执行力提升，并且最大程序的将每个人的能力与特长整合起来。留个作业：你所处的团队有没有哪些机制是你认为很糟糕的，为什么？你觉得应该如何改进？
2025-11-21 23:27:59
960
原创 成为会带团队的技术人（十一） 勤沟通：在信任的基础上，让沟通简单且纯粹
沟通不外乎是一边说、一边听，通过说来表达自己的想法，通过听来明确对方的想法，最终在不断来回的过程中达成共识。所以好的沟通既要有自己的观点，又要认真听，根据对方的反馈来把控整个沟通节奏，引导对话往你希望的方向走。总的来说，这节课我提到了接地气、讲人话、视人为人、不偏见、不傲慢，真诚地去建立信任和联系，而这就是我认为的沟通技巧，简单但是有效，希望对你也有所帮助。最后留一个作业：让你印象最深刻的一次沟通是什么，为什么你至今念念不忘？欢迎在留言区分享你的想法，我们下一讲见。
2025-11-21 22:38:36
602
原创 成为会带团队的技术人（十） 奖优罚劣：怎样传递我们要什么与“不要什么”？
你首先要对“奖优罚劣”有个清晰的认知。在我看来，奖优是通过一些具体的动作（调薪/晋升）告诉大家团队选择什么样的人，鼓励什么行为，罚劣表明团队不需要什么样的人，不能容忍什么行为……它的本质是传递团队要什么和不要什么。你也可以理解成论功行赏，按结果问责。物质上的奖优作用大，但是频次较低，比如以半年/年为单位的晋升、调薪，它能够打开成员的天花板，比如拿了A绩效的同学，第二年他依然希望是A而不是B，从而提高对自己的要求与期望，更容易取得好的成绩。
2025-11-21 21:15:28
756
原创 成为会带团队的技术人（九） 追过程：如何用 PDCA 做过程管理？
要想探讨这个问题，我想先抛出我的管理理念（也是“管理者三板斧”的核心理念），在我看来，管理动作要形成可持续迭代的闭环；管理动作足够简单到可以复制和个性化升级。过程管理当然也遵循这个理念。比如你这次 A 项目做得很好，下次做 B 项目时能否依然做好？在 A 项目中发现问题、解决问题的方法和思路，是否可以在 B 项目中沿用？这就是方法的形成与积累。
2025-11-16 18:39:43
867
原创 成为会带团队的技术人（八） 定目标：让你的方向与公司的方向保持一致
所谓的方向与目标就是：你要往哪去，你要走多远，你要走到哪。清晰的目标就好比沙漠中的指南针，让你能比其他人更快找到水源并生存下去，今天这节课，我提醒你注意这样几点：解读目标非常重要，切勿陷入极端，要么不解读，要么领导说什么就是什么。制定目标一定要够聚焦，但切勿只考虑眼前，注意“长短结合”。注意目标传递，要充分考虑团队成员的感受，选取合适的方式。也许你会发现，目标的制定只是拿结果的起点，而拿结果也只是整个团队里的一部分。
2025-11-16 15:42:58
860
原创 成为会带团队的技术人（七） 架构设计：治理好系统复杂度才最务实
上一讲我们以架构之名聊了一下理解业务这件事儿，这一讲我想进一步来聊一聊日常工作中架构工作的核心关注点是什么？我是在接触分布式开发之后，才对“架构”有了概念，从三高（高可用、高性能、高可扩展）到 DevOps（集群、网关、复杂均衡等），从系统的功能模块设计到微服务的业务建模、领域设计。很长的时间里，架构好似包罗万象，可以装进与技术相关的所有内容，给人的感觉就是想做好架构就要无所不精无所不通。
2025-11-16 02:59:58
857
原创 成为会带团队的技术人（六） 业务理解：深入业务是做好架构的前提
前面 5 讲管理分享了一些过往的经验与思考，从今天开始，我会用两讲的时间，围绕“架构设计与系统演进”与你分享我的经验。这几方面是我认为技术 Leader 在技术工作上一定要做好并且极为重要的，从八二法则上看，它们也是我认为值得花 80% 的精力去做好的，而你能否做好这几点会影响团队未来的发展。。
2025-11-16 01:02:05
951
原创 成为会带团队的技术人（五） 大项目：把握关键点，谋定而后动
对技术 Leader 来讲，团队的开发模式多以项目制或敏捷迭代为主，不论哪种方式，项目管理都是最主要的工作之一。在互联网公司中，日常迭代和重点项目的同步进行几乎成了常态，你也会遇到一些特殊的项目，比如“一号工程（老板项目）”、“技改项目（核心系统重写）”、“倒排期的重大业务（11.11 和 618 的大促、新业务新产品研发）”。这些项目我统称为“大项目”。公司基于战略规划等目的，一定会启动大项目，你必须具备处理这类项目的能力，并不断抽象与思考，形成自己的方法论。这是环境对你的要求。
2025-11-16 00:13:16
912
原创 成为会带团队的技术人（四） 技术债务：如何带领团队从困境中突围而出？
比如开发者编写了低质量或者有潜在风险的代码；对系统的实现和运行不了解，重复代码被大量构造，缺少抽象与沉淀；缺少完善的开发机制和流程把控，比如测试、文档等方面做得不到位……
2025-11-08 21:06:44
925
原创 成为会带团队的技术人（三） 稳定性（三）：那些年源源不断的“红包”事故
今天咱们来聊一下资损事故的防控。我想你一定很熟悉近几年“百亿补贴”“天降红包”“签到抽奖”这些电商、外卖、打车花样百出的营销活动和用户补贴。
2025-11-08 18:04:30
805
原创 成为会带团队的技术人（二） 稳定性（二）：可用性治理的三个关键要点
上一讲我们学习了事故的应急和复盘，但“预防胜于治疗”，所以今天我想从事故预防的角度和你聊一聊可用性治理的关键动作。可能你听过这样一句俗语：只有千日做贼，没有千日防贼。但是在系统稳定性建设上，却无法通过一次优化完全杜绝事故发生的可能。因为业务发展会带动系统演进，它是一个动态变化的过程，并非一个常量，。在这个过程中，上线环节是事故的高发阶段，因为随着变更的加入，原本系统稳定的运行状态会被打破；编码与测试阶段主要是实现功能，但不合理的实现是在架构设计阶段就被埋下的。
2025-11-08 17:17:20
691
原创 成为会带团队的技术人（一） 稳定性（一）：如何应对事故并做好复盘？
通过一次事故，解决一类问题，让一个人（团队）踩过的坑变成所有人踩过的坑，正所谓“一次学费，受益终身”。
2025-11-08 16:07:24
669
原创 【成为会带团队的技术人】（前言） 在管理艺术中寻找确定性的“工程逻辑”
当然，你可能觉得“管理”“带团队”离你很远，因为技术才是你的真爱，但实际上如果你的技术出色，积累了 3~5年的技术经验，具备编码（Coding）、系统设计与实现的硬核实力，很可能就被推着走到“管理”的角色上，让你开始做沟通协同、团队搭建等工作，而这个情况在互联网公司中很常见。某种程度来说，它并不受角色和业务的限制，是非常基础的管理“套路”，你甚至可以先用它来带团队，然后再结合实际的工作场景去扩展它，简单意味着容易理解，并且很好实践。当然，很难有一个明确的标准去衡量你会不会管理，管理得好不好。
2025-11-08 14:55:38
638
原创 170. MQ本地消息表模式是如何保障分布式最终一致性的
事务消息是投递消息的一种方式，可以确保业务执行成功，消息一定会投递成功。需要在业务本地库创建一个消息表(t_msg)id varchar(32) not null primary key comment '消息id',body_json text not null comment '消息体,json格式',status smallint not null default 0 comment '消息状态，0：待投递到mq，1：投递成功，2：投递失败',
2025-04-06 01:42:43
889
原创 168. DDD战术设计改造实践（三）：货拉拉用户CRM改造实践
在本文中，我们深入探讨了DDD战术设计架构模式，并为大家分享了我们货拉拉用户CRM的实际落地经验。以笔者个人的经验来说，DDD首先，DDD的实践并没有统一的标准或固定的模式，每个团队都应该根据自身的业务需求和实际情况来进行设计和调整。其次，不要过于局限于DDD的理论概念，理论与实践之间存在差距，灵活应用才能真正提高开发效率和实现业务价值。最后，牢记DDD的初心——通过更好的业务建模，提升业务系统的维护性和扩展性。无论在何种背景下，DDD。
2025-01-20 01:09:00
984
2
原创 167.DDD战术设计改造实践(二）： 商城订单业务编码实战
无论在什么领域，订单业务都是一个比较复杂且典型的场景，考虑到本文的读者可能来自不同的行业，为了便于大家理解，这里我们选择了商城订单业务中的用户下单场景来演示DDD的编码实践。以此来为读者逐步展开讲述DDD战术设计中的实践形式。
2025-01-19 22:48:46
1119
原创 166. DDD战术设计改造实践（一）：DDD简介
在快速发展的互联网行业中，企业的业务需求和技术架构之间的关系愈发紧密。如何在复杂多变的业务环境中保持系统的稳定性、灵活性与可扩展性，一直都是技术团队面临的重要挑战。注：由于篇幅有限，本系列文章以实践为主，DDD相关基础概念请读者自行查阅资料了解。希望通过这篇文章，能够帮助同行们更好地理解DDD战术设计在复杂业务系统中的应用，并为未来的技术创新与业务发展提供借鉴与启发。
2025-01-19 20:44:44
1127
原创 165.如何开发一个好的接口
接口其实是一种规范，在生活中随处可见，比如：不同厂商的水管使用统一的水管接口对接、电脑厂商和配件厂商按照统一的USB接口标准进行生产完成配对、应用程序之间通过API进行信息交互。亚马逊集团创始人贝佐斯规定，亚马逊的所有系统、团队之间的交互，都必须通过服务接口，现在云计算技术非常火爆，其起源实际上是亚马逊的这种API文化，可以说，API构建了当前数字化世界的通路。所有的团队必须通过服务来对外暴露数据和功能。所有的团队之间的功能，必须通过这些服务接口来进行交互。网络上不允许任何除服务接口的其它交互方式。
2025-01-19 18:30:18
1146
原创 164.链路诊断最佳实践：1 分钟定位错慢根因
【toc]本文聚焦于线上应用的风险管理，特别是针对和两大类问题，提出了一个系统化的根因诊断方案。线上应用风险主要分为“错”、“慢”两大类。JVMCPUFGC然而，面对复杂的应用间依赖，如何抽丝剥茧快速定位异常节点，深入分析异常背后的根本原因，并在极短的时间完成定位与恢复动作，每一步都面临巨大的技术挑战。根据近十年APMTraceAPPABC3sABSQLCLLM。
2025-01-04 23:02:48
1098
原创 163.浅谈API错误码设计与链路追踪
根据亚马逊官方文档的定义，错误码是通过对错误进行抽象，帮助用户或开发者识别和理解异常性质的代号。错误码与具体错误不是一对一的关系，而是错误类型的一种抽象表示，如策略执行失败是一个错误码，但是引起策略执行失败的错误原因可能很多。尽管错误码在系统中只是一个小模块，但它是不可或缺的。错误消息应该帮助用户轻松并快速地理解并解决API错误，以下是一些设计原则：不要假设用户非常了解你的API。用户可能是客户端开发者、运维人员、IT人员或者APP的普通用户。
2025-01-04 22:36:39
962
原创 162.如何尽可能快地上手一个业务or项目？
了解了这些可以方便我们以后定位不同的代码在的位置，方便我们快速定位我们疑问的答案可能会出现在哪个目录（包）下。之后我们就可以开始链路上的熟悉，参照我们之前搞出来的数据模型，我们可以逐个了解数据模型在系统内对应的业务逻辑设计/实现（这些在文档里或多或少也会提及，我们要对比着看），对于每个模块或者功能的业务流程，我们可以边看边作业务流程图来梳理。作图可以帮我们理清逻辑，也方便实在有看不懂的地方的时候，请教他人。当然啦，遇到看不懂的流程也很正常，每个系统都会有很多新手不友好的内容。
2025-01-01 17:46:46
694
原创 161.Go语言Optional模式和Builder模式对比
Optional模式和Builder模式都是Go语言中用于对象构建和配置的重要设计模式。Optional模式通过函数选项提供灵活的配置选项，适用于参数较少且相对简单的情况。Builder模式则通过逐步构建对象并提供多种配置选项，适用于构建复杂对象的情况。在选择使用哪种模式时，应根据具体需求和对象复杂程度进行权衡。
2025-01-01 17:30:03
747
原创 160. 两种常用代码范式
文章中的代码范式可以应用在大部分场景，在项目初起的时候直接套用，可以省下大部分关于包模块划分的思考精力，并且在后续迭代中，团队统一规范，持续按照这个框架演进，可以让代码更加井井有条，减少一些诡异的类职责划分问题。
2025-01-01 16:55:16
923
原创 159.Go简易本地缓存包go-cache一览
go-cache 是一种内存中的键值存储/缓存，类似于memcached，适用于在单台机器上运行的应用程序。它的主要优点是，本质上是一个具有到期时间的线程安全map[string]interface{}，它不需要序列化或通过网络传输其内容。任何对象都可以存储一段时间或永久存储，并且缓存可以安全地由多个goroutine 使用。
2025-01-01 15:34:54
743
原创 158.Go语言并发模式实战指南
并发基础Goroutine是 `Go`` 并发的基本单位Channel是goroutine间通信的推荐方式合理使用context控制并发流程并发模式选择生产者-消费者模式适合任务队列处理扇出模式适合并行处理任务扇入模式适合多数据源聚合根据实际场景选择合适的模式性能优化关键使用对象池避免频繁创建对象合理设置缓冲区大小控制并发数量注意锁的粒度最佳实践要点始终处理错误情况实现优雅关闭添加监控指标注意资源释放实践建议开发阶段编写单元测试验证并发逻辑使用。
2025-01-01 13:35:11
777
原创 智能风控决策引擎系统代码实现篇（十一）基本信息定义【操作符、特征、规则】
前几篇文章我们已经介绍完了服务启动时的各种加载和启动工作，但实际最底层工作的最小单元是规则，规则的执行则依赖特征和操作符，本文我们就介绍与它们相关的代码。
2024-12-25 22:51:32
392
原创 智能风控决策引擎系统代码实现篇（十）加载DSL转换为决策流DecisionFlow，启动Gin路由、决策流启动执行
在上一篇文章中，我们已经介绍了Dsl元信息，决策流执行基本要素INode接口，以及决策流构成、决策流执行上下文记录器Pipeline。本文接着介绍，将决策流yaml文件加载为Dsl结构体到内存，而后转换为决策流，并启动Gin路由，监听执行请求。本文完成后的目录结构。
2024-12-25 21:54:48
556
原创 智能风控决策引擎系统代码实现篇（九）Dsl、INode接口、DecisionFlow、Pipeline上下文定义
DSL: 读取yaml文件后对应的结构体，还需要转换为才是真正可以执行的图: 可实际执行决策流（图)，FlowNode记录了具体的一个节点类比到DB存储，则是DB一条记录是一个DSL元信息配置，我们将其加载到内存后用结构体（DSL）保存，而后这个结构体需要再转换为另一个结构体（DecisionFlow）方可执行。
2024-12-25 21:22:21
716
原创 智能风控决策引擎系统代码实现篇（八）配置文件加载与日志模块
在项目中，日志是不可获取的组件，我们后续万一有问题，最有效的手段就是根据日志排查各种问题。为了后续可以很方便的获取到配置信息，我们专门定义了全局变量，用于存储配置信息。运行后输出如下，因为我们这里选择输出到文件，所以本地会产生一个out文件。在服务启动时，一般第一步就是加载相关的配置文件，如服务启动的端口号，最后，就是服务启动时，将配置文件的信息加载，保存到全局变量中。最后，我们可以将日志的初始化，也放到服务启动入口。接着，我们需要写一个Logger接口的实现类。等服务地址，日志相关配置等。
2024-12-25 20:16:19
494
原创 157. Go实现指数后退算法的自旋锁【单机+Redis版（带自动续期）】
工作中经常会用到锁来处理一些并发安全问题，拿到锁的协程可以执行某些操作，获取不到锁的则需要进行等待。
2024-12-22 22:52:52
1171
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人