ニフティでSRE推進活動を始めて取り組んできたこと

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Copyright © NIFTY Corporation All Rights Reserved.  自己紹介  ニフティ株式会社会員システムグループ SRE推進チーム N1! SRE 浅見則彦担当業務 ● Webサービスの開発・運用 ● SRE推進活動、SREsを増やす活動 ● クラウドアーキテクト、IaC、モニタリング、Toil削減 ● 新人育成、クラウド系勉強会 ● 社内タスクフォース: システム安定化、採用ブランディング 2 

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Copyright © NIFTY Corporation All Rights Reserved.  経緯・歴史  6  AWS PoC・移行〜 2022  2018  2019  2020  2021  AWS移行中〜安定化 SRE推進〜 SRE横展開〜 SRE推進チームができるまでサービス毎のAWS移行が始まる PoC・サービス移行を全員で実施 1サービス単位で移行を進め、 1人大体3〜5サービスを担当する SREを全社的に横展開を進める SLI/SLOの設定、モニタリング、ポストモーテム、障害対応ロールプレイングなどを中心に、SREアプローチの提案や、 SREsを増やすための活動を行う移行も大部分が完了システム不安定な部分が気になり始めるクラウドに適した構成や自動化が求められる安定化PJを立ち上げシステム安定化を進める。 SRE推進チームの前身となる活動がこれ

Slide 7

Slide 7 text

Copyright © NIFTY Corporation All Rights Reserved.  7  ・・・  チーム  サービス・チーム構成  インフラ (AWS) アプリケーションサービスE インフラ (AWS) アプリケーションサービスD インフラ (AWS) アプリケーションサービスA インフラ (AWS) アプリケーションサービスB インフラ (AWS) アプリケーションサービスC インフラ (AWS) アプリケーションサービスF

Slide 8

Slide 8 text

Copyright © NIFTY Corporation All Rights Reserved.  それぞれのチームがアプリとインフラの責任を持つ  8  インフラ (AWS) アプリケーションサービス ● 各チームがプロダクトに責任を持つ状態 ● 開発者も運用をする ● 運用者も開発をする ● インフラも全員で ● オンコール対応 ● チームメンバー全員が全部できるようにクラウドのメリットを十分に活かす素早い開発と効率的な運用のため、メンバーの意識やスキルが変わろうとしていたチームメンバーの役割も変化

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Copyright © NIFTY Corporation All Rights Reserved.  課題解決に向けて 10  信頼性の定義全てを計測 Toil削減自動化未然に防ぐ素早い復旧 ● 素早く復旧するためには ● 問い合せ対応を減らすには ● サービス障害の判断基準 ● サービス状態の把握 ● 時間をかけずに済むには ● 不確かな作業を無くすにはユーザー影響手作業障害/問い合せ 👉 SREのアプローチ

Slide 11

Slide 11 text

Copyright © NIFTY Corporation All Rights Reserved.  SREのアプローチ 11  信頼性を定義、全てを計測する障害は未然に防ぐ、発生する場合は素早い復旧を Toil・手作業を減らす、自動化することで時間削減と品質向上が見込める ● サービスの状態を把握して、正しい判断を行いたい ● ユーザーに提供している価値である信頼性を可視化したい ● 信頼性を起点として、 DevOpsのアクションに繋げたい ● そのために全てを計測する ● 防ぐための自動化 ● 障害は発生するものとして備える ● 訓練・練習 ● Toilを洗い出す ● 手作業は不安定で危険なもの、出来るだけ自動化を

Slide 12

Slide 12 text

Copyright © NIFTY Corporation All Rights Reserved.  組織横断的な関わり  12  SRE推進チームサービスチームA ● あるサービスチームがSRE推進チームへと変化 ● Embedded SRE ぽい感じで横展開していく ● 各チームの持つ課題を一緒に解決していくスタイル ○ システム不安定 ○ SLI/SLO設計 ○ モニタリング ○ IaC ○ Toil ○ オンコール対応 ● 各チーム、段階的に変化を進めるサービスチーム群基幹系インフラ系 SRE実践  変化  横展開 

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Copyright © NIFTY Corporation All Rights Reserved.  SLI/SLO設計ステップ  14  ユーザージャーニー参考: https://cloud.google.com/blog/products/management-tools/practical-guide-to-setting-slos  ● ユーザージャーニーを洗い出す  ● 重要な順に並び替える  SLIを決める期間とSLOを決める ● SLIを決める（どのようなメトリクスを採用するか） ● 期間とSLOを決める

Slide 15

Slide 15 text

Copyright © NIFTY Corporation All Rights Reserved.  SLI、メトリクス  15  サービス種別 SLI 測定方法リクエスト主導型サービス可用性正常に処理された有効なリクエストの割合レイテンシしきい値よりも速く処理された有効なリクエストの割合品質サービスの中断なしに処理された有効なリクエストの割合データ処理サービス鮮度しきい値よりも最近更新された有効なデータの割合カバレッジ正常に処理された有効なデータの割合正確性正しい出力を生成した有効なデータの割合スループットデータ処理率がしきい値よりも速い時間の割合スケジュールされた実行サービススキュー予想開始時刻の許容時間内に開始される実行の割合実行時間許容時間内に完了した実行の割合参考: https://cloud.google.com/architecture/adopting-slos 

Slide 16

Slide 16 text

