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技能
好文章，我在看❤️