变更资产、变更审计和灰度发布

核心目标

核心目标：所有变更单都能够集中审计，为满足审计需要，要采集审计信息包括变更的人、事、物。审计变更是否按要求实施了灰度、回退，信息不需包括如何实现灰度控制、如何执行灰度的细节。

人：执行相关角色，包括执行者、审批者。需要执行者、审批者信息，同时附带执行者与审批者的组织信息。

事：重点看：灰度、回退。灰度、回退是变更的一个操作步骤，回退步骤不是必须出现的。灰度步骤可能包含多次不同阶段的灰度，应该具备基本的阶段信息：灰度阶段名称、阶段起止时间、阶段的整体变更进度。实际执行灰度时，可能会涉及灰度执行的明细，如对模块进行扩容涉及实际扩容的部署实例，可以不对其进行解析处理，如需要审计明细应该转为对应变更工具中进行。每个步骤应该有明确的执行结果信息。整个变更的流程可以总结为：创建-审批-执行灰度-执行回退-结单（终止）

物：变更的对象类别非常多。例如服务发布涉及模块的二进制、配置；服务扩缩容涉及模块的实例；物理设施的变更。

实施思路

  1. 变更工具在单据的信息有更新时上报审计日志，审计工具整理单据信息

  2. 变更工具整理单据的所有步骤信息，提交给审计工具

变更审计关键信息

  1. 变更单据基本信息：变更单据ID、变更所属工具、变更说明、变更单据url、变更单据创建时间、变更单据结束时间
  2. 变更人员信息：变更创建者、变更执行者、变更审批者
  3. 变更对象信息：变更资产类别、变更资产标识
  4. 变更步骤信息：步骤类别（创建、灰度、回退、结单）、步骤名称、步骤执行者、步骤开始时间、步骤结束时间、步骤执行状态、步骤所占进度、步骤执行的扩展信息

ods 清洗方案

  1. 增量合并，存储压力小，但是一个单据的数据可能会跨多个分区。
  2. 全量合并，存储压力大。
  3. 设计方案：变更步骤（原始日志）直接清洗出 dwd 全量表（避免跨分区问题），按小时清洗并保留7天的分区（满足时效性同时避免存储压力过大）。变更单基于变更步骤 dwd 表清洗，按变更渠道+变更类型+变更ID聚合，清洗出单据汇总信息。变更单也可以按增量清洗，仅合并终态单据（结单或关单），按结单时间或关单时间，清洗在对应的分区。增量合并可以使用小时级分区。全量不建议使用，或小时分区+7天保留时间限制。

查问题需要一查到底，弄清楚问题原理，否则迟早会要重改的

只是随便修修，当时能用，后续还是会暴露问题要重新写，之前的功夫都白费了。

调权灰度和正式灰度

  1. 调权灰度：调权灰度是指在灰度发布过程中，通过调整不同版本或不同用户群体的流量权重来实现逐步发布的过程。可以根据发布效果实时调整流量分配比例；从少量流量开始，逐步增加新版本的流量占比；如果新版本出现问题，可以快速降低权重或回滚；常用于功能验证和性能对比测试

  2. 正式灰度：正式灰度是指按照预定义的发布计划进行的正式灰度发布流程。有明确的发布计划和时间表；遵循固定的发布规范和检查点；全量覆盖，最终目标是所有用户都迁移到新版本；更注重发布的稳定性和可靠性

时间分区的理解

mysql根据 modify_time 字段是否在时间分区范围内判断，增量的按时间分区将数据写入twd表里。

AS ds``` 根据 ```modify_time``` 字段配合 ```ds``` 分区判断增量是啥。
1
2
3
4
5
6
7
8
9
10
11
12

来源表有时间分区 ```ds```，则可以特殊指定单个分区（```PARTITION``` 子句设计用于精确指定单个分区，不能用于多个分区），代码如下：

```SQL
SELECT
  ds -- 时间分区 ${YYYYMMDDHH}
FROM
  xx_database.xx_table PARTITION (
    p_${YYYYMMDDHH}
  ) p1
WHERE
  fchangechannel = 'XXX'

如果要合并多个分区，从小时表变成天表，代码如下（自动分区剪枝，TDW分布式数据库的SQL翻译器，会自动根据WHERE条件中的分区过滤条件访问最小的数据集）：

1
2
3
4
5
6
7
SELECT
  ds -- 时间分区 ${YYYYMMDDHH}
FROM
  xx_database.xx_table
WHERE ds BETWEEN -- 从小时表变成天表
  CONCAT(DATE_FORMAT(DATE_SUB(CURRENT_DATE, 1), 'yyyyMMdd'), '00') AND 
  CONCAT(DATE_FORMAT(DATE_SUB(CURRENT_DATE, 1), 'yyyyMMdd'), '23')

去重的方法

SQL：数据去重的三种方法

DISTINCT 关键字

1
2
3
4
5
-- 单字段去重
SELECT DISTINCT column_name FROM table_name;

-- 多字段组合去重
SELECT DISTINCT column1, column2, column3 FROM table_name;

GROUP BY 分组

1
2
3
4
5
6
7
8
9
-- 按部门分组，显示每个部门的员工数量
SELECT department, COUNT(*) as employee_count
FROM employees
GROUP BY department;

-- 按部门职位分组，显示最高薪资
SELECT department, position, MAX(salary) as max_salary
FROM employees
GROUP BY department, position;

ROW_NUMBER() 窗口函数

1
2
3
4
5
6
7
8
9
10
SELECT *
FROM (
    SELECT *,
           ROW_NUMBER() OVER (
               PARTITION BY column1, column2  -- 联合字段分区 
               ORDER BY sort_column。-- 分区排序
           ) as rn
    FROM table_name
) t
WHERE rn = 1;  -- 只保留每个分区的第一条记录（去重）（可选保留第几位）

EXISTS / NOT EXISTS

1
2
3
4
5
6
7
8
-- 保留每个用户的第一条记录
SELECT *
FROM orders o1
WHERE NOT EXISTS (
    SELECT 1 FROM orders o2
    WHERE o2.customer_id = o1.customer_id
      AND o2.order_date < o1.order_date
);

自连接去重

1
2
3
4
5
SELECT t1.*
FROM table_name t1
LEFT JOIN table_name t2 ON t1.dup_column = t2.dup_column 
                        AND t1.id > t2.id  -- 或其他比较条件（比如上面的时间条件）
WHERE t2.id IS NULL;

告警链路

  1. 一个模块可以挂载多个ikey（无限制）
  2. 一个ikey可以挂载多个监控（有限制）

告警自恢复标记

根据告警算法算出的全部告警都报上去，对其中能自恢复（类似接口重试后就可用这种）的告警标记，减少告警数量（省得对部分告警每次都是忽略），提高告警质量。

契约流程

契约：接口列表，通信协议（如http）协议规范（如openapi-v3）

用protobuf格式调用rpc，用protobuf格式生成各种测试。 UAT，业务用例（对外，协作交付）->业务序列图（转成信息流），UAT在生成各种剧本。 UAT需要测试资格，可执行的API，前置的条件（例如单据，需要走业务流程），UAT测试的流程如果走业务流程那么就太长了，需要快速流程。 通过契约开发，契约关联概念，有概念规则约束（例如字段有约束），上下文信息。 mock平台，根据模块的接口生成mock，根据字段生成mock补齐字段。