运维平台走到"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.io 及 platformconfigs 等字段。核心思路是:每个角色的 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)
这段代码展示了三个关键设计点:
- AI 只生成建议,不做最终决策——
generate_suggestions返回的是带风险标注的选项列表。 - 确认动作按角色和风险分级——低风险系统管理员可直接拍板,中高风险必须走安全管理员审批。
- 审计管理员全程只读——即使看到建议,也无权确认执行。
落地时的取舍
把这套机制引入现有运维体系,有几个现实问题需要权衡:
- 交互成本 vs 自动化效率:每一步都让人确认,处置速度会慢下来。建议对低风险操作设置"批量确认"或"自动执行+事后审计"模式,只把中高危操作卡在审批节点。
- 三员管理的人力成本:小团队可能没有足够的人分饰三个角色。Blueking Lite 作为轻量版产品,可以考虑"角色可合并但操作不可自审"的折中方案——同一个人可以兼任系统管理员和安全管理员,但高危操作仍需另一个人的审批。
- AI 建议的可信度:如果 AI 生成建议的准确率不够高,运维人员会倾向于全部驳回,人机协同就退化回纯人工操作。建议在上线初期设置建议的"置信度阈值",低于阈值的不展示,避免信息噪音。
检查清单
引入人机协同决策和三员管理前,可以逐项确认:
- [ ] AI 建议是否附带风险等级和影响范围标注?
- [ ] 确认交互是否支持逐项勾选而非笼统同意?
- [ ] 三员角色是否在权限层硬隔离(而非仅靠界面隐藏)?
- [ ] 高危操作是否强制二次审批,且审批人不能是操作发起人?
- [ ] 审计管理员是否只能读取日志,无法执行任何写操作?
- [ ] 低风险操作是否有快速通道(批量确认或自动执行)?
这次更新把"人机协同"从概念推到了可操作的交互层面,配合三员管理的硬约束,算是给 AIOps 平台补上了最缺的那块——不是算法不够强,而是人怎么安全、高效地和算法一起干活。