8355
69 天前
其实是你没参透这个问题的玄机，我来讲解一下。
机器负载高，你作为运维是有责任监控到这个信息的，
作为事件发起者你做的没错，但错在当了决策者，
只需要把这个事情汇报给上级或着对应业务负责人进行优化排查即可（很有可能优化下代码或着消费逻辑就好了），问他们要不要扩容或着迁移，决定权在他们而不是你，你只是配合实施工作。
如果需要迁移则需要他们对相关业务代码进行梳理形成文档（包括你需要如何迁移过程中需要操作的相关事项进行详细罗列），这样大家一起开会评估迁移成本/风险和操作是否合理是否有遗漏，是否可接受。
之后按照梳理好的文档在会议期间约定的时间对该迁移进行实施，同时在之前会议讨论中需要考虑到迁移失败以及各种异常情况做预案。
后面在实施前拉好群，约好时间，确定好责任对接人，开干，谁掉链子都可以写到复盘文档里。
方案有问题大家一起开会决定的，都有责任，甩锅是甩不了的，这样大家才会认真对待当个事儿来做。
以上形成的所有文档和会议记录以及拉群的聊天记录，看似效率很低，实际是多次提醒相关负责人当个事儿来办，别回复一下 ok 就当没事人了。
这一套方案下来可以降低 99%的失败率，1%就是所有人都没考虑到的情况，能力不行再修炼，大锅一起背，谁也跑不了，不用互相指责甩锅。
互联网大厂就是这种解决问题的方式，甚至可能比我说的更复杂，还要拉上架构以及各种相关负责人一起评估。
把压力传递出去，只有大家站在你这一队问题才好解决。