背景
同事发现一个有重要服务在运行的物理机上，一个目录虽然够用，但是比另一台同样服务的机器相比，空间很小。我们还是跟SA沟通了此事。最终SA跟厂商确认是因为磁盘有坏道引起。因为我们磁盘阵列采用的是RAID1模式，所以并不影响服务运行，但是为了保证服务的稳定性，我们还是决定对磁盘进行修复。
结果呢，在约好的时间点，大家按照操作流程很轻松的修复了。但是前期我们做了很多工作。如果实际操作的时候并不轻松，而是突然出现了意外的情况或者没有考虑到的步骤，虽然最终结果是有惊无险，那也说明我们的前期准备是非常失败的。如果是一次飞机飞行，那就是在拿着生命开玩笑了。而轻松完成也只是入门等级，整个过程，我给自己打60分。
涉及的一些基本硬件知识
RAID
RAID是磁盘阵列，常用的模式有RAID0、RAID1、RAID5、RAID6、RAID10（这里读RAID一零）。
RAID0是机器使用两块硬盘，写文件的时候，采用分片模式，就是把文件拆成均等的两块，同时写入，这样速度比使用一块硬盘提高一倍。可用容量为硬盘容量之和。
RAID1是机器使用两块硬盘，写文件的时候，采用镜像模式，就是把文件写入一块硬盘，之后再复制一份到另一块硬盘。这样速度和一块硬盘基本相同，两块硬盘容量其实只能用一半。但是通过冗余进行容灾，可以允许一块硬盘损坏，不影响服务的运行。我们这次就是这种情况。
RAID5又称为分布式磁盘，是兼顾容量、速度和容灾的一个方案。至少要有3块硬盘组成，采用单校验机制(XOR校验)。原数据和校验数据会分开均匀保存到各块磁盘上。可允许一块硬盘损坏。举个例子，我有一段数据要保存，内容是：
1 2 3 4 5 6
则：
| 硬盘1 | 硬盘2 | 硬盘3 |
| 1 | 2 | 1+2 |
| 3 | 3+4 | 4 |
| 5+6 | 5 | 6 |
RAID6是在RAID5的基础上又增加一种校验方式，至少要有4块盘，从而可以允许两块硬盘损坏。由于复杂度高，功能比不高，所以一般RAID10或者RAID01这样的组合模式更常用。RAID10是组合RAID1和RAID0，用4块硬盘。数据有一块盘做镜像模式，一块盘做分片模式，虽然容量还是只有一半，但是速度提高了一倍，也可以容灾。
rebuild
采用RAID1模式，一块硬盘损坏，要更换可以采用热插拔，之后会执行2到3小时的rebuild操作。rebuild过程重要做：磁盘检查和数据复制两件事情。
根据不同的硬件型号，rebuild过程中会有指示灯显示磁盘状态。比如有的rebuild过程中显示黄色，完成后显示绿色，代表状态是online。
rebuild过程实际不影响服务运行，但是这个过程中读写硬盘会比较频繁，通常建议隔离业务。
事件处理过程
事件处理开始，我们看到的现象就是根目录的空间很小，其他目录都是好几百G，这个目录只有十几G。经过层层追问，最终和厂商一起查出是磁盘坏道引起。SA希望我们把业务隔离1天。而这个服务比较特殊，受外部制约，使用了一个十几年前架构的闭源MQ。我们只有两机房部署，每个机房都是单机运行，其他备份都是冷备。所以整体而言，磁盘修复过程中是单机运行的。所以我们和SA沟通，尽量缩短修复时间。最终我们的整个包含隔离和恢复业务耗时缩短为7个小时。做好准备之后，我们把整个处理过程整理成完整的时序；设计好异常处理流程；为了应对磁盘修复不好这种场景，我们制定了磁盘回退的异常处理；为了应对不但磁盘没有修好，反而整个物理机不能用的场景，我们制定了不得已启用冷备机器的异常处理，这个处理需要进行网络变更，流程复杂，所以更要提前沟通好；然后我们统计好处理当天的业务量，估算好最坏影响时的影响的交易；还带上厂商的分析等数据。总共打印出四张纸，我带着去找领导汇报。
结果领导的两个问题，证明我没有把事情彻底搞清楚。一个是每个机房真的只能一台机器运行吗？因为用的MQ是闭源的，对接方也不清楚到底是为什么只能一台机器运行。确认的事情是对接方一个机房只给了一个IP，之前也咨询过网络，是否可以使用虚拟IP。网络说不可以，但是具体的理由说的不是很清楚。另外一个说RAID1应该是热插拔的，应该是插上就能用。建议说是否rebuild过程中就灰度一点点流量进来。这样主要目的是如果另外一台机器故障，流量可以自动全切到这个机房，达到容灾的目的。领导还强调了一个关键词：概率。带着这个问题，我又和同事调研了一下。同事调研到不能用VIP的根本原因是通道消息序列号问题。通道消息序列号是内存计算的，每发送或收到一条消息，消息序列号自动加1.通道两端的序列号相差大于1，通道的状态则从running变成fail。
另外一件事是概率的问题：我们认为单机运行7个小时是没有问题的，是因为按照之前的运行情况，这7个小时发生事情的概率很小。所以我们认为这7个小时过程中完全隔离业务是无损的方案。实际情况是没有发生问题是概率性的，不是确定的。而事情上rebuild过程中发生问题的概率也很低。SA制定的流程是从修复过程不出问题出发，因为他们做的是IAAS层的工作。而我们作为SAAS层，应该从整体对业务影响角度出发。领导还提了一个问题：7个小时能确保人会一点不走神的在那里盯着吗？如果另一台服务器一旦出现故障，从发现到处理，中间处理时间会很长。因为手动处理是需要沟通，并且操作要走审批。恢复不会很快。
针对这个问题，我让同事在修复开始前，调整告警调整阈值，一笔失败或者超时则短信告警。同时，我们又反思了在制定时序时的目标设定：无损交易下进行修复。但是没有仔细考虑一旦单机运行时，运行机器发生问题时，必然交易损失，要手动来启用EOP，那就是故障。而只是在硬盘插拔时隔离流量，rebuild过程手动验证服务正常之后，切一点点流量，实际也是无损的，而且很可能rebuild过程中，一点正式流量都不会达到这台rebuild中的机器。只是一旦另一台机器出现问题，服务可以自动走这台机器，不会造成故障(实际还有别的因素，实际自动容灾行不通，这里说明避免给我们自己的同事造成误导，不影响对问题的说明)。所以我们最终决定rebuild过程中切一点点流量，实际证明确实是无损的。
总结思考
实际操作是整个处理过程的冰山一角，有惊无险就已经输了。一次把所有事情做对是最高效的。
再早几年的时候，我发现自己会经常想出来一些生活中的句子，觉得不亚于电影里的经典台词。而在工作中，我经常需要发表一些自己的论点或者总结思考。而这时候，我总觉得自己说的是陈词滥调。我总结了原因，从记事起，为生活思考是一种习惯，当我晚上在校园里一圈圈的走，当我坐车上，在车窗的玻璃哈气上涂鸦，我都在思考。而自己为工作又思考了多少，思考了多久。
大学的时候，有个韩剧叫《黄真伊》，女主说：“艺术最需要的是痛苦。”从方法学的角度，痛苦起的作用是触发人的深度思考。所谓兴趣是最好的老师原理也是因为有兴趣所以自然而然的会多为此思考。而现在我在事情的处理过程中思考还远远不够。
推荐阅读
