田园木竹 | 读书笔记之《赵成的运维体系管理课》

最近做运维转型的理论总结，发现结论跟《赵成的运维体系管理课》的很像。于是乎，顺便看看赵成老师的视频课-应用运维体系建设的部分，摘录下有启发的观点，免得再重复造轮子。

有启发的观点

组织：组织结构是第一生产力，技术管理者要有意识的推动协作方式变革，自上而下、博得高层支持
组织：把运维放在平台工程部，在平台产品层面实现统一规划和建设，避免开发、运维的脱节 —— 康威定律
组织：业务研发要有责任心和Owner意识，要吃好自己的狗粮、不挑肥拣瘦甩给运维（平台自助化）
文化：技术运营、服务态度就不应该成为议题。人没有机器靠谱，一线的技术运营、服务意识无法长期持续，平台才是最好的载体
文化：谷歌SRE对个人能力要求很高，国内几乎无法做到；依靠团队、分工协作，降低对个人能力的要求，对外提供出完整的SRE能力
转型：运维转型的背后是微服务架构+DevOps，是技术驱动的组织方式变革；云原生体系囊括了微服务架构、DevOps，云原生落地基本意味着运维必须转型
建模：标准化即建模，标准化的过程就是对运维对象的建模过程
建模：连接才能产生价值，要选择一种运维对象当做核心、关联起尽量多的运维对象，基础服务实例、微服务应用就是这样的核心对象
建模：服务树就是应用CMDB的核心，这个认识挺到位。自己司空见惯，别人总结出来又总感觉醍醐灌顶
建模：运维问题都能归类到应用生命周期的不同阶段，应用自身、应用与周边的关系、业务场景三选一
场景：从「软件生命周期」入手，划分阶段，识别对象、抽象模型(提炼属性、理清关系)、固化信息(CMDB)、梳理「运维场景」，实现管理自动化
场景：CICD是拉通运维和业务开发的关键纽带，是提升整个研发团队效率的关键部分

行文脉络

宏观认识：运维在软件生命周期中的地位
- 生命周期：从软件生命周期看，70-80%的时间是运维阶段，运维时间占比多、领域地位足够重要
- 组织分工：除却开发、测试，剩余工作都算运维；众多角色都在做运维的活儿，但人员不一定归属运维团队
顶层设计：运维的组织、文化、技术原则
- 全局：运维体系化，用架构的思路、做运维 —— 运维架构
  - 古语云，不谋万世者，不足谋一时；不谋全局者，不足谋一域
- 组织：把运维放在平台工程部。在平台产品层面统一规划和建设 —— 康威定律
  - 避免开发、运维的脱节
- 文化：业务研发要有Owner意识，运维要有软件工程思维
  - 业务研发要为自己的应用负责，要关注设计、开发、交付、运维等完整生命周期，而不是只关注开发、后期交付和维护甩给运维。吃自己的狗粮
  - 运维要用工程思维、技术手段来解决效率和稳定问题，而不是依赖人工、依赖运营
- 技术：运维要拥抱微服务架构。微服务的收益已得到业界认可
  - Netflix充分微服务化、提升了效率，同时用新的运维解决方案和组织分工解决了系统复杂度问题
对象建模：以应用为中心，对基础设施、组件、应用进行对象建模；建模的过程，也是标准化的过程
- 公共要点
  - 运维视角的要点
    - 以应用为中心，构建运维管理体系
    - 运维建模时，要选择一种对象当做核心，通过这类对象、关联尽量多的运维对象。基础服务实例、微服务应用，就是这种核心对象
  - 建模步骤：识别对象、对象属性、对象关系，运维场景
    - 对象：应用对象应该在业务设计阶段识别出来
    - 属性：应用属性有业务、管理两类，运维负责管理属性、也称为元数据
    - 关系：应用对象关系分为基础设施、组件、应用三类
  - 建模和标准化的关系：标准化的过程就是对运维对象识别、建模的过程。统一对象模型后技术团队才有共同语言、方便平台级协同
    - 价值：统一、去差异化，共性运维
