从亚马逊到Zoom：一位SRE工程师的转型之路

在科技行业职场中，从一家顶级公司跳槽到另一家顶级公司，往往不只是薪资的考量，更关乎技术方向、成长空间与个人愿景的匹配。GeeksforGeeks的DevOps/SRE导师Manish近期分享了他从亚马逊离职、加入Zoom担任Site Reliability Engineer的经历。他的故事涵盖职业起步的迷茫、自学转行的策略、面试失败的教训，以及如何在没有直接项目经验时通过自建项目补齐短板。对于正在考虑职业转型或跳槽的工程师而言，这些经验具有相当的参考价值。

从Cognizant到亚马逊：一段自学转型的真实历程

Manish的职业起点并不光鲜。大学毕业后，他以Advanced Java Developer的身份加入Cognizant，却被分配到了供应链管理领域——一个他完全不了解的方向。面对“五年后你在哪里”这种问题，他坦言当时毫无头绪。这种迷茫感促使他开始寻找出路。

在朋友的建议下，他利用项目空窗期自学了Python、Scala、Kafka、Airflow、SQL/NoSQL等数据工程相关技术，同时备考AWS云认证，并积极寻求内部转岗机会。最终，一位经理给了他DevOps方向的初级岗位机会。虽然并非最初设想的数据工程方向，但他果断抓住。

进入DevOps领域后，他给自己定下的策略是：第一年全力学习，把公司的项目当作自己的练兵场。他反复研读代码库、理解Jenkins流水线的构建逻辑，将YouTube上看到的项目实践与当前工作内容对照验证，力求打通端到端的架构理解。这种“把公司项目当自己的项目来研究”的方法，为他后续的跳槽打下了基础。

亚马逊云认证（AWS Certification）：AWS提供多个层级的职业认证，常见路径从入门级的 Cloud Practitioner 到助理级（Solutions Architect Associate、Developer Associate、SysOps Administrator Associate），再到专家级（Solutions Architect Professional、DevOps Engineer Professional）以及专项认证（如 Security、Data Analytics）。对转行者而言，认证本身并不能保证拿到offer，但能系统性地补齐云服务、网络、安全与计费模型等基础知识，并在简历筛选中提供可验证的学习信号。Manish在Cognizant阶段备考AWS认证，正是用“证书+内部转岗”组合拳将自己从 Java 开发者推向 DevOps 轨道。

面试碰壁与自建项目策略：面试官真正想考察什么

在Cognizant工作约一年半后，Manish开始积极投递简历。很快，他遭遇了一个许多服务型公司工程师都会面临的困境：90天的通知期让大多数HR望而却步，面试机会寥寥无几。更令他受挫的是，一次CGI的面试仅持续了五分钟便宣告结束——面试官问及Kubernetes架构，而他当时对此几乎一无所知。

这次五分钟的失败反而成了转折点。他开始大量阅读技术文章、观看视频教程，并在自己的笔记本电脑上从零搭建了EKS集群、部署完整项目、集成Jenkins流水线，甚至创建了mini Kubernetes集群。他的核心洞察是：面试官并不要求你在真实工作中使用过某项技术，他们考察的是你是否真正理解原理、是否具备动手能力。本地搭建端到端项目并记录过程中的报错与调试经验，在面试中会成为你有力的佐证。

他还特别强调了简历优化的重要性。他曾主动在LinkedIn上联系亚马逊、微软、Adobe等公司的工程师帮忙审阅简历，并持续调整至ATS友好格式。

EKS 与 mini Kubernetes 集群：EKS（Elastic Kubernetes Service）是 AWS 上的托管 Kubernetes 服务，用户只需管理节点组与工作负载，控制平面由 AWS 运维，因此非常适合做端到端项目：用 Terraform 创建 VPC、IAM 角色与 EKS 集群，再用 kubectl 或 Helm 部署应用，并接入 Jenkins/GitHub Actions 流水线。而“mini Kubernetes 集群”通常指在本地用 kubeadm、k3s、minikube 或 kind 搭建的轻量集群，目的在于理解控制平面组件（API Server、etcd、Scheduler、Controller Manager）与工作节点组件（kubelet、kube-proxy、容器运行时）的协作关系。两者结合既展示云上落地能力，也证明对底层原理的掌握。

亚马逊的两年：实战淬炼与领导力原则

