这是从古自今所有人都在追问的终极问题之一，😂。

国内的没有任何必要，可以考一些产业界推出的认证，比如云平台 aws ，gcp ，azure ，或者其他类别证书。这类是某些职位所必须的有价值的证书。

99%情况想都不用想直接 oss ，比如 s3 这类，各种细致的需求，比如安全，加密，性能，成本，集成，都容易太多。等你发现 s3 这类服务确实有无法满足的需求，你再次评估，搞 minio 或者其他类似服务。

ansible 还是不错的，不过现在 provision 的方式太多了，大部分 distro 都支持 cloud-init ，launch 的时候大部分配置需求都可以满足。更复杂的情况才会考虑 ansible ，chef 这类。

你找的文档和你的操作系统版本不一定一致，里面可能会有细小的差异，你需要一些基础才能识别这些简单问题。比如可能就是一个 systemd 注册的名字和你输入的命令行不一样，你到 systemd 的注册目录去查看一下对应的名字，或者使用 systemctl 把已经注册的服务 list 出来，就知道 mysql 这一项具体叫什么了。所以关键在于你对 linux 系统上后台服务的基础管理知识。

用日志服务？

saas 或者自建都可以的。

https://betterstack.com/logs
https://uptrace.dev/

好吧，那需要回来再看看你的应用是怎么和 lambda 交互的了。如果你的不同来源只能在应用逻辑里面才能区分，那你可以使用自定义 metrics 把用于区分不同业务逻辑来源的信息 publish 出去，这样 metrics 里面就多出来你自定义的 field ，可以实现分组。

如果你的调用来源在应用逻辑以外就能区分，比如 resource group 这种，固定好的静态调用关系，那就不需要自定义 metrics 了。

https://docs.aws.amazon.com/ARG/latest/userguide/supported-resources.html

有限制需要使用 cloudformation ，也就是你的部署工具需要操作最终生成的 cloudformation 模版，附加 resource group 。

这个问题在文档里面有方案，使用 resource group 给负载打标签分类，比如项目或者部门这样的信息作为分类，lambda 的 metrics 会自动附加这些信息。

https://docs.aws.amazon.com/lambda/latest/operatorguide/organize-workload.html

@ztmark 上 appcode

@qiuai docker其实正好可以做统一部署环境这个问题，你可以在一个镜像上安装好你需要的所有运行时环境，像node，python，ruby相关工具等等。然后在每个vps上可以直接导入docker镜像就行了。

我的android开发环境就是这样做的，每次安装sdk，更新sdk，安装ndk，太麻烦了。