SRE&Devops 每周分享 Issue #1 Opening

Hi, 我平时看到一些有趣的文章很喜欢分享给朋友(这也是我写博客的原因吧),现在订阅的内容也越来越多了,有些也实在看不过来(Pocket 都堆满了)。其中订阅了很多 newsletter,newsletter 并不是每一篇都对你的胃口,但是总有几篇不错的,所以我也打算将我的分享整理成这种形式。一方面,我的工作中很多方面还在摸索,另一方面,这样可以将我看过的东西整理下来。最重要是的希望这种方式可以遇到更多同行,大家可以互相交流。

关于形式,暂时我先发布在博客上,后面如果找到不错的 Newsletter 托管(欢迎大家推荐),可能迁移到邮件形式。我每周将想要分享的东西存成草稿,周五中午 1:00 定时发布。当前分那几个板块还没确定,写到哪算哪吧,后面根据需要来调整。

关于投稿,大家发到博客右侧的邮箱即可。

关于内容,暂时会以 URL + 我的推荐语、概括为准。内容我尽量推荐自己看过的,但是有些实在太长,我可能放到 Pocket 慢慢看,还没看完就推荐给大家也说不定。所以大家要带着自己的脑子来读这里推荐的东西,并不一定都是好的。大部分内容都来自 Hacker News,这是我主要的订阅源。

最后,这是一项个人工作,所以无法保证能更新多久也无法保证内容有多少,请见谅。以下是第一期内容。

Honeycomb’s Charity Majors: Go Ahead, Test in Production

“分布式系统天生就是不好克隆、模拟、staged的,所以放弃 Staging 吧。加入线上环境出现问题,有些用户访问图片很慢,有些正常,你能在 Staging 环境发现问题吗?”这是 Honeycomb 在 ChaosConf 2018 的一个演讲,很多人反对在 Production 环境中测试的原因是,他们认为这样会破坏真实用户的体验。但是有像 A/B 测试,金丝雀测试的存在,可以将影响控制在一定范围。

gRPC Load Balancing on Kubernetes without Tears

gRPC 是基于 HTTP/2 的,而 Kubernetes 的负载均衡是基于 TCP 连接的。而 gRPC over HTTP/2 只会建立一个 TCP 连接,所以这样负载均衡就会有问题,所有的请求都发到了一个节点上去。官方推荐使用 Linerd2 来做 gRPC 的负载均衡。

HTTP-over-QUIC to be renamed HTTP/3

HTTP over QUIC(Quick UDP Internet Connections) 被重命名为 HTTP/3,将不再使用 TCP。

Time Series Analysis with LSTM using Python’s Keras Library

这是一篇教程,使用 LSTM 对时间序列数据分析。类似股票走势之类。这对流量监控系统非常有用,普通的规则设定报警很容易出噪音,如果能够基于预测出的流量走势设定监控报警也许更准确一些。

The History of Unix, Rob Pike

上周的一个不错的视频,一位资深程序员 Rob Pike 怀念了 Unix 几十年的历史,和他的故事。

Incident Management in Gitlab

Gitlab 是一家很开放的公司,这是他们的事故管理策略。

Chaos Monkey Guide for Engineers – Tips, Tutorials, and Training

Chaos Monkey 教程,介绍了其理念,实践以及相关的阅读资料(制作很精美)。

How Automatic Root Cause Analysis Works

Instana 如何在复杂的系统中自动定位故障的根因。

Getafix: How Facebook tools learn to fix bugs automatically

我们可以自由的写 Bug 了,毕竟有机器人来修复。

October 21 post-incident analysis

Github 10月32日 故障分析。



SRE&Devops 每周分享 Issue #1 Opening”已经有2条评论

回复 Michael翔 取消回复

您的电子邮箱地址不会被公开。 必填项已用*标注