2024年，Manish终于拿到了亚马逊的Offer。他回忆，自己在大学四年级时就买了一件亚马逊T恤，那件T恤在衣柜里放了近三年，直到入职那天才穿上。

在亚马逊的两年里，他获得了远超技术的成长。他提到，亚马逊的16条领导力原则会“深深根植于你”，其中“坚持最高标准”给他留下了深刻印象。他经常面对没有现成方案、没有POC、没有SOP的问题，需要自己深入排查、提出方案、获得批准并完成交付。

这种高压环境带来的不仅是技术能力的提升，更是抗压能力和自信心的质变。他坦言，亚马逊有时会让人感到沮丧，但这些经历确实在塑造一个人——“如果你在亚马逊工作过，你可以在任何公司工作。”

亚马逊16条领导力原则（Leadership Principles）：这是亚马逊用于招聘、绩效考核与晋升评审的核心行为准则，包括 Customer Obsession、Ownership、Invent and Simplify、Are Right A Lot、Learn and Be Curious、Hire and Develop the Best、Insist on the Highest Standards、Think Big、Bias for Action、Frugality、Earn Trust、Dive Deep、Have Backbone; Disagree and Commit、Deliver Results、Strive to be Earth's Best Employer、Success and Scale Bring Broad Responsibility。面试中的行为问题（Behavioral Questions）通常要求用 STAR 结构回答，并明确对应其中一两条原则。Manish 提到的“坚持最高标准”正是 Insist on the Highest Standards，强调在无现成方案、无 POC、无 SOP 的场景下仍要交付可靠结果。

为何离开亚马逊：当成长方向与个人规划不再匹配

亚马逊是Manish的梦想公司，但他在两年后选择离开。他的理由是：想做的技术方向、想为团队创造的影响力和学习曲线，在亚马逊的当前岗位上已经不够清晰。当被问到“五年后在哪里”时，他又一次感到模糊。

离职准备期间，他经历了密集的面试和被拒——media.net、Warner Bros、PhonePe、eBay、Goldman Sachs等公司，有的止步二面，有的倒在终面。他再次启用之前的方法论：针对目标岗位所需但自己简历中缺失的技术，自建项目补齐，利用晚上11点到凌晨2-3点的时间持续学习和模拟面试。最终，他拿到了包括Zoom在内的几个Offer，选择加入Zoom担任Site Reliability Engineer，并表示目前的工作内容与技术方向与他未来五年的职业规划高度契合。

AI对DevOps/SRE的影响与转型建议

谈及AI对DevOps和SRE领域的影响，Manish的态度务实：你无法回避AI，但可以选择与AI协作。把AI作为提升交付速度和质量的工具，而非竞争对手，是更明智的定位。他同时强调，DevOps和SRE目前仍然是高需求、高薪酬的方向。

对于想从其他领域转入DevOps/SRE的人，他的建议是：先打牢基础，然后通过一个完整的端到端项目把Linux、Shell、AWS、Terraform、Docker、Kubernetes、CI/CD、Prometheus、Grafana和Python等知识点串联起来。从用Terraform创建AWS基础设施，到在EKS上部署应用、集成SonarQube和Trivy、配置GitHub Actions或Jenkins流水线，再到用Prometheus和Grafana做监控可视化——这个项目可以花三到六个月完成，但它能让你在面试中有真实可讲的内容。项目完成后，同步优化LinkedIn和简历，提升被HR发现的概率。

Manish的经历说到底是一条朴素的逻辑：遇到短板就用项目补齐，被拒绝就把挫败感转化为行动力，保持持续学习的节奏。对于正在犹豫是否跳槽或转型的工程师来说，这或许比任何技术攻略都更值得借鉴。

SRE 与 DevOps 的差异：DevOps 更偏向文化、流程与工程实践的整合，强调开发与运维协作、CI/CD、自动化与快速反馈；SRE（Site Reliability Engineer）则起源于 Google，是把软件工程方法用于运维问题的具体岗位，常用 SLO/SLI/错误预算（Error Budget）来量化可靠性，并通过减少琐事（toil）、自动化与容量规划来保障系统稳定。两者在工具链上高度重叠（Kubernetes、Terraform、Prometheus、Grafana 等），但 SRE 更强调以可度量的可靠性目标驱动决策。理解这一差异，有助于转行者根据目标岗位调整简历与项目侧重点。