自动化脚本

概述 监控系统本身也需要被监控。Prometheus 采集了整个基础设施的指标，但如果 Prometheus 自己的配置出了问题、某个 target 掉线了、SSL 证书快过期了、告警规则写得有语法错误——谁来发现这些问题？答案是：一套自动化巡检脚本。本文围绕 Prometheus 生态，构建一套覆盖"拨测→证书检查→配置审计→规则验证→告警模拟→报表生成"的完整巡检工具集。 参考来源：Prometheus 官方文档、Blackbox Exporter 一、批量服务拨测脚本 1.1 基于 Blackbox Exporter 的拨测 Blackbox Exporter 是 Prometheus 官方的黑盒探测工具，支持 HTTP、TCP、ICMP、DNS 等协议。通过 Prometheus API 查询探测结果，可以实现批量服务健康检查： #!/usr/bin/env python3 """ 批量服务拨测脚本 通过 Prometheus API 查询 Blackbox Exporter 探测结果 """ import requests import json from datetime import datetime from typing import List, Dict, Optional from dataclasses import dataclass, asdict import smtplib from email.mime.text import MIMEText import sys @dataclass class ProbeResult: """探测结果""" instance: str module: str # http_2xx, tcp_connect, icmp 等 success: bool status_code: Optional[int] duration: float # 探测耗时（秒） error: Optional[str] last_error: Optional[str] ssl_cert_expiry_days: Optional[float] class PrometheusProber: """Prometheus 拨测器""" def __init__(self, prometheus_url: str, timeout: int = 30): self....

概述 Pipeline as Code 是 Jenkins 从"拖拽式配置"走向"代码化"的分水岭。把流水线定义写在 Jenkinsfile 中，纳入 Git 版本控制，意味着每次流水线变更都有 diff 可审查、有历史可追溯、有分支可回滚。从 Jenkinsfile 语法到生产级流水线设计，详细梳理 Pipeline as Code 的核心实践。 参考来源：Jenkins Pipeline 官方文档 一、Jenkinsfile 语法 1.1 声明式 vs 脚本式 Jenkins Pipeline 有两种语法风格： 维度 声明式（Declarative） 脚本式（Scripted） 语法 结构化 DSL Groovy 代码 可读性 高，接近配置文件 低，需要 Groovy 知识 灵活性 受限于 DSL 约束 完全自由 输入验证 内置 post、when 等结构 需手动实现 推荐场景 标准流水线、团队协作 复杂逻辑、条件分支多 // === 声明式 Pipeline === pipeline { agent any stages { stage('Build') { steps { sh 'make build' } } } } // === 脚本式 Pipeline === node { stage('Build') { sh 'make build' } } 实践建议：优先用声明式，仅在声明式无法表达的复杂逻辑处用 script {} 块嵌入脚本式代码。...

概述 日志是系统运行时留下的最真实记录。当线上出问题时，日志是第一现场；当需要洞察系统行为时，日志是最丰富的数据源。但日志分析不是 grep 几个关键词那么简单——面对每天几十 GB 的日志，你需要高效的解析、灵活的聚合、智能的异常检测和清晰的可视化。本文用 Python 从零搭建一套完整的日志分析工具链。 参考来源：Python re 模块文档、pandas 文档 一、日志解析基础 1.1 正则表达式解析 日志解析的核心是把非结构化文本变成结构化数据。正则表达式是最基础也最灵活的工具： import re from datetime import datetime from typing import NamedTuple, Optional class LogEntry(NamedTuple): timestamp: datetime level: str message: str source: Optional[str] = None # 通用应用日志格式：2026-07-10 14:32:01 [ERROR] [app.payment] Payment failed: order=12345 APP_LOG_PATTERN = re.compile( r'(?P<timestamp>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2})\s+' r'\[(?P<level>DEBUG|INFO|WARN|WARNING|ERROR|FATAL)\]\s+' r'(?:\[(?P<source>[\w.]+)\]\s+)?' r'(?P<message>.+)' ) def parse_app_log(line: str) -> Optional[LogEntry]: """解析应用日志行""" match = APP_LOG_PATTERN.match(line.strip()) if not match: return None return LogEntry( timestamp=datetime....

