DevOps 与云
DevOps 工作，就是把发布软件从一场「事件」变成一件例行公事。我们搭建流水线、基础设施定义与监控体系，让团队在周二下午就能部署，而不必有人屏住呼吸。对一个交付缓慢的团队来说，这通常是杠杆率最高的一类工作，因为它的收益会在此后每一次发布中不断累积。
我们通常从哪里入手
第一个问题是：今天究竟是什么让发布变得痛苦。答案决定了工作的先后顺序，而它往往不是人们预期的那一项。
- CI/CD：自动化构建、测试与部署，让发布可重复。
- 基础设施即代码，让环境可以被重建，而不是靠人脑记住。
- 可观测性：日志、指标与链路追踪，能在故障期间真正回答问题。
- 云成本：找出那些花了钱却什么也没买到的开销。
Kubernetes——但只在它配得上这个位置时
Kubernetes 在足够大的规模下解决真实的问题，在那个规模之下则会制造新的问题。只有当负载规模足以抵得上那份运维成本时，我们才会用它；否则我们会推荐更简单的方案。一个你的团队在凌晨三点调不动的平台，无论多现代，都是负债。
不搞一步到位的云迁移
迁移之所以失败，往往是因为搞成了全有或全无。我们分步迁移负载，每一步都保留回滚能力，并且在迁移前后测量成本与性能，让业务收益是被验证过的，而不是被假定的。
常见问题
- 你们支持哪些云服务商？
- 以 AWS 为主；如果你现在用的是别家，我们也一样能做。单纯为了换云服务商而迁移，很少值得——收益通常来自负载如何架构，而不是账单上印着谁的标志。
- 你们能降低我们的云账单吗？
- 通常可以。第一轮排查一般会发现闲置资源、配置过大的实例，以及无人认领的存储。我们会汇报发现了什么、修复需要什么代价，由你决定哪些值得动手。
- 你们提供 on-call 值班支持吗？
- 我们可以运维自己构建的系统，包括监控与响应。具体条款取决于你需要的覆盖范围——把你的可用性要求告诉我们，什么是现实可行的，我们会讲具体。