流利說簡介

流利說?（NYSE：LAIX）是卓越的科技驅動的教育公司，由王翌博士和胡哲人、林暉博士于 2012 年 9 月共同創立。作為智能教育的倡行者，公司擁有一支優秀的人工智能團隊，其自主研發的人工智能英語老師，基于深度學習技術，能夠為每一位用戶提供個性化、自適應的學習課程。創立九年時間，流利說?連續推出了多樣化、覆蓋不同興趣類別和細分人群的產品，包括“流利說?英語”、“流利說?閱讀”等英語教育App以及“流利說?懂你英語?A+”、“流利說?發音”等英語學習產品。截至2021年6月，流利說?旗下產品累計注冊用戶超過2億，用戶覆蓋175個國家和中國384個城市。同時，其搭建的巨型“中國人英語語音數據庫”已累積實現記錄超39億分鐘的對話和537億句錄音。

自動化的驅動力

面對瞬息萬變的市場，業務團隊希望快速響應市場的需求，打造更多有創意的產品。在這背后，要求Cloud Infra團隊提供更敏捷的基礎設施，提升用云的管理水平，主要體現在：

• 加速資源供應：支持業務團隊以自服務的方式快速獲取云資源；

• 降低總體成本：充分利用云的彈性能力，提升資源利用率以降低總體的成本；

• 提升運維和管理效率：提升運維的效率，減少重復性的人工操作。

流利說的自動化實踐

我們的自動化實現不是一蹴而就的，而是逐步構建的過程，這一過程中我們總結出來的原則是：

1）把日常重復性的工作進行自動化，讓大家切身體會到自動化帶來的價值，構建自動化的文化；

2）以價值導向對自動化的優先級進行排序，釋放自動化的業務價值。

我們從以下三個維度進行自動化的探索，可以說隨著自動化的深入，我們的管理成熟度也越來越高：

• 部署自動化

• 管理自動化

• 治理自動化

部署自動化：資源供給的流程化和自動化

云資源的供給是所有工作開始的第一步，也是我們日常工作之一。在沒有自動化之前，所有的操作都在控制臺上完成，看似簡單，但實際應用中會有許多的問題：

• 資源無法統一管理，沒有統一的倉庫去記錄這些資源的歸屬與規格變更等信息，非常容易出現變動帶來的混亂；

• 手工變更誤操作影響線上服務正常運行，并難以回滾。人機交互過多，原來的便捷就變成了容易出錯，最可怕的就是“點錯了”，還忘了原來是什么樣；

• 創建重復資源時，需要重復人工頁面操作，耗時且無法標準化。

因此，我們基于Terraform、Luban（自研管理平臺）、GitLab實現了完全的資源供給自動化，將供應效率從原來的小時級降低到分鐘級，并且將運維支撐效率提升100%。

整體實現的架構如下：

• 通過Luban實現流程的自動化，基于Chatbox提升了效率和體驗；

• 基于GitLab實現對IaC的資源配置庫統一管理；

• 基于Terraform實現在阿里云的資源創建和變更操作。

以下我們將介紹詳細的架構和實現方案。

1）在 Luban 平臺申請資源

我們給研發團隊提供的各種窗口鏈接都放在了一個叫做 Luban 的平臺上，申請人只需要在前端選擇必要的參數，提交申請，對于申請人來說需要做的事情就結束了，接下來就是等待審批結果。例如，我想要申請一個阿里云 ECS 實例，如果直接寫 Terraform，那大概要寫一個如下的文件：

resource "alicloud_instance" "instance" {
  # cn-beijing
  availability_zone = "cn-beijing-b"
  security_groups   = alicloud_security_group.group.*.id

  # series III
  instance_type              = "ecs.n4.large"
  system_disk_category       = "cloud_efficiency"
  system_disk_name           = "test_foo_system_disk_name"
  system_disk_description    = "test_foo_system_disk_description"
  image_id                   = "ubuntu_18_04_64_20G_alibase_20190624.vhd"
  instance_name              = "test_foo"
  vswitch_id                 = alicloud_vswitch.vswitch.id
  internet_max_bandwidth_out = 10
  data_disks {
    name        = "disk2"
    size        = 20
    category    = "cloud_efficiency"
    description = "disk2"
    encrypted   = true
    kms_key_id  = alicloud_kms_key.key.id
  }
}

看起來好像很容易看懂但有的地方又有點疑惑，接著就要去查 alicloud provider documentation 各個參數的意思然后改參數，對于一個沒有寫過 Terraform 的人來說還是比較麻煩的。所以我們做了一個前端申請頁面后，只需要選擇必定的參數，Luban 后端就會按既定的規則在相應目錄下進行代碼生成并觸發 GitOps 流程，對于申請人來說，只需要等審批結果了。

2）運行Terraform Plan檢查

這一步驟是后臺自動執行的，觸發 mobius webhook 進行 terraform plan。mobius 是 Luban 后端非常重要的一個引擎，它能夠集成 GitLab 的 webhook, 處理 merge request 的 create/update/merge/cancel 事件，能夠處理 Terraform 流程的 init/plan/apply, 并輸出日志。

