電子郵件基礎架構產品開發過程中的 5 大挑戰

已發表: 2023-03-20

電子郵件基礎設施是支持發送、接收和存儲電子消息的互連繫統。因此，它在促進信息交換方面起著至關重要的作用，無論是 B2B 還是 B2C。

就此而言，Radicati Group Inc. 估計，到 2027 年，發送的電子郵件總數將接近 4000 億封。同年，全球用戶數量預計將達到 50 億。

隨著電子郵件流量的持續增長，擁有強大而可靠的電子郵件基礎設施的重要性不容否認。

然而，開發和維護可靠的電子郵件基礎架構並非沒有問題。在本文中，我們討論了組織在電子郵件基礎設施產品開發過程中面臨的前五大挑戰，並提供了克服這些挑戰的實用解決方案。

1：可擴展性

挑戰

由於流量不斷增長，電子郵件基礎設施可能難以處理負載。公司需要採取先發製人的措施來適應增長並避免服務中斷。

在概念開發的同時集思廣益措施是有利的。如果沒有，開發人員需要在發布 MVP 時這樣做，否則他們將面臨以下風險：

生產力損失
客戶滿意度下降
潛在的經濟損失
域權威評級下降
發件人信譽下降

解決方案：

基於雲的基礎設施
負載均衡

使用基於雲的基礎架構

借助基於雲的基礎架構，開發人員可以利用第三方電子郵件服務的可擴展性和可靠性。反過來，他們獲得了滿足不斷增長的客戶需求所需的資源。

聽起來很有希望，但它實際上是如何運作的呢？

第三方電子郵件服務使用大型集中式數據中心來存儲和處理數據。因此，軟件開發公司可以利用最新的技術和資源，而無需自行投資。這有助於用一塊石頭殺死兩隻鳥：

該方法大大降低了運營成本。
它還為組織提供可擴展的解決方案，以滿足他們不斷增長的需求。

這裡要強調的重要一點是，您應該一次一個地開發基於雲的基礎架構。這意味著最好開始在雲中運行一些任務，然後根據當前負載（在本例中為電子郵件或用戶請求的數量）擴展任務本身。

但是基於雲的任務不應臨時擴展，確定各自的產品開發策略至關重要。更重要的是，您必須知道是否存在與之相關的挑戰和瓶頸。

負載均衡的實現

在深入研究之前，請記住負載均衡應該與基於雲的基礎設施一起實施。充其量在一個產品開發階段內。

現在，負載均衡指的是在多個雲端架構和任務之間分配工作負載。主要好處是現有產品能夠處理增加的流量，即使在高峰流量時也是如此。

由於工作負載分佈在多台服務器上，因此沒有一台服務器會受到電子郵件流量的限制。因此，服務中斷和瓶頸的可能性大大降低。

更好的是，負載平衡算法可用於動態調整工作負載的分配，通常基於兩個因素：

請求的數量。
每個服務器的處理能力。

打造一個地獄般的住宿平台

時間回到 2012 年，Airbnb 的產品開發進程正處於關鍵階段。

他們直擊目標受眾，擴展了整個平台。但用戶反饋顯示，涉及更改請求、爭議和退款的邊緣案例數量驚人。當時，所有這些都是通過電子郵件手動處理的，沒有支持請求處理的後端，這給擴展業務帶來了巨大壓力。

Airbnb 面臨著一個冒險的選擇——在一年內僱用 1000 多人，或者構建一個自動化框架來處理邊緣案例。

是的，他們選擇了後者。

當時的 Airbnb 產品經理 Jonathan Golden 不得不無情地確定優先級。主要目標是為自動化雲解決方案（後端框架）創建一個計劃，以處理和分類邊緣案例。

有了這個框架，Airbnb 很快就暢通無阻，並繼續以每年 300% 到 600% 的速度擴展。請注意，這些百分比指的是 Airbnb 的早期指數增長。

但是，從這個例子中可以學到更多的產品開發知識，而不僅僅是將所有東西都移到雲端和自動化工作流程。

