[备忘.经验总结]没有一劳永逸的完美方案 —— “银弹”？那是没有的

    这几天在考虑某客户端程序支持灰度升级的事。最开始其实有一股冲动想要实现出来早点发挥作用，但经过梳理后，逐步意识到其可能带来的实际效果并不如最初设想的那么大，同时还会带来一些新的问题要去面对和解决。

    比如，实施人员的操作负担会增加——执行灰度升级需要更精细的操作，不仅步骤增多，还需要去了解和规划升级策略。然后管理难度也会增加——灰度升级过程中，会存在不同版本客户端共存的情况，增加了环境的复杂度。而这些问题，恰恰是我们现有升级模式的优势所在——对实施够简单。

    回到最初为什么想要来支持灰度升级呢？其实初衷是想实现AIO的平滑升级，降低升级问题对用户造成的使用影响。但是，想要达到或接近这个目标并非只有灰度升级一条路。并且走这条路也未必就能达到好的预期效果。

    回顾目前程序升级面临的主要风险，主要集中在运行环境上。而这类问题属于“一次性”的，一旦在当前环境上解决过就不再会发生。针对这类问题，我们其实可以采取更加直接和有效的解决方案。虽然灰度升级也是解决办法，并且看似能“一劳永逸”，但似乎并不划算（有点把“小菜盘成肉价钱”的意思）。但这个思路后续应该还是可以适时实践的。

整理下这个事情，有两个要点可以记录：
1、完美方案并不存在。正如涛哥例会上常提到的，事物都有其两面性，我们往往要在利弊之间做出权衡和选择。
2、做事情别忘记初衷，不是盲目追求某种方案。我们不是要去做“灰度升级”本身，而是要解决我们所面临的问题。并且灰度升级也只是解决问题的一个可能选择而已。

备注：这里说的“灰度升级”是指只对特定范围的客户端进行升级试运行，在功能稳定后再逐步扩大升级范围。属于实现产品的平滑发布的一种方式，可以降低升级风险并保证整体系统的稳定运行。