マイクロサービスアーキテクチャな組織_システムにSLOを導入している話.pdf

マイクロサービスアーキテクチャな組織、システムにを導入している話年月日株式会社スタンバイ小林良太郎

自己紹介小林良太郎年月スタンバイ入社まで飲食→
インフラエンジニア好きな技術：パケットの気持ちを考えること苦手な技術：正規表現

本日のゴールという用語理解具体的な導入方法（進め方、技術）を知る考えた方が良いこと
やらない方が良いこと

本日のアジェンダ、とはスタンバイの導入事例
目指す姿まとめ

、とは

とはサービスレベルの指標（）の事サービスレベルの性質に関して定義された指標
例：サーバの正常レスポンスの割合サービスレベルに設定した目標（）の事エンジニア組織のゴールに設定することができる例：サーバの正常レスポンスが

とは年に電気工学の制御理論の中で「」という考えが出てきた
年にという記事でシステムにという言葉が使われた年にのつの柱の重要性が解かれた年につの柱を見直す動きがあり（マイクロサービスでログデータ量が肥大化する問題とか）、活発な議論が今でもされている（今はと呼ぶそうです）とは、システムが提供するデータからシステムの内部状態を理解することができ、そのデータを探索することで、何がなぜ起こったのかという疑問に答えられること。

とは年に電気工学の制御理論の中で「"!%#'」という考えが出てきた年に"!%#'#&##!という記事でシステムに"!%#'という言葉が使われた
年に#!"!のつの柱の重要性が解かれた年につの柱を見直す動きがあり（マイクロサービスでログデータ量が肥大化する問題）、活発な議論が今でもされている "!%#'とは、システムが提供するデータからシステムの内部状態を理解することができ、そのデータを探索することで、何がなぜ起こったのかという疑問に答えられること。 ## " &&&$&#"&"!%#'!

がもたらすもの誰のためにを向上させるのか
の向上は、どういう課題を解決するのかの向上は、どんな利益（）をもたらすのか何をゴールとしてを推進すればいいのか

の成熟度を解説した文書のゴールや成熟させることのメリットなどを書いている

のゴールサステナブルなシステムとエンジニアの幸福観測可能なシステムは運用保守が容易でエンジニアが楽になるエンジニアの幸福度が上がれば離職率も下がり、新規採用コストを下げる事ができるビジネスニーズの充足と顧客の幸福はビジネスを成功させるためのものの高いシステムがあれば顧客に必要なものを理解でき、効率よく安全に提供できるようになる

との関係の導入
サステナブルなシステムとエンジニアの幸福ビジネスニーズの充足と顧客の幸福サービス品質の担保通知が多すぎ問題事例を紹介今後チェックリストを紹介の成熟度

スタンバイとは会社や組織、システムの説明

会社紹介社名：株式会社スタンバイ（）代表：南壮一郎所属人数：名（年月日時点）
沿革：年月、ホールディングス株式会社と株式会社ビズリーチ（現ビジョナル株式会社）との合弁事業会社として設立ミッション：「はたらく」にもっと彩を

サービス紹介求人検索エンジン「スタンバイ」取扱求人数：万件以上
（年月時点）

スタンバイのシステム概要求人を集める求人を提供する広告を配信する広告を管理する
常時台前後のコンテナが稼働全て上にあり、ほとんどが一部をに移行し、他の機能も移行予定化の話はでの発表をご覧ください求人を集める求人を提供する広告を配信する広告を管理する

スタンバイの組織概要各サービスごとにチームが分かれてるインフラも含めて、各チームが独立して運用している
組織方針としても、各チームの自立が求められている求人を集める求人を提供する広告を配信する広告を管理する検索基盤データ管理データ基盤

チームの役割は各チームに共通的な基盤や仕組みを提供するは各サービスに間接的に関わっている
チームのミッションは開発速度・生産性の向上とシステム安定稼働の仕組みづくりチーム運用チーム求人を集める求人を提供する広告を配信する広告を管理するチーム検索基盤データ管理データ基盤

最初に導入した

最初に導入したに関するルール、仕組みはチームが主管して作成運用ルール標準エラーバジェットポリシーの定義と監視方法
アラート対応フロー

