技術文章 » DevOps Coach 週刊 #3

DevOps Coach 週刊 #3

2020-08-11 20:34:08

宕機

  • 上一週新發的宕機事故。
  • 近期全球重大宕機事故的分析總結、事後回顧。

上週新發宕機事故

  • Discord 這個值得注意的是，它涉及到谷歌雲平臺中所謂的 "吵鬧鄰居 "情況。https://discord.statuspage.io/incidents/bnv0wbddzz2x
  • Slack 更新快取基礎架構的坑。從2020年7月23日晚上9:00 PDT到2020年8月1日下午5:17 PDT，客戶在使用各種API端點時可能會出現滯後或故障。我們於7月29日開始調查這一問題，並將這些問題追溯到最近對我們的快取基礎設施進行的一項變更，旨在增加該基礎設施的容量。一個不可預見的副作用導致一小部分API請求需要更長的時間來處理並最終超時。我們在8月1日恢復了這一更改，所有受影響的客戶的問題都得到瞭解決。8月6日, 6:49 AM GMT+8 https://status.slack.com//2020-07/7d32ad54b0703c47
  • **佳能 ** 遭遇勒索軟體攻擊，Maze宣稱對此事負責 來源： https://www.zdnet.com/article/canon-suffers-ransomware-attack-maze-claims-responsibility/
  • Steam 伺服器目前已經癱瘓 https://gamerant.com/steam-servers-down-8-05/
  • Fastly 著名 CDN 伺服器最近又出效能事故了， 影響範圍，Edge Cloud Services (Fastly API, 快速設定應用, TLS 製備) https://status.fastly.com/incidents/d6ljy97shb0p

關於 Quay.io 宕機事故回顧

  • 來源官網： https://www.openshift.com/blog/about-the-quay.io-outage-post-mortem
  • 時間線：5 月 19 日第一次宕機，28 日第二次宕機，這些事故影響了大多數 quay.io 服務的使用者。
  • Red Hat SRE 團隊對本次事件的經驗總結：
    • 關於誰和什麼人在使用你的服務，你永遠都不可能有足夠的參考數據。 由於Quay 「一直是正常工作」，我們從來不需要花太多時間分析我們的流量模式，處理負載的行爲。這創造了一種虛假的安全感，即服務將無限期地擴充套件。
    • 當服務出現故障時，恢復是你的首要任務。 由於Quay在第一次中斷期間不斷出現數據庫死鎖的情況，我們的標準流程並沒有明確的實現服務恢復的預期目標。這就導致我們花了更多的時間進行分析和收集數據，希望找到根本原因，而不是把所有的精力都放在讓客戶恢復執行上。
    • 要瞭解你的每一個服務功能的影響。 App Registry很少被我們的客戶使用，所以它不是我們團隊的主要優先事項。當你的產品中有很少使用的功能時，bug就不會被提交，開發人員也不會再看程式碼。我們很容易認爲這不會給團隊帶來任何負擔–直到它突然成爲重大事件的一部分。

關於 Heroku 事故 #2090 的後續分析

  • 概述：此次事件涉及Heroku的基礎設施提供商（大概是AWS）的DNS故障。這次事故的坑是 DNS。
  • 來源官網：https://status.heroku.com/incidents/2090
  • 重要看點：爲了給DNS查詢提供內部IP地址，我們的服務提供商執行自己的內部DNS服務。這些DNS服務是確保在同一地區執行的基礎設施之間建立最快連線的根本。當這些 DNS 服務不可用時，服務之間無法建立新的內部連線。與應用程式或數據服務的外部連線不會受到影響。在此次事件中，我們在一個地區的基礎設施子集上經歷了這些DNS服務的間歇性故障，包括我們運維的Heroku大部分內部服務的地方。
  • 經驗總結：我們正在審查我們如何應對服務提供商的DNS故障或降級，以確保我們能夠儘快發現並解決任何未來的問題。

