用阿里云国内机房的主机有个『小问题』，备案。下面说的，一种情况是没有备案，另外一种情况是备案中，但是业务急于对外发布，等不及以周为单位的备案进程。 访问绑定到阿里云 ECS 上的、没有备案的域名，阿里云机房会劫持你的 http（80 端口）上行流量，无视你实际的返回内容，将之篡改成一个页面 title 为『TestPage』的温馨提示（如下图）。 而一台不能提供 http 服务的阿里云 ECS 不是真正的服务器。解决这个问题的办法，将 http 换到 https 就可以了。 https 选哪家 总所周知，自从 WoSign 被我大天朝数字公司收购之后，颇多周折，跟同袍兄弟 StarSSL 一起被业界良心 chrome 拉黑。现在使用 WoSign 签发的 ssl 证书会被 chrome 直接判定为证书无效。 最近连商务范儿最重的 Symantec 都被 chrome 一再警告之后拉黑。除了认为 chrome 真任性之外，也提醒我们选择 ssl 服务商时一定要慎重。 目前来看，从个人到中小企业，最佳选择是 google 投资的 Let’s Encrypt。运用 ACME 协议自动签发、自动续期，技术宅最爱，不是技术宅也有现成工具简单操作即可。 怎么生成 http ssl 证书 首先注明，申请 Let’s Encrypt 家的 http ssl 证书，不需要提前准备啥资料，不需要书面申请，这跟国内的『管理』方法不一样。你只需要证明这个域名归你所有，http ssl 的证书就可以签发给你使用。但是为了防止域名到期易主、中途转让等等原因，发生域名新主人拿不到 http ssl 证书的情况，所以 Let’s Encrypt 规定了每次签发的 http ssl 证书有效期只有三个月，证书生成一个月之后可以免费重签/续期，不用等到临近有效期再续签。……

app 服务器端的开发中，有一个百年不变的小东西：api 访问的验真问题。因为 http 协议是无状态的，每次 app 发起请求，我都需要验证这次请求的确是由真实的、授权的 app 发起，以此来阻止不诚实用户发起的攻击、数据爬取，确保产品的安全，和用户在产品上的信息安全。 JWT（JSON Web Token）是一个 http 之上的不错的 api 验真协议，结合 https，几乎可以安全地传输各种数据。最关键是，它原理简单，没用到啥黑科技，新瓶装老酒，但实用。 openresty 是春哥做的一款神器，在 nginx 上挂了个 lua 引擎，可以用 lua 脚本指挥 nginx 做很多事情。了解 lua 的童靴都知道，lua 的执行性能堪比 C++/Java 这些编译型语言，大家在一个量级。能做到这步，已经相当感人。用 openresty 来实现 jwt 协议，做 api 访问的验真，可以降低后台系统的复杂程度，同时还能提高系统鲁棒性，防止被恶意攻击时系统雪崩。 现在已经有 openresty 的 jwt 模块，叫 lua-resty-jwt 的，还有基于它做了二次封装的 openresty-nginx-jwt。 有了这个 jwt 的 openresty 模块，可以在 http server 这一层对 api 访问做验真，业务系统接收到的请求理论上都是真实的，避免调用庞大的业务系统做验真。这在收到 api 攻击的时候效果最明显，那时每次调用庞大的业务系统，加载若干组件，仅仅做了一次验真，然后就释放资源，销毁请求。简直是罪过。 话分两头说，直接上这个 jwt 模块存在一些风险。要在生产环境使用 jwt，还有一些工作必须做。 secret 的策略。jwt 协议中，并没有规定 secret 怎么来的，实际操作中，不同的 secret 策略会有不同的效果。 整个系统使用一个固定的 secret。不诚实用户可以注册账户，暴力穷举或内存搜索，得到 secret 明文。存在系统性风险。风险高。 一台服务器使用一个 secret，secret 写到 openresty 的配置中。仍然有上述问题，还增加了做负载均衡的难度。风险高。 一个用户一个 secret，openresty 根据用户信息取 secret 编解码。风险低，复杂度高。 api 访问日志需要保存。特别对验真失败的访问，要能有手段及时处理日志，分析风险，对恶意用户可以屏蔽 IP 等手段规避。 经过验真的 api 访问日志结合静态资源访问日志，可以模拟真实用户的访问场景。结合 lazy load 等前端技术，甚至可以判断出用户究竟看了几页，资源加载速度快还是慢。这么好的资源，不能浪费。 接上面。第一点好解决，一个 subrequest，或者单独给 lua-resty-jwt 一个 redis 存用户的 secret，就行了。第二点和第三点说的其实是一件事情，记日志，而且是把验真失败和验真成功的日志分开记。验真失败的日志需要参与在线准实时的计算，验真成功的日志打包保存，用来做离线的大数据分析，统计用户访问指标，优化产品。……

