Skip to content

四火的唠叨

一个纯正程序员的啰嗦

Menu
  • 所有文章
  • About Me
  • 关于四火
  • 旅行映像
  • 独立游戏
  • 资源链接
Menu

谈谈月饼事件

Posted on 09/15/201606/23/2019 by 四火

mind control

最近在程序员圈子内引起热烈讨论的月饼事件的详情在此,阿里巴巴也给出了官方回应,事件本身的大致内容是:

阿里巴巴有一些低于市场价的月饼供员工抢购,算是公司福利的一种体现。但是安全相关部门的 5 位员工写了脚本,利用内部抢购系统漏洞,抢到了超过限制数量的 133 盒月饼。

于是看到了各种各样的声音,有表示公司做得对;有表示公司的处理方式简直不可理喻;也有质疑公司 HR 的权力之大的。于是讨论就上升到了公司的文化,以及公司的价值观上面。

这件事情在互联网上的讨论已经非常充分了。以下是我的几个观点:

从公司层面上看,杀一儆百,给其他员工带来的是警示作用。我更相信他们只是为了践行这一点的牺牲品。有点必须绝对 “政治正确” 的意思。其中尤其要注意其中的一点,这几个人是公司安全相关部门的员工,因此他们更懂得脚本、漏洞这些事情。换言之,这有点像是 “反贪部门贪污”,或者是 “执法部门违法”。这是这个事件中,角色特殊的方面。在回应中 “作为平台规则的捍卫者,使用工具作弊触及了诚信红线” 说的也是这一点。

然而,公司能从这一举动中带来长远的好处没错,副作用也不可小觑。甚至可以说,负面的影响更甚:

死板的公司文化,恐怖的价值观洗脑氛围

我一直对那些文化过于强势的公司心有忌惮。原因很简单,且不论对错,而事实上,也很难说对错。价值观本来就是一种态度和观念,哪怕就是自己一个人,今天觉得符合这样这样的标准去做是对的,几年以后,可能又会觉得不对了。因此,如果公司强势地渲染、教育、影响一个人的价值取向,不要也不需要急着给正误判断的定论,这种洗脑本身无疑就是非常危险的。就像传销分北派和南派一样,北派传销限制人身自由,而南派传销更注重对人思想的控制,更让人觉得恐怖。

抢月饼的一个目的是开心,这每一盒区区几十块钱的东西,如果能够引起员工积极参与并且乐在其中,无疑就达到了目的。而如今,即便再有这样的活动,还有谁会咧着嘴笑着高高兴兴地抢月饼?我想会有很多人战战兢兢地回想起,自己的某一位前辈和同事,就按下了执行脚本的按键,收到了被离职的传话。月饼将变成一个阴霾的标识。

另外吐槽一下马云的风格,兴许和阿里的价值观息息相关。看过马云演讲(包括英文演讲)的朋友可能会注意到,他特别喜欢说一些口号性、煽动性的话,有时候面对一些尖锐的问题,七弯八拐打个马虎眼也就用这种赢得掌声的口号话绕过去了,因此公司的氛围文化上是不是也会表现得有些 “高调、表达过度” 而 “务虚”,我不得而知。

到底是严刑峻法还是双重标准?

因为一个公司内部的抢月饼事件,就可以把几位员工开除。如果不知道这个事件,如果不了解这个公司,那么你听到这句话的时候,心里可能会想,大概是某一个管理严苛死板的公司吧。谁能想到居然是中国互联网的三巨头之一呢?百度名声已经臭大街了,腾讯本来也屡遭批评,就剩阿里系相对还声誉不错。可是现在呢?我相信依然会有许许多多的求职者削尖脑袋往里钻,但是,阿里巴巴会损失许多优质的求职者——他们不缺一份职位,他们更追求自己想要的生活,脑海里的那个理想,以及希望找到和自己性格融洽工作环境——于是阿里巴巴会上他们的黑名单,毕竟极少有热爱互联网的 IT 人,希望去一个规则死板的地方干活。

你可能听说过 “阿里云抢票” 吧,但是你应该至少听说过 12306 的购票难吧,阿里这么做,是不是应该把自己开除呢?父母是孩子的第一个老师。父母做不好的事情,要让孩子做好,不觉得荒唐么?

ali

有无数种处理方法,比粗暴的开除通报更好

我看到很多人在讨论更好的解决方法,虽然各有利弊,但是总体来看,似乎只有粗暴的开除是最差的,甚至比 “不作为” 都要差很多。今后谁要在和我谈阿里的工程师文化,我都可以拿这个事情糊他脸。

