SDE，通常指的是Software Development Engineer软件开发工程师，但在亚马逊，SDE还有另一层含义——Someone Does Everything。这是因为SDE在亚马逊，确实是啥活儿都要干。
SDE=Someone Does Everything
SDE，通常指的是Software Development Engineer即软件开发工程师。但在亚马逊，SDE还有另一层含义——Someone Does Everything。这是因为亚马逊追求员工效能最大化，不同的角色被尽可能压缩，尤其是对SDE，要求就是“尽量独立、尽量全能”。所以亚马逊的SDE需要负责从研发到上线的所有工作，甚至在上线以后团队还要负责运维7*24 On Call。
亚马逊技术竞争力的关键——啥活儿都干的SDE https://www.sohu.com/a/207306692_100058260
SDE，通常指的是Software Development Engineer软件开发工程师，但在亚马逊，SDE还有另一层含义——Someone Does Everything。这是因为SDE在亚马逊，确实是啥活儿都要干。
SDE=Someone Does Everything
SDE，通常指的是Software Development Engineer即软件开发工程师。但在亚马逊，SDE还有另一层含义——Someone Does Everything。这是因为亚马逊追求员工效能最大化，不同的角色被尽可能压缩，尤其是对SDE，要求就是“尽量独立、尽量全能”。所以亚马逊的SDE需要负责从研发到上线的所有工作，甚至在上线以后团队还要负责运维7*24 On Call。
在传统的软件研发企业中，通常研发（SDE）、测试（QA）和运维（OP）是三组人马。在这种情况下，研发和测试间沟通的不及时、信息的不对称会导致研发效率较低；运维过程中出现的不那么紧急的问题也要经过一定时间才会汇总到研发人员处进行修复。亚马逊的SDE不仅仅做研发还承担测试工作，可以极大提高研发效率。在后期运维的过程中，SDE直接面对客户，可以更及时且全面地了解到客户反馈信息，分析系统质量，选择是对系统整体更新替换还是部分调整，以便更好地满足客户需求。也正是研发人员负责运维这一特性，使得亚马逊可以转变为面向服务的SOA架构。
由于亚马逊的很多研发技术是面向业务的企业应用系统，而不是要做出产品，所以在亚马逊，产品经理的角色通常也不需要。通常研发团队会直接和业务团队对接，了解业务需求，会由业务人员或资深SDE承担类似产品经理或项目经理的工作，把控研发方向。当然，SDE的工作重点还是在研发上，必要时，团队中也会配备测试、运维人员及产品经理。
最令SDE头疼的活儿——“万恶”的On Call
亚马逊的SDE啥都要干，但要问他们最不想干的是什么，估计十之八九会回答——On Call！On Call制度是指在超过90%的团队中，都有SDE轮流On call ，只要BP机一响，无论处于何时何地都要爬起来工作，解决问题。超过半个小时没有回应，问题就会往上一层继续传递，从SDE，到经理、高级经理、总监，一直往上直到传递至杰夫·贝佐斯。SDE在On Call时，做好了没人看得见，一旦出现问题，可能就会吃不了兜着走。
On Call时遇见的各种问题按照严重性，会分为5个等级：
Sev1：公司级的重大问题，十万火急，例如整个网站瘫痪等。
Sev2：部门单元出现的严重问题，影响客户正常使用，需要立刻解决。出现了Sev2就意味着SDE们的BP机要响了。
Sev3：通常当SDE即刻解决的不是十分重要的问题，比如一些客户反馈给客服，客服处理不了转给SDE的问题。
Sev4：微小问题，可忽略。
Sev5：微小问题，可忽略。
在之前的文章中，我们提到过亚马逊的研发团队人数通常保持在2个披萨能喂饱的状态，内部称为pizza team。不同的pizza team的On Call轮班时间、周期和强度完全不同。有的pizza team所负责的业务在全球不同时区都有研发中心，可以和中国、印度等研发团队轮流处理On Call，运维时间只是58。但大多数核心业务，团队集中在亚马逊美国总部，团队On Call时间是724。类似AWS等核心领域的pizza team，平均每周要处理70~80次sev2，轮班的SDE工作强度极大。
其实On Call制度并不是亚马逊的首创，但通常其他公司是由专门的运维团队负责。比如Google就有专门的SRE团队负责On Call，而且Google的SRE因为On Call，所以工资高而且在轮到On Call时算加班，有加班费，所以相对稳定。有些会好奇亚马逊的SDE们钱少事多，为什么还会留在公司，难道他们是一群受虐狂？
SDE金字塔序列
当然不是，实际上，基层SDE的流动率非常高。亚马逊整个公司的员工平均在职时间仅为1年，SDE人员也差不多。在技术人员流动率如此高的情况下，亚马逊如何保持技术和业务的稳定性？这要先从亚马逊的人才序列说起。
在亚马逊，人员职级如下图所示，一共分为10级。
亚马逊的职级相当扁平化，从物流中心的体力劳动者算起，到杰夫·贝佐斯，一共只有10级。比较有趣的是没有L9，具体原因并不明确，可能是只一种象征性的做法，故意删去一级，从而减少企业中的官僚主义。
而SDE的职级从L4起，最高可升至L5，享受VP同等待遇。在亚马逊内部，对于SDE1到Distinguished Engineer各级别的能力素质标准以及晋升要求有明确的规定，为研发人员提供了明确的指引发展通道。通常，应届毕业生进入亚马逊都是SDE1的职位，表现良好即可晋升为SDE2，SDE2就有机会主导一个小西天的架构设计。但是SDE3的门槛很高，不仅需要足够高的技术水平，还要有大型核心项目支出，绝大部分研发人员都晋升不上去。几万员工人里只有不到800名SDE3, 不到70名 Principle SDE。到最高级别的Distinguished Engineer，全公司只有10人，包括“java之父”James Gosling、PHP之父 Andi Gutmans和XML之父 Tim Bray等人，说他们能影响世界毫不夸张。
SDE3以上的研发人员在行政上仍属于某一研发团队或部门，但是在某种程度上，他们属于公司的共享资源，工作不局限于自己的业务本身，还需要带领团队攻克关键项目，并承担团队及部门以外的一些工作。而Principle SDE需要把控公司总体技术架构，并对新技术、新理念做出更多探索。在亚马逊，虽然基层SDE们工作强度大，饱受On Call制度的困扰，流动率高，但SDE3以上的技术人员大部分都相当稳定。有种说法是，Principe SDE级别的技术大牛们把系统整体架构搭建得极其稳定完善，基层SDE只要不恶意乱写代码，系统都不可能崩溃。
综合来看，亚马逊的SDE虽然日子过得苦哈哈，啥活儿都得干，但付出就有回报，他们创造了极高的价值：首创站内搜索功能、物联网技术全球领先、开发出AWS云计算技术……亚马逊能从一个单纯的卖书网站发展成如今的商业帝国，在后台技术上能和Google平起平坐，全依靠他们。