滴滴故障背后，技术方案与人为因素？

作为一名老OP，来蹭下热度哈。其一，滴滴的同行们确实很厉害。容器集群出故障能对核心业务产生长时间的切实影响，这表明滴滴的容器化工作做得相当不错，得给大佬们点个赞，是真心的。别看云原生现在特别火，各个厂家也都喊得很响亮，但实际上由于历史遗留问题和技术能力的限制，能够大规模进行容器化并且敢于把自己的核心业务放在上面的，其实并不多。其二，那篇文章分析得挺好的，除了风险评估那部分实在难以认同之外，其他部分都很不错，在升级过程中的关键风险点也考虑周全了，至于执行得怎么样那就是另外一回事了。其三，关于替换升级和原地升级的争论，搞技术的肯定都觉得替换升级好，新建一个集群就能跨越重重困难，不用去管中间版本变化带来的风险，很完美。不过，这里有个转折，搞技术的人说了不算。要是进行替换升级的话。其四，原地升级其实也行，逐个版本或者按照社区要求跨越三个版本以内进行升级是完全可行的，这种事都做过好几次了，只要胆大心细，就不会有什么大问题，不过比较麻烦。特别是像滴滴这种修改很多、实现又无法融入主线的情况，那就相当于要做至少三次的版本适配，想想就头疼，更不用说升级过程中的风险相当于增加了三倍，时间也不一定能控制得住，还不如一次性解决……其五，根据那篇技术文章来看，感觉滴滴的大佬们应该在不少集群验证过技术方案是可行的，这次故障我盲目猜测是低级错误导致的，不管是误降级也好，误操作也罢，造成了集群版本有偏差，大量的pod可能因为校验不一致而大规模重启，进而导致集群雪崩，控制节点离线。只希望最近大厂故障频发的情况能给老板们一些启示，对技术从业者好一些，很多时候他们可能不善于表达，但他们是保障稳定性的底线……