12月 21, 2025
42 分で読める

ジュニアSRE面接質問と回答

interview
career-advice
job-search
entry-level
ジュニアSRE面接質問と回答
Milad Bonakdar

Milad Bonakdar

著者

SLO、エラーバジェット、アラート、インシデント対応、Linux、自動化、Kubernetesを中心に、ジュニアSRE面接の実践的な質問を確認できます。

ジュニアSRE面接で見られること

ジュニアSRE面接では、ユーザー影響からシステムの兆候へ順序立てて考えられるかがよく問われます。SLO、エラーバジェット、アラート、インシデント対応、Linuxの状態確認、自動化、コンテナ、Kubernetesの基本運用が中心です。シニアのように話す必要はありません。落ち着いて調査し、インシデント中に明確に共有し、リスクを隠さずに反復作業を自動化できることを示しましょう。

各質問では短い回答を練習し、プロジェクト、学習用ラボ、インターン、オンコールの見学などの具体例につなげて説明できるようにします。

SREの基礎

1. サイト信頼性エンジニアリングとは何ですか？また、DevOpsとどのように異なりますか？

回答: SREは、Googleが大規模な本番システムを確実に実行するためのアプローチです。

主な原則:

  • 運用をソフトウェアの問題として扱う
  • 運用作業（トイル）に費やす時間は最大50％
  • 信頼性と速度のバランスを取るためのエラーバジェット
  • 責任追及をしない（Blameless）事後分析
  • 段階的なロールアウトと自動ロールバック

SREとDevOpsの比較:

側面SREDevOps
焦点信頼性とスケーラビリティコラボレーションと自動化
メトリクスSLI、SLO、エラーバジェットデプロイ頻度、リードタイム
アプローチ規範的（具体的なプラクティス）哲学（文化的な動き）
トイル明示的に50％に制限具体的に定義されていない

SREは、DevOpsの原則を具体的なプラクティスとメトリクスで実装します。

希少度: 非常に一般的
難易度: 簡単

2. SLI、SLO、およびエラーバジェットについて説明してください。

回答: これらは、信頼性を測定および管理するためのSREの中核となる概念です。

SLI（サービスレベルインジケーター）:

  • サービスレベルの定量的な測定
  • 例：レイテンシー、可用性、エラー率

SLO（サービスレベル目標）:

  • SLIの目標値
  • 例：「リクエストの99.9％が成功する」

エラーバジェット:

  • 許容される失敗率（100％ - SLO）
  • 信頼性と機能速度のバランスを取るために使用
# SLI/SLOの計算例
def calculate_error_budget(total_requests, failed_requests, slo_target=0.999):
    """
    エラーバジェットの消費量を計算します

    SLO: 99.9% の成功率
    エラーバジェット: 0.1% の失敗を許容
    """
    success_rate = (total_requests - failed_requests) / total_requests
    error_rate = failed_requests / total_requests

    # エラーバジェット: 許容される 0.1% のうち、どれだけ使用したか
    allowed_errors = total_requests * (1 - slo_target)
    budget_consumed = (failed_requests / allowed_errors) * 100

    return {
        'success_rate': success_rate,
        'error_rate': error_rate,
        'slo_target': slo_target,
        'slo_met': success_rate >= slo_target,
        'error_budget_consumed': budget_consumed,
        'remaining_budget': max(0, 100 - budget_consumed)
    }

# 例
result = calculate_error_budget(
    total_requests=1000000,
    failed_requests=500,  # 0.05% のエラー率
    slo_target=0.999
)

print(f"成功率: {result['success_rate']:.4%}")
print(f"SLO達成: {result['slo_met']}")
print(f"消費されたエラーバジェット: {result['error_budget_consumed']:.1f}%")

希少度: 非常に一般的
難易度: 普通

3. トイルとは何ですか？また、どのようにして削減しますか？

回答: トイルとは、次のような反復的で手動の運用作業です。

  • 手動である（人間のアクションが必要）
  • 反復的である
  • 自動化できる
  • 永続的な価値がない
  • サービスの成長とともに直線的に増加する

