「ファーストサーバ最終報告書、ベテラン担当者のマニュアル無視を黙認 」

http://itpro.nikkeibp.co.jp/article/NEWS/20120731/413084/
http://www.firstserver.co.jp/news/2012/2012073101.html
http://support.fsv.jp/urgent/pdf/fs-report.pdf *1
斜め読みだけど，とりあえずざっくりと．

おそらく問題認識が間違ってる．まるでドライバー一人で長距離バスを24時間連続運転させておきながら，ひとたび事故が起きれば「ドライバーの運転ミス／居眠り運転が原因です(キリッ)」と言うような感じ．その場合の事故の責任はドライバー以上に経営者にある．

• バックアップがないのが根本原因．トラブルはあり得るもの．それに対処するためのバックアップ．
• 「手順書」があったけど「管理ツール」はなかったようだ．膨大なサーバーを一人で「手作業で」管理するなど愚の骨頂．
• 作業の「標準化」が重要なのではない．「効率化」が重要．「手順書作りましたのでこれを遵守してください．ただし現実的な時間では作業は終わりませんが，それは現場の責任です」というPRESS ENTERの渕上マネージャ*2のようなやり方では現場も死ぬし，品質も維持できません．*3
• 低コストサーバーだからこそ，運用コストは下げる必要がある．手動対応は非常に高コストで高リスク．
• マニュアルがあろうとなかろうと，手動対応は別の意味で高リスク．
• 完成度の低い手作りスクリプトで作業するのは高リスク．スクリプトは何でも「できすぎる」ために，人的エラーが混入し易い．しかしそれに対する対処は手作業による非効率化・低品質化ではない．

対策においても「バックアップディスクへの変更について，明確に禁止した条項がないことから追加し，バックアップディスクの更新禁止を明確化する」とか書いてる時点でダメダメ．禁止を条項に書いたらコマンドの打ち間違いによる人的ミスが無くなるとでも？そういうのは全部ツールを作って，削除の禁止をツールの中に作り込んで，そのツールを使う限りどんなバカでもハッカーでも削除できないようにしておくんだよ．そもそもバックアップディスクが普通に物理的に触れるような場所に接続されてること自体が問題だろうし．

http://itpro.nikkeibp.co.jp/article/COLUMN/20120802/413862/
http://security.slashdot.jp/story/12/08/01/0057216/
http://internet.watch.impress.co.jp/docs/news/20120731_550314.html
http://cloud.watch.impress.co.jp/docs/news/20120731_550334.html
http://himasoku.com/archives/51731526.html

http://d.hatena.ne.jp/JavaBlack/20120626/p1

http://b.hatena.ne.jp/entry/itpro.nikkeibp.co.jp/article/NEWS/20120731/413084/

• id:Layzie まあ、これだけ見るとA氏が悪いけども、そもそもバックアップが本当の意味でのバックアップじゃないのが根本原因な気がする…

• id:asakiri4177 これをオペミスで片付けようとする会社なんて金輪際信用できない訳で。 ケチんないでちゃんと外部媒体にバックアップ取っとけよ…
• id:tail_y 誰かがマニュアル無視しただけで、取り返しのつかない自体になるバックアップの無い仕組みが悪なんであって、これどう考えても完全にスケープゴートだろ。
• id:hobo_king A氏が、A氏の更新プログラムがと書いてあるが、上が認めてる段階で個人の責任の枠を超えてる。それに一番の問題って、データすっ飛ばした原因じゃなくてバックアップを取って無かった事と違う？
• id:hamukatumix 普通のハードウェア障害だってデータが飛ぶことはある。独自スクリプトのせいにしたい気持ちはわかるが。安定稼働してると逆に予算削られる理不尽。冗長化されてなかったのは誰の責任ですかね。
• id:raitu 「A氏だけはマニュアルに従わず、自作の「更新プログラム」を利用してシステム変更を行っていた」事が原因としている。システム上、バックアップは存在しておらず待機系しかなかった、って話はどうなったんかな？
• id:joker1007 これは軽過失と言いはるためのスケープゴートだろ。もし、仮にこのAさんが駄目駄目でも、バックアップをまともに取ってなかった詐欺は変わらんだろうに。