- 应用建模
  - 应用定义：微服务架构下，应用是提供了一组业务功能、可独立部署的模块，通常以API方式对外提供服务
  - 业务模型：业务架构师，根据业务逻辑，拆分出可独立部署的业务模块，并以API方式对外提供服务
  - 管理模型：应用自身的各种属性，如应用名、功能列表、负责人、Git地址等
  - 依赖模型：应用依赖主要有基础资源、基础组件两类，统称为基础服务。依赖建模，首先需要建立基础服务的管理模型、拿到唯一识别符，然后将应用和基础服务之间关联
- 组件建模
  - 组件分类：接入层，服务化框架，数据库/缓存，消息队列
  - 选型原则：统一规划，收敛技术栈，每种组件只允许一种选型、满足90%+的应用场景
  - 组件服务化：中间件团队提供原生能力，运维团队结合场景、将组件能力服务化，做到业务RD自助化
  - 运维职责：标准化，参与制定基础架构标准，并强势约束；服务化，将组件能力平台自助化
- 基础设施建模
  - 以资源实例为中心的传统CMDB（个人点评）
运维场景：以生命周期视角提炼运维场景
- 应用生命周期：为五个阶段，包括创建、研发、上线、运行、销毁
  - 创建：确定应用、基础服务的关系，固化下来，从应用创建之初就要产生关联；同时，要开启与应用依赖的各类基础服务的生命周期
  - 研发：业务逻辑实现和验证。开发代码、质量保证。为研发团队打造完善的持续集成体系和工具链支持
  - 运行：这是应用生命周期中最重要、最核心的阶段
- 要点整理
  - 从「软件生命周期」入手，划分阶段，识别对象、抽象模型(提炼属性、理清关系)、固化信息(CMDB)、梳理「运维场景」，实现管理自动化。好的思维路径，要贴近生活、容易理解
运维平台：应用CMDB是运维平台的关键
- CMDB分类
  - 资源CMDB，即传统意义上的CMDB，是运维的基石
  - 应用CMDB，即应用配置管理中心，是运维的核心
  - 资源CMDB和应用CMDB，通过应用和资源的关系，组成一张连续的网
- CMDB建设步骤
  - 资源CMDB：识别对象 –> 对象属性 –> 对象关系 –> 流程规范+状态流转 –> 运维场景(服务化)
- 应用CMDB
  - 服务树就是应用CMDB的核心
  - 服务树的应用CMDB中，衍生出”应用 - 集群 - 资源”这样一个运维体系中的核心关系
- 要点整理
  - 服务树就是应用CMDB的核心，这个认识挺到位。自己司空见惯，别人总结出来又总感觉醍醐灌顶，妙哉!
组织结构：如何打造运维的组织体系
- 指导思想
  - 全视角：用软件生命周期的视角设计运维，架构设计阶段对运维能力起决定作用
  - 三化：技术架构标准化，资源组件服务化，应用管理自助化
- 价值呈现
  - 基础服务：IDC、系统、网络、云服务
  - 组件服务：中间件
  - 应用体系：应用管理体系
  - 持续交付：CICD是拉通运维和业务开发的关键纽带，是提升整个研发团队效率的关键部分。CD是最具线上价值的部分
  - 稳定性：通过用户使用场景的分析，将各项基础服务封装并友好地提供出来，并确保最终的落地
  - 技术运营：团队成员要具备技术运营意识，即行为范式
- 组织分工
  - 基础运维
  - 应用运维
  - 数据运维
  - 运维开发
- 协作模式
  - 主动出击，运维人员要有主动性，去沟通、去推进
  - 自上而下，博得高层领导支持，技术管理者要有意识的推动协作方式变革
  - 横向串联，运维就像是串起一串珍珠的绳子，将整个平台技术部门、甚至是业务研发团队给串联起来，推动整体技术架构运维能力的演进
- 谷歌SRE的启示
  - 工程化：SRE是运维场景的工程化实现。SRE is what happens when you ask a software engineer to design anoperations team
  - 稳定性：以稳定性为核心、辐射效率成本，带动日常运维、故障处理、问题定位的效率大幅度提升，容量管理对于成本管控也大有好处
  - 如何落地：谷歌SRE对个人能力要求很高，国内几乎无法做到；依靠团队、分工协作，降低对个人能力的要求，同时对外提供出完整的SRE能力
