開発だけじゃない！SREとして支えるエンジニアリング

https://wake-career.connpass.com/event/363139 でお話しした内容です🙇

Transcript

1. ©iCARE Co.,Ltd
 開発だけじゃない！SREとして支えるエンジニアリング 〜SRE入門はじめの一歩〜 iCARE あいさか (@mist_dev)
2. ©iCARE Co.,Ltd
 自己紹介 • あいさか (@mist_dev) • iCARE SRE 2年生 • Ruby💎とビール🍺が好き • 好きなクラフトビール ◦ 福島のイエロービアワークスサイコー！と いう気持ちになっています ◦ 最近元同僚が「北砂麦酒」を立ち上げたの でぜひ行ってみてね！！
3. ©iCARE Co.,Ltd
 きょうの話 • SRE ってなんだろう • わたしが SRE になったいきさつ • SRE のプラクティスあれこれ • チームで SRE としてやっていること
4. ©iCARE Co.,Ltd
 ©iCARE Co.,Ltd
 今日のはなしの前に
5. ©iCARE Co.,Ltd
 今日のはなしの前に • みなさまのロールを教えてください ◦ SRE ◦ バックエンド・フロントエンドエンジニア ◦ インフラエンジニア ◦ それ以外
6. ©iCARE Co.,Ltd
 今日のはなしの前に • エンジニア歴は何年目ですか ◦ 1-3年目 ◦ 4-6年目 ◦ それ以上
7. ©iCARE Co.,Ltd
 ©iCARE Co.,Ltd
 SRE とは
8. ©iCARE Co.,Ltd
 SRE とは • SRE (Site Reliability Engineering) ◦ サービスの信頼性を適切なレベルで維持し続けるための文化・方法 ◦ ロールの名前で利用されることもあるけど、元の意味としては含まない • 「サービスの可用性、レイテンシ、パフォーマンス、モニタリング、キャパシティに責 任を持つ」 ◦ サービスを落とさない ◦ サービスを遅延させない ◦ サービスの状態を適切に保つ ◦ サービスのサイズを適切に保つ ◦ これらを実施するための観測を行う
9. ©iCARE Co.,Ltd
 開発エンジニアとの違い • 開発エンジニア ◦ アプリケーション開発に責任を持つ ◦ コードを書いて(書いたコードに責任を持って)機能を作り出す • SRE ◦ 開発と運用を連携し、サービスの信頼性を適切に保つことに責任を持つ ▪ システムの信頼性を定量的に評価・改善 ▪ リリース後の安定稼働を確保 • 新規機能をリリースしたい開発エンジニアと、安定稼働させたい SRE ◦ 同じ指標を追いかけていくのがだいじ
10. ©iCARE Co.,Ltd
 Platform Engineering との違い • SRE ◦ 運用をソフトウェアエンジニアリングで改善する ◦ 「サービスの信頼性」が指標になる • Platform Engineering ◦ 開発者が自身のサービスを信頼性高く、効率的に運用できるように、プラット フォームという形で具体的な解決策を構築、提供 ◦ 「開発生産性」や「運用負担の軽減」が指標になる • いずれも同じチーム内でやっているシーンも多々見受けられる ◦ 自分がやっていること・やりたいことがどっちの文脈なのかは考えると良い
11. ©iCARE Co.,Ltd
 ©iCARE Co.,Ltd
 SRE になったいきさつ
12. ©iCARE Co.,Ltd
 いきさつ • 事業会社の開発エンジニアからキャリアをスタート ◦ PHP, Java, Ruby, JavaScript (jQuery → Vue.js) ◦ ガラケーのWebアプリ作成 → 社内API 構築 → スマホサイト運営 • AWS との出会いと、オンコールを含めた障害対応に楽しさを見出す ◦ ものを作ることより、インフラ含めた運用の方に興味が向いてきた • MSP(Managed Service Provider) の会社へ転職 ◦ 他の会社のインフラの面倒を見るお仕事 ◦ インフラレイヤーの設計構築、オンコール対応など従事 ◦ 様々な規模・レベル感のインフラ環境を目の当たりにし楽しく過ごしていた
