阅读赵成的运维体系管理课总结笔记

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

运维的价值

运维的周期

        从软件生命周期来看，软件开发阶段只占整个生命周期的20%~30%左右，软件运行的软件运行维护阶段是最长尾的。

维护阶段

        从开发完成到测试验收通过后交付到运维软件包开始就是软件的维护阶段了

运维相关岗位

        维护阶段岗位有中间间开发、稳定开发、工具开发、监控开发、laaS开发或PaaS开发，甚至专注于底层的基础架构的内核开发，网络开发，协议开发等等都是跟业务软件的运行维护阶段直接相关的。

运维范畴

        一个研发团队内，除去业务需求实现层面的事情，其他都是运维的范畴

运维在框架中的体现

        运维能力是整个技术架构能力的体现，运维层面爆发的问题或故障，一定是整体技术架构中存在问题，单纯看技术架构或运维都是毫无意义的。

运维的忽略

        我们在绝大多数情况忽略了这个隐藏在软件生命周期的真正运维范畴，而是简单的从软件生命周期分段的角度给开发和运维划定了一条界限

运维价值

        运维的真正价值应该跟研发团队保持一致，真正聚焦到效率、稳定和成本上来。

对运维框架的思考

        1.应用运维体系建设

        2.效率和稳定性等方面的最佳实践

        3.云计算方面的思考和实践

        4.个人成长与趋势热点分析

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

Netflix运维现状

        Netflix没有传统的运维，对应岗位是SRE（用软件工程方法重新设计定义运维）。1亿用户，每天1.2亿播放时长，万级微服务实例业务体量，SRE人数不超过10个（Core SRE）

为什么Netflix会做得如此极致？

海量业务规模下的技术框架和挑战

        做法：为了应对超大规模的业务体量，引入微服务架构，提升了开发人员效率。

        挑战：框架复杂度大大提高，为维护带来极大的难度和挑战

        解决方法：在微服务架构下运维必需要靠软件工程思路打造工具支撑体系来支持 

        SRC产生的根本原因：微服务复杂到一定程度，超过人力认知掌控范围，为了有效和统一的技术解决方案之上，开发和运维产生了新的职责分工和协助方式

更加合理的组织架构和先进的工具体系及理念

        Netflix的前瞻性：很早就意识到微服务架构模式下运维已经成为了整个技术架构和体系中不可分割的一部分，将中间件、SRE、DBA、交付和自动化工具、基础架构等团队同一在云平台工程。

        优秀的技术架构：通过多种技术和体系如Spinnaker、Chaos Engineering等技术保障Netflix系统稳定运行

自由与责任并存的企业文化：技术团队端到端负责，you build it,you run it.

        Netflix 启示一：微服务架构模式下，我们必须换一个思路来重新定义和思考运维，运维一定要与微服务架构本身紧密结合起来。

        Netflix 启示二：合理的组织架构是保障技术架构落地的必要条件，用技术手段来解决运维过程中遇到的效率和稳定问题才是根本解决方案。

        Netflix 启示三：Owner 意识很重要，正确的做事方式需要引导，这就是优秀和极致的距离。

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

微服务框架模式下，运维视角中一定要以应用的角度分析和看待问题

应用的起源

        应用是从单体架构或分层架构演化过来的，如从一个单体工程中拆分出N个独立模块设置唯一标识符如APP-1、APP-2，通常称这些独立模块为应用。

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

面临的困难

        定义模块都是从业务角度细分都职业单一职能，需要相对独立的基础设施和组件（机器资源、域名、DB、缓存、消息列队等等），运行过程会有各种复杂关联关系为后续带来困难

应用业务模式

        每个应用对外提供的业务服务能力，并以API的方式暴露给外部

应用管理模型

        应用的各种属性如应用名、应用功能信息、负责人Git 地址、部署结构（代码路径、日志路径以及各类配置文件路径等）、启停方式、健康检测方式等等，其中应用名是唯一标识符

应用运行时所依赖的基础设施和组件

        资源层面：应用运行必需的资源（物理机、虚拟机、容、虚 IP 和 DNS 域名服务等）

        基础组件：中间件体系，如访问数据库需要数据库和数据库中间件，想要更快地访问数据，同时减轻 DB 的访问压力，就需要缓存等

规律

        这些基础设施和组件都是为了上层的一个个业务应用所服务的，始终基础设施和组件都跟应用这个概念保持着紧密的联系。第一步建立各个基础设施和组件的数据模型，同时识别出它们的唯一标识。第二步：标识出基础设施及组件可以与应用名AppName建立关联的属性

真实情况

存在不足

        大部分公司在这块统筹规划是不够的，框架引入微服务后续运维管理手段没有跟上，如开发过程中不考虑生命周期只将应用开发完和服务注册到服务配置中心，后续运维为了方便独立定义应用名体系等其他开发也不统一，系统无法成为体系

需要改进

微服务架构下运维思路要转变，要到应用的维度，从一开始统一规划将框架、开发和运维拉通了去看，要转换视角，规划以应用为核心的管理体系

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

总结：标准先行

为什么要做标准化

        标准化的过程实际上就是对运维对象的识别和建模过程，形成统一的对象模型，针对不同的运维对象，设施不同的动作，防止流程错乱徒增无畏的沟通成本，造成效率低下

标准化套路

        第一步：识别对象，如服务器、网络、ldc等

        第二步：识别对象属性，如服务器的sn序列号、IP地址、厂商等

        第三步：识别对象关系，如服务器所在机柜、接入交换机和服务器之间的级联关系等

        第四步：识别对象场景，如服务器的采购、入库、安装等

应用层面的标准化

        第一步：识别对象，在微服务架构设计拆分的时候确定

        第二步：识别对象属性，应用的元数据的属性、代码属性等等

        第三步：识别对象关系，应用与基础设施的关系、平面层应用与应用之间的关系等等

        第四步：识别对象场景，应用的创建、持续集成、持续发布等等

        在对象中应用是重中之重，是微服务框架下的核心运维对象

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

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

        分布式服务化框架

        分布式缓存及框架

        数据库及分布式数据库框架

        分布式的消息中间件

        前端接入层部分

基础架构组件的选型问题

问题

        由于业界的选择的解决方案和产品非常多，没有严格限制下，不同的开发团队或者开发人选择不统一，团队按照业务领域切分，极其容易产生与业务匹配的小规模技术团队

后果

        开发层面：开发初期投入大量精力到到基础组件和开源产品研究，产品不统一，要做大量适配工作，积累的经验不能互通

        运维层面：组件不统一、需要做大量的针对不同组件的适配工作，容易出现维护投入不足，导致一系列故障频繁等一系列问题。

