大多数运维人员在公司中的地位不高，而且在行业中的薪资相对偏低，究其原因还是因为运维的从业门槛低，大家对运维的认知度不高。因此，季昕华认为，除了上述基本知识，运维人员还因具备以下三方面的素质：

1. 懂业务 ，例如要能理解产品的用户是一线城市还是二线城市，是PC端还是移动端，在对业务有足够的了解的情况下，才能让你的工作成为领导关心的事。

2. 运营化 ，将运维中的意外管理变为过程管理，并能持续改进、持续优化；运维要能做到四个“第一”，即第一时间发现问题，第一时间定位问题，第一时间解决问题和第一时间反馈问题。

3. 系统化 ，要能通过各种系统来辅助运维工作，甚至要能自己开发运维系统。

目前摆在大家面前有几个瓶颈，第一是成长空间有限，在公司的地位不高，行业内的知名度也不高；第二是云计算可能会革掉很多运维人员的名，很多小的初创企业甚至都不需要运维；第三是人员转型困难大。

当然，机会也有不少，比如，互联网正在快速地改变传统行业，之前兴起的O2O浪潮就是很好的例子，运维人员可以帮助那些传统行业快速地成长；大数据的到来也为大家打开了一扇窗户；另外就是云计算，当你能把一个行业做精做细，就能把它挖掘成一个产业，例如又拍云、DNSPod、监控宝和安全宝都是最好的例子。

季昕华建议大家在使用那些免费的运维服务时，如果可以，就更多地向他们付费，让公司知道运维也是有价值的。当台下有开发的同学问到该如何帮助运维同学时，几位嘉宾都讲到了如果能够做到DevOps那是最好的，不要再出现这样的情况：

既然云是本次大会的一个重要主题，那自然少不了云存储的内容。来自七牛的韩拓为大家介绍了七牛在建设云存储方面的一些做法，他的分享分为两部分——底层存储和构建于前者之上的云存储，两者在设计上有着截然不同的地方。

底层存储有以下难点：

• 元数据管理

• 对冗余度的控制（副本的数量与成本的平衡点）

• 修复速度（直接影响存储系统的可靠性，在七牛恢复是集群任务，盘上数据的副本松散地保存在集群中，目前能做到在十几分钟到几十分钟内修复2到3T的数据）

• 应对容量的增长

• 可接受的访问速度

• 合理、有效的缓存

七牛在网络上采用了常规的千兆局域网，这是考虑到了它的成熟度和成本，在机柜之间无法保证任意两点间随时都是千兆，甚至无法保证全联通，而机房之间的速度，带宽成本很高，速度与连通性都无法保证。因此，数据存储的位置需要有一定的平衡，副本在同一机柜和不同机柜各有利弊，机房亦是如此。

在故障方面，除了要将故障视为常态，更要能明确地知道要面对哪些故障，它们的成因、概率和影响范围。

例如，常见的故障有：

1、机房内故障

• 网卡（断线、降速）

• 网线（断线、降速）

• 交换机（整体故障、单口故障、VLAN故障）

• 机柜级联故障

2、机房间故障

• 区域性网络故障（机房出口断网）

• DNS解析故障（服务器之间DNS）

对于机房内的故障，不需要投入太多的资源成本做额外的高可用方案。

在网络安全上，除了必要的基础防御之外，更重要的是业务层面的防护，公有云的基本原则是开放，任何服务可以无条件暴露于公网，机房间的交互与客户无差别，不组VPN。

云存储构建于基础存储之上，它要能提供极高的上传、下载速度，有极高的可用性，有极高的可靠性，有丰富的附加功能（缩略图、水印等等），方便的网络访问。

它的难点在于：

• 云存储属于终端网络，它直接面对用户，情况复杂；它是最外层的接入点，前端没有机会做遮挡，对各种指标要求高。

• 广域网基础设施普遍质量不高，要基于99%可用的基础设施来提供99.999%的服务。

提到基础设施，机房的网络是个大问题，网络延时可以从几毫秒大到几千毫秒，吞吐速度从几十Mbps到几Kbps，而且带宽平均成本也不便宜。机房的可用性并不理想，经常会有链路故障，甚至是大面积、区域性掉线、降速，不仅机房间有问题，机房内也会频繁故障，小城市、小运营商用户会有个例无法访问的现象（七牛为用户提供了下载SDK，在APP和Web上连接到本区域节点下载不到内容时，可通过SDK连接备用域名和IP）。

七牛对数据进行了跨机房冗余，除了可靠性，更多地是为了可用性考虑；数据同步采用了分级异步同步的策略，最热的数据秒级异步同步，而冷数据则会批量同步；成本方面，冗余度的提升并未造成线性的成本提升，同时，异步同步还能智能地利用昂贵的带宽资源。

