自行託管Adobe Commerce災難回覆構想
本文章的災難回覆包含失敗的部署。 雖然整個程式可能不同，但適用類似的原則。 災難可能是由於生產部署失敗、伺服器無回應、發現利用漏洞和其他許多情況所造成。 如果失敗部署的復原程式可能只需要兩個簡單的步驟，從利用漏洞進行復原可能更具挑戰性。 由於環境的複雜性、託管變數和其他複雜性，本文會提供概念和概念，但您需要自行繼續調查。 如此一來，您就可以確保設計符合業務需求的策略。
經常練習復原程式
實務，實務，實務。 實務會先出現在災難回覆清單中是有原因的。 要設定復原計畫卻永遠無法執行，這相當容易。 如果您練習得不夠充分，就很容易發生錯誤、步驟遺失，而且實際復原可能需要更長的時間。 恢復練習的步調取決於您和您的業務合作夥伴。 讓復原程式變成一年一度的活動或許就足夠了，但與貴公司決策者的深入對話應該包括幾個關鍵主題。 這些主題可協助他們瞭解為什麼練習很重要，而且應該受到期待。 以下是一些有助於開始交談的主題：
- 練習可減少實際發生事件時的實際停機時間。 如果練習練習每年中斷您的網站一小時，可能會將實際事件的實際停機時間減少數小時。 通常需要八小時或更長時間才能復原網站。 經常練習這項活動可以減少每個階段所花費的時間，也能更快地回覆。
- 這些練習執行的排程停機時間，可能與伺服器修補程式、清查調整或應定期執行的任何其他動作一致。
- 練習不同的情境，而不是相同的情境。 請偶爾花點時間，從先前的日期進行完整復原。 這包括尋找及使用資料庫的封存復本、復原程式碼以符合日期等內容。 更簡單的方法可能是從失敗的部署中復原，其中您只需復原到先前的認可。
- 驗證復原程式是否確實有效，有時存檔的資料庫可能會損毀。 如此可確保一切皆可復原且正常運作。 尋找及還原舊的DB需要一點時間，您應該知道這個部分的程式可能會持續多久。
- 驗證是否已記錄組態中的所有變更。 這可確保從舊版資料庫復原的任何新設定變更都必須正常運作。 例如，如果您的API金鑰在過去幾天內已變更為您的付款處理程式。 透過良好的變更管理流程，找出這些重要更新即可讓流程按計畫進行。
資料庫備份
資料庫備份應該相當正常。 具有每小時、每日、每週和每月快照是很常見的現象。 備份最終應移至長期儲存空間。 只要企業或技術團隊認為時間已過，可能不再需要快速回覆，就可以進行長期儲存。 從長期儲存體復原會增加復原程式所需的時間，所以在決定何時進行復原時應格外小心。 資料庫備份應自動化，不依賴人為互動。 這可確保您有足夠的資料來源，提供安全且可預測的復原程式。 這也有助於任何法證活動（如果此類活動必要）的可行性和可靠性。 在偵測到利用漏洞後，或嘗試診斷信用卡詐騙活動發生時，或甚至是某人加入您的網站時，您可能會發現需要進行法證研究。 使用這些備份的方式沒有限制，但擁有良好的備份節奏是您在實際需要備份時的最佳選擇。
以下是資料保留原則的範例：
- 每八小時。 備份應易於存取。
- 過去七天的每日備份，且應易於存取。 這些檔案的復本可能是移離現場的候選檔案。
- 過去四週的每週備份會考慮移離現場。
- 過去三個月的每月備份已移至異地。
- 較舊的備份會移至異地長期儲存。
以程式碼表示的基礎結構
此方法表示您擁有工具和程式碼，可為專案重建部分或整個基礎架構。 當伺服器發生問題時可能需要此專案，且必須停止使用。 能夠快速將新伺服器上線、部署程式碼、進行任何PHP、Nginx或Apache設定，以及其他任何設定，自動錶示停機時間更短。 即使執行手冊中有詳細記載的步驟，也更容易設定，執行這些步驟所需的時間要長得多。 此外，請考量在壓力下將無回應網站重新上線時可能發生的人為錯誤。
次要資料庫
使用次要資料庫可能很實用，原因如下：
- 如果主要磁碟機發生故障，則為暖待命
- 允許來自應用程式的就緒請求
- 允許發生mysqldump，並允許在不鎖定資料庫的情況下發生正常交易
- 允許從外部資料來源存取資料，而不會降低網站根據客戶請求交易資訊的能力。
次要資料庫可以當做warm standby使用。 當您考慮如何從主要資料庫失敗中復原時，這可能會開始起作用。 將次要資料庫升級為主要資料庫，比將資料庫重建和還原至新建立的Mysql執行個體來得簡單。 這減少了復原作業期間的實際停機時間。
您可以轉移部分請求至次要資料庫。 若使用此方法，建議將次要資料庫設為唯讀。 允許Adobe Commerce應用程式使用此次要資料庫進行讀取作業，有助於接受部分讀取請求並允許次要資料庫回應。 不過，這項變更只佔所有請求的30-50%，但您可以從主要資料庫中帶走的任何負載都是勝利。
建立包含復原的部署計畫
每個部署都應該包含復原計畫。 是的，每個部署。 如果您對此有所規劃，您絕不會感到驚訝，並準備好應對糟糕的事件。 有時候，最簡單的程式碼更新可能會因為任何原因而災難性失敗。
考慮一個團隊認可小型簡單提取請求，以在資料庫中執行結構描述變更的真實故事。 隨著部署從1分鐘增加到5分鐘，接著又增加到10分鐘，團隊變得越來越擔心。 他們至今仍無法驗證和考慮的生產資料庫與中繼資料庫有任何差異。 他們在使用生產環境復本重新整理中繼環境時，會移除所有客戶資料的慣例。 這表示在此之前的所有測試和QA都會反映部署，應該只需要幾分鐘即可完成。 事實上，他們擁有超過2,000萬客戶，而這項細微的結構變更需要非常長的時間才能完成。 由於他們不知道這實際需要多久，因此他們被迫終止mysql程式並復原部署。
準備部署的復原程式只需要幾分鐘的時間，因為整體程式將會類似。 不過，您應該花一些時間，記錄您會將Git存放庫的HEAD重設回哪個認可。 您應該記錄要使用的資料庫快照集或尋找目前快照集的位置（如果永遠在同一個位置）。 已定義必須討論部署狀態的時間以及自動生效的時間。 例如，如果任何部署需要超過15分鐘，請詢問專案經理和其他利害關係人是否應該繼續。 但是，如果流程需要45分鐘，則自動執行復原流程並通知所有利害關係人，無論專案經理和架構師是否對此專案有所猶豫。
請確定有幾個人參與了整個流程和每個階段。 讓中層開發人員檢閱部署程式、復原程式和檔案位置，是讓他們參與的絕佳方式。 他們最終會執行這些步驟，因此讓他們瞭解整個流程是長期成功的關鍵。 確保每個人都有權叫用部署。 讓您的團隊擁有如此多的發言權，不僅可增強能力，而且可帶來豐厚的回報。 如果初級開發人員真的感到缺少某樣東西，他們應該感到必須大聲疾呼，讓他們的謹慎聲音被聽到。 讓架構師和專案經理確認或減輕他們的恐懼。 請務必建立強大的團隊，負責尋找專案，並保持完美部署的往績記錄。
驗證網域名稱管理、DMS、SSL、WAF的存取權
由於網域名稱過期，因此DNS記錄可能會意外修改、SSL憑證可能會過期等等；請確定您能夠登入並驗證是否經常連線。 每季進行這項簡單的檢查，可讓您確知物品所在位置，尤其是在緊急情況下。 請勿假設您的DNS是在您的註冊機構中進行管理，只是為了知道您已在Amazon中進行管理。 這些記錄不常使用，因此很容易忘記記錄所在的位置。 不要只信任使用者名稱和密碼的書面檔案。 登入每個組態，並驗證您要尋找的組態是否確實在那裡受到管理。 在管理層變動或公司收購期間，事情經常會改變，而且只有一個人知道發生了什麼，因為他們是進行更新的人。 他們不知道您依賴共用的Word檔案，檔案位置是什麼、使用者名稱和密碼。 尋找對您及貴組織有意義的檢查程式，但每三至六個月執行一次此作業是個不錯的起點。