夜雨聆风
在shopify干SRE（顺便refer）
这十四个月在Shopify干系统可靠性工程师（SRE），其实就是“让商业存在于互联网”。我们组专盯底层交易、支付路由和API网关的脉搏——确保全球商家收钱的时候，系统不会出问题。
入职碰上“黑色星期五”预演。整个on-call小组忙的不行，监控墙实时滚动每秒订单量、支付授权延迟、第三方服务心跳。直接教会我区分平台故障与商户自身容量问题要引导。
日常被“容量规划”和“故障逃逸”填满。Shopify的核心服务是围绕“Pod”构建的，每个Pod承载特定商户群。我的主要任务之一是分析Pod的资源使用趋势，预判扩容节点。但这不只是加机器：之前我发现一个Pod的数据库连接数攀升异常，追查后是某个热门评论插件在特定场景下产生了连接泄漏。我需要先写自动化的诊断脚本定位到具体商户应用，再协调应用支持团队通知商户开发者修复，而非直接重启服务掩盖问题。
我们内部用“Crucible”模拟整个交易链路的区域性故障。每月我们都要参与“故障注入”演习，并撰写复盘文档。还有一次是我主导模拟“库存服务缓存大规模失效”的场景，触发了订单履约系统的连锁告警。事后复盘会，库存团队质疑我们模拟的极端性，要求出示历史数据，证明类似模式的低概率事件在过去一年实际发生过三次，只是影响面较小。这种基于数据的争论是这里的沟通方式。
技术栈是务实的混合体：核心是Ruby on Rails和Go，基础设施在Google Cloud Platform（GCP）上，用Kubernetes编排，监控靠自研系统与Datadog组合。作为SRE，我有权在生产环境进行有限的调试，但每次操作都会被录屏，并且需要事后在内部Wiki上记录“操作意图”与“观察结果”。权限很高，约束更严。
绩效评估看“韧性提升”而非“灭火次数”。我的年度目标之一是降低支付路由的“区域性故障恢复时间”。推动了与GCP网络团队的联合架构评审，重新设计了跨区域流量切换的自动化决策树。项目上线后，该指标改善了40%，但过程涉及与十几个团队的拉扯。累啊……
#留学生实习 #北美求职 #留学生求职 #留学生找工作 #互联网大厂 #内推 #北美找工作 #海归求职 #北美留学 #实习生内推
入职碰上“黑色星期五”预演。整个on-call小组忙的不行，监控墙实时滚动每秒订单量、支付授权延迟、第三方服务心跳。直接教会我区分平台故障与商户自身容量问题要引导。
日常被“容量规划”和“故障逃逸”填满。Shopify的核心服务是围绕“Pod”构建的，每个Pod承载特定商户群。我的主要任务之一是分析Pod的资源使用趋势，预判扩容节点。但这不只是加机器：之前我发现一个Pod的数据库连接数攀升异常，追查后是某个热门评论插件在特定场景下产生了连接泄漏。我需要先写自动化的诊断脚本定位到具体商户应用，再协调应用支持团队通知商户开发者修复，而非直接重启服务掩盖问题。
我们内部用“Crucible”模拟整个交易链路的区域性故障。每月我们都要参与“故障注入”演习，并撰写复盘文档。还有一次是我主导模拟“库存服务缓存大规模失效”的场景，触发了订单履约系统的连锁告警。事后复盘会，库存团队质疑我们模拟的极端性，要求出示历史数据，证明类似模式的低概率事件在过去一年实际发生过三次，只是影响面较小。这种基于数据的争论是这里的沟通方式。
技术栈是务实的混合体：核心是Ruby on Rails和Go，基础设施在Google Cloud Platform（GCP）上，用Kubernetes编排，监控靠自研系统与Datadog组合。作为SRE，我有权在生产环境进行有限的调试，但每次操作都会被录屏，并且需要事后在内部Wiki上记录“操作意图”与“观察结果”。权限很高，约束更严。
绩效评估看“韧性提升”而非“灭火次数”。我的年度目标之一是降低支付路由的“区域性故障恢复时间”。推动了与GCP网络团队的联合架构评审，重新设计了跨区域流量切换的自动化决策树。项目上线后，该指标改善了40%，但过程涉及与十几个团队的拉扯。累啊……
#留学生实习 #北美求职 #留学生求职 #留学生找工作 #互联网大厂 #内推 #北美找工作 #海归求职 #北美留学 #实习生内推