13. ©iCARE Co.,Ltd
 いきさつ • 事業により深くコミットしたいと考えるようになった ◦ 顧客の課題解決を SRE という形で支えられるようになりたい ◦ 可能であれば、 BtoB SaaS のプロダクトを持っている事業会社が良い ▪ 社会貢献度の高い BtoB SaaS に携わりたい気持ちが強くなった ▪ 開発エンジニア時代に BtoC なプロダクトに携わっておりマネタイズの難し さを感じていた • 現職の iCARE へジョイン ◦ 3 名の SRE チームで 「Carely 健康管理クラウド」 の信頼性向上に向き合って いる ▪ Platform Engineering の部分もやっている
14. ©iCARE Co.,Ltd
 ©iCARE Co.,Ltd
 SRE のプラクティスあれこれ
15. ©iCARE Co.,Ltd
 SLI / SLO とエラーバジェットの定義 • SLI (Service Level Indicator) ◦ サービスレベル指標 ◦ リクエストの成功率や可用性を指標とし、目標値が達成できているかを評価 • SLO (Service Level Objective) ◦ サービスレベル目標 ◦ ユーザーが期待する「適切」な状態を定義 • エラーバジェット ◦ サービスの信頼性が損なわれる許容値の指標 ▪ 99.9% のアクセスを 200 ms で返す場合 • それ以外のアクセスを　0.1 % 以下に収める
16. ©iCARE Co.,Ltd
 ポストモーテム文化の確立 • ポストモーテム ◦ サービス運用時のシステム障害やデータの損失など、インシデントについてま とめた文書のこと ◦ from: ポストモーテム会議とは？効率的に行う 6 つのヒント • postmortem を英和辞典で引くと「検死」なんて単語も出てくる ◦ from: 英語「postmortem」の意味・使い方・読み方 _ Weblio英和辞書 ◦ 事後の検証、みたいな意味合いでとってもらえると良さそう • インシデントをドキュメント化し後に参照できる形で残す ◦ 影響を及ぼした全ての根本原因が十分に理解される ◦ 再発の可能性や影響を削減するための効果的な予防策が確実に導入される ようにする
17. ©iCARE Co.,Ltd
 トイル(Toil)の削減と自動化 • トイル ◦ 手作業で繰り返し行われ、自動化が可能な作業のこと ◦ これらを自動化によって削減し、開発速度の最大化を目指す • トイルの定義 ◦ 手作業であること ◦ 繰り返されること ◦ 自動化できること ◦ 長期的な価値を持たないこと ◦ サービスの成長に対して比例すること
18. ©iCARE Co.,Ltd
 モニタリングの導入 • モニタリングは、サービスの健全性と可用性を追跡するための主要な手段 • Observability（可観測性）の担保のためにモニタリングを導入する • モニタリングの種類 ◦ アラート ▪ 即時アクションが必要なものを告知 ◦ チケット ▪ 数日中に行う必要があるものを告知 ◦ ロギング ▪ 必要に応じて後に分析できるように記録
19. ©iCARE Co.,Ltd
 開発チームとの協調と共有責任の醸成 • 紹介したプラクティスは開発チームと一緒にやっていくもの ◦ 文化・土台を作っていく • 開発チームと一緒にやるために必要なこと ◦ 開発したものが安全にリリースできるかどうかのレビュー ◦ 生産性向上のためのプラットフォーム提供 ◦ 障害対応や改善のためのオープンな議論 ◦ 定量データに基づく運用改善
20. ©iCARE Co.,Ltd
 ©iCARE Co.,Ltd
 SRE として今やっていること
21. ©iCARE Co.,Ltd
 SLI / SLO とエラーバジェットの定義 • SLI / SLO とエラーバジェットの定義は実はこれから ◦ 一部定義しているものもあるが、積極的に指標として追いかけていない • これからやりたいこと ◦ SLO の定義 ▪ 機能によっても目標値に差異があるので、どう定義するのが良いか考え る ◦ 開発エンジニアの朝会で SLO を追いかけていく ◦ SLO とエラーバジェットを共通単語として、開発エンジニアと議論していく