首先手動處理技術挑戰至關重要。否則，開發人員可能無法很好地了解根本問題。
公司不應該等太久才應用擴展自動化、負載平衡或其他任何東西。如果你不及時去做，挑戰可能會越來越大，以至於克服它們變得更加困難。
始終嘗試創建可應用於產品路線圖中其他問題的解決方案或框架。這樣做會使您的團隊更加敏捷。

2：安全

挑戰

電子郵件基礎設施安全性或缺乏安全性至關重要，因為它直接影響組織與潛在客戶有效溝通的能力。

產品開發團隊需要在早期階段解決這一挑戰，遠早於最小可行產品。但它並不止於此。即使您處理的是成品，定期的安全審計也應該是優先事項。

由於機密信息通常通過電子郵件交換，安全漏洞可能導致敏感信息洩露。這可能會對組織造成嚴重後果，包括聲譽受損、客戶信任喪失以及潛在的法律後果。

此外，重要的是所有團隊都了解潛在的安全風險，以防止可能規避加密和安全協議的漏洞。此類風險之一是社會工程，但在以下部分之一中將對此進行更多介紹。

解決方案：

加密
安全協議
定期安全措施更新

SSL 和 TLS 等安全協議為傳輸中的電子郵件數據提供加密和身份驗證服務。因此，它們可以被視為電子郵件基礎設施產品路線圖中的第一道防線。此外，組織應定期審查和更新內部安全措施。

如何？

例如，開發軟件的公司需要為工程師和其他利益相關者制定內部政策，以限制對代碼庫、git 等的訪問。同時，公司應該有明確的協議，說明如何以及為什麼可以授予某人更大的權限訪問權限。

開發團隊通常使用列表特權原則來實現更高級別的安全性。這意味著更多的訪問權限是按需提供的，很少有人可以訪問所有內容。

我們之前提到過加密移動數據（傳輸中的數據）的 SSL 和 TLS。但這些公司還需要考慮靜態數據加密，並為該數據建立不同的訪問級別。

“Pinky 保證，我們不會黑你！”

這在某種程度上是一個負面的商業案例，但它清楚地表明安全總是有兩個方面——軟件和人。

2023 年 1 月，Mailchimp 遭遇安全漏洞（12 個月內的第三次），暴露了 133 位客戶的敏感數據。社會工程是詐騙者用來獲取敏感信息的策略。

基本上，這意味著在線欺詐者利用毫無戒心且可能缺乏經驗的 Mailchimp 員工來訪問受保護的數據。詐騙者通過網絡釣魚獲取員工的憑證，從而攻擊人員，而不是系統本身。儘管如此，仍有約133名客戶的敏感信息被曝光。

底線是安全的技術方面需要是防彈的。但與此同時，公司需要製定程序並教育員工如何避免成為網絡釣魚或任何其他類型的在線受害者。

3：可靠性

挑戰

可靠性決定了系統隨著時間的推移正確和一致地運行的能力。因此，它是新產品開發過程不同迭代過程中的最大障礙之一。

為什麼？

沒有可靠性，用戶就無法確定他們的電子郵件是否會按預期發送和接收，最終會破壞價值主張。當然，電子郵件基礎設施就是這種情況，但這裡還有更廣闊的前景。

SaaS 中最終產品的可靠性直接影響品牌的聲譽及其交付能力。無論是 MVP 還是已經成功的產品，它都需要承受各種類型的故障，例如 RAM 使用增加、用戶請求激增、意外的基礎架構負載等。

解決方案：

實施冗餘和備份系統
定期基礎設施監控

冗餘涉及將相同數據的多個副本存儲在不同位置。因此，如果一個系統出現故障，可以使用備份。有幾種技術可以做到這一點，最著名的是負載平衡，其中電子郵件分佈在多個服務器上以降低失敗風險。

然後，定期的基礎設施監控提供了指標，允許開發人員在問題成為真正的問題之前檢測並解決問題。這可以通過監控工具和定期系統檢查來完成。或者，有時，開發團隊可以在概念測試期間應用 SWOT 分析來確定最佳方法。

說到監控，開發人員最好在監控之上構建警報。例如，應為以下情況設置警報：