这两天有种忙得不亦乐乎的感觉，倦怠了写博客。 用户就是个数字 要说的是关于鹅厂邮箱的事儿。标题是很多大公司做产品的哲学，当然也包括鹅厂自己家的。 我是鹅厂毕业，也算是鹅厂粉丝，但凡能鹅厂产品能满足要求的地方，就不会用别家的产品。企业邮箱就是一个例子。 我的个人常用邮箱以自己的域名作为后缀，最初放在腾讯邮箱的『企业邮箱免费版』上，用了有两年左右的时间，一直很正常。一直到这周朋友给我发送邮件，被退回来，提示邮箱不存在一类的错误。我才注意到，原来我的免费版的企业邮箱被腾讯单方面终止了服务，正在使用中的邮箱无法收发邮件，甚至无法登陆，从管理后台登陆上去才了解到是域名无故被解绑。而在这之前，无论是我绑定了该企业邮箱的微信，还是企业邮箱本身，被抑或企业邮箱的管理账号，都没有收到任何相关的提示信息。 我首先排除管理账号被盗、黑客为之的可能性。很简单，腾讯企业邮箱的那个管理账号我很长很长时间没有使用过，账号名是一个我从来没有在别的地方使用过的字符串，不存在被社工被钓鱼的可能性。而且管理后台中，我的企业邮箱绑定过三个域名，除开今年有一个因为域名到期没续费自动失效当即被清理，一个我一直在使用中的域名无故清除，只剩下一个绑定后几乎没有使用过的域名。如果是黑客捣鬼，为什么单独给我留一个没使用过的域名？这讲不通。 后来有朋友在朋友圈中留言，了解到原来有朋友也遇到过，也是腾讯企业邮箱免费版，绑定的域名下有一个用来做客服的邮箱，经常在登录使用，也是毫无预警的情况下被清理，并且也是从后台直接解除了整个域名的绑定。 不同的是，朋友用的邮箱在两个月前失效，我的邮箱是在一个月前失效。分批分次在清理免费邮箱——而且是不给你任何预警、提示、通告、宽限期、选择项…… 直接让你的邮箱和邮件消失掉的清理。 到现在，这事儿几乎很明显是腾讯邮箱人为在清理的动作。因为太没底线了。按照腾讯一贯的价值观，这绝对不是一个『正直』的事情，这样的服务态度也不完全不符合『水和电』的特征，更加不『值得尊敬』。 在大厂做过 2C 产品的同学都知道，用户不过是一个庞大的数字，和员工自身利益休息相关的 KPI 也是通过评价这些数字，来调节对员工的奖惩。对于每一个单一的用户，大厂的产品真的是多你一个不多少你一个不少。 今天正好看到广研大 boss 张小龙在微信事业群管理大会上的一个演讲，明确要求内部不要盲从流程和 KPI，要坚持用户价值导向。真的说得很好。他还特别举了 QQ 邮箱的例子，这是个大家都比较熟悉的例子。当年 QQ 邮箱从上不了邮箱服务 Top10 排名到后来逆袭压倒 Hotmail 和网易邮箱，方法是小团对敏捷开发，背后的思想仍然是坚持用户价值导向。如果企业邮箱的团队能够坚持用户价值导向，是一定不会做这么出格的事情。 希望老东家能越来越好。千万守住自己的底线。 139 邮箱之乱象 又是邮箱的故事。 我的 139 邮箱在 2014 年设置过一个别名，这样可以用英文名而不是手机号作为邮箱前缀，识别度更高。我拿 139 邮箱主要是在国企那段时间用来收发工作上的邮件。 然而自开通邮箱别名开始，就经常收到一些莫名其妙的邮件，邮件经常开头有名有姓，称谓是我没听过的名字。刚开始以为是骚扰邮件，没有管，后面类似的邮件来得越来越多，我也听之任之，反正这个邮箱后来几乎就没有怎么用过了。 这周忽然收到一封邮件，是微博发送的，提醒我登录别名邮箱对应的微博账号。很奇怪，我不可能用 139 邮箱注册微博账号。担心邮箱帐密被盗用作什么不好的事情，于是通过微博的找回密码服务找回了账号对应的密码（后来知道，微博账号如果没有绑定手机，那么别人拿到你的邮箱，随便使用一个手机也能找回密码），发现是一个运营了三四年的企业微博，企业地址在上海。到此我才恍然大悟。 在我设置 139 邮箱别名的时候，我设置的这个别名其实是有人在使用的。不知为何，139 邮箱仍然把这个别名分配给我。所以我经常收到本该属于另一个用户的邮件，而且猜想那个用户同时也能收到本该属于我的邮件吧。一个别名邮箱，我们俩都有在使用，不论谁发送邮件，我们俩都能收到。 最后我给我们俩『共用』的别名邮箱发了消息，告诉他这个情况，并承诺把微博密码还给他。希望他能看到。 邮箱作为互联网基础服务，服务的稳定性应该要有最基本的保障，安全和隐私也应该要能做到最基础的保障。这跟邮局里面申请一个邮箱一样的。可是一周内竟然遇到两次大乌龙，我也是醉了。 所幸我还有一个 gmail 注册的企业邮箱。从今天起，免不了后续会逐步把常用邮箱换成那个。 在天朝，用个邮箱都能吓死宝宝。 关于运维的笑话 有个运维跟中学同学聚餐，接了个电话，大家都吓尿了。。。。 『喂，是我。』 『怎么回事？……卡在哪儿了？』 『不行就杀了吧，做事别磨磨唧唧的。先保证业务正常。』 『啥？找不到？杀不了？你不知道 killall 啊！把这个名字的全干了。』 『嗯。』 『诶？怎么还报警了！』 『你让胡总赶紧把警报先关了。你就在现场，报警有个屁用。』 『你跟他好好说一下，就说是我说的。这破事儿二十分钟内就能搞定，不要动不动就报警。』 『嗯。』 『对，挂了也要拉起来，就没什么不行的！他敢挂掉你就再拉一个。』 『擦！早不挂晚不挂，这会儿挂，真特么不是时候！』 『行了，我马上过来。都特么不给老子清净！擦！』 ………… (o_o) 『我不吃了，要去加个班。喂，你们都看着我干嘛…… 』……

