Posts for: #WeChat

最近这些天，被 Log4j 相关的文章、讨论刷了屏。目前我在网上看到的文章，自媒体大多饱含情绪批评阿里，安全圈则多数对技术研究环境有忧虑。

列举一些信息：

1、法律——网络产品安全漏洞管理规定。

链接：http://www.cac.gov.cn/2021-07/13/c_1627761607640342.htm

对“网络产品提供者”（所有提供网络产品的企业，理论上都受约束）的规定：

第七条 网络产品提供者应当履行下列网络产品安全漏洞管理义务，确保其产品安全漏洞得到及时修补和合理发布，并指导支持产品用户采取防范措施：

（一）发现或者获知所提供网络产品存在安全漏洞后，应当立即采取措施并组织对安全漏洞进行验证，评估安全漏洞的危害程度和影响范围；对属于其上游产品或者组件存在的安全漏洞，应当立即通知相关产品提供者。

（二）应当在2日内向工业和信息化部网络安全威胁和漏洞信息共享平台报送相关漏洞信息。报送内容应当包括存在网络产品安全漏洞的产品名称、型号、版本以及漏洞的技术特点、危害和影响范围等。

（三）应当及时组织对网络产品安全漏洞进行修补，对于需要产品用户（含下游厂商）采取软件、固件升级等措施的，应当及时将网络产品安全漏洞风险及修补方式告知可能受影响的产品用户，并提供必要的技术支持。

对从事网络产品安全漏洞发现、收集的组织或者个人的规定：

（一）不得在网络产品提供者提供网络产品安全漏洞修补措施之前发布漏洞信息；认为有必要提前发布的，应当与相关网络产品提供者共同评估协商，并向工业和信息化部、公安部报告，由工业和信息化部、公安部组织评估后进行发布。

（二）不得发布网络运营者在用的网络、信息系统及其设备存在安全漏洞的细节情况。

（三）不得刻意夸大网络产品安全漏洞的危害和风险，不得利用网络产品安全漏洞信息实施恶意炒作或者进行诈骗、敲诈勒索等违法犯罪活动。

（四）不得发布或者提供专门用于利用网络产品安全漏洞从事危害网络安全活动的程序和工具。

（五）在发布网络产品安全漏洞时，应当同步发布修补或者防范措施。

（六）在国家举办重大活动期间，未经公安部同意，不得擅自发布网络产品安全漏洞信息。

（七）不得将未公开的网络产品安全漏洞信息向网络产品提供者之外的境外组织或者个人提供。

（八）法律法规的其他相关规定。

在这个事件中，阿里云同时兼具两个身份（理论上，所有用到 Log4j，受漏洞影响的产品和企业，都是网络产品提供者）。

2、工信部网络安全管理局通报

阿里云发现阿帕奇（Apache）Log4j2组件严重安全漏洞隐患后，未及时向电信主管部门报告，未有效支撑工信部开展网络安全威胁和漏洞管理。工信部网络安全管理局决定暂停阿里云作为上述合作单位6个月。暂停期满后，根据阿里云整改情况，研究恢复其上述合作单位。

3、阿里云回应：

阿里云一名研发工程师发现 Log4j2 组件的一个安全 bug，遂按业界惯例以邮件方式向软件开发方 Apache 开源社区报告这一问题请求帮助。Apache 开源社区确认这是一个安全漏洞，并向全球发布修复补丁。随后，该漏洞被外界证实为一个全球性的重大漏洞。

阿里云因在早期未意识到该漏洞的严重性，未及时共享漏洞信息。阿里云将强化漏洞管理、提升合规意识，积极协同各方做好网络安全风险防范工作。

4、负责任的披露（英语：Responsible disclosure）是计算机安全或其他领域中的一种漏洞披露模型，它限制了漏洞披露的行为，以提供一段时间来修补或修缮即将披露的漏洞或问题。

这也是阿里云提到的“业界惯例”。

5、这两年，我在社交媒体上陆续看到有些安全从业者到日本、新加坡等地工作。