- 要点整理
  - CICD是拉通运维和业务开发的关键纽带，是提升整个研发团队效率的关键部分。这是多么痛彻的领悟~
  - 架构设计阶段对运维能力起决定作用，架构决定了运维的底线
  - 自上而下、博得高层支持，技术管理者要有意识的推动协作方式变革
  - 谷歌SRE对个人能力要求很高，国内几乎无法做到；依靠团队、分工协作，降低对个人能力的要求，对外提供出完整的SRE能力
文化导向：CRE启发的服务意识
- CRE，Customer Reliability Engineering
  - 本质：CRE是用软件工程的思路、提供售后技术支持，岗位具有服务属性、要对客户满意度负责
  - 定义：站在客户的角度、解决问题，对客户消除焦虑（安抚、陪伴和关怀）。对比传统售后，具备响应效率、技术专业性等方面的优势
- 要点整理
  - 服务意识就不应该成为议题。人没有机器靠谱，一线的技术运营、服务意识也无法长期持续，平台才是最好的载体（个人点评）

以下是，课程要点摘要，中间也夹杂了个人的理解、看法。

开篇词 | 带给你不一样的运维思考

议题约束：应用运维领域，运维架构思考，Java技术栈
运维体系：之前的文章更多是针对一个个观点延伸出去写作，而专栏文章可以尝试更系统地输出、能够把一个运维体系讲透
生命周期：70-80%的时间处于运行维护阶段。从软件生命周期的角度看，软件开发阶段只占整个生命周期的 20%~30% 左右，软件运行维护阶段是最长尾的
运维组织：一个研发团队内，除去业务需求实现层面的事情，其它都是运维的范畴。除业务开发和测试外，前面所提到的那些技术岗位都是为软件生命周期中的运行维护阶段服务的，这些角色的作用就是提升研发效率和稳定性，进而降低成本。虽然他们并没有全部被定义为运维岗位，但是本质上他们是跟业务软件的运行维护阶段直接相关的
全局观念：运维能力是整体技术架构能力的体现，运维层面爆发的问题或故障，一定是整体技术架构中存在问题，割裂两者，单纯地看技术架构或运维都是毫无意义的。运维思路上的转变，远比单纯提升运维技术更有价值，而运维真正的价值应该跟研发团队保持一致，真正聚焦到效率、稳定和成本上来。

01 | 为什么Netflix没有运维岗位？

技术架构：微服务化，SRE => DevOps
- 微服务架构：微服务架构大大提升了需求迭代效率。随之而来的便是架构复杂度大大增加，而且这种复杂度已经远远超出人的认知能力，也就是我们已经无法靠人力去掌控了，这也就为后续的交付和线上运维带来了极大的难度和挑战
- 微服务+DevOps：技术驱动的组织变革。微服务架构复杂度到了一定程度，已经远远超出单纯的开发和单纯的运维职责范畴，也远远超出了单纯人力的认知掌控范围，所以必须寻求在此架构之上的更为有效和统一的技术解决方案来解决复杂度认知的问题。进而，在这一套统一的技术解决方案之上，开发和运维产生了新的职责分工和协作方式
- Design For Faliure
组织结构：合理的组织架构是保障技术架构落地的必要条件
工程思维：用技术手段来解决运维过程中遇到的效率和稳定问题才是根本解决方案
企业文化：自由与责任并存，Freedom & Responsibility。技术团队自然会考虑从开发设计阶段到交付和线上运维阶段的端到端整体解决方案，而不会是开发就只管需求开发，后期交付和维护应该是一个叫运维的角色去考虑。Owner意识很重要，正确的做事方式需要引导，这就是优秀和极致的距离。

02 | 微服务架构时代，运维体系建设为什么要以“应用”为核心？

