最近在学习赵成大佬的《进化/运维技术变革与实践探索》一书，在极客时间也有教程。整本书从以下的四个方面进行了梳理：应用运维体系建设、效率和稳定性等方面的最佳实践、云计算方面的思考和实践、个人成长与趋势热点分析。自己在运维行业也有四五年了，但是还未形成自己的知识体系；只有在大量的输入、记笔记、思考、整理后，才能打造出属于自己的知识体系（不管哪个行业）。因此在学习这本书的时候，也分四部分记录自己的学习和思考。
运维体系建设的核心
运维体系建设的核心是：应用
1、应用的起源
1）从单体工程，拆分出n个独立的模块；这些模块可独立部署和运行，并提供对应的业务能力；模块数量与业务复杂度相关；并且每个应用都有唯一的标识符，也就是应用名。
2）此拆模块的过程为从业务角度入手进行拆分细化得到业务逻辑单元；
2、应用模型及关系模型的建立
应用业务模型：也就是每个应用对外提供的业务服务能力，以API的方式暴露给外部；这个业务模型通常是由业务架构师在进行业务需求分析和拆解时设计，更多的是聚焦在业务逻辑上。
应用管理模型：也就是应用自身的各种属性，如应用名、应用功能信息、责任人、Git地址、部署结构（代码路径、日志路径以及各类配置文件路径等）、起停方式、健康监测方式等。
应用运行时所依赖的基础设施和组件：
资源层面：应用运行时所必须的资源载体如物理机、虚拟机或容器；若提供对外服务则还有虚拟IP和DNS域名服务。
基础组件：主要是中间件体系，如数据库、缓存、消息队列、存储等。
应用业务模型主要是开发/架构师关注；应用管理模型和应用运行时所依赖基础设施和软件主要是运维关注。基础设施和关联组件都是为了上层应用服务，若脱离了业务，单独的基础设施和组件没有意义。
应用业务模型、应用管理模型、应用运行时所依赖的基础设施和组件三者关联：
3、应用的生命周期
1）应用的创建阶段
2）应用的研发阶段
3）应用的上线阶段
4）应用的运行阶段
5）应用的销毁阶段
标准化体系建设的基础
标准化、标准化、标准化
标准化的步骤：
标准化的过程实际上是对运维对象的识别和建模；
1）识别运维对象
2）识别对象属性
3）识别对象关系
4）识别对象场景
基础设施层面的标准化：
1）识别运维对象，主要由服务器、网络、IDC、机柜、存储、配件等。
2）识别对象属性，比如服务器的SN序列号、IP地址、厂商、硬件配置（CPU、内存、硬盘、网卡、PCIE、BIOS）、维保信息等；网络设备的属性如厂商、型号、带宽等。
3）识别对象关系，比如服务器所在的机柜、虚拟机所在的宿主机、机柜所在的IDC等，网络拓扑关系等。
4）识别对象场景，服务器的日常操作有采购、入库、安装、配置、上线、下线、维护等。可视化和查询的场景有拓扑关系的可视化和动态展示，交换机和服务器之间的级联关系，状态（正常/故障）展示等。
将以上的信息通过ER建模工具进行数据建模，再将以上的信息固化到数据库中，资源层面的CMDB基本成型。信息固化不是目的，信息流动起来才有价值。
应用层面的标准化：
1）识别运维对象，在做微服务架构设计或拆分的时候就确定下来。
2）识别对象属性
应用的元数据属性：也就是简单直接的描述一个应用的信息，如应用名、应用owner、所属业务、是否是核心链路以及应用功能说明。
应用的代码属性：主要是编程语言及版本（决定后续的构建方式）和GitLab地址。
应用的部署模式：涉及的基础软件包，如Java、C++、Go等语言包，以及如Tomcat、JBoss等容器。
应用的目录信息：运维脚本目录、日志目录、应用包目录、临时目录等。
应用的运行脚本：如启停脚本、健康监测脚本。
应用的运行时参数配置：运行端口、Java的JVM参数GC方式，以及新生代、老生代、永生代的堆内存大小配置等。
3）识别对象关系
应用与基础设施的关系：包括应用与资源、应用与VIP、应用与DNS等的关系。
平行层面的应用与应用之间的关系：应用服务或API与其他应用服务和API的依赖关系，比如全链路这样的工具平台，就是用来处理应用间关系管理的。
应用与各类基础组件之间的关系：比如应用与缓存、应用与消息、应用与数据库之间的关系等。
4）识别对象场景
应用创建、持续集成、持续发布、扩容、缩容、监控，容量评估、压测、限流降级等。
标准化体系建设的基础架构
常见的分布式基础架构组件：
在微服务的分布式架构下，设计的主要基础架构组件有：
分布式服务化框架：如Dubbo、Spring Cloud等。
分布式缓存及框架：缓存如Redis、Memcache等，框架如Codis、Redis Cluster等。
数据库及分布式数据库框架：数据库如Mysql、MariaDB等。
分布式的消息中间件：如Kafka、RabbitMQ、ActiveMQ以及RocketMQ等。
前端接入层部分：四层负载LVS，七层负载Nginx或Apache，再比如硬件负载F5等。
基础架构组件的选型：
从开发层面和运维层面进行选型调研。
基础架构服务化：
对基础架构组件制定了统一的标准后，需要对其进行服务化，比如通过对API接口的封装，进行运维的操作，其实就是PaaS化的过程，产出结果就是Paas平台。
金句
1、软件架构的目的，是将构建和维护所需的人力资源降到最低。
2、跳出运维看运维，从架构角度看运维，这种运维思路上的转变，远比单纯提升运维技术更有价值。
3、SRE不等于运维，SRE的核心理念是：用软件工程的方法重新设计和定义运维工作。
4、在微服务架构下，必须换一个思路来重新定义和思考运维，运维一定要与微服务架构本身紧密结合起来。
5、合理的组织架构是保障技术架构落地的必要条件，用技术手段来解决运维过程中遇到的效率和稳定性问题才是根本解决方案。
6、我们要建立以应用为核心的运维管理体系。
总结
整个这部分介绍了标准化系统建设的核心是应用，然后对基础设施层面的标准化、应用层面的标准化、基础架构的标准化进行了介绍。这些理论上的东西我们要结合自己工作进行比对，看哪些时做的好的，哪些是需要改进的，应用到实际的工作中。可以自己画一张数据模型图出来。从这里也可以看出我们平时需要的运维技术体系也有一个大概的模型。
最后
李先生（Lemon），高级运维工程师（自称），SRE专家（目标）。喜欢钻研底层技术，认为底层基础才是王道。一切新技术都离不开操作系统（CPU、内存、磁盘）、网络等。坚持输入输出，记录自己学习的点滴，在平凡中坚持前行，总有一天会遇见不一样的自己。公众号：运维汪（ID：Leeeee_Li）
