6月24日にモバイルSuicaなどJR東日本でサービス障害、原因は操作手順書ミス 36
ストーリー by nagazou
そりゃ間違える 部門より
そりゃ間違える 部門より
2023年6月24日、JR東日本のシステムにトラブルが発生し、この影響でえきねっとやモバイルSuicaアプリの予約、変更、取り消し、チャージ、Suicaグリーン券の購入、JR東日本びゅうダイナミックレールパックの予約や取り消しなど、モバイルSuicaアプリへのログインを必要とする全てのサービスと会員メニューサイトが利用できない状態となった。この不具合は同日13時に解消された（モバイルSuicaでの案内、Impress Watch、トラベル Watch、ITmedia）。
JR東日本はこのシステムトラブルの原因に関して26日に発表をおこなった。24日の段階では「システムサーバの電源トラブル」と説明されていたが、発表によると同日の電源工事で操作手順書に誤りがあり、その手順書をもとに作業員が工事をした結果、ハードウエアの故障や関連データの不整合が発生したという。一連の障害により、サービス利用者から1000件弱の問い合わせがあったとしている（日経新聞）。
JR東日本はこのシステムトラブルの原因に関して26日に発表をおこなった。24日の段階では「システムサーバの電源トラブル」と説明されていたが、発表によると同日の電源工事で操作手順書に誤りがあり、その手順書をもとに作業員が工事をした結果、ハードウエアの故障や関連データの不整合が発生したという。一連の障害により、サービス利用者から1000件弱の問い合わせがあったとしている（日経新聞）。
作業員の質かな？ (スコア:2, すばらしい洞察)
https://www.itmedia.co.jp/news/articles/2306/27/news079.html [itmedia.co.jp]
マニュアルには本来「盤NO6（CV6）内のブレーカーを『切』にする」と記載されるべきところ、「盤NO6（CV4）内のブレーカーを『切』にする」と書かれていた。
作業スタッフがこの誤りに気づかず、「盤NO4（CV4）」のブレーカーを切ったため、夜間処理中のシステムへの電源供給が止まり、ハード故障やデータ不整合が発生した。
この手順書を見て疑問に思って手を止めない作業員はちょっとヤバい。
手順書を作った社員と現地で作業にあたった社員が同じだった (スコア:4, 参考になる)
モバイルSuica障害…原因は操作手順書に誤り JR東日本 [livedoor.com]
あるあ…あるあるｗ（目をそらしながら
Re: (スコア:0)
＞この手順書を見て疑問に思って手を止めない作業員はちょっとヤバい。
そうなんだけど、
＞手順書を作った社員と現地で作業にあたった社員が同じ
なんか、有りそうな話ね。
でも、複数人で相互チェックして作業してないの？
Re:作業員の質かな？ (スコア:1)
聞けよって気持ちは分からんでもないが、ちゃんと現地で着手前打合せしてたらこんなミス起きないと思う。
本質的には個人の問題ではなく作業管理(プロセス)の問題だと思うな。
Re: (スコア:0)
あー、「盤NO違うけど、CV4だからあってるやろ！」って奴が発動したのですか…。
これは作業員・作業指示者は怒られそうですね。
現地情報と手順書に矛盾が有る場合は、必ず作業を一時中断し確認すること。は大事ですからね…。
私も手順書が誤っていて「ちょっと待って！」をしたことが何度かあります。
Re: (スコア:0)
一作業員の判断で作業が停まるなんてそっちの方が問題。
Re:作業員の質かな？ (スコア:1)
え？
一作業員の判断で作業が止められないのなら、そっちの方が大問題じゃないですか？
オペミスを防ぐ最後の砦なんだから。
Re:作業員の質かな？ (スコア:1)
こういうのは手順書作成者、そして事前のレビューで気づかなかった奴に責任がある
作業者は手順書が100%正しい前提で、マシンのごとく正確確実にオペレーションを行うことが仕事
つか手順書作成者がそのまま作業すんなよと
Re: (スコア:0)
「手順書に矛盾がある場合は作業を止めて〇〇する」という教育が必要。
教育受講後の作業員しか作業禁止。
そういうことをしないなら、作業員が悪いとは言えない。
言っちゃったらもう改善しようがない。
Re: (スコア:0)
指差し確認しないからだろ
盤ナンバー ろく！ よし！
盤ナンバーろくのブレーカー！ かくにん！
盤ナンバーろくのブレーカー！ 状態オン！ かくにん！
盤ナンバーろくのブレーカー！ 切断する ブレーカーきり！
盤ナンバーろくのブレーカー！ 切断！ かくにんよし！
てか、カッコの中のCV4はどこだどこだで盤のブレーカーラベルを探したんじゃなねーのかな？
CV4めっけたから、あったあった、これだでバッチンやっちゃんてない？
手順書に盤とブレーカーの位置まで図示してないといけなかったやつちがうか？
作業前の手順チェックで盤とブレーカーの位置関係を把握してないと危険、きけん
Re: (スコア:0)
マニュアルには本来「盤NO6（CV6）内のブレーカーを『切』にする」と記載されるべきところ、
「盤NO6（CV4）内のブレーカーを『切』にする」と書かれていた。
作業スタッフがこの誤りに気づかず、「盤NO4（CV4）」のブレーカーを切ったため、
この手順書を見て疑問に思って手を止めない作業員はちょっとヤバい。
「盤NO6(CV6)」「盤NO6(CV4)」「盤NO4(CV4)」いずれのブレーカーも有るなら作業員のポカだけど
盤NO とCVのNOが同じものしかない⇒(CV4)の文字を見て盤NO4(CV4)のブレーカーと認識した。という流れなら
実質一意の管理項番をわざわざ複数回記す(そして片方だけ書き間違える)のがよろしくないかな
Re: (スコア:0)
元々は盤NO4(CV4)だったのが設備の増設などで変更が入って、手順書の改版で盤NO6(CV6)に直しそこねたとかなのかな。
それとも他の類似の手順書を流用して、手順書の変更で盤NO6(CV6)に直しそこねたとかなのかな。
手順書というのは、手順書が理解出来なくても、手順書の作業を間違えても、問題が起きないように作るもんだ、と言われた。何かやらかしても安全側に倒れるようにと。
なるべく手順書は新規に作るなとも。誰がその手順書の正しさを保証できるんだと。正しい一面もあるから反論はしなかったが、モヤッとしたのは事実。
日経の記事の識者コメント (スコア:1)
日経の記事についている識者コメント（東大の教授）で、LinuxはWindowsやmacOSに比べて突然の電源断によるファイルシステムの不整合が発生しやすい、という趣旨のことが書いてあるのがもにょる。
ファイルシステムによるだろ、とか、そもそもUPS組んでなかったのか、とか、他に指摘するところがあるだろうに。
Re: (スコア:0)
1000件弱の問い合わせを受け入れられる電源は止まってない指摘とか（どうせ別の場所でしょうけど）
Re: (スコア:0)
多重化とかはどうなってたんかな？メインもサブも全部同じ場所同じ電源？改札のチェックもサーバ経由にするって聞いたけど、大丈夫かという不安はあります。モバイルSuicaユーザなんで。
Re: (スコア:0)
トラブル内容をみるにデータベース関連だろうに
ファイルシステムって・・
Re: (スコア:0)
なんて名前かわすれたけど、そのコメントはLinuxは書き込みシステムコールが非同期って話をしてるんじゃない？
FreeBSDは同期だとか、syncコマンドはおまじないで3回実行とかの
windowsやmacが同期かどうか知らないけど
Re: (スコア:0)
ntfsもxfs, ext4もジャーナルだから理論的には似たようなもんなんだけど、
実戦経験の数が違うのよ。
かたや、syncせずに落としてファイルシステムが壊れたら、素人が何やってんだ、とオペレーターが叱責されるOS、
かたや、電源ぶち抜きでファイルシステムが壊れたら、どんなヘボソフトだ、素人か？と、メーカーが叱責されるOS。
どんなバカが扱ってもそれなりに耐えられないと、コンシューマOSにはなれない。
Re: (スコア:0)
何度か読み直すと
「サーバ用ＯＳでは、パソコン用ＯＳと違い、多くのデータがディスクに書き込まれずに、メモリ上に残っていることがありますので、サーバが予期せず落ちると、データの破壊や不整合が起きて致命的な状態になる場合が多いです。」
と書いた方が語弊がないとは思った。
結局、Windows Server OSでも同じなわけだし。
>LinuxはWindowsやmacOSに比べて突然の電源断によるファイルシステムの不整合が発生しやすい
元の文章にも問題はありますが、正直、あなたの読解力には問題があると思います。
操作手順ミスと言わないといけない。 (スコア:0)
これが通常の作業で発生した場合、原因追及とシステムの信頼性の問題となる。
人為的なミスならそれ以上の追及はない。
Re:操作手順ミスと言わないといけない。 (スコア:1)
ブレーカーを間違えたといっても操作ミスじゃなく手順書作成ミスとなると電気設備の図面と突き合わせチェックしてなかったのかなとは思うね。
そもそもそういうレビューをするというプロセスになってないんだとしたらそこが改善点になるし。
現地作業の着手前に打ち合わせしてると思うんだけど、そこで手順書と図面をにらめっこして、今日はこのサーバの作業なんでこのブレーカー切りますねとかやらなくていいのかなとか。
手順と図面をにらめっこしてもどのブレーカー切ったらどのサーバに影響が出るのかわからないとしたらドキュメントを見直さないといけないと思うな。
こういうところの電源設備なんてよく知らないけど、電気設備絡みとなると、極論、コンピュータが壊れたぐらいで済んで良かったねまであるんじゃないかと。
Re: (スコア:0)
電鉄系って電源周りも自社がやってたりするから怖い。
コールドとアースが逆になってたなんてミスが稀にあったし、アースに200VでUPSが逝った事もあった。
Re: (スコア:0)
え？
Re: (スコア:0)
このスレッドは、お互い言葉足らずですねえ～。
人為的ミスの場合、再発防止策をセットで出さないといけないですね。
Re:操作手順ミスと言わないといけない。 (スコア:1)
このスレッドは、お互い言葉足らずですねえ～。
人為的ミスの場合、再発防止策をセットで出さないといけないですね。
そのうち
Breakerでぶっ壊したので正しい
になったりして
Re: (スコア:0)
雑魚システムならそれで報告書通るかも知れないが、このレベルは無理だろ。
対策会議とか開かれて、担当SIerに厳しい突っ込みが入る地獄の会議が。
Re: (スコア:0)
電源工事の作業ミスでSIerが責められるってどういうことやねん！
Re: (スコア:0)
そこに機械置く決めたのは、あんたんちの人でしょ
Re: (スコア:0)
マニュアルを書いたのは誰だSIerだ裁判だ訴えてやる。
Re: (スコア:0)
ほんとは設備が悪いのに下手に表に出てるせいでまず矢面に立たされるのはシステム作った側
# この件はちゃんと原因出てるけど、最初はシステム作った側が責められたんだろうなぁなんて思ってしまう
Re: (スコア:0)
間違いに気づきようがないド素人でもいける、えー、そこから説明いるの…って感じの操作手順書作るのも冗長でくっそダルいんだよな。
こういう手順のミスで致命的なことになってしまうのは、運用でカバーが招いた悲劇で、設計で何とかすべきではないか。
鉄輪環境以外は (スコア:0)
指差呼称を廃止？
Re: (スコア:0)
作業手順書が間違っているのだから、指差呼称をしても結果は同じ。
手順書を作る段階でレビューを行っていないから、操作対象を間違えていることに気づかない。
今回うまくいったとしても次は違うトラブルに見舞われるかも。
# 鉄輪環境? 一瞬温泉(かんなわ)となにか関係がと思ってしまった。
本日17:00現在でまたトラブルっぽい (スコア:0)
今度は電源入れ間違えたとかですかね
https://twitter.com/JR_Mobile_Suica/status/1673603145300328449 [twitter.com]
Re:本日17:00現在でまたトラブルっぽい (スコア:1)
https://k-tai.watch.impress.co.jp/docs/news/1511960.html [impress.co.jp]
今回はApple Pay側の障害らしい。
Androidの方は影響出ていなかったようで。
電流確認しないの？ (スコア:0)
うちの会社の電源工事の手順だと、配電盤で工事する前に電流値確認があるので、生きてるサーバをいきなり落としたりしないようにしてるよ。
サーバとかスイッチとか電源抜いておかないとダメなので、それはそれで面倒なんだけど。