GitHubが1月28日のサービス障害の詳細を公開。停電により内部のChatOpsシステムも落ちて初期対応が困難に。Redisクラスタの復旧に時間
GitHubが1月28日のサービス障害の詳細を公開。停電により内部のChatOpsシステムも落ちて初期対応が困難に。Redisクラスタの復旧に時間 報告では、サービス障害はGitHub社内のChatOpsシステムも巻き込んで初期対応に時間がかかってしまったこと、一時的な停電がRedisクラスタの障害を引き起こしたため、その究明と復旧が作業の主な部分だったことなどが説明されています。 報告の要点をまとめました。 内部のChatOpsシステムも障害に GitHubのサービス障害は、すでに報告されているように、自社データセンターにおける一時的な停電が最初の原因でした。 At 00:23am UTC on Thursday, January 28th, 2016 (4:23pm PST, Wednesday, January 27th) our primary data center experi
障害の事後分析を読んで得た教訓 ― 「何がシステムを停止させるのか？」 | POSTD
私はポストモーテム（事後分析）の記録を読むのが大好きです。ポストモーテムを読むと勉強になりますが、大抵の教材的資料とは違って、興味深いストーリーが含まれているのです。相当な時間をかけてGoogleとMicrosoftのポストモーテムを読みました。大きな障害を招く最大の原因について、私は（まだ）きちんと分析していませんが、何度も繰り返し目にするポストモーテムのパターンがいくつかあります。 エラーハンドリング 適切なエラーハンドリングのコードを書くのは難しいものです。エラーハンドリングのコードに含まれるバグは、 大きな 問題を引き起こす主な原因となっています。つまり、エラーによってバグのあるエラーハンドリングのコードが実行されるということは、単に個々のエラーが重なるだけという事態にはとどまらないのです。障害が重なって重大なシステム停止につながることはよくあります。それはある意味明らかなことで、
データセンター移転とDRBD - Cybozu Inside Out | サイボウズエンジニアのブログ
@ymmt2005 こと山本泰宇です。今回は去る 5 月から 6 月にかけて行った、cybozu.com のデータセンター移転作業について、失敗してしまったことを中心に解説します。 失敗と書いたのは、移転作業中に何度か、一部のお客様環境でストレージ高負荷による障害を起こしてしまったためです。移転作業自体はスケジュール通り進行し、6 月第二週に完了しています。障害に関しては、こちら（PDF）でお詫びとご報告をしていますが、この記事では技術面ならびに障害を引き起こすにいたった背景について詳述します。 移転に至った背景 移転方式の検討 ストレージ同期の方法 DRBD による同期の詳細 まずは自社環境を移転、成功 そして障害は発生した なぜ障害につながったのか まとめ 移転に至った背景 まず、なぜデータセンターを移転することにしたかを説明します。 端的に言うと、当時のデータセンターが手狭になり拡張
小規模Webサービス向け安上がりシステム構成と開発フロー（怖話.jp） - Fjord, Inc(株式会社フィヨルド)
こちらのエントリーが大変参考になったので、僕らが作ってる怖話.jp（kowabana.jp）のシステム構成や開発方法についても公開していこうと思います。 怖話.jpはスマホ向けWebサービスなのでPC向けとはPVとかの傾向がちょっと違うかも知れません。 怖話.jpとは スマホで17,000話以上のサウンドノベル風の怖い話が閲覧・投稿できるサイト（アプリではありません）です。詳しくは下記エントリーを参照してください。 スマホでサウンドノベル風怖い話投稿サイト | FJORD, LLC（合同会社フィヨルド） 7月16日にRubyKaigi2011に合わせて無理矢理ベータテストオープンして、8月9日に正式オープンしましたので正式オープンからは１ヶ月経ってないまだまだのサイトです。開発期間は約１ヶ月ぐらいです。 サイト情報 （これAnalyticsを直接貼るのはどうやればいいんだろう？） 直近一ヶ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
とあるアプリの開発運用(トラブルシュート)