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，但請花一些時間檢查您的流程，然後找到一個與您的工作流程相匹配的平台。

最後，回顧和迭代。 流程可能存在缺陷，當您發現弱點時，您可以在未來進行改進和彌補。