这一年多一直在负责公司中非常重要的系统的架构升级工作，经过了一年半的努力，终于在本月开始，灰度线上流量了。
做互联网工作的应该都有体会，打代码的时候，是最快乐的时候，待项目上线的那一刻，虽然经过了测试，由于不清楚自己项目中到底有没有问题，心里难免是打鼓的，尤其是像架构升级这样的大项目上线，整个上线进度可能一波三折，劳废心神，一不留神造成业务损失，对自己职业生涯也会有影响。
这次上线是整体架构升级，而且升级的系统对稳定性的诉求是极端苛刻的，这个极端苛刻，并没有任何夸大的成分存在，这就导致了，这次升级，实在的说，如果出一点问题，要找背锅的人，自己是无论如何也逃脱不了干系的。
如何在这样的一个情形下，保证项目的顺利上线就成了非常重要的一个工作。
我将这个情形的解决方案分为了以下两部分：
跑线上流量前
在跑线上流量前，必须要做的事情包括
- 项目正确性方面，进行输出结果新老系统对比：为了保证软件项目的正确性，需要将重构后的项目与老项目进行输出结果对比，以找到潜在的bug。
- 项目稳定性方面，进行稳定性演练：将各种能够想到的故障场景列出，并做好能力互备与降级处理，做好运维平台的建设。
- 项目性能方面，进行压测：针对线上的流量进行压测，保证系统性能侧能够实现要求。
跑线上流量后
跑线上流量后，面临的问题是如果线上出现问题，如何将遇到的损失降低到最低，是个技术问题，而这个问题，也是业界每个人都会遇到的，阿里的三板斧已经给出了一套解决方案，即变更三板斧。
- 可灰度：对新架构承载线上流量，按照一定维度进行灰度，例如城市，人员等，并保证可以随时切回旧系统，降低有问题的代码对业务的影响。
- 可监控：对正式跑的线上流量，需要具备监控能力，在多个维度上对系统进行监控。
- 可回滚: 出现问题后，具备项目回滚的能力。
剩余需要做的，听天命，尽人事。