至于观点，贴一下我信服的 TK（微博：@tombkeeper）在 2019 年 6 月就发过的内容：

限制漏洞披露，结果必然会影响漏洞研究本身。

漏洞研究和其它科技研究工作一样，都是特别苦的事情。人为什么愿意干特别苦的事情？那些博士们为什么愿意在实验室长年累月熬着？当然是为了发布研究成果，获得由此带来的收益（名、利、自我实现感，等等）。限制漏洞披露，就是削减漏洞研究的收益。

如果这种限制是全世界统一行动，那么大家刀枪入库，马放南山，卸甲归田，也挺好的。而如果只是一个国家这么干，那就相当于自己单方面主动裁军。

对安全问题的一个常见误解是认为漏洞是某种像导弹一样的东西，可以用油纸包起来放到山洞里。但导弹不会消失，而漏洞转瞬即逝。漏洞是动态的，不断产生，不断消失，所以其实更像电。电一旦发出来，难以长期保存。所以搞电力建设，核心不是囤积多少电池，而是建多少电站。对于漏洞来说，“电站”就是安全研究者。

在漏洞研究领域，人和人的差别有多大呢？大到一万个臭皮匠也顶不了一个诸葛亮。在任何行业，这种情况都是管理者最不喜欢的，但又是一个客观事实。在目前以及可预见的未来，没有什么软件或硬件能代替优秀的漏洞研究者。

目前业界公认水平最高的漏洞研究团队是 Google 的 Project Zero。Project Zero 汇聚了全世界各类漏洞研究方向上最好的一些人，每年都能产出数量和质量惊人的成果。那为什么这些人都愿意去 Project Zero？

Project Zero 的待遇当然是很好的。但同样的待遇，很多公司都能给得出。最主要的原因是 Google 给了 Project Zero 最宽松的氛围，特别是制度性地允许和鼓励对研究结果进行完全披露。

对研究者来说，除了薪酬待遇，最重要的是自己的成果能为业界所知，能自由地进行交流。这一点，决定了他们能够从内心中产生强大的自我驱动力，能对研究的问题昼思夜想，全身心投入。而不会像大多数人那样抱着拿一份钱打一份工的想法。不会多工作几分钟就认为公司占便宜了，自己吃亏了。

2006 年前后，国内网络安全研究人员的薪酬水平比较低。那几年 McAfee、Fortinet 等外企从中国挖走了大批优秀人才。以至于硅谷有些安全公司研究团队里一半以上都是华人。2012 年之后，国内这个行业的薪酬情况逐渐好起来，去国外的人就少了，一些已经去了国外的人也回来了。

《非暴力沟通》是冰河娟子两口子前些天到公司唠嗑时向我推荐的，正好我也觉得自己这方面做得不太好，之前 Shotgun 建议我看看冲突管理的书籍，我找了几本，没读进去。《非暴力沟通》却一口气快速看完了。

书中观点，让我总结，无非是：

沟通的核心在于倾听与表达。倾听他人时，不解读为批评或指责。表达自己时，不批评或指责。而这其中又有四个要点：

观察：调用一切知觉，看、听、回忆、思考沟通对象表达时的一切。

感受：基于观察结果，换位思考对方的感受，尝试理解，并问询（同时也可以表达自己的感受）。

需求：基于观察与感受，进一步理解对方和自己的真实需求。

行动：明确需求后，倾听时——可以明确地进一步向他确认、求证（也就是判断他的请求）。表达时，则清楚地提出请求，如“你是否愿意……”。

书里有很多例子，一一细看，能让你理解为什么有些表面看似差别不大的表达方式，在实践中会有巨大的差异。

如果你在工作生活中不时与伙伴发生冲突，或者家有不跟你好好沟通的熊孩子，可以尝试本书提到的技巧。

挺多人认为，写得太短，就不配称文章。我觉得，有观点，且能清晰表达，就好了。所以，虽然字少，照发不误。

