架构师2014年7月：存储系统的那些事儿

卷首语 为什么会有DevOps？ 前一阵子看到一篇文章，内容是一个开发者吐槽DevOps，吐槽大意是 说，你们这些运维们凭什么提倡让我们开发者做本来是你们应该做的维 护工作？事实上运维和DBA又无法做开发者能做的工作，但你们却让开 发者做本来应该是运维和DBA应该做的工作，这样岂不是对开发者很不 公平？ 当时我看了这篇文章后心想，DevOps中的一部分的确是让开发做运维 的工作（另一部分是让运维会开发），作者说DevOps让开发者被压上 了更多的担子，的确没错。但是还有一点作者没说，就是他笔下的那 些“很多除了维护系统之外其他事情都不会做的运维和DBA”，实际上要 面临更大更严重的挑战——失业。 作者觉得这事儿对开发者不公平，我倒觉得开发者已经是身在福中的一 批人了。 前两天一个朋友打电话过来，问我能不能介绍一些云计算运维做的比较 好的同学，想跟他们交流交流。他之前看到了Github那一套Hubot的运 维工具，觉得很赞，未来云计算的运维就应该按照这种自动化机器人的 方式来做。我想了一下，忽然发现最近这两年自己接触的技术人当中， 关注运维的开发同学似乎越来越多了，而且也的确有越来越多的开发者 正在投入运维的工作当中去。 说到底，为什么会有DevOps这样的呼声出来呢？我感觉原因主要有两 点： 1、软件更新速度加快（算是敏捷开发运动+互联网爆发式增长联合作用 下的一大成果。现在的时髦语叫做“唯快不破”） 2、基于便宜的通用硬件+开源软件的集群系统越来越多、规模越来越大 （算是全球兴建云计算+全领域业务IT化的直接结果。云计算的口号 是“让普通人也用得起计算”） 这两个都是不可避免的业务需求，我们的世界不可能再回到那种缓慢更 新软件、做什么都采购IOE那些昂贵机器的时代了。几乎所有人都不得 不面临“交付速度加快”和“系统趋于分布式、规模更大”这两件事。 而这两件事情的直接结果就是，我们很容易就把系统中的这里或那里搞 坏了。 运维的同学们呢，不得不去实现“快速部署的同时还不能把这个大系统 搞死”的目标。 事实上，每次软件更新，引入的bug往往比feature多；便宜的硬件本身 就容易坏，数量多了之后更加是天天坏。以前的很多系统，每一个环节 都是正常流程中的一部分：任何一个环节坏了，系统就跑不动了。如果 按照现在的部署频率，很难想象这套系统能活下来。 我们需要一套具备超强容错能力的系统：这个系统中任何一个部分甚至 几个部分坏掉了，系统还是能跑起来——可能服务质量会低一些，但不 要死。 换句话说，我们的计算机网络系统正在从“线性系统”成长为“复杂系 统”。复杂系统是有生命的，能够在一定的阈值内维持自身的平衡。 这套复杂系统谁来实现呢？开发feature的同学......