大数据运维三十六计
随着互联网的发展，大数据正在以惊人的速度被创造和收集着，尤其随着诸如Google和Alibaba等互联网公司的崛起，数据的价值越来越得到认可，甚至被公司定义为战略资源。因此越来越多的公司开始搭建自己的大数据平台，用来处理数据，从中挖掘商业价值。大数据运维正是在这样的背景下发展起来的，它与传统领域的运维有很多共性的地方，也有一些自身的特点。
第一个特点是规模大
大数据领域单个集群的规模一般是几百台物理机，多则上万台。为了满足容灾需求，一般会有多个集群，而且是跨地域部署的。集群规模大了之后各类异常事件会成为常态，譬如硬件故障、网络故障等，这对我们提出了如下几点要求：
- 需要使大数据平台架构具备容忍单机故障，甚至是单集群故障的能力。
- 需要有自动化的运维平台来处理这些常见的日常运维事务，包括硬件维修和服务部署，否则运维成本会很高。
- 需要更加关注底层IDC的架构，要考虑机房的地域分布（既满足容灾要求，又不能太分散）、机房的扩展性、机房的电力、机房间专线的带宽和QoS策略等。
- 要学会用大数据来运维大数据平台。运维的集群规模变大以后，产生的各类日志和事件也是大数据级别，我们要学会用大数据来运维大数据平台。通过数据分析发现平台隐患，更快地定位问题，提升平台稳定性，提升运维效率，同时数据分析也可以帮我们更精细化地管理资源，做到合理采购。
第二个特点是分层
大数据平台实质上是提供大数据的PaaS服务，基于大数据平台会有很多的大数据应用，包括各类离线报表、机器学习、OLAP、实时分析等。大数据运维人员一般只需要负责大数据平台的运维，平台之上具体的业务层都会有自己的应用运维人员。所以大数据运维人员要有能力快速地定位和区分哪些是平台问题，哪些是业务问题。如果把两者混在一起，那么基本上会时刻处于忙碌状态。
本文作者 范伦挺 从事运维工作已经快10个年头，最近7年都在做大数据平台相关的事情，一路走来自己踩过一些坑，也看到别人踩过一些坑。借此机会，将这些经验整理成一条条短句分享出来。希望能让大家的日常工作有所受益！也希望做大数据运维的同学能够通过自身努力，用大数据改变运维，把运维带入到一个数据驱动的智能运维新时代！
大数据运维三十六计之 确保稳定 篇
第一计：数据是大数据之本，宁可停服也不可丢数据。
第二计：不可关闭数据平台回收站功能，任何删除都要默认进回收站，切 勿偷懒跳过。机器或者数据下线一定要有静默期。
第三计：重要数据要有异地灾备，仅同城是不够的。
第四计：所有配置里的密钥要加密存储，关注平台安全。
第五计：大数据平台的控制服务要有机房间切换能力，以加快故障恢复速度。
第六计：大规模系统发布一定要分级灰度。
第七计：多租户系统的quota限制和隔离技术是关键。
第八计：要有很好的各维度TOP N资源占用情况实时分析能力。
第九计：平台运行SLI要对用户透明，避免用户经常怀疑是否是平台有问题。
第十计：平台问题要第一时间公告给用户，否则各种询问的唾沫会淹死你。
第十一计：大数据存储瓶颈除了容量，文件数也是一个大问题。
第十二计：离线作业要有基线关键路径产出时间预测系统，提前预警，否则没有足够时间重跑。
第十三计：实时计算链路长，延时敏感，要有各阶段的详细监控指标，方便问题定位。
第十四计：实时计算要注意热点机器，一粒老鼠屎坏一锅汤。
第十五计：实时计算平台对于延迟很敏感，布局规划上要贴近数据源。
第十六计：实时计算重要业务要通过双链路灾备保证业务稳定性。
第十七计：大规模计算平台至少要能容忍单机故障，否则别让它上线。
第十八计：大数据平台要有服务迁移能力，因为终有一天机房会容不下。
第十九计：大数据平台流量大，共享网络一定要有QoS隔离，否则你将成为众矢之的。
第二十计：大数据平台是电老虎，注意上架密度。
第二十一计：业务规划要提前和机房对齐，否则IDC建设和供应链都很难满足。
第二十二计：用户的突增需求要提前收集，避免资源不足，巧妇难为无米之炊。
第二十三计：多master的物理分布要满足不同机架和交换机要求。
大数据运维三十六计之 控制成本 篇
第二十四计：密切关注集群的水位利用效率，优化一个点都是大把的钱。
第二十五计：按照波峰波谷区别定价，引导用户合理提交任务。
第二十六计：建立作业和存储健康分模型，引导用户做资源优化。
第二十七计：在业务低峰期适合跑一些系统任务，如merge，archive等。
第二十八计：离在线混布可以节省不少资源，但隔离能力是关键。
第二十九计：存储计算分离架构可以扩大混布范围，并且尽快拿到硬件红利。
第三十计：存储需求要预测准，计算资源还可以挤挤，hdd&sdd 混合存储提升shuffle性能。
第三十一计：要储备计算换存储或者存储换计算应急方案，解决临时资源缺口。
第三十二计：规模大、压力大，要时刻关注硬件和网络发展，尽快拿到科技红利。
第三十三计：硬件资源的配比要有预见性，技术迭代比机器过保快。
大数据运维三十六计之 提升效率 篇
第三十四计：大规模和小规模场景不是量的变化，而是质的差异，一定要做好自动化。
第三十五计：自动化工具是生存之本，也是危险根源，一定要有严格测试。
第三十六计：要善于利用大数据运维大数据，运维数据的积累和分析很关键。
案例：欲速则不达——直接删除惹的祸
诚然，上述每一条计策背后都一段刻骨铭心的故事，但篇幅有限无法与大家一一分享，我们在这里仅分享第二计（不可关闭数据平台回收站功能，任何删除都要默认进回收站，切勿偷懒跳过。机器或者数据下线一定要有静默期）背后的一段血泪教训。其实，第二计不仅适用于大数据运维，对传统的数据运维也适用，虽看似简单，却至关重要。
故障来袭
在一个风和日丽的星期天，某公司资深IT男小明正惬意地享受着宅男的周末生活，戴着耳机，手指飞快地在键盘上敲打着。看着一行行code往下延伸，小明嘴角露出一丝满意的微笑。他品上一口咖啡，提提神，继续努力。突然一阵急促的电话铃声响起，小明懒懒地瞥了一眼：又是该死的电话报警。他接起来，静静地听电话那头生硬的电脑语音播报：“异常告警，监控项disk_full状态critical，水位超过了90%，详情查看****。”
故障排查
哎，coding正high呢，又被打断。无奈，小明放下手头的活儿，开始登录系统查看情况。小明查看了整个集群的存储水位，分析了增长趋势，查看了TOP N目录，整体看下来没有发现当前突发的异常事件。不过存储增长趋势从周三开始变快了，对比查看近期的变更操作列表，发现周三有一个变更，变更原因是：新系统切换调试需求，要求将队列缓存数据保留时间从3天延长至5天。此时，作为资深运维人员的小明对报警的原因已经心中有数了，处理这种故障也是小菜一碟。小明拿起了电话，联系了新系统联调测试的负责同学小静，告知小静当前平台存储告警，需要先做清理，等周一上班后再从长计议。小静表示没问题。
故障处理遇险情
放下电话，小明开始在心里盘算接下来怎么操作。他决定采用最快最直接的方法，把多保留的数据直接从HDFS删掉。这时告警电话铃声再次响起，小明想到即使从HDFS直接删除，还会先进回收站，报警依然会持续。先删除，再清理回收站？想想都觉得麻烦，反正是要立马删除释放的，不如直接跳过回收站删除（hadoop fs -rm -r –skipTrash ），干净利落！说干就干。
他立即登录console，各种查看确认路径，先拼好要删除的路径，把路径复制出来，再console粘贴……悲剧发生了，复制的命令中间有换行，删除了上上层目录！身为资深运维人员小明也算见过各种世面，但面对这个场景，还是瞬间觉得整个人被电流击穿，惊出一身冷汗！
小明赶紧采取紧急措施，停止HDFS服务紧急止血，上报故障，拉相关同学一起处理故障。经过各位大神的努力，从nn 日志里回滚了删除操作，重新启动服务。但是已经下发并删除的部分chunk已经回天乏力。之后是漫长的扫描损坏文件，以及与业务同学一一确认后续操作方案（删除损坏文件并重新导入，也有些永久丢失）。
启发
从上面这个故事中我们可以学到三个注意点：
- 做变更时要评估好变更的影响，例如保留时间从3天延长至5天，可能引起的存储增加要有定量评估，不能随意拍脑袋决定。
- 删除操作一定先进回收站，再清理，给自己留条退路。
- 一般不推荐使用复制/粘贴命令，如果要用，一定要注意是否有空格和换行，默认在命令行先敲个#再粘贴。
流程和规范都是历史经验的总结，千万不能为了少敲几个命令而偷懒。血的教训再次告诉我们，任何操作都有风险，一定要走一步检查一步，每走一步都给自己留check的时间和回滚的机会。不要为了快或省事而大踏步往前走，看起来比老运维还牛逼高效，但是一旦踏空，想收都收不住脚，只能堕入万丈深渊。重要的事情说三遍：
任何删除都要默认先进回收站，切勿偷懒跳过！ 任何删除都要默认先进回收站，切勿偷懒跳过！ 任何删除都要默认先进回收站，切勿偷懒跳过！
本文节选自《DevOps三十六计》一书，预计2017年11月出版
本书“大数据运维”部分作者：范伦挺，已在运维领域摸爬滚打近10年，GOPS 全球运维大会金牌讲师。2010年入职阿里，现任阿里巴巴计算平台事业部高级技术专家，负责实时计算平台运维工作。在超大规模集群运维理念和运维产品建设领域具备丰富的经验。