第一节：ITIL

TIL即IT基础架构库(Information Technology Infrastructure Library), ITIL，信息技术基础架构库)由英国政府部门CCTA(Central Computing and Telecommunications Agency)在20世纪80年代末制订，现由英国商务部OGC(Office of Government Commerce)负责管理，主要适用于IT服务管理（ITSM）。ITIL为企业的IT服务管理实践提供了一个客观、严谨、可量化的标准和规范。

ITIL 就是一个标准规范，他并不是一个软件和系统，举例来说，如果想自己构建一个IT服务的系统可以按照这个规范去实现。有一个指定方针！

ITIL分为以下内容

1、事件管理（Incident Management）

事故管理负责记录、归类和安排专家处理事故并监督整个处理过程直至事故得到解决和终止。事故管理的目的是在尽可能最小地影响客户和用户业务的情况下使IT系统恢复到服务级别协议所定义的服务级别。

注释：故障申报处理模块，出现故障把事故给相应的人去处理！一步一步的解决！

2、问题管理（Problem Management）

问题管理是指通过调查和分析IT基础架构的薄弱环节、查明事故产生的潜在原因，并制定解决事故的方案和防止事故再次发生的措施，将由于问题和事故对业务产生的负面影响减小到最低的服务管理流程。与事故管理强调事故恢复的速度不同，问题管理强调的是找出事故产生的根源，从而制定恰当的解决方案或防止其再次发生的预防措施。

注释：类似知识库、提供一些帮助，定位问题和预防的措施。

3、配置管理（Configuration Management）

配置管理是识别和确认系统的配置项，记录和报告配置项状态和变更请求，检验配置项的正确性和完整性等活动构成的过程，其目的是提供IT基础架构的逻辑模型，支持其它服务管理流程特别是变更管理和发布管理的运作。

注释：识别和确认系统的配置项，配置项可以是硬件、也可以是软件！

如果是硬件：一个主机、一个硬盘、一个鼠标都可以是配置项。

如果是软件：比如公司购买的软件

做的CMDB就是ITIL的“配置管理”，SaltStack最明显的作用就是批量管理，还有一个作用就是配置管理，他可以把你的机器配置成你想要的状态！你想要这个机器配置什么服务、什么软件！这也可以叫配置管理！

这个配置管理可以看做CMDB的中的一项功能

4、变更管理（Change Management）

变更管理是指为在最短的中断时间内完成基础架构或服务的任一方面的变更而对其进行控制的服务管理流程。变更管理的目标是确保在变更实施过程中使用标准的方法和步骤，尽快地实施变更，以将由变更所导致的业务中断对业务的影响减小到最低。

注释：我的理解是举例来说：在服务器需要替换的时候、修改主机名、这个都需要流程化、标准化。

5、发布管理（Release Management）

发布管理是指对经过测试后导入实际应用的新增或修改后的配置项进行分发和宣传的管理流程。发布管理以前又称为软件控制与分发

注释：代码发布，它可以做为一个独立的系统！

如果想在公司做自动化，按照这个5大块来做就不会偏离自动化偏离太远，ITIL真正实施的很少因为很大！不过我们可以借鉴它来参考去做我们自动化的东西！

上面5大块具体实现的目标：

事件管理的目标是在不影响业务的情况下，尽可能快速的恢复服务，从而保证最佳的效率和服务的可持续性。事件管理流程的建立包括事件分类，确定事件的优先级和建立事件的升级机制。

问题管理是调查基础设施和所有可用信息，包括事件数据库，来确定引起事件发生的真正潜在原因，一起提供的服务中可能存在的故障。

配置管理的目标是：定义和控制服务与基础设施的部件，并保持准确的配置信息。

变更管理的目标是：以受控的方式，确保所有变更得到评估、批准、实施和评审。

发布管理的目标是：在实际运行环境的发布中，交付、分发并跟踪一个或多个变更。

服务台：服务台是IT部门和IT服务用户之间的单一联系点。它通过提供一个集中和专职的服务联系点促进了组织业务流程与服务管理基础架构集成。服务台的主要目标是协调客户（用户）和IT部门之间的联系，为IT服务运作提供支持，从而提高客户的满意度。

服务台：以上的流程是我们运维和研发同学在后台实现的，如果要后期要交给其他用户，就需要一个入口。完整的前端结合！

第二节：CI/CD

在互联网时代，对于每一个企业，公司，产品快速迭代的重要性不言而喻，针对敏捷开发以使用CICD来完成。

CI/CD持续集成/持续部署

持续集成(Continuous integration)是一种软件开发实践，即团队开发成员经常集成它们的工作，通过每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。

持续部署（continuous deployment）是通过自动化的构建、测试和部署循环来快速交付高质量的产品。某种程度上代表了一个开发团队工程化的程度，毕竟快速运转的互联网公司人力成本会高于机器，投资机器优化开发流程化相对也提高了人的效率，让 engineering productivity 最大化。

持续交付（英语：Continuous delivery，缩写为 CD），是一种软件工程手法，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以释出的状况。它的目标在于让软件的建置、测试与释出变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。

与DevOps的关系

持续交付与DevOps的含义很相似，所以经常被混淆。但是它们是不同的两个概念。DevOps的范围更广，它以文化变迁为中心，特别是软件交付过程所涉及的多个团队之间的合作（开发、运维、QA、管理部门等），并且将软件交付的过程自动化。另壹方面，持续交付是壹种自动化交付的手段，关注点在于将不同的过程集中起来，并且更快、更频繁地执行这些过程。因此，DevOps可以是持续交付的壹个产物，持续交付直接汇入DevOps；

与持续部署的关系

有时候，持续交付也与持续部署混淆。持续部署意味着所有的变更都会被自动部署到生产环境中。持续交付意味着所有的变更都可以被部署到生产环境中，但是出于业务考虑，可以选择不部署。如果要实施持续部署，必须先实施持续交付

CI/CD一篇不错的文章：https://www.cnblogs.com/gudi/p/6667102.html，摘要如下：

CI简介：

CI有一些常用的核心规则，主要规则如下：

规则1：尽量频繁地把代码签入到分支中以进行集成

规则2：不光要对语法进行验，也要提供一系列的自动化来验证

规则3：CI失败后，要把修复CI当做第一优先级的事情

CI有不同的仓库设计方法，一般情况下都会最终映射为微服务，方便部署。

CD简介：

CD采用pipeline方式，它告诉我们每个步骤是否完成，距离最终的产品交付还有哪几项，软件质量的可视化得到了极大改善。