如何解决

        对基础框架有同样的规划和建设，如每种组件只一种选型，数据库版本要统一，中间件统一等等，如何选型还得看具体的业务和应用场景

基础架构的服务化

概念

        基础架构统一标准后，组件只提供简单的维护功能，很多都是命令行层面维护，要将这些组件提供维护的API进行封装提供更加便捷的运维能力，

例子

        如Redis的个个环节基本都是Redis的原生能力来做，基本是不可维护的，需要将原生能力进行封装结合运维场景，将能力服务化（PaaS化），大大提升使用方的便利性

运维的职责是什么

        1.参与制定基础框架标准，并强势地约束

        2.基础框架的服务平台开发，目标是平台自助化，让平台依赖平台的能力自助完成对基础组件的需求，而不是依赖运维的人。

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

应用的生命周期

应用的创建阶段

        确认应用的基础信息和和服务信息，同时固化下来，创建初，要将应用和生命周期挂钩同时开启，还需要开启与应用相关的各类基础服务的生命周期

应用的研发阶段

        主要是业务逻辑实现和验证的阶段，过程当中涉及到代码提交合并、打包编译及不同环境下的发布部署还有各类测试。（这个阶段我们要为研发团队打造完善的持续集成体系和工具链支持）

应用的上线阶段

        过渡阶段，从应用创建过渡到线上运行

应用的运行阶段（应用生命周期中最重要、最核心的阶段）

        从运维角度来看：需要制定每个运维对象的SLI、SLO和SLA，建设能够对应用本身以及相关联的运维基础服务的各项运行指标进行监控和报警的监控体系

        从业务角度看：需要不断迭代更新线上应用，需要依赖研发阶段的持续集成过程与线上发布持续交付最终形成闭环体系

        从运行阶段应用的关系看：应用线上运行会面临外部业务的各种异常变化，以及应用自身依赖的基础设施、基础服务以及应用的各种异常状况。

应用的销毁阶段

        应用的业务职责不存在了，应用进行下线销毁（执行这一步取决于应用与基础服务的关系模型分析和建设是否到位）

06|聊聊CMDB的前世今生

什么是CMDB？

        当识别出运维对象和对象之间的关系时，并形成统一标准，固化到信息管理平台，就叫配置管理，专业说法就是是CMDB

CMDB起源

        源于ITIL（信息技术基础框架库），后由于CMDB本身概念定义问题，限制了CMDB的实施，再后面由于互联网的驱动和运维技术发展重新定义了CMDB

传统运营思路下的CMDB

        传统it运维的角度看，运维是核心对象是资源层面，更多的是把CMDB建设为一个以设备为中心的信息管理平台。

互联网运维体系下的CMDB

        在互联网阶段相比传统CMDB以设备为核心管理，变成了以应用为核心管里。传统CMDB管理范围有限定义为侠义的CMDB，而现在互联网运维思路下的CMDB外延更广，定义为广义的CMDB。

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

观点：CMDB是面向资源的管理，应用配置是面向应用的管理

CMDB是面向资源的管理，是运维的基石

        如以服务器这类资源主要的流程规范建设是确定对象、确定对象属性、确定对象关系、确定规划标准、确定对象场景再到可视规范化展示，如此从资源的维度的信息梳理，以及基于这些信息的平台和的流程规范建设就算基本成型。

应用配置管理是面向应用的管理，是运维的核心

        以应用为核心的管理维度，涉及到应用的基本信息、应用部署涉及的软件包、应用部署涉及的目录等等和CMDB里面的信息是两个维度的东西所以把资源配置和应用配置分开会更清晰

后两者通过“应用名-IP”的对应起来联系到一起

总结

        CMDB 是运维的基石，但是要发挥出更大的价值，只有基础是不够的，我们要把更多的精力放到上层的应用和价值服务上，所以我们说应用才是运维的核心。

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

如何有效组织和管理应用

问题

        微服务架构下如何统一有效的管理数量众多的应用

解决方式

        通过“服务树”的方式进行拆分，基于业务难度进行拆分如电商公司大维度可以拆分为电商、支付等近一步电商可拆分成用户、商品等，再近一步商品可拆分成详情、sku、spu等等，具体部门团队分工负责。

总结

        软件运维阶段，运维工作是否可以高效地组织开展，很大程度上，在前面的业务架构拆分阶段就决定了。也就是业务架构拆分得是否合理、职责是否明晰，决定了后续团队组织架构是否合理、团队职责是否明晰。如果这点没做好，到了运维阶段必然就是混乱的。

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

为什么会有集群服务分组建设

多环境问题

        常见环境众多

多IDC问题

        处理业务时可能会在多个idc机房部署，应用代码相同，但配置可能不同

多服务分组问题

        原因：应用依赖优先级是不同

        核心应用和非核心应用：如出现故障有影响到业务收入就是核心应用，影响较小或不影响非核心

        场景因素决定：这分组需要根据实际的业务场景来决定，是个动态调整的过程，需要开发和运维一起讨论和验证。

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

监控系统

        监控到每个应用、每个集群以及每台机器上的关键信息

发布系统

        监控到每个应用、每个集群以及每台机器上的关键信息

服务化框架

        通过其配置管理中心注册的应用名，来实现应用的服务和 API 管理，这里要做到与 CMDB 统一

基础服务中

       应用名：用于建立应用与分布式服务实例之间的关系

        应用与资源的对应关系：如核心资源做ACL访问控制等等

稳定性保障平台，或者叫服务治理平台。

         针对系统的稳定性，会在应用中做很多的降级限流和开关预案策略

总结：应用为核心的 CMDB 中，衍生出“应用 - 集群服务分组 - 资源”这样一个运维体系中的核心关系。

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

从价值呈现的角度看运维

运维基础平台建设

        如标准化、CMDB、应用配置管理、DNS域名管理等，是运维的基础和核心

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

        如选择开源产品还是自研的中间间产品需要标准化和服务化建设，在整个技术架构体系中，分布式中间件基础服务这一块起到了支撑作用

持续交付体系建设

        拉通运维和业务开发的关键纽带，是提升整个研发团队效率的关键部分。这个部分是整个软件或应用的生命周期的管理体系，

稳定体系建设

        如何快速定位解决问题和故障，稳定性保障

技术运营体系建设

        保障制定标准、指标、规则和流程能有效落地

运维协作模式的改变

        要通力合作，与周边团队协作配合，站在怎么能够打造和发挥出整个技术架构体系运维能力的视角