提供云存储的又拍云，为大家带来了与CDN与DDoS防御方面的一些经验。邵海杨先是介绍了两种DDoS的主要攻击类型，即缓慢性CC攻击和致命流量攻击，在他的日常工作中，遇到较多的是后者，来得快去得也快，不差钱的主经常选择这种方式。他指出：

黄冬曾经表示过，要防御DDoS，直接交给CDN就行了。邵海杨的观点与他不谋而同，自建CDN有以下考量：

• 硬件成本（1U的机箱放多块主板，成本大约在一万五到两万之间）

• 带宽成本（双线带宽贵，做CDN加速不需要双线，只需要单线机房即可，每兆大约只需1块多）

• 架构设计

• 配置要点

• 智能脚本

他对比了Squid、Varnish、Nginx、Apache Traffic Server（ATS）和HAProxy的强弱，目前又拍大量使用了ATS，集群规模已经超过200台，ATS的集群功能现在还不完善，可以通过Nginx在前面做一层一致性Hash的转发，规避ATS的集群问题。另外他也强调了HAProxy强大的HTTP头解析能力，是用来充当防御层的合适选择。可以根据具体的用途进行选择：

• 反向代理（路由加速，隐藏主节点）：HAProxy>Nginx>Varnih>ATS>Squid

• 缓存加速（静态加速、节省带宽、边缘推送）：ATS>Varnish>Squid>Nginx>HAProxy

• 防御功能（快速解析、过滤匹配）：HAProxy>Nginx>ATS>Squid>Varnish

此外，选择的系统最好还要能支持文件读取和匹配，支持热加载生效和可插拔式的缓存组件灵活组合。

架构是需要持续改进的，又拍云的CDN就经过了这样一个过程：

• 智能DNS区域化（又拍云负责部署节点，通过DNSPod实现智能节点选择，自动选择离用户最近的节点，以此实现全网加速）

• 大规模日志分析（如何从日志中提取恶意代码进行分析？又拍云在Nginx中增加了一个模块，将最近的URL保存在内存中，以便实时分析，此外还有一个Hadoop集群分析日志）

• 后端管理不直观（使用OpenCDN来提供多节点CDN管理平台）

CC和DDoS可能会交叉进行，用HAProxy加后端存储，是应对小流量攻击的，如果在承受范围内，可以选择不切节点，但是如果遇到大流量DDoS攻击，可以立刻选择切节点。邵海杨强调到防御DDoS攻击，要靠技术、靠业务，更要获取高层的支持 。

在讲了很多公有云相关的技术之后，支付宝的章邯为大家带来了一些与支付宝的私有云环境有关的内容，他介绍了支付宝私有云中的以业务为核心的监控产品。

在支付宝，除了常规的运维监控和应用监控，还有更多其他的诉求，例如业务监控、合作伙伴监控和SOA环境监控。

章邯特别强调了一个概念——业务分析，它在支付宝的监控体系中起着至关重要的作用：

• 实时BI——有时不是为了排查故障，而是为了确认没有问题

• 确定故障范围——不同的业务特征，代表了不同的故障影响范围；不同的影响范围，应急人员有不同的策略

• 业务与合作伙伴——比如银行，单个银行下跌，可能是银行的问题，所有银行下跌，可能是支付宝的问题

• 业务与应用的关系——通过监控不同的业务，可以快速定位故障

• 业务与业务的关系——虽然没有系统间的直接关系，但业务直接确实有可能会存在相互的影响

• 业务与运维策略的关系——例如，确定机房引流，流量的分配

• 业务与管控策略的关系——管控策略有很多，比如分组、降级、限流和引流，管控策略的制定和业务是息息相关的

很多公司都会采用在系统中埋点的做法进行监控，而支付宝则采用了业务分析结合现象分析的做法来进行实时故障应急处理。章邯指出：

随后，他简单介绍了一下支付宝内部基于日志的监控解决方案XFlush，其中借鉴了Percolator、Storm、Spark、HayStack、GFS和RDDS的很多思想。XFlush追求的是低侵入性、增量计算、不保存原始数据、保证时效性、保证数据准确性、保证可扩展性、避免冗余计算和计算逻辑可扩展性。为了实现上述内容，甚至还实现了一套定制的分布式文件系统XStore，它的特点是能够无限扩展，纯粹为周期统计计算和固话监控点常见而定制，能做到极低的IO，提供高速、无IO的元数据检索。

数据库的运维也是运维的重要工作，作为一个运维大会，自然少不了数据库相关的内容，ThinkInLAMP创始人马骏和MySQL技术专家金官丁分别为大家带来了很多MySQL数据库运维相关的经验分享。而来自金山网络的安全专家赵闽还和大家讲述了很多与Android安全相关的故事，在一个个的故事里让大家感到移动端的安全也是个重要的领域，金山的火眼系统值得关注。

如果您也从事运维行业，或者是对运维感兴趣，那么现在会是个不错的机会，云计算时代中，机遇与挑战并存，如果能选择勇敢地接受挑战，一定会发现运维的领域也可以很精彩。