今天无意中打开 Maxthon，看到了推荐的一则旧闻——『东航两飞机险相撞』。我记得事件当天就有看到这则报道，当时的第一反应是：类似荷兰皇家航空发生的空难（特内里费空难）在虹桥机场被避免了。今天看到的更多是后续报道，新闻报道的焦点几乎都在 V5 的机长和疏忽的管制员身上。 俗话说，对航空航天没点儿兴趣的码农不是好的 CTO。凭借我多年积累的航空知识，和对航空事业发展的关注——其实就是对各城市机场航班老是延误的那点儿感性认知——跑道入侵征候（被规避了，不算空难）在今天不能算是罕见。不过这次这个事件号称是相差三秒相撞，事后也被定型为 A 类跑道入侵事件，说明事件本身还是非常严重的。 下面摘自澎湃新闻的后续报道。 通报称，这是一起塔台管制员遗忘飞机动态，违反工作标准而造成的人为原因严重事故征候。性质极为严重，属于A类跑道入侵，险些发生飞机相撞。当时两架飞机垂直距离仅19米，翼尖距13米，两机仅差约三秒就会发生碰撞。320机组果断处理，操纵正确，避免了一起事故。330机组接受了穿越跑道的错误指令后，虽然看到了飞机起飞，但并未提出质疑。 通报认为，管制员违反相关规定，盲目指挥，双岗制责任落实不到位；专业人员资质是重中之重，自制能力要跟上；管理手段和工作流程存在问题，要系统思考原因，加以改进。 通报还提到，330机组存在SOP的问题，观察不周，不按规定，关闭了应答机。带飞左副驾驶不知道东航穿越跑道程序。没有交叉检查，没有互相证实。但是机组没有机械听从塔台原地等待命令，加速穿越，避免了两机相撞，暴露了训练上的问题。320机组处理非常到位，临危决断，立了大功。副驾驶操纵迟疑，点了一下刹车，机长迅速接过操纵，以7.03度/秒的速率，带杆到机械止动位。 首先明确了这是一起人为因素造成的事故，而且是塔台管制员疏忽占主因、A330 机组占次因的事故。事后调查表明，A330 机组存在 SOP 问题，以及观察不周、关闭应答机等问题。 其次，报道中提到了 A320 机组在事件中临机处置立了大功。7.03度/秒的速率，带杆到机械止动位，才避免了两机相撞的事故。当然，这其中还有一个明显的对比：『副驾驶操作迟疑，点了一下刹车』，后来『机长迅速接过操纵』，才避免了机毁人亡的悲剧。 这其中有多个航空相关的知识，自己也是边看新闻边搜索，记下来，也给其他有兴趣的朋友科普一下。 基础概念 跑道入侵 具体的知识见维基百科跑道入侵条目。 按照定义，很显然，本次事件中，A330 错误地出现在飞机起飞和降落的保护区域表面，是一起跑道入侵事件无疑。 据悉，通报指出，此次事件性质极为严重，属于A类跑道入侵。 据业内人士介绍，“A类跑道入侵”非常罕见。目前，民航界把跑道入侵分为以下五个级： A类，间隔减小以至于双方必须采取极度措施，勉强避免碰撞发生的跑道入侵； B类，间隔缩小至存在显著的碰撞可能，只有在关键时刻采取纠正或避让措施才能避免碰撞发生的跑道入侵； C类，有充足的时间和（或）距离采取措施避免碰撞发生的跑道入侵； D类，符合跑道入侵的定义但不会立即产生安全后果的跑道入侵； E类，信息不足无法做出结论，或证据矛盾无法进行评估的情况。 按照《民用航空器事故征候》标准，A类属于航空器严重事故征候，B类属于一般事故征候。据悉，根据新下发的文件，“A类跑道入侵”是指必须立即采取极端措施才能避免相撞的跑道入侵。 ——摘自传送门 新民晚报 客机离地起飞的介绍 这里有一篇通俗易懂的科普文《客机驾驶探秘Airline Pilot 3.3 起飞离地》。 为简化阅读和防链接失效，同时把重点摘录整理如下。 PFD PFD，直译过来就是『主飞行显示屏』，主要用来显示飞机的飞行状况，以及计算机给出的一部分飞行建议。 上图是波音 737 的 PFD。其中，紫色的倒 V 字型标识是 FD 指令条（Flight Director Command Bar），下面白色的倒 V 字型标识代表自己的飞机。按照例子中的状态解读：飞机需要执行拉起 +8 度抬头的操作。 上图是空中客车的 PFD。Flight Path Director (FPD) 线是计算机所给出的指令，Flight Path Vector (FPV) 表明飞机处于的方位，飞行员要控制飞机使 FPV 处于 FPD 的中心。此例中飞机左转时机头向下，应保持左转并拉起 +4 度抬头。……

