【設計地獄】VPC Peering設計ミスで全社システム3日間停止→緊急PSC移行の修羅場記録
プロローグ：「簡単接続」という甘い誘惑
2025年6月10日（月曜日）午前11時
「VPC間の接続？VPC Peeringでポチポチするだけでしょ。30分もあれば全部つながりますよ」
新しいマルチプロジェクト環境の設計会議で、私はそう自信満々に答えました。まさか、その「簡単な接続」が全社システム3日間停止という大惨事を招くとは夢にも思わず…
これは、VPC設計の甘い認識が招いた修羅場と、そこから学んだネットワーク設計の真実の記録です。
第一章：「美しい設計図」の落とし穴
プロジェクト概要：マルチVPC環境の構築
背景：
会社の急成長に伴い、部署別・環境別にGCPプロジェクトを分離することになりました。
設計要件：
- 部署別の独立性確保
- 環境別（dev/staging/prod）の分離
- 必要に応じた部署間連携
- 共有サービス（AD、DNS、監視）への接続
私が描いた「美しい設計図」
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
[共有サービスVPC]
shared-vpc (10.0.0.0/16)
├─ AD: 10.0.1.0/24
├─ DNS: 10.0.2.0/24
└─ 監視: 10.0.3.0/24
↓ VPC Peering
┌─────────────────┼─────────────────┐
↓ ↓ ↓
[営業部VPC] [開発部VPC] [経理部VPC]
sales-vpc dev-vpc finance-vpc
(10.1.0.0/16) (10.2.0.0/16) (10.3.0.0/16)
↓ ↓ ↓
VPC Peering VPC Peering VPC Peering
↓ ↓ ↓
[営業PROD] [開発PROD] [経理PROD]
(10.1.0.0/24) (10.2.0.0/24) (10.3.0.0/24)
↓ ↓ ↓
[営業STAGING] [開発STAGING] [経理STAGING]
(10.1.1.0/24) (10.2.1.0/24) (10.3.1.0/24)
↓ ↓ ↓
[営業DEV] [開発DEV] [経理DEV]
(10.1.2.0/24) (10.2.2.0/24) (10.3.2.0/24)
|
「完璧だ！部署も環境も綺麗に分離されている。VPC Peeringで必要な部分だけ接続すれば、セキュアで管理しやすいネットワークの完成！」
6月15日：設計レビューでの楽観的承認
CTO： 「なるほど、各部署が独立していて良い設計ですね」
私： 「はい、VPC Peeringで必要な接続だけ行うので、セキュリティも万全です」
インフラ部長： 「IPアドレスの重複は大丈夫？」
私： 「プライベートIPアドレスなので、VPCが違えば重複しても問題ありません」
セキュリティ責任者： 「部署間の不要な通信は遮断できる？」
私： 「VPC Peeringは必要な部分だけ設定するので完璧に制御できます」
全員： 「承認します。2週間で構築してください」
実装開始：意気揚々とVPC作成
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
# 共有サービスVPC
gcloud compute networks create shared-vpc \
--subnet-mode=custom \
--project=shared-services
# 各部署VPC作成
for dept in sales dev finance; do
gcloud compute networks create ${dept}-vpc \
--subnet-mode=custom \
--project=${dept}-project
done
# 各環境VPC作成
for dept in sales dev finance; do
for env in prod staging dev; do
gcloud compute networks create ${dept}-${env}-vpc \
--subnet-mode=custom \
--project=${dept}-${env}-project
done
done
|
「順調だ。次はサブネット作成して、VPC Peeringで接続すれば完了」
第二章：地獄の始まり - IPアドレス重複の悪夢
6月20日：構築作業の開始
VPC Peeringの設定開始：
1
2
3
4
5
6
7
8
9
10
11
12
|
# 共有サービス → 各部署への接続
gcloud compute networks peerings create shared-to-sales \
--network=shared-vpc \
--peer-project=sales-project \
--peer-network=sales-vpc
gcloud compute networks peerings create shared-to-dev \
--network=shared-vpc \
--peer-project=dev-project \
--peer-network=dev-vpc
# ... 以下同様に12個のPeering作成
|
最初の警告サイン：
1
2
3
|
WARNING: Peering 'shared-to-sales' created, but route may conflict
WARNING: Multiple routes to 10.0.0.0/16 detected
WARNING: Possible routing loop detected
|
「警告が出てるけど、まあ大丈夫でしょ。テストで問題なければOK」
6月22日：最初の接続テスト
共有AD（10.0.1.10）への接続テスト：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
# 営業PROD環境から
ping 10.0.1.10
# PING 10.0.1.10: 56 data bytes
# ping: cannot resolve 10.0.1.10: Unknown host
# 開発PROD環境から
ping 10.0.1.10
# PING 10.0.1.10: 56 data bytes
# ping: sendto: No route to host
# 経理PROD環境から
ping 10.0.1.10
# PING 10.0.1.10: 56 data bytes
# Request timeout for icmp_seq 0
|
「あれ？全然つながらない…」
ルーティングテーブルの確認で愕然
1
2
3
4
5
6
7
8
|
# 共有サービスVPCのルーティングテーブル
gcloud compute routes list --project=shared-services
NAME NETWORK DEST_RANGE NEXT_HOP
shared-vpc-route shared-vpc 10.0.0.0/16 shared-vpc
sales-peer-route shared-vpc 10.1.0.0/16 peering-sales
dev-peer-route shared-vpc 10.2.0.0/16 peering-dev
finance-peer-route shared-vpc 10.3.0.0/16 peering-finance
|
営業部VPCのルーティングテーブル：
1
2
3
4
5
6
7
8
|
gcloud compute routes list --project=sales-project
NAME NETWORK DEST_RANGE NEXT_HOP
sales-vpc-route sales-vpc 10.1.0.0/16 sales-vpc
shared-peer-route sales-vpc 10.0.0.0/16 peering-shared
sales-prod-route sales-vpc 10.1.0.0/24 peering-prod
sales-stg-route sales-vpc 10.1.1.0/24 peering-staging
sales-dev-route sales-vpc 10.1.2.0/24 peering-dev
|
「あ…これヤバイ…ルーティングがめちゃくちゃになってる」
6月23日：問題の本質が判明
深夜のデバッグで発見した根本的問題：
1. IPアドレス設計の致命的欠陥
実際の各環境のIPアドレス割り当て：
1
2
3
4
5
6
7
8
9
10
11
|
営業部門:
├─ sales-vpc: 10.1.0.0/16 (部署メイン)
├─ sales-prod: 10.1.0.0/24 (本番環境) ← 重複！
├─ sales-staging: 10.1.1.0/24 (ステージング)
└─ sales-dev: 10.1.2.0/24 (開発環境)
開発部門:
├─ dev-vpc: 10.2.0.0/16 (部署メイン)
├─ dev-prod: 10.2.0.0/24 (本番環境) ← 重複！
├─ dev-staging: 10.2.1.0/24 (ステージング)
└─ dev-dev: 10.2.2.0/24 (開発環境)
|
問題： 各部署のメインVPCと本番環境VPCでサブネットが重複
2. VPC Peeringのルーティング制限
VPC Peeringは「transitive（推移的）」ではない：
1
2
3
|
営業PROD → 営業VPC → 共有VPC → 開発VPC → 開発PROD
↑_________________________↑
この経路での通信は不可能
|
営業PRODから開発PRODに直接通信したい場合、別のPeeringが必要
3. ルーティングループの発生
1
2
3
4
|
パケットの迷子ルート:
10.1.0.10 → sales-vpc → shared-vpc → sales-prod → sales-vpc → ...
↑__________________|
永続ループ
|
「これ完全に設計ミスだ…」
第三章：6月24日 - システム全停止の悪夢
午前9時：本番稼働開始の予定
予定していた移行スケジュール：
- 09:00: 新ネットワーク環境稼働開始
- 10:00: 各部署システムの接続確認
- 11:00: 業務開始
午前9時15分：最初のアラート
1
2
3
4
5
6
|
🚨 Monitoring Alert
Subject: [CRITICAL] Active Directory Authentication Failed
Body: Multiple authentication failures detected
- sales-prod: Cannot reach domain controller
- dev-prod: Authentication timeout
- finance-prod: LDAP connection failed
|
すべての部署で認証システムが機能不全
午前9時30分：問題の連鎖開始
営業部から緊急の電話：
「顧客管理システムにログインできません！今日大事な商談があるのに！」
開発部からSlack：
1
2
3
|
開発部長: 本番システムにデプロイできない
開発部長: 監視システムも見えない状態
開発部長: 何が起きてるの？
|
経理部から内線：
「給与システムと会計システムが全部エラーです。今日は月末締切日ですよ！」
午前10時：緊急対策会議
参加者：
- CTO
- 各部署責任者
- インフラチーム全員
- 外部コンサル（緊急召集）
CTO： 「状況はどうなってる？」
私： 「VPC Peeringの設計に問題があって、ルーティングが正常に動作していません」
営業部長： 「いつ復旧するの？今日は大型案件のプレゼンがあるんだよ！」
私： 「調査中です…早急に…」
開発部長： 「ステージング環境も死んでるから、本番修正もできない状態」
CTO： 「一旦、全部を元の環境に戻せないのか？」
私： 「元の環境はもう廃棄して…戻せません…」
一同： 「……」（絶望的な沈黙）
午前11時：緊急チーム結成
作業分担：
- 私：ネットワーク構成の緊急見直し
- ネットワークエンジニア2名：既存Peeringの調査・修正
- システムエンジニア3名：各システムの影響調査
- 外部コンサル2名：代替ソリューションの検討
午後1時：応急処置の試行
とりあえずの修正案：
1
2
3
4
5
6
7
8
9
10
|
# 重複IPアドレスの緊急修正
# sales-prod: 10.1.0.0/24 → 10.1.10.0/24
gcloud compute networks subnets create sales-prod-new \
--network=sales-prod-vpc \
--range=10.1.10.0/24
# dev-prod: 10.2.0.0/24 → 10.2.10.0/24
gcloud compute networks subnets create dev-prod-new \
--network=dev-prod-vpc \
--range=10.2.10.0/24
|
結果：
1
2
3
4
|
ERROR: Cannot delete subnet 'sales-prod-subnet'
ERROR: 15 instances still attached to subnet
ERROR: Database instances cannot be moved to different subnet
ERROR: Load balancer configuration requires subnet recreation
|
「IPアドレス変更するには、全インスタンス再作成が必要…これは数日かかる」
午後3時：代替案の検討
外部コンサルからの提案：
案1：VPC Peering構成の最適化
- 時間：1-2日
- リスク：ルーティング問題が完全解決するか不明
- 影響：全システム再構築必要
案2：Private Service Connect（PSC）への移行
- 時間：2-3日
- リスク：新技術なので不確定要素あり
- 影響：共有サービスのみ再構築
案3：完全ロールバック（元環境の再構築）
- 時間：1週間
- リスク：低
- 影響：移行プロジェクト完全振り出し
「どれも地獄だ…」
午後4時：PSC移行の決断
判断理由：
- 最も根本的解決につながる
- 将来的な拡張性が高い
- 共有サービスのみの変更で済む
CTO承認：
「PSCで行く。48時間以内に復旧させる」
第四章：地獄の2日間 - PSC緊急移行
6月24日午後5時：PSC移行作業開始
Private Service Connectとは：
- サービス提供者と消費者を安全に接続
- IPアドレス重複を回避
- 推移的ルーティング問題を解決
- より細かいアクセス制御が可能
Step 1：共有サービスをPSCサービス化
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
# Active DirectoryサービスのPSC設定
gcloud compute service-attachments create ad-service \
--region=asia-northeast1 \
--producer-forwarding-rule=ad-forwarding-rule \
--connection-preference=ACCEPT_AUTOMATIC \
--nat-subnets=ad-psc-subnet
# DNSサービスのPSC設定
gcloud compute service-attachments create dns-service \
--region=asia-northeast1 \
--producer-forwarding-rule=dns-forwarding-rule \
--connection-preference=ACCEPT_AUTOMATIC \
--nat-subnets=dns-psc-subnet
# 監視サービスのPSC設定
gcloud compute service-attachments create monitoring-service \
--region=asia-northeast1 \
--producer-forwarding-rule=monitoring-forwarding-rule \
--connection-preference=ACCEPT_AUTOMATIC \
--nat-subnets=monitoring-psc-subnet
|
Step 2：各部署VPCからのPSCエンドポイント作成
1
2
3
4
5
6
7
8
9
10
11
12
|
# 営業部からADサービスへの接続
gcloud compute addresses create sales-ad-psc-ip \
--region=asia-northeast1 \
--subnet=sales-psc-subnet \
--project=sales-project
gcloud compute forwarding-rules create sales-ad-endpoint \
--region=asia-northeast1 \
--network=sales-vpc \
--address=sales-ad-psc-ip \
--target-service-attachment=projects/shared-services/regions/asia-northeast1/serviceAttachments/ad-service \
--project=sales-project
|
6月24日午後11時：最初のPSC接続テスト
1
2
3
4
5
|
# 営業環境からADへの接続テスト
ping 10.1.100.10 # PSCエンドポイントIP
# PING 10.1.100.10: 56 data bytes
# 64 bytes from 10.1.100.10: icmp_seq=0 ttl=64 time=2.3 ms
# 64 bytes from 10.1.100.10: icmp_seq=1 ttl=64 time=1.8 ms
|
「お！つながった！」
6月25日午前3時：各部署での設定変更
各システムでの接続先変更：
1
2
3
4
5
6
7
8
9
10
11
12
|
# 営業システムの設定変更
# /etc/ldap/ldap.conf
URI ldap://10.1.100.10/ # PSCエンドポイント経由
BASE dc=company,dc=local
# 開発システムの設定変更
# /etc/sssd/sssd.conf
ldap_uri = ldap://10.2.100.10/ # 開発部用PSCエンドポイント
# 経理システムの設定変更
# application.properties
ldap.server.url=ldap://10.3.100.10/ # 経理部用PSCエンドポイント
|
6月25日午前6時：システム接続確認
各部署での動作テスト：
1
2
3
4
5
6
7
8
9
10
11
12
13
|
# 営業部システム確認
systemctl status sales-app
● sales-app.service - Sales Management Application
Loaded: loaded
Active: active (running)
Status: "Connected to AD via PSC endpoint"
# 開発部システム確認
kubectl get pods -n production
NAME READY STATUS RESTARTS AGE
api-server-7d4f8b9c 1/1 Running 0 2h
database-proxy-5c7d9 1/1 Running 0 2h
monitoring-agent-3x8k 1/1 Running 0 2h
|
「各システムが正常に動作している…」
6月25日午前8時：業務再開確認
各部署からの報告：
営業部：
1
2
3
|
営業部長: 顧客管理システム正常です
営業部長: メール・カレンダーも復旧
営業部長: 今日のプレゼンに間に合いました！
|
開発部：
1
2
3
|
開発部長: 本番・ステージング環境とも正常
開発部長: CI/CD パイプライン復旧
開発部長: 監視システムも問題なし
|
経理部：
1
2
3
|
経理部長: 給与・会計システム復旧
経理部長: 月末締め処理開始できます
経理部長: お疲れ様でした！
|
「やった…全部復旧した…」
第五章：事後分析と学んだ教訓
復旧後の安定稼働
PSC移行後1週間の監視結果：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
ネットワーク接続状況:
- 接続成功率: 99.98%
- 平均レスポンス時間: 1.2ms（従来2.5ms）
- エラー率: 0.02%（従来3.2%）
システム稼働状況:
- Active Directory認証: 100%成功
- DNS解決: 99.99%成功
- 監視システム: 全指標正常
部署間通信:
- 不要な部署間通信: 完全遮断
- 必要な共有サービスアクセス: 100%成功
- セキュリティポリシー: 完全適用
|
根本原因分析
1. 設計段階での認識不足
間違った理解：
1
2
3
|
× VPC Peeringは「簡単で万能」な接続方法
× IPアドレス重複は「VPCが違えば問題なし」
× ルーティングは「自動で最適化される」
|
正しい理解：
1
2
3
|
○ VPC Peeringは特定の用途に適した接続方法
○ IPアドレス設計は全体像を考慮して慎重に
○ ルーティングは明示的に設計・管理が必要
|
2. 各接続方式の適用場面の理解不足
VPC Peering 適用場面：
1
2
3
4
5
6
7
8
9
10
11
|
適している場合:
- 同一組織内の直接接続
- フルメッシュ接続が必要
- 低遅延・高スループット要求
- 管理コスト最小化
適していない場合:
- 複雑なハブ・スポーク型
- サービス提供・消費関係
- 細かいアクセス制御要求
- IPアドレス重複環境
|
PSC 適用場面：
1
2
3
4
5
6
7
8
9
10
11
|
適している場合:
- サービス提供・消費関係
- 複雑なマルチテナント環境
- IPアドレス重複がある
- 細かいアクセス制御が必要
適していない場合:
- シンプルな直接接続
- 低遅延が最重要
- 設定・運用コストを最小化
- プロトコルレベル制御不要
|
3. テスト・検証プロセスの不備
実施すべきだった検証：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
## ネットワーク設計検証チェックリスト
### 設計段階
- [ ] IPアドレス重複チェック
- [ ] ルーティングテーブル設計
- [ ] 接続可能性マトリクス作成
- [ ] セキュリティポリシー定義
### 実装段階
- [ ] 段階的構築（1VPCずつ）
- [ ] 各段階での接続テスト
- [ ] 負荷テスト・障害テスト
- [ ] ロールバック手順確認
### 稼働前テスト
- [ ] 全システム接続確認
- [ ] パフォーマンス測定
- [ ] セキュリティテスト
- [ ] 運用手順確認
|
改善された最終設計
PSCベースのハブ・スポーク型：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
[共有サービス VPC]
(Service Producer)
┌─ AD Service (PSC)
├─ DNS Service (PSC)
└─ Monitor Service (PSC)
↑
PSC Service Attachment
↑
┌─────────────────────┼─────────────────────┐
↓ ↓ ↓
[営業VPC] [開発VPC] [経理VPC]
PSC Endpoint PSC Endpoint PSC Endpoint
├─ AD: 10.1.100.10 ├─ AD: 10.2.100.10 ├─ AD: 10.3.100.10
├─ DNS: 10.1.100.11 ├─ DNS: 10.2.100.11 ├─ DNS: 10.3.100.11
└─ Mon: 10.1.100.12 └─ Mon: 10.2.100.12 └─ Mon: 10.3.100.12
|
メリット：
- IPアドレス重複問題の解決
- 部署間の完全分離
- 細かいアクセス制御
- 推移的ルーティング問題の解決
- 将来的な拡張性
コスト比較
VPC Peering vs PSC：
| 項目 |
VPC Peering |
PSC |
差額 |
| 接続料金 |
無料 |
$0.01/時間/接続 |
+$2,600/年 |
| データ転送 |
標準料金 |
標準料金 |
同額 |
| 運用工数 |
高（複雑な管理） |
低（シンプル） |
-$50,000/年 |
| 障害対応 |
高（今回の事例） |
低 |
-$100,000/年 |
| 総コスト |
高 |
低 |
-$147,400/年 |
「PSCの方が結果的に大幅にコスト削減になった」
第六章：他の組織への教訓
VPC接続方式選択フローチャート
1
2
3
4
5
6
7
8
9
10
11
|
ネットワーク接続要件
↓
┌─ IPアドレス重複あり？ ─ YES → PSC検討
│ ↓ NO
├─ サービス提供・消費？ ─ YES → PSC推奨
│ ↓ NO
├─ 複雑な制御が必要？ ─ YES → PSC またはProxy検討
│ ↓ NO
├─ 超低遅延が必要？ ─ YES → VPC Peering推奨
│ ↓ NO
└─ シンプルな直接接続？ ─ YES → VPC Peering可能
|
設計時のチェックポイント
1. IPアドレス設計
1
2
3
4
5
6
7
8
9
10
11
12
|
# IPアドレス重複チェックスクリプト例
#!/bin/bash
echo "=== IP Address Overlap Check ==="
for vpc in $(gcloud compute networks list --format="value(name)"); do
echo "VPC: $vpc"
gcloud compute networks subnets list --network=$vpc \
--format="table(name,ipCidrRange)" --sort-by=ipCidrRange
echo ""
done
# 重複チェックロジック
python3 check_ip_overlap.py --vpc-list=vpc_list.txt
|
2. ルーティング設計
1
2
3
4
5
6
7
8
9
10
11
12
|
# ルーティングテーブル可視化
gcloud compute routes list --format="table(
name,
destRange,
nextHopInstance,
nextHopVpnTunnel,
nextHopPeering,
priority
)" --sort-by=destRange
# ルーティングループ検出
./detect_routing_loops.sh
|
3. 接続テスト自動化
1
2
3
4
5
6
7
8
9
10
11
12
13
|
# 接続テスト自動化（Cloud Build）
steps:
- name: 'gcr.io/cloud-builders/gcloud'
script: |
# 各VPCからの到達性テスト
for source_vpc in sales-vpc dev-vpc finance-vpc; do
for target_service in ad-service dns-service; do
echo "Testing $source_vpc -> $target_service"
gcloud compute ssh test-vm --zone=asia-northeast1-a \
--project=${source_vpc}-project \
--command="nc -zv ${target_service}.internal 389"
done
done
|
運用での注意事項
1. PSC運用のベストプラクティス
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
PSC運用ガイドライン:
監視対象:
- エンドポイント接続状況
- サービス健全性
- データ転送量・料金
アラート設定:
- 接続失敗率 > 1%
- レスポンス時間 > 5秒
- 月間コスト 予算の80%超過
定期作業:
- 月次接続状況レポート
- 四半期コスト最適化レビュー
- 半期セキュリティ監査
|
2. 緊急時対応手順
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
## PSC障害時対応フローチャート
### Level 1: エンドポイント障害
1. 他のエンドポイントへの切り替え
2. サービス提供者への連絡
3. 利用者への影響範囲通知
### Level 2: サービス提供者障害
1. バックアップサービスへの切り替え
2. 緊急時VPC Peeringの有効化
3. 復旧作業の開始
### Level 3: 全面障害
1. オンプレミス環境への切り戻し
2. 事業継続計画の実行
3. 外部サポートの要請
|
まとめ：「簡単な接続」という幻想からの脱却
プロジェクトの総括
被害総額：
- システム停止による機会損失: ¥15M
- 緊急対応作業費: ¥5M
- 外部コンサル費: ¥3M
- PSC移行費用: ¥2M
総額: ¥25M
しかし得られた価値：
- 正しいネットワーク設計の習得: プライスレス
- PSC技術の深い理解: プライスレス
- チーム結束力の向上: プライスレス
- 障害対応能力の向上: プライスレス
最も重要な教訓
1. 「簡単」という言葉の危険性
技術者の典型的な思い込み：
「VPC Peeringはポチポチするだけでつながる → 簡単」
現実：
ネットワーク設計にはIPアドレス設計、ルーティング設計、セキュリティ設計、運用設計など、多層的な検討が必要。
2. 適切な技術選択の重要性
技術選択の原則：
- 要件を正確に理解する
- 各技術の特性を深く理解する
- 長期的な運用コストを考慮する
- 拡張性・保守性を重視する
3. 段階的実装とテストの価値
今回の失敗要因：
一気に全VPCを接続して動作確認
正しいアプローチ：
1VPCずつ段階的に構築し、各段階で十分にテスト
他のエンジニアへのメッセージ
ネットワーク設計は「簡単」に見えることが多いですが、実際は非常に奥が深く、一度設計ミスをすると修正が困難な領域です。
私からの3つのアドバイス：
-
「簡単」と思ったときこそ立ち止まる
- 本当に簡単なのか疑問を持つ
- 隠れた複雑さがないかチェックする
- 段階的なアプローチを検討する
-
技術選択は要件ベースで行う
- 流行りや見た目の簡単さで選ばない
- 長期的な運用を考慮する
- 複数の選択肢を比較検討する
-
失敗から学ぶことを恐れない
- 失敗は最高の学習機会
- チーム全体で知識を共有する
- 同じ失敗を防ぐ仕組みを作る
この記事が、同じような設計判断に直面するエンジニアの参考になれば幸いです。
そして、もし同じような失敗をしてしまっても、諦めずに改善し続けることで、必ずより良いソリューションに辿り着けることを信じています。
関連記事：
注意： この記事は実際のネットワーク障害経験に基づいていますが、具体的な組織名やシステム詳細は匿名化しています。
