引言
首先我简单的介绍下系统的产品结构：基于keycloak的IAM认证系统（针对RBAC的子系统）提供给上游的业务应用系统（application1、application2、application3 ...）我们需要拿到下游的中台用户组织信息研发成关于RBAC相关的接口供上游系统使用。在上游应用系统对接IAM系统时发生的request、response产生的日志数据我们需要对接下游运维环境的Elastic生态服务存储日志数据。
问题
事情发生在2024年3月7日上午10点左右，收到上游的应用系统无法登录到业务系统发生500服务系统内部错误～ 第一时间是反馈到IAM项目组了。 我们这边测试一个心跳接口，无法接通。因之前在应用系统上发生请求数据在高并发条件下无法在ElasticSearch中创建索引库而写入相应的文档结果对象。这里所采用的方式是RreetrantLock(true)公平锁在写入ElasticSearch时通过lock.tryLock()获取，在异常捕获后finally中lock.unlock()释放锁的方式，来解决并发请求写入数据不一致的问题。 在IAM发生系统服务宕机时开始的想法是在请求时写入ElasticSearch时数据被锁住了？
直到我通过kinaba连接ES的工具发现了服务宕机，下游的环境运维组协调信息重新给出临时的ElasticSearch服务地址。
原因
这次的线上生产事故由于下游环境运维组更迭服务器发出的通知信息在没有被项目负责人 --> 应用对接人 --> 技术负责人 --> 团队成员每一级的传达不明确。导致即将要更新维护的服务器至服务停机这段时间一直用旧的服务上部署项目，直至成员的之间获得的信息存在差异，所以爆发这次上游系统大规模的宕机故障。
结果
我简单说说在今后规避的方面：
1、首先以自己IAM系统为例，为上游应用系统提供相关的接口时发布新的版本更新在产品使用说明文档中描述清楚这个接口是什么含义？eg:按给定条件进行范围查询日志信息 ...
在更新发布的产品说明文档后，通过在企业微信联系工具编辑消息，新的产品使用说明文档有更新，请大家注意后续的介入操作，并相互告知更新的消息。避免因信息遗漏而得不到最新信息。
2、下游系统更新消息需要项目负责人 --> 应用对接人 --> 技术负责人传达到相对于他们的上游，各组织的人经常关注转发消息。
我就简单说这么多！有关信息传达而导致资源信息不及时，还有什么好建议，欢迎大家在评论区留言！
当然希望这种线上生产事故不在发生。
