随着互联网发展迅猛，不同的公司IT基础设施面临的增长和快速发展。从人肉维护，建设到半自动，全自动，由此产生的自动化体系/运维工具越来越多，目前大多数运维IT环境架构主要分为3种技术体系:

1)开源工具

2)自研发工具(更多的是包含和利用开源软件优秀的特性进行定制化开发）

3)从0自主研发，底层改造到应用层开发

开源的代表作有很多，比如：puppet，saltstack，Ansible，Nagios，Zabbix，Docker，KVM，Openstack等主流开源软件。

自研:资产管理系统，发布系统，监控系统，配管系统，工单系统等。

总结：运维自动化已经是成熟的代名词了，无论从网上搜索，还是各大技术分享，都有很多不错的案例和实施过程。但也很多朋友觉得实施起来很困难，复杂，但是看似很简单。困难和复杂：想不通如何把重复性，不可规整/聚合，业务连接成一线枢纽。看似简单：因为有人/其他互联网运维团队实施出来了，实现的还不错，看似近在迟尺。先定义后实施，这个是关键点，想明白才去做，没想明白千万别去做，否则只有推翻重来或者坑越来越多。

定义分为三个层面：1.数据的定义2.事件的定义3.流程的定义

1.数据的定义：

一切的基石基于数据，第一步数据的纬度要设计好：

①.机房的定义：比如北京机房，上海机房，香港机房等

②.机器类型定义：私有云，公有云，物理机，公有云：ali，aws等细化纬度。

③.业务定义：比如官网业务，订单业务等纬度细化。

④.存储的定义：比如根据自家公司的业务和技术体系来设计：

比如哪些基础信息是需要的，哪些信息看似可要/可不要的，要做好取舍。

数据存储的信息一定要是展现出来有实际意义的，数据存储不在于多，而是在于价值，繁重的数据越来越多，如果定义很多可有/可无的数据存储，对于一个IT基础资产库来说，也是种负担。

数据的存储考量：唯一的，有价值的，可维护，可扩展的四个原则。

⑤.协同的定义：当拥有一份完整的IT基础资产库的时候，只是一份基石，基石铺垫好了，才有上升的扩建空间，数据的标准接入协同分为二部分：

1）内部的系统/资源（运维内部的系统）

2）外部的系统/资源  (业务，安全的系统）

内部系统/资源和外部系统/资源对资产信息库的对接关系策略纬度：

1.可增加/删除的，初始化类型数据系统/可移除的资源数据系统，比如：自动化装机系统

2.可获取的，获取的信息纬度哪些类型，比如：发布系统，监控系统(拿到资产信息库的业务类型，组，主机/IP信息等。

3.可查询的，单条件查询，多条件查询，连同条件查询，比如：安全审计系统，业务类型系统，对外/对内访问IP区分等。

2.事件的定义：

第一要点的数据定义已经设计好，有了完整规范的数据格式，来定义围绕基础信息库基石上扩展事件。

事件定义的逻辑方法论：事件设计-事件构建-事件交付-事件数据汇总

每个自动化操作都依据某个事件场景来实施，实施的策略很多，也需要平衡好优缺点。

1）数据的初始化录入系统，俗称：自动化装机系统

自动化装机系统初衷：

1.需要人工重复性操作

2.快速交付时间周期慢

3.技术提升优势不大

4.用事件根据场景来优化

自动化装机系统交付要点(根据不同主机类型来构建事件场景)：

1.物理机类型（硬件层面：不同硬件厂商的类型，比如远程卡，BIOS初始化，RAID阵列自动划分，软件层面：cobbler)

2.公有云类型  (服务商的Api或者SDK接口）

3.私有云类型 （Openstack，Docker，KVM私有云规范的Api接口或者自己构造一份标准的接口）.

4.从类型选择初始化配置-内部DNS数据接入-获取主机信息资源-启动新主机。

5.数据完整保存，方便以后分析和进一步优化。比如：成本的使用/扩展，业务方机器资源使用率，分析对该事件场景构建优化提升之处。

发布系统，运维日常支持工作占到百分之50%或者更多。代码发布也是运维考核的和支持最重要的一项日常工作。

发布环境常用的包含：local，beta，demo，gray，online等

发布的代码类型：混合型居多。

通常情况下，人肉支撑的耗时，重复性，自检成功/失败发布，排查故障周期很长。尤其是对于重要业务平滑，耗时的情况更多。

而发布系统满足重要的三个因素：

1.自动无损平滑发布（支持多种负载均衡策略，发布代码不重启服务策略，环境组主机流量自动切换）和可视化实时过程/结果查看。

2.稳定，并行的构造多环境/多业务发布，即使某个业务出问题，对于整个发布平台/其他业务发布也是无感知，无影响。

3.权限，安全隔离，完整的审计功能，让研发自助的发布。

4.数据的完整保存，分析目前业务发布测试/迭代，资源调度率，发布时间点，全年发布优化指标等。

总结：以上就举2个事件场景构建的案例，一切事件构建皆为场景，场景的价值在于数据是否帮助/量化，改进业务层面/运维层面的持续增长/交付。

3.流程的定义(一切入口，规范，从流程抓起）

为什么最后才是流程，因为在没有数据做基础铺垫，事件场景构建，一切谈流程都是空话，虚拟的。

流程基于实施的要素：

1)基于一切数据+事件的入口配置

2)流程不在于复杂，在于易用，快捷，可塑造。

3)源地址-目的地址全部过程保存，可追踪。

