SAP成都研究院DevOps那些事

今天的文章來自個人同事平靜靜，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)的團隊，而平靜靜就是當時的主要組織者。

下面是平靜靜的正文。

• • *

你們好，我是平靜靜，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 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服務器等維護成本，經過簡單的少許配置代碼就能夠完成pipeline的構建。劣勢在於，因爲這類工具是多個開發團隊使用，有資源上受限的可能性，以及當遇到服務器問題時使用上的不靈活性。

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

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

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

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

要獲取更多Jerry的原創技術文章，請關注公衆號"汪子熙"或者掃描下面二維碼: