或者有可能嗎？當然，SAP系統遷移是一個複雜而艱苦的過程，其成功需要所有參與者的良好協調工作。而如果在短時間內進行遷移，任務就會變得更加複雜。並不是每個人都決定要這樣做。可能有幾個原因。例如，該過程本身漫長且組織複雜。此外，也存在系統意外停機的風險。或者客戶不確定，在經歷了這樣的手術後，他們是否會獲得與所付出的努力相稱的利益。不過，也有例外。
下面，我們將討論客戶在遷移和維護 SAP 系統過程中遇到的困難，討論為什麼刻板印象並不總是符合現實，並分享一個案例研究，說明我們如何成功地將客戶的系統遷移到 SAP 系統。新的基礎設施建設僅花了三個多月的時間。
SAP系統託管
就在五年前，還很難想像客戶會大量開始使用 SAP 應用程式的託管資源。在大多數情況下，它們是在本地實施的。然而，隨著外包模式和雲端服務市場的發展，客戶的世界觀開始改變。影響 SAP 選擇雲端的論點是什麼？
- 對於剛計劃實施SAP的初學者來說，雲端基礎設施幾乎是一個標準選擇——資源可擴展以滿足系統當前的需求，並且不願意將資源轉移到非核心能力的開發上。
- 在擁有大型系統環境的公司中，在託管 SAP 系統的幫助下，CIO 可以達到質的不同程度的風險管理，因為合作夥伴對 SLA 負責。
- 第三個最常見的論點是建立基礎設施以實現高可用性和災難復原場景的成本高昂。
- Factor 2027 – 供應商宣佈在 2027 年終止對遺留系統的支援。這意味著將資料庫轉移到 HANA，這需要現代化和購買新運算能力的成本。
俄羅斯的SAP託管市場現在可以說已經相當成熟了。這為想要更改託管平台的客戶提供了充足的機會。然而，由於遷移程序的複雜性，此類專案理所當然地會引起企業的注意。這迫使客戶對服務提供者提出了更高的要求，他們不僅必須具備託管和維護 SAP 系統的卓越能力，而且還必須在遷移領域擁有成功的經驗。
變更SAP託管有哪些困難？
主機代管服務各不相同。它們可能無法達到宣稱的服務水平，條款中可能包含許多「但是」和星號，以及隱藏在細則中的免責聲明，而且資源和能力有限。 主機提供者客戶溝通不良、官僚作風、技術限制、技術支援不足以及其他諸多細節問題——這些只是客戶在將業務系統外包到其他基礎設施時可能遇到的部分陷阱。通常，這些問題隱藏在冗長的合約中，客戶難以察覺，只有在實際使用服務時才會浮出水面。
在某些時候，客戶會明顯地意識到他所收到的服務水準與他的期望相去甚遠。這是一種尋找解決方案來糾正這種情況的催化劑，如果失敗，當問題累積到極限並且變得非常痛苦時，他們會採取積極行動，以改變服務提供者的方向開發替代方案。
他們為什麼要等到最後一刻？原因很簡單 - 為客戶遷移系統的過程並不總是透明且易於理解的。客戶很難評估與遷移過程相關的實際風險。我們可以說，客戶的遷移是一種黑盒子：價格、系統停機時間、風險以及如何減輕這些風險都不清楚，總的來說，它是黑暗和可怕的。就好像，如果不成功，那麼高層和表演者都會頭暈目眩。
SAP 是一個企業級系統，很複雜，而且，溫和地說，並不便宜。適當的預算用於它們的實施、修改和維護，企業的壽命取決於它們的可用性和正確運作。現在想像一下停止一些大型生產的後果。這些是財務損失，可以用大量零的數字來計算，以及聲譽和其他同樣重大的風險。
我們將分析從某個客戶遷移 SAP 系統時每個階段可能出現的困難。
準備與設計
遷移是一個包含許多不同部分的公式。最重要的階段之一是設計和準備目標（新）基礎設施的階段。
我們需要深入研究系統的現有實現及其架構。在目標基礎設施中，我們在某個地方重複了現有的解決方案，在某個地方補充和改進了它們，在某個地方重新設計了它們，經過深思熟慮並選擇了解決方案以確保容錯性和可用性，並儘可能地整合所有資源。
在設計過程中，進行了許多不同的練習，最終使我們能夠為遷移做好盡可能多的準備，並考慮到各種細微差別和陷阱（稍後會詳細介紹）。
我們最終得到的是基於我們的資料中心單獨設計的私有雲基礎設施：
- SAP HANA 專用實體伺服器；
- 用於應用伺服器和基礎架構服務的VMware虛擬化平台；
- L2 資料中心之間重複的通訊通道 VPN;
- 兩個主要儲存系統，用於分隔產品和「其他物品」；
- SRC 基於 Veritas Netbackup，具有獨立的伺服器、磁碟架和磁帶庫。
以下是我們如何從技術角度實現這一切。
SAP
- 為了有效地將儲存用於高效的 HANA，我們使用共享磁碟，而不使用 SAP 進行系統資料庫複製。所有這些都包含在基於 Pacemaker 的主備 SUSE HAE 叢集中。是的，恢復時間比複製要長一點，但我們節省了一半的儲存空間，從而節省了客戶的預算。
- 在預生產環境中，HANA叢集被放棄，但技術上重複了生產配置。
- 測試和開發環境分佈在多台伺服器上，沒有 MCOS 配置中的叢集。
- 所有應用程式伺服器均已虛擬化並託管在 VMware 中。
塞蒂
- 我們使用交換器堆疊將控製網路和生產網路的輪廓進行物理分離，將生產網路轉向客戶的資料中心。
- 我們安裝了足夠數量的網路接口，以免混合大量流量。
- 為了從儲存系統傳輸數據，我們創建了經典的 FC SAN 工廠。
SHD
- SAP 的生產和預生產負載留在全快閃陣列上。
- 開發人員測試環境和基礎設施服務被放置在單獨的混合陣列上。
腸易激綜合症
- 使用 Veritas Netbackup 製作。
- 我們在內建腳本中添加了一些內容來備份 MCOS 配置。
- 我們將可操作的副本放在磁碟架上以便快速恢復，並使用磁帶進行長期儲存。
監控
- 所有硬體、作業系統和 SAP 均安裝在 Zabbix 下。
- 我們在 Grafana 中收集了許多有用的儀表板。
- 當警報發生時，Zabbix 可以在事件管理系統中建立請求；我們已在 Jira 上實現了該請求。資訊也在 Telegram 頻道中重複。
Telegram
HANA 的整體健康狀況
SAP 應用程式伺服器狀態：
基礎設施服務
- 為了服務內部命名空間，建立了一個 DNS 伺服器集群，該集群與客戶的伺服器同步。
- 我們創建了一個單獨的檔案伺服器用於資料交換。
- 為了儲存各種配置，增加了Gitlab。
- 對於各種敏感訊息，我們使用了 HashiCorp Vault。
遷移過程
一般來說，遷移過程由以下階段組成：
- 準備所有必要的專案文件；
- 與目前提供者談判 - 解決組織問題；
- 項目新設備的採購、交付和安裝；
- 測試遷移和流程調試；
- 系統轉移、戰鬥遷移。
2019年XNUMX月底，我們簽訂了合同，然後設計了架構，與客戶達成協議後，我們訂購了必要的設備。
您首先需要關注的是設備的交貨時間。平均而言，為 SAP NAHA 交付滿足軟體製造商對硬體平台要求的認證硬體需要 10-12 週。考慮到季節性（該項目的實施恰逢新年），這一周期可能會再延長一個月。因此，有必要盡可能加快流程：我們與經銷商供應商合作，同意透過飛機（而不是陸運和海運）加急交付。
11 月和 12 月用於準備遷移和接收部分設備。我們在公有雲的測試台上進行了準備工作，完成了所有主要步驟並發現了可能的困難和問題：
- 為專案團隊成員之間的互動制定詳細的計劃，並按分鐘計時；
- 以與目標基礎設施中大致相同的方式為資料庫和應用程式伺服器建立了測試平台；
- 配置必要的通訊管道和基礎設施服務來測試整合的運作；
- 制定切換方案；
- 雲端還幫助我們建立預先配置的虛擬機器模板，然後我們只需將其匯入並部署到目標環境即可。
元旦假期前夕，第一批設備抵達我們手中。這使得在真實硬體上部署一些系統成為可能。由於並非所有東西都已到達，我們連接了替換設備，我們設法與供應商和分銷商就其供應達成一致。我們在最後階段收到了目標基礎設施的殘骸。
為了趕上最後期限，我們的工程師不得不犧牲新年假期，在 2 月 XNUMX 日假期期間開始準備目標基礎設施。是的，當它著火併且沒有其他選擇時，有時會發生這種情況。企業的生存所依賴的系統性能處於危險之中。
遷移的一般順序如下：首先是最不關鍵的系統（開發環境、測試環境），然後才是生產系統。遷移的最後階段發生在一月底和二月初。
遷移過程的計劃精確到分鐘。這是一個割接計劃，其中列出了所有任務、完成時間和負責人。所有步驟在測試遷移中都已經制定好了，因此在即時遷移中只需遵循計劃並協調流程即可。
遷移分幾個階段有系統地進行。每個階段有兩個系統。
三個月衝刺的結果是系統在 CROC 資料中心全面運作。整體而言，透過團隊合作取得了積極的成果；整個過程中所有參與者的貢獻和奉獻是最大的。
客戶在專案中的角色
與我們的客戶即將離開的提供者溝通並不容易。這是可以理解的；他們是對成功完成該專案感興趣的人名單上的最後一個。客戶自己承擔了升級和解決所有溝通問題的任務，並解決了 100500% 的問題。對此特別感謝他。如果沒有這種可行的參與過程，專案的結果可能會完全不同。
由於「前」提供者方面的流程正規化，基礎設施支援由實際上遠離問題的專家進行，當時仍然是他們的客戶。例如，匯出相同資料庫的過程可能需要一到五個小時。然後這似乎是某種魔法，一個從未向我們透露的秘密。也許技術支援工程師在此期間沉思冥想，忘記了遙遠的俄羅斯某個地方還有最後期限，工程師沒有新年沙拉，客戶在哭泣和痛苦…
項目成果
遷移的最後一步是轉移系統以進行維護。
現在，我們為客戶要求提供單一視窗服務，並與我們的合作夥伴殷智諮詢一起涵蓋與支援基礎設施元件和 SAP 基礎相關的整個任務範圍。客戶已經在私有雲中生活了六個月。以下是這段時間服務案例的統計：
- 90 起事件（20% 在不涉及客戶的情況下得到解決）
- 在 SLA 內解決 – 100%
- 計劃外的系統關閉 – 0
如果您有與我們的客戶類似的任務，並且想要了解更多有關如何解決它們的信息，請寫信至：ahaidukov@croc.ru
來源： www.habr.com