Copyright © NIFTY Corporation All Rights Reserved.  SLOドキュメントを作る  16  参考: https://cloud.google.com/blog/products/management-tools/practical-guide-to-setting-slos  ユーザージャーニー ● 〇〇が検索できる ● 〇〇を表示できる ● 〇〇を購入できる SLI ● 指標: 可用性 ● メトリクス: 正常に処理された有効なリクエストの割合 SLO ● 目標: 99.9% ● 期間: 30日カテゴリ機能 SLI SLO 可用性〇〇ページの表示 30日間のリクエストの内、 503を除く5xx以外のレスポンスを返す割合 99.9% 成功速度〇〇ページの表示 30日間のリクエストの内、 50%は 200ms以内にレスポンスを返し、 90%は... リクエストの50% ≦ 200 ms リクエストの99% ≦ xxx ms … 👉ユーザーがサービスを使えていますか？の観点で  

Slide 17

Slide 17 text

Copyright © NIFTY Corporation All Rights Reserved.  SLI/SLOを可視化する  17  ● SLOドキュメント・テンプレート ● 各サービスのドキュメントを共有 SLOドキュメントメトリクスの収集、可視化 Amazon CloudWatch ● Datadog ● AWS CloudWatch ● AWS CloudWatch Logs ● サービス概要 ● (クリティカル)ユーザージャーニー ● SLI/SLO ● 内部的なSLI/SLO ○ HTTPサーバー ○ アプリケーション・サーバー ○ API ○ データベース ● 根拠 ● エラーバジェット ● 注意点

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

Copyright © NIFTY Corporation All Rights Reserved.  役割を決める  23  IC(インシデントコマンダー) インシデント時指揮を取る人サービス責任者、PM 補佐 ICを補佐する人、技術的支援や提案などエンジニア記録係状況を整理してSlackなどのチャンネルに流す人エンジニア専門家 (通常は)インシデントを検知した人、1次対応者調査・原因特定、復旧対応をする人エンジニアユーザー連絡係エンドユーザーへ障害の告知をする人 CS、PM 内部連絡係内部の関係者に連絡する人 CS、PM 参考: https://response.pagerduty.com/  

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Copyright © NIFTY Corporation All Rights Reserved.  振り返り文化  25  ポストモーテム共有会パフォーマンス会議 ● 振り返り ● 事例の共有・相談 ● 再発防止のアクション ● MVPの表彰 ● 定期的にサービスのパフォーマンスをみんなで見る ○ SLI/SLO、モニタリング、エラー状況、Toil状況、相談 ● コストも確認する ○ 最適化を意識、コスト削減の施策共有 ● ポストモーテム・ドキュメントの内容 ○ インパクト ○ 根本原因・発生原因 ○ 対応・検出 ○ アクションアイテム ○ 教訓(うまくいったこと・いかなったこと、幸運 ) ○ タイムライン ○ 参考情報、特殊な用語など

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Copyright © NIFTY Corporation All Rights Reserved.  Toilとは  サービスの成長や維持に関わる作業で、手作業で繰り返し行われるという特徴がある作業のこと代表的には(もし以下の作業が手作業で繰り返し行われていたらToilの可能性が高い ) - 証明書の更新作業 - 機能リリース作業 - 問い合わせの調査作業 - 障害対応 - トラフィック対策のサーバー増設作業 - …

Slide 28

Slide 28 text

Copyright © NIFTY Corporation All Rights Reserved.  Toilチェックシート、Toil洗い出し  1. 全作業をリストアップする 2. Toilかどうか、ポイントを付けてみる 3. 発生頻度・作業時間も判断ポイントにサービスにとって必要な作業の洗い出し、優先度を決めて削減・自動化の作業に取り組めるため、非常に分かりやすい。そして、自動化により品質の向上や時間削減に繋がりました。

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Copyright © NIFTY Corporation All Rights Reserved.  まとめ  30  全社的に浸透できたこと ● サービスチームから始まったSREを全社的に広めました ● 横展開で広める際に注意したのは少しずつ変化させること ○ 適用できるところから、解決できるところから柔軟に進める ● 目に見えて分かる効果があると浸透させやすい ○ かっこいいSLO Dashboardができた！モニタリングが充実した！ ○ 障害時の体制が整ったので安心！アラート・連絡フローが明確になった！ ○ システムの見える化、ドキュメントが充実した！ ● ポストモーテム共有会、パフォーマンス会議を定例化 ● ロールプレイング・練習の支援と開催 ● 地道な活動 ○ SRE本、ワークブックの輪読会を1年以上続けていた ○ 新入社員研修やクラウド勉強会にもSRE回を取り入れ新人をそそのかす ○ 社内LT大会などで、SRE、SLI/SLO、ポストモーテム、など発表

Slide 31

Slide 31 text

Copyright © NIFTY Corporation All Rights Reserved.  まとめ  31  今後の展望 ● 各チームにSREsを増やす ○ 品質向上、自己完結できるチーム、DevOpsサイクル高速化のため ○ チームに1人はSREを実践してくれる人がいる状態を目指す ○ そのような人材を育てるための勉強会や研修を用意する ● SLOの運用・エラーバジェット活用 ○ 設定後の定期的な見直し・運用・アクションができるように ○ エラーバジェットの活用 ○ SLO設定がないサービスやシステムへの適用