更新（2017-06-01）：repo 的 url 有变化，更新之。后附更新脚本。 DNF 起源于 YUM 的一个分支，最早用在 Fedora 18，在 Fedora 22 中默认安装，成为系统工具。现在更是被广泛看作 YUM 的接班人。虽然 DNF 号称自己不错，但是幸好，至少从目前来看，都可以看做是对 YUM 的小修补。整体来说，DNF 对 YUM 的兼容做得很好，甚至于部分操作可以 yum 和 dnf 混合着来——当然，新旧掺杂绝对不是好习惯，我就这么一说，证明 YUM 和 DNF 的关联之亲近。用惯了 YUM 的朋友们一定不会抗拒换到 DNF，它们的用法非常相似，而且 DNF 的更有现代语言风格。 我常用的系统是 CentOS，虽然已经被 RedHat 收购，但是 CentOS 的品质和定位都没有变，这很难得。最新（截至 2016-10-16）的 CentOS 是 7.2.1511。下面的步骤在 CentOS 上尝试，对 Fedora/RHEL 理论上同样适用。Fedora 上应该还更加简单，下面的问题好多都不会遇到。 闲话不说，安装步骤如下。 一、手动安装全新的 yum repo 新增一个 repo，从这个 repo 中用 yum 安装 DNF。这是因为 CentOS Base repo 中的 DNF 版本太低，只有 0.……

今年六月，Apple 宣布要把 MacBook 的 OS 名称从 OSX 改名为 MacOS。为了体验第一代的 MacOS Sierra，我也是第一时间选择了系统升级。2012 mid 的 MBP，升级到 MacOS，感觉我也有点拼了。 升级完之后总体感觉还好，几乎都在预期内。却是在升级完成后大约第三天遇到 Chrome 报错，而且是反复的、随机的报错：『ERR_NETWORK_CHANGED』和『ERR_CERT_DATABASE_CHANGED』，就这两个。第一个出现的时候，页面 load 失败；第二个错误出现一般都是 js 或者 css 等页面资源 load 不下来（但是在新窗口打开这些资源又都没有问题）。 找了一圈，国外的网友们普遍表示情绪很稳定，没有遇到过。难道只是我大兲朝人民会遇到？ 一开始考虑过是最近倡导的 HTTP => HTTPS 运动，有部分网站匆忙升级，可能在主站和资源站（相当一部分网站会把静态资源放到 CDN 上）之间的 key chains 路径有冲突所致。CERT_DATABASE_CHANGED 应该也是差不多的意思——原谅我懒癌发作，没去挖 chromium 代码。 不过网站的配置有错，我也没辙。问题却总是要解决的，哪怕用什么讨巧的办法。于是，今天找到了 V2EX 上面的这个 issue《MacOS Sierra 升级 CHROME 用 HTTPS 访问间歇性失败》。原来已经有朋友发现了罪魁祸首，就是 Alipay 的安全控件。从评论区盆友们的反馈看，问题是已经解决了。 评论区给出手动解决的办法。 # 第一种办法：停用支付宝的安全控件 sudo launchctl remove com.alipay.DispatcherService # 第二种办法：彻底删除（手动卸载）支付宝安全控件 sudo rm -rf /Library/Application\ Support/Alipay && \ sudo rm -rf /Library/LaunchDaemons/com.……