運用ルール

運用ルールは開発メンバー全員が責任を持って運用するアラート発生時は、各チームで協力して対応するの作成、修正にはの承認が必要
、エラーバジェットの状態は定期でチームが報告する

標準エラーバジェットポリシー

標準エラーバジェットポリシーエラーバジェットは水曜起算の週間のリクエストを元に計算水曜始まりの週間スプリントなので合わせたエラーバジェットの状態を次スプリントに反映できるエラーバジェットが枯渇した場合は、そのスプリントはリリース禁止
次のスプリントは信頼性回復に努めるようにする致命的なや、セキュリティ関連のリリースはエラーバジェットの大量消費が起きた場合の対応は個別判断ただしポストモーテムは行うこと

の定義と監視方法

数字のをいくら並べてもユーザが
じゃないと意味がないハッピーなユーザを増やすために、を適切に設定する必要がある測定できる結果は時に過大評価されるユーザのために本当に必要なものを見極めて優先度を付けて監視絶対に気にしないとダメなものを定義しましょう

の計測と監視方法各チームと話し合い、を中心としたを作成とはのことで、ユーザが目的を達成するために行う一連のインタラクションのことスタンバイの利用者ごとにを設定
ペルソナが求職者の場合はページではなく、「求職者が検索キーワードを打ち込んで求人一覧を見る」までのレスポンス

の計測と監視方法各チームと話し合い、を中心としたを作成とはのことで、ユーザが目的を達成するために行う一連
のインタラクションのことスタンバイの利用者ごとにを設定ペルソナが求職者の場合はページではなく、「求職者が検索キーワードを打ち込んで求人一覧を見る」までのレスポンス複数チームでつのチームチームチーム

の計測を絞り込み必要があるので、プロキシのログからを計測ログ基盤にはを使っているのでそこから計測
ので頑張るの計測と監視方法例）可用性のがの場合エラー数：以上のステータスコードエラーバジェット：全リクエスト残エラーバジェット：エラーバジェットエラー数可用性レイテンシ

の監視ので監視水曜からのリクエスト数を計算するを作成作成した
に対して通知する条件をとして作成の計測と監視方法頑張って水曜起算する

アラート対応フロー

アラート対応フローアラートが発生した場合は通知を受け取ったチームがに報告各チームのテックリードが集合して対応、原因調査ポストモーテムをコンフルに作成し全員がその
内容を確認

半年運用して出てきた課題

運用ルールは開発メンバー全員が責任を持って運用するアラート発生時は、各チームで協力して対応するオーナーシップを持ちづらく、動く際にお見合い状態になるの作成、修正には
の承認が必要、エラーバジェットの状態は定期で報告する作成と運用のコストが高いもっとカジュアルに「大事なところを監視しよう」くらいの気持ちで初めて欲しい守ることに目がいって、自体を変える方向に行きづらい課題課題

標準エラーバジェットポリシーエラーバジェットは水曜起算の週間のリクエストを元に計算水曜始まりの週間スプリントなので合わせたエラーバジェットの状態を次スプリントに反映できる起算日はエラーバジェットが少ないので、起算日に障害が起きるとあっという間に枯渇
からリリース禁止リリースミスしてすぐに切り戻してもリリース禁止になった時の悲しさ逆に週末はエラーバジェットが溜まってるので多少のエラーは大丈夫というチート課題

標準エラーバジェットポリシーエラーバジェットが枯渇した場合は、そのスプリントはリリース禁止次のスプリントは信頼性回復に努めるようにする致命的なや、セキュリティ関連のリリースは
事業を推進するマネージャー陣にはリリース禁止が痛すぎたリリース禁止が相次ぐと事業計画に支障がでるリリース作業を禁止されると、そのスプリントの計画が崩れるリリース禁止が障害のペナルティになってしまった週間（営業日）のスプリントだとチームを跨いだポストモーテム開催が追いつかないケースが出てきて、再発防止策ができないままリリース禁止課題

の定義と監視方法の監視：その他監視：
通知先、コミュニケーション：ポストモーテム会議：ポストモーテム文書：それぞれ良いツールだが、行ったり来たりが辛い「え？そのやりとりはのどこでやってるの？」とが独立しているので、監視の結果をで調査しづらい課題

