Auto-sync: 2026-04-19 06:32
This commit is contained in:
122
ishenwei/blogwatcher/2026-04-19.md
Normal file
122
ishenwei/blogwatcher/2026-04-19.md
Normal file
@@ -0,0 +1,122 @@
|
||||
|
||||
## 📦 新增 33 篇 (06:05:37)
|
||||
|
||||
### 【Tech With Tim - YouTube】
|
||||
|
||||
- [AI Testing Just Arrived... | KaneAI Full Tutorial](https://www.youtube.com/watch?v=dlgIqefjVe8)
|
||||
Get started with KaneAI using their FREE trial: https://www.testmuai.com/kane-ai/?utm_source=youtube&utm_medium=techwithtim_ifm&utm_campaign=kane_ai&u...
|
||||
|
||||
### 【TEDx Talks - YouTube】
|
||||
|
||||
- [How to face medical diagnoses with hope | Mark Pochapin, MD | TEDxNYU Langone Health](https://www.youtube.com/watch?v=ZQQvgO5fKAU)
|
||||
Through powerful personal and patient stories, Dr. Mark Pochapin reveals how hope is more than wishful thinking—it’s the most vital prescription for h...
|
||||
|
||||
### 【Greyson Zhang - YouTube】
|
||||
|
||||
- [【2026最新】這7個YouTube設定,正在偷偷影響你的流量(最後一個一定要關)](https://www.youtube.com/watch?v=tFUxi3RAOAk)
|
||||
加入最好的創作者成長搞錢社群 👉 https://www.greysonzhang.com/membership免費公開課|2026 YouTube 成長藍圖 👉 https://www.greysonzhang.com/2026-yt一對一咨詢 👉 https://calendly.com/gre...
|
||||
|
||||
### 【李哈利Harry - YouTube】
|
||||
|
||||
- [Claude Opus 4.7 完整上手指南:从0到进阶的最强用法](https://www.youtube.com/watch?v=4OO3CMWN8Hs)
|
||||
🌟 加入AI大師社群並運用AI創業賺錢:https://www.skool.com/aiagent/about?ref=f2b566934c5c4639aaa47ab1fe39310e📌 加入我的免費 Skool 社群,獲取模板:https://www.skool.com/aiagent8/abou...
|
||||
|
||||
### 【零度解说 - YouTube】
|
||||
|
||||
- [Google 把 AI 装进Windows了!效率直接翻倍,用过真的回不去!最新下载安装实测 | 零度解说](https://www.youtube.com/watch?v=77dNa9uscTM)
|
||||
【更多资源】▶https://bittly.cc/lingdu【零度博客】▶https://www.freedidi.com【加入会员】▶https://www.youtube.com/channel/UCvijahEyGtvMpmMHBu4FS2w/join【高级会员】▶https://bittl...
|
||||
|
||||
### 【Reuters - YouTube】
|
||||
|
||||
- ['An absolute sea of tweed' as cyclists pedal through London](https://www.youtube.com/watch?v=bi_4W85Do4M)
|
||||
Hundreds of cyclists dressed in vintage British attire are taking part in London's annual Tweed Run, a rolling fashion parade past landmarks like the ...
|
||||
|
||||
- [GRAPHIC WARNING: Police kill shooter in Kyiv, officials say several dead](https://www.youtube.com/watch?v=2ov0ZwQmmzY)
|
||||
THIS VIDEO CONTAINS SENSITIVE FOOTAGE THAT MAY DISTURB SOME VIEWERSUkrainian police killed a man who opened fire in Kyiv and took hostages in a superm...
|
||||
|
||||
- [Trump signs order to accelerate access to psychedelic drug treatments](https://www.youtube.com/watch?v=M3bSykjrshM)
|
||||
President Trump signed an executive order directing the FDA to expedite review of psychedelic drugs like ibogaine, which advocates say could treat PTS...
|
||||
|
||||
- [Iran tightens Hormuz control, Trump warns against 'blackmail'](https://www.youtube.com/watch?v=3CvMFIs6S5U)
|
||||
Iran said it was tightening control over the Strait of Hormuz, warning mariners the route was again closed, as Trump cautioned Tehran against blackmai...
|
||||
|
||||
- [‘Not in my interest’ to debate Trump: Pope downplays feud](https://www.youtube.com/watch?v=o0QN0RFGiL4)
|
||||
Pope Leo sought to downplay his feud with President Trump, saying reporting about comments he made during his Africa tour ‘has not been accurate in al...
|
||||
|
||||
- [Hormuz closed again - Iran's warning as gunfire reported | Reuters World News](https://www.youtube.com/watch?v=SnVtIt-_VdE)
|
||||
Vessels report being hit by gunfire attempting to cross the Strait of Hormuz, as Iran reimposed strict military controls on the vital waterway. Tehran...
|
||||
|
||||
- [Car strikes pedestrians in deadly Melbourne crash](https://www.youtube.com/watch?v=AOihsh1GMIQ)
|
||||
A police investigation is underway after a car struck and killed at least one pedestrian. The incident occurred at the venue of the Supanova Comic Con...
|
||||
|
||||
- [Mexican search groups find over 1,000 bone pieces](https://www.youtube.com/watch?v=dF7pAWgC4Sc)
|
||||
Search groups announced the discovery of over 1,000 bone fragments in Mexico City that they said authorities mishandled, as families of the missing aw...
|
||||
|
||||
- [Landslide triggers evacuations in northern Peru](https://www.youtube.com/watch?v=NLjbeiRVMZg)
|
||||
A landslide in northern Peru forced more than 170 people to evacuate the area after their homes and crops were put at risk by ground movement.#peru #l...
|
||||
|
||||
- [Australia, Japan start $7 billion warship deal](https://www.youtube.com/watch?v=J3j_Xw4mtzg)
|
||||
Australia and Japan signed contracts launching a $7 billion deal to supply Australia with warships, Tokyo's most consequential military sale since end...
|
||||
|
||||
### 【理想生活实验室】
|
||||
|
||||
- [WGSN 和 Coloro 公布 2028“年度色”,两家机构预测大地色即将流行](http://www.toodaylab.com/84002)
|
||||
还没到年底大家进行总结或者给来年做预测的时候,甚至今年新一年才刚开始,消费趋势预测机构 WGSN 和色彩研究机构 Coloro 就已经在公布新的“年度色”了,并且也是一如既往的提前两年带来,两家机构在 4 月 9 日发布了 2028 年流行色:大地色(Radiant Earth)。WGSN 和 Co...
|
||||
|
||||
- [在《走出洞穴》带来的轻松阅读里,了解 100 个重要的经济学发现 #每周一书](http://www.toodaylab.com/83998)
|
||||
关于经济学的书我们也推荐过不少了,而同时,了解一些经济学知识也正是这几年的一个流行,这的确能帮助我们有更多一个维度去理解一些事情,并且往往会得到与过去直觉上、感觉上所不同的结论。今年 2 月机械工业出版社带来了新书《走出洞穴》,这是一套书,有上下两册,它来自经济学家向松祚(关于他的身份还有中国人民大...
|
||||
|
||||
### 【Engadget is a web magazine with obsessive daily coverage of everything new in gadgets and consumer electronics】
|
||||
|
||||
- [SNK's Neo Geo console remake works with original cartridges and HDMI](https://www.engadget.com/gaming/snks-neo-geo-console-remake-works-with-original-cartridges-and-hdmi-194509442.html?src=rss)
|
||||
Not everyone had the money for the original Neo Geo Advanced Entertainment System when it released in the '90s, but there's still a chance to experien...
|
||||
|
||||
- [Judge sides with creators of banned ICE trackers who allege DHS and DOJ violated their First Amendment rights](https://www.engadget.com/apps/judge-sides-with-creators-of-banned-ice-trackers-who-allege-dhs-and-doj-violated-their-first-amendment-rights-191701801.html?src=rss)
|
||||
A judge has granted the makers of the "ICE Sightings - Chicagoland" Facebook group and the Eyes Up app a preliminary injunction to stop the Trump admi...
|
||||
|
||||
- [Apple avoids a second import ban for its redesigned smartwatches in latest court ruling](https://www.engadget.com/wearables/apple-avoids-a-second-import-ban-for-its-redesigned-smartwatches-in-latest-court-ruling-175600668.html?src=rss)
|
||||
Apple has secured a major victory for its redesigned smartwatches as per the latest decision from the US International Trade Commission. The federal a...
|
||||
|
||||
- [DOJ refuses to help French authorities in criminal probe of X](https://www.engadget.com/social-media/doj-refuses-to-help-french-authorities-in-criminal-probe-of-x-162654518.html?src=rss)
|
||||
The US Department of Justice is siding with X, as the social media platform owned by Elon Musk navigates a criminal investigation unfolding in France....
|
||||
|
||||
- [A comet gets destroyed by the sun, data centers endanger the Potomac River, and more science news](https://www.engadget.com/science/a-comet-gets-destroyed-by-the-sun-data-centers-endanger-the-potomac-river-and-more-science-news-160000714.html?src=rss)
|
||||
The Artemis II astronauts are settling back into life on Earth, but we're not quite tired yet of hearing about their amazing journey. There's a new PB...
|
||||
|
||||
- [Cyberpunk platformers, gallivanting geckos and other new indie games worth checking out](https://www.engadget.com/gaming/cyberpunk-platformers-gallivanting-geckos-and-other-new-indie-games-worth-checking-out-110000924.html?src=rss)
|
||||
Welcome to our latest roundup of what's going on in the indie game space. Once again, there are some neat new games for you to check out this weekend....
|
||||
|
||||
### 【TED Talks Daily】
|
||||
|
||||
- [3 questions to build resilience — and change the world | Sister True Dedication](https://go.ted.com/64BH)
|
||||
Every moment of movement is a chance to become more aware of yourself and the world around you, says Zen Buddhist nun Sister True Dedication. Guiding ...
|
||||
|
||||
### 【Slashdot】
|
||||
|
||||
- [Old Cars 'Tell Tales' by Storing Data That's Never Wiped](https://tech.slashdot.org/story/26/04/18/0621217/old-cars-tell-tales-by-storing-data-thats-never-wiped?utm_source=rss1.0mainlinkanon&utm_medium=feed)
|
||||
Slashdot reader Bismillah shared this report from ITNews: Research and development engineer Romain Marchand of Paris headquartered Quarkslab obtained ...
|
||||
|
||||
- [Fewer US College Students Major in CS. More Choose Data Science, Engineering](https://developers.slashdot.org/story/26/04/18/0332245/fewer-us-college-students-major-in-cs-more-choose-data-science-engineering?utm_source=rss1.0mainlinkanon&utm_medium=feed)
|
||||
"From 2008 to 2024, the number of four-year computer science degrees granted rose about fivefold..." reports the Washington Post. Then in 2025 CS sudd...
|
||||
|
||||
- [US Congress Fails to Pass Long-Term FISA Extension, Authorizes It Through April 30](https://yro.slashdot.org/story/26/04/18/1834202/us-congress-fails-to-pass-long-term-fisa-extension-authorizes-it-through-april-30?utm_source=rss1.0mainlinkanon&utm_medium=feed)
|
||||
Yesterday the U.S. Congress approved "a short-term extension" of a FISA law that allows wiretaps without a warrant for surveilling foreign targets, re...
|
||||
|
||||
- [30 WordPress Plugins Turned Into Malware After Ownership Change](https://it.slashdot.org/story/26/04/18/0552210/30-wordpress-plugins-turned-into-malware-after-ownership-change?utm_source=rss1.0mainlinkanon&utm_medium=feed)
|
||||
Wednesday BleepingComputer reported that more than 30 WordPress plugins "have been compromised with malicious code that allows unauthorized access to ...
|
||||
|
||||
- [Fructose Isn't Just Sugar. It Acts More Like a Hormone](https://science.slashdot.org/story/26/04/18/0444250/fructose-isnt-just-sugar-it-acts-more-like-a-hormone?utm_source=rss1.0mainlinkanon&utm_medium=feed)
|
||||
Slashdot reader smazsyr writes: A new review says we've had fructose wrong for decades. The nine authors, led by Richard Johnson at the University of ...
|
||||
|
||||
- [20-Year-Old Enters Prison for Historic Breach, Ransoming of Massive Student Database](https://yro.slashdot.org/story/26/04/18/156236/20-year-old-enters-prison-for-historic-breach-ransoming-of-massive-student-database?utm_source=rss1.0mainlinkanon&utm_medium=feed)
|
||||
20-year-old Matthew Lane sent a text message to ABC News as his parents drove him to federal prison in Connecticut. "I'm just scared," he said, callin...
|
||||
|
||||
- [FSF to OnlyOffice: You Can't Use the GNU (A)GPL to Take Software Freedom Away](https://news.slashdot.org/story/26/04/18/0417208/fsf-to-onlyoffice-you-cant-use-the-gnu-agpl-to-take-software-freedom-away?utm_source=rss1.0mainlinkanon&utm_medium=feed)
|
||||
Nextcloud joined a project to create a sovereign replacement for Microsoft Office called "Euro-Office". But after that project forked OnlyOffice, Only...
|
||||
|
||||
- [US Government Now Wants Anthropic's 'Mythos', Preparing for AI Cybersecurity Threats](https://yro.slashdot.org/story/26/04/18/039221/us-government-now-wants-anthropics-mythos-preparing-for-ai-cybersecurity-threats?utm_source=rss1.0mainlinkanon&utm_medium=feed)
|
||||
Friday Anthropic's CEO met with top U.S. officials and "discussed opportunities for collaboration," according to a White House spokesperson itedd by P...
|
||||
|
||||
- [Shuttered Startups Are Selling Old Slack Chats, Emails To AI Companies](https://yro.slashdot.org/story/26/04/18/014244/shuttered-startups-are-selling-old-slack-chats-emails-to-ai-companies?utm_source=rss1.0mainlinkanon&utm_medium=feed)
|
||||
Some failed startups are reportedly selling old Slack messages, emails, and other internal records to AI companies as training data, creating a new wa...
|
||||
|
||||
25
wiki/concepts/AWS-Landing-Zone.md
Normal file
25
wiki/concepts/AWS-Landing-Zone.md
Normal file
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: "AWS Landing Zone"
|
||||
type: concept
|
||||
tags:
|
||||
- AWS
|
||||
- Architecture
|
||||
- Multi-Account
|
||||
---
|
||||
|
||||
## Definition
|
||||
AWS Landing Zone 是 AWS 推荐的企业级云基础架构框架,通过多账号策略、安全基线、网络架构等组件提供安全、可扩展的云环境起点。
|
||||
|
||||
## Key Components
|
||||
- **多账号策略**:通过 AWS Organizations 管理多个账户
|
||||
- **安全基线**:安全组、SCP、密码策略等
|
||||
- **网络架构**:VPC、Transit Gateway、VPN/Direct Connect
|
||||
- **身份管理**:IAM 角色、SSO、AD 集成
|
||||
|
||||
## Related Concepts
|
||||
- [[Network-Segregation]]
|
||||
- [[SSM-Access]]
|
||||
- [[Gruntwork-Landing-Zone]]
|
||||
|
||||
## Related Entities
|
||||
- [[AWS]]
|
||||
24
wiki/concepts/Break-Glass-Access.md
Normal file
24
wiki/concepts/Break-Glass-Access.md
Normal file
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: "Break-Glass Access"
|
||||
type: concept
|
||||
tags:
|
||||
- Security
|
||||
- Emergency
|
||||
---
|
||||
|
||||
## Definition
|
||||
Break-Glass Access(紧急访问)是指在紧急情况下绕过正常安全控制流程,获得系统访问权限的机制。通常作为备份方案,仅在无法通过正常渠道访问时使用。
|
||||
|
||||
## Application
|
||||
在 AWS Landing Zone 安全策略中,长期目标是基础设施即代码(IaC)以减少控制台访问和 break-glass access 需求,紧急访问仅作为极端情况的最后手段。
|
||||
|
||||
## Best Practices
|
||||
- 严格限制使用频率
|
||||
- 完整记录访问日志
|
||||
- 事后审查和报告
|
||||
- 逐步减少对它的依赖
|
||||
|
||||
## Related Concepts
|
||||
- [[Zero-Trust-Access]]
|
||||
- [[AWS-Landing-Zone]]
|
||||
- [[Infrastructure-as-Code-IaC]]
|
||||
31
wiki/concepts/CAPA.md
Normal file
31
wiki/concepts/CAPA.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
title: "CAPA"
|
||||
type: concept
|
||||
tags: [incident-management, postmortem]
|
||||
sources: [ctp-topic-30-managing-change]
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Summary
|
||||
CAPA(Corrective and Preventive Action,纠正和预防措施)是事故管理的重要组成部分,通过根因分析防止同类问题再次发生。
|
||||
|
||||
## Definition
|
||||
CAPA 即 Post-mortem 回顾,目的是从事故中提取根因并预防同类问题再次发生。
|
||||
|
||||
## Aliases
|
||||
- Corrective and Preventive Action:纠正和预防措施
|
||||
- Post-mortem:事故回顾
|
||||
|
||||
## Process
|
||||
1. 事故响应:立即采取行动缓解影响
|
||||
2. 根因分析:识别问题的根本原因
|
||||
3. 纠正措施:修复已发现的问题
|
||||
4. 预防措施:制定措施防止同类问题再次发生
|
||||
5. 文档记录:完整记录分析和改进措施
|
||||
|
||||
## Related Concepts
|
||||
- [[Incident Management]]:事件管理,CAPA 的上游流程
|
||||
- [[SRE]]:CAPA 的执行者
|
||||
|
||||
## Connections
|
||||
- [[ctp-topic-30-managing-change]] ← is_the_source_for
|
||||
43
wiki/concepts/Change-Management.md
Normal file
43
wiki/concepts/Change-Management.md
Normal file
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: "Change Management"
|
||||
type: concept
|
||||
tags: [ITSM, change-management, SRE]
|
||||
sources: [ctp-topic-30-managing-change]
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Summary
|
||||
变更管理是 ITSM 的核心流程之一,用于控制和管理 IT 环境的任何变更,降低变更风险并确保服务质量。
|
||||
|
||||
## Definition
|
||||
在云转型项目中,变更管理涉及对生产环境或基础设施的任何修改的控制、审批和跟踪。
|
||||
|
||||
## Change Types
|
||||
|
||||
### 标准变更 (Standard Change)
|
||||
- 预批准变更,无需变更咨询委员会(CAB)批准
|
||||
- 风险低、影响小、高度可预测
|
||||
- 应尽可能实现完全自动化(IaC + CI/CD Pipeline)
|
||||
- 示例:标签更新、配置参数调整等
|
||||
|
||||
### 正常变更 (Normal Change)
|
||||
- 包含一定风险或影响的变更
|
||||
- 需要 CAB 批准,并可能需要跨团队协调
|
||||
- 有预定义的变更窗口
|
||||
- 示例:新服务部署、架构变更等
|
||||
|
||||
### 紧急变更 (Emergency Change)
|
||||
- 为了缓解事故并尽快恢复服务到期望状态而需要立即执行的变更
|
||||
- 事后通过 CAPA/Post-mortem 修复根因
|
||||
- 示例:紧急安全补丁、热故障修复等
|
||||
|
||||
## Related Concepts
|
||||
- [[ITSM]]:IT 服务管理框架
|
||||
- [[SRE]]:站点可靠性工程,变更管理的执行方
|
||||
- [[SMACKS Ticket]]:变更记录和管理工具
|
||||
|
||||
## Related Entities
|
||||
- [[Brendan Starnig]]:CTP Topic 30 讲师
|
||||
|
||||
## Connections
|
||||
- [[ctp-topic-30-managing-change]] ← is_the_source_for
|
||||
40
wiki/concepts/Cyber-Suite.md
Normal file
40
wiki/concepts/Cyber-Suite.md
Normal file
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: Cyber Suite Standards
|
||||
type: concept
|
||||
tags:
|
||||
- Security
|
||||
- CTP
|
||||
- Standards
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
Cyber Suite(网络安全套件标准)是由 PSAC(Product Security Approval Committee)团队发布的网络安全标准文档,定义了 CTP 项目中产品必须遵循的加密算法和安全配置。
|
||||
|
||||
## Updated Standards
|
||||
|
||||
更新后的 Cyber Suite 标准包括:
|
||||
|
||||
### Considered Standard(标准套件)
|
||||
- 符合 FIPS 标准
|
||||
- Java、Golang、Node.js、OpenCel for CNC++ 兼容
|
||||
|
||||
### Optional(可选套件)
|
||||
- 为向后兼容提供
|
||||
- 但包含 CBC(Cipher Block Chaining)模式,被认为安全性较弱
|
||||
|
||||
### Cipher Selection
|
||||
|
||||
产品可从不同类别选择加密套件:
|
||||
- 密钥交换(Key Exchange)
|
||||
- 认证(Authentication)
|
||||
- 加密(Encryption)
|
||||
- 哈希(Hash)
|
||||
|
||||
### Review Requirement
|
||||
|
||||
使用非标准和可选套件之外加密算法的产品需经过 PSAC 团队审查。
|
||||
|
||||
## References
|
||||
|
||||
- [[CTP Topic 36 SendGrid as an email service]]
|
||||
36
wiki/concepts/Early-Live-Support.md
Normal file
36
wiki/concepts/Early-Live-Support.md
Normal file
@@ -0,0 +1,36 @@
|
||||
---
|
||||
title: "Early Live Support"
|
||||
type: concept
|
||||
tags: [SRE, cloud-transition]
|
||||
sources: [ctp-topic-30-managing-change]
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Summary
|
||||
Early Live Support(早期上线支持)是 Build 与 BAU 之间的过渡阶段,确保服务平稳上线。
|
||||
|
||||
## Definition
|
||||
在云转型项目中,Early Live Support 是构建阶段完成后的上线过渡阶段,需要完成 Go-Live Checklist。
|
||||
|
||||
## Key Requirements
|
||||
- 监控覆盖:确保所有关键服务和基础设施都得到充分监控
|
||||
- 支持模型:明确各团队与 SRE 团队的交互方式和责任范围
|
||||
- 事件响应流程:建立清晰的事件响应和升级流程
|
||||
- SLO/SLI 定义:定义明确的服务等级目标和指标
|
||||
|
||||
## Go-Live Checklist Items
|
||||
- [ ] 监控覆盖完整
|
||||
- [ ] 支持模型已定义
|
||||
- [ ] 事件响应流程已建立
|
||||
- [ ] SLO/SLI 已定义
|
||||
- [ ] On-call Schedule 已配置
|
||||
|
||||
## Related Concepts
|
||||
- [[SRE]]:早期上线支持的主要执行者
|
||||
- [[Change Management]]:与变更管理流程相关
|
||||
|
||||
## Related Entities
|
||||
- [[Brendan Starnig]]:CTP Topic 30 讲师
|
||||
|
||||
## Connections
|
||||
- [[ctp-topic-30-managing-change]] ← is_the_source_for
|
||||
29
wiki/concepts/Enterprise-Architecture-EA.md
Normal file
29
wiki/concepts/Enterprise-Architecture-EA.md
Normal file
@@ -0,0 +1,29 @@
|
||||
---
|
||||
id: enterprise-architecture-ea
|
||||
title: "Enterprise Architecture (EA)"
|
||||
type: concept
|
||||
tags:
|
||||
- Technical-Architecture
|
||||
- Cloud-Architecture
|
||||
---
|
||||
|
||||
## Definition
|
||||
企业架构(Enterprise Architecture,EA)是架构体系的高层,负责将业务目标转化为技术原则和标准,确保技术投资与商业战略一致。
|
||||
|
||||
## Position in Architecture Hierarchy
|
||||
- **企业架构(Enterprise Architecture, EA)**:高层,负责将业务目标转化为技术原则和标准
|
||||
- **方案架构(Solution Architecture, SA)**:中间层,负责特定项目或服务的优化实施
|
||||
- **技术架构(Technical Architecture, TA)**:底层,负责具体基础设施的设计和实施治理
|
||||
|
||||
## Responsibilities
|
||||
- 对接业务战略
|
||||
- 制定技术原则和标准
|
||||
- 确保技术投资与商业战略一致
|
||||
|
||||
## Related Concepts
|
||||
- [[Technical-Architecture-TA]]
|
||||
- [[Solution-Architecture-SA]]
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-19*
|
||||
45
wiki/concepts/Error-Budget.md
Normal file
45
wiki/concepts/Error-Budget.md
Normal file
@@ -0,0 +1,45 @@
|
||||
---
|
||||
id: error-budget
|
||||
title: "Error Budget(错误预算)"
|
||||
type: concept
|
||||
tags: [sre, reliability, availability]
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Definition
|
||||
Error Budget(错误预算)是系统在不影响客户的前提下可以不可靠的最大时间量。它弥合了开发与运维之间的鸿沟,将失败正常化为开发过程的一部分。
|
||||
|
||||
## Calculation
|
||||
```
|
||||
Error Budget = 1 - 可用性 SLO
|
||||
```
|
||||
|
||||
例如:
|
||||
- 99.9% SLO → 0.1% Error Budget
|
||||
- 99.99% SLO → 0.01% Error Budget
|
||||
|
||||
完美可用性是 100%,Error Budget 落在 SLO 和 100% 之间。
|
||||
|
||||
## Usage
|
||||
- **在预算内**:开发者可以承担更多风险,快速交付功能
|
||||
- **超出预算**:开发者必须做出更保守的选择,优先保证稳定性
|
||||
|
||||
## Measurement
|
||||
- [[SLI(服务等级指标)]]:可靠性的可量化度量指标
|
||||
- [[SLO(服务等级目标)]]:服务应该达到的性能/可靠性目标
|
||||
- [[SLA(服务等级协议)]]:客户级别的正式协议
|
||||
|
||||
## Importance
|
||||
1. **监控能力**:快速显示 Error Budget 是否未充分利用或已超出
|
||||
2. **小幅度变更**:小迭代变更和充分测试的部署是管理 Error Budget 的关键
|
||||
3. **混沌工程**:通过故意引发故障测试系统韧性,确保满足 NFR
|
||||
|
||||
## Relationship
|
||||
- [[SRE]] ← uses ← Error Budget
|
||||
- Error Budget ← derives ← [[SLO(服务等级目标)]]
|
||||
- [[SLO(服务等级目标)]] ← measures ← [[SLI(服务等级指标)]]
|
||||
|
||||
## References
|
||||
- [[CTP Topic 41 NFR's and Error Budgets]] — Error Budget 概念详解
|
||||
- [[Brendan Standing]] — Micro Focus SRE 负责人
|
||||
- [[NFR(非功能需求)]] — Error Budget 服务的目标
|
||||
29
wiki/concepts/Gate-Process.md
Normal file
29
wiki/concepts/Gate-Process.md
Normal file
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: "Gate Process"
|
||||
type: concept
|
||||
tags:
|
||||
- CTP
|
||||
- Governance
|
||||
- Approval
|
||||
date: 2026-04-19
|
||||
---
|
||||
|
||||
## Summary
|
||||
- 定义:网关审批流程,用于治理项目进度的关键决策点
|
||||
- 目的:确保项目在进入下一阶段前满足特定条件和标准
|
||||
|
||||
## Gate 节点
|
||||
|
||||
| Gate | 名称 | 目的 |
|
||||
|------|------|------|
|
||||
| Gate 0 | 评估准入 | 初步评估需求是否满足进入 POC 的基本条件 |
|
||||
| Gate 1 | 设计权威审批 | 设计权威(Design Authority)审批解决方案设计,确保符合云原生原则 |
|
||||
| Gate 3 | 迁移准入 | 最终批准启动生产环境迁移 |
|
||||
|
||||
## Related Concepts
|
||||
- [[Proof-of-Concept-POC]] — POC 阶段涉及 Gate 0、Gate 1
|
||||
- [[Solution-Design]] — Gate 1 审批的核心对象
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-19*
|
||||
45
wiki/concepts/GitHub-Enterprise-to-GitLab-Migration.md
Normal file
45
wiki/concepts/GitHub-Enterprise-to-GitLab-Migration.md
Normal file
@@ -0,0 +1,45 @@
|
||||
---
|
||||
title: "GitHub-Enterprise to GitLab Migration"
|
||||
type: concept
|
||||
tags:
|
||||
- DevOps
|
||||
- Migration
|
||||
- GitHub
|
||||
- GitLab
|
||||
date-added: 2026-04-19
|
||||
---
|
||||
|
||||
## Definition
|
||||
GitHub-Enterprise to GitLab Migration(GitHub Enterprise 到 GitLab 迁移)是 OpenText 将源代码仓库从 GitHub Enterprise 迁移到 GitLab 的企业级迁移项目。
|
||||
|
||||
## Migration Approaches
|
||||
- **Mirroring**:将 GitHub 仓库同步到 GitLab,保持持续更新
|
||||
- **Shift and Lift**:将代码复制到 GitLab 并同时转换 CI/CD 管道
|
||||
|
||||
## Migration Tracking
|
||||
- 通过 PHT(Product Hub platform)跟踪进度
|
||||
- 定期向开发经理和构建倡导者更新
|
||||
- 规划指南:清点 GitHub 资产、识别管道、了解网络连接
|
||||
|
||||
## Key Milestones
|
||||
1. 安装 GitLab 插件
|
||||
2. 早期访问 GitLab
|
||||
3. 映射仓库到 PHT
|
||||
4. 设置服务账户
|
||||
5. 更新管道
|
||||
|
||||
## Network Connectivity
|
||||
- GitLab proxy 位于 Brook Park,可通过 SD1 访问
|
||||
- 商业实例连接 GitLab 可能需要 GIS 团队批准例外
|
||||
|
||||
## Related Entities
|
||||
- [[GitHub-Enterprise]]
|
||||
- [[GitLab]]
|
||||
- [[OpenText]]
|
||||
- [[Build-Hub]]
|
||||
- [[Project-Thor]]
|
||||
|
||||
## Connections
|
||||
- [[GitHub-Enterprise]] → replaced_by → [[GitLab]]
|
||||
- [[Self-Serve-Migration]] ← applies_to ← [[GitHub-Enterprise-to-GitLab-Migration]]
|
||||
- [[Build-Hub]] ← supports ← [[GitHub-Enterprise-to-GitLab-Migration]]
|
||||
14
wiki/concepts/HCX.md
Normal file
14
wiki/concepts/HCX.md
Normal file
@@ -0,0 +1,14 @@
|
||||
---
|
||||
title: "HCX (Hybrid Cloud Extender)"
|
||||
type: concept
|
||||
tags: [VMware, Migration, Hybrid-Cloud]
|
||||
---
|
||||
|
||||
## Description
|
||||
VMware 提供的混合云扩展工具,实现 on-premises vSphere 和 SDDC 的双向可视化管理,支持每次迁移最多 200 台 VM。
|
||||
|
||||
## Type
|
||||
- 产品/工具
|
||||
|
||||
## Related
|
||||
- 用于 [[VMware-Cloud-on-AWS]] 的多云管理
|
||||
34
wiki/concepts/Hub-and-Spoke.md
Normal file
34
wiki/concepts/Hub-and-Spoke.md
Normal file
@@ -0,0 +1,34 @@
|
||||
---
|
||||
title: "Hub-and-Spoke"
|
||||
type: concept
|
||||
tags:
|
||||
- networking
|
||||
- topology
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Hub-and-Spoke
|
||||
- 星型拓扑
|
||||
- Hub and Spoke
|
||||
|
||||
## Description
|
||||
一种网络拓扑结构,所有分支(Spoke)连接到中心节点(Hub),分支间的通信通常经过 Hub 中转。在 AWS 云网络架构中,Transit Gateway 充当 Hub,VPC 和 Landing Zones 作为 Spoke,实现集中化的网络管理。
|
||||
|
||||
## Use Cases
|
||||
- AWS Transit Gateway 连接多个 VPC
|
||||
- 企业广域网架构
|
||||
- 跨区域网络互联
|
||||
|
||||
## Related Concepts
|
||||
- [[Transit Gateway]]
|
||||
- [[SD-WAN]]
|
||||
- [[Overlay Network]]
|
||||
|
||||
## Related Entities
|
||||
- [[AWS]]
|
||||
|
||||
## Sources
|
||||
- [[ctp-topic-18-wide-area-networking-in-aws-cloud]]
|
||||
|
||||
## Related Sources
|
||||
- [[ctp-topic-14-octane-hub-on-aws-real-life-experience]]
|
||||
30
wiki/concepts/NFR.md
Normal file
30
wiki/concepts/NFR.md
Normal file
@@ -0,0 +1,30 @@
|
||||
---
|
||||
id: nfr
|
||||
title: "NFR(非功能需求)"
|
||||
type: concept
|
||||
tags: [sre, requirements, reliability]
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Definition
|
||||
NFR(Non-Functional Requirements,非功能需求)是评判系统运行状况的标准,决定可用性、性能、安全性、可扩展性等属性。
|
||||
|
||||
## Key Aspects
|
||||
- **可用性(Availability)**:系统正常运行时间比例(如 99.9%、99.99%)
|
||||
- **性能(Performance)**:响应时间、吞吐量等
|
||||
- **安全性(Security)**:数据加密、访问控制等
|
||||
- **可扩展性(Scalability)**:水平/垂直扩展能力
|
||||
|
||||
## Cloud Context
|
||||
在云端,NFR 应更规范化,利用云原生服务:
|
||||
- AWS Backup 定义备份策略和测试频率
|
||||
- DR 规划包含季度测试和 IaC 基础设施
|
||||
- NFR Epic 集成到 Sprint backlog
|
||||
|
||||
## Relationship with SRE
|
||||
- [[SRE]] 通过 [[Error Budget(错误预算)]] 和 [[SLO(服务等级目标)]] 实现 NFR
|
||||
- [[混沌工程]] 验证 NFR 是否满足
|
||||
|
||||
## References
|
||||
- [[CTP Topic 41 NFR's and Error Budgets]] — NFR 在云和敏捷开发中的应用
|
||||
- [[Brendan Standing]] — Micro Focus SRE 负责人
|
||||
21
wiki/concepts/Network-Segregation.md
Normal file
21
wiki/concepts/Network-Segregation.md
Normal file
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: "Network Segregation"
|
||||
type: concept
|
||||
tags:
|
||||
- Network-Security
|
||||
- AWS
|
||||
---
|
||||
|
||||
## Definition
|
||||
网络隔离是通过防火墙或其他安全设备控制不同网络区域之间通信的安全策略,确保敏感 workloads 与不受信任的网络区域分离。
|
||||
|
||||
## Application
|
||||
在 AWS Landing Zone 环境中,通过 Checkpoint 防火墙控制服务器间通信(server-to-server communications),阻断内部网络(on-prem、VPN)直接访问 AWS 生产网段。
|
||||
|
||||
## Related Concepts
|
||||
- [[Checkpoint-Firewall]]
|
||||
- [[SPI-Features]]
|
||||
- [[AWS-Landing-Zone]]
|
||||
|
||||
## Related Entities
|
||||
- [[AWS]]
|
||||
31
wiki/concepts/Observability-Engineering.md
Normal file
31
wiki/concepts/Observability-Engineering.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
title: "Observability Engineering"
|
||||
type: concept
|
||||
tags: [monitoring, sre]
|
||||
---
|
||||
|
||||
## Definition
|
||||
可观测性工程是通过收集、分析和利用系统运行时数据(指标、日志、追踪)来持续理解系统健康状态的能力。
|
||||
|
||||
## Three Pillars
|
||||
1. **Metrics(指标)**:数值型数据,如 CPU 使用率、请求延迟
|
||||
2. **Logs(日志)**:事件记录,详细描述系统活动
|
||||
3. **Traces(追踪)**:请求在系统中的完整调用链路
|
||||
|
||||
## Goal
|
||||
不仅知道"系统是否正常运行",更能理解"系统为什么这样运行",实现:
|
||||
- 问题快速定位
|
||||
- 根因分析
|
||||
- 主动式运维
|
||||
- 容量规划
|
||||
|
||||
## Related Tools
|
||||
- Prometheus:指标收集和存储
|
||||
- Grafana:可视化
|
||||
- Jaeger:分布式追踪
|
||||
- ELK Stack:日志分析
|
||||
|
||||
## Related Concepts
|
||||
- [[SRE]]:站点可靠性工程
|
||||
- [[Monitoring]]:监控
|
||||
- [[Alerting]]:告警
|
||||
30
wiki/concepts/Overlay-Network.md
Normal file
30
wiki/concepts/Overlay-Network.md
Normal file
@@ -0,0 +1,30 @@
|
||||
---
|
||||
title: "Overlay Network"
|
||||
type: concept
|
||||
tags:
|
||||
- networking
|
||||
- virtualization
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Overlay Network
|
||||
- 叠加网络
|
||||
|
||||
## Description
|
||||
叠加网络(Overlay Network)是在现有物理网络(Underlay)之上构建的逻辑网络,用于实现复杂的路由和隧道功能。常见的 Overlay 协议包括 VXLAN、GRE、IPsec 等。在 SD-WAN 架构中,Overlay 网络负责路径选择和流量调度,与底层的物理网络解耦。
|
||||
|
||||
## Use Cases
|
||||
- SD-WAN 叠加网络
|
||||
- 容器网络(如 Kubernetes CNI)
|
||||
- VPN 隧道
|
||||
- 云间互联
|
||||
|
||||
## Related Concepts
|
||||
- [[SD-WAN]]
|
||||
- [[Hub-and-Spoke]]
|
||||
|
||||
## Related Entities
|
||||
- [[AWS]]
|
||||
|
||||
## Sources
|
||||
- [[ctp-topic-18-wide-area-networking-in-aws-cloud]]
|
||||
21
wiki/concepts/Product-Backlog.md
Normal file
21
wiki/concepts/Product-Backlog.md
Normal file
@@ -0,0 +1,21 @@
|
||||
# Product Backlog
|
||||
|
||||
Product Backlog(产品待办列表)是一个存放待开发功能和需求的区域,高亮显示需求、收益和优先级。
|
||||
|
||||
## 核心特征
|
||||
|
||||
- 需求容器:存放所有待处理的功能请求
|
||||
- 优先级排序:基于价值、重要性和复杂度进行排序
|
||||
- 透明度:确保所有需求在同一标准下被审视
|
||||
- 持续演进:随着项目进展不断更新和调整
|
||||
|
||||
## 组成部分
|
||||
|
||||
- 新需求:通过 SMACs 提交
|
||||
- 评估工具:约 20 个问题的计算器,评估简洁性、成本和野心
|
||||
- 入池机制:评估后移入 Octane 作为特性
|
||||
|
||||
## 相关实践
|
||||
|
||||
- [[前置条件阶段]]:新团队加入前的准备流程
|
||||
- [[Sprint-规划]]:通常提前 6 个迭代规划
|
||||
27
wiki/concepts/Program-Demand-Process.md
Normal file
27
wiki/concepts/Program-Demand-Process.md
Normal file
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: "Program Demand Process"
|
||||
type: concept
|
||||
tags:
|
||||
- CTP
|
||||
- Process
|
||||
- Demand-Management
|
||||
date: 2026-04-19
|
||||
---
|
||||
|
||||
## Summary
|
||||
- 定义:从业务需求产生、优先级排序到最终交付迁移的端到端管理路径
|
||||
- 驱动因素:业务案例(如数据中心关闭)、高层管理人员战略优先级、产品组路线图
|
||||
- 关键环节:需求录入 → 优先级排序 → POC 决策 → Gate 审批 → 迁移至 Labs 或 SaaS
|
||||
|
||||
## Related Concepts
|
||||
- [[Proof-of-Concept-POC]] — 在需求处理流程中用于验证可行性的阶段
|
||||
- [[Gate-Process]] — 治理项目进度的关键决策点
|
||||
- [[Landing-Zone]] — 最终交付的目标云环境
|
||||
|
||||
## Connections
|
||||
- [[Sergio]] — 流程讲解专家
|
||||
- [[Damian]] — 流程讲解专家
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-19*
|
||||
23
wiki/concepts/Project-Thor.md
Normal file
23
wiki/concepts/Project-Thor.md
Normal file
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: "Project Thor"
|
||||
type: concept
|
||||
tags: [DevOps, Platform, OpenText]
|
||||
---
|
||||
|
||||
## Summary
|
||||
OpenText 云平台标准化项目,通过五大支柱框架实现工具链统一和供应链安全。
|
||||
|
||||
## Five Pillars
|
||||
- 敏捷和正确的周期管理(Agile and Right Cycle Management)
|
||||
- 产品和发布治理(Product and Release Governance)
|
||||
- Developer Portal(基于 Backstage)
|
||||
- Security as Governance(安全作为治理)
|
||||
- Build Hub(构建中心)
|
||||
|
||||
## Goal
|
||||
标准化工具链,整合治理模型,推广 GitLab、Artifactory 等工具,提升开发者体验和供应链安全。
|
||||
|
||||
## Connections
|
||||
- [[GitLab]] — 源代码托管
|
||||
- [[Artifactory]] — 制品仓库
|
||||
- [[OpenText]] — 所属公司
|
||||
34
wiki/concepts/Proof-of-Concept-POC.md
Normal file
34
wiki/concepts/Proof-of-Concept-POC.md
Normal file
@@ -0,0 +1,34 @@
|
||||
---
|
||||
title: "Proof of Concept (POC)"
|
||||
type: concept
|
||||
tags:
|
||||
- CTP
|
||||
- Validation
|
||||
- Risk-Management
|
||||
date: 2026-04-19
|
||||
---
|
||||
|
||||
## Summary
|
||||
- 定义:概念验证,在正式迁移前用于证明架构可行性、测试复杂网络需求及验证迁移方法的实验性阶段
|
||||
- 核心目的:降低迁移风险,验证架构和技术可行性,让团队熟悉基于 Gruntwork 构建的新一代 Landing Zone
|
||||
- 预期成果:
|
||||
- 经过验证的解决方案设计
|
||||
- 准备就绪的 IaC 脚本(Terraform/Terragrunt)
|
||||
- 明确的迁移时间表
|
||||
|
||||
## Success Criteria
|
||||
- POC 的成功标准应在启动前明确定义
|
||||
- 测试活动需有效证明产品已具备进入生产环境迁移的条件
|
||||
|
||||
## Related Concepts
|
||||
- [[Program-Demand-Process]] — POC 的前置流程
|
||||
- [[Gate-Process]] — POC 需要通过的审批关卡
|
||||
- [[Infrastructure-as-Code-IaC]] — POC 阶段需要准备的核心交付物
|
||||
- [[Landing-Zone]] — POC 熟悉的目标环境
|
||||
|
||||
## Connections
|
||||
- [[PCG-Team]] — 协助产品组进行 POC 的核心团队
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-19*
|
||||
28
wiki/concepts/Recovery-Assurance.md
Normal file
28
wiki/concepts/Recovery-Assurance.md
Normal file
@@ -0,0 +1,28 @@
|
||||
---
|
||||
title: "Recovery Assurance"
|
||||
type: concept
|
||||
tags: [dr, reliability, sre]
|
||||
---
|
||||
|
||||
## Definition
|
||||
恢复保障(Recovery Assurance)是一种从设计层面确保系统具备恢复能力的架构理念,与传统的灾难恢复(DR)不同,它强调主动式而非被动式响应。
|
||||
|
||||
## Key Differences from DR
|
||||
- **DR(灾难恢复)**:被动响应,事件发生后尝试恢复
|
||||
- **Recovery Assurance**:主动设计,在设计阶段就考虑恢复能力
|
||||
|
||||
## Core Principles
|
||||
1. **Design for Failure**:假设组件会故障,设计容错机制
|
||||
2. **Observability**:持续监控系统健康状态
|
||||
3. **Automation**:自动检测和恢复能力
|
||||
4. **Test-Driven**:通过测试验证恢复能力
|
||||
|
||||
## Related Metrics
|
||||
- [[RTO]](Recovery Time Objective):恢复时间目标
|
||||
- [[RPO]](Recovery Point Objective):恢复点目标
|
||||
|
||||
## Related Concepts
|
||||
- [[Self-Healing Systems]]:自愈系统
|
||||
- [[SRE]]:站点可靠性工程
|
||||
- [[Observability Engineering]]:可观测性工程
|
||||
- [[Chaos Engineering]]:混沌工程
|
||||
32
wiki/concepts/SD-WAN.md
Normal file
32
wiki/concepts/SD-WAN.md
Normal file
@@ -0,0 +1,32 @@
|
||||
---
|
||||
title: "SD-WAN"
|
||||
type: concept
|
||||
tags:
|
||||
- networking
|
||||
- wan
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- SD-WAN
|
||||
- Software-Defined Wide Area Network
|
||||
- 软件定义广域网
|
||||
|
||||
## Description
|
||||
软件定义广域网(SD-WAN)是一种通过软件控制层对物理网络进行抽象的技术,实现动态路径选择和负载均衡。在企业云架构中,SD-WAN 通常作为 Overlay Network(叠加网络)部署在 AWS 等公有云上,解决静态路由的局限性。
|
||||
|
||||
## Use Cases
|
||||
- 多分支机构网络互联
|
||||
- 动态路径选择和流量调度
|
||||
- 替代传统 MPLS 专线
|
||||
- Silver Peak 等 SD-WAN 方案集成
|
||||
|
||||
## Related Concepts
|
||||
- [[Hub-and-Spoke]]
|
||||
- [[Overlay Network]]
|
||||
- [[Transit Gateway]]
|
||||
|
||||
## Related Entities
|
||||
- [[AWS]]
|
||||
|
||||
## Sources
|
||||
- [[ctp-topic-18-wide-area-networking-in-aws-cloud]]
|
||||
27
wiki/concepts/SLA.md
Normal file
27
wiki/concepts/SLA.md
Normal file
@@ -0,0 +1,27 @@
|
||||
---
|
||||
id: sla
|
||||
title: "SLA(服务等级协议)"
|
||||
type: concept
|
||||
tags: [sre, reliability, contract]
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Definition
|
||||
SLA(Service Level Agreement,服务等级协议)是客户级别的正式协议,定义了服务提供者对客户的承诺。
|
||||
|
||||
## Key Characteristics
|
||||
- **具有法律约束力**:违反可能涉及经济赔偿
|
||||
- **比 SLO 更宽松**:SLO 是团队内部目标,SLA 是对客户的承诺
|
||||
- **基于 SLO**:SLA 通常基于内部 SLO 制定
|
||||
|
||||
## Relationship
|
||||
- [[SLA(服务等级协议)]] ← based_on ← [[SLO(服务等级目标)]]
|
||||
- [[SLO(服务等级目标)]] ← measures ← [[SLI(服务等级指标)]]
|
||||
|
||||
## Example
|
||||
- SLO: 99.9% 可用性(内部目标)
|
||||
- SLA: 99.5% 可用性(对客户承诺,更宽松)
|
||||
|
||||
## References
|
||||
- [[CTP Topic 41 NFR's and Error Budgets]] — SLI/SLO/SLA 体系详解
|
||||
- [[SRE]] — 站点可靠性工程实践
|
||||
28
wiki/concepts/SLI.md
Normal file
28
wiki/concepts/SLI.md
Normal file
@@ -0,0 +1,28 @@
|
||||
---
|
||||
id: sli
|
||||
title: "SLI(服务等级指标)"
|
||||
type: concept
|
||||
tags: [sre, reliability, metrics]
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Definition
|
||||
SLI(Service Level Indicator,服务等级指标)是可靠性的可量化度量指标,用于衡量系统健康状态。
|
||||
|
||||
## Common SLIs
|
||||
- **可用性**:成功请求占总请求的比例
|
||||
- **延迟**:请求响应时间(如 P99 延迟)
|
||||
- **错误率**:失败请求占总请求的比例
|
||||
- **吞吐量**:每秒处理的请求数(QPS)
|
||||
|
||||
## Usage
|
||||
SLI 被 [[SLO(服务等级目标)]] 引用,用于测量服务是否达到预期可靠性水平。
|
||||
|
||||
## Relationship
|
||||
- [[SLI(服务等级指标)]] ← measures ← [[SLO(服务等级目标)]]
|
||||
- [[SLO(服务等级目标)]] ← derives ← [[Error Budget(错误预算)]]
|
||||
- [[SLA(服务等级协议)]] ← based_on ← [[SLO(服务等级目标)]]
|
||||
|
||||
## References
|
||||
- [[CTP Topic 41 NFR's and Error Budgets]] — SLI/SLO/SLA 体系详解
|
||||
- [[SRE]] — 站点可靠性工程实践
|
||||
32
wiki/concepts/SLO.md
Normal file
32
wiki/concepts/SLO.md
Normal file
@@ -0,0 +1,32 @@
|
||||
---
|
||||
id: slo
|
||||
title: "SLO(服务等级目标)"
|
||||
type: concept
|
||||
tags: [sre, reliability, metrics]
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Definition
|
||||
SLO(Service Level Objective,服务等级目标)定义了服务应该达到的性能/可靠性目标,是团队努力实现的具体指标。
|
||||
|
||||
## Common SLOs
|
||||
- **可用性目标**:99.9%(三个九)、99.99%(四个九)
|
||||
- **延迟目标**:P99 响应时间 < 200ms
|
||||
- **错误目标**:错误率 < 0.1%
|
||||
|
||||
## Relationship with Error Budget
|
||||
SLO 与 Error Budget 直接关联:
|
||||
```
|
||||
Error Budget = 1 - 可用性 SLO
|
||||
```
|
||||
|
||||
例如:99.9% SLO → 0.1% Error Budget
|
||||
|
||||
## Hierarchy
|
||||
- [[SLI(服务等级指标)]] → measures → SLO
|
||||
- SLO → derives → [[Error Budget(错误预算)]]
|
||||
- SLO → satisfies → [[SLA(服务等级协议)]]
|
||||
|
||||
## References
|
||||
- [[CTP Topic 41 NFR's and Error Budgets]] — SLO 与 Error Budget 关系详解
|
||||
- [[SRE]] — 站点可靠性工程实践
|
||||
20
wiki/concepts/SMACs.md
Normal file
20
wiki/concepts/SMACs.md
Normal file
@@ -0,0 +1,20 @@
|
||||
# SMACs
|
||||
|
||||
SMACs(Service Management Access)是一个需求提交的标准化入口,用于启动计时器和确保需求被追踪。
|
||||
|
||||
## 核心特征
|
||||
|
||||
- 标准化提交:所有新需求必须通过 SMACs 提交
|
||||
- 计时启动:提交后开始计时
|
||||
- 追踪保证:确保需求被完整记录
|
||||
|
||||
## 使用方式
|
||||
|
||||
- 提交新需求
|
||||
- 追踪需求状态
|
||||
- 关联评审会议
|
||||
|
||||
## 替代方案
|
||||
|
||||
- 邮件或聊天可作为初始联系方式
|
||||
- SMACs 是最可靠的追踪方式
|
||||
17
wiki/concepts/SPI-Features.md
Normal file
17
wiki/concepts/SPI-Features.md
Normal file
@@ -0,0 +1,17 @@
|
||||
---
|
||||
title: "SPI Features"
|
||||
type: concept
|
||||
tags:
|
||||
- Network-Security
|
||||
- Firewall
|
||||
---
|
||||
|
||||
## Definition
|
||||
SPI(Stateful Packet Inspection)是一种状态包检查防火墙功能,能够追踪活跃连接的状态,基于连接状态做出过滤决策,而非仅依赖静态规则。
|
||||
|
||||
## Application
|
||||
在 AWS Landing Zone 网络隔离场景中,Checkpoint 防火墙启用 SPI 功能,默认拒绝(default deny)策略,仅允许必需的服务和网络段进入 Landing Zone。
|
||||
|
||||
## Related Concepts
|
||||
- [[Network-Segregation]]
|
||||
- [[Checkpoint-Firewall]]
|
||||
21
wiki/concepts/SSM-Access.md
Normal file
21
wiki/concepts/SSM-Access.md
Normal file
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: "SSM Access"
|
||||
type: concept
|
||||
tags:
|
||||
- AWS
|
||||
- Security
|
||||
- Remote-Access
|
||||
---
|
||||
|
||||
## Definition
|
||||
SSM Access(AWS Systems Manager Access)是一种通过 AWS Systems Manager 实现安全远程访问的方案,用户通过扮演 IAM 角色获得目标 EC2 实例的 SSM agent 访问权限,无需 VPN 即可实现安全连接。
|
||||
|
||||
## Application
|
||||
替代传统 VPN,通过浏览器会话或 AWS CLI 访问 AWS 环境内的 EC2 实例。优势包括:双因素认证、安全连接位于 AWS 网络内、成本低、部署快。
|
||||
|
||||
## Related Concepts
|
||||
- [[AWS-Landing-Zone]]
|
||||
- [[Zero-Trust-Access]]
|
||||
|
||||
## Related Entities
|
||||
- [[AWS]]
|
||||
33
wiki/concepts/Self-Serve-Migration.md
Normal file
33
wiki/concepts/Self-Serve-Migration.md
Normal file
@@ -0,0 +1,33 @@
|
||||
---
|
||||
title: "Self-Serve Migration"
|
||||
type: concept
|
||||
tags:
|
||||
- DevOps
|
||||
- Migration
|
||||
- GitHub
|
||||
- GitLab
|
||||
date-added: 2026-04-19
|
||||
---
|
||||
|
||||
## Definition
|
||||
Self-Serve Migration(自服务迁移)是一种迁移模式,在这种模式下,各团队自行定义需求、规划迁移方案并执行管道转换,而非由中央团队统一执行。在 OpenText 的 GitHub 到 GitLab 迁移中采用此模式。
|
||||
|
||||
## Characteristics
|
||||
- 各团队自行定义在 GitHub 中拥有的资产
|
||||
- 各团队规划如何移动代码和转换 CI/CD 管道
|
||||
- Build Hub 团队仅在需要时提供协助
|
||||
- 权限通过 PHT(Product Hub platform)进行自服务管理
|
||||
|
||||
## Related Concepts
|
||||
- [[CI/CD-流水线]]
|
||||
- [[GitOps]]
|
||||
|
||||
## Related Entities
|
||||
- [[GitHub-Enterprise]]
|
||||
- [[GitLab]]
|
||||
- [[Build-Hub]]
|
||||
- [[OpenText]]
|
||||
|
||||
## Connections
|
||||
- [[Self-Serve-Migration]] → enabled_by → [[GitLab]]
|
||||
- [[Build-Hub]] ← supports ← [[Self-Serve-Migration]]
|
||||
29
wiki/concepts/Solution-Architecture-SA.md
Normal file
29
wiki/concepts/Solution-Architecture-SA.md
Normal file
@@ -0,0 +1,29 @@
|
||||
---
|
||||
id: solution-architecture-sa
|
||||
title: "Solution Architecture (SA)"
|
||||
type: concept
|
||||
tags:
|
||||
- Technical-Architecture
|
||||
- Cloud-Architecture
|
||||
---
|
||||
|
||||
## Definition
|
||||
方案架构(Solution Architecture,SA)是架构体系的中间层,专注于特定项目或服务的优化实施,确保系统组件间的高效协作。
|
||||
|
||||
## Position in Architecture Hierarchy
|
||||
- **企业架构(Enterprise Architecture, EA)**:高层,负责将业务目标转化为技术原则和标准
|
||||
- **方案架构(Solution Architecture, SA)**:中间层,负责特定项目或服务的优化实施
|
||||
- **技术架构(Technical Architecture, TA)**:底层,负责具体基础设施的设计和实施治理
|
||||
|
||||
## Responsibilities
|
||||
- 负责中间件与服务优化
|
||||
- 确保系统组件间的高效协作
|
||||
- 特定项目或服务的架构设计
|
||||
|
||||
## Related Concepts
|
||||
- [[Enterprise-Architecture-EA]]
|
||||
- [[Technical-Architecture-TA]]
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-19*
|
||||
@@ -36,4 +36,18 @@ date_added: 2026-04-18
|
||||
|
||||
## Related Entities
|
||||
- [[AWS]]
|
||||
- [[Gruntwork]]
|
||||
- [[Gruntwork]]
|
||||
|
||||
## OpenText Tagging Standard V2
|
||||
OpenText Tagging Standard V2 是标签方法论的具体实现,由 Phenops 团队于 2023 年发起,扩展了以下应用范围:
|
||||
- 云账号
|
||||
- 云资源(计算、存储、网络)
|
||||
- Kubernetes 对象(namespace、pod、deployment、service、configmap)
|
||||
- 容器镜像
|
||||
|
||||
### 标签规范特点
|
||||
- 使用小写下划线语法(如 `ot_business_unit`)
|
||||
- 前缀标签确保语义明确:
|
||||
- OT_ 用于云标签
|
||||
- app.opentext.com 用于 Kubernetes 标签
|
||||
- com.opentext.image 用于容器镜像标签
|
||||
33
wiki/concepts/Technical-Architecture-TA.md
Normal file
33
wiki/concepts/Technical-Architecture-TA.md
Normal file
@@ -0,0 +1,33 @@
|
||||
---
|
||||
id: technical-architecture-ta
|
||||
title: "Technical Architecture (TA)"
|
||||
type: concept
|
||||
tags:
|
||||
- Technical-Architecture
|
||||
- Cloud-Architecture
|
||||
---
|
||||
|
||||
## Definition
|
||||
技术架构(Technical Architecture,TA)是三种架构职能中最贴近技术的层级,负责底层技术实施与基础设施治理。
|
||||
|
||||
## Position in Architecture Hierarchy
|
||||
- **企业架构(Enterprise Architecture, EA)**:高层,负责将业务目标转化为技术原则和标准
|
||||
- **方案架构(Solution Architecture, SA)**:中间层,负责特定项目或服务的优化实施
|
||||
- **技术架构(Technical Architecture, TA)**:底层,负责具体基础设施的设计和实施治理
|
||||
|
||||
## Responsibilities
|
||||
- 维护AWS Enterprise Landing Zones(企业落地分区)
|
||||
- 制定技术路线图(12-24个月前瞻性规划)
|
||||
- 推行"云优先(Cloud-first)"策略
|
||||
- 技术领域(Technical Domains)的生命周期管理
|
||||
|
||||
## Related Concepts
|
||||
- [[Enterprise-Architecture-EA]]
|
||||
- [[Solution-Architecture-SA]]
|
||||
- [[Technical-Domains]]
|
||||
- [[AWS-Enterprise-Landing-Zones]]
|
||||
- [[Cloud-First-Strategy]]
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-19*
|
||||
29
wiki/concepts/Technical-Domains.md
Normal file
29
wiki/concepts/Technical-Domains.md
Normal file
@@ -0,0 +1,29 @@
|
||||
---
|
||||
id: technical-domains
|
||||
title: "Technical Domains"
|
||||
type: concept
|
||||
tags:
|
||||
- Technical-Architecture
|
||||
- Cloud-Governance
|
||||
---
|
||||
|
||||
## Definition
|
||||
将公司技术栈划分为特定的领域(如身份认证、网络、Microsoft堆栈等),每个领域由专人负责其生命周期与路线图。
|
||||
|
||||
## Purpose
|
||||
- 通过首席架构师负责制,实现12-24个月前瞻性路线图规划
|
||||
- 帮助业务部门规避潜在风险、优化预算并提升交付速度
|
||||
- 从"救火式"响应转变为预测性规划
|
||||
|
||||
## Examples
|
||||
- 身份认证领域(Identity & Access)
|
||||
- 网络领域(Networking)
|
||||
- Microsoft堆栈领域
|
||||
|
||||
## Related Concepts
|
||||
- [[Technical-Architecture-TA]]
|
||||
- [[Enterprise-Architecture-EA]]
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-19*
|
||||
35
wiki/concepts/WSJF.md
Normal file
35
wiki/concepts/WSJF.md
Normal file
@@ -0,0 +1,35 @@
|
||||
---
|
||||
title: "WSJF (Weighted Shortest Job First)"
|
||||
type: concept
|
||||
tags: [Prioritization, CTP, Value-Delivery]
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Definition
|
||||
WSJF(加权最短作业优先)是一种用于序列 CTP(云转型计划)工作的优先级排序方法,基于成本效益最大化原则。
|
||||
|
||||
## Formula
|
||||
```
|
||||
WSJF = (业务价值 + 时间关键性 + 风险与机会) / 作业规模
|
||||
```
|
||||
|
||||
## Components
|
||||
- **业务价值 (Business Value)**:收入增加、成本降低、风险改善
|
||||
- **时间关键性 (Time Criticality)**:工作的时间敏感性
|
||||
- **风险与机会 (Risk & Opportunity)**:潜在风险和机会评估
|
||||
- **作业规模 (Size of Job)**:完成工作所需的 effort
|
||||
|
||||
## Application
|
||||
用于在多个需求之间进行优先级排序,以实现:
|
||||
- 最小 effort 实现最大 value
|
||||
- 早期价值交付回业务
|
||||
- 最大化经济利益
|
||||
|
||||
## Connections
|
||||
- [[WSJF]] ← prioritizes ← [[CTP]]
|
||||
- [[Demand Manager]] ← provides ← [[Business Value]]
|
||||
- [[Delivery Manager]] ← estimates ← [[Size of Job]]
|
||||
|
||||
## Aliases
|
||||
- Weighted Shortest Job First
|
||||
- Cost of Delay
|
||||
18
wiki/concepts/Zero-Trust-Access.md
Normal file
18
wiki/concepts/Zero-Trust-Access.md
Normal file
@@ -0,0 +1,18 @@
|
||||
---
|
||||
title: "Zero Trust Access"
|
||||
type: concept
|
||||
tags:
|
||||
- Security
|
||||
- AWS
|
||||
---
|
||||
|
||||
## Definition
|
||||
零信任访问(Zero Trust Access)是一种安全框架,遵循"永不信任、始终验证"原则,每次访问请求都需经过身份验证和授权,无论请求来自网络内部还是外部。
|
||||
|
||||
## Application
|
||||
在 AWS Landing Zone 中,通过 SSM 实现零信任访问:用户需扮演 IAM 角色获得目标 EC2 实例的 SSM agent 访问权限,依赖现有访问控制并启用双因素认证。
|
||||
|
||||
## Related Concepts
|
||||
- [[SSM-Access]]
|
||||
- [[AWS-Landing-Zone]]
|
||||
- [[Break-Glass-Access]]
|
||||
@@ -19,3 +19,6 @@ last_updated: 2025-03-02
|
||||
- [[CI/CD 流水线]]
|
||||
- [[价值流映射]]
|
||||
- [[DevSecOps]]
|
||||
|
||||
## Occurrences
|
||||
- [[CTP Topic 4 Using Agile to run the Cloud Transformation Program]] — 案例:从 Scrum 过渡到 Kanban 最终采用混合模式
|
||||
|
||||
25
wiki/entities/AWS-RAM.md
Normal file
25
wiki/entities/AWS-RAM.md
Normal file
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: "AWS RAM"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Resource Sharing
|
||||
date-added: 2026-04-19
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- AWS Resource Access Manager
|
||||
- RAM
|
||||
|
||||
## Description
|
||||
AWS 资源共享管理器,用于在 AWS Organization 内跨账号共享资源,如 Route 53 Resolver Rules、Transit Gateway 等,实现集中式基础设施管理。
|
||||
|
||||
## Use Cases
|
||||
- 跨账号共享 DNS 解析规则
|
||||
- 共享 Transit Gateway
|
||||
- 共享 Direct Connect 网关
|
||||
|
||||
## Related
|
||||
- [[Route-53]]:DNS 服务,其规则可通过 RAM 共享
|
||||
- [[AWS-Organizations]]:组织管理,配合 RAM 实现资源分享
|
||||
- [[Gruntwork-Landing-Zone]]:Landing Zone 架构,利用 RAM 实现跨账号资源共享
|
||||
16
wiki/entities/Arnold-Dacan.md
Normal file
16
wiki/entities/Arnold-Dacan.md
Normal file
@@ -0,0 +1,16 @@
|
||||
---
|
||||
title: "Arnold Dacan"
|
||||
type: entity
|
||||
tags: [person, OpenText, DevOps]
|
||||
---
|
||||
|
||||
## Summary
|
||||
- 角色:OpenText 技术专家
|
||||
- 贡献:主讲 Project Thor 平台与数据流介绍
|
||||
|
||||
## Aliases
|
||||
- Arnold Dacan
|
||||
|
||||
## Connections
|
||||
- [[OpenText]] — 所属公司
|
||||
- [[Project Thor]] — 主导项目
|
||||
27
wiki/entities/Brendan-Standing.md
Normal file
27
wiki/entities/Brendan-Standing.md
Normal file
@@ -0,0 +1,27 @@
|
||||
---
|
||||
id: brendan-standing
|
||||
title: "Brendan Standing"
|
||||
type: entity
|
||||
tags: [Person, SRE, DevOps]
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Summary
|
||||
Brendan Standing 是 Micro Focus 的 SRE(站点可靠性工程)负责人,在 OpenText Public Cloud Learning Sessions 中分享 NFR(非功能需求)和 Error Budget(错误预算)的实践经验。
|
||||
|
||||
## Roles
|
||||
- [[Micro Focus]] SRE 负责人
|
||||
|
||||
## Occurrences
|
||||
- [[CTP Topic 41 NFR's and Error Budgets]] — 演讲者,讲解 NFR 与 Error Budget 在云和敏捷开发中的应用
|
||||
|
||||
## Aliases
|
||||
- Brendan
|
||||
|
||||
## Key Statements
|
||||
> "We want to drive collaboration across our product groups and operations to ensure our obligation to our customers."
|
||||
|
||||
> "Error budgets normalize failure as part of the development process."
|
||||
|
||||
## References
|
||||
- 视频来源:NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 41_ NFR's and Error Budgets.mp4`
|
||||
17
wiki/entities/Brendan-Starnig.md
Normal file
17
wiki/entities/Brendan-Starnig.md
Normal file
@@ -0,0 +1,17 @@
|
||||
---
|
||||
title: "Brendan Starnig"
|
||||
type: entity
|
||||
tags: [SRE, Platform Engineering]
|
||||
sources: [ctp-topic-30-managing-change]
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Summary
|
||||
SRE Function Lead,负责 Platform Engineering 团队的站点可靠性工程和相关支持工作。
|
||||
|
||||
## Role
|
||||
- SRE Function Lead, Platform Engineering
|
||||
- 讲师:CTP Topic 30 Managing Change
|
||||
|
||||
## Topics Presented
|
||||
- [[ctp-topic-30-managing-change]]:云转型项目中的变更管理流程
|
||||
27
wiki/entities/Build-Hub.md
Normal file
27
wiki/entities/Build-Hub.md
Normal file
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: "Build Hub"
|
||||
type: entity
|
||||
tags:
|
||||
- DevOps
|
||||
- OpenText
|
||||
- Tooling
|
||||
date-added: 2026-04-19
|
||||
---
|
||||
|
||||
## Description
|
||||
Build Hub 是 OpenText 的中央工具管理团队,负责管理 GitLab 等软件交付管道的核心工具,并为各团队提供支持。
|
||||
|
||||
## Role
|
||||
- 管理 GitLab 等中央工具
|
||||
- 为软件交付管道提供支持
|
||||
- 协助团队进行代码迁移和管道转换
|
||||
|
||||
## Related Entities
|
||||
- [[GitLab]] — 管理的中央工具
|
||||
- [[OpenText]] — 所属公司
|
||||
- [[Project-Thor]] — 支持的项目
|
||||
|
||||
## Connections
|
||||
- [[OpenText]] ← works_for ← [[Build-Hub]]
|
||||
- [[GitLab]] ← managed_by ← [[Build-Hub]]
|
||||
- [[Project-Thor]] ← supported_by ← [[Build-Hub]]
|
||||
@@ -3,7 +3,7 @@ title: "CTP (Cloud Transformation Program)"
|
||||
type: entity
|
||||
tags: [Cloud, Transformation, Program]
|
||||
sources: []
|
||||
last_updated: 2026-04-18
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Summary
|
||||
@@ -17,6 +17,24 @@ CTP (Cloud Transformation Program) 是企业云迁移项目,目标是利用 AW
|
||||
- 工作负载迁移
|
||||
- 备份与灾难恢复策略实施
|
||||
|
||||
## Progress & Achievements
|
||||
- 从 Bublikan 迁出 3 个产品,575 台物理服务器被 240 台虚拟服务器替代
|
||||
- 40% 的 Redding 应用在退出后直接关闭
|
||||
- Houston 有 89 个空机架和 360 台未使用服务器
|
||||
- 已交付 Labs、SAS、Corporate 三种 Landing Zone
|
||||
- 已在 609 个 AWS 账户实施标签框架
|
||||
|
||||
## Key Objectives (Current Fiscal Year)
|
||||
- 在加拿大和澳大利亚建立 Landing Zone(已完成)
|
||||
- 搭建 Corporate IT Landing Zone(已完成)
|
||||
- 实施 AWS 账户标签框架(已完成)
|
||||
- Q2: 提供 Demo 和用户培训配置能力
|
||||
- Q2 & Q3: 改进 AWS 账户创建流程
|
||||
- Q2: 关闭 UAHD 数据中心
|
||||
- Q2: 从经典 Landing Zone 迁移工作负载
|
||||
- Q3: 建立 Azure Landing Zone
|
||||
- Q4: 将更多工作负载迁移到企业平台
|
||||
|
||||
## Related Entities
|
||||
- [[AWS]]
|
||||
- [[AWS Backup]]
|
||||
24
wiki/entities/Christian-Deckelman.md
Normal file
24
wiki/entities/Christian-Deckelman.md
Normal file
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: "Christian Deckelman"
|
||||
type: entity
|
||||
tags:
|
||||
- person
|
||||
- networking
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Christian Deckelman
|
||||
|
||||
## Description
|
||||
Micro Focus 的 IT 网络架构师,专注于企业级网络架构设计与实现。在 CTP Topic 18 中分享了 AWS 云广域网(WAN)架构设计的实践经验。
|
||||
|
||||
## Role
|
||||
- IT 网络架构师 @ Micro Focus
|
||||
|
||||
## Related Concepts
|
||||
- [[Transit Gateway]]
|
||||
- [[Hub-and-Spoke]]
|
||||
- [[SD-WAN]]
|
||||
|
||||
## Sources
|
||||
- [[ctp-topic-18-wide-area-networking-in-aws-cloud]]
|
||||
24
wiki/entities/CrowdStrike.md
Normal file
24
wiki/entities/CrowdStrike.md
Normal file
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: "CrowdStrike"
|
||||
type: entity
|
||||
tags: [company, cybersecurity]
|
||||
---
|
||||
|
||||
## Summary
|
||||
CrowdStrike 是全球领先的网络安全公司,以其云原生的终结点保护平台(Falcon 平台)而闻名。
|
||||
|
||||
## Key Products
|
||||
- Falcon:云原生终结点保护平台
|
||||
- Falcon Identity:身份保护
|
||||
- Falcon Cloud:云安全态势管理
|
||||
|
||||
## Key Capabilities
|
||||
- 人工智能驱动的威胁检测
|
||||
- 云原生架构
|
||||
- 实时威胁情报
|
||||
|
||||
## Notable Incident
|
||||
2024年7月,CrowdStrike Falcon sensor 的一次软件更新导致全球范围内数百万 Windows 系统蓝屏死机(BSOD),引发重大 IT 中断。这次事件推动了行业对 DR 和恢复保障的重视。
|
||||
|
||||
## Connections
|
||||
- 与多家云服务商(AWS、Azure、GCP)合作提供安全解决方案
|
||||
21
wiki/entities/Damian.md
Normal file
21
wiki/entities/Damian.md
Normal file
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: "Damian"
|
||||
type: entity
|
||||
tags:
|
||||
- CTP
|
||||
- Expert
|
||||
date: 2026-04-19
|
||||
---
|
||||
|
||||
## Summary
|
||||
- 角色:云转型计划(CTP)专家
|
||||
- 职责:主讲程序需求流程与 POC 入站流程相关课程,介绍 Gate 审批机制
|
||||
- 关联:与 Sergio 共同负责 CTP Topic 20 的讲解
|
||||
|
||||
## Connections
|
||||
- [[Sergio]] — 共同主讲人
|
||||
- [[CTP-Topic-20-Program-demand-process-flow-and-PoC-onboarding]]
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-19*
|
||||
28
wiki/entities/GitHub-Enterprise.md
Normal file
28
wiki/entities/GitHub-Enterprise.md
Normal file
@@ -0,0 +1,28 @@
|
||||
---
|
||||
title: "GitHub Enterprise"
|
||||
type: entity
|
||||
tags:
|
||||
- DevOps
|
||||
- Git
|
||||
- Migration
|
||||
date-added: 2026-04-19
|
||||
---
|
||||
|
||||
## Description
|
||||
GitHub Enterprise 是 GitHub 的企业版,为企业提供私有代码托管和协作功能。在 OpenText 迁移计划中,GitHub Enterprise 许可证将于 2024 年 12 月底到期,公司决定不再续约,转而使用 GitLab。
|
||||
|
||||
## Migration Status
|
||||
- 许可证到期:2024 年 12 月底
|
||||
- 决定:不续约,迁移到 GitLab
|
||||
- 迁移模式:self-serve
|
||||
- 权限控制:通过 PHT 管理
|
||||
|
||||
## Related Entities
|
||||
- [[GitHub]]
|
||||
- [[GitLab]]
|
||||
- [[OpenText]]
|
||||
- [[Build-Hub]]
|
||||
|
||||
## Connections
|
||||
- [[GitHub]] ← is ← [[GitHub-Enterprise]]
|
||||
- [[GitHub-Enterprise]] → replaced_by → [[GitLab]]
|
||||
@@ -3,7 +3,7 @@ title: "GitHub"
|
||||
type: entity
|
||||
tags: [平台, 代码托管]
|
||||
sources: [2025-年-11-个神级-AI-开源平替-GitHub-杀疯了。]
|
||||
last_updated: 2025-04-16
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Definition
|
||||
@@ -11,6 +11,14 @@ GitHub 是全球最大的代码托管平台,专注于开源软件协作。
|
||||
|
||||
## Aliases
|
||||
- github.com
|
||||
- GitHub Enterprise
|
||||
|
||||
## Migration to GitLab
|
||||
OpenText 正在将代码仓库从 GitHub Enterprise 迁移到 GitLab:
|
||||
- GitHub Enterprise 许可证将于 2024 年 12 月底到期,公司决定不再续约
|
||||
- GitLab 将作为集中式源代码控制系统
|
||||
- 迁移采用 self-serve 模式,各团队自行规划和执行
|
||||
|
||||
## Connections
|
||||
- [[2025年11个神级AI开源平替]] ← 托管于 ← [[GitHub]]
|
||||
- [[GitHub]] → replaced_by → [[GitLab]]
|
||||
|
||||
35
wiki/entities/GitLab.md
Normal file
35
wiki/entities/GitLab.md
Normal file
@@ -0,0 +1,35 @@
|
||||
---
|
||||
title: "GitLab"
|
||||
type: entity
|
||||
tags:
|
||||
- DevOps
|
||||
- CI/CD
|
||||
- Git
|
||||
date-added: 2026-04-19
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- GitLab CE
|
||||
- GitLab EE
|
||||
- GitLab.com
|
||||
|
||||
## Description
|
||||
GitLab 是代码托管和 DevOps 平台,提供 Git 仓库管理、CI/CD 流水线、代码审查、项目管理等功能。在 OpenText 迁移计划中,GitLab 将作为集中式源代码控制系统,取代即将到期的 GitHub Enterprise。
|
||||
|
||||
## Role in Migration
|
||||
- 作为 Project Thor 的一部分,GitLab 将成为 OpenText 的集中式源代码控制平台
|
||||
- GitLab 许可证覆盖最多 8500 名用户
|
||||
- 权限通过 PHT(Product Hub platform)进行自服务管理
|
||||
- 支持两种迁移方式:mirroring(同步)和 shift and lift(复制代码并转换管道)
|
||||
- GitLab proxy 位于 Brook Park,可通过 SD1 访问
|
||||
|
||||
## Related Entities
|
||||
- [[GitHub]] — 被迁移的源代码平台
|
||||
- [[OpenText]] — 主办 Public Cloud Learning Sessions 的公司
|
||||
- [[Build-Hub]] — 管理 GitLab 等中央工具的团队
|
||||
- [[Project-Thor]] — 整合 Micro Focus 和 OpenText 工具的项目
|
||||
|
||||
## Connections
|
||||
- [[GitHub]] → replaced_by → [[GitLab]]
|
||||
- [[OpenText]] ← uses ← [[GitLab]]
|
||||
- [[Build-Hub]] → manages → [[GitLab]]
|
||||
22
wiki/entities/Heather-Norris.md
Normal file
22
wiki/entities/Heather-Norris.md
Normal file
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: heather-norris
|
||||
title: "Heather Norris"
|
||||
type: entity
|
||||
tags: [Person, Cloud-Transformation]
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Summary
|
||||
Heather Norris 是云转型计划(Cloud Transformation Program, CTP)的项目经理,负责介绍敏捷原则和方法论在云转型项目中的应用实践。
|
||||
|
||||
## Roles
|
||||
- [[Cloud-Transformation-Program]] 项目经理
|
||||
|
||||
## Occurrences
|
||||
- [[CTP Topic 4 Using Agile to run the Cloud Transformation Program]] — 演讲者,分享敏捷实践经验
|
||||
|
||||
## Aliases
|
||||
- Heather
|
||||
|
||||
## References
|
||||
> "The big problem with Scrum, in my opinion, is that you can't make changes throughout the sprints, we are not advised to." — Heather Norris
|
||||
26
wiki/entities/Martin-Nash.md
Normal file
26
wiki/entities/Martin-Nash.md
Normal file
@@ -0,0 +1,26 @@
|
||||
---
|
||||
id: martin-nash
|
||||
title: "Martin Nash"
|
||||
type: entity
|
||||
tags:
|
||||
- OpenText
|
||||
- Technical-Architecture
|
||||
- CTP
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Martin Nash
|
||||
|
||||
## Role
|
||||
技术架构经理(Technical Architecture Manager),在 OpenText 云转型计划(CTP)中负责技术架构团队的职能介绍和战略规划。
|
||||
|
||||
## Contributions
|
||||
- 介绍技术架构团队的核心职能、组织架构及其在公司云转型进程中的价值
|
||||
- 阐述从"被动响应转向主动规划"的转变,通过"技术领域(Technical Domains)"划分实现12-24个月前瞻性路线图
|
||||
|
||||
## Related Links
|
||||
- [[ctp-topic-23-introduction-to-the-technical-architecture-team-and-function]]
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-19*
|
||||
15
wiki/entities/Martin-Rosler.md
Normal file
15
wiki/entities/Martin-Rosler.md
Normal file
@@ -0,0 +1,15 @@
|
||||
---
|
||||
title: "Martin Rosler"
|
||||
type: entity
|
||||
tags: []
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Martin R.
|
||||
|
||||
## Description
|
||||
OpenText 公司的技术专家,在 Public Cloud Learning Sessions 中分享了 OpenText Tagging Standard V2。
|
||||
|
||||
## Role
|
||||
- 演讲者:介绍 OpenText Tagging Standard V2
|
||||
13
wiki/entities/Matthew-Chapman.md
Normal file
13
wiki/entities/Matthew-Chapman.md
Normal file
@@ -0,0 +1,13 @@
|
||||
# Matthew Chapman
|
||||
|
||||
Matthew Chapman 是 OpenText 云转型计划(CTP)的需求评审会议主持人。
|
||||
|
||||
## 角色
|
||||
|
||||
- 需求评审会议主持人
|
||||
- 参与需求评估、价值判断和优先级排序
|
||||
|
||||
## 相关职责
|
||||
|
||||
- 主持每周双次需求评审会议
|
||||
- 评估需求的理解度、价值和优先级
|
||||
22
wiki/entities/Micro-Focus.md
Normal file
22
wiki/entities/Micro-Focus.md
Normal file
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: micro-focus
|
||||
title: "Micro Focus"
|
||||
type: entity
|
||||
tags: [Company, Enterprise-Software]
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Summary
|
||||
Micro Focus 是一家企业软件公司,提供 SRE(站点可靠性工程)实践,其 SRE 团队负责人 Brendan Standing 在 OpenText Cloud Learning Sessions 中分享 NFR 和 Error Budget 主题。
|
||||
|
||||
## Products & Services
|
||||
- 企业软件解决方案
|
||||
- SRE 团队实践
|
||||
|
||||
## Occurrences
|
||||
- [[CTP Topic 41 NFR's and Error Budgets]] — SRE 负责人 Brendan Standing 担任演讲者
|
||||
- [[CTP Topic 53 Why bother with Cloud]] — 云转型计划进展,成本优化与创新价值分析
|
||||
- [[Brendan Standing]] — Micro Focus SRE 负责人
|
||||
|
||||
## References
|
||||
- 视频来源:NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 41_ NFR's and Error Budgets.mp4`
|
||||
22
wiki/entities/OpenText.md
Normal file
22
wiki/entities/OpenText.md
Normal file
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: "OpenText"
|
||||
type: entity
|
||||
tags: [company, enterprise-software]
|
||||
---
|
||||
|
||||
## Summary
|
||||
OpenText 是全球领先的企业内容管理(Enterprise Information Management, EIM)软件公司,专注于帮助企业管理和利用非结构化数据。
|
||||
|
||||
## Key Products
|
||||
- OpenText Content Suite:企业内容管理平台
|
||||
- OpenText Process Suite:业务流程管理
|
||||
- OpenText Analytics:数据分析
|
||||
- OpenText Cloud:面向企业的云服务
|
||||
|
||||
## Key Capabilities
|
||||
- 非结构化数据管理
|
||||
- 企业内容管理
|
||||
- 业务流程自动化
|
||||
|
||||
## Connections
|
||||
- 与 AWS、GCP、Azure 等公有云合作提供云端解决方案
|
||||
26
wiki/entities/PCG-Team.md
Normal file
26
wiki/entities/PCG-Team.md
Normal file
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: "PCG Team"
|
||||
type: entity
|
||||
tags:
|
||||
- CTP
|
||||
- Platform
|
||||
- Support
|
||||
date: 2026-04-19
|
||||
---
|
||||
|
||||
## Summary
|
||||
- 全称:Platform Control Group(平台控制组)
|
||||
- 角色:云转型计划核心技术团队
|
||||
- 职责:提供云环境支持、安全策略制定、协助产品组进行 POC
|
||||
|
||||
## Aliases
|
||||
- Platform Control Group
|
||||
- PCG
|
||||
|
||||
## Connections
|
||||
- [[Gruntwork-Landing-Zone]] — 提供环境支持
|
||||
- [[CTP-Topic-20-Program-demand-process-flow-and-PoC-onboarding]]
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-19*
|
||||
27
wiki/entities/Palo-Alto-Networks.md
Normal file
27
wiki/entities/Palo-Alto-Networks.md
Normal file
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: "Palo Alto Networks"
|
||||
type: entity
|
||||
tags:
|
||||
- company
|
||||
- security
|
||||
- networking
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Palo Alto
|
||||
- Palo Alto Networks
|
||||
|
||||
## Description
|
||||
Palo Alto Networks 是全球领先的网络安全公司,提供下一代防火墙、云端安全、SASE(Secure Access Service Edge)等解决方案。Prisma Access 是其 SASE 产品,用于替代传统 VPN。
|
||||
|
||||
## Products
|
||||
- Prisma Access:SASE 安全访问服务
|
||||
- Prisma Cloud:云安全平台
|
||||
- VM-Series:虚拟下一代防火墙
|
||||
|
||||
## Sources
|
||||
- [[ctp-topic-18-wide-area-networking-in-aws-cloud]]
|
||||
|
||||
## Related Concepts
|
||||
- [[SASE]]
|
||||
- [[Prisma Access]]
|
||||
12
wiki/entities/Phenops.md
Normal file
12
wiki/entities/Phenops.md
Normal file
@@ -0,0 +1,12 @@
|
||||
---
|
||||
title: "Phenops"
|
||||
type: entity
|
||||
tags: []
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Description
|
||||
OpenText 的一个团队,于 2023 年发起标签标准化工作(Tagging Standard)。
|
||||
|
||||
## Role
|
||||
- 发起者:2023 年启动 OpenText Tagging Standard
|
||||
11
wiki/entities/Rajiv.md
Normal file
11
wiki/entities/Rajiv.md
Normal file
@@ -0,0 +1,11 @@
|
||||
---
|
||||
title: Rajiv
|
||||
type: entity
|
||||
tags:
|
||||
- CTP Presenter
|
||||
- SendGrid
|
||||
---
|
||||
|
||||
## Role
|
||||
|
||||
- CTP SendGrid 主题演讲人
|
||||
11
wiki/entities/Rejoy-Ganapati.md
Normal file
11
wiki/entities/Rejoy-Ganapati.md
Normal file
@@ -0,0 +1,11 @@
|
||||
---
|
||||
title: Rejoy Ganapati
|
||||
type: entity
|
||||
tags:
|
||||
- CTP Presenter
|
||||
- SendGrid
|
||||
---
|
||||
|
||||
## Role
|
||||
|
||||
- CTP SendGrid 主题演讲人
|
||||
@@ -18,4 +18,7 @@ SMACKS 是 Gruntwork Landing Zones 中的内部服务管理工单系统,用于
|
||||
- 生产环境变更请求
|
||||
|
||||
## Related
|
||||
- [[intsas-local]] ← 用于生产环境
|
||||
- [[intsas-local]] ← 用于生产环境
|
||||
|
||||
## Aliases
|
||||
- SMACs (Service Management Automation X):当前的 ITSM 工具名称
|
||||
44
wiki/entities/SendGrid.md
Normal file
44
wiki/entities/SendGrid.md
Normal file
@@ -0,0 +1,44 @@
|
||||
---
|
||||
title: SendGrid
|
||||
type: entity
|
||||
tags:
|
||||
- Email Service
|
||||
- Twilio
|
||||
- Cloud Transformation
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- SendGrid
|
||||
- Twilio SendGrid
|
||||
|
||||
## Description
|
||||
|
||||
SendGrid 是 Twilio 旗下的企业级邮件服务,已被 Cloud Transformation Program (CTP) 采用为标准邮件服务,用于替换现有的语义网关和 Amazon SES 方案。
|
||||
|
||||
## Role
|
||||
|
||||
- 被 CTP 采用为经典和新型 Landing Zones 的标准邮件服务
|
||||
|
||||
## Key Specifications
|
||||
|
||||
- 支持每邮件最多 1000 个收件人(相比 SES 的 50 个限制)
|
||||
- 每月支持 500 万封邮件的套餐
|
||||
- 支持实时监控日志
|
||||
- 支持双因素认证
|
||||
- 支持端到端 TLS 加密
|
||||
- 日志保留 7 天
|
||||
- API 密钥每 180 天轮换
|
||||
|
||||
## Architecture
|
||||
|
||||
两种架构模式:
|
||||
1. **直接发送**:通过 TLS 直接发送到 SendGrid(需使用 software.microcopy.com 域)
|
||||
2. **中继发送**:通过中继服务器发送(适用于不支持 TLS 的应用)
|
||||
|
||||
## Data Flow
|
||||
|
||||
中继服务器位于多个位置(伦敦、印度、东京等),通过专线将邮件发送至美国数据中心处理。
|
||||
|
||||
## References
|
||||
|
||||
- [[CTP Topic 36 SendGrid as an email service]]
|
||||
21
wiki/entities/Sergio.md
Normal file
21
wiki/entities/Sergio.md
Normal file
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: "Sergio"
|
||||
type: entity
|
||||
tags:
|
||||
- CTP
|
||||
- Expert
|
||||
date: 2026-04-19
|
||||
---
|
||||
|
||||
## Summary
|
||||
- 角色:云转型计划(CTP)专家
|
||||
- 职责:主讲程序需求流程与 POC 入站流程相关课程
|
||||
- 关联:与 Damian 共同负责 CTP Topic 20 的讲解
|
||||
|
||||
## Connections
|
||||
- [[Damian]] — 共同主讲人
|
||||
- [[CTP-Topic-20-Program-demand-process-flow-and-PoC-onboarding]]
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-19*
|
||||
26
wiki/entities/Silver-Peak.md
Normal file
26
wiki/entities/Silver-Peak.md
Normal file
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: "Silver Peak"
|
||||
type: entity
|
||||
tags:
|
||||
- company
|
||||
- networking
|
||||
- sd-wan
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Silver Peak
|
||||
|
||||
## Description
|
||||
Silver Peak 是一家专注于 WAN 边缘网络和 SD-WAN 解决方案的公司,后被 Aruba Networks( HPE )收购。其 SD-WAN 产品被企业广泛用于替代传统 MPLS 专线,实现网络连接的自动化和优化。
|
||||
|
||||
## Products
|
||||
- Silver Peak EdgeConnect:SD-WAN 边缘设备
|
||||
- Silver Peak Unity:网络产品组合
|
||||
|
||||
## Related Concepts
|
||||
- [[SD-WAN]]
|
||||
- [[Overlay Network]]
|
||||
|
||||
## Sources
|
||||
- [[ctp-topic-18-wide-area-networking-in-aws-cloud]]
|
||||
- [[ctp-topic-46-netapps-on-aws]]
|
||||
29
wiki/entities/Tom-Bice.md
Normal file
29
wiki/entities/Tom-Bice.md
Normal file
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: "Tom Bice"
|
||||
type: entity
|
||||
tags:
|
||||
- OpenText
|
||||
- FinOps
|
||||
- Tagging-Standard
|
||||
aliases:
|
||||
- Tom Bice
|
||||
---
|
||||
|
||||
## Profile
|
||||
|
||||
Tom Bice 是 OpenText 财务组织的负责人,负责推动跨云服务商的标签标准统一工作。
|
||||
|
||||
## Role
|
||||
|
||||
- 发起并领导 OpenText 标签标准制定
|
||||
- 推动 FinOps 实践落地
|
||||
- 协调业务报表需求与资源标签的对接
|
||||
|
||||
## Notes
|
||||
|
||||
在 2024 年 1 月 23 日的 Public Cloud Learning Sessions 中,Tom Bice 介绍了统一标签标准的愿景,目标是在未来三年内优化约 5 亿美元的云支出。
|
||||
|
||||
## Connections
|
||||
|
||||
- [[Tagging-Methodology]] ← leads
|
||||
- [[FinOps]] ← drives
|
||||
18
wiki/entities/VMware-Cloud-on-AWS.md
Normal file
18
wiki/entities/VMware-Cloud-on-AWS.md
Normal file
@@ -0,0 +1,18 @@
|
||||
---
|
||||
title: "VMware Cloud on AWS"
|
||||
type: entity
|
||||
tags: [VMware, AWS, Cloud]
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- VMC on AWS
|
||||
|
||||
## Description
|
||||
VMware 和 AWS 联合云服务,在 AWS 硬件上原生运行 vSphere 8,提供 vSphere、connectivity 和 firewalls。
|
||||
|
||||
## Type
|
||||
- 产品/服务
|
||||
|
||||
## Related Concepts
|
||||
- [[VMware-Cloud-on-AWS]] ← runs_on ← [[AWS]]
|
||||
- [[HCX]] ← manages ← [[SDDC]]
|
||||
31
wiki/entities/VPC.md
Normal file
31
wiki/entities/VPC.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
title: "VPC (Virtual Private Cloud)"
|
||||
type: entity
|
||||
tags: [AWS, Networking]
|
||||
aliases: [Virtual Private Cloud]
|
||||
---
|
||||
|
||||
## Definition
|
||||
VPC(Virtual Private Cloud,虚拟私有云)是 AWS 提供的逻辑隔离的虚拟网络环境,允许用户在 AWS 云中预置逻辑隔离的网络段。
|
||||
|
||||
## Core Features
|
||||
- 可自定义 IP 地址范围(CIDR 块)
|
||||
- 可划分多个子网(Subnet)
|
||||
- 可配置路由表和网关
|
||||
- 可关联安全组和网络 ACL
|
||||
- 支持跨可用区部署
|
||||
|
||||
## Common Use Cases
|
||||
- 在 AWS 中运行 Web 应用
|
||||
- 部署数据库集群
|
||||
- 创建混合云架构
|
||||
- 隔离不同环境的资源
|
||||
|
||||
## Related Concepts
|
||||
- [[Subnet]]:VPC 内的子网
|
||||
- [[CIDR]]:IP 地址范围表示法
|
||||
- [[IPAM]]:IP 地址管理工具
|
||||
|
||||
## Related Entities
|
||||
- [[AWS]]:提供 VPC 服务的云平台
|
||||
- [[Infoblox]]:提供 IPAM 集成解决方案
|
||||
@@ -41,6 +41,8 @@
|
||||
|
||||
- [CTP Topic 34 Azure Landing Zone Architecture Overview](sources/ctp-topic-34-azure-landing-zone-architecture-overview.md) — Azure Landing Zone 架构设计,Management Groups、Subscription 分离、Terraform Cloud 自动化
|
||||
|
||||
- [CTP Topic 36 SendGrid as an email service](sources/ctp-topic-36-sendgrid-as-an-email-service.md) — SendGrid 被采用为 CTP 标准邮件服务,替换不安全的语义网关和受限的 SES 方案
|
||||
|
||||
- [CTP Topic 46 NetApps on AWS](sources/ctp-topic-46-netapps-on-aws.md) — NetApp on AWS (CVO) 架构、部署、数据分层、安全与迁移
|
||||
|
||||
- [CTP Topic 58 AWS EC2 Image Builder](sources/ctp-topic-58-aws-ec2-image-builder.md) — AWS EC2 Image Builder 服务,用于自动创建、管理和分发 AMIs 和 Docker 镜像
|
||||
@@ -260,18 +262,34 @@
|
||||
|
||||
- [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 的真实经验分享
|
||||
|
||||
- [CTP Topic 4 Using Agile to run the Cloud Transformation Program](sources/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md) — 云转型计划中的敏捷实践应用,从 Scrum 过渡到 Kanban 的混合模式
|
||||
|
||||
- [CTP Topic 28 AWS Tag Validation Tool](sources/ctp-topic-28-aws-tag-validation-tool.md) — AWS 标签验证工具,用于审计资源标签合规性
|
||||
|
||||
- [CTP Topic 30 Managing Change](sources/ctp-topic-30-managing-change.md) — 云转型项目中的变更管理流程,SRE 角色和三种变更类型
|
||||
|
||||
- [CTP Topic 22 Global DNS service offerings](sources/ctp-topic-22-global-dns-service-offerings.md) — AWS 云 DNS 服务架构与混合云 DNS 设计方案
|
||||
|
||||
- [CTP Topic 23 Introduction to the Technical Architecture team and function](sources/ctp-topic-23-introduction-to-the-technical-architecture-team-and-function.md) — 技术架构团队职能、组织架构及云转型价值
|
||||
|
||||
- [CTP Topic 18 Wide Area Networking in AWS Cloud](sources/ctp-topic-18-wide-area-networking-in-aws-cloud.md) — AWS 云广域网架构设计,Transit Gateway、SD-WAN、Prisma Access SASE
|
||||
|
||||
- [CTP Topic 19 Configuring DNS within AWS LZs](sources/ctp-topic-19-configuring-dns-within-aws-lzs.md) — AWS Landing Zone 多账号环境下 DNS 集中化管理
|
||||
|
||||
- [CTP Topic 20 Program demand process flow and PoC onboarding](sources/ctp-topic-20-program-demand-process-flow-and-poc-onboarding.md) — CTP 程序需求流程与 POC 入站流程,Gate 审批机制
|
||||
|
||||
- [CTP Topic 66 Exposing the differences between PostgreSQL RDS and Aurora](sources/ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora.md) — PostgreSQL on RDS 与 Aurora 的详细对比(架构、性能、成本、故障切换)
|
||||
|
||||
- [CTP Topic 72 Implementing an Enterprise DR Strategy using AWS Backup](sources/ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup.md) — 使用 AWS Backup 实现企业级灾难恢复策略
|
||||
|
||||
- [CTP Topic 73 AWS Backup implementation of the Cloud Transformation Program](sources/ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program.md) — AWS Backup 在 CTP 云转型计划中的实施
|
||||
|
||||
- [CTP Topic 65 Tracing the value delivered in Cloud Transformation](sources/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md) — CTP 工作中的价值交付量化与优先级排序方法
|
||||
|
||||
- [CTP Topic 68 Introduction to Redshift](sources/ctp-topic-68-introduction-to-redshift.md) — AWS Redshift 数据仓库架构与核心组件(MPP、列式存储、Leader Node、Compute Node)
|
||||
|
||||
- [CTP Topic 69 Best Practices for Migrating On-Premises (IOD) Virtual Machines to VMware Cloud on AWS](sources/ctp-topic-69-best-practices-for-migrating-on-premises-iod-virtual-machines-to-vm.md) — 将本地虚拟机迁移到 VMware Cloud on AWS 的最佳实践(HCX、Direct Connect、CCOE)
|
||||
|
||||
- [CTP Topic 17 Active Directory Services in Gruntwork AWS LZs](sources/ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs.md) — 在 Gruntwork AWS Landing Zones 中集成 Active Directory 服务实践
|
||||
|
||||
- [CTP Topic 25 Labs Landing Zone overview - ITOM teams](sources/ctp-topic-25-labs-landing-zone-overview-itom-teams.md) — Labs Landing Zone 架构概述,基于 Gruntwork reference architecture
|
||||
@@ -280,22 +298,54 @@
|
||||
|
||||
- [CTP Topic 47 Enterprise Architecture Cloud Standards](sources/ctp-topic-47-enterprise-architecture-cloud-standards.md) — 企业云架构标准、Landing Zone 框架与 Cloud Guardrails
|
||||
|
||||
- [CTP Topic 45 Automatic IP address allocation with IPAM](sources/ctp-topic-45-automatic-ip-address-allocation-with-ipam.md) — 使用 Infoblox NIOS 实现 VPC IP 地址自动化分配
|
||||
|
||||
- [CTP Topic 61 Workload VPC provision with IPAM Automation](sources/ctp-topic-61-workload-vpc-provision-with-ipam-automation.md) — IPAM 与 Workload VPC 自动化 provisioning,YAML 配置、审批流程
|
||||
|
||||
- [CTP Topic 43 VMware Cloud on AWS](sources/ctp-topic-43-vmware-cloud-on-aws.md) — VMware 和 AWS 联合云服务,在 AWS 硬件上原生运行 vSphere 8
|
||||
|
||||
- [CTP Topic 41 NFR's and Error Budgets](sources/ctp-topic-41-nfrs-and-error-budgets.md) — NFR(非功能需求)与 Error Budget(错误预算)在云和敏捷开发中的应用,SRE 实践
|
||||
|
||||
- [CTP Topic 53 Why bother with Cloud](sources/ctp-topic-53-why-bother-with-cloud.md) — Micro Focus 云转型计划进展与价值分析,成本优化与创新机会
|
||||
|
||||
- [CTP Topic 57 Product backlog managing demand](sources/ctp-topic-57-product-backlog-managing-demand.md) — Product Backlog 管理需求流程,SMACs 提交、Octane 入池、前置条件阶段
|
||||
|
||||
## Sources
|
||||
- [CTP Topic 31 Network Segregation and Secure Access to AWS Landing Zones](sources/ctp-topic-31-network-segregation-secure-access-aws-landing-zones.md) — AWS Landing Zone 网络隔离与安全访问解决方案
|
||||
|
||||
- [CTP Topic 40 SaaS Database Architecture On AWS Cloud](sources/ctp-topic-40-saas-database-architecture-on-aws-cloud.md) — AWS 云上 SaaS 数据库架构,SaaS 数据库团队全球运维实践
|
||||
|
||||
- [Learning Sessions Standard AMIs Updates 20231205](sources/learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2.md) — AWS Standard AMIs 概述、更新和发布流程(每两个月发布、支持 23 种操作系统)
|
||||
|
||||
- [Public Cloud Learning Sessions (OpenText) - GitHub Enterprise to GitLab migration](sources/public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20.md) — OpenText 将代码仓库从 GitHub Enterprise 迁移到 GitLab,self-serve 模式
|
||||
|
||||
- [Public Cloud Learning Sessions (OpenText) - Thor Platform & Flows](sources/public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet.md) — Project Thor 平台架构与供应链数据流介绍
|
||||
|
||||
- [Public Cloud Learning Sessions (OpenText) - Evolving from DR to Recovery Assurance](sources/public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2.md) — DR 向 Recovery Assurance 演进,SRE 和可观测性工程实践
|
||||
|
||||
- [Public Cloud Learning Sessions - OpenText Tagging Standard V2](sources/public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meet.md) — OpenText 标签标准 V2,涵盖云资源、Kubernetes 对象和容器镜像的标签规范
|
||||
|
||||
- [Public Cloud Learning Sessions - Tagging Standards for all hyperscalers](sources/public-cloud-learning-sessions-tagging-standards-for-all-hyperscalers-20240123-1.md) — 2024 年 1 月 OpenText 标签标准 V1,建立跨 AWS、GCP、Azure 统一标签体系
|
||||
|
||||
- [CTP Topic 1 Gruntwork Landing Zone Architecture](sources/ctp-topic-1-gruntwork-landing-zone-architecture.md) — 基于 Gruntwork 的 AWS Landing Zone 架构设计
|
||||
- [CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security](sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md) — AWS Landing Zone 部署流程、数据收集策略、基于标签的安全控制机制
|
||||
- [CTP Topic 35 AWS Landing Zone Design Refresher (SaaS Labs)](sources/ctp-topic-35-aws-landing-zone-design-refresher-saas-labs.md) — AWS Landing Zone 设计更新,SaaS(生产)与 Labs(开发)环境区分
|
||||
|
||||
- [CTP Topic 7 SaaS Landing Zone Design](sources/ctp-topic-7-saas-landing-zone-design.md) — 生产环境 SaaS Landing Zone 高级设计,单一 Landing Zone 策略
|
||||
|
||||
- [CTP Topic 6 AWS Workspaces Demo](sources/ctp-topic-6-aws-workspaces-demo.md) — AWS Workspaces 远程桌面演示,预装 PF SSO、Terraform、TerraGrunt、Git、VS Code 等开发工具
|
||||
|
||||
## Entities
|
||||
- [CCOE](entities/CCOE.md) — Cloud Center of Excellence,推动云采纳和治理的核心组织单元
|
||||
- [CrowdStrike](entities/CrowdStrike.md) — 网络安全公司,2024年7月事件推动行业对DR的重视
|
||||
- [Martin Rosler](entities/Martin-Rosler.md) — OpenText 技术专家,OpenText Tagging Standard V2 演讲者
|
||||
- [Phenops](entities/Phenops.md) — OpenText 团队,2023 年发起标签标准化工作
|
||||
- [OpenText](entities/OpenText.md) — 企业内容管理软件公司,主办 Public Cloud Learning Sessions
|
||||
- [Arnold Dacan](entities/Arnold-Dacan.md) — OpenText 技术专家,Project Thor 演讲者
|
||||
- [Kishore Garlopati](entities/Kishore-Garlopati.md) — Azure Landing Zone 技术分享主讲人
|
||||
- [Pradeep](entities/Pradeep.md) — AWS Landing Zone 技术分享主讲人,Checkpoint 防火墙专家
|
||||
- [Holger Rode](entities/Holger-Rode.md) — Octane Hub CTO 软件工厂团队负责人
|
||||
- [Heather Norris](entities/Heather-Norris.md) — 云转型计划(CTP)项目经理,敏捷实践演讲者
|
||||
- [Femi George](entities/Femi-George.md) — AWS 数据库销售专家,CTP Topic 51 主讲人
|
||||
- [Duolingo](entities/Duolingo.md) — 案例公司,使用 DynamoDB + ElastiCache + Aurora
|
||||
- [Netflix](entities/Netflix.md) — 案例公司,使用 DynamoDB 存储 JSON 文档
|
||||
@@ -354,6 +404,7 @@
|
||||
- [EventBridge](entities/EventBridge.md) — AWS 无服务器事件总线服务
|
||||
- [CloudWatch](entities/CloudWatch.md) — AWS 监控和可观测性服务
|
||||
- [AWS Organizations](entities/AWS-Organizations.md) — AWS 账户管理服务
|
||||
- [AWS RAM](entities/AWS-RAM.md) — AWS 资源共享管理器,用于跨账号共享资源
|
||||
- [KMS](entities/KMS.md) — AWS 密钥管理服务
|
||||
- [AIOps](entities/AIOps.md) — AI 运维平台,利用 AI/ML 技术实现运维自动化
|
||||
- [AI SRE](entities/AI-SRE.md) — 使用 AI 自动化站点可靠性工程任务的工具
|
||||
@@ -372,6 +423,8 @@
|
||||
- [Clonezilla](entities/Clonezilla.md) — 开源磁盘镜像备份工具
|
||||
- [Netgear](entities/Netgear.md) — 路由器和网络设备制造商
|
||||
- [RAX50](entities/RAX50.md) — 网件 AX4200 WiFi 6 路由器型号
|
||||
- [SendGrid](entities/SendGrid.md) — Twilio 旗下的企业级邮件服务,CTP 标准邮件方案
|
||||
|
||||
- [KoolCenter](entities/KoolCenter.md) — 梅林固件官方下载服务器
|
||||
- [MerlinClash](entities/MerlinClash.md) — 基于 Clash 的梅林固件科学上网插件
|
||||
- [Transmission](entities/Transmission.md) — 开源 BT 下载客户端
|
||||
@@ -499,7 +552,19 @@
|
||||
- [Axton](entities/Axton.md) — 回到Axton 博主,obsidian-canvas-creator 等视觉类 Skills 作者
|
||||
- [Choi Wontak](entities/Choi-Wontak.md) — tutor-skills 作者
|
||||
|
||||
- [VMware-Cloud-on-AWS](entities/VMware-Cloud-on-AWS.md) — VMware 和 AWS 联合云服务,在 AWS 硬件上原生运行 vSphere 8
|
||||
|
||||
## Entities
|
||||
- [Tom Bice](entities/Tom-Bice.md) — OpenText 财务组织负责人,标签标准制定发起人
|
||||
- [Martin Nash](entities/Martin-Nash.md) — OpenText 技术架构经理,CTP Topic 23 主讲人
|
||||
- [Matthew Chapman](entities/Matthew-Chapman.md) — OpenText CTP 需求评审会议主持人
|
||||
|
||||
## Concepts
|
||||
- [Product-Backlog](concepts/Product-Backlog.md) — 产品待办列表,存放待开发功能和需求,高亮收益和优先级
|
||||
- [SMACs](concepts/SMACs.md) — 需求提交的标准化入口,用于启动计时器和确保需求追踪
|
||||
- [Cyber Suite](concepts/Cyber-Suite.md) — PSAC 发布的产品安全加密标准,包括标准/可选套件和审查要求
|
||||
- [Observability Engineering](concepts/Observability-Engineering.md) — 可观测性工程,通过指标、日志、追踪持续理解系统健康状态
|
||||
- [Recovery Assurance](concepts/Recovery-Assurance.md) — 恢复保障,从设计层面确保系统具备恢复能力
|
||||
- [Service Control Policies](concepts/Service-Control-Policies.md) — AWS Organizations 的策略类型,管理组织内账户的最大权限边界
|
||||
- [Management Groups](concepts/Management-Groups.md) — Azure 组织管理结构,用于组织和管理多个订阅的分层容器
|
||||
- [Subscription](concepts/Subscription.md) — Azure 资源隔离的基本容器,每个订阅有独立的配额和访问控制
|
||||
@@ -622,6 +687,7 @@
|
||||
- [Infrastructure as Code (IaC)](concepts/Infrastructure-as-Code-IaC.md) — 通过代码实现一致性、版本控制的基础设施管理
|
||||
- [敏捷实践](concepts/敏捷实践.md) — Scrum、Kanban 等迭代开发方法论
|
||||
- [DevSecOps](concepts/DevSecOps.md) — 在 CI/CD 流水线中深度集成安全工具的文化理念
|
||||
- [HCX](concepts/HCX.md) — Hybrid Cloud Extender,VMware 混合云扩展工具
|
||||
- [GitOps](concepts/GitOps.md) — 使用 Git 作为单一真相源来管理基础设施和部署
|
||||
- [持续改进 (Kaizen)](concepts/持续改进.md) — 通过迭代学习不断优化流程的文化实践
|
||||
- [混沌工程](concepts/混沌工程.md) — 主动测试系统韧性的实践方法
|
||||
@@ -751,6 +817,10 @@
|
||||
- [道法自然](concepts/道法自然.md) — 道家核心思想,万物依自然规律运行
|
||||
- [缘起性空](concepts/缘起性空.md) — 佛教核心概念,一切现象依赖条件存在,无独立自性
|
||||
- [大智若愚](concepts/大智若愚.md) — 藏锋守拙的生存哲学,真正的智慧看似愚钝
|
||||
- [Self-Serve Migration](concepts/Self-Serve-Migration.md) — 自服务迁移模式,各团队自行规划和执行迁移
|
||||
- [GitHub-Enterprise to GitLab Migration](concepts/GitHub-Enterprise-to-GitLab-Migration.md) — OpenText 将代码仓库从 GitHub Enterprise 迁移到 GitLab
|
||||
- [Project Thor](concepts/Project-Thor.md) — OpenText 云平台标准化项目,五大支柱框架
|
||||
|
||||
- [和光同尘](concepts/和光同尘.md) — 收敛光芒,混同尘俗,不标新立异以保全自身
|
||||
- [无常](concepts/无常.md) — 佛教核心概念,世间万物不断变化、无永恒不变
|
||||
- [安之若命](concepts/安之若命.md) — 尽人事后坦然接受无法改变的结果
|
||||
@@ -774,5 +844,10 @@
|
||||
- [场景共情能力](concepts/场景共情能力.md) — 站在使用场景和受众角度,定义输出的标准与风格的能力
|
||||
- [迭代优化能力](concepts/迭代优化能力.md) — 通过测试反馈持续调整指令,逼近最优结果的能力
|
||||
|
||||
- [Technical-Domains](concepts/Technical-Domains.md) — 将公司技术栈划分为特定领域,每个领域由首席架构师负责生命周期与路线图
|
||||
- [Technical Architecture (TA)](concepts/Technical-Architecture-TA.md) — 最贴近技术的架构层,负责底层技术实施与基础设施治理
|
||||
- [Enterprise Architecture (EA)](concepts/Enterprise-Architecture-EA.md) — 架构体系高层,负责将业务目标转化为技术原则和标准
|
||||
- [Solution Architecture (SA)](concepts/Solution-Architecture-SA.md) — 架构体系中间层,专注特定项目或服务的优化实施
|
||||
|
||||
## Syntheses
|
||||
- (暂无)
|
||||
|
||||
197
wiki/log.md
197
wiki/log.md
@@ -1,3 +1,200 @@
|
||||
## [2026-04-19] ingest | Public Cloud Learning Sessions - Tagging Standards for all hyperscalers (20240123)
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-tagging-standards-for-all-hyperscalers-20240123-1.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: OpenText 标签标准 V1,建立跨 AWS、GCP、Azure 统一标签体系,目标是将云浪费从 30% 降至 15%,预计年省 2500 万美元
|
||||
- Concepts created: Tagging Methodology, FinOps, Service Control Policies
|
||||
- Entities created: Tom Bice
|
||||
- Source page: wiki/sources/public-cloud-learning-sessions-tagging-standards-for-all-hyperscalers-20240123-1.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-19] ingest | CTP Topic 23 Introduction to the Technical Architecture team and function
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-23-introduction-to-the-technical-architecture-team-and-function.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: 技术架构团队职能、组织架构及云转型价值,三种架构职能分工(EA/SA/TA),从被动响应转向主动规划
|
||||
- Concepts created: Technical Domains, Technical Architecture (TA), Enterprise Architecture (EA), Solution Architecture (SA)
|
||||
- Entities created: Martin Nash
|
||||
- Source page: wiki/sources/ctp-topic-23-introduction-to-the-technical-architecture-team-and-function.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-19] ingest | CTP Topic 53 Why bother with Cloud
|
||||
## [2026-04-19] ingest | Public Cloud Learning Sessions (OpenText) - Thor Platform & Flows
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: Project Thor 平台架构与供应链数据流,五大支柱框架:敏捷周期管理、产品发布治理、Developer Portal、Security Governance、Build Hub
|
||||
- Concepts created: Project Thor, GitLab, Artifactory, Source Code Supply Chain, GitLab Proxy, GitLab Geo, Code Signing, Developer Portal, Build Hub, Supply Chain Security
|
||||
- Entities created: Arnold Dacan
|
||||
- Source page: wiki/sources/public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-19] ingest | CTP Topic 53 Why bother with Cloud
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-53-why-bother-with-cloud.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: Micro Focus 云转型计划进展与价值分析,成本优化与创新机会,14数据中心近2万资产,成本reduction成果
|
||||
- Concepts created: Landing Zone, Cloud Transformation Program, FinOps, CCOE
|
||||
- Entities created: CTP(已更新), Micro Focus(已更新)
|
||||
- Source page: wiki/sources/ctp-topic-53-why-bother-with-cloud.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-19] ingest | Public Cloud Learning Sessions (OpenText) - GitHub Enterprise to GitLab migration
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: OpenText 将代码仓库从 GitHub Enterprise 迁移到 GitLab,self-serve 模式,Build Hub 团队提供支持,GitHub 许可证12月底到期不再续约
|
||||
- Concepts created: Self-Serve Migration, GitHub-Enterprise to GitLab Migration
|
||||
- Entities created: GitLab, Build Hub, GitHub Enterprise
|
||||
- Source page: wiki/sources/public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-19] ingest | Public Cloud Learning Sessions - OpenText Tagging Standard V2
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meet.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: OpenText Tagging Standard V2 标签标准,涵盖云资源、Kubernetes 对象和容器镜像的标签规范,三大驱动因素:成本优化、风险降低、自动化效率提升
|
||||
- Concepts created: Tagging Methodology(已更新)
|
||||
- Entities created: Martin Rosler, Phenops
|
||||
- Source page: wiki/sources/public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meet.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-19] ingest | CTP Topic 57 Product backlog managing demand
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-57-product-backlog-managing-demand.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: Product Backlog 管理需求流程,SMACs 提交、Octane 入池、前置条件阶段,Sprint 规划 50% 新需求 + 50% 支持工单/技术债务
|
||||
- Concepts created: Product-Backlog, SMACs
|
||||
- Entities created: Matthew Chapman
|
||||
- Source page: wiki/sources/ctp-topic-57-product-backlog-managing-demand.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-19] ingest | CTP Topic 41 NFR's and Error Budgets
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-41-nfrs-and-error-budgets.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: NFR(非功能需求)与 Error Budget(错误预算)在云和敏捷开发中的应用,SRE 实践,SLI/SLO/SLA 体系
|
||||
- Concepts created: NFR, Error Budget, SLI, SLO, SLA, 混沌工程
|
||||
- Entities created: Brendan Standing, Micro Focus
|
||||
- Source page: wiki/sources/ctp-topic-41-nfrs-and-error-budgets.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-19] ingest | CTP Topic 20 Program demand process flow and PoC onboarding
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-20-program-demand-process-flow-and-poc-onboarding.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: CTP 程序需求流程与 POC 入站流程,Gate 审批机制(Gate 0/1/3),POC 是降低迁移风险的核心环节
|
||||
- Concepts created: Program Demand Process, Proof of Concept (POC), Gate Process, Solution Design
|
||||
- Entities created: Sergio, Damian, PCG Team
|
||||
- Source page: wiki/sources/ctp-topic-20-program-demand-process-flow-and-poc-onboarding.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-19] ingest | CTP Topic 4 Using Agile to run the Cloud Transformation Program
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: 云转型计划中的敏捷实践应用,从 Scrum 过渡到 Kanban,最终采用混合模式(Kanban + Scrum 仪式)
|
||||
- Concepts created: Scrum, Kanban, 每日站会, 回顾会议
|
||||
- Entities created: Heather Norris
|
||||
- Source page: wiki/sources/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-19] ingest | CTP Topic 65 Tracing the value delivered in Cloud Transformation
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: CTP 工作中的价值交付量化与优先级排序方法,通过 WSJF 方法实现经济价值最大化
|
||||
- Concepts created: WSJF
|
||||
- Entities created: OpenText
|
||||
- Source page: wiki/sources/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-19] ingest | CTP Topic 6 AWS Workspaces Demo
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-6-aws-workspaces-demo.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: AWS Workspaces 远程桌面演示,预装 PF SSO、Terraform、TerraGrunt、Git、VS Code 等开发工具,目标在申请后 30-45 分钟内运行 Terraform 计划
|
||||
- Concepts created: AWS Workspaces(新增)
|
||||
- Entities created: AWS(已存在)
|
||||
- Source page: wiki/sources/ctp-topic-6-aws-workspaces-demo.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-19] ingest | CTP Topic 30 Managing Change
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-30-managing-change.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: 云转型项目中的变更管理流程,SRE 角色定义和三种变更类型(标准变更、正常变更、紧急变更)
|
||||
- Concepts created: Change Management, CAPA, Early Live Support
|
||||
- Entities created: Brendan Starnig
|
||||
- Source page: wiki/sources/ctp-topic-30-managing-change.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-19] ingest | Public Cloud Learning Sessions (OpenText) - Evolving from DR to Recovery Assurance
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: DR 向 Recovery Assurance 演进,从被动响应转向主动式架构,通过设计、软件、构建、环境四个维度构建恢复保障能力
|
||||
- Concepts created: Recovery Assurance, Observability Engineering
|
||||
- Entities created: OpenText, CrowdStrike
|
||||
- Source page: wiki/sources/public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2.md
|
||||
- Notes:
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-69-best-practices-for-migrating-on-premises-iod-virtual-machines-to-vm.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: 将本地虚拟机迁移到 VMware Cloud on AWS 的最佳实践,通过 HCX 实现多云管理,Direct Connect 直连,CCOE 自动化迁移脚本
|
||||
- Concepts created: HCX
|
||||
- Entities created: VMware-Cloud-on-AWS
|
||||
- Source page: wiki/sources/ctp-topic-69-best-practices-for-migrating-on-premises-iod-virtual-machines-to-vm.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-19] ingest | CTP Topic 31 Network Segregation and Secure Access to AWS Landing Zones
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: AWS Landing Zone 网络隔离与安全访问解决方案,通过 Checkpoint 防火墙实现网络隔离,SSM 替代 VPN 实现安全远程访问
|
||||
- Concepts created: Network-Segregation, SPI-Features, SSM-Access, AWS-Landing-Zone, Zero-Trust-Access, Break-Glass-Access
|
||||
- Entities created: (AWS 已有), (Checkpoint 已有)
|
||||
- Source page: wiki/sources/ctp-topic-31-network-segregation-secure-access-aws-landing-zones.md
|
||||
- Notes:
|
||||
|
||||
## [2025-03-01] 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: ✅ 成功摄入
|
||||
- Summary: DevOps 成熟度五级框架(初始→局部DevOps→自动化与定义→高度优化→完全成熟),五大评估维度(文化与战略、自动化、结构与流程、协作与共享、技术),涵盖 DevSecOps 集成和关键指标
|
||||
- Concepts created: DevOps 成熟度模型(已有), CI/CD 流水线(已有), DevSecOps(已有), Infrastructure as Code (IaC)(已有), MTTR(已有), Lead Time(已有)
|
||||
- Entities created: (无)
|
||||
- Source page: wiki/sources/DevOps-Maturity-Model-From-Traditional-IT-to-Advanced-DevOps.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-19] ingest | CTP Topic 61 Workload VPC provision with IPAM Automation
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-61-workload-vpc-provision-with-ipam-automation.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: IPAM 与 Workload VPC 自动化 provisioning,通过 YAML 文件定义参数,Infoblox Grid 架构防止重叠 IP,/22 及以下 CIDR 需审批
|
||||
- Concepts created: (IPAM 已有)
|
||||
- Entities created: (VPC 已有), Infoblox(已有)
|
||||
- Source page: wiki/sources/ctp-topic-61-workload-vpc-provision-with-ipam-automation.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-19] ingest | CTP Topic 45 Automatic IP address allocation with IPAM
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-45-automatic-ip-address-allocation-with-ipam.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: 使用 Infoblox NIOS 实现 VPC IP 地址自动化分配,YAML 文件仅指定子网大小而非具体 IP,减少跨团队协作,实现单一数据源
|
||||
- Concepts created: (IPAM 已有), VPC(新增)
|
||||
- Entities created: VPC(新增), Grid Master(新增)
|
||||
- Source page: wiki/sources/ctp-topic-45-automatic-ip-address-allocation-with-ipam.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-19] ingest | CTP Topic 19 Configuring DNS within AWS LZs
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-19-configuring-dns-within-aws-lzs.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: AWS Landing Zone 多账号环境下 DNS 集中化管理,通过专用 DNS 账号统一管理 Private Hosted Zones,Route 53 Resolver Inbound/Outbound Endpoints 处理混合云 DNS 流量
|
||||
- Concepts created: VPC Association Authorization(新增)
|
||||
- Entities created: AWS RAM(新增)
|
||||
- Source page: wiki/sources/ctp-topic-19-configuring-dns-within-aws-lzs.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-19] ingest | CTP Topic 36 SendGrid as an email service
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-36-sendgrid-as-an-email-service.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: SendGrid 被采用为 CTP 标准邮件服务,替换不安全的语义网关和受限的 SES 方案,支持每邮件 1000 收件人、实时监控、双因素认证、TLS 加密
|
||||
- Concepts created: Cyber Suite(新增)
|
||||
- Entities created: SendGrid(新增), Rejoy Ganapati(新增), Rajiv(新增)
|
||||
- Source page: wiki/sources/ctp-topic-36-sendgrid-as-an-email-service.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-19] ingest | CTP Topic 18 Wide Area Networking in AWS Cloud
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-18-wide-area-networking-in-aws-cloud.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: AWS 云广域网架构设计,Transit Gateway 星型拓扑(Hub-and-Spoke),未来演进到 SD-WAN + Prisma Access SASE 架构
|
||||
- Concepts created: Hub-and-Spoke(新增), SD-WAN(新增), Overlay Network(新增)
|
||||
- Entities created: Christian Deckelman(新增), Palo Alto Networks(新增), Silver Peak(新增)
|
||||
- Source page: wiki/sources/ctp-topic-18-wide-area-networking-in-aws-cloud.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-18] ingest | CTP Topic 22 Global DNS service offerings
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-22-global-dns-service-offerings.md
|
||||
- Status: ✅ 成功摄入
|
||||
|
||||
@@ -21,9 +21,12 @@ AI 开源项目、Cloud & DevOps、Vibe Coding、AI时代个人发展、跨境
|
||||
- Gruntwork Landing Zone:Gruntwork 提供的预配置 AWS 基础架构框架,基于 Reference Architecture 包含核心账户和工作负载账户
|
||||
- CCOE(Cloud Center of Excellence):推动云采纳和治理的核心组织单元,负责 AMI 标准制定和发布
|
||||
|
||||
- AWS Workspaces:AWS 提供的托管桌面即服务(DaaS)解决方案,预装开发工具实现快速生产力
|
||||
|
||||
- Standard AMI:AWS 标准机器镜像,包含 OS 加固、最新安全补丁,并支持域集成、SSM agent、DNS 设置,每两个月发布一次
|
||||
- Cloud Guardrails:云守护栏,捕获可扩展性、成本最小化和灵活性的强制性要求和最佳实践
|
||||
- Tagging Methodology:标签方法论,通过为资源定义标准化的元数据(如 Owner, BU, Product, Environment),作为自动化管理和安全策略执行的基础
|
||||
- IPAM(IP Address Management):IP 地址管理工具,用于规划、追踪和管理 IP 地址空间,实现 VPC IP 地址自动化分配
|
||||
- RTO(Recovery Time Objective):系统允许的最大停机时间,是灾难恢复的核心指标
|
||||
- RPO(Recovery Point Objective):可接受的最大数据丢失量,是数据保护的核心指标
|
||||
- 开源平替:功能可替代闭源商业产品的开源项目
|
||||
@@ -206,6 +209,8 @@ AI 开源项目、Cloud & DevOps、Vibe Coding、AI时代个人发展、跨境
|
||||
- **DevOps Maturity Model From Traditional IT to Advanced DevOps** — DevOps 成熟度五级框架详解(初始/应急→局部DevOps→自动化与定义→高度优化→完全成熟),涵盖文化与战略、自动化、结构与流程、协作与共享、技术五大评估领域,以及安全集成方法和常见障碍分析
|
||||
|
||||
- **What is DevSecOps? Best Practices, Benefits, and Tools** — DevSecOps 方法论详解(SDLC 安全集成、SAST/SCA/IAST/DAST 四大工具、Shift Left/Right 策略、企业实施挑战)
|
||||
- **Public Cloud Learning Sessions (OpenText) - GitHub Enterprise to GitLab migration** — OpenText 将代码仓库从 GitHub Enterprise 迁移到 GitLab,self-serve 模式
|
||||
|
||||
- **Ubuntu 服务器通过 rsync 实现日常增量备份** — 使用 rsync 实现 Ubuntu 服务器到 NAS 的增量备份,涵盖 NFS 永久挂载和灾难恢复
|
||||
|
||||
- **CTP Topic 46 NetApps on AWS** — NetApp Cloud Volume ONTAP (CVO) 架构、部署、数据分层(EBS→S3)、安全加密与灾备(SnapMirror)
|
||||
@@ -213,8 +218,10 @@ AI 开源项目、Cloud & DevOps、Vibe Coding、AI时代个人发展、跨境
|
||||
- **CTP Topic 7 SaaS Landing Zone Design** — 生产环境 SaaS Landing Zone 高级设计,单一 Landing Zone 策略、Core/Baseline/Shared Services 账户分离
|
||||
- **CTP Topic 40 SaaS Database Architecture On AWS Cloud** — AWS 云上 SaaS 数据库架构设计,SaaS 数据库团队全球运维实践(500+ 数据库、1000+ 服务器,Oracle/Postgres/DynamoDB 等多种数据库,高可用设计)
|
||||
- **CTP Topic 28 AWS Tag Validation Tool** — AWS 标签验证工具,通过 YAML 配置文件审计资源标签合规性,生成 CSV 报告
|
||||
- **CTP Topic 30 Managing Change** — 云转型项目中的变更管理流程,SRE 角色定义和三种变更类型(标准变更、正常变更、紧急变更)
|
||||
- **CTP Topic 73 AWS Backup implementation of the Cloud Transformation Program** — AWS Backup 在 CTP 云转型计划中的实施,涵盖 SRE 备份模型、DR 账户备份、AWS Backup Audit Manager 审计
|
||||
- **如何在Ubuntu Server上通过NFS挂载Synology NAS上的共享文件夹** — <20><> Ubuntu Server 上通过 NFS 协议挂载 Synology NAS 共享文件夹
|
||||
- **CTP Topic 57 Product backlog managing demand** — Product Backlog 管理需求流程,SMACs 提交、Octane 入池、前置条件阶段
|
||||
- **如何在Ubuntu Server上通过NFS挂载Synology NAS上的共享文件夹** — 在 Ubuntu Server 上通过 NFS 协议挂载 Synology NAS 共享文件夹
|
||||
- **Ubuntu 禁用合盖休眠** — 在 Ubuntu 24.04 中通过修改 systemd-logind 配置禁用笔记本合盖休眠行为
|
||||
- **群晖NAS科学上网方法** — 在群晖 NAS 上通过 V2RayA 配置透明代理,使 Docker 可以科学上网
|
||||
- **RAX50 路由器更新 Merlin Clash 订阅指南** — RAX50 路由器 Merlin Clash 订阅更新教程
|
||||
|
||||
@@ -0,0 +1,57 @@
|
||||
---
|
||||
title: "CTP Topic 18 Wide Area Networking in AWS Cloud"
|
||||
type: source
|
||||
tags:
|
||||
- AWS
|
||||
- WAN
|
||||
- Networking
|
||||
- CTP
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-18-wide-area-networking-in-aws-cloud.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:AWS 云环境中的广域网(WAN)架构设计及其演进路径
|
||||
- 问题域:大型企业跨国云网络管理、跨区域连接、远程访问优化
|
||||
- 方法/机制:Transit Gateway (TGW) 星型拓扑、SD-WAN 叠加网络、Prisma Access SASE 架构
|
||||
- 结论/价值:展示从传统静态路由到智能SD-WAN演进的完整路径,为企业云网络架构提供实践参考
|
||||
|
||||
## Key Claims
|
||||
- Transit Gateway 是 AWS 区域级网络中转服务,连接 VPC、本地网络及跨区域 TGW
|
||||
|
||||
## Key Quotes
|
||||
> "将全球划分为三个地理区域(APJ、EMEA、AMS),每个区域设立一个核心 Hub(如 EMEA 的伦敦,AMS 的俄勒冈)。所有 Landing Zones 通过 TGW Peering 接入区域 Hub,形成星型拓扑"
|
||||
|
||||
> "当前 TGW 间的路由主要基于静态前缀列表(Prefix Lists),缺乏动态路由协议(如 BGP)支持"
|
||||
|
||||
> "计划引入 Silver Peak 的 SD-WAN 方案作为叠加网络(Overlay),实现动态路径选择和自动化流量调度"
|
||||
|
||||
> "计划将传统 Pulse VPN 迁移至 Palo Alto 的 Prisma Access(SASE 架构)"
|
||||
|
||||
## Key Concepts
|
||||
- [[Transit Gateway]]:AWS 区域级网络中转服务
|
||||
- [[Landing Zone]]:企业标准化的 AWS 多账号环境
|
||||
- [[Hub-and-Spoke]]:星型拓扑结构
|
||||
- [[SD-WAN]]:软件定义广域网
|
||||
- [[Prisma Access]]:Palo Alto 的 SASE 安全访问服务
|
||||
- [[Overlay Network]]:叠加网络
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]:亚马逊云服务平台
|
||||
- [[Christian Deckelman]]:Micro Focus IT 网络架构师,演讲人
|
||||
|
||||
## Connections
|
||||
- [[CTP Topic 34 Azure Landing Zone Architecture Overview]] ← relates_to ← [[Landing Zone]]
|
||||
- [[CTP Topic 22 Global DNS service offerings]] ← relates_to ← [[WAN]]
|
||||
- [[CTP Topic 19 Configuring DNS within AWS LZs]] ← relates_to ← [[Landing Zone]]
|
||||
|
||||
## Contradictions
|
||||
- (暂无)
|
||||
|
||||
## Source
|
||||
- NAS: /volume2/work/Public Cloud Learning Sessions/CTP _ Topic 18_ Wide Area Networking in AWS Cloud.mp4
|
||||
|
||||
---
|
||||
*last_updated: 2026-04-14*
|
||||
52
wiki/sources/ctp-topic-19-configuring-dns-within-aws-lzs.md
Normal file
52
wiki/sources/ctp-topic-19-configuring-dns-within-aws-lzs.md
Normal file
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: "CTP Topic 19: Configuring DNS within AWS LZs"
|
||||
type: source
|
||||
tags:
|
||||
- AWS
|
||||
- DNS
|
||||
- Landing-Zone
|
||||
- CTP
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-19-configuring-dns-within-aws-lzs.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:在 AWS Landing Zone 多账号环境下实现 DNS 集中化管理
|
||||
- 问题域:解决跨账号、跨云与本地数据中心(On-prem)之间的域名解析难题
|
||||
- 方法/机制:通过专用 DNS 账号集中管理 Private Hosted Zones,利用 Route 53 Resolver 的 Inbound/Outbound Endpoints 处理混合云 DNS 流量,通过 AWS RAM 跨账号共享 Resolver Rules
|
||||
- 结论/价值:推荐设立专门的 DNS 账号(曾被称为 InfoBlocks 账号)进行集中管理,便于统一维护路由规则和域名记录
|
||||
|
||||
## Key Claims
|
||||
- 在 Landing Zone 中设立专门的 DNS 账号进行集中管理,而非在每个业务账号中分散创建私有托管区
|
||||
- Route 53 Resolver 的 Inbound Endpoints 接收来自本地数据中心的解析请求,Outbound Endpoints 将 AWS 内部请求转发至本地 DNS 服务器
|
||||
- 利用 AWS RAM 将 DNS 账号中定义的解析规则共享给各个业务账号,跨账号 VPC 与私有托管区关联时必须先授权再关联
|
||||
|
||||
## Key Quotes
|
||||
> "推荐在 Landing Zone 中设立专门的 DNS 账号(曾被称为 InfoBlocks 账号),而非在每个业务账号中分散创建私有托管区。这种方式便于统一维护路由规则和域名记录。" — Sankar Gopov
|
||||
|
||||
> "通过 Inbound Endpoints 接收来自本地数据中心的解析请求,通过 Outbound Endpoints 将 AWS 内部请求转发至本地 DNS 服务器。" — Sankar Gopov
|
||||
|
||||
## Key Concepts
|
||||
- [[Route-53-Private-Hosted-Zone]]:AWS Route 53 私有托管区域,用于在指定 VPC 内部解析自定义域名
|
||||
- [[Route-53-Resolver-Endpoint]]:Route 53 Resolver 的入站/出站终端节点,处理混合云 DNS 流量
|
||||
- [[AWS-RAM]]:Resource Access Manager,用于跨账号共享 DNS 解析规则
|
||||
- [[Landing-Zone]]:AWS 多账号环境规范,预配置安全、网络和治理框架
|
||||
- [[VPC-Association-Authorization]]:跨账号关联流程,需先授权再关联
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]:Amazon Web Services,主题云平台
|
||||
- [[Gruntwork]]:提供 Landing Zone 框架
|
||||
- [[Route-53]]:AWS DNS 服务
|
||||
|
||||
## Connections
|
||||
- [[CTP-Topic-22-Global-DNS-Service-Offerings]] ← extends ← 本页面:DNS 服务架构的延续
|
||||
- [[Gruntwork-Landing-Zone]] ← depends_on ← 本页面:DNS 配置依赖 Landing Zone 架构
|
||||
- [[Route-53-Private-Hosted-Zone]] ← implements ← 本页面:具体实现机制
|
||||
|
||||
## Contradictions
|
||||
- (暂无)
|
||||
|
||||
## Notes
|
||||
- Terraform 用于自动化 DNS 配置,在创建业务 VPC 过程中通过预定义模块自动完成规则共享与 VPC 关联
|
||||
@@ -0,0 +1,59 @@
|
||||
---
|
||||
title: "CTP Topic 20 Program demand process flow and PoC onboarding"
|
||||
type: source
|
||||
tags:
|
||||
- Demand-Process
|
||||
- PoC
|
||||
- Onboarding
|
||||
- CTP
|
||||
- Cloud-Transformation
|
||||
date: 2026-04-19
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-20-program-demand-process-flow-and-poc-onboarding.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:云转型计划(CTP)的程序需求流程与概念验证(POC)入站流程
|
||||
- 问题域:企业云迁移的需求管理、风险控制与治理流程
|
||||
- 方法/机制:Gate 审批流程(Gate 0/1/3)、POC 验证、IaC 自动化部署
|
||||
- 结论/价值:POC 是降低迁移风险的核心环节,需验证架构可行性并熟悉 Gruntwork Landing Zone
|
||||
|
||||
## Key Claims
|
||||
- 程序需求流程始于业务端转型需求,经过优先级排序后决定是否进行 POC
|
||||
- Gate 0 用于评估准入,Gate 1 负责设计权威审批,Gate 3 作为迁移最终准入
|
||||
- POC 主要目的是验证架构和技术可行性,让团队熟悉基于 Gruntwork 的新一代 Landing Zone
|
||||
- 新环境强调 IaC,要求使用 Terraform 和 Terragrunt 自动化部署,严禁手动构建
|
||||
- POC 预期成果包括:验证的解决方案设计、准备就绪的 IaC 脚本、明确的迁移时间表
|
||||
|
||||
## Key Quotes
|
||||
> "POC 被强调为降低迁移风险的核心环节" — Sergio
|
||||
> "Gate 1 负责设计权威(Design Authority)审批" — Damian
|
||||
|
||||
## Key Concepts
|
||||
- [[Program-Demand-Process]]:从业务需求产生、优先级排序到最终交付迁移的端到端管理路径
|
||||
- [[Proof-of-Concept-POC]]:概念验证阶段,用于证明架构可行性和测试复杂网络需求
|
||||
- [[Landing-Zone]]:云端预配置的标准化基础架构环境
|
||||
- [[Infrastructure-as-Code-IaC]]:通过脚本(如 Terraform)而非手动操作管理云资源
|
||||
- [[Gate-Process]]:网关审批流程,用于治理项目进度的关键决策点
|
||||
- [[Terraform]]:核心 IaC 工具,用于编写和管理云基础设施配置脚本
|
||||
- [[Solution-Design]]:解决方案设计,在 POC 阶段需完成并经过设计权威审批
|
||||
- [[PCG-Team]]:平台控制组,负责云环境支持、安全策略制定及协助产品组进行 POC
|
||||
|
||||
## Key Entities
|
||||
- [[Sergio]]:云转型计划专家,本次会议主讲人之一
|
||||
- [[Damian]]:云转型计划专家,本次会议主讲人之一
|
||||
- [[PCG-Team]]:平台控制组,提供云环境支持和技术协助
|
||||
- [[Gruntwork]]:提供 Landing Zone 框架的核心技术提供商
|
||||
|
||||
## Connections
|
||||
- [[CTP-Topic-25-Labs-Landing-Zone]] ← extends ← [[Gruntwork-Landing-Zone]]
|
||||
- [[CTP-Topic-1-Gruntwork-Landing-Zone-Architecture]] ← depends_on ← [[Landing-Zone]]
|
||||
- [[PCG-Team]] ← supports ← [[Proof-of-Concept-POC]]
|
||||
|
||||
## Contradictions
|
||||
- (暂无记录)
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-19*
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
id: ctp-topic-23-introduction-to-the-technical-architecture-team-and-function
|
||||
title: "CTP Topic 23 Introduction to the Technical Architecture team and function"
|
||||
type: source
|
||||
tags:
|
||||
- Technical-Architecture
|
||||
- Team
|
||||
- CTP
|
||||
- OpenText
|
||||
date-added: 2026-04-19
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-23-introduction-to-the-technical-architecture-team-and-function.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:技术架构团队(Technical Architecture Team)的职能、组织架构及在公司云转型中的价值
|
||||
- 问题域:云转型过程中的技术治理与架构规划
|
||||
- 方法/机制:从被动响应转向主动规划,通过"技术领域(Technical Domains)"划分和首席架构师负责制实现12-24个月前瞻性路线图
|
||||
- 结论/价值:技术架构团队通过维护AWS Enterprise Landing Zones、推行"云优先(Cloud-first)"策略,帮助业务部门规避风险、优化预算、提升交付速度
|
||||
|
||||
## Key Claims
|
||||
- 技术架构团队核心转变:从被动响应转向主动规划,通过12-24个月路线图从"救火式"响应转变为预测性规划
|
||||
- 三种架构职能分工:企业架构(EA)对接业务战略、方案架构(SA)负责中间件与服务优化、技术架构(TA)专注于底层技术实施与基础设施治理
|
||||
- 云优先策略:除非因数据主权、合规性或极端成本原因必须保留在本地,否则所有新业务应优先上云
|
||||
|
||||
## Key Quotes
|
||||
> "从两个大型组织的合并,涉及基础设施、流程与治理模式的深度融合" — 背景:PSTC与IT部门整合至CIO统一领导
|
||||
> "技术架构团队在维护AWS Enterprise Landing Zones方面的努力,旨在通过标准化和治理确保云环境的安全与高效"
|
||||
> "通过将技术划分为不同的'技术领域(Technical Domains)'并由首席架构师负责"
|
||||
|
||||
## Key Concepts
|
||||
- [[Technical-Domains]]:将公司技术栈划分为特定领域(如身份认证、网络、Microsoft堆栈等),每个领域由专人负责其生命周期与路线图
|
||||
- [[Technical-Architecture-TA]]:最贴近技术的架构层,负责具体基础设施的设计、实施治理以及技术路线图的维护
|
||||
- [[Enterprise-Architecture-EA]]:架构体系的高层,主要负责将业务目标转化为技术原则和标准
|
||||
- [[Solution-Architecture-SA]]:架构体系的中间层,专注于特定项目或服务的优化实施
|
||||
- [[Cloud-First-Strategy]]:云优先策略,优先选择云解决方案而非本地部署
|
||||
- [[AWS-Enterprise-Landing-Zones]]:AWS企业落地分区,一套预配置的、符合最佳实践的AWS多账号环境
|
||||
|
||||
## Key Entities
|
||||
- [[Martin-Nash]]:技术架构经理(Technical Architecture Manager),本次演讲主讲人
|
||||
- [[Cloud-Transformation-Office]]:云转型办公室(CTO),主办方
|
||||
- [[PSTC]]:Professional Services and Technology Company,合并前的组织
|
||||
- [[IT]]:信息技术部门,合并前的组织
|
||||
|
||||
## Connections
|
||||
- [[CTP-Topic-47-Enterprise-Architecture-Cloud-Standards]] ← provides_architecture_framework ← [[Martin-Nash]]
|
||||
- [[CTP-Topic-10-AWS-Landing-Zone-LZ-Data-Collection-Tagging-Related-Security]] ← related_topic ← [[AWS-Enterprise-Landing-Zones]]
|
||||
|
||||
## Contradictions
|
||||
- (暂无)
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-19*
|
||||
56
wiki/sources/ctp-topic-30-managing-change.md
Normal file
56
wiki/sources/ctp-topic-30-managing-change.md
Normal file
@@ -0,0 +1,56 @@
|
||||
---
|
||||
title: "CTP Topic 30 Managing Change"
|
||||
type: source
|
||||
tags: [cloud-learning, change-management, SRE]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-30-managing-change.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:云转型项目中的变更管理流程,以及 SRE 团队在变更管理中的角色
|
||||
- 问题域:IT 服务管理、变更管理流程、SRE 职责
|
||||
- 方法/机制:三种变更类型(标准变更、正常变更、紧急变更)的分类和处理流程,SRE 团队与产品团队的协作模式
|
||||
- 结论/价值:明确 SRE 角色定义和变更管理流程,确保云转型项目中各团队的有效协作
|
||||
|
||||
## Key Claims
|
||||
- SRE 团队的核心职责是通过软件工程思维方式解决运维问题,自动化重复性工作,提高系统可靠性和可测试性
|
||||
- 变更分为三种类型:标准变更(预批准,无需 CAB)、正常变更(需 CAB 批准)、紧急变更(为缓解事故而立即执行)
|
||||
- 事件是触发警报的低级别事件,事故是超出计划外的服务中断或服务质量下降,对客户影响较大
|
||||
- SRE 团队与产品团队的协作分为三个阶段:构建和设置、早期上线支持(Early Live Support)、BAU(日常运营)
|
||||
|
||||
## Key Quotes
|
||||
> "SRE 的核心在于自动化重复性工作,提高系统可靠性和可测试性" — Brendan Starnig
|
||||
|
||||
> "标准变更应尽可能实现完全自动化,通过 IaC + CI/CD Pipeline" — Brendan Starnig
|
||||
|
||||
> "事件的 CAPA(Corrective and Preventive Action)目的是从事故中提取根因并预防同类问题再次发生" — Brendan Starnig
|
||||
|
||||
## Key Concepts
|
||||
- [[SRE]]:站点可靠性工程,将软件工程方法应用于运维问题
|
||||
- [[Change Management]]:变更管理,三种类型(标准变更、正常变更、紧急变更)
|
||||
- [[SMACs]]:Service Management Automation X,当前使用的 ITSM 工具
|
||||
- [[CAPA]]:Corrective and Preventive Action,纠正和预防措施,即 Post-mortem 回顾
|
||||
- [[SLO]]:Service Level Objective,服务等级目标
|
||||
- [[SLR]]:Service Level Requirement,服务等级需求
|
||||
- [[Early Live Support]]:Build 与 BAU 之间的过渡阶段
|
||||
|
||||
## Key Entities
|
||||
- [[Brendan Starnig]]:SRE Function Lead, Platform Engineering,讲师
|
||||
- [[SMACs Ticket]]:内部服务管理工单系统,用于 Ticket、Incident、Change 管理
|
||||
|
||||
## Connections
|
||||
- [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]] ← related_to ← [[SRE]]:AD 服务与 SRE 协作流程相关
|
||||
- [[ctp-topic-28-aws-tag-validation-tool]] ← relates_to ← [[Standard Change]]:IaC 变更的 Tagging 标准属于 Standard Change 范畴
|
||||
- [[ctp-topic-19-configuring-dns-within-aws-lzs]] ← relates_to ← [[SRE Support Model]]:DNS 配置与 SRE 支持模型的关系
|
||||
|
||||
## Contradictions
|
||||
- (暂无记录)
|
||||
|
||||
## Action Items
|
||||
- [ ] 评估现有变更流程,识别可自动化并转化为标准变更的环节
|
||||
- [ ] 明确各团队与 SRE 团队在不同阶段的交互方式和责任范围
|
||||
- [ ] 确保所有团队成员正确使用 PPM、SMACs 和 Octane 等工具
|
||||
- [ ] 完善监控覆盖,确保所有关键服务和基础设施都得到充分监控
|
||||
- [ ] 建立清晰的事件响应和升级流程
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: "CTP Topic 31 Network Segregation and Secure Access to the New AWS Landing Zones"
|
||||
type: source
|
||||
tags:
|
||||
- AWS
|
||||
- Network-Security
|
||||
- Landing-Zone
|
||||
- CTP
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:AWS Landing Zone 网络隔离与安全访问解决方案
|
||||
- 问题域:内部系统(on-prem 和 VPN 用户)可直接访问生产环境 workloads 的安全合规问题
|
||||
- 方法/机制:网络隔离(通过 Checkpoint 防火墙控制服务器间通信)+ 安全访问(通过 AWS Systems Manager (SSM) 替代 VPN)
|
||||
- 结论/价值:解决紧急安全风险,提供临时方案直到 SD-WAN 实施
|
||||
|
||||
## Key Claims
|
||||
- 内部系统和 VPN 用户由于共享网络配置可访问 AWS 生产环境,存在安全合规风险
|
||||
- 网络隔离通过 Checkpoint 启用 SPI(Stateful Packet Inspection)功能,默认拒绝仅允许必需服务和网络段
|
||||
- SSM 通过浏览器会话或 AWS CLI 提供远程访问,用户通过扮演角色获得目标 EC2 实例的 SSM agent 访问权限
|
||||
- SSM 方案成本低、部署快,但长期目标是基础设施即代码(IaC)以减少控制台访问
|
||||
|
||||
## Key Quotes
|
||||
> "The primary driver for this initiative is to address security concerns related to internal systems accessing production workloads in the new AWS landing zones."
|
||||
|
||||
> "Secure access will be facilitated through AWS Systems Manager (SSM), which provides remote access via a browser-based session or AWS CLI, eliminating the need for VPN."
|
||||
|
||||
> "The long-term goal is to move towards infrastructure as code to minimize console access and enhance security, with break-glass access reserved for emergencies."
|
||||
|
||||
## Key Concepts
|
||||
- [[Network-Segregation]]:通过 Checkpoint 防火墙控制服务器间通信,阻断内部网络直接访问 AWS 网段
|
||||
- [[SPI-Features]]:Stateful Packet Inspection,启用默认拒绝,仅允许必需服务和网络段
|
||||
- [[SSM-Access]]:通过 AWS Systems Manager 实现安全的远程访问,替代传统 VPN
|
||||
- [[AWS-Landing-Zone]]:AWS 多账号基础架构框架,用于安全合规部署
|
||||
- [[Zero-Trust-Access]]:零信任访问模式,通过角色扮演和双因素认证实现安全访问
|
||||
- [[Break-Glass-Access]]:紧急访问,仅在紧急情况下使用,优先目标是 IaC 减少此类需求
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]:云平台,提供 SSM、VPC 等服务
|
||||
- [[Checkpoint-Firewall]]:云环境虚拟防火墙,用于网络隔离
|
||||
|
||||
## Connections
|
||||
- [[CTP-Topic-35-AWS-Landing-Zone-Design-Refresher]] ← related_to ← [[CTP-Topic-31-Network-Segregation]]
|
||||
- [[CTP-Topic-18-Wide-Area-Networking-in-AWS-Cloud]] ← extends ← [[CTP-Topic-31-Network-Segregation]]
|
||||
- [[Gruntwork-Landing-Zone]] ← implements ← [[AWS-Landing-Zone]]
|
||||
|
||||
## Contradictions
|
||||
- (暂无)
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
id: ctp-topic-4-using-agile-to-run-the-cloud-transformation-program
|
||||
title: "CTP Topic 4 Using Agile to run the Cloud Transformation Program"
|
||||
type: source
|
||||
tags: [Agile, Cloud-Transformation, CTP, Scrum, Kanban]
|
||||
sources: [NAS /volume2/work/Public Cloud Learning Sessions/CTP _ Topic 4_ Using Agile to run the Cloud Transformation Program.mp4]
|
||||
date: 2026-04-14
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:云转型计划中的敏捷实践应用
|
||||
- 问题域:如何选择和改进敏捷框架以适应云转型项目
|
||||
- 方法/机制:从 Scrum 过渡到 Kanban,最终采用混合模式
|
||||
- 结论/价值:敏捷需要根据项目特点灵活调整,混合模式可能更适合持续变化的云转型项目
|
||||
|
||||
## Key Claims
|
||||
- Scrum 框架的问题在于冲刺期间无法接受变更,这在云转型项目中难以满足
|
||||
- Kanban 允许随时变更,专注于持续交付而非冲刺结束时发布
|
||||
- 当前混合模式结合了 Kanban 的灵活性和 Scrum 的固定仪式
|
||||
- 每日站会应该简短(15-30分钟),聚焦昨天完成、今天计划和任何阻碍
|
||||
- 回顾会议是获得快速反馈和改进开发文化的关键
|
||||
- Microsoft Planner 看板使用 Kanban 结构,包含 backlog、to do、in progress、program key decisions、icebox 等列
|
||||
|
||||
## Key Quotes
|
||||
> "The big problem with Scrum, in my opinion, is that you can't make changes throughout the sprints, we are not advised to." — Heather Norris
|
||||
> "Agile is all about getting that rapid feedback to make the product and make the, you know, the development culture better."
|
||||
|
||||
## Key Concepts
|
||||
- [[Scrum]]:两周冲刺框架,包含产品待办、冲刺计划、回顾、评审和每日站会
|
||||
- [[Kanban]]:持续流框架,允许随时变更,专注于持续交付
|
||||
- [[每日站会]]:每日Brief会议(15-30分钟),分享昨天完成、今天计划和阻碍
|
||||
- [[回顾会议]]:回顾和改进开发文化的会议,产出带负责人的行动项
|
||||
- [[Microsoft Planner]]:项目管理看板工具,使用 Kanban 结构管理需求
|
||||
|
||||
## Key Entities
|
||||
- [[Heather Norris]]:云转型计划的项目经理,演讲者
|
||||
|
||||
## Connections
|
||||
- [[CTP Topic 1 Gruntwork Landing Zone Architecture]] ← uses ← [[Scrum]]
|
||||
- [[CTP Topic 30 Managing Change]] ← relates_to ← [[敏捷实践]]
|
||||
|
||||
## Contradictions
|
||||
- 无
|
||||
|
||||
## Aliases
|
||||
- CTP Topic 4
|
||||
- Using Agile to run the Cloud Transformation Program
|
||||
62
wiki/sources/ctp-topic-41-nfrs-and-error-budgets.md
Normal file
62
wiki/sources/ctp-topic-41-nfrs-and-error-budgets.md
Normal file
@@ -0,0 +1,62 @@
|
||||
---
|
||||
id: ctp-topic-41-nfrs-and-error-budgets
|
||||
title: "CTP Topic 41 NFR's and Error Budgets"
|
||||
type: source
|
||||
tags: [cloud-learning, devops, sre]
|
||||
date: 2026-04-14
|
||||
sources:
|
||||
- raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-41-nfrs-and-error-budgets.md
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-41-nfrs-and-error-budgets.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:NFR(非功能需求)与 Error Budget(错误预算)在云和敏捷开发中的应用
|
||||
- 问题域:如何平衡功能快速交付与系统可靠性要求
|
||||
- 方法/机制:SRE 实践、SLI/SLO/SLA 体系、混沌工程
|
||||
- 结论/价值:Error Budget 将失败正常化,弥合开发与运维之间的鸿沟
|
||||
|
||||
## Key Claims
|
||||
- NFR(Non-Functional Requirements,非功能需求)是评判系统运行状况的标准,决定可用性、性能、安全等属性
|
||||
- Error Budget(错误预算)是系统在不影响客户的前提下可以不可靠的最大时间量
|
||||
- Error Budget = 1 - 可用性 SLO,例如 99.9% SLO 对应 0.1% Error Budget
|
||||
- 混沌工程(Chaos Engineering)通过故意引发故障来测试系统韧性,确保满足 NFR
|
||||
- AWS 共享责任模型下,企业必须自行架构和管理云服务以满足 NFR
|
||||
|
||||
## Key Quotes
|
||||
> "We want to drive collaboration across our product groups and operations to ensure our obligation to our customers." — Brendan Standing
|
||||
|
||||
> "Error budgets normalize failure as part of the development process." — Brendan Standing
|
||||
|
||||
> "Perfect availability is 100%, and the error budget falls between the SLO and 100%." — Brendan Standing
|
||||
|
||||
## Key Concepts
|
||||
- [[NFR(非功能需求)]]:评判系统运行状况的标准,如可用性、性能、安全性
|
||||
- [[Error Budget(错误预算)]]:系统可不可靠而不影响客户的允许时间量
|
||||
- [[SLI(服务等级指标)]]:可靠性的可量化度量指标
|
||||
- [[SLO(服务等级目标)]]:服务应该达到的性能/可靠性目标
|
||||
- [[SLA(服务等级协议)]]:客户级别的正式协议
|
||||
- [[混沌工程]]:主动引入故障测试系统韧性的实践
|
||||
- [[SRE(站点可靠性工程)]]:将软件工程方法应用于运维问题的学科
|
||||
|
||||
## Key Entities
|
||||
- [[Brendan Standing]]:Micro Focus SRE 负责人,演讲者
|
||||
- [[AWS]]:Amazon Web Services,云服务提供商,共享责任模型
|
||||
- [[Micro Focus]]:软件公司,SRE 团队所在组织
|
||||
|
||||
## Connections
|
||||
- [[SRE]] ← implements ← [[NFR(非功能需求)]]
|
||||
- [[SRE]] ← uses ← [[Error Budget(错误预算)]]
|
||||
- [[SLO(服务等级目标)]] ← derives ← [[Error Budget(错误预算)]]
|
||||
- [[SLI(服务等级指标)]] ← measures ← [[SLO(服务等级目标)]]
|
||||
- [[混沌工程]] ← validates ← [[NFR(非功能需求)]]
|
||||
|
||||
## Contradictions
|
||||
- (暂无)
|
||||
|
||||
## Notes
|
||||
- NFR Epic 目标:将 NFR 模板集成到 Sprint backlog,确保任何重大变更都考虑 NFR
|
||||
- NFR 在云端应更规范化,利用云原生服务(如 AWS Backup 定义备份策略和测试频率)
|
||||
- 监控能力对于衡量 Error Budget 是否耗尽至关重要
|
||||
- 下一步:与产品团队合作,将 NFR 集成到 backlog,制定 SLO
|
||||
42
wiki/sources/ctp-topic-43-vmware-cloud-on-aws.md
Normal file
42
wiki/sources/ctp-topic-43-vmware-cloud-on-aws.md
Normal file
@@ -0,0 +1,42 @@
|
||||
---
|
||||
title: "CTP Topic 43 VMware Cloud on AWS"
|
||||
type: source
|
||||
tags: [VMware, AWS, Networking, Hybrid-Cloud, CTP]
|
||||
date: 2026-04-14
|
||||
sources: []
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-43-vmware-cloud-on-aws.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:VMware Cloud on AWS(VMC on AWS)是一项 VMware 和 AWS 联合设计的云服务,在 AWS 硬件上原生运行 vSphere 8
|
||||
- 问题域:为企业提供介于完全本地部署和纯原生云迁移之间的中间地带方案
|
||||
- 方法/机制:通过在 AWS 服务器上原生安装 VMware 虚拟化层,实现应用在本地和云端之间的秒级迁移,访问 AWS 原生服务,享受 27% 成本节省
|
||||
- 结论/价值:VMC on AWS 降低了云迁移风险,提供了熟悉的工具集和运维体验,同时具备云端弹性扩展能力
|
||||
|
||||
## Key Claims
|
||||
- VMC on AWS 是一项 VMware 和 Amazon 联合设计的云服务,VMware 虚拟机管理程序原生运行在 AWS 硬件上,而非简单地在 AWS 上运行 VMware
|
||||
- VMC on AWS 提供与本地环境相同的工具集,使现有 VMware 技能可直接复用
|
||||
- VMC on AWS 支持通过 HCX 实现任意位置之间的 vSphere 工作负载迁移
|
||||
- VMC on AWS 提供 27% 的成本节省,相比传统云部署具有成本优势
|
||||
- VMC on AWS 基础设施基于 i3.metal 和 i3en.metal 服务器主机,构建可用区内的集群,可实现跨可用区的扩展集群
|
||||
|
||||
## Key Quotes
|
||||
> "This is not just something where VMware showed up at Amazon and dropped off a box of CDs" — 强调 VMC 是深度集成的联合工程产品
|
||||
|
||||
> "VMC on AWS is running vSphere 8 and provides access to AWS services with low latency" — vSphere 8 运行在 AWS 基础设施上
|
||||
|
||||
> "The service is available across multiple regions and availability zones globally" — 全球多区域和多可用区支持
|
||||
|
||||
## Key Entities
|
||||
|
||||
## Key Concepts
|
||||
|
||||
## Connections
|
||||
- [[AWS]] ← 基础设施提供商 ← [[VMware Cloud on AWS]]
|
||||
- [[VMware]] ← 联合工程设计 → [[VMware Cloud on AWS]]
|
||||
- [[Hybrid Cloud]] ← 实现方案 ← [[VMware Cloud on AWS]]
|
||||
|
||||
## Contradictions
|
||||
- (暂无)
|
||||
@@ -0,0 +1,53 @@
|
||||
---
|
||||
title: "CTP Topic 45 Automatic IP address allocation with IPAM"
|
||||
type: source
|
||||
tags: [AWS, IPAM, Networking, CTP]
|
||||
date: 2026-04-14
|
||||
source_file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-45-automatic-ip-address-allocation-with-ipam.md
|
||||
---
|
||||
|
||||
## Summary
|
||||
- 核心主题:使用 Infoblox NIOS 实现 VPC IP 地址自动化分配
|
||||
- 问题域:传统手动管理 IP 地址效率低下,需与网络团队手动协调 CIDR
|
||||
- 方法/机制:通过 Infoblox IPAM 自动查询可用 IP 块并预置 VPC,YAML 文件仅指定子网大小而非具体 IP
|
||||
- 结论/价值:减少跨团队协作,实现单一数据源,支持 VPC 销毁时自动清理 IPAM 条目
|
||||
|
||||
## Key Claims
|
||||
- IPAM(IP 地址管理)提供集中化管理、控制、监控和分配 IP 地址空间的能力
|
||||
- 当前使用 Excel 管理 IP 地址效率低下,Infoblox NIOS 作为无缝扩展的解决方案
|
||||
- 新方案无需手动向网络团队请求 IP 地址,NIOS 自动提供下一个可用 IP 块
|
||||
- 新 YAML 文件不包含具体 CIDR 子网 IP,仅指定所需子网大小(如 /22)和父 CIDR
|
||||
- 系统向后兼容,现有使用旧 YAML 文件的 VPC 配置将继续工作
|
||||
|
||||
## Key Quotes
|
||||
> "Managing the IP address in a spreadsheet takes time and it's not a good approach." — 描述传统 Excel 管理方式的低效性
|
||||
> "We are not asking for IP address from the network team." — 新方案的核心价值
|
||||
> "The system is backward compatible, meaning existing VPC configurations using the old YAML file will continue to work." — 向后兼容性保证
|
||||
|
||||
## Key Concepts
|
||||
- [[IPAM]]:IP 地址管理工具,用于规划、追踪和管理 IP 地址空间
|
||||
- [[VPC]]:Virtual Private Cloud,AWS 虚拟私有云
|
||||
- [[CIDR]]:无类别域间路由,用于指定 IP 地址范围
|
||||
- Extensible Attributes:可扩展属性,用于定义云使用相关元数据(如 space owner、subnet name、compartment type)
|
||||
|
||||
## Key Entities
|
||||
- [[Infoblox]]:企业级 DNS/DHCP 和 IPAM 解决方案提供商,提供 NIOS 设备
|
||||
- [[AWS]]:公有云平台,VPC 部署环境
|
||||
- Grid Master:IPAM 架构中的主节点
|
||||
- SRE 团队:负责 VPC 预置的团队
|
||||
- Network Team:负责计算最优 CIDR 范围的团队(旧流程)
|
||||
|
||||
## Connections
|
||||
- [[Infoblox]] ← provides_ipam_capability ← [[VPC]]
|
||||
- SRE 团队 ← automates_vpc_provisioning ← [[IPAM]]
|
||||
- 新流程 ← eliminates_manual_coordination ← Network Team
|
||||
|
||||
## Contradictions
|
||||
- (暂无冲突记录)
|
||||
|
||||
## Notes
|
||||
- 视频状态:已通过 Gemini 摘要
|
||||
- 新 YAML 文件包含 business contact、engineering contact、date 字段
|
||||
- 支持指定可用区 ID 创建子网
|
||||
- 销毁 VPC 时会移除 IPAM grid 中的所有条目
|
||||
- 防止意外删除 VPC 的保护措施:Terragrant.hcl 中需要特殊标志
|
||||
47
wiki/sources/ctp-topic-53-why-bother-with-cloud.md
Normal file
47
wiki/sources/ctp-topic-53-why-bother-with-cloud.md
Normal file
@@ -0,0 +1,47 @@
|
||||
---
|
||||
title: "CTP Topic 53 Why bother with Cloud"
|
||||
type: source
|
||||
tags: [cloud, ctp, opentext, strategy, landing-zone]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-53-why-bother-with-cloud.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:Micro Focus 云转型计划(Cloud Transformation Program)的进展与价值
|
||||
- 问题域:企业云迁移决策、基础设施整合、成本优化
|
||||
- 方法/机制:Landing Zone 框架、标签方法论、财务管控
|
||||
- 结论/价值:云迁移带来显著成本降低和创新机会,但需克服惯性思维
|
||||
|
||||
## Key Claims
|
||||
- Micro Focus 拥有全球最大的商业数据中心足迹,14 个数据中心近 20000 项资产
|
||||
- 从 Bublikan 迁出 3 个产品后,575 台物理服务器被 240 台虚拟服务器替代
|
||||
- 云迁移使产品团队能够更快响应客户、开拓新区域、增加收入
|
||||
- 当前 55% 的 AWS 成本发生在 Landing Zone 之外,缺乏自动化和安全管控
|
||||
|
||||
## Key Quotes
|
||||
> "We're trying to give them the information so that they can understand how they are spending."
|
||||
|
||||
> "The Cloud Transformation Program aims to consolidate infrastructure, reduce costs, and enable innovation across Micro Focus."
|
||||
|
||||
## Key Concepts
|
||||
- [[Landing Zone]]:云基础架构的逻辑边界,分为 Labs、SAS、Corporate 三种类型
|
||||
- [[Cloud Transformation Program]]:Micro Focus 的云转型计划
|
||||
- [[Tagging Methodology]]:标签方法论,通过标准化元数据实现成本追踪和管理
|
||||
- [[FinOps]]:云财务运营,整合财务管理与云资源优化
|
||||
- [[CCOE]]:Cloud Center of Excellence,推动云采纳和治理的核心组织
|
||||
|
||||
## Key Entities
|
||||
- [[OpenText]]:企业内容管理软件公司,主办 Cloud Transformation Program
|
||||
- [[AWS]]:公有云平台,CTP 的主要云服务商
|
||||
- [[SRE]]:站点可靠性工程团队,负责云平台运维
|
||||
|
||||
## Connections
|
||||
- [[AWS]] ← provides ← [[Landing Zone]]
|
||||
- [[OpenText]] ← operates_via ← [[Cloud Transformation Program]]
|
||||
- [[CCOE]] ← governs ← [[Tagging Methodology]]
|
||||
- [[FinOps]] ← monitors ← [[AWS]]
|
||||
|
||||
## Contradictions
|
||||
- (暂无冲突记录)
|
||||
51
wiki/sources/ctp-topic-57-product-backlog-managing-demand.md
Normal file
51
wiki/sources/ctp-topic-57-product-backlog-managing-demand.md
Normal file
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: "CTP Topic 57 Product backlog managing demand"
|
||||
type: source
|
||||
tags:
|
||||
- Product-Backlog
|
||||
- Demand-Management
|
||||
- Agile
|
||||
- CTP
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-57-product-backlog-managing-demand.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:Product Backlog(产品待办列表)管理需求
|
||||
- 问题域:云转型计划(CTP)中的需求管理与优先级排序
|
||||
- 方法/机制:通过 SMACs 提交需求、双周会议评审、20题计算器评估、Octane 入池、前置条件准备阶段
|
||||
- 结论/价值:实现需求透明度和优先级评估标准化,确保所有需求在同一标准下被审视
|
||||
|
||||
## Key Claims
|
||||
- 需求必须通过 SMACs 提交以启动计时器和确保追踪
|
||||
- 每周双次会议评审需求的价值和优先级,计算器评估复杂度、成本和野心
|
||||
- 新团队需经过前置条件准备阶段才能进入 Octane
|
||||
- Sprint 规划通常提前 6 个迭代,50% 分配给新需求,50% 给支持工单和技术债务
|
||||
|
||||
## Key Quotes
|
||||
> "We need a way to make sure it's transparent and we're holding everything up to the light and looking everything for the same lens as we are."
|
||||
|
||||
> "It means that for ADM they can effectively plan all of the work that's going into their sprints with the engineers that are working solidly on their work."
|
||||
|
||||
## Key Concepts
|
||||
- [[Product-Backlog]]:存放待开发功能的区域,高亮需求、收益和优先级
|
||||
- [[SMACs]]:Service Management Access,用于提交新需求的标准化入口
|
||||
- [[Octane]]:数字化产品管理平台,需求评估后移入为特性
|
||||
- [[前置条件阶段]]:产品团队进入企业级 Landing Zone 转型旅程的准备阶段
|
||||
- [[Sprint-规划]]:提前约 6 个迭代规划工作,50% 新需求 + 50% 支持工单/技术债务
|
||||
|
||||
## Key Entities
|
||||
- [[Matthew-Chapman]]:需求评审会议主持人
|
||||
- [[David-Grant]]:需求评审会议参与人
|
||||
- [[Brendan]]:需求评审会议参与人
|
||||
|
||||
## Connections
|
||||
- [[CTP]] ← manages_demand ← [[Product-Backlog]]
|
||||
- [[SMACs]] ← triggers ← [[Demand-Tracking]]
|
||||
- [[前置条件阶段]] ← precedes ← [[Octane]]
|
||||
- [[Sprint-规划]] ← includes ← [[Demand-Allocation]]
|
||||
|
||||
## Contradictions
|
||||
- 邮件或聊天可作为初始联系方式,但 SMACs 是最可靠的追踪方式
|
||||
44
wiki/sources/ctp-topic-6-aws-workspaces-demo.md
Normal file
44
wiki/sources/ctp-topic-6-aws-workspaces-demo.md
Normal file
@@ -0,0 +1,44 @@
|
||||
---
|
||||
title: "CTP Topic 6 AWS Workspaces Demo"
|
||||
type: source
|
||||
tags:
|
||||
- AWS
|
||||
- Workspaces
|
||||
- Demo
|
||||
- CTP
|
||||
- CloudLearning
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-6-aws-workspaces-demo.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:AWS Workspaces 远程桌面解决方案的演示与配置流程
|
||||
- 问题域:云桌面环境预配置与快速生产力工具链部署
|
||||
- 方法/机制:AWS Workspaces 提供基于浏览器或客户端访问的远程 Windows 桌面,预装 PF SSO、Terraform、TerraGrunt、Git、VS Code 等工具,目标是在申请后 30-45 分钟内运行 Terraform 计划
|
||||
- 结论/价值:通过预配置工作区实现用户快速上手,解决环境搭建耗时长的问题
|
||||
|
||||
## Key Claims
|
||||
- AWS Workspaces 提供即用型远程桌面,可通过 Web 浏览器或客户端应用访问
|
||||
- 工作站预装 PF SSO、Terraform、TerraGrunt、Git、VS Code 等开发工具
|
||||
- 使用 Windows Server 2016 配合 Pulse UI(Amazon Linux 存在兼容性问题)
|
||||
- 用户申请后约 21 分钟可完成 TerraGrunt 计划执行
|
||||
|
||||
## Key Quotes
|
||||
> "The goal is that within half an hour, 45 minutes of making a request for a workspace, you've run a Terra Grunt plan against a piece of infrastructure." — 演示目标
|
||||
|
||||
> "Once logged in, users can access the AWS console using Federation, GitHub Enterprise, and generate SSH keys." — 登录后能力
|
||||
|
||||
## Key Concepts
|
||||
- [[AWS Workspaces]]:AWS 提供的托管桌面即服务(DaaS)解决方案
|
||||
- [[TerraGrunt]]:Terraform 的包装工具,简化配置管理和远程状态
|
||||
- [[PF SSO]]:某种单点登录解决方案
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]:云服务提供商
|
||||
- [[OpenText]]:主办本次 CTP 学习活动的公司
|
||||
|
||||
## Connections
|
||||
- [[CTP Topic 58 AWS EC2 Image Builder]] ← uses ← [[AWS Workspaces]]
|
||||
- [[CTP Topic 26 Standard AMI – build, publish, share processes]] ← related_to ← [[AWS Workspaces]]
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: "CTP Topic 61 Workload VPC provision with IPAM Automation"
|
||||
type: source
|
||||
tags: [AWS, VPC, IPAM, Automation, CTP]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-61-workload-vpc-provision-with-ipam-automation.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:IPAM(IP 地址管理)与 Workload VPC 自动化 provisioning
|
||||
- 问题域:企业级 VPC IP 地址分配的手动干预问题
|
||||
- 方法/机制:Infoblox NIOS(Grid 架构)、YAML 配置文件定义 VPC 参数、Availability Zone ID(az id)代替 az name
|
||||
- 结论/价值:消除手动 IP 地址管理,减少错误,支持多 VPC 同时 provisioning,/22 及以上 CIDR 需审批
|
||||
|
||||
## Key Claims
|
||||
- IPAM 自动化消除手动干预,减少人为错误
|
||||
- Infoblox Grid 架构防止重叠 IP 地址
|
||||
- 使用 az id 替代 az name 避免可用区命名不一致
|
||||
- /22 及以下 CIDR 块需要审批流程
|
||||
|
||||
## Key Quotes
|
||||
> "We don't need to worry about IP address. If it's beyond IP address is 22 or greater, then only we need to take the approval."
|
||||
- Pushka, Principal SRE
|
||||
|
||||
> "So we just need to put the information at the right place and everything will work."
|
||||
- Pushka, Principal SRE
|
||||
|
||||
## Key Concepts
|
||||
- [[IPAM]]:IP 地址管理工具,用于规划、追踪和管理 IP 地址空间
|
||||
- [[VPC]]:虚拟私有云,AWS 网络隔离的基本单位
|
||||
|
||||
## Key Entities
|
||||
- [[Infoblox]]:企业级 DNS/DHCP 和 IPAM 解决方案提供商,Grid 架构由 Houston 数据中心的主数据库管理
|
||||
|
||||
## Connections
|
||||
- [[ctp-topic-45-automatic-ip-address-allocation-with-ipam]] ← extends ← [[ctp-topic-61-workload-vpc-provision-with-ipam-automation]]
|
||||
- [[IPAM]] ← used_by ← [[ctp-topic-61-workload-vpc-provision-with-ipam-automation]]
|
||||
- [[Infoblox]] ← provides ← [[IPAM]]
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: "CTP Topic 65 Tracing the value delivered in Cloud Transformation"
|
||||
type: source
|
||||
tags: [Value-Tracing, Cloud-Transformation, CTP]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:CTP 工作中的价值交付量化与优先级排序方法
|
||||
- 问题域:云转型中的价值评估与工作优先级排序
|
||||
- 方法/机制:加权最短作业优先(WSJF)方法、价值流分解、利益相关者分析
|
||||
- 结论/价值:通过经济价值最大化原则序列 CTP 工作,实现早期价值交付
|
||||
|
||||
## Key Claims
|
||||
- Process(流程)是将输入转化为输出和结果的方法论步骤,由数据、资源、时间、资金和知识等输入驱动
|
||||
- Outcome(结果)可以是硬性结果(时间、成本、质量)或软性结果(健康、安全)
|
||||
- Value(价值)由客户定义,体现为公平的回报或等值 goods,涉及收入增加、成本降低、风险改善和市场规模
|
||||
- 价值流(Value Stream)是一组向客户交付产品或服务的活动,分为运营价值流(OVS)和开发价值流(DVS)
|
||||
- 加权最短作业优先(WSJF)= (业务价值 + 时间关键性 + 风险与机会) / 作业规模,用于优先级排序
|
||||
|
||||
## Key Quotes
|
||||
> "A process is a methodical set of steps designed to achieve a specific output and outcome" — CTP 价值交付定义
|
||||
|
||||
> "What we want to do is deliver the maximum value early back into the business for the least amount of effort." — 价值交付目标
|
||||
|
||||
> "The goal is to sequence CTP work for maximum economic benefit" — CTP 工作优先级目标
|
||||
|
||||
## Key Concepts
|
||||
- [[Process]]:将输入转化为输出的方法论步骤
|
||||
- [[Outcome]]:流程产生的结果,分为硬性和软性
|
||||
- [[Value]]:客户定义的monetary worth
|
||||
- [[Value Stream]]:向客户交付价值的一组活动
|
||||
- [[WSJF]]:加权最短作业优先,用于工作优先级排序
|
||||
- [[Cost of Delay]]:延迟成本,业务价值+时间关键性+风险与机会
|
||||
- [[CTP]]:Cloud Transformation Program,云转型计划
|
||||
- [[Business Value]]:业务价值量化指标
|
||||
- [[Demand Manager]]:需求经理,负责捕获业务利益
|
||||
- [[Delivery Manager]]:交付经理,负责估算工作规模
|
||||
|
||||
## Key Entities
|
||||
- [[OpenText]]:主办 Public Cloud Learning Sessions 的企业内容管理公司
|
||||
|
||||
## Connections
|
||||
- [[CTP]] ← depends_on ← [[Value Delivery]]
|
||||
- [[Demand Manager]] ← captures ← [[Business Value]]
|
||||
- [[WSJF]] ← prioritizes ← [[CTP Work]]
|
||||
|
||||
## Contradictions
|
||||
- (暂无)
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: "CTP Topic 69 Best Practices for Migrating On-Premises (IOD) Virtual Machines to VMware Cloud on AWS"
|
||||
type: source
|
||||
tags: [VMware, Migration, VMWare-Cloud-AWS, CTP]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-69-best-practices-for-migrating-on-premises-iod-virtual-machines-to-vm.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:将本地虚拟机迁移到 VMware Cloud on AWS 的最佳实践
|
||||
- 问题域:混合云迁移、网络连接、安全配置
|
||||
- 方法/机制:HCX(Hybrid Cloud Extender)多云管理、Direct Connect 直连、CCOE 迁移脚本
|
||||
- 结论/价值:通过 VMware Cloud 实现无缝迁移,最小化改动、降低停机时间
|
||||
|
||||
## Key Claims
|
||||
- VMware Cloud 环境托管在 AWS infrastructure 上运行,提供 vSphere、connectivity 和 firewalls
|
||||
- 通过 Direct Connect 连接到 Frankfurt AWS region,使用虚拟 Transit Gateway 实现无缝迁移连接
|
||||
- HCX 支持每次迁移最多 200 台 VM,实现 on-premises vSphere 和 SDDC 的双向可视化管理
|
||||
- 迁移成本包括数据出站费用,SDDC 数量和 region 决定最终成本
|
||||
- 两种迁移方法:VMware Cloud UI 方法和 CCOE 团队开发的 oversell 自动化脚本
|
||||
|
||||
## Key Quotes
|
||||
> "The session covers best practices for migrating on-premises virtual machines to VMware Cloud on AWS, based on experience and consultant support from VMware."
|
||||
|
||||
> "Anything which leaves definitely attracts cost." — 数据离开云环境会产生费用
|
||||
|
||||
> "It hardly takes a VM migration with few minutes, which will enable them operated in the cloud infrastructure."
|
||||
|
||||
## Key Concepts
|
||||
- [[VMware-Cloud-on-AWS]]:在 AWS 硬件上原生运行 vSphere 的 VMware 云服务
|
||||
- [[HCX]]:Hybrid Cloud Extender,实现多云管理的工具
|
||||
- [[SDDC]]:Software-Defined Data Center,由 VMware 管理的集群和 ESX nodes(EC2 bare metal instances)
|
||||
- [[Direct-Connect]]:AWS 直连服务,连接本地云到 AWS region
|
||||
- [[CCOE]]:Cloud Center of Excellence,推动云采纳和治理的核心组织
|
||||
|
||||
## Key Entities
|
||||
- [[VMware]]:云虚拟化解决方案提供商
|
||||
- [[AWS]]:公有云平台
|
||||
- [[ESX]]:VMware vSphere 虚拟化平台的 hypervisor
|
||||
|
||||
## Connections
|
||||
- [[VMware-Cloud-on-AWS]] ← runs_on ← [[AWS]]
|
||||
- [[HCX]] ← manages ← [[SDDC]]
|
||||
- [[Direct-Connect]] ← connects ← [[VMware-Cloud-on-AWS]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[ctp-topic-43-vmware-cloud-on-aws]] 冲突:
|
||||
- 冲突点:该 topic 更专注于 VMware Cloud 架构,本次 topic 侧重迁移实践
|
||||
- 当前观点:通过 HCX 实现无缝迁移,最小化改动
|
||||
- 对方观点:VMware Cloud 架构设计和部署模式
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
title: "Public Cloud Learning Sessions (OpenText) - Evolving from DR to Recovery Assurance"
|
||||
type: source
|
||||
tags: [OpenText, DR, Recovery, BCP, SRE]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:灾难恢复(DR)向恢复保障(Recovery Assurance)的演进
|
||||
- 问题域:企业级 DR 策略改进与 SRE 实践
|
||||
- 方法/机制:通过设计、软件、构建、环境四个维度构建恢复保障能力
|
||||
- 结论/价值:从被动响应式测试转向主动式恢复保障架构
|
||||
|
||||
## Key Claims
|
||||
- DR 需要从被动响应转向Recovery Assurance的主动式架构
|
||||
- RTO(恢复时间目标)和RPO(恢复点目标)是DR策略的核心指标
|
||||
- 恢复保障应是设计原则,而非事后补救
|
||||
- SRE和可观测性工程是提升恢复能力的关键技术
|
||||
|
||||
## Key Quotes
|
||||
> "CrowdStrike was not us, but we have had some disruptions." — Jim Rose, 提及基础设施安全事件对DR策略的影响
|
||||
|
||||
> "Every person who is a SME on some part of this has to be involved in developing a plan." — Jim Rose, 描述DR测试的复杂性
|
||||
|
||||
## Key Concepts
|
||||
- [[Recovery Assurance]]:恢复保障,从设计层面确保系统具备恢复能力
|
||||
- [[SRE]]:站点可靠性工程,将软件工程方法应用于运维
|
||||
- [[Observability Engineering]]:可观测性工程,通过持续监控理解系统健康状态
|
||||
|
||||
## Key Entities
|
||||
- [[OpenText]]:企业解决方案公司,主办本次学习活动
|
||||
- [[Jim Rose]]:演讲者,DR/Recovery Assurance专家
|
||||
- [[CrowdStrike]]:安全公司,其安全事件推动了行业对DR的重视
|
||||
|
||||
## Connections
|
||||
- [[DR]] ← evolves_to ← [[Recovery Assurance]]
|
||||
- [[RTO]] ← core_metric ← [[Recovery Assurance]]
|
||||
- [[RPO]] ← core_metric ← [[Recovery Assurance]]
|
||||
- [[SRE]] ← enables ← [[Recovery Assurance]]
|
||||
@@ -0,0 +1,67 @@
|
||||
---
|
||||
title: "Public Cloud Learning Sessions (OpenText) - GitHub Enterprise to GitLab migration - 20240625"
|
||||
type: source
|
||||
tags:
|
||||
- GitHub
|
||||
- GitLab
|
||||
- Migration
|
||||
- OpenText
|
||||
date: 2024-06-25
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:OpenText 将代码仓库从 GitHub Enterprise 迁移到 GitLab
|
||||
- 问题域:企业级源代码管理平台迁移
|
||||
- 方法/机制:self-serve 模式,团队自行定义需求并转换 CI/CD 管道
|
||||
- 结论/价值:GitHub 许可证12月底到期不再续约,GitLab 许可证覆盖8500用户,Project Thor 整合 Micro Focus 和 OpenText 工具,GitLab 作为源代码控制的集中系统
|
||||
|
||||
## Key Claims
|
||||
- GitHub Enterprise 许可证将于12月底到期,公司决定不再续约
|
||||
- GitLab 许可证覆盖最多8500名用户
|
||||
- Project Thor 目标是将 Micro Focus 和 OpenText 工具集成,GitLab 作为集中式源代码控制系统
|
||||
- Build Hub 团队管理 GitLab 等中央工具,为软件交付管道提供支持
|
||||
- 迁移方式为 self-serve,各团队定义自身需求并规划迁移和管道转换
|
||||
|
||||
## Key Quotes
|
||||
> "Each team will define what they have in GitHub today, how they're using it, and they will plan to move it and change their pipelines."
|
||||
|
||||
> "The current solution that is working and is efficient and is actually reporting to scale."
|
||||
|
||||
## Key Concepts
|
||||
- [[GitHub-Enterprise]] → [[GitLab]] 迁移的两种方式:mirroring(同步)和 shift and lift(复制代码并转换管道)
|
||||
- [[Build-Hub]]:管理 GitLab 等中央工具的团队,为软件交付管道提供支持
|
||||
- [[Project-Thor]]:整合 Micro Focus 和 OpenText 工具的项目,GitLab 作为集中式源代码控制
|
||||
- [[PHT]]:Product Hub platform,GitLab 仓库权限控制平台
|
||||
- [[Service-Account-Standard]]:服务账户必须关联到个人,密码有有效期
|
||||
|
||||
## Key Entities
|
||||
- [[OpenText]] — 企业内容管理软件公司,主办 Public Cloud Learning Sessions
|
||||
- [[GitHub]] — 全球最大代码托管平台,Enterprise 版本许可证即将到期
|
||||
- [[GitLab]] — 代码托管和 DevOps 平台,将作为新的集中式源代码控制系统
|
||||
|
||||
## Connections
|
||||
- [[OpenText]] ← hosts ← [[Public-Cloud-Learning-Sessions]]
|
||||
- [[GitHub-Enterprise]] → replaced_by → [[GitLab]]
|
||||
- [[Build-Hub]] ← supports ← [[Project-Thor]]
|
||||
- [[PHT]] ← controls ← [[GitLab]] permissions
|
||||
|
||||
## Contradictions
|
||||
- (暂无)
|
||||
|
||||
## Implementation Steps
|
||||
1. 安装 GitLab 插件
|
||||
2. 早期访问 GitLab
|
||||
3. 映射仓库到 PHT
|
||||
4. 设置服务账户
|
||||
5. 更新管道
|
||||
|
||||
## Network Connectivity
|
||||
- GitLab proxy 位于 Brook Park,可通过 SD1 访问
|
||||
- 商业实例连接 GitLab 可能需要 GIS 团队批准例外
|
||||
|
||||
## Migration Tracking
|
||||
- 通过 PHT 跟踪,定期向开发经理和构建倡导者更新进度
|
||||
- 规划指南:清点 GitHub 资产、识别管道、了解网络连接
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: "Public Cloud Learning Sessions (OpenText)- Product Hub (PHT) Overview and Q&A - 20240806"
|
||||
type: source
|
||||
tags:
|
||||
- Product-Hub
|
||||
- PHT
|
||||
- OpenText
|
||||
- cloud-learning
|
||||
date: 2026-04-19
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-product-hub-pht-overview-and-qa-20240806.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:Product Hub (PHT) 产品层级追踪器概述与问答
|
||||
- 问题域:OpenText 云产品管理平台的产品注册、层级结构和权限管理
|
||||
- 方法/机制:通过自助服务流程请求新产品,层级结构管理(业务单元→业务线→产品),集成外部系统(PSMQ、P2M、ITLS、Backstage)
|
||||
- 结论/价值:PHT 提供统一的产品信息管理,通过标准化的产品请求流程和层级结构,实现产品元数据的集中存储和外部系统集成
|
||||
|
||||
## Key Claims
|
||||
- Product Hub (PHT) 是产品层级追踪器,存储官方产品和部门信息(业务单元、业务线),与官方产品命名注册表中的母版产品不同
|
||||
- 产品是具有独立 CI/CD 流水线或发布周期的软件分发,如果组件需要自己的 CI/CD 流水线则应作为产品创建
|
||||
- 层级结构包括业务单元(有工程和 PM 负责人)、业务线(有所有者和 PM 负责人)、产品(由产品和开发经理管理,与母版产品关联)
|
||||
- 请求新产品是自助流程,提交后由业务线所有者审批;产品状态包括活跃、维护模式和非活跃
|
||||
- GitLab 中源仓库创建需要 24 小时才能在 PHT 中反映,空的组/仓库无法搜索
|
||||
|
||||
## Key Quotes
|
||||
> "A product is a software distribution with its own CI/CD pipeline or release cycle. If a component needs its own cycle, like its own CI/CD pipeline or its own distribution, then we may treat that particular component or module as a product."
|
||||
|
||||
> "Requesting for a new product is a self-serve process; after submission, it goes to LOB approval, where the line of business owner reviews it."
|
||||
|
||||
> "Source repo creation in GitLab takes 24 hours to reflect in PhD, and empty groups/repositories cannot be searched."
|
||||
|
||||
## Key Concepts
|
||||
- [[Product-Hub-PHT]]:Product Hub 产品层级追踪器,OpenText 产品信息管理平台
|
||||
- [[Product]]:具有独立 CI/CD 流水线或发布周期的软件分发
|
||||
- [[Component]]:没有 CI/CD 流水线的库,可能属于某个产品
|
||||
- [[Business-Unit]]:业务单元,产品层级结构的最高层
|
||||
- [[Line-of-Business]]:业务线,业务单元下的产品组织单元
|
||||
- [[Master-Product]]:母版产品,官方产品命名注册表中的产品定义
|
||||
|
||||
## Key Entities
|
||||
- [[OpenText]]:企业内容管理软件公司,主办 Public Cloud Learning Sessions
|
||||
|
||||
## Connections
|
||||
- [[Product]] ← has_parent ← [[Master-Product]]
|
||||
- [[Product]] ← belongs_to ← [[Line-of-Business]]
|
||||
- [[Line-of-Business]] ← belongs_to ← [[Business-Unit]]
|
||||
- [[Product]] ← integrates_with ← [[PSMQ]]
|
||||
- [[Product]] ← integrates_with ← [[P2M]]
|
||||
- [[Product]] ← integrates_with ← [[ITLS]]
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
title: "Public Cloud Learning Sessions - OpenText Tagging Standard V2 - 20250429 170111 Meeting Recording"
|
||||
type: source
|
||||
tags:
|
||||
- OpenText
|
||||
- Tagging-Standard
|
||||
- Cloud-DevOps
|
||||
- Meeting
|
||||
date: 2026-04-19
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meet.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:OpenText Tagging Standard V2(标签标准 V2 版),为云资源、容器镜像和 Kubernetes 对象定义标准化标签
|
||||
- 问题域:云资源标签标准化、成本优化、风险降低、自动化效率提升
|
||||
- 方法/机制:
|
||||
- 使用小写下划线语法(如 `ot_business_unit`)
|
||||
- 前缀标签确保语义明确(OT_ 用于云标签,app.opentext.com 用于 Kubernetes 标签,com.opentext.image 用于容器镜像标签)
|
||||
- 明确 customer(客户)和 tenant(租户)概念
|
||||
- 区分 environment(OpenText 视角)和 service instance(客户视角)
|
||||
- 结论/价值:帮助组织实现成本优化、风险降低和自动化效率提升,当前 OpenText 管理约 3,500 个云账号,跨越 48 种 landing zone 类型
|
||||
|
||||
## Key Claims
|
||||
- 标签标准三大驱动因素:通过成本优化省钱、通过轻松识别技术联系人降低风险、通过标签作为过滤器和选择器提高自动化效率
|
||||
- 标签标准范围包括:云账号、云资源(计算、存储、网络)、Kubernetes 对象(namespace、pod、deployment、service、configmap)、容器镜像
|
||||
- 最佳实践:使用 IaC(如 Terraform)自动化标签创建和维护、创建检查和报告检测缺失标签、避免在标签中存储敏感数据
|
||||
|
||||
## Key Quotes
|
||||
> "It is about taking resources and you will learn more in the presentation about what kinds of object and what exactly and so on."
|
||||
> "The standard helps with cost allocation, improved security and compliance, cloud service delivery, and resource organization."
|
||||
|
||||
## Key Concepts
|
||||
- [[Tagging-Methodology]]:标签方法论,通过为资源定义标准化的元数据实现自动化管理和安全策略执行
|
||||
- [[Terraform]]:基础设施即代码工具,用于自动化标签创建和维护
|
||||
- [[Kubernetes]]:开源容器编排平台,本次标准的应用对象之一
|
||||
|
||||
## Key Entities
|
||||
- [[OpenText]]:企业内容管理软件公司,主办本次学习会议
|
||||
- Martin Rosler:本次会议演讲者,介绍 OpenText Tagging Standard V2
|
||||
- Phenops:标签标准发起团队,2023 年启动该标准
|
||||
|
||||
## Connections
|
||||
- [[OpenText]] ← hosts ← [[Public Cloud Learning Sessions]]
|
||||
- [[Tagging-Methodology]] ← applies_to ← [[Terraform]]
|
||||
- [[Tagging-Methodology]] ← applies_to ← [[Kubernetes]]
|
||||
|
||||
## Contradictions
|
||||
- (暂无)
|
||||
@@ -0,0 +1,48 @@
|
||||
---
|
||||
title: "Public Cloud Learning Sessions (OpenText)- Thor Platform & Flows - 20241210 160056-Meeting Recording"
|
||||
type: source
|
||||
tags: [Thor, Platform, OpenText, DevOps, SRE]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:Project Thor 平台架构与供应链数据流
|
||||
- 问题域:OpenText 云平台标准化、工具整合、供应链安全
|
||||
- 方法/机制:五支柱框架(敏捷周期管理、产品发布治理、Developer Portal、Security Governance、Build Hub)、GitLab + Artifactory 工具整合、代码签名流程
|
||||
- 结论/价值:统一工具链标准、提升开发者体验、增强供应链安全
|
||||
|
||||
## Key Claims
|
||||
- Project Thor 的五大支柱:敏捷和正确的周期管理、产品和发布治理、Developer Portal(Backstage)、Security 作为治理、Build Hub
|
||||
- "供应链的核心是我们的源代码,我们的 IP,托管在 GitLab 中"
|
||||
- 当前状态:源代码从 GitLab 流经制造流程(build farms)到 Artifactory,最终到达客户环境
|
||||
|
||||
## Key Quotes
|
||||
> "We are trying to standardize in GitLab, Artifactory, PMS and UCMDB are backend services that started to grow and will grow further for supply chain security."
|
||||
|
||||
## Key Concepts
|
||||
- [[Project Thor]]:OpenText 云平台标准化项目,五大支柱框架
|
||||
- [[GitLab]]:源代码管理和 CI/CD 平台
|
||||
- [[Artifactory]]:制品仓库管理
|
||||
- [[Source Code Supply Chain]]:源代码供应链,从 GitLab 到 Artifactory 的流程
|
||||
- [[GitLab Proxy]]:GitLab 代理,用于工具间数据流
|
||||
- [[GitLab Geo]]:GitLab 地理复制,用于业务连续性
|
||||
- [[Code Signing]]:代码签名,确保软件完整性
|
||||
- [[Developer Portal]]:开发者门户,基于 Backstage
|
||||
- [[Build Hub]]:构建中心,统一构建环境
|
||||
- [[Supply Chain Security]]:供应链安全
|
||||
|
||||
## Key Entities
|
||||
- [[Arnold Dacan]]:OpenText 技术专家,Thor Platform 演讲者
|
||||
|
||||
## Connections
|
||||
- [[GitLab]] ← hosts ← [[Source Code Supply Chain]]
|
||||
- [[Artifactory]] ← stores ← [[Build Hub]]
|
||||
- [[Project Thor]] ← implements ← [[Supply Chain Security]]
|
||||
|
||||
## Geographical Distribution
|
||||
- 主要工具、源代码和构建资源位于 Brook Park
|
||||
- Sacramento 用于灾难恢复和业务连续性
|
||||
- 区分传统 Micro Focus 网络和 OpenText 网络
|
||||
@@ -0,0 +1,101 @@
|
||||
---
|
||||
title: "Public Cloud Learning Sessions - Tagging Standards for all hyperscalers - 20240123 160135 Meeting Recording"
|
||||
type: source
|
||||
tags:
|
||||
- Tagging-Standard
|
||||
- FinOps
|
||||
- Cloud-Governance
|
||||
- OpenText
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-tagging-standards-for-all-hyperscalers-20240123-1.md]]
|
||||
|
||||
## Summary
|
||||
|
||||
- **核心主题**:建立跨 AWS、GCP、Azure 三大云服务商的统一标签标准
|
||||
- **问题域**:云成本优化、资源治理、FinOps 实践
|
||||
- **方法/机制**:通过标准化标签(Tag)实现成本分配、资源优化、责任追踪和分类管理
|
||||
- **结论/价值**:将云浪费从行业平均 30% 降至 15%,预计年省 2500 万美元,同时提升可持续性
|
||||
|
||||
## Key Claims
|
||||
|
||||
- 统一标签标准是云成本优化的基础,可避免临时标签映射的混乱管理
|
||||
- 标签需在计费控制台启用后才会包含在成本和使用报告中
|
||||
- 采用 GCP 的限制性字符集(小写、数字、连字符、下划线)作为最低通用标准
|
||||
- 标签前缀使用 OT_ 进行区分,例外情况包括 environment、BU、cost center
|
||||
- 99% 资源标签合规率可通过 SCP(Service Control Policies)或标签策略强制执行
|
||||
|
||||
## Key Quotes
|
||||
|
||||
> "If we can agree the tags that need to go here, we don't have to do this and we can get out the analysis results." — 统一标签的价值在于避免临时映射
|
||||
|
||||
> "Typically what you do is almost every module that you've got inside Terraform, there is a tags parameter that you could use." — Terraform 中设置标签的标准做法
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- [[Tagging-Methodology]]:通过标准化标签实现资源元数据管理的方法论
|
||||
- [[FinOps]]:云财务运营,整合财务管理与资源优化
|
||||
- [[Service-Control-Policies]]:AWS 组织策略,用于强制标签合规
|
||||
|
||||
## Key Entities
|
||||
|
||||
- [[Tom-Bice]]:OpenText 财务组织负责人,标签标准制定发起人
|
||||
- [[Phenops]]:OpenText 团队,2023 年发起标签标准化工作
|
||||
- [[OpenText]]:企业内容管理软件公司,主办 Public Cloud Learning Sessions
|
||||
- [[AWS]]:Amazon Web Services,三大云服务商之一
|
||||
- [[GCP]]:Google Cloud Platform,三大云服务商之一
|
||||
- [[Azure]]:Microsoft Azure,三大云服务商之一
|
||||
- [[Terraform]]:基础设施即代码工具,用于标签设置
|
||||
|
||||
## Connections
|
||||
|
||||
- [[Tom-Bice]] ← leads ← [[Tagging-Standard]]
|
||||
- [[Phenops]] ← initiated ← [[Tagging-Standard]]
|
||||
- [[OpenText]] ← hosts ← [[Public-Cloud-Learning-Sessions]]
|
||||
- [[Tagging-Standard]] → enables → [[FinOps]]
|
||||
- [[Tagging-Standard]] → enforces → [[Service-Control-Policies]]
|
||||
|
||||
## Contradictions
|
||||
|
||||
- 无明显冲突
|
||||
|
||||
---
|
||||
|
||||
## 附录:标签标准详情
|
||||
|
||||
### 目标
|
||||
|
||||
- 支持关键业务报表
|
||||
- 适用于所有云服务商的所有账户
|
||||
- 实际可行,快速实施
|
||||
|
||||
### 术语
|
||||
|
||||
- Tag(AWS/Azure):标签
|
||||
- Label(Google Cloud):标签
|
||||
|
||||
### 建议标签
|
||||
|
||||
| 标签名称 | 描述 |
|
||||
|---------|------|
|
||||
| business_unit (BU) | 业务单元 |
|
||||
| OT_technical_contact | 技术联系人 |
|
||||
| cost_center | 成本中心 |
|
||||
| customer | 客户 |
|
||||
| tenant | 租户 |
|
||||
| environment | 环境(生产/实验室等) |
|
||||
| OT_master_product | 主产品 |
|
||||
| custom_fields | 自定义字段 |
|
||||
| platform | 平台 |
|
||||
| cost_type | 成本类型 |
|
||||
| customer_data | 数据分类 |
|
||||
|
||||
### 非必需标签
|
||||
|
||||
- account:可直接获取
|
||||
- region:可直接获取
|
||||
- hyperscaler:可直接获取
|
||||
- resource_name:可直接获取
|
||||
Reference in New Issue
Block a user