NadeshikoManju@薫る花は凛と咲く7月5日播出

统计数据

14
文章
0
粉丝
0
获赞
87
阅读
avatar
估计很多人在等我的技术复盘，那么聊聊 开宗明义，我们应该是目前 All in Cloudflare 公司中这次事故中恢复的最快的一批 Cloudflare 这次的事故其实应该分为两个 Part 来说，DNS 面和数据面。这次炸的实际上是数据面 早在10月20多号，Cloudflare 因为机房在维护而导致流量切换的时候，我们的跨洋访问线路就出现了问题。当时讨论后，我和同事达成一致，决定开始着手将我们的 DNS 和 CDN 分离开来，切换到不同的 vendor 上。 对我们来说 CDN 是 Cloudfront我们在某次冒烟的1h内完成了一条关键链路的迁移。实际上这为我们今天的处理奠定了一个良好的基础 而在本周一，我完成了我们核心域名 Cloudflare 上 DNS record 的 terraform 化。 所以回到事故本身，不同于 AWS 事故我们能做的会相对更少，而 Cloudflare 事故中，我们能尝试做的事情很多。所以我们按照预案，有 Plan A/B A. DNS 和 CDN 双切 B. 在 Cloudflare API 面恢复后仅切换 CDN 我们最后得出结论，选择 Plan B。当然我们也在 Route53 上做好了 Plan A 的准备 而之前准备的 Terraform 实际上在此时帮上了忙，在 Cloudflare API 恢复的第一时间，实际上 Dashboard 和 2FA 等 Auth 还是 failure 的状态。Terraform 帮助我们第一时间完成了切换。同时同事能帮我进行很严谨的 cross check。 分享一些能高效处理事故的 tips 吧 1. 及时拉会，我们事故处理会是一个全员 open 的会 2. 需要有人来承担一号位的职责，负责控场 3. 越忙越容易出错，所有变更一定要同步+cross check，我自己习惯是两次确认“同步：我将变更xx，内容为xxx，请xx帮我确认”，“确认执行，请xx协助验证” 4. 设置关键的时间点，并定时更新时间点。比如我们最开始切换 CDN 时间点定为 , 然后因为临时原因延后。而我们最开始对外恢复公告的时间点定为 UTC+8 ，然后结束前半小时我 reset timer ，定位 UTC+8 。明确的时间点能协助同事更明确知道我们当前在做什么，需要做什么，以及下一步做什么 说实话今晚再一次感受到了有一群很棒的同事是很爽的一件事。我们共同决策，执行指令，处理 corner case，制定接下来的 48h 的 action item，乃至考虑要不要升级数据库（不是（。 期间我有很多在我规划的预案中没有 cover 的部分，而每个同事都在帮助我查漏补缺，这无疑是非常爽的一件事。 如同我们结束了 5h 的全程 follow up 的事故复盘会后，CTO 发的全员感谢信一样“无论是在事先预案和技术实施文档上，还是在应急决策的果断和集体决策（快速信息补齐，临时分工合作，互相 review 找 bug），体现出来的专业性，技术能力，合作精神，都比之前上了不小的台阶” 是的，每个良好的团队，都会随着每一次事故而成长。 最后打个小广告，鄙司目前诚招前/后端/推荐算法/推理加速/infra 等方向的人，如果你想和我们一起成长，欢迎聊聊
#Cloudflare事故 #DNS/CDN分离 #快速恢复 #团队合作 #事故复盘
avatar
今天和 CTO 还有搭档进行入职半年的 1 on 1 on 1（乐（什么叠加 两位都对我入职这半年多给出了超出我预期外的评价 坦白来说我没预料到会有这么好的评价（ 我自己也很惊讶我入职这半年多暴发出来的主观能动性。 我今天和他们坦言，能支持我在这里做事的有两点 1. 我做的事能直接体现在用户的体感上，有着非常强的 feedback 2. 非常高的信任度。在我和 CTO 因为一些事情有分歧的时候，很多时候 CTO 都会优先考虑我的意见。而我在入职才一个多月的时候就放权给我让我负责非常大的技术合作合同。这在其余公司是很难做到的。以及我的同事们对我都报以了非常高的信任与包容 作为一个 SRE 来说，无论是 feedback 还是信任都是极为稀缺的物品。所以我很珍惜。希望在这里能把事情更进一步的做好。每天进步一点。每天都走出更踏实的一步 BTW，我司还在招人，我司更进一步的企业文化参考 后端 / 全栈 / ML Data Engineer / Growth Engineer / SEO Engineer / 推荐算法 / MLE 等职位虚位以待
#入职半年 #积极评价 #主观能动性 #信任与放权 #招聘
avatar
简单复盘一下 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. 指令下达可以更果断一些 差不多就是这样，一点分享，希望能帮到大家
#AWS故障应对 #AIGC Startup SRE #多地备份恢复 #USE1事故 #服务连续性
avatar
怎么说，今天在重保活动的时候，犯了一个很低级的错误，虽然发现的及时没有造成太大的损失，但是还是负罪感爆棚了 还是那句话 SRE 犯错后的代价非常大，处理起来也非常麻烦 所以敬畏生产，谨慎前行 准备在活动时候复盘的时候正儿八经给帮助处理事故的同事认真道个歉了（虽然大家都觉得没啥大不了（但是这是我得做的事
#重保活动 #低级错误 #负罪感 #SRE #道歉
avatar
Cloudflare 这篇好文，雄文，值得推荐。揭示了很多很细节的东西。建议工程师都可以读一下，某些写 Node 的公司（是谁我不说）建议全文背诵一下 另，前情提要
AI编程工具激战：Claude Code、Gemini Cli崛起· 1256 条信息
#CloudFlare #Node.js #工程师 #技术分析 #推荐
avatar
暴论一下 AI 时代的到来，codebase 和架构将以前所未有的速度不断的腐化。 这会意味着稳定性越来越难做。之前被忽视的很多稳定性细节以及最佳实践都会在 AI 时代被放大。越来越多的初创公司比预期的更早的遇到自己的架构瓶颈或者到了技术债务的偿还时刻 而稳定性越来越难做的另外一层含义就是，能做稳定性的人也越来越少。而在 vibe coding 盛行的情况下，能静下心来做稳定性，扣指标的人也越来越少
#AI时代 #代码库腐化 #稳定性挑战 #技术债务 #Vibe Coding
avatar
打完空轨 1st 难得开心，写个杂文放松下
#空轨 1st #杂文 #放松 #游戏 #开心
avatar
到底都是什么人在喜欢nodejs
#Nodejs #技术 #讨论 #受众 #疑问
avatar
被同事赞美省心，活好 看目前看起来我自己的秉持的一定要去尝试理解业务的路子是没有错的 搞 SRE 的，一定是要把业务的体感降到最低的
#同事赞美 #省心 #理解业务 #SRE #降低业务体感
avatar
深夜说一个最近的感想 其实也不算新，还是老生常谈的一个话题“做 infra 的人必须要去贴近业务，否则一切都是空中楼阁” 我介绍过很多次鄙司是 AIGC 头部玩家，主攻二次元赛道。 我们最近面临的一个问题是 Elasticsearch 带来的。 我们用户公开发布的 Artwork 和生成任务都是可以搜索的。 最近 Elasticsearch 频繁会出现部分 Data Node 被打满然后连锁搜索出现问题的情况。 那么我们需要去怎么样快速的解这个问题？ 在进一步讨论之前我们需要思考在这个场景下，搜索这个操作的本质是什么？ 我的看法是资产管理。在 AIGC 场景下，Prompt 毫无疑问是用户的核心资产，而对应的 Task 以及 Artwork 某种意义上算是资产的预览（or 属性） 那么有了这样一个推论后，我们便能清晰的知道，至少在目前的形态下，业务核心属性必然不能为了技术结果让步。 同时我们又有一个观察，我们用户公开发布的 Artwork 其的可见性和 Task 是不太一样的，Artwork 可公开检索，也会承担 SEO 的责任，而 Task 实际上仅用户可见。那么换句话讲，两者的数据的访问频率，资源需求都是不太一样的。 换句话说，我们对 ES 的 Index 存在了多租的需求。但是很遗憾，按照目前的 ES 的设计，是不具备多租的能力的。 虽然长远来说，优化查询会是一个必然的选项，但是在当下面对超高速发展的业务，拆分 Index 为不同的集群，按照 Index 不同的属性给不同的算力/磁盘，快速试错会成为我们的首选。 目前这项工作正在进行中，效果未知，但是整个思考博弈的过程其实是我前几年会很少考虑的。很多时候技术的最优解未必是业务的最优解。 最后的最后，再打一个广告。鄙司招人，ML Engineer，ML Data/Full Stack/Backend/Marketing 等职位虚位以待。如果你想一起做一些有趣的事情，欢迎 DM，帮你老板直达
#AIGC #Elasticsearch #多租户 #业务优先 #二次元
avatar
我们准备家里添的和医院同样的设备以小猫的名义捐给医院了
#小猫 #捐赠 #医院 #医疗设备 #积极
avatar
心态崩了，没忍住在医院哭出来了 昨天早上指标都好不容易贴近正常值的下限 大家都很开心 结果下午就来了个大出血 今天上手术台最后一搏 不能哭了，要忍住 不能影响医生判断
#医院 #大出血 #手术 #心态崩了 #积极
avatar
不怕笑话 我从阿里离职的一个诱因就是 我真被钉一下搞到 PTSD 到物理意义上的失禁过
#阿里 #离职 #钉钉 #PTSD #失禁
avatar
Service mesh 一直没解决一个问题。不管是什么路线，基本上都会保持一个 sidecar 来做很多杂活。而在大规模的场景下 service mesh 没解答的一个问题就是我每个sidecar 500M/0.5 Core 资源累积起来的额外消耗能解决什么样的问题（或者说是 service mesh 独一无二的价值） 而至于小规模场景，为什么要 service mesh（疯了吗