自动化价值：

1）价值性产出：站在业务/团队角度去思考，不追从完美产品方案，只选择合适的产品方案，同时在一定程度上做好取舍。

2）从小而做到细，从细扩展到大，才是本质。

3)  自动化产出一切为数据，对数据定义要设计好，宁愿设计周期长些，也不要盲目实施。

原创：符杰超

随着互联网发展迅猛，不同的公司IT基础设施面临的增长和快速发展。从人肉维护，建设到半自动，全自动，由此产生的自动化体系/运维工具越来越多，目前大多数运维IT环境架构主要分为3种技术体系:

1)开源工具

2)自研发工具(更多的是包含和利用开源软件优秀的特性进行定制化开发）

3)从0自主研发，底层改造到应用层开发

开源的代表作有很多，比如：puppet，saltstack，Ansible，Nagios，Zabbix，Docker，KVM，Openstack等主流开源软件。

自研:资产管理系统，发布系统，监控系统，配管系统，工单系统等。

总结：运维自动化已经是成熟的代名词了，无论从网上搜索，还是各大技术分享，都有很多不错的案例和实施过程。但也很多朋友觉得实施起来很困难，复杂，但是看似很简单。困难和复杂：想不通如何把重复性，不可规整/聚合，业务连接成一线枢纽。看似简单：因为有人/其他互联网运维团队实施出来了，实现的还不错，看似近在迟尺。先定义后实施，这个是关键点，想明白才去做，没想明白千万别去做，否则只有推翻重来或者坑越来越多。

定义分为三个层面：1.数据的定义2.事件的定义3.流程的定义

1.数据的定义：

一切的基石基于数据，第一步数据的纬度要设计好：

①.机房的定义：比如北京机房，上海机房，香港机房等

②.机器类型定义：私有云，公有云，物理机，公有云：ali，aws等细化纬度。

③.业务定义：比如官网业务，订单业务等纬度细化。

④.存储的定义：比如根据自家公司的业务和技术体系来设计：

比如哪些基础信息是需要的，哪些信息看似可要/可不要的，要做好取舍。

数据存储的信息一定要是展现出来有实际意义的，数据存储不在于多，而是在于价值，繁重的数据越来越多，如果定义很多可有/可无的数据存储，对于一个IT基础资产库来说，也是种负担。

