引入微服务架构后，软件架构的细化拆分和灵活多变，大大提升了开发人员的开发效率，也提升了业务需求的响应和迭代速度
微服务被广泛接受和采用的根本原因

微服务架构复杂到了一定程度，已经远超单纯的开发和单纯的运维职责范畴，也远远超出了单纯的人力认知掌握范围，所以必须寻求在此架构之上的更为有效和统一的技术解决方案，来解决复杂度认知的问题。
devops 理念以及衍生出来的一系列话题，我们可以仔细思考，是同样的背景和逻辑。

合理的组追架构和先进的工具体系及理念
中间件 SRE DBA 交付和自动化工具、基础架构等团队放在统一的云平台工程这个大团队下，在产品层统一规划和建设

持续交付系统 spinnaker
稳定性保障工具体系 chaos engineering

自由和责任 企业文化
you build it you run it

更多公司采用微服务架构后，没有充分考虑到后续基于微服务架构的运维问题。在运维团队的设置上，仍然脱离整个技术团队。

应用模型及关系模型的建立

• 应用业务模型

    每个应用对外提供业务服务能力，以api的方式暴露给外部
    业务架构师在进行业务需求分析和拆解时设计的，从运维的角度不会关注太多
  

• 应用管理模型

    应用名、功能信息、责任人、git地址、部署架构（代码路径，日志路经，各类配置文件路径）启停方式，健康检测 。
    应用名作为唯一标识 （AppName表示）
  

• 应用运行时的依赖（基础设施和组件）
  资源层面

    物理机，虚拟机，容器）如果提供http服务（IP和DNS域名）

  基础组件/中间件体系

    数据库          存储和访问数据
    缓存             更快的访问数据，缓解数据库压力
    消息队列      以ing用间数据交互和同步
    存储系统      文件存储和访问
  

  基础设施和组件都是为上层的一个个业务应用服务的

建立各个基础设施和组件的数据模型，同时识别出它们唯一标识。以NameSpace来标识唯一命名。
识别出基础设施及组件可以与应用名AppName建立关联关系的属性

大部分公司在软件架构上引入了微服务，但是后续的一系列运维措施和管理手段没跟上
devops 运维和开发合并
传统模式 运维和开发分开

常见场景
片面的对待基础组件，没有与应用建立起关联关系，没用任何生命周期管理措施。
申请资源的人离职，说不清哪是哪，有没有在用 不了解 不清楚，后续的人不敢动

应用名不统一的问题
开发随便命名，运维方便管理定义一套应用命名体系，方便自己管理。
持续交付和监控系统平台也是独立的，脱节问题更严重

以应用为核心的运维管理体系

• 标准化的原因和步骤

    原因：标准化的过程就是对运维对象的识别和建模过程
    过程：识别各个运维对象，然后日常做的所有运维工作都应该针对这些运维对象
                识别对象---->识别对象属性---->识别对象关系---->识别对象场景
  

• 基础设施层面的标准化

        识别实体对象（服务器，网络，IDC，机柜，存储，配件）
        识别对象的属性
            服务器   SN序列号，IP地址，厂商 、硬件配置（cpu，内存、硬盘、网卡、PCIE、BIOS）维保
            交换机   厂商，型号，带宽
        识别对象之间的关系
            服务器---机柜
            虚拟机---宿主机
            机柜---IDC
  
            核心交换机-->汇聚交换机--->接入交换机--->机柜和服务器之间的级联关系（网络拓扑）
        
        识别出针对运维对象日常运维操作有哪些，识别出运维场景
            服务器 -    采购 入库 安装 配置 上线 下线 维修 
                             可视化，查询
                             交换机和服务器之间的级联关系
                            状态（正常/故障）的展示
  

• 应用层面标准化

        应用为例
            - 识别对象（微服务架构设计，或拆分的时候确定下来的）
            - 识别对象属性  （业务，运维两个维度）
                - 应用的元数据属性 
                - 应用的代码属性
                - 应用的部署模式
                - 应用的目录信息（运维脚本目录，日志目录，应用包目录，临时目录）
                - 应用的运行脚本 （启停脚本，健康监测脚本）
                - 应用运行时的参数配置（运行端口，java的jvm参数）
            - 识别对象关系
                - 应用与基础设施的关系（资源，VIP，DNS）
                - 平行层面的应用与应用之间的关系
                       应用 api与其他应用服务或api的依赖关系（全链路平台就是用来处理应用之间关系关系管理的）
                - 应用与各类基础组件之间的关系，比如应用与缓存、应用与消息、应用与数据库
  
            - 识别应用的运维场景
                创建 持续集成，持续发布，扩容，缩容，监控
                容量评估，压测，限流降级
  