トイルの例:

  • サービスの手動再起動
  • サーバー間のファイルコピー
  • リソースの手動スケーリング
  • 反復的なチケット対応

トイル削減戦略:

# 例: サービス再起動の自動化
#!/bin/bash
# auto-restart-service.sh

SERVICE_NAME="myapp"
MAX_RETRIES=3
RETRY_DELAY=5

check_service() {
    systemctl is-active --quiet $SERVICE_NAME
    return $?
}

restart_service() {
    echo "$(date): $SERVICE_NAME を再起動します"
    systemctl restart $SERVICE_NAME

    # サービスが安定するまで待機
    sleep $RETRY_DELAY

    if check_service; then
        echo "$(date): $SERVICE_NAME が正常に再起動されました"
        # 通知を送信
        curl -X POST https://alerts.company.com/webhook \
          -d "{\"message\": \"$SERVICE_NAME が自動再起動されました\"}"
        return 0
    else
        return 1
    fi
}

# メインロジック
if ! check_service; then
    echo "$(date): $SERVICE_NAME が停止しています"

    for i in $(seq 1 $MAX_RETRIES); do
        echo "試行 $i / $MAX_RETRIES"
        if restart_service; then
            exit 0
        fi
        sleep $RETRY_DELAY
    done

    # すべてのリトライが失敗した場合 - エスカレーション
    echo "$(date): $MAX_RETRIES 回の試行後、$SERVICE_NAME の再起動に失敗しました"
    curl -X POST https://pagerduty.com/api/incidents \
      -d "{\"service\": \"$SERVICE_NAME\", \"severity\": \"critical\"}"
    exit 1
fi

SREの目標: トイルを時間の50％未満に抑え、残りを自動化する。

希少度: 非常に一般的
難易度: 簡単〜普通

監視と可観測性

4. 監視と可観測性の違いは何ですか？

回答: 監視: 事前に定義されたメトリクスとアラートを収集

  • 既知の未知（Known-unknowns）：監視対象を知っている
  • ダッシュボード、アラート、メトリクス
  • 例：CPU、メモリ、リクエストレート

可観測性: 出力からシステムの状態を理解

  • 未知の未知（Unknown-unknowns）：予期していなかった問題をデバッグ
  • ログ、メトリクス、トレースの組み合わせ
  • 任意の質問に答えることができる
Loading diagram...

可観測性の3つの柱:

  1. メトリクス: 集計された数値（CPU、レイテンシー）
  2. ログ: 個別のイベント
  3. トレース: システムを通過するリクエストフロー

例: Prometheus + Grafana + Loki

# Prometheusのスクレイプ設定
scrape_configs:
  - job_name: 'api-server'
    static_configs:
      - targets: ['localhost:8080']
    metrics_path: '/metrics'
    scrape_interval: 15s

希少度: 一般的
難易度: 普通

5. 効果的なアラートをどのように設定しますか？

回答: 優れたアラートは、実用的で意味があり、疲労を引き起こさないものです。

アラートのベストプラクティス:

1. 原因ではなく症状に基づいてアラート:

# 悪い例: 高CPUでアラート
- alert: HighCPU
  expr: cpu_usage > 80

# 良い例: ユーザーへの影響に基づいてアラート
- alert: HighLatency
  expr: http_request_duration_seconds{quantile="0.95"} > 1
  for: 5m
  annotations:
    summary: "APIのレイテンシーが高い"
    description: "95パーセンタイルのレイテンシーは {{ $value }}s です"

2. ランブックへのリンクを含める:

- alert: DatabaseConnectionPoolExhausted
  expr: db_connection_pool_active / db_connection_pool_max > 0.9
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "データベース接続プールがほぼ枯渇"
    runbook: "https://wiki.company.com/runbooks/db-connections"

3. 適切な重大度レベルを使用する:

# ページングが必要（誰かを起こす）
- alert: ServiceDown
  expr: up{job="api"} == 0
  for: 1m
  labels:
    severity: critical

# チケットが必要（営業時間中に対応）
- alert: DiskSpaceWarning
  expr: disk_free_percent < 20
  for: 30m
  labels:
    severity: warning

