自动化巡检工具的设计：让规范自己检查自己-尧图网络科技

自动化巡检工具的设计：让规范自己检查自己

一、规范躺在文档里，等于没写

生产环境的规范越积越多。配置基线、安全策略、资源标签、依赖版本，每条都不缺文档。问题在于，文档不等于执行。人工巡检看似稳妥，实则脆弱。

人记得住上线当天的检查项，记不住半年后的回归。团队轮岗、人员流动，规范很快在执行层断裂。等故障爆发，回头一看，规范其实早写明了，只是没人查。更隐蔽的是"配置漂移"。

线上资源被临时改动后未还原，时间一长就成了新基线。安全基线也一样，一个端口临时开放，忘了关，就成了长期暴露面。标签缺失则直接影响成本分摊与权限治理。自动化巡检要解决的就是这个断层。

把规范从文档里搬出来，变成可执行的检查规则。规则定期跑，结果可量化，例外可追溯。让规范自己检查自己，才是工程化治理的起点。

二、巡检即代码：规则引擎的运转机制

巡检工具的核心是"规则与执行分离"。规则用 DSL 描述，独立于代码发布。执行器按规则拉取资源当前状态，做匹配判断。判断结果分三档：通过、警告、阻断。

关键设计是"例外管理"。某些资源因业务原因暂时不合规，需要登记例外。例外必须带过期时间与责任人，到期自动失效。否则例外会越积越多，规则形同虚设。下面是规则引擎的运转链路：

机制上"规则与执行分离"带来两个好处。一是规则变更不需要重新发版，DSL 改了即生效。二是执行器可复用，同一套引擎跑不同类别的检查。还有一个要点是"幂等执行"。

巡检只读不写，多次跑结果应一致。这样结果可对比、可趋势化，撑起长期治理的度量。

三、Python 实现一个巡检规则引擎

下面实现规则加载、执行与例外管理的最小骨架。规则用 YAML 描述，便于运维侧独立维护。执行器抽象成接口，适配不同资源类型。

import yaml from dataclasses import dataclass from datetime import datetime from typing import Callable @dataclass class Rule: """单条巡检规则：DSL 解析后的内存形态""" rule_id: str severity: str # warn / block check: Callable[[dict], bool] # 返回 False 即违规 description: str = "" @classmethod def from_dict(cls, raw: dict) -> "Rule": # 把 DSL 表达式编译成可调用函数 # 生产应换安全表达式引擎，这里仅演示机制 expr = raw["check"] check_fn = eval(f"lambda r: {expr}", {"__builtins__": {}}, {}) return cls( rule_id=raw["id"], severity=raw["severity"], check=check_fn, description=raw.get("desc", ""), ) @dataclass class ExceptionRecord: """例外登记：带过期时间，防止永久豁免""" rule_id: str resource_id: str expires_at: datetime reason: str @dataclass class ReportItem: rule_id: str resource_id: str severity: str passed: bool excepted: bool = False class Inspector: """巡检引擎：加载规则、跑检查、汇总结果""" def __init__(self): self._rules: list[Rule] = [] self._exceptions: list[ExceptionRecord] = [] def load_rules(self, path: str) -> None: # 规则独立于代码，便于运维侧增删 with open(path, "r", encoding="utf-8") as f: for raw in yaml.safe_load(f) or []: self._rules.append(Rule.from_dict(raw)) def register_exception(self, exc: ExceptionRecord) -> None: self._exceptions.append(exc) def _is_excepted(self, rule_id: str, rid: str) -> bool: now = datetime.now() # 过期的例外视为无效，强制让规则重新生效 return any( e.rule_id == rule_id and e.resource_id == rid and e.expires_at > now for e in self._exceptions ) def run(self, resources: list[dict]) -> list[ReportItem]: results: list[ReportItem] = [] for res in resources: rid = res["id"] for rule in self._rules: try: ok = rule.check(res) except Exception: # 检查函数抛错按违规处理，避免静默漏检 ok = False excepted = self._is_excepted(rule.rule_id, rid) results.append(ReportItem( rule_id=rule.rule_id, resource_id=rid, severity=rule.severity, passed=ok or excepted, excepted=excepted, )) return results

配套的规则 YAML 示例如下：

- id: tag_env_required severity: warn check: "'env' in r.get('tags', {})" desc: 所有资源必须打 env 标签 - id: no_public_ingress severity: block check: "not r.get('public_ingress', False)" desc: 禁止公网入口直接暴露

真实系统会接资源拉取层（云厂商 API 或 CMDB）。并对接告警通道与可视化面板。执行器做成异步任务，避免阻塞主流程。

四、自动化巡检的代价与适用边界

巡检工具落地，代价不在写工具，在养规则。

误报噪音。规则写得太严，正常资源也报警。团队很快会对告警麻木，真正该修的反被忽略。应分级处理：阻断才告警，警告进面板。

规则维护成本。资源结构变了，规则不跟着改就会失效。规则要有 owner，定期 review。否则工具越跑越多"幽灵规则"。

执行权限。巡检要拉资源状态，需要只读权限。权限收紧到最小集合，避免巡检账号成为新的攻击面。

例外滥用。例外本是临时豁免，常被当永久豁免用。例外必须带过期时间，到期强制重新评审。没有时限的例外等于没有规则。

巡检工具的"规则治理"比工具本身更关键。规则会随业务膨胀，半年不清理就会堆积大量失效项。建议给每条规则打 owner 标签与最近一次命中时间，长期零命中的规则要么降级要么下线，避免噪音淹没真实问题。另一个常被忽视的点是"巡检结果的可解释性"：违规项要附带资源快照与规则文本，让被通知的人一眼看懂"哪里错了、该怎么改"，否则只会陷入反复沟通。最后，巡检本身也要被巡检，规则引擎、例外清单、告警通道的健康度，应当纳入同一套可观测体系，别让治理工具成了治理盲区。