Open8
SRE NEXT 2022
気づき
- 開発プロセスの中にSLI/SLOを導入していくアプローチ
- Production Readiness Checklist
- SLOドキュメント
- Toilのスコア化
- 開発者との関わり方
- SREの役割を共有
- GitHub Discussionsを使った信頼性、運用改善の議論
heyにおけるSREの大切さ。マルチプロダクト運用の「楽しさ」と「難しさ」および今後の展望 / 藤原 涼馬
HeyにおけるSREとは何かの整理?
-
RedHatの資料を参考に定義
- SREとは、ソフトウェアの自動化を通じてスケーラブルで信頼性の高いシステム構築と運用を実現する
- SREチームはリリースエンジニアリングや、プロダクション環境におけるサービスの可用性、遅延対応、変更管理、緊急対応、容量管理を担当する
- 品質モデル(狩野モデル)を用いて整理
- 品質特性
- 魅力的品質(リリースエンジニアリング)
- 操作していて楽しくなるユーザー体験
- 一元的品質(リリースエンジニアリング)
- 業務を遂行するのに必要な機能が揃っている
- 当たり前品質(サービスの可用性、遅延対応、・・・)
- システムや機能が意図した通りに動く
- 魅力的品質(リリースエンジニアリング)
- 品質特性
SREとは?
価値提供の支援
"魅力的品質、一元的品質"実現のために
リリースエンジニアリングを介して
実装された機能を滞りなくユーザーに届けられるようにする
提供価値の維持
"当たり前品質"実現のために、アーキテクチャ設計や運用設計に非機能的観点から関与し、安定運用の業務を担う
提供している価値の維持を通じて機会損失の発生を防ぐ
上記をソフトウェアエンジニアリングの知識を活用して実現する
個別プロダクトの拡大と個別最適化における課題への取り組み
発生する課題
- 個別プロダクト、プロダクト間連携の複雑化
- たこつぼ化による学習コストの高騰
- 知識の散財による知識習得、活用の効率低下
これらに対してプロダクトに閉じない横断的な考え方、取り組みが必要
「個別プロダクト、プロダクト間連携の複雑化」への対応
複雑性に対応できるハイスキルエンジニアの育成
- 各種学習機会の提供
- 書籍やセミナー参加の補助
- 安全に試行錯誤できる場の提供
- AWSのsandboxアカウントの提供など
「たこつぼ化による学習コストの高騰」「知識の散財による知識習得、活用の効率低下」への対応
さまざまな知識を容易に収集、活用できるようにして
歪んだアーキテクチャの導入を避ける
- 外部視点の導入(組織外の知見者の視点)
- AWS TAMなどでの個性レビュー
- 知識の集約と活用容易化
- 知識の集約場所の確保
- 個別プロダクトの知識を集約するための(仮想)組織の準備
- プロダクト個別の取組 - 固有事情 = 横断的に利用可能な知識
- 知識活用の容易化
- 横断的に利用可能なコードの提供
- ソフトウェアの再利用性といった大きな課題にしっかり取り組む
- パブリッククラウド、ストレージ、ログの集約など
- 知識の集約場所の確保
取り組みの結果、何を期待する?
プロダクト開発者は当たり前品質の実現はSREに任せ、一元的品質と魅力的品質の実現に注力できるようにする。
事業の成長と共に歩む、ABEMA SRE探求の歴史 / 岩永 勇祐
SREプラクティスの導入(2018 ~2020)
- SLI/SLOを推進するための準備を行い適用するサービスを拡張
- 拡張を進める中で複数のサービスが存在するため、開発プロセスの中に含めたいと思いProduction Readiness Checklistを作成
- 狙い
- SLI/SLOの設定を開発プロセスに含める
- 本番環境での運用品質の担保
- リリースコストの把握・軽減
- 項目
- サービスレベル
- ドキュメント
- モニタリング・アラート
- 耐障害性
- スケーラビリティ
- 狙い
SRE文化普及に立ちはだかった多くの問題と学び
課題
- 開発チームのリソースが確保できない
- 機能開発の速度と守りに対する対応を天秤にかけた時に開発者のモチベーションを確保できなかった
- システム構成が少しづつ不明に
- 作業を譲渡することにより関わるの低下で把握がしにくい
- リスクの把握のコスト増
- SREチーム内で優先度が決めずらい
学び
- 開発チームのベネフィットを意識すること
- 開発チームのモチベーションがどこにあるのかを意識する。(信頼性よりもリリース速度の改善などがモチベーションとなっている)
- 小さく始め、早く失敗し、小さな実績を積む
- チームの特性合わせて少しづつ
- (今は)On-Callから抜けてはいけない
- 障害は学びが多い
- SREの課題の把握やシステム理解が低下してしまう
- 兼務は難しい
SREプラクティスの導入(2021〜)
体制の変更
- SREとPlatformを兼務ではなくチームを明確に分けて、SREは信頼性に注力
- 開発チームの一部のメンバーがSREの役割を担うように
狙い
- 注力するポイントの最適化
- 各プラクティス導入の速度と質を上げる
- 個別のドメイン、および課題の把握と改善
- ナレッジの共有、および伝播
活動
SREが先導してSLI/SLOを再設定
- 活動
- CUJのヒアリング
- SLI/SLOの設計
- SLO Documentの作成
- 開発チームのレビュー
- 可視化&アラート設定
- 定期的な確認&見直し
- 改善
- リクエスト数の少ないサービスでのアラート
- 新しい計測手法の導入
- 設定の簡略化
- 効果
- サービス全体を俯瞰して品質が把握出来るようになった
- 様々なActionの判断基準になった
- 長期的な劣化結果傾向を把握できるようになった
インシデントへの参加
- 活動
- インシデントへの参加
- ポストモーテムの先導
- 改善
- インシデントフローの見直し
- 障害レベルの設定
- 障害を先導するBotの開発
- 効果
- 新たな課題の発掘
- チームを跨いだ連携の強化
- 全体ので障害に対する練度の向上
モニタリング課題の解決
- 活動
- フロントエンドにおけるモニタリング要件お整理
- 各PoCの実施
- ソリューションの導入
- 改善
- 監視領域の品質表作成
- 各デバイスごとの評価
- 改善の実施・先導
- 効果
- クライアント領域での監視体制の強化
- 影響範囲の明確化
体制変更の効果
よかった点
- SREプラクティスの導入効率の向上
- サービスドメイン理解の向上
- 開発チームとの連携強化
- チーム間でのナレッジの共有頻度の向上
苦労した点 - サービスドメインの理解
- 新たなスキルセットの習得
- コミュニケーションスキルの獲得
LegalForceの契約データを脅かすリスクの排除と開発速度の向上をどうやって両立したか / 浜地 亮輔
開発チームのセキュリティ課題に対する取り組み
課題
- データをどうやって守っていいかわからない
- どこまで触っていいかわからない
- ただしく保護されているかわかりにくい
→心理的不安、認知バイアス、認知過負荷、属人化
認知負荷が高いと
- 変更に対するリスク制御が困難、もしくはリスク肥大化のおそれ
- 変更レビューや動作テストの工数拡大のおそれ
- デプロイ頻度の減少
認知負荷をコントロールしてリスクを制御する
セキュリティ観点での認知過負荷に対する取り組み
- 守るべきものの定義
- 全社的に「情報資産分類」を整備→バラバラだった認知が統一
- 過剰に保護していたものは制限を緩める
- ログのマスキング解除
- アクセス制限の緩和など
- 新機能開発時はPRRでデータの格納先を確認→迷いがなくなり判断が早くなる
- Production Readliness Review(PRR) & Premortem
- 大きめの機能開発時にリリースして問題ないかチェック
- スケーラビリティ・可用性・モニタリングなどの観点でチェック
- 新しく扱う機密情報があるか、ある場合はどのレベルに該当するか
- 新しく扱う格納先がある場合、機密データが含まれるかどうか
- 大きめの機能開発時にリリースして問題ないかチェック
- Premortem
- 「障害がはっせいするとしたら何が原因か」を発生前に議論する
- システム構成図、シーケンス図を元に考えられる障害・不具合を議論
- 扱う機密情報が漏洩する手段がないか議論
- 「障害がはっせいするとしたら何が原因か」を発生前に議論する
- Production Readliness Review(PRR) & Premortem
- 責任領域の分割や予防的ガードレールの導入
- 責任領域ごとにAWSアカウント自体を分割
- 予防的ガードレール(SCP)を導入
- 行動監視
- SEIM
- 人に対する権限情報のコード化と自動デプロイ
- 権限情報をTerrafromで管理
- AWS SSO、AzureADなど
- 自動デプロイ環境を整備
- 権限情報をTerrafromで管理
- 権限内容の簡素化
- 複雑だった権限内容を簡素化
ニフティでSRE推進活動を始めて取り組んできたこと / 浅見 則彦
SREのアプローチ
AWS移行後にシステムが安定しない事による課題が発生。本来の目的である”ユーザーに価値を提供する”ことに集中できないため、SREのアプローチにて課題解決を目指す
- ユーザー影響 → 信頼性の定義、全てを計測
- サービス障害の判断基準
- サービス状態の把握
- 障害/問い合わせ → 未然に防ぐ、素早い復旧
- 素早く復旧するためには
- 問い合わせ対応を減らすためには
- 手作業 → Toil削減、自動化
- 時間をかけずに済むには
- 不確かな作業をなくすには
SREチームの関わり
- 複数のサービスチームがあるなかで、あるチームがSRE推進チームへと変化
- Embedded SREぽい感じで横展開
- 各チームの持つ課題を一緒に解決していくスタイル
- 各チーム、段階的に変化を進める
SLI/SLOの設定
ステップ
- ユーザージャーニーを洗い出し、重要な順に並び替える
- SLIを決める
- 期間とSLOを決める
まずは代表的なものを設定
サービス種別 | SLI | 測定方法 |
---|---|---|
リクエスト主導型サービス | 可用性 | 正常に処理された有効なリクエストの割合 |
リクエスト主導型サービス | レイテンシ | 閾値よりも速く処理された有効なリクエストの割合 |
リクエスト主導型サービス | 品質 | サービスの中断なしに処理された有効なリクエストの割合 |
データ処理サービス | 鮮度 | しきい値よりも最近更新された有効なデータの割合 |
データ処理サービス | カバレッジ | 正常に処理された有効なデータの割合 |
データ処理サービス | 正確性 | 正しい出力を生成した有効なデータの割合 |
データ処理サービス | スループット | データ処理率が閾値よりも早い時間の割合 |
スケジュールされた実行サービス | スキュー | 予想開始時刻の許容時間内に開始される実効の割合 |
スケジュールされた実行サービス | 実行時間 | 許容時間内に完了した実行の割合 |
SLI/SLOの可視化
- SLOドキュメント・テンプレート
- サービス概要
- (クリティカル)ユーザージャーニー
- SLI/SLO
- 内部的なSLI/SLO
- HTTPサーバ
- アプリケーション・サーバ
- API
- データベース
- 根拠
- エラーバジェット
- 注意点
- メトリクスの可視化
- Datadog
- AWS CloudWatch
- AWS CloudWatch Logs
オンコール対応改善
フローの確立
- 障害児の連絡体制・フローをアップデート
- 役割性
役割 | 責務 | 担当 |
---|---|---|
IC(インシデントコマンダー) | インシデント時に指揮を取る人 | サービス責任者、PM |
補佐 | ICを補佐する人、技術的支援や提案など | エンジニア |
記録係 | 状況を整理してSlackなどのチャンネルに流す人 | エンジニア |
専門家 | (通常は)インシデントを検知した人、一次対応者、調査・原因特定、復旧対応をする人 | エンジニア |
ユーザー連絡係 | エンドユーザーへ障害を告知する人 | CS、PM |
内部連絡係 | 内部の関係者に連絡する人 | CS、PM |
事前準備
- ドキュメントの整備
- 定期的な障害対応ロールプレイング・練習
振り返り文化
ポストモーテム共有会
- 振り返り
- 事例の共有・相談
- 再発防止のアクション
- MVPの表彰
ポストモーテム・ドキュメントの内要
- インパクト
- 根本原因・発生原因
- 対応・検出
- アクションアイテム
- 教訓(うまくいったこと・いかなかっとこと、幸運)
- タイムライン
- 参考情報、特殊な用語など
パフォーマンス会議
- 定期的にサービスのパフォーマンスをみんなで見る
- SLI/SLO、モニタリング、エラー状況、Toil状況、相談
- コストも確認する
- 最適化を意識、コスト削減の施策を共有
Toilの撲滅
Toilチェックシート、洗い出し
- 前作業のリストアップ
- Toilかどうかのポイント付け(Toil値)
- 手作業(1P)
- 繰り返し(1P)
- 自動化可能(2P)
- 長期的な価値なし(1P)
- 割り込み作業(1P)
- サービスの成長に対してO(n)である(2P)
一人から始めるプロダクトSRE / VTRyo
マネーファワードにおけるSREの種類
- 横断SRE
- Platform SRE
- Enabling SRE(会社横断)
- プロダクト単位
- Product SRE(関わり方は独自で設定)
クラウド勤怠におけるProduct SREの事例
前提
- チーム最初のSRE
- スモールチームのため、開発者をSREにコンバートする余裕はない
- SREを意識的に経験している人はこのチームにはいない
STEP
- まずは現状把握
- プロダクトチームにおける課題の把握
- 開発者の生産性を低下させているものは何か?
- 無差別アラートへの対応
- 通知要件を見直す
- SLO/SLIによるユーザー影響有無の明確化
- ダッシュボードによ可視化(わせてダッシュボードの普及)
- 開発者の生産性を低下させているものは何か?
- チームにSREという考え方をインストールする
- SREとは何かを共有
- SREに対する理解度をアンケートで把握
- アンケート結果をもとにSREについてのLTを実施
- チームにおけるSREのミッションの共有
- チームへの関わり方がイメージしやすくなり、具体的なアプローチの方向性が明確になる
- 「ソフトウェアエンジニアがプロダクトの信頼性と開発速度を最大化する活動ができる状態をつくる」
- スモールチームなのでSREへのコンバートはできない。開発者が自立的にSRE活動してもらうのが一番
- Enabling SREを採用
- チームへの関わり方がイメージしやすくなり、具体的なアプローチの方向性が明確になる
- Enabling SREとして活動
- 日々の仕事に隠れたSRE精神を自覚してもらう
- SlackなどでSREに関する情報を共有
- システムダッシュボードのふりかえり会
- 信頼性や運用効率性に関わるタスク解消時間を作る
- ライブラリアップデートやログの改善など後回しにされがちなタスクを実施する時間を明示的に取るようにチーム全体に働きかけ
- 信頼性や運用効率性に関わるタスク作業ログはみんなが見えるとこで管理
- 新規メンバー参画時も過去の履歴がわかるようにリポジトリに紐づくGitHubDiscussionsで管理する
- 信頼性や運用効率性に関わるタスク作業ログはみんなが見えるとこで管理
- リーダー、PM、開発者といった関係者の合意を取ることが重要
- 「締切はないがやるべきこと」には優先度スコアを計算して決める
- ライブラリアップデートやログの改善など後回しにされがちなタスクを実施する時間を明示的に取るようにチーム全体に働きかけ
- 日々の仕事に隠れたSRE精神を自覚してもらう
- SREとは何かを共有
プルリク作ったらデプロイされる仕組み on ECS / 大渡 裕太
環境
- ECS on EC2
- スポットインスタンスを活用
仕組み
- ブランチ単位でECSサービスを作成、都度デプロイ
- サービスディスカバリで自動でRoute53へのレコード登録
SLO決定のためのArt of SLO / 山口 能迪