「何も起きない」を作る仕事。AI時代に、インフラエンジニアの価値が高まる理由
システム障害が起きると、注目が集まります。
業務システムの停止やネットワークの接続不良、予定していた処理の遅延など、障害の現れ方はさまざまです。
利用者は困り、現場は原因究明と復旧に追われ、影響が大きければニュースにもなりますが、システムが問題なく動き続けた日は、ほとんど話題になりません。
朝、業務システムにログインし、メールを送る。夜間バッチは予定通り終了し、必要なデータも決められた時間までに処理されている。
こうした「いつも通り」は当たり前に見えますが、安定した状態が自然に続いているわけではありません。
異常の兆候を確認し、影響が広がる前に原因を調べる。同じことが起きたとき、誰が対応しても迷わないように判断根拠を残す。
インフラ運用の仕事は、障害が起きてから直すことだけではありません。
「何も起きない状態」を、維持し続ける仕事でもあります。
では、AIや自動化が広がるなかで、この仕事はどう変わるのでしょうか。
AIや自動化で、確認する仕事は速くなる
インフラ運用では、以前から自動化が進められてきました。
監視や定型作業、ログの収集・確認、決められた設定作業などです。
PowerShellやPythonで処理を自動化することもあれば、AIを使って大量のログを整理したり、過去の事例を探したりすることもできます。
人が一件ずつ情報を集めていた作業は、これからさらに速くなるでしょう。
確認や情報収集が速くなるほど、これまで一つの「障害対応」に見えていた仕事の中身も見えやすくなります。
集めた情報を、どう読むのか。
その結果から、何を除外できるのか。
次に、どこを見るのか。
インフラエンジニアが持つ「判断力」という言葉は、少し抽象的です。
実際の障害対応を見ると、その中身が分かります。
エラーログがないとき、何を見るか
ある夜間バッチで、JP1のジョブが強制終了し、後続処理に遅延が発生しました。
障害対応で最初に見るのは、該当ジョブのログです。何が起きたのかを知るための基本的な確認ですが、このときはエラーログが残っていませんでした。
「ログがないので原因不明」とすると、そこで調査は止まります。
実際の対応で着目したのは、エラーログが一切ないことそのものでした。
アプリケーションやOSが異常を検知し、その結果として処理が終了したのであれば、通常は何らかのログが残ります。
しかし、今回は残っていない。
そこから、「ログを出力する猶予なく、外部からプロセスを強制終了された可能性がある」とアタリをつけています。
この時点で原因が確定したわけではありません。
見えてきたのは、「アプリケーション内部で検知されたエラーだけを追っていても、原因に届かない可能性がある」ということです。
ログがない。
これは、情報がないという意味ではありません。
残るはずのものが残っていないことも、次の確認先を決める判断材料になります。
経験者は、最初から原因を知っているわけではない
次に調べたのは、ジョブの実行時刻でした。
強制終了したジョブだけでなく、その前の処理まで遡ってみると、3つ前のジョブからすでに約2時間の遅延が発生しています。
ただ、対象となるジョブはすべて正常終了でした。
処理そのものは完了している。となれば、「処理が壊れて停止した」という方向より、「何らかの理由で処理に時間がかかった」と考えた方が状況に合います。
調査の重点も、処理データ量の増加や、ほかの処理とのリソース競合、排他待ちなど、処理時間を延ばす要因へ移っていきました。
この段階でも、原因を当てているわけではありません。
一つ確認した結果から可能性を減らし、残った候補に合わせて次に見る場所を決めています。
経験者の障害対応は、最初から答えを知っているから速いのではありません。
確認結果を使って、調べなくてよい方向を減らしているのです。
「次にどこを見るか」が判断になる
次の確認対象は、OSとアプリケーションのイベントログでした。
ところが、ここにも異常を示すアラートはありません。
対象のサーバーが毎日再起動する構成だったことも踏まえると、ハードウェアやOSの異常で突然停止した可能性は下がります。そこで調査の目は、異常停止ではなく正常な停止処理へ向きました。
サーバーを制御するvSphere側の情報を見ると、制御された時刻とジョブが停止した時刻が一致しています。
基盤側の停止制御に、実行中のジョブが巻き込まれていたのです。
ここだけを見ると、「経験があるから、サーバー再起動を疑えた」と説明したくなるかもしれません。
実際には、ジョブにエラーログがないため外部からの終了を疑い、OSやアプリケーションにも異常ログがないため異常停止の可能性を下げています。
そこに「毎日再起動するサーバー」という情報が加わり、正常な停止処理へ目を向けた。最後に制御時刻とジョブ停止時刻が重なったことで、基盤側の制御による停止と判断しています。
一つの情報だけで原因を決めたわけではありません。
確認した結果によって、次に見る場所を変えています。
これが、障害対応における判断の一つの姿です。
復旧しても、調査は終わらない
サーバーの再起動にジョブが巻き込まれた。
直接の停止理由は分かりました。
しかし、ここで調査を終えると、もう一つの問題が残ります。
本来、再起動する時間までジョブが動き続けていなければ、今回の事象は起きなかったからです。
なぜ、その時間まで処理が続いていたのか。
再び時系列を遡ると、焦点になるのは3つ前のジョブで発生していた処理時間の超過です。
インフラ側のイベントログなどから基盤側の異常を除外したあとは、アプリケーション側へ調査範囲を広げます。
処理データ量に変化がなかったか。
イレギュラーなデータが含まれていなかったか。
ここから先はアプリケーション側の情報が必要になるため、ベンダーへ調査を依頼しました。
今回、ジョブを停止させた直接のきっかけは、サーバーの停止制御でした。
しかし、その時間までジョブが動いていた背景には、先行処理の遅延があります。
停止理由が分かったところで終わらず、「なぜ、その状態になっていたのか」と、さらに一段戻る。
「何も起きない状態」を作るには、この調査が必要になります。
AI時代に重要になるのは、判断の過程
AIや自動化は、障害対応でも多くの作業を支援できます。
ログを集め、過去の障害事例を探し、複数のイベントを時系列に並べる。決められた確認項目の実行も、支援できる範囲は広がっていくでしょう。
情報収集にかかる時間は、今後さらに短くなるはずです。
そのとき、見ておきたいのが判断の過程です。
どの情報を判断材料にし、そこからどの可能性を下げ、なぜ次のログや設定を確認したのか。
今回の障害対応も、「ログを確認した」という作業だけを並べても、対応の中身は伝わりません。
ログがなかったから、外部からの終了を疑った。
正常終了していたから、処理異常よりも処理の詰まりへ候補を移した。
OSの異常が確認されなかったから、正常な停止制御を調べた。
確認結果によって、次の行動が変わっています。
AIを使って大量の情報を速く集められるようになっても、何を確認し、どう読み、次の調査へどうつなげるかは残ります。
技術者の仕事は、作業を一つずつ実行することから、判断の流れを設計することへ、少しずつ重心を移していくのかもしれません。
「何も起きない」を作る仕事
今回の障害対応では、実際の確認順序と判断根拠が、「障害対応判断フロー 兼 形式知化シート」として整理されました。
経験の浅いメンバーでも、確認結果から同じように「アタリ」をつけ、インフラとアプリケーションの切り分けを進められるようにするためです。
何を確認し、なぜそこを見るのか。その結果を、次の判断にどうつなげるのか。
判断の根拠が残っていれば、次に対応する人が迷う時間を減らせます。同じ障害が起きたときの対応品質も、そろえやすくなるでしょう。
熟練者の経験も、一人の中に閉じたままではなく、次の改善に使える知識へ変わっていきます。
システムが問題なく動いた日は、何も起きていないように見えます。
けれど、その裏側には、異常の兆候を見つけるための確認があり、障害が起きたときの判断があり、その判断を次の人へ残す仕事があります。
「何も起きない」を作る仕事とは、障害が起きないことを祈る仕事ではありません。
起きたことを調べ、確認結果から次に見る場所を決める。直接のきっかけが分かっても、その背景まで遡り、そこで使った判断根拠を次の人が使える形にする。
AIや自動化によって、確認する作業はこれからも変わっていくでしょう。
その変化のなかで、インフラエンジニアの役割も、「自分が作業できること」だけでは測れなくなっていきます。
何を見て、どの可能性を除外し、次の確認先をどう決めるのか。
その判断の過程を設計し、繰り返せる形にする。
「何も起きない」という目立たない一日を支えているのは、こうした仕事の積み重ねです。
インフラ運用や、AI・自動化によって変わるエンジニアの仕事について、これからも現場の事例を交えながら考えていきます。
ディーシステムの「ENGINEERING／技術・運用」では、障害対応、運用改善、技術の形式知化など、実務の中で見えてきたことを紹介しています。
気になるテーマがあれば、ぜひほかの記事もご覧ください。
