８月に私のチームに所管が変わったシステムが先週からトラブった。７月にも似たようなことがあったが、伝送処理が遅延して40時間もの滞留が発生したのだ。
私もいろいろとシステムトラブルは経験しているが、最近は開発・品質の管理手法が向上したためか、トラブルの原因はプログラム不備よりもサーバ本体やネットワーク機器周りの故障や動作不良が多くなっている。複数のシステムが連携している場合は原因の特定、影響の切り分けに時間がかかることもあるが、それでも最後は再起動や部品交換で復旧する。事業会社の立場では直接の復旧対応はベンダにお任せで、業務影響の整理と顧客調整、問い合わせ（クレーム）対応くらいしかやることがない（といってもユーザの多いシステムの場合、その顧客調整がかなりハードかつ重要）。
だが今回のトラブルの原因は故障や機器の不具合ではなく、ウィルス対策ソフトの入れ替えによって生じた処理性能の悪化だった。メモリもCPUもディスクも余裕があるのに、ウィルス対策ソフトを入れ替えた後で伝送処理に謎の待ちが生じてしまっていた。アプリベンダ、基盤ベンダ、ウィルス対策ソフトベンダ共に真の原因を特定できない中では、復旧対応を「ベンダにお任せ」と言うわけにはいかない。各ベンダの間に入って情報を共有し、対策を検討し、出来ることを進めていくしかなかった。
在宅勤務でトラブル対応の中心には立てない
処理遅延の予兆が出始めた日の翌日は在宅勤務の予定にしていたが、出社することにして正解だった。
在宅でもベンダとのやり取りは電話やメール、Teamsで支障はない。だが遅延の原因が特定できない中で遅延・滞留はますます悪化し、各所からの問い合わせも多発する。そんな中、事業会社内の上席やメンバ間で状況を把握・整理・共有するには対面が一番効率がいい。ベンダと電話しているのか、パソコンに向かってなにか確認しているのか。各メンバがなにをしているかが一目で分かるし、部長に報告しに行くタイミングもつかみやすい。また、お互いの表情を見ればそれだけで伝わることも多い。
実際、グループ長や部長は事あるごとに私の席を訪れ、状況の確認や対応の相談をしていった。またその日は数度にわたって関係者が集まって対策会議を開き、暫定の復旧方針が決まったのは20時を越えた。そして復旧対応にとりかかり、遅延・滞留の目途が確認できたときは朝を迎えていた。その間、私だけでなく部長やグループ長も、オフィスに残って復旧対応の効果を見守りつつ、今後の対応を協議した。
その時の状況を在宅勤務中にチャットや電話で再現するのは無理だろう。チャットで指示・報告する場合はすぐに既読にならなければそれだけでコミュニケーションロスになるし、ストレスも発生する。今回の場合、もし私が在宅勤務だったらグループ長や部長に対してストレスを与えていただろうし、トラブルの原因でもないのに悪者になっていたかもしれない。
徹夜でトラブル対応をしていたら、周りのチームからもお菓子やお茶の差し入れがあったり、深夜には部長自らおにぎりを振る舞ってくれたり、労いと感謝の言葉もかけてもらえたりもする。もし在宅勤務で徹夜しても一体感は生まれず、信頼感を与えたりアピールもできない。逆に信頼を損ねてマイナスの評価を得かねない。出社してトラブル対応にあたったかどうかで、評価・印象に天と地ほどの開きが生まれる。
ベンダとの距離が離れていても、Teams会議で資料を共有しながら対策を話し合うことができるのは、オンライン環境が整ったことの恩恵だ。一昔前でも複数拠点を繋いだ電話会議はできたが、会話した内容をメモ帖に書いてタスクを整理し、会議で話したことを共有するなんてことはできなかった。会議で決まった内容をメール等で送り直して復旧対応にあたるのはどうしても遅れが出るし、コミュニケーションロスも発生する。その点、今はとても便利になった。だがそれでもやはり、体面でのコミュニケーションに勝るものはない。トラブル時など急を要するときはなおさらだ。
もしあの日私が在宅勤務していたら、おそらくグループ長がトラブル対応の中心に立ち、私はサポートに徹せざるを得なかった。グループ長はTeamsを使いこなすタイプではないので、おそらくいろいろなタスクを私に振る事はせずに、一人で抱えて対処してしまっていたと思う。トラブル対応の中心にたって旗振りをするのに、やはり在宅勤務では限界があるのだ。
「仕様」だから、で片づけてはいけない
今回のトラブルでもう一つ教訓として学んだことは、引き継いだばかりで十分に理解できていないシステムであっても「仕様」で片づけてはいけない、ということだ。
どれだけ大量に配信があっても一定の件数しか一度に処理できない仕様であり、特定の処理の優先度を上げたりスキップすることはできない。それならせめて、一度に処理する件数を増やせばよいと最初に思いつきそうなものだが、過去の経緯が分からないこともあって「一定の件数しか処理できないのはなにか理由があるのだろう」と思い込んでいた。
だが深夜に及んだ対策会議において、ウィルス対策ソフトの機能を停止しても事態が改善せずに打つ手がなくなりかけた時に基盤ベンダの担当が「処理件数は増やせないのか？」と発言したことで、事態は一気に改善へと進んだ。
アプリベンダ曰く、システムの構築当初は処理件数制限はなかったものだが、利用が拡大するにつれて一度に伝送する件数が膨れ上がって遅延を生じるようになったことから、数年前に処理件数を設定したとのこと。そしてその設定件数に特別な意図があったわけでもなかった。また、幸いにもその件数設定は設定ファイルで指定されており、設定を変更してサービスを上げ直せば変更後の件数が反映されることが分かった。一度に処理する数を増やすとリソース面が心配になるが、謎の待ち時間のせいでＣＰＵもメモリもガラ空きの状態なので、一度の処理件数を増やすことに何も問題はなさそうだ。むしろ大量に滞留・遅延が発生している中では唯一絶対の対策だった。
対応方針について部長席に報告、承認をとり、念のためリソースを確認しながら処理件数を増やしていく。５倍まで増やしたところで滞留解消の目途がついた。CPU使用率も許容範囲に収まっている。そして土日で滞留分はすべての配信が終わり、週明けからようやく正常な状態に復旧できた。
直接の原因はウィルス対策ソフト導入の可能性が高く、その観点での対策ばかりを考えていたが、そもそもアプリの仕様・設計にも問題があったのだ。そして処理件数の設定があることは私も認識していたのだが、その設定値に妥当性があるかどうかを疑っていなかった。違和感は持っていたのだが、しかたがないよね、で片づけようとしていた。
私が開発する側の人間であり、日々システム設計をするまたはレビューする立場であれば、今回の対応はもっと早く気づけたはずだ。いや、ユーザ側の立場であったとしても、納得のいかない仕様があれば妥当性を確認すべきだった。中途半端に引き継がれたという被害者意識が邪魔をして、現状を無責任に受け入れてしまっていたのだろう。経緯はどうあれ、今そのシステムの所管は私であり、安定稼働させる責任を負わなければならないのに、心の中で言い訳をして現実から目を背けてしまっていた。
多くの人たちのサポートによって障害は収束に向かっているが、当事者意識の欠如は強く反省しなければならない。
まだまだ続く、障害対応
一旦の遅延は解消したが、根本原因の究明や再発防止策、品質管理担当への報告などやることは盛りだくさんだ。しかも今回の遅延は更改前のシステムで発生しており、更改後の環境でも同様の事象が発生するかを確認しなければならない。もし新環境でも同様なら、並行して更改後環境の対処も進める必要がある。徹夜での対応の疲れも抜けきってはいない。だが、普段とは違う経験をする中で多くの学びが得られることもまた、トラブル対応の醍醐味ではある。
なんとか乗り切って私自身のスキルアップ、評価アップを勝ち取ってやろう。