阿里巴巴旗下的5款免费实用小工具来阿里6年，我是如何快速成长的？地摊热新思考：互联网思维还有用吗？阿里达摩院员工业余打造“论文知识图谱”：极速搜索，完全可视化我是如何在阿里做“架构师”的？
我是在 2014 年入职饿了么，从前端和 PHP 一直做到后端架构和团队，从 2014 年到 2017 年陆续负责过公司客服、销售、代理商、支付、清结算、订单这些业务的产研与团队；2018 年从业务研发团队抽身，6 个人组起一个小组投身机器学习，试图结合实际的业务场景通过技术改造业务；2019 年回归到平台（中台）研发，负责交易、金融、营销三个中台的研发和团队工作。基于我在饿了么4年和阿里巴巴 2 年研发经历，从技术、业务、管理和架构层面分享一些我的思考。
技术层面
对开发同学而言，技术是立身之本，往往面试造火箭入职拧螺丝，但不可否认的是，技术就是你从业的基石。不管是基本的动手能力还是问题分析能力，包括你的思维逻辑乃至对事物认知的能力，技术思维都会时刻影响你。明显的影响就是当你面对无数个问题的钉子时，技术是不是你顺手的那把锤子。
技术上我比较关注的几个层面：
1. 稳定性
稳定性是一个先有意识再有能力的事儿。记得在 2015 年年初，张雪峰加入饿了么担任 CTO 之后，从他嘴里常听到的一句话就是“研发要对生产环境有敬畏”。
2014年下半年，各方人马开始杀入外卖市场，饿了么启动百城计划进行业务扩张，短时间内从10+城市覆盖到100+城市，日订单量也很快从10万上涨到100万。业务井喷的技术还没有做好足够的准备。我印象中，2014年下半年几乎每天中午交易量都有新高，但也伴随着系统宕机、限流扩容、紧急调优、客服爆线、技术加班熬夜的问题。
我曾在新乡的客服中心看到有的客服同学突然崩溃，耳机直接摔下来离开工位，因为每天会接收到大量用户的来电责问，就在那一刻其实你才会清晰且直观的感受到：你在编辑器的每一行代码，你在服务器的每一次发布，会对现实世界很多活生生的人有直接的影响，你会突然意识到你的工作比你之前以为的要重要且有意义。
所谓研发要对生产环境有敬畏，就是你知道你的作品会对别人产生不好的影响，你会为不好的结果感到惭愧与内疚，这就产生了敬畏。应急处理有一个基本原则：“以业务影响小为主，优先恢复为核心目的，不要纠结手段和根因。”
别把你的懊悔、决心、对稳定性的思考、各种奇妙的idea以及执行力体现在事故复盘会上，系统的安全生产和火灾一样，事前才有意义。
2. 链路设计
大部分产研缺少全链路的视角，往往看到的是自己负责的点，对于一条线乃至整个面是看不到的，也没有机会去思考这些，而对于一些大项目和长链路系统而言，这是致命的。
我的建议是，对你所负责的系统，它关键的上下游、核心业务的链路一定要熟悉，包括数据、接口（调用、功能、逻辑）、各种异常的处理和特殊的设计。能帮你达成这一目的的简单的办法就是画图、画图、画图！重要的结论说三遍，一定要自己能把系统的大图画出来，做到可以根据大图随意放大和缩小。放大到将链路画到业务场景里，突出业务逻辑和上下游交互，缩小到某一次调用的处理逻辑大致是怎样，数据是怎么变化。
经常画图，不用纠结形式和标准，重要的是形成自己理解系统的一个框架，一个自己的思维方式，需要的时候可以随时拿出来用。
日常不管是聊需求还是做系统设计，习惯性的把图画出来，就达成了一半。剩下的一半就要看图去想、去找问题。
3. 技术债务
永远不要骗自己说，现在为了这个需求先挖一个坑，过一段时间再来填（重构 or 重做）。
技术债务和金融债务一样，它必然存在，并且会像无赖一样一直赖着，隔三差五会爆发一下。随着时间的推移和业务的发展，你会发现架构越来越混乱，不同系统的领域边界越来越模糊，系统和需求与组织关系的映射越来越复杂，服务内编码风控越来越不一致，重复的轮子一个接一个隐蔽的出现。
“太忙了没时间梳理哪些问题”、“改那些问题需要上下游一起改，费时费力，推不动”、“现在还没出问题，正在整理了，别催”。这是我们经常会听到的声音。其实，技术同学多少都有点代码洁癖，有很多问题不处理不是主观的原因，而是客观上因为精力、时间、ROI等因素，往往要等问题真的爆发后，大家才能狠下心去处理那些问题。?