自己紹介

山脇 光（Yamawaki Hikaru）

好きな食べ物：からあげ本舗のせせり弁当

先に知っておいてほしい言葉

• AWS（Amazon Web Services）
  • Amazonが提供するクラウドサービスの総称
  • サーバーやDBなどをインターネット経由で利用できる
• SRE（Site Reliability Engineering）
  • サービスの安定稼働を技術で支えるチーム・役割
  • 監視・運用・自動化が主な仕事

今日の研修はこの2つに関わる話が中心です

アジェンダ

1. 監視
2. 運用
3. セキュリティ
4. まとめ・質疑応答

1. 監視

そもそもなぜ監視が必要か

• サービスは「動いていて当たり前」と思われている
• しかし、システムは必ず壊れる
  • ハードウェア故障、ネットワーク障害、ソフトウェアのバグ…
• 監視がなければ「壊れていること」にすら気づけない
• ユーザーからの問い合わせで初めて障害に気づく → 最悪のパターン

監視がない世界 vs ある世界

ログ：システムが記録する動作の履歴（いつ・何が起きたかの記録）
メトリクス：CPU使用率やメモリ残量など、数値で表せるシステムの状態

監視の目的

• 障害の早期発見・早期対応：影響を最小限に
• 予兆の把握：壊れる前に気づく（例：ディスク残量の減少傾向）
• 意思決定の材料：データに基づいたインフラ・設計の改善
• ビジネスへの貢献：安定稼働 = ユーザーの信頼 = 売上

監視の種類

APM：アプリの処理速度や負荷を可視化するツールの総称

監視ツール・サービス

• GSでは主に Amazon CloudWatch を使用
  • AWSの各サービスと連携し、メトリクスやログを自動収集
  • ダッシュボード：グラフで状態を一覧できる画面
  • アラーム：しきい値を超えたら通知してくれる仕組み
• 実際のCloudWatchダッシュボードを見てみよう

アラートの基本（CloudWatch アラーム）

• CloudWatch アラームの3つの状態
  • OK：正常
  • ALARM：しきい値を超えた（＝対応が必要）
  • INSUFFICIENT_DATA：データ不足で判定できない
• ALARMになると → ConneやGoogleChatに通知が届く
• アラートが来たら → 各プロダクトで判断

「どれくらい安定してるか」を測る考え方

• SLI：サービスの品質を数値で表したもの
  • 例：「ページが正常に表示される割合」「応答にかかる時間」
• SLO：SLIに対して「これくらいを目指そう」という目標
  • 例：「正常表示率 99.9% 以上を維持する」
• SLA：お客様との契約上の約束（SLOより厳格）

GSではまだSLI/SLOの本格導入はこれから。
まずは「こういう考え方がある」と知っておけばOKです

2. 運用

運用とは

• サービスを安定して提供し続けるための活動
• 「作って終わり」ではない
• 開発と運用は表裏一体（DevOps の考え方）

DevOps：開発（Dev）と運用（Ops）が協力し、素早く安全にサービスを届ける文化・仕組みのこと

運用のベストプラクティス

• ランブック（手順書）の整備
• 定期的なメンテナンス・アップデート
• キャパシティプランニング
• 変更管理（いつ・誰が・何を変えたか）

→ それぞれ詳しく見ていきましょう

ランブック（手順書）の整備

• ランブック = 「こうなったらこうする」をまとめた手順書
• なぜ必要？
  • 担当者が不在でも対応できる
  • 焦っているときほど手順書が頼りになる
  • 属人化（特定の人しかできない状態）を防ぐ
• ポイント
  • 誰が読んでもわかる言葉で書く
  • スクリーンショットを活用する
  • 定期的に内容を見直す（古い手順は事故のもと）

定期的なメンテナンス・アップデート

• システムは放置すると劣化する
  • セキュリティパッチが当たっていない → 脆弱性が残る
  • OSやミドルウェアのサポート切れ → 問題が起きても助けてもらえない
• 定期メンテナンスの例
  • OS・ソフトウェアのアップデート
  • SSL証明書の更新
  • 不要なデータ・ログの整理
