【IT】三菱UFJニコスのシステム障害の原因が判明、3個のHDDが同時に故障
■ このスレッドは過去ログ倉庫に格納されています
三菱UFJニコスは2018年2月7日、2017年末に発生したシステム障害の原因や影響範囲などについて発表した。同社のクレジットカード「NICOSカード」の基幹システムで、ハードディスク（HDD）が3個故障したのが原因だ。2018年1月末時点で一部の会員に対する請求が遅れているなど、事態を収束しきれていない。
マスターデータから中間加工ファイルを作成するバッチ処理のシステムでHDDが故障し、障害が発生した。三菱UFJニコスによれば、HDD15個で一連の機能を果たしており、そのうち3個が同時に故障した。「2個までの同時障害は自動復旧可能な仕組みを設けていたが、3個の故障は想定外だった」（広報）。同社はシステムやHDDの開発企業を明らかにしていないものの、「発生確率は極めて低いとの報告を受けている」という。
故障したHDDは、障害が発生した2017年12月26日中に交換したが、利用会員の売上データ処理などに遅れが発生した。一部の利用会員に2重請求が発生したほか、請求が遅れるなどの事態につながった。同社はシステム機器の監視体制を強化するなどして対策を講じるという。
http://itpro.nikkeibp.co.jp/atcl/news/17/020803126/ >>179
中の人もちゃんと理解してるか怪しいような >>105
リビルド失敗の典型例。
勘定系でここまでしょぼいのは業務改善命令出ても仕方ない。2時間ルール違反。 >>178
全半角バラバラだからその言い訳は通らない >>122
> ８ＴＢをホットスペアで再現しようと負荷かけたら、ベリファイしていない死んでるセクターがあって、そこで２台目の故障、
> つまり本来は１台壊れていて、２台目のリビルド時にやっと気が付くってのがRAID6の最悪な所
これはない。 通常の Hardware RAID ならそれを回避するのも含めてスクラブかかるから。
スクラブは定期的に HDD なめて、単体HDDでのECCによるエラー訂正や、それでダメなら
RAIDのパリティでのチャンク単位のエラー訂正する処理な。
寧ろ問題なのは RAID-5 や 6 を使うのにバッテリ付きキャッシュ搭載の RAID カード使わない場合。
なぜ RAID-Z が作られたかを勉強するべき。
君の言う障害が発生した要因はバッテリがヘタってるか RAID カード壊れているかであって RAID-6
の問題ではない。
あと、えらく分散ファイルシステムを持ち上げてくれちゃってるが、HDFSやハイパーコンバージドシステム
が速いのは大して更新がすくないディスクに対してのみ。
だからWeb検索とかのビッグデータや仮想マシンのＯＳ側ディスクだけにしか使えない。
トランザクショナルＤＢを分散ファイルシステムに置いてしまうと応答速度面で致命的に遅くなる。
やるにしてもトランザクションログをレプリケーション先にリアルタイムで同期するぐらいだ。
RAID10 や RAID6、RAID60、Luster系分散ファイルシステム、クラウド向けの分散ファイル
システム、ビッグデータ系分散ファイルシステムそれぞれ何が長所で何が短所か、何が得意
なのかを勉強してくれ。 >>185
定期スクラブはもちろん毎日や毎週行うべきだけども、容量を全てスキャンするにはかなりの時間と負荷がかかる
そして、この際にアラートが出ても、１個だから平気などと運用される事例は見る。
どうせ自動的に修復されると信じてしまっている運用はあり得る。
２日連続、あるいは２回連続でアラートが出たら、真剣に交換しよう等とね
運用中にスクラブをするということは、ＨＤＤのヘッドを激しく移動させることになる
最近の大容量ＨＤＤはヘッドの平均移動距離が短いから、もしヘッドが大移動を繰り返した結果、
プラッターに傷がつくと、そこからカスが生じ、すぐにダメになる
なので、スクラブ中に他の所が壊れるメカニズムはある
RAID-5 や 6 を使うのにバッテリ付きキャッシュ搭載の RAID カード使わない、というのは私には想像できない。
もし、バッテリーに問題が生じるような設計をしたならば、設計欠陥を指摘され、致命的なミスと叩かれるだろう。
RAID-Zについては使っているし、その利点も欠点も、長期の運用での状況もある程度押さえているが、
安全に使える環境の問題から、避ける人もいる。
分散ファイルシステムを使うのはとても高速な専用の線を用いて、高速なSSDを使うことが前提として要求されるのは言うまでもない。
性能が足りなければ、どこかで工夫をしなければならない。
ネットワーク越しの書き込みに対しＨＤＤの回転を待つことがいかに長いかを考えるのは前提。
ＤＢはＤＢそのもので分散機能を持っているものがあるだろう？
それをまず検討すべきで、ファイルシステムに全てをゆだねるなどはしない
まあ、どの程度の費用をかけ、どの程度の信頼性を得るか、そして、その流れの方向は押さえておいたほうがいいだろう
例え、今現在、性能が足りないとしても
だいたいのケースにおいて性能が問題になる場合には、根本的にＤＢの設計が腐ってる場合が多いね
妥協に妥協を加えて、これくらいはいいだろう等と、手を抜いた結果が階層的に積みあがると、腐ってくる
ＤＢが本質的に何をして、どのような処理が行われるのかを理解せずに、ＳＱＬを投げたり、
安易にＤＢの最適化機能に頼ろうとすると、ものすごく遅くなる
そもそも、ＤＢに何を入れるべきかが真剣に検討されていないものが多いからね
言われるまでもないことだろうが・・・あなたにとっては SeagateとSamsung
買った後にフォームウェアのバクとか知った後の絶望感 普通は複数の物理サーバで仮想化してるから
HDDが同時に3個壊れようがRAIDカードに不具合があろうが問題にならない
これだけのシステムを素人が設計・運用するとも思えないので
コストをケチって敢えて脆弱な構成にしたか
コストをケチって敢えてHDD障害を放置する運用体制にしたとしか考えられない
まあ無能な経営者揃いの三菱らしくていいんじゃない?w 重要なシステムは、ホットスワップ付きRAID5ストレージを２台ミラーリングするもんだ
また、メインストレージが飛んでも、バックアップデータとログから再実行して復元できるようにしとくもんだ >>1
今の企業ってどこも 壊れるまで使うっていうのが糞みたいな当たり前の話だからな
だから絶対に障害は生じるわけだよ 壊れなくても定期交換するのがリスク回避
そういう極当たりまえの経営判断をできないのが 日本の企業経営者 事案が発生しようが
責任はぜーぶん現場のせいにする 見てみなよ 神戸製鋼 東芝 日産 スバル 三菱マテリアル 全部そうだろｗ 昔IBM製のHDDが立て続けに2台逝った事のある身としてはよく分かる >>191
ＲＡＩＤ５やホットスワップは気休め。
万能じゃない。
このスレに「ＲＡＩＤにしとけよ」とか言っている人がたくさんいるが、
ファイルサーバー程度しか作ったことがない人なのだろう。
ＲＡＩＤにより、データ損失はないかもしれないが、パリティからの
データ自動回復で一気にシステムが遅滞する。
ファイルサーバーや静的なコンテンツ参照のWebサイトなら
それでもなんとかなる。
だけど、オンライントランザクションシステムやバッチ処理システムだと、
自動回復が始まったとたんに急速にレスポンスが低下する。
さらに、パリティからデータ自動回復をやりながらシステムを動かすと、
回復と処理の負荷で、他のディスクまで壊れるということもたまにある
というのが俺の実経験。
三菱ＵＦＪニコスで起きたのも、そういうことなんだろう。
玉突き事故を、「（ほぼ）同時」と言っているのだと思われる。
オンラインやバッチ系のシステムでは、ＲＡＩＤはさらなるディスク故障を
招く原因になることもある。
それを防ぐには
・機械部品の動作がないオールフラッシュのストレージにする
・そんな金がないなら、パリティからのデータ回復がはじまったら
すみやかにシステムを停止するか、処理を書き込みがない
参照オンリーにシステムの設定を変更する。
ホットスワップはあくまで、即時システムダウンしないための
一時しのぎであると理解し、「ホットスワップがあるから動かし続けよう」
ではなく、まずはシステムを止めることを優先する
と理解すべきだ。 まぁ究極的には運頼みだな。
技術的な事情はほとんど公開されてないのに、バカだの素人だのこき下ろせる人がいるのが不思議だ。
自分んとこのシステムは盤石だと信じられるのは、勝手に自分の責任範囲を線引きしてるか、
それこそバカと素人だけではないだろうか。 >>186
> 定期スクラブはもちろん毎日や毎週行うべきだけども
長文だなーって思ったけど、しょっぱなのここですでにアウトだわ。
> ２日連続、あるいは２回連続でアラートが出たら、
RAID-5 カード使わないのが想像できない人がこんなことは言わない。
> ネットワーク越しの書き込みに対しＨＤＤの回転を待つことがいかに長いかを考えるのは前提。
なんでバッテリ付きなのかわかってないね、君は。
あと処理には同期書き込みと非同期書き込みがある事を全く考慮していないな。
> ＤＢはＤＢそのもので分散機能を持っているものがあるだろう？
予算という物があってだね、全てのプロジェクトで Oracle Exadata が使えるわけじゃないんだよ。
ストレージ業界で生きてないなら知ったかやめてくれ、ほんとに。 >>191
業務用途の場合は RAID6 か RAID60、RAID6だと物足りないという客向けにここ最近で
トリプルパリティが出てきた。 RAID51 なんてやってる/客に薦めるところなんて聞いたことが無いな。
どこの何て言う製品を使ってるんだ？
やるにしても製品固有の機能での別筐体／別拠点への非リアルタイム系同期で RAID51相当／
RAID61相当にするぐらいだわ。
あと、ログから再実行ってトランザクショナルＤＢのロールフォワードの事を言っているんだと思うが、
データベースの時点で RAID10 一択で RAID5,6 はあり得んよ。 >>191
ミラーリング＋３ndがよいとされていね
RAIDカードがやられたときにも対処できるように
ソフトRAIDも併用するとか >>177
何台も扱った修理専門のCEの感想
検出しきれずチェックツールがウソ返しやがる
正常に読み書き出来てるようで出来てない壊れ方する >>200
無い
インテルだろうがサムスンだろうがマイクロンだろうがどこでも起きた
チェックツール上では正常だと返してくるのに
なんで動かないか悩んで交換したら直るのが何度かあった
修理対応時は交換用SSD持っていくのが必須 フラッシュの書き込み(実際は消去)の深さが閾値近くに落ちちゃってるんじゃない？
そうなると読みこみの値はランダムになるけど
アクセスパターン依存もあるかも たまにしか起きないものが同時には起こるのは別の理由が必ずある
同時に2つの地震があったとか言いうのもそうだ >>196
いやー、ストレージ業界とか、最近は狭い業務分担が流行りだけども、
私は、そういうのは気にしないし、どうしても作ってくれと言われるものしか作らないんだよ
そして、大規模な仕事が多いのでね
ろくなＤＢも使えないような、利益が出ない案件には興味がないんだよ
金がないならアキラメロン
業界が糞なら転職するかフリーになれ
どんな箇所でも手を入れていいし、予算も潤沢にある、どこかのSierに２回依頼したけども完成しなかった、というのはいい仕事になる >>199
インテルのデータセンター用のでもそうなの？
何千回も強制電源断しても壊れなかったから、信用してたんだが
ちょっと詳しく教えてくれないかい
修理専門の人の話なら信じられるから >>202
フラッシュは劣化するわけだけども、常にコントローラーがチェックしてるし、劣化も温度等の物理特性で傾向があるから
それを十分に考慮した耐久性と残りの稼働可能時間がわかる仕組み
ギリギリの状況で使って、読めなかった、などはしないんだよ、普通は
データセンター用じゃないものを、強制電源断したら、もちろん高負荷中に、だいたいこわれる
何回かやるとね なんとかＰＲＯみたいなものもダメ
そうじゃなく、データセンター用のが壊れるかどうかはとても興味がある 三菱のATM
手 認証 ２０回ぐらいやって認証する 同一ロットで、同じような使われ方してたら死期は似てくるらしいよ。 >>212
読めなくなったから、サルベージしてファイル回収したい、ようなのはあるよ
raid-zが壊れてサルベージする話は見たな
その時に、故障状況見れるって話でしょ
ファクトリーコマンドとか使って >>210
いやいや俺半導体専門だけど
もともと不良セルだったら予想外の故障しても何も不思議はないよ
それはフラッシュに限らずどんな半導体セルにも言えることだけど
ただフラッシュはロジックなんかと比べて閾値のレベルがシビアだから
突然中間に落ちて読めなくなったたとかよく聞く話
コントローラなんて所詮ロジックでフラッシュセルの状態なんてモニタしてないでしょ
つまり半導体はあなたの言う普通はないという壊れ方をよくするし
フラッシュはその点特に繊細だということ 半導体がやっかいなのはある時故障してても
負荷をかけてやると復活しちゃうものがあったりと
とにかく不安定な状態の故障モードが多数あること
実際何が起こってるかなんて切ってみないと分からんw >>215
プロセスやってるの？ それとも物性？
フラッシュは容量増やすためにかなり無理なことをしてるけど、結局エラー訂正で直すしかないよね。
単セルの信頼性など求められてなくて、もちろん多値を盛り込んだりで、エラーありきで、検出して直すじゃない。
大昔のEEPROMじゃないわけだし。
それで、いろんなパラメーターからフローティングゲート周りの状況が解明できて、寿命予測が当たるようになってきたって話だと思ったけども。
私は半導体専門でもないし、現在フラッシュのセルの設計をしているわけでもないけどもね。
まあ、基本は理解してるし、いろんなことをやったから、半導体がどう動いて、どう壊れて、何を何が担保しているのかは押さえているよ。
いくつか作らせてももらえたしね。
もし詳しいなら、コントローラーの訂正と寿命予測について書いてくれないか。
いろんなコントローラーがあるが、各社独自でね。謎な所が多いんだよね。
突然変な壊れ方をする、だけじゃあ、そりゃあらゆる物が予想外に壊れることもあるだろうさ、って一般論と変わらない。
フラッシュに限らずHDDもだけど、エラー訂正ありきで容量を稼いでる時代が長くなったね。
HDDのスクラブどうのって言ってた人がいたけども、フラッシュはコントローラーが勝手にスクラブして、勝手に直すんだよね。
だから、電源が入って無いと、どんどん壊れる。時間経過でも壊れるし、アクセスしても壊れるし、隣接の線をいじっても壊れるし、
ありとあらゆる操作がダメージを与えるし、スクラブしなきゃ話にならないしでね。
各社コントローラーに腐心してるが、それゆえに、情報が少ないんだよ。 >>216
まあ、そういうデータを多数集めて、コントローラーに反映しているんだろうなー、と思って、
インテルのデータセンター用のは信用することにしたんだよ。
とある膜がどのくらい劣化して、どのくらいいらない電子が滞留しているかなんてのは、各社の秘中の秘だろう？
テスト用にいろんなパラメーターを変えて、実験して、解析して、最後は断面見てとかやっても、
量産でマスクはズレるし、だいたい動いたら売らなきゃいけないしで、いちいち一品物を作るわけにもいかないから、
結局、ものすごく沢山あるセルを確率的に壊れるものとして、大雑把に数学的に、これくらいの訂正でいいかな、とやって、
ユーザーに長時間使わせて、合ってた、合ってなかった、とやるしかないんじゃないの。 ああ、あとね
HDDのロットどうのこうの言ってる人が多いけど、そういう人に聞きたいのは、
SDDでもロット分ける？
メインメモリーでもロット分ける？
CPUやマザーボードもロット分ける？
LANケーブルや電源もロット分ける？
言いたいことわかるよね
DRAMはペアで使うから、同一ロット品が安心
このロットのCPUはクロック耐性が高いから云々
で、HDDケーブルがビローンって垂れていたりする
短くしろよ
シールドしろよ
電源に気を使えよ
いろいろ面倒なら、製造業を信用しろよ（確率的に）
大昔は、複数のHDDを並べて密集させる場合には、円盤の回転を同期させてたんだよね
そういう同期用の端子があったから
HDDを密集させて同じ金属板に固定する意味を理解している人がどこまでいるのか知らないけどもさ >>197
ゴミクズIBMだと10の選択肢がねーんだわ 半導体の話だけど上で解説されてることは全くその通りで
壊れるの前提でエラー訂正するしコントローラも設計する
俺が言いたかったのは製造欠陥の話でもともと不良セルだったものが
ある程度動いてたけど負荷によって突然中間値に落ちたりしたんじゃってだけのこと
あらゆるものが予想外に壊れるってのはその通りだけど
半導体が面白いのはフラッシュの場合広い閾値のレンジと
あまりにも多すぎる故障モードだと思う
それゆえ壊れてるのに正しく動いているように見えるなんてのはよくある
特に特定の手順で操作したときだけ故障が顕在化するなんてこともある
だからチェックツールでパスしても実際は壊れてるなんてのは
半導体の世界では当たり前すぎる話でしょってことだけが言いたかった
チェックツールにウソと言われてもねえ…
これ以上はスレ違いかな これは5台でRaid0を組んで3グループでRaid1にしてた感じ？
そして2グループ死んでるのに気づかずにそのまま運用してたとか？ >>69
プロは大変だな
オレのはポエムばかりだから消えたら脳内再生するさとたかｗ >>221
ほー、面白いな。フラッシュ。
HDDの場合だけど、壊れてるセクターがあって、何度も何度も、例えば１０回読むと、エラー訂正できたりする。
微妙に磁石が狂ってて、不安定なのが、０か１かどっちかに転んだタイミングで、セクターが読め、予備に転送できる。
なので、しくこく読み続けてたら、１００セクターくらい回収できた。
フラッシュでも、同じこと出来るだろうね。
やっぱり心配なので、最終的には多重化するけども、根本的な仕組みには興味あるわ。 >>223
個人用の大量のデータを思い切って捨てたら、すっきりした。
ミニマリスト最高だよ >>222
これレイド0+1？
3重ってどういう実装になるの？
カードに3台つなぐと3台でraid1組んでくれるの？ 物理的に別のストレージにあるものをソフトウェアミラーリング
が必須
ホットスワップ付きRAID6ディスクアレイを2台用意(もちろん仮想的に2台じゃなく、物理的に2台)
これをOSによるソフトウェアミラーリングで使用 RAID1+6にしておけば・・・
まあ、エラーメッセージ見てなかったのが最たる原因だろう ３個同時て
それ同じ電源に接続してたとか？
つか、どっか別の場所でマイグレできるようにしとかんといかん奴なんじゃないの？ >>121
俺もそう思った
そうじゃないと考えられない RAID0+1とかホットスワップとか、知ったかさん多いな >>232
学校で勉強して、テストで１文字でも間違えたら、×つけられて？
会社でプレゼン資料作って、１文字でも間違えたら、上司に、×つけられて？
現役の下働きは大変だね。上に行きなよ。
これ、任せたいんだけど、いいかな？から始まって、
やれるだけのことはやりましょう、予算は自由に使うけども、いいよね？
ああ、いいよ、トラブルよりもいいもの
完成、３年ノートラブル。
ほー、いいね。どうやってるの？ コピーしてもいいかな？
そりゃ、いいよ。売ったんだし。
説明はしないけど、ここにドキュメント入ってるから、見て。
誰かに、解析させてもいいかな？
運用終わってからの方がいいんじゃない？
途中で勝手に止めたら、面倒みないよ。
RAIDのレベルがどうのこうのなんてのは、実績の前にはどうでもいいし、客の関心事はそこじゃない。
どんな手段でもいいから、壊れないのを与えたら、なーんにも言わなくなる。
プレゼンする必要もない。
前のと同じ感じで、容量増やしたいんだけど、しか言われない。
そんで、客が勝手に、適当な資料作って、稟議通ればＯＫ
実際に作ったものとプレゼンが違うなんてのはざら。
我が社の過去システムで、これだけの稼働実績のある・・・・の最初の１ページしか、誰も興味ないよ。 >>232はすごいな
あんな短文で>>233をここまでヒートアップさせるなんて 技術用語の扱いがいい加減なやつはシステムの扱いもいい加減だからね
RAID0+1はそれ以前の問題だが RAID6(ホットスワップ付き)を物理的に別筐体で２セット用意して、
さらにミラーリング
これが必須だよ
RAID1+6ってやつ それホントにRAID1+6って呼ぶの？
ディスクの冗長化じゃないと思うけど >>238
RAID0+1 & ホットスワップさん乙 ストレージの耐障害性にFTサーバーがどう関係すんのさ？ 大規模なデータセンターならディスクの多点故障とか日常茶飯事 1cm間隔でずらっとSDカードをが刺さってて死んだら自動で排出。
マガジンに空のSDカードがいっぱい入ってて空いたスロットに自動装填、みたいな装置できないかな。
保守は空メディアの補充だけでいいの。 >>244
ＦＴするならＳＳＤしか選択肢ないし
ストレージも２系統
ファイバーのスイッチも２系統
回線もストレージの速度も最高
などのデラックス仕様になって
しかも何かトラブっても予備常時待機でそっちに切り替わるんだから
何の心配もなくなるんだろ
このニコスみたいにケチケチしたようなのだと何が起こっても知らんな
ＦＴじゃないと心配って客はいい客 >>246
テープがそうなってるな
古いのだとMOのオートチェンジャーとか
CDの４００スタックのとかな
SDカードはドライブユニットのコストがほぼゼロだから
チェンジャーで変えるメリットがない
もしSDが１０００枚刺さってるのが欲しいなら、常時１０００枚さしておき、
定格容量を８００枚分にすればノーメンテになる
大規模なの作ると、物理的に力がかかることで死ぬことも心配しなきゃならなくなるから
装置の中に全部収めて、パネルを開けない方が長持ちする ショッピングのリボ払いで臨時増額返済をATMで受け付けてくれないのはこのせいか？ 誰かが障害原因の言い訳で嘘をつくと、業界全体が迷惑を受けるパターンじゃないかと。
15台中3台が同時なんて 最近明細見てないけど何か最近多く引かれてる様な気が
久しぶりに確認してみるか >>5
2個壊れてたのを気づかず放置してただけじゃないかと思ってしまう。 >>247
問題を全然理解してないよね。。。
単純にストレージを2系統ってのは>>238のRAID6+1的な考え方 >>255
これの解決方法はいくらでも思いつくが
予算ないからこうなってるんだろう
しかも予算を節約するために頭も使ってないし
まずは、ＤＢがダメなんだからオラクル買えよって話
オラクル買えないならストレージで何とかした上で運用で巻き戻しするとかログから再生しかないが、
そんな面倒なことをニコスが出来る筈もないからこのざま
予算も無い上に今まで動いたたから今後も大丈夫って考えとしか思えない
ＦＴ云々ってのは極端な例を出しただけ
予算があるなら全部任せろ
予算が無いなら客が考えろ、その通りに作るから
ってのが私ののやり方
ストレージが死なないとかマシンが落ちても継続ってのはミニマム条件なんすよ
その上でオペミスとか他社のものがぶっ壊れたとかあってもリカバリーどこまで出来るのか
例えサービス止めてでも取り消ししたい場合もあるし
こういう各種アノマリーを上乗せしてやるが客が全部を想定できるはずもなく
説明もメンドイし緊急事態になるまで関心も示さない
なので、予算重視になるわけ
ＦＴの予算出せるってのはそういうこと ディスクが三個同時に壊れるのは確かに相当珍しいし、何か外的要因がある気もする。
とは言え普通はディスク装置ごと飛んでも外部バックアップがあるし、広域災害に備えて遠隔地バックアップもしてるでしょ。
１日くらいは止まってもあとに影響なく復旧できるはず。
ここまで大混乱が起きるほどの重要システムならなおさら。
機器の故障くらいでここまでの影響がでるのは、そもそものシステム設計が悪かったとしか思えない。 >>256
やったことないのにこんな所で知ったかしなくていいよ
RAID6やRAID6+1が何でダメなのかっていう基礎から勉強してくれ
>>257
リビルド時の故障も広義では同時
サクッとシステムが死んでれば傷口はもっと浅かっただろうね raid6の問題ってホールの話？
固定ブロックの場合トランザクションが必要って奴だっけ >>259
書き込みホールは理論的にはどのRAIDレベルでも発生しうるけど
ハードウェアRAIDの場合は普通対策済みだから現実的に問題になることはまずないよ RAIDコントローラーが正常に動いてればな
それがSPOFだったら終わり >>219
海門にやられたからな
ロットごと不良。 >>261
それは全く別の問題だから対策も別だよ
クリティカルなシステムでRAIDコントローラをSPOFにしたりしないしね ニコスはRAIDコントローラの障害じゃないよ
典型的なリビルトの問題
カード会社の基幹システムで
RAIDコントローラがSPOFのストレージユニットなんて使うわけない リビルドに失敗するようなシステムは良くないと思う
故障検出も含めて 先月の１月１５日にニコスポイントをTポイントに移行申込したのに
いまだに移行されていないのもそのせいなのか？？？ ニコスといえば昔の話だが芸能人の明細が目に留まると社内で話題になってたんだよな
○○が△△△を買ったぜなんてな
今じゃーセキュリティーがガチガチで無理だがね
ｂｙ内部告発ではなく、内部つぶやき者 >>266
今は知らんが当時は汎用系でCOBOL
よってそれを言うならリビルドでなくリコンパイルな >>269
そっちのリビルドじゃなくRAIDのリビルドなw これは同時に導入したsegateなら、結構あるあるネタだね クリティカルなシステムならSeagateは使わないこと
HGST >>>>> Western Digital >>>>>>>>>>>>>>>>> Seagate
https://www.backblaze.com/blog/hard-drive-stats-for-2017/ まぁsnmpでRAID状態も管理できずに「発見時は同時に壊れていることを認識した」んだろうなぁ。
同時なんかあるわけねーだろが。 普通にあるよ
球数が数百台の小規模なら無いだろうけど 入金を待ってる店側には、ごめんなさい通知が二回。
しかもまだ全額入金されてない ひどいな
データロストしてて端末側のログと照会してもらう必要あるかもね ■ このスレッドは過去ログ倉庫に格納されています
