查看原文

Chaos 意味着很多问题：事故又多糟糕，修好了么，日志什么样子，哪个客户受影响了，谁是相关的 oncall，等等等等。Google 为这类问题收集了几类数据用于分析，也写了一些工具生成 Postmortem 报告。这些数据主要包括：

• Timing Data：Start Time, Detection Time, End time, Escalation Time, Mitigation Time, 其中从 Hits Production 到 Detected 这段时间叫 TTD，从 Detected 到 Fully Resolved 这段时间叫 TTR，从 Hits Production 到 Fully Resolved 这段时间算作 Duration …

查看原文

IT 行业有不少带名字的架构方法论，例如 Hexagonal Architecture, Onion Architecture, Screaming Architecture, DCI, BCE；但纵使细节不同，总体是差不多的流程：相同的目标，不同的点拆开考虑，分层处理，层层相套，层中有商业逻辑，层间接口相通信。这些架构设计出来的系统也有相似的特征：独立运行，可测试，UI 方便调整，数据库可替换，外部依赖可替换，等等。

系统分层从里到外分别是业务逻辑，用例，控制层，外部接口层(UI, DB, Web, ...)。只能外层依赖内层，不能内层依赖外层。在代码里面，基本原则是外层代码里声明的东西，是不可以在内层代码里提及的，包括函数，类，变量，等等。类似的，外层使用的数据格式也不应该让内层使用。

Entities 封装了企业的 Business Rules …

查看原文

Postmortem 是旨在从发生的事故中汲取经验的流程，它一般是一种基于事故的分析和讨论。系统变得复杂后，故障无法避免，评估和补救也需要跟进，而这些需要花时间去分析数据。很多 Post-Mortem 报告非常耗时，要跟不同团队沟通，找出信息拼在一起得出结论。Post-mortem 的产出可以有很多形式：Learning Review, After-Action Review, Incident Review, Incident Report, Post-Incident Review, Root Cause Analysis (RCA).

一份好的 Post-mortem 报告需要讲好故事，因此它需要包括：

• 事件概览：什么服务/哪些客户收到了影响，Issue 有多久又多严重，谁在处理，以及到底最终怎么修复这个问题。
• Root Cause Analysis：故障的根源是什么？究竟为什么会发生？
• 处理措施：当时如何诊断/评估的？哪些诊断是有用的？哪些诊断是有害的 …

查看原文

本文是 Chicago 大学的人写的关于 Failure 的小论文。

• 复杂系统天生就是高风险的。
• 复杂系统设计上花了大量的功夫抵御故障。
• 灾难往往源于多点同时失效。
• 复杂系统总是潜伏着各种混合的故障
• 复杂系统可以被降级运行
• 灾难总是藏在角落。
• 事故后的分析其实没有一个 Root Cause，它肯定是多个地方同时失效连成串。
• 事后评估总觉得故障其实很容易避免，这种事后诸葛亮要不得。
• 人啊，即制造故障，也抵御故障。
• 程序员们都在赌事故不会发生（尽管时候看起来这些事故完全无法避免
• 系统模糊的一些边界行为只有在事故后才会被解决（这些模糊的地方其实本来就没人说清楚过
• 程序员们是复杂系统的一颗螺丝钉
• 复杂系统中的专家，过段时间就会需要另外一批（因为技术也在升级
• 变更会引入新的故障。
• 事后补救往往增加了系统复杂度，并引入了潜藏的风险。
• 安全必须是系统必须满足的特征，而非要去实现的组件。
• 人类会让系统越来越安全
• 不产生故障的操作往往需要有应对很多故障的经验

查看原文

发生多少次上下文切换非常取决于你所运行的程序。一般来说如果程序有很多系统调用（syscall），那么很有可能上下文切换的量会很高；如果大部分程序都只是空闲等待 socket，那上下文切换就会相对少一些。

系统调用是一定会造成 context switches 的，因为内核需要从用户态转到内核态，然后再回到用户态。另外，也有可能你的很多进程都在进行 CPU 密集运算，每个进程被分到的 CPU 时间分片都不够执行，也会造成上下文切换增加，这个比率 = processes/core。

查看原文

上下文切换也叫进程切换，或者任务切换，指的是 CPU 从一个进程或线程切换去执行另外一个。上下文切换只会发生在内核态中。上下文(context) 指的是 CPU 寄存器数据和 Program Counter。我们知道寄存器是 CPU 内部的可以超级快速存取数据的一个硬件，不过能存储的数据量很小。PC 则是一个特殊的寄存器，存储的是当前 CPU 运行到的具体指令序列的地址。发生上下文切换的时候，具体的行为有：

1. 进程执行 suspend, 上下文被暂时存在内存中
2. 从内存中取出下一个执行的进程的上下文，恢复到 CPU 寄存器上
3. 根据刚恢复的 PC 继续执行指令序列，即执行下一个进程。

上下文切换是操作系统实现多任务的基石。即使 CPU 只有单核，操作系统依然可以实现多任务，靠得就是切分 CPU 时间片，再加进程数据暂存和恢复。尽管有硬件级别的上下文切换，大多数现代操作系统提供的还是软件上下文切换，这样可以使操作系统运行在任何 CPU 上 …

查看原文

本文介绍了不少 Python 3 的好用的特性。

pathlib 的 / 操作可以避免 os.path.join 的调用：

>>> from pathlib import Path
>>> Path('/') / 'path' / 'to' / 'file'
PosixPath('/path/to/file')
>>> Path('/path/').glob('**/*.jpg') # 使用 glob 递归检测所有目录下的 jpg 图片

Type hinting 可以帮助检测参数类型传错。可以用 enforce 这个库强制在运行时检查类型注解。

可以用 astropy 这个库单位转换：frequency(speed=300_000 * u.km / u.s, wavelength …

查看原文

在 Unix 的早期，有个程序叫做 runcom，表示 run commands，缩写是 rc。这个程序，基本上就是早期的 sh，可以运行一个脚本里的一系列命令。不过后来大家就叫这个功能 shell，不叫它 runcom 了。现在 rc.d 指的是 runlevel, 不同的发行版功能不太一样，一般是运行操作系统的时候分别启动哪些组件。

查看原文

后缀 .d 意思是 directory, 也就是目录。虽然 Unix 并不需要目录的名字上带个 .d 表示 这是一个目录, 但不少软件会有用这种风格，例如 init: /etc/init.d。这个风格现在被很多程序采用，用于组合分散的配置。来自 Debian mailing list 中的一个解释：如果见到了 .d 风格，很可能是在说这是一个目录，里面有很多零散的小配置，最终会被合并成为一个服务的配置。

查看原文

Instagram 上线第一天服务器资源仅相当于一台 Macbook Pro，但要 Serve 25000 个用户已经很吃力了。好在 IT 行业素来有分享实践的传统，偷师学艺，没几天就迁移到 AWS 上，用云服务买来了发展的时间。

Virginia 暴风肆虐导致 AWS us-east 机房断电，他们有一半的实例没电了。由于基本功没做，网站没法迅速搞起来，结果花了整整 36 个小时重建整个 infrastructure。经过这个事故，他们痛定思痛，去掉了脆弱的 bash 部署脚本，用上了成熟的 chef，另外采用 WAL-E 和 Postgres WAL shipping replication，并把整个后端运行在异地数据中心。

并入 F 家以后做了一次数据大迁移，相当于 100mph 高速运行的跑车逐个更换零件 …