タグ

設計に関するhinopapaのブックマーク (5)

  • KDDIが4G LTE通信障害の詳細を説明――設計・判断ミスが原因

    KDDIが1月16日、年末年始に発生した「4G LTE」の通信障害について、原因と対策を説明した。 12月31日の通信障害はアクセス集中、信号制御装置の設計ミスで発生 2012年12月31日の0時0分から2時55分にかけて、auの4G LTEのデータ通信が「利用できない」状況、そして同日2時55分から4時23分にかけて、同データ通信が「利用しにくい」状況が発生した。全国の地域で、最大180万回線に影響を及ぼした。 通信障害の発生原因について、KDDI 技術統括部 運用部長の内田義昭氏が説明した。今回の通信障害が発生したLTEネットワークは、「基地局制御装置」と「信号中継装置」、(7Gバイトなどの)通信量を制御する「加入者プロファイルサーバ」で構成されている。加入者プロファイルサーバは、アクセスが集中したときの対策として、各種装置からの信号を破棄する機能を備えている。12月31日の障害時

    KDDIが4G LTE通信障害の詳細を説明――設計・判断ミスが原因
  • 後藤政志参考人(原子炉格納容器設計者)の原発批判…シビアアクシデントは特性(文字おこし) : 座間宮ガレイの世界

    後藤政志氏は、元東芝の原子炉格納容器設計者だ。今回の震災のおり、その直後からUstream中継で、連日数度にわたり、リアルタイムに事故の様子を説明し続けてきた。氏の言葉は専門的な言葉が多く、またその喋り方は決してなめらかではない。しかし、氏の技術的な視点は、私たちの理解を別の視点から深めてくれる。原発のデザイン設計の段階から、事故の対処まで、技術的に容認できない欠陥があることを鋭く指摘している。文字に起こしたものは、ひょっとしたら読みにくいかもしれない。だが動画と補完して読めば、必ずあなたの理解を深めるだろう。 「え、後藤でございます。よろしくお願い致します。わたくしあの、10数年間にわたって1989年からなんですが、10数年にわたって東芝で原子力プラント、特に原子炉格納容器の設計に携わってまいりました。で原子炉格納容器と申しますのは放射性物質を外に出さない。事故の時に閉じ込めると、いう容

    後藤政志参考人(原子炉格納容器設計者)の原発批判…シビアアクシデントは特性(文字おこし) : 座間宮ガレイの世界
  • ブラックなのか判らないけれど社員が逃げた: フライドチキンは空をとぶ -フラソラ-

    ブラックなのか判らないけれど社員が逃げた 1: 以下、名無しにかわりましてVIPがお送りします 投稿日:2011/02/20(日) 00:43:25.99 ID:MAEq+zPo0 社員が携帯を机の上に置いたまま出社しなくなった。 連絡を取る手段が無かった。 直接、住居に行っても返事が無かった。 電気のメータの動きは緩く、人がいない事を物語っていた。 ブラックではなかったと思う。 きちんとした会社だったし、格付けでも上位に入っている。 俺はその会社にSIerとして参画していた協力会社社員だった。 その日、会社は社員の実家へ電話した。 三日後、捜索依頼が出されたという。 reebok easytone 6: 以下、名無しにかわりましてVIPがお送りします 投稿日:2011/02/20(日) 00:47:56.62 ID:MAEq+zPo0 その時の仕事はかなり大きな仕事だった。 大きすぎた。

  • 仮想化環境の具体的な設計方法を知る

    仮想化技術を活用して古くなったサーバーを統合したり、新しいサーバー環境を構築したりすることはごく当たり前になってきたが、まだまだ仮想化環境の設計、構築についてのノウハウが広く広まっているとは言えないのが実情だろう。連載では、仮想化専門コンサルタントが実務で培った設計、構築のノウハウを、これから仮想化に取り組むエンジニアにも分かりやすく解説していく。 第2回の今回は、仮想化環境の具体的な設計について解説する。 仮想化のための要件定義 仮想化環境の導入にあたって、仮想化環境に対する要件の定義をしっかりと行うことが重要である。通常のシステム導入の際の要件定義と大きく変わるところはないが、注意すべき点を挙げておく。 目標・目的の明確化 仮想化を導入することのメリットがさまざまな形で伝えられていることもあり、ともすると仮想化を導入すること自体が目的となりがちである。前回紹介したようなメリット・デメ

  • 構造に沿って要件をUMLで具体的に定義する

    はじめに 「上流工程で作成するドキュメント」というとWordやExcelなどを使い、自然言語(文章など)で表したものをイメージすると思います。しかし、昔から自然言語での表現はあいまいになることが多く、仕様としては適さないことが指摘されています。 皆さんも過去に意味不明な要件定義書を受け取ったことや、「いろいろ書いてあるけど重要なのはたった1行だった」あるいは粒度がバラバラで統一感のないものなどさまざまな要件定義書を見てきたと思います。 前回は要件定義には構造があり、その構造を使うことで要件をスムーズに定義できることを紹介しました。今回はその構造に沿った具体的な定義の方法をご紹介します。 リレーションシップ駆動要件分析(RDRA)は、その名のとおりリレーションシップが重要な意味を持ちます。その情報のつながりを直接表現できる図的な方法としてUMLを使います。 UMLを使って要件を定義する 視点

  • 1