这个抢购系统这样最基本的反复提交的安全问题,如果能够得到修复,这样的悲剧事件也不会发生了。我虽然同意这样的看法,不过一方面这是一个公司内部用的系统,而且是用来抢购月饼这样 “并不重要” 的资源,没有做到足够的安全级别也可以理解;另一方面则是,即便这次把问题避免了,下次在某个角落里类似的问题还会发生。

第二种说法是,可以用幽默的办法、用极客的办法来化解。比如这个帖子所讨论的。

如果没有办法做到巧妙的化解,那至少可以考虑别的方法,得以在机制上不同,可以达到类似的实施效果,但是不留这样明显的空子。比如可以给公司活动、产品征集点子、想创意,来得到月饼的购买权(从有人试图写脚本来抢购的情况来看,这样的方式应该不会遭到冷场吧),公开姓名和数量这些数据,公众监督。

还有的说法,则是 “低调处理”。无论是批评、警告,哪怕是劝退。虽然称不上方法多高明,但至少比这个粗暴的开除+通报强多了。

零容忍是有条件的,比如对于客户信息的泄露,比如对于面向互联网用户的抢购平台的 “知法犯法”,对于一个内部的月饼抢购系统,真犯不上。若这真要执行如此严苛的标准,开发这个平台的工程师,岂不是也得遵循前面两者的安全标准?那现在没有做到,是不是有连带责任?如果要用价值观去扯蛋,那能扯上去的东西实在太多了,能误杀的人事简直无法预计。想想那周知的黑暗的十年,我们在这方面吃的亏,还少吗?

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》

×Scan to share with WeChat

你可能也喜欢看:

  1. 程序员眼中三种类型的公司
  2. 普通程序员、文艺程序员和 2B 程序员
  3. C++程序员和 Java 程序员的差异
  4. 程序员漫画
  5. 折腾的快乐

7 thoughts on “谈谈月饼事件”

  1. chenjinxia says:
    09/21/2016 at 9:41 AM

    这个同学的通报方式不正确。
    假如他对他的 Boss 讲,老大,这个临时的抽奖页面,我写了一个脚本抢单,居然成功了,有漏洞。应该会得到表扬,和奖励

    Reply
  2. wan says:
    09/17/2016 at 6:05 PM

    个人认为处理的非常合理, 我们总是对破坏规则的人太过宽容了.

    Reply
  3. ricoo says:
    09/17/2016 at 9:12 AM

    我感觉阿里的处理方法比较像种宣传方式,事件的发生是意外,但是处理方式或许只是为了凸显公司注重安全保护

    Reply
  4. Abner says:
    09/15/2016 at 9:52 PM

    我倒认为阿里处理得当。勿以恶小而为之,勿以善小而不为。

    其它员工没有做脚本,并不是说没有能力,而是遵循了制度。虽然这样的行为称不上大善,但也是老实小善。公司无法奖励他们,那只能惩治小恶。更何况恶大恶小,也完全跟所看的角度有关。与其模棱两可的批评教育,不如开除直截了当。

    Reply
    1. Abner says:
      09/15/2016 at 10:26 PM

      看了下知乎上的那片关于 google 如何鼓励员工的,似乎和这个事件没有可比性。阿里安全部的四个员工并没有将脚本分享给其它员工,而且完全不顾其它员工的需求。而 Google 的工程师是共享脚本,让所有员工起码都在一个相同的起跑线上。

      Reply
    2. 四火 says:
      09/16/2016 at 4:58 AM

      “勿以恶小而为之,勿以善小而不为。”
      >> 其实我从头到尾都没说这不是“小恶”,这是,但是粗暴的开除通报不可取。

      “与其模棱两可的批评教育,不如开除直截了当。”
      >> 这个操作是简单,但确是最差的一种处理方法,这么做的危害我已经表述了。

      Reply
    3. Takashi says:
      11/16/2016 at 9:12 AM

      「勿以恶小而为之,勿以善小而不为」的前提是,你要定义清楚什么是「恶」,什么是「善」。对一家企业而言,也许员工这么做就是「恶」——它们没有那么多精力去调查清楚事情的原委,因此不会有多少通融;然而如果充分地了解这起事件,会发现在当事人和许多局外人的眼里,这显然不属于「恶」,因为当事人的意识里就不是故意去作恶,最终也没有造成很大的影响和经济损失。从另一个角度来说,当事人中还有去主动承认报告情况的,还可以认为是「善」, 知错能改善莫大焉。

      在本人看来,阿里这么做是想杀鸡儆猴,通过这起事件向外界传达其价值观,以期树立一个制度严明的企业形象。但其实弄巧成拙。

      Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

