ジュニアDevOps面接の質問集

要点

ジュニア DevOps の面接では、問題を落ち着いて切り分けられるか、ソフトウェアデリバリーの流れを説明できるか、本番に近いツールを安全に扱えるかが見られます。Linux のサービスとログ、Git、CI/CD、Docker、クラウド基礎、Terraform、監視、Kubernetes、構成管理、Bash の質問を想定しましょう。

このガイドでは、答えだけでなく考え方も練習します。最初に何を確認するか、どのログを見るか、いつロールバックするか、どのタイミングで追加情報を求めるかを説明できるようにしましょう。

Linux の基礎

1. DevOps エンジニアとして日常的に使用する一般的な Linux コマンドについて説明してください。

回答: DevOps 作業に不可欠な Linux コマンド：

# ファイル操作
ls -la                    # ファイルを詳細とともに一覧表示
cd /var/log              # ディレクトリを変更
cat /etc/hosts           # ファイルの内容を表示
tail -f /var/log/app.log # ログファイルをリアルタイムで追跡
grep "error" app.log     # パターンを検索

# プロセスの管理
ps aux | grep nginx      # プロセスを一覧表示
top                      # システムリソースを監視
kill -9 1234            # プロセスを強制終了
systemctl status nginx   # サービスの状態を確認
systemctl restart nginx  # サービスを再起動

# ファイルの権限
chmod 755 script.sh      # ファイルの権限を変更
chown user:group file    # 所有者を変更
ls -l                    # 権限を表示

# ディスク使用量
df -h                    # ディスク容量の使用状況
du -sh /var/log          # ディレクトリのサイズ
free -h                  # メモリの使用状況

# ネットワーク
netstat -tulpn           # リッスンポートを表示
curl https://api.com     # HTTP リクエストを送信
ping google.com          # 接続をテスト
ssh user@server          # リモートログイン

頻度: 非常に多い
難易度: 簡単

2. Linux で起動しないサービスをどのようにトラブルシューティングしますか？

回答: 体系的なトラブルシューティングのアプローチ：

# 1. サービスの状態を確認
systemctl status nginx
# エラーメッセージを探す

# 2. ログを確認
journalctl -u nginx -n 50
# または
tail -f /var/log/nginx/error.log

# 3. 構成構文を確認
nginx -t

# 4. ポートが既に使用されているか確認
netstat -tulpn | grep :80
# または
lsof -i :80

# 5. ファイルの権限を確認
ls -l /etc/nginx/nginx.conf
ls -ld /var/log/nginx

# 6. ディスク容量を確認
df -h

# 7. 詳細な情報を得るために手動で起動を試みる
nginx -g 'daemon off;'

# 8. SELinux/AppArmor を確認（有効な場合）
getenforce
ausearch -m avc -ts recent

よくある問題:

構成構文エラー
ポートが既に使用中
権限拒否
依存関係の欠落
ディスク容量の不足

頻度: 非常に多い
難易度: 中

Git によるバージョン管理

3. 基本的な Git ワークフローと一般的なコマンドについて説明してください。

回答: 日常的な DevOps タスクの Git ワークフロー：

# リポジトリを初期化
git init
git clone https://github.com/user/repo.git

# 状態を確認
git status
git log --oneline

# 基本的なワークフロー
git add .                    # 変更をステージング
git commit -m "Add feature"  # 変更をコミット
git push origin main         # リモートにプッシュ

# ブランチ
git branch feature-x         # ブランチを作成
git checkout feature-x       # ブランチを切り替え
git checkout -b feature-y    # 作成して切り替え

# マージ
git checkout main
git merge feature-x

# 最新の変更をプル
git pull origin main

# 変更を取り消し
git reset --hard HEAD        # ローカルの変更を破棄
git revert abc123           # 特定のコミットを元に戻す

# 変更を一時退避
git stash                    # 変更を一時的に保存
git stash pop               # 退避させた変更を復元

# 違いを表示
git diff                     # ステージングされていない変更
git diff --staged           # ステージングされた変更

