招聘云工程师时，你需要问的问题和你应该听到的答案。
这篇文章从网上得到，翻译得到并加以自己的理解。
原文链接：https://medium.com/aws-activate-startup-blog/hiring-a-cloud-engineer-questions-to-ask-and-what-you-should-hear-12a960d97163#.217rnonso
--------------------------------
当然你正在运营一家初创公司或者规模不算大的公司，想要招聘一些有经验的云工程师帮助你，本篇文章也许会为你提供一些建议。
这里说到的“云工程师“，其实泛指一些可能涉及到云，或者和云相关的技术职位。
如果你想找某人成为你的CTO，或者找一个暂时完成你某个项目的freelance，那人首先需要具备相应技术/技能以建立你的云架构。
所以，这里有5项关键的核心法则来帮助你正确评价候选人的能力，完成好招聘。
以下就是些你需要问的问题的例句，和你应该听到候选者给你答案的范例。
一切和你的客户息息相关
对大多数的初创公司和他们的客户都很关键的5项法则：
· 可用性
· 可伸缩性/弹性
· 表现
· 解决问题的能力
· DevOps自动运维
可用性
为什么这个关系到你的客户？
如果你的行业和电子信息有关，最糟糕的情况就是Down机。
每down机一分钟，你的客户、收入、名声就down一分钟。
因此以分钟为计数单位的Down机时间就是考验你工程师能力表现的关键。
当你发现，Down机时间数据趋势上升，那你就应该觉得你的IT供应商是有问题的。
你应该问的问题
· 你对Down机这个情况有什么打算？
· 你设计的东西能承担多少SLA（服务等级协议）？多少个9？
· 你如何监控一个应用的正常运行时间？
· 你如何建立一个可自愈型的架构?
你应该听到的答案
“我设计的架构具有防御性”
你的云工程师必须知道如何在以下层级上建立应对down机的架构：
应用、服务器、架构（APP tier、database tier等）以及物理数据中心。
“我的心中有5个9”
你的云工程师必须是积极的，而且也对以前的可用性数据非常自信。
“我不介意随时待命”
这个是个好的信号，这表示这个人对于他工作的责任以及掌握欲。
你想要的是一个人，设计了这个架构并且可以自己运营他们。
当然还有个隐藏目的就是看下那个工程师把自己设计出的是这个完整、自愈型的stack是否还会有后续更新，而不是设计好了就放任不管。
弹性
为什么这个关系到你的客户
知道Slashdot效应吗？就是当一个受众广泛的网站介绍了另一个小众的网站后，小众网站流量激增的现象。Slashdot效应的产生大量的访问虽然你急迫想得到的，但是你的现有架构可能并无法做到可伸缩，这样的话，流量激增使得它的访问速度变慢或者一时间完全不能访问，而且当这个激增产生前和产生后，你的架构必须做到自动伸缩，以保证尽量减少成本。
你应该问的问题
· 你会如何设计你的架构以处理流量激增？
· 你如何监管大规模的项目？
· 如何测试你的系统是否有能力处理大规模项目？
· 针对正常流量和高峰流量，如何让你的系统保持始终保持“正确的规模”？
你应该听到的答案
“这个弹性，那个可伸缩……”
弹性/可伸缩性是云计算带来的最大好处之一。它可以尽可能的按需配额。这并不是说在架构中的所有元素都必须具有可伸缩性，而是你的架构需要认识到可伸缩性的重要性并在关键时刻点可以发挥作用。
“横向伸缩比垂直伸缩重要”
在如今云计算中，增加一个额外的计算/互动/储存到一个既存服务器（垂直伸缩）是小事一桩。但是最终的表现和时间成本却受到限制。从可伸缩性、成本、弹性角度而言，可以增加/减少小型实例的自动伸缩群组的负载均衡是较好的一种方式。你的架构师应该从一开始就使用横向伸缩。
“网络规模服务”
AWS有一些可完全伸缩的非常很好用的服务（比如，AWS S3,AWS DynamoDB，和Elastic Load Balancing云网络负载均衡器）。这意味着处理一些从几个Gb到几个Pb（1024Tb）扩张服务时，不用或者很少用到人力干预。一个好的云工程师会利用服务简化或完全缓解一些效果，比如给某个应用储存不稳定的元素等等。
表现
为什么这个关系到你的客户？
页面的响应时间是影响用户体验最重要的因素之一。
架构师有很多工具可以测试出载入时间的每个毫秒都用在了什么地方。这些载入时间会被一些因素影响，包括用户的物理位置，服务器处理进程以及网络带宽等等。一个好的架构师会优先处理那些载入时间遇到瓶颈并在战略上统筹整个stack。
你应该问的问题
· 你会如何监视系统表现？
· 监控什么数据最重要？
· 有没有遇到过应用表现中记忆、计算、储存遇到瓶颈？你的架构是怎么处理的？
· 你是如何利用缓存改善执行能力？
你应该听到的答案
“缓存数据”
当你开始伸缩业务，database都会是你的痛点。
把数据库问询下到缓存层，比如Memcache 或Redis，可以让你的应用闪电快速阅读，也会显著降低你数据库的需要。
不过你的架构师必须有过在重要储存里缓存数据的经验。
“边缘的缓存设施”
减少网页载入时间最有效的途径之一就是把像图像，CSS，JS等东西缓存在离终端用户越近的地方越好。
我说的就是CDN。所以，你的架构师必须对CDN稍有认识。
“我用过XXX或者YYY工具”
证明一个架构师是否靠谱，就是看他是否负责过真实生产环境的工作负荷，而且会有针对性地选择登入工具和监控工具。
一个架构师的数据报告版就像飞行员的仪器板，我们得依靠这些东西保持飞机空中正常运行。
解决问题的能力
为什么这个关系到你的客户?
信息公司的核心价值可以从他新功能的发布频率中体现。保持产品更新的速度和新功能的发布，与用户参与和满意度密不可分。
如果你的云工程师阻碍了开发人员的进度，
因为他“还在配备集群”或者“还在配置数据库”，
他降低了开发人员的速度而不是帮助他们创新改进。
一个好的云工程会寻找每个机会把问题简单化把同样的事情做好。
你应该问的问题
· 你以前用过什么托管服务？
· 你为开发准备一个数据库，最短需要多久？
· 什么时候开始不适用托管服务并在直接的集群里开始适用自主管理？
你应该听到的回答
“为什么不重新改造那些轮子？”
不管公司是什么种类，普通技术需求会演变成变成一个增长型的复杂架构，比如后台工作人员、外部邮件或者手机推送。
你要的不是那些认为只要个普通架构的工程师。
“我不喜欢管理我自己的集群”
如果有人只为他们曾运营15个集群而自豪，那就是个不好的标志。
管理集群需要很大经历，有时甚至是个全职工作。
管理自己的集群像水藻里找东西。
好的云工程师会在管理细节中使用托管服务，因此才会在stack里更加优化工作负荷。
“我尽量避免数据行政管理”
托管数据库服务的出现，像AWS RDS Aurora，大大减少了运营上复杂程度，之前都需要数据库管理员（Database Administrator）负责管理。
给工作负荷选择正确的托管数据库的能力现在比数据库管理经验来的重要。
自动运维DevOps
为什么这个关系到你的客户
做实物的公司非常注重他们的实物供应链。同样，一个电子信息公司也必须高度注重DevOps。
想象一下你公司的DevOps过程就好比实物供应链中负责确保你的产品性能送达你的客户。
战术上，DevOps意味着确保那些代码写好了，管理好了，测试过了并靠谱地没有重复地被部署。
要知道，你公司的DevOps过程中断或漏洞可能会造成down机或客户的服务降级。
你需要问的问题
· 你以前用的是什么版本管理器？你偏好哪个？为什么？
· 很多人同时使用同一个代码库的时间是什么？在那种环境下你又是如何做的部署？
· 持续整合和持续部署之间的区别是什么？
· 你以前用的是什么DevOps工具？你偏好哪个？为什么？
你应该听到的答案
“这需要衡量。”
人力不够的情况下，添加过多的DevOps程序和技术会降低速率。
你的云工程应该认识到这种得失，自己进行衡量，
找出和基于各种考虑因素的合适DevOps，其中因素包括有：公司规模、开发者的水平、公司成长目标。
“架构即代码”
如今的云，是一个有像AWS CloudFormation模板和AWS Elastic Beanstalk 参数这种有特别格式的text文件的整个技术架构。
如果一个人说可以把整个架构可以在源代码层管理的话，可以证明这是个与时俱进的好云工程师。
我公司BootDev中的自动伸缩架构，就是以架构及代码的形式部署到客户的账号下。
也算是架构及代码产品化的一个体现。
“我真TM喜欢/讨厌xxx工具”
这是个很好的证明，说这个话有很强的自主意见，偏好使用什么工具。
一个如果喜欢或讨厌CI或CD工具的话，其实就走在DevOps的路上。
结论
人发展为一个好的云工程是有很多因素。
我觉得软件开发和DevOps可以很好地转化成了云计算。
不要因为一个人没多少云上的实践经验就立即否定。
那些人如果正视并认真理解了本篇中阐述的一些观点，他们会自己琢磨那些的云特性。
综上所示，你要找的是一个可以全盘看住你的架构并有意持续优化的人。
希望以上内容对你有帮助。