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

2016-07-02 00:59:51 +08:00
 whyishe

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

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

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

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

有没有更好的解决之道?

腾讯云在 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、或者是开发和运维的爱恨情仇...

4419 次点击
所在节点    程序员
1 条回复
chloerei
2016-07-02 18:24:57 +08:00
12-Factor 是 Heroku 创始人提出的, Heroku 创立于 2007 ,现在基于容器的持续集成、持续发布都在追随 Heroku 的脚步, Heroku 领先业界 N 年。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/289733

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX