从传统Unix监控到现代可观测性：SystemVll/Montscan的演进与实践

1. 项目概述：一个被误解的“系统”及其真实价值

最近在整理一些老旧的系统文档和代码仓库时，我反复看到一个组合词：“SystemVll/Montscan”。乍一看，这像是一个标准的系统名称，或许是某个商业监控软件的代号，或者是某个内部项目的简称。但当我真正深入去追溯它的来源、拆解它的构成，并与几位经历过那个时代的老同事交流后，我发现，这远不是一个简单的软件名称。它更像是一个特定历史时期、特定技术栈下，一群工程师为了解决一个经典而棘手的运维难题，所构建的一套方法论、工具链与实践模式的“黑话”总称。今天，我就来彻底拆解这个听起来很唬人的“SystemVll/Montscan”，还原它背后的核心需求、技术本质，并分享如何用现代技术栈复现其核心思想，甚至做得更好。

简单来说，你可以把“SystemVll/Montscan”理解为一个面向传统Unix System V Release 4（SVR4）及其衍生系统（如某些老版本的Solaris、UnixWare）的、以文件系统与进程监控为核心的综合诊断与自动化响应框架。它的诞生，源于在分布式概念尚未普及、云计算还是天方夜谭的年代，运维人员如何管理成百上千台物理服务器上的关键服务。那个时代，没有成熟的APM，没有开源的Prometheus，甚至没有完善的SNMP代理。一切监控与诊断，都高度依赖于操作系统原生提供的工具和自研脚本。“Montscan”很可能就是“Monitoring”与“Scan”的合成词，直指其核心动作：监控与扫描。

这套“系统”的目标用户非常明确：大型企业或机构中，负责维护关键业务系统（如电信计费、金融交易）的资深系统管理员和运维工程师。他们面临的典型场景是：在深夜，某个核心应用的响应速度突然变慢，或交易失败率飙升。他们需要快速定位问题是在应用层、中间件、还是操作系统资源层面。而“SystemVll/Montscan”提供的就是一套从数据采集（扫描系统状态）、到分析判断（基于阈值和模式）、再到执行响应动作（如重启服务、清理缓存）的半自动化流水线。理解它，不仅是对一段技术历史的回顾，更能让我们深刻理解监控体系的底层逻辑，从而在今天设计出更健壮、更本质的解决方案。

2. 核心架构与设计哲学拆解

要理解“SystemVll/Montscan”，不能把它看作一个单一的软件，而应视为一个由多个松散耦合的组件按照既定工作流组合而成的“解决方案”。它的设计哲学深深烙印着早期Unix的KISS（Keep It Simple, Stupid）原则和管道（Pipe）哲学：每个工具只做好一件事，然后通过Shell脚本将它们串联起来，形成强大的处理能力。

2.1 核心组件映射与功能解构

基于其名称和时代背景，我们可以推断出它的核心组件大致分为以下几层：

1. 数据采集层（Scan Agents）：这是“Montscan”中“Scan”的体现。它并非一个常驻的守护进程，而更可能是一系列通过cron定时调用的Shell脚本（如Bourne Shell或Korn Shell）。这些脚本会利用SVR4系统原生的命令工具，采集关键指标：

   • 系统资源：使用sar（System Activity Reporter）、vmstat、iostat、mpstat收集CPU、内存、磁盘I/O、网络流量历史与实时数据。sar是SVR4监控的瑰宝，它能以二进制格式记录历史数据，供日后分析。
   • 进程与文件系统：使用ps、prstat（Solaris）、pfiles检查进程状态、资源占用和打开的文件。使用df、du、find监控文件系统容量、关键目录大小增长以及特定文件（如日志、锁文件、PID文件）的存在与否。
   • 网络与端口：使用netstat、ndd（Solaris下查询网络参数）检查网络连接状态、监听端口。使用ping、traceroute进行基本的网络可达性检查。

2. 分析与判断层（Rule Engine）：这一层是“系统”的大脑，通常由更复杂的Shell脚本或Perl脚本实现。它负责解析采集层输出的文本数据。其核心逻辑是基于阈值的规则判断：

   • 阈值检查：例如，解析df -k的输出，检查/或/var文件系统的使用率是否超过85%；解析ps -ef的输出，统计某个关键进程（如oracle）的数量是否为零（进程消失）或异常增多（可能进程僵死或fork炸弹）。
   • 模式匹配：使用grep、awk、sed对日志文件进行实时或周期性的扫描，寻找“ERROR”、“Fatal”、“panic”等错误关键词，或者特定的事务ID失败模式。
   • 状态关联：简单的关联分析，例如，当发现文件系统满的同时，又检测到某个应用日志停止写入，则很可能推断出是磁盘空间不足导致应用异常。

3. 响应与告警层（Action Executor）：当分析层判断异常发生时，响应层被触发。行动可能包括：

   • 本地修复动作：自动执行预定义的修复脚本，如kill -HUP重启某个进程、rm -f /tmp/*.lock清理陈旧锁文件、archive_logs.sh归档并清理旧日志以释放空间。
   • 告警通知：通过最原始但有效的方式发出告警，例如：
     • 调用mailx或sendmail命令发送邮件给值班人员。
     • 使用wall命令向所有登录用户广播紧急消息（在控制台环境）。
     • 更“高级”的，可能通过自定义的Socket客户端将告警事件写入一个中央的告警服务器（如果存在的话）。
   • 状态上报：将本次检查的结果（正常或异常）以及执行的行动，记录到一个本地的状态文件或通过syslog写入系统日志，便于事后审计。

2.2 设计局限性与时代烙印

理解了其组成，我们就能看清它的优点与固有的局限性，这也是为什么它最终会被更现代的监控体系所取代。

优势：

• 轻量级，零外部依赖：完全基于操作系统自带工具，部署简单，几乎不消耗额外资源。
• 高度灵活和可定制：Shell脚本的灵活性使得它可以针对任何可观测的现象编写检查逻辑，适应性强。
• 直接、无抽象：直接调用系统命令，获取第一手信息，没有中间层的性能损耗和信息失真。

局限性：

• 无统一数据模型：采集的数据是杂乱的文本输出，解析规则脆弱，极易因命令输出格式的微小变化（甚至只是语言环境不同）而崩溃。
• 缺乏历史趋势与可视化：sar虽有历史记录，但分析和可视化能力极弱。难以进行容量规划、趋势预测。
• 告警风暴与噪声：规则通常简单粗暴，容易产生大量重复、无意义的告警，缺乏降噪、聚合、升级的机制。
• 可扩展性差：每台服务器独立运行，难以进行集中配置管理和统一分析。跨主机的关联分析几乎不可能。
• 可靠性存疑：脚本本身的健壮性（错误处理、超时控制）和安全性（权限控制）往往不足。

实操心得：我曾维护过类似这样的脚本体系。最大的教训是，一定要在解析命令输出时，使用最稳定、最明确的字段定位方式。比如，用awk提取数据时，尽量使用$NF（最后一个字段）或明确的字段编号，并结合grep过滤掉标题行，避免因系统版本或配置不同导致解析失败。例如，获取根分区使用率：df -k / | awk 'NR==2 {print $5}' | tr -d '%'就比依赖列位置的写法更可靠。

3. 核心监控项与采集脚本实现详解

让我们抛开“SystemVll/Montscan”这个神秘外壳，直接深入到其核心——具体监控什么以及如何实现。以下是我根据其设计思路，用现代但依然遵循其哲学（使用原生工具+Shell）还原的几个关键监控脚本示例。请注意，这些脚本在当今生产环境中已不推荐作为主力，但用于理解原理和快速搭建临时诊断工具依然极具价值。

3.1 文件系统容量监控与告警

这是最经典、最不可或缺的监控项。脚本需要定时检查关键文件系统的使用率，并在超过阈值时告警。

#!/bin/ksh # 文件系统监控脚本 fs_monitor.sh # 适用于 SVR4 及兼容系统（如 Solaris） THRESHOLD=85 CRITICAL_THRESHOLD=95 ADMIN_EMAIL="ops-team@company.com" HOSTNAME=$(uname -n) # 检查的文件系统列表，可根据需要修改 FILESYSTEMS="/ /var /opt /home" for FS in $FILESYSTEMS; do # 使用df命令获取使用率，注意不同系统的df输出格式可能略有不同 USAGE=$(df -k $FS | awk 'NR==2 {print $5}' | tr -d '%') if [ -z "$USAGE" ]; then echo "无法获取文件系统 $FS 的信息。" | mailx -s "[ERROR] FS Monitor Failed on $HOSTNAME" $ADMIN_EMAIL continue fi if [ $USAGE -ge $CRITICAL_THRESHOLD ]; then SUBJECT="[CRITICAL] 文件系统 $FS 使用率 ${USAGE}% 于 $HOSTNAME" MESSAGE="主机 $HOSTNAME 上的文件系统 $FS 使用率已达到 ${USAGE}%，超过严重阈值 ${CRITICAL_THRESHOLD}%。请立即处理！\n\n$(df -h $FS)" echo "$MESSAGE" | mailx -s "$SUBJECT" $ADMIN_EMAIL # 可以在此触发更紧急的动作，如尝试自动清理临时文件 /usr/bin/find /tmp -type f -name "*.log" -mtime +7 -exec rm {} \; 2>/dev/null elif [ $USAGE -ge $THRESHOLD ]; then SUBJECT="[WARNING] 文件系统 $FS 使用率 ${USAGE}% 于 $HOSTNAME" MESSAGE="主机 $HOSTNAME 上的文件系统 $FS 使用率已达到 ${USAGE}%，超过警告阈值 ${THRESHOLD}%。请注意。\n\n$(df -h $FS)" echo "$MESSAGE" | mailx -s "$SUBJECT" $ADMIN_EMAIL fi done # 记录本次检查到日志 echo "$(date): 文件系统检查完成。" >> /var/log/montscan_fs.log

关键点解析：

1. 健壮性处理：if [ -z “$USAGE” ]用于判断df命令是否成功获取到数据，避免在无效数据上进行数值比较导致脚本崩溃。
2. 阈值分级：设置了WARNING和CRITICAL两级阈值，对应不同的告警严重程度和响应动作。
3. 动作执行：在达到CRITICAL阈值时，除了告警，还尝试执行一个自动清理动作（删除7天前的/tmp下日志文件），这体现了“自动响应”的思想。
4. 日志记录：所有操作都有本地日志，便于追溯。

3.2 关键进程存活性与资源监控

确保关键业务进程（如数据库、应用服务器）持续运行且资源消耗正常。

#!/bin/ksh # 进程监控脚本 process_monitor.sh PROCESS_NAME="java" # 要监控的进程名，例如Java应用 EXPECTED_COUNT=2 # 期望的进程数量 CPU_THRESHOLD=80 # 单个进程CPU使用率警告阈值(%) MEM_THRESHOLD=10240 # 单个进程内存使用量警告阈值(KB) PID_LIST=$(ps -ef | grep -v grep | grep $PROCESS_NAME | awk '{print $2}') CURRENT_COUNT=$(echo "$PID_LIST" | wc -w | tr -d ' ') # 1. 检查进程数量 if [ $CURRENT_COUNT -eq 0 ]; then echo "[CRITICAL] 进程 $PROCESS_NAME 不存在！尝试自动启动..." | mailx -s "进程宕机告警" $ADMIN_EMAIL # 此处应调用启动脚本，例如： # /opt/app/bin/startup.sh > /dev/null 2>&1 & elif [ $CURRENT_COUNT -lt $EXPECTED_COUNT ]; then echo "[WARNING] 进程 $PROCESS_NAME 数量不足。期望: $EXPECTED_COUNT, 当前: $CURRENT_COUNT" | mailx -s "进程数量异常" $ADMIN_EMAIL elif [ $CURRENT_COUNT -gt $EXPECTED_COUNT ]; then echo "[WARNING] 进程 $PROCESS_NAME 数量异常增多。期望: $EXPECTED_COUNT, 当前: $CURRENT_COUNT" | mailx -s "进程数量异常" $ADMIN_EMAIL fi # 2. 检查每个存活进程的资源使用情况 for PID in $PID_LIST; do # 使用ps获取特定进程的CPU和内存信息。注意：ps的CPU是累计值，这里只是一个瞬时快照，不精确，用于粗略判断。 PROCESS_INFO=$(ps -o pcpu,pmem,rss,vsz -p $PID | tail -1) CPU_USAGE=$(echo $PROCESS_INFO | awk '{print $1}') MEM_USAGE=$(echo $PROCESS_INFO | awk '{print $4}') # 使用RSS（常驻内存集，单位KB） # 将浮点数CPU转换为整数进行比较（bash不支持浮点比较，ksh稍好，这里用awk处理） CPU_INT=$(echo $CPU_USAGE | awk '{printf "%d", $1}') if [ $CPU_INT -ge $CPU_THRESHOLD ]; then echo "[WARNING] 进程 $PROCESS_NAME (PID:$PID) CPU使用率过高: ${CPU_USAGE}%" >> /tmp/high_cpu.msg fi if [ $MEM_USAGE -ge $MEM_THRESHOLD ]; then echo "[WARNING] 进程 $PROCESS_NAME (PID:$PID) 内存使用过高: ${MEM_USAGE}KB" >> /tmp/high_mem.msg fi done # 如果有资源警告，汇总发送邮件 if [ -f /tmp/high_cpu.msg ] || [ -f /tmp/high_mem.msg ]; then cat /tmp/high_cpu.msg /tmp/high_mem.msg 2>/dev/null | mailx -s "[WARNING] 进程资源异常" $ADMIN_EMAIL rm -f /tmp/high_cpu.msg /tmp/high_mem.msg fi

关键点解析：

1. 进程识别：使用ps -ef | grep查找进程，但必须用grep -v grep排除掉grep命令自身。更严谨的做法是使用pgrep命令（如果系统支持）。
2. 资源监控的局限性：脚本中通过ps获取的CPU百分比是进程生命周期内的平均CPU时间，并非实时占用率。对于实时监控，prstat（Solaris）或top -b -n 1 -p $PID（Linux）是更好的选择，但输出解析更复杂。这正体现了原生工具监控的粗糙之处。
3. 自动恢复：在进程消失时尝试自动启动，这是自动化响应的核心体现。但必须非常小心，要确保启动脚本是幂等的，且不会在短时间内因某种原因反复重启进程，形成“重启风暴”。

注意事项：这种基于进程名的监控在微服务或容器化环境中基本失效。现代方法更倾向于通过进程监听的端口、提供的HTTP健康检查端点或通过Sidecar代理来汇报状态。

4. 从“Montscan”到现代监控体系的演进与实践

理解了“SystemVll/Montscan”的本质，我们就能清晰地看到监控体系的演进路径。今天的我们不再需要从头编写如此脆弱的脚本，而是有了一系列强大、稳定、生态丰富的工具。下面，我将以复现“Montscan”核心思想为目标，介绍如何用现代技术栈（以Prometheus为例）构建一个更强大、更可靠的监控系统。

4.1 现代监控体系的核心组件对标

4.2 使用Node Exporter实现基础系统监控

Node Exporter完美替代了那些采集CPU、内存、磁盘、网络的Shell脚本。它以一个简单的二进制文件运行，暴露了成千上万个系统指标。

部署与运行：

# 下载并解压Node Exporter wget https://github.com/prometheus/node_exporter/releases/download/v1.6.1/node_exporter-1.6.1.linux-amd64.tar.gz tar xvfz node_exporter-1.6.1.linux-amd64.tar.gz cd node_exporter-1.6.1.linux-amd64 # 以后台方式运行，监听在9100端口 ./node_exporter &

访问http://your-server-ip:9100/metrics，你将看到所有采集到的指标，格式是标准的Prometheus文本格式。例如：

# HELP node_filesystem_size_bytes Filesystem size in bytes. # TYPE node_filesystem_size_bytes gauge node_filesystem_size_bytes{device="/dev/sda1",fstype="ext4",mountpoint="/"} 1.073741824e+10 node_filesystem_avail_bytes{device="/dev/sda1",fstype="ext4",mountpoint="/"} 5.36870912e+09

配置Prometheus抓取：在Prometheus的prometheus.yml配置文件中添加：

scrape_configs: - job_name: 'node' static_configs: - targets: ['your-server-ip:9100']

现在，所有基础系统指标都已进入Prometheus的时序数据库，可以通过PromQL进行查询和告警。

4.3 使用Prometheus告警规则复现核心逻辑

以下是在Prometheus中配置告警规则文件（如alerts.yml）的示例，它直接对应了之前Shell脚本中的检查逻辑，但更强大、更可靠。

groups: - name: host_alerts rules: # 规则1：磁盘使用率告警 (对应 fs_monitor.sh) - alert: HostDiskSpaceRunningOut expr: (node_filesystem_size_bytes{mountpoint="/"} - node_filesystem_avail_bytes{mountpoint="/"}) / node_filesystem_size_bytes{mountpoint="/"} * 100 > 85 for: 5m # 持续5分钟超过阈值才触发，避免瞬时波动 labels: severity: warning annotations: summary: "主机 {{ $labels.instance }} 根分区使用率过高" description: "{{ $labels.instance }} 的根分区使用率已达 {{ $value | printf \"%.2f\" }}%，超过85%的警告阈值。" - alert: HostDiskSpaceCritical expr: (node_filesystem_size_bytes{mountpoint="/"} - node_filesystem_avail_bytes{mountpoint="/"}) / node_filesystem_size_bytes{mountpoint="/"} * 100 > 95 for: 2m labels: severity: critical annotations: summary: "主机 {{ $labels.instance }} 根分区即将写满！" description: "{{ $labels.instance }} 的根分区使用率已达 {{ $value | printf \"%.2f\" }}%，超过95%的严重阈值，请立即处理！" # 规则2：进程存活告警 (对应 process_monitor.sh，需要process-exporter或自定义exporter) # 假设我们通过一个自定义的exporter监控了名为“myapp”的服务进程数，指标为 `myapp_process_count` - alert: MyAppProcessDown expr: myapp_process_count == 0 for: 1m labels: severity: critical annotations: summary: "MyApp 进程在 {{ $labels.instance }} 上已宕机" description: "关键服务 MyApp 的进程数在 {{ $labels.instance }} 上为0，服务已不可用。" # 规则3：系统负载告警 (对应 sar, vmstat 的监控) - alert: HostHighLoad expr: node_load5 / count(node_cpu_seconds_total{mode="system"}) by (instance) > 1.5 for: 10m labels: severity: warning annotations: summary: "主机 {{ $labels.instance }} 负载过高" description: "{{ $labels.instance }} 的5分钟平均负载是核心数的1.5倍以上，当前值为 {{ $value | printf \"%.2f\" }}。"

关键优势：

1. 声明式配置：告警逻辑通过表达式（expr）清晰定义，易于管理和版本控制。
2. 强大的查询语言：PromQL允许进行复杂的多维度聚合、计算和关联分析，这是Shell脚本难以企及的。
3. 内置降噪机制：for子句实现了告警延迟触发，有效过滤瞬时抖动。
4. 灵活的标签系统：通过labels和annotations，告警信息可以携带丰富的上下文，便于在Alertmanager中进行分组和路由。

4.4 配置Alertmanager实现智能告警通知

Alertmanager接收来自Prometheus的告警，并进行处理。以下是一个简单的alertmanager.yml配置示例，实现邮件通知和Webhook调用（用于自动化响应）。

global: smtp_smarthost: 'smtp.company.com:587' smtp_from: 'alertmanager@company.com' smtp_auth_username: 'alertmanager' smtp_auth_password: 'your-password' route: group_by: ['alertname', 'cluster', 'service'] # 按告警名、集群、服务分组 group_wait: 30s # 同一分组内，等待30s再发送，以便聚合 group_interval: 5m # 同一分组内，告警间隔至少5分钟 repeat_interval: 12h # 重复告警的间隔 receiver: 'default-email' routes: - match: severity: critical receiver: 'critical-webhook' # 严重告警走Webhook，可能触发自动化 continue: false # 匹配后不再继续向下路由 receivers: - name: 'default-email' email_configs: - to: 'ops-team@company.com' headers: subject: '[{{ .Status | toUpper }}] {{ .GroupLabels.alertname }} on {{ .GroupLabels.instance }}' - name: 'critical-webhook' webhook_configs: - url: 'http://your-automation-platform/api/v1/alert' send_resolved: true # 也发送恢复通知

这个配置实现了：

• 告警分组与抑制：相同类型的告警会被聚合在一起发送，避免“告警风暴”。
• 分级路由：critical级别的告警会发送到Webhook，触发自动化响应流程；其他告警则发送邮件。
• 静默与抑制：Alertmanager还支持基于标签的静默规则，可以在计划维护期间屏蔽特定告警。

5. 常见问题、排查技巧与演进思考

即使采用了现代监控体系，在构建和运维过程中，我们依然会遇到各种问题。以下是一些从“Montscan”时代到云原生时代都通用的监控实践心得和常见问题排查技巧。

5.1 监控数据不准或丢失

• 问题：Node Exporter指标缺失，或数值明显不合理（如磁盘使用率超过100%）。
• 排查：
  1. 检查Exporter状态：首先访问http://exporter-ip:9100/metrics，看是否能正常获取数据，并检查是否有相关指标（如node_filesystem_*）。
  2. 检查挂载点过滤：Node Exporter默认可能会过滤掉某些文件系统（如网络文件系统、虚拟文件系统）。检查Node Exporter的启动参数，确保--collector.filesystem.ignored-mount-points或--collector.filesystem.ignored-fs-types没有误过滤掉你需要监控的挂载点。
  3. 检查Prometheus抓取配置：在Prometheus的Web UI（http://prometheus-ip:9090/targets）中查看对应Target的State是否为UP，以及是否有抓取错误信息。
  4. 检查时间同步：确保监控服务器（Prometheus）和被监控节点（Node Exporter）之间的时间基本同步（NTP），否则告警时间戳会混乱。

5.2 告警规则不触发或误报频繁

• 问题：配置了告警规则，但预期的情况发生时没有告警；或者告警频繁触发，但实际系统正常。
• 排查与优化：
  1. 验证PromQL表达式：在Prometheus的Graph页面或使用promtool命令行工具，手动执行你的告警规则表达式，确认它能返回你期望的时间序列数据。
  2. 合理设置for持续时间：这是抑制瞬时毛刺的关键。对于CPU使用率、负载等波动较大的指标，for时间应设置得长一些（如5-10分钟）。对于进程宕机这种明确事件，可以设置较短（如1分钟）。
  3. 使用rate()或increase()处理计数器：对于像网络流量、请求数这类计数器（counter）类型的指标，直接使用其原始值没有意义，必须使用rate()或increase()函数计算速率或增量。例如，监控网络错误率：rate(node_network_receive_errs_total[5m]) > 0。
  4. 避免“布尔告警器”：像up{job="node"} == 0这样的告警，一旦目标恢复，告警就会消失，你可能会错过它。更好的做法是使用absent(up{job="node"})，它会在目标丢失期间持续告警。

5.3 从“监控”到“可观测性”的演进思考

“SystemVll/Montscan”代表的是经典的**监控（Monitoring）思维，即基于已知的故障模式（如磁盘满、进程死）设置检查点。而现代运维正在向可观测性（Observability）**演进，其核心是：当发生未知的、前所未见的故障时，我们能否通过系统外部输出的数据（指标、日志、链路追踪），快速定位到问题的根因？

1. 三大支柱：

   • Metrics（指标）：即Prometheus所做的，用于回答“发生了什么”和“有多严重”。它是监控的基石。
   • Logging（日志）：结构化的、带有上下文的日志（如JSON格式），通过ELK Stack或Loki进行集中收集和检索，用于回答“为什么发生”和“详细的错误上下文”。
   • Tracing（链路追踪）：如Jaeger、Zipkin，用于追踪一个请求在分布式系统中流经的所有服务，用于回答“请求在哪里变慢或失败”以及“服务间的依赖关系如何”。

2. 实践建议：

   • 指标与日志关联：在告警信息中，不仅包含指标值，还应包含可以快速定位相关日志的线索，例如主机名、时间戳、服务名、请求ID等。这能极大缩短故障排查时间。
   • 建立服务拓扑图：利用服务发现和链路追踪数据，自动生成系统服务依赖图。当某个底层服务故障时，可以直观地看到所有受影响的上游服务。
   • 拥抱SLO（服务等级目标）：不要只监控基础设施（CPU、内存），更要监控业务层面的用户体验。定义如“登录接口99.9%的请求延迟低于200ms”这样的SLO，并基于此设置告警（如错误预算耗尽告警）。这才是真正以用户为中心的监控。

最后一点个人体会：回顾“SystemVll/Montscan”这样的老系统，最大的价值不是去复刻它，而是理解其背后“采集-分析-响应”的朴素闭环思想。今天的工具链（Prometheus、Grafana、Alertmanager、ELK/Loki、Jaeger）将这个闭环的能力提升了数个数量级。我们的重点应该放在如何更好地运用这些工具，设计出贴合自身业务、能快速发现并定位问题的可观测性体系，而不是沉迷于编写和维护脆弱的脚本。毕竟，运维的终极目标不是让自己成为救火队员，而是让系统稳定到无需救火。