Cloudways 平台如何帮助机构更好地交付项目

我们在我们的机构中​​花了数年时间完善我们的应用程序和 Web 开发项目管理流程。 在项目生命周期中有很多潜在的故障点，可能会导致客户关系的破裂。 作为服务提供商，我们有责任确保我们提供尽可能顺畅和稳定的交付过程。

我们希望帮助客户实现他们的目标，我们希望在第一份合同之后与他们建立长期关系。 您客户的终身价值不必停留在网络构建上。 如果做得好，一个有效的团队和出色的交付将使您有利于发展关系，进一步支持他们超越最初的简介。

免责声明：我前段时间爱上了 Cloudways，所以请接受这是我对两年蜜月的玫瑰色、严重偏见的看法。 我将分享我不得不强调的挫败感，这正是我几乎每天都佩戴他们品牌的原因！

潜在的失败接触点

许多机构通过低成本主机在线工作来开发和测试他们的应用程序。 我们在线项目经验中的关键接触点包括：

• 不可靠的开发服务器
• 缺乏一致的备份
• 糟糕的用户界面
• 有限的安全选项
• 支持慢
• 主机限制
• 糟糕的文档

不可靠的开发服务器

没有什么比部署到慢速服务器或让客户质疑你的工作质量更糟糕的了，这些客户对加载需要多长时间感到沮丧。

缺乏一致的备份

尽管使用 Github，但有时我们需要快速将网站回滚到以前的还原点，在那里我们可以从那个时间获得清晰的快照，包括数据库。 许多主机希望您管理自己的备份，而我们在控制面板上经历的手动备份过程缓慢、笨拙且不可靠。

糟糕的用户界面

深入研究完全加载的控制面板、尝试找出如何设置 SSH 或找到可以控制 PHP 版本的位置似乎微不足道，但它们会增加工作流程的延迟和压力。 记录一个不直观的界面对于创建和遵循来说也是一个挑战。

有限的安全选项

在从事公共部门项目时，我们必须进行尽职调查。 如果无法选择添加具有安全级别的团队访问权限或激活双因素身份验证，则会限制我们可以使用的主机。

慢支持

当某些东西不起作用时，没有什么比项目中期更糟糕的了。 您最不需要的是通过支持服务台平台的缓慢响应。 24 小时响应 SLA​​ 无法满足我们的业务需求。

主机限制

虽然没有主机可以为您提供对托管服务器的完全不受限制的访问，但我们已经撞到了许多砖墙，使我的系统管理员过于热情。 诸如可以安装的包或配置选项等限制必须导致我们将开发服务器迁移到项目中期，这让我们耽搁了几天时间。

话虽如此，您应该考虑使用我们为代理机构提供的无忧 WordPress 托管服务。

糟糕的文档

作为一个开发团队，我们非常了解服务器环境的内部工作原理，以及可供我们使用的选项。 我们希望能够深入研究文档以找到继续工作所需的内容，而不必依赖提交无数的支持问题。

Cloudways 如何改变云托管游戏？

因此，这几个接触点有时可能看起来微不足道，但会使项目、截止日期和压力成倍增加，这些很容易不成比例地爆炸。 经营两家机构，这些问题给我带来了很大的压力，并导致我犯了有害的错误。

在以前的平台上，我和我的团队不得不处理数据丢失、安全漏洞、支持失败等问题。 我不知所措。

多年来，云已经接管了，我意识到云服务器可以解决我的速度和资源问题，但是，启动和管理服务器的过程很复杂。 我们需要一位专家来支持我们并管理服务器，以便我们可以专注于我们最擅长的事情。

一些云产品提供的控制面板试图提供更简单的界面，但我们仍然遇到了受限的问题，或者由于“非托管”条款而几乎没有得到支持。 在它被“管理”的地方，我们几乎没有权力或控制来添加我们需要的东西。

游戏改变者

我们已经解决了速度问题，但其他问题仍然存在。 然后 Cloudways 引起了我的注意并震撼了我的世界！ 他们创建了一个中央系统，允许我跨多个云解决方案启动服务器，这将解决我的大部分项目困境。

我可以选择适合不同项目类型的服务提供商。 有一个简单的界面来管理一切，并通过实时聊天和文档快速访问支持。 没有什么是完美的，包括 Cloudways，但是从忍受不适合目的的平台来看，Cloudways 对我们的业务来说几乎是完美的。