ベストプラクティス:

明確なコミットメッセージを書く
頻繁にコミットし、定期的にプッシュする
機能ブランチを使用する
プッシュする前にプルする
コミットする前に変更を確認する

頻度: 非常に多い
難易度: 簡単

4. Git でマージコンフリクトをどのように解決しますか？

回答: ステップごとのコンフリクト解決：

# 1. マージを試みる
git merge feature-branch
# Auto-merging file.txt
# CONFLICT (content): Merge conflict in file.txt

# 2. コンフリクトが発生したファイルを確認
git status
# Unmerged paths:
#   both modified:   file.txt

# 3. コンフリクトが発生したファイルを開く
cat file.txt
# <<<<<<< HEAD
# Current branch content
# =======
# Incoming branch content
# >>>>>>> feature-branch

# 4. ファイルを編集してコンフリクトを解決
# コンフリクトマーカーを削除し、必要な変更を保持

# 5. 解決したファイルをステージング
git add file.txt

# 6. マージを完了
git commit -m "Resolve merge conflict"

# 代替案：マージを中止
git merge --abort

コンフリクトマーカー:

<<<<<<< HEAD - 現在のブランチ
======= - セパレータ
>>>>>>> branch-name - 取り込む変更

頻度: 多い
難易度: 簡単～中

CI/CD の基礎

5. CI/CD とは何ですか？また、なぜ重要ですか？

回答: CI/CD は、継続的インテグレーション（Continuous Integration）と継続的デプロイメント/デリバリー（Continuous Deployment/Delivery）の略です。

継続的インテグレーション（CI）：

すべてのコミットでコードを自動的にビルドおよびテスト
バグを早期に発見
コードが適切に統合されることを確認

継続的デプロイメント（CD）：

テストに合格した後、自動的に本番環境にデプロイ
リリースサイクルを高速化
手動エラーを削減

Loading diagram...

利点:

フィードバックループの高速化
統合問題の軽減
自動テスト
一貫性のあるデプロイ
市場投入までの時間短縮

頻度: 非常に多い
難易度: 簡単

6. GitHub Actions を使用した基本的な CI/CD パイプラインについて説明してください。

回答: GitHub Actions ワークフローの例：

# .github/workflows/ci-cd.yml
name: CI/CD Pipeline

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    
    steps:
    - name: Checkout code
      uses: actions/checkout@v4
    
    - name: Setup Node.js
      uses: actions/setup-node@v4
      with:
        node-version: '20'
    
    - name: Install dependencies
      run: npm ci
    
    - name: Run tests
      run: npm test
    
    - name: Build application
      run: npm run build
    
    - name: Run linter
      run: npm run lint

  deploy:
    needs: build-and-test
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    
    steps:
    - name: Deploy to production
      run: |
        echo "Deploying to production..."
        # ここにデプロイコマンドを追加

重要な概念:

トリガー: パイプラインの実行タイミング（プッシュ、PR、スケジュール）
ジョブ: 並行して実行できる独立したタスク
ステップ: ジョブ内の個々のコマンド
アーティファクト: ジョブ間で渡されるファイル

頻度: 非常に多い
難易度: 中

Docker とコンテナ化

7. Docker とは何ですか？また、なぜコンテナを使用するのですか？

回答: Docker は、コンテナでアプリケーションを開発、出荷、実行するためのプラットフォームです。

コンテナ vs VM:

コンテナはホスト OS カーネルを共有（軽量）
VM は完全な OS を含む（重量）
コンテナは数秒で起動
リソースの利用効率が向上

利点:

一貫性: どこでも同じ環境
分離: アプリケーションが干渉しない
移植性: どこでも実行可能
効率性: 軽量で高速

# Dockerfile の例
FROM node:18-alpine

WORKDIR /app

COPY package*.json ./
RUN npm ci --only=production

COPY . .

EXPOSE 3000

CMD ["node", "server.js"]

頻度: 非常に多い
難易度: 簡単

8. 一般的な Docker コマンドについて説明してください。

