1 个自动化脚本搞死公司，是碰瓷么？看后续调查结果

（给Python开发者加星标，提升Python技能）

原创：Python开发者（id：PythonCoder）

5 月 31 日，1 个法国程序员 Nicolas Beauvais 在推特上控诉 DigitalOcean 搞死他们公司 Raisup。

「Python开发者」之前推文《1 个 Python 自动化脚本引发的惨案！把公司搞死了》中已有详情，DigitalOcean 承诺后续将公布事件调查结果。

6 月 5 日，DO 的 CTO Barry Cooks 在官博发文，梳理了事件经过和调查结果。

「Python开发者」翻译并整理如下：

第 1 次被封

5 月 29 日，Raisup 账号第 1 次被封。Nicolas 给出的理由：「DO 认为那个 Python 自动化脚本可能是恶意程序」。

Barry 的解释：

DO 有 1 个自动化服务，用于监控加密货币挖矿行为，比如：虚拟机的 CPU 负载和创建虚拟机的行为。除了这些因素外，还考虑了一些账号级的因素（包括付款历史记录和当前运行速度与总付款的比较）。目的是最小化潜在的高 CPU 负载欺诈对其他客户的影响。

在对账号采取任何操作之前，会检查自动安全性，以避免对信誉良好而没有任何警告的客户采取操作。

不幸的是，在这种情况下，安全性不足以阻止自动化操作。此外，由于客户是赊账运行的，所以他们没有清晰的付款历史记录，这意味着没有触发一个主要的安全性(付款历史)。自动化服务代表客户创建一个支持 ticket，以便就操作进行快速通信。

悲催的是，

• Nicolas 在多个虚拟机上并行启动了他的 Python 自动化脚本高，导致 CPU 高负载；

• Nicolas 是赊账（on credit），没有清晰的付款历史记录。

这 2 个因素触发了第 1 次封禁。

第 1 次解封

Nicolas 回应了 DO 发出了 ticket 后，经过多次沟通。

DO 的一位滥用操作（Abuse Operations）代理在 Raisup 宕机 12 小时后重新启用了他们的账号 。然而，这个代理同时还犯了一个错误，没有把 Raisup 的 CPU 高密集活动标记成「已批准」，这就给第 2 次封禁埋下了祸根。

第 2 次被封

上面已提到，因为 DO 代理的失误，没有把 Raisup 标记成「已批准」。而 Nicolas 在账号第 1 次解封后又搞了一回 CPU 高密集操作…… 

这又被另外一个滥用操作代理发现了（不是第一次封号的代理），于是 Raisup 账号又悲剧了，Nicolas 收到了拒绝解封的自动回复邮件。

最终解封

后来 Nicolas 持续在推特发帖，引起大量开发者围观，事件发酵后，引起 DO 官方和 CTO 的关注。

经过后续沟通，DO 最终解封 Raisup 的账号，重启了他们的虚拟机，并且标注了合适的安全标识，

DO 领导层出面道歉，Raisup 接受。Nicolas 可以继续愉快地在葡萄牙度假了。

DO 未来的改进

Barry Cooks 表示，这是一起跨技术、人员、流程引发的事故。

技术

• 旨在防止欺诈和滥用算法对健康、非滥用的客户采取自动操作的安全措施，但这那些对于没有支付历史记录的客户来说，是不够的。

流程

• 对客户的响应时间框架是 12 小时，然后是 29 小时，因为后续锁的响应时间太长了。

  
  

• 从 ticket 管理的角度来看，对帐户被锁的响应的优先级设置低了。

  
  

• DO 第一次在推特上的回应没有认识到已经造成的潜在危害，也没有对客户的情况表示同情。

  
  

• 帐户被封后的自动回复邮件，没有解释原因，行文给客户造成一种无助感，需要纠正。

人员

• 没有遵循添加「Allow High Cpu Usage」标志的过程。

• 对报告的假阳性作出判断的准则并不明确，结果导致拒绝访问。

要改进的，就是上面这些出问题的地方，Barry 还在文中提到，为了防止再次出现类似情况，以后封锁客户账号，会改成两个代理一起审核。

详细改进，见：

https://blog.digitalocean.com/an-update-on-last-weeks-customer-shutdown-incident/

在之前推文评论中说 Nicolas 是碰瓷的童鞋，看完这个后续，你还坚持碰瓷说法么？

推荐阅读

（点击标题可跳转阅读）

我用 Python 和 Twilio 实现自动化选课

ShutIt：一个基于 Python 的 shell 自动化框架

觉得本文对你有帮助？请分享给更多人

关注「Python开发者」加星标，提升Python技能

好文章，我在看❤️