概述 代码质量问题越早发现，修复成本越低。在提交阶段拦截比在 CI 阶段拦截快，在 CI 阶段拦截比在生产环境出问题后修复快。Git Hooks 提供了在提交和推送的关键节点自动执行检查的能力——格式化代码、运行 lint、验证提交信息、执行测试。从 Git Hooks 原理到工具链实践，构建一套从本地到 CI 的代码质量自动化体系。 参考来源：Git Hooks 官方文档、pre-commit 官网 一、Git Hooks 体系 1.1 Hooks 概览 Git Hooks 是 Git 在特定操作（如 commit、push、merge）发生时自动执行的脚本，存放在 .git/hooks/ 目录中： Hook 名称 触发时机 常见用途 是否可跳过 pre-commit commit 执行前 代码格式化、lint 检查 --no-verify prepare-commit-msg 编辑提交信息前 自动生成提交信息模板 - commit-msg 提交信息写入后 验证提交信息格式 --no-verify post-commit commit 完成后 通知、统计 否 pre-push push 执行前 运行测试、防止推送到 protected 分支 --no-verify pre-merge-commit merge 完成前 合并前检查 - post-merge merge 完成后 恢复依赖、更新子模块 否 pre-rebase rebase 执行前 防止 rebase 已推送的提交 - post-checkout 切换分支后 恢复环境 否 1....

概述 Ansible 的上手门槛很低——一个 YAML 文件、几行 yum install 就能跑通。但当你面对几百台服务器、多套环境、复杂的依赖关系和严格的变更审计要求时，“能跑"和"能上线"之间隔着一整个工程体系。本文把生产级 Playbook 的核心实践浓缩成一份可操作的指南，涵盖从结构组织到性能优化的全链路。 参考来源：Ansible 官方好的实践 一、Playbook 结构优化 1.1 目录布局 生产级 Ansible 项目应该遵循标准目录结构。这不是 Ansible 的强制要求，而是大量团队踩坑后形成的共识： production-project/ ├── ansible.cfg # 项目级配置 ├── inventory/ │ ├── production/ │ │ ├── hosts.ini # 生产环境主机清单 │ │ └── group_vars/ │ │ ├── all.yml # 所有环境共享变量 │ │ ├── web.yml # web 组专用变量 │ │ └── db.yml # db 组专用变量 │ └── staging/ │ ├── hosts.ini │ └── group_vars/ │ └── all....

概述 很多人对 Makefile 的印象停留在 C/C++ 编译辅助工具。但 Make 本质上是一个依赖关系驱动的任务执行引擎——你告诉它"目标是什么、依赖什么、怎么生成"，它负责按正确顺序执行并跳过无需重复的步骤。这种模型在运维场景中同样强大：部署依赖构建、清理依赖停止服务、检查依赖配置就绪。从语法基础到运维实战，把 Makefile 的能力完整展开。 参考来源：GNU Make 手册 一、Makefile 语法基础 1.1 基本结构 # 目标: 依赖 # 命令（必须用 Tab 缩进，不能用空格） target: dependencies command1 command2 一个实际例子： # Makefile - 基础示例 hello: main.c utils.c gcc -o hello main.c utils.c -Wall clean: rm -f hello *.o .PHONY: clean 关键规则：命令行必须以 Tab 开头，不是空格。这是 Makefile 最常见的初学者错误。 1.2 执行机制 Make 的工作流程分三步： 解析：读取 Makefile，构建依赖关系图 比较：检查每个目标的修改时间，判断是否需要重新生成 执行：按拓扑排序执行过时目标的命令 目标文件不存在 → 执行命令生成 目标文件存在，但依赖更新 → 重新执行 目标文件存在，依赖未变 → 跳过（这就是增量构建的核心） # 执行第一个目标 make # 执行指定目标 make clean # 指定 Makefile 文件 make -f MyMakefile build # 并行执行（利用多核） make -j4 # 只打印命令不执行 make -n # 强制重新生成 make -B # 输出详细执行过程 make V=1 二、变量与函数 2....

概述 定时任务是运维自动化的基础组件——日志轮转、数据备份、证书续期、健康检查、报表生成，几乎每个运维场景都离不开定时执行。大多数人对定时任务的认知停留在 crontab -e 加一行 0 2 * * * /path/to/script.sh，但这在生产环境中远远不够：任务失败了谁通知？执行超时了谁处理？多台机器上的任务怎么协调？从 cron 到 systemd timer 到分布式调度，逐步梳理定时任务的管理实践。 参考来源：cron Wikipedia、systemd.timer 官方文档 一、cron 语法与局限 1.1 cron 表达式 cron 表达式由 5 个字段组成： ┌──────── 分钟 (0-59) │ ┌────── 小时 (0-23) │ │ ┌──── 日 (1-31) │ │ │ ┌── 月 (1-12) │ │ │ │ ┌ 星期 (0-7, 0和7都是周日) │ │ │ │ │ * * * * * command 表达式 含义 0 2 * * * 每天凌晨 2:00 */15 * * * * 每 15 分钟 0 */6 * * * 每 6 小时 0 0 * * 0 每周日 0:00 0 0 1 * * 每月 1 号 0:00 30 3-5 * * * 3:30, 4:30, 5:30 0 0 1 1,4,7,10 * 每季度首月 1 号 @reboot 系统启动时 @daily / @midnight 每天 0:00 @weekly 每周日 0:00 @monthly 每月 1 号 0:00 @yearly / @annually 每年 1 月 1 日 0:00 1....

