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
    # 11/30 SRE 讀書會共筆 --- # 第5章減少瑣事 by Wnlin (Ref: https://goo.gl/o8UBce) - 「唯一不變的事情就是一直在改變」 ## 瑣事的定義 - 可以自動化的事情你偏偏要手動作 - 隨著系統或流量規模成長的時候,而產生的零碎事情,不管是監控或告警 - 沒有持續價值的事情 - 不是很重要的事情,你又花很多時間處理 - PIXNET 案例 - VPN 去哪裡下載? - 同事的機器(筆電)倒入咖啡 - 又有同事不小心把水灑入機器(筆電) - 電腦很貴,防水要做好 ## 為什麼瑣事越少越好? - 軟體工程 (33%) - 撰寫自動化腳本, infra as code - 系統工程 (33%) - 服務的 infra 基礎建設 - - 雜事或文書流程 (33%) - 預期應該要 13% - 我們實際上 53%,其他剩下 23% - 下班後連回來作順便兼 on call - 我們終於用 50% 作研發的事情,但是剩下一半在做瑣事 - SRE 應該專心投入在研發以及維護 ## 利用溝通技巧減少雜事 - 跟主管溝通或是同事的重點 - 講重點就好,節省 SRE 的時間 - [圖片] Ref FB 的 美食什麼見習生 ## Q&A,大家覺得瑣碎的雜事定義是? - 書裡面的定義,手動性,手動執行腳本來作一些事情,定義為瑣事 - Google 認為這樣的事情也應該要減少 - Rick: VIM 例子,往左邊刪除的方法,同事認為用 IDE 的熱鍵更方便 - afu: d ^ 可以從游標處往左邊刪除至行首 - Rick 同事:有人來問你問題,一定得思考,不能直接重複問題,難以被分類在維運或工程工作,認為這是雜事 - 正瑋: 大概像是董事長來問你說:我的手機要如何操作 OOO 這種情境 - 職涯發展停頓,造成士氣低落,一直被打斷,怎麼辦? - 正瑋:可以使用番茄鐘 ; 但是遇到小孩子打斷還是無解 - --- # 第六章 Monitoring System by Tim @ Droi ## 定義 - Monitoring 監控 - 分為 white-box & black-box - white-box 系統內明確噴出來的訊息 - black-box: user 的 behavitor,我知道 user 現在做了麼行為 - Dashboard - 讓大家更明確知道可以看到哪些東西 - Alert - 理論上發生問題或從 Dashboard 看出異常要發出告警 - Root cause - 問題發生根源的原因 - Push - code 有作變更,定義為 Push ## Why monitoring ? - 做長期趨勢的分析 - 透過監控了解系統的狀態 - 例如想要知道目前效能如何,可以設定兩種不同 path 看最後結果,來決定公司的決策 - 如果系統都沒有作監控,出事情也沒人知道,最後難以收拾 - 打造儀表板是蠻重要的事情,出問題有了地方可以去看 - ## Reasonable Expectations - 要做合理的監控 - 當系統複雜時,需要大量的工程人員投入,不是容易的事情 - Google 一個 SRE 團隊大概是 10 ~ 12 人 - 他們希望 SRE 專注在開發層面,希望把重複或瑣碎的事情自動化解決 - 把共同的基礎建設或監控拉出去,不要讓每個團隊都做一樣的事情 - 準則,不希望有專職的人24小時盯著看,這樣很浪費人力 - 建立系統時應該簡單明瞭,不要有 Magic 系統,例如要針對門檻或指標比較智慧的發出告警 - 發生問題時 RD 要能快速地的定位到問題根源 - 希望不要有誤報,盡量保持良好的告警品質 ## Sympyom vs Causes - 什麼東西壞了?是一種 Sympom 現象 - 帶過 ## Black Monitoring vs White - 黑箱就是告訴你出問題了,白箱是有一些指標讓你作監控 ## 四大黃金訊號 - Latency - 正常跟異常要分開,例如 server 拋出 500 是很快速的,沒辦法正確呈現系統狀態 - Traffic - 例如 RPS, IOPS 數據,By Request 去看你想要的型態,蠻具有監控的意義 - Errors - 分為隱性與顯性 - 顯性是 http 回 404 或 500 之類有明確錯誤的情況 - 隱性的是即使回 OK,但裡面其實有 Bug,得透過 E2E 測試才能知道有問題 - 例如頁面少顯示了某個元件 - Saturation (飽和度) - 多久可以到達上限 - 到達上限前的前指標,例如 CPU usage,到 100% 之前服務就會出問題,不能等到 100% 才發告警 - Chooing an Appropriate Resolution - 避免長尾問題,例如想監控 CPU,每分鐘收一次資料,可能有其中幾秒使用率超級高,剩下的 5x 秒用量都不高,最後的結果會被那幾秒影響,不能代表這一分鐘的狀況 - 要考慮系統效能,是要作即時 Real-time 的,還是 Batch - 例如要作 99.99 % ? 你不需要那麼頻繁作監控的話可以把時間拉長,增加服務可用性 - ASAP, no simpler - 讓你的系統可預測而且可靠 - 監控的基本標準 - 不常用或沒用到的監控指標可以定期刪掉 - 訂定監控的原則 - 必須要是緊急的 - 告警出來時應該有對應的行動,不要只是看著他 - 告警的東西應該是需要人力介入的 - 瑣碎的 script 可以解決的事情不見得需要告警 - 同樣的東西不要告警多次 - 一個 symptom 背後可能有多個原因 - 盡量不要對原因作告警,而是對 symptom 作告警 - (例如 500 增加) - Monitoring for the Long Term - 以長遠發展為考量,才是一個好的監控系統 - Big Table 案例 - 內在有個長尾問題會發海量 alert,老闆會常來問 - Google 作法:不讓老闆看到,disable email - Gmail 案例 - 要不要把權宜之計放進去,放的話就沒問題,可是會留下技術債 - 這是一個 tradeoff - 盡量減少告警讓 RD 有時間去改善系統 - 結論 - 清楚簡單 - 專注在 Symptom 而不是 root cause - 不要假警報,一定要建立 Dashboard ,才能有歷史資料回顧 - 公司案例分享:E2E Testing 之前接微信,容易壞掉,老闆會很緊張,後來作 white-box ,接 prometheus 再接 Slack,後來被老闆發現後也加入了 Slack 群組 - Pjack (Trendmicro):E2E 是某種現象,代表使用者的行為,如果是白箱會看比較細,例如磁碟空間夠不夠。 - 一個現象背後可能有多個原因,例如硬碟滿了,或是 Process crash, I/O 太高等等 - 也可能反過來,某台機器 I/O 有問題,但 E2E 沒問題,為什麼?機器可能很多台,那你半夜是不需要起床修的 - 專注在很緊急的 Symptom,再利用 white-box 幫助你判斷找出問題根源 ## 討論,你們配多少人力來處理監控,例如安排一個人24小時監控? - Rick (91APP) 分享:盡量讓人員專注,上班時間互相支援,無法有專人作監控。原則上不固定人員,輪流。週末的操作等等 - 我們沒辦法 white-box,系統太複雜,例如今天 Facebook 驗證出問題,我們也束手無策 - 有事情能解就解,不行的話往後丟,打電話 - SRE 對商務邏輯了解有限,找可以解決的人求助,例如交易系統 - ELB 的 health 數量,如果是 1 我們要立刻處理 - jnlin (PIXNET) 分享:原則一樣,每個元件或產品有負責的 RD 團隊,無法處理就找到對的人 - Rick (91APP) 分享:業務團隊可能會一直問原因,要有人指揮,跟其他部門溝通,避免有誤解 - 熟悉現場狀況的人可以跳出來,不見得要主管指揮 - 例如 Domain Name 跳轉,之類之類的 - 正瑋:慘的是不同同事各自作不同的行動,互斥 - 新人教育訓練有經典案例分析,當下的重大問題,誰處理的,所有紀錄都有 - 某一次在山上外訓,接到告警,只好一起開車回公司 - Earou (91APP) 分享:讀完這章對我的衝擊,一個 Symptom 可能造成另一個。 - 不要貪心監控太多指標 - 要慎選指標,例如我就專看 Latency,其他的就事後分析再拿出來看 - 時間有限,一個服務十個指標都跳起來會造成混亂 - 先把現場狀況排除後事後再分析 - 正緯:大家都有建 Dashbaord 嗎? - 大部分人都有建。 - 會擺一台電視專門顯示嗎? 平常不放,宣傳意味大於實質意味(91 APP) - John: 監控通常不可能都是綠燈,一定有些是黃燈,例如空間不夠。給老闆看的最好只秀綠燈的,黃燈的不要顯示 - 正緯:鬆耦合系統,大家實務上會這樣作嗎?例如有的老牌監控會所有事都做,Google 傾向多個小服務,定義出個接口 - wnlin (PIXNET): 例如我們會監控 E2E 的東西,例如 www.pixnet.net,我們只要監控 80/443 port ,跳起來時深入去看 IRC 拋出什麼錯誤導致不穩定的紅燈 - Tim: 大家越來越多人用 K8S,AWS (不確定有沒有聽錯) 的人說接下來要開源他們的 monitoring solution - wnlin: 資料都被 Google 蒐集了覺得哪裡怪怪的 - jnlin: 用資料去交換便利性 - 正緯:有些法律規定個資不能放在第三方國家 storage - --- # 第七章 Google 的自動化系統的演進 by Levi Chen @ 91 APP ## 此章節的三位作者都是 SRE 主管,不同國家 ## 自動化是一種力量倍增器,但不是萬靈丹 ## 對力量的倍增並不能改變力量用在哪裡的準確性 ## 自動化的價值 - 一致性 - 人類執行數百次相同動作時,無法保證一定是正確的 - 平台性 - - 錯誤集中化 - 容易擴展,設計系統時間可能會很常,但是比教人快 - 我們公司帶一個人至少要三個月才能上手 - - 修復速度更快 - 降低常見故障的修復時間 - 可以把時間花在其他事情上 - 一個問題越晚被發現,代價越高 - 聽過的趨勢案例分享:被使用者回報一個 bug,成本非常高 - 行動速度更快 - 人類不能像機器一樣反應 - 加開機器人工執行會慢很多 - 沒有自動化,系統很難長久運行,尤其google 早已遠遠超過人工可以處理的地步 - 節省時間 - 如何說服你的老闆作自動化 - 這種優勢比較難立刻被計算出來 - 一旦你用自動化風裝任務,任何人都可以執行他 - 以前參加研討會 (2015, 12) 聽到的金句:系統管機器,人管系統。 ## 自動化對 Google SRE 的價值 - 高度一致的基礎建設 - 很多機器都是 G 自己設計的 - 如果 provider 沒 API ,Google 就自幹 - 看得比較遠,能自己設計未來對公司比較有幫助 ## 自動化分類的層次結構 - 很少被測試的自動化系統很脆弱,因為系統不斷在演進。像是故障轉移 (failover) 可能數個月才發生一次 - 自動化演進路徑 - 沒有自動化 - 手動執行 - 外部維護系統特定的自動化系統 - 外部維護的通用自動化系統 - 內部維護的系統特定的自動化 - 資料庫自己作故障移轉 - 不需要作自動化的系統 ## 讓自己脫離工作 - Google 的廣告數據存在 MySQL - SRE 對於維護這樣的系統太簡單,沒挑戰性,所以開始想下一代的開發,把 MySQL 遷移到 K8S 的前身 Borg - 希望帶來以下益處 - 有效利用容器化資源 - 遇到的問題 - 遷移頻率達一週數次,對 relica 是可以的,但是對 master 無法 - 每次轉移都需要花 30 ~ 90 分鐘 - 需要花大量人力處理 - 為了滿足錯誤預算 .... - 成功後,他們在無聊的維運上減少 95% 時間,釋放 60% 資源 ## 使用 Prodtest 檢測不一致的狀況 - 隨著 cluster 數量成長,一些需要手動改設定,除錯浪費太多時間 - 用 Pyhton 設計系統,針對佈署也做了單元測試 - 確保每次佈署的服務都是正確的 - Google 有機制是發現錯誤時,自動修復它 ## 專業化的傾向 - 很多自動化依賴 sshd,Google 認為很不安全,因為每個人都要有 root 才能執行 - 要把 SRE 權限降到最低,透過一個伺服器,透過他來審計,追蹤誰下過了什麼指令 - 跳板機可能很多公司都有,但審計是另一個問題(正瑋) - 你看到的 GKE 其實已經疊了四層,K8S 開發者之前到公司提到的 - 自動化作太好時,OP 很少機會接觸實際情境,如果工具壞掉,就沒能力可以處理 - 但從 Google 經驗看,自動化與自主化已經不是可以避免的選項 ## 自動化允許大規模故障發生 - Google 拆除機器上的硬碟與刪除資料的過程都是自動化 - 某個程式錯誤,很不幸整個資料中心的硬碟都 earse 了 - 但他們有良好的容錯計畫,所以流量自動的避開這個機房,對使用者而言,只有增加一點點延遲,沒有損害 ## 討論與分享 - 有時候連 script 設計者都忘記來龍去脈,只要執行就完成了 - 航空業有注意到機師太依賴自動降落,不太熟悉手動降落了 - 大家寫自動化腳本時,有人寫測試嗎? (正瑋) - arrack: 感覺會變成循環? - playbook (Ansible ?) 的文件有建議最好也要寫測試 - arrack (PIXNET): 自動化的困擾:如果用 Google 雲端服務,會不知道是改版的影響,還是自動化腳本的問題 - 什麼東西應該自動化? 投資報酬率 (正瑋) - jnlin (PIXNET): 會重複用到的,例如每個月甚至每天都會作,自動化就有用。第二種是也許不是常常過,而是一個團隊很多人都會作。自動化可以事情變得比較一致,比較快,不出錯。 - Rick (91APP):symptom 跟自動化要可以對得起來,如果不幸選錯了 ... 如果問題當下很複雜,自動化就 .... ; 沒有 pattern / 症狀模糊時,自動化不是萬靈丹。 - 正瑋: Google 寫這本書的附加價值是順便賣 K8S 跟 GCP - jon:自動化系統變複雜後,其他人學習的曲線會增長,無法 100% 傳授,因為他沒有經歷過當時的時空背景 ; 自動化系統是基於多個工具打造,都是要學習成本的 - Rick: 三千多個 UT Case,跑下去就下班了,結果隔天來上班來看第一個 case 就失敗,停止了 ; 其他系統 300 多個 case,但有一半是假的,會 pass 但沒實質作用 - jnlin: 自動化要針對比較單純的指標,相對來說是問題根源的指標,而不是一種現象,現象背後的原因可能很多,例如 latency 變高去作一些事情,但可能沒辦法收到成效。 例如硬碟空間不夠就自動加大來緩解,就是適合的自動化應用 - Earou (91APP):大家寫自動化程式時會先寫需求嗎?還是說直接先寫程式,別人就越不知道在幹什麼,就會不知道如何測試它,大家如何把它文件記錄下來 - 正瑋:小程式的話會把需求與註解寫在程式碼裡面 我最終的目的是把知識共享,所以會把該補的文件補完。 - Levi:我們會有小的 code review,這樣人員流動比較不會那麼痛,系統流程如何如何,從自動化腳本就知道事情 - jnlin: 有沒有同事很討厭寫文件?各位如何解決這個問題 - Rick: 我們的案例是會寫但是寫出來的文件別人看不懂? - Rick: 我寫 script 的原則是 follow Linux 指令設計哲學,不知道怎麼下就輸入程式名稱,會吐出基本的範例,最小單位的範例一定要可以跑 - Pjack (Trendmicro):我覺得要每個人做到這件事情很難。Python 網站上面看到一個工具,叫 clime, 可以幫助寫出有統一風格且好用的 Script - https://github.com/moskytw/clime - 註解即 Command line 的 help - 功能模組化, 可以一直重覆利用

    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