4. アラート疲労を避ける:

  • for: 期間を使用して、アラートの頻発を回避
  • 関連するアラートをグループ化
  • 適切な閾値を設定
  • 定期的に確認および調整

希少度: 非常に一般的
難易度: 普通

インシデント対応

6. インシデント対応プロセスについて説明してください。

回答: 構造化されたインシデント対応は、影響と回復時間を最小限に抑えます。

インシデント対応の手順:

Loading diagram...

1. 検知:

  • アラートが発生するか、ユーザーが問題を報告
  • アラートを確認
  • インシデントチャネルを作成

2. トリアージ:

# 簡単な評価チェックリスト
- ユーザーへの影響は何ですか？
- 影響を受けているユーザーの数は？
- 影響を受けているサービスは何ですか？
- 状況は悪化していますか？

3. 緩和:

# 一般的な緩和戦略
- 最近のデプロイのロールバック
- リソースのスケールアップ
- 問題のある機能を無効化
- バックアップシステムへのフェイルオーバー
- トラフィックのレート制限

4. 解決:

  • 根本原因を修正
  • メトリクスが正常に戻ることを確認
  • 再発を監視

5. 事後分析（責任追及をしない）:

# インシデント事後分析テンプレート

## 概要
何が起こったかの簡単な説明

## 影響
- 期間: 2024-11-25 10:00 - 10:45 UTC (45 分)
- 影響を受けたユーザー: ~10,000 (全体の 5%)
- 影響を受けたサービス: API、Web フロントエンド

## 根本原因
遅いクエリによるデータベース接続プールの枯渇

## タイムライン
- 10:00: 高 API レイテンシーのアラートが発生
- 10:05: オンコールエンジニアが確認
- 10:10: データベースがボトルネックであることを特定
- 10:15: 接続プールサイズを拡大 (緩和)
- 10:30: 遅いクエリを特定して強制終了
- 10:45: サービスが完全に復旧

## 解決策
- 即時: 接続プールを 100 から 200 に拡大
- 短期: クエリタイムアウト (30 秒) を追加
- 長期: 遅いクエリを最適化、クエリ監視を追加

## アクションアイテム
- [ ] 遅いクエリのアラートを追加 (担当者: Alice, 期限: 2024-12-01)
- [ ] アプリケーションにクエリタイムアウトを実装 (担当者: Bob, 期限: 2024-12-05)
- [ ] 上位 10 件の遅いクエリを確認して最適化 (担当者: Charlie, 期限: 2024-12-10)

## 教訓
- 接続プールの監視が不十分だった
- クエリパフォーマンスの低下に気付かなかった

希少度: 非常に一般的
難易度: 普通

7. レイテンシーが高くなっているサービスをどのようにトラブルシューティングしますか？

回答: 体系的なデバッグアプローチ：

# 1. 問題の検証
curl -w "@curl-format.txt" -o /dev/null -s https://api.example.com/health

# curl-format.txt:
#     time_namelookup:  %{time_namelookup}s\n
#        time_connect:  %{time_connect}s\n
#     time_appconnect:  %{time_appconnect}s\n
#    time_pretransfer:  %{time_pretransfer}s\n
#       time_redirect:  %{time_redirect}s\n
#  time_starttransfer:  %{time_starttransfer}s\n
#                     ----------\n
#          time_total:  %{time_total}s\n

# 2. アプリケーションメトリクスの確認
# - リクエストレート (急上昇?)
# - エラーレート (リトライを引き起こすエラー?)
# - リソース使用量 (CPU、メモリ)

# 3. 依存関係の確認
# - データベースクエリ時間
# - 外部API呼び出し
# - キャッシュヒット率

# 4. インフラストラクチャの確認
top  # CPU使用率
free -h  # メモリ
iostat  # ディスクI/O
netstat -s  # ネットワーク統計

# 5. エラーログの確認
tail -f /var/log/app/error.log | grep -i "timeout\|slow\|error"

# 6. アプリケーションのプロファイリング
# Pythonの例
import cProfile
cProfile.run('my_function()')

# 7. データベースの確認
# スロークエリログ
SELECT * FROM mysql.slow_log ORDER BY query_time DESC LIMIT 10;

