三节课是首家互联网产品主题学习社区，提供最系统的产品 + 运营课程学习，定期出品有深度的产品观察 + 评论。

　　如需转载，请联系三节课微信公众号（ID: sanjieke），并注明出处。

昨天下午，知乎APP出现了一个较为严重的故障——其iOS版本出现登陆账号串号（后经知乎团队仔细查验，并非「串号」，而是属于数据展示错乱，并不会产生错乱的写入操作）的事故，三节课昨天下午在业内首家对此事进行了报道。（详情）。

因为是第一时间首家发出的消息，加上三节课的目标用户都是互联网从业者们，所以消息发出后很快引发了一系列连锁反应——大量媒体对我们的报道进行了转载，大量用户也对此信息进行了传播，消息阅读量很快突破4W。

因为事情本身对知乎还是一个比较负面的事，所以文章发出后，知乎的工作人员在第一时间就和我们取得了联系，交流了事件的实际情况以及后续的处理措施。不得不说，从第一时间的响应给出说明，到之后对于问题的排查、解决，再到后续与我们的进一步交流，知乎团队在整个过程中都显得非常专业。

在本文中，我们将知乎与我们之间的沟通，以及我们所了解到的一系列相关信息整理成文，除了澄清昨天文中的两处错处之外，下文中你将也可以看到在出现了一个如此巨大的负面事件，且遭遇了N多行业媒体和用户的负面评价之后，一家公司是如何在最短时间内进行处理并给出回应的。

我们相信，其中必有许多值得借鉴之处。

1.

首先，我们要帮知乎说两句话，也对于昨天我们发布的信息进行一些校正和说明。

其一，我们必须道歉的是，昨天的文章中，有一处表达存在偏颇之处。

我们在昨天的文章中提到过，登录出现“串号”情况后，用户能够完整看到另一位用户的匿名回答，并对此解读到“部分用户的匿名回答可能会被泄露”。

关于这个信息，昨天在推送消息时，我们并没有进行特别完整的测试，也不理解知乎的产品逻辑设计，所以当时是纯粹凭借的直觉和推断得出了推论。

而事实上，知乎APP用户登录后的个人中心中，并不存在一个入口可以看到“我的匿名回答”，甚至是在“我的全部回答”中也不会显示出“匿名回答”的信息。所以其实“匿名回答可能会被泄露”的情况其实概率非常小。

经与知乎沟通及后续确认，知乎的匿名回答如果被回复或被点赞，在个人通知里是可以看到的，但刚好收到通知进到消息列表里面是比较低概率的事件，且你只能看到问题，看不到当时的回答是什么。

举例：小A之前匿名回答过一个问题，且这个问题被点赞了，小A的消息通知里会提醒小A在这个问题里被点赞了。如果这个问题下面的回答只有一个是匿名评论，那基本可以断定这个答案就是小A回答的。如果这个问题下面的回答有很多都是匿名评论，那除了作者小A本人之外，即使被小B串号看到，小B也无法判断，到底哪个匿名评论才是小A的。

也就是说，看到有匿名回答，但是点开后，并没有这样一个匿名回答和账号信息直接被关联展示的页面，所以不能够用作直接证据来证明某某回答是谁发的。是否存在被发现的概率？是。但由于数据展示错乱导致匿名回答泄露的概率还是非常低的。

其二，atv，我们在昨天的文中对于此次事件通过几名业内人士进行了解读，解读认为，知乎在发现问题后，粗暴地切断了服务器，似乎说明知乎没有备份数据。

　　而按照知乎团队在后续第一时间给出的回应，当时进行紧急下线处理的背景，其实是这样的——

　　知乎团队在发现问题之后，需要确定问题，但确定问题的原因是需要时间的。在此期间，为了保护用户的隐私不被泄露，所以工程师那边对移动端的服务做了暂时的紧急下线处理。

　　知乎有一套完整的危机处理体系，在这个体系中，所有的决策判断都会遵循这样的大前提：在任何时候，用户的权益都是第一位。知乎在对用户各方面权益的优先级排序中，将用户的帐号安全和隐私视为最高优先级。

　　基于事件可能对用户的安全和隐私方面的权益造成损害的考虑，判断需要以更高级别的用户权益为优先，所以暂时牺牲了用户的访问体验，比较快速地采取了最严格的措施来止损。这一点，从产品和运营角度综合来看，是完全可以理解的，这和粗暴切断服务器以及没备份没有关系。