本文介绍了企业互联网开发及运维的一些实践，深入剖析了互联网项目开发及上线过程中的各种痛点及解决之道。
一个互联网项目的上线并不是那么容易，需要经过很多的环节：从服务器的准备开始，紧接着是业务系统的搭建，搭建的过程中涉及到操作系统、依赖中间件、应用部署、配置修改等众多事情；搭建完毕后，进行业务的线上验证及各种场景的演练，并进行高并发的压力模拟测试，找出性能瓶颈，并不断进行问题修正、架构调整；最后进行灾备的演练，整理好自动化脚本，然后挑选灾备环境的某一组进行上线试运行，迎接上线运行真实用户压力的考验。
回想每次新项目上线的过程，每次都是一次痛苦的折磨。花费这么长时间，根源究竟是什么？答案就是这里面太多的环节都是依赖人工去处理。那么我们该如何缩短交付周期呢？
回到大家手上的互联网项目，当项目上线后，是不是就万事大吉了呢？庆功后，更多的事情才慢慢到来，随着业务的开展，用户量渐渐增加，高并发的场景也开始凸显。由于只是关注了业务系统本身的上线，与之相关的外围支撑系统并没有建设，这种状况下，根本无法了解系统的内部运行状况。当前到底有多少用户在访问系统、每台服务器正承受多大的压力、当前的业务量到底是多少？我们可以思考下，淘宝做双11活动的时候，交易量是如何统计的？京东做618活动，实时流量又是如何统计的？我们应该建设哪些外围支撑，才能做到系统不是黑盒？
当线上业务系统出错的时候，是不是经常遇到无从下手的情况？这是因为随着业务规模的不断扩大，线上系统变的错综复杂，就像图中的电线一样，稍有不慎，就会起火！可能是网络问题、环境问题、代码问题、第三方API的问题等等，想要定位问题需要各种不同的技术栈，调用链路的追踪，没有科学的依据，几乎不可能。
当线上出现的问题排解的差不多了，业务也稳定了，新的问题又来了。用户的活跃带来了流量的井喷式暴增，稍有不慎就会导致系统崩塌。这个时候，需要进行及时的扩容，拯救系统。但往往事与愿违，机器准备不到位、环境部署不够快、业务扩容不及时，导致扩容的成本居高不下。
或者采取了自认为“明智”的讨巧做法，借用其他业务线的机器进行了扩容，但是你的业务系统跟兄弟系统环境是不一致的。新业务的侵入，导致了其他业务线环境的改变，反而造成了别的业务线瘫痪，真是城门失火、殃及池鱼。我们急需一致化的环境进行扩容，Docker是我们的救兵。
面对如此多的问题，可以想象团队的状况会是怎样的？团队整天忙于救火，压力非常大。很多时候为了救火而救火，拆了东墙补西墙，代码更是纯粹为了解决问题而堆上去的，代码管理混乱，技术积累缺乏……
在这种技术积累的情况下，老板又要开启一条新业务线。由于没有统一的项目模板，导致每次项目启动都是底层代码都要重写一遍。模块封装不够，导致本可以公用的模块，每个团队都要重新封装一次，研发资源的重复投入，使得研发成本居高不下。
为了使一切更规范起来，我们需要一个稳定的底层支撑平台，保证业务的快速发展。做到快速开发新提出的需求，不断的迭代小版本，开发的过程中有一些通用的模板和经过验证的技术组件直接套用。开发完成后，能够快速部署上线，小版本持续集成。上线以后服务不要挂掉，出现问题能够快速定位。流量暴增的时候，能够及时感知，并实现快速扩容。服务状态可以不断检测，挂掉的时候，最好能够自动重启……
我们再来看使用平台的价值和收益，首先持续集成的过程更加顺畅，其次平台的自动化将使运维人员的成本降低，再次基于DevOps的理念，将使得开发和运维在日常工作中高度协同，自动化的流程，让一切变得规范，新版本的迭代更快更强，线上运行的更加稳定可靠。
iuap平台支持DevOps全生命周期管理，并提供了对应工具支撑。提供了DevOps的最佳实践和工具使用说明，提供组件库对研发成果进行管理。保证编码、构建、测试、预发布、部署、监控等各个环节的持续进行。
对于快速开发，提供了一系列的开发工具、框架与组件、后端示例代码、前端模板等。并通过官网文档，进行知识的传递和反馈交流，社区化的响应开发者的各种难题。
想要解决系统黑盒的问题，我们通过收集浏览器端用户点击情况和收集Nginx日志的方式，以索引库的方式进行性能数据存储，最终对大数据进行分析，展示相应的业务报表，可视化的查看系统的各项运行指标。
线上出错，我们通过收集服务器端应用性能数据的方式，实时展示应用的调用拓扑图，并根据出现异常的请求，进行下钻，定位出具体出现问题的代码。
Docker的镜像一致性，将业务运行所需的操作系统、依赖环境、业务war包等都统一封装到了一起，应用部署的时候，直接拉取镜像即可。业务规模小的时候，只需启动少量容器，业务规模上来后，可以执行扩容操作，再次拉取镜像，以Docker的形态启动更多的应用容器实例。从此不再担心大流量来袭时的束手无措。