运维基础平台建设

        多少由运维团队完成

分布式中间件服务化建设

        和分布式团队配合，一起指定各种使用规划、标准、规划和流程

持续交付体系建设

        与虚拟化技术团队协作，实现用户使用的场景化需求

稳定体系建设

        对运维整体技术能力要求非常高，需要将不同部门甚至开发团队串联起来，朝着发挥出整体技术架构运维能力的方向演进。

运维组织架构

        基础运维：包括 IDC 运维、硬件运维、系统运维以及网络运维；

        应用运维：主要是业务和基础服务层面的稳定性保障和容量规划等工作；

        数据运维：包括数据库、缓存以及大数据的运维；

        运维开发：主要是提供效率和稳定性层面的工具开发。

10 | 谷歌SRE运维模式解读

SRC岗位的定位

        通过软件工程的方式开发自动化系统来替代重复和手工操作”的岗位。

SRE岗位的职责

        以稳定性为目标，围绕着稳定这个核心，负责可用性、时延、性能、效率、变更管理、监控、应急响应和容量管理等相关的工作。

管理体系上

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

技术体系上

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

谷歌为稳定性为核心目标的做法

        自动化：为了减少人为的、频繁的、重复的线上操作

        持续交付：由于需求迭代速度非常快，需要更加完善的发布系统。

        问题定位：为了能够快速定位问题，保障稳定

        各类分布式系统：如分布式锁、分布式文件、分布式数据库

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

CRE产生背景

        很多企业用户将本地运维转移到云上，对云上环境和稳定的担忧

CRE岗位的职责

        CRE 出现的根本目的，就是消除客户焦虑，真正地站在客户的角度去解决问题，同时对客户进行安抚、陪伴和关怀。

从CRE谈起做运维为什么要用服务心态

        是不是有服务心态，表现在我们的做事方式上，就是我们是否能够站在对方的角度考虑问题、解决问题。

如何做好

        1.多使用业务术语，少使用技术术语

        2.学会挖掘问题背后的真正诉求

        3.解决问题的时候冠军目标、而部署聚焦困难

12 | 持续交付知易行难，想做成这事你要理解这几个关键点

什么是持续交付？

        持续交付代表着从业务需求开始到交付上线之后的端到端的过程。

持续交付的关键点

        1.配置管理：具备标准化意识，展开工作时先标准化对象，先准化，再固化、然后自动化

        2.需求拆解：明确拆解的深浅

        3.提交管理：代码提交过程中合并策略就是提交管理

        4.构建打包：代码编译成可发布的软件包

        5.自动化测试：功能测试和非功能测试

        6.部署发布：部署到不同环境发布策略和注意事项不同

13 | 持续交付的第一关键点：配置管理

版本控制

        如SVN和Git，版本控制的主要作用是保证团队在交付软件的过程中能够高效协作，版本控制提供了一种保障机制。版本控制及其工具是必不可少的，因为这是开发团队协作最基础的工具

依赖管理

        如java熟知的依赖管理工具有 Ant、Maven 和 Gradle。

软件配置

        1.代码配置：跟代码运行时的业务逻辑相关的

        2.应用配置：应用的属性和关系信息

        3.代码配置和应用配置的区别：代码配置和业务逻辑有关是运行时的配置不依赖环境，代码配置和业务逻辑无关和环境有关

14 | 如何做好持续交付中的多环境配置管理？

多环境问题

1. 开发环境：主要是应用或软件开发过程中完成后，开发人员对实现的代码测试、联通、基本业务验证

2. 集成环境：开发人员完成代码开发并自验证通过后，部署到此环境，测试人员确保软件业务功能可用

3. 预发环境：在真实的生产环境下进行验证，不接入线上流量

4. Beta环境：灰度环境，引入万分之一或千分之一流量验证

5. 线上环境：正式发布上线

不同环境下的应用配置管理

        核心：应用配置管理

        应用属性信息：如代码属性、部署属性、脚本信息等

        应用对基础组件的依赖关系：如应用对 DB、缓存、消息以及存储有依赖，不同的环境会有不同的访问地址、端口、用户名和密码

        近一步理解：环境配置管理主要是针对应用对基础设施和基础服务依赖关系的配置管理。

环境配置管理的解决方案

方案一，多个配置文件，构建时替换

        不同环境定义一个配置文件，优点简单直接比较便捷。缺点实际环境众多，每多出一个环境就要多添加配置文件，配置同步容易出问题

方案二，占位符（PlaceHolder）模板模式

        配置值用变量来替换，缺点还是需要在文件中根据环境增多同步添加配置,需要重复构建

方案三，AutoConfig方案

        对比第二种添加了配置校验，构建时如果不匹配构建会报错，提前发现问题。还是没有解决多环境配置值问题

15 | 开发和测试争抢环境？是时候进行多环境建设了

环境分类

        线上环境：测试验收用

        线下环境：为用户提供服务

        规划上两环境是独立区域

线下环境分类建设

        来源：上述环境无法满足日常开发需求，需建立细分的小环境

 集成测试环境

        在软件发布上线前进行功能验证，保障业务流程顺畅

开发测试环境

        在开发人员为尽快发布代码，在完整业务应用和基础服务的环境下验证自己的代码功能。

项目环境

        在某些时间段时间非常紧凑，需要多项目并行，开发测试环境无法满足。只部署同一项目中涉及变更的应用

环境建设上的关键技术点

        来源：因线下环境的细分带来更多的工作量，复杂度和涉及到的技术有以下四个方面

        网段划分：如何进行网段划分

        服务化架构的单元化调用：如何建立服务调用规则

        环境的域名访问策略：选择何种访问策略

        自动化管理：以应用为核心如何设计管理模式

16 | 线上环境建设，要扛得住真刀真枪的考验

生成环境

        早期业务体量不大影响范围有限，线上环境=生产环境

Beta环境

        产生原因：发展后业务体量增大复杂度提高影响力变大，需要解决

        作用：针对小规模流量的真实业务模拟

        如何实现：通过调用RPC权重或流量的配比下调或调用HTTP在四层或七 层权重降低

预发环境

        产生原因：针对Beta环境可能也会造成部分真实用户和无法真实的模拟 生成环境数据场景；

        作用：复现线下无法复现的问题，定位问题

        如何实现：状态基础服务共用，网络隔离上，预发环境做独立的网段的划分，保证一定的稳定性