这篇文章阐述的是对我整个职场影响较深的思想之一。当年上大学，从《读者》上第一次读到这篇文章，觉得貌似很有道理，记住了。进入职场后，发现这简直就是某些看似不可思议、却又一遍一遍发生的事实的背后真理。后来知道它还有『鲶鱼效应』、『逃离舒适区』、『可以共苦不能同甘』等等不同的称谓。 转载自《南方周末》电子版。如有侵权请告知，会删除。 我曾经在随笔中谈到过有关的士司机的经历。与其他城市相比，这种经历以发生在纽约的最为有趣，原因有三。 第一，纽约的司机来自世界各地，语言、肤色都各不相同；每个人都配有一张小牌子，上头写着自己的名字。因此，每次上车后，辨认他们究竟是土耳其人、马来西亚人、希腊人、犹太人还是俄罗斯人，就成了一件很有意思的事情。他们中的很多人总是通过“他们”自己的电台来相互联系，电台里说着他们的语言，播放他们的歌曲，因此，有时打的去中央公园就好像是打的在加德满都旅行。 第二，在纽约没有人把的士司机作为终身的职业，而只是把它当作一份临时工作；因此，坐在的士方向盘前方的有可能是一名学生、一位失业的银行员工或是一个刚来不久的移民。 第三，纽约的士司机总是成群结队地出现：在某个时期内，大部分司机都是希腊人，过一段时间后又变成了巴基斯坦人，之后又是波多黎各人，诸如此类。通过这一点我们可以观察到移民的浪潮以及各个种族的胜利：当某一群的士司机从这个行业消失时，就意味着他们碰到了好运气，声势壮大了，说明他们可能转移到烟草店、蔬菜店里工作，转移到城市的另一个区域生活，登上了一个新的社会台阶。 因此，除了能够观察的士司机个体的心理差异（有癔病患者，有厚道热情者，有投身政治者，有反对某主义者）之外，出租车更是一个观察社会现象的绝好场所。 上个星期，我碰到了这样一个司机：他是有色人种，名字很难拼，后来他告诉我他是巴基斯坦人。聊到这儿的时候，他问我是哪国人（纽约的外来人口相当多），我说我是意大利人，于是他就开始问我问题。看上去他似乎对意大利相当感兴趣，后来我才明白，他之所以有这么多问题，是因为他对意大利一无所知，既不知道意大利在哪儿，也不知道那里说什么语言（通常，当你告诉一个的士司机说在意大利人们讲意大利语时，他们都会感到很震惊，因为他们已经习惯性地认为全世界都在讲英语了）。 我快速向他描绘了一下，说意大利是一个半岛，中部是绵延的山脉，而周围则被一圈海岸线包围，那里有许多美丽的城市。当聊到意大利的人口时，他惊讶于意大利的人口居然那么少。随后他又问我意大利人是否都是白种人，还是多种族混杂，我向他大致解释说：起初，所有的意大利人都是白种人，但现在也有一些黑人，不过数量总比美国要少。他当然也想了解意大利有多少巴基斯坦人。我回答说，可能有一些，但比菲律宾人和非洲人要少。听了我的回答，他显得不太高兴，或许在想为什么他的民族不愿意去意大利这个国家。 我又傻乎乎地告诉他说意大利也有一些印度人，他立刻怒视着我：我不该把两个如此不同的民族相提并论，不该提起这个在他心目中如此低等的民族。 最后，他问起谁是我们的敌人。我问：“什么？”于是他耐心地向我解释说他想知道意大利人目前正和哪个民族进行战争，不管是为了领土争端、种族仇恨，还是边界侵略等其他原因。我说我们没和任何民族打仗。他继续耐心地问我谁是我们历史上的敌人，也就是那些和意大利人相互残杀的民族。我再次重申我们没有这样的敌人。最近的一场战争发生在五十多年前，即使是在那场战争里，我们也没有搞清楚过究竟谁是我们的敌人，谁又是我们的盟友。他对我的回答很不满意，并坦白地告诉我说他认为我在撒谎。一个民族怎么可能没有敌人呢？ 那件事就到此结束了，我为本民族这种麻木的和平主义而多给了他２美金的小费。但我一下车就忽然想起了本应该在刚才告诉他，却一时没有想起的正确答案。这种现象被法国人称为“ｅｓｐｉｒｉｔ ｄ＇ｅｓｃａｌｉｅｒ（马后炮）”。 我应该告诉那个司机意大利人是有敌人的。但那种敌人却不是外来的敌人，他们也根本无法确定谁是自己的敌人，因为他们总是在内部持续地争斗。意大利人之间总是在斗争：城市跟城市斗，邪教与正教斗，阶级跟阶级斗，政党与政党斗，同一政党中的成员相互斗，大区跟大区争，政府跟司法部门争，司法部门又与经济部门争，国家电视台与私人电视台争，联合政府之间的成员互相争，部门与部门争，报纸与报纸争。 我不知道那个司机是否能听懂我这样的回答，但如果我刚才这样回答他，作为一个没有敌人的国家的公民，至少不会丢脸。……