git 提交后，mobius 會自動進行 terraform plan 的 Pipeline。

Tech Leader 通過前端的申請歷史，可以看到對應資源申請的詳細進展，查看 plan 結果是否符合預期，符合單擊 approve 進入下個流程，由基礎設施成員進行復審。

3）提示值班人員進行資源變更審批

在Plan運行成功之后，自動進入到下一環節，Luban Bot模塊提示Infra團隊的值班人員進行資源變更審批。

4）自動化對線上資源進行變更

Infra團隊的值班人員在GitLab審批通過后，觸發mobius webhook 進行 terraform apply 即對線上做出變更，apply 成功后，mobius 自動進行代碼 merge, 至此一個申請流程結束，而申請人也會在內部Chat上收到 Luban Bot發出的資源申請成功的通知。

從以上四個步驟可以看出，資源的供應不僅是完全自動化的，而且非常的嚴謹，再也不需要人員專門去學習寫 Terraform， 重點就放在 review terraform plan 輸出的變化是不是符合預期，并且通過ChatBot的觸發性通知，提升了效率。

管理自動化：彈性伸縮自動化

我們的業務受到用戶在一天內的使用習慣影響，在一天內不同時段呈現明顯的波峰波谷；同時，定期的運營活動、市場促銷活動也會帶來用戶訪問的激增。在業務波峰時增加云資源、在業務波谷期釋放資源，毫無疑問將可以幫助我們降低云上的成本。

如果只是根據業務活動計劃手動調整資源，或者在負載高水位被動進行人工的配置，顯然這對用戶體驗不是最佳的，也并不能動態實時響應降低成本。因此我們將開始著手研究如何實現彈性伸縮的自動化。

經過一段時間的摸索，我們做到了基于規則配置或業務指標監控根據業務的變化自動調節資源數量，實際應用效果來看，在相同的業務負載下，成本節約超過20%。

在技術上，我們從容器層、應用服務器層和數據庫層各層都實現了自動化的彈性伸縮：

• 容器層：使用HPA進行pod伸縮，觸發伸縮的事件有：監控指標、業務指標和定時任務；

• 服務器層：使用彈性伸縮組，基于服務器指標實現ECS的伸縮；

• 數據庫層：使用云原生的數據庫實現彈性，如EMR可定時或者根據cpu/mem指標彈出ECS。

治理自動化：成本管理自動化

對于流利說這樣成長在云上的企業來說，成本管理是我們的關鍵任務。如何有效的管理云上開支、利用技術的手段杜絕資源浪費是我們要解決的首要問題；而成本如何自動化的分攤到各個業務團隊，是我們進行成本管理的基礎。

1）基于標簽進行成本分攤

云上成本分攤其實沒有想象中的那么復雜，云廠商在對應的云資源上面均有對應的 Tags 體系，K8s 的各種資源同樣具有 Labels 體系，兩個標簽體系中其實是可以很好的關聯的；同時阿里云也有賬單相關 API 可調用。

我們自研了Catalog系統，來進行資源與 App 的綁定，同時明確各個 App 的 Owner、Team，并且以此作為公司內部所有資源使用歸屬與統計的唯一數據源。至此我們已經具備了基于 Catalog 源數據管理來進行成本分攤的能力。

當資源有歸屬者轉換，我們只需要修改 Catalog 系統即可，極致輕巧且高效。當然我們也有部分資源因為長久以往的積累，導致多個團隊混用的情況發生。我們依靠大部分可以明確關系的資源均攤成本后，依靠此比例的準確性再來進行無法分攤的資源分攤，并與各個業務線達成共識。

2）自動化的成本分析報告

對于公共支持團隊，比如大數據、基礎設施、業務中臺等資源，我們通過在整體成本已經明確的業務線占比，再將公共支持團隊成本均攤到各個業務線。同時我們也計算了研發環節對于整個成本在各個業務的占比情況，并將所有成本數據做好同比環比。

綜上，基于 Catalog + Tags/Labels 進行明確資源關系，通過絕大部分精準的數據來進行分攤，解決公共資源的分攤難問題，最終每月有一份詳細的自動化的成本分析報告給到各個業務線，同時也有相對簡單的實時監控大盤。

此外，我們還基于 Prometheus 中各種資源的歷史監控數據，統計了計算資源 CPU & Memory 利用率、存儲資源 CPU & Memory & Iops 利用率等，做到了按每周為一個計算周期自動化發送，報表核心模板如下：

我們基于數據說話對低利用率資源進行合理的降配，至今沒有出現任何反彈的情況、也沒有出現任何線上生產事故。

總結

通過自動化的應用，對于我們Cloud Infra團隊來說提高了工作的效率、提升我們的管理水平；同時對于業務也帶來了顯著的好處，包括更快的交付資源、更透明的成本開支。

作者介紹

流利說技術部 Cloud Infra 團隊