前些天，跟老池群里瞎扯。他说：花钱才有乐趣。我习惯性怼他：显然不是，乐趣来自内心。（后来他解释：乐趣肯定来自内心，我的原则是，不为了省钱减少乐趣。）

我记几个最近让我觉得愉悦有乐趣的小事。

比如：背个相机散步，在路上边走边看，可能是一束光，也能是层叠的光影，可能是一面白墙，细细观察，各有特点。于是能拍下一些没什么人会喝彩的照片。

比如：看阿加莎·克里斯蒂的《无人生还》，书的“骨架”就是这么一首童谣。

十个小士兵，出门打牙祭；不幸噎住喉，十个只剩九。

九个小士兵，秉烛到夜半；清早叫不答，九个只剩八。

八个小士兵，旅行去德文；流连不离去，八个只剩七。

七个小士兵，举斧砍柴火；失手砍掉头，七个只剩六。

六个小士兵，捅了马蜂窝；蜂来无处躲，六个只剩五。

五个小士兵，同去做律师；皇庭判了死，五个只剩四。

四个小士兵，结伴去海边；青鱼吞下腹，四个只剩三。

三个小士兵，动物园里耍；狗熊一巴掌，三个只剩俩。

两个小士兵，日头下面栖；毒日把命夺，两个只剩一。

一个小士兵，落单孤零零；悬梁了此生，一个也不剩。

将自己代入到岛上，设身处地，脑子里满是问号的同时，又有点头皮发麻。将自己代入为阿加莎，构思这本小说，还有多少种不同结构玩法。

比如：清早带两只神兽跑步，这俩家伙穿着校服，在我身边一左一右地小碎步，让我感觉自己还有点神气。

我告诉他们我的感受后，他们突然就忽左忽右，忽前忽后地边跑边笑，捉迷藏似的。这时候我享受极了。

比如：今年我学会了游泳。

蛙泳时，头埋进水中，一时会觉得自己镶嵌在绿色且温暖的翡翠里，轻轻一拨拉，漂浮着，有时会舒服得让我有些恍惚。

而自由泳时，因为还不熟练，每次出发前还要调匀呼吸，竭尽全力力争不喝水地“爬”到对岸。喘着粗气游到尽头，觉得这次比上次游得似乎好了一点点。

比如：前几天跟小叫聊天，他说到最近很少做梦，没有做会害怕的噩梦，也没做什么美梦。我问他做过什么美梦，他说，都忘记了呀。

又想了想，说：有一次，梦见一群很大的蚂蚁在烤鸡腿吃，我告诉姐姐了，姐姐说，她之前梦见过一样的。是一群很大的蚂蚁在给她喂披萨吃，搞笑吧？

比如：翻看老照片，看到小泡几年前的小作文，写着：

一天，小蜗牛们去春游，三辆车要载小蜗牛们去春游，有一只蜗牛没上车，它遇到了蚂蚁、蝴蝶、螳螂，蚂蚁问：“你为什么不上车？”“因为我想看花草。”蝴蝶问：“你爬很慢为什么要自己春游？”“因为我不想晕车。”螳螂问：“其它蜗牛到家了怎么办？”“我在路上看月光。”

是呀——我在路上看月光。

这种“我在路上看月光”的洒脱，就很有乐趣。

近期，有几位知识星球里的星主找我们。有家 SaaS 公司扩大业务，做了社群小程序，因此销售四处出击，主要的沟通话术（核心竞争力对比是）：

知识星球的手续费是按订单金额抽成，我们更便宜，只需要每年支付几千元年费，并且还能同时拥有很多营销工具，可以做裂变增长。

这些星主们，多数是告诉我们，竞争更激烈了。少数则是希望——有竞争了，是不是可以降一降手续费。

我给的反馈也简单，建议先认真花点时间做个测试，如果确定希望迁移，我们可以协助。

对此，我的观点是：

一、仅有微信小程序的社群产品，留存、活跃、用户停留时长都很难做起来。

