FB、谷歌发布宕机事故报告；微软开源 Azure 数据压缩的算法、硬件和源码

(给技术最前线加星标，每天看技术热点)

转自：开源中国、solidot、cnBeta、腾讯科技、快科技等

【技术资讯】

0、Facebook 宕机事故系服务器配置问题导致

昨天 Facebook 及旗下产品 Instagram 和 WhatsApp 遭遇了严重的宕机事故，世界各地的 Facebook 用户都反馈称他们登录 Facebook、Instagram 和 WhatsApp 遇到一些问题，并且也无法发帖。

Facebook 发布消息承认了此次服务中断，虽然表示该事故与 DDoS 无关，但具体原因并未交待。

网络安全管理公司 Netscout 首席工程师 Roland Dobbins 认为此次宕机可能是一个 BGP 路由错误引起的，他表示：“BGP 路由从一家欧洲 ISP 偶然泄露到一家知名的中转 ISP，这家中转 ISP 随后将路由向上传送到一些对待节点或这家中转 ISP 的下游提供商，结果导致访问一些知名互联网公司的服务出现了短暂的异常。”

然而云监控公司 ThousandEyes 则认为这是由内部错误导致的，“因为 Facebook 返回了‘ 500 内部服务器错误码’”。

今天 Facebook 发推文正面回应了此次事故的原因，其表示正是因为服务器配置的改动而导致了此次宕机，并称目前问题已经解决，系统正在恢复。

值得一提的是，Facebook 此次宕机事故是知名宕机追踪网站 Downdectector 有史以来遇到的最严重的一次，Downdetector 的联合创始人 Tom Sanders 表示：“从持续时间来看，这是迄今为止我们在 Downdetector 于 2012 年推出以来所遭遇的最大一次宕机，我们的系统在此次事件中处理了来自最终用户的大约 750 万份问题报告。”

1、SRE 超载系统导致，谷歌发布宕机事故分析报告

谷歌发布了 12 日大面积服务中断事故的分析报告，指出系 SRE 超载系统使得 Google 云存储错误率提高导致。

12 日全球各地的许多用户反映使用 Gmail、YouTube、Google Drive、谷歌音乐与谷歌的其它服务时都遇到了问题，包括北美洲、南美洲、欧洲和亚洲的部分地区都受到影响，谷歌随后承认出现故障，谷歌云平台状态页面（Google Cloud Status Dashboard）显示，此次故障影响了谷歌云存储的所有区域。

当地时间 14 日，谷歌发布了针对该事件的分析报告。

谷歌表示内部 blob（大型数据对象）存储服务经历了 4 小时 10 分钟的服务中断。分析了根本原因，其指出在 3 月 11 日，Google SRE 被告警内部 blob 服务使用的元数据的存储资源显著增加；3 月 12 日，为了减少资源使用，SRE 进行了配置更改，其副作用是使系统的关键部分超载以查找 blob 数据的位置，而增加的负载最终导致级联故障。

更具体的，12 日 18:40 到 22:50，谷歌内部 blob 存储服务错误率提高，平均错误率为 20％，事件发生时错误率为 31％，用户可见的 Google 服务，包括使用 blob 存储服务的 Gmail、照片和 Google 云硬盘错误率也提高了，如果没有这些服务中内置的缓存和冗余机制极大地降低了用户影响，那么后果会更加严重。

此次事故中，重大的影响包括：Google 云存储的长尾延迟较高，平均错误率为 4.8％，所有存储桶位置和存储类都受到影响，依赖于云存储的 Google 云平台服务也受到影响；Stackdriver Monitoring 在检索历史时间序列数据时出现了高达 5％ 的错误率，最近的时间序列数据可用，警报没有受到影响。App Engine 的 Blobstore API 出现了较高的延迟和错误率，在获取 blob 数据时达到峰值 21％，App Engine 部署出现了高达 90％ 的错误，从 App Engine 提供静态文件也会出现错误率提升。

谷歌表示非 Google 云平台服务受到的影响将会有单独的事件报告。

对于因此事件受到影响的服务与应用客户，谷歌深表歉意，并表示正在采取措施以提高可用性并防止此类中断再次发生。

详情查看：

https://status.cloud.google.com/incident/storage/19002

2、微软开源用于 Azure 数据压缩的算法、硬件和源码

微软正在向 OCP（开源计算项目，Open Compute Project）发布 “Project Zipline” 数据压缩算法，以及相关的硬件规格和源码。

微软正在开源云压缩算法，并优化着云存储的硬件实现。微软将该算法命名为 “Project Zipline”，加上相关的硬件规范和源码发布到 OCP。

OCP 公布开放硬件设计，致力于省成本地构建数据中心。微软于 2014 年加入 OCP，是该组织交换机抽象接口（SAI）项目的创建者。目前，OCP 已经发布了主板、芯片组、电缆、通用插座、连接器和开放式网络和交换机的规范。

微软官方在一篇博文表示，“Project Zipline” 是针对各种数据集进行了优化的前沿压缩技术，发布的 RTL （寄存器传输语言，Register Transfer Language）允许硬件供应商使用参考设计来生产硬件芯片，以达到最高的压缩、最低的成本和算法功耗。

