--- title: 皆がSRE的な観点を持ったエンジニアになっていく仕組みとは tags: #sre author: [HireRoo](https://www.docswell.com/user/hireroo) site: [Docswell](https://www.docswell.com/) thumbnail: https://bcdn.docswell.com/page/4JMVG4RNJW.jpg?width=480 description: 新しいサービスの規模やシステムが大きくなるとインシデントも多くなり、インシデント発生から解決までのリードタイムが長い、膨大な工数がかかるという課題感を感じるようになります。そういった課題への対応として、専任のSRE担当をつくりたいと思うものの、人的リソースが足りないために、SRE活動が後回しになっている企業も多いのではないでしょうか？ ハイヤールーでは、各エンジニアがSRE的な観点をもった「マインド」や「開発」を行いやすい「仕組み」を取り入れることで、SRE専任のメンバーなどを置かずに、社内のエンジニアみんなが SRE 的な観点をもって開発を行えるようにしています。 本登壇では、ハイヤールーが具体的にどのようなツールやドキュメントなどを活用し、全エンジニアがSRE的な観点をもったマインドや活動をおこなっていきやすい「仕組み」としているか、ご紹介いたします。 published: December 07, 23 canonical: https://www.docswell.com/s/hireroo/KYW61E-2023-12-07-184959 --- # Page. 1 ![Page Image](https://bcdn.docswell.com/page/4JMVG4RNJW.jpg) 皆がSRE的な観点を持った エンジニアになっていく仕組みとは @icchy_san 1 # Page. 2 ![Page Image](https://bcdn.docswell.com/page/PJR2ZWR4E9.jpg) イントロダクション 自己紹介 伊藤 友一 @icchy_san ● ● ● 株式会社ハイヤールー共同創業者の一人 前職では某エンジニアQ&Aサイトや看護・介護職の方向けのサービス のインフラを触っていました 最近はPlatform周りの業務に携わる事が多いです 2 # Page. 3 ![Page Image](https://bcdn.docswell.com/page/PEXD9PRZ7X.jpg) Agenda 1 スタートアップフェーズのSRE 2 ハイヤールーのSRE活動紹介 3 まとめ # Page. 4 ![Page Image](https://bcdn.docswell.com/page/3EKXPDRV7D.jpg) 01 スタートアップフェーズのSRE # Page. 5 ![Page Image](https://bcdn.docswell.com/page/L735XRGQE5.jpg) スタートアップフェーズのSRE スタートアップでSRE活動が軽視されそうな理由 機能が少ない ユーザーも少ない 問題が顕在化する 可能性も低い 安定性 << 機能開発 5 # Page. 6 ![Page Image](https://bcdn.docswell.com/page/87DD2Y1W7G.jpg) スタートアップフェーズのSRE SRE的活動をしたほうがよいと考えられる理由 スケールしていく企業の場合、 信頼性の担保は必要不可欠 ● ● サービスのパフォーマンスが低い ダウンタイムが長い サービスに対するマイナスの印象がつく。 マイナスの印象はなかなか払拭できない 自社サービスが他社サービスと比較された結果選ばれない 6 # Page. 7 ![Page Image](https://bcdn.docswell.com/page/VJPX16QX78.jpg) スタートアップフェーズのSRE 一般的にSREがやること SREがやることって… ● トイル削減 ● ポストモーテムの実施 ● パフォーマンスチューニング ● SLI/SLOの設定 ● エラーバジェットの設定 ● ︙ 7 # Page. 8 ![Page Image](https://bcdn.docswell.com/page/2EVLY353JQ.jpg) スタートアップフェーズのSRE 一般的にSREがやること SREがやることって… ● トイル削減 ● ポストモーテムの実施 ● パフォーマンスチューニング ● SLI/SLOの設定 ● エラーバジェットの設定 ● ︙ とにかく多い！ 8 # Page. 9 ![Page Image](https://bcdn.docswell.com/page/57GX936YEL.jpg) スタートアップフェーズのSRE New! スタートアップでSRE活動が軽視されそうな理由 全システムの管理を1人で行うと... ● ● ● ? 1人で全サービスを把握 ⇒ 負荷がかかる 各サービスの理解が浅い ⇒ 難しい業務も いずれ限界が来る ⇒ スケールしない スタートアップでは1人運用は厳しい。 フェーズ的に合わない活動内容も存在する。 9 # Page. 10 ![Page Image](https://bcdn.docswell.com/page/4EQ8W546JP.jpg) 02 ハイヤールーのSRE活動紹介 # Page. 11 ![Page Image](https://bcdn.docswell.com/page/KJ42K9QME1.jpg) スタートアップフェーズのSRE 結論 （再掲） SREがやることって… ● トイル削減 ● ポストモーテムの実施 ● パフォーマンスチューニング ● SLI/SLOの設定 ● エラーバジェットの設定 ● ︙ 11 # Page. 12 ![Page Image](https://bcdn.docswell.com/page/LE1MXKPY7G.jpg) スタートアップフェーズのSRE 結論 ハイヤールーのSREがやってること ● トイル削減 ● ポストモーテムの実施 ● パフォーマンスチューニング ● SLI/SLOの設定 ● エラーバジェットの設定 ● ︙ 12 # Page. 13 ![Page Image](https://bcdn.docswell.com/page/GEW3ND21E2.jpg) スタートアップフェーズのSRE ハイヤールーのSRE活動をする上での人員構成 – SREの区分 大まかなSRE区分 Pure SRE いわゆるGoogle SREで サービス横断するSRE Role SRE 各開発チームのメンバーが 開発をメインにしつつ、パフォーマンス チューニングなどを行う Embedded SRE 各開発チームに派遣されるSRE Platform SRE Center of Practiceを実装するSREで 各チームにツールや環境の提供を行う ※他にもあると思うが、説明しやすいように一部抜粋 13 # Page. 14 ![Page Image](https://bcdn.docswell.com/page/47ZV3GDXE3.jpg) スタートアップフェーズのSRE ハイヤールーのSRE活動をする上での人員構成 – SREの区分 ハイヤールーでのSRE区分 Pure SRE いわゆるGoogle SREで サービス横断するSRE Role SRE 各開発チームのメンバーが 開発をメインにしつつ、パフォーマンス チューニングなどを行う Embedded SRE 各開発チームに派遣されるSRE Platform SRE Center of Practiceを実装するSREで 各チームにツールや環境の提供を行う ※他にもあると思うが、説明しやすいように一部抜粋 14 # Page. 15 ![Page Image](https://bcdn.docswell.com/page/YJ65XY1P7V.jpg) スタートアップフェーズのSRE ハイヤールーのSRE活動をする上での人員構成 – 実際に行うこと SRE活動や開発をしやすくなるように 基盤やツールの提供 Role SRE ● ● ● （メイン）開発 所属チーム内のインシデント対応・管理 パフォーマンスチューニング Platform SRE ● ● トイル削減 ポストモーテム会の実施 サービスのコンテキストを理解しているメンバーが インシデント対応や管理を行ったり、 パフォーマンスチューニングをしたりするので、 SRE専任1名で対応するよりも低コストでSRE活動ができる。 15 # Page. 16 ![Page Image](https://bcdn.docswell.com/page/GJ5YXG4PJ4.jpg) スタートアップフェーズのSRE ハイヤールーで行っていること ハイヤールーのSREがやってること ● トイル削減 ● ポストモーテムの実施 ● パフォーマンスチューニング 16 # Page. 17 ![Page Image](https://bcdn.docswell.com/page/LE35XRG6J5.jpg) ● ● ● スタートアップフェーズのSRE トイル削減 ポストモーテムの実施 パフォーマンスチューニング トイル削減(1) – 何故やるのか サービスをリリースするまでにやること サービスの新規作成 手作業が必要な処理 モニタリングの設定 本番・開発環境の両方に構築 高頻度・多量 新しいバージョンの リリース作業 ︙ 初期構築者の レビュー 生産性の低下 & オペミスによる インシデント率 増加 リリースまでの リードタイム 増加 要望対応速度 が遅くなり 信頼が薄れる 17 # Page. 18 ![Page Image](https://bcdn.docswell.com/page/8EDD2Y1MEG.jpg) ● ● ● スタートアップフェーズのSRE トイル削減 ポストモーテムの実施 パフォーマンスチューニング トイル削減(2) – どう進めるか 優先度（例） サービスの新規作成 モニタリングの設定 本番・開発環境の両方に構築 新しいバージョンの リリース作業 例 1 頻繁に行うことでヒューマン エラーを避けたい部分 2 頻繁に行うことではないが、 ヒューマンエラーを避けたい部分 本番・開発環境の両方 でリソース作成 3 できればやりたい部分 モニタリングの設定 サービスの新規作成 優先度ぎめ 新しいバージョンの リリース作業 ︙ 18 # Page. 19 ![Page Image](https://bcdn.docswell.com/page/V7PX16QQE8.jpg) ● ● ● スタートアップフェーズのSRE トイル削減 ポストモーテムの実施 パフォーマンスチューニング トイル削減(2) – どう進めたか 優先度（例） 例 1 頻繁に行うことでヒューマン エラーを避けたい部分 新しいバージョンの リリース作業 2 頻繁に行うことではないが、 ヒューマンエラーを避けたい部分 本番・開発環境の両方 でリソース作成 3 できればやりたい部分 モニタリングの設定 サービスの新規作成 CI/CDによるワークフローの自動化 CI周りの話は「モノレポでマイクロサービスを開発するための戦略と運用」で書いています。 19 # Page. 20 ![Page Image](https://bcdn.docswell.com/page/2JVLY35P7Q.jpg) ● ● ● スタートアップフェーズのSRE トイル削減 ポストモーテムの実施 パフォーマンスチューニング トイル削減(2) – どう進めたか 優先度（例） 例 1 頻繁に行うことでヒューマン エラーを避けたい部分 新しいバージョンの リリース作業 2 頻繁に行うことではないが、 ヒューマンエラーを避けたい部分 本番・開発環境の両方 でリソース作成 3 できればやりたい部分 モニタリングの設定 サービスの新規作成 IaCによる宣言的なリソース管理 20 # Page. 21 ![Page Image](https://bcdn.docswell.com/page/5EGX936QJL.jpg) ● ● ● スタートアップフェーズのSRE トイル削減 ポストモーテムの実施 パフォーマンスチューニング トイル削減(2) – どう進めたか 優先度（例） 例 1 頻繁に行うことでヒューマン エラーを避けたい部分 新しいバージョンの リリース作業 2 頻繁に行うことではないが、 ヒューマンエラーを避けたい部分 本番・開発環境の両方 でリソース作成 3 できればやりたい部分 モニタリングの設定 サービスの新規作成 テンプレーティングやモジュール化 21 # Page. 22 ![Page Image](https://bcdn.docswell.com/page/4JQ8W54W7P.jpg) ● ● ● スタートアップフェーズのSRE トイル削減 ポストモーテムの実施 パフォーマンスチューニング トイル削減(2) – どう進めたか 優先度（例） 例 1 頻繁に行うことでヒューマン エラーを避けたい部分 新しいバージョンの リリース作業 2 頻繁に行うことではないが、 ヒューマンエラーを避けたい部分 本番・開発環境の両方 でリソース作成 3 できればやりたい部分 モニタリングの設定 サービスの新規作成 22 # Page. 23 ![Page Image](https://bcdn.docswell.com/page/K742K9Q1J1.jpg) ● ● ● スタートアップフェーズのSRE トイル削減 ポストモーテムの実施 パフォーマンスチューニング トイル削減(3) – 最終的にできたもの テンプレートから サービス初期化 IaCでリソース定義 CI ・単体テストの実行 ・成果物を生成（Docker Imageなど） CD ・IaCで管理されたリソース の適用 ・成果物を各環境へデプロイ 23 # Page. 24 ![Page Image](https://bcdn.docswell.com/page/LJ1MXKP5EG.jpg) ● ● ● スタートアップフェーズのSRE トイル削減 ポストモーテムの実施 パフォーマンスチューニング トイル削減(3) – 最終的にできたもの テンプレートから サービス初期化 IaCでリソース定義 CI ・単体テストの実行 ・成果物を生成（Docker Imageなど） CD ・IaCで管理されたリソース の適用 ・成果物を各環境へデプロイ Platform SREから提供されたワークフローに則るだけで Role SREは開発を始める段階でSRE活動に必要なツール郡が揃う 24 # Page. 25 ![Page Image](https://bcdn.docswell.com/page/GJW3ND2WJ2.jpg) ● ● ● スタートアップフェーズのSRE トイル削減 ポストモーテムの実施 パフォーマンスチューニング トイル削減(3) – 最終的にできたもの テンプレートから サービス初期化 IaCでリソース定義 CI ・単体テストの実行 ・成果物を生成（Docker Imageなど） CD ・IaCで管理されたリソース の適用 ・成果物を各環境へデプロイ Platform SREから提供されたワークフローに則るだけで Role SREは開発を始める段階でSRE活動に必要なツール郡が揃う トイル削減にコストはかかるが、全員でSRE活動を行うマインドを 構築する上で必要な投資 25 # Page. 26 ![Page Image](https://bcdn.docswell.com/page/4EZV3GD2J3.jpg) スタートアップフェーズのSRE ハイヤールーで行っていること ハイヤールーのSREがやってること ● トイル削減 ● ポストモーテムの実施 ● パフォーマンスチューニング 26 # Page. 27 ![Page Image](https://bcdn.docswell.com/page/Y765XY36EV.jpg) ● ● ● スタートアップフェーズのSRE パフォーマンスチューニング ポストモーテムの実施 トイル削減 ポストモーテムの実施 (1) ポストモーテムを導入する上で重要なこと ロギング 共有 見返したり、インシデント対応者同士のコミュニケーションに利用 ポストモーテム共有会を利用して社内全員でインシデントの共有・知識の蓄積 ポストモーテム: インシデント内容と学びの共有を目的とした報告書のこと ポストモーテム インシデント の内容・影響範囲 インシデント からの学び 27 # Page. 28 ![Page Image](https://bcdn.docswell.com/page/G75YXGL574.jpg) ● ● ● スタートアップフェーズのSRE パフォーマンスチューニング ポストモーテムの実施 トイル削減 ポストモーテムの実施 (2) – ロギング インシデントタイムライン（ロギング）を活用し、 チーム内の作業のコンフリクトや不適切な対応を防ぐ NG OK A B A B Slack Slack Ale Ale rt rt 対応 互いに知らぬ 場所で対応 Ale rt Ale rt 方針 の共 有 vi a Sla ck 共通認識を持って対応 インシデントの範囲が 増加の可能性 UP 対応完了 28 # Page. 29 ![Page Image](https://bcdn.docswell.com/page/9J2GXYLGJR.jpg) ● ● ● スタートアップフェーズのSRE パフォーマンスチューニング ポストモーテムの実施 トイル削減 ポストモーテムの実施 (3) – 共有 ポストモーテム会までの流れ インシデント 対応 ・アラート確認 ・Slackで対応報告 ・恒久対応 or 一次対応 ポストモーテム 作成 ・Notionに ポストモーテムを作成 ポストモーテム会 実施 ・ポストモーテムの レビュー ・チームを横断した知見の 共有 オペレーション化 （Optional） ・再発する可能性があると判断 されたものはオペレーション として残す ・属人化を防ぐ 29 # Page. 30 ![Page Image](https://bcdn.docswell.com/page/DEYV8GQGEM.jpg) ● ● ● スタートアップフェーズのSRE パフォーマンスチューニング ポストモーテムの実施 トイル削減 ポストモーテムの実施 (3) – 共有 ポストモーテム会までの流れ インシデント 対応 ・アラート確認 ・Slackで対応報告 ・恒久対応 or 一次対応 ポストモーテム 作成 ・Notionに ポストモーテムを作成 ポストモーテム会 実施 ・ポストモーテムの レビュー ・チームを横断した知見の 共有 オペレーション化 （Optional） ・再発する可能性があると判断 されたものはオペレーション として残す ・属人化を防ぐ 上記サイクルを回しながら知識を蓄積 サービスが無くなってもポストモーテムで得た知識は消えない ⇒ 早めに始めると知識が多く貯まるのでオススメ 30 # Page. 31 ![Page Image](https://bcdn.docswell.com/page/VJNMQGK878.jpg) スタートアップフェーズのSRE ● ● ● パフォーマンスチューニング ポストモーテムの実施 トイル削減 ポストモーテムの実施 (4) – ハイヤールーで利用しているテンプレート ● ● ● ● インシデントの詳細 ○ 根本原因 ○ 影響範囲 ○ 一次対応方法 ○ 恒久対応方法 インシデント対応のために行った（行う）アクション インシデントからの学び ○ うまく行ったこと ○ うまく行かなかったこと インシデントタイムライン 31 # Page. 32 ![Page Image](https://bcdn.docswell.com/page/YE9NDWVXE3.jpg) スタートアップフェーズのSRE ハイヤールーで行っていること ハイヤールーのSREがやってること ● トイル削減 ● ポストモーテムの実施 ● パフォーマンスチューニング 32 # Page. 33 ![Page Image](https://bcdn.docswell.com/page/GE8K3NP97D.jpg) ● ● ● スタートアップフェーズのSRE ポストモーテムの実施 トイル削減 パフォーマンスチューニング パフォーマンスチューニング サービスの規模 ∝ 負荷増減 なるべく楽をして全員で パフォーマンスチューニングに取り組む環境を作りたい 外部サービスの利用 & moduleで自動構築 Datadog ● ● APM、Tracingを利用してリクエストごとのパフォーマンス計測 Infrastructureを利用してシステムメトリクスの計測 Query Insights ● スロークエリや頻繁に実行されるクエリの計測 33 # Page. 34 ![Page Image](https://bcdn.docswell.com/page/LELZVP1MJR.jpg) ● ● ● スタートアップフェーズのSRE ポストモーテムの実施 トイル削減 パフォーマンスチューニング パフォーマンスチューニング – システムメトリクスの可視化 リクエスト数をモニタリング コンテナに割り当てられるCPUの使用率 メトリクスを取っておくだけで因果関係が明確 34 # Page. 35 ![Page Image](https://bcdn.docswell.com/page/4JMVG4W6JW.jpg) ● ● ● スタートアップフェーズのSRE ポストモーテムの実施 トイル削減 パフォーマンスチューニング パフォーマンスチューニング – 実際に利用例 1 インシデント発生 & ログやAPMのチェック 2 調査結果の共有 & ソリューションの提案 3 ソリューションの実装とリリース 収集前のデータとの比較はできないので、 初期からメトリクスは収集したほうがよい データがない データが存在 メトリクス収集開始 35 # Page. 36 ![Page Image](https://bcdn.docswell.com/page/PJR2ZWYNE9.jpg) 03 まとめ # Page. 37 ![Page Image](https://bcdn.docswell.com/page/PEXD9PG87X.jpg) ● ● ● スタートアップフェーズのSRE ポストモーテムの実施 パフォーマンスチューニング トイル削減 Platform/Role SREが改めて何をしているのか Platform SRE Role SRE トイル削減 インシデント 管理 ポストモーテム パフォーマンチューニング トイル削減 ポストモーテム インシデント 管理 パフォーマンス チューニング 37 # Page. 38 ![Page Image](https://bcdn.docswell.com/page/3EKXPD4L7D.jpg) スタートアップフェーズのSRE 以上を踏まえてハイヤールーでのSRE活動全体 サービス開発 基盤やツールの提供 メイン業務 基盤を活用して開発を行う インシデント管理 自分が管理しているサービスでインシデントが 発生した際にライブインシデントレポート、ポス トモーテムの作成を行う パフォーマンス チューニング サービス初期化時に構築されるオブザーバビ リティを元にボトルネックになる部分を見つけ、 チューニングを行う developers (Role SRE) platform SRE ポストモーテム会 38 # Page. 39 ![Page Image](https://bcdn.docswell.com/page/L735XRL6E5.jpg) Take Away 全体のまとめ ● PoC後のサービス拡大フェーズでは開発速度だけでなく、 信頼性も重要 ● SRE活動しようと動いている一人に負荷が集中しないよう、開発者全員が SRE的な動きを行いやすい環 境を構築することが重要 ○ Platform SREとRole SREとして分離することで、全員が部分的に SREとしてサービスの信頼性の 担保に寄与できる環境を作っている ● SRE活動をする上で最低限行ったほうが良いと考えていること ○ トイル削減 ○ ポストモーテム ○ パフォーマンスチューニング 39 # Page. 40 ![Page Image](https://bcdn.docswell.com/page/87DD2YNM7G.jpg) ご清聴ありがとうございました 40 # Page. 41 ![Page Image](https://bcdn.docswell.com/page/VJPX165Q78.jpg) スタートアップフェーズのSRE ハイヤールーのSRE活動をする上での人員構成 ハイヤールーでの SRE 区分 Pure SRE いわゆるGoogle SREで サービス横断する SRE Embedded SRE 各開発チームに派遣される SRE Role SRE 各開発チームのメンバーが 開発をメインにしつつ、 パフォーマンスチューニングなどを行う 41 # Page. 42 ![Page Image](https://bcdn.docswell.com/page/2EVLY3PPJQ.jpg) スタートアップフェーズのSRE ハイヤールーのSRE活動をする上での人員構成 ハイヤールーでの SRE 区分 Pure SRE Embedded SRE いわゆるGoogle SREで サービス横断する SRE 各開発チームに派遣される SRE Role SRE 各開発チームのメンバーが 開発をメインにしつつ、 パフォーマンスチューニングなどを行う ハイヤールーでの 組織体制 Platform チーム ≒ Embedded SRE 開発 チーム ≒ Role SRE 開発 チーム ≒ Role SRE 開発 チーム ≒ Role SRE 42 # Page. 43 ![Page Image](https://bcdn.docswell.com/page/57GX93PQEL.jpg) スタートアップフェーズのSRE ハイヤールーのSRE活動をする上での人員構成 Platform チーム + Role SREという構成になっており、各サービスの メンバーは開発と Role SREとしての活動を行っている。 そのため、各サービスのチームでは ● 各サービスにおけるインシデント管理 ● パフォーマンスチューニング を行っている。 SRE活動をメインとしたメンバーではないため、 CI/CDの構築や各 サービスでオブザーバビリティを構築するための基盤となる部分の 開発に関しては Platformチームで行っている。 その結果、 各サービスのコンテキストを理解しているメンバーがパ フォーマンスチューニングだったり、インシデントの管理を行うことが できるため、負荷を分散することができる 。 また、開発者側も、パフォーマンスチューニングを行うために必要な 基盤が自動で Platformチームから提供されるため、その時間を開発 に充てることができるため Win-Winな状態になっている。 大まかにな僕のSRE区分 Pure SRE いわゆるGoogle SREで サービス横断する SRE Embedded SRE 各開発チームに派遣される SRE Role SRE 各開発チームのメンバーが 開発をメインにしつつ、パフォーマンスチュー ニングなどを行う 43 # Page. 44 ![Page Image](https://bcdn.docswell.com/page/4EQ8W52WJP.jpg) ● ● ● スタートアップフェーズのSRE ポストモーテムの実施 パフォーマンスチューニング トイル削減 ポストモーテムの実施 (2) – ロギング インシデントタイムラインはインシデント発生から一次対応、あるいは恒久対応ま でのリアルタイムなログを関係者同士で共有する場であり、対応者それぞれが共通 認識を持ってインシデント対応作業を実行する際に利用される。 NG OK A A B B Slack Slack Ale rt Ale rt Ale Ale rt 対応 互いに知らぬ 場所で対応 インシデントの範囲が 増加の可能性 UP rt 方針 の共 有 vi a Sla ck 共通認識を持って対応 対応完了 44 # Page. 45 ![Page Image](https://bcdn.docswell.com/page/KJ42K9L1E1.jpg) スタートアップフェーズのSRE ● ● ● ポストモーテムの実施 パフォーマンスチューニング トイル削減 [WIP] ポストモーテムの実施 (1) ポストモーテムを導入する上で重要なこと 1. 2. 3. インシデントタイムライン（ログ）を取ること 全員に対して共有する場を設けること 人を非難しないこと メモ：スライド全体コピーして別のスライドを作成して作業 する（編集がぶつからないように） 45 # Page. 46 ![Page Image](https://bcdn.docswell.com/page/LE1MXKL57G.jpg) ● ● ● スタートアップフェーズのSRE ポストモーテムの実施 パフォーマンスチューニング トイル削減 ポストモーテムの実施 (2) – インシデントタイムライン（ログ）を取ること 各チーム（サービス）ごとに アラートが流れてくる Slack のチャンネルが存在 し、その中でやり取りされる（ライブ インシデントレポートとして活用）ため、 どのようなインシ デントがどのように解決されたか を知る機会が他のチー ムに無くなってしまう。 ポストモーテム会を行うことで ● ● ● ● インシデントの解決と恒久対応のアクションが全 員に共有できる 根本原因の解決の放置を防ぐ機会になる 対応方法によってはオペレーションに落とし込 み、ドキュメントを作ることでアラート対応の属人 化を防ぐことができる サービスの作成・削除をしても知見として残る といったメリットが挙げられる。 ※人ではなく仕組みに問題があるはずなので、ポストモーテムではそこを議論する事が重要 46 # Page. 47 ![Page Image](https://bcdn.docswell.com/page/GEW3NDVWE2.jpg) ● ● ● スタートアップフェーズのSRE ポストモーテムの実施 パフォーマンスチューニング トイル削減 ポストモーテムの実施 (3) – 全員に対して共有する場を設けること 各チーム（サービス）ごとに アラートが流れてくる Slack のチャンネルが存在 し、その中でやり取りされる（ライブ インシデントレポートとして活用）ため、 どのようなインシ デントがどのように解決されたか を知る機会が他のチー ムに無くなってしまう。 ポストモーテム会までの流れ 1 Slack上で対応についての コミュニケーションを取る 2 恒久対応可能なら行う、時間がかかる場 合は一次対応後にタスクを切る 3 対応後にインシデントレポートを Notion上 に作成する 4 ポストモーテムの会で発生したインシデ ントの発表と恒久対応の進捗確認 5 継続して発生する可能性があるものに関 してはオペレーションとしてドキュメント化 し、属人化しないように対応 ポストモーテム会を行うことで ● ● ● ● インシデントの解決と恒久対応のアクションが全 員に共有できる 根本原因の解決の放置を防ぐ機会になる 対応方法によってはオペレーションに落とし込 み、ドキュメントを作ることでアラート対応の属人 化を防ぐことができる サービスの作成・削除をしても知見として残る といったメリットが挙げられる。 ※人ではなく仕組みに問題があるはずなので、ポストモーテムではそこを議論する事が重要 47 # Page. 48 ![Page Image](https://bcdn.docswell.com/page/47ZV3G42E3.jpg) スタートアップフェーズのSRE ● ● ● ポストモーテムの実施 パフォーマンスチューニング トイル削減 トイル削減 日々の開発の中にある代表的なトイル ● ● ● ● ● デプロイ ビルド サービス初期化時の共通コード Terraformの適用 Kubernetesへの変更適用 これらはリリースに必要で、毎回ほぼ同じことを繰り返 す作業でありつまらない仕事であり、ヒューマンエラー による事故が発生する部分でもある。 かつて、手動でサービスの初期化を行った際に、サービ ス名をconfigに設定するコードに不備があり、サービス 名が unnamed-go-serviceとなってしまい、正しくア ラートできない危険性のあるコードが開発環境に出てい たことがある。 48 # Page. 49 ![Page Image](https://bcdn.docswell.com/page/YJ65XYG67V.jpg) スタートアップフェーズのSRE 現状のハイヤールーで採用していない項目について ● ● SLI/SLO ○ 指標（Latencyや成功したレスポンスの割合）と指標の数値目標 エラーバジェット ○ 100%エラーのないサービスは無いという前提のもと、一定期間 において事前に許容するエラー率 ○ エラーバジェットがない状態では新しいリリースは許容されない ○ 開発陣とSREとで対立しないために設定されることが多い ○ ハイヤールーではエラーバジェットによるリリースストップをして いない ■ 機能を拡充しないといけないフェーズでリリースができな いとサービスの成長が止まってしまう ■ エラーが発生していることに素早く気づき、ユーザーが 気づくよりも早く修正を行うことで、実質 SLO100％を保 つことができる ■ エラーバジェットの設定はできる状態になっている 機能Aがほしい HireRoo Error Budget 超えてるので NG SRE developers 49