インターネットサービス用のシステムメンテナンスの苦労

私の会社ではIT・メカトロの製品開発販売や受託開発などを行っていますが、私が直接担当することが多いのは、ProDHCPを中心に、インターネットサービスを構成するシステムです。

どの仕事もミスは可能な限り防ぐべきことは当たり前ですが、インターネット向けはユーザ数・社会インフラとしての役割などから、ミスなどによりサービスに影響が出ると、かなり大事になります。

そのため、インターネット向けシステムのメンテナンスを行う際には、2週間以上前にユーザに告知することや、利用が少ない午前2時から5時くらいで作業することなどを要求されることが多く、また、作業前に念入りな検証を行い、万が一の問題も潰す努力をした上で、本番作業に挑みます。

理想的には本番環境と限りなく同じ検証環境を準備し、そこで念入りにリハーサルを行い、作業本番では手順通りに進めることが一番です。しかし、インターネット向けシステムは構成も複雑で規模が大きい場合が多く、同等の検証環境を準備することはコスト面のみならず、技術的にもハードルが高いことも多いものです。

本番環境と検証環境の違いが多いほど、本番で想定外の事態にぶつかる可能性が上がります。さらに、どれだけ素晴らしい検証環境を用意して準備を重ねても、本番で流れるトラフィックと同じことを再現することが難しすぎるため（端末や構成機材があまりにも多様すぎて、全て準備・想定するのは現実的に無理なことが多い）、手順通りに作業を進めても想定外の事態が起きてしまうことも少なくありません。

多くの場合、想定外の事態が発生した場合の時間的猶予は5分から30分くらいでしょう。その間に可能な限りサービスを提供させる状態にしつつ、問題の原因を探り、対処方法を考え出し、対策して稼働させることができるかどうかが勝負になります。

本番で試行錯誤するなどあり得ないと思うかも知れませんが、ユーザへの事前告知で停止期間や影響範囲を伝えた範囲で何とかしなければ、さらに大変なことになります。本番環境で後でもう一度試行錯誤するチャンスをもらうことは相当難しいからです。ベストは猶予時間内で解決することで、最低限、原因解析を確実に行えるデータ取りまでは済ませた上で切り戻さないと先に進められなくなってしまいます。

これらの背景があるために、どれだけ手順が明確になっていても、該当分野において百戦錬磨のベテラン技術者が本番に立ち会って欲しいという希望はとても強いものです。なにも起きなければある程度の知識を持つ技術者で簡単に対応できる作業でも、インターネット向けシステムの本番作業では万が一のことが起きる可能性があり、短時間で対処できるかどうかでプロジェクトの成否が大きく違ってしまいます。原因が分かってしまえば誰でも対応できる内容でも、多くのユーザの不特定多数の端末を相手に処理するシステムでの調査検討はとても大変なのです。

おそらく立ち会った件数としても解決した問題の数としても年齢としても私はベテランクラスだと思いますが、それでも、稼働中のシステムでのメンテナンス作業では、キーボードを打つ指が震えることがあるくらいです。「準備・検証は十分したはずだ」「この通りで問題ないはずだ」と頭で考えながらも、「それでも本当にこのコマンドを実行して大丈夫か？」と不安になるのです。まあ、実際、自分の作業に問題がなくても、例えば長期連続稼働していたサーバをリブートしたことによりハードディスク障害により二度と起動しなくなる、ということなども、実は結構起きたりします。結局、できる限りの準備をした上で、覚悟を決めて進めてみて、必死で観察し、問題が起きているようであれば死にものぐるいで対処するしかないものだと思います。

システム障害はたびたび大きな社会問題にもなりますが、作業している現場では、本当に手を抜いていることなど希で、皆必死で作業しているものです。それでも、今のシステムはあまりにも複雑に構成されており、作業ミス以外にも、ソフトウェアの問題もあるかもしれませんし、ハードウェアが故障することもあります。

実際に作業している技術者も、間で問題が起きないように調整・管理しているシステムエンジニアも、エンドユーザの窓口となっている回線事業者側の皆さんも、皆それぞれ必死に頑張っている状況を良くわかっていて、その苦労を知っているからこそ・・・キーボードを打つ指が震えるのですねぇ。

今日もそんな作業を終えて、ぐったり疲れた新幹線の中で、こんなことを書いてみたくなったのでした。

来週は深夜の本番作業です。それが終われば少し精神的に楽になれることでしょう。