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. 梳理关系
   • 关联关系
   • 拓朴关系
   • 规划
4. 流程规范化建设，状态同步
   • eg：服务器上下线，维修，装机流程
5. 拓朴关系的可视化与动态展示

08 如何在CMDB中落地应用的概念

• 业务架构决定了技术架构，而技术架构又决定了一个研发团队的组织架构。
• 应用名需要设定规范
• 应用管理思路：产品线 - 业务团队 - 应用
• 基于以应用为核心的 CMDB 中，衍生出“应用 - 集群服务分组 - 资源”这样一个运维体系中的核心关系

应用集群服务分组建设

• 场景1：多环境问题
• 场景2：多IDC问题
• 场景3：多服务分组问题
  • 核心应用和非核心应用
  • 场景因素决定

09 如何打造运维组织架构？

• Netflix 给我们的启示: 在提供基础服务能力的同时，提供对应的自助化运维能力。
  • 开发人员可以在这样一个平台上完成自己想要做的任何运维操作，而不再依赖运维的人
• 运维需要和整个技术架构体系融合，最重要的是要促进职能协作上的融合。
  • 要考虑如何打造和体现出整个技术架构的运维能力，而不是运维的运维能力

从价值呈现的角度看运维

研发团队最重要的目标：效率，稳定，成本，从运维的角度来说，与这三个点契合的事情。从以下方面实现:

• 运维基础平台体系建设（运维的基础与核心）
  • CMDB
  • 应用配置管理
  • DNS域名管理
  • 资源管理
  • 其他偏向运维自身体系建设
• 分布式中间件的服务化建设
  • 技术架构体系中，分布式中间件基础服务这一块起到了支撑作用
  • 分布式中间件服务化建设
    • 与分布式中间件团队制定各种使用标准、规范和流程；中间件团队负责提供运维服务能力的接口；
    • 运维团队根据用户使用的场景进行场景化需求分析，并最终实现场景，同时负责标准和自助化工具平台的推广和落地
• 持续交付体系建设
  • 持续交付体系是拉通运维和业务开发的关键纽带，是提升整个研发团队效率的关键部分
  • 应用创建 --》 应用研发 --》 应用上线 --》 应用运行 --》 应用销毁
  • 开发与运维容易爆发矛盾的阶段
  • 服务化持续交付体系建设，提供底层运维服务能力，运维要做的就是通过中间件运维能力的封装整合，进而实现用户使用的场景化需求
• 稳定性体系建设
  • 快速发现线上问题
  • 快速定位问题
  • 如何快速从故障中恢复业务
  • 有效评估系统容量
  • 故障管理
    • 故障有效管理
    • 故障复盘
    • 日常演练
• 技术运营体系建设
  • 确保制定的标准，指标，规则和流程能够有效落地
    • 技术平台实现
    • 管理流程
    • 执行人员沟通与协作
  • 具备技术运营意识
    • 能够有制定输出标准的意识与能力
    • 能够有规范流程制定的能力
    • 能够将标准和流程固化到工具平台中
    • 能够确保承载了标准和规范的平台落地（平台可用，确实给团队带来效率与稳定性方面提升）

运维协作模式的改变

上面几个事情：

• 要站在怎么能够打造和发挥出整个技术架构体系运维能力的视角，而不仅仅是发挥运维团队的运维能力
• 由运维团队发起，与周边技术团队协作配合来完成的。
• 运维团队要主动出击，去沟通，去推进
• 必须能得到上级主管甚至是更高层技术领导的支持
• 运维在这个过程中要发挥的最关键作用就是通过用户使用场景的分析，将各项基础服务封装并友好地提供出来，并确保最终的落地
• 方式上，或者是通过工具平台的技术方式，比如分布式中间件基础服务；或者是通过技术运营能力，比如稳定性能力在业务层面的落地

运维的组织架构

• 基础运维
• 应用运维
• 数据运维
• 运维开发

10谷歌SRE运维模式解读

• SRE关注的目标不是Operation（运维），而是Engineering（工程），一个“通过软件工程的方式开发自动化系统来替代重复和手工操作”
• SRE 是一个岗位，但更是一种运维理念和方法论
• SRE岗位的职责：稳定和效率
• SRE能力模型：
  • 技术上的能力
  • 产品设计
  • 标准规范制定
  • 事后复盘总结归纳
  • 技术运营能力
  • 良好的沟通协作能力
• 日常事项：
  • 管理体系：涉及服务质量指标（SLI、SLA、SLO）、发布规则、变更规则、应急响应机制、On-Call、事后复盘机制等一系列配套的管理规范和标准制定等
  • 技术体系：以支持和实现上述标准和规范为目标，涉及自动化、发布、监控、问题定位、容量定位，最终以电子流程串联各个环节，做到事件的闭环
• 要想做好运维，就得跳出运维的局限，要站在全局的角度，站在价值呈现的角度，站在如何能够发挥出整体技术架构运维能力的角度，来重新理解和定义运维才可以
• 各类主要系统：
  • 自动化
  • 持续交付
  • 问题定位
  • 各类分布式系统

11从谷歌CRE谈起，运维如何培养服务意识？

• CRE概念: Customer Reliability Engineering，客户稳定性工程师
• 产生背景：越来越多的用户选择在云上开展自己的业务，很多企业和用户将业务从原来传统的自运维 IDC 机房迁移到云上。这样做其实就是选择相信公有云平台，但同时也就放弃了对底层基础设施的把控，甚至把企业最为核心的数据也放到了云上。说简单点，就是一个公司的身家性命都交给公有云了。当云上不稳定的情况发生时，公有云客户通常是手足无措的。因为他并不了解出了什么状况，不知道是自己的问题还是云上基础设施或基础服务的问题，也不知道自己应该从哪里入手恢复业务，所以时间长了必然就会感到非常焦虑，各种不放心
• CRE的岗位职责：
  • 消除客户焦虑，真正地站在客户角度去解决问题，同时对客户进行安抚、陪伴和关怀。
  • 与售后服务不同，站在客户的角度解决问题，和客户一起排查问题，汇报给客户进展；同时对接云服务商，协调资源，必要时候将故障升级，寻求更专业解决方案。
  • 对客户线上系统进行稳定性标准评审，并给出专业的建议。如果客户同意遵守这样的标准规范执行，在后续出现故障时，CRE 就完全可以按照非常成熟的 SRE 的运作模式去协作用户处理故障，这样就会大大提升 CRE 和客户的协作效率，为故障快速处理赢得更多宝贵时间
• CRE角色具备：
  • 良好的专业技术能力
  • 非常强的问题解决能力
  • 优秀的客户沟通和关怀能力

CRE服务心态

• 服务心态：表现在我们的做事方式上，就是我们是否能够站在对方的角度考虑问题、解决问题。
• tips:
  • 多使用业务术语，少使用技术术语: 从业务角度出发考虑技术解决方案，而不是从技术角度出发让业务来适配技术。不要限定在当前的技术解决方案上。
  • 学会挖掘问题背后的真正诉求：不了解背景，为什么要做这件事情。开放性问题：
    • 为什么要这样做？
    • 谁要求做这件事情的？
    • 这样做的目的是什么？
    • 这样做是为了解决什么问题？
    • bad case: 很多业务方人员提的不是需求，直接就是一个解决方案，而运维人员听了之后往往不会去分析为啥要这样就直接开干了，业务人员达成效果后就走了，留给运维一个“隐患”，日积月累终有一天爆发了
  • 解决问题的时候关注目标，而不是聚焦困难：注意力在哪里，结果就在哪里