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

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

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

スタンバイ

March 11, 2022
Tweet

More Decks by スタンバイ

Other Decks in Business

Transcript

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

  2. 自己紹介  小林良太郎  年月スタンバイ入社  まで飲食→   

    インフラエンジニア  好きな技術:パケットの気持ちを 考えること  苦手な技術:正規表現 
  3. 本日のゴール     という用語理解  具体的な導入方法(進め方、技術)を知る  考えた方が良いこと

     やらない方が良いこと 
  4. 本日のアジェンダ  、    とは  スタンバイの導入事例 

    目指す姿  まとめ 
  5. 、   とは 

  6.  とは    サービスレベルの指標(  )の事  サービスレベルの性質に関して定義された指標

     例:  サーバの正常レスポンスの割合    サービスレベルに設定した目標(  )の事  エンジニア組織のゴールに設定することができる  例:  サーバの正常レスポンスが
  7.    とは   年に電気工学の制御理論の中で「  」という考えが出てきた 

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

      年に#!"!の つの柱の重要性が解かれた   年に つの柱を見直す動きがあり(マイクロサービスでログデータ量が肥大化する問題)、活 発な議論が今でもされている  "!%#'とは、システムが提供するデータからシステムの内部状態を理解することができ、そ のデータを探索することで、何がなぜ起こったのかという疑問に答えられること。 ## " &&&$&#"&"!%#'!   
  9.   がもたらすもの  誰のために    を向上させるのか 

        の向上は、どういう課題を解決するのか      の向上は、どんな利益(  )をもたらすのか  何をゴールとして    を推進すればいいのか 
  10.          

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

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

        サステナブルなシステムと エンジニアの幸福  ビジネスニーズの充足と顧 客の幸福  サービス品質の担保  通知が多すぎ問題 事例を紹介 今後 チェックリスト を紹介     の成熟度
  13.  スタンバイとは 会社や組織、システムの説明

  14. 会社紹介  社名:株式会社スタンバイ(  )  代表:南壮一郎  所属人数: 名(年月日時点)

     沿革: 年月、 ホールディングス株式会社と株式会社ビズリー チ(現ビジョナル株式会社)との合弁事業会社として設立  ミッション:      「はたらく」にもっと彩を 
  15. サービス紹介  求人検索エンジン「スタンバイ」       取扱求人数:万件以上

    (年月時 点) 
  16. スタンバイのシステム概要   求人を集める  求人を提供する  広告を配信する  広告を管理する

     常時台前後のコンテナ が稼働  全て上にあり、ほと んどが    一部を  に移行 し、他の機能も移行予定  化の話は      での発表を ご覧ください 求人を集める 求人を提供する 広告を配信する 広告を管理する
  17. スタンバイの組織概要   各サービスごとにチーム が分かれてる  インフラも含めて、各 チームが独立して運用し ている 

    組織方針としても、各 チームの自立が求められ ている 求人を集める 求人を提供する 広告を配信する 広告を管理する             検索基盤 データ管理 データ基盤
  18. チームの役割   は各チームに共通的 な基盤や仕組みを提供す る  は各サービスに間接 的に関わっている 

    チームのミッション は開発速度・生産性の向 上とシステム安定稼働の 仕組みづくり  チーム運用チーム 求人を集める 求人を提供する 広告を配信する 広告を管理する        チーム    検索基盤 データ管理 データ基盤
  19.  最初に導入した

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

     アラート対応フロー
  21.  運用ルール

  22.  運用ルール  は開発メンバー全員が責任を持って運用する  アラート発生時は、各チームで協力して対応する  の作成、修正には の承認が必要 

    、エラーバジェットの状態は定期 で チームが報告する
  23.  標準エラーバジェットポリシー

  24.  標準エラーバジェットポリシー  エラーバジェットは水曜起算の週間のリクエストを元に計算  水曜始まりの週間スプリントなので合わせた  エラーバジェットの状態を次スプリントに反映できる  エラーバジェットが枯渇した場合は、そのスプリントはリリース禁止

     次のスプリントは信頼性回復に努めるようにする  致命的な  や、セキュリティ関連のリリースは  エラーバジェットの大量消費が起きた場合の対応は個別判断  ただしポストモーテムは行うこと
  25. の定義と監視方法

  26.         

  27.          数字のをいくら並べてもユーザが

    じゃない と意味がない  ハッピーなユーザを増やすために、  を適切に設 定する必要がある  測定できる結果は時に過大評価される  ユーザのために本当に必要なものを見極めて優先度 を付けて監視  絶対に気にしないとダメなものを定義しましょう           
  28. の計測と監視方法  各チームと話し合い、を中心とした を作成  とはのことで、ユーザが目的を達成するために行う一連 のインタラクションのこと  スタンバイの利用者ごとにを設定 

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

    のインタラクションのこと  スタンバイの利用者ごとに を設定  ペルソナが求職者の場合は ページではなく、「求職者が検索キーワードを打ち込ん で求人一覧を見る」までのレスポンス  複数チームでつの          チーム チーム チーム
  30.  の計測  を絞り込み必要があるので、プロキシのログか らを計測  ログ基盤にはを使っているのでそこから計測   

    の  で頑張る の計測と監視方法  例)可用性の が の場合 エラー数: 以上の ステータスコード エラーバジェット:全リクエスト   残エラーバジェット:エラーバジェットエラー数 可用性 レイテンシ
  31.  の監視  の で監視  水曜からのリクエスト数を計算する を作成  作成した

    に対して通知する条件を とし て作成 の計測と監視方法  頑張って水曜起算する   
  32.  アラート対応フロー

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

    内容を確認
  34.  半年運用して出てきた課題

  35.  運用ルール  は開発メンバー全員が責任を持って運用する  アラート発生時は、各チームで協力して対応する  オーナーシップを持ちづらく、動く際にお見合い状態になる  の作成、修正には

    の承認が必要  、エラーバジェットの状態は定期 で報告する  作成と運用のコストが高い  もっとカジュアルに「大事なところを監視しよう」くらいの気持ちで初めて欲しい  守ることに目がいって、自体を変える方向に行きづらい 課題 課題
  36.  標準エラーバジェットポリシー  エラーバジェットは水曜起算の週間のリクエストを元に計算  水曜始まりの週間スプリントなので合わせた  エラーバジェットの状態を次スプリントに反映できる  起算日はエラーバジェットが少ないので、起算日に障害が起きるとあっという間に枯渇

    からリリース禁止  リリースミスしてすぐに切り戻してもリリース禁止になった時の悲しさ  逆に週末はエラーバジェットが溜まってるので多少のエラーは大丈夫というチート 課題
  37.  標準エラーバジェットポリシー  エラーバジェットが枯渇した場合は、そのスプリントはリリース禁止  次のスプリントは信頼性回復に努めるようにする  致命的な  や、セキュリティ関連のリリースは

     事業を推進するマネージャー陣にはリリース禁止が痛すぎた  リリース禁止が相次ぐと事業計画に支障がでる  リリース作業を禁止されると、そのスプリントの計画が崩れる  リリース禁止が障害のペナルティになってしまった  週間(営業日)のスプリントだとチームを跨いだポストモーテム開催が追いつ かないケースが出てきて、再発防止策ができないままリリース禁止 課題
  38.  の定義と監視方法   の監視:   その他監視:  

     通知先、コミュニケーション:    ポストモーテム会議:   ポストモーテム文書:   それぞれ良いツールだが、行ったり来たりが辛い  「え?そのやりとりは  のどこでやってるの?」    と が独立しているので、監視の結果を で調査しづらい 課題
  39.  アラート対応フロー  アラートが発生した場合は通知を受け取った チームがに報告  各チームのテックリードが集合して原因調査  集合したあとの動きが不明瞭で混乱を招いた 

    障害の原因になっていないチームは時間のロ スになった  ポストモーテムをコンフルに作成し全員がその内 容を確認 課題
  40. 課題まとめ  複数チームでの運用はオーナーシップを持ち辛かった  起算日を設けたエラーバジェットの運用に公平性を持たせられなかった  リリース禁止がペナルティになってしまって、信頼性向上につながらなかっ た  チームと他チーム間で前提知識量に差が出て、理解と運用にコストが必

    要な、複雑な仕組みになってしまった  「作ったから頑張って運用してね」の難しさ 
  41. 改善した 

  42.  運用ルール  起算日を撤廃し、基本的に週間のローリングウィンドウ  のオーナーはチーム  最初に作成した は一旦、フロントエンドチームに持ってもらった 

    跨るような は、 が見た方がいいと思ってます(個人的見解)  各チームに を作ってもらうので、妥当性の判断は がやる  の作成:チームメンバーと  の承認:プロダクト責任者  の妥当性確認:
  43.  標準エラーバジェットポリシー  違反時にリリースを止めるかは、チームのマネージャーが判断  とはいえ、基本的なルールを以下のように策定  が 内に収まり、エラーバジェットが回復するまではリリースを制限 

    リリース制限期間中はリリースの優先度を下げ、信頼性回復を最優先タスクとする  ただし以下の場合はリリース   リリース期日を公にしていたり、リリースしないことでユーザに不利益が生じる  重大なセキュリティ対応( 〜相当)  スタンバイの収益に影響を与えるような重大なバグや障害への対応
  44. アラート対応フロー  インシデントコマンダーを置く  ただし陣頭指揮する義務は負わない  負っている義務は「関係者に連絡して招集」だけ  あまりに義務を負わせると遠慮や心理的抵抗が生ま れて初動が遅れるリスクがある

     「なるべく早く、必要な人間が必要なアクションを 起こす」ことを最優先し、インシデントコマンダー は初動時の連絡役として動く  必要な指示や判断は基本的にテックリードやが 行う 
  45. 定義と監視    に統合する    にログを送信し、そこでを監視 

      の機能で、以下を  内で一貫して作業できる  計測  アラート通知  インシデント対応用  チャンネル作成  インシデント対応記録ドキュメント作成  ポストモーテム作成 
  46. に統合する(管理)  複数のモニターをベースに を作成できる  通知する閾値や通知先を設 定できる 

  47. に統合する(アラート通知)    通知はこのように来る     

    ボタンを押す と  作成画面が出る 
  48. に統合する(インシデント部屋作成)  作成されたチャンネルに招待される  このチャンネルに関係者を招待し、情 報拡散を防げる  チャンネルの上部に、に作成 されたインシデントページへのリンク ができる

     チャンネル作成者がインシデントコマ ンダー 
  49. に統合する(対応記録作成)   のインシデント管理ページで 障害対応記録を残せる  障害が起きているサービスや対応する チームなどを設定できる  

     や   (  と か)へのリンクも貼れる 
  50. に統合する(対応記録作成)     (復旧)タスクの作成も  上で行える  

     だと流れてしまうので、こちら でタスク管理を作成しても良い  障害が復旧したら、を に変更 
  51. に統合する(ポストモーテム作成)  インシデント管理画面から、「     」を押す  解決済みのインシデントから作成すると、イン

    シデントのメタデータやタイムラインが作成さ れたポストモーテムを作成することができる    の書き込みを  できる  グラフの挿入も簡単にできる  公式ドキュメント  インシデント管理 
  52.   向上のためにしたこと 

  53.   向上のためにしたこと       

         に設定すること で、ログに    の  を付与できる  エラーが起きたやコンテナイ メージを特定できる  公式ドキュメント:        
  54.   向上のためにしたこと    公式ドキュメントのように  をゼロにすると、我々の環境( 

     )では内部の名前解決で 使っているが不安定になった   をデフォのにすると安 定した  のをにするとさらに安定し た 
  55.   向上のためにしたこと  #   先程の 周りの障害調査時 に、

     !では!で  のメトリクスをうまく取れ ない事象発生  !ではなくにすると問題な く取れるので部の は 、アプリケーションは !で 動くようにを使い分けた  " !  " # !  !     " !
  56.   向上のためにしたこと  ("  特定の#!を使う"$ !" を作成 

    #!の指定がない場合は %$の " %!に ! (するようになっている $$!#  &%# ("'#%"$#%#$"%# #"$  
  57. 今後の課題と目指す姿 

  58.  今後の課題と目指すところ  自立と規律  に関して各チームにどこまで任せるのか明確に決めてない  マイクロサービスな組織で各チームが独立してる中、トップダウ ンでを導入させるのは自立している組織なのか 

    自走して のエラー通知状況を可視化。さらに通知から自 動でチケットを作成し、スプリントの計画に盛り込んでいる チームもある
  59.  今後の課題と目指すところ  のある生活  を現在のリソースを、新機能開発か信頼性回復のどちらに割り振るか のパラメータとして使っているか  エラーバジェット通知だけを見る運用になってないか 

    中身を知らない、誰かが作ったエラーバジェットが尽きたら障害対応する 生活と、のエラー率が上がったら障害対応する生活は何が違うのか  ある程度のエラーを受容する一方で、どの程度のユーザが  になるの か
  60.          

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

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

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

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

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

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

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

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

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

    数字のをいくら並べても、ユーザが じゃないと意味はない        
  70. メンバー募集しています!  人々の「はたらく」をアップデートしていく仲間を募集しています。  「株式会社スタンバイエンジニア求人」で検索  バックエンドエンジニア 検索エンジンエンジニア 広告システムエンジニア テックリード候補

    サーチクオリティ  モバイルエンジニア フロントエンドエンジニア 機械学習エンジニア データエンジニア エンジニア エンジニアリングマネージャ
  71. None