所以由于以上三点，我们就观察到了非常常见的两个现象。第一个就是迭代速度慢。因为架构的耦合，往往A上线，明明不关B的事情，需要B配合，B上线明明不关C的事情，需要C配合，最后问了一圈，只好10个功能一起弄完一起上线，那上线周期以月为周期。第二个就是可复用性差，如果你是一个领导，你会经常问这样的问题，明明你记得某个模块里面有某个功能，当另外一个模块需要的时候，拿不出来，需要另外开发。
最终就形成了技术债务，就像咱们借P2P，借了一万，一个月后发现要还两万。同理，当领导一年前问你某个功能开发需要多长时间，你半天就搞定了，一年后，你说要一个星期，领导很困惑，以为你开始学会偷懒了，变成老油条了，其实领导已经不知道单体应用里面已经一团浆糊了。
2.2、技术架构：资源申请慢，复用性差，高可用性差
从技术架构的角度来看，基于虚拟机技术，资源申请非常的慢。因为虚拟机大量地依赖于人工的调度，需要运维人员非常清楚，要部署在什么地方，往往需要通过excel进行维护。另外VMware还有一个问题，它使用共享存储，会限制整个集群的规模，因为此时的应用不多，这个程度的规模还可以接受。
另外网络、虚拟化、存储等基础设施，没有抽象化的概念，复杂度非常高，开发接不了这个工作，必须依赖运维，就要审批。由统一的一帮人来做，而且他们要考证书，比如，网络要有思科的证书，虚拟化要有VMware的证书，要特别专业才能做这件事情，因此会极大地降低迭代速度。业务方无论做什么事，都要走审批，运维部的人根本忙不过来，就会降低资源的申请速度。
所以我们经常观察到这样的现象，业务部门要部署应用，本来需要80台机器，却要申请100台，因为流程比较慢，万一不够，就要重新申请，一旦申请的，就不愿意归还运维部，因为说不定什么时候要用上，这样资源利用率大大降低。另外部署应用的时候，如果基于脚本部署，应该是环境越干净越一致，脚本部署的越顺畅，所以本来应该每次部署都是新创建的虚拟机，而且一旦一个系统被安装坏了，不必修复这个系统，重新创建一个虚拟机是最方便的。本来挺好的虚拟机的特性，被审批流程给破坏了，业务部门发现虚拟机坏了，想想重新申请太慢了，于是就忍忍，自己在虚拟机里面进行修复，十分浪费时间。
多种多样的中间件，每个团队独立选型中间件，没有统一的维护，没有统一的知识积累，无法统一保障SLA。一旦使用的消息队列，缓存，框架出了问题，整个团队没有人能够搞定这个事情，因为大家都忙于业务开发，没人有时间深入的去研究这些中间件的背后原理，常见的问题，如何调优等等。
2.3、数据架构：数据分散质量差，单一维度统计分析，人为报告反馈链长
这个时候的数据是非常分散的，不同的数据存在不同的业务系统中，如上面说的单体应用客户管理系统、生产系统、销售系统、采购系统、订单系统、仓储系统和财务系统等，或者同一个业务系统但由不同的机器在采集，这都导致了数据没有统一的标准，而是以割裂的形态存在，也就是数据孤岛。
但是业务的领导和部门的主管想了解业务的运行情况，就需要有人统计分析，这就是分析师，但是分析师因为生产流程太多了，数据太分散了，设备、系统、测量数据一堆，每个特性最少N个数据，一方面需要到处找人，一方面N多数据接口、N多数据格式，各自为战，数据对接不上。所以报告一般以周为单位给出，然后层层汇报，领导根据汇报，才能调整策略，然后再根据运行情况，再出报告，这个反馈链太长，要以月为单位了，不能适应市场的快速变化。
2.4、研发流程：上线依赖人，部署风险高，脚本难维护
上线依赖于人工和脚本，人是最不靠谱的，很容易犯错误，造成发布事故。而发布脚本、逻辑相对复杂，时间长了以后，逻辑是难以掌握的。而且，如果你想把一个脚本交给另外一个人，也很难交代清楚。
另外，并且脚本多样，不成体系，难以维护。线上系统会有Bug，其实发布脚本也会有Bug。
所以如果你上线的时候，发现运维人员对着一百项配置和Checklist，看半天，或者对着发布脚本多次审核，都不敢运行他，就说明出了问题。
2.5、组织架构：研发运维标准不一，难保障端到端高可用
线上的高可用性，业务层的开发人员不会做任何事情，他认为是线上一旦出事，应该由运维集中处理，迫使运维服务的发布人员依赖虚拟化机制，来提供高可用机制。我们都知道VMware有非常著名的简化运维的高可用机制，比如FT、HA、DR等类似的机制。如果我们是从IT层来做高可用，有一个缺点，作为基础设施层来讲，它看上层没有任何的区别，所以没有办法区分业务优先级。比如说FT的模式，跑CPU指令，它不知道这是最核心支付的指令、还是日志的指令，再如数据中心之间的同步，存储层是无法区分交易数据和日志数据的。这样就会造成一方面该同步的没有同步，不该同步的同步了很多，使得线上业务SLA降低了。另一方面浪费了存储和带宽的资源。而且一个服务到底是不是正常，需要应用层开放一个health接口来返回，如果应用层不做这件事情，基础设施只能通过看进程是否存在，端口是否监听等判断，很可能出现进程在，但是服务不可用的情况，也会降低SLA。
