如何构建您的内容技术栈

如何构建您的内容技术栈

由 Mux 赞助的 DEV 全球展示挑战赛：展示你的项目！

如何构建您的内容技术栈

战略 - 架构 - 工作流程 - DevOps

跳转至章节

• 概述
• 内容策略
• 内容架构
• 内容工作流程
• 内容开发运维
• 结论 

概述

在组织内部构建内容战略时，内容管理战略家经常会提到“内容堆栈”。在 Agility，我们更具体地将堆栈中的四个独立组件称为：内容战略、内容架构、内容工作流和内容 DevOps。

在当今互联互通的世界中，构建内容堆栈或许是现代企业最重要的举措之一。品牌推广和信息传递的效果直接取决于内容堆栈的运行状况，而这最终会转化为更高的用户参与度、更大的流量以及更高的转化率。构建高效的内容堆栈能够帮助企业在品牌信息传递方面快速响应，并提升可靠性。接下来，我们将逐一了解内容堆栈的各个组成部分。

内容栈是一个自顶向下的构建过程。我们从高层组件入手，然后逐步定义和实现底层元素。需要注意的是，在实现底层组件之后再修改高层组件可能会非常耗时耗力，因此我们必须确保一开始就走对方向。此外，我们也应该努力保持简单事物的简洁性，并尝试将复杂问题分解成更小、更简单的部分。

最高层级是内容策略。我们的策略旨在满足业务需求，并阐明最高层级的目标；我们需要对系统的运作方式有一个概览。在明确战略愿景和目标之后，我们可以着手研究工作的起点、最终交付成果以及中间的所有任务和检查点。 

我们的目标是编写一个引人入胜、全面详实的叙述，指导构建不同内容元素的架构模型。这便构成了内容架构。  

接下来，我们需要考虑这些内容最终要去哪里，我们称之为目标位置或输出位置。

随着我们不断深入研究每个端点的具体需求，我们的架构模型必然会随之调整。在规划内容流向的各个环节时，我们也应该思考未来的发展趋势——我们目前的决策是否基于一项可能很快消失或发生剧变的技术？我们将如何应对这些变化？如何增强系统的弹性，使其具备这种灵活性？ 

此时，我们必须考虑谁在何时对哪些内容元素进行哪些操作：

• 谁负责撰写内容？
• 谁批准的？
• 谁触发了导致内容流向终端的事件？

这叫做内容工作流程，它的核心在于人的因素。务必记住，这些人是内容的生命线，他们的经验至关重要。我们需要确保他们能够成功。

现在我们可以开始探讨内容如何在我们的技术栈中流动并输出到各个平台。我们称之为内容DevOps。这可能包括我们需要集成的工具、提供数据或接收数据的应用协议，以及需要实现的软件开发组件。

让我们更深入地了解一下我们技术栈的这四个层次，首先从内容策略开始。

内容策略

内容策略是内容体系中最重要的组成部分，也是首要组成部分。你可以把它想象成一个持续的、俯瞰全局的视角，它展现了整个体系应该如何运作。制定策略的过程，正是你确定所有真正重要、高层次问题的机会：

• 作为一家企业（或业务部门），您的战略目标是什么？
• 你的创意内容如何融入该策略并创造价值？
• 组织中的哪些部门将从这项战略中受益？
• 随着时间的推移，我们需要哪些团队来实施和维护我们战略的完整性？

提出这些问题（以及更多问题）将为您的内容堆栈的主要元素奠定基础。这确实是一个自上而下的流程；我们越能从宏观层面定义哪些因素能帮助您在未来取得成功，就越容易在未来持续取得成功。

有三个战略领域需要重点关注：

实例

“实例”是您 Agility 帐户的构建模块，它提供了一种将内容拆分成逻辑部分的方法。 

例如，在上图中，我们使用了 3 个实例来存储组织的所有数据，其中一个“主”实例用于存储公司数据、品牌信息，以及新闻、博客文章和新闻稿列表。您可能还需要使用 Agility 的实例来存储产品和服务以及活动和竞赛信息。

工具

数据处理工具正在迅速变化，但我们已经看到一些顶尖企业涌现，尤其是在上面提到的 4 个类别中：CRM、电子邮件营销/营销自动化，以及我们可以称之为“工作流自动化”的广泛类别。 