主要原因是：

微信是个巨大的生态系统，用户的社交、工作、生活都离不开微信——这表示用户有大量重要的微信消息需要查阅，有很多重要的微信工具需要使用（比如健康码、行程码）。

任何一个动作，打断了你在社群里的阅读、互动之后，用户都很难重新找回社群里交流的感觉，甚至找不到社群的入口。

因此社群活跃度会下滑。

知识星球一直关注的活跃用户指标叫——七日三活（七天里有三天活跃，才有资格算是社群里的活跃用户），我们做了很多工作。

二、SaaS 形态容易引导着企业走向大而全。

很多 SaaS 企业对“以用户为中心”的理解，是产品上也听用户的——毕竟用户要这个，还要那个……而且他们付了钱。

大而全，可能出现的最大问题是：功能完备，但是没有一个是市场上最好的。

国外有家公司叫 Basecamp，他们也做 SaaS，几十个人远程办公，每年能够有几千万美金利润，他们的一个核心理念就是做减法。

我一直认为，做加法一时痛快，长期痛苦。也因为有这种思维，所以我们宁愿将知识星球做深做透。

三、裂变带来的用户往往质量不高。

虽然“裂变”这个词被广泛使用，很多产品但凡做营销，必须谈裂变，我还是质疑。拿核裂变类比，核裂变是由较重的（原子序数较大的）原子，主要是指铀或钚，裂变成较轻的原子的一种核反应或放射性衰变形式。

而大多数营销工具的使用者，“裂变”的起点，“原子序数”都很小。因此，大多数的裂变，都是无用功。

四、坚守长期价值。

短时间内，会有一部分用户被“只收 SaaS 年费，不收手续费”吸引。不过其实认真想想，或许可以想到一种可能性：大多数付了 SaaS 年费的人，连这个年费都没挣回来。

在知识星球里，模式是：你挣到钱了，分给知识星球一点，让我们能健康发展，有办法持续改进并且维持恰当的利润。

长期看，注重用户体验，期待能有更好的内容留存，期待更多用户活跃与互动的用户，会寻找更好的社群产品，而知识星球就在这里。

做少，做小，做简单，长期来看，或许有机会做成最好的——因为我们做了足够狭小细分的领域。

之前看过《重来 3：跳出疯狂的忙碌》，前些日子 Tony 推荐，我又认真重读。Basecamp 这两位特立独行的创业者的书，曾有一本《Getting Real》，我学产品时，从中吸收了不少观点。

又看一遍后，我总体想法有：

1. 不追求做大、上市这些事，而是把目标设定为做一家能够长期生存、有价值、有利润、有效率、员工满意度高的小公司。

2. 把时间花在思考怎么做减法，而非只是忙碌地工作。可以微调组织结构、业务、产品，公司、团队、业务、商业模式都简单了，效率能高起来，团队也能更开心。

摘抄书中的一些内容（但还是推荐你自己看一遍）：

一切始于这个概念：你的公司是个产品。没错，你做出来的东西叫作产品（或服务），但它是经由你的公司做出来的。正是因为这个原因，你的公司应该是你最棒的产品。

如果你把公司视作产品，你就会问出不一样的问题：在这里工作的人知道怎么使用它吗？它是简单的还是复杂的？它的运作原理显而易见吗？它哪里最快，哪里最慢？它有漏洞吗？哪些漏洞可以快速修复，哪些需要花很长时间？公司跟软件一样，必须能用，也必须有用。它大概也会有漏洞—由于糟糕的组织设计或文化上的疏忽，公司所遭遇的挫败。

当你把公司当成一件产品来审视的时候，你就有了全新的视角，各种各样的改进可能会纷纷出现。当你意识到你的工作方式可以改变时，你就可以着手塑造更新、更好的东西了。

公司里的各种条条框框、规则，其实都是可变的。

做公司如做产品，要不断迭代，越来越简单、易用、自然，而且有利润。