快进几个月，我们的项目工作流程已经完全改变并且变得更好。

我们的项目设置工作流程

现在，我们的开发堆栈和实时服务器拥有非常清晰的工作流程，所有这些都位于 Cloudways 生态系统中。

服务器选择

首先，我们根据需要的规格和容量选择现有服务器或创建新服务器。 能够在世界上几乎任何位置在领先的云服务上创建服务器是一种非常令人满意的体验。

应用程序设置

现在我们启动我们的应用程序。 借助 Cloudways，我们可以从各种具有预打包设置的应用程序模板中进行选择，例如 WordPress、电子商务等。 我们谨慎地采用命名约定，以便可以轻松识别我们的应用程序。

设置项目

接下来，我们使用 Cloudways 界面创建一个新项目。 我们可以选择与该项目相关的应用程序（站点）。 例如：“Client X – Dev”和“Client X – Staging”。 这对于快速访问相关服务器很重要，但也允许我们控制谁可以访问什么。 将应用程序与项目相关联真正为我们释放了团队管理的力量。

组建团队

现在我们审查谁将成为项目的一部分并将他们添加为项目的成员。 我们还配置了他们需要的访问级别。 例如，我们的一些开发人员需要能够更改服务器设置和包，但不需要访问备份、扩展选项、安全设置等。

Git 设置

对于版本控制，我们现在将我们的私有存储库链接到准备代码部署的相关应用程序。 这使我们能够保护代码库免受想要“尝试一下”的冒险但善意的开发人员的侵害。

通知设置

我们已经设置了 Cloudways Bot 来发送特定通知。 这可以通过他们的 API 通过电子邮件或 Slack 推出。 然而，我们喜欢 API，并且基于我们在“应用程序设置”中设置的命名约定，我们能够在内部创建规则，规定谁应该被通知每个应用程序的内容。 这意味着团队成员不会被不相关的更新淹没。 他们更有可能关注机器人。

备份

我喜欢安全。 因此，当我们准备好开始时，我喜欢备份我们从项目开始时所处的位置，然后再继续构建所有内容。 我们还允许某些成员在开发过程中进行按需备份。

故障排除工作流程

我们现在有一个与我们的流程相匹配的设置流程。 我们知道，在项目期间，我们可能会遇到需要解决的问题。 这些可能是缺少包、没有足够的资源、错误等等。 Cloudways 让我们很容易解决问题。

以下是我们在 Cloudways 上的做法。

谷歌

通常我们的问题与 Cloudways 并不真正相关，因为它可能是我们需要在终端或需要安装的包中使用的命令。 所以我们的第一站就是从互联网上获取这类信息。 我个人是 Bing 的粉丝 :)。

支持文档

接下来，我们查看支持文档。 Cloudways 不会回避以开发人员为中心的内容。 例如，他们深入研究管理 WP-CLI或如何通过命令行管理 Git 。 我们经常在这里找到我们需要的资源，从而节省了我们任何进一步的步骤。

脸书群组

很可能有人问过我们之前的问题。 所以如果我们在文档中没有找到它，我们下一步就是搜索Cloudways Users组。 我们经常会发现有人报告了一个问题，然后是来自非常支持社区的一系列评论。 您的解决方案很可能在这些有用的评论之一中。

如果我们一无所获，我们也会发布问题，但如果我们的问题是时间敏感的，我们现在将转到 Cloudways 支持。

云道支持

我们没有直接跳到支持票中，而是首先确保我们已经用尽了以前的途径。 首先，因为它可以自己解决问题并从中学习！ 其次，因为当我们将问题提交给支持时，这会为我们提供有关我们问题的更多信息。

我们现在可以进行实时聊天，并提供详细的问题陈述以及我们尝试过的内容。 我在几分钟内就与一名技术人员进行了实时聊天，那时他们有足够的信息将您的问题分配给相关的支持团队或将您指向知识库中的某些内容。

我的大部分支持都让我感到不安，Cloudways 的事件发生在我跳过所有之前的步骤并且在盲目恐慌中，我将负担放在了实时聊天中毫无戒心的支持技术人员身上。 不是我最自豪的时刻。

包起来！

不要满足于可能使您失败的系统。 虽然我当然会推荐 Cloudways，但请花一些时间检查您的流程，然后找到一个与您的工作流程相匹配的平台。

最后，回顾和迭代。 流程可能存在缺陷，当您发现弱点时，您可以在未来进行改进和弥补。