# アクティブなクエリ
SELECT pid, query, state, query_start
FROM pg_stat_activity
WHERE state = 'active';

一般的な原因:

  • データベースのスロークエリ
  • 外部APIのタイムアウト
  • メモリプレッシャー（GCの一時停止）
  • ネットワークの問題
  • リソースの枯渇
  • 非効率なコードパス

希少度: 非常に一般的
難易度: 普通

自動化とスクリプト

8. サービスが正常かどうかを確認し、必要に応じて再起動するスクリプトを作成してください。

回答: ヘルスチェックと自動修復スクリプト：

#!/usr/bin/env python3
"""
自動再起動機能を備えたサービスヘルスチェッカー
"""
import requests
import subprocess
import time
import sys
from datetime import datetime

class ServiceMonitor:
    def __init__(self, service_name, health_url, max_retries=3):
        self.service_name = service_name
        self.health_url = health_url
        self.max_retries = max_retries

    def check_health(self):
        """サービスが正常かどうかを確認します"""
        try:
            response = requests.get(
                self.health_url,
                timeout=5
            )
            return response.status_code == 200
        except requests.exceptions.RequestException as e:
            print(f"{datetime.now()}: ヘルスチェックに失敗しました: {e}")
            return False

    def restart_service(self):
        """systemctlを使用してサービスを再起動します"""
        try:
            print(f"{datetime.now()}: {self.service_name} を再起動します")
            subprocess.run(
                ['systemctl', 'restart', self.service_name],
                check=True,
                capture_output=True
            )
            time.sleep(10)  # サービスが開始されるまで待機
            return True
        except subprocess.CalledProcessError as e:
            print(f"{datetime.now()}: 再起動に失敗しました: {e.stderr}")
            return False

    def send_alert(self, message, severity='warning'):
        """監視システムにアラートを送信します"""
        try:
            requests.post(
                'https://alerts.company.com/webhook',
                json={
                    'service': self.service_name,
                    'message': message,
                    'severity': severity,
                    'timestamp': datetime.now().isoformat()
                },
                timeout=5
            )
        except Exception as e:
            print(f"アラートの送信に失敗しました: {e}")

    def monitor(self):
        """メインの監視ループ"""
        if self.check_health():
            print(f"{datetime.now()}: {self.service_name} は正常です")
            return 0

        print(f"{datetime.now()}: {self.service_name} は異常です")
        self.send_alert(f"{self.service_name} が停止しています", severity='warning')

        # 再起動を試みます
        for attempt in range(1, self.max_retries + 1):
            print(f"再起動の試み {attempt}/{self.max_retries}")

            if self.restart_service() and self.check_health():
                print(f"{datetime.now()}: サービスが回復しました")
                self.send_alert(
                    f"{self.service_name} が再起動後に自動回復しました",
                    severity='info'
                )
                return 0

            time.sleep(5)

        # すべてのリトライが失敗しました
        print(f"{datetime.now()}: サービスの回復に失敗しました")
        self.send_alert(
            f"{self.service_name} が {self.max_retries} 回の試み後に回復に失敗しました",
            severity='critical'
        )
        return 1

if __name__ == '__main__':
    monitor = ServiceMonitor(
        service_name='myapp',
        health_url='http://localhost:8080/health'
    )
    sys.exit(monitor.monitor())

希少度: 一般的
難易度: 普通

信頼性のプラクティス

9. ランブックとは何ですか？また、なぜ重要ですか？

回答: ランブックとは、運用タスクとインシデントを処理するための文書化された手順です。

ランブックの構造:

# ランブック: 高 API レイテンシー

## 症状
- API 95 パーセンタイルのレイテンシー > 1 秒
- ページの読み込みが遅いというユーザーからの苦情
- アラート: "HighAPILatency" が発生

## 重大度
**警告** - ユーザーエクスペリエンスが低下しますが、サービスは機能します

## 調査手順

