InfoQ ホームページ Failure に関するすべてのコンテンツ
-
Netflixは218台のCassandraノード再起動にどう対処したのか
Amazonは9月末，メジャーアップデートメンテナンスを実施した。同社クラウドサーバ群のおよそ10%に影響する，Xenハイパーバイザのセキュリティ上の脆弱性に対するパッチの実施が目的だ。今回のアップデートではそれらのサーバを再起動する必要があったため，結果的に同社の最大顧客であるNetflixを含むAWSユーザ，およびその提供するサービスに影響が及んだ。
-
組織の機能不全に目をつぶることはスクラムマスターの失敗につながる
多くの組織でスクラムマスターが失敗する理由は、スクラムの導入と組織の機能不全に取り組むスクラムマスターの責務の認識不足である、Bob Marshall氏はそう説明する。
-
早く失敗することは早く学ぶこと
早く失敗する，何度も失敗する，ということは，アジャイルチームに推奨されるプラクティスのひとつだ。"This is Agile"の著者であるSander Hoogendoorn氏はブログで，プロジェクトの早い段階において失敗予測に基づく放棄を決定するための，有効な戦略を持つことの重要性を論じている。
-
リーンスタートアップが投資家と付き合うには
リーンスタートアップを採用する起業家たちも，ビジネス資金の調達に投資家の協力を得ることがある。しかしリーンスタートアップで起業するビジネスプランには，従来の起業スタイルとは異なる部分が多い。また，失敗から学ぶ，ピボット(pivot, 路線変更)する，といった行動を重視するリーンスタートアップは，投資家から敬遠される可能性もある。起業家と投資家が一緒になって，資金調達にリーンスタートアップアプローチを使うことはできるのだろうか？
-
持続可能なリーンスタートアップチームに必要な態度
Ramli John氏は2013 Lean Startup Conferenceでminimum viable attitudes for lean startup teamsと題した講演を行った。氏によれば、チームが持続可能なリーンを行うためには、3つの態度が必要だ。すなわち、謙遜、飢餓感、幸福だ。
-
Simian Armyを使わないPagerDutyの復元性テスト
PagerDutyのDoug Barth氏が，特別な自動化作業を前もって用意することなくシステムの復元性テストを開始するという，同社で実施したアプローチについて，DevOps Days Londonで講演した。目標としたのは障害発生点の早期発見と，１週間に１時間の時間枠を設けて，その対処方法についてオープンに議論することだ。
-
リーンスタートアップで失敗から学ぶ
リーンスタートアップは望ましい製品を顧客に素早く提供し、顧客のニーズを理解する方法だ。リーンスタートアップは失敗を調べ、失敗から学ぶ��リーンスタートアップを実践することで素早く学びより優れたイノベーターになれるのだ。また、リーンスタートアップの手法を教育に利用しているトレーナーもいるので、生徒は学習を早めることができる。
-
クラウドサービス障害発生時にサービスを維持するには
先週、AWSの障害がいくつかの大規模サイトを襲った。どうすればサービス停止を避けられるのだろうか。スケールする以外にもフェールオーバーを実現する方法はある。
-
恐怖の中でのアジャイルの導入
アジャイルを導入し、チームを変えるのは、効果的な場合もあるし、そうでない場合もある。失敗には共通の特徴があるだろうか。恐怖は関係するだろうか。恐怖に満ちた環境てアジャイルを導入する場合、どんな事態が待ち受けているか。
-
-
商業的関心が失敗を隠す
Philippe Kruchten氏がアジャイルについて次ように述べている。"アジャイルの運動はティーンエイジャーに似ています。自己中心的で、鏡ばかり見ていつも外見を気にしていて、批判は受け付ず..."。氏は12の口に出しにくいことを列挙する。意図的に避けられている言いにくい問題だ。第一に挙げられているのは、商業的関心が失敗を隠してしまうことだ。
-
Amazon EC2 障害の詳細とその教訓
Amazon は米国東部リージョンのアベイラビリティゾーンで発生したサービス障害に関する詳細な報告書を発表した。その分析や論評，今回の出来事から学ぶべき教訓などの話題で，オンラインメディアは持ちきりだ。
-
Skypeの機能停止から学ぶ
12月22日16時、Skypeが利用できなくなり始めた。始めは影響を受けたユーザは少なかったが、次第に広まり、24時間近くネットワークが停止する事態にまで発展した。1週間後、SkypeのCIOであるLars Rabbe氏は 今回の機能停止の事後分析を行い、何が起こったのかの説明をした。
-
いつもコードが悪いのか?
ソフトウェアプロジェクトの失敗には、様々な理由が挙げられる。プロジェクトが失敗するのは間違った要求のためであったり、コストとスケジュールが超過したためであったりする。単にマネジメントが悪かったと言って失敗するプロジェクトはほんの少しだ。根本原因の分析をした場合に、すべての失敗したプロジェクトは、不完全なコードが主な元凶になるだろうか? いつもそうだろうか?