十年前，數據幾乎等同於(yu) 關(guan) 係數據庫。如今，數據則可能呈現出各種形態，包括 NoSQL、時間序列、像 CockRoachDB 和 Spanner 這樣提供全局一致性的 SQL 存儲(chu) ，以及提供聚合日誌文件查詢功能的事件流。隨著數據源不斷增長，數據規模越來越大，種類越來越多，變化速度越來越快，企業(ye) 想要對這些數據做出更實時的響應，上述情況也就應運而生了。對於(yu) 開發人員，每種形式的數據使用方法都存在固有的優(you) 缺點，如何取舍是個(ge) 難題。架構師和開發人員應該密切關(guan) 注各種工具和模型提供的新功能，同時保持勤奮好學，不要完全以對待現有工具的常用方法來使用新工具。我們(men) 必須認識到數據形勢正在發生重大變革，並堅持尋找合適的策略和工具。

開發人員喜歡抽象層，原因很明顯，因為(wei) 他們(men) 可以將複雜問題封裝到抽象層中，從(cong) 而集中精力處理更高層級的問題。在前幾期的技術雷達中，我們(men) 都闡述了這種發展趨勢，很多團隊在同時使用雲(yun) 和容器時都會(hui) 采用這種方法。一開始他們(men) 關(guan) 注的是 Docker 及其生態係統。然後焦點開始轉向 Kubernetes。現在，我們(men) 發現主要活動總體(ti) 上都集中在基礎設施即代碼方麵，尤其是集中在 Terraform 生態係統上。雖然除了 Terraform，我們(men) 還推薦了其他工具，但是它在提供商社區中的采用率仍然讓人印象深刻。本期雷達的內(nei) 容重點包括 Terratest（用於(yu) 測試基礎設施代碼），以及 GoCD 的新提供商（可以使用 Terraform 配置 GoCD）。

Kotlin 作為(wei) 一項開源語言，不僅(jin) 在 androids 環境中獲得了廣泛應用，而且還在向其他環境拓展，也在技術雷達中受到了持續密切的關(guan) 注。由於(yu) 不喜歡現有的語言選擇，JetBrains 在內(nei) 部開發了 Kotlin，並隨後開源。Kotlin 似乎在各種開發人員中廣受歡迎。它經常在各種平台和工具中用作通用甚至專(zhuan) 用開發語言，而且在技術雷達中出現的頻率也越來越高。此外，我們(men) 的項目團隊也在采用該語言（Ktor、MockK、Detekt、HTTP4K）。這個(ge) 新興(xing) 語言在實用性設計和先進工具中獲得了廣泛應用，並且形成了一個(ge) 蓬勃發展的生態係統，取得了巨大的成功，對此我們(men) 深感欣慰。

隨著“一切即代碼”理念的盛行，以前難以改變的絕大多數環節（基礎設施、安全、合規性和運營），幾乎都變得可以通過編程來處理，這就意味著開發人員可以采用更完善的工程實踐。然而，我們(men) 仍然經常看到，要麽(me) 配置子係統異常複雜，要麽(me) 過度依賴於(yu) 可視化編排工具，邏輯滲透到配置文件中，以 YAML 編寫(xie) 的條件語法晦澀複雜，還有各種技術需要使用大量編排框架等情況。隨著多語言編程、基礎設施即代碼和一切皆服務技術的出現，我們(men) 不再需要將各種組件都組合到單一內(nei) 聚的係統中。因此，原本應位於(yu) 係統邊界內(nei) 的邏輯就會(hui) 泄漏到編排工具、配置文件和其他管道中。雖然有時候確有這種必要，但是我們(men) 建議各團隊保持謹慎，考慮將此類代碼放在開發人員執行測試、版本控製、持續集成和其他完善的工程實踐的位置。請避免將業(ye) 務邏輯放在配置文件中（並且避免使用要求將業(ye) 務邏輯放在配置文件中的工具），盡可能減少必須執行的編排操作，不要讓編排功能主導你的係統。