### 1. 現在のメトリクスを確認
```bash
# レイテンシー分布を確認
curl -s http://prometheus:9090/api/v1/query?query='histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))'

# リクエストレートを確認
curl -s http://prometheus:9090/api/v1/query?query='rate(http_requests_total[5m])'

2. ボトルネックを特定

  • データベースクエリ時間を確認
  • 外部API呼び出しを確認
  • キャッシュヒット率を確認
  • 最近のデプロイを確認

3. 依存関係を確認

# データベース接続
mysql -e "SHOW PROCESSLIST;"

# Redisレイテンシー
redis-cli --latency

# 外部API
curl -w "%{time_total}\n" -o /dev/null -s https://external-api.com/health

緩和手順

簡単な修正 (< 5 分)

  1. アプリケーションインスタンスをスケールアップ
kubectl scale deployment api --replicas=10
  1. キャッシュTTLを一時的に増やす
redis-cli CONFIG SET maxmemory-policy allkeys-lru

問題が解決しない場合

  1. 最近のデプロイをロールバック
kubectl rollout undo deployment/api
  1. レート制限を有効にする
kubectl apply -f rate-limit-config.yaml

解決

  • 根本原因を修正 (遅いクエリ、非効率なコード)
  • 修正をデプロイ
  • 30分間監視
  • 通常のキャパシティにスケールバック

エスカレーション

30分以内に解決できない場合:

  • エスカレーション先: @backend-team
  • Slack チャネル: #incidents
  • オンコール: PagerDuty のエスカレーションポリシーを使用

関連情報


**ランブックが重要な理由:**
- インシデント対応の迅速化
- 一貫した手順
- 知識の共有
- インシデント中のストレス軽減
- 新しいチームメンバー向けのトレーニングツール

**希少度:** 一般的  
**難易度:** 簡単

---

### 10. グレースフルデグラデーションの概念について説明してください。

**回答:**
**グレースフルデグラデーション**とは、コンポーネントが故障した場合に、システム全体が完全に故障するのではなく、機能が低下した状態で動作し続けることを意味します。

**戦略:**

**1. フィーチャーフラグ:**
```python
# 負荷が高いときに重要でない機能を無効にする
class FeatureFlags:
    def __init__(self):
        self.flags = {
            'recommendations': True,
            'analytics': True,
            'search_autocomplete': True
        }

    def is_enabled(self, feature):
        # エラーバジェットが低い場合、重要でない機能を無効にする
        if self.error_budget_low():
            non_critical = ['analytics', 'search_autocomplete']
            if feature in non_critical:
                return False
        return self.flags.get(feature, False)

    def error_budget_low(self):
        # エラーバジェットが 20% 未満かどうかを確認
        return get_error_budget() < 0.2

# 使用例
flags = FeatureFlags()
if flags.is_enabled('recommendations'):
    show_recommendations()
else:
    # グレースフルデグラデーション - 静的なコンテンツを表示
    show_popular_items()

2. サーキットブレーカー:

from enum import Enum
import time

class CircuitState(Enum):
    CLOSED = "closed"  # 通常の操作
    OPEN = "open"      # 失敗、リクエストを拒否
    HALF_OPEN = "half_open"  # 回復をテスト

class CircuitBreaker:
    def __init__(self, failure_threshold=5, timeout=60):
        self.failure_threshold = failure_threshold
        self.timeout = timeout
        self.failures = 0
        self.last_failure_time = None
        self.state = CircuitState.CLOSED

    def call(self, func, *args, **kwargs):
        if self.state == CircuitState.OPEN:
            if time.time() - self.last_failure_time > self.timeout:
                self.state = CircuitState.HALF_OPEN
            else:
                # 失敗するサービスを呼び出す代わりにフォールバックを返す
                return self.fallback()

        try:
            result = func(*args, **kwargs)
            self.on_success()
            return result
        except Exception as e:
            self.on_failure()
            return self.fallback()

    def on_success(self):
        self.failures = 0
        self.state = CircuitState.CLOSED

    def on_failure(self):
        self.failures += 1
        self.last_failure_time = time.time()
        if self.failures >= self.failure_threshold:
            self.state = CircuitState.OPEN

    def fallback(self):
        # キャッシュされたデータまたはデフォルトの応答を返す
        return {"status": "degraded", "data": []}

# 使用例
breaker = CircuitBreaker()
result = breaker.call(external_api_call, user_id=123)

