Blueking Lite 更新:人机协同决策交互优化与三员管理落地

2026-06-05 27 预计阅读时间:1 分钟
来源:oschina.net AI 摘要 原文链接

免责声明:本文为 AI 摘要整理,建议结合原文阅读。摘要可能省略上下文、版本差异或边界条件,不作为官方说明。

预计阅读时间:11 分钟

运维平台走到"AI First"这一步,最大的挑战不再是算法本身,而是人怎么和算法一起把决策做完。Blueking Lite 本周的更新直指这个痛点——优化选项确认与流程推进的交互体验,同时内置了三员管理角色体系,让权限边界更清晰。

人机协同决策:从"算法说了算"到"人确认、机执行"

传统 AIOps 平台常见的问题:系统抛出一堆告警,自动生成处置建议,运维人员要么全盘接受,要么逐条驳回,中间缺乏有效的交互节点。这次更新把"确认"这个动作重新设计了:

  • 选项确认更明确:每个 AI 生成的操作建议都附带影响范围和风险等级,运维人员可以逐项勾选确认,而不是笼统的"同意/拒绝"。
  • 流程推进更平滑:确认后系统自动衔接下一步执行,减少手动切换界面的次数。

这意味着运维人员的角色从"被动审批者"变成了"主动决策者",AI 负责生成选项和预估风险,人负责拍板,拍板后机器立刻接手执行。

三员管理:权限分离的硬约束

更新中另一个实质性变化是内置了三员管理角色:

角色 职责范围 典型操作
系统管理员 平台配置、用户管理、功能开关 创建用户、分配权限、调整系统参数
安全管理员 安全策略、审计规则、敏感操作审批 设置密码策略、审批高危操作
审计管理员 操作日志审查、合规报告生成 查询操作记录、导出审计报告

三员管理的核心逻辑是权限互斥:系统管理员不能审批自己的高危操作,安全管理员不能修改系统配置,审计管理员只看不动。这在金融、政务等合规要求严格的场景下是硬性要求。

下面是一个模拟三员管理角色与权限分离的 RBAC 配置示例,可以直接用于 Kubernetes 或类似系统的 RoleBinding 设计:

# 三员管理角色定义 - 适用于 Kubernetes RBAC 或类似权限体系
# 假设运维平台运行在 K8s 上,以下为最小化角色定义

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: ops-system-admin
rules:
  # 系统管理员:平台配置与用户管理
  - apiGroups: ["ops.blueking.io"]
    resources: ["platformconfigs", "users", "featureflags"]
    verbs: ["get", "list", "create", "update", "delete"]
  # 明确排除:不能操作安全策略和审计记录
  - apiGroups: ["ops.blueking.io"]
    resources: ["securitypolicies", "auditlogs"]
    verbs: []  # 无权限

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: ops-security-admin
rules:
  # 安全管理员:安全策略与高危操作审批
  - apiGroups: ["ops.blueking.io"]
    resources: ["securitypolicies", "passwordpolicies", "hazardousapprovals"]
    verbs: ["get", "list", "create", "update"]
  # 明确排除:不能修改系统配置和用户
  - apiGroups: ["ops.blueking.io"]
    resources: ["platformconfigs", "users"]
    verbs: []

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: ops-audit-admin
rules:
  # 审计管理员:只读审计日志,生成合规报告
  - apiGroups: ["ops.blueking.io"]
    resources: ["auditlogs", "compliancereports"]
    verbs: ["get", "list"]
  # 明确排除:不能执行任何写操作
  - apiGroups: ["ops.blueking.io"]
    resources: ["platformconfigs", "securitypolicies", "users"]
    verbs: []

---
# 角色绑定示例 - 将不同用户绑定到对应角色
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: system-admin-binding
subjects:
  - kind: User
    name: zhangwei
roleRef:
  kind: ClusterRole
  name: ops-system-admin
  apiGroup: rbac.authorization.k8s.io

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: security-admin-binding
subjects:
  - kind: User
    name: liming
roleRef:
  kind: ClusterRole
  name: ops-security-admin
  apiGroup: rbac.authorization.k8s.io

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: audit-admin-binding
subjects:
  - kind: User
    name: chenfang
roleRef:
  kind: ClusterRole
  name: ops-audit-admin
  apiGroup: rbac.authorization.k8s.io

使用前需要根据实际 API Group 和资源名称替换 ops.blueking.ioplatformconfigs 等字段。核心思路是:每个角色的 verbs 列表里,对不该碰的资源显式写空数组,避免默认继承带来的权限溢出。

人机协同流程的实操思路

把"选项确认"和"三员管理"结合起来,一个典型的人机协同处置流程可以这样设计:

"""
模拟人机协同决策流程:AI 生成建议 → 人确认 → 安全管理员审批(高危) → 自动执行
实际使用时替换为 Blueking Lite SDK 或自研平台的 API 调用
"""

from enum import Enum
from dataclasses import dataclass

