《DevOps软件架构师行动指南》读后感1
通过阅读《DevOps软件架构师行动指南》这本书，对DevOps架构方法论和关键技术有一个全面的了解和认知。
DevOps是什么？
在书里面给出定义为，DevOps是一套实践方法，在保证高质量的前提下缩短系统变更从提交到部署至生产环境的时间。实际上看了这个定义你也很难对DevOps有一个全面的了解。因此也可以定义为，DevOps是在保证质量的前提下，提供的一整套从开发，测试到生产运维的持续交付和管控方法论。在整个过程中需要实现自动化，可视化，流水线式作用，同时将质量管控无缝嵌入其中。
DevOps拓展了原有的持续集成方法论，其核心增加了组件化和微服务架构，其次增加在交付和部署的时候和PaaS云资源池和动态调度的集成。
不仅在新系统的开发交付，其更加重要价值在于老系统在后续变更中的持续交付和集成能力。也就是常说的实现了开发，运维和质量管控的一体化作业。也就是我们经常说的，打开了开发和运维之间的鸿沟，真正实现了开发，运维的一体化作业。
DevOps提倡将运维人员作为首要的干系人，并在需求阶段一开始就介入。
DevOps确保整个发布过程是可视化的，同时实现发布过程的质量控制，可管理和可追溯。以确保在部署出现问题的时候能够快速的查找原因或整体回滚。
运维人员后期运维难的一个重要原因就是前面所以开发和测试过程对他们都是黑盒，对于这种部署在软硬件环境里的黑盒系统，在出现故障时候他们也很难第一时间查找到真正的原因并快速解决。
DevOps和敏捷，我更愿意理解为需求的条目化，持续集成，可视化这几个关键点的实践。
在协同上面要注意到，DevOps有两个重点，其一是开发，QA+测试，运维三大角色之间的协同；其二是软件打包版本在开发，测试，生产多个环境间的自动化部署和迁移。
人们从不同的视角定义DevOps，例如运维人员采用敏捷实践，开发人员承担运维责任，以及其它一些视角的定义。但共同目标都是缩短一个功能或改进点从业务思路构想到最终部署给用户的时间。
