自动化脚本

概述 日志是系统运行时留下的最真实记录。当线上出问题时，日志是第一现场；当需要洞察系统行为时，日志是最丰富的数据源。但日志分析不是 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....