办公网生产环境（小蘑菇环境）

        产生原因：在项目上线前，因为时间原因，只能暂时等着

        作用：提前暴露很多问题，并进行优化改进，进一步保障系统问题和用户体验。

        如何实现：访问用户是办公网内的员工用户用指定办公网wifi接入，在稳定性相当于办公室生成环境，规模上是公司大部分员工的频繁访问产生的业务量

17 | 人多力量大vs.两个披萨原则，聊聊持续交付中的流水线模式

持续交付流水

        从一个应用代码提交开始，到发布到线上的主要环节，整个流程串起来是一个简化流水线模式

项目的需求分析

        要针对一个需求进行拆分，最终拆分成一个个的功能点，这些功能点最终落实到一个个对应的应用中，对应的逻辑体现就是应用代码的一个 feature 分支。

从一开始的需求管理维度，就确定了最终多个应用联调、测试以及最终发布的计划和协作方式

提交阶段之开发模式选择

主干开发模式

        每一次代码提交都是合并到 master 主干分支，确保 master 随时是可发布状态

gitflow开发模式

        在 master 分支之外，会有一条常驻 develop 开发分支，所有功能开发和缺陷修复都在这个分支上再建立分支。发布时合入一个从 master 分支中签出的 release 分支，最终发布的是 release 分支代码，然后 release 分支再合并回 master 和 develop 分支。

分支开发模式

功能开发或缺陷修复从 master 签出独立的一个 feature 或 bug 分支，发布前从 master 分支签出一个 release 分支，并将要发布的 feature 或 bug 分支合入。发布完成后，release 分支合入 master 分支。

开发模式选择原则

        主干开发模式：比较适合规模较大的应用

        gitflow：比较适合并行开发

18 | 持续交付流水线软件构建难吗？有哪些关键问题？

构建环节

        如java

        工具：Gitlab、Maven、Docker、自动化脚本工具

构建过程

1. 用JDK编译镜像，需要构建任务就创建一个Docker实例作为独立编译环境

2. 构建任务会根据应用配置管理中的 Git 地址，将代码克隆下来放到指定的编译目录。Docker 实例启动后，将编译目录挂载到 Docker 实例中。

3. 执行mvn package命令编译打包，生成一个可发布的软件包

4. 生成软件包放到指定构件库目录，或者直接发布到 maven 的构件库中管理，然后将 Docker 实例销毁。

几个关键问题

为什么用Docker做编译环境的工具？

        Docker 容器很大的一个优势在于其创建和销毁的效率非常高，可以快速创建出多个并行的实例来提供编译环境

为什么不直接生成 Docker 镜像做发布？

        虽然 Docker 是一个容器，但是我们的使用方式仍然是虚拟机模式，要给它配置 IP 地址，要增加很多常用命令比如 top、sar 等等，定位问题需要 ssh 到容器内。虽然 Docker 是一个容器，但是我们的使用方式仍然是虚拟机模式，要给它配置 IP 地址，要增加很多常用命令比如 top、sar 等等，定位问题需要 ssh 到容器内。

19 | 持续交付中流水线构建完成后就大功告成了吗？别忘了质量保障

流水线构建过程中，我们尤其要重视 3 个方面的工作内容

依赖规则限制

        主要是对代码依赖的二方包和三方包做一些规则限制。

功能测试

        包括单元测试、接口测试、联调测试和集成测试。

非功能测试

安全审计

        由安全团队提供的源代码扫描工具，在构建的同时，对源代码进行安全扫描，对于高危漏洞，一旦发现，是不允许构建出的软件包发布的。

性能和容量压测

        主要针对核心应用，进行发布前后的性能和容量比对，如果出现性能或容量差异较大，就会终止发布。

20 | 做持续交付概念重要还是场景重要？看“笨办法”如何找到最佳方案

软件的持续部署发布

        将构建完成和验证通过的应用软件包，发布到该应用对应环境下的 IP 主机上的指定目录下，并通过应用优雅上下线，来实现软件最新版本对外提供服务的过程。                                                  

1. 从 CMDB 中，拿到线上生产环境下的应用主机 IP 列表去对应关系，目的是要将软件包发布到应用对应的 IP 主机上。

2.  检查每台机器上的服务是否正常运行，如果是正常服务的，说明可以发布，但是服务本身异常，就要记录或跳过

3. 下载 war 包到指定目录。这里要依赖前期应用配置管理，在这一步要获取到该应用的源代码目录。

4. 关闭该应用在这台主机上的监控，以免服务下线和应用终止产生线上错误告警。

5. 下线。RPC 服务从软负载下线，如果该应用还提供了 http 的 Web 调用，就需要从 Nginx 这样的七层负载下线，下线动作均通过 API 接口调用方式实现。

6. 下线后经过短暂静默，重启应用。对于 Java 应用来说，重启时可以自动解压，启停命令等还是之前从应用配置管理中获取响应路径和命令脚本名称。

7. 上线，进行健康监测，检查进程和应用状态是否正常，如果全部监测通过，则开始上线服务，开启监控。

发布策略

        业界常见的几种模式，如蓝绿发布、灰度发布（金丝雀发布）、滚动发布等等

滚动发布

        即每批次发布 10 台或 20 台，升级完成后，再启动下一批次发布。这样每次发布的机器数量可以自行设定，但是必须低于 50%。

持续交付体系的收益

        持续交付体系运作起来后，整个流水线过程完全自助发布，运维无需介入，达到了 DevOps，或者说是 NoOps 的效果。

21 | 极端业务场景下，我们应该如何做好稳定性保障？

我们所面对的极端业务场景

可预测性场景

        业务场景是可预测的，列如业务峰值和系统压力峰值会出现在某几个固定的时间点，我们所做的所有准备工作和稳定性应对措施，都是针对这些固定时间点的

不可预测场景

        业务场景是不可预测的，如社交类业务不知道什么时候会出现突发热点事件，无法随时准备

我们要迎接的技术挑战

运维自动化

        标准化覆盖面是否足够广泛，应用体系是否完善，持续交付流水线是否高效，云上资源获得是否足够迅速，这些都是运维自动化的基础。

容量评估和压测

        要时刻做好对系统容量心中有数，在特定条件下判断扩容的部位、多少、顺序，日常对各类系统进行模拟压测

限流降级

        主动降价：判断业务是否在容量承受范围之内，是否要主动把功能关闭

        被动降级：就是熔断，需要有手段将故障进行隔离

开关预案

        业务功能开关：如限流降级

        系统功能开关：如当缓存故障，将多于请求转发到数据库中，但数据库的容量没有缓存高，通过限流到数据库可支持容量再降级