目标：在微服务的架构模式下，我们的运维视角一定转到应用这个核心概念上来，一切要从应用的角度来分析和看待问题
应用：业务模型，管理模型，依赖模型 => 以应用为核心的运维管理体系
- 应用业务模型
- 应用管理模型：自身属性
- 应用依赖模型
  - 依赖建模：第一步，建立各个基础设施和组件的数据模型，同时识别出它们的唯一标识。第二步，识别出基础设施及组件可以与应用名 AppName 建立关联关系的属性
  - 基础设施和组件都是为上层的一个个业务应用所服务的，从始至终基础设施和组件都跟应用这个概念保持着紧密的联系
    - 问题：跨应用混用的资源，如数据库、缓存、域名、CDN、S3
    - 反思：基础设施和组件并未像应用一样、充分微服务化。应用按功能拆分API、实现微服务化，基础设置和组件更多是按照资源拆分
关注点：应用模型，运维自动化，持续交付，稳定性

03 | 标准化体系建设（上）：如何建立应用标准化体系和模型？

为什么要做标准化
- 标准化的过程实际上就是对运维对象的识别和建模过程
- 形成统一的对象模型后，各方在统一的认识下展开有效协作，然后针对不同的运维对象，再抽取出它们所对应的运维场景，接下来才是运维场景的自动化实现
- 日常做的所有运维工作，都应该是针对这些对象的运维。如果运维操作脱离了对象，那就没有任何意义
- 常见误区：运维工作不知从何下手；上来就做工具和自动化、却始终不得章法，工具做了一堆，效率却并没有提升（做工具和自动化平台之前需要大量的准备工作）
标准化实施步骤
- 识别对象
  - 应用对象，不应该是运维阶段才被识别出来的，而是在之前设计阶段就被识别和确认下来，然后延伸到运维这里才对
- 识别对象属性
  - 应用属性，会有业务和运维两个维度的属性。业务属性由业务架构师搞定
- 识别对象关系
  - 应用关系，分三类：和基础设施、和应用、和组件
- 识别对象场景

04 | 标准化体系建设（下）：如何建立基础架构标准化及服务化体系？

基础组件分类
- 接入层，LVS、Nginx
- 服务化框架，Dubbo、Spring Cloud
- 缓存，Redis、Codis
- 数据库，MySQL、TiDB
- 消息中间件，Kafka、RocketMQ
基础组件选型
- 问题：重复造轮子。每个小团队所负责的业务相对独立，自主权就会变大，如果整个团队没有一个强有力的架构师角色、去做端到端的约束，就极其容易出现
- 影响：开发层面，重复投入、适配、经验不互通；运维层面，适配成本
- 原则：对基础架构有统一的规划和建设。原则上，每种基础组件只允许一种选型，至少能满足 90% 甚至更多的应用场景
基础组件服务化
- 服务化：基于这些原生能力进行封装，结合运维场景，将能力服务化，这样就大大提升了使用方的便利性
运维的职责
- 标准化，参与制定基础架构标准，并强势地约束
- 服务化，组件平台自助化，让开发依赖平台的能力自助完成对基础组件的需求，而不是依赖运维的人

05 | 如何从生命周期的视角看待应用运维体系建设？

应用生命周期
- 在微服务架构下，应用是核心对象，通过应用生命周期、可以串联起其它对象的生命周期
- 应用生命周期分为五个阶段，包括创建、研发、上线、运行、销毁
- 日常接触到的各种技术解决方案，都是在解决应用生命周期不同阶段中应用自身或者应用与周边关系的问题，或者是所面对的场景问题
阶段详解
- 创建
  - 确定应用、基础服务的关系，固化下来，从应用创建之初就要产生关联
  - 同时，要开启与应用相关的各类基础服务的生命周期
- 研发：业务逻辑实现和验证。开发代码、质量保证。为研发团队打造完善的持续集成体系和工具链支持
- 上线
- 运行：这是应用生命周期中最重要、最核心的阶段
- 销毁
运维架构
- 从生命周期入手，划分阶段，提炼属性，理清关系，固化基础信息，实现运维场景
- 对于业界思路、解决方案，借鉴但不要套用，因为别人的思路和解决方案往往是建立在一个非常稳固的基础设施之上

06 | 聊聊CMDB的前世今生

