Posts

不仅是定时：使用 systemd 构建企业级自动化运维体系

不仅是定时：使用 systemd 构建企业级自动化运维体系

在 Linux 环境下，如何让服务“永远在线”？对于企业级 Agent 系统而言，答案通常不是编写一个死循环的 Shell 脚本，而是将任务交给系统最底层的管家——systemd。

1. 为什么弃用用户态 Daemon？

在之前的运维实践中，我们尝试过使用自定义的 blog_daemon 进行自动化调度，但结果证明它不可靠：

  • 状态丢失：Daemon 若因崩溃、重启或环境抖动导致 PID 文件丢失，整个调度机制就会“瘫痪”。
  • 权限与依赖限制：Daemon 难以管理任务间的依赖顺序，也无法精准进行资源限制（如 CPU/内存配额）。

2. systemd 的核心优势

将任务转交给 systemd（通过 .service 与 .timer），意味着将任务的生存责任交给了内核：

  • 内核级保障：systemd 与内核紧密协作，即使服务崩溃，它也能通过 Restart=always 实现秒级恢复。
  • 资源限制 (Cgroups)：通过配置 MemoryMax 或 CPUQuota，可以防止 Agent 因死循环或内存泄露耗尽主机所有资源。
  • 依赖管理：通过 After=network.target，确保服务在网络就绪后再启动，解决了 Daemon 启动时常见的“网络不可用”问题。

3. 局限性与避坑指南

尽管 systemd 强大，但它并非完美，在生产环境中需注意：

systemd 的局限性：

  1. 侵入性强：配置需要 Root 权限。在部分云原生环境（如只读文件系统）中，我们无法触及系统级目录，此时 systemd 会失效。
  2. 配置复杂：相比 crontab，systemd 的配置逻辑冗长。如果项目环境多变，配置迁移成本高。
  3. 单点风险：systemd 本身是系统守护进程，一旦它出现异常，整个系统的服务管理将瞬间停滞（尽管这种情况极少见）。

避坑指南：

  • 配置验证：在上线前，务必使用 systemd-analyze verify 检查语法，防止服务启动失败导致雪崩。
  • 日志归一化：systemd 托管的服务日志默认由 journald 管理，需配置好日志轮转，防止 /var/log 空间被写满。
  • 非 Root 环境替代方案：如果环境限制无法使用 systemd（如无 Root 权限的容器内），请考虑 supervisord 或基于 容器调度器 (K8s/Nomad) 的健康检查机制，而非编写简易 Daemon。

4. 企业级最佳实践：Systemd 配置模板

# /etc/systemd/system/agent-task.timer
[Unit]
Description=Daily Agent Task Timer

[Timer]
OnCalendar=*-*-* 12:00:00
Persistent=true

[Install]
WantedBy=timers.target

总结

对于企业级 Agent 系统，追求“高可靠性”的关键不在于代码写得多么复杂，而在于如何高效地利用操作系统的管理能力。systemd 是 Linux 运维的定海神针，但我们也需清楚它的边界——当系统权限受到限制时，拥抱云原生架构（如 GitHub Actions/K8s）将是更优雅的选择。

read more
Posts

从自动化到智能化：Playwright 全栈进阶指南

从自动化到智能化：Playwright 全栈进阶指南

Playwright 已经超越了传统的自动化测试框架，成为了 Web 浏览器协议栈的最强控制端。无论是常规的端到端测试，还是赋予 AI Agent 真实世界的“双手”，Playwright 都是必不可少的工具。

以下是 Playwright 从零到 AI 代理的进阶路线图。

目录

  1. 环境搭建与架构初探
  2. 定位器与交互艺术
  3. 异步测试与高级等待机制
  4. AI 代理与浏览器控制 (MCP)
  5. CI/CD 与多环境适配

1. 环境搭建与架构初探

Playwright 基于 WebKit、Chromium 和 Firefox 的原生 CDP（Chrome DevTools Protocol），相比 Selenium 具有更高的稳定性和并发性能。

  • 初始化：npm init playwright@latest 或 Python 下 pip install playwright
  • 关键配置：理解配置文件中的 projects（多浏览器并行）与 use（全局断言/超时设置）。

2. 定位器与交互艺术

拒绝 XPath，全面拥抱 Web-First Locators。

  • 推荐使用：getByRole, getByLabel, getByPlaceholder, getByTestId。
  • 交互逻辑：click, fill, press 均具备自动等待功能，有效减少了手动 sleep 的“代码异味”。

3. 异步测试与高级等待机制

  • 事件驱动：利用 page.waitForEvent 和 page.waitForResponse 精准监控 Web 交互流。
  • 状态断言：使用 expect 工具链进行原子化断言（如 toBeVisible）。
  • 网络拦截：使用 page.route 进行 API Mock 或异常注入，模拟复杂的后端行为。

4. AI 代理与浏览器控制 (MCP)

这是 Playwright 进阶的巅峰：将浏览器控制权交给 LLM。

read more
Posts

我的博客自动化发布SOP

这篇 SOP 记录当前博客的真实发布流程。早期我曾经用过 public 子模块和部署仓库分离的方案，但当前仓库已经改成更简单的方式：Markdown 源码、Hugo 模板和 GitHub Actions workflow 都在 caozuohua.github.io 仓库内，push 到 main 后由 Actions 构建并部署 GitHub Pages。

当前仓库结构

caozuohua.github.io/
├── content/posts/        # Markdown 文章源码
├── layouts/              # 站点模板覆盖
├── themes/ananke/        # Hugo 主题
├── hugo.toml             # 站点配置
└── .github/workflows/    # GitHub Pages 部署流程

当前生产地址是 https://caozuohua.github.io/。本地构建产物会生成到 public/，但它只是验证结果，不再作为单独部署仓库提交。

第一阶段：内容创作

新文章统一放在 content/posts/ 下。推荐使用 page bundle 结构：

hugo new content/posts/YYYY-MM-DD-kebab-case-slug/index.md

Front matter 至少包含：

---
title: "文章标题"
date: 2026-06-30
publishDate: 2026-06-30
description: "一句话 SEO 摘要"
tags: ["标签1", "标签2"]
categories: ["分类"]
draft: false
---

写作完成后先做三项检查：

read more