LinkedIn 最近的 Hadoop 事故總結：理論 vs. 實戰

  • 概述：LinkedIn的這起事件影響了多個內部客戶，他們對耐用性和延遲的要求各不相同，使得恢復變得複雜。
  • 來源官網：https://engineering.linkedin.com/blog/2020/learnings-from-a-recent-hadoop-incident
  • 學習制度化：一場大型事件結束後，總會有一些心得體會。以下是我們正在跟進的幾條。
    • 爲Hadoop基礎設施建立一個強大和更全面的主機生命週期管理。
    • 建立更好地理解我們在負載下各數據中心的網路行爲，並確保按需修改網路路由的自動化方式。
    • 目前，我們正在Azure上構建下一代基礎設施，包括Hadoop協定棧。就中期而言，我們將有一個額外的叢集，該叢集建立在一個完全不同的技術棧上，這應該會進一步幫助我們實現冗餘。
    • 調查其他架構的可行性，作爲我們Azure遷移的一部分。例如，我們可以將數據攝取一次，然後將相同的數據複製到 D/R Cluster中，並通過數據佈局和查詢規劃優化來吃掉延遲成本。我們正在採用Apache Iceberg作爲我們的表格式。有了Iceberg，我們應該可以更好地對受影響的檔案進行鍼對性的恢復。在我們當前架構的臨時，我們已經建立了幾個工具，讓我們能夠輔助恢復（例如，恢復除損壞數據以外的所有數據，更容易從另一個叢集恢復大檔案等），並圍繞它建立了執行本，以便於存取。
    • 努力審計我們的流程，以確保它們有定義良好的災難恢復協定。
    • 增加我們的災難演練的頻率，此外，還要審查災難演練中流程的表現與他們所述的恢復策略的評分卡。
    • 繼續研究我們的工具，圍繞着理解世系，因爲事實證明它在識別流和數據的依賴性方面非常有用。這也將提供理解生態系統端到端的連線圖的能力–這在災難恢復等大型協調事件中是非常寶貴的。
    • 一些流量所有者在他們的應用工作流本身中增強了彈性。例如，對延遲敏感的應用，產生關鍵業務小時和每日指標的應用，正在應用邏輯本身中進行明確的數據呆滯性與彈性的權衡。
    • 專注於提高我們預測數據恢復的數據可用性SLA的能力，以便在這種性質的事件再次發生時有能力快速發佈。我們的內部數據消費者可以使用這些SLA，並在恢復協定的決策選擇方面做出明智的決定。

GitHub可用性報告 – 2020年7月

  • 概述：相信很多人都經歷了 GitHub 7 月13 日的事故。該事故持續了4 小時 25 分鐘。以下報告包括對涉及Kubernetes pods和DNS服務受損的事件的描述。
  • 來源官網：https://github.blog/2020-08-05-github-availability-report-july-2020/
  • 要點回顧：
    • 事件的起因是我們的生產型 Kubernetes Pods 開始被標記爲不可用。這在我們的叢集中層出不窮，導致容量減少，最終導致我們的服務癱瘓。對Pods的調查顯示，Pod中的一個容器超過了其定義的記憶體限制並被終止。儘管該容器不需要處理生產流量，但Kubernetes的性質要求所有容器都是健康的，Pod才能 纔能被標記爲可用。
    • 一般情況下，當一個Pod執行到這種故障模式時，叢集會在一分鐘左右恢復。在這種情況下，Pod中的容器被設定爲ImagePullPolicy爲Always，它指示Kubernetes每次都要獲取新的容器映象。然而，由於之前完成了一次例行的DNS維護操作，我們的叢集無法成功到達我們的註冊表，導致Pods無法啓動。當爲了緩解而觸發了重新部署時，這個問題的影響就增加了，我們看到這個故障開始在我們的生產叢集中傳播。直到我們使用快取的DNS記錄重新啓動進程，我們才得以成功獲取容器映象，重新部署，並恢復我們的服務。
  • 後續事項：展望未來，我們已經確定了本季度要解決的一些領域。
    • 加強監控，確保Pod重新啓動不會再基於這種相同的模式而失敗
    • 儘量減少我們對映象倉庫的依賴。
    • 在DNS變更期間擴大驗證範圍
    • 重新評估所有現有的Kubernetes部署策略

新聞

