反感标签化评估，原地升级风险有哪些？

我特别讨厌标签化的评估方案。中风险意味着什么？具体有哪些风险？相应的损失估算怎样？在乐观、中性、悲观假设下分别会有哪些损失？要是把这些都列明白，我想正常人就知道该不该冒这个险了。
从这个措辞判断，我更觉得是技术团队主动想原地升级。不然，原地升级的难度应被评估为潜在风险极高。也许是高层先下达了年内必须完成k8s升级的考核目标，在此目标下，不允许采用耗时久但风险小的方案。
但做事的人都清楚，这个风险一旦出现，涉及的就是上千万元的事，像服务中断、故障处理投入、账务错误及纠正处理投入，极端状况下还会造成无法恢复和挽回的局面。
假设基础设施二进制兼容是一种极为愚蠢的做法。
比较务实的方案如下：其一，老集群腾出5% - 10%的机器（或者按数量新组建一批swap集群），全都重装新系统并升级为新集群；其二，把老集群的边缘业务迁移至新集群，同时观察运行情况；其三，稳定之后，每次释放老集群原本规模5% - 10%的机器，重复前面两步直至迁移全部完成。
结合其他回答来看，这次升级有个很重要的底层原因，即两个版本采用的hash方案不同，从而导致进一步全面崩溃。我不太了解这个细节，所以不好评价。不过我想指出，如果这种说法正确，那就表明这个升级方案从始至终都未曾经过测试验证，毕竟这样的变化只要稍作测试肯定就能发现。
最后再提一下，我特别讨厌标签化的评估方案。中风险指的是什么？有哪些具体风险？损失又该如何估算？在乐观、中性、悲观假设下的损失分别是什么？要是能把这些都列明白，我想正常人就知道该不该冒这个险了。
阿里、滴滴出现过几次P0级故障，同行应从中汲取教训。技术人员评估风险要谨慎，把风险具体内容客观列出，别只给个不实在的低中高。业务管理人员综合评价后，若出于成本考量冒险可以，但也要为不切实际的冒险承担相应责任。
毕竟对于赌徒而言，可多次赌赢，但一次输就完了。