SAP成都研究院DevOps那些事

作者：平靜靜 來源：微信公眾號【汪子熙】

原文連結：https://mp.weixin.qq.com/s/dcXZBwaVLZpYTHH4oN8wlw

今天的文章來自我的同事平靜靜，SAP成都研究院一位程式媛。平靜靜2010年加入SAP，熟悉她的人一般都叫她平靜。在她待過的每個小組，平靜靜都不是最引人矚目的開發人員，然而她總是能一如既往，保質保量地完成開發任務，為團隊默默地做出自己的貢獻。

Jerry和平靜靜曾經在同一開發小組裡共事過三年多的時間。2013年時，我們所在的CRM開發團隊曾一起努力，將Twitter, Facebook和新浪微博等社交媒體的支援新增到CRM呼叫中心中去。令Jerry至今記憶猶新的是 ，早在2013年9月，平靜靜就開始使用Selenium進行SAP CRM WebUI的自動化測試用例開發，並且是當時SAP成都研究院最早使用Git進行原始碼管理的同事之一，比2014年成都團隊大規模從ABAP技術棧切換到Java技術棧上整整早了一年。Jerry對於Selenimu的學習最早也是從閱讀平靜靜的程式碼開始的。當時的CRM團隊也是SAP成都研究院最早開始實踐探索性測試( Exploratory Test )的團隊，而平靜靜就是當時的主要組織者。

今天平靜靜要介紹的DevOps Enginner，有些朋友對這個詞可能不太熟悉。其實就在前幾天，準確地說是2018年6月27日，Jerry的朋友圈被一條新聞刷屏了。

6月27日下午，阿里雲出現重大技術故障，故障於北京時間2018年6月27日， 16：21左右開始，16：50分開始陸續恢復 。阿里雲官方給出的故障時間大概持續了30分鐘，陸續恢復時間有一個小時多。

6月27日凌晨時分，阿里雲釋出了該故障原因的官方說明：“ 我們在運維上的一個操作失誤，導致一些客戶訪問阿里雲官網控制檯和使用部分產品功能出現問題。 ”

該官方宣告提到的“觸發了一個未知bug”，具體是什麼bug？

“具體原因是一個核心的應用在拉VIP列表的時候，返回了空列表，這就會導致上千VIP被禁用了 。VIP = Virtual IP Address，虛擬IP地址，主要作用為叢集的負載均衡的入口地址，可通過一個VIP的地址，實現一組業務的訪問，通常也叫叢集負載均衡技術。VIP是叢集業務的入口，如果數千個VIP被禁用了，可能後端上萬臺的服務、應用、資料庫等將直接無法訪問，本次故障盲點，是測試通過了，在生產環境觸發了一個未知bug，導致核心應用在拉取VIP列表時，為空了，導致內部的上千臺負載均衡不可用，從而後端的應用也不可達。”

對於這個重大技術故障發生之後阿里雲運維團隊的處理速度，業界還是給予了很高的評價：

"對於大型網際網路公司，運維技術架構都是多層機構。 在內部負載均衡上配置的VIP如果不可達的話，後端的service層和資料庫等內容，都是不可達的，這也是為什麼故障的時候，頁面能開啟，但是報錯為502故障，502錯誤一般常為後端伺服器不可用，這也說明了故障的根源所在。阿里的運維團隊故障響應還是比較給力的，數千個VIP配置錯誤，在半小時內從發現，到定位，到故障排除，以及解決，還是挺快的。”

說完了阿里雲，言歸正傳，讓我們來了解SAP成都研究院的DevOps吧。

下面是平靜靜的正文。

---

大家好，我是平靜靜，過去的一年我在SAP成都研究院Customer Engagement Center團隊擔任DevOps Engineer 。您一定聽說過 Development Engineer ( 開發工程師 ) ，也聽說過 Operation Engineer ( 運維工程師 ) ，那 DevOps Engineer 是個什麼工種？想回答這個問題，在我擔任 DevOps Engineer 這短短的一年看來，其實既有隻緣身在此山中的困惑，也有不足為外人道的窘迫。

文章目錄

• DevOps in SAP

• DevOps in SAP Customer Engagement Center

• DevOps Engineer到底要幹些什麼？

• DevOps Engineer的一天，大概是什麼樣的？

現在就讓我梳理一下自己對 DevOps 的粗淺認識和感受。如果您對 DevOps 的話題感興趣，恰好身邊也有 DevOps 小夥伴，不妨也跟他們聊聊。

DevOps in SAP