最近被徐新女士的《用人问题上，“野狗”和“小白兔”都要干掉》一文刷爆了朋友圈，有些很少转载鸡汤文的朋友也转发了这篇文章，且转载的朋友中几乎都是自己创业或做管理的朋友，看来此鸡汤很对大多数创业者、管理者的胃口。 虽然大家普遍觉得这碗鸡汤营养很好，我还是觉得它鸡精放太多——鲜而犯腻，而在这个食材也就是观点上有偏颇。从篇幅上看，徐新女士演讲稿关于人才怎么用的篇幅并不大，演讲稿的书面内容与标题表达出来的笃定语气不太相符，猜想这个标题是标题党后来扣上去的。不过影响这么大的文章，我还是想忍不住说两句。 首先要说的是分类的问题：什么是小白兔员工？什么是野狗员工？ 按照前导文给出的答案，野狗员工业绩好，但价值观不好（人品不好，吃回扣等），小白兔员工则兢兢业业，勤勤恳恳什么都好，价值观和勤奋都没有关系，就是人没有什么贡献。相对应的，价值观好、业绩好的是明星员工。 从定义中可以看出来，徐女士从价值观和业绩两个方面来评判一位员工属于哪一类型。虽然我并不觉得把所谓『价值观』列在对员工的评判维度——注意此处不是评价维度，评判带有判决或者盖棺定论的意味，因为这次评判是徐新女士建议对部分员工做处理的依据——里面是公平的，不过这个地方我就先不展开，姑且按照文中这个思路来。 补充一下，我也并不认为那些会把『猴子』抛给领导的员工属于小白兔员工，他们是小孩子和心机婊。我也不认为那些完全不能跟公司提供的平台和平共处、准备捞一票闪人的员工会是野狗，他们业绩再好也只是祸害。 其次，我们做企业的目标到底是做事情还是甄选明星员工？ 这个问题我想除了 HR 之外，大家应该都选择前者吧。如果两者有冲突，一定是先事情做好，活下来，再考虑打造明星团队。活下来，活得更好，才是我们创业的目的。专职打造明星团队是 MBA 做的事情。 那么我反问两句。第一，那么能够创造业绩的野狗员工为什么不能留？因为野狗员工会带坏企业氛围？那你一个管理者创始人干嘛去了？你招聘的 HR 干嘛去了？这个问题瞄准一个目标，你的企业到底是谁在影响团队。在回答之前，先好好想一想这个问题，出了野狗，到底是野狗的错，还是你的管理策略有失误。第二，兢兢业业做好本职工作的小白兔员工为什么没有业绩？难道兢兢业业不对吗？到底出了什么问题？这个问题瞄准的是，到底谁该对公司的战略和战术负责，是老板还是中层管理还是员工。同样，想一想再回答这个问题。 讲第三个问题之前，先要搞清楚职场岗位职责分工是怎么回事？以及为什么要有岗位职责的分工？全体员工动员起来，参与管理的『阿米巴模式』到底好不好？ 包括我身边一些朋友，哪怕他们自己身居企业高管的位置，仍然没有把『岗位』和『岗位职责』区分开来。比较有代表性的观念包括：『我们一个创业小公司，搞那么多岗位干什么？谁意识到问题、谁有能力，谁补位就好了』，以及『「排除万难做好工作」、「创造条件也要上」是一线员工应该考虑的事情』。我认为一个团队之所以为团队，不是一个团伙，很重要一点是团队更有『规矩』：分工明确，配合可靠。理想情况下，应该能够放心地把后背交给你的队友。在一个完整的团队中，一定要有清晰的分工界面，明晰每个岗位对应的职责。哪怕团队成员不多，我们可以一人多岗，也一定不能模糊岗位职责。唯有此，每个人才能清楚自己的前后左右都由谁负责，才知道一旦出了问题自己应该找谁沟通，才能放心而专注地完成自己份内的工作。也唯有此，团队整体效率才有可能等于或大于个人效率之和，发挥出协同效应。 有句话忘了谁说过，『没有做过好员工的老板都不是好老板』。这个『好老板』我理解不是指员工说老板好，而是这个老板能带领团队产出高业绩，带大家一起吃肉，这样的老板才配叫好老板。而一个做好过基层工作的老板，一定会给员工创造一个更专注本职工作的环境。在他的团队里，员工消耗在非工作沟通、管理甚至自我管理上的精力要尽可能地少，他的员工可以心无旁骛在本职工作上专注，全情投入，团队整体的价值是大于单个员工价值相加之和的。这样的团队，才是一个员工和领导各司其职的团队，才是一个上下层配合默契的团队，才能称得上是一个高效的团队。 其实不论什么样的团队，它比个人单打独斗更高级的地方都在于：团队合作的效率高于个人价值。一个团队，如果不关注产出成果的效率，而注重它究竟要是一个怎样的存在，这叫『买椟还珠』。所以，无论是小白兔还是野狗，只要做到让他在团队中充分发挥价值，让他对团队利大于弊，完全可以留，这不是什么一定会有冲突的事情。反之，用不好这类人，觉得不能用，辞掉就好。完全没必要上纲上线到把员工做一个分门别类来设置教科书。 至于最近看到有些公司又开始追捧阿米巴模式，号称自己的团队平等、自经营和自管理等等，我想问的是：你的员工真的可以全情投入到你们的事业中去吗？你为创造这种全情投入的环境，做了些什么？假如他能全情投入工作，他的职业规划在你的设计中吗？社会的发展和同行的诱惑就在那里，总不能简单归结为个人差异，然后回避吧。 最后，小白兔和野狗就一无是处了吗？一定要除掉小白兔和野狗吗？ 我自己带过各种团队，有自己培养的嫡系，有空降切别人的团队，有作为甲方带外包做项目，也有在被甲方指挥的外包团队里面干过…… 这么多经历总结起来就是，一个团队成员一定要具备多样性，这个团队才是完整的，才能有成长的生命力。一个团队的领导如果眼睛里揉不进沙子，对下属像处女座选媳妇儿一样追求完美二字，这个团队的效率和克服困难的能力，一定不会强。 所以还是上面表达的观点。『有教无类』，关键看你怎么用。野狗员工为了业绩无所不用其极，他们为团队做了不好的示范，但他们也能帮你发现新的业务增长点；小白兔员工为了自己的安稳两耳不闻窗外事，做老郝先生做自己份内的工作，但他们通常也会承担别人不愿意干的脏活儿累活儿。只要不是特别抵触工作，或者处处与人为敌，每个人都可以有他的位置，就看做领导的怎么安置而已。 PS：抢救出来的一篇文章，险些烂尾。做教训，牢记。2016.09.28 于成都……

