1. 程式人生 > >微服務時代下崛起的 TestOps 工程師

微服務時代下崛起的 TestOps 工程師

前言

微信中有些上次參加源創會微服務專場的很多朋友,希望整理下關於 PPT 的演講內容,然後發表一篇文章:關於微服務下 TestOps 的工作和未來。

然後我也正有這樣的想法,但是可能單方面的自我總結比較片面,希望幫助很多還在迷茫的探索的QA工程師尋找未來之路。

文章的大綱:

  1. 微服務和 DevOps
  2. DevOps 孵化下的 TestOps
  3. TestOps 在未來

9月24日源創會微服務專場重慶站(https://www.oschina.net/question/2686220_2267084)

TestOps 很新鮮(內心認為你們是這樣想的),也可以說是衍生的新型職位,維基百科甚至沒有收錄關於 TestOps 的詞條。

谷歌(Google)上的關於 TestOps 只有寥寥無幾的文章,國內的 TestOps 更是一片空白,很多人停在理論上,沒機會去實踐。

因為機緣我在一家新型網際網路創業公司,公司沒有運維的同時,又是在微服務的架構下,我們又在做敏捷… 所以有幸改變了之前的工作方式和內容。

開始前,有個段子。剛進入公司的時候內心還在想:xx(自動幻想遮蔽詞),現在測試要求會 coding 就算了,怎麼還要會運維,而且不是簡單的 linux 命令,搭建伺服器、管理伺服器、Docker、微服務…有些名詞聞所未聞,當時還覺得年代變了嗎?

要求這麼高了,基於想提高自己、不被網際網路淘汰的態度接受了這份看起來難度很大的工作。

CTO 是微服務架構方面的專家,他引領我走向了TestOps,然後我發現我已經無法自拔的愛上了這個職位(由衷的感嘆)。

我們愉快的開始吧!

TestOps

這次文章的主題是關於新型的工程師TestOps。

工程師TestOps

開始文章前,給大家講一個故事,為什麼叫容易消失的測試工程師。產品研發前每次會開一個需求評審會,產品經理會叫上研發經理、前端、後端坐下來翻雲覆雨一波。

討論片刻,遇到問題想到測試曾經發現一個詭異的問題,這時候拍了拍腦袋,忘了叫上測試人員討論呢,連忙去喊測試過來一起討論。次日,又是一番舌戰群儒。

又發現一個另外的測試同志發現的詭異問題,卻又忘了喊測試…而且這樣的頻率也很頻繁。測試還要每次不厭其煩的補位需求評審會。

反而每次產品有關業務的一些問題又會去詢問測試具體細節,這明明是很矛盾的消失啊?(黑人問號臉)

為什麼會出現測試容易消失掉?因為測試攻城獅的職業定位緣故,很多人看來測試的工作輕鬆,技術含量沒有那麼高,所以導致存在感降低。

微服務

如何做一個有存在感的設計師工程師呢,咱們開始前規避這個話題,文章最後來回答這個問題。

DevOps

我們先看看微服務和 DevOps。微服務這兩年火的一塌糊塗,跟敏捷離不開。網際網路日新月異,產品迭代供不應求,那麼敏捷作為這個階段的主題。微服務跟隨著浮出海面並且波濤洶湧。

微服務

 DevOps

咱們先看看傳統的幾個工作流,詢問過一些朋友網友和同事(第一種比較主流,第二種我曾經的一家公司):

  • 測試為中心:開發提交程式碼到程式碼倉庫,運維拉取程式碼部署到伺服器上。運維通知測試進行測試,測試發現BUG告知開發修改提交程式碼然後迴圈。
  • 開發為中心:開發提交程式碼到程式碼倉庫,通知運維拉取程式碼部署到伺服器上。開發再通知測試進行測試,測試發現BUG告知開發,開發修改提交程式碼到倉庫。開發再通知運維拉取部署。
  • 沒有中心:一些創業公司沒有太多的資本和業務有些開發兼職運維測試(手動滑稽)

我們比較下前面兩種的優劣吧:

第一種情況:測試會花費大量的時間在溝通,但是有多領域技能的提升。開發人員專注力提升。缺點是:測試人員無法專注於質量掌控,開發局限於coding。

第二種情況:開發會花費大量的時間在溝通,但是有多角度的視野。測試人員專注力提升。缺點是:開發人員無法專注於業務開發和技術專研,測試侷限於測試。

他們有一個共同的缺點:

無論是開發和運維還是測試和運維,他們之間總有無盡的黑暗的牆阻隔。運維像個黑盒被吞沒。

那麼微服務如何解決這些場景呢?

持續整合

這是個微服務較為主流的工作流程:

開發人員提交程式碼到程式碼倉庫,微服務所獨有的持續整合CI(Continuous Integration)和持續交付工具CD(Continuous Delivery)自助拉取程式碼調取一個配置中心,ssh連線對應遠端伺服器將程式碼部署到伺服器上啟動服務。通過工具通知或者開發測試溝通通知測試人員進行測試。測試通過後,部署到預生產環境和生產環境。

紅色框內的工作流我們稱之為 DevOps。這個名詞最近越來越火。簡單解釋下DevOps(來自可愛的wiki百科):

DevOps 是軟體開發、運維和質量保證三個部門之間的溝通、協作和整合所採用的流程、方法和體系的一個集合。

它是人們為了及時生產軟體產品或服務,以滿足某個業務目標,對開發與運維之間相互依存關係的一種新的理解。

大家知道了DevOps是種工作流,甚至可以叫做工作文化。這些工作流的設施由哪些東西支撐呢?我們可以進行技術選型:

DevOps

這些都是比較主流的微服務設施,當時現場有人提問:像京東有一整套的設施為何不去使用?

我們需要的設施是服務於最適合當前的業務和架構場景的,所以我們的設施都是經過調研斟酌的。

篩選組合成了一套最適宜於自己架構的設施,經歷過很多次失敗。並且我們不斷完善我們的架構,最近在做高可用服務,歡迎志同道合的夥伴加入我們一起玩微服務。

我們比較一下傳統行業下和微服務下的變化吧:

  1. 運維人員通過之前人為部署變為機器部署,我們稱之為去OPS化。
  2. 測試由程式碼測試變成映象測試
  3. 處理線上故障和上線宕機機制改變

說到映象這裡有一個單詞不得不提了:Docker,Docker 和微服務相輔相成。如果說微服務沒使用 docker 甚至都是個偽命題。

Docker 有三個大要素:映象倉庫、映象、容器

下面總結了 Docker 的簡易工作流:

Jenkins 和 Ansible 設施把開發人員的程式碼通過讀取dockerfile檔案的方式生成一個映象。

這個映象扔進映象倉庫中,可以是個視覺化的頁面進行管理。當容器啟動時從對應的映象倉庫拉取分發到被 docker swarm 叢集下的一個 worker 服務中就被執行起來了。

Docker 不是虛擬機器,它類似於虛擬機器。但是它更輕量,容器只用啟動開發者軟體所需要的依賴,不像虛擬機器啟動需要的依賴系統和軟硬體。

那麼 Docker 的 images 是怎麼回事呢?我嘗試舉個栗子:images像安裝包,它裡面是個包。就像蘋果手機,APP 就是映象,APPstore 是映象倉庫,手機是啟動 APP 的載體也就是容器。

我們之前對映象有個誤區:

映象

之前我們一直以為一個映象對應一個容器,所以不同環境啟動不同的容器。我們發現其實映象中依賴和程式碼都是一樣,除了資料庫的地址也就是資料來源不同。

如果一個映象對應一個容器我完全可以按照傳統的做法將程式碼部署到不同的伺服器上就可以了。所以我們認為真正的映象應該只有一個,所有不同的伺服器上的容器啟動的映象也應該是一個。

我們如何解決呢?

資料

需要解決這個問題很簡單,將image中的APP和資料來源分離。映象只存在程式碼和開發者依賴的軟體,不存在任何的環境變數。通過資料卷掛載的方式,呼叫外部配置中心對映。映象永遠是那個映象。

基本到這第一節的內容就結束,這次主題是Testops。很多人肯定會奇怪為什麼要將微服務和DevOps,TestOps是被孵化出的衍生職位,讓微服務飛一會兒。我們好登機!讓我們進入正題吧:

Testops

一張wiki百科的維恩圖:

大家知道過前端和後端是沒有分離的,後來前後端分離後,前端逐漸發展成了大前端,那麼未來是不是DevOps也會進行革命性的變革:

之前講過DevOps是個工作流也可以說是個團隊,將來它會劃分為3個工種測試開發已經有了,那麼DevOps會分裂為一個DevOps工程師和TestOps工程師。

TestOps工程師

之前那副圖有講過DevOps工作流。以我為例,公司Testops主要涉及的工作內容,如圖所示的所有的範圍:

包括持續整合工具的搭建和維護,配置中心的程式碼編寫和維護。服務相關的處理和維護。測試的本職工作。

TestOps

如何定義 TestOps 呢?

顧名思義:測試運維。Testops 還要站在測試角度推動研發和運維,將持續測試運用到持續整合中的我們都可以稱之為 TestOps。

持續整合

有一個簡易開發團隊中 Testops 的工作流:

TestOps 應該掌握哪些技能呢:

  1. Dev 能力用於測試工具開發和運維工具開發,並不是業務程式碼開發。
  2. Ops 能力用於微服務設施和基礎設施搭建和維護,區別於運維人員的服務效能和安全性監控
  3. QA 基本具備的能力和整個測試體系的運用。

TestOps 在 DevOps 中的價值體現於團隊價值和個人價值:

TestOps 應該有怎麼樣的未來?

曾經看到一篇文章,這位賽斯-埃利奧特是位微軟的測試專家,他很多文章開始關注 TestOps,他提及臉書和微軟開始改變他們的流程,開發者不再是部署程式碼到伺服器上,他們會有一部分 TestOps 任務。

也就是說未來成為 TestOps 的不單單是測試也有可能是開發或者運維。

未來價值:

DevOps 能推動整個測試和運維團隊統一整個研發流程,幫助團隊更敏捷的提交產品。

他能解決流程問題,但是無法發現開發過程中測試的缺陷。只有專業的 TestOps 站在專業的測試角度推動開發和運維一起進行。

TestOps 和 DevOps 形成一個完整的持續整合和持續交付體系,才是完善了整個微服務下的工程師架構了。

設想下未來的工作場景:

開發人員提交程式碼到程式碼倉庫,C I工具會有持續測試平臺和持續部署平臺。持續測試平臺包含:程式碼質檢工具類似 sonar,介面測試工具,UI測試工具…測試人員只用編輯測試場景和用例來幫助工具執行用例。

如果有了人工智慧AI那麼很有沒有可能功能測試人員將會失業哦。

未來 TestOps 應該會一直關注:

簡單做個自我介紹:

我大學學習的是電氣工程與自動化,偶然機會接觸了IT。開始成為了一個測試工程師,16年7月加入特贊任職測試總監,開始幫助公司開發一些關於測試框架和測試工具。

因為平時兼職了運維,領導微服務方面的專家,接觸了微服務,所以慢慢發展成了一個 TestOps 工程師,而且未來我會堅持成為專業的TestOps。

關於特贊:

特贊(tezign.com)是一個利用大資料和智慧匹配技術為企業精確對接設計創意人的科技公司,目前開放平面設計、UIUX設計、插畫設計、動畫視訊設計,積累了來自16個國家、74個城市的10000+位優秀設計師,服務了4000+企業客戶。

特贊重新定義未來企業和創意人才的合作方式,讓天下沒有難做的設計。特贊在2016年4月獲得紅杉資本中國基金領投的數千萬級人民幣A輪融資。

特贊(Tezign)的名字是 科技(Technology)和 設計(Design)的結合,我們將科技和商業帶入設計。Design Matters是特贊發起的一個社會專案,致力於通過會議、研討和工作坊等模式把設計和人文融入科技,吸引了超過40家媒體和累積20萬的觀眾。

關於團隊:

特贊是一個具有創意基因的網際網路技術團隊,來自於人工智慧、人機互動、大資料、SaaS軟體服務化、創意管理、廣告媒體等跨學科背景的成員組成,畢業於哈佛大學、普林斯頓大學、哥倫比亞大學、復旦大學、浙江大學、武漢大學等國內外知名學府和Facebook、阿里巴巴、新浪、盛大、豆瓣、奧美、Isobar等著名公司

下面是我們比較成熟的架構了:

我們服務全部是通過 Docker 啟動的,通過 Node.js 開發了一個服務閘道器(Tezign-service-gateway)也是通過 docker 啟動。

服務通過註冊中心(Zookeeper)註冊,服務閘道器發現服務。

動態路由根據請求連通前後端。Nginx做負載均衡。紅色框內為微服務所需的一些微服務設施。這套架構目前非常穩定,我們還在持續優化中。

還記得開頭前說的那個問題嗎?如何做一個有存在感的測試工程師。首先我認為你自己要感覺到自己存在的價值,別人才能認可你的存在。多聽多看多學習百益無害。

浩瀚宇宙99%的星星不會發光,但是他們一直存在,並且永垂不朽。我堅信存在即合理。所以做最好的自己,你就最好的存在著。

最後,由於文章篇幅問題。工作內容的細節問題,我們可以線上進行交流,如何做好或者發展成為一個 TestOps。感謝大家閱讀這篇冗長的理論文。

原文來自微信公眾號:GitChat技術雜談