轉載本文需註明出處：微信公衆號EAWorld，違者必究。
作者自白：
伴隨新版本的發佈，我們團隊也對這次迭代做了些回顧，有值得分享的新特性與設計，也有一些需加強的能力，藉此與大家分享。
主題大綱：
一、新特性部分
1、安全提升，更細粒度的流程與權限控制
2、企業級中間件支持，更匹配普元現有客戶需求
3、全新看板，更精益的度量並指導優化
4、UI大升級，提供To C的互聯網體驗
5、監控增強，圍繞應用視角的運行監測
6、流水線與工單結合，向一體化工作臺演進
二、待提升部分
1、自動化測試體系的完善
2、預警能力的建設
3、流水線任務的持續豐富
新特性
DevOps產品，從定位上來看，仍舊保持初衷不變，要建立一條從業務需求到最終線上運營的IT生產線。
之前的版本其實已經形成了從項目管理->組件設計->代碼管理->持續集成->自動部署->度量優化的能力，所以在5.2版本需求範圍定義時，更多的是從流水線豐富、實施模板、API擴展、安全可靠幾個方面着手的，在此分享以下6個特性：
特性一：安全提升，更細粒度的流程與權限控制
DevOps平臺相對特殊的定位（跨部門、跨環境、長週期）使得平臺在安全上需要更加去關注，這個版本從以下三個方面進行了加強。
1、圍繞功能碼的菜單、操作（API）、環境的三類授權
第一個方面：仍舊是從RBAC着手，考慮到DevOps至少是有兩層權限的：
並且在第二層權限中，會隨着項目類型的不同，擁有的菜單集、功能集範圍也不相同。所以需要在兩級都提供面向菜單、功能碼、環境的細粒度權限配置能力，才能保證滿足各類客戶要求。
2. 充分考慮安全隔離、單向通信的部署架構
第二個方面則是部署架構的安全，參考下圖：
比如一般企業，開發測試區和生產區都是完全隔離的，介質共享傳遞更多是拷貝或者堡壘機完成，在DevOps平臺上，要注意的就是如何能在最小開放的情況下，完成上述不同環境的完整流水線。
一般來講我們在客戶那邊是通過部署多套任務引擎來解決這類問題的，devops門戶只與各環境中的任務引擎打交道（相當於拿任務引擎作爲agent入口），而不去和各個環境中的其他任何機器交互。
但到了有些客戶那邊，多部署引擎是允許的，但是必須只是單向通信。考慮到devops一般都會集成不少中間件或開源工具，比如爲了實時看到部署的執行狀態，需要通過回調接口形成與任務引擎的雙向通信，這個就會受到限制，所以又需要其他的部署架構或技術方案來解決，這裏就不一一贅述。
3. 其他安全示意
第三個方面，更多的是一些瑣碎的安全控制（因爲安全這個領域，本來就是瑣碎的，要持續修補的，最明顯的就是殺毒軟件的病毒庫）。所以我們平臺還做了如下的一些事情，像密碼強度、定時備份、審計日誌明細化等：
特性二：企業級中間件支持，更匹配普元現有客戶需求
第二個特性則是後續的每個版本都會做的，針對不同中間件的集成能力，任務化封裝。
畢竟我們主要關注的還是企業市場，企業市場裏不可能完全拋棄傳統的應用服務器、數據庫等。
所以在這個版本里，增加了像ear、數據腳本等CI的能力，同時也補充了weblogic、websphere、oracle存儲過程，以及普元自有產品上的發佈回退等能力。
不僅僅CICD，產品裏還做了傳統中間件本身的安裝部署運維等能力。
特性三：全新看板，更精益的度量並指導優化
第三個特性是重構了原有項目Issue看板的能力，之前我們更多的是純粹的集成，比如集成jira、禪道都完全是API導向，在DevOps產品裏並沒有一套自己的清晰模型，這就使得每次使用標準的變更，都需要對產品進行深度代碼定製，非常不友好。
在這個版本里，我們新抽象了模型，抽象的要點包括：
如何保證看板適應不同客戶、項目的要求？
將不同的幾種項目Issue模型進行抽象，包括看板泳道、issue流轉flow、issue的一些狀態數據集等。
所以上面這張圖無論是泳道、還是具體的story、bug、task的流轉與關聯，都可以通過模板來進行客戶化配置。
看板這塊還解決了需求與後續代碼、介質的信息斷層問題 ：
現在可以通過需求追溯代碼提交歷史，自動統計一個需求所花的代碼行等，並與後續的工件形成關聯，爲度量提供更多原始數據。
特性四：UI大升級，提供To C的互聯網體驗
第四個特性則是UI的升級，這裏要感謝兩位前端同事在短短一個多月，將整個技術棧從NUI（一套基於jquery的UI）徹底升級爲基於Vue.js的全新門戶。
同時前端提供的很好的動態表單能力，使得以後擴展一個流水線上的任務（包括任務對應的表單、控件、驗證、級聯等），只要通過配置就可直接展示。
現在增加一個流水線上的任務，前端要做的就是提交圖片資源、部分表單控件之間的特殊事件聯動處理、再重新打包就足夠了。
特性五：監控增強，圍繞應用視角的運行監測
第五個特性則是發佈後的監控能力，藉助我們的微服務、容器雲等其他平臺，此版本可以看到如下一些監控視圖：
這是針對應用產生日誌的滾屏展示與檢索。
這是對於應用運維的timeline圖，以及每次運維操作的具體執行信息。
還有像上圖這種，與我們其他平臺集成的系統調用拓撲、業務請求鏈路、進程資源信息、長sql語句等。
特性六：流水線與工單結合，向一體化工作臺演進
第六個特性則是一直猶豫要不要做的工單能力，因爲在以前的項目實施中，很多企業客戶是要求與其ITIL進行集成。但是在最近的幾個實施項目裏，大家都希望把devops向真正的一體化工作臺演進，所以在這個版本中提供了獨立的流程任務與工單管理能力。
舉個例子，如上圖，通過設置流水線上某個環境的審批人（支持多人，比如一般生產環境都要有發佈評審與執行審批），最終在執行過程中，會產生相關的工單並通知到干係人，由相關人進行線上審批，觸發流水線的繼續執行。
目前平臺提供的工單包括：項目立項單、代碼merge單、環境部署前審批單、環境部署後確認單、人工任務單（用於更細粒度的一些確認事宜）等，且此模塊可支持快速納入新流程與工單類型。
待提升部分
自動化測試：雖然現在平臺做過了jmeter、以及我們公司的自動化測試產品（UTP）的集成，但是在一些具體細節上打磨的不夠，需要好好考慮測試能力集成的正確模式。
預警能力：平臺現在的度量更多是給出結果統計，並沒有建立完善的指標預警策略，這塊需要形成對應能力（當然，具體指標值是要經過長期運營才能定，我們也只能給出我們公司的參考值）。
流水線任務的持續豐富：每個版本都要持續做的，流水線上任務的豐富，現在雖然各類構建、部署任務都很多了，但是一些細節還不夠，就比如應用數據備份、滾動升級過程的流量切換，這些都是要去補充的。
本文分享的相對簡單，沒有做技術實現的深入，需要了解產品具體能力、功能實現細節的，可通過其他渠道與我們團隊建立長期溝通機制。
精選提問：
問1：看板這塊還是集成JIRA來做麼？
答：現在產品默認帶是Jira，剛纔也提到了，本次把issue和workflow模型都抽取出來了，形成自己的一套，這樣在集成其他的項目管理工具時，就變得相對容易了。在客戶那邊也已經集成過zentao了，其他幾個暫時還沒有。
問2：沒看到 codereview 部分的細節。請問這個系統中，有 codereview 的位置嗎？codereview 對培養工程師編碼能力還是非常必要的。
答：codereview確實是很重要的一環，gerrit我們集成過，但沒有放在產品中，原因是gerrit的主要是人工+自動的評價模式，流程相對固化。但人工其實通過gitlab flow的merge request等手段已經可以解決，自動通過hook我們也提供了，所以就沒有帶在裏面，而且gerrit的權限管理我們在集成時遇到了一些小問題。所以總得來說，codereview我們同gitlab的一些flow模式支持了，但沒有做到gerrit那樣的強流程模式。
問3：任務引擎有什麼作用麼？在網絡隔離的時候，安全性是如何保證的？
答：任務引擎是我們的流程引擎+jenkins，網絡隔離時，通過開唯一交互端口，並且限進出口流向來控制的，在一個客戶那邊還使用過專用跳板機。
問4：請問應用服務監控是如何實現的？:
（1）持續集成耗時監控：持續集成各節點耗時，超過閥值告警
（2）服務耗時監控：監控超過指定時間的接口耗時
（3）任務監控：包括單元測試、持續集成等，包括定時任務是否正常發起，發起是否執行成功，主機資源使用情況等
（4）iimp同步監控：監控和iimp交互的數據
（5）可用性探測：通過可用性探測獲取服務可用性指標，包括可用時長，不可用時長等
答：這些都要一個個談了，不太清楚你的現狀。持續集成耗時是通過jenkins集成+回調來實現的，jenkins有pipeline的超時設置能力；服務耗時監控是通過我們的微服務平臺能力來做的，類Hystrix；任務監控就雜了，主機資源通過zabbix，定時任務目前沒有
可用性探測是發佈時提供健康探測入口，定時探測，可用不可用是基於定時探測數據來計算，沒有那麼精確；網絡監控和數據同步沒有做；接口耗時，histrix就可以，如果是長鏈路，我們目前是通過skywalking的（APM）。