统一返回 200 以及统一 POST 一把梭，如果明确了错误返回结构，统一了各个基础设施的认知，建设了响应的工具。没问题，你甚至可以剥离掉 HTTP ，剥离掉 Cookies ，什么都不用。就是把 HTTP 当作传输层。

如果上面三者做不到，干嘛不遵循标准的 HTTP Schema 协议？

12 年了啊，那你应该问他 IE 6/7/8 怎么做兼容方案？

> 运维方向（ SRE 、Devops 、云原生）

运维 = Operation ，即事务性操作。

SRE 一般是大规模团队才拆分，在小团队里面 SRE 很可能等同于传统运维。

DevOps 一般是效能团队负责，如果公司规模小，就是搭建一下 Gitlab / Jenkins ，也演变为运维。

云原生就更宽泛了，是一个大方向集合，狭义上面是容器和调度相关，宽泛概念上是面向云 /资源的技术都算。这个领域里面本身就有各类 Title：研发、测试、运维、架构师、解决方案。

根据你的背景，如果是在小团队，适合运维多面手。在大团队，就要选择具体角色了，如果没有研发背景，选择面就少了。

个人建议，先去小而精规模团队。

首先 SRE 应该是一位开发工程师（甚至应该是非常资深，才能具备技术判断力）。职责是服务全站业务、系统，提供工具、平台、机制保障大规模范围的可用性。也有特定岗位 SRE 服务于特定的复杂系统。

该岗位产生的原因还是职责细化，小团队不应该需要这样的岗位，直接把职责打包给基础设施团队或架构团队就可以了。

这个项目目前阶段，不是开箱即用的产品。可以等待它再发展一下，同时有些理念还是可以去学习一下的。

哈，liluo ，有品味的工程师，帮顶一下。

Cool.

@Willem97 有，可以加 v 细聊。

@fengsien1999 上海陆家嘴，北京环球金融中心。

@zkw111 我的套路比较固定，不代表所有同事。

1. 围绕过往项目问题，包括业务域问题、设计思路、挑战和方案
2. 硬的（语言、Kubernetes 相关、计算机基础、设计题、常见中间件
3. 软的（闲聊为主）
4. 在线笔试

好文艺的名字，有个同学开的甜品店，也叫多云转晴。

@XTTX 看规模和解决的问题。总体而言，Terraform 做 IaaS 管理很方便啊，Ansible 则更适合小规模管理（个人观点）。

我这里不使用这两者，有专门的平台管理集群，也有独立的 Operator 管理节点。

@FabricPath 那确实，kind 适合 Operator 开发。

@FabricPath 本地开发的话，kind 可以了解一下。不过有需要自研 Kubernetes 组件的团队，肯定能提供一套完整的开发环境的，不用本地资源。

@bruce0hh 没有复杂的要求，如果有练习过刷题肯定没问题。如果没准备也没关系，可以交流一下其他亮点项目 / 贡献。

我找到我的原因了，我的显示器外接线（ USB 扩展线）干扰了 Trackpad 。

容器调度领域人少，本帖子长期有效，详情可以扫码细聊。

看上去是对标 Rancher ？

3-5 开启简历投递了，感兴趣的同学快来试试哦。