アカウント名:
パスワード:
各種検査、テスト、本番環境の移行、運用時のバックアップなど、プロセス全体を再点検し、問題点を洗い出し、改善策を検討・実施する必要がある
問題点が「下請けSESを使ったため」とか「社員の能力が足りてなかった」みたいな話に集約されちゃいそうな気もするけど、大丈夫なんかな。
肝心なのは洗い出した問題に対する改善策によって再発を防げる見込みが十分にあることで、それさえ実現すればどのように集約されるかなど些細なことだ。
テストカバレッジ上げましょう。
『テストちからバレッジ』でもだいたいあってる。
問題点：社員の危険察知能力が足りていなかった改善策：各部署の壁に現場猫のポスターを貼る
実際に掲示されたもの：モチベーションアップ株式会社のポスター
チェックシートみたいな書類が増えるよりはマシでは。
増えないですむのか？
元請けの原因調査チームなら、それらの原因は結局「管理能力が足りなかった」ということになるのだが。
> 「下請けSESを使ったため」とか「社員の能力が足りてなかった」
こういうのを問題点と捉えない人がいるけど、「こういうのを抱えながら障害起こさないようにするにはどうすべきか？」というのは大事な話で「ミドルウェアベンダーにプロジェクトに入ってもらう」とか「識者にレビューしてもらう」とかやってるところはやってますよ
そういうのは切り捨てないといつまでたっても問題点として残りますよ。出来ない奴にやらせるって本末転倒もいいところ。現実はそうもいかないって人もいるけど、そんなこと言っているからこんなことになるわけで。
理想に向けて現実を変えていかなきゃいけない場面で「ゲンジツガー」って足引っ張る人ばっかりですからねえ
・OSが32ビットから64ビットへ更改（事実）・インデックステーブルの生成に不具合（報告）・メモリ不足ではない（NTTデータ談）以上のことから、整数ビット長の違い、カラムのサイズ違いなどが予想されるが‥‥基本設計時に、OS変更に伴うテスト仕様を洗い出しているよね。
・32bitと64bitでCPUアーキテクチャは同じなのか? 違ったらいろいろ問題でそうだよね。・テーブルを生成するアプリの記述言語は32bitと64bitで同じなのか? 記述言語変わってたらコンパイラやライブラリの影響でてくるよね。 記述言語同じでもコンパイラのバージョン違ったら振る舞い変わってるかもだよね。
でもまあ、他のプログラムは問題は出ず(テストで問題を見つけて直した？)、このプログラムだけ問題が出たってことはメインのプログラムじゃないので手薄だった(スキルの低いエンジニアが対応してた、テストも甘かった)ってことなのだろうか。
確かにメインの機器じゃなかったかと中継するだけのコンピュータでもパケットの一部を書き換える機能があるルーターの特殊なものかも知れないし問題のアプリがルーターの管理ツールって可能性もあるんだよね32bitや64bitが中継機のことと思うけど（管理ツールかも知れんけど）大丈夫だろって思い込みかな
でも仮にルーターだったら、わざわざ自社でテストはしないかなもちろん通信テストはするけど、パケットの中身が一部壊れてたとか見逃すかもね
コンパイラを32ビット対応の古いのから64ビット対応の新しいのにした時に、'char'のデフォルトがsignedからunsignedに変わったのが原因だったりして。テストケースは問題が起きない0-127の値しかなかったけど、本番データには128-255があった、とか。
# 金融系でC言語使ったりしないか。
Cへのトランスレータとかだったりしてね
CとJAVAと公言されてたはずですよ
使うよ。特に右から左へデータ選別して渡すような速度が必要なリレー系のサーバでは。障害が起きたのがRCサーバだからC、しかも無印のCで書かれてたんじゃないかと思う。で、古いそーすをコンパイルして、コンパイル通ったから、まぁ実績あるし簡単な動作チェックだけしときゃいいだろと思ってテストサボってたんだと思うよ。
仕様書が降りてくるころには仕様が変わっている軍曹状態かもしれない
でも現実としてそういう話でもあるんだよな
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
なにか見つけないといけない (スコア:0)
各種検査、テスト、本番環境の移行、運用時のバックアップなど、プロセス全体を再点検し、問題点を洗い出し、改善策を検討・実施する必要がある
問題点が「下請けSESを使ったため」とか「社員の能力が足りてなかった」みたいな話に集約されちゃいそうな気もするけど、大丈夫なんかな。
Re:なにか見つけないといけない (スコア:1)
肝心なのは洗い出した問題に対する改善策によって再発を防げる見込みが十分にあることで、
それさえ実現すればどのように集約されるかなど些細なことだ。
Re: (スコア:0)
テストカバレッジ上げましょう。
Re:なにか見つけないといけない (スコア:2)
『テストちからバレッジ』でもだいたいあってる。
Re: (スコア:0)
大きなシステムに関わったひとなら言えないなあ
Re:なにか見つけないといけない (スコア:1)
問題点：社員の危険察知能力が足りていなかった
改善策：各部署の壁に現場猫のポスターを貼る
Re:なにか見つけないといけない (スコア:3, おもしろおかしい)
実際に掲示されたもの：モチベーションアップ株式会社のポスター
Re: (スコア:0)
チェックシートみたいな書類が増えるよりはマシでは。
Re: (スコア:0)
増えないですむのか？
Re: (スコア:0)
元請けの原因調査チームなら、それらの原因は結局「管理能力が足りなかった」ということになるのだが。
Re: (スコア:0)
> 「下請けSESを使ったため」とか「社員の能力が足りてなかった」
こういうのを問題点と捉えない人がいるけど、
「こういうのを抱えながら障害起こさないようにするにはどうすべきか？」というのは大事な話で
「ミドルウェアベンダーにプロジェクトに入ってもらう」とか「識者にレビューしてもらう」とか
やってるところはやってますよ
Re: (スコア:0)
そういうのは切り捨てないといつまでたっても問題点として残りますよ。
出来ない奴にやらせるって本末転倒もいいところ。
現実はそうもいかないって人もいるけど、そんなこと言っているからこんなことになるわけで。
Re: (スコア:0)
理想に向けて現実を変えていかなきゃいけない場面で
「ゲンジツガー」って足引っ張る人ばっかりですからねえ
Re: (スコア:0)
・OSが32ビットから64ビットへ更改（事実）
・インデックステーブルの生成に不具合（報告）
・メモリ不足ではない（NTTデータ談）
以上のことから、整数ビット長の違い、カラムのサイズ違いなどが予想されるが‥‥基本設計時に、OS変更に伴うテスト仕様を洗い出しているよね。
Re: (スコア:0)
・32bitと64bitでCPUアーキテクチャは同じなのか?
違ったらいろいろ問題でそうだよね。
・テーブルを生成するアプリの記述言語は32bitと64bitで同じなのか?
記述言語変わってたらコンパイラやライブラリの影響でてくるよね。
記述言語同じでもコンパイラのバージョン違ったら振る舞い変わってるかもだよね。
でもまあ、他のプログラムは問題は出ず(テストで問題を見つけて直した？)、このプログラムだけ問題が出たってことは
メインのプログラムじゃないので手薄だった(スキルの低いエンジニアが対応してた、テストも甘かった)ってことなのだろうか。
Re: (スコア:0)
確かにメインの機器じゃなかったかと
中継するだけのコンピュータ
でもパケットの一部を書き換える機能がある
ルーターの特殊なものかも知れないし
問題のアプリがルーターの管理ツールって可能性もあるんだよね
32bitや64bitが中継機のことと思うけど（管理ツールかも知れんけど）
大丈夫だろって思い込みかな
でも仮にルーターだったら、わざわざ自社でテストはしないかな
もちろん通信テストはするけど、パケットの中身が一部壊れてたとか見逃すかもね
Re: (スコア:0)
コンパイラを32ビット対応の古いのから64ビット対応の新しいのにした時に、'char'のデフォルトがsignedからunsignedに変わったのが原因だったりして。テストケースは問題が起きない0-127の値しかなかったけど、本番データには128-255があった、とか。
# 金融系でC言語使ったりしないか。
Re: (スコア:0)
Cへのトランスレータとかだったりしてね
Re: (スコア:0)
CとJAVAと公言されてたはずですよ
Re: (スコア:0)
# 金融系でC言語使ったりしないか。
使うよ。
特に右から左へデータ選別して渡すような速度が必要なリレー系のサーバでは。
障害が起きたのがRCサーバだからC、しかも無印のCで書かれてたんじゃないかと思う。
で、古いそーすをコンパイルして、コンパイル通ったから、まぁ実績あるし簡単な動作チェックだけしときゃいいだろと思ってテストサボってたんだと思うよ。
Re: (スコア:0)
問題点が「下請けSESを使ったため」とか「社員の能力が足りてなかった」みたいな話に集約されちゃいそうな気もするけど、大丈夫なんかな。
仕様書が降りてくるころには仕様が変わっている軍曹状態かもしれない
Re: (スコア:0)
でも現実としてそういう話でもあるんだよな