Cloud Native 和运维，开发的锅我们不背

现在的互联网研发流程基本上离不开，产品、开发、测试、运维、运营这些角色，而这些角色之间互相看不上眼的，除了产品与研发这一对冤家外，就要数运维和开发了。

我见过一个最大的锅，要数一次补丁升级触发历史参数问题，开发没有考虑到某一个接入层应用接口的参数变化，出了事运维没有及时监控到并加以处理。部门老总直接降成副的，锅不可谓不大... 锅是一定会有的，这时问题就来了，锅谁背？

传统的做法是运维和开发一起背锅。

开发觉得我挺冤，运维处理问题不及时凭什么我要扛。运维觉得，开发一天到晚投版本，系统不稳定都是开发侧这些变更闹的。

有没有更好的解决之道？

腾讯云在 7.5-6 的云+未来峰会所倡导的 Cloud Native 理念, 包括 devops ，微服务，以及其他十二原则...

Cloud Native （云原生架构）意味面向可弹性调整存储、网络与计算能力的云计算环境而设计的软件架构，可适应快速变化、高度可扩展、高可用的业务需求。在云原生架构层面，减少出运维问题的几率..

I. 基准代码,一份基准代码，多份部署

II. 依赖,显式声明依赖关系

III. 配置,在环境中存储配置

IV. 后端服务,把后端服务当作附加资源

V. 构建，发布，运行,严格分离构建和运行

VI. 进程,以一个或多个无状态进程运行应用

VII. 端口绑定,通过端口绑定提供服务

VIII. 并发,通过进程模型进行扩展

IX. 易处理,快速启动和优雅终止可最大化健壮性

X. 开发环境与线上环境等价,尽可能的保持开发，预发布，线上环境相同

XI. 日志,把日志当作事件流

XII. 管理进程,后台管理任务当作一次性进程运行

Refer:http://12factor.net/zh_cn/

DevOps 原则不关心你你是系统架构师， DBA ，测试，或者是网络管理员。相同的规则覆盖所有的成员，每个成员都应该遵循两个简单的原则：

保持系统运作流程不可中断

随时提升和优化工作流程

相信这样的原则，对于背锅这件事带来的改变是从 Ops 到 Dev 的反向交流通道，运维哥哥要有机会给程序员们提意见，并得到反馈，以确保

“开发团队不会在周五下午 5 点后把代码交付进行部署，剩下运维团队周末加班加点来给他们擦屁股”

以上属于玩笑，开发与运维和谐相处的要点在于让锅少一点，而不一定是每次出事大家都要扯是谁的责任...

欢迎留言告诉我，你怎么看Cloud Native、或者是开发和运维的爱恨情仇...