总结：应用是微服务架构下的核心运维对象

• 常见的分布式基础架构组件

        - 分布式服务化框架  （Dubbo，Spriing Cloud)
        - 分布式缓存框架 （Redis，Memcache，Codis，Redis Cluster）
        - 数据库 （mysql，mariaDB, 淘宝DRDS，sharding-jdbc, TiDB)
        - 分布式消息中间件（Kafka, RabbitMQ,ActiveMQ以及RocketMQ）
        - 前端接入层部分 （四层负载LVS，七层负载Nginx，apache，硬件负载F5）
  

• 基础架构组件的选型问题

        团队初期或者引入微服务初期由于开源产品的便利性，开发人员对技术探索的好奇心，不同团队，个人根据喜好选择不同
        大公司相对严格，越来越规范，吃过亏
        技术的应用，一般会随着应用场景的逐步深入和业务体量的增长，逐步暴露出各种各样的问题

  • 开发层面

    • 产品形态的不统一，导致开发人员还需要在技术层面协作上做大量日配工作，经验无法互通

  • 运维层面

    • 针对不同组件的适配影响效率
    • 整个链路因为各种原因而串联不起来
      发展下去，架构失控
      原则上，每个基础组件只允许一种选型，比如mysql，然后统一版本，配套的中间件统一

• 基础架构的服务化

  • 把组件提供的维护api进行封装，以便提供更加便捷的运维能力
  • 服务化的过程就是PAAS化的过程，把基础架构组件服务化完成，PAAS平台也就基本成型了

  • 以Redis缓存为例，要把原生能力进行封装，结合运维场景，将能力服务化

    • 创建和申请容量
    • 容量扩容缩容，新增分片的服务发现以及访问路由配置
    • 运行指标监控，如QPS，TPS，存储数据数量
    • 主备切换

• 运维的职责

  要做的事情基础架构标准化，基础架构服务化

  • 参与制定基础架构标准并对标准进行强势约束

    • 因为历史原因造成架构标准不统一的问题，需要开发和运维共同解决
    • 保持良好协作，制定统一的路线图
    • 提供工具化的手段支持开发改造

  • 基础架构的服务化平台开发

                  目标：让开发人员依赖平台能力自助完成对基础组件的需求，而不是依赖运维人员
                  如果不朝着服务化方向发展，运维将始终被拖累在这些基础组件的运维操作上
    

• 创建阶段

  • 确认应用的基础信息和基础服务的关系，固化下来

• 研发阶段

  • 业务逻辑的实现和验证阶段

    • 业务逻辑层面（开发代码/质量保证）涉及代码提交合并，编译打包，发布部署
    • 验证（持续集成）各种测试

• 上线阶段

  • 过渡阶段

• 运行阶段

  • 核心阶段（需要各种指标的输出）

    • 制定每个运维对象的SLI、SLO、SLA
    • 同时能够对这些指标进行监控和报警
    • 业务需求的不断变化和迭代，仍然会用到研发阶段的持续集成过程，最终与线上发布形成持续交付的闭环体系
    • 应用关系，与基础服务之间的关系，与其他应用之间的依赖（应用之间依赖管理和链路追踪）
    • 外部业务量的各种异常变化，流量激增，热点事件，服务器故障，IDC故障，数据库故障，api报错（线上稳定性保障场景）

• 销毁阶段

  • 应用自身销毁
  • 围绕着应用的基础设施，基础服务以及关联关系都要被一并清理（减少浪费)
  • 日常工作中，缓存系统有很多NameSpace不知道是谁的，消息系统中很多Topic也不知道是谁的，但又不敢随意乱动，无端占用着系统资源

  总结
  独立思考很重要
  别人的思路和解决方案往往建立在一个非常稳固的基础之上，二这些基础又太枯燥，太繁琐，常常被一带而过，甚至略去不讲。
  

• 基础设施层面（IDC机房、机柜、机架、网络设备、服务器）
• 应用层面（应用元信息，代码信息，部署信息，脚本信息、日志信息）

ITIL（信息技术基础架构库）

