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