故障现象
对资源执行编排apply的时候，可能是用户提供的hcl文件的问题导致的错误，也有可能是tic服务本身的问题，更有可能的是tic依赖的云API导致的问题。下面我们就这些错误一一说明一下该如何处理。
故障影响
高。
故障定位
如果用户提交的terraform模版文件本身语法有问题，那么在执行plan的时候就会报错。需要注意的是，语法没有问题不代表就可以编排，还需要在apply运行时才能知道。 比如说我们提交一个语法不合规的模版：
可以看到少了一个”}”符号，执行plan的时候tic就会报错，此时就需要用户修改hcl模版文件：
如果plan事件无法执行（apply，destroy事件同理），那么TIC的后台服务就出问题了，就需要去依次检查一下cgi网关和websocket服务是否正常，terraform operator、executor服务是否已启动，基础组件（数据库、csp等）是否运行正常，以及组件间依赖的tce配置是否正确。 cgi网关提供TIC的API服务，可以在浏览器F12查看网络面板得到请求响应的信息，还可以看到websocket的连接状态和双向数据传输。
这里可以看看是否是客户端的请求问题，如果是的话，根据错误信息调整再试试（也有可能网络出了问题，比如网关服务，这时候只能去找管理员了）。如果不是的话，就是后台问题了，最容易想到的办法就是根据云API的requestid去服务器排查日志，但是我们需要先看看服务是否正常，首先登录服务器。
kubectl get pod -ntce |grep tic
这两个pod必须处于running状态，否则需要查看pod的事件排查没起来的原因然后重启pod。pod起不来的原因很有可能是依赖的基础组件出了问题，根据启动日志逐一排查。
更多的是依赖的云产品的API出了问题，根据前端报错的requestid，使用查询脚本定位到云产品具体报错原因。
[err] Error: [TCECloudSDKError] Code=InvalidParameter.CheckParamNotPass, Message=CreatePGInstanceHour, create master, but have no standby nodes, RequestId=19e23639-eedd-e7f5-4bcf-4e51ff1ca9b2
使用bash searchlog.sh 19e23639-eedd-e7f5-4bcf-4e51ff1ca9b2 定位具体问题