71 lines
6.7 KiB
Markdown
71 lines
6.7 KiB
Markdown
---
|
||
title: "Support Infrastructure Maintainer Agent Personality"
|
||
type: source
|
||
tags: []
|
||
date: 2026-04-30
|
||
---
|
||
|
||
## Source File
|
||
- [[Agent/agency-agents/support/support-infrastructure-maintainer.md]]
|
||
|
||
## Summary（用中文描述）
|
||
- 核心主题：The Agency Support 部门的基础设施维护专家 AI Agent 人格定义——专注于系统可靠性、性能优化和成本效率的云原生基础设施专家。
|
||
- 问题域：企业级云基础设施的监控、自动化、安全合规、灾备恢复与成本优化。
|
||
- 方法/机制：Prometheus + Grafana 监控告警体系；Terraform IaC 基础设施即代码；GPG AES-256 加密 + S3 分层存储的自动化备份；Terraform Auto Scaling Group 实现弹性伸缩；多阶段工作流（评估规划 → 监控实施 → 性能优化 → 安全合规验证）。
|
||
- 结论/价值：Infrastructure Maintainer 是 The Agency Support 部门所有 Agent 的运行基础，为 Support Responder 和 Analytics Reporter 提供稳定可靠的底层支撑。
|
||
|
||
## Key Claims（用中文描述）
|
||
- **Prometheus + Grafana 监控告警体系** 确保关键基础设施指标（CPU/内存/磁盘/服务可用性）实时告警，达成 99.9%+ 上线时间目标。
|
||
- **Terraform IaC 基础设施即代码** 实现 AWS 资源（VPC/Subnet/Auto Scaling Group/RDS）的版本化管理，确保跨环境部署一致性。
|
||
- **GPG AES-256 加密 + S3 分层存储** 的自动化备份与灾备恢复方案，通过经过验证的恢复流程保障数据安全。
|
||
- **Terraform Auto Scaling Group** 配合 launch template 实现弹性伸缩，结合 CloudWatch 告警自动触发扩缩容，保障峰值负载下的服务可用性。
|
||
- **安全合规集成**（SOC2/ISO27001）要求在所有基础设施变更中强制嵌入安全加固和合规验证流程，默认启用零信任架构和 MFA。
|
||
- **成本优化** 通过资源正确规模分析和预留实例策略，达成年度效率提升 20%+ 的目标。
|
||
- **MTTR < 4 小时** 的故障恢复能力要求建立完善的监控告警、备份恢复和事件响应流程。
|
||
|
||
## Key Quotes
|
||
> "Keeps the lights on, the servers humming, and the alerts quiet." — Infrastructure Maintainer Agent 核心价值观
|
||
|
||
> "Prometheus Monitoring Configuration" — 展示 CPU/内存/磁盘/服务可用性的多维度监控告警规则，覆盖 warning/critical 两级 severity
|
||
|
||
> "Terraform IaC Configuration" — 展示 VPC/Subnet/Auto Scaling/RDS 的完整基础设施代码，backend 使用 S3 + DynamoDB 状态锁保证并发安全
|
||
|
||
> "Comprehensive Backup and Recovery Script" — 展示 GPG AES-256 加密备份 + S3 Standard_IA 分层存储 + 30 天自动清理的完整灾备方案
|
||
|
||
## Key Concepts
|
||
- [[InfrastructureAsCode]]：通过 Terraform 实现基础设施的声明式代码管理，确保所有云资源（VPC/Subnet/RDS/Auto Scaling Group）可版本化、可审计、可重现。
|
||
- [[PrometheusMonitoring]]：开源监控系统，scrape_interval 15s 配置实现近实时指标采集，配合 alerting 规则实现多级告警（warning/critical）。
|
||
- [[DisasterRecovery]]：GPG AES-256 加密备份到 S3，分层存储（Standard_IA），30 天自动清理，经过验证的恢复流程保障 RTO/RPO 目标达成。
|
||
- [[AutoScaling]]：Terraform aws_autoscaling_group 配合 launch template 和 ELB 健康检查，实现基于负载的弹性伸缩。
|
||
- [[ZeroTrustSecurity]]：零信任架构默认启用，最小权限原则 + MFA 多因素认证，所有系统实施访问控制和审计日志。
|
||
- [[CostOptimization]]：通过资源正确规模分析、预留实例和自动化策略，实现年度效率提升 20%+ 的目标。
|
||
- [[SecurityCompliance]]：SOC2/ISO27001 合规验证框架，所有基础设施变更强制嵌入安全加固和合规检查。
|
||
- [[IncidentResponse]]：结构化事件响应流程，清晰升级路径，配合 Prometheus 告警实现快速故障检测和恢复（MTTR < 4 小时）。
|
||
- [[MultiCloudStrategy]]：多云架构设计，供应商管理和服务优化，避免单一供应商锁定。
|
||
- [[ContainerOrchestration]]：Kubernetes 和微服务架构的容器编排能力，支持服务发现、负载均衡和自动恢复。
|
||
|
||
## Key Entities
|
||
- [[InfrastructureMaintainer]]：AI Agent，The Agency Support 部门的基础设施专家，专注于系统可靠性、性能优化和安全合规。
|
||
- [[Terraform]]：基础设施即代码工具，用于声明式管理 AWS 云资源（VPC/Subnet/RDS/Auto Scaling Group）。
|
||
- [[Prometheus]]：开源监控系统，用于收集和告警基础设施指标。
|
||
- [[Grafana]]：可视化平台，与 Prometheus 集成展示监控仪表盘。
|
||
- [[AmazonRDS]]：AWS 托管关系数据库服务（PostgreSQL），Terraform aws_db_instance 管理的核心数据存储。
|
||
- [[AmazonS3]]：AWS 对象存储服务，用于备份文件存储和 Terraform 状态文件管理。
|
||
- [[AmazonVPC]]：AWS 虚拟私有云，Terraform aws_vpc 定义的网络隔离基础。
|
||
- [[AmazonAutoScalingGroup]]：AWS 自动伸缩组，Terraform aws_autoscaling_group 管理的弹性计算资源。
|
||
- [[AmazonCloudWatch]]：AWS 监控服务，与 Auto Scaling Group 集成触发伸缩策略。
|
||
|
||
## Connections
|
||
- [[support-support-responder]] ← depends_on ← [[support-infrastructure-maintainer]]：工单系统依赖稳定的基础设施运行
|
||
- [[support-analytics-reporter]] ← depends_on ← [[support-infrastructure-maintainer]]：数据分析依赖数据库和存储基础设施
|
||
- [[support-legal-compliance-checker]] ← integrates ← [[support-infrastructure-maintainer]]：合规验证框架共享安全加固和审计日志机制
|
||
- [[compliance-auditor]] ← depends_on ← [[support-infrastructure-maintainer]]：审计需要访问控制和审计日志基础设施
|
||
- [[automation-governance-architect]] ← provides_policies_to ← [[support-infrastructure-maintainer]]：治理框架提供基础设施自动化策略指导
|
||
|
||
## Contradictions
|
||
- 与 [[testing-reality-checker]] 冲突：
|
||
- 冲突点：变更审批严格度——Infrastructure Maintainer 遵循"SOC2/ISO27001 合规验证"框架（合规即放行），Reality Checker 要求压倒性视觉证明才授予生产就绪（默认"NEEDS WORK"）。
|
||
- 当前观点：合规验证作为 CI/CD 流水线 Gate，不阻断常规变更但强制阻断高风险变更，在监管框架内最大化变更效率。
|
||
- 对方观点：Reality Check 默认"NEEDS WORK"，即使合规 Agent 认证通过仍需截图证据截断"幻想型认证"，视觉真实性验证优先于合规框架。
|
||
- 协调方案：合规认证（Legal Compliance Checker + Infrastructure Maintainer）作为监管准入门槛，Reality Check 作为质量门禁——两者在流水线中处于不同阶段（合规 Gate 在部署前，质量 Gate 在部署后截图验证），不互斥但独立决策。
|