• id:jaguarsan これは「5000件ものデータが吹っ飛んだ」原因であって、「吹っ飛んだデータが帰ってこない」原因じゃないよね？インフラ企業としては後者のが罪重いんだが

むしろ責任を個人になすり付けるために作られた報告書の感が．

• id:tsucchi1022 手順書が善でスクリプトが悪みたいな世の中にならないことを望む

• id:AltNight こういうのって「マニュアルが古くてダメだったから自作した」とかじゃないかなーとか思うんだけど、まあ外野としてはわからん
• id:solidstatesociety マニュアル無視というタイトルとマニュアルがないという本文との狭間で。SLA100%を定義できたモノはなんだったのかというのが重要かも知れない。

• id:TakamoriTarou 10年やってたって、それそのマニュアルが実態と乖離したクソだった所に問題があるんじゃ無いのか。おそらくマニュアル通りにやると、業務が終わらないとかそう言う理由がある気がする。良くある話だが。
• id:aoi_tomoyuki 社員は「何がマニュアルだよｗ形骸化したゴミじゃねえかｗｗｗ」とでも思ってるかもね。Aさんが悪いみたいになってるけど、めんどくさいメンテ作業とか全部ベテランのAさんに任せっきりになってたとかありそうだよね
• id:seiunsky cdします。lsします。みたいのがあって数時間使っちゃうようなアレだろ。そういうマニュアルを改善していくためスクリプト化したりレビューがあるというスタンスならもう少しマシだったと思うんだけども

• id:dazz_2001 極度のコストダウンが真因だと思う。安さを売りにしていたため、人員が確保できず、メンテナンス業務をこなすために、独自のツールを作る。よくある事と言えばそれまでだけど、身につまされるな
• id:REV 「スクリプトにマクロで業務を改善したら上役から怒られた」話を思い出した。 / マニュアル無視しないとサビ残青天井、無視すると「必要なら、１兆円だって出したのに。言わずに無視したのが悪い」というオチかと。
• id:betelgeuse 大事故が起きるまで予算はつかず、現場のマニュアル無視と上司の黙認で「目標」が「達成」されているすてきな状態が続く。というお話

• id:komo-z 「事故が起きなくて当たり前」と思われ、トラブルが起きないと大切さをわかってもらえない。安定稼働してるから担当者の評価も低いし、予算もつかない。だとしたら理不尽だよね。組織や経営者の問題はどうなのかな。