互联网技术线的职业发展轨迹到今天已经很清晰，大体来说两个选择，要么继续深入走技术专家路线，当个架构师、研发专家，向计算机科学家方向迈进，要么转管理路线，从小组长做起，向 CTO 迈进。 这是正向的。反向，从一家公司技术负责人的 title，也能看出这家公司在技术方面的解题思路及现状。 1、招聘组长 / leader / 主管的，注意留意这家公司最近招聘攻城狮的岗位 JD。 通常直接在 JD 里面说招聘 leader 一类 title 的非大厂企业，通常的意思是：我们需要一名高级攻城狮。至于你能不能胜任 leader，需要在工作中观察。不过不管怎么说，能把 leader 提出来单独招聘，是有意识在补充团队的中坚力量，应该给个赞。 这一类企业，留意他们最近招聘攻城狮的 JD，一个是 JD 中的任职要求，是否有侧重点，是否描述清晰，大致可以看出这个团队遇到了什么问题。第二是看看攻城狮 JD 中的薪资范围，可以从侧面了解这家公司攻城狮的待遇水平，也可以看出公司对这个角儿的期望，是个管培生，骨干，还是个救火队长。 2、招技术总监的，企业是希望用管理手段来修补技术问题。 技术总监的职责偏管理而非技术，这是大家都有共识的。公司少一个技术总监，言下之意就是公司觉得技术管理上出了点问题，需要个人来补救。再换个角度翻译就是：希望通过技术管理来提（ya）高（zha）技术团队工作效率。 走技术总监这条线，等于就是走技术管理路线了。而且，一定是管理工作大于技术工作。 3、招架构师 / 首席架构师 / 研发专家的，通常是需要一个救火队长，少数是准备做大~~~项目。 架构师 / 首席架构师 / 研发专家这几个 title 是在技术线的，现实中很多企业里面已经是到技术线顶端了。 需要这类角色的企业，不少是需要一个能带队、独当一面的技术骨干，有不少企业在招聘的当下还面临一堆代码腐烂的系统，和一个问题重重的团队。能应聘这个职位的，跟应聘技术总监类似，入职后都要面临非常大的挑战，不同的是管理层的期望。能放出这个 title 的空缺，企业管理层是期望用技术的手段来解决现阶段面临的问题。 4、招 CTO 的，要么是一穷二白的创业小作坊，要么是高管层对产品的把控已经一筹莫展。 首先明确，CTO 在一家职能完备的企业里面，是高管角色，背的业务指标的，关心的是产品技术团队为公司业务增长提供多大的助力，对一个产品能不能实现、实现得好不好，他不负直接责任只负管理责任。同时，也意味着 CTO 对公司的主要业务必须非常熟悉。 创业小作坊招 CTO，基本上都是期望用 title 吸引住人才；而稍大一点的企业招 CTO，释放出来的信号是，高管层希望有人能通过对产品工作全权负责，来保增长促发展。 不管怎么说，就像 Fenng 自身遭遇的事情一样，CTO 这个角儿不好做。 另外还有一种常见的技术高管 title，叫『技术 VP』。这个基本上是活儿照干，但是不享受最后胜利果实的意思。企业招这个角儿的意思通常是：需要这么一个背业务指标的技术高管，你很合适，但又觉得你对企业带来的收益不高，比如没有一个好履历不方便放出去拉融资，所以把 CTO 的位置空缺，等遇到更合适的人，随时把你一脚踢开。 如果不是公司大到一定份儿上，招这个角儿的公司都是在耍流氓。 作为一名技术出身、想要升阶的求职者，首先搞清楚自己的期望，然后选择合适的职位去求职。不管最终选择什么样的岗位，都需要做好一件事：管理好别人的期望。而一个连自己的期望都管理不好的人，肯定没有办法管理好别人的期望。……

