Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Developers Summit 2021 summer

Developers Summit 2021 summer

Developers Summit 2021 summerの発表資料です
https://event.shoeisha.jp/devsumi/20210730/session/3228/

masayoshi

July 30, 2021
Tweet

More Decks by masayoshi

Other Decks in Technology

Transcript

  1. 2021.07.30 株式会社はてな Developers Summit 2021 Summer Mackerelチーム リードSRE 古川 雅大

    Mackerel開発チームの リードSREが考える働き方と組織作り
  2. - 名前: 古川 雅大 ( id:masayoshi Twitter: @yoyogidesaiz ) -

    所属: 株式会社はてな - MackerelチームのリードSRE (Site Reliability Engineer) - 趣味 - ネットワーク、サーバーをいじること - 格闘ゲーム 自己紹介
  3. - 対象 - SREをある程度知っている人 - これからSREを組織に導入していく人 - SLOの運用に困っている人 - 構成

    - SREの進め方 - 実例 - チーム変遷 - SLOの決め方 - 感想 - SREsの働き方と面白さ 今日話すこと
  4. - “Class SRE Implements DevOps” - 組織のサイロを減らす - ツール、考え方を共通化、チーム構成 -

    失敗を受け入れる - SLO, エラーバジェットポリシー - 段階的な変更の実装 - カナリアリリース、小さいことから始める - 自動化の活用 - IaC, CI/CD, Toilの撲滅 - 測定する - Observability, SLI, 定量化 SREとは “SRE vs. DevOps: competing standards or close friends?” https://cloud.google.com/blog/products/gcp/sre-vs-devops-competing-standards-or-close-friends
  5. - プロダクトのステークホルダーに全員に理解してもらう必要がある - 例えば、エンジニアではないマネージャーにも理解してもらう必要がある - 専門外の知識を勉強することは大変 - 分厚い専門書を読むハードルは高い - どれから始めるべきかSREsから説明をする必要がある

    - SREの項目はSREsから見ても多岐にわたる - 最初にやることはSREの根幹となるSLO, エラーバジェットからが良い - マネージャーにも理解しやすい SREの最低限の基本を理解してもらう Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy 編, 澤田 武男, 関根 達夫,細川 一茂,矢吹 大輔 監訳、Sky株式会社 玉川 竜司 訳, ”SRE サイトリライア ビリティエンジニアリング ――Googleの信頼性を支えるエンジニアリングチーム ”, オライリー・ジャパン , 2017 分厚い専門書→
  6. - 「開発パフォーマンス」と「信頼性」はトレードオフ - 毎日デプロイして信頼性を100%は幻想 - トレードオフになっている基準を別々に目標にすると.... - Devは「開発パフォーマンスを上げる」だけに注目する - Opsは「信頼性を上げる」だけに注目する

    - => DevOpsがうまくいかなくなる大きな原因の一つ - トレードオフの中で「ユーザーに提供する価値の最大化」を図る - Dev, Ops (+ Biz, Sec) のインセンティブを揃える 開発パフォーマンスと信頼性
  7. - SREを進めていく上で最適なチーム構成は状況によって異なる - SREsの人数 - プロダクトの規模や数 - プロダクトの性質 - 社内でのDevOpsの理解度

    - 現在のチーム構成や運用状況 - 比較も難しい - 成果や変化は年単位でしか測定できない - 他社とも直接比較はできないので、自分たちで考え、見つけていくしかない チーム構成
  8. - プロダクトの数が多い - プロダクトの数 > SREs(10人程度) - 多様なサービス - toC向け自社開発、toB向けSaaS、受託開発など色々

    - レガシーなサービスがある - 例えば「人力検索はてな」は2001年開始のサービス - オンプレ環境あり - 一部のサービスはオンプレ運用(最近のサービスはAWS) - 2017年以前はSREsがいるOpsチームがあり、プロダクトの運用を担当 はてなの例 * microserviceの数ではない *
  9. はてなのチーム構成 ~ 2017 システムプラットフォーム部 はてな ブックマーク チーム Mackerel チーム …

    SREs SREs App App プロダクト Devチーム Ops&プラット フォームチーム SREs SREs 当時はSREという職種ではなかったですが、便宜上 SREsと記載しています PdM PdM
  10. - オンプレ環境の基盤が古く、自動化が不十分でOpsチームしか触れない - なので、Devチームがアラートの設定やインフラ設定が出来ない - アラートをDevチームがあまり見てくれない、対応出来ない - Devチームで設定したアラートではないし、プロダクトを考慮したアラート設定では ない -

    オーナーシップを発揮しにくい - Opsチームはアラートの対応など、Toilが多くオンプレ環境の基盤を改善できな い - 最初に戻る - エラーバジェットポリシーの設定やToilを50%以下に抑えることの重要性 - こういう負のループになると抜け出すのが難しいから - 運用が開発のボトルネックになる はてなのチーム構成 ~ 2017
  11. 社内のチーム構成 2017 ~ 2021 システムプラットフォーム部 SREs SREs プロダクト Devチーム Ops&プラット

    フォームチーム はてな ブックマーク チーム Mackerel チーム … App App PdM PdM SREs SREs
  12. - PdMへのSLOの説明の実施 - トレードオフの理解と、ビジネス上の優先度を考慮した運用を目指す - OpsチームがDevチームの自律的運用をサポート - 徐々にOpsチームからSREsをDevチームに入れていく - 最初はMackerelチームから実施され、1チームずつ増やしていった

    - 1つのDevチームが自律的に運用することで、Opsチームをサポート - Opsチームで基盤改善やクラウド化に取り組む時間を増やす - Opsチームが基盤改善やクラウド化に取り組む - Devチームの運用負荷軽減や、開発パフォーマンスへの寄与 - お互いがサポートすることで利益を得る正のループを作る - インセンティブ設計 社内のチーム構成 2017 ~ 2021
  13. - Devチームの中にSREsを入れる形は文化形成に非常に有効 - 外からではなく、中から変える方が楽 - 自分たちでアラート設定をし、アラートに対応するようになる - スプリント会でSLOを確認するようになる - ロードマップで運用タスクが議論されるようになる

    - 自主的にチーム内でやることが当たり前になっていく(文化) - しかし、デメリットもある - SREsの人数がある程度必要になる - Devチーム内で情報が閉じやすくサイロ化には気をつける必要がある 社内のチーム構成 2017 ~ 2021
  14. - Ops&プラットフォームチームを分けたい - プロダクトのOpsを担当するプロダクトSREチーム - 基盤開発と開発した基盤運用をするプラットフォームチーム - Devチームの中にSREsを入れる形 + 横断組織の2層構造

    - Devチームの運用成熟度やSREsの人数、ビジネス上の優先度で判断 - 他社との比較だとメルカリさんと似たような構成になりそう - 細かいところは当然違うが、全体としては似ている 社内のチーム構成 2021 ~ * https://engineering.mercari.com/blog/entry/2020-07-16-083548/ *
  15. - 簡易的なものでよいので、まずは仮運用で初めてみるのが良い - SLOの見直しは定期的に実施することになる - 測定した値の推移などを確認するため、数ヶ月単位のデータの蓄積が必要 - 早くデータの蓄積を始めたほうが良い - 難しいSLOやSLIを定義してしまうと実装に時間がかかる

    - SLI実装はウォーターフォールでやる必要は一切ない - チーム内のライフサイクルの中にSLO見直しを組み込む - スプリント会など、ステークホルダーが参加する会で見直す - SLOを見る習慣を作る SLO運用の始め方
  16. - 最初のSLOを決める - 競合サービスやユーザーの満足度を満たせる可用性など明確な理由があるならその数値 - 1ヶ月のエラーバジェットから決める - 一般的なWebサービスなら99 ~99.9%ぐらいで始めるのがよさそう -

    最初のSLIを決める - HTTP Status Codeの5xx errorの割合 - HTTP Response Timeの90%ile, 99%ile - SLOの見直しをする期間と会を決める - 最初は1週間~1ヶ月ぐらいの頻度が良い - PdMとDeveloper, SREが参加する定例会で見直す(例えばスプリント会) - 上記の内容をSLO Docsとしてまとめる - その際には決めた理由を書いておく(例えば根拠なしなど) - 仮運用中はエラーバジェットポリシーでデプロイの禁止などはしなくて良い とりあえず始めるSLO仮運用
  17. - AWS ECS上で動いているブログサービス - SLOを決める - 99.5% - SLIを決める -

    MackerelでALBからStatus Code Countと90%ile,99%ileのResponse Timeを取得 - Mackerelの式監視機能で5xxエラー率を出して可視化 & アラート設定 - チーム内のスプリント会でSREsとDeveloper, PdMでSLOを確認する - SLO違反していたら、開発を止めてまで対応するべき温度感だったか確認する - ここで現状の運用の温度感と大きなズレがないか確認していく - SLIが1,2ヶ月ぐらいでどのような変化をしているか観察する - SLO違反していなくてもどのような傾向なのかを確認することは大事 (例)とりあえず始めるSLO仮運用
  18. - Request Driven - Availability - Latency - Quality -

    Pipeline - Freshness - Correctness - Coverage - Storage - Durability SLIを改善 * https://sre.google/workbook/implementing-slos/#slis-for-different-types-of-services
  19. - 開発パフォーマンス指標 (ソフトウェアデリバリのパフォーマンス) - リードタイム - デプロイ頻度 - 平均修復時間 -

    変更失敗率 - SLO(信頼性) - エラーバジェット - 障害許容時間 - 障害原因の割合 - 変更起因障害の割合 開発パフォーマンスと信頼性の関係 それぞれの指標から変更起因の(予想or許容)障害時間を出す
  20. - 変更起因障害予想時間 = デプロイ頻度 x 変更失敗率 x 平均修復時間 - デプロイ頻度

    - 30日で20回デプロイ(営業日には毎日デプロイ) - 変更失敗率 - 5%なら20回に1回デプロイ後に障害が発生する - 平均修復時間 - 30分なら1回の障害で30分の障害時間になる 開発パフォーマンス指標から予想時間 このチームのパフォーマンスだと30日で30分程度障害になると考えられる
  21. - 変更起因障害許容時間 = (1-SLO) x ウィンドウサイズ x 変更起因障害の割合 - エラーバジェット

    - エラーバジェット = 1 - SLO - SLOが99.9%なら、0.1% - ウィンドウサイズ(計測期間) - デプロイ頻度の単位時間と同じにしておく(今回なら30日) - 障害許容時間 = エラーバジェット x ウィンドウサイズ = 43分ぐらい - 変更起因障害の割合 - SRE WorkbookのBinary Push と Configuration Pushが該当 - 例えば、60%なら43分のうち26分程度が変更起因障害許容時間になる SLOから許容時間 このSLOや目標値だと30日で26分程度の変更起因の障害を許容できる
  22. - 変更起因障害予想時間 = デプロイ頻度 x 変更失敗率 x 平均修復時間 - 今回の例だと30min

    - 変更起因障害許容時間 = (1-SLO) x ウィンドウサイズ x 変更起因障害の割合 - 今回の例だと26min - 変更起因障害予想時間(30min) > 変更起因障害許容時間(26min) - よって、このチームパフォーマンスだとSLO違反する可能性がある 開発パフォーマンスと信頼性の関係
  23. - SLO違反しないように予想時間 < 許容時間にするにはどうするか - 当たり前だが、予想時間を減らす or 許容時間を増やすか - 全て掛け算なので、変数を減らせば減る、増やせば増える

    - 予想時間を減らす - デプロイ頻度、変更失敗率、平均修復時間のどれかを減らす - この内、一番減らしやすいのはデプロイ頻度になる - SLO違反したときはデプロイ頻度を減らすことでSLOを復旧する - つまりエラーバジェットポリシーでデプロイを凍結する - 許容時間を増やす - エラーバジェット, 変更障害起因の割合を増やす - (ユーザーの満足度を毀損しない範囲なら)SLOを下げるのが一番楽 - 今回なら99.8%にすれば20回以上デプロイできる 開発パフォーマンスと信頼性の関係
  24. - 開発パフォーマンス指標を計測して、そこからチームの目標を考える - 開発チームでデプロイ頻度の目標値をどれぐらいにするか - その目標値とSLOがかけ離れた値になっていないか関係式で確認する - SLOから開発パフォーマンスはイメージしにくい - デプロイ回数に変換できることで、PdMが目標をイメージしやすい

    - この関係式はあまり細かいことは考慮していないのであくまで参考値程度 - 実際には障害が起こるときはエラーバジェットをまとめて消費することが多い - 簡易的だがモデル化することにより、ソフトウェアで扱ったりシミュレーションなどが可能に なった 開発パフォーマンスと信頼性の関係
  25. - チーム構成について - インセンティブ設計 - 組織論、人のシステム - ネットワーク構成やシステム構成を考えているような面白さがある - Clean

    ArchitectureやDDDを考える面白さのようなものだろうか - SLOの決め方について - 信頼性のモデル化 - 「要はバランス」をソフトウェアで扱えるようにする - モデル化して関連付けたことで、更にDevチームに歩み寄れた気がする - 単純にSLOを議論するより、Devチームの目標と近くなった - 現実の問題をモデル化して、ソフトウェアで扱えるようにすること もソフトウェアエンジニアリングを感じる SREの面白さ
  26. - 「人のシステム」を改善し「機械のシステム」を改善する - 「機械のシステム」を改善し「人のシステム」を改善する - 2つのシステムの信頼性をコントロールしてビジネスに貢献していく - それには - 機械と人を結ぶソフトウェアエンジニアリング

    - 人と人を結ぶコミュニケーション - 機械と機械と結ぶシステムエンジニアリング SREsの働き方 システムが好きならSREに是非挑戦しましょう! * 株式会社はてなはSREsを絶賛募集中です! We are hiring!!!