1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
  07 ,2017

ビジネス、心理、マーケティングを軸にいろいろなニュースや事象を分析します


プロフィール

なおゆき

Author:なおゆき
Web広告代理店でシステムエンジニアをしています。
セルフイメージはProblem Analyzer(問題を分析する人)。

このブログでは、IT を中心に
新ビジネスのニュースや現場でよくある問題について
分析します。

検索フォーム
ブロとも申請フォーム
QRコード
QRコード
--

Category: スポンサー広告

Tags: ---

 

スポンサーサイト
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

03

Category: 未分類

Tags: ---

Comment: 0  Trackback: 0

AWS の障害はなぜ起こったのか
この数日、肋骨を折って痛かったので、RSS でニュースのチェックをしていなかった。
5/2 に大体の流れは追えたので、ブログにまとめる。

クラウドコンピューティングの代表的なサービスである
Amazon Web Service が大障害を起こした。
で、非常によくまとまっている記事があったので貼り付けておく。
(これだけ詳細な記事を書いた記者を賞賛に値すると思う)

Amazon Web Servicesの障害はなぜ起こったのか

ざっくり言うと、人的な作業ミス+設計ミスということ。
僕のテケトーな理解でサマると以下のような感じ。

 ①スケールアウトのインフラ作業でミスした
 ②ネットワークの予備用リソースに自動で割り振っちゃった
  (おそらく、この動作は想定外)
  このリソースはメインではないので、比較的貧弱
 ③ネットワークがパンク

この事象を分析するには
①、②が埋め込まれた原因と検出できなかった原因について
ブレイクダウンできると思う。
質問にすると、こんな感じ。

 ①-1⇒なぜ、人的ミスが作業の中に埋め込まれたのか
 ①-2⇒なぜ、人的ミスを作業の中で防げなかったのか

 ②-1⇒なぜ、想定外の動作が埋め込まれたのか
 ②-2⇒なぜ、想定外の動作をテストで検出できなかったのか

Amazon の内部情報を知らないので、以降は一般論になる。

①-1 は作業手順書のレビュー、STG 環境(準本番環境)の手順の検証で防止する。
これができない原因として
 A. 現場への負荷が多すぎてレビューがザル
 B. 担当者が変わってしまっていてシステムを理解していない
 C. STG 環境と本番環境の構成が根本的に異なっている
ということがある。
(ええ、実体験ですとも。。)

①-2は、作業手順を順守することで守られる。
これができない原因として
 A. 手順のミスが作業中に発覚したが、
   変更した内容が間違っていた
 B. 上記に加えて変更した手順を立案した人と比べて
   他の担当者のシステム理解が貧弱すぎて何も言えない

②-1は、設計レビュー、コードレビューで防止する。
これができない原因として
 A. 新しいシステムの場合、想像できないことが多々ある
  (今回は多分これが大きい)
 B. 一般的に運用を経験していないプログラマは
  キャパシティまでは考えても、運用のしやすさを考慮に入れた
  システムを設計しない
  (ええ、実体験ですとも。。)

②-2 は、障害テストで防止する。
これができない原因として、
 A. 通常運用の中で起きる障害はテストするが、
   作業ミスについてテストすることはない
 B. 二次障害はサポート対象外にすることが多い
  (コスト的にテストしきれない)


①-1, 2 は本来どこの会社でも対策をとらなくてはいけないものだと思う。
AWS の障害報告の原文は読んでいないが、これがかけてないかな。

②-1, 2 は新しいサービスでは非常に難しい。
テクノロジーのロードマップを引いて、古い資産を捨てて、
よりよいサービスを提供する仕組みを考えて行かないといけない。
さもなくば、古い資産は負債に成り下がる。(ある意味、ゆでガエル)
スポンサーサイト

テーマ : 気になるニュース    ジャンル : ニュース

Comments

Leave a Comment

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。