故障模拟

        在日常中经历过的故障中提炼出场景，制定好策略，然后不断进行模拟演练。

监控体系

        通过监控体系支持采集和统计指标和异常判断

极端业务场景下的不确定因素

        如商城业务场景下的各类复杂变量组合，数量众多，可能很多微小变化会产生很大差别，系统可能对后果无法承受

22 | 稳定性实践：容量规划之业务场景分析

流量规划的场景分析

        如电商：在大促这个场景下，在零点时间段，交易下单这个环节是核心中的核心，其他业务与其形成倒三角的峰值评估。

        根据业务 GMV、UV 等目标，对技术上的交易下单峰值这个核心指标进行推导的过程，如商城中GMV 目标收入，UV、PV、转化率、客单价以及商品单价，都是业务目标，通过大会场UV值推导其他UV值再推导加入购物车的值再一步步推导下单的峰值是和支付峰值是多少，后优化容量以应对过多的业务量

构造压测的数据模型

        数据模型要接近真实场景，数据量要接近真实场景

23 | 稳定性实践：容量规划之压测系统建设

第一个维度，压测粒度

单机单应用压力测试

        摸清单应用的模型，根据模型进行单机单应用压力测试获得单个应用和单个应用集群容量水位值作为后续扩容基础

单链路压力测试

        获取到单个应用集群的容量水位之后，开始对某些核心链路进行单独的压力测试如商品详情浏览链路、加购物车链路、订购下单链路等等

多链路/全链路压力测试

当单链路的压测都达标之后，我们就会组织多链路，或者全链路压测。

第二个维度，压测接口及流量构造方式

线上流量回放

        常见的技术手段如 TCPCopy，或者 Tcpdump 抓包保存线上请求流量。

线上流量引流

        将应用集群中的流量逐步引流到一台主机上，直到达到其容量阈值； ·可以通过修改负载均衡中某台主机的权重，将更多的流量直接打到某台主机上，直到达到其容量阈值。

流量模拟

        如用 Gatling，或者针对我们自己的需求，比如自动生成压测脚本等，做了一些二次开发

第三个维度，施压方式

        1.通过实现在 Web 控制台配置好的压测场景，自动生成压测脚本。

        2.利用数据工厂构造出压测数据，进行业务场景的模拟，

        3.通过 Web 控制台，根据压测脚本和压测数据，生成压测任务，推送到压测集群的 Master 节点，再通过 Master 节点推动到上百台的 Slave 节点，然后就开始向线上系统施加模拟的流量压力了。

第四个维度，数据读写

        对压测数据做专门的标记，通过分布式数据库中间件判断请求是否是压测请求，是则将路由写到影子库中（影子库相当于正式库的影子对于非敏感信息，数据内容也可以保持一致，最大程度上保证数据模型一致）

24 | 稳定性实践：限流降级

什么是限流和降级

限流

        它的作用是根据某个应用或基础部件的某些核心指标，用来决定后续请求是否拦截，一秒阈值200，但是一秒内有210，多的10就会拦截

降级

        它的作用是通过判断某个应用或组件的服务状态是否正常，来决定是否继续提供服务。如50ms内请求多于n此，不再对外提供服务，静默一段时间（如5s或10s）

常见的限流解决方案

第一类，接入层限流

Nginx 限流

        对于一个 Web 类应用，如 Web 页面或 H5 页面，通常会将限流策略增加到这一层，设置 QPS、并发数以及 CPU 的 Idle 作为限流指标。Nginx 通过对应函数接口，获取到以上指标信息，然后通过 Lua 脚本实现限流的逻辑。

API 路由网关模式

        在配置中心中进行配置即可。

第二类，应用限流

        赖配置中心管理，限流逻辑会配套服务化的框架完成。

第三类，基础服务限流

1. 资源和策略：资源就是要进行的限流对象，策略就是限流规则

2. 时间精度：主要指对于 QPS、并发数或 CPU 的阈值判断。

3. 指标计数: 对于并发限制请求，会统计当前的并发数

4. 限流方式: 对于 Nginx 就针对总的请求进行限流即可，

5. Spring AOP: 通过配置需要限流的方法作为 AOP 的切入点，设定 Advice 拦截器，在请求调用某个方法，或请求结束退出某个方法时，进行上述的各种计数处理，同时决定是否要进行限流，如果限流就返回约定好的返回码，如果不限流就正常执行业务逻辑。

6. Web 类型的限流: 对于 Web 类型 URL 接口限流，我们就利用 Servlet 的 Filter 机制进行控制即可。

7.  控制台:  将上述的各种配置和策略通过界面的方式进行管理，同时在配置完成之后，能够同步到对应的服务实例上。

限流降级的难点

        从整个建设过程来看，限流降级的难点和关键还是在于整体技术栈的统一，以及后期对每个应用限流降级资源策略的准确把握和配置。

整体技术上

        对服务化框架、各类分布式框架以及代码开发框架（如 Spring），很难做到统一

限流降级策略把握上

        如开发人员要非常清楚哪些接口是核心接口，它的来源和去向有哪些；哪些来源是核心的，哪些是非核心的；如果要限流，需要对哪些接口限流，同时要重点保障哪些接口等等

25 | 稳定性实践：开关和预案

如何理解开关和预案

开关

        这个概念更多是业务和功能层面的，主要是针对单个功能的启用和停止进行控制，或者将功能状态在不同版本之间进行切换。

预案

        可以理解为让应用或业务进入到某种特定状态的复杂方案执行，这个方案最终会通过开关、限流和降级策略这些细粒度的技术来实现，是这些具体技术方案的场景化表现。

技术解决方案

1. 开关管理：开关的字段以key-Value方式管理，开关方式相当于if判断获取的value值

2. 开关推送：当在控制台上修改开关值后，会推送到微服务的配置中心做持久化，这样当应用下次重启时依然可以获取到变更后的值。另外一种方式，通过 HTTP 的方式推送，这种情况的应用场景是，当第一种情况失败时，为了让开关快速生效预留第二个接口。

3. 配置变更：应用中引入的开关 SDK 客户端会监听对应配置的变更，如果发生变化，就会马上重新获取，并在业务运行时生效。

4. 预案执行：就是多个开关策略的串行执行，会重复上面这几个关键步骤

26 | 稳定性实践：全链路跟踪系统，技术运营能力的体现

全链路跟踪系统在技术运营层面的应用

        如 TraceID，请求从接入层进来，TraceID 就需要创建；或通过 Nginx 插件方式创建到 http 的 header 里；或通过 RPC 服务化框架生成。后续的请求中，这个字段会通过框架自动传递到下一个调用方，而不需要业务考虑如何处理这个核心字段。

