├── Chapter 1 Outline.md ├── Chapter 2 Data Service.md ├── Chapter 3 Continuous Delivery Service.md ├── Chapter 4 Product Operation Service.md ├── Chapter 5 Monitoring Service.md ├── Chapter 6 Client Service.md ├── Chapter 7 Cost Service.md ├── Chapter 8 User Experience Service.md ├── Chapter 9 HA Service.md ├── LICENSE └── README.md /Chapter 1 Outline.md: -------------------------------------------------------------------------------- 1 | # 第一章 总纲 2 | 3 | ## 1. 开放运维联盟介绍 4 | 开放运维联盟（OOPSA）成立于2015年10月31日，2015 GOPS：全球运维大会·上海站。在现场八百名运维同仁的共同见证下，开放运维联盟指导单位数据中心联盟（DCA）常务副理事长何宝宏博士、秘书长孙明俊女士，和开放运维联盟的六位联合发起人共同点亮启动球。 5 | 6 | OOPSA 的六位联合发起人均为运维资深从业人士，其中既有一线大厂如BAT 多年工作经验的专家人士，也有近年来运维行业的思考者、布道者、运维自媒体。这些发起者的共同特点是，深植于运维，深知其中疾苦；深爱着运维，希望和广大运维同仁们一起，共同成长。 7 | 8 | OOPSA 的成立，得益于微信及这个时代。来自高效运维、互联网运维杂谈和数据中心操作系统等微信公众号的众多高质量技术原创文章，吸引了大量志同道合的同仁。于是，大家汇聚，相识、相知。 9 | 10 | ![](http://7xl5e0.com1.z0.glb.clouddn.com/C1%200001.png) 11 | 12 | 图片地址：http://7xl5e0.com1.z0.glb.clouddn.com/C1%200001.png 13 | 14 | 开放运维联盟想汇聚行业的力量与智慧，从运维最佳实践、运维规范开始，一步一步，从内而外，开展工作。互联网行业可能会消失，但运维不会消失，希望运维可以见证并助力传统企业融合互联网的全过程。 15 | 16 | ![](http://7xl5e0.com1.z0.glb.clouddn.com/C10002.png) 17 | 18 | 图片地址：http://7xl5e0.com1.z0.glb.clouddn.com/C10002.png 19 | 20 | 开放运维联盟下设多个工作组，包括应用运维工作组、云运维工作组及大数据运维工作组等，以分别及协同开展工作。 21 | 22 | ## 2. 应用运维工作组介绍 23 | 本工作组目前由以下成员组成（按字母序）： 24 | 25 | - 刘栖桐（腾讯互娱运维负责人，智能运维提出方） 26 | - 梁定安（腾讯SNG空间运维负责人） 27 | - 徐奇琛（京东无线运维总监） 28 | - 孙宇聪（coding.net CTO，原Google SRE） 29 | - 王津银（优维科技创始人，精益运维提出者） 30 | - 涂彦（腾讯互娱运维总监，智能运维提出方） 31 | - 萧田国（触控科技总监，高效运维提出者） 32 | 33 | 这七位同学分别来自于游戏、搜索、电商、社交这几大互联网应用的领域，基本可以代表目前主要方向上的互联网应用，他们的经验可以提取一些通用的东西出来，能够普惠于整个互联网行业的运维。 34 | 35 | ## 3. 互联网应用运维涵括范围 36 | **应用运维是做什么的？** 37 | ![](http://7xl5e0.com1.z0.glb.clouddn.com/C10003.png) 38 | 39 | 图片地址：http://7xl5e0.com1.z0.glb.clouddn.com/C10003.png 40 | 41 | 42 | 用运维就是支持每个公司应用系统的运维，这些应用系统有一些是直接对外提供服务，为公司直接创造价值的，最典型的例子，比如游戏或者电商的网站等等。 43 | 44 | 还有一些可能不直接创造价值，但是对于公司来说是非常重要的系统，比如通信行业，电信对外服务的网站，这也是非常重要的应用系统。那么，维护这些系统就叫应用运维。 45 | 46 | 应用运维的价值是要服务于业务，帮助业务实现价值的最大化。要么就是帮助业务赚更多的钱，要么就是帮助业务提供更好的服务给业务的用户，从而为业务创造更大的价值。 47 | 48 | 因此，应用运维相比于传统的网络运维、IT运维要更贴近业务一些，**所以应用运维模式就是要贴近业务、理解业务，进而进一步挖掘业务背后的价值，最后进一步扩展服务的价值。** 49 | 50 | ## 4. 互联网应用运维标准产生背景 51 | 为什么要做互联网应用运维框架和能力模型？ 52 | 53 | 大家都很熟悉ITIL，运维领域在这之前一直流行的指导思想就是ITIL思想，带给大家的是可用性管理、发布管理、配置管理、变更管理，事件管理。 54 | 55 | 接触ITIL久了以后，用ITIL指导事件会发现一些问题： 56 | - ITIL的这些理念非常正确，它总结得非常到位，好象已经无可再提炼了，但是要把这些指导思想从思想层面落地，好象中间有一点对不上，原因是什么呢？ITIL这些理念提炼得非常抽象，已经非常理论化了，如果我们再把它反推回去让它变成落地的实践是有点困难的。当然，ITIL里面已经提供了最佳实践，实施标准比如ISO20000之类的，但是热度不那么火，推广范围也没有那么广。所以，IT作为一个思想去指导我们怎么思考、怎么规划是非常有用的，但是真正要落地的时候，可能就有点困难。 57 | 58 | - ITIL的制定已经有非常悠久的历史，ITIL是英国在80年代末开始制定的，在2000年成为国际标准。那个时候互联网应用并不发达，ITIL的很多指导思想是基于IT服务的，当我们把它应用到互联网运维领域的时候，总是感觉方向上是正确的，落地的时候好像缺一点点，这也是造成ITIL在我们互联网领域落地有点困难的原因。 59 | 60 | 基于以上两个原因，需要有一套基于ITIL思想同时又结合互联网应用领域实际落地经验的指导思想，来帮助大家怎么样更好地把互联网运维做好。 61 | 62 | ## 5. 互联网应用标准的体系构成 63 | 这套体系应该包括以下几个部分： 64 | 65 | ![](http://7xl5e0.com1.z0.glb.clouddn.com/C10004.png) 66 | 67 | 图片地址：http://7xl5e0.com1.z0.glb.clouddn.com/C10004.png 68 | 69 | - 互联网应用运维框架。主要是作为一套指导思想，去告诉大家互联网应用运维需要做哪些大方向的事情； 70 | - 互联网应用运维能力模型。这个运维能力模型是支撑这套框架的，同时也是一套对于运维能力的评估标准。 71 | - 互联网应用运维规范。这个规范就是真正去指导如何落地，是能力模型和框架落地的主要部分。 72 | - 互联网行业千变万化，虽然可以简单地把互联网行业的应用划分为游戏、社交、电商等等几大类，但是每个公司的情况各有不同，因此还需要沉淀各个不同行业的最佳实践案例，以此来指导每一个行业、每一个公司面对不同情况的时候，你可以去参考这些最佳实践案例，比如电商行业、通信行业、金融行业等等。 73 | 74 | ## 6. 互联网应用运维标准框架 75 | 应用运维存在的最大价值就是服务业务，这样我们的工作也应该围绕着业务来开展。一个典型互联网业务的链条包括从研发到上线，上线之后聚集用户、营销，后面还有下线等。 76 | 77 | 它分为研发期和运营期两大周期，应用运维主要工作聚集在运营期中，但是在研发期中也有应用运维要做的事情。 78 | 79 | 互联网应用运维框架就是基于整个业务的时间线来设计的。当一个业务应用在研发期的时间，这时候产品和研发是研发人员的主要工作，但是应用运维也可以做高可用架构设计，我们从运维经验中沉淀下来的高可用性方案输出给研发，研发在研发周期中就把业务的架构设计得更合理。所以，应用运维的框架中就有这样一个高可用架构设计在这里。 80 | 81 | ![](http://7xl5e0.com1.z0.glb.clouddn.com/C1%200005.png) 82 | 83 | 图片地址：http://7xl5e0.com1.z0.glb.clouddn.com/C10005.png 84 | 85 | 当业务上线的时候，持续部署是应用运维另外一个重要的工作。部署完之后还是不够的，业务可能出现故障，要及时发现和处理，这个时候就要做可用性保障，包括备份、监控等等。 86 | 87 | 业务的下一个阶段是要拉用户，我们这个时候要帮助业务更好地吸引用户，我们要提供一些数据给到业务，可能业务需要看一些在线的运营数据、用户数据，就需要我们运维提供和搜集，同时我们自己也需要在运维中发现我们系统的问题，比如有没有BUG，有没有用户体验的问题。 88 | 89 | 一个应用在整个运营周期中，其实会碰到很多用户体验上的问题，比如用户用得不爽会流失，这个时候我们要做什么？我们要做用户体验优化，通过应用运维不断地发现运营过程中的用户体验问题，找到问题点，持续推动改进，让我们的应用可以使用户用得更爽，这样用户更愿意留在我们的应用中。 90 | 91 | 在运营过程中可能还有很多大的活动，比如电商的双11，所以还要有专项运营活动的支持。 92 | 93 | 同时，成本也是运维可以帮助业务做的很大价值的事情，在整个周期中都有有持续成本优化的职责。 94 | 95 | 最后，客户服务，它不一定是运维直接面对我们的最终用户服务，这个客户服务是应用运维所面临的内部客户和外部客户，我们怎么样和他们建立良好的关系，怎么和他们之间有更好的信息沟通。 96 | 97 | ## 7. 互联网应用运维能力成熟度模型 98 | 我们把框架进行展开，对框架里的每一个点，每一个点哪些能力维度，通过五个层级的方式评估这些能力维度中做得怎么样，这就是能力模型。 99 | 100 | ![](http://7xl5e0.com1.z0.glb.clouddn.com/C10006.png) 101 | 102 | 图片地址：http://7xl5e0.com1.z0.glb.clouddn.com/C10006.png 103 | 104 | 进一步把这些能力模型再展开，看看每一级中去给大家一些指导的思路，怎么样把这个能力模型从一级到五级逐步提升起来。 105 | 106 | 比如数据服务中，数据项管理从1级到4级怎么做等等，这些都有详细的描述。 107 | 应用运维工作组经过半年的努力，现在已经把应用运维框架的草案拿出来了，我们把人力模型的草案也输出了，我们把这些草案都开源出来，开放出来，让大家都能够阅读，一起来建设。 108 | 109 | ![](http://7xl5e0.com1.z0.glb.clouddn.com/C10007.png) 110 | 111 | 图片地址：http://7xl5e0.com1.z0.glb.clouddn.com/C10007.png 112 | 113 | 同时，我们很希望这些最佳实践案例能够大家一起来贡献，因为凭我们自己的力量没有办法把最佳实践案例都收集齐，大家一起把整个模型、框架、案例完善起来。 114 | 115 | 所以，后面希望更多的人和应用运维工作组一起，把应用运维建设成第一套可以实际落地指导运维工作的一套规范体系，大家一起把它建设得更加完善。谢谢大家！ 116 | 117 | ![](http://7xl5e0.com1.z0.glb.clouddn.com/C10008.png) 118 | 119 | 图片地址：http://7xl5e0.com1.z0.glb.clouddn.com/C10008.png 120 | 121 | ## 8. 标准的行业价值和意义 122 | 互联网应用运维框架及能力成熟度模型（本文）是我国仍至全世界第一个应用运维标准草案，其出现的意义重大，包括： 123 | 124 | - 总结国内外大中型互联网企业的先进运维经验，减少中小型互联网企业的重复建设； 125 | - 将互联网应用运维经验标准化，输出给传统企业，给传统企业互联网转型作为参考和指导； 126 | - 将运维是从繁杂的技术工作中解脱出来，提升运维对企业的贡献，协助运维成为企业的核心竞争力之一。 127 | 128 | ## 9. 标准的推广 129 | 互联网应用运维草案目前已经编辑就绪，目前的推广计划为： 130 | 131 | - 内测。限量邀请国内外资深运维从业者进行内部修正； 132 | - 宣讲。组织各种线上和线下沙龙，综合各方修改意见，进行宣传和完成； 133 | - 开源。发布本标准，并基于知识共享协议予以，允许更多的传播与修正。 134 | 135 | ## 10. 声明 136 | 本文编写过程中参考了国内外相关书籍，如有冒犯还请指出。 137 | 本文基于CC BY-NC-ND 3.0协议。 138 | 139 | 140 | 141 | 142 | 143 | 144 | 145 | 146 | 147 | 148 | 149 | 150 | 151 | 152 | 153 | 154 | -------------------------------------------------------------------------------- /Chapter 2 Data Service.md: -------------------------------------------------------------------------------- 1 | # 第二章 运营数据服务 2 | ### 本章起草人：刘栖桐（腾讯互娱运维负责人，智能运维提出方） 3 | 4 | ## 1. 整体框架 5 | ### 1.1 概述 6 | 运营数据服务是应用运维里面的核心服务之一，它是运维自动化和智能化的核心能力，也是使运维能扩展价值的重要能力。为实现这一能力，需要全面掌握应用运维的相关数据项，并通过对这些数据项的处理（采集-存储-统计/分析），使其可以用于监控和发现业务问题，进而帮助业务优化体验和性能等关键指标。 7 | 8 | 运营数据服务的服务对象包括运营、运维、研发、测试等几乎所有同运营相关的角色。 9 | 10 | ### 1.2 框架图 11 | 12 | ![](http://7xl5e0.com1.z0.glb.clouddn.com/c2%20001.jpg) 13 | 14 | 图片地址：http://7xl5e0.com1.z0.glb.clouddn.com/c2%20001.jpg 15 | 16 | ## 2. 最佳实践 17 | ### 2.1 数据项管理 18 | 数据服务的前提是需要清楚的知道哪些数据是有价值的，对这些数据项持续管理，同时还要建立数据项之间的关联关系，明确各数据项之间的相关性。数据项可以分为宏观和微观两类，例如单位时间内的“登录成功率”是宏观数据，而“单用户登录失败”则是微观数据，宏观数据可以用于发现问题和预测趋势，微观数据则可以帮助定位具体的问题点； 19 | 20 | #### 2.1.1 可管理级最佳实践 21 | ##### 2.1.1.1 概述 22 | 保证运维质量是运维的核心价值之一，运维质量相关数据项首先需要被识别和管理起来，例如“登录成功率”、“点击成功率”、“支付成功率”等等； 23 | 24 | ##### 2.1.1.2 最佳实践 25 | 26 | - 首先梳理出业务的逻辑，建议可以以用户在业务中的行为为主线进行梳理，最后形成用户行为的多条逻辑线，例如登录、购买等等 27 | - 按照上述的用户行为逻辑线，识别相关数据，根据重要程度不同可以分为关键逻辑和次要逻辑，例如登录逻辑就是关键数据项之一。 28 | - 建立数据项管理的流程来保证数据项的完整性和正确性 29 | - 建立数据项管理库对数据项进行记录和维护，要求要方便维护管理 30 | - 根据自身条件的不同，可以优先将宏观和关键的数据项管理起来（目的是先保证能发现业务的关键问题），再逐渐扩展； 31 | 32 | #### 2.1.2 已定义级最佳实践 33 | ##### 2.1.2.1 概述 34 | 运维除了关注基础运维质量之外，也有责任帮助业务进一步掌控用户体验的状态，因此我们需要具备对用户体验数据项的识别和管理能力 35 | 36 | ##### 2.1.2.2 最佳实践 37 | - 可以从用户行为逻辑线出发进一步梳理其中用户体验相关的数据项，例如登录逻辑中的“用户登录等待时长”等 38 | - 数据项管理的流程覆盖到用户体验相关的数据项 39 | 40 | #### 2.1.3 量化管理级最佳实践 41 | ##### 2.1.3.1 概述 42 | 在一个业务以及不同的业务之间，数据项之间存在着关联性，例如在游戏业务中，“登录成功率”和“同时在线用户数”之间存在明显的关联。而在电商业务中，“支付成功率”和“交易笔数”、“单位时间交易金额”之间也存在关联。将这些数据项之间的关联性识别并管理起来，能让我们更容易的进行问题分析、故障定位和趋势预测等进一步的工作 43 | 44 | ##### 2.1.3.2 最佳实践 45 | - 建立数据项相关性的视图，识别哪些数据项具有相关性，并明确其相关性系数 46 | - 建立数据项相关性管理流程，因为随着业务逻辑的变化，数据项的相关性可能会发生变化 47 | - 数据项管理库应该能够储存和维护数据项相关性的信息，并具备较好的可维护性 48 | 49 | ### 2.1.4 优化管理级最佳实践 50 | #### 2.1.4.1 概述 51 | 数据项以及数据项相关性的维护可以不依赖人工，可自动识别和自动维护 52 | 53 | #### 2.1.4.2 最佳实践 54 | （暂无） 55 | 56 | === 57 | 58 | ### 2.2 数据管理 59 | 60 | 识别出数据项之后，还需要具备将这些数据采集并管理起来的能力，以供进一步使用。数据管理包含了几个维度：数据源管理、数据采集和清洗、数据传输、数据存储、数据生命周期管理。保证数据的完整性和采传效率是数据管理的关键能力。 61 | 62 | #### 2.2.1 可管理级最佳实践 63 | ##### 2.2.1.1 概述 64 | 业务运行质量相关的数据能够找到明确的数据源，并能被有效的采集、传输和存储，使这部分数据具备用于后续数据分析和利用的条件。但数据源未实现标准化，可能存在采集效率不高和后续维护成本高的问题；采集到数据可能没有集中存储，因此对数据进行关联分析的难度较大。在本阶段，数据管理的职责已经被明确定义出来，但负责数据管理的人可能是由运维或其他角色兼任的，没有分化出专职的人员。 65 | 66 | ##### 2.2.1.2 最佳实践 67 | - 根据2.1.1中所确定的数据项明确相应的数据源 68 | - 理解数据源的数据结构，根据数据源的格式确定相应的采集方案，包含要素为：采集方式（例如脚本采集、接口上报等），采集频率（根据数据项需求确定，同时需要考虑对系统的性能影响） 69 | - 采集的数据可能进行初步清洗，也可能没有，本阶段的清洗一般是很简单和初级的，只对明显的脏数据进行过滤，清洗规则没有标准化。 70 | - 数据采集过程中会涉及数据传输的问题，可以根据情况选择传输方式，传输时要注意有限速措施，避免占用资源过高影响服务器性能或网络性能。 71 | - 采集到的数据可能是分散存储或集中存储的，在本阶段，数据量可能不会太大，对存储结构和存储组件的要求不高，没有标准化，有较多的选择，但需要满足数据完整性和存储性能的要求。 72 | - 数据的安全性有保证，有严格的权限管理机制来保护数据不被非法访问或获取。 73 | 74 | #### 2.2.2 已定义级最佳实践 75 | ##### 2.2.2.1 概述 76 | 对运维质量和用户体验相关的数据都能够明确数据源，并能被有效的采集、传输和存储，使这部分数据具备用于后续数据分析和利用的条件。在本级的阶段，随着数据项的增加（纳入了用户体验数据的采集）和数据量的增大，对数据源的管理和采集、清洗、传输和存储方案都提出了更高的要求，因此在这些领域，方案都实现了标准化，但对上述方案的管理可能还需要人工介入。在本阶段，数据管理工作量加大，可能需要专职人员负责。 77 | 78 | ##### 2.2.2.2 最佳实践 79 | - 根据2.1.2中所确定的数据项明确相应的数据源 80 | - 对数据源进行标准化，同数据源的owner（例如开发方）明确数据输出的标准，为后续环节的标准化打下基础。 81 | - 建立数据源的采集、清洗、传输、存储的标准并落地。例如，同类数据的采集方式和采集频率保持统一标准等。 82 | - 数据实现集中存储，以便于交叉汇总和关联分析。 83 | - 因为数据源较多且数据量较大，所以需要有高性能的采集、传输、存储的方案来保障数据的完整性、一致性和时效性。此点对于进一步利用数据意义重大。 84 | 85 | #### 2.2.3 量化管理级最佳实践 86 | ##### 2.2.3.1 概述 87 | 88 | 形成了数据管理的集中管控体系，该体系能够动态的管理和控制数据源、采集渠道和集中存储，且具备图形化的管理界面，易于数据管理人员遂行管理职责。随着数据源和数据量的进一步增大，要求数据管理方案具备对海量数据的管理能力 89 | 90 | ##### 2.2.3.2 最佳实践 91 | - 动态管理的核心思想是自动感知、自动修复，目的是最大限度的保证数据的完整性、一致性和时效性，同时降低维护成本。数据管控体系的动态管理能力能力包含了监控、故障自愈、配置修正、自动扩缩容等要素。例如要能自动感知数据源的变化并做出相应的反应，当数据源的数据量发生变化时能及时自动扩容传输通道和存储。 92 | - 图形化管理界面能够实时展示数据管理各节点的状态，并能帮助数据管理人员容易的修改各配置项。当出现问题无法自动修复时，也能帮助数据管理人员及时定位到问题点并给出修复建议。 93 | - 要具备海量的数据采集、传输、清洗和存储能力，能够保证数据的完整性、一致性和时效性。 94 | 95 | #### 2.2.4 优化管理级最佳实践 96 | （暂无） 97 | 98 | === 99 | ### 2.3 数据呈现 100 | #### 2.3.1 概述 101 | 数据呈现是数据服务的交付界面，统计的数据结果需要以某种方式呈现出来，供服务对象（运营、开发、测试等）查看；数据呈现方式很重要，好的呈现可以帮助服务对象一目了然的了解运营状况。 102 | 103 | #### 2.3.2 可管理级最佳实践 104 | #### 2.3.2.1 概述 105 | 通过定期报告的方式让服务对象可以大致了解运维质量的主要数据，呈现方式要便于阅读并固化下来，但该报告可能需要人工或部分人工统计生成且时效性不强。 106 | 107 | #### 2.3.2.2 最佳实践 108 | - 根据客户需求制定报告内容，应包含主要的运维质量数据，例如可用性、容量状况、故障状况、风险问题等。根据对象的不同，报告内容应该有针对性，所突出的重点有所不同。 109 | - 确定报告格式，原则是便于阅读、重点突出。如果要采用图表展示，则应避免图表数据太繁杂，切忌大量数据的堆砌和罗列。阅读性太差的报告无法传递需传递的信息，长期下去容易流于形式。 110 | - 报告发送周期根据服务对象的不同可以有日报、周报、月报等，因为需要人工整理，所以确定报告周期时需要考虑时效性和人力投入成本的平衡。 111 | 112 | #### 2.3.3 已定义级最佳实践 113 | ##### 2.3.3.1 概述 114 | 除运维质量类数据之外，用户体验类数据也可被呈现（在部分公司，还会包含营销类数据，这取决于公司内部的分工要求是否由应用运维来负责提供此类数据），而数据呈现方式也进一步改进，有固定的页面展示，数据的时效性增强，不受报告周期的限制；同时，为了满足不同服务对象的需求，周期报告仍可保留，改为订阅及自动发送的方式。 115 | 116 | ##### 2.3.3.2 最佳实践 117 | 118 | - 明确页面上需展示的数据以及呈现方式，建议可以根据服务对象的不同呈现不同的数据（这要求页面能识别当前阅读者的对象属性）； 119 | - 为保障数据的安全性，页面必须具备用户权限管理的能力，数据按重要程度有分级机制，用户权限和数据分级有匹配关系 120 | - 页面要具备自动刷新的功能 121 | - 要有数据报告订阅功能 122 | - 页面有监控机制，如果页面有异常可及时发现 123 | 124 | #### 2.3.4 量化管理级最佳实践 125 | ##### 2.3.4.1 概述 126 | 本级要求数据的呈现不再按传统的分类（如可用性、故障等），而是将各类数据关联起来，以场景化的方式呈现，例如基于“一次新版本发布”的场景关联呈现各类数据，这要求各数据源之间必须明确关联关系（2.1.3中要求的能力），并形成关联模型。此外，数据系统可给服务对象建议的报告模版，也允许服务对象自定义数据展示方式。 127 | 128 | #### 2.3.4.2 最佳实践 129 | - 明确业务中的主要运营场景，并按照重要程度分级； 130 | - 根据运营场景明确各场景的数据项，引入2.1.3中的数据项关联关系，并建立数据关联模型，关联模型应该包含多种策略，以保证其准确性； 131 | - 根据场景和数据关联模型来设计数据呈现方式； 132 | - 整套数据呈现的框架是可配置的，新的数据项和关联关系很容易被配置进去； 133 | 134 | #### 2.3.5 优化管理级最佳实践 135 | ##### 2.3.5.1 概述 136 | 数据中的异常点能在页面上被自动识别出来并自动关联到相应的事件。新数据甚至可以被自动识别并自动给出其建议的呈现方式（如果有相应策略的话）。本级对自动化的要求较高，甚至要求数据系统对业务有一定的理解（可以认为具备了一定的智能） 137 | 最佳实践 138 | 139 | ##### 2.3.5.2 最佳实践 140 | （暂无） 141 | 142 | === 143 | 144 | ### 2.4 数据监控/预测 145 | #### 2.4.1 概述 146 | 运维收集了大量的数据，无异于一座宝库。仅在运维领域，这些数据就可以用于监控和故障自愈、业务趋势分析、用户体验优化等；但这些数据不会主动说话，要将这些数据利用起来，需要有相应的能力。 147 | 148 | ![](http://7xl5e0.com1.z0.glb.clouddn.com/c2%20002.png) 149 | 150 | 图片地址：http://7xl5e0.com1.z0.glb.clouddn.com/c2%20002.png 151 | 152 | #### 2.4.2 可管理级最佳实践 153 | ##### 2.4.2.1 概述 154 | 运维质量（即可用性）相关的数据能被监控，本级的主要要求是将数据用于业务可用性监控，达到本级的能力要求基本可以发现某个单项可用性指标的异常，但没有关联分析，误报率可能较高。例如，通过游戏PCU监控可以发现游戏PCU陡降的问题，但无法自动发现引起PCU陡降的故障点。再例如，通过对ping探测可以发现某服务器宕机的故障，但不能自动发现该宕机故障对于业务其他指标有何影响。具体监控指标可参看“应用运维规范之监控能力模型”的建议。 155 | 156 | ##### 2.4.2.2 最佳实践 157 | 158 | - 首先需明确监控点并关联相应的数据； 159 | - 针对各数据设定监控方式，可以是阈值监控，也可以是趋势监控。以上监控方式应该是可配置的，便于维护，可以随时修改、打开、关闭； 160 | - 监控之后要进一步跟告警对接起来，告警渠道要保证通畅和及时； 161 | 162 | #### 2.4.3 已定义级最佳实践 163 | ##### 2.4.3.1 概述 164 | 除监控可用性相关的异常点之外，也能监控用户体验的异常。这要求将监控策略覆盖到用户体验数据上去，因为数据维度的增加，对于监控策略和监控模型也提出了更高的要求； 165 | 166 | ##### 2.4.3.2 最佳实践 167 | - 明确用户体验监控点并关联相应的数据 168 | - 针对各数据设定监控方式，因为数据复杂度增加，所以需要完善监控模型，使监控更精准 169 | 170 | #### 2.4.4 量化管理级最佳实践 171 | ##### 2.4.4.1 概述 172 | 本级要求除了能及时发现故障异常之外，还要能通过数据间的关联关系、关联模型和智能分析决策自动定位问题点，定位成功率超过60%；并具备通过数据趋势预测风险的能力； 173 | 174 | ##### 2.4.4.2 最佳实践 175 | 176 | - 通过数据项的关联关系（见2.1.3章节要求的能力）和关联模型（见2.3.4章节要求的能力）设置分析策略，最初策略可能比较简单，随着策略的增加，使其决策更加智能；策略中间可能有较多的逻辑树判断，例如A组件的某个指标下降，可能关联到B组件，而B组件又跟C组件有关联，可以根据此逻辑链找到问题点； 177 | - 定位到问题点之后，系统应该能根据策略判断下一步应该如何动作，完成动作之后应该再次探测问题是否消除，通过这样的方式反复多次直到问题解决。在这个过程中，当策略不成熟时，可以设置每一步决策均需人工审核后才能执行，以保证安全。但最终目的是分析和决策可以自动执行，不需人工干预 178 | - 趋势预测的原理同上一点类似，也需要不断验证和修正分析模型 179 | - 以上各项功能应该统一在一套平台内，所有配置项可以灵活设置，方便各种策略的调整； 180 | - 因为系统具备执行自主权限，为了保证安全，除了系统层面的安全监控和严格的权限控制之外，还需要设置安全阈值，即当系统执行破坏后果严重的操作时必须能及时发现和具备人工干预能力； 181 | 182 | 183 | #### 2.4.5 优化管理级最佳实践 184 | ##### 2.4.5.1 概述 185 | 数据智能分析决策的能力具备自我学习能力，能够通过实际环境的变化自我修正其分析和决策策略，具备学习能力。 186 | 187 | === 188 | ### 2.5 业务优化 189 | #### 2.5.1 概述 190 | 在2.4章结中，通过对数据的分析和预测，我们可以及时发现业务的异常甚至自动恢复，本节要求我们利用此项能力持续帮助业务优化，例如，我们不光可以发现异常并恢复，我们还要深挖异常背后的原因并持续推动业务进行优化，直到问题被根本性的解决。 191 | 192 | #### 2.5.2 可管理级最佳实践 193 | ##### 2.5.2.1 概述 194 | 运维质量相关的数据异常有被标识出来并持续关注而不止是当时解决就结束。有流程来跟进这一过程，例如问题单流程。 195 | 196 | ##### 2.5.2.2最佳实践 197 | 198 | - 有问题单流程并形成闭环 199 | - 有相应的管理和考核机制来保证流程的持续执行 200 | - 流程可能需要人工跟进 201 | 202 | #### 2.5.3 已定义级最佳实践 203 | ##### 2.5.3.1 概述 204 | 除运维质量类数据外，用户体验的异常问题也被流程覆盖进来持续跟进 205 | 206 | ##### 2.5.3.2 最佳实践 207 | - 增加问题单的问题类别和覆盖范围 208 | - 部分问题单可以实现自动转入，而不需要人工录入 209 | 210 | #### 2.5.4 量化管理级最佳实践 211 | ##### 2.5.4.1 概述 212 | 数据成为业务优化的主要驱动力，这里的数据不仅仅是异常数据，例如，游戏业务中，玩家接入延时200ms也可以正常游戏，但我们认为如果提升到150ms可以使玩家获得更好的体验，从而增加玩家的留存率。受此驱动也可以发起一个优化流程来闭环此次优化； 213 | 214 | ##### 2.5.4.2 最佳实践 215 | 216 | - 要实现此目标必须依赖2.3.3的数据关联模型，明确的关联模型能让我们清楚各种数据之前的影响关系，从而评估某个数据是不是需要优化 217 | - 业务优化的流程有系统支持，基本实现自动录入且闭环 218 | - 优化的过程能被持续跟踪，每一步优化之后的数据可以明确呈现出来 219 | 220 | #### 2.5.5 优化管理级最佳实践 221 | ##### 2.5.5.1 概述 222 | 相对上一级的进步在于本级的系统可以主动发现系统中潜在的优化点并智能决策是否优化，也会自动跟进优化的结果，具备一定的智能。 223 | 224 | ##### 2.5.5.2 最佳实践 225 | （暂无） 226 | 227 | 228 | 229 | 230 | 231 | 232 | 233 | 234 | 235 | 236 | 237 | 238 | 239 | 240 | 241 | -------------------------------------------------------------------------------- /Chapter 3 Continuous Delivery Service.md: -------------------------------------------------------------------------------- 1 | #第三章 持续交付服务 2 | 3 | ### 本章起草人：王津银 （优维科技创始人，精益运维提出者） 4 | 5 | ## 1. 整体框架 6 | ### 1.1 概述 7 | 持续交付是应用运维里面的一个核心服务，它是DevOps的自动化能力的核心，为实现这一能力，需要全面的研发／测试／运维管理能力。本规范就是从构成这一服务的能力要素出发，逐一分解行业的最佳实践，从而为大家提供更多的参考。 8 | 9 | ### 1.2 框架图 10 | 基于持续交付的服务能力，分解如下表： 11 | 12 | ![](http://7xl5e0.com1.z0.glb.clouddn.com/C3%20001.jpg) 13 | 14 | 图片地址：http://7xl5e0.com1.z0.glb.clouddn.com/C3%20001.jpg 15 | 16 | ## 2. 最佳实践 17 | ### 2.1 持续管理与集成 18 | 19 | ![](http://7xl5e0.com1.z0.glb.clouddn.com/C3%20002.jpg) 20 | 21 | 图片地址：http://7xl5e0.com1.z0.glb.clouddn.com/C3%20002.jpg 22 | 23 | #### 2.1.1 可管理级最佳实践 24 | 25 | ##### 2.1.1.1 概述 26 | 定期的自动化构建与测试。任意一个构建都可以自动化过程重新从源版本控制库上构建。建立了版本化的交付物仓库（Aritifict Repo），对构建结果进行统一管理。 27 | 28 | ##### 2.1.1.2 最佳实践 29 | 30 | - 源代码是集中管理，类似于svn或者git，分布式的版本控制工具对提高研发效率会有帮助. 31 | - 在项目中建使用标准而统一的编码及构建规范，比如说源代码的目录结构，代码编译文件的输出位置等等，确保后续的构建过程是统一化。 32 | - 至少执行每日的自动化构建和测试，提前发现代码的构建问题和一些版本问题（单元测试／验收测试／性能测试等等），该工作可在非工作时间进行，便于提前发现问题。 33 | - 构建过程是自动化的，自动化构建的能力可以随时从源代码的主干或者分支上进行，做到版本可用。 34 | - 版本构建完成之后，构建结果放置到统一的交付物仓库 （Aritifact Repo）中，这个可以和源代码分离管理。类似一个分布式文件系统中集中存放。 35 | 36 | #### 2.1.2 已定义级最佳实践 37 | ##### 2.1.2.1 概述 38 | 能够做到源代码仓库的每一次修改都可以触发进行自动化构建和测试。能够很好的管理项目的外部依赖。能够在不同项目中很好的重用脚本和工具。 39 | 40 | ##### 2.1.2.2 最佳实践 41 | 42 | - 代码提交时可以自动触发构建过程 43 | - 代码的依赖关系被很好的管理，从源头上管理了源代码版本和依赖之间的关系 44 | - 自动化构建和测试的脚本与工具都是可以重复使用的 45 | 46 | #### 2.1.3 量化管理级最佳实践 47 | ##### 2.1.3.1 概述 48 | 构建度量指标的收集，提供可视化工具，在资源和流程确保构建失败时能及时采取行动修复，以免构建长时间失败。 49 | 50 | ##### 2.1.3.2 最佳实践 51 | 52 | - 实时的可视化构建展示平台 53 | - 建立按照项目的自动化每日构建和实时构建平台 54 | - 建立构建的度量指标，比如说构建成功率／自动化测试通过率／代码覆盖率等等 55 | 56 | #### 2.1.4 优化管理级最佳实践 57 | ##### 2.1.4.1 概述 58 | 团队定期碰头，讨论自动化构建过程中遇到的问题。 利用新收集的反馈信息，脚本、工具和可视化平台来解决问题。 59 | 60 | ##### 2.1.4.2 最佳实践 61 | （暂无） 62 | 63 | === 64 | ### 2.2 环境管理 65 | #### 2.2.1可管理级最佳实践 66 | ##### 2.2.1.1 概述 67 | 对应用涉及到的环境有清晰的职责定义和owner定义，并具有在线可视化管理能力。 68 | 69 | ##### 2.2.1.2 最佳实践之环境的清晰定义和职责管理 70 | 对于持续交付过程来说，一次完整的持续发布需要经过开发／测试／预发布／生产等多种环境，对于每一个环境的管理来说，需要有清晰的职责定义，从而确保环境的有效性。一个有效性的环境对于产品的最终质量有很好的控制作用，同时也能避免这个环境不一致带来的奇怪问题。常见的分类如下： 71 | 72 | ![](http://7xl5e0.com1.z0.glb.clouddn.com/C3%20003.jpg) 73 | 74 | 图片地址：http://7xl5e0.com1.z0.glb.clouddn.com/C3%20003.jpg 75 | 76 | - 开发环境。供开发者使用的自测环境。 77 | - 测试环境。供测试人员测试验证的环境，无论是自动化测试还是手工测试环境，但在这个环境中有多个版本同时在并行测试。 78 | - 联调环境。在联调环境中，只有一个待发布版本的验证调试，同时依赖版本也提供了一个独立环境，避免版本测试之间的干扰。 79 | - 预发布环境。也称体验环境，这个环境是对部分用户或者内部用户试用的环境，目的是为了确保功能是否正常，算是一个灰度过程的一部分。 80 | - 生产环境。也称production环境，这个环境是直接面向最终用户的环境。 81 | 82 | 对以上环境来说，每个环境的管理都需要确定如下管理职责： 83 | 84 | - 建立一致的环境管理规范，从OS级／应用级／发布过程级别等维度建立规范要求，特别是测试、预发布及生产环境 85 | - 清晰界定环境管理的角色要求，比如说测试/预发布环境测试人员管理、生产环境运维管理 86 | - 测试人员需要有多测试环境的管理能力，如测试、预发布和联调环境等等 87 | - 环境的管理最终需要通过持续部署平台来固化 88 | 89 | ##### 2.2.1.3 最佳实践之环境的可视化管理 90 | 必须建立环境的标准化管理，把以上的规范要求和职责管理要求全部固化到平台中。在平台中很容易建立如上的管理过程，把持续测试和持续部署的过程打通，让整个过程可视化。如下： 91 | 92 | ![](http://7xl5e0.com1.z0.glb.clouddn.com/C3%20004.jpg) 93 | 94 | 图片地址：http://7xl5e0.com1.z0.glb.clouddn.com/C3%20004.jpg 95 | 96 | #### 2.2.2 已定义级最佳实践 97 | ##### 2.2.2.1 概述 98 | 开发／测试／生产甚至其它各种环境的标准化和规范化能力是一致的。 99 | 建立了标准的环境管理过程。 100 | 101 | ##### 2.2.2.2 最佳实践之标准化和规范化 102 | - 环境的操作系统版本必须是统一的，比如说操作系统的版本和内核版本是一致的 103 | - OS级别的配置是一致的，最好的情况是公司级是一致的。考虑到业务之间的差异可以做到和应用关联（配置管理）。 104 | - 所有的应用部署相关信息是标准化的，比如说应用包的结构，应用包部署的目录，监控方式，日志清理，应用运行属主等等 105 | 106 | ##### 2.2.2.3 最佳实践之环境管理过程 107 | - 环境的创建过程是一致的，都是使用持续部署工具创建的，注意要确保所有环境的创建过程是一致的。 108 | - 所有环境的随着版本的升级和变更过程是一致的，是由平台来完成，而非人为完成的。 109 | - 环境的管理过程应该以一个自动化平台为基础，这个平台能覆盖配置管理／应用包发布和持续交付完整自动化交付流等场景。 110 | 111 | #### 2.2.3 量化管理级最佳实践 112 | ##### 2.2.3.1 概述 113 | 所有环境的管理都纳入了运维监控能力范围，提供了容量／可用性／一致性等多种监控手段。 114 | 115 | ##### 2.2.3.2 最佳实践之运维监控 116 | - 建立以应用为维度的端到端的数据采集体系，完整的指标体系是后续的监控和分析平台的基础。如下图： 117 | 118 | ![](http://7xl5e0.com1.z0.glb.clouddn.com/C3%20005.jpg) 119 | 120 | 图片地址：http://7xl5e0.com1.z0.glb.clouddn.com/C3%20005.jpg 121 | 122 | - 越接近生产环境，越看重以应用为维度的持续反馈和容量及一致性管理能力，统称应用的状态管理。 123 | - 平台需要能过实时生成应用的状态报告，里面包括变更信息／告警信息／状态信息／容量信息／一致性状态等等。 124 | - 考虑到环境的场景和服务的对象不同，在开发环境／测试环境，可以降低对监控／容量管理的要求。 125 | 126 | #### 2.2.4 优化管理级最佳实践 127 | （暂无） 128 | 129 | 130 | === 131 | 132 | ### 2.3 部署管理 133 | #### 2.3.1 可管理级最佳实践 134 | ##### 2.3.1.1 概述 135 | 自动化部署到几种环境中。新环境的创建成本非常低。所有的配置不和应用包关联，做到版本控制且分离管理。建立了全面的部署工具集，部署行为可以依赖部署工具集完成。 136 | 137 | ##### 2.3.1.2 最佳实践 138 | - 建立端到端的部署工具集，基本的分类如下： 139 | 140 | ![](http://7xl5e0.com1.z0.glb.clouddn.com/C3%20006.jpg) 141 | 142 | 图片地址：http://7xl5e0.com1.z0.glb.clouddn.com/C3%20006.jpg 143 | 144 | - 作业交付层是配置管理层的工具和作业能力，从作业对象来说，是针对OS和外部服务化系统对象。前者等同于配置管理，后者去驱动服务系统变更，比如说mysql管理平台。 145 | - 应用交付层是考虑到应用包的变更场景，提供的一个自动化场景。但是这个场景在巨石架构和微服务架构下特征不一样。巨石架构下，版本升级过程无法原子化，依赖很多外部过程来完成；而微服务架构下，版本升级过程可以原子化，不依赖关联的外部过程。 146 | - 业务交付层是一种复杂化的场景化封装的调度流来完成的，比如说巨石架构下的版本升级过程以及业务迁移／扩容／缩容过程等等，完全是场景化驱动的。 147 | - 应用的配置管理能独立和应用的集群建立关联管理，比如说开发／测试／生产集群等等，配置需要和他们建立维度关联，以方便清晰的管理。 148 | - 应用包的配置管理一定要放到包的外部进行管理，最好是放到环境变量中或者转化成KV配置项管理模式，配置的管理成本很低。 149 | - 把配置当成核心的应用信息，需要建立版本管理能力，版本管理／基线管理等等。 150 | 151 | #### 2.3.2 已定义级最佳实践 152 | ##### 2.3.2.1 概述 153 | 软件部署使用全自动、自助服务且一键化得过程，并使用相同的过程向各种环境部署。部署工具集可以通过统一而标准的调度流来统一调度，完成新环境部署。 154 | 155 | ##### 2.3.2.2 最佳实践 156 | 157 | - 以应用为维度建立统一的CMDB配置管理和工具变更过程流，通过CMDB配置管理来驱动变更流。 158 | - 工具集是统一Appstore模式管理的，并对工具集合建立了版本管理，确保工具的历史是可以回溯的。 159 | - 封装了统一的调度引擎，这个引擎能过驱动实时的交付流，能够驱动作业能力和持续部署的能力。 160 | 161 | #### 2.3.3 量化管理级最佳实践 162 | ##### 2.3.3.1 概述 163 | 精心计划的部署管理，对发布和回滚流程进行测试。对于变更的对象要有强制校验的能力，避免变更过程异常。 164 | 165 | ##### 2.3.3.2 最佳实践 166 | 167 | - 建立标准的部署过程分类，不同的部署过程有不同的流程要求 168 | 169 | ![](http://7xl5e0.com1.z0.glb.clouddn.com/C3%20007.jpg) 170 | 171 | 图片地址：http://7xl5e0.com1.z0.glb.clouddn.com/C3%20007.jpg 172 | 173 | - 建立正常版本的统一部署时间窗，集中规范管理变更过程，比如说周二和周四下午放开版本管理。 174 | - 对正常版本来说，建立一个部署流程，确保部署过程是精心组织的。 175 | - 对于版本升级来说，可以使用灰度的能力。灰度又分机器级灰度（运维部署工具可以完成）和业务级别灰度（特性灰度／内容灰度等等）。 176 | - 在运维部署平台内，需要有快速回滚的能力。对于巨石架构来说是一个挑战，因此需要有回滚的测试过程。 177 | - 变更的过程需要有强制的检验能力，版本级检验能力，文件级一致性对比能力，实时的变更状态持续反馈能力等等。 178 | 179 | 180 | #### 2.3.4 优化管理级最佳实践 181 | （暂无） 182 | 183 | === 184 | ### 2.4 发布流程管理 185 | #### 2.4.1 可管理级最佳实践 186 | ##### 2.4.1.1 概述 187 | 发布流程能满足不频繁的执行需要，虽然过程可能繁琐，但是能够可靠的执行。 188 | 189 | ##### 2.4.1.2 最佳实践 190 | 191 | - 每次发布的过程都是研发／测试和运维深度参与的过程，而非运维独立完成。 192 | - 测试、研发部门可以为运维输出详细、可靠的部署文档，执行过程复杂而繁琐。 193 | - 组织建立了一个标准的发布流程，发布流程清晰的定义了职责关系 194 | 195 | #### 2.4.2 已定义级最佳实践 196 | ##### 2.4.2.1 概述 197 | 定义并执行变更管理和审批过程，相关的变更过程是明确而具体的，同时有明确的回滚方案。 198 | 199 | ##### 2.4.2.2 最佳实践 200 | - 根据发布版本的不同特性，建立了标准的变更和审批控制流程 201 | - 测试已经作为发布过程被很好的执行，甚至是安全也已经被很好的执行 202 | - 在发布之前，对应用程序的性能程序有明确的数据，并且根据业务容量的变化，有自己的临时变更预案 203 | - 发布的灰度和回滚已经有了明确的预案 204 | 205 | #### 2.4.3 量化管理级最佳实践 206 | ##### 2.4.3.1 概述 207 | 环境与应用程序的健康性得到监控，并有前瞻性管理；变更前置时间得到关注和监控。对于变更的对象要有强制校验的能力，避免变更过程异常。 208 | 209 | ##### 2.4.3.2 最佳实践 210 | 211 | - 运维立体化监控系统对应用的环境和程序的健康性有很全面的监控，并能够根据应用生成应用性能采样报告。 212 | - 在发布之前，版本发布对业务容量的影响做了全面预估，并提前做了相应的资源准备。 213 | - 变更的过程是依赖持续交付系统的，整个变更过程和时间是能得到有效控制的。 214 | - 变革的过程是使用平台来固化的，整个变更过程没有被异化的可能。 215 | - 变更完成之后能够从对象本身（版本／文件一致性对比）和对象状态两个维度来描述变更的结果，避免变更过程异常。 216 | 217 | #### 2.4.4 优化管理级最佳实践 218 | ##### 2.4.4.1 概述 219 | 运营和交付团队定期沟通来管理风险，缩短循环周期。 220 | 221 | ##### 2.4.4.2 最佳实践 222 | （暂无） 223 | 224 | === 225 | 226 | ### 2.5 测试管理 227 | #### 2.5.1 可管理级最佳实践 228 | ##### 2.5.1.1 概述 229 | 自动化测试是用户故事开发流程输出的一部分。测试行为终止在测试环境，属于面向研发过程的服务质量测试。 230 | 231 | ##### 2.5.1.2 最佳实践 232 | 233 | - 遵循传统的测试方法论，测试是对研发质量的保证，核心的能力是确保研发程序是否有存在bug，对业务需求的满足情况。 234 | - 测试作用能力更多的是在测试环境，没有把测试能力延伸到更多的环境，比如说预发布／生产环境。 235 | - 建立测试驱动研发的敏捷开发文化，能过把测试用例作为用户故事的一部分，从而确保后续测试过程效率和质量。 236 | 237 | #### 2.5.2 已定义级最佳实践 238 | ##### 2.5.2.1 概述 239 | 自动化的单元测试和验收测试，验收测试由专门的测试人员开发。测试是开发过程一部分。测试行为延伸到运维生产环境，完成主动性测试，面向用户的服务质量测试。 240 | 241 | ##### 2.5.2.2 最佳实践 242 | 243 | - 建立明确的单元测试文化，把单元测试作为研发规范过程的一个核心度量。建立单元测试的红黑榜，对好的团队进行奖励，对差的团队提出改进要求。 244 | - 把验收测试做为持续集成的一部分，由测试人员建立验收测试的标准。 245 | - 和测试团队一起提炼可测试性的标准，把可测试性前置到开发过程中，降低后期的测试过程的成本。 246 | - 测试的能力可以延续到线上环境，生产环境需要有测试数据和生产数据的隔离能力。 247 | - 线上的自动化测试结果要实时的保留下来，供业务可用性监控和分析使用。 248 | - 根据自动化测试生成的业务可用性报表可以作为业务可用性的一个重要参考，驱动DevOps持续优化。 249 | - 测试内容分级也属于测试管理挺重要的一部分,比如聚焦在核心流程 。对于互联网产品的大量分支更多是研发自测或垂直合作测试团队测试, 
测试制定一定的标准去把控授权出去测试模块的质量。 
 250 | 251 | #### 2.5.3 量化管理级最佳实践 252 | ##### 2.5.3.1 概述 253 | 质量度量和趋势跟踪。对于非功能需求进行了定义和度量。 254 | 255 | ##### 2.5.3.2 最佳实践 256 | - 测试和运维一起开发和使用质量度量单/多指标体系，获取实时的质量指标状态，指标的多与少可以根据业务的具体重要情况来决定。 257 | - 对所有的产品和业务的度量标准建议遵循统一一套标准，这样有利于能力对比。 258 | - 质量的度量指标有业务可用性／产品满意度／用户体验等等。 259 | - 业务可用性可以通过可追踪的事件系统数据或者自动化测试线上模拟系统生成。 260 | - 产品满意度可以通过产品论坛或者appstore的评价情况来分析得出或者通过客服渠道的投诉情况计算得出。 261 | - 用户体验是延时和错误的综合性分析中得出，前提是必须建立这两个数据的采集／处理／分析体系。 262 | - 测试还可以提供一些非功能性的度量指标，比如说服务／接口性能，服务的依赖复杂度等等，方便后续的运维管理。 263 | - 建立测试管理自身的度量,比如测试团队的漏测严重/ 致命bug数、缺陷有效率等。 264 | 265 | #### 2.5.4 优化管理级最佳实践 266 | （暂无） 267 | 268 | ### 2.6 数据管理 269 | #### 2.6.1 可管理级最佳实践 270 | ##### 2.6.1.1 概述 271 | 对数据库的变更使用自动化脚本完成，而这些脚本与应用的版本相对应 272 | 273 | ##### 2.6.1.2最佳实践 274 | - 数据库变更的脚本根据应用发布的版本做了对应的管理 275 | - 数据库的变更脚本也需要和应用的构建库统一集中管理，方便回滚 276 | 277 | #### 2.6.2 已定义级最佳实践 278 | ##### 2.6.2.1概述 279 | 数据库变更作为部署流程的一部分自动执行。 280 | 281 | ##### 2.6.2.2 最佳实践 282 | 283 | - 数据库服务作为后台服务，应看作应用的附加资源进行管理 284 | - 数据库变更可以分解成两种变更场景，一种是随应用变更而变更的场景；另外一种是数据库独立变更的场景。 285 | - 随应用变更而变更的场景是一种关联变更场景，可以做作为部署流的一部分自动化执行。 286 | - 数据库独立变更的场景，比如说索引变更等等，此时可以作为数据库变更服务独立执行 287 | 288 | #### 2.6.3 量化管理级最佳实践 289 | ##### 2.6.3.1 概述 290 | 每次部署都进行数据库的升级和回滚测试。对数据库进行监控和优化。 291 | 292 | ##### 2.6.3.2 最佳实践 293 | 294 | - 数据变更是重要的变更，确保升级过程可以回滚，需要对数据库变更场景进行分类 295 | - 数据不变，业务改变。这种是最简单的场景，只要在前面加个nginx做分流即可 296 | - 数据结构不变，取值变化，新的取值对应新的业务。 297 | 298 | >例如：假设有一个订单业务，订单类型分为1-手机充值，2-淘宝实物，3-机票，现在新增一种4-酒店类型这种也比较简单，前提是要求原有的老代码健壮性比较强，老系统取到新数据，只要不报错，直接忽略即可；新代码读取新的取值进行业务逻辑处理即可 299 | 300 | - 数据结构改变。这种是比较复杂的，不管是灰度还是回滚，比较保险的做法是“绝不删除任何老数据，新的业务操作新数据，新的业务兼容老数据”。 301 | 302 | >举例来说：假设有一个学生管理系统设计了一个班级字段，但这个字段内容包含“学院-系别-班级”（例如：计算机学院-软件工程-2001080），现在要拆开为3个列，“学院”、“系别”、“班级”，那么就新增3个列，原有列保留，新系统增加删除修改信息的时候，同时修改4个列（“学院”、“系别”、“班级”、老的“班级”） 303 | 304 | - 新业务数据和老数据完全无关。这种也很简单，数据隔离就好，新业务用新表，或者新的存储方式都可以 305 | 对数据库有全面的监控能力，并且可以根据采集的指标有profiling的能力。 306 | 307 | #### 2.6.4优化管理级最佳实践 308 | ##### 2.6.4.1 概述 309 | 在两次发布之间建立了数据库性能和部署流程的反馈回路。 310 | 311 | ##### 2.6.4.2 最佳实践 312 | 无 313 | 314 | === 315 | 316 | ### 2.7 配置管理 317 | #### 2.7.1 可管理级最佳实践 318 | ##### 2.7.1.1 概述 319 | 重建软件所需的内容都进行了版本控制，包括：源代码／配置／构建和部署脚本／数据迁移。业务配置管理是通过文件管理的方式来完成，管理复杂而繁琐。 320 | 321 | ##### 2.7.1.2 最佳实践 322 | - 配置管理的范畴需要延伸，从基础设施的配置管理到上层应用的配置管理，即全面的CMDB配置管理。 323 | - 基础设施资源的配置管理是面相资源的配置管理方式，需要构建完整的配置及配置对象关系。 324 | - 面向应用的配置管理是以应用为中心的配置管理，构建的是应用及应用对象的配置管理。 325 | - 对所有的进行配置管理，从源代码，编译文件，配置文件到部署脚本等等。 326 | - 频繁提交代码到主干，以便于持续构建，确保代码运行正常 327 | - 业务配置文件必须分离到程序包和源代码包外部进行管理 328 | - 业务配置文件可以作为环境变量进行管理，利用操作系统的环境变量来进行读取 329 | - 必须建立一个构建库来管理所有的编译结果，同时构建库还需要完整的管理软件包的配置、依赖配置和环境配置等等。 330 | - 可视化管理以上的过程，需要借助一个标准的持续部署管理平台，对环境、软件包、部署脚本、软件配置等等做到可视化管理 331 | 332 | #### 2.7.2 已定义级最佳实践 333 | ##### 2.7.2.1 概述 334 | 库和依赖被很好的管理。变更过程决定了版本控制的使用规则。业务级配置管理能力通过环境变量或者云化配置中心来完成。 335 | 336 | ##### 2.7.2.2 最佳实践 337 | 338 | - 库和配置一般通过一些有效的工具进行管理，比如说java的maven，ruby的gems等等。 339 | - 对于一个程序包来说，必须显示的声明所依赖的库和依赖的版本信息，方便版本回溯。 340 | - 必须隔离软件包和系统的全局依赖信息，减少版本的交叉影响 341 | - 业务级别的配置管理使用环境变量进行管理，并且是和软件的版本与环境相对应的，确保配置信息的可扩展性 342 | - 对于一个海量的分布式系统来说，业务配置管理的变更可以称为一个独立场景，此时可以通过分布式配置中心来统一管理。 343 | - 海量的配置管理需要有快速的配置下发，配置版本对比，配置快速回滚等等能力。 344 | - 用户和密码等敏感信息不应该保存在版本库中 345 | - 对配置项需要有明确的配置命名习惯，这样可以通过配置的信息归类可以找到具体的含义，比如说DB的配置，可以增加DB头来命名。 346 | - 配置中的每个元素，使每个配置元素在整个系统中是唯一的 347 | - 配置信息的模块化，降低配置在模块之间的耦合，减少配置的交叉影响 348 | - 从配置的成熟度来说，建议配置文件模式统一，到配置格式统一，到使用方式统一等等 349 | - 应用程序所依赖的所有外部服务，以及这些服务的版本和配置信息 350 | - 基于应用的拓扑结构被很好的管理，这份配置信息对应用的变更／故障定位和影响评估都有很大的意义。 351 | 352 | #### 2.7.3 量化管理级最佳实践 353 | ##### 2.7.3.1 概述 354 | 开发人员每天至少提交到主干一次。只在需要发布时才会拉分支。 355 | 356 | ##### 2.7.3.2 最佳实践 357 | - 频繁提交到主干，减少多版本的持续集成带来的合并风险。 358 | - 配置的全面管理覆盖，从基础设施／环境管理／应用及应用配置管理／依赖管理等等，都能够识别出配置管理的准确率。 359 | - 配置的动态管理需要有自动的配置管理能力，而非依赖手工管理能力。 360 | 361 | #### 2.7.4 优化管理级最佳实践 362 | 无 363 | 364 | === 365 | ### 2.8 架构管理 366 | #### 2.8.1 可管理级最佳实践 367 | ##### 2.8.1.1 概述 368 | 所有服务的变更是可以通过webconsole完成的，可视化完成 369 | 370 | ##### 2.8.1.2 最佳实践 371 | - 识别服务变更的场景分类，比如说服务上线／服务下线等等，这个梳理要注意，第一要面向最终用户；第二要以应用的交付能力为核心度量。 372 | - 分解每个场景化的服务变更动作，比如说服务上线 373 | 374 | ![](http://7xl5e0.com1.z0.glb.clouddn.com/C3%20008.jpg) 375 | 376 | 图片地址：http://7xl5e0.com1.z0.glb.clouddn.com/C3%20008.jpg 377 | 378 | - 把服务变更的动作映射到运维的变更平台中，驱动服务变更过程的webconsole化。 379 | 380 | #### 2.8.2 已定义级最佳实践 381 | ##### 2.8.2.1 概述 382 | 对关联的技术架构服务变更可以通过其提供的API接口来调用完成；应用程序具备运维可管理能力。 383 | 384 | ##### 2.8.2.2 最佳实践 385 | 386 | - 对于技术架构来说，抽象其中的公共服务化能力，比如说分布式RDS／分布式cache服务／分布式消息队列服务等等。 387 | - 把每个后台服务当作应用的附加资源来进行管理，以便纳入统一的cmdb管理。比如说Mysql服务就可以当作应用的附加RDS服务来看待。 388 | - 所有的后台服务都实现了平台化管理，平台化管理其中运维可视化管理，运维场景化管理，运维监控能力以及系统API的对外开放性等等。 389 | - 基于平台化的能力，应用程序具备运维可管理能力。可管理能力遵循了标准的运维变更（发布／升级／回滚等等）过程，运维状态（监控／分析）管理过程等等。 390 | 391 | #### 2.8.3 量化管理级最佳实践 392 | ##### 2.8.3.1 概述 393 | 架构的服务化能力可以从监控／管理／调用能力／调用状态等多个角度衡量。 394 | 395 | ##### 2.8.3.2 最佳实践 396 | 397 | - 架构的服务化能力是可运维能力，其中包括架构的自服务／监控／可视化管理／场景化管理能力等等。 398 | - 架构的服务化能力之自服务需要有运维平台支撑，能够满足不同角色运维管理需要，比如说应用运维／系统运维／研发等等。 399 | - 架构的监控能力是内部的服务状态监测能力和外部服务SDK的状态监控能力。 400 | - 架构的场景化管理能力是能够可视化抽象各种服务的运维变更／故障处理／运营分析场景等等，比如说服务的迁移，故障在线定位，服务的性能优化管理等等。 401 | 402 | 2.8.4 优化管理级最佳实践 403 | 无 404 | 405 | 406 | 407 | 408 | 409 | 410 | -------------------------------------------------------------------------------- /Chapter 4 Product Operation Service.md: -------------------------------------------------------------------------------- 1 | # 第四章 产品运营服务 2 | 3 | ### 本章起草人：徐奇琛（京东无线运维总监） 4 | 5 | ## 1. 整体框架 6 | ### 1.1 概述 7 | 如下为产品运营支持服务模型的整体框架。应用运维为所服务业务领域的产品提供良好的运营支持服务是运维团队一个很重要的能力考量点，同样也是我们对公司技术体系部门、业务部门及最终用户输出服务的重要渠道之一。优质的运营支持服务，不是简单的做好业务方分配的任务或在每个执行环节完成交付即可，而是应该站在业务角度，基于对所服务产品及应用的深度理解结合运维自身的能力为业务方提供精准的、前瞻的、体系化的、超出预期的全生命周期服务支持。 8 | 9 | 在互联网应用运维框架之产品运营服务的成熟度模型中，我们主要以业务知识理解、项目管理能力、客户导向能力、业务连续性管理能力为基础能力围绕运营支持服务能力展开介绍。 10 | 11 | ![](http://7xl5e0.com1.z0.glb.clouddn.com/C4%20001.jpg) 12 | 13 | 图片地址：http://7xl5e0.com1.z0.glb.clouddn.com/C4%20001.jpg 14 | 15 | ### 1.2 框架图 16 | 17 | ![](http://7xl5e0.com1.z0.glb.clouddn.com/C4%20002.jpg) 18 | 19 | 图片地址：http://7xl5e0.com1.z0.glb.clouddn.com/C4%20002.jpg 20 | 21 | ## 2. 最佳实践 22 | ### 2.1 业务知识管理能力 23 | 对于业务知识的理解是应用运维有效开展各项工作的基础，特别是在产品运营的日常及大型营销推广的支持工作上，对业务理解程度、上游部门需求沟通效果都直接决定了运维提供服务的质量以及能否为业务方创造出额外价值。在大型互联网企业，对业务知识的掌握能力是运维人员能力模型/职业发展的必选项。本章节通过目前互联网公司的通用进阶措施，讲述业务知识管理能力在不同成熟度模型团队下的实践经验。 24 | 25 | #### 2.1.1 可管理级最佳实践 26 | ##### 2.1.1.1 概述 27 | 业务知识理解能力的可管理级（成熟度第二级），要求应用运维团队对自身公司所提供的业务服务或产品线有基本的认知度。并在招聘、培训、考核等管理工作上作为细化管理项，要求明确列入并对能力加以控制。团队能够正确理解业务方需求，根据流程准确的完成交付。 28 | 29 | ###### 2.1.1.2 最佳实践 30 | - 首先从源头开始切入，在招聘面试工作中除考量候选人技术和其他通用能力外，明确业务知识的问题占比及通过要求。业务知识作为专项素质能力项，加入招聘评估的环节。例如在游戏行业，考察应用运维是否了解不同游戏类型的不同架构模型、各类模块故障带给业务收入或用户的影响、游戏各个生命周期的用户运营需求、运营活动支持的工作流程等等。 31 | - 对于现有人员定期培训，对运维人员进行业务知识培训。包括入职培训、业务专项的培训等方式让运维人员了解所支持产品的运作流程、核心模块划分、业务需求沟通中需掌握的业务概念等。促使运维团队清晰的理解产品的核心流程与重点业务模块划分、业务流量与基本商业模式、用户的活跃周期等重要信息。使得与各需求团队在交付上有基本的共识、优先级控制，达到交流流畅、配合默契，提供的服务交付能够达到业务部门的基本要求。 32 | - 在业务知识的培训和学习过程中，通过考试、上岗资质认证、执行权限开通等必要的控制方式（最基本的考核管理），帮助人员的业务理解能力有效达标后成为合格的应用运维，同时也有效控制了因人员业务理解度低而潜在的风险。 33 | 34 | ![](http://7xl5e0.com1.z0.glb.clouddn.com/C4%20003.jpg) 35 | 36 | 图片地址：http://7xl5e0.com1.z0.glb.clouddn.com/C4%20003.jpg 37 | 38 | #### 2.1.2 已定义级最佳实践 39 | ##### 2.1.2.1 概述 40 | 业务知识管理能力的已定义级（成熟度第三级），应用运维团队对于业务知识的学习更加全面和持续，在基本的业务知识基础之上逐步从核心业务模块扩展到整个业务域。关注行业的新技术方案和新业务营销模式的兴起，知识积累方式由分散和被动趋于规律和平台化管理。能够突破日常固定的工作流程主动开展进一步的学习交流，不断深入挖掘业务领域知识、扩大业务需求的支持面和效率（工具）、并能够细分出场景提供更优质的服务，通过有效沟通最终沉淀下不同级别不同需求维度的运维交付流程。 41 | 42 | ##### 2.1.2.2 最佳实践 43 | - 完整的业务域学习，要求团队除业务核心功能核心流程以外建立更完善、完整的学习要求，了解营销、黄金流程以外的大量配套或分支模块的作用。诸如在电商领域，要对外部开放互联体系、营销推广活动工具、个性化推荐、画像等完整的业务模块和业务商业模式全面的学习和建立技术配套。以电商为例： 44 | 45 | ![](http://7xl5e0.com1.z0.glb.clouddn.com/C4%20004.jpg) 46 | 47 | 图片地址：http://7xl5e0.com1.z0.glb.clouddn.com/C4%20004.jpg 48 | 49 | >注释：黄金流程是电商行业对业务核心主流程的别称 50 | 51 | - 通过对业务的学习和理解，结合特定的业务方需求，能够根据不同场景优化现有模式固定的运维解决方案。例如电商营销模块的应用运维，会区分不同类型的营销活动（战略单品、热点营销、日常整点秒杀、周年庆大促等）、不同品类的热度（厂家爆款、热点sku等），从而为不同上游需求方提供合理的解决方案（包括资源方案、风控模式、预案和降级等），根据细分不同场景形成分级配套的标准化服务。 52 | - 建设体系化的学习发展计划，结合企业职能的学习平台固化成团队周期性学习流程，更好的提高运维团队持续学习的完成效率及完成质量。比如通常基于例如“e-learning”等学习类平台以及周期性个人学习发展计划的学习流程，固定考核周期中包含迭代更新业务知识考试以保障运维团队业务知识学习的连续性和阶段性。 53 | - 搭建部门或团队的知识体系库，存放业务文档、人员综合素质学习、重点项目资料等重要信息。配套完善权限管理与信息安全管理。 54 | 55 | #### 2.1.3 量化管理级最佳实践 56 | ##### 2.1.3.1 概述 57 | 业务知识管理能力的量化管理级（成熟度第四级），应用运维团队在已定义级别之上，基于对业务知识的充分理解、业务数据沉淀、业务案例的实践经验积累，通过进一步的量化分析能力，去沉淀运维可补充完善的工作、例如未达到最佳的服务交付、可提供业务方的重要数据与监控等等，实现对业务数据及运维服务质量的可量化管理，做到动态运营。 58 | 59 | ##### 最佳实践 60 | - 通过业务知识的理解，能够与运营方积极开展沟通，补充业务缺失的重要监控点、遗漏的数据上报项。透明数据标准与口径，做到运维支持效果、运营推广、新功能新产品发布等事后数据的可衡量。例如，针对各类大型节点的运营活动建立起多种维度的数据视图以量化效果，包括分析活动的流量构成、资源使用及负载、用户投诉数据以及必要的业务方ROI数据。联合产品运营方基于可量化的各项数据指标，有效调整资源（IDC资源、运营推广资源、人力资源）/容灾方案等。 61 | - 运维凭借掌握的业务数据和运维数据，建立业务推广需求的推导模型，提供精准的业务反馈和风险预判能力，使业务的容灾策略、业务开关设计机制更合理。 62 | 63 | #### 2.1.4 优化管理级最佳实践 64 | ##### 2.1.4.1 概述 65 | 业务知识管理能力的优化管理级（成熟度第五级），由点及面的拓展业务知识学习领域，从对产品的理解逐步过度到对整个行业的理解。除产品运营外，对行业生态，战略分析有更深入的理解。并结合业务理解和技术运营体系的方法论，使运维形成帮助业务数据提升的能力。 66 | 67 | ##### 2.1.4.2 最佳实践 68 | （无） 69 | 70 | === 71 | 72 | ### 2.2 项目管理能力 73 | 项目管理能力是运维人员应具备的通用技能项之一，也是多团队合作有序开展工作的保障。项管能力也需要具备良好的沟通能力、思维严谨、高效协作的意识等能力支撑。在互联网产品运营支持服务的常规工作中，有超过半数以上的需求会以项目组/项目制的形式开展。运维人员的项目管理能力和意识也决定了项目的完成质量。 74 | 75 | #### 2.2.1 可管理级最佳实践 76 | ##### 2.2.1.1 概述 77 | 项目管理能力的可管理级（成熟度第二级），要求运维团队对外接口成员须具备基本的项目管理和团队协作能力，熟悉项目管理的基础知识。一方面能够参与到项目组，根据计划完成辅助性的工作，并做好及时的跟踪及反馈；另一方面要求能够根据项目立项的流程组织实施运维主导的小型项目，能够根据整体的目标进行合理的任务分解与推进，在可控的风险范围内执行完成。 78 | 79 | ##### 2.2.1.2 最佳实践 80 | - 团队定组织与项目管理初级培训，确保运维团队内各职能各角色熟悉项目管理的基础知识和通用流程。项目实施能够遵循先前设定的流程，保障资源并权责落实到人，整个项目过程有监管和控制能力。 81 | - 能够参与产品与业务运营方组织的项目，比如了解常规项目内容、周期、流程。包括产品版本或功能迭代、工具平台建设、热点运营活动的保障等辅助类执行工作，根据项目经理的分配保障执行效果。 82 | - 团队成员能够独自主导小型项目，通过良好的沟通能力和项目组织能力，推动运维类项目的有效执行。比如，IDC级的业务腾挪、设备周期性的低负载优化、组件的批量化升级等维护类项目；运维工具新功能新平台的迭代上线等等工作。 83 | - 能够通过excel、邮件等基本工具将项目工作有效管理起来，做好项目的进展周知和同步管理。 84 | 85 | #### 2.2.2 已定义级最佳实践 86 | ##### 2.2.2.1 概述 87 | 项目管理能力的已定义级（成熟度第三级），要求进一步规范化团队的项目管理能力，并完善跨团队合作的能力。具备完善的项目管理措施，能在标准流程和特殊情况下得到有效的实施。并形成公司各团队统一标准，使得协同流程更加流畅、组织效率整体提升。在重点项目的跨部门跨职能的沟通上，要求掌握多种沟通技巧，以快速达成共识，促进项目执行效率。 88 | 89 | ##### 2.2.2.2 最佳实践 90 | - 项目管理知识的进阶培养，能够熟悉项目阶段、各阶段匹配的主要任务及配套工作文档以及各级角色,团队具备一定的项管方法论理解与运用，如4W1H等原则运用。 91 | 92 | ![出自jeff苏君福原创提供](http://7xl5e0.com1.z0.glb.clouddn.com/C40001.jpeg) 93 | 94 | 图片地址：http://7xl5e0.com1.z0.glb.clouddn.com/C40001.jpeg 95 | 96 | - 运营、产品、开发、测试、运维、PM等多角色通过公司级统一的项目管理平台和标准项目对接流程开展各项工作。项管平台的能力按团队特性，融合打通产品迭代、敏捷、测试管理等特性加快整体的效率。 97 | - 根据项目的分类不同，在团队内建立起对应细化的项目执行要求。如产品的功能迭代项目、重点营销项目等等需要建立起对应合适的流程要求以配合好不同需求团队不同角色的要求。在项目的不同阶段控制风险主动升级寻求资源。以达到产品运营的重要节点风险可控。 98 | 99 | #### 2.2.3 量化管理级最佳实践 100 | ##### 2.2.3.1 概述 101 | 项目管理能力的量化管理级（成熟度第四级），公司的项目管理不仅形成了制度，而且要实现数字化的管理。对管理流程要做到量化与数字化。通过量化管理来实现流程的稳定性，实现管理的精度，降低项目实施质量上的波动。通过项目管理平台实现项目管理工具化和标准化能力，建立团队各项目线的视图，能够对项目的执行过程、效果跟踪、数据总结具备更细化的数据评估能力。 102 | 103 | ##### 2.2.3.2 最佳实践 104 | - 团队做到合理透明的项目评估机制，在互联网公司，业务部门的需求和项目条线是繁多的，团队的资源和人力都比较有限。团队需要建立对项目需求合理评估以及分级支持的能力。包括在对项目背景理解后的需求分析与评审、预估ROI、资源沟通等，项目前后都有合理的评估以及结果数据的量化和数字化展现，使团队合理的利用资源及做好服务。 105 | - 对于大型项目，各阶段各模块的拆分是有序和顺畅的。对于风险控制和团队协作有更加明确的要求。团队能够关注项目的各环节数据与问题的总结和改善。 106 | 107 | 108 | #### 2.2.4 优化管理级最佳实践 109 | ##### 2.2.4.1 概述 110 | 项目管理能力的优化管理级（成熟度第五级），在优化级水平上，公司各团队协作的项目管理能力趋于完善。公司不仅能够通过信息渠道与数字化渠道来实现对项目的管理，而且能够充分利用历史数据和持续的改善，对公司在项目实施的过程中可能出现的风险予以预防。能够主动地改善流程，运用新技术，实现流程的优化。 111 | 112 | ##### 2.2.4.2 最佳实践 113 | (无) 114 | 115 | === 116 | 117 | ### 2.3 业务连续性管理 118 | 保障业务的连续是运维为企业贡献的核心价值之一，是运维最为本质的一种服务能力。在模式繁多的业务运营推广过程中，运维通过开源/商业解决方案、流程规范保障以及技术运营方法论实践等多种控制方式，做到业务连续性的保证。 119 | 120 | #### 2.3.1 可管理级最佳实践 121 | ##### 2.3.1.1 概述 122 | 业务连续性管理能力的可管理级（成熟度第二级），了解行业通用的开源容灾解决方案和技术原理。对当前负责系统进行容灾设计，保障日常阶段业务的高可用。面对突发情况能够及时按照规范和时效性要求处理，确保营销质量和业务基本的连续性。 123 | 124 | ##### 2.3.1.2 最佳实践 125 | - 理解系统层次和业务系统架构，熟悉每个架构层通用的容灾措施。 126 | - 7*24的运维值守流程+应急响应流程 127 | - 业务核心模块的部署要求做到无单点 128 | - 团队建立操作规范，避免人为原因导致业务中断。 129 | 130 | #### 2.3.2 已定义级最佳实践 131 | ##### 2.3.2.1 概述 132 | 业务连续性管理能力的已定义级（成熟度第三级），业务系统架构设计符合简化及标准的原则、建立合理的业务连续性的标准架构、日常的运维规范及应急流程对于业务稳定性具备控制能力，并通过对各模块的定期演习来优化架构和完善流程。 133 | 134 | ##### 2.3.2.2 最佳实践 135 | - 明确公司/企业业务连续性的标准架构及目标衡量机制。能够根据企业或业务模式的特点，基于团队人员能力、技术架构、响应流程、灾难恢复/容忍度等维度制定。 136 | - 变更控制：变更管理的保障，业务功能上线、组件配置维护都遵循灰度的要求。对于变更有非常严格的要求，包括圈定范围细化分类，如网络架构类、服务器类、机房环境类、系统管理类、应用管理类。应用运维主要负责应用管理类的变更管理并协调周知其他类别的管理。对变更建立分级管理、风险控制、信息周知的流程。配备详细的变更流程管理杜绝风险。 137 | - 运营协作流程：业务运营与技术支撑建立良好的联动机制，要求建立流程保障活动流量等信息的及时传递。在电商领域，频繁的运营活动和季节性大促都会带来突发性的大流量，虽然系统具备一定的容量冗余，但还是可能会受制于流量的力度、局部性等问题带来的不可用故障；运营信息的及时流转对于做好支撑工作尤为重要。一般电商企业会建立清晰的促销协作流程，并明确各团队的工作流。 138 | - 架构层：基于DO合作，“简化”原则下的软件系统高可用设计，各架构层具备高可用、可切换、可扩展、合理缓存设计、系统高内聚低耦合等特性。 139 | - 演习：对业务各模块建立频次合理的演习计划，帮助团队熟练掌握流程并及时发现软件架构或业务变化导致的问题。帮助业务持续完善架构和预先发现风险。 140 | - 效率：故障信息流转效率和故障恢复效率的保障建设。借助于事先定义的场景化响应流程和工具，引导各类故障信息的高效流转、响应和处理。 141 | - 应急响应机制：根据故障的不同等级建立配套的应急响应机制，对于故障的流转、处理、上升、总结等多个阶段都有明确的要求。 142 | 143 | #### 2.3.3 量化管理级最佳实践 144 | ##### 2.3.3.1 概述 145 | 业务连续性管理能力的量化管理级（成熟度第四级），通过历史数据和故障场景的积累，建设工具做到高频故障的快速自愈。系统架构的设计融入海量运营的方法论，如业务有损体验、过载保护的规则、立体化监控等等。业务连续性管理做到对技术团队清晰的量化能力。 146 | 147 | ##### 2.3.3.2 最佳实践 148 | - 结合运维数据和场景，对于软件架构自身及网络&设备导致的高频低损类故障做到自修复；重大故障要求建立更清晰的流程、人员权责、决策响应机制。 149 | - 根据业务的不同维度，建立更加完整的监控覆盖能力。 150 | - 联合QA团队制定公司高可用能力的数值定义、评估规范、考核细则，以量化的管理手段，度量各业务可用性的数据。 151 | - 根据业务特性在高可用和成本之间进行合理的取舍，软件设计中引入有损体验和柔性降级等方法在保障一定的可用性的基础之上合理的降低成本。 152 | - 应急机制&问题管理：能够进一步根据产品线或模块或重大故障场景，建立更加有针对性的保障服务。通过周期性的问题总结，促进持续改善。 153 | 154 | #### 2.3.4 优化管理级最佳实践 155 | ##### 2.3.4.1 概述 156 | 业务连续性管理能力的优化管理级（成熟度第五级），根据业务特点和Devops的价值观，技术体系在长期共赢合作下对于技术架构的设计、容灾策略、监控数据的可视化建设上有明确的共识与创新学习迭代能力。并能够在服务好业务部门的同时建立足够的沟通，避免因业务变化带来潜在的风险以及在理解业务的前提下进行技术侧的改良和优化。 157 | 158 | ##### 2.3.4.2 最佳实践 159 | （无） 160 | 161 | === 162 | 163 | ### 2.4 运营服务能力 164 | 运营服务能力是应用运维结合不同的业务领域，提供给业务在整个产品生命周期的运营过程中所需要的技术协助，包括业务的需求项目支持、架构容灾解决方案规划、用户体验改善等全面的技术运营服务体系。 165 | 166 | #### 2.4.1 可管理级最佳实践 167 | ##### 2.4.1.1 概述 168 | 运营服务能力的可管理级（成熟度第二级），运维团队与业务方建立有效的沟通，承接好日常的支撑需求工作。对常规的业务可用性管理、业务需求项目、持续部署等基础服务能力提供支持。以保障公司业务运营稳定性。 169 | 170 | ##### 2.4.1.2 最佳实践 171 | - 需求管理：建立明确有效的运营服务渠道，确保对业务方的有效宣导与对接。如以专门的接口人、服务热线、项目管理流程、需求模板等方式确保需求接收渠道的有效。 172 | - 在可管理阶段，要求运营服务类目中包含对于所服务业务的高可用管理、业务运营日常需求支持、持续部署服务等基本的服务场景。 173 | - 团队定义基本的运维服务流程，面向需求部门透明过程和结果。 174 | 175 | #### 2.4.2 已定义级最佳实践 176 | ##### 2.4.2.1 概述 177 | 运营服务能力的已定义级（成熟度第三级），运维团队面向业务提供更加完整的服务目录，扩展自身的服务能力范畴。针对产品活动、营销推广等重要场景化需求，建立专属的服务流程保障。依托ITIL管理实现服务流程透明及闭环，标准化的交付能力。 178 | 179 | ##### 2.4.2.2最佳实践 180 | - 在已定义级别，要求进一步扩展团队提供的服务类目范围，需关注用户体验管理、运营决策管理、营销活动管理、产品规划管理等等重要服务。 181 | - 对专项场景，建立深度服务保障体系。如营销类的大促流程会细化各个环节。在项目管理的力度、促销架构和资源管理、特定预案设计等细化维度都会有更精细化的要求。（如图） 182 | 183 | ![](http://7xl5e0.com1.z0.glb.clouddn.com/C4%20005.jpg) 184 | 185 | 图片地址：http://7xl5e0.com1.z0.glb.clouddn.com/C4%20005.jpg 186 | 187 | - 通过运维ITIL体系的管理，做到服务与需求处理的闭环与透明过程，提高效率和用户满意度。 188 | - 配套标准化的常态化运营机制，如客户回访、客户投诉率、客户运营品质每周TOP问题跟踪闭环、产品问题上下游跟踪闭环改进。 189 | 190 | #### 2.4.3 量化管理级最佳实践 191 | ##### 2.4.3.1 概述 192 | 运营服务能力的量化管理级（成熟度第四级），在完善的运营服务目录基础下，通过长期对需求、项目、结果数据的分析。建立更加细化的运营服务分级支持能力，从合理资源投入、自助化授权程度、优化覆盖范围等维度给到业务的不同阶段以最合适的运营服务方案。对业务建立完整的数据运营、质量控制，精准合理的资源管理能力，帮助业务方提高运营能力，为其提供更好的决策依据和效果跟踪。 193 | 194 | ##### 2.4.3.2 最佳实践 195 | - 需求分析与优化：通过长期的需求数据积累，合理的分析推动改善运营服务窗口资源的配比，通过工具合理的授权节省下资源更多投入重点需求。 196 | - 对于重点营销活动，建立业务模块清晰的容量模型，完善各环节监控数据的建设。为业务方提供前瞻的决策依据。 197 | - 为业务提供完整的数据视图服务，包括运维数据、运维建设的业务辅助数据、技术运营和业务运营关联的数据等等，在运营全阶段提供数据支撑。例如，运维数据包括用户属性分析、各地区的可用性等可以做一定的数据拟合便于业务方决策；辅助运营做流量分析得出恶意流量数据引导运营策略、合作商更换等优化措施。 198 | 199 | #### 2.4.4 优化管理级最佳实践 200 | ##### 2.4.4.1 概述 201 | 运营服务能力的优化管理级（成熟度第五级），深入理解运营服务，结合各自公司的属性与业务特征，基于通用标准化、数字化、自动化的原则，能够建立最适合的产品运营标准服务系统。 202 | 运营细分至基础运营、用户运营、活动运营等能力与服务延展，在保障服务效率和质量的基础上，面向用户、营销提供全面的增值服务能力，业务运营与技术运营高效的协作补强，补充业务方短板（用户体验、业务安全、成本优化等领域）帮助业务指标的持续提升。 203 | 204 | ##### 2.4.4.2 最佳实践 205 | （无） 206 | 207 | === 208 | 209 | ### 2.5 客户导向能力 210 | 用户价值是企业运营生存的核心竞争力，运维人员也同样需要以用户的视角评估开展工作，客户导向也成为互联网技术人员必备的意识。对于运维而言服务好内外部用户，具备用户为先的价值观意识，技术运营才能更好的服务好业务运营。 211 | 212 | 运维人员的客户服务的通用能力、组织建设能力建议亦可参考第六章客户服务的章节详细学习。 213 | 214 | #### 2.5.1 可管理级最佳实践 215 | 216 | ##### 2.5.1.1 概述 217 | 客户导向能力的可管理级（成熟度第二级），要求运维人员能够积极主动的开展各项工作、带感情的传达信息、准确并彻底地了解用户，以高效职业的态度开始沟通协作是第一步。与内部客户（内部业务部门）顺利建立稳定的业务合作关系，满足内部各业务需求部门、合作方的日常需求。 218 | 219 | ##### 2.5.1.2 最佳实践 220 | - 运维人员积极主动的服务意识。 221 | - 透明高效的完成用户需求工作并及时的给与反馈。 222 | - 要事为先，能够辨别工作的主次，以公司用户价值、品牌形象为重。 223 | 224 | #### 2.5.2 已定义级最佳实践 225 | ##### 2.5.2.1 概述 226 | 客户导向能力的已定义级（成熟度第三级），能够通过平台/工作流保障对用户的服务能力，对于需求的分级、执行，有明确的规范流程保障。对需求做到分析用户（内外）反馈数据并跟进、深度的沟通以建立长期服务优化计划。 227 | 228 | ##### 2.5.2.2 最佳实践 229 | - 以ITIL管理的方式确保对需求、服务满意度的控制，对用户的需求与服务以标准化的流程交付。 230 | - 具备需求管理的能力，对人员处理需求的效率、满意度、需求合理性进行分析，优化当前流程不足。 231 | - 通过内外部用户的反馈数据，发现运营过程问题并主动改进。如在需求管理平台具备满意度收集环节，根据反馈数据迅速安排改进优化；关注外网用户的不同分类投诉发现架构或流程中的不足，对用户数据分类、处理、回访。 232 | 233 | #### 2.5.3 量化管理级最佳实践 234 | ##### 2.5.3.1 概述 235 | 客户导向能力的量化管理级（成熟度第四级），能够通过用户数据的有效运营，建立起用户体验的可衡量的指标，预警用户的潜在需求风险、性能体验等的亚健康指标下降等，能够做到用户满意度的持续提高。 236 | 237 | ##### 2.5.3.2 最佳实践 238 | - 通过用户投诉日报/体验速度监控/产品功能灰度用户体验群等各类渠道，全面收集用户数据。重视接触客户沟通能力和渠道的管理。 239 | - 对于业务功能发布和变更遵循严格的灰度原则，尽可能降低变更引起对用户的影响范围。 240 | - 业务各类监控的关联建设，打通监控层和用户数据层。比如，用户对支付的投诉（舆情），需关联支付的业务量监控、应用服务监控、IDC基础网络监控等数据做关联分析。同时，在流程上对变更、发布、配置加以更有效的控制。 241 | - 结合各维度的用户数据建立用户舆情的大数据能力，并持续优化数据模型；通过大数据分析得出用户对产品的正负评价、痛点、功能接收程度、建议并辅助产品决策和开展针对性的技术优化。建立用户体验和产品收益的关联。 242 | 243 | 对于用户体验优化的更多细节亦请参考第八章用户体验服务。 244 | 245 | #### 2.5.4 优化管理级最佳实践 246 | ##### 2.5.4.1 概述 247 | 客户导向能力的可管理级（成熟度第五级），长期通过建立用户为先/以用户价值为依归的团队价值观，宣导深入每一位成员的意识。建立完善的用户满意度监控、用户体验全流程数据，能够更前瞻的发现隐患趋势。通过专业能力的实践建立技术和用户价值的双赢。 248 | 249 | ##### 2.5.4.2 最佳实践 250 | （无） 251 | 252 | 253 | 254 | 255 | 256 | 257 | -------------------------------------------------------------------------------- /Chapter 5 Monitoring Service.md: -------------------------------------------------------------------------------- 1 | # 第五章 监控服务 2 | ### 起草人：梁定安（腾讯SNG运维负责人） 3 | 4 | ## 1. 整体框架 5 | ### 1.1 概述 6 | 运维的核心职责：质量、效率、成本。监控能力是应用运维保证业务质量的重要能力，监控能力的强弱可以作为衡量应用运维团队工作出色与否的标准之一。本规范将从四大能力模型的不同成熟度阶段，为读者提供通俗易懂的参考。 7 | 8 | ![](http://7xl5e0.com1.z0.glb.clouddn.com/C5%20001.jpg) 9 | 10 | 图片地址：http://7xl5e0.com1.z0.glb.clouddn.com/C5%20001.jpg 11 | 12 | ### 1.2 框架图 13 | 14 | ![](http://7xl5e0.com1.z0.glb.clouddn.com/C5%20002.jpg) 15 | 16 | 图片地址：http://7xl5e0.com1.z0.glb.clouddn.com/C5%20002.jpg 17 | 18 | ## 2. 最佳实践 19 | ### 2.1 应用监控能力 20 | 21 | 应用监控能力是运维为了保障业务质量的表现层或产品化的能力模型，伴随该能力模型发展的同时，监控平台能力、质量管理能力和事件响应及处理能力都必须相应的有所提高，以便更有力的支撑监控表现层的能力提升。本章节通过应用监控能力的框架能力分享，阐述在不同能力阶段的实践经验。 22 | 23 | #### 2.1.1 可管理级最佳实践 24 | ##### 2.1.1.1 概述 25 | 应用监控能力可管理级是处于初级能力模型阶段，运维通过监控能力的建设能够实现常用的监控点部署，根据一般的故障场景总结设计出监控点。此阶段的监控能力是点的监控，多为使用外部获取数据的被动式监控方法，运维在此成熟度下对监控反映的异常事件也多为被驱动式的响应。 26 | 27 | ##### 2.1.1.2 最佳实践 28 | - 系统日志的监控分析，如dmesg、message等系统日志的监控分析。 29 | - 应用日志的监控分析。 30 | - 被动响应式监控，如收到应用慢或不可用的反馈，被动式监控和排障。 31 | - 外部可用性探测，如外部ping。 32 | - 进程端口级监控，如本地ps等方法。 33 | - 单机容量级监控分析，如CPU、内存、硬盘空间等容量监控。 34 | 35 | 应用监控能力可管理级，对精细化管理的要求不高，能实现对常见系统级或应用进程级的监控分析，即可达到此成熟度模型的要求。 36 | 37 | #### 2.1.2 已定义级最佳实践 38 | ##### 2.1.2.1 概述 39 | 应用监控已定义级，运维的监控能力可灵活根据场景采用主动或被动（埋点或非埋点）的监控方案，较全面的覆盖操作系统、服务端、客户端的应用监控需求，并针对不同场景的监控都有明确的指标衡量服务的可用性或可靠性，运维对生产环境的质量监控有较强的掌控力。 40 | 41 | ##### 2.1.2.2 最佳实践 42 | 43 | - 操作系统监控体系（面），利用探针（agent）系统化的采集操作系统的运营信息，作为监控分析排障用途。如zabbix的操作系统监控能力。 44 | - 浏览器监控体系，针对浏览器应用场景的监控体系，在体系中包含：返回码、测速、H5等监控方案。如嵌入js获取监控信息、自动化测试用例模拟波测。 45 | - 服务端监控体系，针对应用程序的监控，主要有两种方法： 46 | - 开发人员提前在开发过程中埋入监控逻辑，运维提供上报方法或日志采集的方法将监控数据汇总，供分析、展现、排障使用。 47 | - 运维通过对应用程序的日志分析，进行有限的数据收集，以达到监控应用服务质量的目的。 48 | 49 | - 客户端监控体系，主要包括两种模式： 50 | - 区别于服务端的监控，客户端根据细分场景的不同制定对应的业务监控逻辑，实时主动上报监控数据流，在运维监控系统中分析，是实时监控能力的体现。如安卓、IOS等不同客户端的监控能力的建设。 51 | - 客户端埋置监控逻辑定时写入本地日志，在特定的场景下（异常/wifi）触发本地日志上报，运维监控系统接收后，解析日志文件供离线监控分析用户。如安卓的BCI注入的监控方案。 52 | 53 | 在已定义阶段，应用监控能力已经实现操作系统、服务端、客户端、浏览器的全覆盖，运维借此能很好的对服务的可靠性或可用性进行很好的度量，并以此开展优化工作。 54 | 55 | #### 2.1.3 量化管理级最佳实践 56 | ##### 2.1.3.1 概述 57 | 应用监控在量化管理级，主要强调的是监控数据的灵活应用和关联分析，监控数据中并非只有异常数据才需要运维关注并触发行动，往往在大量的监控数据中，深埋着很多有价值的数据需要运维人员主动挖掘。 58 | 59 | ##### 2.1.3.2 最佳实践 60 | 监控数据的灵活应用和关联分析，聚焦在监控应用方向，主要有以下实践： 61 | 62 | - 端到端关联分析，在分布式架构盛行的今天，任何业务逻辑都有可能跨机房、跨网络、跨服务、跨设备来完成，当异常发生时，排障要追溯到根源便需要由大量监控数据汇聚在一起，进行关联分析。此举能有效的收敛监控产生的告警，快速定位目标问题，加速监控排障的效率。如常见的三层互联网架构web层-逻辑层-存储层，通过端到端的监控数据关联分析，当存储层发生异常时，逻辑层和web层都有波及受影响的可能，通过监控数据的关联分析，端到端监控能够精准的判定存储的异常且发生告警通知，将web层和逻辑层发生的异常告警将被收敛。 63 | - 接口级的监控能力，对于应用程序内函数级的调用关联分析，是APM的一个重要课题，也是运维快速排障或优化性能的重要数据支持。例如，通过分析内存的堆栈信息获取安卓客户端代码中相关函数间的调用关系和函数执行的耗时数据。 64 | 65 | #### 2.1.4 优化管理级最佳实践 66 | ##### 2.1.4.1 概述 67 | 应用监控优化管理级，监控能力从程序侧延伸到用户侧，通过用户在互联网上的使用痕迹，通过机器学习等手段，对用户使用业务的言论进行分析，应用监控迈入智能化阶段，并借助全局监控数据的大数据挖掘能力，实现用户体验的精准判断，并与自动化运维能力结合实现智能排障。 68 | 69 | ##### 2.1.4.2 最佳实践 70 | （暂无） 71 | 72 | === 73 | 74 | ### 2.2 质量体系化能力 75 | 质量体系管理能力，主要是助力运维推进标准化规范的动力，是运维贯彻落实质量、效率、成本目标的自上而下的管理办法。因此，质量体系管理能力对运维持续优化监控发现的异常问题，推动根源问题解决的很重要的能力模型。 76 | 77 | #### 2.2.1 可管理级最佳实践 78 | ##### 2.2.1.1 概要 79 | 质量体系管理能力在可管理级成熟度模型下，主要是对操作系统级的监控点的部署有要求，但并未形成明确的度量考核要求。此阶段强调软意识，暂未能形成闭环管控。 80 | 81 | ##### 2.2.1.2 最佳实践 82 | - 操作系统级监控点的推广要求，如容量监控，dmesg等质量监控点的要求。 83 | 84 | #### 2.2.2 已定义级最佳实践 85 | ##### 2.2.2.1 概述 86 | 已定义级的质量体系管理能力，从上一阶段的点的监控能力进化为面的监控能力，质量体系对指标的度量要求逐渐清晰与明确，运维制定与之要求相应的管理与考核流程，形成闭环式管理监控发现的质量问题，有助于质量的持续优化。 87 | 88 | ##### 2.2.2.2最佳实践 89 | 90 | - 操作系统监控质量体系管理，对操作系统层需监控的指标进行度量化的要求，并制定清晰的目标和响应时间要求。如coredump事件的响应时间。 91 | - 浏览器监控质量体系管理，针对浏览器应用场景的监控体系独有的指标，进行度量与考核要求，并通过对指标的关注和运营，持续优化业务的质量。如http返回码的占比控制，测速数据的考核等。 92 | - 服务端监控质量体系管理，成功率、请求量、延时是服务端监控常用的质量，质量体系管理同样从这3个指标进行度量和考核，要求应用开发负责人与运维通过提升3个指标来对应用程序持续优化。如制定目标成功率提升为99.99%。 93 | - 客户端监控质量体系管理，针对客户端应用场景的监控体系独有的指标，进行度量与考核要求，并通过对指标的关注和运营，持续优化业务的质量。如crash率，耗电量等指标的度量与考核要求。 94 | 95 | 通过质量体系管理能力的成熟，明确了开发和运维的共同价值目标，都是为了优化用户的体验和应用程序的可用性 。因此，运维在推动落实监控方案和监控指标时，与开发协力打造最适合监控方案，以形成质量考核与运维活动正向推动，是devops概念的实例化。 96 | 97 | #### 2.2.3 量化管理级最佳实践 98 | ##### 2.2.3.1 概述 99 | 质量体系管理能力在量化管理级所覆盖的范围进一步扩大，从按架构分层：操作系统层、服务端、客户端分别的质量考核管理，逐渐进入对端到端的链条式质量度量考核的阶段。质量体系管理实现了数据关联分析，对应用整体的可用性或可靠性度量更加精准与聚焦。 100 | 101 | ##### 2.2.3.2 最佳实践 102 | - 日志标准化，制定全局标准日志规范，监控数据关联分析时，可通过日志获取丰富的信息，供智能监控与自动化处理能力使用。如全局返回码，根据返回码便可识别出异常的节点。 103 | - 端到端链路质量管理要求，通过对核心链路的整体监控，将多个度量指标：操作系统层、服务端、客户端的指标统一聚集到链路上，集中度量与考核，更贴近用户使用业务的场景，质量体系管理能力更精细化。如用户交易链路的质量度量与考核。 104 | - 接口级调用质量管理要求，按接口级调用的场景，定义相应的度量和考核指标进行要求。如接口间的调用延时度量与考核。 105 | 106 | 质量体系管理的管控，最直观的就是落地为度量能力与考核要求，一旦企业内部达成统一的质量考核目标，应用运维的监控方案便能轻松的推广与实现。 107 | 108 | #### 2.2.4 优化管理级最佳实践 109 | ##### 2.2.4.1 概述 110 | 质量体系管理能力，技术侧对应可用性和可靠性，用户侧对应用户体验。在优化管理级，要求对用户体验的质量进行度量与考核。并辅以其他技术侧的监控数据进行关联分析，将应用全生命周期监管起来，质量体系管理的考核要求也将贯彻整个生命周期。 111 | ##### 2.2.4.2最佳实践 112 | (暂无) 113 | 114 | === 115 | 116 | ### 2.3 事件响应与处置能力 117 | 运维救火队员的形象大部分源自于对监控异常事件的快速响应与紧急处理能力。因此，事件响应与处置能力是最能体现运维能力建设好与坏的直接能力模型。 118 | 119 | #### 2.3.1 可管理级最佳实践 120 | ##### 2.3.1.1 概述 121 | 运维对事件响应和处置能力在可管理级阶段，仍处于相对被动的状态，依靠有限的监控点产生的告警，由运维进行一线排障或驱动开发排障，以手工查问题解决问题为主，有值班机制。 122 | 123 | ##### 2.3.1.2 最佳实践 124 | - 交付一线的运维排障能力。 125 | - 交付24小时值班机制。 126 | 127 | #### 2.3.2 已定义级最佳实践 128 | ##### 2.3.2.1 概述 129 | 应用运维团队在已定义级阶段，随着监控能力的提高，运维对异常事件的感知速度更快，并且通过工具化的建设和监控数据的分析，逐步实现潜在异常提前发现的预警机制，一线二线的排障机制，运维能力的不断提高，使得排障场景运维对开发的依赖度降低。 130 | 131 | ##### 2.3.2.2 最佳实践 132 | - 异常预警机制，通过经验积累和数据趋势分析，部分监控点的潜在问题可被提前发现，将问题扼杀在摇篮中。如容量的使用趋势可以预测未来一段时间内会出现的高负载。 133 | - 一线工具化，对于常见的排障场景，运维的经验和处理方法被抽象成工具，低阶的运维人员可以通过工具操作，以满足一线排障的要求。 134 | - 二线流程化，在一线无法解决的问题中，二线运维会有闭环的排障分析流程，保证所有流入二线的问题都将有效的被修复，并且不再重复发生。如根源问题分析流程RCA（Root Cause Analysis）。 135 | 136 | 运维的事件响应与处置能力步入已定义级阶段，意味着运维团队的整理抢险能力已经从手工时代进入工具化时代。 137 | 138 | #### 2.3.3 量化管理级最佳实践 139 | ##### 2.3.3.1 概述 140 | 量化管理级阶段下的事件响应和处置能力，因应用监控能力、质量体系化能力、监控平台能力都实现了端到端的监控数据关联分析，监控整体能力有长足的发展，运维对事件响应和处置能力同样继承了监控关联分析的利好，异常事件告警量经过智能聚类和收敛而数量锐减，运维得以更聚焦核心问题处置上，也得以有更多资源投入自动化运维的能力建设上。 141 | 142 | ##### 2.3.3.2 最佳实践 143 | - 端到端告警与处理，实现链路监控分析与告警的能力，告警数量将被收敛，对监控平台对数据处理加工的要求将更高。 144 | - 接口级调用异常与处理，代码级的监控能力，需要开发在编码过程中提前埋点，告警精准定位到代码级别，可直接由开发人员处理此类告警。 145 | 146 | 运维事件响应与处置能力在量化管理级阶段，受惠于监控数据的关联分析，智能化与自动化的事件响应与处理能力都被逐步实现。 147 | 148 | #### 2.3.4 优化管理级最佳实践 149 | ##### 2.3.4.1 概述 150 | 在优化管理级阶段中，事件响应与处置能力就被智能化二合为一，有望实现预警或告警并自动化处理，引入机器学习等大数据技术加强对异常事件的深入学习和分析，并强化业务架构和自动化的建设，异常事件得以被自动处置。 151 | 152 | ##### 2.3.4.2 最佳实践 153 | （暂无） 154 | 155 | ### 2.4 监控平台能力 156 | 监控平台能力是决定监控产品化或表现层的直接支撑能力，同样是质量体系化能力的数据支持，更是事件响应级处置能力的数据来源。因此，监控平台能力的建设很关键，在本章将阐述监控平台建设的实践要点。 157 | #### 2.4.1 可管理级最佳实践 158 | ##### 2.4.1.1 概述 159 | 监控平台能力在可管理级阶段，对监控点的数据有集中处理和统计分析的需要，多为依赖手动触发的批量采集脚本，将零散的监控点信息收集并分析，整个过程不能实现自动化，需要人工衔接。 160 | 161 | ##### 2.4.1.2最佳实践 162 | - 批量采集数据工具，实现数据采集功能，将分布式的本地数据集中管理。如expect实现的采集脚本。 163 | - 监控数据分析工具，零散的非自动衔接的数据分析工具，但能满足对监控数据统计分析的基本诉求。如awk、sed等。 164 | 165 | #### 2.4.2 已定义级最佳实践 166 | ##### 2.4.2.1 概述 167 | 运维能根据监控场景的需求，建设成套监控平台架构，实现数据采集、传输通道、数据处理、可视化展现等能力，此阶段的监控平台架构会按分布式系统设计，可灵活扩展，平台能力能满足应用监控的需要。 168 | 169 | ##### 2.4.2.2 最佳实践 170 | - 数据采集，监控平台提供支持埋点或非埋点的监控数据采集能力，供应用选择，满足不同场景的监控需求。如数据采集agent，logstash等。 171 | - 传输通道，提供稳定高质量的数据传输服务，用于分布式的监控数据的集中化处理。如http上传、分片、对账等能力。 172 | 数据处理，面对大量的监控数据上报，监控平台需支持实时流处理能力和离线的大数据计算能力，以备不同监控分析场景使用。如storm、hadoop等。 173 | - 监控可视化，对不同场景的监控数据分析需求抽象为数据可视化服务，提供通用的聚类、翻译等计算逻辑，以图、表等形式展现。如对ip地址翻译为省份、运营商，成功率提供趋势图分析，返回码提供饼图分析等。 174 | - 告警处理，对于监控异常点的收敛与告警能力，通过引入不同的告警算法，旨在将精准的告警信息推送到合适的人手中。如利用3sigma算法精准计算波动偏差值。 175 | - 监控系统的自我监控，监控系统承担发现业务质量异常的重任，监控系统的高效可靠成为业务质量监控度量的只要因素之一，运维需要在建设监控系统的同时，注意加强对监控系统的可用性管理和监控能力。 176 | 177 | #### 2.4.3 量化管理级最佳实践 178 | ##### 2.4.3.1 概述 179 | 监控平台能力在量化管理级阶段的表现为，监控平台架构的各个功能模块更加独立和产品化，能将监控数据集中加工，并提供通用的数据银行接口，供应用监控表现层的展现形式多样化，同时监控平台自身的健壮性和可靠性更强。 180 | 181 | ##### 2.4.3.2 最佳实践 182 | - 数据银行，完成所有监控数据的加工处理入库，并灵活根据不同的应用监控场景，封装成通用的接口供监控产品化使用，数据透明给所有有使用数据需求的技术人员，数据获取不再困难。如提供数据检索功能，丰富的数据接口满足各种监控诉求。 183 | - 监控系统的自愈能力，监控平台要完成高可用架构的同时，应建设异常场景的自动恢复能力，保证监控平台在重大故障来临时，自身的高可用性不受影响。如监控系统的容量弹性伸缩。 184 | 185 | #### 2.4.4 优化管理级最佳实践 186 | ##### 2.4.4.1 概述 187 | 监控平台能力在优化管理级阶段，平台对数据加工处理更智能化，可灵活根据监控数据的产品化需要，组织和变更数据计算、翻译、降维等数据处理逻辑，自动适配用户使用监控数据的场景要求，让监控原始数据到数据加工处理到监控可视化产品的过程更高效，以确保用户使用监控产品时的体验最优。监控平台数据处理的能力迈入智能化和自动化。 188 | 189 | ##### 2.4.4.2 最佳实践 190 | （暂无） 191 | 192 | 193 | 194 | 195 | 196 | 197 | 198 | 199 | 200 | 201 | 202 | -------------------------------------------------------------------------------- /Chapter 6 Client Service.md: -------------------------------------------------------------------------------- 1 | 2 | # 第六章 客户服务 3 | 4 | ### 本章起草人：萧田国（触控科技总监、高效运维提出者） 5 | 6 | ## 1. 整体框架 7 | 8 | ### 1.1 概述 9 | 如下为客户服务的整体框架。良好的客户服务是运维部门对公司其他业务部门及最终用户的最大价值输出，也是对运维部门自身最大的挑战之一。良好的客户服务，不是单单一方面能力即足以支撑，往往需要多种能力配合，在互联网应用运维框架之客户服务的成熟度模型中，我们主要考察组织建设与保障能力、客户感知与导向能力、熟悉业务能力、沟通能力和响应与处理能力。 10 | 11 | ### 1.2 框架图 12 | 13 | 14 | ![](http://7xl5e0.com1.z0.glb.clouddn.com/c6%20001.jpg) 15 | 16 | 图片地址：http://7xl5e0.com1.z0.glb.clouddn.com/c6%20001.jpg 17 | ## 2. 最佳实践 18 | 19 | ### 2.1 组织建设与保障能力实践 20 | 良好的客户服务，首先在于组织结构。组织建设的基石是明确分工/职责/KPI，然后据此根据运维部门规模和业务复杂程度，设定具体的组织结构。 21 | 22 | #### 2.1.1 可管理级最佳实践 23 | ##### 2.1.1.1 概述 24 | 运维团队有基本的分工，已建立基本的组织结构，有一定的岗位职责。 25 | 26 | ##### 2.1.1.2 最佳实践 27 | - 进行明确的团队人员分工及小组职责划分，不随意分配工作； 28 | - 分别基于小组和个人，进行明确的KPI划分，KPI可衡量； 29 | - 重要岗位有主备人选，确保紧急情况时仍然可以紧急响应； 30 | - 具有一定的服务意识宣导机制。 31 | 32 | 33 | 34 | #### 2.1.2 已定义级最佳实践 35 | ##### 2.1.2.1 概述 36 | 建立了面向业务和客户的运维组织结构，而非传统的竖井式组织结构，有专门的组织对接业务需求，善用具备较好沟通能力的人员。 37 | 38 | ##### 2.1.2.2 最佳实践 39 | - 具有固定的接口人制，统一面向业务和客户，不再多对多沟通； 40 | - 选用具有良好沟通能力和良好客户界面的运维人员作为接口人； 41 | - 建立了初步的持续改进机制，能够定期/不定期回顾服务并作出改进； 42 | - 一般需要设置运维开发类岗位，常见业务固化在业务平台而非流程中； 43 | - 制定客户满意度考核机制，以提高接口人服务输出能力及服务提供能力。 44 | 45 | 46 | 47 | #### 2.1.3 量化管理级最佳实践 48 | ##### 2.1.3.1 概述 49 | 建立了紧急情况响应和处理中心以及运维办法，可快速响应、发现和解决业务需求。具有较好的问题总结归纳能力，可以预估部分可能出现的异常并快速解决。 50 | 51 | ##### 2.1.3.2 最佳实践 52 | - 建立紧急情况响应和处理中心，成员包括运营/研发/测试/运维/客服。 53 | - 制定紧急情况响应和处理办法，授权基层人员部分高权操作能力，紧急情况可自行决定操作。 54 | - 具有一定的数据分析和问题总结归纳能力，可以预估部分可能出现的异常并快速解决。 55 | - 持续改进的机制得到有效落实，内部培训体系尤其是服务意识宣导机制较为完善。 56 | 57 | 58 | 59 | #### 2.1.4 优化管理级最佳实践 60 | ##### 2.1.4.1 概述 61 | 建立了完善的、全流程的运维应急流程响应机制，实现部分自处理功能，并能从组织结构等方面全面支持，包括预案/流程/职责分工/定期演练等；能够按照PDCA的方法论及时发现不足并予以改进。 62 | 63 | 64 | ##### 2.1.4.2 最佳实践 65 | - 建立完善的、全流程的运维应急响应机制，实现部分自处理功能，以缩短处理时间，避免人为决策导致客户满意度降低； 66 | - 优化组织结构以支持应急响应机制，成立紧急行动小组，建立灵活、快速、合理、长期有效的重大故障及事件升级机制； 67 | - 及时发现流程中存在的问题并予以改进，持续提升服务水平； 68 | - 建立定期演练机制，在不通知的情况下，具备随时切换的能力。 69 | 70 | === 71 | 72 | ### 2.2 客户感知与导向能力最佳实践 73 | 用户价值是企业运营生存的核心竞争力，运维人员也同样需要以用户的视角评估开展工作，客户感知与导向也成为互联网技术人员必备的意识。对于运维而言服务好内外部用户，具备用户为先的价值观意识，技术运营才能更好的服务好业务运营。 74 | 75 | #### 2.2.1 可管理级最佳实践 76 | ##### 2.2.1.1 概述 77 | 客户感知与导向能力的可管理级（成熟度第二级），主要要求运维人员能够积极主动的开展各项工作，以高效职业的态度开始沟通协作是第一步。与客户（内部业务部门）顺利建立稳定的业务合作关系，满足内部各业务需求部门、合作方的日常需求。 78 | 79 | ##### 2.2.1.2 最佳实践 80 | - 运维人员积极主动的服务意识； 81 | - 透明高效的完成用户需求工作并及时的给与反馈； 82 | - 具有客户感知意识，能够将基本的客户新需求及满意度采集上来并汇总整理； 83 | - 要事为先，能够辨别工作的主次，以公司用户价值、品牌形象为重。 84 | 85 | #### 2.2.2 已定义级最佳实践 86 | ##### 2.2.2.1 概述 87 | 客户导向能力的可管理级（成熟度第三级），能够通过平台/工作流保障对用户的服务能力，对于需求的感知、分级、执行有明确的规范流程保障。对需求做到一定的分析、用户（内外）反馈数据跟进、深度的沟通以建立长期服务优化计划。 88 | 89 | ##### 2.2.2.2 最佳实践 90 | - 有效感知和控制需求及服务满意度，对用户端的服务与协作以标准化的流程统一交付。 91 | - 开展需求管理，对人员处理需求的效率、满意度、需求合理性进行分析，优化当前流程不足。 92 | - 通过收集用户反馈数据，发现运营过程问题并主动改进。如在需求管理平台具备满意度收集环节，根据反馈数据迅速安排改进优化；关注外网用户的不同分类投诉发现架构或流程中的不足，对用户数据分类、处理、回访。 93 | - 以周或月为单位定期发布感知报告。 94 | 95 | #### 2.2.3 量化管理级最佳实践 96 | ##### 2.2.3.1 概述 97 | 客户导向能力的量化管理级（成熟度第四级），能够深入分析识别关键需求，通过用户数据的有效运营，建立起用户端体验的可衡量指标，预警用户的潜在需求风险、性能体验等亚健康指标下降等，能够做到用户满意度的持续提高。 98 | 99 | ##### 2.2.3.2 最佳实践 100 | - 建立了用户感知体系，相关角色职责清晰，感知理念深入每个运维人心中； 101 | - 监控用户投诉日报/体验速度； 102 | - 关注灰度，减少用户的受伤害程度； 103 | - 监控关联建设，打通技术层和用户层。对变更、发布、配置加以更有效的控制； 104 | - 基于KPI等对感知信息进行量化分析，并预测客户需求变化和发展趋势。 105 | 106 | #### 2.2.4 优化管理级最佳实践 107 | ##### 2.2.4.1 概述 108 | 客户导向能力的优化管理级（成熟度第五级），长期通过建立用户为先/以用户价值为依归的团队价值观，宣导深入每一位成员的意识。建立在完善的用户满意度监控、用户全流程数据，能够更前瞻的发现隐患趋势并提出优化改进建议。通过专业能力的实践建立技术和用户价值的双赢。 109 | 110 | ##### 2.2.4.2 最佳实践 111 | - 具备完善的用户感知体系； 112 | - 根据感知信息分析，建立数据模型，发现和预测当前业务或服务中存在的问题与不足； 113 | - 关注长线的业务价值和用户价值，结合用户投诉数据的长线分析，提出优化改进建议，为业务部门提供建设性意见，为服务改进提供依据与契机，使服务更加精准、有效； 114 | - 技术改善用户体验带来业务价值，通过性能优化等提升销售额。 115 | 116 | === 117 | 118 | ### 2.3 熟悉业务能力最佳实践 119 | 熟练掌握业务是提供高效运维的基础。因此，需要充分理解服务或产品对用户产生的收益与价值，全面掌握业务知识，为用户提供专业、周到、快速、高效的服务。 120 | 121 | #### 2.3.1. 可管理级最佳实践 122 | ##### 2.3.1.1 概述 123 | 熟悉公司运营的产品，能够熟练掌握业务流程并能通过高效作业完成各项业务。 124 | 125 | ##### 2.3.1.2 最佳实践 126 | - 建立较为完善的业务培训机制，人员正式上岗前能接受较为系统的业务培训与辅导； 127 | - 提供服务的人员均具有较为扎实的业务水平，理论与实操考核均符合要求。 128 | 129 | #### 2.3.2 已定义级最佳实践 130 | ##### 2.3.2.1 概述 131 | 人员业务素质全面，能够编写指导手册、培训手册，并能指导用户快速完成各项操作或高效处理用户各类业务咨询。 132 | ##### 2.3.2.2 最佳实践 133 | - 各业务小组均能结合自身业务实际编撰指导手册、培训手册或常见问题手册； 134 | - 业务小组内部能够完成对新进人员的培训、辅导及考核，实现良性的动态业务传承。 135 | - 对用户在业务需求上的支持与处理高效，很少需要跨部门的处理。 136 | 137 | #### 2.3.3 量化管理级最佳实践 138 | ##### 2.3.3.1 概述 139 | 人员能够充分理解产品或服务的内涵，以及对用户产生的收益与价值，并能较为轻松评估各类业务对用户产生的影响范围及程度。 140 | 141 | ##### 2.3.3.2 最佳实践 142 | - 人员充分了解和掌握各类业务对用户的影响范围及程度； 143 | - 能够依据对用户的影响范围及程度采取合理的优先级予以业务响应； 144 | - 学习客户业务知识，了解和掌握客户业务变化和发展趋势。 145 | 146 | #### 2.3.4 优化管理级最佳实践 147 | ##### 2.3.4.1 概述 148 | 除做好自身的业务支持外，还能配合业务部门完成业务需求分析以及制定解决方案，促进业务及产品的优化升级。 149 | 150 | ##### 2.3.4.2 最佳实践 151 | - 能够配合业务部门完成业务需求分析以及制定解决方案； 152 | - 对业务部门的业务优化改进提出建设性意见； 153 | - 帮助业务部门从业务上优化完善产品或服务。 154 | 155 | 156 | === 157 | 158 | ### 2.4 沟通能力最佳实践 159 | 在基础运维被“云化”的趋势下，沟通能力显得愈加重要。成熟度模型中，级别不同，也使得要求不一。 160 | 161 | #### 2.4.1 可管理级最佳实践 162 | ##### 2.4.1.1 概述 163 | 被动式沟通为主，但建立在对业务知识有一定理解的基础上，了解运营需求的目的，快速把握要点并高效执行。 164 | 165 | ##### 2.4.1.2 最佳实践 166 | - 正确理解业务需求，如期完成业务需求，并及时反馈； 167 | - 过程预警：如无法按期完成，提前和业务方主动沟通，并达成一致； 168 | - 建立工单系统，方便进行工作跟进、结果反馈； 169 | - 建立客户满意度考核机制，和KPI及绩效挂钩。 170 | 171 | #### 2.4.2 已定义级最佳实践 172 | #####2.4.2.1 概述 173 | 理解需求并主动向上沟通或升级，以获取进一步资源提升对营销部门更好的服务结果。主动提供月报。 174 | 175 | #####2.4.2.2 最佳实践 176 | - 主动跟进与分析业务需求背后的更深层次原因，不再是简单地完成需求； 177 | - 按时或定期提供运维分析报告，协助运营提高效率、降低成本。 178 | 179 | #### 2.4.3 量化管理级最佳实践 180 | ##### 2.4.3.1 概述 181 | 掌握多种沟通技巧，能进行跨团队的高效沟通，并通过沟通表达可优化环节，主动组织、定期交流沟通、共同优化改进。 182 | 183 | ##### 2.4.3.2 最佳实践 184 | - 理解并贯彻执行高效沟通原理及技巧，理解三角桩子等沟通方法（参见《金字塔原理》等书籍）； 185 | - 善于站在其他团队或用户的角度，逆向思考和分析问题。 186 | 187 | #### 2.4.4 优化管理级最佳实践 188 | ##### 2.4.4.1 概述 189 | 出色的内外部跨团队多边沟通能力，协助公司营销部门的KPI拆解，大型项目有效及时的沟通，团队协作顺畅。 190 | 191 | ##### 2.4.4.2 最佳实践 192 | - 训练并获得高效沟通能力，以让运营部门愿意接受帮助； 193 | - 协助公司营销部门拆解KPI，实现高效团队协作。 194 | 195 | ### 2.5 响应与处理能力最佳实践 196 | 高效响应与处理能力的建立，需要多方面同时着手，本文重点阐述如何通过当面沟通、要事第一及一些指导原则来加以培养和提升。 197 | 198 | #### 2.5.1. 可管理级最佳实践 199 | ##### 2.5.1.1 概述 200 | 有统一的客户需求接收和响应机制，过程预警，及时通报。 201 | 202 | ##### 2.5.1.2 最佳实践 203 | - 建立服务台机制，以统一接收客户需求并规范化处理； 204 | - 建立基于工具的客户需求接收和响应机制，并通过邮件、短信等方式及时通知； 205 | - 过程预警：因技术等问题导致无法及时完成的任务，需及时和业务方沟通，取得一致； 206 | - 具有一定的技术支持力量（含外部供应商）。 207 | 208 | #### 2.5.2 已定义级最佳实践 209 | ##### 2.5.2.1 概述 210 | 采用多种技术手段，做到客户支持的简单、方便、透明，快速交付，使得客户无需关心技术细节。 211 | 212 | ##### 2.5.2.2 最佳实践 213 | - 对于经常性日程事务，建立自动化或自助化工具，提供处理效率； 214 | - 非数据库级别的程序版本更新部署，实现自助化，并交给业务方或研发人员自行部署，以实现透明化。 215 | - 提高沟通和处理问题能力，掌握用业务语言表述和处理问题的技巧，避免将技术问题暴露给非技术人员。 216 | 217 | #### 2.5.3 量化管理级最佳实践 218 | ##### 2.5.3.1 概述 219 | 清晰定义响应和处理时长，根据历史数据和所掌握的业务技能，预判客户需求并主动实现，在客户提出需求之前即已完成，并具备快速交付的能力。 220 | 221 | ##### 2.5.3.2 最佳实践 222 | - 清晰定义出各类请求的响应和处理时长要求，能够高效响应并处理各类请求和业务需求。 223 | - 掌握预判客户需求的技巧，学习了解客户需求背后的需求，并尝试提前解决。 224 | - 经常和客户主动沟通，沟通内容不限于技术和业务本身。 225 | - 根据当前数据预测未来业务量，提前做好应对准备。 226 | 227 | #### 2.5.4 优化管理级最佳实践 228 | ##### 2.5.4.1 概述 229 | 根据历史数据分析及自身经验积累，积极主动的发现客户在业务和流程上的问题，帮助或指导客户提升业务能力。 230 | 231 | ##### 2.5.4.2 最佳实践 232 | - 通过数据分析和监控等措施先于用户发现存在的风险、隐患或问题，并采取措施予以处置； 233 | - 根据数据分析，建立数据模型，预测和发现客户业务及流程的问题； 234 | - 根据既往经验及数据分析结果，帮助客户查漏补缺，指导客户提升业务能力，提高主动服务水平。 235 | 236 | 237 | 238 | 239 | 240 | 241 | -------------------------------------------------------------------------------- /Chapter 7 Cost Service.md: -------------------------------------------------------------------------------- 1 | # 第七章 运维成本服务 2 | ### 本章起草人：梁定安（腾讯SNG运维负责人） 3 | 4 | ## 1. 整体框架 5 | 6 | ### 1.1 概述 7 | 8 | 运维团队的核心职责：质量、效率、成本，成本管理是应用运维团队很重要的能力之一，本规范将介绍成本管理的三大能力模型的不同成熟度模型，引用行业最佳实践，为读者提供更通俗易懂的参考。 9 | 10 | ![](http://7xl5e0.com1.z0.glb.clouddn.com/C7001.jpg) 11 | 12 | 图片地址：http://7xl5e0.com1.z0.glb.clouddn.com/C7001.jpg 13 | 14 | ### 1.2 框架图 15 | 16 | ![](http://7xl5e0.com1.z0.glb.clouddn.com/C7002.jpg) 17 | 18 | 图片地址：http://7xl5e0.com1.z0.glb.clouddn.com/C7002.jpg 19 | 20 | ## 2. 最佳实践 21 | ### 2.1 设备成本管理能力 22 | 23 | 在应用运维的成本管理能力模型中，设备与带宽的管控能力是最能体现运维对运营成本的管控水平的两项，本章节通过应用运维对设备成本管理的案例，阐述设备管理能力在不同能力模型分级的实践经验。 24 | 25 | #### 2.1.1 可管理级最佳实践 26 | ##### 2.1.1.1 概述 27 | 设备成本的可管理级，主要是设备规模不大、设备运营成本未成为运营成本主要矛盾的阶段下，应用运维团队被动对设备成本的管控状况。 28 | 29 | ##### 2.1.1.2 最佳实践 30 | - 被动响应需求式的支持设备成本管理任务。 31 | - 使用离线工具来完成设备成本的统计、核算、分类等工作，如excel等表格类软件。 32 | - 设备管理线下流程化，如“统一硬件机型管理标准”，“制定设备采购、使用、退役管理流程”，“设备预算核算管理办法”，以保证设备的流转有据可依。 33 | 34 | 设备成本可管理级，对精细化管理的要求不高，能实现对硬件成本的核算和利用率提高即可达到此成熟度模型的要求。 35 | 36 | #### 2.1.2 已定义级最佳实践 37 | ##### 2.1.2.1 概述 38 | 设备成本管理在第三级已定义级的阶段，应用运维团队重点是通过建设管理系统来强化设备成本的线上管理能力，逐渐从离线工具管理升级为设备系统管理，此系统可与CMDB配置管理数据库关联设备资产信息，为设备成本管理效率提升埋下坚实的基础。 39 | 40 | ##### 2.1.2.2 最佳实践 41 | 设备成本管理系统通常应具备：预核算管理、业务归属管理、设备分布管理、趋势分析管理、容量度量等功能。 42 | 43 | ![](http://7xl5e0.com1.z0.glb.clouddn.com/C7003.jpg) 44 | 45 | 图片地址：http://7xl5e0.com1.z0.glb.clouddn.com/C7003.jpg 46 | 47 | - 预核算管理，主要是对业务使用的设备总成本进行管理，在设备成本合理使用的前提下，充足的设备预算能够支撑业务的快速发展。 48 | - 业务归属管理，用于记录与区分不同业务线使用的设备管理能力，便于设备成本核算时，能够快速且准确将总的设备运营成本拆分到具体不同的业务线。 49 | - 设备分布管理功能，主要在宏观层面对整体设备分布进行统筹管控，便于因地制宜的做好设备预算规划，让业务发展与设备使用的诉求密切关联，并且更好的指导运营规划团队的IDC规划。 50 | - 趋势管理功能，以图表的形式体现业务在不同时间点的设备成本走势，便于运维更好管控设备的库存量和采购量。 51 | - 容量度量功能，根据硬件设备的主要性能特征，对设备使用的合理性进行度量，以保证设备成本的真实使用情况都被运维掌控。 52 | 53 | 通过设备管理系统的建设，应用运维可以很便捷实现设备成本的管控，并可制定成本定期review方案，让设备运营成本管理更加清晰透明。 54 | 55 | #### 2.1.3 量化管理级最佳实践 56 | ##### 2.1.3.1 概述 57 | 设备成本量化管理级，是根据公司和业务的成本管理要求，在已定义级的管理系统基础上，制定恰当的指标并度量各个业务线设备成本的使用情况，让业务运维和开发能够基于此目标开展相应的技术优化工作，使企业设备成本 58 | 59 | ##### 2.1.3.2 最佳实践 60 | 度量与考核设备成本的合理性，推进优化技术使企业设备使用结构最优化，可以有几个办法： 61 | 62 | - 容量指标管理，利用容量度量功能，制定符合企业成本管理要求的管理方案，在兼顾运维质量与效率的前提下，优化设备成本。如多核CPU负载不均，通过设置CPU绑定或亲和性优化。 63 | - 灵活的资源管理，根据业务特性灵活组合或分配设备硬件资源，已达到设备使用结构最合理化。如CPU计算型服务与存储型服务混合部署，使用虚拟化技术将硬件资源碎片化利用等。 64 | - 技术架构革新，如同步调用优化为异步调用，利用分布式架构优化性能瓶颈等。 65 | - 产品策略与技术优化并重，在特定的场景下产品策略的调整比技术优化效果更显著。如离线计算比实时计算更容易节省设备资源。 66 | 67 | ![](http://7xl5e0.com1.z0.glb.clouddn.com/C7004.jpg) 68 | 69 | 图片地址：http://7xl5e0.com1.z0.glb.clouddn.com/C7004.jpg 70 | 71 | #### 2.1.4 优化管理级最佳实践 72 | ##### 2.1.4.1 概要 73 | 通过数据分析，精确预测与业务发展相符的设备成本，引入新技术、自动化等能力，使设备成本管理步入智能化阶段。 74 | 75 | ##### 2.1.4.2 最佳实践 76 | （暂无） 77 | 78 | === 79 | 80 | ### 2.2 带宽成本管理能力 81 | 带宽成本在公司IT成本管理中与设备成本的重要性一致，对于互联网公司而言，带宽成本如控制不当会造成巨大的浪费，本节重点从技术手段和产品策略两个角度阐述带宽优化的实践理论。 82 | 83 | #### 2.2.1 可管理级最佳实践 84 | ##### 2.2.1.1 概要 85 | 带宽成本可管理级，应用运维团队应该熟知运营商对带宽的计费规则，包含CDN和IDC分别使用带宽成本结构，根据公司各个业务使用带宽的情况，能按要求计算出带宽成本数据。（备注：CDN带宽比IDC带宽价格更低，在带宽使用整体数量不变的前提下，CDN带宽占比重越大，企业带宽成本越低。“CDN带宽消耗”下文简称OC带宽，“IDC带宽消耗”下文简称DC带宽）。 86 | 87 | ##### 2.2.1.2 最佳实践 88 | - 响应需求式的支持设备成本管理任务，需明确带宽月度计费规则。如OC与DC的选型，OC或DC带宽成本计费方案的不同。 89 | - 使用离线工具来完成带宽成本的统计、核算、分类等工作，如excel等表格类或画图类软件。 90 | - 带宽管理流程化。如制定“带宽预核算管理办法”等规则，以保证带宽成本可控。 91 | 92 | #### 2.2.2 已定义级最佳实践 93 | ##### 2.2.2.1 概要 94 | 带宽成本已定义级，运维团队根据带宽管理需要，建设带宽成本管理系统，提升对带宽管控能力。 95 | 96 | ##### 2.2.2.2 最佳实践 97 | 带宽成本管理系统通常需要包含如下几大功能：预核算管理、业务归属管理、趋势管理等功能。 98 | 99 | - 预核算管理，主要是对业务使用的OC和DC带宽进行月度/年度的预测与核算，让业务使用带宽有计划与可控。如年度带宽预算管理与月度带宽核算管理。 100 | - 业务归属管理功能，基于CMDB系统，对带宽计算相关的外网IP地址或域名等配置项与业务关联起来，为带宽成本预核算提出数据支持； 101 | - OC与DC管理功能，带宽成本有OC与DC两种，针对不同的使用场景，管理系统应有能力区分统计。 102 | - 趋势管理功能，记录在不同时间点带宽的走势，便于运维核对带宽的实际使用与业务指标的发展管理。 103 | 104 | 通过带宽管理系统的建设，应用运维可以很便捷的实现带宽成本的管控，并可制定成本定期回顾方案，让带宽运营成本管理更加清晰透明。 105 | 106 | #### 2.2.3 量化管理级最佳实践 107 | ##### 2.2.3.1 概述 108 | 带宽使用可度量，带宽成本的合理性将成为成本考核的要求。推进技术优化，促使带宽使用最优化，是量化管理级成熟度模型的重点。 109 | 110 | ##### 2.2.3.2 最佳实践 111 | - OC与DC带宽结构合理配比，提升OC命中率，降低DC带宽占比，有利于带宽总成本下降。如扩容OC缓存的能力，用更廉价的OC换DC的带宽消耗。 112 | - 技术架构革新，如协议级优化，图片webP压缩，视频码率降低等。 113 | - 产品策略配合技术优化，如业务下载限速，分片下载等策略。 114 | - 安全策略，如限制外链，扫黄打非。 115 | 116 | 提前预防在带宽成本的管控中尤为重要，因为带宽成本与设备成本管理不同，带宽是事后计费的，往往我们发现考核不符合预期时，已经产生了较预算更高的费用。因此，对带宽成本的管控应技术先行，保证更精细化与最优化。 117 | 118 | #### 2.2.4 优化管理级最佳实践 119 | ##### 2.2.4.1 概述 120 | 带宽成本优化管理级，要求应用运维团队根据业务特性不同，通过数据分析，精确预测与业务发展相符的带宽成本，应用运维团队要多与产品、开发沟通，寻找用户体验和带宽成本消耗的最优性价比方案，并持续革新运维能力，使带宽成本管理迈入智能化阶段。 121 | 122 | ##### 2.2.4.2 最佳实践 123 | (暂无) 124 | 125 | === 126 | 127 | ### 2.3 运维服务交付成本管理能力 128 | 运维团队的核心职责是为业务交付“质量、效率、成本”的优质服务，运维服务交付成本最优化是运维自身的能力建设成果的体现，交付能力包括：服务化能力、架构能力、监控能力、自动化能力等纬度，本节将展开阐述交付成本管理能力的细节。 129 | 130 | #### 2.3.1 可管理级最佳实践 131 | ##### 2.3.1.1 概述 132 | 运维服务交付管理在可管理级阶段，业务规模与设备规模相对不大，业务对运维的能力要求相对不高，运维被动响应发布变更、监控、故障处理等需求，围绕着有限的服务目录，交付运维能力服务。 133 | 134 | ##### 2.3.1.2 最佳实践 135 | - 交付基础运维能力，为业务提供系统运维服务。如系统重装、进程管控、软件安装等。 136 | - 交付基础监控能力，如基础硬件性能监控、进程端口监控等。 137 | - 交付硬件设施管理能力，如设备选型与交付管理、宕机维护、备件替换等。 138 | - 交付排障能力，如容量恢复、硬盘空间清理等能力。 139 | 140 | #### 2.3.2 已定义级最佳实践 141 | ##### 2.3.2.1 概述 142 | 应用运维团队在已定义级阶段，将明确对业务交付的标准化服务目录，服务范围较可管理级有扩大，围绕着服务目录中的交付能力进行系统化或工具化的支持，降低运维能力的交付成本。非运维服务目录包含的工作也会逐渐被纳入标准化运维规范中，朝更低交付成本的运维系统中转移。 143 | 144 | ##### 2.3.2.2 最佳实践 145 | 146 | ![](http://7xl5e0.com1.z0.glb.clouddn.com/C7005.jpg) 147 | 148 | 图片地址：http://7xl5e0.com1.z0.glb.clouddn.com/C7005.jpg 149 | 150 | - 运维效率系统，这是通用的运维能力，运维提供系统化的能力支持，高效高质量的实现业务变更需求。如持续部署系统等。 151 | - 运维监控系统，业务质量的监控、告警、度量能力，通过运维监控系统的建设，将以服务化的形式交付给业务团队使用。如系统级监控、应用级监控。 152 | - 事件管理系统，定义生产环境的突发事件，并且制定适宜的流程管理办法与责任人制，让每个会影响业务质量或运维质量的问题都能得到根治。 153 | - 需求流程系统，对于未能实现系统化交付的运维能力，通过制定需求流程规则，承诺交付完成时间（SLA）和完成质量，以达到业务方需求被有序并高效的响应和处理。 154 | 155 | #### 2.3.3 量化管理级最佳实践 156 | ##### 2.3.3.1 概述 157 | 运维提出标准化组件管理规范，围绕标准化建立运维平台，运维能力以产品化或服务化的模式提供，业务遵守运维规范要求，便能享受高效的运维服务。此成熟度模型下，对业务提出高标准化的管理要求，逐渐将运维对象收拢并统一管理。 158 | 159 | ##### 2.3.3.2 最佳实践 160 | 161 | ![](http://7xl5e0.com1.z0.glb.clouddn.com/C7006.jpg) 162 | 163 | 图片地址：http://7xl5e0.com1.z0.glb.clouddn.com/C7006.jpg 164 | 165 | - 运维效率系统，常用操作从自动化服务逐渐升级为智能化服务，运维效率系统联动监控系统智能决策自动化事件的触发，并以质量系统的结果度量智能决策的效果。 166 | - 运维质量系统，根据经验模型对异常事件进行自动化修复，业务质量具备自愈能力，未知的异常事件将被快速识别并告警，质量度量由监控异常迈入监控未知问题阶段。如运维聚焦未知问题，已经故障都将由经验模型自动化修复，无需人为介入。 167 | - 需求流程系统，运维非自动化的能力服务化，以接口调用的形式串联需求涉及的每个环节，降低人工操作的成本。 168 | - 事件管理系统，突发事件将智能关联所有与之相关的监控异常信息，数据来源于运维效率系统和运维质量系统，使突发事件在产生的同时结论也将被负责人一并获知。 169 | 170 | 运维交付能力在量化管理级阶段，主要强调不同运维能力系统间的相互对接与合作，基于更强大更多维度的数据整合，运维服务能力进入智能化时代。 171 | 172 | #### 2.3.4 优化管理级最佳实践 173 | ##### 2.3.4.1 概述 174 | 通过架构能力和运维平台能力的不断优化提升，运维交付能力步入智能决策和全自动化时代，运维服务交付成本最低。 175 | 176 | ##### 2.3.4.2 最佳实践 177 | （暂无） 178 | 179 | 180 | 181 | 182 | 183 | -------------------------------------------------------------------------------- /Chapter 8 User Experience Service.md: -------------------------------------------------------------------------------- 1 | # 第八章 用户体验服务 2 | 3 | ### 本章起草人：涂彦（腾讯互娱运维总监，智能运维提出方） 4 | 5 | ## 1. 整体框架 6 | 7 | ### 1.1. 概述 8 | 用户体验服务是应用运维体系中的一项进阶能力要求，它来源于对用户在接触互联网产品、系统、服务的过程中，所产生的反应与变化。在互联网行业蓬勃发展的今天，本规范希望在大家认识用户体验重要性的同时，一起让运维工作在运营过程中更好服务于产品的用户体验，产生更多的服务价值。 9 | 10 | ### 1.2 框架图 11 | 基于用户体验的服务能力，分解如下表： 12 | 13 | ![](http://7xl5e0.com1.z0.glb.clouddn.com/C8001.jpg) 14 | 15 | 图片地址：http://7xl5e0.com1.z0.glb.clouddn.com/C8001.jpg 16 | 17 | ## 2. 最佳实践 18 | ### 2.1 业务认知能力 19 | #### 2.1.1 可管理级最佳实践 20 | ##### 2.1.1.1 概述 21 | 应用运维部门需要清晰认识到用户体验服务的主体是用户，通过对用户在业务运营过程中产生的各类行为数据进行有效地分析，能够从处理过的各类故障及事件中分辨出哪些属于用户体验面临和需要解决的问题。 22 | 23 | ##### 2.1.1.2 最佳实践 24 | - 建立统一、集中的故障事件库， 包括故障类型、业务名称、影响级别、影响范围、故障描述、故障来源、故障时间、故障处理记录等。 25 | - 在已处理故障中，需要进行将影响用户体验的相关故障及事件进行统计与分析的工作。 26 | - 在进行统计与分析用户体验相关故障及事件中，需要进行将故障及事件与用户体验某类问题匹配的工作。 27 | - 在与用户体验某类问题匹配过程中，需要形成该体验类问题的解决方案。 28 | 29 | #### 2.1.2 已定义级最佳实践 30 | ##### 2.1.2.1 概述 31 | 通过对用户体验类问题的不断分析、汇总和积累，需要将一个个点的问题逐步整合形成面，而这些面恰恰定义了用户的不同场景体验，运维要找出不同场景体验中可以度量的数据指标。 32 | 33 | ##### 2.1.2.2 最佳实践 34 | - 定义业务在运营中，关键路径和非关键路径之间不同的用户体验场景。 35 | - 定义每个体验场景中可以用来度量体验健康程度的数据指标。 36 | - 将用户体验场景有序串联，形成阶段性的用户行为轨迹。 37 | - 在关键路径和非关键路径的体验场景中通过体验数据指标进行动态的管控，并设置告警进行实时发现与处理。 38 | - 除本身体验数据外，还需要关联体验场景以外的数据，比如网络、软硬件性能、玩家状态等数据，尽可能全面完整判断体验问题的原因。 39 | 40 | #### 2.1.3 量化管理级最佳实践 41 | ##### 2.1.3.1 概述 42 | 运维能通过对业务全面的认知，准确定义业务在运营过程中的完整体验场景，同时运用衡量数据指标来准确分析原因以及给出解决方案 43 | 44 | ##### 2.1.3.2 最佳实践 45 | - 规划设计符合业务全生命周期的用户体验管理方案，通过组件和平台系统来管理业务不同阶段的体验优化。 46 | 47 | 48 | #### 2.1.4优化级最佳实践 49 | ##### 2.1.4.1 概述 50 | 运维对用户体验管理由业务的运营期应对提前到业务的筹备阶段规划，与项目开发就用户体验进行更早期更全面的管理设计。 51 | 52 | ##### 2.1.4.2 最佳实践 53 | 暂无 54 | 55 | ==== 56 | 57 | ### 2.2 数据管理能力 58 | #### 2.2.1 可管理级最佳实践 59 | ##### 2.2.1.1 概述 60 | 根据以往处理经验进行判断并解决，恢复后通过事故前后数据变化来验证和总结，以此说明用户体验恢复的结果。 61 | 62 | ##### 2.2.1.2 最佳实践 63 | - 将影响用户体验的事件按一定原则归类，并对应上每一类事件的技术解决方案，持续优化，不断完善。 64 | - 记录每次事件中用户体验受影响前后关联的数据变化情况，从技术方案角度分析和阐述清楚用户体验的变化趋势。 65 | 66 | #### 2.2.2 已定义级最佳实践 67 | ##### 2.2.2.1 概述 68 | 通过已经积累的经验建立监控、告警系统，持续优化策略，主动发现体验异常。 69 | 70 | ##### 2.2.2.2 最佳实践 71 | - 在积累一定的影响用户体验影响事件库和技术解决方案库后，逐步建立不同类型事件的体验数据指标，用于衡量较好的用户体验标准。 72 | - 建立监控、告警系统，根据不断积累和持续优化的用户体验衡量指标，制定监控与告警所需的不同体验数据标准阀值，在业务运营过程中持续进行监控，并进行异常的主动处理。 73 | - 创建和定义该业务运营过程中用户体验的不同场景，在这些场景中形成可度量的数据指标，这些指标包括并不限于：指标定义、计算公式、数据源、指标说明等。对于通过系统二次计算而来的数据指标需要明确详细说明。 74 | - 持续提升数据平台能力，即采集/处理/分析过程中的能力，例如建立标准的数据上报机制，建立分层数据标准模型，建立自定义的数据dashboard展现机制，让研测运可以完成业务指标的分析展现能力。 75 | 76 | #### 2.2.3 量化管理级最佳实践 77 | ##### 2.2.3.1 概述 78 | 根据不同的体验场景制定相应的指标模型以及度量指标体系，在实际业务运营过程中，利用数据管理用户体验。 79 | 80 | ##### 2.2.3.2 最佳实践 81 | - 依据场景和数据指标，建设数据采集、统计、分析、展示的综合系统，全面、立体、多维度展示用户体验的健康状况，包括并不限于：基础体验比如下载、登陆、支付等。核心体验比如使用业务核心功能的体验数据等。甚至舆情、口碑等评价数据。 82 | - 不断完善用户体验管理系统，重点建设数据从采集、预警到分析、跟踪的整体能力，需要做到问题发现、问题分析、问题跟踪的关键环节全部数据化。 83 | 84 | #### 2.2.4 优化管理级最佳实践 85 | ##### 2.2.4.1 概述 86 | 通过用户体验管理系统，不断完善数据驱动解决问题的能力，同时提供同类型多业务的数据基线服务。 87 | 88 | ##### 2.2.4.2 最佳实践 89 | 暂无 90 | 91 | === 92 | 93 | ### 2.3 体验优化能力 94 | #### 2.3.1可管理级最佳实践 95 | ##### 2.3.1.1 概述 96 | 应用运维部门能够针对用户体验问题的报告，运用运维技术和业务经验，进行及时处理、事后分析与总结。 97 | 98 | ##### 2.3.1.2 最佳实践 99 | - 根据以往处理过的事件以及故障，形成基于用户体验事件处理的技术方案库。 100 | - 每次用户体验事件的处理都可以进行及时的总结与分析，并通过脚本工具形成循环的任务执行，对于已知固定问题持续监控和处理。 101 | 102 | #### 2.3.2 已定义级最佳实践 103 | ##### 2.3.2.1 概述 104 | 将用户体验管理的工作覆盖到业务全生命周期，形成应对策略与方案，并持续建设数据类工具。 105 | 106 | ##### 2.3.2.2 最佳实践 107 | - 根据以往经验和历史数据，与产品团队就业务生命周期的用户体验问题形成功能设计层面上的持续优化的应对策略与解决方案。 108 | - 根据以往经验和历史数据，与开发团队就业务生命周期的用户体验问题形成模块开发层面上的持续优化的应对策略与解决方案。 109 | - 根据与产品团队和开发团队制定的策略与方案，持续建设数据采集组件、数据存储、统计、分析、展示等工具，通过工具发现问题并推动用户体验的改善。 110 | - 通过不同类型多业务的用户体验管理经验，寻找业务间的共性与差异，形成同类型业务、不同类型业务之间，可以作为用户体验管理度量标准的数据指标。 111 | 112 | #### 2.3.3 量化管理级最佳实践 113 | ##### 2.3.3.1 概述 114 | 在熟练管理单业务能力基础上，建设全类型全业务的用户体验管理的能力，以提供更多业务可参考的用户体验基线数据服务。 115 | 116 | ##### 2.3.3.2 最佳实践 117 | - 通过系统，持续提供用户体验基线数据服务，帮助项目团队在策划与开发环节更早规避问题进行合理设计。 118 | - 所有体验类数据、关联数据，形成采集、存储、统计、分析、预测并涵盖不同用户体验场景，通过监控与告警及时、准确发现，围绕合理的技术方案进行处理、跟踪、反馈等自动化处理。 119 | 120 | #### 2.3.4 优化管理级最佳实践 121 | ##### 2.3.4.1 概述 122 | 通过建设完善的工具系统，形成用户体验管理的智能闭环处理。 123 | 124 | ##### 2.3.4.2 最佳实践 125 | 126 | === 127 | 128 | ### 2.4 方案沉淀与标准形成能力 129 | #### 2.4.1 可管理级最佳实践 130 | ##### 2.4.1.1 概述 131 | 运维需要具备局部跨业务管理用户体验的能力。 132 | 133 | ##### 2.4.1.2 最佳实践 134 | - 根据不同业务的已知用户体验问题事件，逐步定义部分跨业务的用户体验场景及其可以度量的数据指标集。 135 | - 根据定义好的局部业务体验场景和数据指标制定通用的技术解决方案，并持续优化和完善。 136 | - 所有已定义场景、数据指标变化以及解决方案需要被长期记录在系统中。 137 | 138 | #### 2.4.2 已定义级最佳实践 139 | ##### 2.4.2.1 概述 140 | 运维需要具备全局跨业务管理用户体验的能力。 141 | 142 | ##### 2.4.2.2 最佳实践 143 | - 根据不同业务的已知用户体验问题事件以及业务产品模型，逐步定义全局跨业务的用户体验场景及其可以度量的数据指标集。 144 | - 根据定义好的全局跨业务体验场景和数据指标制定通用的技术解决方案，并持续优化和完善。 145 | - 持续建设用户体验管理平台系统，记录和完善场景、指标、方案等。 146 | - 根据定义好的全局用户体验场景，建设全局用户体验健康视图，同时在不同场景中定义不同的健康指数，并通过健康指数实时监控、发现和处理各类事件与问题。 147 | 148 | 149 | #### 2.4.3 量化管理级最佳实践 150 | ##### 2.4.3.1 概述 151 | 持续完善用户体验管理平台系统，从不同用户体验维度出发，推动运维技术工作的深度建设。 152 | 153 | ##### 2.4.3.2 最佳实践 154 | - 从全局用户体验场景中区分基础用户体验与核心用户体验，针对基础用户体验管理，推动相同业务在软硬件、网络等运维环境中的持续优化，针对核心用户体验管理，推动不同业务在产品策划、功能设计、模块开发等环境中的持续优化。 155 | - 提供各类体验度量指标与场景模型，参与业务的产品规划设计前期定型工作，并对产品核心功能在用户使用行为中起到关键影响。 156 | - 覆盖到不同的用户类型，可以针对不同用户类型，比如普通活跃用户、核心活跃用户、流失用户等进行从群体到个体的用户体验管理与跟踪。 157 | 158 | 159 | #### 2.4.4 优化管理级最佳实践 160 | ##### 2.4.4.1 概述 161 | 通过用户体验管理系统平台，提供不同类型业务在全生命周期从设计到运营各个阶段所需的用户体验类数据及模型参考，精准管理更加细分化的用户体验问题。 162 | 163 | ##### 2.4.4.2 最佳实践 164 | 暂无 165 | 166 | 167 | 168 | 169 | 170 | 171 | 172 | 173 | -------------------------------------------------------------------------------- /Chapter 9 HA Service.md: -------------------------------------------------------------------------------- 1 | # 第九章 高可用架构服务 2 | 3 | ### 本章起草人：孙宇聪（coding.net CTO, 原Google SRE） 4 | 5 | ## 1. 整体框架 6 | ### 1.1 概述 7 | 运维团队是一个公司最贴近生产一线的技术部门。运维团队对高可用软件架构、高效公司研发体系有强烈的需求和最多的实践经验。运维团队是架构改造、可用性改造上最有话语权的团队。本规范将介绍运维团队针对设计和实践高可用架构中几个不同类别的成熟度模型，引用行业中的最佳实践，为读者提供通俗易懂的参考。 8 | 9 | ### 1.2 框架图 10 | 11 | ![](http://7xl5e0.com1.z0.glb.clouddn.com/C9%20001.png) 12 | 13 | 图片地址：http://7xl5e0.com1.z0.glb.clouddn.com/C9%20001.png 14 | 15 | ## 2. 最佳实践 16 | ### 2.1 研发流程优化 17 | 应用运维团队应当积极参与研发流程的每一个环节,力争在优化流程、改善沟通、推行自动化等方面为整个业务研发流程贡献力量，以达到最快最好的实现业务价值的共同目标。 18 | 19 | #### 2.1.1 可管理级最佳实践 20 | ##### 2.1.1.1 概述 21 | 达到可管理级，应用运维团队应当积极参与业务开发计划，了解开发交付周期进度安排，能够确保运维团队有足够的人力，时间，以及工具配合完成业务需求。运维团丢需要能够及时获取资源、执行变更以帮助应用开发团队及时交付既定目标，确保新业务按时、安全上线。 22 | 23 | ##### 2.1.1.2 最佳实践 24 | - 运维团队应该针对业务需求，做好基础架构选型工作，与开发团队共同选型业务中用到的第三方云服务提供商，第三方硬件等，确保运维团队在业务交付后有足够的人力、能力管理这些第三方服务，或者有充分准备时间学习和了解这些服务。 25 | - 运维团队应该参与开发团队计划排期，确保运维团队有足够的时间理解新业务需求，帮助确认资源，评估变更执行难度，保障交付时运维团队有足够人力、资料执行变更。 26 | - 了解、参与应用开发团队的产品测试流程。运维团队一方面可以增强对新业务的理解，另一方可以帮助产品团队完善测试体系，及时找到性能，可用性，可管理性等方面的缺陷，帮助产品团队提高交付质量。 27 | 28 | #### 2.1.2 已定义级最佳实践 29 | ##### 2.1.2.1 概述 30 | 进入已定义级，应用运维团队应该与开发团队在整个开发过程中形成了有效的互相沟通体制，形成了一套有效的信息共享模式，开发团队及时将业务方面最新需求同步给运维团队，运维团队能及时为开发团队提供反馈，确保实际交付物满足运维团队操作需求。 31 | 32 | ##### 2.1.2.2 最佳实践 33 | - 运维团队可以辅助开发团队选择一套测试框架，积极投入力量与开发团队共同开发维护一套标准的压测工具和流程，确保可能存在的性能问题在测试阶段提前显现，提前解决。 34 | - 运维团队应该在自动化等方面大力投入，确保开发团队也能使用运维开发的自动化工具在离线测试环境中自主执行测试、部署、更新，加快迭代速度，提升交付质量。 35 | - 运维团队可以辅助开发团队进行模拟灾难测试，找到整个业务的关键弱点，及时发现软件可用性、可靠性设计上的缺陷，将问题提前暴露，与开发部门共同商议优化。 36 | 37 | #### 2.1.3 量化管理级最佳实践 38 | ##### 2.1.3.1 概述 39 | 进入量化管理级，应用运维团队与开发团队应该共同量化业务开发和交付过程的各项指标，针对整个流程上的弱点有的放矢的投入人力，确保业务开发过程与交付的顺畅与安全。 40 | 41 | ##### 2.1.3.2 最佳实践 42 | - 应用运维团队应当积极推进建立一套生产环境接受性标准 (Production Acceptance Test)，为业务组件确立相关的性能基线，确保开发部门交付质量可以经过量化测试，及时暴露性能隐患、算法缺陷，架构问题等，避免上线过程中和上线之后造成事故。 43 | - 应用运维团队应该在系统可靠性、可用性测试上投入精力。针对业务特点模拟一些可预知的灾难场景，如数据库查询变慢，流量过载，网络延迟增加等等，将问题场景提前暴露，确保开发团队有足够的数据和切实的环境来解决这些问题。 44 | 45 | #### 2.1.4 优化管理级最佳实践 46 | ##### 2.1.4.1 概述 47 | 应用运维部门应该持续不断的参与优化整个研发流程，推行敏捷开发实践，提升迭代速度。应用运维团队应该时刻和开发团队保持同步，互相学习互相促进，共同利用更先进的技术、创新理念优化业务交付的整个过程。 48 | 49 | 应用运维部门应该确保与最终用户体验保持一致，确保业务部门所有的开发力量、运维力量都是在为业务效果最优化努力。 50 | 51 | ##### 2.1.4.2 最佳实践 52 | 无 53 | 54 | === 55 | 56 | ### 2.2 生产系统管理/变更管理 57 | 运维团队最重要的职责就是管理生产环境和实施业务团队需要的变更。高效、有效的组织和管理变更，是运维团队的第一要务。 58 | 59 | #### 2.2.1 可管理级最佳实践 60 | ##### 2.2.1.1 概述 61 | 运维团队全面接管生产系统的管理权是第一步。刚刚建立的运维团队经常处于有职无权，被动接受的情况。开发团队经常绕过团队直接操作生产环境。要达到可管理级阶段，运维团队必须要做到全程介入，并且在参与的过程中整理、总结、统一各种资源的管理、配置、建立其一套自己的资源管理规范。 62 | 63 | ##### 2.2.1.2 最佳实践 64 | - 运维团队应该推动建立一套统一的、完备的、命名规则和管理体系。初期做到文档化，未来可以实现代码化，为最终的自动化打基础。 65 | - 运维团队内部对程序的配置文件等形成了一套标准流程，放入VCS中管理，可以做到有记录的跟踪变更。 66 | - 运维团队应推动业务部门建立起完整的离线测试环境、可以做到离线构建、离线验证。进一步减少在线部署的出错几率。 67 | - 运维团队应该主动推进对变更频率的调整。