数据的存储考量：唯一的，有价值的，可维护，可扩展的四个原则。

⑤.协同的定义：当拥有一份完整的IT基础资产库的时候，只是一份基石，基石铺垫好了，才有上升的扩建空间，数据的标准接入协同分为二部分：

1）内部的系统/资源（运维内部的系统）

2）外部的系统/资源  (业务，安全的系统）

内部系统/资源和外部系统/资源对资产信息库的对接关系策略纬度：

1.可增加/删除的，初始化类型数据系统/可移除的资源数据系统，比如：自动化装机系统

2.可获取的，获取的信息纬度哪些类型，比如：发布系统，监控系统(拿到资产信息库的业务类型，组，主机/IP信息等。

3.可查询的，单条件查询，多条件查询，连同条件查询，比如：安全审计系统，业务类型系统，对外/对内访问IP区分等。

2.事件的定义：

第一要点的数据定义已经设计好，有了完整规范的数据格式，来定义围绕基础信息库基石上扩展事件。

事件定义的逻辑方法论：事件设计-事件构建-事件交付-事件数据汇总

每个自动化操作都依据某个事件场景来实施，实施的策略很多，也需要平衡好优缺点。

1）数据的初始化录入系统，俗称：自动化装机系统

自动化装机系统初衷：

1.需要人工重复性操作

2.快速交付时间周期慢

3.技术提升优势不大

4.用事件根据场景来优化

自动化装机系统交付要点(根据不同主机类型来构建事件场景)：

1.物理机类型（硬件层面：不同硬件厂商的类型，比如远程卡，BIOS初始化，RAID阵列自动划分，软件层面：cobbler)

2.公有云类型  (服务商的Api或者SDK接口）

3.私有云类型 （Openstack，Docker，KVM私有云规范的Api接口或者自己构造一份标准的接口）.

4.从类型选择初始化配置-内部DNS数据接入-获取主机信息资源-启动新主机。

5.数据完整保存，方便以后分析和进一步优化。比如：成本的使用/扩展，业务方机器资源使用率，分析对该事件场景构建优化提升之处。

发布系统，运维日常支持工作占到百分之50%或者更多。代码发布也是运维考核的和支持最重要的一项日常工作。

发布环境常用的包含：local，beta，demo，gray，online等

发布的代码类型：混合型居多。

通常情况下，人肉支撑的耗时，重复性，自检成功/失败发布，排查故障周期很长。尤其是对于重要业务平滑，耗时的情况更多。

而发布系统满足重要的三个因素：

1.自动无损平滑发布（支持多种负载均衡策略，发布代码不重启服务策略，环境组主机流量自动切换）和可视化实时过程/结果查看。

2.稳定，并行的构造多环境/多业务发布，即使某个业务出问题，对于整个发布平台/其他业务发布也是无感知，无影响。

3.权限，安全隔离，完整的审计功能，让研发自助的发布。

4.数据的完整保存，分析目前业务发布测试/迭代，资源调度率，发布时间点，全年发布优化指标等。

总结：以上就举2个事件场景构建的案例，一切事件构建皆为场景，场景的价值在于数据是否帮助/量化，改进业务层面/运维层面的持续增长/交付。

3.流程的定义(一切入口，规范，从流程抓起）

为什么最后才是流程，因为在没有数据做基础铺垫，事件场景构建，一切谈流程都是空话，虚拟的。

流程基于实施的要素：

1)基于一切数据+事件的入口配置

2)流程不在于复杂，在于易用，快捷，可塑造。

3)源地址-目的地址全部过程保存，可追踪。

自动化价值：

1）价值性产出：站在业务/团队角度去思考，不追从完美产品方案，只选择合适的产品方案，同时在一定程度上做好取舍。

2）从小而做到细，从细扩展到大，才是本质。

3)  自动化产出一切为数据，对数据定义要设计好，宁愿设计周期长些，也不要盲目实施。

原创：符杰超