第一个场景，问题定位和排除

        如某个页面变慢。根据 URL 查看某次调用的情况，发现瓶颈是在 RateReadService 的 query 接口出现了严重阻塞。就可以根据详细的 IP 地址信息，到这台机器上或者监控系统上，进一步判断这个应用或者这台主机的异常状况、机器故障、运行故障等等

第二个场景，服务运行状态分析

1. 运行质量服务：通过一段时间的数据收集形成服务接口运行状态的分析，也就是应用层的运行监控，常见的监控指标有 QPS、RT 和错误码，还可以跟之前的趋势进行对比

2. 应用和服务依赖：根据调用链的分析，统计出应用与应用之间，服务与服务之间的依赖关系及依赖比例，

3. 依赖关系的服务质量：关注被依赖的应用或服务的实时运行状态和质量，看应用间实时的调用状态。如应用调用 QPS是否 突然增加了，或者 RT是否 突然暴涨，通过该依赖关系就可以快速确认。

第三类场景，业务全息

        全链路跟踪系统与业务信息的关联，如商品没有享受优惠用户进行投诉需要在商品的整个购买环节和流程一步步排除寻找问题所在

27 | 故障管理：谈谈我对故障的理解

为什么容易出现故障

1. 系统正常只是该系统无数异常情况下的一种特例

2. 故障，是一种常态，任何一个软件系统都避免不了

3. 业务体量越大，系统越复杂，问题和故障就越多，出现故障是必然的。

4. 我们的目标和注意力不应该放在消除故障，或者不允许故障发生上，因为我们无法杜绝故障。所以，我们更应该考虑的是，怎么让系统更健壮，在一般的问题面前，仍然可以岿然不动，甚至是出现了故障，也能够让业务更快恢复起来。

5. 故障永远只是表面现象，其背后技术和管理上的问题才是根因

我们需要做

1. 出问题，管理者需要自我反省

2. 强调技术解决问题，而不是单纯地靠增加管理流程和检查环节来解决问题，技术手段暂时无法满足的，可以靠管理手段来辅助。

28 | 故障管理：故障定级和定责

故障的定级标准

技术支持（NOC）

        作用1：跟踪线上故障处理和组织故障复盘

        作用2：制定故障定级定责标准，同时有权对故障做出定级和定责，

故障定级标准

        故障等级：P0-P4，P0最高

        如交易链路故障定级标准：

        如用户IM故障定级标准：

故障的责任标准

目的

1. 避免扯皮推诿

2. 正视问题，严肃对待

1. 变更执行比：如变更方没有及时通知到受影响方，或者事先没有进行充分的评估，出现问题，责任在变更方；如果通知到位，受影响方没有做好准备措施导致出现问题，责任在受影响方；变更操作的实际影响程度大大超出预期，导致受影响方准备不足出现故障，责任在变更方。

2. 服务依赖：比如私自调用接口，或者调用方式不符合约定规则，责任在调用方；如果是服务方没有明确示例或说明，导致调用方出现问题，责任在服务方等等。

3. 第三方责任：比如机房 IDC 电力故障、服务器故障、运营商网络故障等等，如果确实是不可抗力导致，责任在第三方；但是因自身的冗余或故障预案问题导致故障，责任在应用 Owner。

29 | 故障管理：鼓励做事，而不是处罚错误

关于责任和处罚：

1. 定责是对事不对人

2. 处罚对人不对事

对处罚的态度

        1.处罚不能一刀切，更不能上纲上线，一定要慎重。

        2.绝大多数的严重故障都是因为无意识或意识薄弱导致的，并不是因为单纯的技术能力不足等技术因素。

我们要做

        鼓励做事，而不是处罚错误，对故障一定要有容忍度，一定要有耐心

        处罚的“负”作用远超我们的想象，如果定责跟绩效强挂钩，团队就陷入这种恐慌、质疑、挑战以致最终相互不信任的局面。

30 | 故障管理：故障应急和故障复盘

故障应急

业务恢复预案

        第一原则：优先恢复业务，而不是定位问题。

第一方面，故障模拟

        1.IDC层面：可以通过人为破坏进行模拟的，模拟手段相对简单，但是破坏力和影响面会很大，所以做之前一定要准备充分。

        2.系统层面：通过开源和Linux系统自带的工具支持，模拟系统异常场景

        3.应用层面：通过Spring 的注解功能，在运行时模拟异常状况，然后有针对性地看各种限流降级和开关预案策略能否生效

第二方面，有效的组织协调

1. 确定故障影响面及等级：故障通过个个渠道反馈，技术支持根据故障定级标准

2. 组织应急小组：无法马上定位排查故障，召集个个技术骨干和主管由技术负责人带头指挥排除故障

3. 信息通报：对故障先进行初步登记，组织应急小组后每个一段时间开展信息同步，直至故障排除

故障复盘

目的：复盘的目的是为了从故障中学习，找到我们技术和管理上的不足，然后不断改进。

1. 召集复盘会议：会提前将故障信息发给故障处理的参与方，准备复盘过程中需要讨论的问题，视情况决定是否邀请业务方人员参会

2. 组织会议流程：协调和控制会议中的讨论

3. 对故障定级定责：起到类似“法官”的判决作用，根据前面讲到的标准执行

4. 明确后续改进行动及责任人，录入系统并定期跟踪。

故障复盘关键环节：

        第一，故障简单回顾：主要针对故障发生时间点，故障影响面，恢复时长，主要处理人或团队做简要说明

        第二，故障处理时间线回顾：技术支持在故障处理过程中会简要记录处理过程，比如每个操作的时间点，责任人，操作结果，中间的沟通和协作过程，比如几点几分给谁打了电话，多长时间上线的等，

        第三，针对时间线进行讨论：回顾完上述时间线之后，提出过程中存在的疑问，通常我们对处理时长过长、不合理的环节提出质疑。

        第四，确定故障根因：通过讨论细节，我们对故障根因进行判断，并再次对故障根因的改进措施进行讨论

        第五，故障定级定责：根因确定后，结合前面已经确认的故障影响面，对故障定级定责

        第六，发出故障完结报告：故障完结报告的主要内容包括故障详细信息，如时间点、影响面、时间线、根因、责任团队（这里不暴露责任人）、后续改进措施，以及通过本次故障总结出来的共性问题和建议。

定期总结故障案例

        按照一个季度、半年和全年的周期，更容易地发现一些共性问题，以便于研发团队在稳定性建设方面的规划。

        故障复盘时一定要制定出我们自身需要改进的措施

