Forwarded from yihong0618 和朋友们的频道 (伊)
Tall, Snarky Canadian
Why it took 4 years to get a lock files specification
(This is the blog post version of my keynote from EuroPython 2025 in Prague, Czechia.)
We now have a lock file format specification. That might not sound like a big deal, but for me it took 4 years of active work to get us that specification. Part education…
We now have a lock file format specification. That might not sound like a big deal, but for me it took 4 years of active work to get us that specification. Part education…
临江仙·夜归临皋
夜饮东坡醒复醉，归来仿佛三更。家童鼻息已雷鸣。敲门都不应，倚杖听江声。
长恨此身非我有，何时忘却营营。夜阑风静縠纹平。小舟从此逝，江海寄余生。
夜饮东坡醒复醉，归来仿佛三更。家童鼻息已雷鸣。敲门都不应，倚杖听江声。
长恨此身非我有，何时忘却营营。夜阑风静縠纹平。小舟从此逝，江海寄余生。
Forwarded from Manjusaka 的碎碎念（以及摇曳露营 S4 制作确定！）
简单复盘一下 AWS 这次事件作为一个 AIGC Startup SRE 的一些操作吧，希望能帮到大家
从入职开始发现我们主要的集群在 USE1 之后，我就开始做一些准备了。
我主要做的事情有这几件事
1. 将我们核心的几个数据库做了多地的备份，形成了 USE1，Tokyo，SG 三地备份。这样在极端情况下，我们损失一部分数据，但是也能保证服务的继续
2. 将我们 SG 的测试集群从原本的 EC2 自己简单搭的 K3S，重构为了一个标准的 AWS EKS 集群。这样可以在灾害时刻快速 warmup 一个集群，复用 AWS 已有组件。将 manifest 变更的代价降至最小
3. 简单梳理了一个 SOP，包含用户公告，DNS 切换，封版等事宜
回到今天，我大概在 AWS 事故发生后的10min，发现了我们容器中有新的 Pod 无法 setup。
在和 AWS 支持确认是 USE1 的问题后，我意识到 ECR 的事件必然关联其余事件，于是我就果断按照我自己规划的 Tier1 等级事件开始处理（对于 SRE 来说，这种事情宁可错，但是不能错过）
T+0 min，我发布了全员公告，开始进入紧急模式。我 setup 了一个全员公开会议。所有人员可以随时加入
T+2 min，我确认事件如我所预期的一样，在逐渐扩大，我发出了两个指令，1. 全线禁止任何代码合入/提交（主要是避免新创建资源会导致 Pod rotate 进而影响流量），2. 请运营同学准备公告
T+3 min, 我开始按照 SOP，开始进行数据库在 SG 区域的恢复，并且级联创建诸如 OpenSearch / Redis 等在内的依赖
T+5 min，我们开始正式的确认上下游依赖的具体问题，确认一个新上线的核心服务受到影响
T+10min，我们停服公告和其余服务的受影响公告发出
T+10min，我请另外两位同时协助 setup 新的 ECR 以及清理测试环境已有资源，并同步 CTO ，在极端情况下，我们可能会存在保体验，丢数据的决策。
T+15min， 我们最终确认目前已创建的资源以及流量入方向不会受到太大影响。切换方案挂起，但是我们继续准备相关资源
T+30min，我们第一个数据库恢复完毕
T+40min，我们第二个数据库恢复完毕
T+1h，我们所有关联的核心 infra，RDS/ES/Redis 都 stand by，并且按照生产架构设置主从等优化选项。同时我们也开始正在新的集群启动新的服务
所幸，最终 AWS 的 crash 没有影响我们全部服务。我们无须面对切换流量后复杂的数据修复工作
大概 T+2h 到 T+3h 后，我正式通报全员，紧急状态解除。为保险起见，今晚依旧对 feature 封版。
回顾整个事故，我还可以做的更多
1. 将我之前为自己准备的极端 case SOP，对全员公开。这样确保我即便不在线，也有人能接替我
2. 我们可以做一些提前的预先演练
3. 指令下达可以更果断一些
差不多就是这样，一点分享，希望能帮到大家
从入职开始发现我们主要的集群在 USE1 之后，我就开始做一些准备了。
我主要做的事情有这几件事
1. 将我们核心的几个数据库做了多地的备份，形成了 USE1，Tokyo，SG 三地备份。这样在极端情况下，我们损失一部分数据，但是也能保证服务的继续
2. 将我们 SG 的测试集群从原本的 EC2 自己简单搭的 K3S，重构为了一个标准的 AWS EKS 集群。这样可以在灾害时刻快速 warmup 一个集群，复用 AWS 已有组件。将 manifest 变更的代价降至最小
3. 简单梳理了一个 SOP，包含用户公告，DNS 切换，封版等事宜
回到今天，我大概在 AWS 事故发生后的10min，发现了我们容器中有新的 Pod 无法 setup。
在和 AWS 支持确认是 USE1 的问题后，我意识到 ECR 的事件必然关联其余事件，于是我就果断按照我自己规划的 Tier1 等级事件开始处理（对于 SRE 来说，这种事情宁可错，但是不能错过）
T+0 min，我发布了全员公告，开始进入紧急模式。我 setup 了一个全员公开会议。所有人员可以随时加入
T+2 min，我确认事件如我所预期的一样，在逐渐扩大，我发出了两个指令，1. 全线禁止任何代码合入/提交（主要是避免新创建资源会导致 Pod rotate 进而影响流量），2. 请运营同学准备公告
T+3 min, 我开始按照 SOP，开始进行数据库在 SG 区域的恢复，并且级联创建诸如 OpenSearch / Redis 等在内的依赖
T+5 min，我们开始正式的确认上下游依赖的具体问题，确认一个新上线的核心服务受到影响
T+10min，我们停服公告和其余服务的受影响公告发出
T+10min，我请另外两位同时协助 setup 新的 ECR 以及清理测试环境已有资源，并同步 CTO ，在极端情况下，我们可能会存在保体验，丢数据的决策。
T+15min， 我们最终确认目前已创建的资源以及流量入方向不会受到太大影响。切换方案挂起，但是我们继续准备相关资源
T+30min，我们第一个数据库恢复完毕
T+40min，我们第二个数据库恢复完毕
T+1h，我们所有关联的核心 infra，RDS/ES/Redis 都 stand by，并且按照生产架构设置主从等优化选项。同时我们也开始正在新的集群启动新的服务
所幸，最终 AWS 的 crash 没有影响我们全部服务。我们无须面对切换流量后复杂的数据修复工作
大概 T+2h 到 T+3h 后，我正式通报全员，紧急状态解除。为保险起见，今晚依旧对 feature 封版。
回顾整个事故，我还可以做的更多
1. 将我之前为自己准备的极端 case SOP，对全员公开。这样确保我即便不在线，也有人能接替我
2. 我们可以做一些提前的预先演练
3. 指令下达可以更果断一些
差不多就是这样，一点分享，希望能帮到大家
Frost's Notes
https://github.com/MoonshotAI/kimi-cli
uvx —from=kimi-cli kimi 启动
Frost's Notes
临江仙·夜归临皋 夜饮东坡醒复醉，归来仿佛三更。家童鼻息已雷鸣。敲门都不应，倚杖听江声。 长恨此身非我有，何时忘却营营。夜阑风静縠纹平。小舟从此逝，江海寄余生。
水龙吟·登建康赏心亭
楚天千里清秋，水随天去秋无际。遥岑远目，献愁供恨，玉簪螺髻。落日楼头，断鸿声里，江南游子。把吴钩看了，栏杆拍遍，无人会，登临意。
休说鲈鱼堪脍，尽西风，季鹰归未？求田问舍，怕应羞见，刘郎才气。可惜流年，忧愁风雨，树犹如此！倩何人唤取，红巾翠袖，揾英雄泪！
楚天千里清秋，水随天去秋无际。遥岑远目，献愁供恨，玉簪螺髻。落日楼头，断鸿声里，江南游子。把吴钩看了，栏杆拍遍，无人会，登临意。
休说鲈鱼堪脍，尽西风，季鹰归未？求田问舍，怕应羞见，刘郎才气。可惜流年，忧愁风雨，树犹如此！倩何人唤取，红巾翠袖，揾英雄泪！
Forwarded from yihong0618 和朋友们的频道 (伊)
如果对 debug 感兴趣，大家可以依次看我心目中最厉害的 debugger 的三个视频和一个播客，能学到非常多的东西：
1. Real World Debugging with eBPF
https://www.youtube.com/watch?v=nggZEwGLC-Q
2. eBPF for Python Troubleshooting
https://m.bilibili.com/video/BV1bJz9YTEGJ
3. gdb -p $(pidof python)
https://bilibili.com/video/BV121Wnz1ELm
4. 播客《和 Gray 聊聊那些年遇到的神奇 Bug》
https://pythonhunter.org/episodes/ep35
1. Real World Debugging with eBPF
https://www.youtube.com/watch?v=nggZEwGLC-Q
2. eBPF for Python Troubleshooting
https://m.bilibili.com/video/BV1bJz9YTEGJ
3. gdb -p $(pidof python)
https://bilibili.com/video/BV121Wnz1ELm
4. 播客《和 Gray 聊聊那些年遇到的神奇 Bug》
https://pythonhunter.org/episodes/ep35
YouTube
SREcon23 Asia/Pacific - Real World Debugging with eBPF
Real World Debugging with eBPF
Zhichuan Liang, Isovalent
In this talk, we'll explore the use of eBPF for debugging real-world production issues in a Golang environment. We'll cover the limitations of traditional debugging tools like gdb and delve, and dive…
Zhichuan Liang, Isovalent
In this talk, we'll explore the use of eBPF for debugging real-world production issues in a Golang environment. We'll cover the limitations of traditional debugging tools like gdb and delve, and dive…
❤1
#reading 读完收获不小：
1. 明清嬗代并不是大家以为的落后蛮族征服先进汉人王朝的故事。清朝无论在军事科技还是意识形态都领先明朝。明之亡当然有自身的因素，但有没可能单纯是打不过呢？毕竟菜是原罪。
2. 我理解了吴三桂其人和他背后的辽人军功集团，以及他为何明明先做了「汉奸」，却又在康熙时要复明。
3. 军事永远都是政治的延伸，甚至是经济的延伸，唯独不是纯粹的战争本身。
1. 明清嬗代并不是大家以为的落后蛮族征服先进汉人王朝的故事。清朝无论在军事科技还是意识形态都领先明朝。明之亡当然有自身的因素，但有没可能单纯是打不过呢？毕竟菜是原罪。
2. 我理解了吴三桂其人和他背后的辽人军功集团，以及他为何明明先做了「汉奸」，却又在康熙时要复明。
3. 军事永远都是政治的延伸，甚至是经济的延伸，唯独不是纯粹的战争本身。