class RiskLevel(Enum):
    LOW = "low"
    MEDIUM = "medium"
    HIGH = "high"

class Role(Enum):
    SYSTEM_ADMIN = "system_admin"
    SECURITY_ADMIN = "security_admin"
    AUDIT_ADMIN = "audit_admin"

@dataclass
class AIActionSuggestion:
    action_id: str
    description: str
    risk_level: RiskLevel
    affected_resources: list[str]
    estimated_impact: str

def generate_suggestions(alert_context: dict) -> list[AIActionSuggestion]:
    """AI 根据告警上下文生成处置建议(模拟)"""
    # 实际场景中调用平台 AI 引擎
    return [
        AIActionSuggestion(
            action_id="restart-service",
            description="重启异常服务进程",
            risk_level=RiskLevel.MEDIUM,
            affected_resources=["app-server-01", "app-server-02"],
            estimated_impact="服务中断约 30 秒"
        ),
        AIActionSuggestion(
            action_id="scale-up-cluster",
            description="扩容集群节点",
            risk_level=RiskLevel.LOW,
            affected_resources=["cluster-prod"],
            estimated_impact="资源成本增加约 15%"
        ),
    ]

def human_confirm(suggestions: list[AIActionSuggestion], operator_role: Role) -> dict:
    """运维人员逐项确认,高危操作需安全管理员二次审批"""
    confirmed = {}
    for s in suggestions:
        # 模拟运维人员确认逻辑
        print(f"[{s.risk_level.value}] {s.description}")
        print(f"  影响范围: {s.affected_resources}")
        print(f"  预估影响: {s.estimated_impact}")

        # 低风险:系统管理员可直接确认
        if s.risk_level == RiskLevel.LOW and operator_role == Role.SYSTEM_ADMIN:
            confirmed[s.action_id] = "approved_directly"

        # 中高风险:需要安全管理员审批
        elif s.risk_level in (RiskLevel.MEDIUM, RiskLevel.HIGH):
            confirmed[s.action_id] = "pending_security_approval"
            print(f"  ⚠ 需安全管理员审批后执行")

        # 审计管理员无执行权限
        elif operator_role == Role.AUDIT_ADMIN:
            confirmed[s.action_id] = "rejected_no_execution_permission"

    return confirmed

def security_approve(confirmed: dict, suggestions: list[AIActionSuggestion]) -> dict:
    """安全管理员审批高危操作"""
    final = {}
    for s in suggestions:
        status = confirmed.get(s.action_id)
        if status == "pending_security_approval":
            # 模拟安全管理员审批
            final[s.action_id] = "approved_with_condition"
            print(f"[审批通过] {s.description} - 执行前需通知相关团队")
        else:
            final[s.action_id] = status
    return final

# 运行示例
alert = {"type": "service_anomaly", "service": "order-service"}
suggestions = generate_suggestions(alert)
confirmed = human_confirm(suggestions, Role.SYSTEM_ADMIN)
final = security_approve(confirmed, suggestions)
print("\n最终执行计划:", final)

这段代码展示了三个关键设计点:

  1. AI 只生成建议,不做最终决策——generate_suggestions 返回的是带风险标注的选项列表。
  2. 确认动作按角色和风险分级——低风险系统管理员可直接拍板,中高风险必须走安全管理员审批。
  3. 审计管理员全程只读——即使看到建议,也无权确认执行。

落地时的取舍

把这套机制引入现有运维体系,有几个现实问题需要权衡:

  • 交互成本 vs 自动化效率:每一步都让人确认,处置速度会慢下来。建议对低风险操作设置"批量确认"或"自动执行+事后审计"模式,只把中高危操作卡在审批节点。
  • 三员管理的人力成本:小团队可能没有足够的人分饰三个角色。Blueking Lite 作为轻量版产品,可以考虑"角色可合并但操作不可自审"的折中方案——同一个人可以兼任系统管理员和安全管理员,但高危操作仍需另一个人的审批。
  • AI 建议的可信度:如果 AI 生成建议的准确率不够高,运维人员会倾向于全部驳回,人机协同就退化回纯人工操作。建议在上线初期设置建议的"置信度阈值",低于阈值的不展示,避免信息噪音。

检查清单

引入人机协同决策和三员管理前,可以逐项确认:

  • [ ] AI 建议是否附带风险等级和影响范围标注?
  • [ ] 确认交互是否支持逐项勾选而非笼统同意?
  • [ ] 三员角色是否在权限层硬隔离(而非仅靠界面隐藏)?
  • [ ] 高危操作是否强制二次审批,且审批人不能是操作发起人?
  • [ ] 审计管理员是否只能读取日志,无法执行任何写操作?
  • [ ] 低风险操作是否有快速通道(批量确认或自动执行)?

这次更新把"人机协同"从概念推到了可操作的交互层面,配合三员管理的硬约束,算是给 AIOps 平台补上了最缺的那块——不是算法不够强,而是人怎么安全、高效地和算法一起干活。


相关推荐