Nex-opensourcehorray/media-company-portfolio

# 流媒体平台：本地到 AWS 的迁移架构 ## 项目概述 本作品集项目记录了将本地流媒体平台迁移到 Amazon Web Services 的已完成架构、迁移规划、安全、验证和运维设计工作。 最终目标架构旨在支持经过身份验证的应用程序访问、直播、视频点播 (VOD)、字幕转录与翻译、私有媒体源站、全球内容分发、集中监控以及安全治理。 该架构使用托管式和无服务器 AWS 服务，以减少基础设施管理开销，并提高弹性、可扩展性、可观测性和运维一致性。 此公开存储库代表最终的架构和文档基线。客户身份识别信息、特定环境的生产值以及敏感的运维证据已被排除或进行匿名化处理。 ## 项目状态 | 领域 | 状态 | 本存储库中的证据 | | --- | --- | --- | | 现状评估 | 完成 | 现状架构图和记录的风险分析 | | 目标 AWS 架构 | 完成 | 整体架构图和功能流程图 | | 业务和服务映射 | 完成 | 可用性、可扩展性、成本、运维和安全映射 | | 迁移规划 | 文档基线完成 | `docs/MIGRATION_PLAN.md` | | 安全标准 | 文档基线完成 | `docs/SECURITY.md` | | 验证规划 | 文档基线完成 | `docs/VALIDATION.md` | | 生产运维手册 | 文档基线完成 | `docs/RUNBOOK.md` | | 基础设施即代码 | 独立的实施工作流 | 结构和实施要求记录在 `infrastructure/` 下 | | 部署和验证证据 | 未公开表示 | 排除或匿名化了特定环境或敏感的证据 | | 客户生产迁移 | 未公开表示 | 为保密起见已排除或进行匿名化处理 | **状态说明：** “文档基线完成”意味着用于架构和规划审查的公开作品集材料已完整。这本身并不声明每个生产环境的值、审批记录或部署产物都是公开可用的。 ## 我的贡献 对于匿名化的作品集材料，我完成了以下工作： - 评估了可用的现有架构，并识别了其在可用性、可扩展性、同步和运维方面的主要风险。 - 分析了塑造迁移设计的业务目标和非功能性需求。 - 选择并映射了用于应用程序访问、直播、VOD 处理、字幕处理、内容分发、安全和监控的 AWS 服务。 - 设计了目标 AWS 架构，并将其分解为六个功能流程。 - 制定了分阶段迁移方案，包括试点、切换、稳定、恢复和回滚的考量。 - 定义了安全、监控、治理和恢复的控制措施。 - 准备了验证标准和生产运维手册结构。 - 制作了经过净化处理的架构图和辅助作品集文档。 我的贡献涵盖了架构评估、解决方案设计、迁移规划、安全和运维规划以及文档编写。实施或生产迁移的主张应由授权的部署和验证证据单独支持。 ## 业务目标 该迁移计划旨在： 1. 提高平台的可用性和弹性。 2. 根据多变的观众需求进行弹性扩缩容。 3. 通过托管服务和自动化减少手动的基础设施管理。 4. 优化媒体存储、处理和交付成本。 5. 加强安全、监控、审计和治理。 6. 提供全球分布、低延迟的媒体交付。 **最终的架构提供了一个安全、高可用且具备全球可扩展性的流媒体平台，同时赋予组织更大的灵活性来扩展其数字媒体服务。** ## 2. 业务标准与服务映射 ### 2.1 高可用性和弹性 **业务需求：** 流媒体平台必须提供至少 99.9% 的服务可用性，并尽量减少对直播和点播内容交付的中断。 **AWS 服务映射：** - **AWS Elemental MediaLive – Standard Class：** 直播频道使用两条独立的处理 pipeline。这提供了 pipeline 冗余，并降低了因单个编码器或基础设施故障导致广播中断的风险。 - **AWS Elemental MediaPackage：** MediaPackage 接收来自 MediaLive 的编码流，并为其准备多种流媒体格式进行分发。它提供了一个托管的源站，并有助于维护可靠的流封装和分发。 - **Amazon S3：** VOD 源文件、处理过的媒体资产、字幕和支持性内容存储在 Amazon S3 中，它提供了持久且可扩展的对象存储。 - **Amazon CloudFront：** CloudFront 通过全球分布的边缘节点分发直播和 VOD 内容。缓存的内容可以更靠近观众进行服务，从而提高性能并减轻源站服务的负载。 - **Amazon Route 53：** Route 53 提供高可用的 DNS 解析，并可以在需要时支持基于健康检查或故障转移的路由。 这些服务共同消除了现有环境中的几个单点故障，并提供了更具弹性的内容处理和交付路径。 ### 2.2 可扩展性和不可预测的受众需求 **业务需求：** 预期的在线观众人数尚未明确确立。因此，平台必须能够容纳低流量时段和突然的需求激增，而无需进行大量的手动容量规划。 **AWS 服务映射：** - **Amazon CloudFront：** CloudFront 在 AWS 边缘节点之间扩容内容交付，并在请求到达源站之前吸收大部分观众流量。 - **Amazon API Gateway：** API Gateway 为应用程序 API 提供了一个托管且可扩展的入口点，例如用户配置、内容目录、字幕选择和播放授权请求。 - **AWS Lambda：** Lambda 会根据传入的事件和 API 请求自动进行扩缩容。它可以支持媒体处理编排、元数据更新、字幕工作流和应用程序后端功能，而无需持续运行服务器。 - **Amazon DynamoDB – 按需容量模式：** DynamoDB 可以存储媒体元数据、观众偏好、字幕映射和处理状态信息。在平台的早期阶段，按需容量非常适用，因为流量模式尚不确定，并且数据库可以根据应用程序需求自动扩缩容。 这种方法允许组织在不投入大量预置基础设施的情况下启动平台。 ### 2.3 成本优化 **业务需求：** 由于初始受众规模和长期内容消费模式尚不确定，组织希望最大程度地减少不必要的云支出。 **AWS 服务映射：** - **Amazon DynamoDB 按需容量：** 企业为消耗的数据库请求付费，而不是在低需求期间维持预置的读写容量。 - **Amazon S3 Lifecycle Policies：** 生命周期规则可以自动将较旧或较少访问的媒体资产转换为成本更低的存储类别。保留和删除规则也可以应用于临时摄取文件、中间处理输出和过期内容。 - **AWS Lambda 和 Amazon API Gateway：** 基于请求的定价避免了在工作负载间歇性或流量较低时持续运行应用服务器的成本。 - **Amazon CloudFront 缓存：** 经常请求的媒体片段和支持文件会在边缘节点进行缓存，从而减少对源站的重复请求，并降低源站处理和数据传输的要求。 - **AWS Elemental MediaConvert：** MediaConvert 提供托管的、基于任务的视频转码。组织只需为已完成的处理工作付费，而无需运营永久的转码集群。 - **AWS Cost Explorer 和 AWS Budgets：** Cost Explorer 可用于按服务、账户或标签分析支出，而 AWS Budgets 可以在实际或预测支出超过商定的阈值时通知利益相关者。 这些控制措施建立了一种基于消耗的成本模型，同时提供了随着平台增长来监控和管理支出的机制。 ### 2.4 卓越运维和自动化 **业务需求：** 该平台应减少手动管理，以便工程团队可以专注于安全、治理、服务改进和事件响应。 **AWS 服务映射：** - **托管媒体服务：** AWS Elemental MediaLive、MediaPackage 和 MediaConvert 减少了维护操作系统、编码服务器、编解码器包和自定义扩缩容机制的需求。 - **事件驱动处理：** Amazon S3 事件、Amazon EventBridge、AWS Step Functions 和 AWS Lambda 可以自动化执行媒体摄取、转码、转录、翻译、元数据更新和通知工作流。 - **Amazon CloudWatch：** CloudWatch 收集服务指标、应用程序日志和运维事件。当处理任务失败、API 错误增加或服务性能超过定义的阈值时，警报可以通知工程团队。 - **AWS CloudTrail：** CloudTrail 记录账户活动和 AWS API 操作，支持安全调查、运维故障排查和治理审查。 - **基础设施即代码：** Terraform 或 AWS CloudFormation 可用于创建可重复的环境，减少配置漂移，并确保基础设施变更受到版本控制和可审查。 自动化和集中式可观测性减少了运维工作量，同时提高了平台变更的一致性和可追溯性。 ### 2.5 安全和治理 **业务需求：** 迁移后的环境必须保护媒体资产、应用程序接口、观众信息和管理操作。 **AWS 服务映射：** - **AWS Identity and Access Management：** IAM 角色和策略为管理员、应用程序和 AWS 服务强制执行最低权限访问。 - **AWS Key Management Service：** AWS KMS 管理用于保护受支持的数据存储和应用程序资源的加密密钥。 - **AWS WAF：** WAF 保护 CloudFront 和 API Gateway endpoint 免受常见的应用层威胁，例如 SQL 注入、跨站脚本攻击、恶意机器人和异常请求模式。 - **AWS Shield：** AWS Shield 提供针对影响受支持的 AWS 边缘和应用程序服务的分布式拒绝服务攻击的保护。 - **Amazon S3 Block Public Access 和 CloudFront Origin Access Control：** 媒体存储桶保持私有，而授权内容通过 CloudFront 交付，而不是直接从 Amazon S3 公开。 - **AWS CloudTrail 和 AWS Config：** CloudTrail 记录账户活动，而 AWS Config 评估资源配置，并支持检测未经授权或不符合规范的更改。 这些服务跨身份、数据保护、应用程序访问、网络入口点、监控和治理建立了分层安全控制。 ## 3. 架构概述 - **现状（本地）：** ** ### 3.1 现状 – 本地架构 现有环境使用以单个启用缓存的应用服务器为中心的**混合本地架构**。如项目文档的“现状”部分所述，该架构代表了在迁移到目标 AWS 平台之前将要评估的遗留环境。 中心服务器支持七个客户端设备。所有客户端请求都指向该服务器，由其执行主要的应用程序处理、业务逻辑和数据处理操作。经常访问的信息存储在**内存缓存**（例如 RAM 或 Redis）中，这允许服务器更快地响应重复的读写请求，而无需每次都从持久性存储中检索相同的信息。 为了进行长期持久化，本地服务器通过 HTTPS 或 AWS SDK 安全连接到 AWS。增量数据、客户端信息、备份和归档文件被传输到 Amazon S3 存储桶。当本地缓存中没有所需信息时，也可以从 Amazon S3 检索数据并与本地服务器同步。因此，本地服务器仍然是主要的处理层，而 Amazon S3 主要提供持久性和增量存储。 尽管通过内存缓存提供了相对较快的访问速度，但该架构存在一些局限性。中心服务器代表了一个**单点故障**，因为所有客户端处理和缓存操作都依赖于这一台机器的可用性。硬件故障、操作系统问题、缓存故障或维护活动都可能中断所有连接客户端的服务。 该设计的可扩展性也有限。随着客户端、应用程序请求或媒体处理工作负载的增加，服务器可能会遇到 CPU、内存、磁盘和网络争用。扩展环境通常需要手动升级服务器或购买额外的基础设施。现有架构中没有显示负载均衡器、冗余的应用服务器或自动扩缩容功能。 此外，仅存储在内存中的信息是易失性的，可能会在服务器重新启动或发生故障时丢失。因此，组织必须维护内存缓存和 Amazon S3 之间可靠的同步。延迟或未成功的增量写入可能会在本地服务器和云存储之间产生不一致的数据。对互联网连接的依赖也意味着网络中断可能会延迟归档、同步、备份和数据检索操作。 总体而言，现有架构适用于规模较小且相对可预测的工作负载，但它引入了可用性、可扩展性、恢复和运维管理方面的风险。这些限制使其难以支持不可预测的受众增长和媒体流需求，这也是将处理、存储和内容交付功能迁移到托管且可扩展的 AWS 服务的主要理由。 ## 3.2 目标 AWS 架构 ### 整体架构  目标平台将应用程序访问、媒体处理、字幕处理、内容分发和横向安全控制分离开来。 ### 功能流程分解  | 流程 | 功能 | 主要 AWS 服务 | | ---- | ---------------------------------- | --------------------------------------------------------------------- | | F1 | 身份验证和应用程序 API | Route 53, API Gateway, AWS WAF, Cognito, Lambda, DynamoDB | | F2 | 直播流处理 | MediaLive, Transcribe Live, Translate, MediaPackage | | F3 | VOD 处理 | S3, EventBridge, Step Functions, MediaConvert, SQS | | F4 | 字幕处理 | Transcribe, Translate, S3, DynamoDB | | F5 | 内容分发 | CloudFront, MediaPackage, S3, Origin Access Control | | F6 | 安全和监控 | WAF, KMS, Firewall Manager, CloudWatch, CloudTrail, Config, GuardDuty | ## 4. 迁移策略 ### 4.1 迁移方法 此次迁移结合使用了**重新平台化**和**重构**，而不是直接在 AWS 中重现现有的本地环境。 核心媒体功能被重新平台化到托管的 AWS 服务上，而应用程序工作流被重构为无服务器和事件驱动的组件。这种方法减少了基础设施管理开销，提高了可扩展性，并使平台能够更有效地应对不可预测的观众需求。 主要的工作负载过渡包括： - **直播流处理：** 从本地编码基础设施重新平台化到 AWS Elemental MediaLive 和 AWS Elemental MediaPackage。 - **VOD 处理：** 使用 Amazon S3、Amazon EventBridge、AWS Step Functions、AWS Lambda 和 AWS Elemental MediaConvert 重构为事件驱动的工作流。 - **媒体存储：** 迁移到具有生命周期策略的私有 Amazon S3 存储桶，以实现长期的成本优化。 - **元数据和状态处理：** 在初始运行期间使用按需容量重新平台化到 Amazon DynamoDB。 - **应用程序 API：** 在适当的地方重构为使用 Amazon API Gateway 和 AWS Lambda。 - **字幕生成：** 使用 Amazon Transcribe、Amazon Translate、AWS Lambda 和 Amazon S3 实现自动化。 - **内容分发：** 迁移到 Amazon CloudFront，为直播流、VOD 资产和字幕文件提供全球分布、低延迟的分发。 ### 4.2 迁移阶段 #### 第一阶段 – 探索与评估 对现有环境进行评估，以确定： - 应用程序和基础设施依赖项。 - 直播流和 VOD 处理工作流。 - 媒体格式、编解码器、分辨率和存储要求。 - 网络带宽和连接要求。 - 元数据 schema 和数据库依赖项。 - 安全、隐私、保留和合规性要求。 - 恢复目标和可接受的服务中断时间。 评估结果将用于确定工作负载的优先级、估算迁移工作量、识别技术风险并建立可衡量的成功标准。 #### 第二阶段 – AWS 基础与登录区 在迁移生产工作负载之前，需准备具有以下内容的 AWS 环境： - 用于开发、测试、预发布和生产的独立账户或环境。 - 集中式身份和访问控制。 - 日志记录、审计、监控和成本管理服务。 - 加密密钥和安全策略。 - 私有 S3 存储桶和 CloudFront Origin Access Control。 - 用于可重复部署的基础设施即代码模板。 - 资源标签标准和预算通知。 这一基础确保在引入媒体资产或生产流量之前建立安全、治理和运维控制。 #### 第三阶段 – 试点迁移 首先迁移有限的试点工作负载。试点应包括具有代表性的媒体内容和非关键的直播或 VOD 工作流。 试点验证： - 媒体摄取和转码。 - 支持设备之间的播放兼容性。 - 字幕转录和翻译。 - API 和元数据处理。 - CloudFront 缓存和源站访问。 - 监控、警报和运维程序。 - 性能、安全性和预计的运营成本。 在开始生产迁移之前，应解决在试点期间识别出的问题。 #### 第四阶段 – 媒体和元数据迁移 现有的 VOD 资产以受控批次的方式传输到 Amazon S3。每次传输后都会验证文件校验和、对象计数、元数据和播放结果。 在必要时，可以使用 AWS DataSync 或分段上传过程来提高大型数据传输的可靠性。应首先迁移经常访问的内容，而归档内容可以稍后传输或直接放入适当的较低成本存储类别中。 应用程序元数据使用经过测试的转换和验证程序迁移到 DynamoDB 或另一个选定的目标数据库。 #### 第五阶段 – 应用程序和工作流迁移 应用程序服务以增量方式迁移，以降低运维风险。针对以下内容引入事件驱动工作流： - 媒体摄取。 - 转码。 - 缩略图生成。 - 转录和翻译。 - 元数据更新。 - 处理状态跟踪。 - 故障通知。 - 内容发布审批。 在此阶段，本地环境和 AWS 环境可以并行运行，以支持测试并减少个别迁移失败的影响。 #### 第六阶段 – 生产切换 在切换之前，项目团队应： 1. 完成媒体资产和元数据的最终同步。 2. 确认监控仪表板和警报正常运行。 3. 从多个位置和设备验证直播流和 VOD 播放。 4. 确认已测试安全、备份、恢复和运维手册。 5. 在需要 DNS 更改的地方减少 DNS 生存时间值。 6. 对受影响的生产系统建立临时冻结更改期。 7. 获得技术和业务利益相关者的正式批准。 然后将生产流量逐渐重定向到 AWS 环境。在整个切换期间，将密切监控关键服务指标——包括播放失败、API 错误、延迟、丢帧、处理失败和 CloudFront 错误率。 #### 第七阶段 – 稳定和优化 成功切换后，AWS 环境进入稳定期。在此期间，团队将审查： - 服务可用性和应用程序性能。 - 媒体处理的成功率和失败率。 - CloudFront 缓存有效性。 - 存储类别使用和生命周期规则。 - DynamoDB 容量和访问模式。 - 安全发现和配置更改。 - 实际支出与预算预测的比较。 只有在 AWS 平台成功运行了商定的验证期且所有回滚要求均已过期后，才应停用本地环境。 ### 4.3 验证和成功标准 当满足以下条件时，迁移即被视为成功： - 可以通过 AWS 平台交付直播和 VOD 内容，而不会出现不可接受的中断。 - 支持的媒体格式和字幕语言正常工作。 - 迁移的文件和元数据通过完整性检查。 - 应用程序性能满足商定的延迟和可用性目标。 - 安全和访问控制测试未产生任何未解决的关键发现。 - 监控、警报、备份和恢复程序按预期运行。 - 运营成本保持在批准的预算阈值内。 ### 4.4 回滚策略 在商定的回滚窗口期间，现有的本地平台保持可用。 如果 AWS 环境遇到严重的播放故障、不可接受的性能下降、数据完整性问题、安全问题或在批准的切换期内无法纠正的重复处理失败，则可能会启动回滚。 回滚过程包括： - 将流量重定向到现有的本地 endpoint。 - 恢复以前的 DNS 或路由配置。 - 停止向受影响的 AWS 工作流中摄取新媒体。 - 核对在切换期间创建的媒体资产和元数据。 - 在再次尝试迁移之前记录故障原因和纠正措施。 详细的切换和回滚说明应保存在 `/docs/RUNBOOK.md` 中。 ## 5. 安全部署与治理 ### 5.1 安全设计原则 目标环境遵循以下原则： - 最低权限访问。 - 纵深防御。 - 默认加密。 - 私有源站访问。 - 集中式日志记录和监控。 - 分离生产环境和非生产环境。 - 自动化的配置和合规性检查。 - 可追溯和可审查的基础设施变更。 应尽可能通过基础设施即代码来定义安全控制，以便可以一致地部署、审查和重现配置。 ### 5.2 身份和访问管理 AWS Identity and Access Management 角色用于应用程序组件、自动化工作流、管理员和部署 pipeline。 身份设计包括： - 最低权限 IAM 策略。 - 基于角色的访问，而不是长期的共享凭证。 - 特权用户的多因素身份验证。 - 分离管理、运维和只读职责。 - 服务和自动化进程的临时凭证。 - 定期审查未使用的权限、角色和访问密钥。 - 限制对生产资源和加密密钥的访问。 MediaLive、MediaConvert、Lambda、Step Functions 和其他 AWS 服务的服务角色应仅允许访问每个工作流所需的特定资源。 ### 5.3 网络和边缘安全 该架构主要使用托管的 AWS 服务，并且不直接将媒体存储桶暴露在公共互联网上。 公共入口点仅限于批准的服务，例如： - 用于媒体分发的 Amazon CloudFront。 - 用于应用程序 API 请求的 Amazon API Gateway。 - 需要时的 AWS Elemental MediaPackage endpoint。 AWS WAF 保护 CloudFront 和 API Gateway 免受常见的应用层攻击、恶意请求、机器人和异常请求模式的影响。AWS Shield 针对影响受支持 endpoint 的分布式拒绝服务攻击提供了额外的保护。 Amazon S3 Block Public Access 保持启用状态，并且 CloudFront Origin Access Control 限制访问，以便可以通过批准的 CloudFront 分发而不是直接从 S3 源站检索媒体对象。 如果 Lambda 函数需要访问私有资源，它们会被放置在具有严格安全组的私有子网中。在适当的情况下应使用 VPC endpoint，以减少对公共网络路径的依赖。 ### 5.4 数据保护 数据在其整个生命周期中都受到保护。 控制措施包括： - 在支持的地方使用由 AWS Key Management Service 管理的密钥进行静态加密。 - 使用 HTTPS 和 TLS 1.2 或更高版本进行传输中的数据加密。 - 具有公共访问屏蔽功能的私有 S3 存储桶。 - 对关键媒体、配置和字幕资产进行 S3 版本控制。 - 基于业务和监管要求的生命周期和保留策略。 - 通过密钥策略和 IAM 权限限制对 KMS 密钥的访问。 - 对应用程序密钥和敏感配置值进行加密。 - 安全删除或使临时摄取和处理文件过期。 除非经过适当的匿名化处理或获得批准，否则不应将生产数据复制到开发或测试环境中。 ### 5.5 应用程序和 API 保护 应用程序 API 通过 Amazon API Gateway 公开，并使用适当的授权、限流、请求验证和 AWS WAF 规则进行保护。 根据应用程序要求，播放授权可以使用已签名的 CloudFront URL、签名 cookie 或短期的访问 token，以减少受保护内容的未经授权分发。 敏感信息（例如 API 凭据、第三方集成密钥和数据库连接值）应存储在 AWS Secrets Manager 或 AWS Systems Manager Parameter Store 中，而不是嵌入在源代码或基础设施即代码模板中。 ### 5.6 日志记录、监控和检测 安全性和运维事件被集中记录和监控。 目标控制措施包括： - 用于 AWS 账户活动和 API 审计的 AWS CloudTrail。 - 用于应用程序日志、服务指标、仪表板和警报的 Amazon CloudWatch。 - 用于配置跟踪和合规性评估的 AWS Config。 - 用于分析被阻止和可疑请求的 AWS WAF 日志。 - 需要时，用于敏感存储桶操作的 Amazon S3 访问日志或 CloudTrail 数据事件。 - 针对未经授权的访问尝试、策略更改、处理失败、API 错误升高和异常流量模式的警报。 应根据运维、法律和合规性要求保护日志免遭未经授权的修改并予以保留。 ### 5.7 治理和变更管理 基础设施变更通过受版本控制的 Terraform 或 AWS CloudFormation 模板进行管理。 治理流程应要求： - 对基础设施变更进行同行审查。 - 在非生产环境中进行测试。 - 在生产部署之前获得批准。 - 用于所有权、环境、项目和成本分配的资源标签。 - AWS Budgets 和成本警报。 - 定期审查 IAM 和安全策略。 - 使用 AWS Config 进行自动化配置检查。 - 记录例外情况和接受的风险。 - 定期审查 AWS 服务限制和配额。 在使用多个 AWS 账户的情况下，AWS Organizations 和服务控制策略可以建立组织范围内的限制，并防止被禁止的操作。 ### 5.8 备份、恢复和事件响应 为媒体资产、元数据、配置和基础设施定义建立了备份和恢复控制措施。 恢复设计包括： - 对关键资产进行 S3 版本控制和适当的复制或备份控制。 - 针对重要元数据表的 DynamoDB 时间点恢复。 - 受版本控制的基础设施即代码模板。 - 记录在案的恢复程序。 - 经过测试的事件响应和回滚手册。 - 确定的恢复时间和恢复点目标。 - 定期的恢复演练。 应记录、调查和审查安全及运维事件，以确定纠正措施和对平台的改进。 ## 6. 存储库导航 - `/docs/MIGRATION_PLAN.md` - 完整的分阶段迁移历程。 - `/docs/RUNBOOK.md` - 切换策略和回滚程序。 - `/docs/SECURITY.md` - 数据保护和基础设施稳健性。 - `/docs/VALIDATION.md` - 切换策略和回滚程序。 - `/infrastructure/` - 用于部署的基础设施即代码模板。 ## 7. 如何部署（可选但推荐） 1. 克隆存储库。 2. 使用 `terraform init` 初始化环境或部署 CloudFormation 堆栈。 3. [任何其他所需的命令...]

标签：AWS, DPI, 云迁移, 媒体流媒体, 架构文档, 架构设计, 系统运维