由经验得知，80% 生产环境的问题都是由新的变更引起的，而且其中80% 的问题是在部署后24小时之内就可以发现并再次需要部署。运维团队应该有计划，有目的的减少变更频率，与产品研发团队达成一致意见，共同寻找一个平衡点，给产品团队充足的时间完成本地测试、集成测试。另一方面，给运维团队留出时间优化部署流程、增加监控信号源，建立基础架构，而不是整天疲于奔命的执行变更。 68 | 69 | #### 2.2.2 已定义级最佳实践 70 | ##### 2.2.2.1 概述 71 | 进入已定义级，运维团队的重点应该放在变更管理的规范化、标准化、自动化上。运维团队和开发团队制定了固定的发布计划、有计划的实施变更。 72 | 73 | ##### 2.2.2.2 最佳实践 74 | - 运维团队应该有计划的建立一套变更评审流程，对生产环境的各种改变，做到有据可依，有因可查。如果能做到风险评估、回滚预案等等就更好了。 75 | - 变更工具自动化、可重现性保障
运维团队应该着重强调提高自动化水平，将成功的流程、工具固化为标准流程、工具，确保每次变更执行可重现，可回退。做到整个流程可控。 76 | - 运维团队应该推动变更实施的自服务化：
运维团队的特殊性经常体现在拥有生产环境权限，是唯一能够“直接”操作生产环境的团队。但是这并不代表“所有”的 生产环境操作必须由运维团队完成。一个更好的目标可以是建立起一套自服务体系，把更新能力更多的还给开发团队。
例： Nginx 服务器的配置管理很多时候是由运维团队完成的，但是某个业务内部的一些转发逻辑、细节优化等如果完全需要运维团队参与维护会带来很多不必要的等待和沟通。一个更好的方式是建立起一个自服务系统，允许开发团队自己维护配置文件。运维团队将精力投入在 77 | 78 | 1. 对最终配置文件的自动和人工校验 79 | 2. 对最终配置文件的自动化测试、自动化更新和回滚系统的开发。 80 | 81 | 将运维团队对Nginx服务器配置的全职参与降低为审批型参与甚至不参与，将使运维团队发挥更大的作用。 82 | - 客户调查
作为运维团队，针对变更管理流程上也应该对服务的对象，也就是研发、产品团队做客户调查。加强自服务体系，提高流程的执行速度和可靠程度。 83 | 84 | 85 | #### 2.2.3 量化管理级最佳实践 86 | ##### 2.2.3.1 概述 87 | 变更管理的量化管理级，通常体现在对变更执行前后对生产环境的影响是否能够量化。在变更执行初期，可以很快的判断一次变更是否会对业务造成明显的影响，从而及早发现、处理由此带来的问题。 88 | 89 | ##### 2.2.3.2 最佳实践 90 | - 量化变更对业务的影响，关键点在于建立一套基线体系。
根据业务不同，运维团队应该着手收集、建立起一套监控体系， 收集不同信息源获得的各种信息。运维和开发共同制定一套明确的软件架构方案，架构包括对配置方式的统一、管理接口、监控接口的统一。运维团队要求新增业务组件必须重用此架构。
以 Coding 的一个后端服务器为例，在实践过程中，我们发现有主要几个信息源直接体现一个业务的健康程度: QPS / CPU： 作为一个计算重型的业务，QPS和CPU之间的比率是很基本稳定的。Peak Memory： 该服务长期占用固定数量的内存，随着load高低变动很小。为此，在执行变更之前我们一般先确立当前版本的性能基线，具体执行变更时除了关注业务功能外，密切关注新版本的实例在这两个重要指标上是否有变化。这样如果有性能问题可以及早让开发团队介入寻找问题根源，避免变更带来大规模的业务问题。 91 | 92 | - 变更执行自动化 Human Error是生产系统变更管理中最难排除的因素。就算有一个比较完善的变更执行文档，也会在执行过程中遇到各种各样的人为问题。只有将变更过程变成自动化的，将人放回到审核而不是执行的位置上才能本质上解决这个问题。将变更执行流程自动化的过程，也带来更好的研发、测试体验。 93 | 94 | #### 2.2.4 优化管理级最佳实践 95 | ##### 2.2.4.1 概述 96 | 变更管理是运维部门的第一要务，是最值得花费时间、人力、物力优化的方向。运维团队应该持续不断的集思广益，收集新思路，将变更管理流程做的更好。进入优化级别，运维团队应该有能力推进工具化支持高级多维度灰度发布能力：支持A/B测试，自动化信号收集，多版本同时运行、动态切换等。 97 | 98 | ##### 2.2.4.2 最佳实践 99 | 暂无 100 | 101 | === 102 | 103 | ### 2.3 可管理性 104 | 可管理性是运维的部门关注的另一个重点。生产环境涉及的东西越多，运维部门的压力越大。运维部门应该集中提高各类资源、业务服务的可管理性，节省人力，提高效率，降低出错几率、为未来自动化打基础。 105 | 106 | #### 2.3.1 可管理级最佳实践 107 | ##### 2.3.1.1 概述 108 | 运维团队应该推动将所有业务服务的配置、启动、分发等方式统一化，在团队内部形成一套标准体系。这些事情有时候看起来很小，很琐碎，有时候甚至觉得不值得一做。但是聚沙成塔，如果团队成员要为每种业务记住各种各样不同的配置启动运维方式，不但增加运维团队知识共享的难度，也极大的提高了培养新成员的压力，更造成了各种各样自动化运维工具研发困难。运维团队应该在这件事情上坚持推动统一。 109 | 110 | ##### 2.3.1.2 最佳实践 111 | - 开发或者推行一套标准的启动配置方式， 统一命令行参数、环境变量的传递等程序的配置方式。 112 | - 推行运维系统自己维护、执行的一套完整的打包、配置、运行工具体系，力求做到跨组件、跨业务的统一。 113 | 114 | #### 2.3.2 已定义级最佳实践 115 | ##### 2.3.2.1 概述 116 | 进入已定义级，应用运维团队应该逐步推行一套明确的软件交付规范，推进配置方式的统一、管理接口、监控接口的统一。运维团队针对管理接口基本形成了一套半自动化的脚本、或者自动化的操作工具。对组件的监控接口基本形成了一套对应的数据收集、报警等能力。 117 | 118 | ##### 2.3.2.2 最佳实践 119 | - 推动建立一套CI系统， 自动从代码库构建推送配置文件到生产环境。 120 | - 利用容器化等技术实现基础架构的服务化和统一化 121 | - 利用Prometheus 等集中化的监控平台搭建一个模板化的监控环境 122 | 123 | #### 2.3.3 量化管理级最佳实践 124 | ##### 2.3.3.1 概述 125 | 进入量化管理级，应用运维团队应该逐步推行一套明确的软件交付规范，推进配置方式的统一、管理接口、监控接口的统一。运维团队针对管理接口基本形成了一套半自动化的脚本、或者自动化的操作工具。对组件的监控接口基本形成了一套对应的数据收集、报警等能力。 126 | 127 | ##### 2.3.3.2 最佳实践 128 | - 公司统一维护一套基础服务库或者框架。比如Coding内部推行的标准运行库，要求公司内部全部微服务使用同一套框架，同一套启动配置方式。 129 | - 采用APM框架等自动提供一套标准化的Instrumentation 体系，自动收集汇报服务关键指标，例如CPU, Memory, Latency 等， - - - 统一收集统一监控，自动接入统一的Dashboard。 130 | - 统一监控的覆盖率、推进组件同质化。 131 | - 构建适合自己的集群管理平台， 如： 132 | - 基于 Kubernetes, Mesos, Docker 的技术的Coding 自研容器化编排系统 （参见附录） 133 | - 腾讯公司的织云平台级运维服务. 134 | - 开源的Saltstack, Chef, Pupeet 等运维管理平台. 135 | - 基于CloudFoundry,等构建的企业内部PaaS平台。 136 | 137 | #### 2.3.4 优化管理级最佳实践 138 | ##### 2.3.4.1 概述 139 | 进入优化级，通常公司研发团队有了很长时间的共同积累，运维团队应该承担起基础库的维护工作，最大化在基础设施上的投入，不断优化底层代码和基础库的性能和效率，这将带来整个公司的研发效率和生产效率的提升。 140 | 141 | ##### 2.3.4.1最佳实践 142 | 无 143 | 144 | === 145 | 146 | ### 2.4 流量管理、容量伸缩能力 147 | 互联网业务普遍存在着爆发性高、业务热点复杂等特点。业务运维团队想提升业务可用性的一个重要能力就是建立起一套有效的流量管理、容量伸缩能力，能够将现有的有限资源动态分配，合理利用达到最好的业务效果。 148 | 149 | #### 2.4.1 可管理级最佳实践 150 | ##### 2.4.1.1 概述 151 | 进入可管理级，应用运维团队应该建立了基本的流量管理能力。能够针对可预见的流量变化配备合适的资源，有相应的预警措施，有处理过载的能力。 152 | 153 | ##### 2.4.1.2 最佳实践 154 | - 运维团队通过常见开源软件、第三方负载均衡器等实现手动的、基本入口级整体流量管理控制，可以按常见变量如IP、域名、API接口等维度进行简单的流量管控. 155 | - 运维团队可以通过部署IDS 或流量分析系统为整个业务提供可见性支持，收集业务中各种优先级的流量的重要性和健康度指标。 156 | - 运维团队可以根据业务需要和资源配置情况对业务中不重要的流量进行有损的手工调控, 157 | 158 | >例如：双11等电商秒杀关键时刻资源紧张时可以丢弃一些不重要的流量，保障关键性业务的正常运转。 159 | 160 | #### 2.4.2 已定义级最佳实践 161 | ##### 2.4.2.1 概述 162 | 进入已定义级，要求运维团队有全局流量管控的能力。能够根据业务的不同需要，结合实际物理资源情况等迅速进行流量调整、容量再配置。 163 | 164 | ##### 2.4.2.2 最佳实践 165 | - 运维团队可以针对业务中不同的优先级流量指定相应的服务水平指标，通过L2, L3, L7 不同层面的调节措施限速、排队等等达到限速目标。 166 | - 运维团队可以提供更高级，精确的流量控制工具可以按照业务特点精确的进行流量调整。 167 | - 运维团队可以建立对后端服务的自动化保护机制防止过载和连锁故障的发生。 168 | 169 | #### 2.4.3 量化管理级最佳实践 170 | ##### 2.4.3.1 概述 171 | 量化管理级要求运维团队运维团队支持流量管控配置与服务发现等自动化工具结合，支持动态调整、自动更新等。 172 | 173 | ##### 2.4.3.2 最佳实践 174 | - 例如：利用容器化等技术，根据实时流量自动扩展、收缩后端系统。 175 | - 又例: Youtube转码系统可以根据目前实时视频上传转码的需要自动配置不同格式的转码器的部署数量，达到最优化的资源配置机制。 176 | - 负载均衡器在进行流量的分配时，同时收集后端的健康度信号，自动评判哪些流量造成了系统性热点，自动分摊，自动聚合类似流量起到合理利用资源的目的。 177 | - 运维团队可以推行后端组件自行监控资源占用情况，包括CPU,Memory等如果发现系统资源占用情况到达一定阈值，停止接收新请求，避免系统过载、资源不够导致的性能急剧下降或者崩溃。 178 | - 流量管控系统可以进行自动Query-of-death检测，如果发现某一类请求会造成后端的不可用， 可以及时的做到自动屏蔽、发送报警，进一步缩短针对未知问题的防御程度，进一步提高整个系统的鲁棒性、可靠性。 179 | 180 | #### 2.4.4 优化管理级最佳实践 181 | ##### 2.4.4.1 概述 182 | 进入优化级，运维团队应该将重点放在合理利用资源，保护系统热点，提高系统可用性的关键性能力。在复杂业务系统中，每个系统组件都可能并行处理多种不同业务。其中难免在某一类业务中出现不可预知的热点、逻辑问题导致整个系统出现问题。常见的现象包括：某一类请求资源消耗过高、某种特殊组合造成系统死锁、某中意外输入导致程序崩溃等。运维团队应该推行自动化的容量伸缩、流量管控能力用以提高系统的鲁棒性，可用性，将紧急问题降级为资源问题。 183 | 184 | ##### 2.4.4.2 最佳实践 185 | 暂无 186 | 187 | === 188 | 189 | ### 2.5 灾难处理能力 190 | 应用运维团队通常是公司的救火队员，承担着关键时刻保障业务可持续性的压力。所以灾难处理能力是运维团队平时应该最重视培养的一项能力。 191 | 192 | #### 2.5.1 可管理级最佳实践 193 | ##### 2.5.1.1 概述 194 | 灾难处理能力可管理级，要求运维团队在关键时刻必须能够充当合格的救火队。在紧急时刻，能够及时响应问题，能够可靠、准确的定位问题，能够及时、有效的集合公司内外的人力、物理等力量共同解决业务部门遇到的问题。要做到这些，就要在非关键时刻下工夫。运维团队平时必须有计划的将保障业务系统正常运行的涉及到的各种硬件、软件、第三方系统、基础设施等等各个方面的关键信息、联系人、紧急处理流程等完全掌握。 195 | 196 | ##### 2.5.1.2 最佳实践 197 | - 建立一套合理的、灵活的、多级的 Oncall 体制，保障随时有人力响应紧急情况。轮值制度应该考虑的点包括： 198 | - 灾难升级制度：好的轮值制度应该分级处理，尽量将每次紧急情况的处理在报警前预先分类，按级报警，力求一次性找到对应的人来处理。 199 | - 对响应时间的要求要明确：非关键性业务的响应时间可以是小时级，关键业务的响应时间应该在分钟级。轮值人员务必在响应时间内及时上线开始处理问题。 200 | - 有足够的轮值力量和后备方案，确保当轮值人员有意外情况时，可以有其他的后备力量接替等。 201 | - 适当的补偿体系。 202 | - 培养良好的事后复盘体制，将每次灾难处理当成一次学习机会，力求将混乱、复杂的灾难处理流程文档化、记录化。为以后的提升和内部培训积累资料。 203 | - 定时组织灾难处理流程的演习，确保团队每个人熟悉业务灾难处理流程，掌握各种信息、工具，能够有效的在关键时刻调动各种资源解决问题。 204 | 205 | #### 2.5.2 已定义级最佳实践 206 | ##### 2.5.2.1 概述 207 | 进入已定义级意味着运维团队对于业务运行问题不再是被动的处理过程，而是逐渐进入一种主动模式。运维团队有计划的排除潜在问题，致力于业务的关键组件的可靠性提升，有计划有目的的降低问题发生的可能性。 208 | 209 | ##### 2.5.2.2 最佳实践 210 | - 运维团队有计划的测试、验证、优化各种硬件、软件配置保证常见单点灾难不会造成数据的丢失，损坏。确保硬件恢复之后可在1-X分钟内正常恢复服务，不会出现无法启动、无法重新部署的问题。 211 | - 推行计划内不可用时间：运维部门应该鼓励开发部门利用计划内不可用时间上线测试新功能，将新业务、新改变带来的风险分摊。 212 | 213 | #### 2.5.3 量化管理级最佳实践 214 | ##### 2.5.3.1 概述 215 | 进入量化管理级，要求运维团队针对业务恢复时间制定明确的SLA，将业务风险量化，定期进行灾难恢复演习，确保业务恢复的流程完备、可重现。 216 | 217 | ##### 2.5.3.2 最佳实践 218 | - 产品软件架构升级：提升可靠性的一个关键性就是运维部门应该联合开发部门一起推动业务组件支持按主、从模式部署，热备优于冷备。力求故障切换时间可在1-X小时内完成。整套过程尽量自动化，无业务降级、无数据丢失。 219 | - 运维团队推动服务架构升级支持分片式(sharding)部署。可以自动进行主从切换、动态重分片等，进一步减少不可用时间。 220 | 221 | #### 2.5.4 优化管理级最佳实践 222 | ##### 2.5.4.1 概述 223 | 进入优化管理级，运维部门应该致力于与业务部门共同努力为公司业务制定切实有用的风险模型，支持在有限预算和有限容量下最优化业务运行能力的目标。很多业务本身上就存在严重的资源竞争、负载难以预估、系统热点明显等特性。这些特性问题只能通过架构改进，但是却无法根除。任何一个业务团队所能投人力和物力都是有限的，运维团队就要在这种情况下和业务团队共同探寻一套可以接受的系统降级方案。在物理资源、人力资源有限的情况下制定出系统降级方案，保障业务顺利进行，出现问题也始终处于可接受的范围内。 224 | 225 | ##### 2.5.4.2 最佳实践 226 | 暂无 227 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Creative Commons Attribution Non Commercial No Derivatives 3.0 2 | 3 | Full name：Creative Commons Attribution Non Commercial No Derivatives 3.0 4 | 5 | Short identifier：CC-BY-NC-ND-3.0 6 | 7 | Other web pages for this license： 8 | 9 | http://creativecommons.org/licenses/by-nc-nd/3.0/legalcode 10 | 11 | Text 12 | 13 | Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported 14 | 15 | CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE LEGAL SERVICES. DISTRIBUTION OF THIS LICENSE DOES NOT CREATE AN ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS INFORMATION ON AN "AS-IS" BASIS. CREATIVE COMMONS MAKES NO WARRANTIES REGARDING THE INFORMATION PROVIDED, AND DISCLAIMS LIABILITY FOR DAMAGES RESULTING FROM ITS USE. 16 | 17 | License 18 | 19 | THE WORK (AS DEFINED BELOW) IS PROVIDED UNDER THE TERMS OF THIS CREATIVE COMMONS PUBLIC LICENSE ("CCPL" OR "LICENSE"). THE WORK IS PROTECTED BY COPYRIGHT AND/OR OTHER APPLICABLE LAW. ANY USE OF THE WORK OTHER THAN AS AUTHORIZED UNDER THIS LICENSE OR COPYRIGHT LAW IS PROHIBITED. 20 | 21 | BY EXERCISING ANY RIGHTS TO THE WORK PROVIDED HERE, YOU ACCEPT AND AGREE TO BE BOUND BY THE TERMS OF THIS LICENSE. TO THE EXTENT THIS LICENSE MAY BE CONSIDERED TO BE A CONTRACT, THE LICENSOR GRANTS YOU THE RIGHTS CONTAINED HERE IN CONSIDERATION OF YOUR ACCEPTANCE OF SUCH TERMS AND CONDITIONS. 22 | 23 | 1. Definitions 24 | 25 | a. "Adaptation" means a work based upon the Work, or upon the Work and other pre-existing works, such as a translation, adaptation, derivative work, arrangement of music or other alterations of a literary or artistic work, or phonogram or performance and includes cinematographic adaptations or any other form in which the Work may be recast, transformed, or adapted including in any form recognizably derived from the original, except that a work that constitutes a Collection will not be considered an Adaptation for the purpose of this License. For the avoidance of doubt, where the Work is a musical work, performance or phonogram, the synchronization of the Work in timed-relation with a moving image ("synching") will be considered an Adaptation for the purpose of this License. 26 | 27 | b. "Collection" means a collection of literary or artistic works, such as encyclopedias and anthologies, or performances, phonograms or broadcasts, or other works or subject matter other than works listed in Section 1(f) below, which, by reason of the selection and arrangement of their contents, constitute intellectual creations, in which the Work is included in its entirety in unmodified form along with one or more other contributions, each constituting separate and independent works in themselves, which together are assembled into a collective whole. A work that constitutes a Collection will not be considered an Adaptation (as defined above) for the purposes of this License. 28 | 29 | c. "Distribute" means to make available to the public the original and copies of the Work through sale or other transfer of ownership. 30 | 31 | d. "Licensor" means the individual, individuals, entity or entities that offer(s) the Work under the terms of this License. 32 | 33 | e. "Original Author" means, in the case of a literary or artistic work, the individual, individuals, entity or entities who created the Work or if no individual or entity can be identified, the publisher; and in addition (i) in the case of a performance the actors, singers, musicians, dancers, and other persons who act, sing, deliver, declaim, play in, interpret or otherwise perform literary or artistic works or expressions of folklore; (ii) in the case of a phonogram the producer being the person or legal entity who first fixes the sounds of a performance or other sounds; and, (iii) in the case of broadcasts, the organization that transmits the broadcast. 34 | 35 | f. "Work" means the literary and/or artistic work offered under the terms of this License including without limitation any production in the literary, scientific and artistic domain, whatever may be the mode or form of its expression including digital form, such as a book, pamphlet and other writing; a lecture, address, sermon or other work of the same nature; a dramatic or dramatico-musical work; a choreographic work or entertainment in dumb show; a musical composition with or without words; a cinematographic work to which are assimilated works expressed by a process analogous to cinematography; a work of drawing, painting, architecture, sculpture, engraving or lithography; a photographic work to which are assimilated works expressed by a process analogous to photography; a work of applied art; an illustration, map, plan, sketch or three-dimensional work relative to geography, topography, architecture or science; a performance; a broadcast; a phonogram; a compilation of data to the extent it is protected as a copyrightable work; or a work performed by a variety or circus performer to the extent it is not otherwise considered a literary or artistic work. 36 | 37 | g. "You" means an individual or entity exercising rights under this License who has not previously violated the terms of this License with respect to the Work, or who has received express permission from the Licensor to exercise rights under this License despite a previous violation. 38 | 39 | h. "Publicly Perform" means to perform public recitations of the Work and to communicate to the public those public recitations, by any means or process, including by wire or wireless means or public digital performances; to make available to the public Works in such a way that members of the public may access these Works from a place and at a place individually chosen by them; to perform the Work to the public by any means or process and the communication to the public of the performances of the Work, including by public digital performance; to broadcast and rebroadcast the Work by any means including signs, sounds or images. 40 | 41 | i. "Reproduce" means to make copies of the Work by any means including without limitation by sound or visual recordings and the right of fixation and reproducing fixations of the Work, including storage of a protected performance or phonogram in digital form or other electronic medium. 42 | 43 | 2. Fair Dealing Rights. Nothing in this License is intended to reduce, limit, or restrict any uses free from copyright or rights arising from limitations or exceptions that are provided for in connection with the copyright protection under copyright law or other applicable laws. 44 | 45 | 3. License Grant. Subject to the terms and conditions of this License, Licensor hereby grants You a worldwide, royalty-free, non-exclusive, perpetual (for the duration of the applicable copyright) license to exercise the rights in the Work as stated below: 46 | 47 | a. to Reproduce the Work, to incorporate the Work into one or more Collections, and to Reproduce the Work as incorporated in the Collections; and, 48 | 49 | b. to Distribute and Publicly Perform the Work including as incorporated in Collections. 50 | 51 | The above rights may be exercised in all media and formats whether now known or hereafter devised. The above rights include the right to make such modifications as are technically necessary to exercise the rights in other media and formats, but otherwise you have no rights to make Adaptations. Subject to 8(f), all rights not expressly granted by Licensor are hereby reserved, including but not limited to the rights set forth in Section 4(d). 52 | 53 | 4. Restrictions. The license granted in Section 3 above is expressly made subject to and limited by the following restrictions: 54 | 55 | a. You may Distribute or Publicly Perform the Work only under the terms of this License. You must include a copy of, or the Uniform Resource Identifier (URI) for, this License with every copy of the Work You Distribute or Publicly Perform. You may not offer or impose any terms on the Work that restrict the terms of this License or the ability of the recipient of the Work to exercise the rights granted to that recipient under the terms of the License. You may not sublicense the Work. You must keep intact all notices that refer to this License and to the disclaimer of warranties with every copy of the Work You Distribute or Publicly Perform. When You Distribute or Publicly Perform the Work, You may not impose any effective technological measures on the Work that restrict the ability of a recipient of the Work from You to exercise the rights granted to that recipient under the terms of the License. This Section 4(a) applies to the Work as incorporated in a Collection, but this does not require the Collection apart from the Work itself to be made subject to the terms of this License. If You create a Collection, upon notice from any Licensor You must, to the extent practicable, remove from the Collection any credit as required by Section 4(c), as requested. 56 | 57 | b. You may not exercise any of the rights granted to You in Section 3 above in any manner that is primarily intended for or directed toward commercial advantage or private monetary compensation. The exchange of the Work for other copyrighted works by means of digital file-sharing or otherwise shall not be considered to be intended for or directed toward commercial advantage or private monetary compensation, provided there is no payment of any monetary compensation in connection with the exchange of copyrighted works. 58 | 59 | c. If You Distribute, or Publicly Perform the Work or Collections, You must, unless a request has been made pursuant to Section 4(a), keep intact all copyright notices for the Work and provide, reasonable to the medium or means You are utilizing: (i) the name of the Original Author (or pseudonym, if applicable) if supplied, and/or if the Original Author and/or Licensor designate another party or parties (e.g., a sponsor institute, publishing entity, journal) for attribution ("Attribution Parties") in Licensor's copyright notice, terms of service or by other reasonable means, the name of such party or parties; (ii) the title of the Work if supplied; (iii) to the extent reasonably practicable, the URI, if any, that Licensor specifies to be associated with the Work, unless such URI does not refer to the copyright notice or licensing information for the Work. The credit required by this Section 4(c) may be implemented in any reasonable manner; provided, however, that in the case of a Collection, at a minimum such credit will appear, if a credit for all contributing authors of Collection appears, then as part of these credits and in a manner at least as prominent as the credits for the other contributing authors. For the avoidance of doubt, You may only use the credit required by this Section for the purpose of attribution in the manner set out above and, by exercising Your rights under this License, You may not implicitly or explicitly assert or imply any connection with, sponsorship or endorsement by the Original Author, Licensor and/or Attribution Parties, as appropriate, of You or Your use of the Work, without the separate, express prior written permission of the Original Author, Licensor and/or Attribution Parties. 60 | 61 | d. For the avoidance of doubt: 62 | 63 | i. Non-waivable Compulsory License Schemes. In those jurisdictions in which the right to collect royalties through any statutory or compulsory licensing scheme cannot be waived, the Licensor reserves the exclusive right to collect such royalties for any exercise by You of the rights granted under this License; 64 | 65 | ii. Waivable Compulsory License Schemes. In those jurisdictions in which the right to collect royalties through any statutory or compulsory licensing scheme can be waived, the Licensor reserves the exclusive right to collect such royalties for any exercise by You of the rights granted under this License if Your exercise of such rights is for a purpose or use which is otherwise than noncommercial as permitted under Section 4(b) and otherwise waives the right to collect royalties through any statutory or compulsory licensing scheme; and, 66 | 67 | iii. Voluntary License Schemes. The Licensor reserves the right to collect royalties, whether individually or, in the event that the Licensor is a member of a collecting society that administers voluntary licensing schemes, via that society, from any exercise by You of the rights granted under this License that is for a purpose or use which is otherwise than noncommercial as permitted under Section 4(b). 68 | 69 | e. Except as otherwise agreed in writing by the Licensor or as may be otherwise permitted by applicable law, if You Reproduce, Distribute or Publicly Perform the Work either by itself or as part of any Collections, You must not distort, mutilate, modify or take other derogatory action in relation to the Work which would be prejudicial to the Original Author's honor or reputation. 70 | 71 | 5. Representations, Warranties and Disclaimer 72 | 73 | UNLESS OTHERWISE MUTUALLY AGREED BY THE PARTIES IN WRITING, LICENSOR OFFERS THE WORK AS-IS AND MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND CONCERNING THE WORK, EXPRESS, IMPLIED, STATUTORY OR OTHERWISE, INCLUDING, WITHOUT LIMITATION, WARRANTIES OF TITLE, MERCHANTIBILITY, FITNESS FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, OR THE ABSENCE OF LATENT OR OTHER DEFECTS, ACCURACY, OR THE PRESENCE OF ABSENCE OF ERRORS, WHETHER OR NOT DISCOVERABLE. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO SUCH EXCLUSION MAY NOT APPLY TO YOU. 74 | 75 | 6. Limitation on Liability. EXCEPT TO THE EXTENT REQUIRED BY APPLICABLE LAW, IN NO EVENT WILL LICENSOR BE LIABLE TO YOU ON ANY LEGAL THEORY FOR ANY SPECIAL, INCIDENTAL, CONSEQUENTIAL, PUNITIVE OR EXEMPLARY DAMAGES ARISING OUT OF THIS LICENSE OR THE USE OF THE WORK, EVEN IF LICENSOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. 76 | 77 | 7. Termination 78 | 79 | a. This License and the rights granted hereunder will terminate automatically upon any breach by You of the terms of this License. Individuals or entities who have received Collections from You under this License, however, will not have their licenses terminated provided such individuals or entities remain in full compliance with those licenses. Sections 1, 2, 5, 6, 7, and 8 will survive any termination of this License. 80 | 81 | b. Subject to the above terms and conditions, the license granted here is perpetual (for the duration of the applicable copyright in the Work). Notwithstanding the above, Licensor reserves the right to release the Work under different license terms or to stop distributing the Work at any time; provided, however that any such election will not serve to withdraw this License (or any other license that has been, or is required to be, granted under the terms of this License), and this License will continue in full force and effect unless terminated as stated above. 82 | 83 | 8. Miscellaneous 84 | 85 | a. Each time You Distribute or Publicly Perform the Work or a Collection, the Licensor offers to the recipient a license to the Work on the same terms and conditions as the license granted to You under this License. 86 | 87 | b. If any provision of this License is invalid or unenforceable under applicable law, it shall not affect the validity or enforceability of the remainder of the terms of this License, and without further action by the parties to this agreement, such provision shall be reformed to the minimum extent necessary to make such provision valid and enforceable. 88 | 89 | c. No term or provision of this License shall be deemed waived and no breach consented to unless such waiver or consent shall be in writing and signed by the party to be charged with such waiver or consent. 90 | 91 | d. This License constitutes the entire agreement between the parties with respect to the Work licensed here. There are no understandings, agreements or representations with respect to the Work not specified here. Licensor shall not be bound by any additional provisions that may appear in any communication from You. This License may not be modified without the mutual written agreement of the Licensor and You. 92 | 93 | e. The rights granted under, and the subject matter referenced, in this License were drafted utilizing the terminology of the Berne Convention for the Protection of Literary and Artistic Works (as amended on September 28, 1979), the Rome Convention of 1961, the WIPO Copyright Treaty of 1996, the WIPO Performances and Phonograms Treaty of 1996 and the Universal Copyright Convention (as revised on July 24, 1971). These rights and subject matter take effect in the relevant jurisdiction in which the License terms are sought to be enforced according to the corresponding provisions of the implementation of those treaty provisions in the applicable national law. If the standard suite of rights granted under applicable copyright law includes additional rights not granted under this License, such additional rights are deemed to be included in the License; this License is not intended to restrict the license of any rights under applicable law. 94 | 95 | Creative Commons Notice 96 | 97 | Creative Commons is not a party to this License, and makes no warranty whatsoever in connection with the Work. Creative Commons will not be liable to You or any party on any legal theory for any damages whatsoever, including without limitation any general, special, incidental or consequential damages arising in connection to this license. Notwithstanding the foregoing two (2) sentences, if Creative Commons has expressly identified itself as the Licensor hereunder, it shall have all rights and obligations of Licensor. 98 | 99 | Except for the limited purpose of indicating to the public that the Work is licensed under the CCPL, Creative Commons does not authorize the use by either party of the trademark "Creative Commons" or any related trademark or logo of Creative Commons without the prior written consent of Creative Commons. Any permitted use will be in compliance with Creative Commons' then-current trademark usage guidelines, as may be published on its website or otherwise made available upon request from time to time. For the avoidance of doubt, this trademark restriction does not form part of this License. 100 | 101 | Creative Commons may be contacted at http://creativecommons.org/. 102 | 103 | Standard License Header 104 | There is no standard license header for the license 105 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # aops --------------------------------------------------------------------------------