アラート対応フローアラートが発生した場合は通知を受け取ったチームがに報告各チームのテックリードが集合して原因調査集合したあとの動きが不明瞭で混乱を招いた
障害の原因になっていないチームは時間のロスになったポストモーテムをコンフルに作成し全員がその内容を確認課題

課題まとめ複数チームでの運用はオーナーシップを持ち辛かった起算日を設けたエラーバジェットの運用に公平性を持たせられなかったリリース禁止がペナルティになってしまって、信頼性向上につながらなかったチームと他チーム間で前提知識量に差が出て、理解と運用にコストが必
要な、複雑な仕組みになってしまった「作ったから頑張って運用してね」の難しさ

改善した

運用ルール起算日を撤廃し、基本的に週間のローリングウィンドウのオーナーはチーム最初に作成したは一旦、フロントエンドチームに持ってもらった
跨るようなは、が見た方がいいと思ってます（個人的見解）各チームにを作ってもらうので、妥当性の判断はがやるの作成：チームメンバーとの承認：プロダクト責任者の妥当性確認：

標準エラーバジェットポリシー違反時にリリースを止めるかは、チームのマネージャーが判断とはいえ、基本的なルールを以下のように策定が内に収まり、エラーバジェットが回復するまではリリースを制限
リリース制限期間中はリリースの優先度を下げ、信頼性回復を最優先タスクとするただし以下の場合はリリースリリース期日を公にしていたり、リリースしないことでユーザに不利益が生じる重大なセキュリティ対応（〜相当）スタンバイの収益に影響を与えるような重大なバグや障害への対応

アラート対応フローインシデントコマンダーを置くただし陣頭指揮する義務は負わない負っている義務は「関係者に連絡して招集」だけあまりに義務を負わせると遠慮や心理的抵抗が生まれて初動が遅れるリスクがある
「なるべく早く、必要な人間が必要なアクションを起こす」ことを最優先し、インシデントコマンダーは初動時の連絡役として動く必要な指示や判断は基本的にテックリードやが行う

定義と監視に統合するにログを送信し、そこでを監視
の機能で、以下を内で一貫して作業できる計測アラート通知インシデント対応用チャンネル作成インシデント対応記録ドキュメント作成ポストモーテム作成

に統合する（管理）複数のモニターをベースにを作成できる通知する閾値や通知先を設定できる

に統合する（アラート通知）通知はこのように来る
ボタンを押すと作成画面が出る

に統合する（インシデント部屋作成）作成されたチャンネルに招待されるこのチャンネルに関係者を招待し、情報拡散を防げるチャンネルの上部に、に作成されたインシデントページへのリンクができる
チャンネル作成者がインシデントコマンダー

に統合する（対応記録作成）のインシデント管理ページで障害対応記録を残せる障害が起きているサービスや対応するチームなどを設定できる
や（とか）へのリンクも貼れる

に統合する（対応記録作成）（復旧）タスクの作成も上で行える
だと流れてしまうので、こちらでタスク管理を作成しても良い障害が復旧したら、をに変更

に統合する（ポストモーテム作成）インシデント管理画面から、「」を押す解決済みのインシデントから作成すると、イン
シデントのメタデータやタイムラインが作成されたポストモーテムを作成することができるの書き込みをできるグラフの挿入も簡単にできる公式ドキュメントインシデント管理

向上のためにしたこと

向上のためにしたこと
に設定することで、ログにのを付与できるエラーが起きたやコンテナイメージを特定できる公式ドキュメント：

向上のためにしたこと公式ドキュメントのようにをゼロにすると、我々の環境（
）では内部の名前解決で使っているが不安定になったをデフォのにすると安定したのをにするとさらに安定した

向上のためにしたこと # 先程の周りの障害調査時に、
!では!でのメトリクスをうまく取れない事象発生 !ではなくにすると問題なく取れるので部のは、アプリケーションは !で動くようにを使い分けた " ! " # ! ! " !

