HackMD
  • Prime
    Prime  Full-text search on all paid plans
    Search anywhere and reach everything in a Workspace with Prime plan.
    Got it
      • Create new note
      • Create a note from template
    • Prime  Full-text search on all paid plans
      Prime  Full-text search on all paid plans
      Search anywhere and reach everything in a Workspace with Prime plan.
      Got it
      • Options
      • Versions and GitHub Sync
      • Transfer ownership
      • Delete this note
      • Template
      • Save as template
      • Insert from template
      • Export
      • Dropbox
      • Google Drive
      • Gist
      • Import
      • Dropbox
      • Google Drive
      • Gist
      • Clipboard
      • Download
      • Markdown
      • HTML
      • Raw HTML
      • Sharing Link copied
      • /edit
      • View mode
        • Edit mode
        • View mode
        • Book mode
        • Slide mode
        Edit mode View mode Book mode Slide mode
      • Note Permission
      • Read
        • Owners
        • Signed-in users
        • Everyone
        Owners Signed-in users Everyone
      • Write
        • Owners
        • Signed-in users
        • Everyone
        Owners Signed-in users Everyone
      • More (Comment, Invitee)
      • Publishing
        Everyone on the web can find and read all notes of this public team.
        After the note is published, everyone on the web can find and read this note.
        See all published notes on profile page.
      • Commenting Enable
        Disabled Forbidden Owners Signed-in users Everyone
      • Permission
        • Forbidden
        • Owners
        • Signed-in users
        • Everyone
      • Invitee
      • No invitee
    Menu Sharing Create Help
    Create Create new note Create a note from template
    Menu
    Options
    Versions and GitHub Sync Transfer ownership Delete this note
    Export
    Dropbox Google Drive Gist
    Import
    Dropbox Google Drive Gist Clipboard
    Download
    Markdown HTML Raw HTML
    Back
    Sharing
    Sharing Link copied
    /edit
    View mode
    • Edit mode
    • View mode
    • Book mode
    • Slide mode
    Edit mode View mode Book mode Slide mode
    Note Permission
    Read
    Owners
    • Owners
    • Signed-in users
    • Everyone
    Owners Signed-in users Everyone
    Write
    Owners
    • Owners
    • Signed-in users
    • Everyone
    Owners Signed-in users Everyone
    More (Comment, Invitee)
    Publishing
    Everyone on the web can find and read all notes of this public team.
    After the note is published, everyone on the web can find and read this note.
    See all published notes on profile page.
    More (Comment, Invitee)
    Commenting Enable
    Disabled Forbidden Owners Signed-in users Everyone
    Permission
    Owners
    • Forbidden
    • Owners
    • Signed-in users
    • Everyone
    Invitee
    No invitee
       owned this note    owned this note      
    Published Linked with GitHub
    Like BookmarkBookmarked
    Subscribed
    • Any changes
      Be notified of any changes
    • Mention me
      Be notified of mention me
    • Unsubscribe
    Subscribe
    # 1/11 SRE 讀書會共筆 / 第十六章 ~ 第十八章 --- 場地提供:PIXNET - 誠徵 [SRE 服務可靠度工程師](https://gist.github.com/jnlin/8329bea1c1ed92a1924da7e032304261),有興趣的朋友可聯繫 applyjob@pixnet.tw # 第十六章 - 跟蹤故障 by 曾義格 (正瑋代打) ## 可靠性 - 可靠性的基礎是建立在一個 baseline,並持續的追蹤 - 有持續性的追蹤,可以累積事故的資料,進而有系統性的案例學習以及事後檢討 - 事後檢討通常是針對某一個單一重大事件 - 平日的瑣碎事情也不要放過,避免只抓了大魚,忽略小魚 ## Escalator - 警報閒置沒人處理的話,升級通知更多的人 ## Outalator - 例如 Dashboard ,集中警報事件彙整在一起,在單一工具管理 ## 故障追蹤工具需具備的特性? - 聚合:工具應有能力消除重複警報,以避免重工 - 標籤:資訊的分類,方便下一位人員迅速進入狀況 - 分析:有每日每週每月歷史數據,根據數量層面分析,是否有誤報等等 ; 根據時間軸分析趨勢 ; 容易作縱向或橫向的比較,比如跨團隊/跨服務去比較,可能某團隊的誤報較多 - 報告與公告:寄發 email,有助於後人工作交接、review,看見全貌 ## 意外用途及好處 - 可以把高權限使用者設定為是某種警報,登入時被記錄下來,藉此知道他們的足跡 - 自動化任務的軌跡,例如自動化升級 - 可以手動建立問題與問題的關聯性,把警報與故障建立連結 ## 討論 - jnlin: 大家實際用的追蹤工具是什麼?例如都自己開發或使用開源軟體 - 正瑋: 例如 issue tracking 工具 ? - jnlin: 我們沒有,用比較傳統人工方式在做,用 issue tracking 在做,比較費工,所以好奇有沒有自動化的解決方案 - Rick: 去年有實驗,但作不起來,把 CloudWatch 串 Redmine,一早睡醒就炸了,警報太多(有 event 就自動開 ticket),超過門檻就爆了,數千個。 - 已經根據 Alert 產生 - 與會人 David (灰色上衣):用 CloudWatch 串 Jira ,自動開 ticket,後來就沒有使用了,僅止於概念驗證 - 與會人 (墨綠色上衣):我覺得是 Google 系統龐大到需要長期追蹤各種事件才會這樣作 - 正瑋: 資訊量太大,人無法好好處理 - Rick:應該回到需求面,後面有個團隊需要這東西作些事情才作 - 與會人 (墨綠色上衣):我覺得串得到 Slack 讓手機收得到通知就可滿足需求了 - 與會人 David (灰色上衣):我們之前會做是源自於客戶要求 - jnlin: 有公司會作每週每月的故障分析數量這種東西嗎? - 與會人 (墨綠色上衣):我們公司會有,寄出來給團隊參考,今年發生多少問題,跟其他團隊比較相對高,就會提高注意 # 第十七章 - 測試可靠性 by Arrack - 「如果你沒有測試過某個東西,他一定會掛掉,你一定要假設他會壞掉」 ## 軟體測試類型 - 傳統測試分三種 - Unit Tests (金字塔底層) - Integration Tests - System Tests (金字塔尖端) - 冒煙測試 - 早期製造業在做管道的時候,想知道有無隙縫,就把煙灌進去,如果有隙縫,煙就會冒出來 - 性能測試 - 生產環境測試,也分三種 - 配置測試,我們自己沒經驗 - 壓力測試,例如 Google GKE YAML 檔 - 我們曾經遇到 container 的值比線上的還要大,就會炸掉 - Apache AB - 金絲雀測試 - 隨機抽樣檢查,導流量 - 公式的概念類似比例越高出錯機會就越高 ### 建立測試環境 - SRE 的夢想:專案開始就在,現實通常是到中途才被抓進來 - 用最小力氣得到最大收益:例如優先對購物車寫測試,核心 API 等等 - 把遇到的問題寫成測試案例 - 要建立一套良好的測試基礎建設 - 增加持續建置的系統,每次程式碼異動都做建置 - Jenkins - PHP - 當異常時,負責的工程師應優先處理,否則持續擱置可能衍生更多問題 - 定時建置失去意識:Jenkins 第一天建置失敗會很緊張,沒有當下修好的話,之後幾天就麻痺了 - 緊急發布能力受到嚴重影響 ### 大規模測試 - ~~(場地線路中斷)~~ - 進行容量規劃 - SRE 工具有兩個特點 - 副作用是在良好的測試過的主流 API 範圍內 - 由於現存的驗證和發布流程,這些工具基本不會對用戶造成直接的影響 - 針對危險性高的軟體設立防護等級 ### Testing Disater - 災難恢復工具都設計為離線,主要作這些事情 - 可紀錄狀態 - ... - 修復後應該要 100% 不可重現 - 如果多試幾次就會重現,那問題可能比想像的嚴重,可針對性的升級優先程度和嚴重程度 ### 對速度的渴求 - 針對感興趣的情境設立假設,需要對所有場景同時進行估算 - 工程師比較關心他的程式碼是否有預料之外的 race condition ### 發布到正式環境 - 在 SRE 模性下,測試與生產環境分離,可能導致難以重製生產環境的問題 ### 允許測試失敗 - 早期軟體是每年發布一次,例如 office,每次的修改相當多,上次更新的可靠度數據對下次來說沒有任何意義 - 就 Web 而言,你可以快速的測試,快速的失敗 - 發布之前,對文件的修改要等待發布測試完成 - 提供一種應急機制,可以在尚未測完就發布佈署 ### 整合 - 使用現成語法比如 YAML 降低撰寫配置的時間成本 - 當一個工具出現異常時,要對他有足夠的信心,變成負面循環,沒有任何系統可使用 - 確保某些測試可以冒出問題 - 發現問題的時候僅通知 勿自動修復 ### 正式環境探針 (Probes) - 測試機制是通過提供確定的數據驗己案系統行為是否可以接受 - 可以將錯誤請求類型分類: - 已知的錯誤請求 - 已知的正確請求,可以重製 - 已知的正確請求,不能重製 ### 小結 - 寫測試是投報率高的手段 - 建議推行寫測試的文化,我覺得蠻困難的 ## 討論 - 正瑋: 這章跟你在看的軟體測試是相同的東西,有一段金絲雀測試的公式,有人可以解釋嗎? "CU=RK" - Arrack: RD 要有強制寫測試的觀念是蠻困難的 - 正瑋: 自從接觸測試之後,得到的最大感想是,測試提供安全防護,你可以信任你的程式碼是安全沒有問題。 不管是程式碼本身,還是基礎建設,配置等等,其實許多環節都需要測試。 - 正瑋: 出一個包就補一個測試 - Arrack: 我們公司有作這樣的事,例如寄信有詭異的 bug,就把他寫成測試案例 - 有的 RD 對這種事抱持信仰,一定會去作,有的以時程優先,壞掉就壞掉讓他放在那邊 - Win: 我們開發初期會先進 QE 人工去測,這時期的 bug 就很值得寫測試 - Win: 我們有個專案覆蓋率高達 9x%,可是最近改需求就發現很痛,同時要改架構功能與測試,就變得雙倍甚至三倍時間 - Arrack: 主要是他這個沒辦法變成你的 KPI,因為老闆看不到,可是某個專案沒寫測試,一天到晚出包,可是很快就改好了,他 KPI 就很高 - jnlin: 所以可以用修 bug 的速度當作 API - 與會人 fripig:我們公司目前沒有自動化配置,要除錯就要先配置很久 - 正瑋: 我們對於 VM / container 的使用方式與看法相較於以前,在照顧伺服器比較多當成畜生看待。你是照顧一隻寵物還是一隻牛,牛死了就換一隻。 如果是一個需要精心照顧,上面有許多配置的機器,你要作測試就很累,可是如果是取代性很高的就輕鬆許多。 - 正瑋: 怎麼測得快又測得好是很傷腦的事情 - # 第十八章 - SRE部門中的軟件工程實踐 by Raix ## Google 幕後軟體工程實踐 - 許多不為人知的軟體來自 SRE team - 正式環境是人造最複雜的系統之一 - 有豐富的運維經驗,適合開發內部工具解決問題 - 開發的工具也是一個完整軟工項目 - 制定未來發展方向 ## 為什麼軟工對 SRE 很重要 - 複雜度太高需要自己開發 - SRE 非常適合以及有效 - 需要設計出實現大規模佈署與災難處理,以及容易與基礎建制整合的工具 - SRE 是工具直接使用者,了解開發重點 - 容易獲取直接和高品質的使用者回饋 - 團隊大小不應該與用戶服務規模比例成長 - 以 Google 的使用者數量級,這樣團隊就得擴張到幾百萬人了 ## Auxon 案例分析 ## 傳統的容量規劃方法 - 蒐集未來專案需求的預測 - 根據擁有的數據來計畫明天 - 預測長度一般是幾個季度到幾年 - 制定資源的採購和分配計畫 - 如何最好的滿足未來資源需求? - 需要在哪裡建構多少資源? - 評審並且核准此計畫 - 計畫合理嗎? - 是否符合產品的期望? - 佈署和配置對應的資源 - 哪些服務最終會使用? - 如何把資源合理分配? ## 傳統規劃方法的缺點 - 不可靠 - 出現效率衰退的問題,被逼著開更多機器來滿足業務需求 - 或是用戶需求增加,例如行銷案成功,出現流量高峰,導致資源也隨之增加 - 新的計算叢集或資源限制導致上線推遲 - 產品的決策變化(備份從一份增加到多份),導致資源需求大幅成長 - 事倍功半 - 蒐集足夠的數據以預測未來的需求是很麻煩且容易出錯 - 把帶有限制的資源請求與實際可用資源進行結合也是麻煩的過程 - 使用的工具時常不可靠或是很難用 ## 解決方案:基於意圖的容量規劃 - 列出你的要求,不要拘泥於具體實作細節 - 把服務的依賴和資源的參數用程式設計的方式記錄下來 - 使用演算法自動產生資源的配給方案 - 好處 - 由電腦自動處理可以節省大量人力 - 服務負責人員可以專注在更高級的目標,例如要服務多少萬人用戶,回應時間要在幾秒以內,達到更高的計畫精確度,最後降低成本 - 提供更高... - 意圖是服務負責人對如何維運的一個理性表達 - 1) 我需要 50 個 CPU 資源,必須在集群 X,Y,Z 中,為了服務 Foo 使用 - 具體的資源請求 - 為什麼需要這麼多資源?一定要在指定的集群中嗎? - 2) 我需要 50 個 CPU 資源,必須在地理區域 YYY 任意三個集群中 - 增加自由度了,仍然沒有回答到為什麼要三個集群 - 3) 我想要滿足 Foo 在每個地理區域的需求成長,同時保障 N +2 冗餘 - 有了更多自由度,同時更好理解 - 4) 我們想要把 Foo 以 99.99% 的可靠度運行 - 最大自由度,當容量得不到滿足的後果也最清楚 - Google 最常使用第三個表達方式 ## 表達產品意圖的先決條件 - 依賴關係 - 服務依賴的其他服務和基礎建設會影響位置的決策 - 效能指標 - 服務需要多少計算資源來服務使用者? - 優先級 ## Auxon 架構圖 ## 需求和實現:成功與不足 - Auxon 起源於一位 SRE 與一位技術專案經理 - 任何一個複雜的軟工專案都會遇到一定程度的不確定性 - 不要過於關注完美的解決方案,尤其是問題還不夠清楚的時候 - 應該更快的發布與迭代 - Auxon 一開始先建構簡單的邏輯來處理資源分配,讓團隊更有實際的體感 - 不確定性不意味專案無法推進,可以促使開發更具備通用與模組化的軟體系統 - 經過很多很多次的發布與迭代,逐漸形成一個產品的模樣 - 要確保提供的解決方案有真實的使用案例,在開發的時候才會一直有一個真實可解決的問題,知道可行與否 ## 提升了解程度,推進採用率 - 不要低估人們對產品了解的難度 - 別人跟你推坑使用工具時都會有抗拒感 - 向大型團隊推廣內部軟體工具需要以下幾點: - 持續和完整的推廣方案 - 想辦法得到使用者擁護你 - 拉到資深工程師或是主管的背書協助,有助於接下來的推廣 - 如果解決方案使用起來太困難,SRE 就會自己開發,不要用你的 - 設立期望值,給產品設定一個最小成功條件,或是 MVP - 辨識合適的目標族群使用者 - Google 內部有些團隊已經使用別的解決方案,用得好好的也不會想要採用你這套還在開發中的軟體 - 初期目標是沒有容量規劃流程的團隊 - 早期的成功案例會變成工具的推廣者 - 提供這些用戶協助,想辦法幫助他們更好的使用工具 - 在適合的層次上進行設計:不可知性,你不知道他們會怎麼去使用你的軟體,確保他們不管有什麼類型數據都可以採用 Auxon - 盡量避免落入 100% 採用率的陷阱,一直想著要達成的話你可能要付出非常多成本,不同的客戶需求一發過來就滿足,最後可能兩邊都不滿意 ## 團隊組成 - 最好的團隊是合併通用型人才和領域專家 - 例如與統計分析部門合作 - 通用型人才可以快速開始工作 - 資深領域專家提供知識和經驗 - 多樣化團隊可以避免設計盲點 ## 在團隊培養軟工風氣 - 什麼因素使 Auxon 可以演化為一個長期軟工專案? - 相關領域專家表示興趣 - 技術力很強的用戶群體 - 提供足夠明顯的優勢,可以明確減少 SRE 瑣事,優化既有的基礎建設 - 跟組織發展的目標是一致的 - 哪種專案不適合? - 同時改變太多架構或元件 - 要求全部都有或是全部沒有的上線方式,風險太高 - 目標太大或是太抽象,沒有足夠的實際案例來證明可行性 ## 招募和開發時間 - SRE 通常是通用型人才 - 廣度優先學習方式讓 SRE 對全局知識掌握 - 但缺少產品討論和挖掘需求的經驗 - 結合對使用者需求經驗豐富的 PM - 更好培養一個兼顧開發和實戰經驗的份為 - 確保專注、沒有干擾的開發時間 - 內部的主要軟體專案都是從一個小專案開始,並非一開始就有遠大目標 - 停留在某個工程師的草根項目,在業餘時間開發 - 通過某種正式內部管道成為正式專案 - 從主管層獲得可,擴展成一個完整的軟體開發產品 ## 如何達成這一點 - 建立並且宣揚戰略目標非常重要 - 此軟體持續性的產生加速作用 - 減少同樣任務的執行方式 - 評估組織的能力 - 需要找人來彌補團隊中缺少的角色和技能 - 在 Google 通過內部招募人才是最好的策略 - 不斷發布與迭代 - 別降低標準 - 想辦法抵抗走捷徑的誘惑 - 問自己如果是其他團隊開發的,你會不會想此用 - 可靠度很重要 (五個 9 ?) - 用戶不滿意就不用了,你就沒辦法提升產品的佔有率 ## 結論 - 成功和失敗的產品項目是為了以後的項目鋪路 - SRE 驅動的軟體開發專案對公司建立可持續的維運團隊是很有幫助的 - 不斷開發工具來簡化流程,或者是自動化 - 不需要隨著服務規模呈現線性成長 - SRE 花在軟體開發的經歷最終會對整個公司團隊以及個人得到回報 ## 討論 - 與會人 (jnlin 左手邊): 雲端都有 Quota 需求,在 AWS 會長什麼樣子?GCP 會問你一系列問題,應變流量成長 - Google 真的會問你一系列問題,像是作用是什麼,為什麼要開那麼多 - GCP 會讓你資源慢慢的增加,讓你增進可以使用的資源 - 與會人 "GCP 代表" (墨綠色上衣):分享 capsity planning :實體機年代你可能很在意,但在 VM 年代,so ? 信用卡刷下去就對了 到 container 又更不重要,你可能只是開個 200MB 的 container 出來,丟上去,像 AWS EKS 就可以讓你不用浪費太多錢。老闆問的話可能只想知道每個月大概的數字支出 - 與會人 "GCP 代表" (墨綠色上衣):我們會作 Cost Review,解釋年度成長量是否正常,是否預期。 他們會以為最多的錢花在開機器,其實不是,是花在每天儲存太多 Log (數 GB) -- 把所有 HTTP Request Header 都印出來了, S3 每個月的支出就佔總成本的 30%,這是不合理的事情 - 作 cost review 可以發現 RD 在設計沒有考量的點 ; 前人都承襲前前人開 C4 大絕,但其實 M系列就夠用了。 - john: 我們公司有句話:前人這麼作一定有他的道理,不要自作主張 - john: 容量規劃部分,一方面的壓力來自財務,他們那邊不能很含糊,一定要有個數字,他們每年定期要作財務規劃,要花多少錢等等。 講太多細節又會被砍,變成攻防戰 - Arrack: 習慣是很難改變的,我們在內部登入系統做了一鍵登入,上線後使用比例還是 50%,後來去詢問同事才知道很多人瀏覽器都紀錄了帳號密碼,另類的一鍵登入

    Import from clipboard

    Advanced permission required

    Your current role can only read. Ask the system administrator to acquire write and comment permission.

    This team is disabled

    Sorry, this team is disabled. You can't edit this note.

    This note is locked

    Sorry, only owner can edit this note.

    Reach the limit

    Sorry, you've reached the max length this note can be.
    Please reduce the content or divide it to more notes, thank you!

    Import from Gist

    Import from Snippet

    or

    Export to Snippet

    Are you sure?

    Do you really want to delete this note?
    All users will lost their connection.

    Create a note from template

    Create a note from template

    Oops...
    This template is not available.


    Upgrade

    All
    • All
    • Team
    No template found.

    Create custom template


    Upgrade

    Delete template

    Do you really want to delete this template?

    This page need refresh

    You have an incompatible client version.
    Refresh to update.
    New version available!
    See releases notes here
    Refresh to enjoy new features.
    Your user state has changed.
    Refresh to load new user state.

    Sign in

    Forgot password

    or

    By clicking below, you agree to our terms of service.

    Sign in via Facebook Sign in via Twitter Sign in via GitHub Sign in via Dropbox Sign in via Google

    New to HackMD? Sign up

    Help

    • English
    • 中文
    • Français
    • Deutsch
    • 日本語
    • Español
    • Català
    • Ελληνικά
    • Português
    • italiano
    • Türkçe
    • Русский
    • Nederlands
    • hrvatski jezik
    • język polski
    • Українська
    • हिन्दी
    • svenska
    • Esperanto
    • dansk

    Documents

    Tutorials

    Book Mode Tutorial

    Slide Mode Tutorial

    YAML Metadata

    Contacts

    Facebook

    Twitter

    Feedback

    Send us email

    Resources

    Releases

    Pricing

    Blog

    Policy

    Terms

    Privacy

    Cheatsheet

    Syntax Example Reference
    # Header Header 基本排版
    - Unordered List
    • Unordered List
    1. Ordered List
    1. Ordered List
    - [ ] Todo List
    • Todo List
    > Blockquote
    Blockquote
    **Bold font** Bold font
    *Italics font* Italics font
    ~~Strikethrough~~ Strikethrough
    19^th^ 19th
    H~2~O H2O
    ++Inserted text++ Inserted text
    ==Marked text== Marked text
    [link text](https:// "title") Link
    ![image alt](https:// "title") Image
    `Code` Code 在筆記中貼入程式碼
    ```javascript
    var i = 0;
    ```
    var i = 0;
    :smile: :smile: Emoji list
    {%youtube youtube_id %} Externals
    $L^aT_eX$ LaTeX
    :::info
    This is a alert area.
    :::

    This is a alert area.

    Versions

    Versions and GitHub Sync

    Sign in to link this note to GitHub Learn more
    This note is not linked with GitHub Learn more
     
    Add badge Pull Push GitHub Link Settings
    Upgrade now

    Version named by    

    More Less
    • Edit
    • Delete

    Note content is identical to the latest version.
    Compare with
      Choose a version
      No search result
      Version not found

    Feedback

    Submission failed, please try again

    Thanks for your support.

    On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?

    Please give us some advice and help us improve HackMD.

     

    Thanks for your feedback

    Remove version name

    Do you want to remove this version name and description?

    Transfer ownership

    Transfer to
      Warning: is a public team. If you transfer note to this team, everyone on the web can find and read this note.

        Link with GitHub

        Please authorize HackMD on GitHub

        Please sign in to GitHub and install the HackMD app on your GitHub repo. Learn more

         Sign in to GitHub

        HackMD links with GitHub through a GitHub App. You can choose which repo to install our App.

        Push the note to GitHub Push to GitHub Pull a file from GitHub

          Authorize again
         

        Choose which file to push to

        Select repo
        Refresh Authorize more repos
        Select branch
        Select file
        Select branch
        Choose version(s) to push
        • Save a new version and push
        • Choose from existing versions
        Available push count

        Upgrade

        Pull from GitHub

         
        File from GitHub
        File from HackMD

        GitHub Link Settings

        File linked

        Linked by
        File path
        Last synced branch
        Available push count

        Upgrade

        Danger Zone

        Unlink
        You will no longer receive notification when GitHub file changes after unlink.

        Syncing

        Push failed

        Push successfully