Agility 的灵活性使其能够轻松与这些平台集成。您的内容策略必须包含如何实现平台集成、希望哪些数据流经哪些工具以及这些数据需要进行哪些处理等内容。例如，您可能希望将博客文章同步到社交媒体帐户，或者集中管理徽标和品牌文件。

。

在上图中，我们可以绘制出数据如何从您的主要敏捷实例流向组织内的各种工具和输出目标。请注意，这只是一个可能场景的示例——您自己的内容架构将独一无二。正因如此，构建内容堆栈（包括制定详细的内容策略）的过程才显得尤为重要。

团队

人才是任何组织最宝贵的资产。那些日复一日与你并肩作战的人，正是推动组织前进的动力。 团队在内外部运作的效率，将决定任何内容策略的成败。 

短期内，重要的是确定需要哪些角色和职责才能启动项目。同时也要考虑到长期成功可能需要承担的职责。考虑这些角色，并决定这些职责是外部职责还是内部职责。

你不需要一次性把所有人召集到一个大房间里，但建立这些群体之间的良好关系对你大有裨益。如果你了解内容的战略目标、内容的撰写者、编辑者、开发人员的合作对象等等，作为审批人，你就能更轻松地做好自己的工作。 

一旦确定了团队和分配的角色，就可以着手处理内容架构问题了。

内容架构

构建一个经得起时间考验的高效内容架构绝非易事，但只要有指导，并充分了解谁将使用哪些内容（详见后续内容工作流程）以及他们的需求，我们就能打造出一个可扩展的架构。请记住，此时的努力终将获得回报，因为我们最初的架构规划将成为组织管理内容的基础。

在您根据人力资源和有状态 机制定义内容工作流之前，您将无法完整地定义内容架构。同样，在您执行内容 DevOps 清单的过程中，您可能需要向架构中添加组件。在某些情况下，可能需要添加一些您之前遗漏的数据，但请允许并预料到与不同团队之间会进行大量的沟通和协作。此外，还要警惕让内容堆栈中较低层级的需求过多地决定架构运作方式的陷阱。地基的形状需要容纳其他部分，但其自身也必须足够完整，才能支撑整个结构。

首先，我们将了解敏捷内容架构的组成部分。在下图所示的组件层中，我们可以看到两个不同的组件层——共享内容和页面。

共享内容

Agility 的共享内容部分就像一个内容数据库：它提供内容列表和单个内容项，可以按名称引用，并在任何你喜欢的地方重复使用。以前面的 3 个敏捷实例为例，其中第一个实例是主实例，包括企业内容和品牌。以下是我们如何使用主敏捷实例的方法。

我们已确定将高管团队简介、条款与条件以及招聘信息归入“企业内容”范畴。这些内容可能分别以列表（简介）、项目（条款与条件文档/副本）和列表（招聘信息）的形式呈现。同样，我们也确定了哪些类型的内容应归入“品牌”范畴。您可以轻松地与团队内部成员进行头脑风暴，提出对您而言重要的各种内容，然后进行有效的组织整理。

接下来，需要确定每种内容类型中需要采集哪些数据，这些数据具体是什么类型，以及它们之间可能存在怎样的关系。由于这本身就是一个很大的话题，而且每个组织的具体情况也不尽相同，因此本文档不会深入探讨这方面的规划。 

频道、网站地图、页面和模块

敏捷内容架构的真正优势在于它允许您创建多个临时层级结构。这其实就是“站点地图”的一种比较专业的说法，站点地图用于定义和管理网站上特定数字渠道内的页面。当然，我们希望能够使用所需的内容，但通常情况下，主要输出是网站。对于营销团队来说，让团队能够轻松地查找、编辑、审批和发布网站页面通常是首要任务，因此，确保架构的这一部分正确无误至关重要。

网站地图结构的重要组成部分包括：

• 数字渠道
  • 这些是站点地图可以放置的最高级别分组。您可以使用它来划分任何需要独立层级结构的内容。
• 网站地图
  • 每个频道可以有 1 个站点地图，但一个站点地图可以包含任意数量的页面，并且每个页面下面可以有任意数量的嵌套页面，由您决定。
  • 这为您的内容团队提供了极大的灵活性，让他们可以创建网站的整体结构。
