18、DevOps 事件管理与知识管理全解析

DevOps 事件管理与知识管理全解析

1. 事件流转机制

当需要代码支持的事件流入服务台时，服务台虽识别出事件与代码更改相关，但因缺乏必要技能，不会也不能决定是否将工单转移给 DevOps 团队，而是将其升级到 L2 团队。L2 团队作为技术管理职能部门，更有能力推荐代码更改，并将事件转移给 DevOps 团队。

DevOps 团队并非接受所有流入的事件。当事件到达 DevOps 事件桶时，事件经理会介入，审查并分析事件，判断是需要代码更改还是通过配置文件更改来解决。若是后者，事件会被推回 L2 支持团队；若需要代码更改，事件经理会获取相关信息，将事件添加到产品待办事项列表中。

从经验来看，约 60% 的事件在服务台或通过自动工具无需人工干预即可解决；约 30 - 35% 的事件需要配置级别的更改；只有一小部分事件会流转到 DevOps 团队，需要进行代码更改。代码通常不会导致服务中断，配置、基础设施和网络等代码构建之上的多个层面都可能引发事件。

为确保开发和测试环境与生产环境相似，并识别任何回归问题，将配置更改通过 CI - CD 管道是一种良好实践。此外，L2 执行的更改应在冲刺回顾期间由 L3 团队进行审查，以反思更改并确定改进机会。

曾有项目将 L2 支持与 DevOps 团队合并，结果团队解决事件的工作量远超实际开发工作，团队士气从高涨变得低落。因此，L2 应独立于 DevOps 团队之外。

2. 知识管理的核心地位

知识管理常被忽视，但它与产品维护和升级所需的配置管理同样重要。在事件管理中，人们往往优先考虑开发和直接对服务或产品有贡献的工作，而忽视知识的创建和维护。当事件发生时，开发