技改在任何时候都是个敏感的事情。大量的问题需要摆平，天时地利人和，缺一不可。
天时
即选择合适时机进行技术改造工作。在时机的选择上，我们经历了三个阶段。
空闲时段
在开发企业应用时，技术改进也是常见的工作。企业应用开发的特点是有忙有闲。在版本发布前都紧锣密鼓进行开发工作；在老版本发布之后，新版本刚刚启动开发时，有相对空闲时间，可以进行技术改进。
而当这一套方法搬到互联网应用开发上时，却发现基本行不通。互联网应用开发是两种情况：很忙和非常忙。预留大片的时间进行技术改进，几乎是不现实的。如果有业务可以有空闲时间做技改，那基本上也就没必要改了，因为这也意味着这个业务进入稳定和衰退期。
随需改进
既然找不到空闲时段，另一个选择是随需进行，也就是在项目开发过程中，对涉及到的模块进行改进。而在实践中，我们也发现这种做法难度很大。
- 遗留系统的模块依赖关系往往令人匪夷所思，改进过程中，经常会发现需要对所依赖的底层模块进行大调整，导致改进工作无法进行。
- 就算是所依赖的模块没有问题，改进工作也会导致更多的时间开销，2~3倍都是正常的。这个延迟不是所有项目都能够承受的。
优化团队
比较适合互联网应用开发的做法，是组建专门团对进行技术改进。预留大约30%的开发能力来进行技改。这些人可以是专门负责架构改进的，也可以从项目组中抽调轮岗。
- 改进前，制定改进计划，循序将近进行。涉及到具体模块改进时，抽调负责该模块的技术人员来参与。
- 如果模块改进和业务开发工作同时开展，则可以考虑将这两个工作合并进行。
技改不能一哄而上，也不能蜻蜓点水的做。他是一个持续的过程，循序将近，不要中断。项目紧的时候挑选风险小的任务来执行，少安排几个重构点。项目松的时候重构下核心接口，多安排些重构。但是不要中断。 一旦中断，往往结果是没有人会愿意继续。重构往往是个前人栽树 后人乘凉的事，风险又大，短期看不到效果，大家做着做着，往往就放弃了。所以持续改进是必须的，避免半途而废。
还有一个大家容易忽略的地方，对于特别看重绩效的团队，按照产出来度量工作成果，那必须果断避开绩效考评的这段敏感时期。
地利
所谓地利，从软件角度，主要是基础设施的建设。在针对现有系统进行改进，推动微服务架构前，需要评估下当前的基础设施建设是否能够满足要求。 服务所需要的基础设施包括:
虚机环境或者docker
不同服务的线上压力和运行环境需求不同，内存，CPU，磁盘需求也不一样。按照服务需要自动弹性创建所需要的环境，是微服务部署的前置条件。
版本控制软件
版本控制不仅仅是协调人和人之间的协作，同时也是保证线上运行的系统必须是最终正式的版本。一旦出现问题，开发人员可以从版本控制服务器上下载到一致的代码。现在一般用git来实现。为什么不用SVN,网上有很多对比文章，不是本文重点。
代码评审软件
每个微服务作为独立的项目来开发，统一编码规范，审核代码逻辑等，在这场景下犹为重要。和git相配合，gitlab是优先考虑的codereview软件。
集成发布 集群对微服务是必不可少的基础环境，将一个服务部署到几十，甚至上千台机器上是必要的。这种情况下，人工部署是不现实的，依赖于集成发布环境，实现获取版本，集成编译，备份老版本，发布新版本，启动服务，暂停服务和重启服务。推荐使用jenkins。
系统监控
监控自动化也是必要的基础设施。对出问题的服务报警，在高峰期对核心服务进行监控，都必须借助监控系统来处理。推荐使用zabbix。
日志分析
排查错误和对系统进行审查，日志处理是不可避免的。想跟踪某个ID用户的行为，在几百台机器上逐个查看日志也是不现实的。使用工具，如ELK，将日志收集到一个存储中，提供检索功能来查看日志，甚至对日志做统计分析，也是必须的设施。
办公环境
不用说，新老系统开发人员得在一起办公，随时交流。如果条件无法满足，那至少必须建立顺畅的沟通方式，比如QQ群，微信群等。邮件并不是一个好的选择，电话会议也是不错的。
人和
最重要的因素。总体上包括三个方面内容，上级领导的支持，团队成员的认可，合作部门的理解。
上级的支持
毫无疑问，上级领导支持是前提条件。重构是高风险的工作，往往不容易立即出新成果，而且还需要额外的投入。几个月内，没有新东西，出货速度变慢，没有其他因素，不是重构就是在怠工。从公司层面，更高层的人越能知道什么时机适合开展重构工作。公司马上要架构调整了，系统快下架了，近期有重大活动需要支持，有人需要尽快出成果来晋升….都需要慎重评估是否可以进行重构，而这些事情，越高层的人掌握的信息越多，所以得到他们的支持是必须的。
团队成员的认可
其次是团队成员们认可。特别是老系统的开发人员，他们认可和毫无保留的支持是必要的条件。他们最清楚系统有哪些坑，哪些是必须改动的，哪些是没有用的功能，哪些只是临时的解决方案。这样才可以在功能迁移时，有目的地进行调整。