在运维派前面文章中已经报道了 DigitalOcean宕机 的事故，今天将DigitalOcean的官方公告来了解整个事件的详细过程：
事件回顾
2017年4月5日，DigitalOcean的控制面板与API遭遇时长4小时56分钟的不可用状态。在此期间，全部运行中的Droplets仍继续正常运转，但用户无法创建或者管理额外的Droplets乃至其它资源。我们非常清楚客户对我们服务方案的高度依赖，而这样的服务中断显然是不能接受的。我们对这一状况深表歉意，并将承担全部相关责任。您对于我们的信任是我们最为重要的资产，因此我们希望在这里分享与此次事件相关的全部细节信息。
2017年4月5日上午10：24（美国东部时间，简称EDT），我们开始接收到公共服务不可用之相关警报。在发生初始警报的3分钟之内，我们发现主数据库已经遭到删除。4分钟之后，我们开始利用一套时间延迟型数据库副本开始执行恢复流程。在接下来的4个小时内，我们将数据复制并恢复至与主要与次要副本相一致的水平。在此次服务中断过程中，主要时间消耗被用于进行副本间数据复制并将其还原至活动服务器当中。
当日下午3：20（美国东部时间），主数据库已经得到完全恢复，且未丢失任何数据。
DigitalOcean简介
DigtialOcean是一家创立于2011年的美国云服务提供商，拥有遍布全球的数据中心。2015年12月，DigitalOcean成为了全球第二大面向Web的网络寄存服务公司。
据资料显示，DigitalOcean拥有超过3万家企业团队客户，如：Atlassian、Docker、Salesforce、惠普、红帽、爱立信等。
事件时间表
• T0.00 – 10:24 EDT – 首次发现问题。
• T0.03 – 10:27 EDT – 验证生产数据库是否已被删除。
• T0.10 – 10:34 EDT – 开始利用时间延迟副本进行数据恢复。
• T1.29 – 11:53 EDT – 时间延迟副本备份完成。
• T2.10 – 12:34 EDT – 将备份复制至主服务器之过程完成; 恢复流程正式开始。
• T3.07 – 13:31 EDT – 主服务器恢复完成; 继续将备份复制至各副本内。
• T4.56 – 15:20 EDT – 全部系统恢复完成。
未来措施
造成此次事件的根本原因在于一项工程师驱动之配置发生了错误。自动化测试执行流程中使用的生产凭证存在配置错误。着眼于未来，我们将大幅减少某些行为对于主要系统的访问，以确保不再出现类似情况。
如上所述，此次事件的持续时间主要受到我们网络速度的影响，即需要将数据重新加载至我们的数据库当中。虽然此类事件未来仍有可能再次发生，但我们正在致力于升级数据库服务器之间的网络连接，同时更新相关硬件以提高恢复速度。我们预计相关改进将在未来几个月之内陆续完成。
总结
我们希望与大家尽快分享相关信息，以便您能够尽早了解与此次服务中断相关的事件性质与影响。着眼于未来，我们将继续评估并实施可避免开发人员错误之各类保障性举措，努力改进以数据为核心的恢复流程，同时探索如何在未来可能对客户造成影响的事件中提供更理想的实时信息。我们高度关注自身服务的可靠性，并一直在努力提供一套可靠的平台供各位用户运行您的关键性任务应用。
DigitalOcean全体成员感谢您的理解，并再次就此次事件给您带来的不便表达诚挚歉意。
原文链接：https://www.digitalocean.com/company/blog/update-on-the-april-5th-2017-outage/
本文链接：https://www.yunweipai.com/13165.html
网友评论comments