早些年 SAP 的產品大多是開發週期較長的On- Premise 產品，比如 ERP ， CRM 。SAP除了開發團隊，還有一個專門負責產品維護的部門,名叫 IMS 。那時候的模式是開發團隊完成開發之後，就可以妥妥地移交給 IMS 團隊。一年之後新的版本釋出，再繼續 移交 。任何客戶的問題如果SAP Primary Support解決不了，那麼都是交給 IMS 團隊處理，開發團隊可以很大程度上心無旁騖地繼續做下一階段的開發。

 

2015 年左右，隨著公司的戰略轉型，一系列基於雲的新產品推出，SAP開發團隊也在不斷追求沒有最短只有更短的交付時間。 1 年， 3 個月， 1 個月， 2 周。。。試想一下，原來那套基於On-Premise的開發和維護的模式是不是就搞不定了？也許 IMS 團隊的同學會跳出來說，容我們緩緩，上週 移交 給我們的東東我們還沒處理完 bug 呢，這周又來這麼多新 功能， 實在是 Hold 不住了。。。另一方面 ，SAP開發團隊也想了解，產品做得到底怎麼樣，應該怎樣迭代得更好呢？但是隔著 SAP Primary Support 以及 IMS 團隊 ， 離客戶這麼遠，資訊從何而來呢？

不只是 SAP 一家公司在思考。 戰略轉型，也就意味著組織結構需要做出必要的調整。 國內外的很多軟體公司都在尋求新的產品開發和維護模式，使得各個團隊之間減少時間損耗，從而更加高效地協同工作。如果開發和維護不再是界線分明的兩個團隊，而是由一個團隊同時 Hold 住開發和維護，是否可行呢？

 

借用維基百科中關於DevOps的定義：

DevOps（Development和Operations的組合詞）是一種重視軟體開發人員（Dev）和IT運維技術人員（Ops）之間溝通合作的文化、運動或慣例。透過自動化軟體交付和架構變更的流程，來使得構建、測試、釋出軟體能夠更加地快捷、頻繁和可靠。

https://zh.wikipedia.org/wiki/DevOps

DevOps in SAP Customer Engagement Center

關於 DevOps 理念在一個團隊中如何落地，細分一下，大致有：

1. 開發即維護：每個小夥伴都既是開發，也是維護，不分工;

2. 開發和維護：團隊中一部分小夥伴是開發，另一部分是維護，分工明確;

3. 一半開發，一半維護：團隊中的維護工作由開發小夥伴們來定期輪崗。

第一種策略最貼近 DevOps 的理念。第二種策略最接近傳統，第三種策略折衷。沒有孰優孰劣，合適的才是最好的。要考慮的因素既要保證產品的 交付 ，同時兼顧團隊小夥伴們自己的職業興趣點和 專長 ，以及溝通成本。

SAP成都Customer Engagement Center 團隊最初在轉型 DevOps 時，採用第三種方式，由開發的同學每兩週輪一次崗。每位同學在 輪崗 的兩個星期中， 50% 的 精力 用來做開發，另外的 50%精力 用來處理 DevOps 相關的 任務 。在執行一段時間之後，收到的反饋認為，雖然仍有 50%精力 做開發，但會影響 大家做事的專注力 ，整體效率不是太高。同時，有時輪崗的交接做得不到位會導致後續要花更多的成本在瞭解問題的上下文和 跟蹤 問題上。

成都團隊在之後的執行中調整為了第二種方式，雖然更接近傳統方式，但彌補了方式三的短板。

 

DevOps Engineer 到底要幹些什麼？

DevOps Engineer 是指 DevOps 的模式下，身兼開發和維護的 Engineer 。當然在現實生活中， DevOps Engineer 並不一定跟 Developer 承擔同樣的開發工作。那麼 DevOps Engineer 在他/她們的小角落裡都在做些什麼呢？

 

DevOps ，就像這個詞的構成方式，是 Development 和 Operation 的組合，那麼一千個組就可能有一千種組合方式。這取決於 DevOps Engineer 的 資源 ，以及團隊目前所處的階段。

 

就SAP成都 Customer Engagement Center 團隊而言，團隊目前處於已發版，有客戶的狀態。這意味著可能會有客戶報過來的 ticket ，以及來自售前團隊以及內部 產品經理 團隊的 demo  需求，也可能會有更多的內部 ticket 以及 tenant setup 的要求。因此 DevOps 同學會投入更多精力在 Operation 方面，其實也就是下圖中的客戶生命週期（ Customer Life cycle） 方面。

 

再比如，如果團隊處於開發階段，未發版，那麼來自於 客戶生命週期 方面的 任務 不多，可以更多地關注 CI/CD（持續整合 / 持續交付） 以及監控等環節了。

在有更多的 資源的 情況下， DevOps 同學就可以 專注於 偏 dev 方向的 話題上 ，比如客戶系統的自動化建立， cloud reporting 等等。

