此为个人《DevOps A Software Architect`s Perspective -Len Bass, etc》阅读笔记。
DevOps: A Software Architect`s PerspectiveDevOps 是一项运动，他设想在开发组和运维组之间没有冲突。
- 1. DevOps 是什么
- 1.1 定义
- 1.2 DevOps 生命周期过程（波特价值链标注）
- 1.3 发布过程
- 1.4 DevOps 形式
- 1.4.1 自动化
- 1.5 DevOps 与敏捷
- 1.6 团队结构
- 2. 云即平台
- 2.1 概述
- 2.2 云的特性
- 2.2.1 虚拟化
- 2.2.2 IP 和域名系统管理
- DNS
- 2.3 独特的云特性对DevOps的影响
- 3. 运维
- 3.1 运维服务
- 3.2 业务连续性和安全
- 3.3 服务策略
- 3.4 服务运维
- 3.4.1 服务运维概念
- 3.4.2 服务运维功能
- 3.5 持续服务改进
DevOps 是一套实践方法，在保证高质量前提下缩短系统变更从提交到部署至生产环境的时间。
- 在部署对系统的变更时（一般是代码形式），质量很重要。保证质量的方式：一在把修改后的代码放到生产环境前必须跑通各种自动化测试用例；二在把变更对外开放之前，先让一小部分用户对生产环境的变更进行测试；三对新部署的代码密切监控一段时间。
- 该定义要求交付机制也是高质量的。
- 两个重要时间周期：一开发人员提交代码的时间；二把代码部署到生产环境的时间。
- 该定义以目标为导向：如果一种实践的目的是 减少开发人员从提交代码到生产环境之间的时间，则无论是否包括敏捷方法、工具和协作形式，都是一种DevOps实践。
向客户发布新系统或现存系统的新版本是软件开发周期中最敏感的步骤。发布过程包括以下步骤：
- 与客户/ 干系人一起定义发布及部署计划并达成一致意见。
- 确保每个发布包包含的一组相关资产与服务组件之间是相互兼容的。
- 确保在整个转换活动期间都能保持发布包及组件的完整性并在配置管理系统中准确记录。
- 确保所有发布包和部署包都能追踪、安装、测试、验证，以及卸载或者在需要时能够_回滚_(卸载新版本，重新部署旧版本)，如代码中存在错误、内存不足或许可证/ 证书过期。
DevOps 有很多种形式，但各种形式都始终贯穿两个主题：自动化 及 开发团队的职责。
1.4.1 自动化工具可以执行生命周期过程的每一个步骤需要的操作，针对生产环境或者外部操作规格说明检查操作的有效性，把过程中发生的错误报告给相关人员，并保留操作历史，以用于质量控制、报告和审计等目的。
在工具成为一组过程的中心后，就必须对这些工具进行管理。如工具调用可通过脚本、配置变更或运维终端；若是复杂的终端命令，建议把命令的使用脚本化。
工具可以通过规格说明文件进行控制，如Chefcookbooks, Amazon CloudFormation等。
“基础设施即代码（infrastructure-as-code）”
- 脚本、配置文件和规格说明文件必须遵循与应用代码一样的质量控制。
- 脚本和配置文件也应进行版本控制和错误检查。
规范敏捷交付包括三个阶段，DevOps实践会影响这三个阶段：
、
- 在开始阶段，运维人员考虑的内容将为开发人员增加一些需求。发布计划包含了为功能定优先级、开发与运维人员之间的配合、发布调度和确定运维人员为了支持新发布需要做哪些培训。
- 在构造阶段中，DevOps实践的关键是对代码分支的管理、持续集成和持续部署的使用、自动化测试的测试用例合并。
- 在转换阶段，由开发团队负责部署、监控部署过程，确定是否需要回滚以及何时回滚，并监控部署后的运行。
一般认为团队规模应该相对较小。
小团队特点在于：
- 可以快速做出决定；
- 团队成员之间更容易组成一个关系紧密的群体；
- 人在小团队比在大团队更容易表达意见；
- 不便之处是难以完成较大的任务，通常会将大任务分成若干个小任务，交给不同的小团队，团队之间需要配合。将开发团队输出成果成为**“服务”**。
美国国家技术与标准研究所 (National Institution of Standards and Technology, NIST) 给出了一个关于云的描述，使用了以下元素：
-
按需自助服务。用户可以单方面供给计算能力，如服务时间和网络存储，无需与服务供应商进行人工交互。
-
广泛的网络接入。能力通过网络提供并借助标准机制进行访问。
-
资源池化。服务供应商的计算资源被汇聚起来通过多租户模式提供给多个用户，不同的物理资源和虚拟资源按照用户的需要动态地进行分配和重新分配。
-
快速弹性。能力可被弹性的提供和释放。
-
可计量的服务。云能够利用计量能力来自动控制和优化资源的使用，该计量能力依据服务类型进行某种程度抽象。资源使用能被监控、控制，并可以被报告。
云供应商提供的服务可归纳为三类：
- 软件即服务 (Software as a Service, SaaS)。用户能够使用运行在云基础设施上的供应商应用。用户不需管理或控制底层尴尬的云基础设施，包括网络、服务器、操作系统、存储，甚至单独的应用程序功能。示例：电子邮件；
- 平台及服务 (Platform as a Service, PaaS)。用户能够向云基础设施部署自建或采购的应用程序，这些应用程序使用了供应商支持的编程语言、库、服务和工具来创建。示例：Web服务器、数据库、开发工具等；
- 基础设施即服务 (Infrastructure as a Service, IaaS)。用户能够配置处理器、存储器、网络以及其他基础计算资源，可以部署和运行任意软件，包括操作系统和应用程序。示例：虚拟机、存储器、负载均衡器、网络等；
在云计算中，虚拟机 (Virtual Machine, VM) 是物理机的模拟。
一个虚拟机镜像是一个文件，其中包含了可引导的操作系统和其在上边安装的软件。虚拟机镜像提供了启动虚拟机（更准确的说，虚拟机实例）所需的信息。
使用IaaS时，用户通过云供应商提供的应用程序接口（Application Programming Interface, API）从虚拟机获取一个虚拟机实例。
API可能嵌入在命令行解释器、Web界面或其他某种工具中。
API带有一组资源的虚拟机，包括CPU、内存和网络。
-
创建虚拟机：
用户发出一个创建命令。通常，云供应商有创建虚拟机的实用程序。需要将虚拟机所需的资源、虚拟机计费时对应的账户、要装载的软件，以及指定虚拟机安全性和外部连接的一组配置参数告知该实用程序。云基础设置确定在哪个物理机上创建该虚拟机实例。该物理机的操作系统成为_云监视器（hypervisor）_，他为新虚拟机分配一个IP地址 —— 该地址用于收发消息。
-
装载虚拟机：
创建虚拟机镜像的过程成为**“烧制”。一个重度烧制的镜像包含了运行应用所需的所有软件，一个轻度烧制**的镜像仅包含一部分需要的软件。
虚拟化引入了不确定性：1. 由于一个虚拟机对应一个物理机上的其他虚拟机共享资源，所以虚拟机之间可能会有干扰。2. 加载虚拟机取决于底层物理基础设施和需要动态加载的其他软件，可能有时间和可靠性方面的不确定性。
2.2.2 IP 和域名系统管理 DNS万维网（Word Wide Web，www）之下是一个将url 的一部分转换成 IP地址的系统。
域名表示了用于解析的路由路径。解析顺序由后向前，表示解析范围又大到小（本地）。
每个DNS项都有存活时间 Time to Live，TTL) 即DNS项的过期时间。客户端和本地会缓存该NDS项，该缓存项将在存活时间制定的时间内保持有效。当查询在过期时间前到达时，客户端/ 本地 DNS 服务器将其从缓存中直接获取IP地址。在过期时间后到达时，IP地址由权威DNS服务器来解析。
只要虚拟机处于活跃状态，虚拟机创建时分配给它的IP地址就会一直保持，当虚拟机被终止、暂停或停止时，处于不活跃状态。这种情况下，IP会返回给云供应商的池中重新分配。
2.3 独特的云特性对DevOps的影响- 简单创建和切换环境的能力；
- 轻松创建虚拟机的能力；
- 数据库管理。
环境 是 足够智行软件系统的一组计算机资源，包括所有支持软件、数据集、网络通信，以及执行软件系统所需定义的外部实体。
通过使环境之间没有可修改的共享资源来实现一个环境与另一个环境的隔离。
将生产轻松从一个环境切换到另一个环境可以使业务持续性的实现变得更为容易。业务持续性意味着当主数据中心发生故障时业务能够继续运作。
总结：云的使用开启了许多机会，但也面对分布式计算的相关问题：
云依赖的平台天生为分布式的，云还利用虚拟化来实现快速扩展和收缩给定用户的资源。
可以操纵IP地址来支撑通过隔离环境进行的各种形式的测试。
在大型分布式环境中，单个组件的故障的出现在意料之中。
从运维角度，需关注 控制虚拟机激增，管理不同的数据库管理系统，确保环境满足开发和运维任务的需要。
《Agile Project Management for dummies》- Mark C. Layton
敏捷软件开发宣言：个体和互动高于流程和工具；可工作软件高于详尽的文档；客户合作高于合同谈判；相应变化高于遵循计划。
价值二：
辨别文档是否有用：甘特图：包含贯穿始终的详细任务和日期进度计划总是超出产品开发所需，且有些细节在未来开发中有可能变化；需求文档：开发团队需要根据需求（产品特性和要求细节）来开发产品；产品技术规范：记录创建产品过程，使未来变更更容易，应简洁；定时状态报告：管理目的，无用于产品创建；
价值三：关注三个关键阶段：项目开始、项目中任何范围变更和项目结束。
3. 运维 3.1 运维服务定义敏捷十二原则：
- 优先考虑尽早和持续不断交付有价值的软件，使客户满意；
- 即使在开发后期也欢迎需求变更；
- 采用较短的项目周期（几周到几个月），不断可交付可工作软件；
- 业务人员和开发人员在整个项目期间一起工作；
- 围绕富有进取心的个体而创建项目；
- 无论团队内外，传递信息效率最高的方式是对面交谈；
- 可工作软件是度量进度的重要指标；
- 倡导可持续开发；
- 坚持不懈追求技术卓越和良好设计；
- 简洁为本，最大限度减少工作量；
- 最好的架构、需求和设计出自组织团队；
- 团队定期反思如何提高成效，并相应协调和调整自身行为。
运维服务包含供给硬件、供给软件，或者支持不同的IT功能；由运维提供的服务，还包括服务级别协议的规格说明和监控、容量规划、业务持续性以及信息安全。这些服务包含在DevOps实践过程中和过程外。影响运维的所有活动是：
- 硬件供给：虚拟化硬件可由开发团队或更自动化的应用来分配；
- 软件供给：内部开发的软件由开发团队进行部署，其他软件由运维提供；
- IT功能供给：开发团队负责事故处理和部署工具；
- 服务级协议的规格说明和监控：开发团队负责监控、评估和响应事故；
- 容量规划：开发团队负责单个应用的容量规划，运维团队负责整体容量规划；
- 业务连续性：开发团队负责与应用架构有关，运维团队负责其他部分。运维可以为业务连续性提供服务和策略，反过来可为开发团队使用；
- 信息安全：开发团队负责某个特定应用，运维负责其余全部；
IT 功能
运维活动支持不同的功能，这些功能包含：
- 服务台的运维。服务台的员工负责处理所有的事件和服务请求，并作为所有问题的第一级处理者；
- 技术专家。运维团队通常有网络、信息安全、存储、数据库、内部服务器、web服务器和应用程序的专家；
- IT服务的日常供给。这些包含周期性和重复性的维护运维、监控、备份以及设施管理；
组织可以使用2个关键参数对能够维持业务连续性的多个可选方案进行成本/收益分析：
- 恢复点目标 (Recovery Point Objective, RPO)：当灾难发生时，对数据丢失的最长容忍时间是多少？
- 回复时间目标 (Recovery Time Objective, RTO): 当灾难发生时，不能提供服务的最长容忍时间是多少？
这两个值是独立的。因为有些数据的丢失是可容忍的，但不可容忍不能提供服务；有些相反。
制定策略是 预定组织希望在特定时间内达到特定水平，首先判断组织当前的位置，决定从当前位置到一个期望状态的路径。
期望状态同时受内部和外部事件影响。内部事件包括人才调动、硬件故障、新软件发布，市场活动和商务活动；外部事件包括政府政策、收购或消费者反馈等。
3.4 服务运维 3.4.1 服务运维概念事故管理核心活动：
- 将事故记录到核心活动中；
- 分类和排优先级；
- 初步诊断；
- 如果有需要，上报给有相应技术或授权的人；
- 调研和诊断；
- 解决和恢复；
- 事故结束，如果有需要，侧重新分类、用户满意度调查、存档以及判断该事件是否还会发生。
核心：监控。
监控可以和其他控制方式结合，如 开环 和 闭环。
持续服务改进的焦点：IT服务和业务需求之间达成一致。
