『なぜエラーが医療事故を減らすのか』はスゴ本
「バグを排除しようと圧力をかけると、バグが報告されないプロジェクトになる」 この寸言は、よく忘れられる。シックス・シグマや日経ナントカに染まった管理者が、バグを目の敵にし、バグゼロの号令をかける。不具合が表面化すると、たまたまそこに詳しいだけの担当を犯人扱いし、なぜなぜ分析を強要し、ccメールや全体会議で晒し者にする。 なぜなぜ分析とは、「なぜそれが起きたのか？」「その原因の原因は？」と、原因を幾重にも掘り下げる手法のこと。5段階も遡及すると、たいてい「私の不注意でした」となり、対策は「意識を入れ替える」という小学校の学級目標になる。反面、もっと深刻な「仕様変更が電話口で伝えられていた」とか「アジャイルの名のもとにテストが省略されていた」などは放置される（なぜなら、「人」を原因にしたいから）。 こんな冗談みたいな施策を続けていくと、スケープゴートになった人はどんどん心をすり減らし、不具合の
ssコマンドはバグと地雷の塊なのでnetstatの代わりにならない - ろば電子が詰まつてゐる
既に有名な話ですが、CentOS 7およびRed Hat Enterprise Linux 7からはifconfigコマンドやnetstatコマンドが非推奨となり、デフォルトインストールすらされなくなりました。代替として、ifconfigコマンドはipコマンド、netstatコマンドはssコマンドが用意されています。 というわけでさっそくssコマンドを試していたのですが、明らかに動きがおかしなところがあり、少し調べてみました。 そして、「netstatコマンドの代替と思って安易にssコマンドを使うと、これは痛い目に遭うな……」ということが分かったので、不幸になる人を少なくするためにこのエントリを書きました。 概要 結論から先に言うと、CentOS 7/ RHEL 7のssコマンドには「UDPの開放ポートがTCPと報告される」というひどいバグがあり、使うべきではありません。 また、ssコマン
夏の夜中に起きるバグ - 標高+1m
または代々木の12階に出る妖怪について。 某P社では、Android入りの巨大モニタに入れた簡単なアプリを勤怠管理のインターフェースに使っているんだけど、夏が近づいてきたある日から、このアプリに不思議な現象が起き始めた。夜中の11時頃から朝方に掛けて、サーバにランダムな複数の社員の出勤/退勤のリクエストが高速に続々と送られて来るんだ。 ログに残っているUAもIPも例のモニタのものだから、リクエストがあのアプリから送られているのはほぼ間違いない。アプリのバグじゃないかってことでそれを作った張本人であるところの僕に調査依頼が来たんだけど、僕は夜中の11時になにかするようなコードを書いた覚えはない。ソースを見ても特に問題の動作を引き起こしそうな記述はなかった。 リクエストの回数も不自然だった。高速に何百回も叩かれているのを見れば、当然ソース上で無限ループが発生している可能性を疑うんだけど、それに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
