预防能力指标
预防故障发生
网络
网络服务SLA签订
- 指标分类：预防能力/预防故障发生/网络
- 指标解释：网络是整个系统服务的基础设施，网络质量的优劣直接关系到服务的可靠性。
- 指标要求：对网络质量的要求需要和网络组明确（包含：带宽、延时）。
- 评分标准：
- 和网络提供商无明确约定的，不得分。
- 指标有明确完整约定的得60分，部分约定的，每增加一个指标得30分。
- 对指标对应的数据使用状态有例行监控和审计的得40分，部分有监控和审计的，每增加一个得20分。
- 验证手段：提交与网络签订SLA的材料（备忘录或邮件等）。
- 判例：无
- 指标级别：2
- 对应角色：OP、网络提供商
程序
变更规范
- 指标分类：预防能力/预防故障发生/程序
- 指标解释：变更管理权限混乱、无明确通报机制和流程规范，给线上带来无数隐患、也直接影响线上问题定位和止损效率。
- 指标要求：需要有明确的变更流程，主要包括：上线前的测试方案和风险评估，上线的权限管理、时间窗口、通报机制等。
- 说明：BUG修复类、只能在低峰期进行变更、变更持续时间长的特殊情况，可以设置特殊的窗口和流程规范，但不能无章可循。
- 评分标准：
- 1.有明确的时间窗口，特别是对于时间窗口之外的上线有完善的紧急流程规范，得30分
- 2.有明确的上线权限管理和通报机制，得30分。
- 3.有完善的检查回归手段，得40分。
- 验证手段：查看变更数据。
- 判例：无
- 指标级别：1
- 对应角色：OP、RD、QA
QA测试
- 指标分类：预防能力/预防故障发生/程序
- 指标解释：完备的测试是拦截线上程序BUG的有效手段，该指标用于衡量测试完备度。
- 指标要求：对测试形式、测试内容进行规范。
- 评分标准：
- 对于高风险、核心服务或基础组件的程序变更应纳入测试，并按如下标准进行评分：
- 测试任务对代码合法性进行校验得25分。
- 测试任务对模块级功能进行验证得25分。
- 测试任务对系统级功能进行验证得25分。
- 测试任务产出格式化的测试报告得25分。
- 验证手段：抽样检查测试记录中是否包含对应测试项目。
- 判例：无
- 指标级别：2
- 对应角色：QA
编码规范
- 指标分类：预防能力/预防故障发生/程序
- 指标解释：不遵循代码规范编写的程序，上线后往往引入可用性隐患，该指标用于衡量程序编码是否符合公司代码规范要求。
- 指标要求：遵循代码编码规范。
- 评分标准： 通过代码检查等工具验证编码已全部遵循公司代码规范得100分，部分遵循的，根据比例得分。
- 验证手段：提交代码检查等工具的验证记录。
- 判例：无
- 指标级别：2
- 对应角色：RD
操作
线上线下隔离
- 指标分类：预防能力/预防故障发生/操作
- 指标解释：线上、线下隔离是指将线上环境与线下环境隔离开，不允许线下服务在授权外访问线上服务。
- 指标要求：原则上，线上与线下进行隔离，避免线下压力、异常流量发送到线上，影响线上服务。确因特殊需求，需要线下连接线上的，通过例外授权进行。其中对线上压测和写线上的需求，不得例外授权。
- 评分标准：
- 1．已通过技术手段对所有核心模块实施线上、线下隔离的，得70分，实施部分核心模块的根据模块数比例得分。
- 2．可通过技术手段实现隔离例外授权控制的，得30分，其中对线上压测和写线上的需求，不得例外授权。
- 验证手段：从实现隔离的技术平台获取线上、线下隔离策略数据。
- 判例：RD线下测压，压垮passport线上服务 导致用户登录失败。
- 指标级别：2
- 对应角色：OP、RD
运维操作规范
- 指标分类：预防能力/预防故障发生/操作
- 指标解释：运维操作规范指针对OP的线上操作行为制定相应的操作准则。线上操作包括程序、数据变更，配置修改，数据获取，故障处置，增加或下线机器、环境清理等对线上产品环境进行变更的行为。
- 指标要求：对OP线上操作需要制定操作规范，常规类操作需明确操作流程和技术要求；非常规类操作，规范中至少需额外增加对审批流程、操作前后通报机制、操作后验证机制、操作分级进行的要求。运维操作规范需定期review。
- 评分标准：
- 1．OP线上操作（包括常规和非常规），明确操作流程和技术要求，得20分。
- 2．OP非常规类操作，制定审批流程，得20分；操作前后有通报机制，得10分，操作后有验证机制，得20分，有操作分级要求，得20分。
- 运维操作规范每年review一次得10分。
- 验证手段：
- 1．产品线提交运维操作规范文档。
- 2．抽样检查或产品线提交操作审批记录、操作通报记录、操作后验证记录、操作分级记录。
- 3．抽样检查或产品线提交运维操作规范review记录。
- 判例：无。
- 指标级别：2
- 对应角色：OP
运维操作培训
- 指标分类：预防能力/预防故障发生/操作
- 指标解释：运维操作培训是指对OP进行运维操作流程、技术要求、安全意识等方面的培训，目的是让每个OP对线上操作要求有清晰的认识，上岗前具备操作安全意识和技能，降低线上操作风险。
- 指标要求：对新入职或刚转入的同学在正式上岗操作前，需开展运维操作培训，培训考核通过后方能上岗。《运维操作规范》大版本更新、修订后，需重点就变更内容在整个团队内开展培训。
- 评分标准：
- 1．对新入职或刚转入同学在2个月内进行运维操作规范培训，得40分，否则得0分。培训考核通过后上岗，得30分，培训后未考核或考核未通过上岗，得0分。
- 2．《运维操作规范》大版本更新、修订后，1个月内在整个团队内进行培训，得30分，否则得0分。
- 验证手段：
- 1．产品线提交新入职和刚转入同学的培训、考核记录。
- 2．产品线提交团队培训记录。
- 判例：无。
- 指标级别：2
- 对应角色：OP
安全审计
- 指标分类：预防能力/预防故障发生/操作
- 指标解释：安全审计指将实际操作行为与安全规则进行对比，发现日常操作中存在的违规、高风险行为，是基础运维风险事后管控的重要措施。
- 指标要求：各产品线应对如下方面进行安全审计：非法登录；人员与权限不匹配情况；超级、区域总控授权、操作行为审计；线下连线上行为审计；初始化平台操作行为审计。
- 评分标准：
- 对非法登录审计得20分，对人员与权限不匹配审计得10分，对超级、区域总控审计得30分，线下连线上审计得20分，初始化平台操作审计得20分。
- 验证手段：通过giano平台获取或产品线提交审计报告。
- 判例：无
- 指标级别：2
- 对应角色：OP
平台
平台服务SLA签订
- 指标分类：预防能力/预防故障发生/平台
- 指标解释：外部依赖的平台可用性直接影响服务可用性，不应使得平台成为服务的可用性短板。
- 指标要求：应与平台明确SLA，SLA不应限于服务可用性指标，还应该包括故障联动预案、变更流程规范等。
- 评分标准：
- 1.服务可用性指标（50）:应与平台明确约定量化的可用性指标（服务成功率、MTTR等）及其限制条件（如冗余度、容量）。满足得50分。
- 2.故障联动预案（40）:应与平台制定常见故障场景下的联动预案（包括流量调度、降级等），并定期演练。特别是，平台服务需要降级的，需要与业务预期达成一致。满足得40分。
- 3.变更流程规范(10）:业务与平台方有约定的变更时间窗口，满足得10分。
- 验证手段：
- 平台SLA数据纳入rskpi，提交与平台方约定的故障联动预案及变更流程规范wiki。
- 判例：业务方与依赖服务需要有联动预案，以保证故障下的快速止损。例如，贴吧拆分了北京网通、北京电信、南京02、南京03四个逻辑机房，但MOLA集群只有北京、南京02、南京03三个镜像。2015.7.21，mola升级导致其北京镜像出现单副本（单副本将导致更新失败），导致贴吧北京的部分发帖失败，需要贴吧执行预案，将北京的流量全部调度到南京以实现完全止损。但贴吧缺失MOLA北京机房故障的预案（相当于北京两个逻辑机房故障预案），南京无法承担北京全流量，导致无法快速有效的止损。
- 指标级别：2
- 对应角色：OP、RD
第三方公司
第三方公司快速沟通渠道构建
- 指标分类：预防能力/预防故障发生/第三方公司
- 指标解释：依赖第三方公司的服务发生故障时,需要具备完整分层次的沟通机制,包括商务/技术多个层次,方便在可以预见的故障情形下进行有效及时地沟通。
- 指标要求：应与第三方依赖公司，以备忘录方式明确双方技术/商务接口人，定期更新并通过定期演练保持快速畅通的沟通渠道。
- 评分标准：
- 1.完备性：与第三方依赖公司沟通，以备忘录方式明确双方商务/技术接口人（主备至少各一人），联系方式应包括电话/邮件/hi或qq，得50分。
- 2.时效性：月度更新接口人信息；季度与第三方沟通演练，各得25分。
- 验证手段：提交与第三方依赖公司签订的备忘录。
- 判例：
- 指标级别：2
- 对应角色：OP、RD、PM
第三方公司服务SLA签订
- 指标分类：预防能力/预防故障发生/第三方公司
- 指标解释：调用第三方公司服务的产品线，需要与其签订服务质量SLA约束，用于获取第三方公司在技术、商务服务质量上的承诺，防范相关故障发生，或在故障发生后有对应处理依据。
- 指标要求：应与第三方公司签订服务质量SLA约束，其中“服务可用性算法”和“可用性数据采集标准”双方应确认一致，在商务上应明确惩罚性条款。
- 评分标准：与第三方公司签订技术指标明确的服务质量SLA约束，且明确惩罚性条款的，得100分，否则不得分。
- 验证手段：提交与第三方依赖公司签订的SLA协议。
- 判例：无
- 指标级别：2
- 对应角色：OP、RD、PM
运营
容量规划
- 指标分类：预防能力/预防故障发生/运营
- 指标解释：明确的容量数据是应对服务流量波动及故障时流量调度的重要依据。没有最新的容量数据，会导致流量调度时无法快速决策，或者执行后出现预期外问题反而对服务造成损失。
- 指标要求：
- 对于每个逻辑服务单元，需要有明确的容量数据，并定期更新。
- 对于流量的变化趋势，年度变化特征，有贴近实际情况的预估，重点关注重大事件（如节日/运营/假期/新闻）。
- 评分标准：
- 1．完备性：对所有逻辑服务单元均有明确的容量数据，且覆盖其下的核心功能，得30分。否则不得分
- 2．实测性：容量数据为针对线上实际环境测试得到，而非线下模拟和推演得到的，得20分。否则不得分。
- 3．时新性：容量数据有定期更新机制，且周期小于1个月的，得30分。否则不得分。
- 4．预测：有对全年关键节点的流量预估机制，节点到来前一周可给出预估数据，得20分。无或者不能提前一周，不得分。
- 验证手段：提交容量评估系统或工具中的线上容量压测记录、容量评估记录以及容量预测机制和预测记录。
- 判例：无
- 指标级别：1
- 对应角色：OP
攻击
防攻击能力
- 指标分类：预防能力/预防故障发生/攻击
- 指标解释：网络攻击行为由于其突发性的大流量，消耗大量网络资源或超出系统的服务能力，导致系统崩溃，无法为正常用户提供服务。
- 指标要求：对常见攻击有识别、防御的能力。攻击种类包括dns攻击、syn flood/udp flood、cc、waf防御类。对攻击类型识别和防御评估覆盖率，对攻击到来、识别、防御评估生效速度。大规模攻击时可在运营商侧封禁被攻击ip，避免持续影响机房出口，产品线应制定ip封禁预案，提前约定明确的封禁阈值。
- 评分标准：
- 1．完备性：可有效防御所有常见攻击行为的得40分，否则酌情给分
- 2．精细化：可针对不同流量来源、不同模块进行防攻击的，得30分，否则不得分。
- 3．高效性：攻击行为可在2分钟内被识别并防御的，得30分，否则不得分。需要人工识别攻击行为后添加策略的不得分。
- 判例：用户产品需要有基本的防攻击策略，进行流量清洗，保护服务。例如，2015.7.1，贴吧核心服务frs页受攻击导致该服务异常，由于贴吧防攻击策略被关闭导致分布式防攻击策略未第一时间生效；frs本身流量在贴吧整体流量占比很少，因此攻击导致的流量增长未能第一时间发现。故障持续时间1小时。
- 指标级别：2
- 对应角色：OP、RD
预防故障扩散
程序调度
调度容错
- 指标分类：预防能力/预防故障扩散/程序调度
- 指标解释：应对上下游服务异常，程序需要在调度策略上具有容错能力，不能因为少部分调度单元的实例异常就影响服务最终效果。 基本的调度策略需要至少包含：异常容忍(单机、单交换机、慢后端)、流量管理(负载均衡、队列保护)、健康检测(心跳探活、请求探活)。其中：重试、超时、按照query哈希调度等都是具体指标的实现方式。
- 指标要求：
- 在异常容忍上至少需要支持单机容错，更好的需要支持单交换机、单物理IDC以及慢后端的异常
- 在流量管理上需要按照业务特性支持不同维度的负载均衡(比如:全打散、按照query哈希、部分打散等)
- 在健康检测上也需要按照业务特性支持心跳或者请求探活，或者两者兼有。
- 评分标准：整体评分，总分100分，其中异常容忍：40分，流量管理40分，健康监测20分。
- 异常容忍如果不能容忍单机异常不得分，可以容忍单机异常得 10分，在此基础上可以做到单交换机异常容忍加20分，可以做到单物理IDC常容忍的得40分
- 流量管理上不支持负载均衡的不得分。支持负载均衡的如果只是简单的全打散得10分。如果可以契合业务需求定制支持全打散、query哈希的可以加20分。如果可以做到过载保护加10分。
- 不支持健康检查的不得分，支持任意一种健康检查的得10分。如果能做到无损探活并且能保证时效性的再加 10分。
- 验证手段：
- 通过杀掉单机、单网段的服务来验证实际效果
- 在机制上通过review来判断。
- 判例：无
- 指标级别：1
- 对应角色：OP、RD