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

by スタンバイ

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

、とは

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

最初に導入した

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

運用ルール

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

の定義と監視方法

Slide 26

Slide 26 text

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

アラート対応フロー

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

改善した

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

向上のためにしたこと

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

今後の課題と目指す姿

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

まとめ

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

No content