詳盡的 DevOps 現狀報告側(ce) 重於(yu) 對高績效組織的數據驅動型統計分析。這項研究持續多年，結果發表在 Accelerate，證明了組織績效和軟件交付效能之間存在直接關(guan) 聯。研究人員證實，隻需四個(ge) 關(guan) 鍵指標就能區分低績效、中績效和高績效人員：前置時間、部署頻率、平均修複時間 (MTTR) 和變更失敗率。的確，我們(men) 已經發現這四個(ge) 關(guan) 鍵指標（Four key metrics）是個(ge) 簡單卻強大的工具，可幫助領導和團隊專(zhuan) 注於(yu) 衡量並改進重要的環節。實施構建流水線是一個(ge) 良好開端，以便你能夠捕獲四個(ge) 關(guan) 鍵指標，並使軟件交付價(jia) 值流可見。例如，作為(wei) GoCD Analytics 的一等公民，GoCD 流水線能夠衡量這四個(ge) 關(guan) 鍵指標。

機器學習(xi) 的持續交付 (CD4ML) 模型（Continuous delivery for machine learning -CD4ML models），將持續交付實踐應用於(yu) 開發機器學習(xi) 模型上，以便於(yu) 隨時應用在生產(chan) 環境中。該方法解決(jue) 了傳(chuan) 統機器學習(xi) 模型開發的兩(liang) 個(ge) 主要問題：一個(ge) 是訓練模型和將模型部署到生產(chan) 環境之間的周期過長，此過程通常包括將模型手動轉換為(wei) 可上線的代碼；另一個(ge) 問題是使用被過時數據訓練過的產(chan) 品環境模型。

機器學習(xi) 模型的持續交付流水線有兩(liang) 個(ge) 觸發因素：(1) 模型結構的變動；(2) 訓練與(yu) 測試數據集的變動。要使其發揮作用，我們(men) 需要對數據集和模型源代碼進行版本化。流水線通常包括用測試數據集來測試模型、按需使用 H2O 等工具來對模型作自動轉換、以及將模型部署到生產(chan) 環境以交付價(jia) 值。

作為(wei) ThoughtWorks 的開發人員，我們(men) 對於(yu) 工作中可能涉及到的道德問題十分敏感。隨著社會(hui) 對科技的依賴程度日益增長，軟件開發團隊在製定決(jue) 策時必須考慮道德問題。目前已經出現的一些工具，可以幫助我們(men) 思考自己所構建的軟件會(hui) 在未來產(chan) 生什麽(me) 影響。此類工具包括技術塔羅牌和道德風險手冊(ce) （Ethical OS），這兩(liang) 類工具都獲得了廣泛好評。道德風險手冊(ce) 為(wei) 我們(men) 提供了一個(ge) 思維框架和一係列工具，可以促進我們(men) 圍繞軟件構建方麵存在的道德問題展開討論。該手冊(ce) 由 Institute of the Future（未來研究所）和科技與(yu) 社會(hui) 解決(jue) 方案實驗室（Tech and Society Solutions Lab）聯合編製。其中探討了一係列切實的風險，例如網癮、多巴胺經濟，而且還分析了很多值得探討的場景。

我們(men) 在使用分布式賬本技術 (DLTs) 方麵積累的經驗越多，遇到的當前智能合約（Smart contracts ）未完善之處就越多。從(cong) 理論上來看，在賬本上自動添加不可否認、不可逆的合約是個(ge) 好主意。但如果在你考慮如何使用現代化軟件交付技術來開發它們(men) ，以及出現實施方式之間的差異時，問題就出現了。不可變數據是一回事，但不可變業(ye) 務邏輯則完全是另外一回事！一定要想清楚是否在智能合約中包含邏輯，這一點真的非常重要。我們(men) 已經發現，不同的實施方式之間存在截然不同的運營特征。例如，即使合約可以演變，不同平台對這種演變的支持程度也不一樣。我們(men) 的建議是，在智能合約中加入業(ye) 務邏輯之前，請認真考慮，並權衡不同平台的利弊。