概述 kubectl 是 Kubernetes 管理员最常用的工具，但大多数人只用了它 20% 的功能。每天敲几十遍 kubectl get pods -n production，却不知道一行别名就能省掉一半字符；遇到问题只知道 kubectl describe 和 kubectl logs，却不知道 krew 插件能一键排查网络、资源、证书问题。本文逐步梳理 kubectl 的生产力提升工具链，从别名到插件到交互式工具，让你的 K8s 日常操作效率翻倍。 参考来源：kubectl 官方文档、krew 官网 一、kubectl 别名配置 1.1 基础别名 # ~/.bashrc 或 ~/.zshrc # 基础缩写 alias k='kubectl' alias kg='kubectl get' alias kd='kubectl describe' alias kdel='kubectl delete' alias ke='kubectl exec' alias kl='kubectl logs' alias kf='kubectl apply -f' alias kdf='kubectl delete -f' alias kr='kubectl run' # 常用资源缩写 alias kgp='kubectl get pods' alias kgs='kubectl get svc' alias kgn='kubectl get nodes' alias kgd='kubectl get deployments' alias kgsec='kubectl get secrets' alias kgcm='kubectl get configmaps' alias kging='kubectl get ingress' alias kgns='kubectl get namespaces' alias kgpv='kubectl get pv' alias kgpvc='kubectl get pvc' alias kdsa='kubectl describe sa' # 宽输出 + 自定义列 alias kgpw='kubectl get pods -o wide' alias kgsw='kubectl get svc -o wide' alias kgnw='kubectl get nodes -o wide' # watch 模式 alias kgpw='watch -n 2 kubectl get pods -o wide' alias kgnw='watch -n 5 kubectl get nodes -o wide' # 所有命名空间 alias kgpa='kubectl get pods --all-namespaces' alias kgsa='kubectl get svc --all-namespaces' # YAML 输出 alias kgpy='kubectl get pods -o yaml' alias kgsy='kubectl get svc -o yaml' 1....

前言 Shell 脚本是运维工程师最常用的自动化工具。本文记录几个实战中常用的脚本模式。 日志定期清理 服务器日志堆积是常见问题，以下脚本按保留天数自动清理： #!/bin/bash # clean_logs.sh - 日志清理脚本 LOG_DIR="/var/log/app" KEEP_DAYS=30 find "$LOG_DIR" -name "*.log" -type f -mtime +${KEEP_DAYS} -exec gzip {} \; find "$LOG_DIR" -name "*.gz" -type f -mtime +${KEEP_DAYS} -delete echo "$(date): 日志清理完成，保留 ${KEEP_DAYS} 天" 配合 crontab 每天执行： 0 2 * * * /opt/scripts/clean_logs.sh >> /var/log/clean_logs.log 2>&1 批量主机健康检查 通过 SSH 批量检查多台服务器状态： #!/bin/bash # health_check.sh - 批量健康检查 HOSTS=("web-01" "web-02" "db-01" "cache-01") THRESHOLD=80 for host in "${HOSTS[@]}"; do echo "--- ${host} ---" ssh "$host" " echo \"CPU: \$(top -bn1 | grep 'Cpu' | awk '{print \$2}')%\" echo \"MEM: \$(free | awk '/Mem/{printf \"%....

概述 Bash 是运维世界使用最广泛的脚本语言——几乎每台 Linux 服务器都自带解释器，无需安装任何运行时。但 Bash 也是最容易写出"能跑但不能信赖"脚本的语言：没有类型检查、错误默认静默、变量不加引号就分词、管道中的失败被吞掉。一个线上故障的根因往往就是某个 Bash 脚本没做错误处理。本文逐步梳理生产级 Bash 脚本的编写规范，让你写出的脚本不只是"能跑"，而是"可信赖"。 参考来源：Google Shell Style Guide、ShellCheck 一、脚本骨架：set -euo pipefail 1.1 三行头 每个生产级 Bash 脚本的开头应该是这样的： #!/usr/bin/env bash set -euo pipefail 这三行做的事情： 选项 作用 不加的后果 -e (errexit) 命令失败时立即退出 错误被忽略，脚本继续执行，可能导致灾难性后果 -u (nounset) 使用未定义变量时报错 拼写错误的变量名静默返回空字符串 -o pipefail 管道中任一命令失败则整体失败 管道中前面的命令失败被忽略，只看最后一个命令的退出码 一个经典反面案例： #!/bin/bash # 没有任何安全设置 cd /nonexistent/directory # 失败，但脚本继续 rm -rf * # 在当前目录执行了！灾难 加上 set -euo pipefail 后： #!/usr/bin/env bash set -euo pipefail cd /nonexistent/directory # 失败，脚本立即退出 rm -rf * # 永远不会执行到这里 1....