如果進程開始消耗更多內存。
如果有特定的數據處理/計算問題。
在 500 個代碼響應的情況下。

這些警報與內部架構支持和隨叫隨到的產品管理有關；這兩者都應該在軟件開發過程中或在軟產品發佈時建立。

用簡單的英語來說，當相關事件觸發警報時，工程師應該立即跳到警報上，即使是在半夜。

大佬們是怎麼做到的

谷歌本身就是產品設計策略的一個很好的例子，它在早期就成功地克服了可靠性挑戰。他們的基礎設施經過精心設計，具有多級冗餘。這使得搜索引擎巨頭能夠確保用戶電子郵件按預期發送和接收，即使在發生內部故障的情況下也是如此。

另一個例子是 Microsoft，它通過使用負載平衡和備份系統實施了高度可靠的電子郵件基礎設施。這些措施幫助 Microsoft 確保其電子郵件服務保持高度可靠，即使面對顯著增長和增加的需求。

但不幸的是，它不再是那樣了。在產品生命週期中，有幾個轉折點，Microsoft 可能未能在這些轉折點進行適當的市場研究和競爭對手分析——更多內容在“管理性能預期”部分。

4：互操作性

挑戰

互操作性表示電子郵件基礎設施或任何 SaaS 服務與其他應用程序集成並良好協作的能力。

通常，集成應包括：

客戶關係管理 (CRM)
企業資源規劃 (ERP)
數據存儲

有什麼好處？

在不同應用程序之間無縫交換信息的能力有助於公司做出明智的、數據驅動的決策。此外，它還允許他們簡化與產品相關的流程。好處是高互操作性還可以帶來更好的用戶體驗。

請注意，在集思廣益產品概念時應解決這方面的問題。將集成選項與目標市場中可用的選項進行權衡是值得的。

解決方案：

開放標準
跨平台兼容性

開放標準是公開可用的規範，允許不同的系統協同工作。

電子郵件基礎設施的關鍵開放標準包括簡單郵件傳輸協議 (SMTP)、郵局協議版本 3 (POP3) 和互聯網消息訪問協議 (IMAP)。

至於兼容性，電子郵件基礎架構必須設計為適用於不同的操作系統（Windows、macOS 和 Linux），以及不同的網絡瀏覽器（Google Chrome、Mozilla Firefox、Safari 等）。

然而，合併開放標準和確保跨平台兼容性並非沒有挑戰。以SMTP為例，開發者往往需要對其進行特定的調整，甚至可能要加加密。要輕鬆實現此修復和其他特定於產品的修復，建議使用 AWS 等互連平台。

最後，開發團隊需要密切關注簽名、垃圾郵件解決方案、DNS 記錄等，因為這與使他們的軟件與第三方集成良好配合有關。

簡而言之，這歸結為在產品開發過程的每個階段都遵循標準格式和協議。之後，工程師可以根據需要自定義後端工作流程和前端。

讓我們鬆一口氣

如果您認為 Slack 成功地重塑了我們的協作方式，那您就沒有錯。但問題是他們是怎麼做到的。

讓我們忽略 Slack 在上市階段有一個穩定的解決方案這一事實。讓我們忘記一個機智的營銷策略，它成功地改變了成群結隊的沮喪的 IT 員工。這裡重要的是轉換後會發生什麼。

首先，進入Slack的門檻很低。但是，它涵蓋了您可以想像的大多數用例。然後，將您的團隊遷移到 Slack 非常簡單。用戶管理很輕鬆，集成列表還在繼續......

根據您的業務規模和範圍，您可以連接 Jira、Notion、Coda、Google 應用程序等，將所有通知和數據通道集中在一個屋簷下。所有這一切都在幾天甚至幾小時內完成。

最令人印象深刻的是 Slack 互操作性幾乎是一勞永逸的。集成所需的一切後，您始終只需點擊一下即可獲得數據或通信源。而且這種用戶體驗是難以匹敵的。

5：管理績效預期

挑戰

管理性能預期的挑戰在於確保產品滿足最終用戶的需要和要求。因此，將性能期望等同於用戶期望是安全的，尤其是在開發 SaaS 時。