我們(men) 已親(qin) 眼見證，組織通過使用版本火車（Release train）概念，從(cong) 極低的發布頻率成功轉向更高頻率。版本火車是一種用於(yu) 協調跨多個(ge) 團隊或具有運行時依賴性組件的發布技術。無論所有預期功能是否已準備就緒，所有版本根據一個(ge) 固定且可靠的時間表發布（火車不會(hui) 等你，如果錯過，就隻能等下一趟了）。雖然我們(men) 完全支持關(guan) 於(yu) 定期發布和演示可用軟件的紀律性，但從(cong) 中長期來看，我們(men) 發現該方法存在一些嚴(yan) 重缺陷，因為(wei) 該方法會(hui) 增加有關(guan) 變更排序的臨(lin) 時耦合，而且如果團隊趕著在給定時間範圍內(nei) 完工，質量可能會(hui) 降低。我們(men) 更傾(qing) 向於(yu) 關(guan) 注在必要的架構與(yu) 組織的方法，來支持獨立發布。雖然火車對於(yu) 提升較慢團隊的速度非常有用，但我們(men) 也看到它給快速團隊帶來了上限。所以我們(men) 認為(wei) ，在使用該技術時，應盡量小心謹慎。

以太坊虛擬機 (EVM) 最初是為(wei) 以太坊主網絡設計的。但如今，大多數團隊不再想要從(cong) 頭開始發明區塊鏈；相反，他們(men) 會(hui) 選擇“超越以太坊的 EVM（EVM beyond Ethereum ）”。我們(men) 看到眾(zhong) 多區塊鏈團隊選擇對以太坊進行分支（如 Quorum）或實現 EVM 規範（如 Burrow、Pantheon），並添加他們(men) 自己的設計。這樣做不僅(jin) 是為(wei) 了重用以太坊的設計，還可以利用其生態係統和開發人員社區。對於(yu) 許多開發人員而言，“智能合約”的概念差不多等同於(yu) “以 Solidity 編寫(xie) 智能合約”。雖然以太坊本身具有一些限製，但圍繞 EVM 生態係統的技術正在繁榮發展。

時序數據庫（TSDB）已經問世一段時間了。隨著符合時序模型的使用場景愈發常見，TSDB 日益成為(wei) 主流。InfluxDB 仍然是 TSDB 的理想選擇，主要用於(yu) 監控場景。TICK Stack 就是一款以 InfluxDB 作為(wei) 核心的監控解決(jue) 方案。Influx 2.0 的 alpha 版最近引入了 Flux（一種用於(yu) 查詢和處理時序數據的腳本語言）。雖然 Flux 目前仍處於(yu) 早期階段，且無法斷定能比 InfluxDB 獲得更廣泛的應用，但它承諾會(hui) 比 InfluxQL 更強大且更具表達力，且能將時序分析工作交由數據庫來完成。然而，InfluxDB 隻有企業(ye) 版才能提供集群支持，因此在項目中需要留意這個(ge) 限製。

Istio 正逐漸成為(wei) 將微服務生態係統付諸應用的標準基礎設施。其開箱即用的橫切關(guan) 注點的實現，已經幫助我們(men) 快速實現了微服務。這些橫切關(guan) 注點實現包括：服務發現、服務之間和從(cong) 請求到服務之間的安全性、可觀測性（包括遙測和分布式跟蹤）、滾動發布和彈性。Istio 是我們(men) 一直使用的服務網格技術的主要實現平台。我們(men) 非常享受它的每月發布及無縫升級所帶來的持續改進。我們(men) 使用 Istio 來啟動項目，從(cong) 一開始就能獲得可觀測性（跟蹤和遙測）和服務之間的安全性。我們(men) 正密切關(guan) 注其在網格內(nei) 外各處服務之間身份驗證方麵所做的改進。此外，我們(men) 希望看到 Istio 為(wei) 配置文件建立最佳實踐，從(cong) 而在為(wei) 服務開發人員提供自主權和為(wei) 服務網格運營商提供控製權之間達到平衡。

GraphQL 生態係統和社區正不斷發展。Hot Chocolate 是用於(yu) .NET（包括新的 core 和原先的傳(chuan) 統框架）的 GraphQL 服務器。該平台可用於(yu) 構建和托管 schema，並能用於(yu) 處理針對這些 schema 的查詢。Hot Chocolate 的開發團隊近期增添了 schema 拚接功能，允許從(cong) 單個(ge) 入口點跨多個(ge) schema（從(cong) 不同位置聚合而成）進行查詢。雖然該功能會(hui) 被以多種方式誤用，但還是值得對其進行評估。