传统CMDB
- 传统CMDB 源于 80 年代末的 ITIL，源于传统 IT 运维阶段
- 从传统 IT 运维的角度来看，运维的核心对象是资源层面。CMDB 是与每个企业具体的 IT 软硬件环境、组织架构和流程强相关的，这就决定了 CMDB 一定是高度定制化的体系
  - 运维基于这样一个表格去管理和分配各种资源，问题也不算太大。究其根本，就是基础设施层面的架构形态相对稳定，有稳定的软件模块数量和架构
- 高大上的 ITIL 体系，更多的是被当做流程规范来落地的，真正体现在技术方案和技术产品上的落地并不多。我想这是实施过程中对 ITIL 理解和运用的一大误区
互联网CMDB
- 传统运维思路下的 CMDB，因为管理范围有限，可以定义为狭义上的 CMDB；而互联网运维思路下的 CMDB 外延更广，我们称它为广义的 CMDB
- 理念、思路上的转变，远比技术上的实现更重要。

07 | 有了CMDB，为什么还需要应用配置管理？

观点：CMDB 是面向资源的管理，应用配置是面向应用的管理
- CMDB 是面向资源的管理，是运维的基石
- 应用配置管理是面向应用的管理，是运维的核心
CMDB建设步骤
- 资源CMDB：识别对象 –> 对象属性 –> 对象关系 –> 流程规范+状态流转 –> 运维场景(服务化)
应用配管
- 应用名
- 应用名和IP的关系：应用CMDB、资源CMDB产生关联

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

应用组织
- 服务树概念：这个提法是小米在早期互联网运维实践的分享中传播出来的。我第一次听到这个概念是在 13 年阿里技术嘉年华大会上听小米运维的分享。再往前，这个概念应该是从百度的运维体系中借鉴出来的
- 服务树层级：业务架构决定了技术架构，而技术架构又决定了一个研发团队的组织架构 - 有悖于康威定律
- 架构决定运维的底线：到了软件运维阶段，运维工作是否可以高效地组织开展，很大程度上，在前面的业务架构拆分阶段就决定了。也就是业务架构拆分得是否合理、职责是否明晰，决定了后续团队组织架构是否合理、团队职责是否明晰。如果这点没做好，到了运维阶段必然就是混乱的。
应用分组
- 应用分组维度，IDC、环境、重要程度等等。从文中例子看，作业远离一线挺久了
- 应用CMDB中，衍生出”应用 - 集群 - 资源”这样一个运维体系中的核心关系
评价
- 服务树就是应用CMDB的核心，这个说法很受用
- 作者对服务树的抽象，深度一般般

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

指导思想：Netflix的启示
- 全视角：用软件全生命周期的视角去看待运维，关注架构阶段对运维能力的决定性作用
  - 要想做好运维就一定要跳出运维这个框框，从全局的角度来看运维，要考虑如何打造和体现出整个技术架构的运维能力，而不是运维的运维能力
- 自助化：运维能力服务化，平台自助化
  - 在提供基础服务能力的同时，提供对应的自助化运维能力。也就是说，开发人员可以在这样一个平台上完成自己想要做的任何运维操作，而不再依赖运维的人
价值呈现
- 运维中台体系。这一部分是运维的基础和核心。包括标准化、应用管理
- 中间件服务化。和中间件团队一起制定标准，中间件团队提供接口、运维负责服务化
- 持续交付体系。持续交付体系是拉通运维和业务开发的关键纽带，是提升整个研发团队效率的关键部分。CD是最具线上价值的部分
- 稳定性体系。通过用户使用场景的分析，将各项基础服务封装并友好地提供出来，并确保最终的落地
- 技术运营体系。团队成员要具备技术运营意识，即行为范式
协作模式
- 思路：要站在怎么能够打造和发挥出整个技术架构体系运维能力的视角，而不仅仅是发挥运维团队的运维能力
- 跨团队协作。一方面运维团队要主动出击，去沟通，去推进。另一方面，必须能得到上级主管甚至是更高层技术领导的支持，技术管理者要有意识的促进组织协作方式变更
- 运维在这个过程中，就好像串起一串珍珠的绳子，将整个平台技术的不同部门，甚至是开发团队给串联起来，朝着发挥出整体技术架构运维能力的方向演进 —— 串联角色没有核心价值，无论怎么搞都没有服务提供方来的硬!
评价
- 如果再让我选择一次，CD一定要抓在运维团队手里! 滴滴、作业帮的教训历历在目
- 业界没有一劳永逸的组织架构，也没有放之四海而皆准的组织架构标准，更没有万能的可以解决任何问题的组织架构设计，这里的关键是我们如何能够发挥出团队整体的能力和价值，而这一点又需要我们不断地与自己所在团队和业务特点去匹配和契合，这是一个不断变化的过程，也是需要持续调整的过程
- DevOps理念，要求业务研发具备运维素养，也要求软件具备可运维性

