diff --git a/content_zh/docs/tasks/traffic-management/fault-injection/index.md b/content_zh/docs/tasks/traffic-management/fault-injection/index.md
index 4dd32b70a6..2512162c47 100644
--- a/content_zh/docs/tasks/traffic-management/fault-injection/index.md
+++ b/content_zh/docs/tasks/traffic-management/fault-injection/index.md
@@ -18,25 +18,31 @@ keywords: [流量管理,故障注入]
 * 通过首先执行[请求路由](/zh/docs/tasks/traffic-management/request-routing/)任务或运行以下命令来初始化应用程序版本路由：
 
     {{< text bash >}}
-    $ istioctl create -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
-    $ istioctl replace -f @samples/bookinfo/networking/virtual-service-reviews-test-v2.yaml@
+    $ kubectl apply -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
+    $ kubectl apply -f @samples/bookinfo/networking/virtual-service-reviews-test-v2.yaml@
     {{< /text >}}
 
+* 通过上面的配置，下面是请求的流程：
+    *  `productpage` → `reviews:v2` → `ratings` (`jason` 用户)
+    *  `productpage` → `reviews:v1` (其他用户)
+
 ## 使用 HTTP 延迟进行故障注入
 
-为了测试我们的微服务应用程序 Bookinfo 的弹性，我们将在 reviews :v2 和 ratings 服务之间的一个用户 "jason” _注入一个 7 秒_ 的延迟。
-由于 _reviews:v2_ 服务对其 ratings 服务的调用具有 10 秒的硬编码连接超时，因此我们期望端到端流程是正常的（没有任何错误）。
+为了测试我们的微服务应用程序 Bookinfo 的弹性，我们将在 `reviews:v2` 和 `ratings` 服务之间的一个用户 `jason` 注入一个 7 秒的延迟。
+这个测试将会发现故意引入 Bookinfo 应用程序中的错误。
+
+由于 `reviews:v2` 服务对其 ratings 服务的调用具有 10 秒的硬编码连接超时,比我们设置的 7s 延迟要大，因此我们期望端到端流程是正常的（没有任何错误）。
 
 1. 创建故障注入规则以延迟来自用户 "jason”（我们的测试用户）的流量
 
     {{< text bash >}}
-    $ istioctl replace -f @samples/bookinfo/networking/virtual-service-ratings-test-delay.yaml@
+    $ kubectl apply -f @samples/bookinfo/networking/virtual-service-ratings-test-delay.yaml@
     {{< /text >}}
 
 1. 确认已创建规则：
 
     {{< text bash yaml >}}
-    $ istioctl get virtualservice ratings -o yaml
+    $ kubectl get virtualservice ratings -o yaml
     apiVersion: networking.istio.io/v1alpha3
     kind: VirtualService
     metadata:
@@ -80,15 +86,15 @@ keywords: [流量管理,故障注入]
     {{< /text >}}
 
 1. 查看页面的返回时间：
-   1. 打开浏览器的 *开发工具* 菜单
-   1. 打开 *网络* 标签
-   1. 重新加载 `productpage` 页面，你会看到页面实际上用了大约 6s。
+    1. 打开浏览器的 *开发工具* 菜单
+    1. 打开 *网络* 标签
+    1. 重新加载 `productpage` 页面，你会看到页面实际上用了大约 6s。
 
-## 了解发生了什么
+## 理解原理
 
 你发现了一个 bug。在微服务中有硬编码超时，导致 `reviews` 服务失败。
 
-在 `productpage` 和 `reviews` 服务之间超时时间是 6s - 编码 3s + 1次重试总共 6s ，`reviews` 和 `ratings` 服务之间的硬编码连接超时为 10s 。由于我们引入的延时，`/productpage` 提前超时并引发错误。
+在 `productpage` 和 `reviews` 服务之间超时时间是 6s - 编码 3s + 1 次重试总共 6s ，`reviews` 和 `ratings` 服务之间的硬编码连接超时为 10s 。由于我们引入的延时，`/productpage` 提前超时并引发错误。
 
 这些类型的错误可能发生在典型的企业应用程序中，其中不同的团队独立地开发不同的微服务。Istio 的故障注入规则可帮助您识别此类异常，而不会影响最终用户。
 
@@ -113,18 +119,18 @@ keywords: [流量管理,故障注入]
 
 测试微服务弹性的另一种方法是引入 HTTP abort 故障。在这个任务中，在 ratings 微服务中引入 HTTP abort ，测试用户为 `jason` 。
 
-在这个案例中，我们希望页面能够立即加载，同时显示 `product ratings not available` 这样的消息。
+在这个案例中，我们希望页面能够立即加载，同时显示 `Ratings service is currently unavailable` 这样的消息。
 
 1. 为用户 "jason” 创建故障注入规则发送 HTTP abort
 
     {{< text bash >}}
-    $ istioctl replace -f @samples/bookinfo/networking/virtual-service-ratings-test-abort.yaml@
+    $ kubectl apply -f @samples/bookinfo/networking/virtual-service-ratings-test-abort.yaml@
     {{< /text >}}
 
 1. 确认已创建规则
 
     {{< text bash yaml >}}
-    $ istioctl get virtualservice ratings -o yaml
+    $ kubectl get virtualservice ratings -o yaml
     apiVersion: networking.istio.io/v1alpha3
     kind: VirtualService
     metadata:
@@ -160,14 +166,15 @@ keywords: [流量管理,故障注入]
 
     如果规则成功传播到所有的 pod，您应该能立即看到页面加载并看到 `Ratings service is currently unavailable` 消息。
 
-1. 注销用户 `jason`，您应该会在 `/productpage` 网页上看到评级星标的评论成功显示。
+1. 如果您注销用户 `jason` 或在匿名窗口（或其他浏览器）中打开 Bookinfo 应用程序，您应该会在 `/productpage` 仍然调用 `reviews:v1`（没有调用  `ratings`）
+ 除了 `jason` 外的用户都会看到网页上看到评级星标的评论成功显示。
 
 ## 清理
 
 1. 删除应用程序路由规则：
 
     {{< text bash >}}
-    $ istioctl delete -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
+    $ kubectl delete -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
     {{< /text >}}
 
 1. 如果您不打算探索任何后续任务，请参阅 [Bookinfo 清理](/zh/docs/examples/bookinfo/#清理)说明以关闭应用程序。