基础概念的常见误区
很多人对谷歌云的第一印象，就是"海外可用的服务器"，其实这个理解太窄了。谷歌云是一整套完整的公有云服务体系，从最底层的物理基础设施，到中层的虚拟化资源，再到上层的平台化托管服务，都有覆盖。对普通开发者来说，平时用得最多的还是IaaS层的计算、存储、网络资源，少量用到PaaS层的托管服务，不用一开始就去啃所有的产品文档，先把常用资源的概念理清楚就够。
还有很多人会问，谷歌云的服务和其他公有云有什么本质区别吗？从普通开发者的使用角度来看，核心能力其实差不多，都是提供虚拟化计算存储资源，主要的差异在产品设计逻辑和具体的规则上，所以不用抱着"必须完全不一样"的心态去学习，先把基础规则搞清楚就好。
第一个最常见的误区，是混淆不同计算实例的类型。谷歌云的计算实例分很多种，最常用的是共享型、标准型和抢占式三类，很多人分不清区别，随便选。共享型实例是多个实例共享物理服务器的计算核心，资源供给不会做独占保证，适合开发、测试这类对稳定性要求不高的场景，放到生产环境，一旦流量上来，就可能出现算力不足、响应延迟飙高的问题。标准型实例是独占分配计算资源，稳定性有保证，适合生产环境的核心服务。抢占式实例的特性我后面单独说，很多人在这里踩的坑很大。
第二个常见误区，是把所有数据都往实例的系统盘放。不少新手部署项目的时候，图省事，程序、日志、业务数据全部都存在系统盘里，觉得反正够大。实际上谷歌云的系统盘默认是和实例绑定的，如果实例因为误操作或者其他原因被删除，系统盘里的数据也会跟着被清除，哪怕选择保留数据盘，重新挂载也会多出很多配置工作量，不小心就会丢数据。
还有一个误区，就是觉得权限配置无所谓，刚建完项目就给所有协作账号开最高权限，这个问题我后面再讲。
几个常见场景的实际经验
从我自己和身边朋友的经历来看，普通开发者用谷歌云，大部分问题都出在对场景匹配不对，配置漏了步骤，我整理几个碰到最多的场景。
第一个场景是小型应用部署。很多人做中小规模的项目，会把所有内容都放在一个计算实例里，包括前端静态文件、后端程序、数据库，这样不是不能跑，但有很多可以优化的地方。比如前端的静态资源，包括图片、CSS、JS文件，完全可以放到谷歌云的对象存储服务里，对象存储的可用性比单个实例高很多，还能直接配合全球分发网络加快用户访问，不需要占用实例的计算和带宽资源。业务数据一定要放到独立的持久化磁盘里，不要和系统盘放一起，哪怕实例出问题，数据也能单独挂载出来不会丢。如果是无状态的后端服务，还可以配置自动扩缩容，流量高的时候自动新增实例，流量低的时候自动减少，不用一直留着高配置实例空闲运行。
第二个场景是网络问题排查。我碰到过至少三个开发者，程序在本地测试完全正常，部署到谷歌云之后，外部无法访问，翻遍了程序日志也找不到错误，最后折腾大半天才能发现问题出在哪。谷歌云默认的安全规则是，新建实例之后，只放开SSH管理的默认端口，其他所有的入口访问默认都是拒绝的，很多人不知道有这个规则，一出问题就怀疑是网络连通性异常，其实只要去后台的防火墙配置里，新增一条对应端口的允许入口规则，问题就能解决。还有一个容易忽略的点，是出口带宽的配额，谷歌云对不同类型的实例有不同的出口带宽配额，如果你的应用需要输出大流量，要提前去查看配额有没有满足需求，不够的话提前申请调整，不要等到上线之后流量跑不起来才发现问题。
第三个场景是抢占式实例的使用。很多新手不了解抢占式实例的设计目标，直接拿来跑核心的在线服务，结果出了大问题。抢占式实例是谷歌云提供的用于临时任务的实例类型，适合批量数据处理、渲染、临时测试这类不需要长时间稳定运行的任务，系统会根据整体资源的使用情况，主动回收闲置时段的抢占式实例，如果拿来跑需要持续在线的业务，很容易出现实例被突然回收，服务中断的情况。我之前见过一个开发者，把自己的个人博客跑在抢占式实例上，跑了半个多月都没事，结果某天凌晨实例被回收，博客停了三天自己才发现，这个教训还是挺明显的。
第四个场景是权限配置。谷歌云的IAM权限体系做的非常细，不同角色可以分配不同粒度的权限，很多新手图省事，不管是谁协作，都直接给所有者权限，这个做法有很大的安全隐患。如果某个协作账号的密码泄露，整个项目的所有资源都会被控制，风险很高。正确的做法是遵循最小权限原则，给不同的账号分配刚好够用的权限：负责部署的账号，只需要给计算实例、对象存储的编辑权限就够，不需要给项目管理或者删除资源的权限；负责看监控和排查问题的账号，只给查看权限就够，不需要操作权限；专门用来做自动化部署的服务账号，权限也要收得尽可能窄，不要开多余的权限。这个点看起来不起眼，但是真出安全问题，影响会非常大。
容易被忽略的基础配置
除了上面说的这些，还有几个基础配置，很多新手刚用谷歌云的时候不会注意，等到出问题才想起补，我也整理在这里。
第一个是数据备份。不管是什么类型的数据，都要开定期备份，持久化磁盘可以开自动快照策略，按天或者按周做快照，快照存在独立的存储位置，哪怕原盘出问题，也能从快照恢复数据。对象存储里的重要数据，可以开启跨区域存储，把副本存到不同的区域，防止单个区域出故障导致数据丢失。很多人觉得自己不会出问题，结果碰到误操作删除数据，或者磁盘故障，才发现没有备份，最后找不回来，损失很大。
第二个是监控告警。谷歌云自带了完整的监控告警工具，大部分普通开发者的需求都能满足，不需要自己额外搭监控服务。很多人建完实例就不管了，也不开告警，服务宕机了半天，还是用户反馈才知道，这个被动程度太高了。只要花十几分钟配置一下，把关键指标加上告警：比如CPU使用率超过阈值发告警，磁盘使用率超过阈值发告警，实例状态异常发告警，就能提前发现大部分问题，不用等用户找上门。
第三个是资源规划。很多人刚起步做项目，上来就选最高配置的实例，觉得这样性能好，其实完全没必要。可以先从低配置的实例开始，运行一段时间之后，看监控里的资源使用率，如果CPU和内存一直跑不满，再调低配置也不晚，如果资源不够用再升级，这样更合理。不要一开始就把配置拉满，造成不必要的资源浪费。还有一个点，就是项目的配额，谷歌云对每个项目的各类资源都有默认配额，比如最多能开多少个实例，最多能占用多少带宽，如果你需要用到更多资源，要提前申请调整，不要等到要开新实例的时候才发现配额不够，耽误上线时间。
从实际使用的经验来看，谷歌云的资源划分逻辑偏向于更细粒度的拆分，刚接触的人需要一点时间适应这种逻辑，不要直接把其他平台的操作经验套过来，很多问题就是这么出来的。比如很多人习惯了自建服务器的时候所有端口默认开放，到谷歌云这里就容易忘了配置防火墙，这个习惯差异一定要注意。
总的来说，对普通开发者来说，用谷歌云不需要一开始就掌握所有的产品功能，先把常用的几个基础服务的概念理清楚，把安全、备份、告警这些基础配置做好，匹配好不同资源的适用场景，就能避开大部分常见的坑，稳定运行自己的项目。