微信号:infoqchina

介绍:有内容的技术社区媒体

【架构师】(7月刊)卷首语

2014-07-11 18:13 杨赛

前一阵子看到一篇文章,内容是一个开发者吐槽DevOps,大意是说:你们这些运维们凭什么提倡让我们开发者做本来是你们应该做的维护工作?事实上运维和DBA又无法做开发者能做的工作,但你们却让开发者做本来应该是运维和DBA应该做的工作,这样岂不是对开发者很不公平?


当时我看了这篇文章后心想,DevOps中的一部分的确是让开发做运维的工作,作者说DevOps让开发者被压上了更多的担子,的确没错。但是还有一点作者没说,就是他笔下的那些“很多除了维护系统之外其他事情都不会做的运维和DBA”,实际上要面临更大更严重的挑战——失业。


作者觉得这事儿对开发者不公平,我倒觉得开发者已经是身在福中的一批人了。


前两天一个朋友打电话过来,问我能不能介绍一些云计算运维做的比较好的同学,想跟他们交流交流。他之前看到了Github那一套Hubot的运维工具,觉得很赞,未来云计算的运维就应该按照这种自动化机器人的方式来做。我想了一下,忽然发现最近这两年自己接触的技术人当中,关注运维的开发同学似乎越来越多了,而且也的确有越来越多的开发者正在投入运维的工作当中去。


说到底,为什么会有DevOps这样的呼声出来呢?我感觉原因主要有两点:

1、软件更新速度加快(算是敏捷开发运动+互联网爆发式增长联合作用下的一大成果。现在的时髦语叫做“唯快不破”)

2、基于便宜的通用硬件+开源软件的集群系统越来越多、规模越来越大(算是全球兴建云计算+全领域业务IT化的直接结果。云计算的口号是“让普通人也用得起计算”) 这两个都是不可避免的业务需求,我们的世界不可能再回到那种缓慢更新软件、做什么都采购IOE那些昂贵机器的时代了。几乎所有人都不得不面临“交付速度加快”和“系统趋于分布式、规模更大”这两件事。


而这两件事情的直接结果就是,我们很容易就把系统中的这里或那里搞坏了。


运维的同学们呢,不得不去实现“快速部署的同时还不能把这个大系统搞死”的目标。


事实上,每次软件更新,引入的bug往往比feature多;便宜的硬件本身就容易坏,数量多了之后更加是天天坏。以前的很多系统,每一个环节都是正常流程中的一部分:任何一个环节坏了,系统就跑不动了。如果按照现在的部署频率,很难想象这套系统能活下来。


我们需要一套具备超强容错能力的系统:这个系统中任何一个部分甚至几个部分坏掉了,系统还是能跑起来——可能服务质量会低一些,但不要死。


换句话说,我们的计算机网络系统正在从“线性系统”成长为“复杂系统”。复杂系统是有生命的,能够在一定的阈值内维持自身的平衡。


这套复杂系统谁来实现呢?开发feature的同学们是不会care的,这不是他们的领域。只懂得维护一台服务器和一个小集群的运维同学是做不到的,因为他们不知道如何为一个死的系统注入生命。

这就是为什么会有DevOps,这就是为什么我们需要懂开发的同学们来运维系统。


本期《架构师》主要内容:《郑晔谈Java开发》、《Swift尚不成熟》、《让我们再聊聊浏览器资源加载优化》、《存储系统的那些事》、《腾讯云的弹性、高可用与隔离》、《AWS S3产品总监谈存储》、《搜狐云景Container经验谈》。感兴趣的读者可以点击“阅读原文”下载本期杂志。


 
InfoQ 更多文章 Facebook如何实现PB级别数据库自动化备份 学术派Google软件工程师Matt Welsh谈移动开发趋势 Spotify为什么要使用一些“无聊”的技术? 妹纸们放假了,汉纸们做啥? 大多数重构可以避免
猜您喜欢 为设计师准备的 10 个最棒的 Chrome 扩展插件 投票攻略 途牛原创 | 自动化测试平台TAP-页面自动化测试 Android Low Memory Killer 金融行业大数据的应用案例分享