🖥️インフラエンジニアの業務を全部見せるでござる

この記事でわかること

どうも拙者でござる、10代からキーボードを叩き続けてきた生粋のオタクエンジニアですぞｗｗ

アプリケーションエンジニアからすると、インフラエンジニアって「なんか裏でサーバいじってる人」みたいなふわっとした印象を持たれがちでござる。デュフフ、それはあまりに勿体無い。ということでこの記事では、普段は表に出てこないインフラエンジニアの業務を、同業のエンジニア諸君に向けて専門的にぶっちゃけていくでござるぞ。

• インフラエンジニアが実際にやっている業務領域の全体像
• 1日の業務の流れ（設計・構築・運用のリアル）
• 使っている技術スタックと具体的な作業内容
• 障害対応やオンコールの実態

インフラエンジニアの業務領域はクソ広いでござる

まず前提として、一口に「インフラエンジニア」と言ってもカバー範囲が異常に広いのが実情でござる。昔ながらのデータセンターでラックにサーバを積む物理系から、AWSやGCPを操るクラウド系、さらにはSREやプラットフォームエンジニアまで、境界はどんどん曖昧になってきてますぞ。

拙者の観測範囲だと、業務はざっくり以下のレイヤーに分かれるでござる。

見ての通り、扱う技術の幅がえげつないでござるｗｗ 全部を極めるのは無理ゲーなので、得意分野を持ちつつ広く浅く抑えるのが現実解ですぞ。

業務フェーズ1: 設計でござる

インフラの仕事は、いきなり手を動かすわけではないでござる。まずは設計から入りますぞ。

設計フェーズでやることは主にこんな感じでござる。

• 要件定義（可用性、性能、コスト、セキュリティ要件のヒアリング）
• 構成図の作成（ネットワーク図、システム構成図）
• 冗長化・災害対策（マルチAZ、リージョン間フェイルオーバー）
• コスト試算（クラウドは油断すると請求で泣くでござる）

ここで手を抜くと後で地獄を見るので、拙者は「可用性いくつ欲しいの？」を口酸っぱく確認しますぞ。SLA 99.9%と99.99%では構成の複雑さもコストも段違いでござるからな。

業務フェーズ2: 構築（IaC）でござる

今どきのインフラ構築は、手作業でポチポチではなくコードで管理するのが主流ですぞ。いわゆる Infrastructure as Code（IaC）でござる。

Terraformを使った構築のイメージはこんな感じでござる。

resource "aws_instance" "web" {
  ami           = "ami-0abcdef1234567890"
  instance_type = "t3.micro"

  tags = {
    Name = "web-server"
    Env  = "production"
  }
}

コード化することで得られるメリットは以下でござる。

• 構成が全てレビュー可能（Pull Requestで差分が見える）
• 環境の再現性が高い（本番と同じ構成をステージングに複製できる）
• 変更履歴がGitに残る（誰がいつ何を変えたか一目瞭然）

昔は先輩の脳内にしか設定が存在しない「秘伝のタレサーバ」があったものですが、今やそれは負債でしかないでござるｗｗ コード化は正義ですぞ。

業務フェーズ3: 運用・監視でござる

構築して終わりではないのがインフラの宿命でござる。むしろここからが本番。システムは動き続ける限り、ずっと面倒を見る必要がありますぞ。

監視では、いわゆる可観測性（Observability）の3本柱を押さえるのが基本でござる。

• メトリクス: CPU、メモリ、レイテンシなどの数値データ
• ログ: アプリやミドルウェアが吐き出す記録
• トレース: リクエストがどのサービスをどう通ったかの追跡

これらをPrometheusやGrafana、Datadogなどで可視化して、閾値を超えたらアラートを飛ばす仕組みを組むでござる。

# Prometheus アラートルールの例
groups:
  - name: example
    rules:
      - alert: HighCPUUsage
        expr: cpu_usage_percent > 90
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "CPU使用率が高いでござる"

オンコールと障害対応のリアルでござる

さて、同業諸君が一番気になるであろう障害対応の話ですぞ。デュフ、ここはリアルを語らねばなるまい。

多くの現場ではオンコール当番制を敷いていて、当番の日は深夜だろうがアラートが鳴れば叩き起こされるでござる。スマホに PagerDuty の通知が来た瞬間の心臓の跳ね方といったらないｗｗ

障害対応の基本フローはこんな感じでござる。

1. 検知（アラートやユーザ報告で気づく）
2. 影響範囲の切り分け（どこまで壊れているか特定）
3. 一次対応（サービス復旧を最優先、原因究明は後回しでもよい）
4. 恒久対応（根本原因を潰す）
5. ポストモーテム（振り返りと再発防止）

重要なのは、障害を個人の責任にしない「ブレームレス」な文化ですぞ。人を責めても仕組みは改善されないでござるからな。障害から学んで仕組みを強くする、これがSRE的な思想でござる。

拙者が思う、この仕事の面白さ

インフラの仕事は地味に見られがちですが、実際はめちゃくちゃ知的でエキサイティングでござる。

• 大規模トラフィックをどう捌くか考えるパズル的な楽しさ
• コストと性能のトレードオフを最適化する経済学的な面白さ
• システム全体を俯瞰できる視座の高さ

アプリが華やかな表舞台なら、インフラは舞台を支える屋台骨。拙者はこの「縁の下感」がたまらなく好きなのでござるｗｗ

まとめ

今回はインフラエンジニアの業務を、設計・構築・運用・障害対応の4フェーズで解説したでござる。

• 業務領域はネットワークからセキュリティまで超広範
• 設計フェーズで要件と可用性を詰めるのが超重要
• 構築はIaCでコード化するのが今の主流
• 運用は可観測性の3本柱で監視する
• 障害対応はブレームレスな文化で仕組みを改善する

普段見えづらいインフラの仕事、少しは解像度が上がったなら嬉しいでござる。それでは拙者はオンコールの通知に怯えながら寝るとするｗｗ 良きインフラライフを、ではでは〜ですぞ。