1、紧急修复故障
公司集群机器下线，肯定是出了故障，那第一优先级当然是尽快核查集群机器下线的原因，然后给出针对性解决方案，如果短时间内集群问题没法解决，也要尽快升级领导，把对业务的影响讲清楚，如果上级重视了，可能就会帮你协调到更高端的技术资源，这个工作一定要同步进行，一定要给集群支撑方足够的压力，这叫对症下药，也是治本的方法，其他方法说起来都是曲线救国。
这一步做到位了，如果时间的确紧急，那就走到下一步。
2、资源动态扩容
既然是集群，按道理资源是有冗余的吧，那么临时动态扩容是最基本的方法，这也是云计算存在的意义吧，如果这一步都做不到，至少说明系统规划没做好啊，难不成现在数据仓库还是单机？如果是这样，就要考虑数据仓库云化的方法，现在hadoop大数据平台架构已经很成熟了。
这一步如果做不到，那就记下来跟规划部门秋后算账，然后继续往下走。
3、资源腾挪调整
集群资源的使用也存在2/8现象，既然是核心任务，肯定有很多非核心任务，那就把其他非核心任务的资源腾挪部分给核心任务，假如是hadoop集群，可以采取调整队列的方法来快速增加资源，当然前提是要能够大致判断调整后的业务影响，不过这种抢别人资源的方式还是比较简单粗暴。
如果资源调无可调，那就继续往下走。
4、调整优先级别
如果资源腾挪不现实，比如短时间内难以在资源层面进行精细化的调度，那就对所有任务的优先级进行排序，把核心任务的调度优先级提升，调低其他任务的优先级，确保核心任务的生成时间满足要求，当然前提是对所有任务的重要程度、相互依赖程度和对业务的影响有比较清晰的认识，这些功夫都在诗外，临时仓促的去调整任务优先级可能会导致严重的后果。
如果任务有成千上万，互相之间有千丝万缕的关系，短时间不具备梳理清楚和操作的条件，那就继续往下走。
5、任务代码优化
核心任务一般是比较复杂的，消耗的资源也比较多，意味着有较多的优化空间，原来家里有余粮的时候可能不太会关注代码的质量和效率，现在不得不去做优化了，这就看开发人员的能力了，技术大拿在这个时候往往显示出了价值，我们以前就通过将hive换成spark取得了不错的提速效果。
如果代码优化的空间仍然有限，那就继续往下走。
6、降低任务依赖
数据仓库建模通过模型的复用可以有效提升上层应用的整体支撑效率，但回归到单个应用的任务，由于需要依赖仓库模型的生成，反倒影响了生成速度，这就是局部和全局最优的矛盾。通过剥离核心任务对数据仓库模型的依赖，为其量身定做一套数据处理逻辑，则可以大幅提升效率，后果是造成了资源的浪费，加剧了数据仓库整体资源的紧缺状态，当然非常时期非常手段，有时候为了考核保障就不得不这么做。
如果这样也不行，那就继续往下走。
7、核心任务容灾
既然核心任务这么重要，而单集群也不可信任，那就不能把所有鸡蛋放在一个篮子里，容灾或者应急是常规做法，比如我们为了确保某些作业万无一失，常常会采取异地异构（核心任务分别放在hadoop和MPP集群）的解决方案，前提是核心任务规模不大，否则投资和成本都吃不消，数据仓库由于数据量大的特点，一般都不会做容灾方案，虽然集群垮掉是极小概率事件，但集群性能下降是很大概率事件，比如hadoop一个参数调整就可能大幅降低数据处理的效率。
这已经是最后一招了，下面就讲讲管理手段。
8、做好解释工作
核心任务延迟肯定影响了业务，面对这种情况，一方面要及时跟上级做好沟通汇报，协同各方做好故障的分析，给出可以落地的解决方案，如果下属能拿着这7个方案来让我决策，我会很满意，另一方面，要做好核心任务延迟对业务造成的实际影响的评估，做到心中有数，同时跟业务方做好解释工作，适当降低业务的预期。
能做到这一步，我想已经超越了大多数人，因为这不是简单的技术问题，对于处理人员的综合素质要求挺高。
9、转危机为机会
出故障对于数据仓库来讲既是挑战，其实也是机会，平时没出问题的时候业务感受不到数据仓库的价值，要争取些资源还挺难的，如果故障真的对业务造成了较大的影响，可能会让公司重新审视数据仓库的价值。
记得以前某次IT系统挂了，造成了较大的社会影响，后来分析出来的原因是容量不足，然后公司对规划部门、市场部门、IT部门的负责人各打50大板，说规划部门没规划好容量，少投钱了，说市场部门乱提需求，没做好业务规划，通过这次事件，IT反倒受到了更多重视，并且获取了更多的资源来保障生产，各种容灾系统拔地而起，然后就没有发生过整个系统挂掉的情况。
其实还有一点我没说，就是最终靠的还是人，临时抱佛脚也没啥用，希望对大家有所启示。
免责声明：本平台仅供信息发布交流之途，请谨慎判断信息真伪。如遇虚假诈骗信息，请立即举报
举报
