防止 - 缺失的新领域注册咨询
Issues轻微事件
受影响的组件
ConsoleConsole
- identified
我们已经查明了域名注册的原因 无法提供建议 并正在努力实施一个固定。 我们将继续在状态网页上发布任何新的信息或更新.
- monitoring
一项措施已经执行,我们正在监测结果.
- resolved
这一事件已经得到解决.
自动翻译自官方事件更新。
80 Knowbe4 incidents · 2025年9月 — official updates, affected components, duration and resolution details.
我们已经查明了域名注册的原因 无法提供建议 并正在努力实施一个固定。 我们将继续在状态网页上发布任何新的信息或更新.
一项措施已经执行,我们正在监测结果.
这一事件已经得到解决.
自动翻译自官方事件更新。
我们正在调查一个影响控制台登录的问题。 我们将在此提供更多的最新情况.
一项措施已经执行,我们正在监测结果.
这一事件已经得到解决.
□ ** 摘要** 2026年10月13日,从约14:19到15:05\(UTC\),所有区域的客户都无法登录到KnowBe4安全意识培训\(SAT\)控制台,KnowBe4学习者经验台,PhishER控制台通过KnowBe4 SAT. SAML和密码登录返回错误,KnowBe4SAT控制台没有出现在KnowBe4平台上. 一些背景进程,包括用户同步和培训电子邮件,在此期间也失败了. 这起事件是由一个生产发布 与我们代码的另一个变化相冲突。 14:59至15:05\(UTC\)之间, 这个问题没有造成数据损失。 □** 轮回原因** 代码部署移除了启动配置值来加速应用程序启动时间. 在测试最初的更改之后, 我们的代码中添加了一个单独的组件, 因此,每次试图保存用户记录都引起了一个错误,包括记录登录尝试的更新. □** 客户影响** 各地区的客户无法通过SAML或密码登录到KSAT控制台. 无法通过KnowBe4SAT控制台访问PhishER控制台。 新的用户创建,用户同步,培训的电子邮件在此期间失败了,但在重新部署后自动被重审. □** 减轻和补救** 我们发现部署取消了另一个部分仍然需要的配置值。 通过恢复释放,这得到了缓解,我们通过直接检查和自动化测试,确认了所有区域的恢复情况。 我们还还原了原始代码的原始修改,并准备了一个包含相容性修补的校正版本,因此可以安全地重新恢复原来的改进. □ ** 预防措施** 新增密码核查和部署测试.
自动翻译自官方事件更新。
我们收到消息称, KnowBe4 电子邮件安全添加显示错误“ KnowBe4 电子邮件安全阻碍发送此消息”。 我们正在调查这一问题,并将在获得更多信息后更新这一页.
并监测结果以确保不再出现更多问题.
这一事件已经得到解决.
从2026年10月12日星期一大约14:25\(UTC\)起,到2026年10月13日星期二大约15:07\(UTC\)起,欧盟预防和保护案例中的一些客户在从微软Outlook发送邮件时遇到困难. 受影响的信件没有发送,"KnowBe4 Email Security"添加了以下错误:"被添加的"KnowBe4 Email Security"阻止了这封信件的发送". 这个问题是由于一个添加版本如何准备发行时出错而导致的,该版本产生了两个略有相异的同版本. Outlook在加载后会下载一组必须匹配的文件. 在欧盟的例子中,Outlook有时会收到两个副本的文件,因此加载无法完成加载,信件也没有发送. 一些设备也保存了失败的下载,因此这些设备上的错误一直持续到应用了固定. 为了解决这个问题,我们的团队修正了欧盟的附加文件,以便每个客户都能收到一个匹配的集. 然后,我们向所有区域发布了增补内容的更新版本,清除了任何被节省的错误。 KnowBe4 Email Security add-ind-于2026年10月13日以15:07\(UTC\)左右恢复正常运行. 为了防止今后出现这类问题,我们正在改变添加版本的准备和发布方式,使每个版本总是产生同一套文件,每个客户同时收到同一套版本. 我们也在更改添加文件,这样无法将添加文件的下载保存在设备上. 最后,我们增加了加载出错的提示,以更快地发现. 这个问题没有造成数据损失.
自动翻译自官方事件更新。
我们目前正在调查一个有关美国服务器的预防和保护性能退化的问题.
我们与美国的预防和保护事例查明了一个问题,导致业绩下降。 一项解决办法已经落实,我们将继续监测这一问题.
这一事件已经得到解决.
□ ** 摘要** 从2026年9月28日星期一约16:00\(UTC\)起,到2026年9月30日星期三约12:35\(UTC\)起,一些顾客在访问美国预防和保护案例时遇到延迟邮件流和间歇性问题. 9月28日,我们的监控显示网络流量很大,每个小时的顶端都有尖刺. 一些顾客开始遇到间歇性的问题, 邮件处理取决于开始的出站时间的内部检查,因此消息被排入队列. 顾客向支援小组报告了这个问题,我们张贴了一份状况页通知。 当天晚些时候,随着美国交通量的减少,性能有所恢复. 9月29日,我们的工程师审查了前一天跨邮件网关的数据、他们依赖的内部服务以及网络层。 邮件流动延误和控制台访问问题短暂地返回,然后随着网络流量下降而缓解,与9月28日的情况相同。 9月30日,从大约12:19到12:35\(UTC\fs),我们的团队在继续服务的同时提高了美国网络服务的能力. 他们的载荷在改变后立即下降,而"预防和保护"则于2026年9月30日12:35\(UTC\)左右恢复了正常性能. 我们在9月30日和10月1日监测了高峰流量,没有再出现。 这个问题没有造成数据损失。 □** 轮回原因** 造成这一问题的原因是,处理我们美国邮件处理服务流量的网络服务能力有限。 在高峰期交通,尤其是小时高峰期,网络服务无法快速处理连接. 这增加了经过他们的交通延误并导致一些连接下降. 流量包括内部请求 我们发送的邮件网关 查询分发名单的成员, 所以应用正确的政策。 这些请求都受到严格的时间限制,这样一个缓慢的查询无法无限期地拖延邮件处理. 当网络服务将请求延迟到超过这个限度时,它们失败了. 因此邮件处理速度放缓,消息被排队. 有两个因素使问题变得更加糟糕和难以确定。 首先,一些内部请求也使用了这些网络服务,并受到容量限制的影响. 其次,网络服务在计算使用量达到通常表示出问题的水平之前开始退化. 标准计算监测没有捕捉到网络饱和,因此原因需要较长的时间来识别. 在不中断服务的情况下找到安全增加能力的办法也需要时间,这就是为何在9月30日适用了这一固定。 □** 减轻和补救** 我们发现,美国网络服务 没有足够的能力处理高峰流量。 我们通过提高它们的能力来缓解这种情况, 以保持服务在整个变化中运行。 容量增加后,网络服务处理高峰流量,不再再出问题. 我们还发现计算使用本身并不是网络饱和的可靠迹象. 我们扩大了监测范围,除了计算使用外,还跟踪网络健康指标。 最后,我们发现很难找到失败的内部请求在哪里破裂。 我们增加了记录 显示内部请求失败和超时之处 □** 客户影响** 在9月28日和29日美国运输量高峰期间,一些客户在通过“预防和保护”处理和发送进出邮件方面出现延误。 分发给分发清单的邮件可能处理得比较慢,同时重新检查。 有些顾客还间歇性地难以登入或使用美国控制台。 随着美国交通量的减少,影响每天都有所缓解,排队邮件一旦恢复容量就得到处理。 9月30日事变后,在高峰交通期间没有再出现再退化. □ ** 预防措施** 为了防止今后出现这类问题,我们提高了美国网络服务的能力,并扩大了我们的监测范围,除了计算使用外,还跟踪网络健康指标. 我们还在内部请求失败时增加了伐木,以提高能见度.
自动翻译自官方事件更新。
我们已查明了“保护”的一个问题,它导致业绩下降,我们的工程小组正在寻找解决办法.
我们发现保护问题已导致业绩下降。 一项解决办法已经落实,我们将继续监测这一问题.
我们已查明了“保护和预防”的一个问题,这个问题已导致业绩下降,我们的工程队正在寻找解决办法.
一项措施已经执行,我们正在监测结果.
这一事件已经得到解决.
□ ** 摘要** 从2026年9月24日(星期四)约17:07\(UTC\)起,到2026年9月25日(星期五)约09:16\(UTC\)起,一些顾客间歇性地出现慢跑,出错,并延误了美国"保护和预防"的邮件流动. 9月24日, 电子邮件流量异常高涨, 我们的监控在17:07\(UTC\)时发出警报。 一些客户在加载页面或高级选项时看到保护系统访问缓慢或间歇性出错. 访问不一致,所以有些顾客可以使用"保护",而另一些顾客看到错误. 通过美国实例的邮件处理速度放缓,一些消息被延迟,或者预期时没有出现在节制收件箱中. 性能似乎有所改善,因此我们把状态页通知移至了18:39\(UTC\)Monitor. 后来又再次出现这个问题,顾客报告说我们的支助小组继续进展缓慢。 在19:57\(UTC\),我们把通知移回调查,并将它扩大到包括“预防”,因为影响越来越明显。 我们的小组监测了受影响的系统,而邮件量上升则减弱了。 随着网络服务上的负载恢复正常,邮件处理恢复了,邮件队列一夜后恢复正常. 我们确认, " 保护 " 正在正常装载,测试信息正在再次发送,然后继续进行监测。 2026年9月25日09:16左右(UTC\)保护与预防恢复正常性能. 这个问题没有造成数据损失。 □** 轮回原因** 这个问题是电子邮件流量异常高涨造成的。 增加的量使处理我们美国邮件处理流量的网络服务承受了持续的负担。 这些网络服务在固定能力限度内运作,在激增期间其能力无法扩大。 因为他们跟不上激增的速度,所以减速了,一些处理断断续续地失败了. 因此,大量邮件被排入了美国的邮件处理,一些页面和"保护"中返回错误的动作,一些信件被延迟,或者在预期时没有出现在节制收件箱中. 有两个因素使这一问题难以管理。 首先,由于访问断断续续的失败,一些检查成功,而客户却继续看到出错,使得恢复更加难以确认. 第二,我们的监测显示,在网络服务上的峰值负载比目前负载更明显,这使得实时判断负载是否仍然被提升更加困难. □** 减轻和补救** 我们发现,处理美国邮件的网络服务在流量激增期间已达到了固定容量限制,在活动期间其容量无法增加. 我们的小组监测了受影响的系统,而提高的邮件量则减弱,网络服务负荷恢复正常。 邮件处理随后被恢复,并排队处理邮件. 由于这个问题以前似乎在反复出现之前有所改进,我们在若干方面证实在解决事件之前已经恢复。 我们确认,“保护”正在正常地装入,测试信息正在通过美国邮件处理发送,支持请求正在正常地进行。 我们还在一夜之间进行监测,没有从客户那里收到关于美国事件的新报告。 □** 客户影响** 一些客户对"保护"的访问缓慢或间歇性,偶尔在加载页面或高级选项时会看到出错. 美国的邮件处理因保护和预防而被推迟。 在某些情况下,信息被延迟,或者在预期时没有出现在节制收件箱中. 邮递经过美国邮件处理时, 大多数使用加码的保护客户不受邮件处理延迟的影响. 保护和预防控制台仍然可用,尽管一些控制台行动受到邮件处理缓慢的影响。 □ ** 预防措施** 为了防止今后出现这类问题,我们正在改进对电子邮件量异常增加的监测. 我们还在改进我们的监测,以显示我们网络服务的当前负荷,而不仅仅是最高值. 此外,我们正在评估如何在交通突起时更动态地扩大我们的网络能力,并评估处理美国邮件处理的网络基础设施的长期改进。 自此之后,我们又针对[后一事件](https://status.nowbe4.com/incidents/9wc6rjm8g70v)提高了美国网络服务的能力.
自动翻译自官方事件更新。
我们收到了用户在试图登录时收到"Access Delied"错误消息的报告. 我们已查明这一问题,并正在努力执行解决办法,并将在获得更多信息后更新这一页.
这一问题已经确定,一个解决办法已经落实,并将在我们得到更多信息后更新这一页.
这一事件已经得到圆满解决,所有系统都已全面运作.
自动翻译自官方事件更新。
我们收到报告称,一些用户无法成功提交网络表格提交材料。 我们正在调查这一问题,并将在获得更多信息后更新这一页.
这一问题已经确定,一个解决办法已经落实。 随后还将提供更多资料.
这一问题已经确定,一个解决办法已经落实,并将在我们得到更多信息后更新这一页.
这一事件已经得到圆满解决,所有系统都已全面运作.
2026年9月23日星期三,大约从08:15到11:18\(UTC\),一些顾客在英国的"安全Webforms"(security Webforms)中经历了缓慢和失败的表格提交. 这一问题是联合王国生产环境最近发生变化后数据库性能受限造成的。 数据库设置也导致一些查询运行效率低下. 因此,答复时间增加,一些表格提交失败。 为了解决这个问题,我们的团队暂时暂停了一个背景同步任务以减少负载,调整了数据库设置以提高查询效率,并增加了存储吞吐量. 安全Webforms以11:18\(UTC\)恢复了正常性能. 为了防止今后出现此类问题,我们增加了数据库带宽监测。 我们还在提高背景同步任务的效率。 这个问题没有造成数据损失.
自动翻译自官方事件更新。
我们收到消息称用户无法通过英国地区的Web Access(Secure Message Portal)发送邮件, 我们正在调查这一问题,并将在获得更多信息后更新这一页.
我们执行了一个固定方案.
我们正在继续监测任何其他问题.
这一事件已经得到圆满解决,所有系统都已全面运作.
2026年9月21日星期一,大约从08:55起至2026年9月22日星期二,大约是2.30\(UTC\),一些用户遭遇了错误,无法通过英国地区的Web Access\(Secure Message Portal\)发送邮件. 这一事件由数据库更新过程中的配置出错所引起,导致服务间歇性中断. 为了解决这个问题,我们恢复了配置,Web Access于2026年9月22日以 2.30\(UTC\)恢复了正常运行. 为了防止今后出现此类问题,我们正在审查和更新我们的数据库配置。 这个问题没有造成数据损失.
自动翻译自官方事件更新。
我们收到的报告称,用户无法登录DE和联合王国的KSAT。 我们正在调查这一问题,并将在获得更多信息后更新这一页.
这一事件已经得到解决.
□ ** 摘要** 2026年9月17日,一份背景工作将一个大用户组存档,并作为单一的无限制数据库交易运行. 这次交易将大量用户行锁定,导致美国地区登录超时,因为他们会写到同一个表格. 在打入了平台执行限制后,该工作被终止,并在15分钟的间隔内自动重试了5次,导致75分钟出局. 为了解决这个问题,我们安装了一个固定装置,将登录器从锁上解开。 然后,我们为登录变更带来的倒退以及档案工作采取了后续措施。 # # 发生的事情 # 先前的更改将"所有用户存档"动作从同步的,超时的网络请求移动到无限制的背景工作. 当一个大型用户组被存档时,这引发了新的背景任务. 任务将所有受影响的用户行锁定在一个单项交易中,在承诺前执行每个用户的写作和同步的外部服务呼叫. 登录尝试, 写到同一个表格, 被排到锁定的任务后面, 并且为美国用户超时 。 当任务达到15分钟平台执行限制时,终止了中交,交易回滚,任务被重新交付到队列. 这一循环发生5次,导致75分钟出站. 当内部22:35\(UTC\)发现故障时,宣布出事,并呼救一名工程师回应. 从登录流中解开写动作的缓解被部署在大约23:44\(UTC\). 缓解本身造成了回归:任何区域的任何用户如果先前错误地打入了密码,就不能再登录,因为重新发送失败的登录尝试试图写入只读数据库. 至2026年9月18日09:17\(UTC\),这一回归的修补被跨区域部署. 13:45和14:05\(UTC\)之间, 事件于2026年9月18日以19:12\(UTC\)完全解决. □** 轮回原因** 一个对大组用户档案进行无限制的单笔交易背景工作,在许多受影响的行上独有锁,阻断了登录进程自己的行写. 先前为了将这一操作从网络请求超时移出并进入背景工作而作的更改,取消了对其持续时间的唯一剩余限制. 该站台的15分钟执行限后触发了自动杀和再交付周期,5次重复了锁相争论并导致75分钟出站窗口. □ ** 发现和减轻** 我们发现,未封存的档案交易锁定了大量受影响的用户行,屏蔽了其他表格的写作. 短期内,通过将登录过程的书写依赖性与受影响的表格脱钩而缓解了这种情况,然后通过纠正存档工作而长期固定下来. 我们还发现,不协调的工人货币加剧了锁的争论。 短期内,通过人工减少工人的货币来缓解这种情况。 对这些工作进行错开和序列化的长期固定是计划好的. 最后,我们发现,登录后缀回归导致先前尝试失败的用户全区域登录失败,因为写作被只读数据库拒绝. 这一点是通过在所有区域部署和核实的有针对性的代码修改加以固定的。 □ ** 预防措施** 我们正改善我们大集团的档案业务, 也为特定背景工作者增加更改检查, 最后,除了定期的间接检查之外,我们还要增加数据库交易时间和清理延误的直接警报。 □** 客户影响和回收** 登录失败在美国地区持续了约75分钟. 第二天早上发生了两起仅限美国的短暂事件,几分钟内人工清除。 用户管理等一些管理行动也受到了影响。 合作伙伴登录未受影响。 二次回归持续了10小时左右,影响到了以前未能成功登录的用户的所有地区. 到9月18日下午,各地区均确认全面恢复,状态页被标为已解决. 这个问题没有造成数据损失。 □ ** 结束** 单一无限制的背景交易,加上自动重试机制,导致美国地区的登录中断. 特定触发任务及其再试行为已经固定,登录不再依赖于争辩的写入路径. 同一事件回归和两起轻微的再起在数小时内得到解决。 上文跟踪了其余的预防工作,包括工人协调和数据库交易监测.
自动翻译自官方事件更新。
我们收到报告说,用户无法登录美国KSAT的例子。 我们正在调查这一问题,并将在获得更多信息后更新这一页.
我们执行了一个定律, 我们正在监测结果.
我们收到新报告,用户无法登录美国KSAT的例子。 我们正在调查这一问题,并将在获得更多信息后更新这一页.
这一事件已经得到解决.
□ ** 摘要** 2026年9月17日,一份背景工作将一个大用户组存档,并作为单一的无限制数据库交易运行. 这次交易将大量用户行锁定,导致美国地区登录超时,因为他们会写到同一个表格. 在打入了平台执行限制后,该工作被终止,并在15分钟的间隔内自动重试了5次,导致75分钟出局. 为了解决这个问题,我们安装了一个固定装置,将登录器从锁上解开。 然后,我们为登录变更带来的倒退以及档案工作采取了后续措施。 # # 发生的事情 # 先前的更改将"所有用户存档"动作从同步的,超时的网络请求移动到无限制的背景工作. 当一个大型用户组被存档时,这引发了新的背景任务. 任务将所有受影响的用户行锁定在一个单项交易中,在承诺前执行每个用户的写作和同步的外部服务呼叫. 登录尝试, 写到同一个表格, 被排到锁定的任务后面, 并且为美国用户超时 。 当任务达到15分钟平台执行限制时,终止了中交,交易回滚,任务被重新交付到队列. 这一循环发生5次,导致75分钟出站. 当内部22:35\(UTC\)发现故障时,宣布出事,并呼救一名工程师回应. 从登录流中解开写动作的缓解被部署在大约23:44\(UTC\). 缓解本身造成了回归:任何区域的任何用户如果先前错误地打入了密码,就不能再登录,因为重新发送失败的登录尝试试图写入只读数据库. 至2026年9月18日09:17\(UTC\),这一回归的修补被跨区域部署. 13:45和14:05\(UTC\)之间, 事件于2026年9月18日以19:12\(UTC\)完全解决. □** 轮回原因** 一个对大组用户档案进行无限制的单笔交易背景工作,在许多受影响的行上独有锁,阻断了登录进程自己的行写. 先前为了将这一操作从网络请求超时移出并进入背景工作而作的更改,取消了对其持续时间的唯一剩余限制. 该站台的15分钟执行限后触发了自动杀和再交付周期,5次重复了锁相争论并导致75分钟出站窗口. □ ** 发现和减轻** 我们发现,未封存的档案交易锁定了大量受影响的用户行,屏蔽了其他表格的写作. 短期内,通过将登录过程的书写依赖性与受影响的表格脱钩而缓解了这种情况,然后通过纠正存档工作而长期固定下来. 我们还发现,不协调的工人货币加剧了锁的争论。 短期内,通过人工减少工人的货币来缓解这种情况。 对这些工作进行错开和序列化的长期固定是计划好的. 最后,我们发现,登录后缀回归导致先前尝试失败的用户全区域登录失败,因为写作被只读数据库拒绝. 这一点是通过在所有区域部署和核实的有针对性的代码修改加以固定的。 □ ** 预防措施** 我们正改善我们大集团的档案业务, 也为特定背景工作者增加更改检查, 最后,除了定期的间接检查之外,我们还要增加数据库交易时间和清理延误的直接警报。 □** 客户影响和回收** 登录失败在美国地区持续了约75分钟. 第二天早上发生了两起仅限美国的短暂事件,几分钟内人工清除。 用户管理等一些管理行动也受到了影响。 合作伙伴登录未受影响。 二次回归持续了10小时左右,影响到了以前未能成功登录的用户的所有地区. 到9月18日下午,各地区均确认全面恢复,状态页被标为已解决. 这个问题没有造成数据损失。 □ ** 结束** 单一无限制的背景交易,加上自动重试机制,导致美国地区的登录中断. 特定触发任务及其再试行为已经固定,登录不再依赖于争辩的写入路径. 同一事件回归和两起轻微的再起在数小时内得到解决。 上文跟踪了其余的预防工作,包括工人协调和数据库交易监测.
自动翻译自官方事件更新。
我们发现了一个引起登入和访问的问题 以英国为例.
一项措施已经执行,我们正在监测结果.
这一事件已经得到解决.
自动翻译自官方事件更新。
在Septermber 8日,我们意识到,由于Defense的有害代码删除引擎与Classic Outlook的遗产Word渲染引擎进行例行的HTML库升级,输入的HTML电子邮件在Classic Outlook中部分或空白地完成. 网上的新展望和展望没有受到影响。 这纯粹是一个显示问题:没有电子邮件被延迟、丢失或损坏,威胁侦测工作仍然充分活跃。 工程还原了更新以恢复正常渲染. 如果在此窗口中暂时禁用有害代码去除,请重新启用,以确保完整的保护.
自动翻译自官方事件更新。
我们收到了关于送交电子邮件核查工作空间部的问题的报告。 我们正在调查这一问题,并将在获得更多信息后更新这一页.
我们收到报告说,微软公司已经缓解了提供电子邮件核查工作方济各基金的问题,我们正在监测结果.
这一事件已经得到解决.
自动翻译自官方事件更新。
我们已经查明了一个问题,即用户在处理中的信息方面可能遇到延误,我们的工程小组正在寻找一个解决办法.
我们的工程小组已经针对在PhishER中造成信息处理延误的问题实施了一个解决方案,我们正在监测结果.
我们的工程组已经针对这个在PhishER中造成消息处理延迟的问题实施了一个解决方案.
□ ** 摘要** 在2026年8月26日的例行部署中,一个基础设施管理框架出人意料地移除了主信息处理队列和持有无法处理的消息的次要队列. 这导致进入PhishER客户收件箱的电子邮件发送暂时中断。 这个问题没有造成数据损失。 □** 轮回原因** 2026年8月24日,一次内部配置的改变使得直播配置记录与我们的代码不同步. 后来更新的代码没有恢复这些记录。 当2026年8月26日进行例行出品部署时,活性配置代码没有包含迁移后的资源记录. 因此,部署将活动队列视为未经管理的资源并移除. □** 减轻和补救** 自动监控提醒我们信息处理的下降,并组建了一个事件应对小组. 我们发现队列已被删除。 短期内通过重新运行受影响的生产工作来再造缺失的队列来缓解了这种情况. 然后,我们核实实时电子邮件处理工作已经恢复。 最后,我们重放在云存储中的邮件有效载荷 在外出期间,我们重放到客户的收件箱。 □** 时间线** 所有时间都在协调世界时. * ** 2026年8月24日,18:41:** 内部配置更改后将更新后的资源记录写入了直播制作配置. * 2026年8月26日,15:15:** 制作部署移除了存储无法在制作中处理的信件的输入队列和队列,停止了电子邮件发送到客户的收件箱. * 2026年8月26日,15:59:** 我们的自动监控提醒工程组注意正在处理的零信息,一个事件反应小组被呼叫. * 2026年8月26日,16:01:** 我们确认队列已被删除,并核实收到的电子邮件有效载荷仍然安全储存。 * 2026年8月26日,16:15:** 我们确定配置不匹配是主要根源。 * ** 2026年8月26日,16:25:** 我们的团队重新调整了 受影响的生产工作, 和队列被重建。 * ** 2026年8月26日,18:44:** 我们的自动重播完成了将所有备份的邮件传送给客户的收件箱. □ ** 预防措施** 为了防止今后出现这类问题,我们从前置检查中取消了活配置步骤,从生产变更中分离部署规划. 我们还增加了自动检查 以确认排队状态 □** 客户影响** 2026年8月26日从15:15到16:25\(UTC\),提交给PhishER的来信邮件没有被处理入客户收件箱. 在整个干扰期间,进入的电子邮件有效载荷被安全地储存在云层中。 在队列被恢复后,一个自动回放交付给客户收件箱的电子邮件。 所有已备份的信息都是由18:44\(UTC\)发送. 这个问题没有丢失客户电子邮件数据.
自动翻译自官方事件更新。
我们收到报告称,Gmail Phish警报按钮显示错误 "[报告PhishAttrep ()] 发生了内部错误 。 请再次尝试" 当报告phish。 我们正在调查这一问题,并将在获得更多信息后更新这一页.
这一问题已经确定,一个解决办法正在实施之中.
一项措施已经执行,我们正在监测结果.
这一事件已经得到解决.
2026年8月21日星期五,从大约05:20到12:55\(UTC\fs90\bord1\shad1\1cHF0F0F0}),一些顾客在使用Gmail Phish Alert Button 添加来报告可疑邮件时遭遇间歇性故障,收到"内部出错已经发生"消息而不是成功报告确认. 这一问题影响到了所有区域的客户,最大的误差集中在欧盟西部和美国东部服务地区。 这个问题由Google的Apps Script平台的缓存服务中断而来,添加者依赖它存储每个用户的会话配置. 服务开始间歇地返回读取的空出结果,同时仍然接受新写作,导致受影响的报告提交失败. KnowBe4直接接触了Google,并在大约12:19到12:39\(UTC\)之间提交了一份正式的bug报告. 出错量在供应商侧条件解除后不久急剧下降,而Gmail Phish Alert按钮则以约12:55\(UTC\)恢复了正常性能. 为了防止今后出现此类问题,我们正在继续与Google合作,追踪潜伏缺陷的解决情况。 这个问题没有造成数据损失.
自动翻译自官方事件更新。
我们正在调查一个问题,在通过 Phish 提醒按钮报告消息时, 导致不交付报告被退回, 在账户设置中启用“ 发送我们一份副本”
一项措施已经执行,我们正在监测结果.
这一事件已经得到解决.
2026年8月18日星期二,大约从14:10到14:55\(UTC\),使用 Phish 提醒按钮的客户使用 **Send Us a Copy** 功能,为 **Send Us a Copy** mailbox收到未发送报告. 这个问题是由共享电子邮件路由基础设施的配置变化所引发的. 这一变化将我们中转和生产环境所使用的讯息部分重新命名。 由于制作规则依赖于这个共享组件,重命名导致**Send Us a Copy**邮箱交付失败并引发了未交付报告. 为了解决这个问题,我们团队更新了受影响的配置,以引用正确的组件,**Send Us的一个Copy**功能在14:55\(UTC\)恢复到正常性能. 为了防止今后出现这类问题,我们正在将我们的集成和生产环境的电子邮件路由配置分开。 我们还在将遗留的配置与我们目前的基础设施管理标准相协调。 这个问题没有造成数据损失.
自动翻译自官方事件更新。
We are currently investigating an issue affecting Google PhishRIP queries, which may cause them to fail.
Based on our investigation into the recent errors affecting Google PhishRIP queries, it appears these may be related to suspended Gmail accounts. We are continuing to monitor the issue.
Upon further investigation we have determined that the errors affecting Google PhishRIP queries were related to individual issues on Google accounts.
我们发现一个问题 阻止账户设置 装入SAT控制台.
一项措施已经执行,我们正在监测结果.
这一事件已经得到解决.
2026年8月4日,星期二,大约从18:22到19:43\(UTC\),一些客户在KnowBe4控制台的**账户设置**页面上装入CA、DE、欧盟、英国和美国各地区的问题。 这个问题是由一系列应用程序的更改引起的,这些更改增加了账户设置经验中使用的GraphQL请求的复杂性. 每次更改在单独评价时都低于平台所配置的复杂性阈值,但综合起来,请求超过了该阈值并阻止了页面加载. 工程将复杂性阈值确定为促成因素,并进行了从19:14\(UTC\)开始的纠正性改变。 在全灾区校正后,KnowBe4控制台在大约19:43\(UTC\)恢复了正常运行. 为了防止今后出现这一问题,我们提高了复杂性门槛。 这个问题没有造成数据损失.
自动翻译自官方事件更新。
我们正在调查一个 有关电子邮件被 PhishRIP 意外隔离的问题
这一问题已经解决,PhishRIP的查询不再出乎意料地对信息进行断层处理。 我们还在调查可能受到影响的询问
这一事件已经得到解决.
□ ** 摘要** 2026年7月28日,PhishRIP服务的更新使得一些PhishRIP的搜索查询比他们本该有的要广泛. 不符合指定发送标准的电子邮件被隔离到一些客户账户中. 自动监测和客户支持票迅速浮出水面。 工程公司在宣布事件发生后约25分钟内恢复了这一变化,并停止了意外的采石. 然后,工程将错误的隔离邮件恢复到客户的收件箱。 □** 旋转原因** 2026年7月28日,我们向PhishRIP背后的查询服务部署更新维护. 这一更新旨在改进对无效发件人地址的处理,允许系统倒回只搜索地址的域部分. 然而,现有的验证逻辑使用一个正则表达式,需要发送字段中的"@"符号. 当一个查询使用一个空域,如[example.com](http://example.com)没有用户名或"@"符号时,regex标记域为无效. 现有验证与域搜索更新之间的这种冲突导致系统完全放弃了发送者标准. 查询与收件箱相对应,仅使用其剩余参数,在预定发送者以外的邮件进行匹配和断开。 □** 时间线** 所有时间都在协调世界时. 时间 时间 时间 时间 | -- -- -- -- -- -- -- 19:36 我们的自动监控检测出异常的查询执行模式,并通知了我们的工程师,他们立即开始调查. | QQ 19:51 QQ 问题升级为高发量出产事件,组建了反应小组. | 19:52 我们的支援团队升级了第一批举报出乎意料的检疫的顾客入场券,证实了监测警报. 19:54 原因来源于最近一个查询 API的部署,工程开始恢复变化。 事件通讯被张贴到我们的状态页面, 20:16 部署完全恢复。 QQ20:35 生产检查证实,主体和域名查询再次只匹配预定目标,不再有信息被隔离出错. 我们的情况网页也相应更新。 | 20:39 工程开始恢复错误的隔离邮件. \ 03: 49\ (下天\ )\ \ 完成所有客户查询集的恢复, 通过我们的支援团队登录 。\ \ \ \ □ ** 缓解和补救** ** 恢复守则。 ** 我们权衡了停止PhishRIP在中途的行动 与恢复代码。 停止背景任务会打乱每个租户的合法安全工作流程,因此恢复工作是更好的选择。 在升级后约40分钟内就已部署并核查了密码。 ** 电子邮件修复。 ** 为了避免真正恶意的电子邮件回到客户环境中,我们手动恢复而不是批量恢复. Engineering使用内部管理员工具分批恢复电子邮件,并和Support合作验证每个账户ID,查询ID,并首先获得客户批准. 所有报告账户一夜之间都恢复了。 □ ** 预防措施** * ** 衰退覆盖率**: 我们正在增加单域、非标准、光线发送查询的单元和集成测试,以便在部署之前抓住这些输入案例。 * 护栏**: 我们正在查询引擎中添加一个检查, 如果其核心过滤参数在评估中被丢弃, 则会阻止查询运行 。 □ ** 结束** 一个单一的验证规则导致了这种情况:一个假定每个发件人字段都包含有QQ的regex. 当查询使用空域时,该假设放弃了发送过滤器,查询匹配的邮件远远超过预期. 一旦我们找到它,修复是直截了当的,而修复工作在宣布事件发生后约25分钟内就停止了破坏. 恢复隔离邮件是一个更困难的过程:我们无法在不冒真正恶意邮件返回收件箱的风险的情况下恢复邮件的批量. 我们的小组选择在整个夜晚中谨慎行事,按支助帐户进行工作。 两项预防措施更早会发现这一点:一项测试只涵盖域域发送者查询,另一项是当发送者过滤器被剥去时拒绝运行查询的护栏. 两者现在都计划好了。 眼前的问题已经解决,所有已上报的账目都已恢复。 □** 荣耀** * ** PhishRIP:** PhishER功能让管理员搜索并隔离一个组织中每个用户的收件箱的接字邮件. * ** Regex\(正则表达式):** 软件中用于搜索文本并验证输入的图案,例如检查电子邮件地址格式是否正确. * ** 代码还原:** 后出软件更新以返回到之前的稳定版本.
自动翻译自官方事件更新。
我们正在调查用户无法在商店购买保护许可证。 我们得到更多信息后将更新这一页.
我们执行了一个定律, 我们正在监测结果.
我们收到报告说,顾客无法在商店购买保护许可证。 我们正在调查这一问题,并将在获得更多信息后更新这一页.
并监测结果以确保不再发生更多问题.
我们正在继续监测在线商店的修复措施,以确保不再出现问题.
这一事件已经得到解决.
自动翻译自官方事件更新。