饿了么四年+阿里两年：研发路上的思考与总结后端架构与团队，2014-2017年先后负责公司客服、销售、代理、支付、清算和结算、订单；2018年退出业务研发团队，组建6人团队。团队致力于机器学习，结合实际业务场景，尝试通过技术改造业务；2019年回归平台（中台）研发，负责交易、金融、营销三个中台的研发和团队工作。结合我在饿了么4年和阿里巴巴2年的研发经验，我想从技术、业务、管理、架构等方面分享一些思考。在技??术层面，对于开发类学生来说，技术是立身之本。虽然他们经常面试造火箭和拧螺丝，但不可否认的是，技术是你职业生涯的基石。无论是基本的动手能力还是问题分析能力，包括你的思维逻辑甚至是对事物的认知能力，技术思维都会一直影响你。最明显的影响是当你面对无数钉子时，技术是否是你最舒服的锤子。在技??术方面，我比较注重几个层面：基本功（语言、编码水平，主要是动手能力）；具有大型分布式系统（RPC、SOA、MySQL、Redis、MQ）的实践经验；项目（DB设计、API合约、DDD抽象、链路设计、项目风控）；稳定性（可用性和资本损失）。1、稳定稳定是先有意识再有能力的问题。记得2015年初，张雪峰加入饿了么担任CTO后，从他嘴里听到最多的一句话就是“研发要敬畏生产环境”。2014年下半年，各行各业开始进入外卖市场。饿了么启动百城计划，拓展业务。短时间内，从10+城市覆盖到100+城市，日订单量从10万迅速增长到100万。虽然业务井喷，但技术还不够成熟。在我的印象中，2014年下半年几乎每天中午交易量都创新高，但同时也伴随着系统宕机、限流扩容、紧急调优、客服等问题突发、技术加班和熬夜。我曾经在新乡的客服中心看到，有的客服同学突然崩溃，耳机掉了直接离开了车站，因为他们每天接到大量的用户电话，就在那一刻，你其实清晰直观地感受到：你在编辑器里写的每一行代码，你在服务器上做的每一次发布，都会直接影响到现实世界中很多真实的人，你会突然意识到你的工作更重要更有意义比你以前想的要多。所谓研发要对生产环境敬畏，就是你知道你的工作会对别人造成不好的影响，你会因为不好的结果而感到羞愧和内疚，这就产生了敬畏。应急响应有一个基本原则：“尽量减少业务影响，以恢复为核心，不纠结于手段和根源”。不要把你的自责、决心、求稳、各种奇思妙想、执行力等在事故回顾会上体现出来。系统的安全生产与火灾一样，事前有意义。2.链接设计大多数产研公司都缺乏全链接的视角。他们往往看到自己负责的点，却看不到一条线，甚至整个面，也没有机会去思考。对于一些大型项目和长链接系统来说，这是致命的。我的建议是，对于你所负责的系统，一定要熟悉它的上下游和核心业务的关键环节，包括数据、接口（调用、函数、逻辑）、各种异常处理、特殊设计等。帮助您做到这一点的最简单方法就是画、画、画！重要结论说三遍。你必须会自己画出系统的大图，然后你可以根据大图随意放大缩小。放大把链接画进业务场景，突出业务逻辑和上下游交互，缩小到某个调用的一般处理逻辑和数据如何变化。经常画画，不用担心形式和标准。重要的是形成一个理解系统的框架和自己的思维方式，需要的时候可以随时使用。日常生活中不管是讲需求，还是做系统设计，如果习惯性地画图，就会事半功倍。剩下的一半要看图思考，找问题。3.永远不要骗自己技术债务，现在就为这个需求挖个坑，过段时间再补上（重构或重做）。技术债和金融债一样，是必然存在的，会像流氓一样挂在嘴边，时不时地爆发。随着时间的推移和业务的发展，你会发现架构越来越混乱，不同系统的领域边界越来越模糊，系统与需求、组织关系的映射越来越多和越来越复杂，服务中编码的风险控制也越来越复杂。不一致的、重复的轮子一个接一个地阴险地出现。“太忙没时间整理哪些问题”，“改那些问题需要上下游都去搞定，费时费力，推不掉”，“还没有问题，还正在整理中，不要着急。”这是我们经常听到的声音。其实技术同学或多或少都比较执着于代码整洁度。有很多问题没有处理好不是因为主观原因，而是客观上因为精力、时间、ROI等因素。我们往往要等到问题真正爆发出来，大家才能解决问题。.我以前处理技术债务的方法是有一个清单，我会定期审查所有系统，并考虑到我的团队和其他团队的事故，以清除所有地雷。系统本身就是平衡的产物，是时间、功能、风险、未来可能性等几个方向平衡的结果。所以，对研发同学技术债的考验，不是你在日常工作中如何保证系统的技术债为0，而是你要评估清楚哪些问题是紧急的，哪些问题可以在有限的资源下解决和时间。放手吧。很难想象一个没有技术追求的团队能开发出健壮、可维护、可扩展的系统。相反，这种业务代码的堆砌，短期内可能会“快速”实现业务需求，但从长远来看，这种烂系统的增多会极大地阻碍业务的发展，形成应用的黑洞。一。工程师们被困在业务需求和糟糕的系统之间，筋疲力尽。这会导致系统腐败和退化，技术债务越来越高，丑陋的代码疯狂生长，像肿瘤一样消耗你所有的能量，最后要了你的命。4.警惕大型项目。不是每个人都有能力管理大型项目，也不是每个人都能平衡交付压力、发布质量、产品逻辑和时间窗口。这是一个非常具有挑战性的工作，需要纯技术辅助能力之外还有很多软能力，比如组织沟通和协作能力，权力和责任的需求能力，产品业务期望的平衡能力，响应能力到紧急情况。工程越大，对Owner的要求就越高，真正能把大工程做好，不留大坑的，少之又少。一个大项目从立项到立项的时间往往远远超过项目的实际开发周期。项目的顺利进行需要“妥协”，但项目的成功需要坚持。很多项目之所以失败，是因为在做的过程中在各个方面都在不断的妥协，最终做出来的东西和当初想要的相去甚远。除了业务层面的技术，研发同学还需要提高对业务层面的理解和关注度。对于研发，商业就像一门外语。如果您不懂业务，就像在国外一样。与产品、业务、运营等其他工种相比，技术更倾向于与技术打交道。在大多数学生眼里，生意很乱，没有秩序。没有像技术那样清晰的实现路径和稳定的共识知识结构。而且，技术相对容易被证伪，而商业往往是不断的尝试，研发讨厌“不确定性”。但是如果你想在一个庞大的组织里做好技术，你就必须和业务打交道。毕竟，业务是公司的核心价值。1.根据业务规划做技术规划很多同学习惯把规划等同于策划。阿里是一家尊重技术的商业公司。所有的团队都在谈论业务，计划中的业务规划，周报中的业务项目，报告中的业务成果。升职的时候，也要突出自己的“军功”。与技术本身相比，大家更关注的是技术改变了什么。这就是我们为什么要在业务部分讲技术团队如何规划的原因。这是公司运作的出发点（目的），只有延伸出来，才能有具体的技术规划和组织设计作为解决方案。深入理解业务和设计策略，拆解活动和项目，通过组织和各种机制确保项目执行和落地，最终取得业务成果。这是大公司标准的战略执行方式。研发同学在做技术规划和团队规划的时候，一定要考虑你的环境，公司今年会重点做什么，各大部门的目标是什么，对应的产品和业务状态是什么，纯技术迭代的好处在商业场所。另外，目前团队有哪些不可抗力，或者影响计划进度的阻力。很多同学在规划的时候会习惯性的按照这样的思路：①总结现状（痛点）②相应的解决方案和策略③展望未来。有时②和③的顺序会颠倒。很多时候人们发现最后的部门规划和自己的规划没有任何关系，不知道该往哪个方向努力，或者干脆继续按照自己的规划走。对于大多数学生，我建议规划应该切合实际。在做技术规划之前，跟你身边的研发团队聊聊，跟你对口的产品和运营聊聊，知道他们的目标是什么，知道公司的重点是什么，然后结合你现在的痛点，现在和未来找到之前的平衡点，找到对现在和未来都有利的部分。规划需要包括一些硬性内容，比如这个目标要解决什么问题，如何保证解决，是否解决好，好的结果谁来认可等等，规划要有重点。如果没有关键点，那就不是计划，而是进度表。很多学生不参与规划，有自己的“想法”。比如公司的业务或战略变化太快，组织调整太频繁。不可否认，变化是频繁的，这种组织变化对规划的影响，但如果你一直这样想，你永远不会从变化中获得价值，因为你总是在观望。2、研发应该比产品更懂业务。雷军说：“永远不要试图用战术上的勤奋来掩盖自己战略上的懒惰。”对于R&D同学来说，必须比商科学生更懂业务，才能找到技术和业务的平衡空间。对于大部分同学来说，往往只熟悉自己负责的系统，但是对于想要更多空间，更多成长的同学，我可以给出一个明确的结论：仅仅熟悉自己负责的系统是不够的.首先，不同的人对熟悉度的定义不同。仅仅熟悉你负责的系统是不够的，你贡献代码，你设计并完成需求交付。不仅要知其前世今生，一路思其成长，忧其未来发展，更要知其风险隐患，知其生死。基于你最了解的核心系统，从中开始扩展业务场景，从而了解你的上下游，可以结合业务场景进行挖掘。从业务的角度，从产品环节，从技术优化和隐患多角度，让自己的设计维度和视角不断增加，这样你的信心或者控制的范围就会越来越大，就会有将来会有更多的机会。管理团队是一个宏观和微观并存的东西。宏观上讲组织、谋略、谋划、编兵。在微观层面，我们专注于沟通、成长和情感。大多数同学之所以在微观层面受挫，是因为没有把握好宏观层面的节奏。公司是营利性机构，技术中心是成本部门。技术中心之所以有一定的组织，一定是：“公司期望这个组织解决某一类问题，并在一定程度上解决它。”所以这里你要明白一个关键词，“结果和KPI”并不取决于你如何定义它，而是看给你下放目标的组织和管理者对你的期望是什么。你的GAP往往不一定是结果的差异，而是期望的差距。1.拥抱变化其实很多时候你不需要拥抱，变化会突然抱住你，勒紧你的脖子，让你有一瞬间呼吸困难的感觉。互联网公司之所以变化快，很大程度上取决于其业务属性。与传统企业相比，互联网企业能够更快、更清晰地感受到与市场的契合度，并及时调整策略。结合过去几年的经历，以及加入阿里巴巴这两年，我有两个核心感悟：一是要对业务发展和环境变化保持敏感。如果您可以在更改发生之前主动发起更改，那么最好将被动变为主动。即使做不到，也要清醒地感受和思考变革背后的驱动力在哪里，找到发力点，才能适应变革；二是工作内容的调整，汇报路线的调整，变化带来的团队调整。变化等，无论是好是坏，在一段时间内都是相对的，而不是在一个人的工作生涯中是绝对的。在不可能顺利的时候，调整心态，让自己跳出情绪，多关注事情本身，会是更好的选择。2、加人不能解决问题。即使你说“不能”，你的行为也会很老实，你仍然会尽可能多地索取HC，希望在你的职责范围内建立更多的“核心”系统。其实，从管理的角度，你可以看看自己是否“有效加人”。有的技术负责人不重视新人的落地，相当于注重数量不注重质量。最后的结果一定是一团糟。从绝对的理论角度来说，加人肯定是有帮助的。你有更多的资源，你就有更大的周转和经营空间。但从经验来看，在大多数情况下，人的加入并不会产生最终的价值变化（项目的结果，业务的成败）。因为系统的开发和项目的推进不是简单的资源积累，1000人一天的系统是不可能1000人一天建起来的。在现实世界中，我们往往不是被使用的资源量打败，而是被资源使用的方向和效率打败。3、自觉向上管理这个问题源于以往的两点经验：第一，我经历过无数次组织关系调整。除了不带人和带多少人之外，更看重的是自己的汇报线。我向谁汇报，谁是我的Leader，我能和谁相处，他能不能让我进步和成长。第二，很多同学会搞不清楚和Leader的关系。基于这两点，我把向上管理单独加了一个话题。先说结论：是的！想！想！必须！必须！就连马总也说，员工离职的三大因素之一就是跟领导合不来。怎能安心无视。如果你还以一种听话甚至奉承向上管理的态度来处理你们的关系，我只能说太不成熟了。向上管理我没有系统学过，也没有系统看过这方面的书，所以就说说我的理解吧。个人在组织中获得报酬和利益的基本途径是促进组织的成长和完善，同时提高自身，分享自己的那份利益。这就要求你产生的结果应该对组织有积极的溢出效应，但是这个方向和标准并不是每个人都清楚或者准确把握的。表现不佳的学生常常感到沮丧，甚至抱怨自己经常加班，甚至最后一个离开部门，周末还要处理工作。不谈背景，如果你中了上面这一项，我给你一个忠告：除了工厂是计件计费的，其他地方的体力劳动和最终结果之间没有明显的直接关系。就像你上学的时候，肯定有几个别人家的孩子，不是很努力，学习很好，就是好像天天陪你玩，成绩却总是碾压你。从学校到社会，这种现象并没有消失。不要迷信加班和体力消耗。大多数人只要想都想不到，他们愿意付出的体力是远远超乎你想象的。与Leader相处、沟通，本质上是为了达成一个约定的目标和相互认可的结果。这是一个非常关键的初衷。有时我会开玩笑地和我的组员聊天，说你要好好看看我的Leader要做什么，然后你就去做，这样我就可以汇报了。方向、节奏和结果的重点对于工作和成就的发展至关重要。同时，你需要从他们那里获取更多的信息，以方便自己的判断、决策和学习，不断从他们身上汲取养分。在某些环境下，体力消耗是必要的，但唯有体力消耗最终只能打动你。你的团队不想每天陪你加班到11点或者发帖到凌晨2点，更别提凌晨1点30分就有电话商量方案了。因此，我们必须做好“期望管理”。领导对你的期望，项目的期望，还有你对他给你空间和支持的期望，大家要重点明确，目标一致。在架构层面，我觉得对架构层面有清晰的认识也很重要，包括业务架构、技术选型、具体实现。1.最重要的是定义问题。爱因斯坦说：“提出问题比解决问题更重要！”定义问题是一项脑力工作，解决问题是一项体力工作。大家习惯了看到问题就赶紧去锤。从概率上来说，他们很可能会陷入一个解决问题的黑洞，就是你一直在解决问题，但最后你的情况并没有改善。当你遇到困难或情况时，更重要的是首先定义问题，具体要解决什么问题，解决它有什么好处，以及如何确保解决它。二是定义结构，这个问题的重点，你对应的解决方案是什么，如何权衡利弊，最后的解决方案如何穿透透传，从点到面。一个团队可以不停地努力，但不一定能取得成果。他们大多习惯于把自己面临的问题罗列出来，而没有对这些问题进行全面的分析和梳理。其实，最难的是“找问题”。2.问题的本质没有那么深。有时我们在做一个项目的时候，可能会有一个产品需求。大家看了之后觉得做起来很难或者不可能，因为现在系统不支持，改造成本太高，不确定因素很多。技术风险。我相信在这种情况下，很少有人会盲目要求增加人手和处理时间来解决这个问题。在大多数情况下，我们会看看是否有捷径或其他解决方案来实现产品效果，即使技术实现是肮脏和曲折的。其实这个时候，如果再横向纵向挖掘一下，或者多问几个问题，可能会得到不一样的答案。这个需求为用户解决了什么问题？目前的解决方案在业务（产品、技术）上是否具有独特性，这个解决方案会带来哪些成本和新问题，目前正在推进的其他项目是否会对这个问题产生影响？相关的，有没有其他团队正在解决类似的问题或者之前已经解决过。3.实现目标在工作中，从谈判API合同，到发起需求，再到完成推广，都有办法成功。任何问题都可以通过找出不足、制定计划、抗拒挫折、反复训练、反馈调整来解决。《债务危机》的作者-桥水基金CEO达里奥总结了一个五步成功法，很有意思：著名数学家波利亚有一本名著《怎样解题》，给出了一个四步解题法，从研发的角度可能更明智：4.持续学习是基础。时代在不断发展变化，现在是波澜壮阔的时代。变化在短时间内跌落谷底。一个企业的发展，必然要符合一定时期环境的要求，但随着时代的变迁，如果跟不上变化，就只能被时代所抛弃。俗话说，让你成功的最终会让你失败。比如柯达和诺基亚也不能幸免，个人也逃不过这个规律。在这样的情况下，持续学习和改变自己的能力是R&D学生最大和最强的优势。日新月异的技术本身就需要你不断学习，同样的习惯辐射到各个领域，让你逐渐取长补短，优化自己。所以，如果说R&D同学最需要什么，我觉得持续学习能力是最关键的。就像饿了么创始人王源在接受采访时说的那样，让我至今难忘：最重要的是选择，最难的是坚持。