3. タイムアウトとリトライ:

import requests
from requests.adapters import HTTPAdapter
from requests.packages.urllib3.util.retry import Retry

def create_resilient_session():
    session = requests.Session()

    # リトライ戦略
    retry = Retry(
        total=3,
        backoff_factor=0.3,
        status_forcelist=[500, 502, 503, 504]
    )

    adapter = HTTPAdapter(max_retries=retry)
    session.mount('http://', adapter)
    session.mount('https://', adapter)

    return session

# タイムアウト付きの使用例
session = create_resilient_session()
try:
    response = session.get('https://api.example.com/data', timeout=5)
except requests.exceptions.Timeout:
    # グレースフルデグラデーション - キャッシュされたデータを使用
    response = get_cached_data()

希少度: 一般的
難易度: 普通

コンテナ化の基礎

11. Dockerとは何ですか？また、仮想マシンとどのように異なりますか？

回答: Dockerは、アプリケーションをその依存関係とともにパッケージ化するコンテナ化プラットフォームです。

コンテナと仮想マシンの比較:

Loading diagram...

主な違い:

機能コンテナ仮想マシン
起動時間秒分
サイズMBGB
リソース使用量軽量重い
分離プロセスレベルハードウェアレベル
OSホストOSを共有VMごとに個別のOS

Dockerの基本:

# イメージをプル
docker pull nginx:latest

# コンテナを実行
docker run -d \
  --name my-nginx \
  -p 8080:80 \
  nginx:latest

# 実行中のコンテナをリスト
docker ps

# ログを表示
docker logs my-nginx

# コンテナ内でコマンドを実行
docker exec -it my-nginx bash

# コンテナを停止
docker stop my-nginx

# コンテナを削除
docker rm my-nginx

Dockerfileの例:

# ベースイメージ
FROM python:3.12-slim

# 作業ディレクトリを設定
WORKDIR /app

# 要件をコピー
COPY requirements.txt .

# 依存関係をインストール
RUN pip install --no-cache-dir -r requirements.txt

# アプリケーションコードをコピー
COPY . .

# ポートを公開
EXPOSE 8000

# ヘルスチェック
HEALTHCHECK --interval=30s --timeout=3s \
  CMD curl -f http://localhost:8000/health || exit 1

# アプリケーションを実行
CMD ["python", "app.py"]

ビルドと実行:

# イメージをビルド
docker build -t myapp:1.0 .

# 環境変数を使用して実行
docker run -d \
  --name myapp \
  -p 8000:8000 \
  -e DATABASE_URL=postgres://db:5432/mydb \
  -e LOG_LEVEL=info \
  myapp:1.0

# リソース使用量を表示
docker stats myapp

Docker Compose（マルチコンテナ）:

services:
  web:
    build: .
    ports:
      - "8000:8000"
    environment:
      - DATABASE_URL=postgresql://db:5432/mydb
    depends_on:
      - db
      - redis
    restart: unless-stopped

  db:
    image: postgres:14
    environment:
      - POSTGRES_DB=mydb
      - POSTGRES_PASSWORD=secret
    volumes:
      - postgres_data:/var/lib/postgresql/data

  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"

volumes:
  postgres_data:

Docker Composeで実行:

# すべてのサービスを開始
docker compose up -d

# ログを表示
docker compose logs -f web

# サービスをスケール
docker compose up -d --scale web=3

# すべてのサービスを停止
docker compose down

ベストプラクティス:

  • 公式ベースイメージを使用
  • レイヤー数を最小限に抑える
  • rootとして実行しない
  • .dockerignoreを使用
  • イメージに適切にタグ付け
  • 脆弱性をスキャン

希少度: 非常に一般的
難易度: 簡単〜普通

バージョン管理とデプロイ

12. Gitのワークフローと、デプロイをどのように処理するかを説明してください。

回答: Gitは、バージョン管理とデプロイの自動化に不可欠です。

一般的なGitワークフロー:

Loading diagram...

基本的なGitコマンド:

# リポジトリをクローン
git clone https://github.com/company/repo.git
cd repo

# フィーチャーブランチを作成
git checkout -b feature/add-monitoring

