这是学习笔记的第 2101 篇文章
最近和同事在梳理一个系统的改进方案，里面也涉及到一些汇报思路和技巧，最终的方案是需要申请一些服务器，但是整个分析的过程，是一套严谨的推理过程，总之是让领导认为这是在解决问题，而不是在逃避问题，同时申请服务器是在优化资源配置，而不是无脑一味的要资源。
问题的背景是有两套数据仓库集群，存储都是以T为单位来计算的，最近碰到了一些硬件问题也发现了原本设计中的潜在问题；同时对于目前的业务增长，领导也提出了新的期望，比如计算任务要到下午才能计算完成，预期想优化到早晨，前后讨论过几次，总体感觉解决方案和思路比较牵强，虽然是解决了部分问题，但是一上来就是申请服务器感觉还缺少一些信服力。
首先，我们应该明确这是一套高可用服务的改进方案，而不是单纯的资源申请方案。整个方案的目标有两个：
1）改进现有服务集群的问题
2）在现有基础上优化服务的计算能力
服务集群的问题
对于现有集群的潜在问题关注，也是由最近发生的一个硬盘问题发现的，整个集群的节点有上百个，整个服务的部署是单机多实例，一台服务器上部署有20个实例，硬盘是按照8T*10的规格去配置的，使用了RAID5,结果最近系统部同事收到了一个磁盘报警，本来这是一件很正常的事情，结果在工程师维修的时候发现另外一块磁盘也存在潜在瓶颈，虽然没有报警，但是通过一些方法发现已经处于损坏的边缘，这个时候问题的优先级就上来了，如果第2块磁盘再发生损坏，那么整个文件的存储在RAID5的模式下就存在问题了。当然集群本身是有高可用机制的，但是目前的集群节点部署是按照组对称部署的，类似如下的方式。
实际每个服务器上面的实例数有20个，即10个primary,10个mirror,如果发生了服务器存储损坏，导致服务不可用，那么原本的10个Primary节点会漂移到另外的服务器上面，那么从高可用层面来说是可行的。但是存在四个严重问题：
1）如果节点漂移到从库，开始大量的计算任务，很可能会把整个集群跑崩，可能产生一种连锁反应，整个节点不可用，后续导致集群不可用。
2）如果后续要修复节点，耗时过长，因为整个集群的存储空间有近70T，要重构整个节点需要耗费的时间和成本较高，一天以内是弄不完的，而且在重构的过程中还对原有的节点存在风险。
3）整个集群的水平扩展在之前缺少严格的演练和测试，尽管从哪理论上可行，但是集群现在已经具备规模，不能接受未经评估验证的方案。
4）虽然后续做了磁盘修复，但是单块磁盘的空间过大，导致rebuild的耗时差不多在13个小时，如果这个期间出现磁盘问题，就前功尽弃了。
所以在这个过程中发现了一些很明显的问题，也有一些改进措施。
1）对于磁盘的配置，建设设置为RAID5 hotspare的模式，至少可以容忍坏两块盘。
2）集群的节点设计属于过度设计，早期更多考虑了功能和性能，而对可用性的考虑有所欠缺
服务计算优化的背景
目前的业务增长量超过预期5倍，随着业务需求的接入，对于服务可用性的要求也越来越高，部分业务从原本的T 1模式升级为近实时的数据分析，而一些业务的优先级也随着需求的接入而显得更加重要，比如在指定的时间前需要提供好指定的数据分析结果，这属于公司运营的重要参考指标。
在现有的情况下，我们经过上述的评估，发现原有的问题需要改进，同时业务的优先级提升，计算能力目前还难以扩展。所以在现有的资源配置下，是难以实现上述的两个需求的。
我们可以设计如下的改进策略。
1）充分利用现有的资源，比如测试资源等。
2）对现有的集群问题进行优化和改进
3）业务层实现双活需求，比如某个集群真不可用，我们可以较为平滑的把计算任务迁移到另一个集群开始计算，不应该碰到卡脖子的情况。
所以这个方案的一种合理解决思路就是申请一个新的集群，分为如下的几个步骤：
1）集群1--迁移到--新集群
2）集群1进行重构，已有的历史数据可以通过ETL重建
3）集群2--迁移到--集群1
4）集群2重构
5）集群资源重构和优先级配置
整体来说，能够解决现有问题，也能够优化资源的配置。算是一种合理的解决方案。