• 页面模板
  • Agility 中的页面模板允许我们划分页面上可以放置内容的区域。例如，顶部区域/底部区域、左侧区域/右侧区域，或者第一列/第二列。 
  • 这使得编辑人员能够更好地控制内容的呈现方式，而无需访问任何代码，甚至无需任何开发经验。
• 模块定义
  • 模块定义与用于共享内容项的内容定义非常相似，只是它是专门为在页面上使用而设计的。
  • 当编辑人员使用页面模板构建页面时，他们可以从我们设置的任何模块定义中进行选择。
• 页
  • 就是现在！你之前在数据模型设置和配置方面所做的所有努力，现在终于开始真正发挥作用了。
  • 将页面添加到站点地图后，您的内容编辑人员就可以定义网站的导航结构和内容层级。选择一个模板，将一些模块拖放到可用区域中，即可开始使用。

内容工作流程

内容架构中最宝贵的要素是人。随着组织的发展，你的内容团队将成为你解决问题、取得成果的坚实后盾。如何才能让他们满意？倾听他们的意见。采纳他们的反馈，确保他们拥有成功所需的工具。了解他们每天的工作内容、角色和职能，确保你面面俱到。 

毋庸置疑，内容技术栈的这一部分代表着一段旅程，希望它永无止境。大多数内容管理系统的实施都被认为是失败的，因为实际使用该解决方案的团队没有获得充分的授权，无法发挥出最佳水平。 

你现在就有机会避免这些陷阱。

用例

打造卓越的内容工作流体验，所有环节都应从识别用例开始。用例是示例项目/操作，它概述了团队成员将如何实际完成工作。  

你可以通过以下几种方式来构思出优秀的用例：

• 与团队开会，集思广益。
  • 这或许应该是你的首选方案，它将为你带来大量关于如何增强团队能力的想法和知识。
  • 务必确保这些会议不要过多地纠缠于对现有工具的抱怨。这是推进新流程的机会——重点应该放在这上面。
• 观察团队工作情况并收集指标
  • 仔细观察一下你的团队目前是如何工作的。他们的行动步骤是什么？完成一项任务需要多长时间？每项任务包含多少个步骤？
  • 这些指标将帮助您确定衡量您希望在内容工作流程中实现的改进的方法。
• 基于内容架构创建空用例
  • 为确保您的内容架构的各个方面都涵盖在用例中，请仔细检查每种类型的共享内容、页面和模块定义，确保您的团队能够有效地应对每种情况。

您可能想知道，为什么我们在创建内容架构之前，没有在内容工作流程中创建这些用例。这是一个很好的问题。在很多情况下，启动项目时，您应该首先考虑团队的需求，然后再开始定义结构。然而，就内容架构而言，我们希望对内容策略的目标保持全局性的把握。 

一旦你开始集思广益地构思内容工作流用例，你可能会发现自己陷入了繁琐的细节之中，甚至与团队产生一些摩擦。我们的经验证明，根据你对系统所需实现目标的合理预测，为你的内容系统制定一个架构草案，能够极大地帮助你的团队专注于未来，而不是纠结于过去。

一定要利用创建用例的机会来验证您的内容架构。现在对该结构进行的任何更改都相对容易，至少与在开发 DevOps 流程之后进行更改相比是如此。

用户指南

用例一旦通过内容架构验证，其自然发展方向便是根据每个具体任务生成用户指南。这些指南通常针对特定角色，并概述组织内用户使用内容所需了解的各项任务。

用户指南通常会汇编成文档，但您也可以将它们添加到 Wiki 系统中。您可以将每份指南视为一份循序渐进的成功指南。一份优秀的用户指南可以帮助新用户快速上手系统，从而在您需要完成任务时节省大量时间和资源。

展望未来，随着系统的演进，务必将用户指南放在首位。我们经常看到一些内容架构沿用多年——我可以几乎肯定地说，自最初的用例和指南创建以来，人们最初执行的任务肯定已经发生了变化。因此，持续更新和完善这些工具将带来丰厚的回报。

内容开发运维