從客戶簽單的那一刻起，就進入了客戶生命週期管理：首先是客戶系統的配置，測試，將系統交付給客戶使用；其次是支援客戶在使用系統過程中遇到的各種問題；再到客戶系統的升級，以及可能的遷移等。這一系列活動都是直接跟客戶生命週期管理相關的。

 

那麼，怎樣保障客戶在使用雲產品的過程中能夠達到合同中所約定的服務品質（SLA：Service-Level Agreement）呢？是不是程式碼的質量足夠好就可以了呢？當然，程式碼質量好肯定是產品的重要保證，但不同於On-Premise產品之處在於，雲產品有更多的不確定性，也就更加需要監控工具的輔助。

 

首先，採用微服務架構的產品需要考慮部署在雲上的服務是否可達。打個比方，如果部署在雲上的服務處於 stop 的狀態，那麼客戶的系統肯定是無法正常工作的。為了瞭解雲上的服務是否還“活” 著，可以使用 availability check （ SAP 內部工具）, 每間隔一定的時間就對雲上的服務發起請求。通過請求返回的響應值來判斷雲服務的狀態，從而達到監控的目的。為了接近實時，間隔的時間可以儘可能的短，比如說每分鐘發起一次請求。同時為了避免誤判，也可以調整設定，當 2 或 N 次以上的請求都顯示不可達時，才發出警告提示。這樣，當有異常情況出現時，比如確實有服務“掛 ” 了，  availability check 就可以第一時間通過郵件通知到相應的團隊。或者如果還連線了 SPC 系統 ， 還可以在 SPC 中建立 ticket 通知到一線的雲支撐團隊。

另一方面，雲上的服務只要是 live 狀態就可以了麼？那麼如果遇到服務響應時間下降或者錯誤率升高，會不會客戶很生氣，後果很嚴重呢？這個時候，就需要別的監控工具了。目前正在服役的工具是 Dynatrace 。每個團隊可以根據自己的情況定製監控皮膚。此外在遇到具體問題時，可以跳轉到具體的某個服務頁面檢視相應的指標，比如 Response time, Failure rate, CPU consumption, Throughput ，來分析問題可能的原因，以及相應的對策，比如是否需要增加服務的 instance 或者 memory 。如果調整之後的效能仍然不夠滿意，那麼就需要深入看看程式碼層面是否有問題，檢查是否存在可優化的地方。

除了以上提到的 availability check 以及 Dynatrace ，行業中還有很多其他的監控工具，具體使用哪種取決於公司或者每個團隊的選擇。

 

客戶在使用系統的過程中，難免會出各種各樣的問題，有的疑似 bug ，於是客戶一封 ticket 就報了過來。 DevOps 或者開發團隊想要重現一下問題， debug 看看。額， debug 對於雲產品實在是種奢侈，只好求助於問題發生時留下來的蛛絲馬跡。這個時候如果雲平臺自帶的檢視日誌的命令不夠用，比如說 cf logs ，那麼就只好藉助於 Kibana 這一類的視覺化日誌分析工具了。

如果說，監控是為了實現更好的服務質量，那麼 CI/CD 就是為了在不影響產品質量的前提下更快地交付產品。將 versioning ， build ，各種測試，程式碼掃描，以及 deploy 等步驟作為一個 pipeline 來整體考慮，這是現在更通用的做法。據瞭解，目前有的團隊自己來負責從 Jenkins 伺服器到 pipeline的 配置 ， 有的團隊則藉助於 SAP 內部的 CI/CD 工具，比如目前在服役的 codepipes ，或者 piper 。使用工具的優勢在於，節省了 Jenkins 或 Bamboo 伺服器等維護成本，通過簡單的少量配置程式碼就可以完成p ipeline 的構建。劣勢在於，由於這類工具是多個開發團隊使用，有資源上受限的可能性，以及當遇到伺服器問題時使用上的不靈活性。

所以，在我看來，客戶生命週期管理是核心，監控以及 CI/CD 其實也是為了更好的服務於客戶生命週期。

DevOps Engineer 的一天，大概是什麼樣的？

如同前面提到的，不同組的 DevOps Engineer 工作內容可能很不一樣。舉個例子， 有時候會收到幾個 ticket ，急著救火，有時候會耗在配 demo 上，搗鼓半天。有時候在發版的前期跟難用的 pipeline 工具死磕。 DevOps Engineer 不是最懂需求的，甚至也不精於測試和開發。但是會發現當有問題問了一圈無果時，也許問問 DevOps Engineer ，他/她或許是知道答案的那個人，或者能夠幫您找到真正有能力解決問題的人。

 

感謝閱讀，以及瞭解 DevOps 的那些事。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31473948/viewspace-2158719/，如需轉載，請註明出處，否則將追究法律責任。