01 ｜ 为什么Netflix没有运维岗位？
微服务复杂到一定程度，远超单纯的开发和运维的指责范畴，也远超单纯人力的掌控范围，所以需要寻求在此架构之上的更为有效和统一的解决方案，从而开发和运维产生了新的指责分工和协作方式。
Netflix带给我们的启示一：
微服务架构模式下，我们必须换一个思路来重新定义和思考运维，运维一定要与微服务架构本身紧密结合起来。
Netflix带给我们的启示二：
合理的组织架构是保障技术架构落地的必要条件，用技术手段来解决运维过程中遇到的效率和稳定问题才是根本解决方案。
Netflix带给我们的启示三：
Owner意识很重要，正确的做事方式需要引导，这就是优秀和极致的距离。
02 ｜ 微服务架构时代，运维体系建设为什么要以“应用”为核心？
应用的起源：微服务架构一般是从单体架构或分层架构演进过来的。软件架构服务化的过程，就是我们根据业务模型进行细化的过程，也就是在这个过程中切分出一个个具备不同职责的业务逻辑模块，然后每个微服务模块都会提供相对应的业务逻辑的服务化接口。
这些模块可以独立部署和运行， 并提供对应的业务能力，拆分后模块的数量与业务体量和复杂度相关，少则十几个，多则上百个，我们通常称这些模块为应用。
为了确保每个应用的维一性，我们给每个应用定义一个唯一的标识符，如 APP01、APP02等，我们常称这些标识符为“应用简称” 。应用的概念将是我们进行微服务架构管理的核心概念。
各个应用之间相对独立，但为了完成整体的业务流程和目标，各应用之间就必然会进行交互，然而交互的过程就需要依赖一些基础设施和组件，如服务器资源、域名、数据库、缓存、消息队列等等。所以除了应用实体之外，还存在一些基础组件实体，应用在运行的过程中，需要不断的和基础组件实体之间产生和建立各种复杂的关联关系，这也为后续运维带来了诸多困难。
所以，我们首先要做的就是以应用模型为中心，梳理与之相关的各类模型以及相关之间的关系，这是我们后续运维自动化、持续交付以及稳定性保障的基础。
1. 应用业务模型
应用业务模型是每个应用对外提供的业务服务能力，并以API的方式对外提供服务，通常是由业务架构师在进行需求分析和拆解时进行设计，更多的是聚焦业务逻辑。
2. 应用管理模型
应用管理模型，就是应用管理所需要的各类属性信息，如应用名、应用描述、负责人、代码库地址、部署结构、启停方式、健康检测方式等。
3. 应用所依赖的基础设施和组件
资源层面：
应用运行所依赖的计算资源（物理机、虚拟机或容器），对外提供的服务地址（如域名）
基础组件：
应用容器（Tomcat、Wildfly）和数据库组件、缓存组件、消息队列组件、文件存储服务组件、分布式任务调度组件等等。
基础设施和组件都是为上层一个个业务应用服务的，脱离了业务应用，这些组件和基础设施并没有单纯存在的意义。
通过梳理信息我们就可以建立出以应用为核心的应用模型和关联关系模型，基于应用这个统一的概念，系统中原本分散杂乱的信息，最终都被串联了起来，应用也成为了整个运维信息管理及流转的纽带。
微服务架构模式下的运维思路也需要转变，一定要将视角转换到应用这个纬度，从一开始就要统一规划，并将架构设计、研发过程、运维工作整体全局拉通考虑。
03 ｜ 标准化体系建设，如何建立应用标准化体系和模型？
标准化工作所运维过程中最基础、最重要但又是最容易被忽视的一个环节。
为什么要做标准化？
标准化的过程设计上就是对运维对象的识别和建模的过程。形成统一的对象模型后，针对不同对象抽取他们所对应的运维场景，接下来才是运维场景自动化的实现。
标准化套路：
- 识别对象。
- 识别对象属性。
- 识别对象关系。
- 识别对象场景。
基础设施层面的标准化
识别实体对象
主要有服务器、网络设备、IDC、机柜、存储等。
识别对象属性
比如服务器，就有对应的SN序列号、IP地址、品牌、型号、硬件配置、维保信息等。
识别对象之间的关联关系
比如服务器所在机柜、虚拟机所在宿主机、机柜所在IDC等简单关系。
复杂的例如 核心交换机、汇聚交换机、接入交换机以及和服务器之间的端口连接关系。
识别运维场景
以服务器为例，日常操作有采购、入库、出库、安装、配置、上线、下线、维修等等。
另外坑存在可视化和查询场景，如拓扑关系的可视化和动态展示，交换机与服务器之间的级联关系、状态的展示等。
根据这些场景的优先级才能去做相关的开发建设。
应用层面的标准化
1. 识别对象
2. 识别对象属性
样例：一个应用应该具备哪些基本的运维属性
应用的元数据属性
如应用名、应用负责人、所属业务、是否核心链路应用以及应用功能说明等。
应用代码属性
主要是编程语言及版本（决定了后续的构建方式），Git代码库地址等。
应用部署模式
涉及到基础软件包，如语言包 Java、C++、Go 等；容器如 Tomcat、JBoss 等。
应用目录信息
如运维脚本目录、日志目录、应用包目录、临时目录等。
应用运行脚本
如启停脚本、健康监测脚本等。
应用运行时的参数配置
如运行端口、Java 的 JVM 参数 、GC 方式、堆内存大小配置等。
3. 识别对象关系
应用和基础设施的关系
包括应用与计算资源、应用与 负载均衡VIP、应用与域名解析的关系等；
应用与应用之间的关系
应用服务或 API 与其它应用服务和 API 的依赖关系。（可以通过调用链监控工具获取应用服务接口之间的调用和依赖关系）
应用与各类基础组件之间的关系
比如应用与缓存，应用与消息队列、应用与 DB 之间的关系等等。
4. 识别运维场景
应用创建、持续集成、持续发布、扩容、缩容、监控、故障自愈等；
再复杂点的比如容量评估、压测、限流降级等。
微服务的分布式架构下，涉及到的主要基础架构组件：
分布式服务化框架
业界开源产品比如 Dubbo、Spring Cloud 框架；
分布式缓存及框架
业界如 Redis、Memcached，框架如 Codis 和 Redis Cluster；
数据库及分布式数据库框架
数据库如 MySQL、MariaDB 等，中间件如淘宝 DRDS、Sharding-JDBC、Mycat等。
分布式的消息中间件
如 Kafka、RabbitMQ、ActiveMQ 以及 RocketMQ 等；
接入层
如四层负载 LVS，七层负载 Nginx 或 Apache，再比如硬件负载 F5 等。
当业务开发人员的资源消耗在和业务开发无关的事情上，业务开发就很聚焦于业务架构，无法更快、更多、更好的完成业务需求。
运维的职责：基础架构标准化 + 基础架构服务化
参与制定基础架构标准，并强势约束。
基础架构服务化平台建设
让开发使用平台功能完成基础组件的服务自助化，而不是依赖运维人员。
组织架构决定产品形态。
各家公司由于历史原因，会存在各种遗留问题，在业务高速发展时期，需要CTO和总架构师高瞻远瞩，将组织架构和团队职责做好划分，发挥各团队最大化效能，只有这样，企业IT才能更好更长久的发展。
