由 12f-2
四月底，當異鬼圍攻臨冬城時，我們遇到了一件更有趣的事：我們進行了一次不太尋常的部署。基本上，我們會不斷地向生產中推出新功能（就像其他人一樣）。但這次與其他的都不一樣。它的規模如此之大，以至於我們所犯的任何潛在錯誤都會影響我們所有的服務和用戶。最後，我們按照計劃在計劃和宣布的停機時間內完成了所有工作，並沒有對銷售產生任何影響。這篇文章介紹了我們如何實現這一目標以及那些想要實現這一目標的人如何在家中重複這一目標。
我現在不會描述我們所做的架構和技術決策，也不會告訴您這一切是如何運作的。這些更像是在頁邊空白處做的筆記，記錄了我所觀察到的和我直接參與過的最困難的推廣活動之一是如何進行的。我不保證完整性或技術細節，也許它們會出現在另一篇文章中。
背景 + 這是什麼樣的功能
我們正在建構雲端平台 （MCS），我在那裡擔任技術總監。現在是時候將 IAM（身分和存取管理）新增至我們的平台了，它為所有使用者帳戶、使用者、密碼、角色、服務等提供統一管理。為什麼需要雲端是一個顯而易見的問題：所有用戶資訊都儲存在其中。
通常，這些東西都是在任何專案的開始階段就開始建構的。但在 MCS 中，情況的歷史發展略有不同。 MCS 由兩部分組成：
- Openstack 擁有自己的 Keystone 授權模組，
- 基於 Mail.ru Cloud 專案的 Hotbox（S3 儲存），
隨後，新的服務隨之出現。
本質上，這是兩種不同類型的授權。此外，我們還使用了一些來自 Mail.ru 的獨立開發，例如 Mail.ru 共享密碼存儲，以及定制的 openid 連接器，它在虛擬機的 Horizon 面板（原生 OpenStack UI）中提供 SSO（直通授權）。
對我們來說，創建 IAM 意味著將所有這些組合成一個完全屬於我們自己的系統。同時，我們不想在過程中丟失任何功能，而是為未來奠定基礎，使我們能夠透明地改進它而無需重構和擴展功能。同樣在開始時，使用者獲得了基於角色的服務存取模型（中央 RBAC，基於角色的存取控制）和一些其他小東西。
這項任務並不簡單：python 和 perl、多個後端、獨立編寫的服務、多個開發團隊和管理員。最重要的是，生產系統上有數千個即時用戶。所有這些都必須記錄下來，最重要的是，必須在沒有人員傷亡的情況下完成。
我們要推出什麼？
粗略地說，我們花了大約 4 個月的時間準備了以下內容：
- 我們創建了幾個新的守護進程，它們聚合了先前在基礎設施不同部分運行的功能。其餘服務以這些惡魔的形式分配了一個新的後端。
- 我們編寫了自己的密碼和密鑰中央存儲，可供我們所有的服務訪問，並且可以根據需要自由修改。
- 我們從頭開始為 Keystone 編寫了 4 個新的後端（使用者、專案、角色、角色分配），它們基本上取代了其資料庫，現在充當我們使用者密碼的單一儲存庫。
- 我們教導所有 Openstack 服務使用第三方策略服務來制定策略，而不是從每個伺服器本地讀取這些策略（是的，這是 Openstack 預設的工作方式！）
如此重大的重新設計需要對由不同開發團隊編寫的多個系統進行大規模、複雜且最重要的是同步的變更。組裝完成後，整個系統就可以運作了。
如何推行這樣的改變而不搞砸？首先，我們決定展望一下未來。
推廣策略
- 可以分幾個階段推出產品，但這會使開發時間增加三倍。此外，一段時間內我們的資料庫中的資料會完全不同步。我必須編寫自己的同步工具並長期使用多個資料儲存。這會產生各種各樣的風險。
- 所有可以為用戶透明準備的事情都已提前做好。花了2個月的時間。
- 我們允許自己停機幾個小時——僅用於用戶創建和修改資源的操作。
- 對於所有已經建立的資源來說，停機是不可接受的。我們計劃在部署期間，資源應該不停機運行，也不會影響客戶。
- 為了減少出現問題時對客戶的影響，我們決定在周日晚上推出。晚上，管理虛擬機器的客戶較少。
- 我們已經警告所有客戶，在選定的推出期間，服務管理將無法使用。
題外話：什麼是 rollout？
<小心，哲學>
每個 IT 專家都可以輕鬆回答什麼是推出。您設定 CI/CD，所有內容都會自動交付到生產環境。 🙂
當然，這是事實。但困難在於，使用現代工具來自動化程式碼交付，卻失去了對部署本身的理解。當你看到現代交通工具時，你就會忘記車輪發明的史詩性質。一切都自動化了，以至於部署通常是在不了解全局的情況下進行的。
整個畫面是這樣的。此次發布主要包括四個面向：
- 代碼交付包括資料修改。例如他們的遷徙。
- 代碼回滾是指在發生錯誤時返回的能力。例如，透過建立備份。
- 每次推出/回滾操作的時間。必須了解前兩點任何操作的時機。
- 受影響的功能。評估預期的正面影響和可能的負面影響至關重要。
為了成功推出，必須考慮所有這些方面。通常只評估第一點，或最多評估第二點，然後部署就被認為是成功的。但第三和第四點更為重要。如果推出需要 3 小時而不是 XNUMX 分鐘，哪個用戶會喜歡它？或者如果在推出過程中某些額外的事情受到影響怎麼辦？或者某項服務的宕機會導致難以預料的後果？
第一幕..n，準備發布
起初我想簡單描述我們的會議：整個團隊、各個部分、在咖啡點進行的大量討論、爭論、測試、腦力激盪。後來又想，沒必要了。四個月的開發總是包含這些內容，特別是當你寫的不是可以持續交付的東西，而是即時系統的重要功能時。這會影響所有服務，但對於使用者來說，除了「Web 介面中的一個按鈕」之外，沒有任何變化。
我們對如何進行工作的理解隨著每次會議而改變，而且改變相當顯著。例如，我們將更新整個計費資料庫。但我們計算了時間並意識到在合理的推出時間內做到這一點是不可能的。他們花了將近一周的時間來分片和存檔計費資料庫。當預期的推出速度仍然不令人滿意時，他們又訂購了更多、更強大的硬件，並將整個基地搬遷到那裡。不是我們不想早點做，而是當前的推廣需求讓我們別無選擇。
當我們中的一個人懷疑推出可能會影響我們虛擬機的可用性時，我們花了一周的時間進行測試、試驗、審查程式碼，並清楚地了解到這不會發生在我們的生產中，甚至最懷疑的人也同意這一點。
同時，技術支援人員進行了自己的獨立實驗，為客戶編寫了關於推出後應該改變的連接方法的說明。他們致力於使用者使用者體驗、準備說明並提供個人諮詢。
我們已經實現了所有可能的推廣操作的自動化。每個操作都經過腳本編寫，即使是最簡單的操作，也會不斷進行測試。我們爭論如何最好地關閉該服務——降低守護進程或使用防火牆關閉對該服務的存取。我們為推出的每個階段創建了一個命令清單，並不斷更新它。我們繪製了所有推廣工作的甘特圖並不斷更新，同時標註了時間表。
所以…
推出之前的最後一幕
……是時候推出了。
俗話說，藝術作品不可能完成，只能完成。您必須付出意志力，意識到您無法找到所有問題，但要相信您已經做出了所有合理的假設，預見了所有可能的情況，關閉了所有關鍵錯誤，並且所有參與者都已盡其所能。你推出的程式碼越多，你就越難相信這一點（此外，每個人都明白，不可能預見所有的事情）。
當我們確信已經盡一切可能為用戶覆蓋與意外影響和停機相關的所有風險時，我們決定準備推出。也就是說，任何事情都可能出錯，除了：
- 影響（對我們來說最神聖、最珍貴的）使用者基礎設施，
- 功能：推出後我們的服務的使用應該與之前相同。
推出
兩個滾，八個不干擾
我們將對所有用戶的請求進行 7 小時的停機處理。目前，我們既有推出計劃，也有回滾計劃。
- 推出過程本身大約需要 3 小時。
- 測試需要 2 小時。
- 2 小時是為了可能回滾更改而預留的。
為每個動作繪製了甘特圖，包括需要多長時間、按順序執行什麼、並行執行什麼。
推出甘特圖的一部分，早期版本之一（沒有並行執行）。最有價值的同步工具
所有參與者在推廣過程中都有明確的角色、他們要執行的任務以及他們要負責的事情。我們嘗試將每個階段自動化，推出、回滾、收集回饋並再次推出。
事件紀事
因此，15 月 29 日星期日晚上 10 點，XNUMX 個人來上班。除了主要參與者外，還有一些人只是為了支持團隊而來，我們對此要特別感謝他們。
值得一提的是，我們的關鍵測試員正在休假。不經過測試就不可能推出，我們正在研究各種方案。一位同事同意在休假期間對我們進行測試，為此她受到了整個團隊的極大感激。
00:00。停止
我們停止用戶請求並掛上「技術工作」的牌子。監視器裡尖叫，但一切正常。我們檢查了一下，除了應該掉落的東西之外，沒有其他東西掉落。我們開始進行遷移工作。
每個人都列印出逐點推進計劃，每個人都知道誰在什麼時候做什麼。每次行動後，我們都會檢查時間，以確保沒有超出時間，並且一切都按計劃進行。目前沒有直接參與推廣的人正在準備推出一個線上玩具（Xonotic，類似 3 quacks），以免打擾他們的同事。 🙂
凌晨 02 點。推出
令人驚訝的是：由於我們對資料庫和遷移腳本進行了最佳化，我們提前一小時完成了部署。大家齊聲喊道：「他們出來了！」所有新功能都已投入生產，但目前只有我們可以在介面上看到它們。每個人都進入測試模式，將事情分成小組，然後開始查看最終的結果。
效果不太好，10 分鐘後我們才意識到這一點，因為團隊成員的專案中沒有任何連線或運作。快速同步，表達我們的問題，設定優先級，分成團隊並進行調試。
凌晨 02 點 30 分。兩大問題與“四眼聯盟”
我們發現了兩個大問題。我們意識到客戶將看不到某些連接的服務，並且合作夥伴帳戶會出現問題。兩者都與某些邊緣情況的遷移腳本的不完美有關。我們現在就需要修復它。
我們寫了查詢來解決這個問題，至少在 4 隻眼睛看來是如此。我們在預生產階段對它們進行測試，以確保它們能夠正常工作並且不會破壞任何東西。我們可以繼續前進。同時，我們啟動了常規整合測試，發現了更多問題。它們都是小事，但也需要修復。
凌晨03點。 -00 個問題 +2 個問題
之前的兩個大問題已經解決，幾乎所有小問題也都解決。所有不忙於修復的人都在積極地處理他們的帳戶並報告他們發現的情況。我們確定優先順序，在各個團隊之間分配任務，並將非關鍵任務留到早上。
我們再次進行測試，發現兩個新的大問題。並非所有服務策略都正確到達，因此某些使用者請求未獲得授權。另外還有合作夥伴帳號的新問題。我們趕緊去看。
03:20。緊急同步
已修復一個新問題。對於第二個，我們安排了緊急同步。我們明白發生了什麼事：先前的修復解決了一個問題，但卻產生了另一個問題。讓我們休息一下，弄清楚如何正確且不產生後果地做到這一點。
03:30。六眼
我們了解基地的最終狀態應該是什麼樣的，以便所有合作夥伴都能獲得好處。我們用 6 倍的眼光撰寫一份請求，在預生產中運行它，測試它，然後將其推廣到生產中。
04:00。一切正常
所有測試均已通過，未發現任何嚴重問題。有時，如果團隊中某些事情沒有進展，我們會迅速做出反應。大多數情況下，警報都是錯誤的。但有時某些東西無法到達，某個地方的某個頁面無法正常運作。我們坐下來，修理、修理、修理。一個獨立的團隊正在推出最後一個重要功能—計費。
04:30。不歸路
不歸路已經臨近，也就是說，如果我們開始回滾，我們將無法滿足給予我們的停機時間。計費系統有問題，它了解並記錄一切，但頑固地拒絕從客戶那裡註銷金錢。個別頁面、操作和狀態存在一些錯誤。主要功能正常，所有測試均成功通過。我們決定，這項措施已經實施，我們不會再回滾。
06:00。在 UI 中全部打開
錯誤已修復。一些不影響使用者的操作留待以後再做。我們向所有人開放介面。我們繼續修改計費方式，等待使用者回饋和監控結果。
07:00。 API 載入問題
很明顯，我們對 API 的負載和負載測試的規劃略有錯誤，導致未能識別問題。結果，約有 5% 的請求失敗。我們動員起來，尋找原因。
Billing很固執，也不想工作。我們決定將其推遲到以後，以便以冷靜的方式做出改變。也就是說，所有資源都累積在其中，但客戶不會註銷他們的資金。當然，這是一個問題，但與整體推廣相比，它似乎不是根本問題。
08:00。 API 修復
他們針對該負載推出了修復方案，故障就消失了。我們開始回家。
10點。全部
一切都已確定。監控和客戶都安靜了下來，團隊也漸漸進入了睡眠狀態。仍有剩餘帳單，我們明天會恢復。
然後在白天，我們為一些客戶推出了修復日誌、通知、回傳代碼和客製化的服務。
因此，推出成功了！當然，它本來可以做得更好，但我們得出的結論是，我們缺少什麼才能達到完美。
在總
在為期2個月的積極準備過程中，共完成了43項任務，耗時從幾個小時到幾天不等。
在推出期間：
- 新的和修改過的惡魔——5 個，取代 2 個巨石；
- 資料庫內的變更 - 我們所有 6 個包含使用者資料的資料庫都受到了影響，從三個舊資料庫卸載到一個新資料庫；
- 完全重新設計的前端；
- 下載的程式碼量為33萬行新程式碼，≈3千行測試程式碼，≈5千行遷移程式碼；
- 所有資料都完好無損，沒有一台客戶的虛擬機器受到損壞。 🙂
良好推廣的良好做法
他們在這個困難的情況下指導了我們。但一般來說，在任何推出過程中遵循它們是有用的。但部署越複雜，它們發揮的作用就越大。
- 首先要了解的是，這項措施將如何影響用戶。會有停機時間嗎？如果有，那麼停機時間是多久？這將如何影響用戶？可能出現的最佳和最壞情況是什麼？並消除風險。
- 計劃好一切。在每個階段，您都需要了解推廣的各個面向：
- 代碼交付；
- 代碼回滾；
- 每次操作的時間；
- 受影響的功能。
- 演練各種場景，直到所有推出的階段以及每個階段的風險都變得清晰為止。如果對某件事有疑問，可以先休息一下，再單獨檢查有疑問的階段。
- 如果對我們的用戶有幫助的話，每個步驟都可以而且應該得到改進。例如，它將減少停機時間或消除一些風險。
- 回滾測試比程式碼交付測試重要得多。有必要檢查回滾後系統是否會恢復到原始狀態，並透過測試來確認這一點。
- 任何可以自動化的事情都應該自動化。任何無法自動化的事情都應該提前寫在備忘錄上。
- 建立成功標準。什麼功能應該可用以及什麼時候可用？如果沒有發生這種情況，請執行回溯計畫。
- 最重要的是人。每個人都應該清楚自己在做什麼、為什麼做、在推廣過程中什麼取決於自己的行動。
但如果用一句話來概括，那麼透過良好的規劃和開發，您可以推出任何東西而不會對銷售產生影響。甚至會影響生產中的所有服務。
來源： www.habr.com