無服務器架構的應用，讓 FaaS 編程風格在開發人員之間越來越普及。該架構通過獨立構建和部署的函數，幫助開發人員專(zhuan) 注於(yu) 解決(jue) 核心業(ye) 務問題。這些函數能響應事件、運行業(ye) 務流程、在流程中生成其他事件，完成任務後隨即消失，不再消耗資源。以前，AWS Lambda 或 Microsoft Azure Functions 等專(zhuan) 有無服務器平台已實現這種編程範式。Knative 是基於(yu) Kubernetes 的開源平台，用來運行 FaaS 工作負載。Knative 有幾點突出之處：開源且適用於(yu) 任何供應商；實現了 CNCF 無服務器工作小組白皮書(shu) 中所定義(yi) 的無服務器工作流；通過實現符合 CNCF CloudEvents 規格的事件接口，來確保跨服務的互操作性；尤其重要的是，它能夠解決(jue) 在運維混合 FaaS 與(yu) 長期運行的容器化架構時所遇到的常見挑戰。該平台易與(yu) Istio 和 Kubernetes 集成。例如，通過在不同版本的函數之間切換流量，開發人員可以利用 Istio 實施金絲(si) 雀發布策略。對於(yu) 處在相同 Kubernetes 環境中的長期運行的容器服務和 FaaS 程序，開發人員都可以享受到 Istio 所提供的可觀測能力。我們(men) 預計，Knative 開源事件接口將繼續支持更多底層源和目的事件的集成。

隨著越來越多的團隊擁抱 DesignOps，該領域的實踐和工具也日漸成熟。UI 開發環境專(zhuan) 注於(yu) 用戶體(ti) 驗設計師與(yu) 開發人員之間的協作（UI dev environments），為(wei) UI 組件的快速迭代提供了綜合環境。目前在該領域可用的工具包括：Storybook、React Styleguidist、Compositor 和 MDX。這些工具既可以在組件庫或設計係統的開發過程中單獨使用，也可以將其嵌入到 web 應用程序中使用。通過使用這些工具，許多團隊在開發準備工作中縮短了 UI 反饋周期並改善了 UI 工作的時間。於(yu) 是，使用 UI 開發環境成為(wei) 了我們(men) 合理的默認選擇。

大量的精力仍然被浪費在部署本地開發環境和排查“works on my machine”（在我的機器上可以工作）的問題上。多年來，我們(men) 的團隊已經采用“檢查並實施”的方法，使用腳本化方法來確保本地開發環境的配置始終一致。Batect 是由 ThoughtWorker 開發的一款開源工具，可幫助輕鬆搭建和共享基於(yu) Docker 的構建環境。Batect 作為(wei) 構建係統的入口點腳本，能夠啟動容器來執行完全不依賴於(yu) 本地配置的構建任務。對構建配置和依賴項的更改僅(jin) 通過源碼管理即可共享，無需在本地機器或 CI 代理上進行任何更改或安裝。在該領域的其他工具中，我們(men) 偏向於(yu) 使用 Cage，但我們(men) 也看到 batect 正在以符合我們(men) 團隊需求的方向迅速發展。

Detekt 是一個(ge) 適用於(yu) Kotlin 的靜態代碼分析工具。它能夠發現代碼中的壞味道和複雜性。你可以通過命令行運行它，也可以使用其插件集成一些熱門的開發者工具，例如 Gradle（用於(yu) 在項目構建時執行代碼分析）、SonarQube（用於(yu) 除靜態代碼分析外的代碼覆蓋率統計）和 IntelliJ 等。Detekt 能夠給 Kotlin 應用的構建流水線錦上添花。

在日誌管理領域，Humio 是一款相對較新的工具。該工具完全從(cong) 零開始構建，通過基於(yu) 定製設計的時序數據庫的內(nei) 置查詢語言，在日誌提取和查詢方麵性能非常快。從(cong) 提取、可視化和報警提醒的角度來看，該工具能夠與(yu) 幾乎所有工具相集成。日誌管理領域已被 Splunk 和 ELK Stack 主導，所以，有替代選擇也是一件好事。我們(men) 將持續關(guan) 注 Humio 的發展。

