evops是一个非常高大上的名字，事实上说的简单点就是开发和运维本身就是一个团队的，要干就一起把事情干好。谁出了问题，站点都不行。
作为一个架构师。必需要devops，并且要知道怎样推行devops。
首先要自己主动化，举个阿里的样例。阿里通过aone系统来实现半自己主动化部署：
- 开发者开发代码先自測通过后，提交代码到git。
- 在aone中一键部署到日常环境。
部署是自己主动化扫描依赖冲突，系统安全等问题。
- 測试接到部署成功的通知，进行測试。假设測试通过。则审批通过，能够线上公布。
- 线上运维人员一键部署到线上。部署能够分配部署。进行A/B測试。假设出现故障能够一键回滚。
当然这里面牵扯到了非常多角色，事实上假设是一个公司。这个团队应该一体的，不分彼此。团队中每一个角色都是程序猿。每隔一段时间须要轮换岗位。
事实上不仅仅是部署须要自己主动化，測试、扩容、监控、分析等等都须要自己主动化。当然这须要依据你公司的实际情况进行实践，最先须要的事实上也是部署自己主动化。怎样实现呢：
- 使用开源产品 git,hudson,ansible或者puppet
- 制定对应的规范，自己主动化部署是有规范的，每一个人都必须遵守。否则故障就会立即出现
- 进行定制化开发。使整个系统形成一个总体。
- 上面的开源产品并非一个总体，须要通过自己编码使其成为一套系统。
- 涉及web系统开发，底层脚本编写，打包规范制定
- 不断发现反复劳动，使其自己主动化
- 要有相应的监控系统，及时发现异常
有了这一个自己主动化系统之后。你能够考虑一下后面的产品安装、測试、扩容、监控、分析系统的自己主动化。
另外持续改进也是devops的核心，要有发现改进的眼睛。
仅仅要有事情反复做3次以上，就考虑是否须要自己主动化。
假设你不进行devops。随着业务的增多，系统的增多，终于还是须要进行从头到尾的改造。
不如一開始建设的时候就预先设计考虑好，事实上这些东西假设你懂的，開始的时候就做好。并不浪费太多时间。反而能节省大量的时间，何乐而不为。