向上のためにしたこと (" 特定の#!を使う"$ !" を作成
#!の指定がない場合は %$の " %!に ! (するようになっている $$!# &%# ("'#%"$#%#$"%# #"$

今後の課題と目指す姿

今後の課題と目指すところ自立と規律に関して各チームにどこまで任せるのか明確に決めてないマイクロサービスな組織で各チームが独立してる中、トップダウンでを導入させるのは自立している組織なのか
自走してのエラー通知状況を可視化。さらに通知から自動でチケットを作成し、スプリントの計画に盛り込んでいるチームもある

今後の課題と目指すところのある生活を現在のリソースを、新機能開発か信頼性回復のどちらに割り振るかのパラメータとして使っているかエラーバジェット通知だけを見る運用になってないか
中身を知らない、誰かが作ったエラーバジェットが尽きたら障害対応する生活と、のエラー率が上がったら障害対応する生活は何が違うのかある程度のエラーを受容する一方で、どの程度のユーザがになるのか

の成熟度を解説した文書のゴールや成熟させることのメリットなどを書いている

の紹介これから紹介するのは、の質が影響するもののリスト（本資料では成熟度が低い場合に出るネガティブな部分のみ抜粋）これは出発点として使い、自らの状況を確かめるために使いましょう改善するに当たって正しい順序や規定された方法はありません

の成熟度が低いと起きる現象システムの回復性オンコールのローテーションに多くの費用を費やしているクリティカルな障害が頻繁に起こるオンコール担当者が偽のアラートを受信し、アラート疲労に悩まされたり、障害から学ぶことができないトラブルシューターが問題を簡単に調査できない問題解決に多くの時間がかかる特定のメンバーが、何度も障害対応に巻き込まれる。

の成熟度が低いと起きる現象コードのデリバリカスタマーサポートにかかるコストが高いエンジニアの時間のうち、新機能の開発よりもバグフィックスに費やされる割合が高い新しいモジュールの導入はリスクが高くなるため、懸念されることが多い問題の発見、再現、修復に長い時間がかかる。開発者は、一度リリースした自分のコードを信用していない

の成熟度が低いと起きる現象複雑性と技術的負債の管理スケーリングの限界や、エッジケースにぶつかったときの再現に、エンジニアの多くの時間が費やされるチームは間違ったものを修正したり、間違った修正方法を選んだりして、気が散ってしまう局所的な変更から制御不能な波及効果が頻繁に発生するコードに変更を加えることを恐れている

の成熟度が低いと起きる現象リリースサイクルリリースの頻度が少なく、多くの人の介在が必要一度にたくさんの変更がリリースされるリリースが温もりのある手作業営業はリリース予定日を意識して約束を取り付けなければならない

の成熟度が低いと起きる現象ユーザの振る舞いを理解プロダクトマネージャーは、次に何を作るべきかについて適切な判断を下すための十分なデータを持っていない開発者は、自分たちの仕事にインパクトがないと感じている製品機能が過大な範囲に拡大したり、サイクルの後半まで顧客からのフィードバックが得られない提供しているサービスが顧客の課題解決につながっておらず、市場に受け入れられていない

完璧な組織などいない。どこが弱いのかチェックし、改善してメリットが大きそうなところを改善ユーザとエンジニアのを阻害するものは何か考えるチェックして分かった弱い箇所の責任者を確認。改善にはお金と時間がかかる

まとめ

まとめにオーナーシップを持つことが重要いきなりではなく、重要なものを監視する習慣から始める導入障壁を下げ、組織の自立性を保ちながら仕組みを浸透させていくツールや環境を見直し、使いやすいように改善していくのが大事
数字のをいくら並べても、ユーザがじゃないと意味はない

メンバー募集しています！人々の「はたらく」をアップデートしていく仲間を募集しています。「株式会社スタンバイエンジニア求人」で検索バックエンドエンジニア検索エンジンエンジニア広告システムエンジニアテックリード候補
サーチクオリティモバイルエンジニアフロントエンドエンジニア機械学習エンジニアデータエンジニアエンジニアエンジニアリングマネージャ

マイクロサービスアーキテクチャな組織_システムにSLOを導入している話.pdf

マイクロサービスアーキテクチャな組織_システムにSLOを導入している話.pdf

More Decks by スタンバイ

Other Decks in Business

Featured

Transcript