インフラ・運用の場合

インフラ・運用とは

役割の概要

開発者が作ったアプリケーションを、安定して動かし続けるための仕事です。

flowchart LR
    A[開発] --> B[インフラ構築]
    B --> C[リリース]
    C --> D[運用・監視]
    D --> E{障害発生?}
    E -->|Yes| F[障害対応]
    F --> D
    E -->|No| D

主な業務

よくある1日の流れ

flowchart LR
    A[9:00
朝会] --> B[9:30
監視確認]
    B --> C[10:00
作業]
    C --> D[12:00
昼休み]
    D --> E[13:00
作業続き]
    E --> F[16:00
報告・記録]
    F --> G[18:00
退勤]

タイムスケジュール例（運用チーム）

障害発生時の1日（例）

flowchart TB
    A[10:30 アラート検知] --> B[10:35 状況確認]
    B --> C[10:40 上司に報告]
    C --> D[10:45 一次対応開始]
    D --> E[11:30 復旧確認]
    E --> F[12:00 報告書作成]
    F --> G[午後: 再発防止策検討]

最初の1ヶ月で覚えること

第1週：環境と業務を理解

第2週：Linuxとツールの基礎

第3〜4週：実務を経験

1ヶ月後の目標状態

flowchart TB
    A[1ヶ月後の目標] --> B[システム構成を説明できる]
    A --> C[サーバーに接続してログを確認できる]
    A --> D[手順書に沿って作業できる]
    A --> E[障害発生時に何をすべきか分かる]

この経験で身につくスキル

技術スキル

ビジネススキル

目指せる人材像

成長を感じられるポイント

3ヶ月後

• システム構成図を見て、主要なサーバーを説明できる
• 手順書に沿って一人で作業できる
• 障害発生時に「何を確認すべきか」が分かる

6ヶ月後

• ログを見て問題の原因を推測できる
• 簡単な手順書を自分で書ける
• 障害対応の一次切り分けができる

1年後

• 複雑な作業も任せてもらえる
• 監視アラートの意味と対処法が分かる
• 障害対応で後輩にアドバイスできる

「開発じゃないから成長できない」は誤解

開発者が知らないこと

インフラ・運用の経験者は、開発者が見落としがちな視点を持っています。

• 本番環境の厳しさ（テスト環境と違う）
• 障害対応のリアル（深夜対応、プレッシャー）
• 運用を考えた設計の重要性
• 「動けばOK」ではなく「安定して動き続ける」

最初に学ぶべきこと

1. Linuxの基本操作

ほとんどのサーバーはLinuxです。

最低限覚えるコマンド

ログの確認方法

# 最新のログを表示
tail -100 /var/log/application.log

# リアルタイムで追跡
tail -f /var/log/application.log

# 特定のキーワードを検索
grep "ERROR" /var/log/application.log

# 組み合わせ
tail -f /var/log/application.log | grep "ERROR"

2. ネットワークの基礎

flowchart LR
    A[ユーザー] --> B[ロードバランサー]
    B --> C[Webサーバー1]
    B --> D[Webサーバー2]
    C --> E[DBサーバー]
    D --> E

覚えておくべき用語

3. 監視の基本

何を監視するか

アラートが来たら

1. まず状況を確認
2. 影響範囲を把握
3. 一次対応（できる範囲で）
4. 上位者に報告
5. 記録を残す

障害対応の進め方

障害発生時のフロー

flowchart TB
    A[アラート検知] --> B[状況確認]
    B --> C[影響範囲の特定]
    C --> D[エスカレーション判断]
    D --> E[一次対応]
    E --> F[復旧確認]
    F --> G[記録・報告]

1年目にできること

報告のポイント

## 障害報告

### いつ
2024/01/15 10:30 検知

### 何が
Webサーバー1号機のCPU使用率が100%

### 影響
サイトの応答が遅い状態

### 現在の状況
- Webサーバー2号機は正常
- 原因調査中

### 対応状況
- 10:35 〇〇さんに報告済み
- 10:40 ログ確認中

手順書の読み方・書き方

手順書の重要性

インフラ・運用では手順書通りに作業することが基本です。

• ミスを防ぐ
• 誰がやっても同じ結果になる
• 問題があれば手順書を改善

手順書を読むときの注意

1. 作業前に全体を読む（途中で「あれ？」とならないように）
2. 前提条件を確認（環境、権限、事前準備）
3. 確認ポイントを把握（どこで何を確認するか）
4. ロールバック手順を確認（失敗したときの戻し方）

手順書を書くときのコツ

良い手順書の特徴

## 手順1：サービス停止

### 目的
アップデート作業のためサービスを停止する

### 実行コマンド
```bash
sudo systemctl stop application
```

### 確認方法
```bash
sudo systemctl status application
# 「Active: inactive」と表示されればOK
```

### 期待結果
- サービスが停止していること
- 「inactive」と表示されること

### 注意事項
- 停止前に利用者への告知が完了していること

よくある失敗と対策

学習のステップ

ステップ1：今の環境を理解する

• 自社のシステム構成を把握
• どこに何のサーバーがあるか
• どんな監視をしているか

ステップ2：基礎スキルを身につける

• Linuxコマンド
• ネットワークの基礎
• シェルスクリプトの基礎

ステップ3：自動化を学ぶ

• シェルスクリプトで定型作業を自動化
• 構成管理ツール（Ansible等）
• CI/CDの基礎

ステップ4：クラウドを学ぶ

• AWS / Azure / GCPの基礎
• Infrastructure as Code（IaC）
• コンテナ（Docker、Kubernetes）

キャリアパス

インフラ・運用からのキャリアは多様です。

flowchart TB
    A[インフラ・運用] --> B[SRE]
    A --> C[クラウドエンジニア]
    A --> D[セキュリティエンジニア]
    A --> E[DevOpsエンジニア]
    A --> F[インフラアーキテクト]

まとめ

インフラ・運用で大切なこと：

1. 手順書を守る（勝手な判断をしない）
2. 記録を残す（作業ログ、障害記録）
3. 報告・相談を早く（特に障害時）
4. システム全体を理解する（開発者より広い視野を持てる）
5. 「安定して動き続ける」ことの価値を理解する

インフラ・運用の経験は、エンジニアとしての土台になります。「開発じゃないから」と卑下せず、自信を持って取り組んでください。