31 | 唇亡齿寒，运维与安全

运维和安全的关系

        在协作上：运维不能只是被动响应，而应该主动与安全合作，共建安全体系，与运维体系融合，把防线建设好，从源头控制

安全体系

        1.入网监控：对进入线上环境人员登录管控，如通过VPN接入进行管控，是整个环境的第一道防线

        2.堡垒机：入网监控后，对其中的硬件或虚拟设备进行登录管控，可通过堡垒机实现

        3.主机安全管控：添加Agent（代理），实时地对可疑的进程、端口、账号、日志以及各类操作进行监控

        4.黑盒扫描：对主机上对外开放的端口和使用的服务进行扫描，通过模拟恶意攻击来实现

        5.白盒扫描（代码审计）：针对代码中明显的漏洞（xss漏洞、sql注入等等）进行审计

        6.WAF，Web Application Firewall：WAF对外部Web服务进行保护，通过一定的业务规则配置和识别来阻止恶意访问实现

        7.应急响应中心SRC：对外聚集“白帽子”通过主动发现网站和系统漏洞，后通过SRC提交给安全部门

32 | 为什么蘑菇街会选择上云？是被动选择还是主动出击？

所面临问题

成本闲置问题

        如电商平台在双十一、双十二时流量是平时的几十上百倍需要采购更多设备，但是流量峰值通过平时设多数备处于闲置状态，收益非常低

基础维护问题：选择托管IDC模式

1. 资源利用率问题：现实CPU资源的使用率只有10%-20%，而调度分配技术上门槛又太高，硬件厂商对定制规模太小基本不考虑

2. IDC机房扩建问题：面临机房扩建，存在资源紧张，而选择不同运营商的机房间纯在差异影响业务体验甚至业务发展

3. IDC机房的选址：国内优秀资源紧张，存在的零星机柜分布和维护十分不方便，如果选择低节点网络质量还会下降

4. 底层技术投入和人才的问题：专精人才太少，人力成本很高，发生人员流动存在风险，在发展需求上更聚焦业务而不是基础研究

纵观技术发展趋势

1. 软件框架发展的趋势上看：云计算不断发展，对资源层面依赖变少
2. 人工智能对云计算能力的释放：未来人工智能的发展和应用，必然依赖云计算

“没有银弹”

        不能依靠未来云计算就无视现在问题，无论技术、产品、还是服务都是需要累积和共同努力

33 | 为什么混合云是未来云计算的主流形态？

关于混合云

1. 最开始解释：私有云和公有云的混合

2. 发展一定阶段：因为公有云更加丰富，早期通过CDN提供服务，这种模式从云的特性讲就是混合云模式

3. 现在解释：云服务兴起，云服务与自身业务和IDC机房形成了一个整体

4. 应用场景：已经构建了自身的技术体系和架构，在选择上云过程需要的过渡阶段就是混合云的应用场景

所经历的几个基础设施建设阶段

完全托管IDC模式

        选择与电信运营商或者第三方 ISP 合作，租赁其 IDC 机房中的机柜，其他主机硬件和网络设备自行采购，然后放入机房中进行托管

资源短缺租赁模式

        跟运营商或第三方 ISP 谈过一些短期租赁服务器和资源的合作（方式上不够灵活称“人肉云”）

同城混合云模式

        运营商和ISP服务商的云资源和自身在同一机房或同城机房，而使用他们的云资源

共有云体系内混合云模式

        整体搬迁到共有云平台，自身使用完全独立的物理机资源，除硬件和网络外，操作系统和各项技术栈还完全是由我们自己运维，对于数据库或大数据这样的存储类业务，本身支持业务运行的核心基础设施，短期内仍然还是采用独占物理机的模式

1. 技术匹配问题：自身对各种中间件和工具进行了自研做了大量的优化工作和特性定制，还有云上资源无法满足对硬件的特定需求

2. 数据安全问题：政策要求或政策限制的业务，如金融行业或ToB业务，在数据安全方面需要全面考虑

34 | Spring Cloud：面向应用层的云架构解决方案

Spring cloud架构的影子

1. 提出Cloud-Native(云原生)概念,帮企业提供云上业务端到端的技术解决方案，全面提升软件交付效率，降低运维成本。除了业务解决方案和代码，其它事情都可以交给平台处理。

2. Spring Cloud 除了提供微服务治理能力之外，还成为了微服务应用与云平台上各项基础设施和基础服务之间的纽带，并在其中起到了承上启下的关键作用。

CNCF

        来源：Google创建的云原生体系

        优势：与K8S集成配套，方便应用到K8S生态当中

35 | 以绝对优势立足：从CDN和云存储来聊聊云生态的崛起

CDN和云存储

        随着业务高速发展，对存储要求本地压力极大，选择CDN厂商回源访问云储存的方式，完全依赖CDN这种第三方服务去解决存储要求

云生态的优势

技术层面

        CDN 模式下，图片上传云存储以及 CDN 回源云存储，基本都是走公网网络，在国内复杂的网络条件下，传输质量就很难保障。在公有云模式下基本都有专线质量保障。即使没有专线，他们也会不断优化中间的线路质量。

成本层面

1. CDN宽带费用：整体拉低了CDN价格

2. 回源宽带费用：通过整合到公用云内部网络，回源价格大大降低

3. 储存空间费用：无太大变化

生态优势，强者越强

        一般情况下客户都会首选生态内的产品，而不会再跳出去选择其它独立的产品服务，很多独立的技术产品，正在向云生态靠拢，选择跟公有云合作，争取让产品进入到某个云生态中，并提供相应的云上解决方案和技术支持。

36 | 量体裁衣方得最优解：聊聊页面静态化架构和二级CDN建设

静态化架构建设的业务场景

如电商

1. 访问量最大的是商品详情页

2. 页面组成包括商品名称、商品描述、产品参数描述、价格、SKU、库存、评价、优惠活动、优惠规则以及同款推荐等等信息

3. 其中商品名称、商品描述、产品参数描述等等，一般在商品发布之后，就很少再变动，属于静态化的内容可以单独存放，

4. 可通过业务请求时直接返回，而不用再通过调用应用层接口的方式，去访问缓存或者查询数据库，可大大提升访问效率

页面静态化框架

ATS（Apache Traffic Server）：开源产品，它能对动静态分离的场景提供很好的支持

关键技术点

1. 动静态分类：将页面静态信息和动态信息区分出来，将静态信息通过ATS集群获取后用HTTP请求调用获取通过ATS组装返回给调用