传统CMDB
cmdb与每个企业具体的it软硬件环境、组织架构和流程强相关，是高度定制化的系统
以设备为中心的信息管理平台（适用于IT基础设施形态变化不大）（单体架构，或分层架构）

个人经历（500台服务器，以excel作为cmdb，记录去管理和分配各种资源）能够胜任的原因就是基础设施层面的架构形态相对稳定，有稳定的软件模块数量和架构

ITIL 管理服务的流程体系，以一条条流程规范和约束，增加流程和审批

互联网运维体系下的cmdb
以应用为核心
微服务技术架构的落地和实践，应用各维度的管理复杂度，应用复杂度就体现出来
云计算蓬勃发展，逐渐屏蔽了IDC，网络设备，以及硬件服务器这样的底层基础设施复杂度

前面狭义的指简单的硬件资源配置管理
后面广义的以应用为核心的分布式服务化框架，缓存，消息，数据库，接入层等基础组件都被纳入这个体系

运维自动化

• 第一层 自动化服务器安装部署，网络自动化配置
• 持续交付，devops ， SRE

1. 确定服务器，网络，IDC，机柜，存储，配件等大的维度

2. 确定硬件属性

   • 服务器属性有SN序列号，IP地址，厂商，硬件配置（CPU，内存，硬盘，网卡，BIOS）维保
   • 网络设备有厂商，型号，带宽，IP

3. 梳理以上信息的关联关系，拓扑图

   • 服务器所在的机柜
   • 虚拟机所在的宿主机
   • 机柜所在的IDC等
   • 复杂的还有核心交换机，汇聚交换机，接入交换机以及机柜和服务器之间的级联关系

4. 规划问题

   • IP地址段的规划，数据库，大数据，业务应用等
   • 那个机柜用于做虚拟化宿主机，哪些机柜只放数据库机器等
   • ER建模，固化到数据库中

5. 流程规范建设

   • 服务器的上线，下线，维修，装机等流程
   • 流程过程中的状态变更同步管理

6. 拓扑关系的可视化和动态展示

   • 交换机与服务器之间的级联关系、状态（正常/故障）的展示

   至此，从资源维度进行信息的梳理，以及基于这些信息进行平台和流程规范建设算是基本成型

应用配置是面向应用的管理，是运维的核心
cmdb的基础信息部分，从传统的SA运维模式看，已经足够，从应用运维的角度看，远远不够