Zipline 压缩技术预计可以进入到各种市场，比如网络数据处理、智能固态硬盘、档案系统、云设备、通用微处理器和边缘设备等，微软希望 OCP 社区可以为该算法和规范做出贡献。

在此之前，微软发布并对加密微控制器标准 “Project Cerberus" 做了贡献。官方将 Cerberus 视为 Project Olympus 的下一阶段。微软的数据中心服务器设计为 Project Olympus 做着贡献，其 FV2 虚拟机系列在 Azure 中就部署了 Project Olympus 硬件。

据了解，“Project Zipline” 项目的发布是为了配合2019年开放计算项目全球峰会（The Open Compute Project Global Summit 2019）的启动。去年这个峰会，微软推出了标准化 SSD 固件接口的规范 “Project Denali”。

【业界资讯】

0、Linux 基金会宣布红队项目，致力于孵化开源安全工具

谁都想软件有着很高的安全性吧。毕竟，每一天都会有不一样的安全漏洞，从糟糕软件的沼泽中冒出来。

在近期举办的开源领导力峰会上，Linux 基金会宣布了新的红队项目（Red Team Project）。新项目将孵化出开源网络安全工具，帮助开源软件安全性的提高。

对于不在安全领域的人来说，红队可以模仿现实中攻击者追踪系统的方法，是一个公司测试安全软件的有效选择。而红队项目正是开源安全工具的孵化器，这些工具包括了网络攻防（cyber range）自动化、容器化渗透测试工具、二进制风险量化和标准验证程序。

这个项目并非凭空产生，而是基于 Fedora 红队特别兴趣小组。Jason Callaway，现在是谷歌客户工程师，在当时开启了 "Fedora 红队 SIG。红队项目有一些想要构建的漏洞映射工具，同时也想做出 Cyber-ITL 项目的开源实现。

这里提到的网络攻防（Cyber-range），是指模拟黑客攻击的虚拟空间，理论上是在云上进行的。一次网络攻防包括了易受攻击的机器镜像、易受攻击的应用配置，攻击平台，漏洞利用和操作者。用户可以部署黑客脚本，用代表着现实情况的红蓝队进行安全训练。通俗点说，就是用你的安全基础设施进行“战争游戏”。

开源 CTL （Cyber Test Lab）提供给了开源软件一个代码分析的方法。除了可以帮到开发者，终端用户也可以使用 CTL 帮助预防糟糕的二进制文件。

1、Chrome 提供可选搜索引擎 DuckDuckGo

可能是出于反垄断方面的考虑，搜索巨人在其最受欢迎的浏览器 Chrome 中将竞争对手、匿名搜索引擎 DuckDuckGo 加入到可选使用的搜索引擎名单中。这一变更随 Chrome 73 的推出提供给了用户，但不是所有地区的用户，只限于 60 多个国家和地区，其中不包括中国。DDG 创始人 Gabe Weinberg 对此表示欢迎。此前 Google 还将 Duck.com 域名转让给了 DuckDuckGo。

2、Linux 基金会成立持续交付基金会

在近日举办的开源领导力峰会（Open Source Leadership Summit）上，Linux 基金会宣布成立一个新的子基金会——持续交付基金会（Continuous Delivery Foundation，CDF）。

主页：https://cd.foundation

持续交付（CD）是一种软件工程方法，开发团队在短周期内完成软件，确保软件可以随时可靠地发布。与之密切相关的是“持续集成（CI）”，持续集成是一种软件开发实践，开发团队成员经常集成他们的工作，每次集成都通过自动化的构建（包括编译、发布与自动化测试）来验证，从而尽快发现集成错误。

随着微服务和云原生架构的广泛采用，对持续交付工具和实践的需求越来越大。然而 Linux 基金会开发人员关系副总裁 Chris Aniszczyk 却表示：“尽管多年来在采用持续集成方面我们取得了很多进展，但是持续交付带来的挑战已经被证明更为棘手。”

Linux 基金会在公告中表示，持续交付基金会将作为供应商中立平台，为重要的开源项目提供持续交付和规范，以加快发布管道流程。持续交付基金会将促进行业顶级开发人员、最终用户和供应商之间的协作，以传播 CI/CD 和 DevOps 方法、定义/文档最佳实践，提供指导并创建培训材料，使全球任何软件开发团队能够实施 CI/CD 最佳实践。

持续交付基金会的使命是维护并发展一个开放的持续交付生态，基金会的创始成员包括 Alauda、阿里巴巴、Anchore、Armory、Autodesk、Capital One、CircleCI、CloudBees、DeployHub、GitLab、Google、华为、JFrog、Netflix、Puppet、Red Hat、SAP 和 Snyk。

首批托管项目包括开源 CI/CD 系统 Jenkins、基于 Kubernetes 的开源 CI/CD 解决方案 Jenkins X 与开源多云 CD 解决方案 Spinnaker，以及 CI/CD 组件的开源项目与规范 Tekton。接下来将会成立技术监督委员会（Technical Oversight Committee，TOC），其关注点是聚合整个持续交付生态，以围绕可移植性和互操作性制定规范和项目，其它项目可以由此托管。

除了 Linux 基金会，CloudBees 和 Jenkins 社区，以及 Google 也一起领导了持续交付基金会的成立。

觉得这些资讯有帮助？请转发给更多人

关注 技术最前线 加星标，看 IT 要闻

喜欢就点一下「好看」呗~