2. 动态数据获取：直接采用 ATS 的 ESI 标签模式，用来标记那些动态的被请求的数据。

3. 失效机制：分为主动失效、被动失效和定时失效，失效消息通过 HTTP 的 Purge 方法发送给 ATS，而失效中心则会通过订阅消息系统中特定的 Topic，或者 MySql 中特定的 binlong 变更，执行失效。

静态化框架在大促场景中的应用

        如在双十一通过提前确定商家和商品，在促销时间如价格、优惠、库存这些必需固定，有变化也在订购阶段，将静态数据提高到了95%，RT时延也从200ms降低到50ms

二级CDN建设

        在用户访问网站时可能由于不同用户位置距离不同，访问体验不同，可以在静态化角度来看可以将请求分布到更多地域节点，解决用户访问距离问题，方案有进行静态化与公有云相结合

                        

1. 回源线路，公网回源转变为专线回源：将公网访问模式调整成了内网调用模式

2. 弹性伸缩：通过公有云节点很方便地进行动态扩缩容

3. 高可用保障：保障多节点的高可用，在单个节点故障时，要能够快速切换通过 HttpDNS 这样切换 IP 的方式实现

37 | 云计算时代，我们所说的弹性伸缩，弹的到底是什么？

弹性伸缩的主体是谁

常见主体

1. 服务器的弹性伸缩：如运行到私有云上为保障弹性，提前采购、上架、装机、配置然后交付资源，但公有云就可以省去，即拿即用

2. 应用的弹性伸缩：同上，需拿到运行的服务器资源

3. 业务的弹性伸缩：通常一个业务可能会包括多个应用，所以为了保障整个业务容量充足，需要扩容多个应用

日常工作应该注意的点

1. 一定是从实际问题出发，找到问题的主体，然后才是针对问题的解决方案

2. 如果问题处于初期，且是发散状态时，主体可能表现出很多个，这时我们一定要找到最本质的那一个，往往这个主体所涉及的运维场景就包括了其它主体的场景。

38 | 我是如何走上运维岗位的？

如何做好运维工作

        要敢于承担责任，敢于表达自己的想法

        能站在对方的角度考虑问题，或者说要有服务心态。

        文字表达和口头表达能力。

        从更全面的角度看待问题。

        首问负责，问题闭环。

为什么会把运维当作职业发展的方向？

        作者在华为中工作受到华为公司氛围影响，认为做运维很自豪

39 | 云计算和AI时代，运维应该如何做好转型？

国外netflix的模式

        运维工作全部都由开发人员完成，平台也由开发自己完成，只保留极少的 Core SRE 角色专门响应和处理严重等级的故障。

国内阿里的模式

        2016年也开始进行“去 PE”的组织架构调整，原来需要 PE 完成的运维工作，全部由开发承担。

作者团队

        近两年也没有招聘新的应用运维人员了

1. 随着自动化逐步完善，效率不断提升，单个 PE 能够支持的业务变得越来越多；同时，很多事情开发都可以自助完成。

2. 有意识地招聘具备开发能力的人员，他们入职后一方面参与各类平台的开发，另一方面还要定期轮岗做一些运维工作。后来我发现，只要有效进行引导，同时具备运维和开发能力是不成问题的。

应用运维的转型

建议：学会写代码

        1.从 Python、PHP 或 Go 这些上手比较简单的语言开始

        2.提升产品意识

        3.提升技术运营意识。

云计算和 AI 带给我们的挑战

        如O2O除业务代码外，其它基础层面的服务就完全依赖于某大型公有云的 IaaS、PaaS 以及周边的各类服务体系；

        要根据自己的业务特点，找到跟业务相切合的价值呈现点，是我们每一个人应该去思考和探讨的。只有找到这些点，我们做的事情才会有价值和意义，我们所在的岗位才会有价值和意义。

        要多去了解AI，因为未来随着技术、数据和计算能力的提升，AI 是一个必然的趋势。如果一点都不了解，极有可能就会被卡在门槛外面

40 | 运维需要懂产品和运营吗？

        研发团队对运维团队的诉求，以及运维呈现的价值已经发生了变化，我们更加需要能够帮助团队建设出高效运维体系的角色，而不是能够被动响应更多问题的角色

运维的角色转变和价值体现

        运维要有产品和运营意识，第一能将寻求将清楚，第二能将产品推广落地

技术产品

        通过发现日常生活中的痛点隐患很靠人力完成的工作转换成需求，把一些标准化和生命周期管理的方法论融进来，通过流程图或文字描述输出，如此提升我们标准化制定能力、场景需求分析能力；

技术运营

1. 平台落地：运维和开发配合做出一些改造，为后续更大规模的效率提升和平台建设打下基础。

2. 线上运行数据分析：应该要形成对整个业务和技术架构体系改进和完善的正反馈才行

3. 过程改进：解决好不同角色和团队之间的协作问题，同时过程中需要改进和完善的内容，能够落实到平台和工具的，也要形成正反馈，来提升我们工具和平台的效率。

41 | 冷静下来想想，员工离职这事真能“防得住”吗？

关于员工离职的两个观点

        第一个观点：对于离职这个事情，本质上就是员工个人发展和团队发展不匹配之间的矛盾。

        第二个观点：对于员工离职，从管理者角度，我们应该理解为必然结果，坦然接受，而不是避而不谈。

谈谈如何做好技术管理

        1. 帮助员工做好个人中长期发展目标规划

        2. 进行梯队建设

        3. 提升管理意识

技术管理中引以为戒的一些反模式

        1. 事必躬亲，不懂授权，不敢授权

        2. 总认为自己才是最正确的

        3. 仅仅关注技术层面，忽略全局

42 | 树立个人品牌意识：从背景调查谈谈职业口碑的重要性

对求职者的背景调查

        背景调查对于关键岗位和高级别岗位，至少在互联网公司，已经成为了必须环节。而且越关键、越高端，背调审计就越严格。

作者观点

        1.对于我认为特别优秀的，我会给出强烈推荐或者非常推荐的建议。

        2.对于确实存在短板或较大自身问题的，我也会客观反馈，建议对方在候选人面试时或入职后，在管理上多加注意。

如何树立个人口碑

        背调过程不可控，但是我们自身的表现却从来都是可控的。

        如果想要树立个人的好口碑，那就需要我们付出更多，要让团队和其他成员明确你独特的个人价值

要引以为戒的反例

        第一个，诚信问题，这是高压线，触碰不得。

        第二个，消极怠工问题，这一点我认为是职业道德问题，是令人厌恶的。