# 変更を加えてコミット
git add .
git commit -m "Prometheus監視を追加"

# リモートにプッシュ
git push origin feature/add-monitoring

# mainから更新
git checkout main
git pull origin main
git checkout feature/add-monitoring
git rebase main

# フィーチャーをマージ (PR承認後)
git checkout main
git merge feature/add-monitoring
git push origin main

ブランチ戦略:

1. Gitflow:

  • main: 本番環境で使用できるコード
  • develop: 統合ブランチ
  • feature/*: 新機能
  • release/*: リリースの準備
  • hotfix/*: 緊急修正

2. Trunk-Based Development:

# 短命なフィーチャーブランチ
git checkout -b feature/quick-fix
# 1日未満の作業
git push origin feature/quick-fix
# レビュー後すぐにmainにマージ

デプロイワークフロー:

1. CI/CDパイプライン (GitHub Actions):

name: 本番環境にデプロイ

on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: テストを実行
        run: |
          npm install
          npm test

      - name: リンティングを実行
        run: npm run lint

  build:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Dockerイメージをビルド
        run: |
          docker build -t myapp:${{ github.sha }} .
          docker tag myapp:${{ github.sha }} myapp:latest

      - name: レジストリにプッシュ
        run: |
          echo ${{ secrets.DOCKER_PASSWORD }} | docker login -u ${{ secrets.DOCKER_USERNAME }} --password-stdin
          docker push myapp:${{ github.sha }}
          docker push myapp:latest

  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: 本番環境にデプロイ
        run: |
          kubectl set image deployment/myapp \
            myapp=myapp:${{ github.sha }}
          kubectl rollout status deployment/myapp

2. デプロイスクリプト:

#!/bin/bash
# deploy.sh - 簡単なデプロイスクリプト

set -e  # エラー時に終了

# 構成
APP_NAME="myapp"
VERSION=$(git rev-parse --short HEAD)
ENVIRONMENT=${1:-staging}

echo "$APP_NAME バージョン $VERSION を $ENVIRONMENT にデプロイ"

# テストを実行
echo "テストを実行中..."
npm test

# アプリケーションをビルド
echo "アプリケーションをビルド中..."
npm run build

# Dockerイメージをビルド
echo "Dockerイメージをビルド中..."
docker build -t $APP_NAME:$VERSION

まとめ

ジュニアSRE面接では、SLO、アラート、インシデント対応、Linuxトラブルシューティング、安全な自動化を実例で説明できるようにしておきましょう。良い回答はコマンドの暗記ではなく、ユーザー影響を確認し、信頼できるシグナルを見て、低リスクで緩和し、学びを記録する流れを示します。

Newsletter subscription

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

最新の洞察をメールボックスに直接お届けします

関連投稿

ジュニアフロントエンド開発者の面接質問：HTML・CSS・JavaScript
12月 21, 2025
39 分で読める

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

セマンティックHTML、レスポンシブCSS、JavaScriptのスコープ、非同期処理、DOMイベント、配列メソッドを32問で確認できます。

Milad BonakdarMilad Bonakdar
ジュニアフロントエンド面接質問：Reactとツール
12月 21, 2025
31 分で読める

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

React、Git、ビルドツール、Webパフォーマンス、デバッグ、アクセシビリティ、テストを扱う21問で、ジュニアフロントエンド面接に備えましょう。

Milad BonakdarMilad Bonakdar
Node.jsバックエンド開発者（ジュニア）面接質問
12月 21, 2025
43 分で読める

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

JavaScript基礎、非同期処理、イベントループ、Express、REST API、データベース、セキュリティ、テスト、デバッグを扱うジュニア向けNode.js面接質問35問で練習できます。

Milad BonakdarMilad Bonakdar

次の面接は履歴書一つで決まる

数分でプロフェッショナルで最適化された履歴書を作成。デザインスキルは不要—証明された結果だけ。

私の履歴書を作成

この投稿を共有

6秒を最大限に活用

採用担当者は平均わずか6〜7秒しか履歴書をスキャンしません。当社の実績のあるテンプレートは、即座に注目を集め、読み続けてもらえるように設計されています。

目立つ履歴書を作成