連休明けのシステム障害
システム障害が多発しています。
昨日は銀行系のシステム障害が多かったのですが、今日はJALにて発生しています。
日本航空（JAL）の国内線チェックイン関連のシステムで2019年5月8日朝に障害が生じ、「タッチ＆ゴー」と呼ばれるチェックイン機能が使えなくなっている。
同日朝6時50分ごろ、国内線のチェックイン機能を担う複数のサブシステムの1つ「J-Server」に不具合が起こった。これにより、羽田をはじめとする各空港の国内線において「自動チェックイン機や保安検査場の搭乗者確認端末にICカードやおサイフケータイ、QRコードなどをかざして搭乗者や搭乗便のデータを参照できなくなった」（JAL広報部）。不具合の具体的な内容や原因などは判明していない。
偶然ではない
システム運用の経験から評価すれば、システム障害に偶然はありません。かならず根本原因がありますが、その発生するタイミングがごくごく小さいため、偶然と表現されがちなのです。特に連休明けは障害確率が上昇します。これに理由があります。
いくつかの必然性を表現してみます。
平日運用／休日運用の品質の差
24時間運用を行っているセンターであっても、どうしても休日は人が少なくなります。オペレーターは24時間シフトを組んで人数を確保しているかもしれませんが、設計者や保守担当者などの技術者は手薄となりリモートでの対応が主となります。また、作業承認をする管理職も基本的には休みのため、緊急作業だけしか実施しないのが休日対応です。
連休の間に何らかの変調があっても、基本的には連休明けの対応とするのが主です。大きな変更をして問題が発生しても人が手薄なためリスクになるからです。人がそろっている平日に持ち越すのがセオリーです。
しかし、10日間ともなると、見逃しや、先延ばししたことによる問題が起きがちとなります。また10日間に累積した休日明けの作業を、5月7日にまとめて実施することにより、作業を短期間に詰め込むこととなります。作業品質が低下したり、複数の作業が影響しあって障害要因となります。
また、平日運用ではスペシャリストの数も多いので、障害予兆に対して敏感です。障害はいきなり発生せず、その予兆があることが多いです。10連休は確実に予兆を捕まえずらくなるので、このタイミングは不思議ではありません。
大型連休中に変更を行うケースが多い
今回のJALのケースだと、実は2019/5/14にJALの国内線航空券の予約サイトリニューアルを一週間後に控えています。
JAL（日本航空）は、国内線の航空券予約サイトを5月14日にリニューアルする。分かりやすく情報を伝えすることを目指して、デザイン・情報量を見直し、予約・購入の手順を削減。スマートフォンでの操作性をさらに改善するとしている。
関連性は不明ですし無関係かもしれませんが、昨今のシステムは連携しあっています。あるシステムは凍結していたとしても、別のシステムが変更したために連携エラーとなることは十分ありえます。
システムは、基本的に変更せずリソースに問題がなければ、安定します。
連休中に大型変更の準備や、そのための軽微な変更を行うことがシステム障害につながることは本当によくあることです。
システムの利用頻度が急増した直後にハードウェア障害が起きやすい
最近はどんどん仮想化、抽象化され、ハードウェアの存在をあまり気にしなくなっています。しかし、結局はハードウェアでシステムは動いています。
ハードウェアは物理的な機構です。たくさん動かせば故障率が上昇します。熱を持つほど壊れやすくなりますし劣化していきます。
連休中によりシステムが稼働するということは、よりハードウェアも動かされたということで、連休中に故障が発生するのは当然ですが、意外とその稼働が終わった後に故障が発生することもよく経験しました。
ハードウェア故障の報告書には、「偶発的な」「稀な」と言った言葉が並ぶのですが、その発生タイミングには傾向があることを知っています。
ログが増える
連休中にシステムの利用が増えたことを前提としますが、端的にログの量が増えます。安定運用している場合には忘れがちなのですが、急にシステム利用が増えるときはログが増えストレージを圧迫します。ログを保管するストレージをシステムボリュームが同居している場合も多く、その場合はシステムの動作に影響を与えます。また、ログに書けないことで異常をきたすシステムもあります。
また、この状況が発生する場合、システム利用が増えた時ではなく、それが落ち着いた連休後に実は連休中のログが肥大化していてバックアップ時にバックアップ用ストレージにログが移動できず、バックアップが失敗するということもありました。
急に利用が増えるシステムの場合は、ログの急増を気にする必要があります。
「何も起こっていないシステム」の運用担当者にご褒美を
システム運用や保守は、結構地味です。
何も起こらなくて当たり前。何か起こったら怒られる。
BtoC系のシステムだと、ツイッターが炎上し不満や怒りに満たされます。昔は2ちゃんねるのスレッドだったのですが今はSNSになりましたね。
ですから、システム運用担当者は毎日ビクビクして過ごしています。私もそうです。
でも、システムエンジニアとして評価されがちなのは、アプリケーション開発エンジニアです。表舞台にも立ちやすい。インフラの世界でも、構築が花形で運用は下支えでした。
結局、IT業界でも長い間、運用系のインフラエンジニアは日蔭の存在だったのかなと思います。
ただ、昨今、ビジネスのデジタル化に伴い、サービスを平常に整える運用系エンジニアの価値は正直うなぎのぼりだと思っています。何も起こらないようにする設計を施せるインフラエンジニアの市場価値は大きいです。作った後に変更するのは大変なので、設計時にこれを施せる人は市場でもひっぱりだこです。そこにクラウドサービスの構築・運用が加わればさらに強いでしょう。
ぜひ、この連休中にシステムに何事もなく、かつ連休明けの様々な対応も無事にこなした運用部門や担当者には、高い評価をしてほしいです。あまりにも10連休には地雷がたくさんあり、かなりの難易度を感じました。
企業活動とデジタルビジネスの結合度はさらに強くなり、その依存度も上がってきます。「何も起こっていないシステム」を作る責任はさらに上昇します。これを実現した運用担当者にはそれなりのご褒美をあげてほしいなあ・・と思います。
