做过运维工作的人都明白那种感受: 警报声一响, 首先就要去查看指标, 接着切换并翻开日志, 然后跳转查找Trace, 最终回到工单系统当中撰写复盘。进行一次故障排查的时候, 五六个系统需要来回切换, 最后得出的结论还分散在各个地方。在往上去翻的时候, 碰到了这个国产的开源项目, 它的思路感觉挺合心意的哟: 就是把可观测性、事件中心、还有任务中心, 全都放进到一个能够让Agent调用的工作流当中, 然后使得运维人员那种“到处去查系统”的情况, 转变成为“问系统”的状态。项目是什么它是一个针对真实运维现场所打造的开源智能运维 Agent 平台, 其作者 ID 为既定的内容, 遵循 2.0 协议, 完全是在个人业余时间进行开发, 当下拥有 183 星以及 81 Fork, 官方还专门开设了在线体验站。国产运维项目组合的技术栈标准是: 后端有 DRF , 前端是Vue 3 Plus , 数据库支持与MySQL 8。主要功能自然语言排障的AIOps智能体, 有工具调用, 有二阶段回答, 有Skill模板, 有预检, 有待确认动作, 该模型只负责理解和规划, 不能绕过后端直接动手。可观测性面板, 它会聚合告警, 还会聚合指标, 也会聚合日志, 同样会聚合Trace, 并且会聚合看板, 最终形成Agent能够进行查询的证据来源。事件中心: 沉淀下失败定位的线索, 关键的写操作要明确, 需对上下文做复盘, 并且要支持依据系统、环境、应用以及时间来作过滤。任务中心里, 有主机巡检这一项, 还有批量命令, 以及脚本模板, 另外存在任务草稿亦有计划任务, 其中动作入口全都统一进行收敛。从事应用发布相关事务的工单系统, 有审批流环节, 还涉及 SQL 审计, 有事务工单, 变更全过程可留下踪迹。对容器进行管理, 其中涵盖K8s集群, 包含工作负载, 涉及Pod终端, 还有“/”, 实现环境的一站式管理。RBAC权限进行审计, 后端的API要审计, 前端的路由得审计, 菜单按钮也要审计, 场景实现统一接入, 并且这个前端只是在进行体验方面的优化, 而后端才是真正具有安全边界的所在。一个典型场景比如, “生产order - 异常分析”这种情况, 传统的方式是, 要开启五六个系统, 通过人工来进行串联。在这里, 你通过用自然语言向Agent提问, 它会自身去调配告警、日志以及Trace工具来进行取证工作, 而后端则负责进行RBAC以及参数清洗的工作, 并且最终Skill输出结论、依据以及建议操作出来。要是需要执行巡检, 或者执行命令, 首先要生成任务草稿, 在你确认之后才会进入任务中心, 其结果会自动回写到事件中心, 以及审计链路当中。一句话理解模型负责理解平台负责边界。安装指南一键起推荐git clone https://github.com/aiyiyi121/sxdevops.git cd sxdevops docker compose up -d --build启动后访问 :8000容器会自动执行和初始化演示数据。本地开发模式cd backend pip install -r requirements.txt python manage.py migrate python manage.py seed_data python -m daphne -b 0.0.0.0 -p 8000 sxdevops.asgi:application cd frontend npm install npm run dev前端 :3000后端 :8000。使用指南初次登录之时需采用默认之管理员账号admin, 其密码为本Admin, 并且还预先设置好了、、、好几个分具有不同角色的演示账号, 以此便于体验RBAC这一效果。还没进行生产部署的时候, 要想清楚, 得把这几项环境变量改一下: 把它们换成随机的数值, 让其表现为DEBUG0, 填入真实存在的域名, NS0, 对于MySQL和Redis连接串, 要按照实际的情况去进行更改。关闭初始化演示数据可以设置 0 和 TES0。写在最后有一个作为纯个人开源的AIOps项目, 它的完成度相较于所想象的要高出不少, 关于可观测性此一模块跑通了, 事件这一模块也跑通了, 任务这一模块同样跑通了, 工单这一模块亦是跑通了, K8s这一模块已然跑通了, RBAC这个模块也成功跑通了, 而且一键启动的情况很顺利, 二次开发所面临的门槛并不高。当前存在的小遗憾在于, 镜像现行状况是需要自行进行build操作。此种情况下, 它尚未被推送到相关处, 在首次开展部署工作时, 会牵扯到很多依赖的拉取。另外, 文档的语言主要是以中文呈现, 这极有可能使面向海外范围时其传播受到牵制。不过, 针对此情况, 作者所规划的路线图里已然涵盖健康检查、审批以及呈现闭环状态的自动化这些趋向, 是很值得持续保持关注的。于那些中小系列的团队自主构建AIOps的情况而言, 或者针对那些想要去学习“AI Agent进而与运维平台”相融合这种思路的同学来讲, 这无疑是一种相当不错的可供参考的实现方式。开展针对开源爱好者的小型调查, 你们所在团队的运维排障情况究竟怎样, 是当前依靠人工逐个切换系统来进行, 还是已然具备由Agent联结起来的方式, 在评论区域交流讨论一下。 又一个国产开源智能运维平台！183星SxDevOps，让运维告别切窗口
做过运维工作的人都明白那种感受: 警报声一响, 首先就要去查看指标, 接着切换并翻开日志, 然后跳转查找Trace, 最终回到工单系统当中撰写复盘。进行一次故障排查的时候, 五六个系统需要来回切换, 最后得出的结论还分散在各个地方。在往上去翻的时候, 碰到了这个国产的开源项目, 它的思路感觉挺合心意的哟: 就是把可观测性、事件中心、还有任务中心, 全都放进到一个能够让Agent调用的工作流当中, 然后使得运维人员那种“到处去查系统”的情况, 转变成为“问系统”的状态。项目是什么它是一个针对真实运维现场所打造的开源智能运维 Agent 平台, 其作者 ID 为既定的内容, 遵循 2.0 协议, 完全是在个人业余时间进行开发, 当下拥有 183 星以及 81 Fork, 官方还专门开设了在线体验站。国产运维项目组合的技术栈标准是: 后端有 DRF , 前端是Vue 3 Plus , 数据库支持与MySQL 8。主要功能自然语言排障的AIOps智能体, 有工具调用, 有二阶段回答, 有Skill模板, 有预检, 有待确认动作, 该模型只负责理解和规划, 不能绕过后端直接动手。可观测性面板, 它会聚合告警, 还会聚合指标, 也会聚合日志, 同样会聚合Trace, 并且会聚合看板, 最终形成Agent能够进行查询的证据来源。事件中心: 沉淀下失败定位的线索, 关键的写操作要明确, 需对上下文做复盘, 并且要支持依据系统、环境、应用以及时间来作过滤。任务中心里, 有主机巡检这一项, 还有批量命令, 以及脚本模板, 另外存在任务草稿亦有计划任务, 其中动作入口全都统一进行收敛。从事应用发布相关事务的工单系统, 有审批流环节, 还涉及 SQL 审计, 有事务工单, 变更全过程可留下踪迹。对容器进行管理, 其中涵盖K8s集群, 包含工作负载, 涉及Pod终端, 还有“/”, 实现环境的一站式管理。RBAC权限进行审计, 后端的API要审计, 前端的路由得审计, 菜单按钮也要审计, 场景实现统一接入, 并且这个前端只是在进行体验方面的优化, 而后端才是真正具有安全边界的所在。一个典型场景比如, “生产order - 异常分析”这种情况, 传统的方式是, 要开启五六个系统, 通过人工来进行串联。在这里, 你通过用自然语言向Agent提问, 它会自身去调配告警、日志以及Trace工具来进行取证工作, 而后端则负责进行RBAC以及参数清洗的工作, 并且最终Skill输出结论、依据以及建议操作出来。要是需要执行巡检, 或者执行命令, 首先要生成任务草稿, 在你确认之后才会进入任务中心, 其结果会自动回写到事件中心, 以及审计链路当中。一句话理解模型负责理解平台负责边界。安装指南一键起推荐git clone https://github.com/aiyiyi121/sxdevops.git cd sxdevops docker compose up -d --build启动后访问 :8000容器会自动执行和初始化演示数据。本地开发模式cd backend pip install -r requirements.txt python manage.py migrate python manage.py seed_data python -m daphne -b 0.0.0.0 -p 8000 sxdevops.asgi:application cd frontend npm install npm run dev前端 :3000后端 :8000。使用指南初次登录之时需采用默认之管理员账号admin, 其密码为本Admin, 并且还预先设置好了、、、好几个分具有不同角色的演示账号, 以此便于体验RBAC这一效果。还没进行生产部署的时候, 要想清楚, 得把这几项环境变量改一下: 把它们换成随机的数值, 让其表现为DEBUG0, 填入真实存在的域名, NS0, 对于MySQL和Redis连接串, 要按照实际的情况去进行更改。关闭初始化演示数据可以设置 0 和 TES0。写在最后有一个作为纯个人开源的AIOps项目, 它的完成度相较于所想象的要高出不少, 关于可观测性此一模块跑通了, 事件这一模块也跑通了, 任务这一模块同样跑通了, 工单这一模块亦是跑通了, K8s这一模块已然跑通了, RBAC这个模块也成功跑通了, 而且一键启动的情况很顺利, 二次开发所面临的门槛并不高。当前存在的小遗憾在于, 镜像现行状况是需要自行进行build操作。此种情况下, 它尚未被推送到相关处, 在首次开展部署工作时, 会牵扯到很多依赖的拉取。另外, 文档的语言主要是以中文呈现, 这极有可能使面向海外范围时其传播受到牵制。不过, 针对此情况, 作者所规划的路线图里已然涵盖健康检查、审批以及呈现闭环状态的自动化这些趋向, 是很值得持续保持关注的。于那些中小系列的团队自主构建AIOps的情况而言, 或者针对那些想要去学习“AI Agent进而与运维平台”相融合这种思路的同学来讲, 这无疑是一种相当不错的可供参考的实现方式。开展针对开源爱好者的小型调查, 你们所在团队的运维排障情况究竟怎样, 是当前依靠人工逐个切换系统来进行, 还是已然具备由Agent联结起来的方式, 在评论区域交流讨论一下。