Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
解消したはずが…技術と人間のエラーが交錯する恐怖体験
Search
Lamaglama39
July 29, 2025
Technology
0
210
解消したはずが…技術と人間のエラーが交錯する恐怖体験
Lamaglama39
July 29, 2025
Tweet
Share
Other Decks in Technology
See All in Technology
AIが住民向けコンシェルジュに?Amazon Connectと生成AIで実現する自治体AIエージェント!
yuyeah
0
260
あなたの知らない OneDrive
murachiakira
0
230
アジャイルテストで高品質のスプリントレビューを
takesection
0
110
kintone開発チームの紹介
cybozuinsideout
PRO
0
73k
自社製CMSからmicroCMSへのリプレースがプロダクトグロースを加速させた話
nextbeatdev
0
130
人と組織に偏重したEMへのアンチテーゼ──なぜ、EMに設計力が必要なのか/An antithesis to the overemphasis of people and organizations in EM
dskst
5
600
Postman MCP 関連機能アップデート / Postman MCP feature updates
yokawasa
0
140
株式会社ARAV 採用案内
maqui
0
340
Yahoo!ニュースにおけるソフトウェア開発
lycorptech_jp
PRO
0
330
イオン店舗一覧ページのパフォーマンスチューニング事例 / Performance tuning example for AEON store list page
aeonpeople
2
270
Gaze-LLE: Gaze Target Estimation via Large-Scale Learned Encoders
kzykmyzw
0
310
Webアクセシビリティ入門
recruitengineers
PRO
1
220
Featured
See All Featured
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
Optimizing for Happiness
mojombo
379
70k
Designing for humans not robots
tammielis
253
25k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.9k
Rebuilding a faster, lazier Slack
samanthasiow
83
9.1k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.6k
Unsuck your backbone
ammeep
671
58k
The World Runs on Bad Software
bkeepers
PRO
70
11k
Transcript
画像は Gemini 2.5 Flash で作成した サーバーのお化けです。
自己紹介 赤池 悠 (あかいけ はるか) 1998/07/29生まれ 所属:クラスメソッド株式会社 クラウド事業本部コンサルティング部 ブログ:https://dev.classmethod.jp/author/akaike/ Twitter:@lamaglama39
最近怖かった出来事: 自宅のProxmoxクラスターが突然めっちゃ不安定になっ て、私の心も不安定になりました。 (再起動したら直りました)
これは前職で私が 実際に経験したお話しです…。
私が担当していたシステム、および環境 • Direct Connectでの オンプレミス ↔ AWS 接続 • 複数システム共通VPC
+ AWSサービス別サブネット
その日私がやっていた作業 • 新規システム用のDirect Connect + AWSリソースの作成作業 • 人生初Direct Connectに胸を躍らせる
起きた事件。
それは唐突に起きました。 私が作業を完了させてから約 1時間後に既存のDirectConnectが突如ダウンし、 オンプレから既存システムへの通信がすべてダウン …。
それは唐突に起きました。 • 障害状況 ◦ 既存DirectConnectのステータスがダウン ◦ オンプレから既存システムへの疎通NG • 騒然とする現場 ◦
大量の障害検知に対応する運用部門 ◦ 各システムのアプリ担当者からの問い合わせ ◦ いつになく殺気立つPM (普段は仏) • 調査に駆り出される私 ◦ 直前でDirectConnectに関連する作業を実施していたため、逃れられない (別回線の作業だから俺は絶対関係ないだろ… と思いながら調査したのはここだけの秘密です。) ◦ AWSサポートにて電話しながらの調査実施
第1の障害原因 AWS Direct Connect ロケーション
第1の障害原因はなんだったのか。 「AWS Direct Connect ロケーション側の問題」により障害が発生していた。
無事解消するまでの話。 • AWSサポートとのやり取り ◦ 「AWS側での障害は確認していない」との回答 ◦ AWS上でそれらしい障害原因が見つからないため、 それ以上調査が進まない… • 回線事業者への問い合わせと連絡
◦ マネージャー陣によって別途回線事業者へ問い合わせ ◦ AWS Direct Connect ロケーション側で問題が発生していたことが判明 ◦ しばらくした後、Direct Connectのステータスがアップし、 回線事業者からも復旧の連絡があった ◦ オンプレから各システムへの疎通もOK
すべて解消した! そう思われていたが…。
障害はまだまだ終わらない…。 なぜか特定のサブネット上のリソースだけ、疎通が通らない …。
障害はまだまだ終わらない…。 • 障害状況 ◦ オンプレミスから特定のサブネットへの疎通だけ通らない ◦ それ以外のサブネットへは、正常に疎通できる • 疲弊し始める現場 ◦
ほっと一息ついた10分後には、おかわり障害対応 ◦ 困惑するPM • 引き続き調査に駆り出される私 ◦ これにより、ほぼまるまる1日の障害対応が確定 ◦ とりあえずネットワーク周りの設定から調査し始めた
第2の障害原因 ヒューマンエラー
第1の障害の裏側で起きていたこと。 エンジニア〇〇さんが、 新規システム向けにサブネットなどのリソースを作成していた。 (マネジメントコンソールから手動作業)
第1の障害の裏側で起きていたこと。 オンプレミス向けのRoute Tableは各サブネット共通で利用しており、 新規サブネットに関連づける際に、誤って既存のサブネットの関連付けを解除してしまった。
無事解消するまでの話。 • 調査方法 ◦ 問題のサブネットにルートテーブルが関連づけられていないことを確認 ◦ CloudTrail + Configにて、 該当のサブネットとルートテーブルの設定履歴を確認
• 解消方法 ◦ サブネットにルートテーブルを関連付け ◦ 無事疎通が通るようになり、障害解消
結論 人間が一番の単一障害点
どう対策するべきか。 • 作業プロセスの改善 ◦ 事前準備の強化 ▪ 作業前にシステム全体の依存関係を図式化し、影響範囲を明確化 ◦ 作業手順の標準化 ▪
チェックリスト形式の作業手順書を作成し、確認すべき項目を明文化 ▪ 重要な設定変更は、作業前後の状態を必ず記録
どう対策するべきか。 • 監視・検知体制の構築 ◦ 疎通確認の自動化 ▪ 各サブネットからオンプレミスへの疎通を定期的に自動チェック (スクリプト、Network Synthetic Monitorなど)
• 作業体制の見直し ◦ 複数人での相互確認 ▪ 重要なインフラ作業は必ず複数人でレビュー ▪ 設定変更前後の状態を相互確認する体制を作る ◦ 段階的作業とロールバック準備 ▪ 作業を小さな単位に分割し、各段階で動作確認を実施 ▪ 即座に元の状態に戻せるよう、作業前の設定を必ず保存
どう対策するべきか。 • 技術的な対策 ◦ Infrastructure as Code(IaC)の活用 ▪ TerraformなどのIaCを使用して設定を管理し、 手動での設定ミスを防止
▪ 変更履歴も自動的に管理 ◦ 作業時の権限の最小化 ▪ 作業に必要最小限の権限のみを付与 ▪ 重要な設定変更には承認フローを組み込む
ありがとうございました。 作業ミスに気をつけて、 用法用量を守って正しくAWSを利用しましょ う。