应用名(应用标识）---IP 或其他 主机名，容器ID等

CMDB是以IP为标识的资源维度的配置管理，有了应用名之后，来看应用维度的配置管理
涉及的信息

• 应用的基础信息，责任人，应用的git
• 应用部署涉及的基础软件包，语言包（java，c++，Go等）、web容器（tomcat，jboss等），web服务器（apache，nginx）基础组件（各种agent，如日志，监控，系统维护类的tsar）
• 应用部署涉及的目录，运维脚本目录，日志目录，应用包目录，临时目录
• 应用运行涉及的各项脚本和命令（如启停脚本，健康脚本）
• 应用运行时的参数配置（如java的JVM，GC方式，堆内存大小配置）
• 应用运行的端口号
• 应用日志的输出规范
• 其他
  梳理的过程就是标准化的过程，然后进行信息建模和数据固化，有了“应用配置管理”

在往后基于应用配置管理的流程规范和工具平台建设，涉及经常说的持续集成和发布，持续交付，监控，稳定性平台，成本管理

将两类信息统一，二者通过“应用名---IP”联系到一起就是CMDB

总结：
仅仅基于cmdb 的资源信息作自动化，最多只能做出自动化的硬件采集，自动化装机，网络-硬件拓扑关系生成等资源层面的工具，这些工具只会在运维层面产生价值，离业务很远

基于应用这一层去做，可以做持续集成和发布、持续交付、弹性扩缩容，稳定性平台，成本控制

• 有效组织和管理应用

  • “服务树”的概念，树形的层次结构

  • 业务维度的拆分---->产生应用拆分原则---->技术团队的组织架构（业务架构决定技术架构，技术架构决定团队组织架构）

    • 组织架构中不同的团队单元分别承担着对应业务的需求开发和实现的职责

  • 应用管理规范

    • 应用名必须使用大小写英文字母以及下划线的组合
    • 应用名不超过40个字符，尽量简单易懂
    • 不允许出现机房代号和主机名称这样的信息

• 应用的集群服务分组建设（应用----集群服务分组----资源）

  • 为什么有集群分组

    • 多环境问题
    • 多IDC问题

    • 多服务分组

      • 功能优先级不同（核心应用和非核心应用），影响业务收入就属于核心应用
      • 场景因素决定（电商）（秒杀活动）

• CMDB在基础服务体系中的核心位置

  • 应用----集群服务分组----资源的对应关系，对周边系统的作用

    • 监控系统（根据此关系监控应用，集群，以及每台服务器上的关键信息）
    • 发布系统（将每个应用对应的代码编译打包，并发布到对应集群的主机上）

    • 服务化框架（需要依赖应用和集群分组两个信息，主要是对应用名和集群分组名的依赖）

      • 通过配置中心注册的应用名来实现对应用的服务和api管理，与cmdb统一
      • lvs 和nginx 四层和七层负载
      • zookeeper开源分布式配置管理等

    • 基础服务

      • 分布式数据库，分布式缓存，消息（需要应用名，应用与资源IP的对应关系，集群分组与IP的对应关系）
      • 访问控制依赖--应用与资源IP的对应关系

    • 稳定性保障平台（服务治理平台）

      • 针对系统稳定性，有很多降级限流和开关预案策略

• 自助化运维能力的建设（做好运维和整个技术架构体系的融合，不要割裂两者。不仅仅是促进组织架构层面的融合，更是促进职能协作上的融合）

• 价值呈现的角度看运维（效率，稳定，成本）

  1. 运维基础平台体系建设（标准化体系，cmdb，应用配置管理，DNS域名管理，资源管理）基础核心
  2. 分布式中间件的服务化建设（标准化，服务化） 支撑

  3. 持续交付体系建设 （连接运维和业务开发的关键纽带，是提升整个研发团队效率的关键部分）

     • 依赖（1和2）

     • 是整个应用的生命周期的管理体系

       • 包含应用创建，研发阶段的持续集成
       • 上线阶段的部署发布
       • 运行阶段的各类资源服务扩容缩容
     • 运维和开发比较容易爆发矛盾的地方

  4. 稳定性体系建设（依赖1和2）

     • 稳定性保障
     • 快速发现线上问题
     • 快速定位问题
     • 快速从故障中恢复业务
     • 有效评估系统容量
     • 机制建设，应急响应，故障有效管理，复盘，演练

  5. 技术运营体系建设

     • 侧重运作机制方面（确保我们制定的标准，指标，规则，流程可以有效落地）

     • 技术运营意识

       • 制定输出标准的意识和能力
       • 制定规范流程的能力
       • 将标准和流程固化到工具平台
       • 确保承载了标准和规范的平台落地，平台必须可用

• 运维协作模式的改变

  • 运维团队发起，周边技术团队协作配合完成
  • 运维团队主动出击，去沟通和推进
  • 上级主管甚至更高层技术领导的支持

  • 例子：平台技术部门（分布式中间件，虚拟化技术，稳定性工具平台以及大数据几个字部门），指责细分

    • 运维基础平台建设（运维完成）

    • 分布式中间件服务化建设

      • 运维和分布式中间件部门一起制定各种使用标准、规范和流程
      • 中间件团队负责提供运维服务能力
      • 运维根据用户使用场景需求分析，负责实现，同时负责标准和自助化工具平台的推广和落地

    • 持续交付体系建设

      • 多部分协作完成（虚拟化部门，中间件团队，运维）
      • 服务化框架提供底层运维服务能力，中间件运维能力的封装整合

    • 稳定性体系建设

      • 链路埋点，限流降级，开关预案

• 运维的组织架构

  • 基础运维：IDC运维，硬件运维，系统运维以及网络运维。

    • 应该擅长硬件和操作系统层面的运维

  • 应用运维：主要是业务和基础服务层的稳定性保障和容器规划等

    • 应该更擅长业务稳定性保障、疑难问题公关以及技术运营等

  • 数据运维：数据库、缓存以及大数据的运维

    • DBA本身就是专业性极高的一个岗位

  • 运维开发：效率和稳定性层面的工具开发

    • 对上述几个岗位日常运维需求的支持，是否能将人力投入转换成工具平台支撑，取决于这个团队的能力

  总结：
  业界没有一劳永逸的组织架构，也没有放之四海皆准的组织架构标准，更没有万能的可以解决任何问题的组织架构设计
  需要不断的与自己所在团队和业务的特点去匹配和契合
  这是一个不断变化的过程，也是需要持续调整的过程
  

• SRE的岗位定位

       SRE 关注的目标不是operation（运维），而是Engineering（工程），是一个通过软件工程的方式开发自动化系统来替代重复和手工操作）的岗位

• SRE的岗位职责

       负责可用性、时延、性能、效率、变更管理、监控、应急响应和容量管理（效率和稳定）
       SRE的直译是网站稳定性工程师，以稳定性为目标，围绕着稳定这个核心，负责可用性，时延，性能，效率，变更管理，监控，应急响应和容量管理等
       有“管理”和“技术”两方面的事情要做

  • 管理上，涉及服务质量指标（SLI，SLA，SLO），发布规则，变更规则，应急响应机制，On-Call, 事后复盘机制等一系列的管理规范和标准制定

  • 技术上，以支持和实现上述标准和规范为目标，涉及自动化，发布，监控，问题定位，容量定位，以电子流串联各个环节，实现事件的闭环

     技术上的平台和系统是用来支撑管理手段的。主要系统如下

  • 自动化：通过减少认为的，频繁的，重复的线上操作，来大大减少因为认为失误造成的故障，同时提升效率（kubernetes)
  • 持续交付
  • 问题定位，google的Dapper 涉及全链路跟踪和分析，限流降级，开关和预案系统，强弱依赖等

  • 各类分布式系统（分布式锁，分布式文件，分布式数据库）

      SRE的理念通过稳定性这个核心点，将整个运维体系要做的事非常系统紧密的整合起来，而不是任由其成为一个个孤立的运维系统
      SRE是一个岗位，更是一种运维理论和方法论。

