1⾄3节
微服务架构复杂度到了⼀定程度，已经远远超出单纯的开发和单纯的运维职责范畴，也远远超出了单纯⼈⼒的认知掌控范围，所以必须寻求在此架构之上的更为有效和统⼀的技术解决⽅案来解决复杂度认知的问题。进⽽，在这⼀套统⼀的技术解决⽅案之上，开发和运维产⽣了新的职责分⼯和协作⽅式。 微服务架构模式下，我们必须换⼀个思路来重新定义和思考运维，运维⼀定要与微服务架构本⾝紧密结合起来。
合理的组织架构是保障技术架构落地的必要条件，⽤技术⼿段来解决运维过程中遇到的效率和稳定问题才是根本解决⽅案
Netflix 的企业⽂化是 Freedom & Responsibility，也就是⾃由和责任并存，⾼度⾃由的同时，也需要员⼯具备更强的责任⼼和 Owner 意识。体现在技术团队中就是，You Build It，You Run It。⼯程师可以随时向⽣产环境提交代码或者发布新的服务，但是同时你作为Owner，要对你发布的代码和线上服务的稳定运⾏负责
Owner 意识很重要，正确的做事⽅式需要引导，这就是优秀和极致的距离
包装箱制作
应⽤模型及关系模型的建⽴
应⽤模型
应⽤业务模型：每个应⽤对外提供的业务服务能⼒，并以 API 的⽅式暴露给外部
应⽤管理模型：应⽤⾃⾝的各种属性，如应⽤名、应⽤功能信息、责任⼈、Git 地址、部署结构（代码路径、⽇志路径以及各类配置⽂件路径等）、启停⽅式、健康检测⽅式
资源层⾯（资源载体）：ecs，
基础组件（中间件）：DB，消息队列，Redis，⽂件存储
关系模型
建⽴各个基础设施和组件的数据模型，同时识别出它们的唯⼀标识
识别出基础设施及组件可以与应⽤名 AppName 建⽴关联关系的属性，或者在基础组件的数据模型中增加所属应⽤这样的字段
微服务架构模式下的运维思路⼀定要转变，⼀定要将视⾓转换到应⽤这个维度，从⼀开始就要统⼀规划，从⼀开始就要将架构、开发和运维的⼯作拉通了去看，这⼀点是与传统运维的思路完全不同的。
我们要转换视⾓，规划以应⽤为核⼼的运维管理体系。
标准化的过程实际上就是对运维对象的识别和建模过程。形成统⼀的对象模型后，各⽅在统⼀的认识下展开有效协作，然后针对不同的运维对象，再抽取出它们所对应的运维场景，接下来才是运维场景的⾃动化实现。
标准化体系建设：如何建⽴应⽤标准化体系和模型？
标准先⾏，标准先⾏，标准先⾏
标准化的过程实际上就是对运维对象的识别和建模过程。于纷繁复杂中抽象出标准规范的东西，是我们后续⼀系列⾃动化和稳定性保障的基础
标准化的思路：
1. 识别对象
2. 识别对象属性
3. 识别对象关系
4. 识别对象场景
应⽤层⾯标准化
如何建⽴基础架构标准化及服务化体系？
基础架构标准化
基础组件的选型问题？
产品形态不⼀，导致需要⼤量适配⼯作
采⽤不同的基础架构，产品探索过程后⽆法应⽤到其他业务团队。
组件不统⼀时，需要⼤量适配⼯作
⼯作量⼤，导致后期故障频发问题，
团队内部⽭盾激化
推进基础架构统⼀规划与建设
网页游戏开发技术原则上，每种基础组件只允许⼀种选型，⾄少就能满⾜ 90% 甚⾄更多的应⽤场景
⽐如定mysql的版本
基础架构的服务化
基于这些原⽣能⼒进⾏封装，结合运维场景，将能⼒服务化，这样就⼤⼤提升了使⽤⽅的便利性。(⽐如阿⾥云产品，即PAAS)
运维职责
1. 基础架构标准化
2. 基础架构的服务化
有意识去做的两件事情:
参与制定基础架构标准，并强势地约束
基础架构的服务化平台开发，⽬标是平台⾃助化，让开发依赖平台的能⼒⾃助完成对基础组件的需求，⽽不是依赖运维的⼈如果不朝着服务化⽅向发展，运维将始终被拖累在这些基础组件的运维操作上
如何从⽣命周期的视⾓看待应⽤运维体系建设
问题：如何进⾏准确和全⾯的识别对象？
从“应⽤⽣命周期管理”的⾓度分阶段去梳理。对于⼀个对象，既然有⽣命周期，就会有不同的⽣命周期阶段，那这个对象在不同的阶段，可能就会具备不同的属性、关系和场景。只要我们把⼀个对象的⽣命周期阶段理清楚了，顺着这条主线分阶段进⾏分解，就可以分析得更加清晰、明确和具体了。
应⽤的⽣命周期
应⽤创建
基础信息: 应⽤名，责任⼈，gitlab, 代码类型，是否核⼼应⽤
基础服务（mysql，cache，vip， dns， topic）关系
研发阶段
持续集成
⼯具链⽀持
上线阶段
上线，灰度，测试
运⾏阶段
运维⾓度：
运⾏状态相关的属性：进程，端⼝，⽬录，⽇志
相关联的基础服务的各项运⾏指标
业务⾓度：
持续集成过程
依赖管理
链路跟踪的场景
异常变化
基础设施异常
基础服务异常
应⽤服务异常
活动⼤促
第三⽅依赖故障: IDC,
销毁阶段
关联资源清理
总结触摸笔
运维架构的切⼊点：从⽣命周期⼊⼿，划分阶段，提炼属性，理清关系，固化基础信息(CMDB)，实现运维场景
在思考问题和设计解决⽅案的时候，⼀定要从实际出发、从问题出发、从基础出发，理清⾃⼰的需求和痛点，然后再去寻求解决⽅案。
⽇常接触到的各种技术解决⽅案，都是在解决应⽤⽣命周期不同阶段中应⽤⾃⾝或者应⽤与周边关系的问题，或者是所⾯对的场景问题CMDB的前世今⽣
Configuration Management DataBase
传统CMDB
CMDB 是与每个企业具体的 IT 软硬件环境、组织架构和流程强相关的，这就决定了 CMDB ⼀定是⾼度定制化的体系
传统CMDB以设备为中⼼的信息管理平台：从传统 IT 运维的⾓度来看，运维的核⼼对象是资源层⾯，所谓的基础架构也就是⽹络设备和硬件设备这个层⾯；各种关联和拓扑关系，基本也是从服务器的视⾓去看
设置为核⼼管理
互联⽹下的CMDB
应⽤核⼼管理
互联⽹技术的快速发展，⼤⼤推进了微服务技术架构的落地和实践，这种场景下，应⽤各维度的管理复杂度、应⽤的复杂度就逐渐体现出来了，所以我们的很多运维场景就开始围绕着应⽤来开展
当前的应⽤以及以应⽤为核⼼的分布式服务化框架、缓存、消息、DB、接⼊层等基础组件，都应该纳⼊这个配置管理的范畴
07有了CMDB，为什么还需要应⽤配置管理
CMDB 是⾯向资源的管理（资源 ≠资产），应⽤配置是⾯向应⽤的管理
建设运维的基础管理平台时通常要做的步骤：
1. 确定对象
2. 确定对象的属性
3. 梳理关系
关联关系pvc安全阀
拓朴关系
规划
4. 流程规范化建设，状态同步
eg：服务器上下线，维修，装机流程
5. 拓朴关系的可视化与动态展⽰
08 如何在CMDB中落地应⽤的概念
气泡垫业务架构决定了技术架构，⽽技术架构⼜决定了⼀个研发团队的组织架构。
应⽤名需要设定规范
应⽤管理思路：产品线 - 业务团队 - 应⽤
基于以应⽤为核⼼的 CMDB 中，衍⽣出“应⽤ - 集服务分组 - 资源”这样⼀个运维体系中的核⼼关系
应⽤集服务分组建设
场景1：多环境问题
场景2：多IDC问题
场景3：多服务分组问题
核⼼应⽤和⾮核⼼应⽤
场景因素决定
09 如何打造运维组织架构？
Netflix 给我们的启⽰: 在提供基础服务能⼒的同时，提供对应的⾃助化运维能⼒。
开发⼈员可以在这样⼀个平台上完成⾃⼰想要做的任何运维操作，⽽不再依赖运维的⼈
运维需要和整个技术架构体系融合，最重要的是要促进职能协作上的融合。
海马ゆう要考虑如何打造和体现出整个技术架构的运维能⼒，⽽不是运维的运维能⼒
从价值呈现的⾓度看运维
研发团队最重要的⽬标：效率，稳定，成本，从运维的⾓度来说，与这三个点契合的事情。从以下⽅⾯实现:
运维基础平台体系建设（运维的基础与核⼼）
CMDB
应⽤配置管理
DNS域名管理
资源管理
其他偏向运维⾃⾝体系建设
分布式中间件的服务化建设
技术架构体系中，分布式中间件基础服务这⼀块起到了⽀撑作⽤
分布式中间件服务化建设
与分布式中间件团队制定各种使⽤标准、规范和流程；中间件团队负责提供运维服务能⼒的接⼝；
运维团队根据⽤户使⽤的场景进⾏场景化需求分析，并最终实现场景，同时负责标准和⾃助化⼯具平台的推⼴和落地持续交付体系建设
持续交付体系是拉通运维和业务开发的关键纽带，是提升整个研发团队效率的关键部分
应⽤创建 --》 应⽤研发 --》 应⽤上线 --》 应⽤运⾏ --》 应⽤销毁
开发与运维容易爆发⽭盾的阶段
服务化持续交付体系建设，提供底层运维服务能⼒，运维要做的就是通过中间件运维能⼒的封装整合，进⽽实现⽤户使⽤的场景化需求稳定性体系建设
快速发现线上问题
快速定位问题
如何快速从故障中恢复业务
有效评估系统容量
故障管理
故障有效管理
故障复盘
⽇常演练
技术运营体系建设
