CloudFormation 或类似模板
把 AWS 资源定义为受版本控制的代码,让账户中的网络、计算和存储可以像其他变更一样被重建和审查。
迪拜企业往往在 AWS 账户已经发展到、当初搭建的人无法再持续盯守的规模时,才会迪拜聘请 AWS 云工程师。这一角色负责配置 AWS 基础设施,主要通过代码而不是在控制台里点击操作,搭建用于部署应用变更的流水线,并监控账户中的故障、安全隐患和成本蔓延,在这些问题影响到客户之前先行处理。
这与专注于应用本身的 AWS 开发工程师有意区分开来。根据 AWS 官方上线公告,其中东(阿联酋)区域自 2022 年起已开放供生产环境工作负载使用,而这往往是与迪拜企业合作的 AWS 云工程师需要确认的第一个基础设施决策:账户是否真的配置在该区域,以及原因是什么。
AWS 云工程师负责的内容
具体的 AWS 基础设施,日常保持健康运行。
把 AWS 资源定义为受版本控制的代码,让账户中的网络、计算和存储可以像其他变更一样被重建和审查。
使用 AWS 自有流水线工具或同类第三方工具,自动完成构建和发布步骤,省去容易出错的手动部署。
经过调优的仪表盘和告警,能及早发现真实问题,而不会因为无关紧要的噪音打扰团队。
只授予每个人或每个服务实际需要的最小 AWS 权限,并组织账户结构,让失误的影响保持可控。
设置子网、路由和安全组,让各环境彼此妥善隔离,也与公共互联网在该隔离的地方保持隔离。
关注 AWS Cost Explorer 或类似工具,合理调整资源规模,并在闲置资源悄然累积成本之前将其移除。
相关技能
专门针对 AWS 的运维严谨性,对照真实生产工作核实。
| 技能或工具 | 合格的表现 | 为何重要 |
|---|---|---|
| 面向 AWS 的基础设施即代码 | 把从受版本控制的模板构建 AWS 环境作为标准做法 | 靠手动点击搭建的 AWS 基础设施难以复现或审查 |
| IAM 策略设计 | 编写权限范围狭窄的策略,并能说明自己刻意限制过的某项权限 | 过宽的 IAM 权限是 AWS 账户安全事故的主要诱因之一 |
| CloudWatch 与日志 | 能设置有意义的告警,并能讲述一次借助这些告警提前发现的真实事故 | 没有可见性的 AWS 账户会悄无声息地失效,直到问题明显暴露 |
| VPC 与网络设计 | 能熟练设计子网、路由和安全组,而不只是接受默认设置 | 糟糕的网络设计是宕机和数据暴露的常见根源 |
| 成本工具 | 习惯性地使用 AWS 自有的成本工具,而不只是在账单引发担忧时才用 | AWS 成本按用量增长,不定期审查很容易在不知不觉中累积 |
合作方式
一个有持续需求的在线 AWS 账户最适合专属聘用,因为随着产品发展,新环境、日益复杂的流水线和各类事故会持续出现。为某个明确系统从零搭建 AWS 账户结构,更适合以限定范围项目的形式交付,附带文档完成干净的交接。如果目标是长期充实您自己的团队,招聘支持服务会投入我们的寻访和技术评估能力,招聘决定仍由您做出。针对现有 AWS 配置做一次简短而聚焦的审查,例如在审计或扩容问题出现之前,恰好适合作为独立的咨询服务。
候选人评估
区分真正运维 AWS 的人和只在控制台里点过几下的人的考察方式。
您可以自行运用这些考察方式,也可以让我们团队在招聘支持服务的技术评估环节中代为进行。
而不是控制台的截图。一份真实的模板,展示的是一个人实际搭建 AWS 基础设施的方式。
出了什么问题、CloudWatch 或其他工具如何发现的,以及事后做了哪些改动来避免重演。
一个资源配置过度、后来在不破坏任何功能的前提下降低账单的具体例子。
询问他们会如何为新入职成员授予访问权限,以及该成员离职时又如何干净利落地收回权限。
迪拜这类工作大多是接手他人搭建的 AWS 配置,因此可以问问对方在改动任何内容之前,会如何安全地摸清情况。
认证
有一项认证与这一角色紧密对应,AWS 近期更新过这个名称。
根据 AWS 官方认证页面,这项此前曾用另一个名称的认证,验证的是监控和维护 AWS 工作负载、实施安全控制和网络配置、业务连续性和成本优化方面的能力,与这一角色直接对应,且可核实。
这项认证证实候选人对 AWS 运维各类主题有广泛了解。上文的事故讲述和成本问题,则能展示这些知识是否真的在真实压力下被运用过。
阿联酋相关事项
两个专属于在迪拜运维 AWS 基础设施的方面。
本角色属于我们的云计算分类,是更广泛的迪拜聘请开发工程师部分的一员。如果您的基础设施不限定于某一家服务商,请参见我们不区分服务商的云工程师页面。如果需要的是 AWS 应用代码而不是基础设施,我们的AWS 开发工程师页面更合适;如果需要的是 AWS 账户背后的架构决策,请参见AWS 解决方案架构师。
直接解答
AWS 开发工程师编写运行在 AWS 服务上的应用代码。AWS 云工程师则负责配置、自动化和监控该应用所依赖的 AWS 账户、网络和流水线,并在问题出在基础设施而不是应用逻辑时负责应对。
在小型系统上,工作层面通常可以。随着 AWS 账户规模扩大、真实客户开始依赖它,把两个角色拆分开通常能让双方都推进得更快,也能减少运维工作被功能开发截止日期挤占的情况。
会,这是常见的工作,通常以项目制的形式限定范围:根据明确的简报搭建账户结构、网络、身份体系和部署流水线,附带文档完成交接。
通过合理调整资源规模、移除闲置资源、选择贴合实际用量的计费模式,并把查看成本仪表盘作为日常工作的一部分,而不是账单突然飙升时才临时应对。
不应该。如果服务商尚未确定,我们的云架构师角色会先妥善处理这一决策,这样您就不会在 AWS 真正确定之前,先招入一位专精 AWS 的人。
资料来源
书面固定价格
已收到,我们正在为您撰写报价。
工作时间内您将在 45 分钟内收到。请查收确认邮件。