• id:uzulla 「軽過失の枠内だが、比較的重度の過失」新しい(笑，これは流行る！ ／ 「上長が黙認」してる時点でそれはAさんの責任ではないのでは…（何のための上司や）請負ならわかるが
• id:taqpan 「上長もこれを是認」か。誰も意見出来ないほど個人に頼りきっていたのかな。必要な人材への投資をケチってたようにも読める。。。
• id:Kmusiclife これは一人に丸投げという認識でいいのかな？A氏も悪いが決定的に大企業として終わってる。
• id:karronoli 「一般的なレンタルサーバー業者の水準…」ってあるんかね? / メンテナンスの方法とかマニュアルとかに疑問を持てたのはAさんだけということか． / 形だけでもミスを説明できて怒りの矛先もできた，と斜め読みした
• id:natural_distance ベテランの作業リスクをとるコトを会社は選択したってことかな。。。

• id:honeniq 事故を起こした以上は責められても仕方ないけど、非常によくある光景。

• id:hiroyukim 自動化をせざるない背景があると思ってて、まずかったのは会社を巻き込んでこの作業をいかに効率良く安全性を確保していきませんかと持ちかけられなかったことじゃないかと思う。かんけいないけどエジソンの逸話を思

しかし現場の技術者の意見などエライ人は耳を貸さない罠．

• id:wisteria_vii デプロイについては「自作の「更新プログラム」」よりも、本番・待機系へ同時適用しちゃったとか、それ以外の部分が大きいような気もする。

• id:kaiton A氏はマニュアルを作る能力も、想定外が起こっても解決するスキルは少なからずあるのだろう。けれど、業務用サーバを私的サーバと同じような考えでメンテナンスするべきでない。

• id:neverbirth 救いようがない杜撰さとレベルの低さだと思うんだが…。
• id:usi4444 A氏は自作プログラムを使うリスクをよく理解していなかったのか。しかしテストもせずいきなり実行とは凄まじく杜撰な運用。A氏に同情している人、将来貴方もやらかす恐れがあるよ。

• id:hyakuhyaku たぶん立場によって見え方が変わる記事。たいした技術もないくせに何でも抱え込みたがるめんどくさいオッサンが「ぼくのかんがえたすばらしい更新プログラム」を使って大失態ってパターンも十分ありえるからなー。

杜撰な運用は批判されるべき．しかしそれは企業体質の問題であって，A氏個人の責任は実はそんなに大きくない．

なにしろ彼(or彼女?)以前には手動での作業が推奨されていたのだろう？効率的な管理に必要な最低限のツール類を開発するための予算さえも認められなかった結果では．
またバックアップがなかったのも彼個人の裁量でできる問題ではない．

• id:haruten 標準化って、ベテランにとってはレベルの低い仕事を強要することになるけれども、ベテランだからこそ、標準化に従うべき

否．

求めるべきは自動化による効率化と安定品質であって，「非効率なマニュアル化」ではない．IT以前の旧世代の老害連中は自動化が理解できないので「非効率なバッドプラクティスのマニュアル化」に堕ちることが多い．そしてそういう組織は赤字体質になって，残業手当も払えずにブラック化する．

もちろん効率化の上でもマニュアル化は必要だが，マニュアル化は銀の弾丸ではない．

• id:rdfrk 起こるべくして起こったヒューマンエラーだったわけだ・・
• id:amazedkoumei A氏以外は手順書遵守する程度に手順確立されてんのにA氏だけはわざわざ自作ブログラム書いてたって？(　´_ゝ｀)ﾌｰﾝ

ひょっとして，なにか大きな誤解をしているのでは？「マニュアルを無視したから」ヒューマンエラーが起きたと勘違いしてない？？

ヒューマンエラーが起こるのは当然の事実．Ａ氏であろうとなかろうと，手順を守ろうと無視しようと，マニュアルがあろうとなかろうと，それは全く何の関係もない．マニュアル自体の中にもヒューマンエラーは含まれている．

だからこそ，ヒューマンエラーが起きたとしても，致命的なデータ損失が怒らないようにバックアップをとっているわけ．

• id:geopolitics バケツで臨界も手順無視だった。善意の手続き省略（現場の改良による省力化）だったが。スケープゴートにされるのかな。

あれとこれとは話が別．

臨界事故は品質が悪化していた．スクリプトによる管理は品質が向上している．この二つの区別ができないひとは，ITの世界に口出しすべきではない．

• id:nurupo889 おまえは何を言っているんだ？『ファーストサーバの過失について「軽過失の枠内ではあるものの、比較的重度の過失であったものと解される」と結論』
• id:s_kuroi 「軽過失の枠内ではあるものの、比較的重度のものである」って「下の上」みたいなものかな(；´Д｀)？
• id:BRITAN 『報告書では、「比較的重度」という表現を用いているものの、全体としてファーストサーバの過失の程度を「軽過失の枠内」だとしている。』←誰か日本語で頼むｗｗｗ
• id:mas-higa 「軽過失の枠内ではあるものの、比較的重度のものである」 意味がわからん
• id:lumberyard 結論有りきだから"「軽過失の枠内だが、比較的重度の過失」"みたいな気の狂った報告になる
• id:reachout 「軽過失の枠内ではあるものの、比較的重度の過失」ニホンゴムツカシネー
• id:arien_nu 「軽過失の枠内だが、比較的重度の過失」日本語でおｋ
• id:myosho ここに業界や企業の体質があらわれている。結果さえ出ればいいという、過渡期の零細のやりかたが温存されているのである。企業体質として社内ルールや統制系統を遵守することもできないのだから、軽過失ではない。

「重過失」という法律用語があって，重過失と認められるか否かで賠償金額などが変わるという話らしい．

なお、重過失の意味については、最高裁判所が以下のように判示しています。

（最高裁判所昭和３２年７月９日判決）

重大な過失とは、通常人に要求される程度の相当な注意をしないでも、わずかの注意さえすれば、たやすく違法有害な結果を予見することができた場合であるのに、漫然これを見すごしたような、ほとんど故意に近い著しい注意欠如の状態を指すものと解するのを相当とする。

システム担当者のための法律相談 受発注で泣かずにすむ本

http://www.junya-matsushima.net/article/14440215.html

重過失（じゅうかしつ、gross　negligence）

　著しい過失よりも更に重い、故意に比肩する重大な過失をいう。なお、著しい過失と重過失が修正要素として区別されている場合には、それぞれ与えられる数値は択一的に適用され、重複しては適用されない。例えば、重過失があったとされる場合には、当該掲げられた数値を減ずれば足り、更に著しい過失の分の数値を減ずるわけではない。

　車両一般の重過失の例としては、酒酔い運転、居眠り運転、無免許運転、おおむね30km以上の速度違反（高速道路を除く）、過労、病気及び薬物の影響その他の理由により、正常な運転ができないおそれがある場合（道路交通法66条違反）等が挙げられる。

　自転車特有の重過失としては、制動装置不良、明らかな高速度進入が挙げられる。自転車の「明らかな高速度進入」とは、坂道をノーブレーキで下ってきた場合など高速度であることが容易に推認できる場合のみを意味する。　

http://www.jikosoudan.net/article/13670898.html

「ヘビーなラノベ」である「なれる！SE」みたいなもんですかね．

なれる!SE (7) 目からうろこの?客先常駐術 (電撃文庫)

http://www.animate-onlineshop.jp/products/detail.php?product_id=1167036

http://b.hatena.ne.jp/entry/www.firstserver.co.jp/news/2012/2012073101.html

• id:nanoha3 ケアレスミスで超事故る設計ってどうよ
• id:houyhnhm 経緯は分かったけど、何故パッチ当てる前にシステムバックアップしてなかったのか、そこが知りたい／ブクマ家にマニュアルがバグってるという観点が無いのは不思議。

• id:JULY いろいろ思うところがあるけど、担当者Aが、なぜ独自方式にこだわっていたのかが知りたい。単にAの問題なのか、使うことになっていた配布システムに問題は無かったのか。

• id:rryu 担当者A以外の担当者はいたのかという疑惑が…
• id:cu39 「担当者A」にほぼ全てを負わせてるけど、実在するんだろうか……。

再発防止策を発表

http://www.itmedia.co.jp/news/articles/1208/10/news051.html
http://internet.watch.impress.co.jp/docs/news/20120810_552814.html
http://support.fsv.jp/urgent/fs-report.html
メモ

*1:ひょっとしてこの報告書って，pdfなのに画像扱いで検索不可？？「バックアップ」などのキーワードで検索してみたら検索結果0件だった．ワードか何かで作ったのを印刷した後，スキャンして作ったっぽい感じ．検索されて真相が露呈するのがそんなにイヤですか．

*2:「冷たい方程式」 http://el.jibun.atmarkit.co.jp/pressenter/all_entrylist.html

*3:「なお例によって君もしくは君のメンバーがミスを犯し，或いは逮捕拘束されても，当局は一切関知しないのでそのつもりで．成功を祈る．」なノリだ．丸投げするだけで責任は取らない責任者たち．