回答: 必須の Docker コマンド：

# イメージ
docker pull nginx:latest          # イメージをダウンロード
docker images                     # イメージを一覧表示
docker rmi nginx:latest          # イメージを削除
docker build -t myapp:1.0 .      # イメージをビルド

# コンテナ
docker run -d -p 80:80 nginx     # コンテナを実行
docker ps                         # 実行中のコンテナを一覧表示
docker ps -a                      # すべてのコンテナを一覧表示
docker stop container_id          # コンテナを停止
docker start container_id         # コンテナを開始
docker restart container_id       # コンテナを再起動
docker rm container_id            # コンテナを削除

# ログとデバッグ
docker logs container_id          # ログを表示
docker logs -f container_id       # ログを追跡
docker exec -it container_id bash # コンテナに入る
docker inspect container_id       # 詳細情報を表示

# クリーンアップ
docker system prune              # 未使用のデータを削除
docker volume prune              # 未使用のボリュームを削除

# Docker Compose
docker compose up -d             # サービスを開始
docker compose down              # サービスを停止
docker compose logs -f           # ログを表示

頻度: 非常に多い
難易度: 簡単

9. Web アプリケーションとデータベース用の Docker Compose ファイルを作成してください。

回答: マルチコンテナアプリケーションの例：

version: '3.8'

services:
  web:
    build: .
    ports:
      - "3000:3000"
    environment:
      - NODE_ENV=production
      - DB_HOST=db
      - DB_PORT=5432
      - DB_NAME=myapp
    depends_on:
      - db
    volumes:
      - ./logs:/app/logs
    restart: unless-stopped

  db:
    image: postgres:15-alpine
    environment:
      - POSTGRES_DB=myapp
      - POSTGRES_USER=admin
      - POSTGRES_PASSWORD=secret
    volumes:
      - postgres_data:/var/lib/postgresql/data
    ports:
      - "5432:5432"
    restart: unless-stopped

  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"
    restart: unless-stopped

volumes:
  postgres_data:

重要な概念:

services: コンテナを定義
depends_on: サービスの依存関係
volumes: 永続的なデータストレージ
environment: 環境変数
ports: ポートマッピング
restart: 再起動ポリシー

頻度: 多い
難易度: 中

クラウドの基礎

10. IaaS、PaaS、SaaS の違いについて説明してください。

回答: クラウドサービスモデル：

IaaS（Infrastructure as a Service）：

提供：仮想マシン、ストレージ、ネットワーク
管理：OS、ランタイム、アプリケーション
例：AWS EC2、Azure VM、Google Compute Engine
ユースケース：インフラストラクチャの完全な制御

PaaS（Platform as a Service）：

提供：ランタイム環境、データベース、ミドルウェア
管理：アプリケーションとデータ
例：AWS Elastic Beanstalk、Heroku、Google App Engine
ユースケース：インフラストラクチャではなくコードに集中

SaaS（Software as a Service）：

提供：完全なアプリケーション
管理：ユーザーデータと設定
例：Gmail、Salesforce、Office 365
ユースケース：すぐに使えるアプリケーション

Loading diagram...

頻度: 多い
難易度: 簡単

11. DevOps エンジニアが知っておくべき基本的な AWS サービスは何ですか？

回答: 必須の AWS サービス：

コンピューティング:

EC2: 仮想サーバー
Lambda: サーバーレス関数
ECS/EKS: コンテナオーケストレーション

ストレージ:

S3: オブジェクトストレージ
EBS: EC2 用のブロックストレージ
EFS: 共有ファイルストレージ

ネットワーク:

VPC: 仮想プライベートクラウド
Route 53: DNS サービス
CloudFront: CDN
ELB: ロードバランシング

データベース:

RDS: マネージドなリレーショナルデータベース
DynamoDB: NoSQL データベース

DevOps ツール:

CodePipeline: CI/CD サービス
CodeBuild: ビルドサービス
CloudWatch: モニタリングとロギング
IAM: アクセス管理

