查看原文

本文倡导了一种学习方法：DIY！对应汉语：知其然，知其所以然。使用 Linux 多戳戳看系统怎么运行的，出了问题去底层看看怎么修复，云实例出问题删了重建对职业生涯没啥帮助。建议可以自己鼓捣鼓捣 Linux 桌面，树莓派，从 DHCP, DNS，mailserver, webserver 开始一个一个搭建

查看原文

本文介绍了最近 IETF 标准的一项议案 DNS over HTTPS (DoH)，并探讨了为什么不选用 DNS over TCP。首先DoH 和 DoT 二者有很多是一样的，甚至 HTTPS 基本都是基于 TCP 的。人们寄希望于 HTTPS 可以修复 DNS 劫持的问题，通过 HTTPS 也可以引入更好地 纠错，Congestion 控制。现有大部分互联网设施对 HTTP 几乎都支持地非常友好。HTTP/2 到 QUIC 的升级，可以让 DoH 不用再去做标准化。好处多多，对于 HTTP 和 DNS 协议二者可能都是互利互惠的事情。有人甚至在考虑集成 …

查看原文

本文讨论了 Linux 替换掉 Unix 标准的一套网络管理工具 netstat, ifconfig，使用新的工具例如 ss, ip 套件。

• Linux ss ip 这套工具使用 netlink sockets，比较高效. netstat, ifconfig 这套工具的缺点在于性能低，要从 /proc 中读取很多文件，而要改写底层估计很难，技术上倒是可以做到但是更多是个 political 问题。
• 另外一个问题是 ifconfig 的输出其实已经和现在的网络架构蛮不一样了，有些信息都不够全。要修输出格式，估计很多脚本都会坏掉。
• 既然升级成本太高，切到新工具也是个不错的办法。

查看原文

本文介绍了如何在服务响应时间偏高后快速定位问题，解决方案是做 service tracing。监控除了采集应用的 latency，也采集依赖服务的调用或者方法的 latency，面板上可以在应用 latency 偏高后转而查看具体依赖的 latency distribution heatmap，如果能定位到具体的机器或者进程就更好了，可以转到具体的机器去排查 utilization 和内存什么的。从方法上来说，就是有办法 drilldown 到具体的病灶，链条不能断。

查看原文

Calendar Versioning 是一种基于日历日期的软件发新版打版本号的方法。软件会随着时间越来越好，这种发版方法简称 CalVer，一般使用 Gregorian calendar。例如 Ubuntu，Twisted, youtube_dl, pytz 等不少软件使用这种方法抬版本号。使用 CalVer 的场景可以是项目非常大，或者是 time-sensitive 的项目。

查看原文

本文讨论了Debuggable code 的好处。

• Debuggable code 可能和 clean code 相违背
• Robust software 有一个特性：能在任何有问题不晓得怎么处理的地方崩溃，又能从上次崩溃的地方恢复执行。时不时做些 check，过不了的地方直接崩溃，而不是简单认为“这不可能发生”，这样会省下很多debug的时间。
• Debuggable code: 总是在运行前做些检查。
• 比起运行的快的系统，不如慢一些，但是容易 debug

查看原文

本文是一篇 Google 的论文的学习笔记，论文讲的是 Google 如何给像 Gmail 这样的 user-facing 服务做性能分析和性能数据收集。

• 要想分析生产环境的性能，只能上生产环境去收集，不能在实验环境里面收集。生产环境的数据实在是太难预测了。
• Google 使用的技术有两种：
  • coordinated bursty tracing：所谓的 bursty 是指同一时间点，所有程序同时开启 tracing 几毫秒，然后同时关闭 tracing 一会儿，如此往复。
  • vertical context injection：比较复杂，大约是整个系统各个层上的所有软件都直接触发 syscall，通过一些无副作用的 syscall 序列把需要的信息丢进 kernal traces。// 有点黑科技。。

查看原文

本文是一篇实验报告，在 GCE 上删掉 iptable 规则后，路由到那台节点的请求会怎么样呢？

• 理解的前提是：
  • kube-proxy 运行在每台节点上
  • kube-proxy 需要查询 master 才能知道每个节点能处理哪些 application 的请求。
  • 就算请求到了节点，而应用不在这个节点上，kube-proxy 也能将请求导到临近可用的节点上。
  • kube-proxy 负责管理 iptable 规则
• 当你删除了某个节点上的 iptable 的一条规则，请求会卡住大约 30 秒，不 timeout 的话，最终会等到结果响应回去。
• 原理：有 pod add/delete 的时候 master node 就会重新计算 routing list.kube-proxy 会每隔 --iptables-sync-period （10-30s …

查看原文

有了 Kubernetes 编排的容器，服务，部署，Pod，Secret 等系统部件，debug 反而变得比单体应用难多了，因为这些部件太动态了。一般出了问题，除了删掉 Pod，碰碰运气能否自己解决。如果不能解决，目前比较简单地做法：快速加个代码，打个日志，重新部署。文中提到了一个方案：部署 Squash Daemonset 到 Host，可以做 debug。另外一个方案是打包镜像的时候就把 debugger 打进去，然后部署的时候把 debugger 的端口暴露到 node localhost。最后一个方案是 kubernetes --feature-gates=PodShareProcessNamespace=true 和 kubectl debug --image=<your-debugger-image> <your-application-pod>。

查看原文

这又是一篇比较 SRE 和 DevOps 的文章。SRE 要去定义什么算一个服务的可用指标，哪些可用的级别, 以及不可用时的预案。这些事情有对应的概念，SLI-指标，SLO-指标的目标，SLA-跟客户的约定目标。SRE 在定义出这些指标后，要去搜集监控信息，算出 uptime，进而算出各个指标。如果违背了 SLO，也就是 uptime 降低了，甚至烧光了预定的额度（error budget），那在恢复之前就别做特性开发了，把系统调稳了先。Toil 是指手动做运维的部分工作，SRE 的目标是尽可能将这部分工作降低。