• 「壊れてから直す」より「壊れる前に手入れする」
  お客様へのリリース情報はこちら

キャパシティプランニング

• キャパシティ = システムが処理できる容量・能力のこと
• 足りないとどうなる？
  • サイトが重くなる・落ちる
  • 例：繁忙期(3月)にアクセス集中 → サーバーがパンク
• 余らせすぎるとどうなる？
  • 無駄なコストが発生する
• 「今どれくらい使っているか」を把握しておくことが大事

変更管理

• いつ・誰が・何を変えたかを記録すること
• なぜ必要？
  • 障害が起きたとき「直前に何か変えた？」がすぐわかる
  • 変更が原因なら、元に戻せば復旧できる
• GSでは GitHub で変更を管理している
  • Conne-webリポジトリ
  • プルリクエストで変更内容をチームでレビュー
• 「自分は覚えている」は信用しない → 必ず記録に残す

3. セキュリティ

セキュリティで守りたい3つのこと

• 機密性：見ていい人だけが見られる
  • 例：お客様の個人情報が外部に漏れない
• 完全性：情報が正しいまま保たれる
  • 例：データが勝手に書き換えられない
• 可用性：使いたいときにちゃんと使える
  • 例：攻撃を受けてサービスが止まらない

よくある脅威

• フィッシング（だましてパスワードを盗む）
• ランサムウェア（データを人質に身代金を要求）
• 不正アクセス（他人のアカウントに侵入）
• 内部不正（社内の人間による情報持ち出し）
• サプライチェーン攻撃（取引先経由で侵入）

→ 実際に起きた事例を見てみましょう

事例① ニコニコ動画（2024年6月）

• ランサムウェア攻撃でサービスが約2ヶ月停止
• サーバーのデータが暗号化され、身代金を要求された
• 動画・生放送・チャンネルなど全サービスが利用不可に
• 復旧までに膨大なコストと時間がかかった

教訓：ランサムウェアは「データを人質にとる」攻撃。
バックアップの有無が復旧のスピードを左右する

事例② KADOKAWAグループ（2024年6月）

• ニコニコ動画だけでなくグループ全体が被害を受けた
• 取引先・従業員の個人情報がダークウェブに流出
• 出版事業の受注・物流システムにも影響
• 攻撃者はグループ内のネットワークを横断的に侵害

教訓：1つのシステムが破られると、つながった先にも被害が広がる。
これがサプライチェーン攻撃の怖さ

事例③ フィッシング（身近な脅威）

• 「アカウントが停止されました」等の偽メール・SMSが届く
• 本物そっくりのログイン画面に誘導 → パスワードを入力させる
• 最近は業務用ツールを狙ったものも増えている
  • Microsoft 365、Google Workspace の偽ログイン画面など
• 盗まれたアカウントから社内情報が流出するケースも

教訓：「自分は引っかからない」と思っている人ほど危険。
少しでも怪しいと感じたらURLを確認・リンクを踏まない

事例④ 内部不正

• 退職者が顧客リストを持ち出し → 転職先で利用
• 委託先の社員が個人情報を不正にコピー
• 悪意がなくても、USBメモリや私用メールへの転送はリスク

教訓：セキュリティの脅威は外部だけではない。
アクセス権限の管理と「やってはいけないこと」の理解が大切

全員が気をつけること

• パスワードの使い回しをしない（GSでは Bitwarden で管理）
• 多要素認証（MFA）を必ず有効にする
• 知らないリンク・添付ファイルを開かない
• 業務データを私用端末・私用メールに送らない
• 離席時はPCをロックする（Win: Win+L / Mac: Ctrl+Cmd+Q）
• 困ったら自己判断せずすぐ相談する

4. まとめ

本日のポイント

1. 監視：問題を早く見つけ、早く対応する仕組み
2. 運用：サービスを安定提供するための継続的な活動
3. セキュリティ：守るべき情報と、守るための行動

困ったときは

• まず先輩・チームメンバーに相談
• ドキュメント・ランブックを確認
• エスカレーションを恐れない
• 「わからない」と言える文化を大事に

質疑応答

ご質問があればどうぞ！