エンジニアなら知っておきたい障害報告&再発防止策の考え方 - Qiita
システムには障害がつきものです。どんなにしっかりと作られたサービスであっても思わぬところで、バグやミスが発覚して、トラブルになるものです。大事なのはこういった障害を次への糧にしていくこと。失敗というのは大事な資産なので、管理できるようにしましょうという話。 あわせて読みたい あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ メンタリングの方法について基礎をまとめました。内心でなく行動を変えることが障害報告とも共通します。 新入社員が来てメンターになれって言われたけど、どうすればいいのかという対話テクニック 半年で40kg痩せた！ダイエットでわかるリーンなプロジェクトマネジメント手法 心理的安全性ガイドライン（あるいは権威勾配に関する一考察） 障害の種類と障害報告について 障害には、小さなもの、たとえば画面に表示されているテキストの乱れから、すべての画面で50xエラーが発生
Dropboxが2日以上ダウン。原因はメンテナンス用スクリプトのミス
オンラインストレージサービスのDropboxが、米国時間1月10日の午後から約2日間にわたって障害を引き起こしていました。直接の原因は、OSをバージョンアップするために実行したメンテナンス用スクリプトにバグがあったことです。 障害の状況を時系列で追いつつ、原因についての報告を見てみましょう。 約48時間続いた復旧作業 障害の状況報告については、Dropbox Tech Blogの「Dropbox Status Update」でまとめられています。ポイントごとに引用し、訳しました。 障害発生が認識されたのは、米太平洋時間の午後6時40分です。後になって分かるのですが、この日の5時半に障害の原因となったメンテナンスが始まっています。それから1時間後にDropboxのダウンが発覚します。 1/10 at 6:40pm PT: We are aware that the Dropbox site
TwilioのRedisによる決済サービスの障害、2つの原因 - unknownplace.org
Twilio というサービスで決済サービスの障害があったらしいが、恐しいことにこのサービス、 決済情報をRedisで管理していたらしい、というのをRedis作者、antirez氏のblogで知った。 Twilio incident and Redis - Antirez weblog この件に関しては、Twilio自体も 調査報告 を出している。簡単にまとめるとこういう感じだ: TwilioではRedisを single-master, multi-slave なレプリケーション環境で使用している ネットワーク障害で一時的に master-slave 間の接続が切れたことにより、master-slave間のデータの再同期が発生 この再同期がすべてのslaveに対して同時に発生したため、masterの負荷が高くなり、結果決済サービスの障害が発生 この負荷を解決するためmasterを再起動する
データセンター移転とDRBD - Cybozu Inside Out | サイボウズエンジニアのブログ
@ymmt2005 こと山本泰宇です。今回は去る 5 月から 6 月にかけて行った、cybozu.com のデータセンター移転作業について、失敗してしまったことを中心に解説します。 失敗と書いたのは、移転作業中に何度か、一部のお客様環境でストレージ高負荷による障害を起こしてしまったためです。移転作業自体はスケジュール通り進行し、6 月第二週に完了しています。障害に関しては、こちら（PDF）でお詫びとご報告をしていますが、この記事では技術面ならびに障害を引き起こすにいたった背景について詳述します。 移転に至った背景 移転方式の検討 ストレージ同期の方法 DRBD による同期の詳細 まずは自社環境を移転、成功 そして障害は発生した なぜ障害につながったのか まとめ 移転に至った背景 まず、なぜデータセンターを移転することにしたかを説明します。 端的に言うと、当時のデータセンターが手狭になり拡張
2012年1月から全社員2万6000人がGmailに移行
ソフトバンクグループでGoogle Appsの導入を担当した内山敏氏、諸岡みどり氏、津乗伸治氏（左から） ソフトバンクグループの通信3社（ソフトバンクモバイル、ソフトバンクテレコム、ソフトバンクBB）は2011年末までに、約2万6000人の全社員が使う社内メールシステムを米グーグルのクラウドコンピューティングサービス「Google Apps（Gmail、キーワード解説記事）」に全面移行する。日本企業が社内向けにGmailを活用する事例は他にもあるが（関連記事1、関連記事2）、ソフトバンクの導入は最大規模になる。 全社員への導入を円滑に進めるため、まず2011年2月から、営業担当者を中心とした約2000人を対象にパイロット導入している。その後、順次利用対象を拡大し、2011年10月から全社員約2万6000人の利用を開始。12月末までの3カ月間は、自社のデータセンターで運用している従来のメール
(新人向け) Unixオペレーションの注意点 - Magical Diary
主に新人向けとして、Unixサーバで作業をする際の注意点を書いておく。 ここに書いてある内容は絶対的なものではないし、会社や現場ごとにルールがあるので、適宜ルールに合わせて実践すれば良い。 ログを取れ 何をやったか、何をやらなかったか、というエビデンスのためにログは必ず残しておく。SSHクライアントによっては毎回自動的にログ取得する設定が可能なので、設定しておくと良いだろう。 作業後に問題が発生した場合に作業内容を確認するためにも使うため、必ずログは取得しておくこと。 (追記) 当たり前だが、コマンドとその出力をペアで取ることに意味がある。 set -x (set verbose) しろ ログを取得しても、コマンドラインを編集した際には以下のように非常に見づらいものとなってしまう。(がんばれば解析することは出来るが…) ESC[0mESC[27mESC[24mESC[JESC[1myasu
HowToMakeAlmostAnything2010
How to Make (Almost) Anything (ほぼ何でもつくる方法) 2010年度 体験記 田中浩也 /慶應義塾大学環境情報学部准教授・マサチューセッツ工科大学客員研究員・ファブラボジャパン MITメディアラボでは、ニール・ガーシェンフェルド教授による人気講座「How to Make (Almost) Anything (ほぼ何でもつくる方法)」が毎年秋学期に開講されている。 ニール・ガーシェンフェルドは、当初このクラスを、ごくごく少数の大学院生に、研究に使うための３次元プリンタ、カッティングマシン、ミリングマシン等、 機材の利用方法を教えるための演習として考案したという。しかしながら、初年度、初回授業の教室に行って彼は驚いた。MITの内外から１００名を越える人 々が押し寄せ、「こういう授業をずっと待っていたんだ」「お願いだから受講させてください」と口々に嘆願されたというの
googleで賢く探すために最低知っておくべき５つのこと／検索テクニック、ノウハウ、裏技の手前に
検索オプションや演算子の紹介や「辞典になる」「電卓になる」みたいな機能紹介は省く（これについては、googleのヘルプか、たとえばここhttp://search.web-sun.com/g_help.htmlを参照）。 以下では、基本の考え方と、それを受けて、では具体的にどう検索するかを、いくつかの事例をつかって簡単に説明する。 どれも知っている人には当たり前のことばかりだが、このあたりのことをまとめたものは意外に少ないようなので、メモ代わりになるようにまとめてみた。 まとめたのは最低限のものであって、取り上げるべき事項は他にもいろいろあるだろうが、簡素なのがウリということで。 考え方は、googleで検索するときだけでなく、調べもの全般に用いることができると思う。 １．（基本）「○○について××が知りたい」→検索語「○○ ××」 ［例］富士山の高さが知りたい （考え方） →富士山の高さが
国勢調査のシステムはセールスフォースのクラウド採用。開発期間は数週間（修正あり） － Publickey
5年に一度、国が行う国勢調査がはじまっています。 その国勢調査の内部作業を行う業者を支援するためのシステムが、セールスフォース・ドットコムのクラウドによって構築されていることが同社社長 宇陀栄次氏のツイートで明らかになりました。 はい、仰る通りです。パートナー様経由ですが。使ったら、次は5年後ですし、バックアップも災害対策も無料で、開発期間も数週間です。RT @tera3pokole: @udaeiji 今回の国勢調査のシステムも御社が請け負われたのでしょうか。less than a minute ago via Echofon宇陀栄次 udaeiji この記事では当初、セールスフォース・ドットコムのシステムが東京都をモデル地域として行われた国勢調査のオンライン回答に使われたものと書きましたが、間違いでした。オンライン回答のデータはセールスフォース・ドットコムは使われておらず、データも国内
［速報］mixiが障害の経緯を発表。原因はお盆のアクセス急増ではなく、memcachedの異常終了
8月10日の17時20分頃から12日未明までの長時間にわたり、サービスが利用不能もしくは利用しにくい状況になっていた「mixi」。数度の断続的な復旧ののちに、本日12日午前1時50分頃には復旧が完了し、現時点で全面的に復旧しているようです。 その障害の経緯について株式会社ミクシィの広報からプレスリリース「『mixi』のアクセス障害のお詫び及び復旧に関するお知らせ」として発表されました。 原因はアクセスの急増ではなかった プレスリリースの中で、今回の障害の原因は以下のように説明されています。 『mixi』のデータベースへの負荷軽減のために導入しているデータキャッシュシステムが複数同時に異常終了したことに伴い、データベースへの負荷が急増したため『mixi』を閲覧しづらい状態となりました。 高負荷かつ特殊な状態でのみデータキャッシュシステムの異常終了が発生していたため、根本的な原因の究明に時間が
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
超慎重派の私がうっかりハンコを押してしまった、太陽光発電訪問販売の巧妙な手口