我們(men) 對於(yu) Kubernetes 對行業(ye) 產(chan) 生的影響興(xing) 奮不已，但也擔心隨之而來的運維複雜度。保持 Kubernetes 集群啟動並運行、管理在該集群上部署的軟件包都需要特殊技能和時間。升級、遷移、備份等運維流程經常會(hui) 是一項全職工作。我們(men) 認為(wei) Kubernetes Operator 會(hui) 對降低複雜度起到關(guan) 鍵作用。該框架提供了一套標準機製，為(wei) 在 Kubernetes 集群中運行的軟件包描述了自動化運維流程。雖然 Operator 由 RedHat 發起和推廣，但多個(ge) 社區為(wei) 常用開源軟件包（如 Jaeger、MongoDB 和 Redis）開發的 Operator 已初露頭角。

Apache Beam 是一個(ge) 開源的統一編程模型，用於(yu) 定義(yi) 和執行數據並行處理流水線的批處理與(yu) 流式傳(chuan) 輸。Beam 模型基於(yu) 數據流模型，允許我們(men) 以優(you) 雅的方式表達邏輯，以便在批處理、窗口化批處理或流式傳(chuan) 輸之間輕鬆切換。大數據處理生態係統已經取得了長足發展，這可能會(hui) 導致人們(men) 難以選擇正確的數據處理引擎。允許我們(men) 在不同運行程序之間切換，這是選擇 Beam 的一個(ge) 關(guan) 鍵原因。幾個(ge) 月前，它支持了 Apache Samza，這是除 Apache Spark、Apache Flink 和 Google Cloud Dataflow 之外的又一個(ge) 新的運行程序。不同運行程序具有不同能力，且提供輕便的 API 是一項困難的任務。Beam 將這些運行程序的創新主動應用於(yu) Beam 模型，並與(yu) 社區合作以影響這些運行程序的路線圖，從(cong) 而試圖達到微妙的平衡。Beam 具有包括 Java、Python 和 Golang 多種語言的 SDK。我們(men) 也成功使用了 Scio，它為(wei) Beam 提供了 Scala 包裝器。

與(yu) Cypress 和 TestCafe 一樣，Puppeteer 也是備受我們(men) 團隊推崇的一款 Web UI 測試工具。Puppeteer 能夠對無頭瀏覽器進行細粒度控製，生成時間軸信息，以用於(yu) 性能診斷等。我們(men) 的團隊發現，相較其他基於(yu) WebDriver 的同類工具，Puppeteer 更加穩定、快速和靈活。

Room 是一個(ge) 數據持久化庫，用於(yu) 在 androids 上訪問 SQLite。它支持使用最小限度的樣板代碼進行數據庫訪問，同時通過編譯時 SQL 校驗使數據庫訪問更加穩健。令我們(men) 開發人員感到滿意的是，使用 LiveData 後，Room 能夠與(yu) 可觀察查詢完整集成。Room 是 androids Jetpack 組件之一，旨在簡化 androids 應用開發。

Rust 最近一次在技術雷達中出現是 2015 年，自那以來，我們(men) 看到開發者對 Rust 的興(xing) 趣在逐漸提升。我們(men) 的一些客戶正在使用 Rust 語言，尤其在圍繞基礎設施工具方麵的使用最為(wei) 常見，而在高性能的嵌入式設備中也可以見到 Rust 的身影。不斷完善的生態係統以及語言本身的改進推動了人們(men) 的興(xing) 趣提升。語言的改進方麵，包括了直接的性能增強，也包括了直觀表現力的提高，例如非詞法作用域的更改。大多數重大變化都包含在去年 12 月發布的 Rust 2018 標準中。

fastai 是一個(ge) 開源 Python 庫，能夠簡化對快速且準確的神經網絡的訓練。它基於(yu) PyTorch 構建，已成為(wei) 備受我們(men) 數據科學家歡迎的工具。fastai 可簡化模型訓練中的難點，如預處理、使用少量代碼加載數據。該庫根據深度學習(xi) 最佳實踐構建而成，對計算機視覺、自然語言處理 (NLP) 等提供開箱即用的支持。創始人的動機是為(wei) 深度學習(xi) 創建易於(yu) 使用的庫，使之成為(wei) 一個(ge) 改進版的 Keras。GCP、AWS 和 Azure 很快便接納了 fastai，將其包含在機器學習(xi) 的鏡像中。fastai 的創建者意識到 Python 在速度和安全方麵的限製，已宣布接納 Swift 作為(wei) 深度學習(xi) 的替代語言。我們(men) 將密切關(guan) 注其進展。