当然脚本比较难维护，专业性强，所以上线还是由写脚本的运维统一完成。
1.4、组织架构：研发与运维隔离
组织状态相对简单。
运维部和开放部是天然分开的，谁也不想管对方，两边的老大也是评级的，本相安无事。
统一的运维组，管理物理机，物理网络，Vmware虚拟化等资源，同时部署上线由运维部负责。
开发组每个业务都是独立的，负责写代码，不同的业务沟通不多，开发除了做自己的系统外，还需要维护外包公司开发的系统，由于不同的外包公司技术选型差异较大，因而处于烟囱式的架构状态。
机房当然只能运维人员能碰，这里面有安全的问题，专业性的问题，线上系统严肃的问题。如果交给没有那么专业的开发去部署环境，一旦系统由漏洞，谁能担责任，一旦线上系统挂了，又是谁的责任，这个问题问出来，能够让任何争论鸦雀无声。
2、阶段一的问题
阶段一有问题吗？这要从业务角度出发，其实也本没有什么问题。
中间件，服务层，前端，全部由外包商或者乙方搞定，端到端维护，要改什么招手即来，而且每个系统都是完整的一套，部署方便，运维方便。
数据库无论使用Oracle, DB2，还是SQL Server都没有问题，只要公司有足够的预算，而且性能也的确杠杠的，里面存储了大量存储过程，会使得应用开发简单很多，而且有专业的乙方帮忙运维，数据库如此关键，如果替换称为Mysql，一旦抗不出挂了，或者开源的没人维护，线上出了事情，谁来负责？
如果一起安好，其实没有任何问题，这个时候上容器或者上微服务，的确自找麻烦。
那什么时候，才会觉得阶段一有问题呢？还是从业务角度出发。当你的系统需要灵活的响应业务变化的时候，才会感觉到痛。
例如本来你经营着一家超市，原来主要通过线下进行销售，此次冠状病毒突然使得大家都不能逛超市了，这个时候就需要能够线上下单，线上销售，但是由于疫情事发突然，你外采的供应链管理，ERP等系统根本没办法修改，加入自己的业务逻辑，你让外包公司开发的系统，也不能随便修改，因为这需要重新招标，瀑布式的开发，交付，上线。你根本来不及。
再如你是一个汽车厂商，原来主要通过4S店进行销售，突然国家出台了一项激励新能源车的政策，使得你想借此机会促进一下销售，但是你发现外采的和外包的系统同样不能修改，等你改完了，风口早就过去了。
没有办法快速迭代上线，是阶段一的主要问题，我们还是分别从企业架构的五个方面依次阐述。
2.1、业务架构：架构耦合问题，架构腐化问题，技术债务问题
外采的程序和外包的程序，为了交付方便，往往开发成为单体应用。你可能会说，如果变成我自己开发和维护，是不是就能够解决这个问题了？而且我有企业服务总线，可以灵活的对于多个单体应用接口做集成。那是不是也能够解决，快速迭代上线的问题呢？
自然，自己开发和维护，灵活性确实要强的多。但是如果你依然采取单体的架构，你将来仍然会存在因为耦合问题导致无法快速响应业务变化情况。
因为任何混合在一起的架构，都会不断地腐化，即便你花时间和精力重构了一遍，还会再腐化，再重构，再腐化。这是架构的天然宿命，也是人性而导致的。他不能避免，但是可以不断地修正。所以架构设计并不能避免架构腐化的问题，但是能够解决及时发现及时修正的问题。
如果你不相信这一点，那我们就举一个例子，看是不是天天发生在你的身边。
就像图中显示的一样，左边是你的领导认为一个单体应用的内部架构，里面的几个模块，界限清楚，调用分明。而右面可能是实际的内部架构，界限已经十分模糊，很多逻辑都糅合在了一起。
为什么会出现这种现象呢？第一个原因就是没时间搞。对单体应用内部的界限是不可观测的。我们都知道，领导都非常重视功能和bug，因为功能和bug都是可以观测的，而且是会影响用户的体验的。而架构往往不受重视，是因为单体运用内部的架构，领导是看不到的。他看不到，他就不会给你留时间，在开发功能的时候，不断的去调整架构。第二个原因，就是没动力搞。一旦代码的很多逻辑糅合在一起，那代码的可理解性就会非常的差。这个时候重构往往就更加的费时间。而领导又不肯留时间，那这时候开发人员就会想，反正领导也不重视，代码可理解性差呢，Code Review也Review不出啥来，那索性就头痛医头脚痛医脚好了。第三个原因。就是没胆量搞。哪怕这时候有一个有技术洁癖技术理想的人想搞这个事情，但是他会发现，代码复杂，耦合性强，越是核心的逻辑，越是不敢动，因为线上出了问题，谁改谁负责，所以，只好层层封装。
以上的三点。都是不可避免的人性。作为管理者和架构设计者不能要求我们的程序员是圣人，也不能不考虑人性去解决这些问题。