需要明確的是，電子郵件基礎設施產品或任何 SaaS 的成功很大程度上取決於最終用戶和目標客戶對它的看法。即——產品滿足用戶性能期望的程度。

隨著對電子郵件的依賴程度越來越高，用戶希望基礎架構安全、快速且可靠。此外，用戶希望它是：

便於使用
可從多個設備訪問
能夠大規模處理電子郵件流量

解決方案：

測試
優化
清晰的溝通
反饋迴路

冒著顯而易見的風險，定期測試和優化需要成為任何產品開發過程中不可或缺的一部分。它可能涉及進行調查、焦點小組、A/B 測試以收集用戶反饋等。

清晰的溝通與測試密切相關，因為它有助於建立信任和透明度。通常，溝通包括有關開發過程的定期公開更新、通知用戶有關基礎架構的更改以及解決用戶產生的任何性能問題。

所有的溝通和測試都會為開發人員提供合格的客戶反饋，進而有助於滿足他們的需求和期望。這裡的關鍵步驟是將給定的反饋整合到產品開發過程中。

簡而言之，這意味著對系統的所有缺點保持警惕。甚至可以進行業務分析，以更好地了解在不損害其商業化的情況下應用什麼方法來改進產品。

然後，關鍵的一步是將所有發現轉化為可操作的任務和更新，以進一步簡化您的軟件。

但是，在測試和監控您的應用程序時，需要牢記某些事項。例如，壓力測試確定代碼是否運行緩慢。然而，運行緩慢的事實並不需要更新。開發團隊需要深入了解哪些更新對性能至關重要，哪些可以取消優先級以優化資源使用。

巨人之戰

如前所述，本節探討了 Microsoft 可能未能達到性能預期的領域，從而讓競爭對手得以蓬勃發展。它有一些故事，涉及蘋果和谷歌。

到 2021 年 9 月他們發布 MPP（郵件隱私保護）時，蘋果已經在電子郵件客戶端市場份額上擊敗谷歌。當時，蘋果的份額接近 59%，谷歌在 28% 左右，但微軟的 Outlook 遠遠落後，約為 5%。

現在，微軟被打敗的原因可能是什麼？

為了找到答案，我們應該進一步回顧過去。

大約二十年前，谷歌於 4 月 1 日推出了 Gmail。微軟很快就意識到這不是愚人節玩笑。 Windows 之父竭力爭取在大約十年的時間裡保持主導地位。但是，一旦 Gmail 在 2015 年接管了市場，Outlook 基本上就出現了螺旋式下降。

但為什麼？

可以肯定地說原因是績效預期失敗。基本上，Gmail 更快、更易於使用，而且它提供了更加精簡的界面。再加上更多的功能和更大的存儲空間（1GB——當時是 Outlook 的 500 倍），Gmail 獲勝也就不足為奇了。

快進到今天，很明顯谷歌可能會像十年前的微軟一樣陷入困境。現在，失敗的關鍵性能預期是跟踪。考慮到入站電子郵件的數量，無論是營銷電子郵件還是交易電子郵件，人們更願意隱藏他們的電子郵件事件。

當然，跟踪打開率、地理位置和設備變得越來越困難這一事實讓營銷人員感到心痛。但統計數據表明，這正是用戶所期望的。

Apple 的電子郵件開發團隊很早就注意到了這一趨勢，並且是第一批提供可行解決方案以將電子郵件噪音降至最低的團隊之一。這種性能預期、監控和更新可能會導致 Apple 在可預見的未來主導電子郵件客戶端領域。

打造好產品

到目前為止，您應該對產品開發過程中的關鍵挑戰有深入的了解。需要強調的是，您開發的產品類型並不重要。

所描述的挑戰與利基市場無關，而且在很大程度上與產品開發週期無關。即使您只是處於構思階段，您肯定希望產品安全、可靠且可擴展。然後，當您到達啟動階段時，不要停止產品創意篩选和驗證。

最後，重要的是要記住，產品開發過程的每一步都需要大量的研究、分析和實施規劃。好消息是本文為您提供了可靠的路線圖和需要關注的關鍵領域。