Point
1. 公的個人認証サービスがシステム障害により停止した
2. 障害を防ぐための稼働確認作業が，慢性的な遅延により目的を果たせず
3. システムを改修し，運用方法を定期的に見直すことで再発防止へ
電子自治体の基盤となるユーザー認証サービス（公的個人認証サービス）を全国の市区町村に提供している自治体衛星通信機構は，2005年1月27日にシステム障害に見舞われた。前年に発生した障害を受けて取り組んだ再発防止策が目的通りの役目を果たせず，今回の障害原因の一端となっていた。
サービス開始から23分間停止
障害は，公的個人認証サービスを構成するシステムの一つで発生した。地方自治体の窓口端末からデジタル証明書の発行・失効の依頼を受け付ける「認証局受付」というサーバー・アプリケーションが異常停止していたのだ。
同機構では，午前8時30分のサービス開始に備えて，7時からオペレータがシステムの稼働状況を確認している。サーバー・アプリケーションの異常停止は，この稼働確認作業を通じて8時25分に見つかった。
オペレータは，ただちにベンダーSEとシステム管理者に連絡。事前に用意していた復旧手順書に従ってサーバー・アプリケーションを再起動させた。本来より23分遅れの8時53分にサービスは復旧した。
この間，同サービスを利用する地方自治体の窓口では，証明書の発行・失効に関する業務ができない状態だった（図1[拡大表示]）。幸い，証明書を発行・失効しようとした住民がいなかったために，実害の発生だけは免れた。
シェルが勝手にプロセスを止めた
ログや直前の保守記録などを分析した結果，前日（1月26日）の夜間に実施した認証局受付サーバーの保守作業の直後に，サーバー・アプリケーションが停止したことを突き止めた。保守作業の内容は，認証局受付サーバーの設定値の変更だ。類似の作業は2004年1月29日に公的個人認証サービスを開始して以来，何度となく実施しており，障害前日の作業もそれ自体は問題なく完了していた。
では，何が障害を引き起こしたか。引き金を引いたのは，保守担当者が保守コマンドの呼び出しに利用した「シェル・プログラム」だった（図2[拡大表示]）。同機構が採用していた商用UNIXの場合，保守担当者が平常時に使っていたシェル・プログラム「C shell」では，シェルを終了してもシェルから起動したアプリケーション（子プロセス）は稼働し続けた。ところが，1月26日の保守作業でたまたま使ったシェル・プログラム「Bourne Shell」の挙動は，C shellと違っていた。シェルの終了に伴い，子プロセスまで自動的に終了させてしまったのだ。
一般にはあまり知られているとは言い難いが，こうした挙動の違いは珍しいものではない。本誌がUNIX/Linuxベンダーの協力を得て調査した範囲では，シェルの終了時に子プロセスを終了させるか否かは，OSの種類，シェルの種類/バージョン，子プロセスの起動方法などの組み合わせで，微妙に異なる。
例えば，同じBourne ShellとC shellを比べても，自治体衛星通信機構が採用している商用UNIXでは挙動に違いが出たが，別ベンダーの商用UNIXでは差が出なかった。また，C shellとPOSIXベースの「sh」を比べたときに，自治体衛星通信機構と同様の違いが出るケースもあった。
こうしたシェルの挙動の違いを想定し，使用すべきシェルの種類/バージョンを手順書に明記しておけばよかった。だが，自治体衛星通信機構で利用していた当時の手順書に，そのような記述は無かった。そのため，シェルの種類やバージョンによる挙動の違いを知らなかった保守担当者は，個人的に使い慣れたBourne Shellを使ってしまった。
当夜の保守作業を終えた担当者は，Bourne Shellから認証局受付アプリケーションを再起動し，正常稼働を確認。そのままBourne Shellを終了した。このとき，起動したはずの認証局受付アプリケーションまで意図せず終了した。正常稼働したと思っている保守担当者が，認証局受付アプリケーションの終了に気づくはずはなかった。
平常時と異なるシェル・プログラムを用いた保守担当者を責めることは簡単だが，自治体衛星通信機構は保守担当者のミスを大きな問題とは考えなかった。「手順書に記載されていない以上，単純に保守担当者のせいにはできない」（公的個人認証サービスセンター 技術主査 藤井秀彦氏）からだ。原因を掘り下げ，（1）テストやレビューを通じてシェルの挙動の違いを洗い出せなかったこと，（2）認証局受付アプリケーションがOSのプロセス終了命令（SIGHUP）に反応する作りだったこと——に根本原因を見出した。
