Developers Summit 2021 summerの発表資料です https://event.shoeisha.jp/devsumi/20210730/session/3228/
2021.07.30株式会社はてなDevelopers Summit 2021 SummerMackerelチーム リードSRE古川 雅大Mackerel開発チームのリードSREが考える働き方と組織作り
View Slide
- 名前: 古川 雅大 ( id:masayoshi Twitter: @yoyogidesaiz )- 所属: 株式会社はてな- MackerelチームのリードSRE (Site Reliability Engineer)- 趣味- ネットワーク、サーバーをいじること- 格闘ゲーム自己紹介
Mackerelとは
クラウド運用を簡単にはじめられるSaaS型サーバー監視サービスMackerelの特徴● システムの運用・監視を簡単にはじめられます● クラウド時代に最適な監視モデルをもとに素早く導入できます● 日本語ドキュメントやサポートによって成長を後押しします4
システムの運用・監視を簡単にはじめられます➔ 導入はガイドにしたがってコマンドを実行するだけ➔ エージェントが死活監視とメトリック取得を自動で開始➔ 直感的なUIでサービスの状況を可視化➔ 監視をはじめる敷居が下がり、チームで取り組めます5
- 対象- SREをある程度知っている人- これからSREを組織に導入していく人- SLOの運用に困っている人- 構成- SREの進め方- 実例- チーム変遷- SLOの決め方- 感想- SREsの働き方と面白さ今日話すこと
- 今回の発表はチーム構成とSLOの実例にフォーカスした発表- もっと全体の考え方やSREとはなにかという話題は以下の発表を参考に- 「SREの文化と組織」- 発表資料- https://speakerdeck.com/masayoshi/sre-culture-organization- 動画- https://www.youtube.com/watch?v=g_oNjQ_G4aw(参考) 今回の発表と一緒にどうぞ
SREの進め方
- “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
- 組織のメンバーにSREの最低限の基本を理解してもらう- 「開発パフォーマンス」と「信頼性」のトレードオフを理解してもらう- SREはOpsチームだけでは達成できないことを理解してもらう- プロダクトに対してSLOを設定、運用してもらう- DevとOpsでSLOという共通の目標値で議論できる- SLOをプロダクトのステークホルダで決められる = 自律したチームになるSREを始めるにはまず、SLOをチームで決められるところを目指す(高度なことはそれからでも良い)
- プロダクトのステークホルダーに全員に理解してもらう必要がある- 例えば、エンジニアではないマネージャーにも理解してもらう必要がある- 専門外の知識を勉強することは大変- 分厚い専門書を読むハードルは高い- どれから始めるべきかSREsから説明をする必要がある- SREの項目はSREsから見ても多岐にわたる- 最初にやることはSREの根幹となるSLO, エラーバジェットからが良い- マネージャーにも理解しやすいSREの最低限の基本を理解してもらうBetsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy 編, 澤田 武男, 関根 達夫,細川 一茂,矢吹 大輔 監訳、Sky株式会社 玉川 竜司 訳, ”SRE サイトリライアビリティエンジニアリング――Googleの信頼性を支えるエンジニアリングチーム”, オライリー・ジャパン, 2017分厚い専門書→
- 「開発パフォーマンス」と「信頼性」はトレードオフ- 毎日デプロイして信頼性を100%は幻想- トレードオフになっている基準を別々に目標にすると....- Devは「開発パフォーマンスを上げる」だけに注目する- Opsは「信頼性を上げる」だけに注目する- => DevOpsがうまくいかなくなる大きな原因の一つ- トレードオフの中で「ユーザーに提供する価値の最大化」を図る- Dev, Ops (+ Biz, Sec) のインセンティブを揃える開発パフォーマンスと信頼性
(参考)社内説明資料
- SLOを使って、「開発パフォーマンス」と「信頼性」のバランスを制御- DevとOpsで矛盾しないインセンティブ設計- プロダクトにあったSLOを選択する- トレードオフを理解していても、いきなり設定、運用することは難しい- SLOを設定、運用するための導入支援が必要- 最終的にはプロダクトマネージャーに決めてもらう- 導入支援の仕方- 支援しやすいチーム構成- SLOの定量的な判断基準の提供SLOを設定、運用してもらう
チーム構成
- SREを進めていく上で最適なチーム構成は状況によって異なる- SREsの人数- プロダクトの規模や数- プロダクトの性質- 社内でのDevOpsの理解度- 現在のチーム構成や運用状況- 比較も難しい- 成果や変化は年単位でしか測定できない- 他社とも直接比較はできないので、自分たちで考え、見つけていくしかないチーム構成
- プロダクトの数が多い- プロダクトの数 > SREs(10人程度)- 多様なサービス- toC向け自社開発、toB向けSaaS、受託開発など色々- レガシーなサービスがある- 例えば「人力検索はてな」は2001年開始のサービス- オンプレ環境あり- 一部のサービスはオンプレ運用(最近のサービスはAWS)- 2017年以前はSREsがいるOpsチームがあり、プロダクトの運用を担当はてなの例* microserviceの数ではない*
はてなのチーム構成 ~ 2017システムプラットフォーム部はてなブックマークチームMackerelチーム…SREs SREsApp AppプロダクトDevチームOps&プラットフォームチーム SREs SREs当時はSREという職種ではなかったですが、便宜上SREsと記載していますPdM PdM
- オンプレ環境の基盤が古く、自動化が不十分でOpsチームしか触れない- なので、Devチームがアラートの設定やインフラ設定が出来ない- アラートをDevチームがあまり見てくれない、対応出来ない- Devチームで設定したアラートではないし、プロダクトを考慮したアラート設定ではない- オーナーシップを発揮しにくい- Opsチームはアラートの対応など、Toilが多くオンプレ環境の基盤を改善できない- 最初に戻る- エラーバジェットポリシーの設定やToilを50%以下に抑えることの重要性- こういう負のループになると抜け出すのが難しいから- 運用が開発のボトルネックになるはてなのチーム構成 ~ 2017
- 負のループから抜け出すために- Opsチームのエンジニアリングの時間を確保する- Devチームで自律的に運用ができるようにする- 不要なアラートの抑止- クラウド移行や、コンテナ化でエコシステムの活用- SREやCloudNativeに取り組む必要がある- 特にDevチームが自律的に運用ができるようにすることを重視はてなのチーム構成 ~ 2017
社内のチーム構成 2017 ~ 2021システムプラットフォーム部SREs SREsプロダクトDevチームOps&プラットフォームチームはてなブックマークチームMackerelチーム…App AppPdM PdMSREs SREs
- PdMへのSLOの説明の実施- トレードオフの理解と、ビジネス上の優先度を考慮した運用を目指す- OpsチームがDevチームの自律的運用をサポート- 徐々にOpsチームからSREsをDevチームに入れていく- 最初はMackerelチームから実施され、1チームずつ増やしていった- 1つのDevチームが自律的に運用することで、Opsチームをサポート- Opsチームで基盤改善やクラウド化に取り組む時間を増やす- Opsチームが基盤改善やクラウド化に取り組む- Devチームの運用負荷軽減や、開発パフォーマンスへの寄与- お互いがサポートすることで利益を得る正のループを作る- インセンティブ設計社内のチーム構成 2017 ~ 2021
- Devチームが自律的に運用できる箇所が増加- Opsチームがいくつかのレガシー基盤の撤退- EOLのOSやミドルウェアのアップデート- クラウド化やコンテナ化- MackerelはECS(Fargate)で稼働- はてなアンテナはEKSで稼働社内のチーム構成 2017 ~ 2021
- 「MackerelにおけるEC2からFargate移行の軌跡とFargateのメリットデメリットについて」- 発表資料- https://speakerdeck.com/masayoshi/2021-06-cloud-native-reg-event- 動画とセミナーBlog- https://aws.amazon.com/jp/blogs/news/managed-service-day-2021-1/(参考)Mackerelチームのコンテナ化
- Devチームの中にSREsを入れる形は文化形成に非常に有効- 外からではなく、中から変える方が楽- 自分たちでアラート設定をし、アラートに対応するようになる- スプリント会でSLOを確認するようになる- ロードマップで運用タスクが議論されるようになる- 自主的にチーム内でやることが当たり前になっていく(文化)- しかし、デメリットもある- SREsの人数がある程度必要になる- Devチーム内で情報が閉じやすくサイロ化には気をつける必要がある社内のチーム構成 2017 ~ 2021
- Ops&プラットフォームチームを分けたい- プロダクトのOpsを担当するプロダクトSREチーム- 基盤開発と開発した基盤運用をするプラットフォームチーム- Devチームの中にSREsを入れる形 + 横断組織の2層構造- Devチームの運用成熟度やSREsの人数、ビジネス上の優先度で判断- 他社との比較だとメルカリさんと似たような構成になりそう- 細かいところは当然違うが、全体としては似ている社内のチーム構成 2021 ~* https://engineering.mercari.com/blog/entry/2020-07-16-083548/*
SLOの決め方
- 簡易的なものでよいので、まずは仮運用で初めてみるのが良い- SLOの見直しは定期的に実施することになる- 測定した値の推移などを確認するため、数ヶ月単位のデータの蓄積が必要- 早くデータの蓄積を始めたほうが良い- 難しいSLOやSLIを定義してしまうと実装に時間がかかる- SLI実装はウォーターフォールでやる必要は一切ない- チーム内のライフサイクルの中にSLO見直しを組み込む- スプリント会など、ステークホルダーが参加する会で見直す- SLOを見る習慣を作るSLO運用の始め方
- 最初の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仮運用
- 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仮運用
- SLIを改善する- SLIをよりサービスの正常性を正確に表現できている指標に変更- SLOの値を調整する- SLOの運用において、重要なところ- 「開発パフォーマンス」と「信頼性」のトレードオフのバランスをどう取るかSLOの改善* https://sre.google/workbook/implementing-slos/#slis-for-different-types-of-services
- Request Driven- Availability- Latency- Quality- Pipeline- Freshness- Correctness- Coverage- Storage- DurabilitySLIを改善* https://sre.google/workbook/implementing-slos/#slis-for-different-types-of-services
(例)MackerelのSLIの一部
- (大前提として)ユーザーの満足度を満たすSLOを定めたとして- 「開発パフォーマンス」と「信頼性」のトレードオフのバランスはどうなっているか?- SLOに関する疑問- 今のチームで99.9%から99.8%のSLOを変更すると、どれだけ開発パフォーマンスが上がるのか?- 定量的に判断、決定する方法はあるの?- エラーバジェットが大量に余るんだが...SLOの調整
- 開発パフォーマンス指標 (ソフトウェアデリバリのパフォーマンス)- リードタイム- デプロイ頻度- 平均修復時間- 変更失敗率- SLO(信頼性)- エラーバジェット- 障害許容時間- 障害原因の割合- 変更起因障害の割合開発パフォーマンスと信頼性の関係それぞれの指標から変更起因の(予想or許容)障害時間を出す
- 変更起因障害予想時間 = デプロイ頻度 x 変更失敗率 x 平均修復時間- デプロイ頻度- 30日で20回デプロイ(営業日には毎日デプロイ)- 変更失敗率- 5%なら20回に1回デプロイ後に障害が発生する- 平均修復時間- 30分なら1回の障害で30分の障害時間になる開発パフォーマンス指標から予想時間このチームのパフォーマンスだと30日で30分程度障害になると考えられる
- 変更起因障害許容時間 = (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分程度の変更起因の障害を許容できる
(参考)SRE Workbookの障害原因の例* https://sre.google/workbook/postmortem-analysis/#top_eight_outage_triggerscomma_2010en_das
図にするとこんな感じ* 我々は「はてなSLOモデル」と呼んでいる
- 変更起因障害予想時間 = デプロイ頻度 x 変更失敗率 x 平均修復時間- 今回の例だと30min- 変更起因障害許容時間 = (1-SLO) x ウィンドウサイズ x 変更起因障害の割合- 今回の例だと26min- 変更起因障害予想時間(30min) > 変更起因障害許容時間(26min)- よって、このチームパフォーマンスだとSLO違反する可能性がある開発パフォーマンスと信頼性の関係
- SLO違反しないように予想時間 < 許容時間にするにはどうするか- 当たり前だが、予想時間を減らす or 許容時間を増やすか- 全て掛け算なので、変数を減らせば減る、増やせば増える- 予想時間を減らす- デプロイ頻度、変更失敗率、平均修復時間のどれかを減らす- この内、一番減らしやすいのはデプロイ頻度になる- SLO違反したときはデプロイ頻度を減らすことでSLOを復旧する- つまりエラーバジェットポリシーでデプロイを凍結する- 許容時間を増やす- エラーバジェット, 変更障害起因の割合を増やす- (ユーザーの満足度を毀損しない範囲なら)SLOを下げるのが一番楽- 今回なら99.8%にすれば20回以上デプロイできる開発パフォーマンスと信頼性の関係
- 今回の例でSLOと許容デプロイ回数だけ変数にすると以下のようになる- 99.9% => 99.8%- 0.1%下げただけだが、エラーバジェットが2倍になっている- つまり、許容されるデプロイ回数も2倍になっている- 変更失敗率1/2や平均修復時間1/2に比べると楽なことが多いSLOと許容デプロイ回数99.8 %あれば毎日デプロイしても大丈夫！
- 開発パフォーマンス指標を計測して、そこからチームの目標を考える- 開発チームでデプロイ頻度の目標値をどれぐらいにするか- その目標値とSLOがかけ離れた値になっていないか関係式で確認する- SLOから開発パフォーマンスはイメージしにくい- デプロイ回数に変換できることで、PdMが目標をイメージしやすい- この関係式はあまり細かいことは考慮していないのであくまで参考値程度- 実際には障害が起こるときはエラーバジェットをまとめて消費することが多い- 簡易的だがモデル化することにより、ソフトウェアで扱ったりシミュレーションなどが可能になった開発パフォーマンスと信頼性の関係
* https://developer.hatenastaff.com/entry/2021/03/04/093000(参考)開発パフォーマンス指標の計測
SREsの面白さと働き方
- チーム構成について- インセンティブ設計- 組織論、人のシステム- ネットワーク構成やシステム構成を考えているような面白さがある- Clean ArchitectureやDDDを考える面白さのようなものだろうか- SLOの決め方について- 信頼性のモデル化- 「要はバランス」をソフトウェアで扱えるようにする- モデル化して関連付けたことで、更にDevチームに歩み寄れた気がする- 単純にSLOを議論するより、Devチームの目標と近くなった- 現実の問題をモデル化して、ソフトウェアで扱えるようにすることもソフトウェアエンジニアリングを感じるSREの面白さ
- 当然インフラ構築、運用、監視の面白さもある- Monitoring, Observability- 障害対応とポストモーテム- 総合すると「システムを扱う面白さ」があるSREの面白さ
- インフラエンジニアからSREsになって扱う「システム」が増えた- 「人のシステム」と「機械のシステム」- Webサービスの信頼性は、2つのシステムを考慮する必要がある- この2つのシステムをうまく組んで信頼性を実現するSREsの働き方運用チーム開発チーム会社組織サーバネットワークアプリケーションWebサービスのシステム機械のシステム人のシステム
- 「人のシステム」を改善し「機械のシステム」を改善する- 「機械のシステム」を改善し「人のシステム」を改善する- 2つのシステムの信頼性をコントロールしてビジネスに貢献していく- それには- 機械と人を結ぶソフトウェアエンジニアリング- 人と人を結ぶコミュニケーション- 機械と機械と結ぶシステムエンジニアリングSREsの働き方システムが好きならSREに是非挑戦しましょう！* 株式会社はてなはSREsを絶賛募集中です！ We are hiring!!!
masayoshi
nozomiito
cembasaranoglu
sosuiiii
tarao
sbtechnight
miyakemito
makamaka
tsubakimoto_s
mizunohiroaki
datarian
xibuka
davidbonilla
eileencodes
moore
philnash
afnizarnur
danielanewman
brad_frost
mza
zenorocha
bkeepers
jrom
chriscoyier