卷首语
前一阵子看到一篇文章，内容是一个开发者吐槽 DevOps，大意是说：你们这些运维们凭什么提倡让我们开发者做本来是你们应该做的维护工作？事实上运维和 DBA 又无法做开发者能做的工作，但你们却让开发者做本来应该是运维和 DBA 应该做的工作，这样岂不是对开发者很不公平？
当时我看了这篇文章后心想，DevOps 中的一部分的确是让开发做运维的工作，作者说 DevOps 让开发者被压上了更多的担子，的确没错。但是还有一点作者没说，就是他笔下的那些“很多除了维护系统之外其他事情都不会做的运维和 DBA”，实际上要面临更大更严重的挑战——失业。
作者觉得这事儿对开发者不公平，我倒觉得开发者已经是身在福中的一批人了。
前两天一个朋友打电话过来，问我能不能介绍一些云计算运维做的比较好的同学，想跟他们交流交流。他之前看到了 Github 那一套 Hubot 的运维工具，觉得很赞，未来云计算的运维就应该按照这种自动化机器人的方式来做。我想了一下，忽然发现最近这两年自己接触的技术人当中，关注运维的开发同学似乎越来越多了，而且也的确有越来越多的开发者正在投入运维的工作当中去。
说到底，为什么会有 DevOps 这样的呼声出来呢？我感觉原因主要有两点：
1、软件更新速度加快（算是敏捷开发运动 + 互联网爆发式增长联合作用下的一大成果。现在的时髦语叫做“唯快不破”）
2、基于便宜的通用硬件 + 开源软件的集群系统越来越多、规模越来越大（算是全球兴建云计算 + 全领域业务 IT 化的直接结果。云计算的口号是“让普通人也用得起计算”） 这两个都是不可避免的业务需求，我们的世界不可能再回到那种缓慢更新软件、做什么都采购 IOE 那些昂贵机器的时代了。几乎所有人都不得不面临“交付速度加快”和“系统趋于分布式、规模更大”这两件事。
而这两件事情的直接结果就是，我们很容易就把系统中的这里或那里搞坏了。
运维的同学们呢，不得不去实现“快速部署的同时还不能把这个大系统搞死”的目标。
事实上，每次软件更新，引入的 bug 往往比 feature 多；便宜的硬件本身就容易坏，数量多了之后更加是天天坏。以前的很多系统，每一个环节都是正常流程中的一部分：任何一个环节坏了，系统就跑不动了。如果按照现在的部署频率，很难想象这套系统能活下来。
我们需要一套具备超强容错能力的系统：这个系统中任何一个部分甚至几个部分坏掉了，系统还是能跑起来——可能服务质量会低一些，但不要死。
换句话说，我们的计算机网络系统正在从“线性系统”成长为“复杂系统”。复杂系统是有生命的，能够在一定的阈值内维持自身的平衡。
这套复杂系统谁来实现呢？开发 feature 的同学们是不会 care 的，这不是他们的领域。只懂得维护一台服务器和一个小集群的运维同学是做不到的，因为他们不知道如何为一个死的系统注入生命。
这就是为什么会有 DevOps，这就是为什么我们需要懂开发的同学们来运维系统。
本期主编：杨赛
目录
- 卷首语
- 2 | 为什么会有 DevOps？
- 人物 | People
- 6 | 郑晔谈 Java 开发：新工具、新框架、新思维
- 观点 | Opinion
- 10 | OWASP 发布构建安全 Web 应用的十大控制措施
- 14 | 替代 Objective-C？Swift 尚不成熟
- 16 | 让我们再聊聊浏览器资源加载优化
- 专题 | Topic
- 39 | Apache Kafka：下一代分布式消息系统
- 52 | SLIK：高扩展、低延时的键值存储索引实现（RAMCloud）
- 62 | 存储系统的那些事
- 避开那些坑 | Void
- 68 | J.P. 摩根运用 LeSS 框架实施大规模敏捷
- 76 | Node.js 异步处理 CPU 密集型任务的新思路
- 82 | 分布式存储系统的雪崩效应
- 特别专栏 | Column
- 88 | 腾讯云的弹性、高可用与隔离
- 90 | AWS S3 产品总监谈存储
- 94 | 搜狐云景 Container 经验谈
- 封面植物
评论