在华为有这么一个传统，简称“惯例”。
12月23日，一位华为员工在华为内网发布离职帖，标题为《国际惯例：离职前发一贴！我轻轻地走，不带走一行代码...》。
从此，华为员工们之间产生了一种难以描述的默契，离职前多半会在内网发个帖，发帖多半会加上这几个字：“国际惯例”，似乎这样在华为的职业生涯才算完整，渐渐的“国际惯例”也成为了华为员工们离职的代称。
华为er们国际惯例的内容可谓丰富多彩，既有对华为职业生涯的回顾和总结，也有对未来发展道路的思考和规划，还有对公司管理问题的真诚反馈。
阿里内网“阿里味”上虽然没有这个“惯例”，但一些即将离职的员工也喜欢发布一些在阿里职业生涯的回顾和总结。
今天就将这篇在阿里员工中热传的一篇文章，分享给大家。
（注：文章转载自阿里前员工秦续业，转载请联系作者本人）
选在去年 6.18 这个好记的日子离职，快一年了。
毕业的时候加入阿里。在 你遇到过的最不被尊重的面试是怎样的 里我回答了当初我是怎么加入的。
因为彼时无线搜索事业部(实习的部门)已经独立出去和 UC(当时还没被收购)合资成立了神马，于是我加入了阿里妈妈事业部。
刚加入的时候，适逢轰轰烈烈的登月计划。远古的阿里同学应该知道，当时阿里内部有两套大数据系统，云梯1--基于 Hadoop 和云梯2--自研，也叫 ODPS(后来的MaxCompute)。当时各事业部都用着云梯1，但是上面大手一挥，所有都需要切换到 ODPS，这个任务非常庞大，阿里如此多的事业部，如此多的离线脚本，数据都要迁，难度很大，于是各个事业部都有单独的负责人牵头，成立独立的登月组织。
我一来，手上被分到几十个 Hive 脚本迁到 ODPS，我一脸不解，这玩意没有什么技术含量，味至极，但没办法，其他正式员丁也一样，大家除了遵从也做不了啥。
最后登月成功的时候，大家差不多是这画风：
一脸欣慰。然后当时核心基线，相比干云梯1，慢了有快2小时。干是大家奔向 ODPS 那边，和ODPS工程师对接，疯狂优化自己的脚本，使用了各种奇技淫巧(各种 SQL 的 hint)，终于速度差不多了。
因此 ODPS 愣是靠着从上到下的管理，将整个阿里超大的体量，都真正跑了起来。所以，后来即使我们百般看不上 ODPS，它在世界上真正处理问题的体量，确实是绝无仅有的。这个角度，国内也没有竟品能出其右。
刚加入阿里那年适逢世界杯，当时淘宝技术部的明风举办了一个世界杯相关的比赛，要求用 spark来预测比赛的胜负关系，到了半决赛开始，还要预测比分。
当时，我就拉着“百阿”的两个同学参加了。说到百阿，这是进入阿里要参加的一定程度上有洗脑的培训。然而，到了5月这个时间点，听说百阿也没有了。
因为实际上参加这个比赛，虽说是业余时间搞，但说不占用工作时间，是不可能的。毕意经常为了赶时间，我们可能要通宵。对工作的影响也是显而易见的。但当时的阿里，还是相对宽松的。我们主管也没有反对，也鼓励我作为新人，参加公司内部举办的比赛。
当时，我学生时代写过一个分布式的爬虫框架 cola，抓数据对我驾轻就熟，于是我把 whoscored上和世界杯有关的数据都抓了一遍。这个网站的数据非常全，甚至包括每场比赛每个球员的具体数据。在 spark 上，我们主要用 mllib 的算法。具体内容就不多说了。最终，我们居然一路过关斩将，在几十个队伍里，其中不乏很多阿里很有经验的算法工程师，最终拿到了第一名。
第一名有很多奖品，其中一个是 spark summit的门票。次年，我就去了旧金山参加了 spark summit，给我留下了深刻的印象，有机会可以展开说说。
我想说的是，当时的阿里，真的有着相对宽松的氛围。主管也不会那么讲究 KPI，很多完成不了的，到财年底改下就是了。
当时在阿里妈妈，我在团队主要做的事情，就是归因(attribution)，简单来说，用户可能看了很多网页，可能点了广告，可能搜索了商品，但他最终购买了，那么前序的浏览、搜索、广告，到底哪个能对他的购买产生贡献，贡献值是多少。这其中的核心点是，用户浏览的数据量是非常大的，也有非常多的来源;归因也有不同的算法。
在我去之前，每个计算都需要定制，缺少一个框架能通过简单的配置，就可以完成各种归因的计算。于是，我就自己琢磨，然后写了一套系统，用广通过配置，可以指定浏览的数据源们，效果的数据源们，可以加入自定义的数据处理，然后指定归因"的算法来进行计算，整个过程通过配置就可以完成。做这个的时候，其实也没有什么人管我，我基本都凭着自己的理解完成，做完了以后别人就可以用了。当时这个过程还是简单快乐的。我离开阿里妈妈后，同事们给我这套系统申请了一个专利，当时的阿里，虽然能听说一些高层的政治斗争，但只是听说，对下面干活的人没有影响，尽管大佬们也来来往往，做的事情一直没变。
在阿里妈妈的时候，所有工作重度依赖 ODPS，但我惊讶地发现，ODPS除了写SOL，居然只有 Java 接口。当时 pandas 已经兴起很久，pyspark 的发展也如火如荼，怎么 ODPS 还这么落后。于是我就开始着手写 ODPS 的 Python 接口，ODPS 当时也没有文档，要实现Python 接口只能读 Java 代码，然后用 Python 实现同样功能。
在出发去日金山参加 Spark summit 之前，当时 ODPS 的老板找到我，希望我能加入。他还给我布置了作业，希望我能参加 Spark summit 时候，考虑如何在 ODPS 上实现类似 pandas的系统。美国回来后，我没有犹豫，内部转岗加入了阿里云。这个选择很简单，因为阿里云更加技术，阿里妈妈很多时候还是太偏业务了。
加入 ODPS 后，内部其实有一套简陋得不行的 Python 接口，是几个 ODPS 工程师的兴趣爱好，没错，当时大家可以凭着兴趣爱好做一些和本职工作无关的事情。我把我之前在内部开源的 Python 实现合并了进去。相信在阿里待过，在 ODPS 上用过 Python，都应该知道这个项目。它就是PyODPS。
后来，我就着手实现 pandas on ODPS，具体细节就不赘述了，主要实现原理是，定义一套 DSL，它有着和 pandas 类似的接口，在执行的时候，把计算图编译到 ODPS SOL执行。这样，用户就可以用他习惯的 pandas 接口来跑在大数据系统上了。
到了的时候，我越来越发现，这种试图做中间层的方式的局限太大了，首先，pandas 上很多接口都无法在 ODPS 上实现，因为 ODPS 本质上支持的是 SOL，只支持关系代数的语法，但 pandas 上有很多操作并不能用关系代数描述。其次，还有用户问到他想使用numpy、scikit- learn，ODPS 上也无法实现。
还得自己做引擎！于是，那时候通过和各个大佬激烈的立项答辩，Mars 项目终于开始了。这个就不详细展开了，简单说，通过支持任意形状的、细粒度的 DAG 执行器，Mars 可以支持 numpy pandas、scikit-learn 等等接口。
那几年，慢慢就能感受到公司的变化。公司也没人举办比赛了，KPI 的要求越来越严格。一些销售的 KPI 也都落到开发身上，但开发并不直接接触客户，除了干着急，没有任何办法。整治斗争也越来越激烈，慢慢地，这些斗争不再局限于高层，底层干活的同学也会被波及，你不得不为老板考虑如何在身位上卡别人脖子。
想从0开始做好一个产品，数年如一日地演进：不是为了 KPL，每年拿外面的成果到内部包装，明年再换个想法继续搞好 KPI--越来越难在阿里生存。
劣币驱逐良币。
干是我离开了，创立自己的公司，有机会再聊我们的公司，但我们希望能在开源上几年如一日，做好产品，做我们真正中国人引领的世界级开源项目。
以上。
