文章的翻譯是專門為課程的學生準備的 ，從今天開始！
您是否曾經將新服務發佈到生產環境？ 或者您可能參與支援此類服務？ 如果是，是什麼激勵了你？ 什麼對生產有利，什麼不利？ 如何培訓新團隊成員發布或維護現有服務。
大多數公司在工業運營實踐方面最終都採用了“狂野西部”的方法。 每個團隊透過反覆試驗來決定自己的工具和最佳實踐。 但這往往不僅影響專案的成功，也影響工程師。
反覆試驗創造了一個相互指責和推卸責任的環境。 有了這種行為，從錯誤中學習並不再重蹈覆轍變得越來越困難。
成功的組織：
- 認識生產指南的必要性，
- 研究最佳實踐，
- 在開發新系統或組件時開始討論生產準備問題，
- 確保遵守生產準備規則。
生產準備包括“審查”過程。 審查可以採用清單或一組問題的形式。 審核可以手動、自動或同時進行。 您可以製作可適應特定需求的清單模板，而不是靜態的需求清單。 這樣，工程師就可以在需要時獲得繼承知識和足夠的靈活性的方法。
何時檢查服務是否已準備好投入生產？
不僅在發布之前進行生產準備檢查，而且在將其轉移給另一個營運團隊或新員工時也很有用。
檢查時間：
- 您正在將一項新服務發佈到生產環境。
- 您將生產服務的操作轉移給另一個團隊，例如SRE。
- 您將生產服務的作業轉移給新員工。
- 組織技術支援。
生產準備清單
前一段時間，舉個例子，我 測試生產準備的清單。 儘管此列表源自 Google Cloud 客戶，但它在 Google Cloud 之外也很有用且適用。
設計和開發
- 開發一個可重複的建置過程，不需要存取外部服務，也不依賴外部系統的故障。
- 在設計和開發期間，為您的服務定義和設定 SLO。
- 記錄對您所依賴的外部服務的可用性的期望。
- 透過消除對單一全域資源的依賴來避免單點故障。 複製資源或在資源不可用時使用後備（例如，硬編碼值）。
配置管理
- 靜態、小型和非秘密配置可以透過命令列參數傳遞。 對於其他一切，請使用配置儲存服務。
- 動態配置必須具有回退設置，以防配置服務無法使用。
- 開發環境配置不應與生產配置相關。 否則，這可能會導致從開發環境存取到生產服務，從而可能導致隱私問題和資料外洩。
- 記錄可以動態配置的內容，並描述配置交付系統不可用時的後備行為。
發布管理
- 詳細記錄發布過程。 描述版本如何影響 SLO（例如，由於快取未命中而導致延遲暫時增加）。
- 記錄金絲雀版本。
- 制定金絲雀發布審查計劃，如果可能的話，制定自動回滾機制。
- 確保回滾可以使用與部署相同的流程。
可觀察性
- 確保收集 SLO 所需的指標集。
- 確保您可以區分客戶端資料和伺服器資料。 這對於尋找故障原因很重要。
- 設定警報以減少勞動成本。 例如，刪除日常操作引起的警報。
- 如果您使用 Stackdriver，請在儀表板中包含 GCP 平台指標。 設定 GCP 依賴項警報。
- 始終傳播傳入的痕跡。 即使您不參與跟踪，這也將允許較低級別的服務調試生產中的問題。
防護與安全
- 確保所有外部連線均已加密。
- 確保您的生產項目具有正確的 IAM 設定。
- 使用網路隔離虛擬機器實例組。
- 使用 VPN 安全地連接到遠端網路。
- 記錄並監控使用者對資料的存取。 確保所有使用者對資料的存取都經過審核和記錄。
- 確保調試端點受到 ACL 的限制。
- 清理使用者輸入。 配置使用者輸入的有效負載大小限制。
- 確保您的服務可以選擇性地封鎖單一使用者的傳入流量。 這將阻止違規行為而不影響其他用戶。
- 避免啟動大量內部操作的外部端點。
容量規劃
- 記錄您的服務如何擴展。 例如：使用者數量、傳入有效負載的大小、傳入訊息的數量。
- 記錄您的服務的資源需求。 例如：專用虛擬機器執行個體的數量、Spanner 執行個體的數量、GPU 或 TPU 等專用硬體。
- 文件資源限制：資源類型、區域等。
- 記錄建立新資源的配額限制。 例如，如果您使用 API 建立新實例，則限制 GCE API 請求的數量。
- 考慮運行負載測試來分析效能下降。
就這樣。 我們在課室見！
來源： www.habr.com