订阅·联系

四火,啰嗦的程序员一枚,现居西雅图

Amazon Google Groovy Hadoop Haskell Java JavaScript LeetCode Oracle Spark 互联网 亚马逊 前端 华为 历史 同步 团队 图解笔记 基础设施 工作 工作流 工具 工程师 应用系统 异步 微博 思考 技术 数据库 曼联 测试 生活 眼界 程序员 管理 系统设计 缓存 编程范型 美股 英语 西雅图 设计 问题 面向对象 面试

分类

  • Algorithm and Data Structure (30)
  • Concurrency and Asynchronization (6)
  • System Architecture and Design (43)
  • Distributed System (18)
  • Tools Frameworks and Libs (13)
  • Storage and Data Access (8)
  • Front-end Development (33)
  • Programming Languages and Paradigms (55)
  • Testing and Quality Assurance (4)
  • Network and Communication (6)
  • Authentication and Authorization (6)
  • Automation and Operation Excellence (13)
  • Machine Learning and Artificial Intelligence (6)
  • Product Design (7)
  • Hiring and Interviews (14)
  • Project and Team Management (14)
  • Engineering Culture (17)
  • Critical Thinking (25)
  • Career Growth (57)
  • Life Experience and Thoughts (45)

推荐文章

  • 聊一聊分布式系统中的时间
  • 谈谈分布式锁
  • 常见分布式系统设计图解(汇总)
  • 系统设计中的快速估算技巧
  • 从链表存在环的问题说起
  • 技术面试中,什么样的问题才是好问题?
  • 从物理时钟到逻辑时钟
  • 近期面试观摩的一些思考
  • RSA 背后的算法
  • 谈谈 Ops(汇总 + 最终篇):工具和实践
  • 不要让业务牵着鼻子走
  • 倔强的程序员
  • 谈谈微信的信息流
  • 评审的艺术——谈谈现实中的代码评审
  • Blog 安全问题小记
  • 求第 K 个数的问题
  • 一些前端框架的比较(下)——Ember.js 和 React
  • 一些前端框架的比较(上)——GWT、AngularJS 和 Backbone.js
  • 工作流系统的设计
  • Spark 的性能调优
  • “残酷” 的事实
  • 七年工作,几个故事
  • 从 Java 和 JavaScript 来学习 Haskell 和 Groovy(汇总)
  • 一道随机数题目的求解
  • 层次
  • Dynamo 的实现技术和去中心化
  • 也谈谈全栈工程师
  • 多重继承的演变
  • 编程范型:工具的选择
  • GWT 初体验
  • java.util.concurrent 并发包诸类概览
  • 从 DCL 的对象安全发布谈起
  • 不同团队的困惑
  • 不适合 Hadoop 解决的问题
  • 留心那些潜在的系统设计问题
  • 再谈大楼扔鸡蛋的问题
  • 几种华丽无比的开发方式
  • 我眼中的工程师文化
  • 观点的碰撞
  • 谈谈盗版软件问题
  • 对几个软件开发传统观点的质疑和反驳
  • MVC 框架的映射和解耦
  • 编程的未来
  • DAO 的演进
  • 致那些自嘲码农的苦逼程序员
  • Java 多线程发展简史
  • 珍爱生命,远离微博
  • 网站性能优化的三重境界
  • OSCache 框架源码解析
  • “ 你不适合做程序员”
  • 画圆画方的故事

近期评论

  • + 1.123687 BTC.GET - https://graph.org/Payout-from-Blockchaincom-06-26?hs=bc7ad362723e233c862c0befa566a75a& on 常见分布式系统设计图解(汇总)
  • rocky on 关于时间管理的一点新的感悟
  • panshenlian.com on 初涉 ML Workflow 系统:Kubeflow Pipelines、Flyte 和 Metaflow
  • panzhixiang on 关于近期求职的近况和思考
  • Anonymous on 闲聊投资:亲自体验和护城河
  • 四火 on 关于近期求职的近况和思考
  • YC on 关于近期求职的近况和思考
  • mafulong on 常见分布式基础设施系统设计图解(四):分布式工作流系统
  • 四火 on 常见分布式基础设施系统设计图解(八):分布式键值存储系统
  • Anonymous on 我裸辞了
© 2025 四火的唠叨 | Powered by Minimalist Blog WordPress Theme