今年 今年还真是一个特别的年份。夏季刚来不久，天还没到最热的时候，老丈人就过世了。等入了伏，我们听了一整个夏天的救护车呜呜声。吃饭的时候，『呜呜呜呜呜』；在街上散步的时候，『呜呜呜呜呜』；坐公交车上，『呜呜呜呜呜』…… 有一次在家吃饭，救护车从楼下过了四次。重庆婆婆家楼上有老俩口和小儿子同住，结果做保安的小儿子下班回家，发现老俩口热死在家里——他们家竟然没有装空调。还有最近心脏猝死的山东大学生们。没有熬过今年的人，好像特别多。 另外，今年的蝉也特别多，多到建行放 ATM 的小门面里，小小不足十个平方，一到晚上，容纳了不下十只蝉，到处飞肆意闹。早晨出门，街边随处可见死掉的蝉，有些还趴在汽车前挡玻璃上，裸露在晨光里。鬼知道今年哪儿来这么多蝉。 自己动手 Homebrew 是 MacOS 下不错的工具，一个包管理器，码农最爱。不过人家一直没出稳定版，最新的好像才 0.9.9。最近就遇到一个不爽的事情：php56-grpc 这个包安装不上，编译阶段报错。仔细一看，原来用的扩展版本是 0.5.1 beta，人家扩展已经到了 1.0.0 stable，难怪。 于是干脆，自己修改 formular 升级，并提交了 PR。爽。中间顺带还解决了 ext-grpc 的一个 bug。 同时也深深感觉谷子哥家的东西，还真不是一般人能够触碰的。你要用，你就得懂。各种依赖，甚至于对他家私有库的依赖路径，都大大咧咧放进来。一旦遇到报错，要是没耐心跟还真不知道该怎么弄。幸运的是，这次人家就犯了一个小错误，改起来特别简单，顺手改完提交一下。 开放平台 蚂蚁金服成了互金行业名副其实的霸主，前段时间机构找个人投资者接盘蚂蚁金服股权的爆料显然并没有阻止它的快速成长。参照阿里系其它业务的发展轨迹，料想蚂蚁金服最近两三年会有个非常漂亮的成长曲线。 昨天才发现，蚂蚁金服在这个月（八月十日）发布了开放平台。 互金的开放平台还真不多见。印象中支付宝的开放平台做了一段时间之后，很快也就不能完全『开放』，半遮半掩地走着，运营上也完全没有再推。微信的开放体系中，与互金有关、涉及到支付的部分一直就没稳定过，从我亲身经历的项目来看，貌似财付通的技术限制让人捉急，不过也从来没看到微信从运营上推这部分的业务，反而是申请相关权限的时候接受审核力度很大。其它家，像什么京东、百度、腾讯开平…… 几乎都很少放开与金融相关的功能。特别是创业以来，我自己接触互金行业之后，感受到如果真放开的话，这其中的问题非常多，实际操作的时候平台侧会承担相当大的风险。因此，看到蚂蚁金服（支付宝）在如今开放平台遍地开花的时候再次推出自己家的开放平台，怎么说呢，一方面吃瓜看个热闹，另外一方面还真想看看他们会怎么去做这个事情。搞不好，金融行业真能因此进入『互联网+』的时代。 这是个不断触碰监管者 G 点来做创新的行业。希望蚂蚁金服能在除了『流量营销』和『会员管理』之外拿出更多有意思的玩儿法。……