|
CCI作为DevOps最成熟最基础的产品之一，在高频大量的使用中难免出现一些问题无法解决，现在让我们来讲讲这样问题的处理思路与方案。
自检思路基本概念
服务日志
当有功能进行异常时，可以优先考虑排查对应的服务日志 CCI的日志分服务进行存储。
日志存放路径为：/data/bkce/logs/ci/
如果需要获取全部服务日志，则进入CCI后台服务机器：find /data/bkce/logs/ci/ -name \-devops.log -o -name \-devops-error.log |xargs tar zcvf /root/bkci-log.tar.gz
然后发送打包好的 /root/bkci-log.tar.gz 日志。
平台运维
如果页面上出现明显的报错，应该F12打开浏览器控制台，检查是哪个服务的报错，以下是一些常见的错误类型的HTTP状态码：
●- 404 - 请求资源未发现，通常是前端文件缺失造成的，查看网关日志以确定具体文件位置。
●- 500 - 服务内部错误，通常是服务出现报错造成的，查看服务日志以定位具体问题。
●- 503 - 服务不可用，通常是服务状态异常或Consul状态异常造成的，首先检查服务和Consul的状态，其次查看服务日志。
●- 如果服务日志中出现了调用另一个服务的报错，应该同步查看另一个服务的日志。
●- 如果服务日志中出现了调用基础组件的报错，应该同步检查基础组件的状态。
如果问题与资源情况有关，应该检查各机器的CPU、内存、磁盘使用情况，对资源进行清理或者扩容。
如果问题是在变更后出现的，应该详细检查变更流程是否有严格按照文档操作，是否有遗漏某些步骤或者在某些步骤中出现了报错。
配置使用
①页面配置方面的问题，首先可以查看帮助中心里的文档，其次可以询问相关同事。
②后台配置方面的问题，可以询问运维同事或研发同事。
其他
①防火墙/网络策略的问题，应该先对照网络策略清单或根据服务日志报错，确定需要开通的网络策略，然后反馈给负责人进行调整。
②蓝鲸底座、数据库、中间件或操作系统相关的问题，可以先与运维同事沟通，确定问题是否可以在内部解决，如果问题难度较高则联系运维同事处理。
★先来看看流水线中触发器相关的一些问题处理思路和方案
○gitlab触发插件无法触发流水线
2. 查看下devops_ci_process.T_PIPELINE_WEBHOOK表是否有注册这条流水线， SELECT * FROM devops_ci_process.T_PIPELINE_WEBHOOK WHERE pipeline_id = ${pipeline_id}，${pipeline_id}可以从url地址获取。
a. 查看repository服务到gitlba的网络是否能 通， 比如是否配置gitlab的域名解析。
b. 查看gitlab仓库的权限是否是master权限。生成accesstoken的用户需要是仓库的maintainer角色，且accesstoken 的 Scopes需要具有api权限。
c. 在repository服务部署的机器上，执行grep "Start to add the web hook of " $BK_HOME/logs/ci/repository/repository-devops.log查找注册失败原因，$BK_HOME默认是/data/bkce
a. 到gitlab的webhook页面，查看是否有注册成功。
b. 如果gitlab中有注册的url，url是 http://域名/external/scm/codegit/commit 然后点击编辑，查看View detail，如图2。
c. 查看发送的错误详情，如图3。检查gitlab到 BK-CI 机器的网络是否可达，如gitlab服务器是否能解析 BK-CI 域名。
5. 如果上面都没问题，在process服务部署的机器上，执行grep "Trigger gitlab build"
$BK_HOME/logs/ci/process/process-devops.log 搜索日志，查找触发的入口日志，查看gitlab push过来的请求体。注意查看gitlab push过来的请求体，对比请求体中的http_url字段和代码库里代码仓库的地址是否完全匹配，如果一个是域名形式的url，另一个是ip形式的url，则不匹配。
6. gitlab 的 hook记录中，报错 Hook execution failed。这是因 gitlab 10.6 版本后为了安全，默认不允许向本地网络发送 webhook。需要解开 gitlab 的安全限制。
○定时触发的流水线，时间显示不对，触发时间也不对
| 
