配置变更风险管理

迁移到MSE Nacos

ACM进入下线状态，所有配置管理相关的需求由MSE中的Nacos承接（ACM独享版，更好的安全和稳定性）。您需要在ACM控制台导出配置，然后在MSE控制台导入之前导出的配置即可完成迁移。具体操作，请参见将应用配置从ACM迁移到MSE Nacos。

组织配置

ACM 提供了 dataId、group、app、namespace 等四个维度来帮助管理配置。勤于梳理且善用这些维度，能减少在配置管理过程中发生失误，提高系统稳定性。

• 配置组织方式

  • dataId

    • 用来表示一组相关的 key=value 的配置项的集合。

    • 规范 dataId 命名，例如： com.company.trade.threadpool.params，trade.p1.props。

  • group

    一般使用模块名或者云资源名。若一个应用使用了 Nginx，SLB， 此处 group 命名即 nginx，slb。

  • app

    应用分组，一般是一个简单的业务单元或者微服务分组，由一个小型或中型团队开发和维护。

  • namespace

    粗粒度隔离多个应用的配置，例如多环境。

• 配置影响分级

  每个配置项的变更对系统的影响均不同。例如：日志级别的变更出现错误，会改变系统的日志量，此外一般不会有其它负面的影响。而连接池、线程池、限流阈值、主机配置等的变更往往是一个 Server 级别或者一个应用服务集群级别的影响。

  分布式系统如全局路由规则、负载均衡策略、网络配置等是重量级的配置，错误的变更往往会带来严重的后果。因此需要按照配置影响力，将配置等级分为 P0~P4。

  以下是示例说明。

  级别	影响力	例子
  P0	全网	全局路由规则，网络配置，负载均衡配置
  P1	应用集群	集群限流阈值，集群服务端点
  P2	主机级别关键配置	主机资源配置，线程池大小
  P3	进程级别非关键配置	日志级别
  P4	无关紧要的配置	版本信息

• 避免配置项集中于一个文件

  若将应用的所有配置项都放在一个配置里，则意味着所有的人都在一个配置集上修改，这将导致配置变更、推送变得相对频繁，且增加了互相冲突以及误操作的风险，不利于更好的配置授权和分级的变更流程管控。

• 重要配置变更使用灰度发布

  重要的配置（如 P0、P1 级）需设置变更审核、灰度等发布策略来降低变更风险。

确保配置安全

敏感配置信息请加密后存储在 ACM 里

ACM Server 的主机和配置存储中默认不做数据加密处理。对于一些敏感配置信息，如密码、Token、AccessKey 等信息，必须加密后才可以存储在 ACM 里。

ACM 的 API 和控制台均有提供配置信息加密工具，帮助您将信息加密之后再存储到 ACM 里。