SRE&Devops 每周分享 Issue #5
这个周工作比较忙，分享的东西不多。 The headers we don’t want 介绍了几类被误用和滥用的 Header。有些不错的干货的，让我惊讶的是很明显用错 Header 的网站竟然有这么多，还长达 20 多年。不过有些观点我不同意本文，比如 Response 放上 Server，我觉得是有用的，比如对互联网上的统计，测试收集各种服务器的性能等。 Getting started...
View ArticleSRE&Devops 每周分享 Issue #6 Closing
Hi，这是这一系列的最后一篇内容，之后不会再每周提供定时发布。遇到有意思的文章我会分享在 Twitter 上，这种方式更加实时，也比较有互动性。这是我的 Twitter: laixintao 。以下是本期内容。 Ubuntu 发布的 《上云白皮书》 现在可选的云服务多种多样，公有云、私有云、混合云，还有不同的厂商提供了不同的服务，从 Bare mental Server 到 VPS...
View ArticleClik here to view.
连接池中的连接失效的几种处理方案
在分布式系统中，用连接池缓存住连接，来节省连接反复销毁和创建的成本，是一种很常见的做法。但是在高可用的分布式系统中，”切换”是一个非常普遍的操作，切换就会造成连接池失效的问题。 TCP 虽说是”有连接的”，但这个连接实际上是一个虚拟连接。客户端用一段内存保存连接的五元组(源端口，源IP，目的端口，目的IP，协议)，服务端也保存一个这样的五元组，双方就认为有这么一个连接了，可以通过这个连接收发。...
View Article谈谈预防故障的性价比
说到保障系统的稳定性上，从预防的层面上看，总是有无数的事情可以去做。我觉得人们经常陷入的一个误区是，总是假设系统的某些方面会出问题，然后想办法针对这些特定的问题去做预防，认为预防好了这些问题自己的系统就万无一失了。这就导致很多时间花费在穷举系统可能出现的错误上、针对特定的错误做预防措施上。...
View ArticleGitops 的一些实践经验
之前看过多很多讲 Gitops 概念的文章，今天终于看到一篇讲实践的（原文见这里），我觉得这篇文章很有参考价值，介绍了一些 gitops 实在会遇到的问题和工具，和大家分享一下。 1.只用一个 git 仓库 建议所有跟基础设施有关的内容都放到一个仓库，包括有的团队、所有的项目。比如 kubernetes 的 template， infra as code 的平台，比如 terraform，比如...
View ArticleP99 是如何计算的
Latency （延迟）是我们在监控线上的组件运行情况的一个非常重要的指标，它可以告诉我们请求在多少时间内完成。监控 Latency 是一个很微妙的事情，比如，假如一分钟有 1亿次请求，你就有了 1亿个数字。如何从这些数字中反映出用户的真实体验呢？...
View ArticleClik here to view.
最近的工作感悟
我在 Shopee 维护一个 Service Mesh 系统，大部分的 RPC 调用要经过这个系统，这个系统每分钟要处理上千万的请求。我们在本文中就把它叫做 Oitsi 系统吧，方便描述一些。干的事情其实和 Istio 是差不多的。 Oitsi 将对 RPC 调用设置了很多错误码，类似于 HTTP 协议的 404, 502 等等。Application 报出来的错误码在一个区间，Oitsi...
View ArticleClik here to view.
用 Nginx 在公网上搭建加密数据通道
最近在跨机房做一个部署，因为机房之间暂时没有专线，所以流量需要经过公网。对于经过公网的流量，我们一般需要做以下的安全措施： 只能允许已知的 IP 来访问； 流量需要加密； 第一项很简单，一般的防火墙，或者 Iptables 都可以做到。 对于加密的部分，最近做了一些实验和学习，这篇文章总结加密的实现方案，假设读者没有 TLS 方面的背景知识，会简单介绍原理和所有的代码解释。 TLS/SSL 的原理...
View ArticleClik here to view.
没来的请举手
我们需要在一个 VPC 网络环境中采集一些服务的 metrics，TSDB 存储在中心机房中，存储节点、中心节点和采集端的网络是不通的，要访问的话必须开通防火墙配置。网络架构大体如下： 直接从 central 去访问应用的 metrics 暴露端口采集数据，肯定不显示，这样的话要开通的防火墙太多了，也就失去了防火墙的意义。 怎么才能尽可能少的开通防火墙，又保证数据采集呢？ 最直观的方法是，直接用...
View ArticleSRE 线上操作指南
我们每天要进行大量的线上变更操作。怎么保证这些操作安全，不会导致故障，是我每天都在思考的问题。 这篇文章从工作经历总结一些原则和想法，希望能有帮助。 线上操作有几点基本的要求： 操作需要是可以灰度的 (Canary)：即能够在一小部分范围内生效，如果没有问题，可以继续操作更多的部分； 操作必须是可以验证和监控的：要知道自己操作的结果，是否符合预期；...
View Article
