三节课是首家互联网产品主题学习社区，提供最系统的产品 + 运营课程学习，定期出品有深度的产品观察 + 评论。
如需转载，请联系三节课微信公众号（ID: sanjieke），并注明出处。
昨天下午，知乎APP出现了一个较为严重的故障——其iOS版本出现登陆账号串号（后经知乎团队仔细查验，并非「串号」，而是属于数据展示错乱，并不会产生错乱的写入操作）的事故，三节课昨天下午在业内首家对此事进行了报道。（详情戳我）。
因为是第一时间首家发出的消息，加上三节课的目标用户都是互联网从业者们，所以消息发出后很快引发了一系列连锁反应——大量媒体对我们的报道进行了转载，大量用户也对此信息进行了传播，消息阅读量很快突破4W。
因为事情本身对知乎还是一个比较负面的事，所以文章发出后，知乎的工作人员在第一时间就和我们取得了联系，交流了事件的实际情况以及后续的处理措施。不得不说，从第一时间的响应给出说明，到之后对于问题的排查、解决，再到后续与我们的进一步交流，知乎团队在整个过程中都显得非常专业。
在本文中，我们将知乎与我们之间的沟通，以及我们所了解到的一系列相关信息整理成文，除了澄清昨天文中的两处错处之外，下文中你将也可以看到在出现了一个如此巨大的负面事件，且遭遇了N多行业媒体和用户的负面评价之后，一家公司是如何在最短时间内进行处理并给出回应的。
我们相信，其中必有许多值得借鉴之处。
1.
首先，我们要帮知乎说两句话，也对于昨天我们发布的信息进行一些校正和说明。
其一，我们必须道歉的是，昨天的文章中，有一处表达存在偏颇之处。
我们在昨天的文章中提到过，登录出现“串号”情况后，用户能够完整看到另一位用户的匿名回答，并对此解读到“部分用户的匿名回答可能会被泄露”。
关于这个信息，昨天在推送消息时，我们并没有进行特别完整的测试，也不理解知乎的产品逻辑设计，所以当时是纯粹凭借的直觉和推断得出了推论。
而事实上，知乎APP用户登录后的个人中心中，并不存在一个入口可以看到“我的匿名回答”，甚至是在“我的全部回答”中也不会显示出“匿名回答”的信息。所以其实“匿名回答可能会被泄露”的情况其实概率非常小。
经与知乎沟通及后续确认，知乎的匿名回答如果被回复或被点赞，在个人通知里是可以看到的，但刚好收到通知进到消息列表里面是比较低概率的事件，且你只能看到问题，看不到当时的回答是什么。
举例：小A之前匿名回答过一个问题，且这个问题被点赞了，小A的消息通知里会提醒小A在这个问题里被点赞了。如果这个问题下面的回答只有一个是匿名评论，那基本可以断定这个答案就是小A回答的。如果这个问题下面的回答有很多都是匿名评论，那除了作者小A本人之外，即使被小B串号看到，小B也无法判断，到底哪个匿名评论才是小A的。
也就是说，看到有匿名回答，但是点开后，并没有这样一个匿名回答和账号信息直接被关联展示的页面，所以不能够用作直接证据来证明某某回答是谁发的。是否存在被发现的概率？是。但由于数据展示错乱导致匿名回答泄露的概率还是非常低的。
其二，我们在昨天的文中对于此次事件通过几名业内人士进行了解读，解读认为，知乎在发现问题后，粗暴地切断了服务器，似乎说明知乎没有备份数据。
而按照知乎团队在后续第一时间给出的回应，当时进行紧急下线处理的背景，其实是这样的——
知乎团队在发现问题之后，需要确定问题，但确定问题的原因是需要时间的。在此期间，为了保护用户的隐私不被泄露，所以工程师那边对移动端的服务做了暂时的紧急下线处理。
知乎有一套完整的危机处理体系，在这个体系中，所有的决策判断都会遵循这样的大前提：在任何时候，用户的权益都是第一位。知乎在对用户各方面权益的优先级排序中，将用户的帐号安全和隐私视为最高优先级。
基于事件可能对用户的安全和隐私方面的权益造成损害的考虑，判断需要以更高级别的用户权益为优先，所以暂时牺牲了用户的访问体验，比较快速地采取了最严格的措施来止损。这一点，从产品和运营角度综合来看，是完全可以理解的，这和粗暴切断服务器以及没备份没有关系。
关于以上两点，我们在文章发出时没有经过严谨的审核，给知乎造成了困扰，也误导了一部分读者的判断，为此，我们要向知乎诚挚致歉。
同时，我们也会吸取经验，在以后推送相关资讯和报道时，会力求将内容的真实、可靠和严谨放在第一位。
2.
经常关注三节课的用户会知道，关于互联网圈子里发生的一些事件，我们一般会在事后有一个复盘，有些是吸取教训，有些是学习经验。这既是希望在事件梳理的过程中，培养自己的总结习惯，也是希望将复盘展现给大家，用于更多用户的学习。
这次也不例外。
像前面提到的，关于知乎团队对本次事件的处理方式，我们认为，有很多环节是很值得我们学习的。
我们不妨先来看看在三节课推送过了这篇对知乎有明显负面影响的消息后，知乎跟我们都说了些什么。
在我们昨天的推送发出之后（下午3点46分），有很多三节课的用户进行了转发，迅速形成刷屏，想必知乎官方也第一时间注意到了这条推送。
于是，下午4点5分，推送完成19分钟后，知乎的负责人就主动联系我们进行了说明（见下图）。
可以看到，这个时候，知乎官方并未进行过多解释，只是——
1.对文中的不实之处进行了解释，并告知真实原因；
2.表明了知乎已经在第一时间修复，当前一切以用户为重，结束后将统一就事件进行说明。
应该说，作为第一家发布消息的消息源，知乎的沟通方式让我们感受很好。至少，在一个对自己构成了较大影响的负面消息传播源面前，他们既没有跪舔逢迎，也没有简单粗暴地寻求删稿之类的处理（当然了，删稿这种事，我们应该也是不会干的），而是选择了坦诚透明的说明沟通，并表明了以用户为先的问题处理立场。
应该讲，一款大用户体量的产品出现如此重大的问题，此时的内部应该是极度忙乱的，而此刻的知乎还能够以用户为中心，秉持自己客观理性的风格来与消息源进行沟通，很难得，值得我们点赞。
随后，在大约5点前后，知乎官方的负责人又对于事态的进展主动进行了说明（真的是主动）。
而5点53分，知乎官方正式发布了关于昨日事件的公告，我们也第一时间收到了知乎官方发来的告知同步信息。
应该讲，这是一篇很诚恳的公告。公告里将故障出现的原因以及知乎现在做了哪些处理都一一呈现，并没有逃避。
然后，直到晚上，当一切喧嚣都已经尘埃落定后，知乎官方的负责人才开始就昨天的事件与我们进行了深度的沟通，开始逐一指出文中存在偏颇的地方，并分享了自己的一些理解。
应该说，面对这一事件，这样一种“出事后优先考虑用户，直到用户的问题都解决了才来开始表达自己的不满”的沟通处理方式对于我们来说是特别认可和喜欢的。以至于最后我们不仅全盘接受了知乎指出的问题和批评，也愿意尽我们的所有力量来帮知乎进行后续的说明。
但假如知乎在事件出来之初就跑来找我们吵架或是以各种理由要求我们删贴呢？我想最终结果可能未必会好。
3.
另外一个可以观察的维度是：从下午2点05分事故出现，到最终5点53发布官方公布的这3个多小时内，知乎团队具体又做了哪些动作，采取了哪些处理措施呢？这其中又有哪些需要我们学习的呢？
在与知乎官方负责人的交流中，我们也具体询问了这一点。在收集了我们的问题后，知乎官方给予了我们非常详细的回复，现整理如下——
14点03分，第三方防火墙服务器端安全措施变更，“串号”问题出现。
14点05分，知乎工程团队收到产品警报，而后，知乎开始逐步收到用户反馈。在此之后，工程师团队推断是第三方防火墙问题，并联系第三方，要求其做回滚处理，同时进行了防火墙切换。出于保险起见，知乎对移动客户端服务做了紧急下线处理，以上动作，在14 点 30 分完成。
而后，工程团队一直在进行筛查影响范围、定位故障和尽快修复这几个方面的工作，包括：
强制在该时段访问知乎的用户重新登录；
具体故障明确定位后，出于谨慎，知乎进行了多次的测试和筛查；
在此基础上，对移动端服务逐步测试上线，所以恢复的过程并没有很快。同时，工程师团队对其他环节也进行了反复检查，并确认所有后台数据库一直受到严密的保护，本次故障没有涉及任何数据库泄露。16时00分，完成整体检查后，移动客户端服务恢复。
持续观察上线后的反馈情况，并无异常反馈。
另外一方面，面向用户的公告其实也一直在准备中，最终在下午6点左右发出，包含对于事件的原因，初步筛查结果，知乎的初步处理措施等。知乎内部的公告发布流程并不繁琐，但需要对用户负责，所以知乎团队最终选择等待查明故障原因，完全确认事实状况并且进行初步妥善处理之后发出。
其实直到昨晚，在移动端服务重新上线后，知乎团队也在跟第三方一起做更为细致的核查和更精确的受影响用户定位，确定一共327名用户受到了影响。以及已经可以确定，并没有知友发布的内容遭到篡改（因为实际是「数据展示错乱」，不涉及写入）。
第三方技术故障造成影响的情况，虽然小概率，但知乎团队也在进一步评估相关技术方案，会很快上线更多保障措施。
甚至一直到今天中午，知乎官方负责人还和我们说，他们在等技术的同事出一份100%确定故障的说明，再来向我们说明相关具体信息。到我们文章准备发出的时候，知乎刚刚发出“关于知乎客户端因第三方防火墙故障临时下线的公告补充”，戳“阅读原文”可以看到。
知乎在重大故障面前的一系列动作，对于任何可能会遇到用户隐私泄密的产品和团队来说，是一例正确的示范，知乎在这短短4个小时以内的反应，也足以见其对用户的真诚和毫无保留，我们叹服知乎这样一个其实并不算小的团队在遇到危机的时候，能够有如此灵活迅速，能够如此坦率诚恳。可以说，如果不是一个真正从上而下都特别重视用户的团队，是很难做到这一点的。
至此，关于本次事件的说明告一段落，我们也希望本次事件可以对大家有所启发。
最后，对于本次事件前后知乎的表现，我们想说的是：可以，这很知乎。