这件事情其实在心里酝酿了很久，直到女票发来一篇文章，简单扫了一眼。第二天，清晨，灵光一现，然后就有了这么一个标题。
我自认为自己是一个比较专注的人，以至于认定的事情尽可能的会去把它做好。当然，可能会由于技术水平限制，或许当时有更好的解决方案。很是赞同这么一句话：你所做的不仅仅是做给当前老板的，更多的是做给未来即将优秀的自己。
做了这么多年编程工作，大大小小的项目也接触了不少。有些是自己主导开发，一些是老旧版的项目维护，多多少少对于项目发展，系统架构甚至职场还是有自己的一些想法的，或许激进或许不符合目前公司发展现状，但总归是自己的一些切身感悟。
随着互联网的迅猛发展，国内ATB也在引领技术的潮流，不经意间一些新潮的技术思想就会涌入我们的视野。但是，作为二三线城市，对于技术的追求并没有那么强烈，当然这也跟区域的互联网环境有一定的关系。
其实我想说的是，都说环境造就人，可我不这么觉得，环境的确有好坏，但你总有选择的权利吧？即使你起点低，暂时没有选择的资本，最起码你可以掌控自己业余时间吧，充电何尝不是一种对未来的选择？
好了，扯了这么多，以至于技术债这三个字第一次才出现。其实就是想谈谈人生、聊聊生活，不至于话题聊得那么枯燥。
什么是技术债
技术债务是由团队为了短期的项目利益故意做了欠佳的技术决策而招致的。当然，也可能是由于当时水平限制导致的不合理设计。
总之，不管是有意而为之还是无意中的实践，如果不及时弥补，出来混，总是要还的。
技术债是如何形成的
初创公司，成本限制，分工不合理，人员配比不齐
初始的技术选型(当然这不是最主要的)，跟不上技术潮流(重点)
巨型项目，不考虑系统架构、扩展和性能问题
大部分依赖人工部署，功能测试
没有合理的日志监控手段
硬件环境差，特别是工作环境的流畅性，直接影响生产效率和心情
以上种种，在创业初期三五个用户的时候，是完全不考虑的。但是发展3-5年，用户有了持续增长并且可以预知用户的前提下，如果还是这个样子就有点可怕了。当用户数据到达了某个临界点的时候，以前欠的技术债，一一都得还回来。
内存溢出了什么鬼？
CPU 200% 赶紧检查一下
访问页面怎么这么慢？
一会404了，一会500了
首页数据不正确，定时任务怎么不跑了
用户无法支付了，赶紧打个war包，你说现在放还是不放
生产一直报错，而开发运维一直不知，直到用户找来
巨型项目交付时间变的越来延长
有时候，我们不仅仅维护他人的项目，还要着手开发自己的功能，往往会遗留下一些技术债。当然，前人挖坑，后人填坑，碰上了别说倒霉，很多人也是在解决前人留下的债务危机中迅速成长起来的。
那么如何构建高可用和高并发的系统，并且能够做到错误预警通知，然后快速动态的去修复问题，让生产系统在最短的时间里恢复运行。
