diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/2023-09-08-dcm-using-kcl/index.md b/i18n/zh-CN/docusaurus-plugin-content-blog/2023-09-08-dcm-using-kcl/index.md
index 917db3520..4822cb7e7 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/2023-09-08-dcm-using-kcl/index.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/2023-09-08-dcm-using-kcl/index.md
@@ -11,7 +11,7 @@ tags: [KCL, Kubernetes Resource Model, Dynamic Configuration Management]
 
 > 随着云原生技术的发展，我们更多地转向云基础设施，Kubernetes 和 Terraform 等 IaC 工具已成为越来越流行的管理和部署基于云 API 的应用程序的工具。但是随之而来衍生出的复杂性问题和认知负担问题在近几年达到了高峰。
 
-![](TODO: 补充 Gtener 认知负担曲线图)
+![cognitive-loading](/img/blog/2023-09-08-dcm-using-kcl/cognitive-loading.png)
 
 Kubernetes 和云 API 越来越复杂的原因主要有以下几点：
 
@@ -34,6 +34,7 @@ Kubernetes 和云 API 越来越复杂的原因主要有以下几点：
 + 扩展性：并且能够已可扩展的方式
 + 稳定性：
 + 效率低：往往没有标准的方式去管理这些动态的不同环境的配置
++ 配置漂移：这是因为静态配置文件是手动编写的，针对一组静态环境和基础架构。在这种设置中，静态 IDP 容易出现故障，或者在团队需要执行回滚、更改配置或重构等任务时会导致额外的负担。此外，大多数通常内置于静态 IDP 中的工具可以解决单个痛点，例如环境即服务。它们也内置于自行编写的工作流程中，这往往会导致影子运维或更大程度地依赖运维人员。问题在于，大多数这些工具无法解决大多数交付设置所困扰的核心问题：静态管理应用程序和基础设施配置的方式，采用这种非标准化的方法也可能导致复杂度呈指数增长，并往往导致配置漂移
 
 ## 为什么需要一种新范式
 
diff --git a/static/img/blog/2023-09-08-dcm-using-kcl/cognitive-loading.png b/static/img/blog/2023-09-08-dcm-using-kcl/cognitive-loading.png
new file mode 100644
index 000000000..c547e5a9a
Binary files /dev/null and b/static/img/blog/2023-09-08-dcm-using-kcl/cognitive-loading.png differ