專案發佈速遞

  • Nano 5.0 — The popular simple Unix text editor.
  • Julia 1.5 — High performance, dynamically typed language.
  • Mastodon 3.2 — Federated social app.
  • Django 3.1 — Python-based Web application framework.
  • Alacritty 0.5 — Simplicity-focused terminal emulator.
  • Terraform 0.13 General Availability

DevOps 大會/峯會

KubeCon + CloudNativeCon 歐洲 2020

  • 8 月 17 – 20， 免費
  • 報名： https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/

Commit 峯會

  • 8 月 26 ~ 27， GitLab 免費
  • 報名：https://about.gitlab.com/events/commit/

DevOps Fusion

  • 8 月 26 日， 免費
  • 報名：https://swisstestingday.ch/en/

DevOpsCon 倫敦 2020

  • 8 月 31 日 ~ 9 月 3 日，收費
  • 報名： https://devopscon.io/

提交大議資訊發郵件到：[email protected]

文章

麥肯錫：《十種 「反模式」，讓技術轉型脫軌。》

  • 大型組織轉型專案的反模式清單。在選擇技術、技術管理、路線圖等方面都有很好的建議。
  • https://www.mckinsey.com/business-functions/mckinsey-digital/our-insights/ten-antipatterns-that-are-derailing-technology-transformations

AWS：《爲運維視覺化構建儀表 儀錶板》

  • 一篇關於儀表 儀錶盤設計的好文章，有很多道理、提示、技巧和例子。
  • https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/

LearnK8s：《驗證Kubernetes YAML的最佳實踐和策略》

  • 看看對驗證和測試Kubernetes組態檔有用的幾個工具。有用的對比表和每個不同工具的例子。
  • https://learnk8s.io/validating-kubernetes-yaml

推薦 Arrested DevOps 這個網站，它是幫助你實現理解、開發良好實踐、運營你的團隊和組織的播客，以獲得最大的DevOps妙用。

  • 關於Service Mesh和SMI規範的所有事情的討論。
  • https://www.arresteddevops.com/service-mesh/

Dev.to：《使用Conftest、Regula和OPA保護你的Terraform管道安全》

  • 關於使用Conftest和Regula幫助編寫安全的Terraform程式碼和測試作爲CI流程的一部分的貼文。
  • https://dev.to/prince_of_pasta/securing-your-terraform-pipelines-with-conftest-regula-and-opa-4hkh

無罪網：《事件回顧從小白到大師》

  • Under Armour（！）的首席SRE對他們如何進行SRE有很多有趣的事情可以分享。我喜歡他們對事件回顧的方法，即從1:1採訪相關人員開始。保羅-奧斯曼–Under Armour（無罪峯會）。
  • https://www.blameless.com/blog/improving-postmortems-paul-osman

medium.com 《主要的DevOps挑戰以及如何應對這些挑戰？》

  • DevOps通過提供高效的解決方案，幫助加快交付速度，鼓勵團隊之間的共同作業，並促進敏捷環境，推動組織走向更美好的未來。
  • https://medium.com/faun/major-devops-challenges-and-how-to-address-them-3b4d7b6ee50b

工具

  • Open Service Mesh是一個新的輕量級、可延伸的、用於動態微服務環境的服務網狀結構。它提供了開箱即用的可觀察性功能，並使用SMI進行設定。

  • https://openservicemesh.io/

  • https://github.com/openservicemesh/osm

  • Sysbox是一個新的容器執行時，它可以讓你更容易地在容器中執行低階軟體，比如Systemd、Docker和Kubernetes。由於可插拔的執行時功能，你也可以用Docker執行它。

  • https://github.com/nestybox/sysbox

  • 我們開始看到應用框架和開發者工具爲在Kubernetes等平臺上執行提供高階抽象。Tye是一個有趣的.NET工具，它可以簡化在雲原生平臺上執行.NET應用程式。

  • https://github.com/dotnet/tye

  • Turandot允許在Kubernetes中使用TOSCA。TOSCA提供了一種高階服務描述，旨在實現底層基礎設施之間的可移植性和互操作性。

  • https://turandot.puccini.cloud/

  • Copper是一個Kubernetes的組態檔驗證器。它支援使用內建的Javascript DSL編寫定製測試。

  • https://github.com/cloud66-oss/copper