准入模板

基本信息

  • scm模块名:
  • 模块直接负责人:
  • 报警接收人:

系统与网络

网段

  • 检查点：网段需求
  • 规范描述：除金融类产品外应避免特殊网段需求（特殊网段：比如需要隔离网段，在交换机上设置acl控制）

硬件

  • 检查点：套餐或配件
  • 规范描述：业务程序仅提供虚拟化资源，其他存储业务暂时可使用物理机

软件

  • 内核版本：应避免特殊内核版本或操作系统发行版的需求，默认centos4u3和6u3
  • 系统配置：服务应该根据其实际需求在软件中修改对应的参数，不应该依赖于非系统通用套餐规定的特殊系统参数配置。
  • 依赖软件：除redis/zk这种独立的服务外，不应该依赖于系统来提供特殊的软件或运行时环境（如python的环境），应在程序的整体代码环境中打包给出。

性能

  • 性能测试:要求：有全系统性能数据（至少有子模块的性能测试测试数据）,具体需要满足如下2点，需要QA确认
    1. 可测性-可通过模拟流量或环境, 而非直接影响用户的方式给出
    2. 性能-满足 SLA 要求下的能承担的极限压力；
  • 启动时间:要求：程序的启动时间最长不应超过5分钟。（PHP／java的时间不能超过1分钟；C 5分钟）
  • 资源扩展:资源合理利用性，要求：CPU／内存资源使用不应有明显浪费（比如内存用满，CPU空闲）

服务架构

关联关系

  • 数据热加载:要求：
    1. 对数据更新时效性要求高的（10分钟内），服务运行依赖的本地数据, 需要通过非重启的方式加载。
    2. 数据实时更新的服务，如重启后需要追数据（否则会有数据延迟），要求在10分钟同步更新完毕
  • RPC等服务调用解耦:要求： 服务调用（包括上下游的所有调用）不能使用具体的物理位置，如机器名、机器IP等，应使用BNS名字服务（推荐）／域名／VIP/zookeeper（不推荐）来解耦

    上游调用：调用模块／调用方式／配置文件路径／调用是否存在跨IDC调用

    下游调用：调用模块／调用方式／配置文件路径／调用是否存在跨IDC调用

idc运营商

  • 多IDC部署多运营商接入
    • IDC：一级服务需要能够至少在2个IDC部署，并且在单机房故障下有明确的预案
    • 运营商：速度敏感型服务至少需要有联通/移动/电信3个运营商的接入

容错与预案

  • 容错策略

    • RPC请求需要对所调用服务的失败、读写超时有容错处理，能够容忍下游单实例故障，能够容忍下游非核心模块全部故障，能够容忍bns/zookeeper服务异常
    • 建议配置：连接超时100ms/读写超时不超过2s/重试1次，超时重试的时长不应超过5s
    • 下游服务异常恢复后，上游服务应具备自恢复能力（不需要重启）
    • bns/zookeeper服务异常后，服务需要有本地关联配置的cache的策略，bns的通用解决方案
    • 其他第三方服务需要有明确的运维团队和运维接口人
    • 实例可以被随时停止、重启、增加

      上游调用1： 调用模块名：XXX/连接超时：xxms （参考值100ms）/读超时：xxms （需要小于其上游调用超时）/写超时：xxms （需要小于其上游调用超时）/重试次数：1次 （建议共请求2次，以免雪崩）/重试的条件：连接、读、写超时均会重试/重试后仍失败的影响：比如下单失败或者降级后无促销信息

  • 预案

    • 服务明显异常时应具备明确的预案，并明确执行条件和流程

部署

包管理

  • 目录结构建议：
    • bin: 运维接口, 主程序
    • conf: 配置文件
    • data: 数据文件
    • log: 日志文件
    • lib: 依赖的lib库"
  • 运维接口：服务必须提供一个可执行文件(不接受多个文件启动的方式), 作为对其运维操作(启动/停止/重载/健康检查)的唯一入口
    • 启动 sh dispaly_control start
    • 停止 sh dispaly_control stop
    • 重启 sh dispaly_control restart
    • 健康检查：sh dispaly_control status|monitor|healthcheck
  • 配置文件：配置文件只能存在SCM或者paas发布平台上，不能并存，也不能存在其他位置（以一个为最终版本，否则造成的不一致风险业务自行承担）

日志

  • 日志操作：
    • 支持日志随时被删除、切割（不需要重启服务）；
    • 日志切割和删除：切割方式默认以小时为单位切割，命名为：xxx.log.yyyymmddhh(如 as.log.2016081009)
    • 日志本地保存天数默认3～7天，如需要额外保留需明确需求给OP备份到Hadoop
    • 声明核心报表依赖的日志：日志文件名以及日志传输异常的报警接收人
  • 日志格式：
    • a.日志中的时间需要符合标准的时间格式，便于查看，建议：level: %Y-%m-%d %H:%M:%S，如NOTICE: 16-08-11 10:59:59
    • b.日志中需要有的字段标志
      • 错误日志：请求的异常状态,异常的原因（错误码＋错误信息）
      • 访问日志：请求来源（client ip）、总耗时、关联模块的处理实例id/ip、请求关联模块的耗时、logid（建议有可trace的id－可选）

上线

  • 上线：要求模块上线不能要求停服务或者切流量（多系统联合的复杂上线可单独评审）

监控

服务核心指标

  • 服务与模块都需要明确自己的核心功能，对应核心指标项、如何采集(日志或者接口)以及判定异常的方法，默认要求至少包含平响／pv／pvlost/报警阈值

    核心功能： pv： 提供日志样例（匹配的关键字飘红）/ pvlost： 提供日志样例/ 平均响应时间：提供日志样例/ 可用性计算方式：／ 报警阈值：／

默认通用监控

  • 机器，资源使用，进程，端口等通用监控默认由OP添加，报警同步发送给RD

依赖服务状态

  • 必须提供方法（通常是日志），呈现所依赖的服务（上下游均需要包含）的请求状态，包括但不限于：调用的ip：port，请求失败的错误（错误信息+错误码）、时延等(与日志的格式保持一致)；

安全

https接入

  • 直接对外可见的服务需要支持https（防内容劫持）

代码开发

  • 符合公司安全规范

第三方组件

  • 服务使用的第三方组件必须通过公司安全组的扫描
  • 服务使用的内外部组件不允许是snapshot或停止维护的版本

非业务接口

  • 要求服务不允许开放非业务需要的后门端口和接口

SLA

  • 服务必须明晰其在端上核心功能，每个功能对应的核心指标，衡量方法以及目标SLA。 （如成功率、时延、正确率等） 如果是已有核心流程增加了一些逻辑或者策略 那就需要review原来的指标是否需要调整； 如果是新增的用户可见的独立功能，则需要确定新的SLA

results matching ""

    No results matching ""