我们不推崇忙碌，我们推崇高效。投入的精力能减少吗？要做的事情能砍掉多少？我们的清单里写的不是“哪些事情要做”，而是“哪些事情不要做”。

什么也不干是完全可以的。更妙的境界是，没有值得做的事情。如果你当天的工作只需3小时就能完成，那做完了就停下。不要只为了让自己保持忙碌或拥有高产的感觉，就再用5小时的工作把这一天填满。利用时间的一个妙招就是，不做不值得做的事。

想要完成更多事？唯一的办法就是少干点。

我们决定，规模要尽可能地小，持续时间要尽可能地长。我们没有不断发明新产品、承揽更多责任与义务，而是持续不断地、有意识地精简和减负——即便是在顺风顺水的情况下。

世上并没有哪条自然法则规定，企业必须快速且永无止境地增长。

做减法，做更少的事，但是做好，做出效果。

我们并不是凭空认为，在绝大多数情况下，非实时沟通就是比实时沟通效果好，这是经过好几年对聊天工具的滥用之后才发现的。我们看到了干扰是如何发生的，工作效率又是如何被降低的，于是我们找到了一种更好的沟通方式。

上次你能把完全不受干扰的3个甚至4个小时留给自己和工作，是什么时候？我们曾在一个600人的大会上提出这个问题，举手作答者还不到30人。你答得出来吗？

我们努力创造出一种非即时回应的文化。如果一个问题并不紧急，那么3小时后再回复也无妨，没人会火烧眉毛。我们不但接受，还鼓励员工这样做：不要经常检查电子邮件、聊天工具或即时短信，给自己留出足够长的、不受打扰的时段。

等一等不要紧，天不会塌下来，公司也不会倒掉。它只会变成一个更加冷静、镇定，工作起来更舒服的地方。对每个人都一样。

涉及群聊时，我们有两条首要的经验法则：“在少数情况下实时沟通，在大部分情况下不必”，以及“如果这件事很重要，那就慢慢来”。

重要的议题需要留出时间思考，也需要跟群聊中的其他话题区分开来。如果大家在群聊中讨论的某件事情显然非常重要，就不应该七零八落地一句句发消息，我们就会请大家“把它好好地写下来”。这一条要和另一条准则一起使用：“如果你需要每个人都看到它，就不要在群里说。”为这件事开辟一个永久的、可以让大家深思熟虑的讨论空间，而不是让它在5分钟后就被新信息淹没不见。

有许多管理人员之所以喜欢群聊，是因为他们可以快速地进出，并且同时对很多人说话，可这会导致许多员工整天心神不宁：明知自己还有很多实实在在的工作要做，却必须努力跟上群聊的进程。

聊天工具、群聊其实对效率是很大的妨碍。

放下手机，慢一些回复，往往也没事。

对重要的议题，用云文档讨论，或者当面快速聊清楚。

在Basecamp，我们的一个应对办法是写月度简报。团队带头人把当月做完的工作和取得的进展写成简报，向全公司公开。把所有微末小事都总结成大家愿意去关心的要点。这就足以让大家都跟上节奏，但又用不着了解无关紧要的海量细节。

管人的人，按月做 OKR 回顾，其他人索性抛掉周报日报这些事。

每周有个跨部门的信息同步会议，提前把待讨论事项都记录在云文档里，都做预习、思考，开会时有事说事，没事几分钟快速结束。

固定的截止日期，可变的工作量，如此一来，权衡、妥协和折中就会参与进来，而这些都是健康、冷静的项目进程的必备要素。而当你既要敲定日期，工作量也不能变的时候，你就等着迎接焦虑、过劳和筋疲力尽吧。

界限即自由。切实可行的截止日期，再加上灵活可变的工作量，刚好符合这个道理。但要做到这个，你需要制订预算，摒除预估。高质量的成果会自然而然地将给定的时间段填满——如果你允许的话。

尝试两周一个冲刺的 Scrum，就是“固定截止日期 + 可变工作量”的一种体现，我们正在实验。