ネットをフラフラしていると、以下のような記事を見つけた。
会社の携帯を持たされている時の手当 : 専門家に相談するトピ : 発言小町 : 大手小町 : YOMIURI ONLINE（読売新聞）
元記事が消えてしまうといけないので、要約すると
- 24時間365日稼働するシステムを運用している
- それが止まると、自分の携帯電話が鳴って呼び出される
- 勤務時間外まで待機させられるのっておかしくない？手当ぐらいくれよ
ということである。
これがWebサービスの話なのかどうかは知らないが、Webサービスの運用・保守ではよくある話だなあ、という感想を持ったので、皆さんが利用したり、あるいはクライアントとして運用を依頼しているWebサービスというものが実際にどのよう運用されているのか、というのを書いておこうと思う。
Webサービスというのはオンライン・システムである。それもインターネットという無法地帯と繋がっていることがほとんどだ。いわばWebサービスとは荒海に浮かぶ一隻の船のようなものであり、気象条件や船の欠陥や故障、客（ユーザー）の不始末で、わりと簡単に転覆してしまう。
例えば、ある日の深夜2時にWebサービスが落ちた時の障害解決フローを簡単にストーリーとして紹介してみよう。
ちなみに以下は完全なフィクションであり、わかる人には色々と突っ込みどころがあると思うが、そのあたりは予め我慢していただきたい。
ストーリー：深夜2時の障害対応
自社で運用している会員制のコミュニティサイトで障害が発生した。
URLを叩いても、本来お花畑で楽しそうに遊ぶ女性の画像が表示されるHPの代わりに、真っ白な画面に意味不明の英語のエラーメッセージが表示され、まったく操作ができないのである。
会員からの苦情のメールまたは、死活監視システムの警報アラームを受け取った社内の誰かが、システム担当者の携帯電話を鳴らす。
システム担当者は日々の仕事の鬱憤を一人酒にぶつけて、ようやく寝入ったところだった。度重なる着信音で叩き起こされた彼は、眠い目をこすりながら、早速不具合を家のPCから確認する。
表示された無機質なエラーメッセージを見るに、どうもデータベースに接続できないというエラーのようだ。
コンプライアンス上、家からWebサービスを運用しているサーバーに接続することは許されないので、担当者は急いで着替えると、タクシーで深夜の街を疾走して会社に向かう。
人気のないオフィスに入った担当者がメンテナンス用の端末でサーバーに接続しようとする。が、繋がらない。どうやらサーバー自体が何やら異常を起こしているらしい。
担当者はサーバーをホスティングしている会社に電話をかける。自動音声や保留音で5分程待たされたあげく、ホスティング会社の社員が退屈そうな声で応答する。
担当者はホスティング会社の社員に「サーバーに端末レベルでつながらない」旨を伝える。ホスティング会社の社員は「確認する」と言い残して、電話を保留にする。
また5分程の時間が流れる。ようやく社員が戻ってきて言う。「こちらからも繋がりませんね。」…そんな事は知っている。
「で？」と担当者は尋ねる。何が原因なのか。
「不明です」と社員は答える。サーバーがメモリ不足でスレッジングを起こしているかもしれないし、物理的に故障しているのかもしれない。端末でログインできない以上、何もわかりません。と。
「…再起動で」と苦渋の表情を浮かべた担当者は言う。サーバーのシャットダウンを行った後、二度と起動してこないという事態もあり得るが、サービスが止まっている以上同じことである。
「わかりました」とホスティング会社の社員が答える。
端末がつながらないので、サーバーを再起動する方法は、物理的にサーバーの電源スイッチを押すぐらいしかない。
が、データセンター内に収められたサーバーの電源スイッチを押すことができるのは、ホスティング会社の社員のみである。（もちろん物理的にスイッチを押すわけではなく、リモートでスイッチのON,OFFや電源断を行うシステムがデータセンター内にある。らしい、が詳しいことは知らない。）
一旦電話を切る。やることのない担当者はサーバーにpingを飛ばし続けることにする。こうすればサーバーが再起動した時に、それをいち早く知ることができるのだ。pingの応答が消え、サーバーがシャットダウンした事を知る。知ったところで、どうにもならないのだが。
不安な時間が10分ほど流れる。突然pingが復帰し、サーバーが生き返ったことを知る。ほっとする間もなく、担当者はすぐにメンテナンス用端末でサーバーに接続する。今度は繋がった。
サービスのURLを叩き、ブラウザでも確認する。お花畑HPはまだ表示できず、データベースには相変わらず接続できないようだ。
しかし、今は端末が繋がっている。担当者は手動でデータベースに接続を試みる。どうもデータベースのデータが破損しているようだ。担当者は、慎重に手順を思い出しながら（あるいはgoogleで検索しながら）データベースのデータ復旧を試みる。
その間にオフィスの電話がなる。ホスティング会社からだった。「サーバーが復旧しました」そんなことは知っている。それにサーバーは生き返ったがサービスは死んだままである。
どうも、ファイルシステムの破損があったようで、ファイルシステムの復旧を行った結果、再起動にこぎつけたらしい。
データベースには相変わらず繋がらないが、ファイルシステムが破損している間に波及的にデータベースが破損したのかもしれないな、と担当者は考える。もちろん詳しい原因究明はサーバーログを見なければわからない。担当者は礼を言って電話を切る。
データベースの復旧が完了する。念のため、Webサーバーも再起動してみると、お花畑HPが無事に表示され、Webサービスが復旧した。
時間は早朝4時になっていた。担当者は回復の連絡をサポート担当にメールしたり、障害情報をサイトに掲載したり、朝までに上司向けの障害報告書を書く準備を始める。
障害対応の核心と属人性
以上が、深夜2時のシステム担当者の苦闘の記録である。
技術に明るくない方にとっては、詳細を読んで、「なんだか大変な作業をしてもらっているんだな」という印象を受けるかもしれないが、よく読んで貰えば、システム担当者がしたことは、実は、以下のことだけであることが分かるはずだ。
- ホスティング会社に電話する
- ホスティング会社に再起動を依頼する
- データベースを復旧する（やり方はgoogleが知っている）
もし、システム担当者でなくとも、それなりにUnixに詳しく、端末を適切に触れる程度の人間であれば、件のWebサービスについて何も知らなくても、上記の手順ぐらいは簡単にこなせるだろう。この事例の復旧手順に限って言えば、別にシステム全体に通じた担当者を叩き起こす必要はないのである。
ただ、障害対応の核心は、適切な復旧手順を見つけ出すことにある。
適切な復旧手順を見つけるには、様々なテクニックが必要だ。
例えば、端末がリモートで接続できなかった時点で、担当者がホスティング会社に電話したのは、サーバーへのネットワーク経路に異常がないかを確認する目的も兼ねている。ホスティング会社の端末はインターネットを介していない（筈）なので、そこからも繋がらないことからサーバー自体の異常であることがわかるのである。
このように、障害対応というのは、何が可能で、何が不可能であるか、を判断基準として、問題を細かく切り分け、それを解決するという作業であると言える。
これが可能なのは、かなり熟練したWebエンジニアで、かつWebサービスのシステム全体に精通した人物でなければならない。
例えば、上述のストーリーでは障害の原因はサーバーのファイルシステム破損が原因だった訳だが、障害の厄介さで言えば（その後のHDD交換等が必要となったとしても）マシな部類と言える。
データベースの設計ミスによる不整合の発生やら、ユーザー数増加の結果の過負荷が原因であった場合の障害対応は、こんなものではすまない。おそらく翌日の夕方まで厄介な作業にとりつく羽目になるだろう。
このように、障害対応というのは最もエンジニアの力量や知識の差が出る場面であるとも言え、そのようなことが出来るエンジニアは社内にそう多くない。会社内に一人だけしかいない、ということもよくあるので、彼らは飲酒していようが、寝ていようが、旅行していようが、深夜2時に叩き起こされることになるのである。
後日談：障害対応の報酬
さて、勤務時間外に思わぬ作業を強いられた担当者であるが、翌朝、報告書を提出した彼に上司が言った言葉は以下のようなものである。
「タクシー代の領収書を経理にまわしといて、あと今日は昼までで帰っていいから」
なんと、これだけの活躍した彼に与えられた報酬は、深夜のタクシー代と、その日の勤務時間の短縮だけである。それらはいわば立て替えただけなので、実質の報酬は0だとも言える。
もちろん会社によっては、タイムカードの記録から障害対応の時間分の「深夜勤務手当」を出す場合もある。というか普通出すだろ、と思うかもしれないが、「今日は昼までで帰っていい」特権を与えたらそれで十分と考える経営者や上司はかなり存在するのだ。
というか私個人の経験で言えば、こういうケースで金銭的に報酬を受け取ったことは一度もないし、深夜2時に出社したにも関わらず、結局その日もフルタイムで働いてしまったことすらある。
程度の差こそあれ、これが、中小ITベンダーの障害対応の実態である。
それでも多くのエンジニアが文句を言わないのは、それほど頻繁に呼び出されるわけではないから我慢しているだけだったり、社内での自分のポジションが上がるからいいかということだったりするが、何よりも自分の作ったWebサービスに愛着があって、そのユーザーに不便を強いるのが辛いということだったりする。
当たり前だが、このような属人性に頼った運用体制には問題がある。
たまに、「障害復旧の見込みが立たない」という理由で、古いWebサービスが廃止になったりするが、これはシステムに愛着を持ったエンジニアが退職してしまった結果、そのシステムを復旧することが誰にもできなくなってしまったということだったりする。（多分）
以上、Webサービスを24時間365日動かすために、エンジニアがボランティアに近い活躍をしているケースがある、ということを書いた。
もしあなたが運用を依頼しているWebサービスの保守費用が異様に安かったり、あなたが使っているWebサービスが社員数もスキルもありそうもない企業によって運用されているのなら、上述したような狂気じみた運用がなされている場合があることを覚えておいたほうが良いだろう。
もちろん、交代制勤務のまともな運用部署があり、ネットワークなどのインフラを含めたワンストップの運用体制を組んでいる企業もあるし、AWSなどのクラウドサービスを上手く構築して、冗長構成を組んだりして、ちょっとした障害ではサービスが止まらないようにしているところもある。
だが、そのどちらも単純な「ボランティア方式」で運用するより、費用がかさむし、例えシフトを組んで対応していても、難しいトラブルを解決できるのは昼間にいる数人といったケースや、あらゆる冗長化をぶちやぶって、サービスが止まることも無いわけではない。結局は程度の問題なのだ。
いずれにせよWebサービスが数人のエンジニアの「愛着」に依存している可能性があることは、そのサービスの継続性におけるリスク要因として冷静に考える必要があるだろう。
「成果を出す」オウンドメディア運営
5つのスキルと全48タスク
をプレゼント。
これからオウンドメディアをはじめる企業さま、現在運用中の企業さま全てにお役に立つ資料です。ぜひご活用ください。
資料ダウンロードページはこちら↓
https://tinect.jp/ebook/5skills48tasks/
メールアドレス宛てに資料が自動送信されます。
ティネクトの事業・サービス詳細はこちら
【プロフィール】
著者名：megamouth
文学、音楽活動、大学中退を経て、流れ流れてWeb業界に至った流浪のプログラマ。
ブログ：megamouthの葬列