DevOps 将开发和运维流程整合到一个循环中，用于部署和更新支持我们在线资产的各种组件。这体现在一个持续重复的路径中，路径依次为：计划 > 创建 > 验证 > 打包 > 发布 > 配置 > 监控 > 计划。 这一流程重新定义了我们在线部署和维护代码的方式，因为它使我们能够快速、持续地迭代新功能和修复错误。

DevOps的兴起

DevOps 的概念近年来因其诸多优势而备受关注。

• 集中管理的源代码控制存储库服务
  • GitHub 等工具和其他托管代码存储库服务使得团队能够轻松利用复杂的代码工具和团队功能，而无需投入大量时间和成本。
  • 这些服务使内部团队和外部/外包团队能够以极低的 IT 开销协同工作。
• 在线包裹管理器
  • Node 包管理器 (npm.org)、nuget.org 和其他包管理器的出现，使得可重用代码模块得以普及。
  • 这使得开发团队能够快速地将行业标准的功能包集成到他们的代码中。
• 集中管理和托管的 DevOps 服务“管道”
  • GitHub Pipelines、Azure DevOps 和 AWS CodeDeploy 等工具已经变得非常流行，而且很容易使用。
  • 任何开发团队都可以轻松地实现代码部署机制的自动化，这样一旦代码被检入源代码控制库，就可以启动构建 > 测试 > 验证流程，然后发布管理团队就可以批准将该代码发布到生产部署环境。
• 使用 PaaS 技术的容器化托管
  • 让代码的构建和部署变得更容易固然很好，但如果没有灵活且可扩展的托管模型，所有的努力都将付诸东流。

借助 Docker/Kubernetes 等“容器化”应用程序以及 Azure 和 AWS 的 PaaS 产品，您的 DevOps 团队可以以可扩展且经济高效的方式快速启动满足您所有需求的部署端点。

您的 DevOps 策略

要制定 DevOps 战略，你需要考虑几个问题。以下几个问题可以帮助你入门：

• 谁将负责开发在线业务所需的软件组件？
• 随着时间的推移，这些代码文件的所有权将归谁所有？
• 代码将存储在哪里（本地部署还是托管服务）？
• 代码的构建/测试/审批/发布流程需要哪些步骤？
• 在每个责任层级，谁将对这一过程负责？
• 您将依赖哪些软件包和/或框架，以及存在哪些风险？

云托管与本地部署

对于每个组织而言，在DevOps方面面临的最大选择之一就是确定系统的部署位置。是部署在云端还是本地？这是一个至关重要的问题，它将影响后续的战略和战术决策。如果选择云部署，哪个云服务提供商最合适？是否存在可以节省成本的无服务器方案？ 

版本控制和发布

我们始终建议对每个内容堆栈都采用分阶段的方法，而这种方法论就包含了DevOps。系统架构需要确保定期发布计划的合理性，以便根据需要发布新功能和修复错误。

最灵活的 DevOps 策略将包含持续集成和持续交付的概念。 

速度、可靠性、灾难恢复和业务连续性

我们秉持着“一切皆快”的理念。速度是重中之重，在生产环境中绝不容妥协。务必尽早并频繁地强调，所有产品的响应时间都必须低于一秒。 

可靠性和正常运行时间也是重中之重——您需要确保您的在线服务和资产始终可用，并且如有必要，您需要能够将其作为指标来证明。现代 DevOps 策略将包含负载均衡和地理故障转移等概念，作为提高正常运行时间和可靠性的工具。

内容分发网络 (CDN) 也可用于加速网络服务，并提供 Web 应用程序防火墙 (WAF) 保护，帮助抵御分布式拒绝服务 (DDoS) 等攻击。CDN还可以帮助在流量高峰期保持速度。 

结论

我们生活在一个需要快速行动的世界。我们需要迅速制作原型，并将最初的想法转化为最终成果。我们必须充分了解流程运作和失效的原因。此外，我们还需要保持高效的工作节奏。作为个人和组织，我们都遵循着一种内在的韵律，这种韵律以日、周、月等周期性地涌动。 

您的内容堆栈是一个工具，可以帮助您将组织的节奏转化为成功所需的产出。我们已经探讨了内容策略、内容架构、内容工作流和内容DevOps的概念。深入剖析这些概念如何与您组织的想法相联系，既令人兴奋又充满挑战。

我们希望能够加入您的旅程。