• 借鉴和落地

  • 个人要求比较高
  • 靠团队中具备不同能力的人协作，共同达成SRE的职责和目标

• CRE 的产生背景

  • 越来越多的公司将自己的业务迁移到云上，基础环境不在可控，客户变得焦虑

• CRE的岗位职责

  • 消除客户焦虑，真正的站在客户的角度去解决问题，对客户进行安抚
  • 和客户一起排查，问题不解决，自己不撤退，随时通报进展，必要的时候将故障升级到更高级别，寻求更专业的资源投入以共同解决
  • 跟客户沟通传递一些稳定性保障知识
  • CRE即具备良好的专业技术能力，又有非常强的问题解决能力，优秀的的客户沟通和关怀能力

• 运维为什么要有服务心态

  • 日常工作中不断提升自己的服务意识
  • 很多问题都是因为服务意识不够而导致的

  • 具体的改进措施

    • 多用业务术语，少用技术术语，用对方能够听得懂的表达方式表达技术观点

    • 挖掘问题背后真正的诉求

      • 为什么要这样做
      • 是谁要求做这件事情的
      • 这样的目的是什么
      • 这样做是为了解决什么问题

    • 解决问题时关注目标而不是聚焦困难(下图)

运维要不断提升自己的技术能力，另一方面也要注意培养自己的服务意识，让自己的能力得以发挥，创造更大的价值

• 案例

  • 国外的netflix模式，强调自助化运维
  • 国内阿里巴巴的模式，“去PE”的组织架构调整，初期靠人，后期靠平台

• 应用运维的转型

  • 学会写代码，具备代码开发能力，已经成为一项必备技能
  • 即懂业务，又懂开发，更具竞争力
  • 代码开发上，建议从python、php或Go这些上手比较简单的语言开始
  • 提升产品意识，改变被动响应模式

  • 提升技术运营仪式

    • 把承载了标准化和规范体系的工具平台真正落地应用起来，同时在落地过程中，进行问题收集和一定数据分析，再回到产品设计和需求实现的流程中进行改进，形成良性的闭环

• 云计算和AI带来的挑战

  • AI的一种实现方式---机器学习算法
  • AI和ops的结合，更多是场景驱动的
  • 机器学习算法是离不开场景和业务特点的，懂线上运维实际情况的人做这件事情，会更加合适

总结，传统的SA（系统管理员，系统运维工程师）网络工程师会更加收敛，一方面是岗位设置上会收敛到各大云平台厂商哪里，做专职的基础和后端的服务维护。随着自动化的完善，在岗位数量上也会收敛，不会再出现大批量的岗位需求。岗位的价值空间以及成长空间，将变得极为有限。