例：AWS CLI で EC2 インスタンスを起動：

aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type t2.micro \
  --key-name my-key-pair \
  --security-group-ids sg-0123456789abcdef0 \
  --subnet-id subnet-0123456789abcdef0 \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=WebServer}]'

頻度: 非常に多い
難易度: 中

Infrastructure as Code

12. Infrastructure as Code（IaC）とは何ですか？また、なぜ重要ですか？

回答: IaC とは、手動プロセスではなく、コードを通じてインフラストラクチャを管理することです。

利点:

バージョン管理: インフラストラクチャの変更を追跡
再現性: 同一の環境を作成
自動化: 手動エラーを削減
ドキュメント: コードがドキュメントとして機能
一貫性: どこでも同じ構成

一般的な IaC ツール:

Terraform: マルチクラウドプロビジョニング
Ansible: 構成管理
CloudFormation: AWS 固有
Pulumi: コードベースの IaC

Terraform の例:

# main.tf
provider "aws" {
  region = "us-east-1"
}

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"

  tags = {
    Name = "WebServer"
    Environment = "Production"
  }
}

resource "aws_security_group" "web_sg" {
  name        = "web-sg"
  description = "Allow HTTP traffic"

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

頻度: 非常に多い
難易度: 中

13. 基本的な Terraform ワークフローについて説明してください。

回答: Terraform ワークフローの手順：

# 1. Terraform を初期化
terraform init
# プロバイダーとモジュールをダウンロード

# 2. コードをフォーマット
terraform fmt
# .tf ファイルをフォーマット

# 3. 構成を検証
terraform validate
# 構文をチェック

# 4. 変更を計画
terraform plan
# 作成/変更/破棄されるものを表示

# 5. 変更を適用
terraform apply
# インフラストラクチャを作成/更新
# 確認を求めるプロンプト

# 6. 状態を表示
terraform show
# 現在の状態を表示

# 7. インフラストラクチャを破棄
terraform destroy
# すべてのリソースを削除

Terraform ファイル構造:

project/
├── main.tf          # メイン構成
├── variables.tf     # 入力変数
├── outputs.tf       # 出力値
├── terraform.tfvars # 変数値
└── .terraform/      # プロバイダープラグイン

変数の例:

# variables.tf
variable "instance_type" {
  description = "EC2 インスタンスタイプ"
  type        = string
  default     = "t2.micro"
}

variable "environment" {
  description = "環境名"
  type        = string
}

# terraform.tfvars
environment = "production"
instance_type = "t2.small"

頻度: 多い
難易度: 中

モニタリングとロギング

14. Web アプリケーションで監視するメトリックは何ですか？

回答: 主要な監視メトリック：

アプリケーションメトリック:

応答時間/レイテンシ
リクエストレート（1 秒あたりのリクエスト数）
エラーレート（4xx、5xx エラー）
スループット

システムメトリック:

CPU 使用率
メモリ使用量
ディスク I/O
ネットワーク I/O

インフラストラクチャメトリック:

コンテナ/ポッドの状態
サービスの可用性
ロードバランサーのヘルス

Prometheus クエリの例:

# 平均応答時間
rate(http_request_duration_seconds_sum[5m])
/ rate(http_request_duration_seconds_count[5m])

# エラーレート
sum(rate(http_requests_total{status=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m]))

# CPU 使用率
100 - (avg by (instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

アラートのしきい値:

応答時間 > 500ms
エラーレート > 1%
CPU 使用率 > 80%
メモリ使用量 > 85%
ディスク使用量 > 90%

頻度: 多い
難易度: 中

15. 複数のサーバーからのログを一元化するにはどうすればよいですか？

回答: 一元化されたロギングアーキテクチャ：

Loading diagram...

一般的なスタック（ELK）：

Elasticsearch: ログを保存してインデックスを作成
Logstash/Fluentd: ログを収集して処理
Kibana: ログを可視化して検索

Filebeat 構成の例:

# filebeat.yml
filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /var/log/app/*.log
  fields:
    app: myapp
    environment: production

output.elasticsearch:
  hosts: ["elasticsearch:9200"]
  index: "app-logs-%{+yyyy.MM.dd}"

processors:
  - add_host_metadata: ~
  - add_cloud_metadata: ~

ベストプラクティス:

構造化ロギング（JSON）を使用
相関 ID を含める
保持ポリシーを設定
戦略的にインデックスを作成
ログボリュームを監視

頻度: 多い
難易度: 中

Kubernetes の基礎

16. Kubernetes とは何ですか？また、その基本的なコンポーネントは何ですか？

回答: Kubernetes は、コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するコンテナオーケストレーションプラットフォームです。

基本的なコンポーネント:

コントロールプレーン:

API サーバー: すべてのコマンドのエントリポイント
etcd: クラスターデータ用のキーバリューストア
スケジューラー: ポッドをノードに割り当て
コントローラーマネージャー: 必要な状態を維持

ワーカーノード:

kubelet: ノード上のポッドを管理
kube-proxy: ネットワークルーティング
コンテナランタイム: containerd や CRI-O などの CRI ランタイムでコンテナを実行

Loading diagram...

基本的な Kubernetes オブジェクト:

1. ポッド:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80

2. デプロイメント:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21
        ports:
        - containerPort: 80

3. サービス:

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  type: LoadBalancer

一般的な kubectl コマンド:

# リソースを取得
kubectl get pods
kubectl get deployments
kubectl get services

# リソースを記述
kubectl describe pod nginx-pod

# ファイルから作成
kubectl apply -f deployment.yaml

# リソースを削除
kubectl delete pod nginx-pod

# ログを表示
kubectl logs nginx-pod

# ポッドでコマンドを実行
kubectl exec -it nginx-pod -- /bin/bash

# ポートフォワード
kubectl port-forward pod/nginx-pod 8080:80

頻度: 非常に多い
難易度: 簡単

構成管理

17. Ansible の基本について説明し、簡単なプレイブックを作成してください。

回答: Ansible は、SSH を使用してサーバーを構成する、エージェントレス構成管理ツールです。

重要な概念:

インベントリ: 管理するサーバーのリスト
プレイブック: タスクを定義する YAML ファイル
モジュール: 再利用可能な作業単位
ロール: 整理されたタスクのコレクション

インベントリファイル:

# inventory.ini
[webservers]
web1.example.com
web2.example.com

[databases]
db1.example.com

[all: vars]
ansible_user=ubuntu
ansible_ssh_private_key_file=~/.ssh/id_rsa

簡単なプレイブック:

# playbook.yml
---
- name: Setup Web Servers
  hosts: webservers
  become: yes
  
  vars:
    app_port: 8080
    app_user: webapp
  
  tasks:
    - name: Update apt cache
      apt:
        update_cache: yes
        cache_valid_time: 3600
    
    - name: Install required packages
      apt:
        name:
          - nginx
          - python3
          - git
        state: present
    
    - name: Create application user
      user:
        name: "{{ app_user }}"
        shell: /bin/bash
        create_home: yes
    
    - name: Copy nginx configuration
      template:
        src: templates/nginx.conf.j2
        dest: /etc/nginx/sites-available/default
      notify: Restart nginx
    
    - name: Ensure nginx is running
      service:
        name: nginx
        state: started
        enabled: yes
    
    - name: Deploy application
      git:
        repo: https://github.com/example/app.git
        dest: /var/www/app
        version: main
      become_user: "{{ app_user }}"
  
  handlers:
    - name: Restart nginx
      service:
        name: nginx
        state: restarted

テンプレートの例:

# templates/nginx.conf.j2
server {
    listen {{ app_port }};
    server_name {{ ansible_hostname }};
    
    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

プレイブックの実行:

# 構文をチェック
ansible-playbook playbook.yml --syntax-check

# ドライラン（チェックモード）
ansible-playbook playbook.yml --check

# プレイブックを実行
ansible-playbook -i inventory.ini playbook.yml

# 特定のタグで実行
ansible-playbook playbook.yml --tags "deploy"

# 特定のホストに制限
ansible-playbook playbook.yml --limit webservers

Ansible ロールの構造:

roles/
└── webserver/
    ├── tasks/
    │   └── main.yml
    ├── handlers/
    │   └── main.yml
    ├── templates/
    │   └── nginx.conf.j2
    ├── files/
    ├── vars/
    │   └── main.yml
    └── defaults/
        └── main.yml

ロールの使用:

---
- name: Setup Infrastructure
  hosts: all
  become: yes
  
  roles:
    - common
    - webserver
    - monitoring

アドホックコマンド:

# すべてのホストに ping
ansible all -i inventory.ini -m ping

# すべてのホストでコマンドを実行
ansible all -i inventory.ini -a "uptime"

# パッケージをインストール
ansible webservers -i inventory.ini -m apt -a "name=nginx state=present" --become

# ファイルをコピー
ansible all -i inventory.ini -m copy -a "src=/local/file dest=/remote/file"

# サービスを再起動
ansible webservers -i inventory.ini -m service -a "name=nginx state=restarted" --become

頻度: 多い
難易度: 中

スクリプトと自動化

18. 一般的な DevOps タスクを自動化する bash スクリプトを作成してください。

回答: bash スクリプトは、DevOps の自動化に不可欠です。

例 1：バックアップスクリプト

#!/bin/bash

# ローテーション付きのデータベースバックアップスクリプト
set -e  # エラー時に終了
set -u  # 未定義の変数で終了

# 構成
DB_NAME="myapp"
DB_USER="backup_user"
BACKUP_DIR="/var/backups/mysql"
RETENTION_DAYS=7
DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_FILE="${BACKUP_DIR}/${DB_NAME}_${DATE}.sql.gz"
LOG_FILE="/var/log/mysql_backup.log"

# メッセージをログに記録する関数
log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a "$LOG_FILE"
}

# 通知を送信する関数
send_notification() {
    local status=$1
    local message=$2
    
    # Slack に送信
    curl -X POST -H 'Content-type: application/json' \
        --data "{\"text\":\"Backup ${status}: ${message}\"}" \
        "$SLACK_WEBHOOK_URL"
}

# バックアップディレクトリが存在しない場合は作成
mkdir -p "$BACKUP_DIR"

# バックアップを開始
log "Starting backup of database: $DB_NAME"

# バックアップを実行
if mysqldump -u "$DB_USER" -p"$DB_PASSWORD" "$DB_NAME" | gzip > "$BACKUP_FILE"; then
    log "Backup completed successfully: $BACKUP_FILE"
    
    # ファイルサイズを取得
    SIZE=$(du -h "$BACKUP_FILE" | cut -f1)
    log "Backup size: $SIZE"
    
    # 古いバックアップを削除
    log "Removing backups older than $RETENTION_DAYS days"
    find "$BACKUP_DIR" -name "${DB_NAME}_*.sql.gz" -mtime +$RETENTION_DAYS -delete
    
    # S3 にアップロード (オプション)
    if command -v aws &> /dev/null; then
        log "Uploading backup to S3"
        aws s3 cp "$BACKUP_FILE" "s3://my-backups/mysql/" --storage-class GLACIER
    fi
    
    send_notification "SUCCESS" "Database $DB_NAME backed up successfully ($SIZE)"
else
    log "ERROR: Backup failed"
    send_notification "FAILED" "Database $DB_NAME backup failed"
    exit 1
fi

log "Backup process completed"

例 2：ヘルスチェックスクリプト

#!/bin/bash

# サービスヘルスチェック スクリプト
SERVICES=("nginx" "mysql" "redis")
ENDPOINTS=("http://localhost:80" "http://localhost:8080/health")
ALERT_EMAIL="[email protected]"

check_service() {
    local service=$1
    
    if systemctl is-active --quiet "$service"; then
        echo "✓ $service is running"
        return 0
    else
        echo "✗ $service is NOT running"
        return 1
    fi
}

check_endpoint() {
    local url=$1
    local response=$(curl -s -o /dev/null -w "%{http_code}" "$url")
    
    if [ "$response" -eq 200 ]; then
        echo "✓ $url is healthy (HTTP $response)"
        return 0
    else
        echo "✗ $url is unhealthy (HTTP $response)"
        return 1
    fi
}

check_disk_space() {
    local threshold=80
    local usage=$(df -h / | awk 'NR==2 {print $5}' | sed 's/%//')
    
    if [ "$usage" -lt "$threshold" ]; then
        echo "✓ Disk usage: ${usage}%"
        return 0
    else
        echo "✗ Disk usage critical: ${usage}%"
        return 1
    fi
}

# メインヘルスチェック
echo "=== System Health Check ==="
echo "Date: $(date)"
echo

failed_checks=0

# サービスをチェック
echo "Checking services..."
for service in "${SERVICES[@]}"; do
    if ! check_service "$service"; then
        ((failed_checks++))
    fi
done
echo

# エンドポイントをチェック
echo "Checking endpoints..."
for endpoint in "${ENDPOINTS[@]}"; do
    if ! check_endpoint "$endpoint"; then
        ((failed_checks++))
    fi
done
echo

# ディスク容量をチェック
echo "Checking disk space..."
if ! check_disk_space; then
    ((failed_checks++))
fi
echo

# 結果をレポート
if [ $failed_checks -

面接では短いスクリプトでも構いません。エラー処理、終了コード、ログ出力、安全なテスト方法を説明できることが重要です。

出題頻度: 非常に高い
難易度: 中

まとめ

Git リポジトリ、テスト、CI ワークフロー、Dockerfile、簡単なデプロイ先、ログやメトリクスを含む小さなプロジェクトを準備しましょう。ジュニア職では、すべてのコマンドを暗記するよりも、問題を安全に切り分ける手順を説明できることが大切です。

最新のキャリアアドバイス

要点

Linux の基礎

1. DevOps エンジニアとして日常的に使用する一般的な Linux コマンドについて説明してください。

2. Linux で起動しないサービスをどのようにトラブルシューティングしますか？

Git によるバージョン管理

3. 基本的な Git ワークフローと一般的なコマンドについて説明してください。

4. Git でマージコンフリクトをどのように解決しますか？

CI/CD の基礎

5. CI/CD とは何ですか？また、なぜ重要ですか？

6. GitHub Actions を使用した基本的な CI/CD パイプラインについて説明してください。

Docker とコンテナ化

7. Docker とは何ですか？また、なぜコンテナを使用するのですか？

8. 一般的な Docker コマンドについて説明してください。

9. Web アプリケーションとデータベース用の Docker Compose ファイルを作成してください。

クラウドの基礎

10. IaaS、PaaS、SaaS の違いについて説明してください。

11. DevOps エンジニアが知っておくべき基本的な AWS サービスは何ですか？

Infrastructure as Code

12. Infrastructure as Code（IaC）とは何ですか？また、なぜ重要ですか？

13. 基本的な Terraform ワークフローについて説明してください。

モニタリングとロギング

14. Web アプリケーションで監視するメトリックは何ですか？

15. 複数のサーバーからのログを一元化するにはどうすればよいですか？

Kubernetes の基礎

16. Kubernetes とは何ですか？また、その基本的なコンポーネントは何ですか？

構成管理

17. Ansible の基本について説明し、簡単なプレイブックを作成してください。

スクリプトと自動化

18. 一般的な DevOps タスクを自動化する bash スクリプトを作成してください。

まとめ

実際に機能する週次のキャリアのヒント

実際に機能する週次のキャリアのヒント

関連投稿

ジュニアフロントエンド開発者の面接質問：HTML・CSS・JavaScript

ジュニアフロントエンド面接質問：Reactとツール

Node.jsバックエンド開発者（ジュニア）面接質問

応募をやめて、採用されよう。

この投稿を共有

6秒を最大限に活用