タグ

BCPに関するno_riのブックマーク (13)

  • 東京都産業労働局

    令和2年2月12日 X-HUB TOKYO成果発信イベントを開催! 令和2年2月12日 令和元年度第10回東京都大規模小売店舗立地審議会の開催について 令和2年2月10日 「江戸東京リシンク」展初開催 伝統産業に光を当てる江戸東京きらりプロジェクトの新たな取り組み 令和2年2月 7日 デザインマンホール蓋モバイルスタンプラリー等を実施 令和2年2月 7日 若手・女性リーダー応援プログラム助成事業等説明会実施 令和2年2月 7日 Tokyo技能五輪・アビリンピック2021大会基計画策定 令和2年2月 6日 令和2年度「ネクスト・目指せ!中小企業経営力強化事業」 中小企業の販路拡大を支援します! 令和2年2月 6日 第18回 東京アビリンピックの入賞者について 令和2年2月 6日 令和元年度次世代イノベーション創出プロジェクト2020助成事業 支援プロジェクト決定のお知らせ 令和2年2月 6

    東京都産業労働局
    no_ri
    no_ri 2013/04/12
  • 「想定外」が無くならない真の原因

    東日大震災が発生して以来、「想定外」という言葉は、まるで2011年を象徴するキーワードのようになってしまった。筆者自身、この「想定外」をタイトルに使った記事を既に1度書いた。 けれどもこの言葉は、何か悪い事態を引き起こして誰かに迷惑をかけた当事者が釈明に使う言葉としてはちょっと微妙だ。「想定外」という表現が釈明としてスムーズに周囲を納得させられるのは「事前に被害状況の断片すら想像できなかった」ことを話し手と聞き手で共有できているケースだけなのではないだろうか。 例えば、需要を読み違えて大量の在庫を抱えた新商品の仕入れ担当者がいたとしよう。その担当者が上司に向かって「この売れ行きは想定外でした」と釈明したら、上司は「そうか、しょうがないな」と原因追究をやめるだろうか。何らかの判断ミスではないかと勘繰られて、さらに突っ込みが入る可能性が高いような気がする。 ひょっとするとその担当者は上司から

    「想定外」が無くならない真の原因
    no_ri
    no_ri 2011/09/30
    ダメージコントロールのお話
  • 多くのプロジェクトは、計画段階ですでに失敗している

    多くのプロジェクトは、計画段階ですでに失敗している:情報マネージャとSEのための「今週の1冊」(38) 確実に目標を達成するためには、“PDCA”の“P”で考えるべきことがたくさんある。検討すべき項目を一つ一つ丁寧に扱い、もっと慎重にプランニングを進めるべきだ。 数年前、ある自治体のプールで、幼い少女が浄化設備の吸水口に吸い込まれて亡くなる事故があった。マスコミは「現場の危機管理に問題があった」と報じたが、それは間違っている。「問題は、『事故が起きたときの危機管理』ではなく、『ずっと前から吸水口の金網がはずれていた』という日ごろの管理にあったのだ。日人は“危機管理が苦手”なのではなく、“管理自体が苦手”なのであって、危機的状況になるとそれが『バレる』だけなのである」――このように言われると、国や企業、さらにはプロジェクトチームまで、あらゆる組織のマネジメント、全てに当てはまるような気がし

    多くのプロジェクトは、計画段階ですでに失敗している
    no_ri
    no_ri 2011/05/16
    『日本人は“危機管理が苦手”なのではなく、“管理自体が苦手”なのであって、危機的状況になるとそれが『バレる』だけなのである』
  • 「接続されたネットワーク」は脆弱:壊滅が急激に連鎖 | WIRED VISION

    前の記事 『iPad』、発売から10日間で驚異的なウェブシェア アイスランド火山灰:飛行機への影響と「飢饉」の可能性 次の記事 「接続されたネットワーク」は脆弱:壊滅が急激に連鎖 2010年4月19日 サイエンス・テクノロジーIT コメント: トラックバック (0) フィードサイエンス・テクノロジーIT Brandon Keim イタリアの電力ネットワーク全体に、障害がカスケード(連鎖)的に拡がる様子(左から右へ:地図に重ねて表示)。地図の斜め上に表示しているのは、送電網に依存しているインターネット・ノード。 Image credit: Nature。サイトトップ画像は、Wikipedia周辺のWWWの構造。Wikipediaより 単独では障害耐性の高いネットワークが、互いに接続しあうと脆弱になり、壊滅的な障害を起こしやすくなる――このように示唆する研究が発表された。互いに緊密につながりあ

  • アマゾンのクラウドが落雷で一部停止、そのとき何が起きたか?

    先週の水曜日、アマゾンのクラウドサービスAmazon EC2を運用中の米国のデータセンターに落雷があり、電力配分装置(Power Distribution Unit:PDU)が破損。一部のサービスが停止するという事故がありました。 このときアマゾンの内部では何が起きてどう対応したのか? アマゾンがクラウドの稼働状況を報告している「AWS Service Health Dashboard」にあがっている、6月10日の報告を翻訳しながら追ってみましょう(時刻は現地時間の午後です)。 Amazonによる障害復旧報告 6:39PM 「アベイラビリティゾーン」にあるいくつかのインスタンスが電源の故障によって接続できなくなったことを検知しました。接続は回復済みで、問題を調査中です。 6:54PM いくつかのホストはまだ接続できていません。引き続き調査中です。 7:33PM 中間報告。落雷によって1カ所

    アマゾンのクラウドが落雷で一部停止、そのとき何が起きたか?
  • 配電変電所の継電器が作動して遮断機が遮断した場合:アルファルファモザイク - 2ちゃんねるスレッドまとめブログ

    ■編集元:ガイドライン板「361 名前:水先案名無い人 投稿日:2009/11/29(日) 15:19:23 ID:PFZOnURT0」より 870 不明なデバイスさん :2009/11/27(金) 01:45:59 ID:eCdG3zSF 配電変電所の継電器が作動して遮断機が遮断した場合、 原因が分からなくても1分後に強制的に再投入されることになってる。 大抵は雷で一瞬地絡したり、一時的に鳥などが接触したのが原因なので、 再投入成功する。 再投入成功の場合は復旧と見なし、再投入失敗の場合は事故と見なして 原因特定の調査が始まるから停電が長引く可能性大。 ちなみに、電力会社はこの1分後の強制再投入をあまり公表したがらない。 なぜなら、感電事故でせっかく電気が遮断されたのに、救助される前や救助中に 再投入されて、助かる物が助からなかったり、救助者も感電するという二次災害の

  • データセンターが「落ちる」ことを想定したグーグルのアーキテクチャ

    サーバを安全に運用する施設として構築されるデータセンターですが、グーグルではそのデータセンターですら"落ちる"ことがあると想定してアーキテクチャを構築しています。 米グーグルが今年の5月に行ったイベント「Google I/O」で、同社のGoogle App Engine datastore leadであるRyan Barett氏が行った講演「Transactions Across Datacenters (and Other Weekend Projects)」のビデオがYouTubeで公開されました。 Barett氏は、担当しているGoogle App Engineのデータベースに関してグーグルが「multihoming」(マルチホーミング)と呼ぶ複数のデータセンターを用いた処理を実現している理由として、データセンターが自然災害や停電に見舞われたり、メンテナンスなどによるデータセンターの

    データセンターが「落ちる」ことを想定したグーグルのアーキテクチャ
  • 「Doblog」投稿不能のまま1カ月 ブロガー移転先分かる「難民キャンプ」出現

    NTTデータのブログサービス「Doblog」(ドブログ)で2月8日に起きた障害が復旧せず、1カ月以上にわたって記事を投稿できない状態が続いている。このほどユーザーの1人が、Doblogユーザーの移転先を収集・公開する「Doblog難民キャンプ」を開設。移転先情報を50件以上掲載している。 Doblogは、サーバのHDD障害で、2月8日から閲覧・投稿ができなくなった。2月20日以降、閲覧は一部を除いて可能になったが、投稿はできないままだ。このためDoblogのブロガーは、ほかのブログサービスに移転しても、Doblog上で移転先の告知すらできない状態だ。 「難民キャンプ」は、Doblogのブロガーや読者が移転先を告知・共有するためのサイトで、「Doblog暦5年超の元ドブロガー」という匿名の個人が、「gooブログ」上に開設した。移転先情報をコメントで受け付け、整理して掲載している。「今回の障害

    「Doblog」投稿不能のまま1カ月 ブロガー移転先分かる「難民キャンプ」出現
    no_ri
    no_ri 2009/03/13
    匿名個人の方が運営元よりも全然良いというこの事実。NTT「だった」らこんなことにはならなかったかもねぇ
  • いざという時、動きますか? ディザスタリカバリの総点検

    いざという時、動きますか? ディザスタリカバリの総点検:ERMへ向かう企業経営(1/3 ページ) 事業継続のために構築したディザスタリカバリ(DR)対策が、正しく機能すると胸を張ることができる状態にあるだろうか。DR対策における抜け穴をチェックし、災害リスクに強い事業インフラを確立しよう。 2000年以降、事業継続(ビジネスコンティニュイテ=BC)や障害復旧(ディザスタリカバリ=DR)への関心が高まり続けたことで、多くの企業が既に対策を講じている。だがDR対策ではデータをレプリケーションするというレベルにとどまり、大規模な災害などが実際に起きた場合に、確実に復旧できるという確証を持てないケースが少なくない。リスク対処への強化が求められる昨今、DR対策において見落としがちなポイントを再度確認し、「抜け穴」のないDR対策を実現していこう。 複製だけは済まされない 現在のDR対策サービスの多くは

    いざという時、動きますか? ディザスタリカバリの総点検
    no_ri
    no_ri 2009/02/27
  • 「技術者は技術の向こうにある社会情勢にも目を向けよ」、奈良先端大山口教授

    技術者は技術の向こうにある社会情勢にも目を向けよ」、奈良先端大山口教授:Black Hat Japan 2007 Briefings Report(1/3 ページ) 去る10月23日から26日の4日間、国際セキュリティカンファレンス「Black Hat Japan 2007」が開催。基調講演では、奈良先端科学技術大の山口教授が情報セキュリティにおける技術の大切さを訴えた。 「セキュリティはヒトの問題? いいえ、やはり技術でしょう」。2004年に内閣官房情報セキュリティセンター 情報セキュリティ補佐官に任命された奈良先端科学技術大学院大学 情報科学研究科の山口英教授は、10月25日の「Black Hat Japan 2007」基調講演冒頭でこう切り出した。 「情報セキュリティ管理のための新しい技術」と題した講演で、山口氏はセキュリティ技術の大切さを強調する。 「国策に深くかかわるようになっ

    「技術者は技術の向こうにある社会情勢にも目を向けよ」、奈良先端大山口教授
  • サイトのハッキングに安価な手段で対処した政府機関

    シンプルなバックアッププランのおかげで、「ca.gov」ドメインがハッキングされた後もカリフォルニア大気資源委員会はサイトの全面閉鎖という事態を免れた。 これは、カリフォルニア大気資源局(ARB)のWebサイトだ。何の変哲もない地味なサイトだが、先週、このサイトが大きな注目を集めることになった。サイトにアクセスできなくなるという危機をARBが見事に乗り切ったからだ。 ほかの多くのカリフォルニア州政府機関では、そんなわけにはいかなかった。10月2日、すべてのサブドメインを含む「ca.gov」ドメイン全体が誤って乗っ取られた結果、各州政府機関ではWebページと電子メールシステムが使用不可能になるという障害が断続的に発生した。 これは、すべての「.gov」ドメインを管理する連邦調達局(GSA)が、ca.govドメインをいきなりオフラインにしてしまったのが原因だ。ハッカーがポルノページにリダイレク

    サイトのハッキングに安価な手段で対処した政府機関
    no_ri
    no_ri 2007/10/10
    技術的にどうこうという話ではなく、ウェブサイトに求める機能をきちんと把握している
  • 災害発生!でも業務は止められない---目次

    新潟県の中越地震や三条の水害など,企業ネットを直撃する大災害が連続している。災害時にはシステム保護や企業存続のため,とっさの判断が求められる。それまで有効だと思われてきた手段が機能しない場合もある。いつ襲ってくるか分からない災害に,どう対処すべきか。被災地のユーザーの声から有効な対策を探る。 目次

    災害発生!でも業務は止められない---目次
  • 【アステラス製薬】IT部員全員の連絡が途絶えても、バックアップの起動は死守

    アステラス製薬は、災害など非常時でも重要な事業を止めないためBCP(事業継続計画)を策定し、2007年4月にも実行に移す。このBCPでは、“継続する”業務を、(1)受注・発注、物流(2)生産、(3)製品の回収や当局への報告――の三つに絞り、いざというときに各部署や各社員がどのように動くべきかを策定する。 日常業務の情報システムへの依存度が高まっている中、BCPの実行では、必要な情報システムを使えるかどうかが一つのポイントになる。そこで同社は、情報システムのバックアップ対策も強化している。とはいえ、無尽蔵にコストをかけられるわけではない。いかに費用対効果の高い方法、仕組みでバックアップを実現するかに知恵を絞っている。 合併でデータセンターの有効活用が可能に アステラス製薬は、2005年に旧・山之内製薬と旧・藤沢薬品工業が合併して誕生した。合併前にも、両社それぞれで段階的に情報システムの災害対

    【アステラス製薬】IT部員全員の連絡が途絶えても、バックアップの起動は死守
  • 1