10 | 谷歌SRE运维模式解读

SRE岗位定位
- SRE 关注的目标不是 Operation（运维），而是 Engineering（工程），是一个“通过软件工程的方式开发自动化系统来替代重复和手工操作”的岗位
- SRE is what happens when you ask a software engineer to design anoperations team
- 谷歌就没把 SRE 定义为纯操作类运维的岗位，从另外一个维度来解决运维问题、才把运维做到了另一个境界
SRE岗位职责
- 总结：以稳定性为导向，同时带动了日常运维、故障处理、问题定位效率的大幅度提升，容量管理对于成本管控也大有好处
- 稳定：以稳定性为目标，围绕着稳定这个核心，负责可用性、时延、性能、监控、应急响应、效率、变更管理、容量管理等相关的工作
  - 管理体系：涉及服务质量指标（SLI、SLA、SLO）、发布规则、变更规则、应急响应机制、On-Call、事后复盘机制等一系列配套的管理规范和标准制定等
  - 技术体系：以支持和实现上述标准和规范为目标，涉及自动化、发布、监控、问题定位、容量定位，最终以电子流程串联各个环节，做到事件的闭环
- 效率
  - 谷歌的运维其实并没有单独去提自动化、发布、监控等内容，而是通过稳定性这个核心目标，把这些事情全部串联在一起，同时又得到了效率上的提升
- 支撑系统
  - 自动化：为了减少人为的、频繁的、重复的线上操作，减少人为失误造成的故障，同时提升效率
  - 持续交付：谷歌非常重视持续交付
  - 问题定位
  - 分布式中间件
SRE能力要求
- 软件工程
- 技术运营，包括规范制定、流程制定、产品设计、事后复盘总结归纳等
- 沟通协作
如何借鉴和落地
- 谷歌模式的SRE对个人能力要求很高，SRE岗位薪资比SWE要高出25%（SWE SoftWare Engineer，软件工程师）。国内的SRE、PE、应用运维，一般无法达到谷歌SRE的个人能力要求
- 依靠团队分工协作、降低对个人能力的要求。加强团队协作，依靠团队力量，精细分工、彼此协调，对外提供出完整的SRE能力

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

CRE岗位背景
- Customer Reliability Engineering
- 起因：企业开始大量使用公有云，公有云客户变多；公有云无法做到完全的无瑕疵
CRE岗位职责
- 本质：CRE，就是用软件工程的思想，做售后技术支持
- 定义：站在客户的角度、解决问题，对客户消除焦虑（安抚、陪伴和关怀）。对比售后支持，具备响应效率、技术专业性等方面的优势
- 陪伴：加入客户的“作战室”（War Room），和客户一起排查，问题不解决，自己不撤退；还会随时通报进展，必要的时候会将故障升级到更高的级别，寻求更专业的资源投入以共同解决；同时根据客户的不同反应进行不同方式的安抚
- 输出：发挥谷歌多年积累下来的非常宝贵的线上运维经验，在日常就跟客户沟通传递一些稳定性保障的知识
- CRE这个角色，既具备良好的专业技术能力，又有非常强的问题解决能力，同时还要具有优秀的客户沟通和关怀能力
- CRE更多的是一个服务性质的岗位，最终是要对客户的满意度负责
服务心态
- 服务心态：站在对方的角度考虑问题，解决问题
  - 多使用业务术语，少使用技术术语
  - 学会挖掘问题背后的真正诉求
  - 解决问题的时候关注目标，而不是聚焦困难
- 点评：机器比人更会服务! 永远相信，机器会比人更好~

Prev Next