Auto-sync: 2026-04-18 17:09
This commit is contained in:
32
wiki/concepts/AWS-Backup.md
Normal file
32
wiki/concepts/AWS-Backup.md
Normal file
@@ -0,0 +1,32 @@
|
||||
---
|
||||
title: "AWS Backup"
|
||||
type: concept
|
||||
tags: [AWS, Backup, DR]
|
||||
sources: []
|
||||
last_updated: 2026-04-18
|
||||
---
|
||||
|
||||
## Summary
|
||||
AWS Backup 是 AWS 托管的集中化数据保护服务,用于跨账户和跨区域自动备份 AWS 资源。
|
||||
|
||||
## Definition
|
||||
AWS Backup 是 AWS 提供的托管备份服务,支持 S3、RDS、EBS、EFS、EC2、FSx、DynamoDB 等 AWS 服务的统一备份。
|
||||
|
||||
## Key Features
|
||||
- 集中管理:跨账户、跨区域备份
|
||||
- 不可变性(Immutability):防止备份被篡改或删除
|
||||
- 时间点恢复(PITR):S3 和 RDS 可在 1 秒内恢复
|
||||
- 备份计划:支持每日、每小时或自定义计划
|
||||
- 法律保留(Legal Holds):隔离备份以满足合规要求
|
||||
- 基于角色的访问控制(IAM)
|
||||
- CloudWatch 集成监控
|
||||
|
||||
## Limitations
|
||||
- 无法排除特定附加卷,必须备份所有卷
|
||||
- 不支持增量快照,仅支持崩溃一致性快照
|
||||
- 热备份已被 Amazon 不推荐用于数据库
|
||||
|
||||
## Connections
|
||||
- [[AWS]] → 提供 [[AWS Backup]]
|
||||
- [[RTO (Recovery Time Objective)]] ← 降低 [[备份和恢复]]
|
||||
- [[AWS Backup]] ← 替代 [[CCIE 门户]]
|
||||
47
wiki/concepts/Docker-容器化.md
Normal file
47
wiki/concepts/Docker-容器化.md
Normal file
@@ -0,0 +1,47 @@
|
||||
---
|
||||
id: Docker-容器化
|
||||
title: "Docker 容器化"
|
||||
type: concept
|
||||
tags:
|
||||
- Docker
|
||||
- Containerization
|
||||
- Cloud-Migration
|
||||
- DevOps
|
||||
last_updated: 2026-04-18
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Containerization
|
||||
- Containerize
|
||||
|
||||
## Summary
|
||||
- **定义**:使用 Docker 容器技术将应用程序及其依赖打包为标准化单元的过程
|
||||
- **目的**:实现应用的可移植性、一致性和隔离性
|
||||
- **云迁移价值**:将遗留应用容器化是云就绪的关键步骤
|
||||
|
||||
## Key Details
|
||||
- **核心优势**:
|
||||
- 跨环境一致性(开发、测试、生产)
|
||||
- 资源隔离和高效利用
|
||||
- 快速部署和弹性伸缩
|
||||
- 简化迁移流程(lift-and-shift)
|
||||
- **适用场景**:
|
||||
- 微服务架构
|
||||
- 云迁移(lift-and-shift)
|
||||
- 持续集成/持续部署(CI/CD)
|
||||
- 开发环境标准化
|
||||
- **限制**:
|
||||
- 容器内数据持久化需要额外机制(Volume)
|
||||
- 有状态应用的容器化复杂度较高
|
||||
- 不适合数据库等有状态服务直接运行
|
||||
|
||||
## Octane Hub 案例
|
||||
- Octane Hub 使用 Docker 容器运行各种 Web 应用(QuickSee、Release Manager、Patch Manager)
|
||||
- 容器化使其能够从本地数据中心无缝迁移到 AWS
|
||||
- 数据库未直接容器化,使用 EBS 而非 EFS 存储
|
||||
|
||||
## Connections
|
||||
- [[Dockerfile]] ← defines ← [[Docker-容器化]]
|
||||
- [[Docker-Image]] ← builds ← [[Docker-容器化]]
|
||||
- [[Octane-Hub]] ← uses ← [[Docker-容器化]]
|
||||
- [[Cloud-Migration]] ← enabled_by ← [[Docker-容器化]]
|
||||
60
wiki/concepts/EFS-vs-EBS.md
Normal file
60
wiki/concepts/EFS-vs-EBS.md
Normal file
@@ -0,0 +1,60 @@
|
||||
---
|
||||
id: EFS-vs-EBS
|
||||
title: "EFS vs EBS"
|
||||
type: concept
|
||||
tags:
|
||||
- AWS
|
||||
- Storage
|
||||
- Cloud-Migration
|
||||
last_updated: 2026-04-18
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- EFS
|
||||
- EBS
|
||||
- Elastic File System
|
||||
- Elastic Block Store
|
||||
|
||||
## Summary
|
||||
- **EFS(Elastic File System)**:AWS 托管的网络文件系统(NFS),支持多实例共享访问
|
||||
- **EBS(Elastic Block Store)**:AWS 托管的块存储,附加到单个 EC2 实例
|
||||
- **云迁移价值**:正确选型存储对性能和成本至关重要
|
||||
|
||||
## Key Details
|
||||
|
||||
### EFS 特点
|
||||
- **协议**:NFSv4
|
||||
- **访问方式**:多可用区网络访问
|
||||
- **性能模式**:通用和最大 IO 两种模式
|
||||
- **计费**:按存储量和吞吐量计费
|
||||
- **适用场景**:
|
||||
- 文件共享
|
||||
- Web 服务内容
|
||||
- 备份存储
|
||||
- 容器共享存储
|
||||
- **限制**:
|
||||
- 延迟较高,不适合数据库
|
||||
- 不支持本地 HDD 性能模式(处理延迟敏感工作负载时性能差)
|
||||
|
||||
### EBS 特点
|
||||
- **协议**:块设备
|
||||
- **类型**:gp3/gp2、io1/io2、st1、sc1
|
||||
- **访问方式**:单实例附加
|
||||
- **性能指标**:IOPS 和吞吐量独立配置
|
||||
- **适用场景**:
|
||||
- 操作系统启动盘
|
||||
- 数据库存储
|
||||
- 应用程序数据
|
||||
- 需要低延迟的 工作负载
|
||||
- **限制**:
|
||||
- 仅限于单个可用区
|
||||
|
||||
## Octane Hub 案例
|
||||
- 最初考虑使用 EFS 存储,后因性能问题放弃
|
||||
- 改用 EBS 用于实时数据库,EFS 用于备份
|
||||
- 验证了 EFS 不适合数据库场景
|
||||
|
||||
## Connections
|
||||
- [[AWS]] ← provides ← [[EFS-vs-EBS]]
|
||||
- [[S3]] ← alternative_to ← [[EFS-vs-EBS]]
|
||||
- [[Database-Migration]] ← requires ← [[EFS-vs-EBS]]
|
||||
42
wiki/concepts/Packer.md
Normal file
42
wiki/concepts/Packer.md
Normal file
@@ -0,0 +1,42 @@
|
||||
---
|
||||
id: Packer
|
||||
title: "Packer"
|
||||
type: concept
|
||||
tags:
|
||||
- DevOps
|
||||
- IaC
|
||||
- AMI
|
||||
- AWS
|
||||
last_updated: 2026-04-18
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- HashiCorp Packer
|
||||
|
||||
## Summary
|
||||
- **定义**:HashiCorp 开发的开源工具,通过模板定义自动构建机器镜像(AMI、VMDK、QCOW2 等)
|
||||
- **用途**:实现基础设施的不可变部署
|
||||
- **云迁移价值**:标准化镜像构建,确保环境一致性
|
||||
|
||||
## Key Details
|
||||
- **核心功能**:
|
||||
- 多平台镜像构建(AWS AMI、VMware、Vagrant、Docker 等)
|
||||
- JSON/HCL 模板定义
|
||||
- 预置和后置配置脚本
|
||||
- 并行构建加速
|
||||
- **工作流程**:
|
||||
1. 定义模板(Builder 配置)
|
||||
2. 运行 provisioner(配置脚本)
|
||||
3. 输出镜像
|
||||
- **与 Terraform 集成**:
|
||||
- Packer 构建 AMI
|
||||
- Terraform 使用 AMI 部署基础设施
|
||||
|
||||
## Octane Hub 案例
|
||||
- Octane Hub 使用 Packer 构建自定义 AMI
|
||||
- 从手动控制台脚本演进到自动化镜像构建
|
||||
|
||||
## Connections
|
||||
- [[Terraform]] ← uses_ami_from ← [[Packer]]
|
||||
- [[Infrastructure-as-Code-IaC]] ← implementd_by ← [[Packer]]
|
||||
- [[AMI]] ← built_by ← [[Packer]]
|
||||
48
wiki/concepts/TerraGrunt.md
Normal file
48
wiki/concepts/TerraGrunt.md
Normal file
@@ -0,0 +1,48 @@
|
||||
---
|
||||
id: TerraGrunt
|
||||
title: "TerraGrunt"
|
||||
type: concept
|
||||
tags:
|
||||
- DevOps
|
||||
- IaC
|
||||
- Terraform
|
||||
- AWS
|
||||
last_updated: 2026-04-18
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Terragrunt
|
||||
|
||||
## Summary
|
||||
- **定义**:Terraform 的包装工具,提供模块化、变量共享和环境隔离
|
||||
- **用途**:管理多环境、多账户的 Terraform 配置
|
||||
- **云迁移价值**:简化 Landing Zone 多账户部署
|
||||
|
||||
## Key Details
|
||||
- **核心功能**:
|
||||
- 远程状态存储配置
|
||||
- 模块化配置复用
|
||||
- 多环境/多账户管理
|
||||
- 自动输入变量传递
|
||||
- **工作目录结构**:
|
||||
```
|
||||
live/
|
||||
├── prod/
|
||||
│ └── terragrunt.hcl
|
||||
├── staging/
|
||||
│ └── terragrunt.hcl
|
||||
└── dev/
|
||||
└── terragrunt.hcl
|
||||
```
|
||||
- **与 Terraform 关系**:
|
||||
- TerraGrunt 调用 Terraform
|
||||
- 纯 Terraform 包装,不替代
|
||||
|
||||
## Octane Hub 案例
|
||||
- Octane Hub 使用 TerraGrunt 部署 AWS 基础设施
|
||||
- 从手动脚本演进到 IaC 流程
|
||||
|
||||
## Connections
|
||||
- [[Terraform]] ← wrapped_by ← [[TerraGrunt]]
|
||||
- [[Infrastructure-as-Code-IaC]] ← implementd_by ← [[TerraGrunt]]
|
||||
- [[Multi-Account-Strategy]] ← managed_by ← [[TerraGrunt]]
|
||||
41
wiki/concepts/VPC-Transit-Gateway.md
Normal file
41
wiki/concepts/VPC-Transit-Gateway.md
Normal file
@@ -0,0 +1,41 @@
|
||||
---
|
||||
id: VPC-Transit-Gateway
|
||||
title: "VPC Transit Gateway"
|
||||
type: concept
|
||||
tags:
|
||||
- AWS
|
||||
- Network
|
||||
- VPC
|
||||
- Cloud-Migration
|
||||
last_updated: 2026-04-18
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Transit Gateway
|
||||
- TGW
|
||||
|
||||
## Summary
|
||||
- **定义**:AWS 中心辐射式网络互联服务,允许跨 VPC 和本地数据中心之间的网络流量路由
|
||||
- **用途**:简化复杂网络的连接和管理
|
||||
- **云迁移价值**:实现多 VPC 统一网络架构
|
||||
|
||||
## Key Details
|
||||
- **核心功能**:
|
||||
- 跨 VPC 互联(数千个 VPC)
|
||||
- AWS 与本地数据中心互联(通过 Direct Connect 或 VPN)
|
||||
- 跨区域互联
|
||||
- 路由表控制
|
||||
- **优势**:
|
||||
- 简化网络 architecture(中心辐射模型)
|
||||
- 减少复杂对等连接管理
|
||||
- 集中审计和日志
|
||||
- **计费**:按小时和数据量计费
|
||||
|
||||
## Octane Hub 案例
|
||||
- Octane Hub 使用 VPC Transit Gateway 实现网络互联
|
||||
- 解决了多 VPC 和本地数据中心连接需求
|
||||
|
||||
## Connections
|
||||
- [[AWS]] ← provides ← [[VPC-Transit-Gateway]]
|
||||
- [[VPC]] ← connected_by ← [[VPC-Transit-Gateway]]
|
||||
- [[AWS-Organizations]] ← manages ← [[VPC-Transit-Gateway]]
|
||||
22
wiki/entities/CTP.md
Normal file
22
wiki/entities/CTP.md
Normal file
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: "CTP (Cloud Transformation Program)"
|
||||
type: entity
|
||||
tags: [Cloud, Transformation, Program]
|
||||
sources: []
|
||||
last_updated: 2026-04-18
|
||||
---
|
||||
|
||||
## Summary
|
||||
CTP (Cloud Transformation Program) 是云转型计划,涉及将工作负载迁移到 AWS 云。
|
||||
|
||||
## Definition
|
||||
CTP (Cloud Transformation Program) 是企业云迁移项目,目标是利用 AWS 等公有云服务重构现有基础设施。
|
||||
|
||||
## Key Activities
|
||||
- 云评估与规划
|
||||
- 工作负载迁移
|
||||
- 备份与灾难恢复策略实施
|
||||
|
||||
## Related Entities
|
||||
- [[AWS]]
|
||||
- [[AWS Backup]]
|
||||
27
wiki/entities/Holger-Rode.md
Normal file
27
wiki/entities/Holger-Rode.md
Normal file
@@ -0,0 +1,27 @@
|
||||
---
|
||||
id: Holger-Rode
|
||||
title: "Holger Rode"
|
||||
type: entity
|
||||
tags:
|
||||
- Person
|
||||
- CTO
|
||||
- Software
|
||||
- AWS
|
||||
last_updated: 2026-04-18
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Holger
|
||||
|
||||
## Summary
|
||||
- **角色**:Octane Hub CTO(软件工厂团队负责人)
|
||||
- **贡献**:分享 Octane Hub 将生产服务迁移到 AWS 的真实经验
|
||||
- **专业领域**:云迁移、Docker 容器化、AWS 基础设施
|
||||
|
||||
## Key Details
|
||||
- 在 CTP Topic 14 中分享了 Octane Hub 云迁移经验
|
||||
- 负责软件工厂团队,管理约 10TB 文件存储和大型 MSSQL 数据库
|
||||
- 主导了从 Bibling 数据中心到 AWS Landing Zone 的迁移项目
|
||||
|
||||
## Connections
|
||||
- [[Octane-Hub]] ← employed_by ← [[Holger-Rode]]
|
||||
33
wiki/entities/Octane-Hub.md
Normal file
33
wiki/entities/Octane-Hub.md
Normal file
@@ -0,0 +1,33 @@
|
||||
---
|
||||
id: Octane-Hub
|
||||
title: "Octane Hub"
|
||||
type: entity
|
||||
tags:
|
||||
- Company
|
||||
- Software
|
||||
- AWS
|
||||
- Cloud-Migration
|
||||
last_updated: 2026-04-18
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- OctaneHub
|
||||
- Octane
|
||||
|
||||
## Summary
|
||||
- **角色**:软件公司
|
||||
- **业务**:软件开发和运维
|
||||
- **云迁移状态**:已完成从本地数据中心到 AWS 的生产服务迁移
|
||||
- **技术栈**:Docker 容器化、Packer + Terraform/TerraGrunt、AWS Landing Zone
|
||||
|
||||
## Key Details
|
||||
- **CTO**:Holger Rode(软件工厂团队负责人)
|
||||
- **主要应用**:QuickSee、Release Manager、Patch Manager、安全程序板
|
||||
- **基础设施**:约 10TB 文件存储和大型 MSSQL 服务器数据库
|
||||
- **迁移动因**:Bibling 数据中心即将关闭
|
||||
- **迁移目标**:无缝过渡,紧密镜像现有设置
|
||||
|
||||
## Connections
|
||||
- [[AWS]] ← hosted_on ← [[Octane-Hub]]
|
||||
- [[Holger-Rode]] ← works_at ← [[Octane-Hub]]
|
||||
- [[Docker-容器化]] ← used_by ← [[Octane-Hub]]
|
||||
@@ -39,6 +39,8 @@
|
||||
|
||||
- [Never write another prompt](sources/never-write-another-prompt.md) — 通过工具简化 AI 提示词创建流程
|
||||
|
||||
- [CTP Topic 44 AWS Backup in Micro Focus](sources/ctp-topic-44-aws-backup-in-micro-focus.md) — AWS Backup 服务及其在 Micro Focus 云迁移项目中的应用
|
||||
|
||||
- [养虾日记1:我用 OpenClaw 管了 28 万张照片:一次真实的多设备照片整理实战](sources/养虾日记1-我用-OpenClaw-管了-28-万张照片-一次真实的多设备照片整理实战.md) — 利用 AI Agent 自动化整理 28 万张照片(MD5 去重 + 批次任务 + Cron 定时执行)
|
||||
|
||||
- [教學 ChatGPT 先做知識整理,再讓 Canva、 Gamma AI 輸出簡報](sources/jiao-xue-chatgpt-xian-zuo-zhi-shi-zheng-li-zai-rang-canva-gamma-ai-shu-chu-jian-bao.md) — AI 简报制作四阶段工作流(ChatGPT 资料研究 + Canva/Gamma 设计)
|
||||
@@ -248,7 +250,10 @@
|
||||
|
||||
- [Blogwatcher Daily 技能收藏](sources/blogwatcher-daily-shou-cang.md) — RSS 订阅监控与每日摘要生成自动化
|
||||
|
||||
- [CTP Topic 14 Octane Hub on AWS Real life experience](sources/ctp-topic-14-octane-hub-on-aws-real-life-experience.md) — Octane Hub 将生产服务迁移到 AWS 的真实经验分享
|
||||
|
||||
## Entities
|
||||
- [Holger Rode](entities/Holger-Rode.md) — Octane Hub CTO 软件工厂团队负责人
|
||||
- [Mem0](entities/Mem0.md) — Camp 1 记忆后端领导者,53.1k stars
|
||||
- [MemPalace](entities/MemPalace.md) — 本地优先逐字存储,46.2k stars
|
||||
- [Supermemory](entities/Supermemory.md) — 时间感知记忆,21.8k stars
|
||||
|
||||
26
wiki/log.md
26
wiki/log.md
@@ -1,3 +1,12 @@
|
||||
## [2026-04-18] ingest | CTP Topic 14 Octane Hub on AWS Real life experience
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: Octane Hub 将生产服务从本地数据中心迁移到 AWS 的真实经验分享,涵盖 Docker 容器化、Packer + Terraform 部署、VPC Transit Gateway 网络、EFS vs EBS 存储选型
|
||||
- Concepts created: Docker-容器化, Packer, TerraGrunt, VPC-Transit-Gateway, EFS-vs-EBS
|
||||
- Entities created: Octane-Hub, Holger-Rode
|
||||
- Source page: wiki/sources/ctp-topic-14-octane-hub-on-aws-real-life-experience.md
|
||||
- Notes: 云迁移动因是 Bibling 数据中心即将关闭,目标是无缝过渡,初始考虑 EFS 后因性能问题改用 EBS
|
||||
|
||||
## [2026-04-18] ingest | Blogwatcher Daily 技能收藏
|
||||
- Source file: raw/Skills/blogwatcher-daily收藏.md
|
||||
- Status: ✅ 成功摄入
|
||||
@@ -1282,15 +1291,15 @@
|
||||
- Source page: wiki/sources/The-Myths-and-Misconceptions-About-Cloud-Computing-LinkedIn.md
|
||||
- Notes: 与 Cloud Adoption、Cloud Native、Hybrid Cloud、Multi-Cloud 存在概念关联
|
||||
|
||||
## [2026-04-16] ingest | DevOps Maturity Model From Traditional IT to Advanced DevOps
|
||||
## [2026-04-18] ingest | DevOps Maturity Model From Traditional IT to Advanced DevOps
|
||||
|
||||
- Source file: raw/Cloud & DevOps/DevOps Maturity Model From Traditional IT to Advanced DevOps.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Status: ✅ 成功复摄
|
||||
- Summary: DevOps 成熟度五级框架(初始/应急→局部DevOps→自动化与定义→高度优化→完全成熟),涵盖文化与战略、自动化、结构与流程、协作与共享、技术五大评估领域,以及安全集成方法和常见障碍分析
|
||||
- Entities created: (无新实体)
|
||||
- Concepts created/updated: DevOps 成熟度模型(新建)
|
||||
- Concepts created/updated: DevOps 成熟度模型(更新)
|
||||
- Source page: wiki/sources/DevOps-Maturity-Model-From-Traditional-IT-to-Advanced-DevOps.md
|
||||
- Notes: 与 DevOps、CI/CD 流水线、DevSecOps、IaC、敏捷实践存在概念关联
|
||||
- Notes: 复摄更新 source page 内容
|
||||
|
||||
## [2026-04-16] ingest | Ubuntu服务器通过rsync实现日常增量备份
|
||||
- Source file: raw/Home Office/Ubuntu服务器通过rsync实现日常增量备份.md
|
||||
@@ -1664,6 +1673,15 @@
|
||||
- Source page: wiki/sources/AI-Memory-Tools-Two-Camps.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-18] ingest | CTP Topic 44 AWS Backup in Micro Focus
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-44-aws-backup-in-micro-focus.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: AWS Backup 服务及其在 Micro Focus 云迁移项目中的应用,涵盖 DR 策略、RTO/RPO、当前备份流程差距
|
||||
- Concepts created: AWS Backup, 备份和恢复, RTO, RPO, 不可变性, 法律保留
|
||||
- Entities created: CTP, AWS
|
||||
- Source page: wiki/sources/ctp-topic-44-aws-backup-in-micro-focus.md
|
||||
- Notes: 与现有灾难恢复、RTO、RPO 概念关联;AWS Backup 作为新概念添加
|
||||
|
||||
## [2026-04-18] ingest | Install WSL
|
||||
- Source file: raw/Home Office/Install WSL.md
|
||||
- Status: ✅ 成功摄入
|
||||
|
||||
@@ -1,41 +1,68 @@
|
||||
---
|
||||
title: "DevOps Maturity Model From Traditional IT to Advanced DevOps"
|
||||
type: source
|
||||
tags: [DevOps, Maturity Model, Cloud & DevOps]
|
||||
date: 2024-08-14
|
||||
source_file: raw/Cloud & DevOps/DevOps Maturity Model From Traditional IT to Advanced DevOps.md
|
||||
tags: []
|
||||
date: 2025-03-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/DevOps Maturity Model From Traditional IT to Advanced DevOps.md]]
|
||||
|
||||
## Summary
|
||||
本文介绍了 DevOps 成熟度模型,一个用于评估组织 DevOps 实践水平的分级框架。该模型涵盖五个阶段:从初始/应急阶段(传统瀑布式开发)到完全成熟阶段(持续部署)。模型从文化与战略、自动化、结构与流程、协作与共享、技术五个关键领域进行评估,并提供具体的业务收益、安全集成方法和常见障碍分析。
|
||||
- 核心主题:DevOps 成熟度五级框架,从传统 IT 过渡到完全成熟的 DevOps 实践
|
||||
- 问题域:组织 DevOps 实践水平评估、持续改进路径规划
|
||||
- 方法/机制:五大评估维度 × 五级成熟度阶段,系统化评估组织 DevOps 能力
|
||||
- 结论/价值:结构化框架帮助组织识别当前状态、规划改进路径、实现持续交付卓越
|
||||
|
||||
## Key Claims
|
||||
- DevOps 成熟度模型通过五个阶段帮助组织评估当前实践水平并制定改进路线图
|
||||
- 五个成熟度阶段分别为:初始/应急阶段、局部 DevOps、自动化与定义阶段、高度优化阶段、完全成熟阶段
|
||||
- 成熟度评估的四个关键领域包括:文化与战略、自动化、结构与流程、协作与共享、技术
|
||||
- 高质量 DevOps 成熟度模型应包含:评估标准、成熟度等级、DevOps 实践、相关指标、文化指南、工具与技术、角色与职责
|
||||
- 采用 DevOps 成熟度模型可带来更快的调整能力、更好的扩展性、增强的运营绩效、更快的交付时间、改进的质量
|
||||
- DevOps 成熟度模型是评估组织 DevOps 实践的结构化框架,帮助评估当前实践、识别改进领域、规划升级路径
|
||||
- 五级成熟度:初始/应急 → 局部 DevOps → 自动化与定义 → 高度优化 → 完全成熟
|
||||
- 四大评估维度:文化与战略、自动化、结构与流程、协作与共享、技术
|
||||
- DevSecOps 核心:将开发、运营、安全融合为统一流程
|
||||
- 关键指标:MTTR、MTTD、MTTA、部署频率、变更失败率、回滚率
|
||||
|
||||
## Key Quotes
|
||||
> "The DevOps maturity model is a structured framework that guides organizations through adopting and implementing DevOps principles." — DevOps 成熟度模型定义
|
||||
> "The core of DevOps security is merging development, operations, and security into a unified process." — DevSecOps 核心理念
|
||||
|
||||
> "DevOps practices help organizations swiftly adjust to evolving market trends and customer needs." — 业务价值体现
|
||||
|
||||
## Key Concepts
|
||||
- [[DevOps 成熟度模型]]:评估组织 DevOps 实践水平的五级框架
|
||||
- [[DevOps]]:结合开发与运营实现持续软件交付的方法论
|
||||
- [[CI/CD 流水线]]:自动化测试、集成和部署的持续交付管道
|
||||
- [[DevSecOps]]:在 CI/CD 流水线中深度集成安全工具的文化理念
|
||||
- [[Infrastructure as Code (IaC)]]:通过代码实现一致性、版本控制的基础设施管理
|
||||
- [[敏捷实践]]:Scrum、Kanban 等迭代开发方法论
|
||||
- [[DevOps 文化]]:打破开发与运维壁垒,优先协作、持续学习和客户导向的文化理念
|
||||
- [[MTTR]]:平均恢复时间,衡量故障恢复效率
|
||||
- [[IaC]]:基础设施即代码,自动化基础设施管理
|
||||
|
||||
## Key Entities
|
||||
(本文档未涉及需要创建页面的人、公司或产品实体)
|
||||
|
||||
## Connections
|
||||
- [[DevOps 成熟度模型]] ← extends ← [[DevOps]]
|
||||
- [[DevOps 成熟度模型]] ← includes ← [[CI/CD 流水线]]
|
||||
- [[DevOps 成熟度模型]] ← includes ← [[DevSecOps]]
|
||||
- [[DevOps 成熟度模型]] ← includes ← [[Infrastructure as Code (IaC)]]
|
||||
- [[DevOps 成熟度模型]] ← includes ← [[敏捷实践]]
|
||||
- [[DevSecOps]] ← core_principle ← DevOps 与安全融合
|
||||
- [[CI/CD 流水线]] ← enables ← 持续交付
|
||||
- [[Infrastructure as Code (IaC)]] ← supports ← 基础设施自动化
|
||||
|
||||
## Contradictions
|
||||
(暂无)
|
||||
|
||||
## 五级成熟度对比
|
||||
|
||||
| 阶段 | 组织 | 交付 | 自动化 | 测试 | 安全 | 监控 |
|
||||
|------|------|------|--------|------|------|------|
|
||||
| Phase1 初始/应急 | 团队孤立工作 | 瀑布式、里程碑驱动 | 手动管理服务器 | 手动测试、瓶颈 | 发布前几周才介入 | 用户报告故障 |
|
||||
| Phase2 局部 DevOps | 小团队试点合作 | 引入敏捷实践 | 部分自动化 | 单元/集成/E2E 测试 | 独立安全团队 | 关键告警 |
|
||||
| Phase3 自动化与定义 | 标准流程定义 | 全面敏捷集成 | 大部分基础设施自动化 | 安全扫描集成到开发流程 | 安全参与设计讨论 | 持续监控 |
|
||||
| Phase4 高度优化 | 跨职能协作 | 频繁部署 | 不可变基础设施 | 性能/负载测试 | 依赖管理、持续监控 | 应用健康追踪 |
|
||||
| Phase5 完全成熟 | 自治全栈团队 | 每日多部署 | 零人工干预 | 实时数据决策 | 安全门禁 | 最高可用性 |
|
||||
|
||||
## 常见障碍
|
||||
- 开发与运维沟通不畅
|
||||
- 缺乏明确目标战略
|
||||
- 抵制变革
|
||||
- 投资不足
|
||||
- 治理薄弱
|
||||
- 流程僵化
|
||||
- 忽略终端用户
|
||||
- 与业务流程集成不足
|
||||
@@ -0,0 +1,74 @@
|
||||
---
|
||||
id: ctp-topic-14-octane-hub-on-aws-real-life-experience
|
||||
title: "CTP Topic 14 Octane Hub on AWS: Real-Life Experiences"
|
||||
type: source
|
||||
tags:
|
||||
- AWS
|
||||
- Octane-Hub
|
||||
- Migration
|
||||
- CTP
|
||||
- Cloud-Migration
|
||||
- Landing-Zone
|
||||
sources:
|
||||
- NAS /volume2/work/Public Cloud Learning Sessions/CTP _ Topic 14_ Octane Hub on AWS_ Real life experience moving production services into the new land.mp4
|
||||
last_updated: 2026-04-18
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i.md]]
|
||||
|
||||
## Summary
|
||||
- **核心主题**:Octane Hub 将生产服务从本地数据中心迁移到 AWS 的真实经验分享
|
||||
- **问题域**:云迁移规划、技术选型、网络配置、存储方案、IaC 实施
|
||||
- **方法/机制**:
|
||||
- Docker 容器化部署模式
|
||||
- Packer + Terraform/TerraGrunt 基础设施即代码
|
||||
- VPC Transit Gateway 网络互联
|
||||
- 标签系统资源管理
|
||||
- EBS + EFS 分层存储策略
|
||||
- **结论/价值**:通过紧密镜像现有设置实现无缝过渡,验证了 Landing Zone 架构的可行性
|
||||
|
||||
## Key Claims
|
||||
- Octane Hub 团队使用 Docker 容器运行各种 Web 应用,包括 QuickSee、Release Manager、Patch Manager 等,处理约 10TB 文件存储和大型 MSSQL 数据库
|
||||
- 云迁移的动因是 Bibling 数据中心即将关闭,目标是实现无缝过渡,紧密镜像现有设置以避免在 Go Live 期间进行重大技术变更
|
||||
- 初始考虑 EFS 用于存储,但因性能问题(数据库无法直接在 EFS 上运行)不适用,改用 EBS 用于实时数据库,EFS 用于备份
|
||||
- 部署方式从控制台脚本演变为使用 Packer 构建 AMI,使用 Terraform/TerraGrunt 部署
|
||||
- 网络问题需要多次 PCS 请求,与网络团队协作解决,使用 VPC Transit Gateway 并实施标签系统管理访问
|
||||
- DNS 设置使用 Cname 指向 AWS software infra.net 域,通过 Route 53 管理
|
||||
|
||||
## Key Quotes
|
||||
> "云转型计划提供了帮助,团队在 5 月左右获得了概念验证 Landing Zone 账户的访问权限,随后在 6 月获得了生产账户"
|
||||
> "团队目标是实现无缝过渡,紧密镜像现有设置以避免在 Go Live 期间进行重大技术变更"
|
||||
> "最初考虑 EFS 用于存储,但由于性能问题(数据库无法直接在 EFS 上运行)不适用,改用 EBS 用于实时数据库"
|
||||
|
||||
## Key Concepts
|
||||
- [[Docker-容器化]]:Octane Hub 的主要部署模式,容器化遗留应用实现云就绪
|
||||
- [[Packer]]:用于构建自定义 AMI 的工具
|
||||
- [[Terraform-TerraGrunt]]:基础设施即代码的部署流程
|
||||
- [[VPC-Transit-Gateway]]:AWS 网络互联解决方案
|
||||
- [[标签系统]]:基于角色和环境管理资源访问
|
||||
- [[EFS-vs-EBS]]:文件存储与块存储的性能差异,EFS 不适合数据库场景
|
||||
- [[Multi-Account-Strategy]]:AWS 多账号架构策略
|
||||
|
||||
## Key Entities
|
||||
- [[Octane-Hub]]:一家软件公司,演讲者 Holger Rode 为其 CTO 软件工厂团队负责人
|
||||
- [[AWS]]:Amazon Web Services,AWS 云平台
|
||||
- [[Holger-Rode]]:Octane Hub CTO 软件工厂团队负责人,分享迁移经验
|
||||
|
||||
## Connections
|
||||
- [[Octane-Hub]] ← uses ← [[Docker-容器化]]
|
||||
- [[Docker-容器化]] ← managed_by ← [[Terraform-TerraGrunt]]
|
||||
- [[AWS-Landing-Zone]] ← enables ← [[Multi-Account-Strategy]]
|
||||
- [[ctp-topic-14-octane-hub-on-aws-real-life-experience]] ← related_to ← [[ctp-topic-7-saas-landing-zone-design]]
|
||||
|
||||
## Contradictions
|
||||
- 与 Landing Zone 最佳实践可能存在差异:
|
||||
- 冲突点:EFS 原被考虑用于存储,后因性能问题放弃
|
||||
- 当前观点:数据库应使用 EBS 块存储而非 EFS 文件存储
|
||||
- 对方观点:为了简化管理,优先选择托管存储服务
|
||||
|
||||
## Action Items
|
||||
- [ ] 评估现有工作负载是否适合容器化
|
||||
- [ ] 规划数据库从 MSSQL 到 Postgres 的迁移路径
|
||||
- [ ] 检查 EBS/EFS 存储选型是否合理
|
||||
- [ ] 制定 DR 和高可用性改进计划
|
||||
52
wiki/sources/ctp-topic-44-aws-backup-in-micro-focus.md
Normal file
52
wiki/sources/ctp-topic-44-aws-backup-in-micro-focus.md
Normal file
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: "CTP Topic 44 AWS Backup in Micro Focus"
|
||||
type: source
|
||||
tags:
|
||||
- AWS
|
||||
- Backup
|
||||
- DR
|
||||
- CTP
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-44-aws-backup-in-micro-focus.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:AWS Backup 服务及其在 Micro Focus 云迁移项目中的应用
|
||||
- 问题域:云数据保护、灾难恢复策略、AWS 托管服务
|
||||
- 方法/机制:AWS Backup 集中化备份、跨账户跨区域复制、不可变性保护、法律保留
|
||||
- 结论/价值:AWS Backup 提供统一的备份管理,支持 S3、RDS 等服务的托管备份,弥补当前流程的分散式管理缺陷
|
||||
|
||||
## Key Claims
|
||||
- AWS Backup 是托管服务,用于集中化和自动化数据保护
|
||||
- AWS Backup 支持跨账户和跨区域备份,提供不可变性防止勒索软件威胁
|
||||
- S3 和 RDS 时间点恢复可在 1 秒以内完成
|
||||
- 当前备份流程是分散的,涉及多个团队,增加错误风险
|
||||
|
||||
## Key Quotes
|
||||
> "AWS Backup 是一个托管服务,用于在 AWS 云中集中化和自动化数据保护。"
|
||||
|
||||
> "灾难恢复策略根据 RTO 和 RPO 而有所不同,从备份和恢复到 Active-Active 有四种主要策略。"
|
||||
|
||||
## Key Concepts
|
||||
- [[AWS Backup]]:AWS 托管服务,集中化数据保护
|
||||
- [[RTO]](Recovery Time Objective):恢复时间目标
|
||||
- [[RPO]](Recovery Point Objective):恢复点目标
|
||||
- [[不可变性]](Immutability):备份防篡改保护机制
|
||||
- [[法律保留]](Legal Holds):合规隔离备份
|
||||
- [[备份和恢复]](Backup and Restore):最基本的 DR 策略
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]:Amazon Web Services,云服务商
|
||||
- [[CTP]]:Cloud Transformation Program,云迁移计划
|
||||
- [[CCIE 门户]]:当前管理快照的内部平台
|
||||
|
||||
## Connections
|
||||
- [[AWS Backup]] ← depends_on ← [[S3]]
|
||||
- [[AWS Backup]] ← depends_on ← [[RDS]]
|
||||
- [[AWS Backup]] ← extends ← [[EC2 Backup]]
|
||||
- [[RTO]] ← depends_on ← [[灾难恢复策略]]
|
||||
- [[备份和恢复]] ← implements ← [[RTO]]: 8+ 小时
|
||||
|
||||
## Contradictions
|
||||
Reference in New Issue
Block a user