22. ©iCARE Co.,Ltd
 ポストモーテム文化の確立 • 障害対応フローを定義し、下記を実施している ◦ 障害報告書の作成 ◦ ポストモーテムの実施 ◦ インシデントマネジメント委員会の実施 ▪ ポストモーテムの管理とタスク進捗の確認 ◦ 障害対応フローのロールプレイング研修 • これからやりたいこと ◦ ポストモーテム実施に関するふりかえり ◦ ポストモーテム実施の軽量化（AIでのサマリーなど）
23. ©iCARE Co.,Ltd
 トイル(Toil)の削減と自動化 • 何回も発生する作業の自動化を進めている ◦ 本番同等環境の起動停止 ◦ TrustedAdvisor の diff 検知 ◦ CloudTrail の監査ログ突き合わせ ◦ バウンスメールのリスト作成 ◦ ライブラリアップデートの自動レビュー(Devin) • これからやりたいこと ◦ AIと組み合わせて更なるトイルの撲滅...
24. ©iCARE Co.,Ltd
 モニタリングの導入 • Datadog を利用し、下記の検知の仕組みやダッシュボードを用意している ◦ 随時：障害や障害となりそうな要素の検知・通知 ◦ 週次：基盤側の推移確認, APMやメトリクスでの異常確認 ◦ 月次：基盤側、コスト関連の推移 • これからやりたいこと ◦ 定義した SLO の推移を追うダッシュボードの作成 ◦ 現行のアプリケーションに即した形で外形監視を見直し
25. ©iCARE Co.,Ltd
 開発チームとの協調と共有責任の醸成 • SRE プラクティスの共有と実践 ◦ ポストモーテムの導入時に座学を実施 ▪ ポストモーテムの意図と意義をインストール ▪ インシデント発生後のポストモーテム実施がスムーズに ◦ 障害対応フローのロールプレイング ▪ 実際の障害対応時のインシデントコマンダーを開発エンジニアに担って もらう • これからやりたいこと ◦ 開発エンジニアが主体的に SRE プラクティスを実践するための基盤作り
26. ©iCARE Co.,Ltd
 そのほかにやっていること • 開発者の皆様と課題解決 ◦ DBや基盤の負荷が上昇しそうな機能のリリース時に負荷対策レポートの作成 ◦ デプロイフローのエラー対応 • IaC CI/CD 関連 ◦ Terraform での環境構築 ◦ Github Actions でのデプロイフロー整備 • セキュリティ関連対応 ◦ 脆弱性関連ニュースのウォッチと対応 ▪ 緊急度の高い脆弱性 (CRITICAL, HIGH) への対応は可能な限り早く実 施
27. ©iCARE Co.,Ltd
 そのほかにやっていること • EOL 対応 ◦ OS, ミドルウェア, ライブラリ ▪ 一部土日に停止メンテナンスを入れて対応 • 障害対応 ◦ インシデントコマンダーは移譲しつつ、対応は開発部隊全体で実施 ◦ 障害報告書の記載やログ調査などのサポートなど • セキュリティチェックシート対応 ◦ 契約前のお客様から組織のセキュリティ項目に対応しているかのチェック
28. ©iCARE Co.,Ltd
 ©iCARE Co.,Ltd
 SRE に興味が出てきたら
29. ©iCARE Co.,Ltd
 SRE に興味が出てきたら • 本を読もう！ ◦ SRE サイトリライアビリティエンジニアリング―Googleの信頼性を支えるエ ンジニアリングチーム ◦ SREの探求―様々な企業におけるサイトリライアビリティエンジニアリングの 導入と実践 ◦ SREをはじめよう―個人と組織による信頼性獲得への第一歩
30. ©iCARE Co.,Ltd
 SRE に興味が出てきたら • カンファレンスへGO！ • 2025/9/18(木) Platform Engineering Kaigi 2025 ◦ Platform Engineering に興味がある人はこちら • 2025/10/27(月) Observability Conference Tokyo 2025 ◦ システムの状況把握・可視化に興味がある人はこちら • 2026/1/31(土) SRE Kaigi 2026 ◦ 「ゆる SRE 勉強会」発祥の SRE カンファレンス • 2026/7/10(金)-11(土) SRE NEXT 2026 ◦ 日本では古株の SRE カンファレンス
31. ©iCARE Co.,Ltd
 ©iCARE Co.,Ltd
 Thank you.