復旧が間に合わない誤算
さらに，障害を未然に防げなかった間接要因を洗い出した。同機構は，午前7時からシステムの稼働状況を順次確認しているので，本来ならばその過程で発見した障害はサービス開始時刻までに復旧できるはずだったのだ。
実は，前年から障害防止を目的にサービス開始前の稼働確認作業を拡充していたことがあだとなり，復旧時間が奪われていた。（図3[拡大表示]）のように，認証局受付サーバーの稼働確認は午前7時30分に作業を開始する予定だった。ところが実際に作業が始まったのは，前工程の遅れに伴い，予定時刻を35分過ぎた8時5分だった。稼働確認が予定通り始まっていたら，障害発生の認識に20分，復旧作業に28分を要したとしても8時18分。8時30分のサービス開始にギリギリ間に合っていた。
稼働確認作業が遅延した理由は，2004年7月以降に作業内容を大幅に拡充したことにあった。自治体衛星通信機構は2004年5月26日～7月26日，証明書の失効データが正常に同期できない障害により，失効すべき証明書を放置するというトラブルを経験した。同機構は「電子自治体の信頼性を揺るがしかねない深刻な事態」（同センター 副センター長 田代信司氏）と認識し，一丸となって再発防止に取り組んできた。その具体策の一つが，サブシステム間で失効データが正しく同期されたかどうかの整合性を確認するといった稼働確認作業だった。
「作業量が増えても，担当者の習熟度が上がれば，人員を増やさなくてもカバーできるはず」——。そんな同機構の期待とは裏腹に，2004年末ごろにはオペレータの作業が過密状態となり，遅延は常態化していたようだ。「（サービスの信頼性を回復したい一心で）確認項目の追加ばかりに視線が向いていた。現場の作業スケジュールや復旧時間などへの配慮が十分ではなかった」（田代氏）と課題を痛感する。
「一時の改善策に安心できない」
2005年1月の障害を受けて，自治体衛星通信機構は再発防止に取り組んでいる（図4[拡大表示]）。
直接原因であるシェルの挙動の違いを吸収するため，三つの対策を実施済みだ。(1)保守担当者が想定外のシェルを使用しないように，手順書にC shellの利用を明記した。(2)手順書作成時にレビュー不足を見逃さないよう，手順書の品質をチェックするリストを作成した。(3)万一，保守担当者が想定外のシェルを利用した場合に備えて，認証局受付アプリケーションをOSのプロセス終了命令に反応しない作りに改修した。
間接原因である稼働確認作業の遅延で復旧作業が間に合わなかった点について，藤井氏は「一時の改善策に安心できないと分かった。定期的に見直すことが重要」と語る。具体的には，(4)稼働確認作業のうち，優先度の高いものや，復旧時間が長く必要なものを，できるだけ早いタイミングで完了できるように，調整を繰り返している。
