無服務器計算風靡一時，遵循以下提示可消除其中的非計算瓶頸，避免程序限制和任務排隊，並保持功能的及時響應…
無服務器計算提供了一個基礎架構，允許將服務器資源應用於系統，以便擴展並有效提供計算能力，但省去了服務器管理帶來的麻煩，這意味着沒有人需要在運行時關心單個服務器（坦率地說，沒有人真正關心過），這使得將一組服務器外包到雲提供商具有成本效益，而無服務器界面通過最小化合同使外包關係變得儘可能簡單。
關於無服務器，許多人的直接反應是嘗試用圖表和與其各自無服務器功能相關的告警來替換附加到服務器的圖表和告警。然而，這並未從根本上解決應用程序管理挑戰。正如沒有人真正關心服務器一樣，沒有人真正關心無服務器功能。
大部分人關心的只是系統爲用戶提供的服務水平，這意味着有價值的監控必須關注可能出錯的事情，並且在無服務器的情況下，出錯不再關注服務器層面，因爲服務器容量耗盡等錯誤已經被有效隱藏。那麼，典型的無服務器問題是什麼？又是如何表現的呢？
冷啓動成本
這是無服務器系統經常出現且被頻繁討論的問題，爲了最大限度提高利用率，無服務器提供商有時會選擇完全關閉非活動功能。當負載恢復時，啓動成本會導致響應時間延長。當一個業務功能由鏈接在一起的許多無服務器功能組成時，這種效果可能會複雜化。
解決方法：許多用戶人爲ping功能以確保服務活着。要通過鏈式服務網絡有效應用此策略，必須瞭解它們之間的端到端關係，以便依賴鏈中的所有服務保持活動狀態，從而使業務的端到端跟蹤必不可少。
資源請求
無服務器平臺會限制無服務器功能將執行的併發請求數，通常是在某個帳戶和單個功能級別。一旦達到併發限制，進一步的用戶請求將排隊，從而導致響應時間延長。雖然限制有效計算資源池似乎有悖常理，但這確實可以防止潛在花銷（不要忘記，容量按消費基礎計費）。
解決方法：提高門檻或者確保合理設置資源以滿足響應時間和併發方面的任何非功能性要求。同樣，需要端到端的可見性，因此可以快速確定受限制的內容，以及限制對最終用戶體驗的影響。
非計算瓶頸
如果解決了所有無服務器限制，就可以支持儘可能多的併發請求。根據具體情況，這並不意味着麻煩徹底解決，如果等待讀取或寫入數據，就需要無限縮放lambda等待數據訪問，同時需要爲非生產性等待付費。
功能懸掛的確切原因隨持久性存儲的不同而有差異：
- 雲數據存儲：雲數據服務變得越來越有彈性，但許多仍需要根據併發讀寫卷配置資源。
- 傳統系統：沒有哪個功能是孤島，許多做無服務器的用戶正在使用無服務器功能（有時是大型機，有時是傳統的基於服務器的部署）包裝現有系統。雖然很容易提高閾值以允許功能擴展，但這隻意味着很容易壓倒無法輕易擴展的後端。
解決方案：爲了確保後端系統能夠承受理論上的最大負載，請將它們與功能限制器一起調整。這有助於確保系統端到端地順利運行，從而避免不必要的成本和客戶不滿。在某些情況下，可能需要複製數據以使不同的系統從不同的位置訪問（當然，這以增加數據管理複雜性爲代價，可能導致不一致的風險蔓延到數據中）。
此外，在事務級別瞭解系統端到端流程，對識別和告警生產瓶頸以及端到端分析至關重要。
無服務器ops是devops
無服務器最普遍的含義是，開發人員配置代碼，在無服務器計算中爲生產提供整個包，而不僅僅是功能部件，這意味着一旦使用IDE調試生產問題，最好熟悉某種性能管理解決方案，因爲至少一半“錯誤”可能會與部署相關。系統命運完全在個人手中，應用程序級別的端到端可見性至關重要。