ウィルス感染でWebサービスが20日間ダウン。本当にごめんなさい - Qiita
障害が起きたWebサービスは個人で運営しているサービスです。 2016年2月、障害から20日後にサービス再開しましたがアクティブユーザは以前の18%です。未だ回復の目処は立っていません。冗長化していないサーバがウイルス感染し、その後の対応も後手後手に回ってしまいました。 2016年1月末に起こるべくして起こった障害について記事にしてみました。ご迷惑をお掛けしてしまい本当に申し訳ありません。 ■ ユーザは、もう戻ってこない どんなウイルスに感染したのか SYNフラッド攻撃（SYN Flood Attack）を他のWebサイトに行うウイルスに感染して、確認していませんが他のサービスをSYNフラッド攻撃していたと思います。またウイルス感染時にサーバのsshdを書き換えられsshで接続できなくなりました。感染後にコンソールログインして書き換えられた醜い authorized_keys を見た時ゾッ
続・Web系の自分が想像と障害で学んだバッチ処理・設計の基本 - コンポツさん
バッチ処理というのがそれ単体で勉強するのが難しく勉強しようとすると何に手を付けるべきかさっぱりわからないということは、先日のブログで述べたとおり。 自分が経験の中で得てきた知見は正しいのかどうか、世間の人に見てもらいたかったというのが書いた動機。 そして、新たな視点や指摘をゲットしてより不測の事態を考慮できている最高なバッチを作りたいという目的があったわけだ。 で、いろいろな意見をもらったのだけどその中で特に辛いと感じたのはこれ。 基幹システムにおけるバッチ処理みたいなものに関する知見については、カジュアルに学ぶ方法はありません。それを体系化した知識として整理した上で、実装できる組織があるんなら、それでメシが食えるんじゃないですかね。— 太一 (@ryushi) 2016, 2月 18 読んでいると 「俺達は障害でつらい思いをしてるし当然先人達も障害でつらい思いをしているはずだ。 なのに、
マイクロサービスにおける障害と Failurewall - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? マイクロサービスにおける障害と Failurewall こちらは Scala Advent Calendar 2015 25日目の記事です。 Scalist の皆さん、一年間お疲れさまでした。 当記事の目的はマイクロサービス(に限らないですが)における失敗の怖さについて説明することと、それを克服するためのライブラリ、Failurewall を紹介することです。 障害は怖い 障害の連鎖 現代的な Web アプリケーションは多くの依存を抱えています。MySQL のようなデータベースに依存することもあれば、Twitter API のような外部
AWS大規模障害を乗り越えたNetflixが語る「障害発生ツールは変化に対応できる勇気を与えてくれる」 | さくらのナレッジ
このコラムのNetflixの「FIT（障害注入テスト）」について書いた記事を執筆した直後のことですが、Netflixのサービスをある災害が襲いました。AWS（Amazon Web Services）のus-east-1リージョン全体で大規模障害が発生したのです。 この大規模障害を同社がどのように乗り切ったか。その一部が以下のBlog記事で明かされています。 Chaos Engineering Upgraded 「AWSリージョンが落ちることはめったにない。だが、それは実際に起こった」と記事では語っています。2015年9月20日、US-EAST-1リージョンのAmazonのDynamoDBサービスが、問題が発生して停止します。これは20以上のAWSサービスに影響を及ぼしました。その影響により、AWSをインフラとする複数のインターネットサービスが6〜8時間にわたってダウンしてしまったのです。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
