《DevOps软件架构师行动指南》读后感2

第2章整体写的相当弱，特别是对于DevOps为何需要和云结合，维护需要PaaS平台能力没说透彻。

运维整体架构可以参考ITIL标准体系。运维服务包括供给硬件，提供软件，或者支持不同的IT功能。由运维提供的服务还包括了SLA服务等级水平协议的规格说明，软硬件环境状态监控，容量规划，事件管理，故障和问题跟踪处理，日常环境检查，环境和数据备份，业务连续性和信息安全等。

DevOps不仅仅是考虑软件变更在交付过程中的自动化，也需要考虑后续运维过程的自动化。

IT服务治理，单独的一个内容，需要提供什么样的服务，安全要求如何，合规要求如何？SLA服务级别如何定义？日常的变更，发布，问题，事件管理流程是如何的？服务的业务连续性如何保证？高可用性如何保证？这些都需要在IT服务和治理管控框架中进行定义。

对于服务设计需遵循标准化，松耦合，抽象，可复用，自治，无状态，可发现，可组装等标准原则。


监控是运维过程中最重要的核心，因为它收集事件，检测事故和度量以判断是否符合服务等级协议。它提供服务改善的基础。服务等级协议也可以定义和监控运维活动，例如事故发生后的响应时间。监控的结果由开发或运维团队来进行分析并采取行动。

监控可以和其他控制结合在一起，例如对云资源的自动伸缩控制。

微服务架构和DevOps

实施DevOps往往需求架构调整，其关键原因就是尽量减少每次部署动作对整体应用的影响，同时匹配前面谈到的持续高频，小规模发布的需求。而这种关键调整的关键就是微服务架构。对于微服务架构我前面很多文章都已经谈到过了，这本书这部分仍然没有讲透。

微服务架构对于部署流水线作业带来的好处可以总结为：
1. 团队可以按微服务模块单独划分，减少团队之间的耦合和交叉影响
2. 多个微服务模块组件松耦合，完全可以独立自治管理，对于变更发布仅需要发布最小组件单位，降低风险
3. 微服务模块更加容易部署到轻量Docker容器，实现快速的自动化部署和集成