最近では自社で物理サーバを管理することがほとんどなくなりました。クラウドサービスやホスティングサービスは便利な一方、利用者からは見えない・わかりづらい点があります。［ クラウド編］では、前半に初級レベルのトラブルシューティングのキモを、後半ではとくにクラウドやホスティングを利用している場合に発生しがちなややこしいトラブル例を紹介します。
トラシュー事例（初級編）
まずは簡単なロールプレイをしてみましょう。このシナリオは弊社の新人研修の卒業試験で実施しているロールプレイとよく似たものです（筆者が勤めるハートビーツは24時間365日の有人監視サービスを提供しています） 。
あなたはWebサイト制作会社の新人研修を修了し、先月からエンジニアチームに配属されました。
ある日、先輩たちが全員出払って自分1人が留守番しているタイミングで営業さんが駆け寄ってきました。彼曰く「先週納品した◯◯商事さまから、システムが使えないと連絡がきている」とのこと。先輩たちは山奥で合宿中のため2～3日連絡が取れない状態です。営業さんもそのことを知っているので、新人と知りつつあなたのところに助けを求めてきました。
こんなとき、どうすべきでしょうか？ 弊社の新人研修ではここからすべて自分で考えて行動する必要がありますが、今回はHowToを含めてシナリオで説明していきます。
① 状況を確認する
まずは今の状況を確認しましょう。重要なのは2点です。
先方が認識している問題とは具体的に何か？
再現方法・発生条件は何か？
そこで、具体的に何が問題なのか、何をどのようにしたら、どうなるべきところがどうなっているのかを確認しましょう。たとえば、「 サイト（https://portal.example.com/）にログインしたら、パスワードはあっているはずなのにパスワード間違いと表示される。誰が試してもそうなる。」というふうに。
また、営業さんはこのシステム・お客さんについて詳しいはずなので、どのような対処を優先すべきか確認しましょう。具体的には、ユーザへの告知、データの保護、システムの復旧、再発防止のいずれを優先すべきかを確認します。
たとえばユーザ告知を優先すべきであれば、システム復旧よりもメンテナンス画面への切り替えを最優先で実施すべきです。またデータの保護や再発防止を優先すべきであれば「とりあえず再起動」などの対応はしないほうが良いでしょう。
また社内外のドキュメントや納品物を確認し、当該システムのドキュメントを集めましょう。対応を進めるにあたり次の5つの情報が必要になると思います。
WebサイトのURL
サーバのIPアドレス
サーバ構成
ログイン方法、アカウント、パスワード
事業者の連絡先、管理画面ログインアカウント、パスワード（クラウドやホスティングの場合）
多くの会社では納品物はファイルサーバなどである程度集約しているでしょうから、そこを探してみましょう。アカウントやパスワードはパスワードマネージャに保管されているかもしれません。ざっと探して見つからない場合は営業さんにも聞いてみるのと、開き直ってお客さんに聞いてみましょう。情報を集めることで次のアクションとして何をすべきかが見えてきます。
② 問題発生個所をおおまかに特定する
情報がそろってきたら問題発生個所を特定しましょう。最初からピンポイントで特定しようとせず、まずは再現させながらおおまかに特定することに注力しましょう。
たとえば「Webサイトがブラウザで表示できない」といった場合は、サーバの問題、DNSの問題、クライアント（接続元）側の問題などいろいろなケースが考えられます。
まずは自分の手元でも問題が再現するか確認しましょう。再現しない場合は接続元の問題の可能性が高いと考えられます。またDNSでの名前解決が実施できているか確認しましょう。名前解決ができない場合、レコード設定誤りのようなDNSの問題やドメイン有効期限切れの可能性が考えられます。
このように問題個所を特定することを俗に「問題の切り分け」と呼びます。切り分けの結果、サーバ側に問題がありそうだとなった場合にはサーバにログインしましょう。たいていはsshでログインすることになると思いますが、Windowsサーバの場合はRemote Desktopを使うかもしれません。ログインできない場合は何が・どこが変なのかを考える必要があります。サーバ側ネットワークの問題が発生しているとしたら、同じ問題によりsshができなくなっている可能性があります。
クラウドやホスティングサービスは、たいていブラウザから利用できる管理画面を用意しています。この管理画面ではサーバの状態が確認できます。もし然るべきサーバが停止状態だった場合は、起動することで問題が解決するかもしれません。
事業者によっては管理画面でサーバのコンソール画面を見られる機能を用意しています。さくらのクラウドやIDCFクラウド、ニフティクラウドにはこの機能があります。
図1 のように画面が見られる場合は見てみましょう。コンソール画面を見ることで、ネットワークの問題なのかサーバの問題なのかが判断できます。
図1 管理画面でサーバのコンソール画面を見るもし画面に何か意味不明な文字がたくさん表示されている場合は記録しておきましょう。スクリーンショットをとるか、スマホのカメラで撮影しておくと良いと思います（図2 ） 。Kernel Panicという状態になっている場合はこの文字だらけの画面でサーバ全体がハングアップしているため、電源をOFF/ONして再起動するしかありません。クラウドやホスティングサービスの管理画面から実施できる場合は再起動し、問題が再発するかどうか様子を見ましょう。物理サーバの場合、データセンタのサービスとしてリモートハンドが用意されている場合があるので利用しましょう。リモートハンドとは電話などで依頼してサーバの電源ボタンを押してもらうサービスのことです。対象のサーバを指定し、どのボタンをどのように押してほしいかを指定し依頼します。たとえば「◯◯（サーバ名）のDELLのロゴの右側にある電源マークのボタンを5秒ほど押しっぱなしにしてから離す、その後数秒待ってから同じボタンを軽く1度押す」などと指定します。
図2 Kernel Panicサーバの電源はONだけど画面に何も表示されていない場合は画面が省電力モードになっているかもしれないので、画面をクリックして［Ctrl］か［Tab］を何度か押してみましょう。
サーバを再起動するとメモリ上のデータが消える、データの不整合が発生する、サーバが2度と起動しないなど新たな問題が発生する可能性があります。現状でサーバが利用できていないので、方針が復旧優先の場合は問題ないのですが、復旧よりもデータ保護や再発防止を優先したい場合には再起動せず詳しいエンジニアの判断を待ったほうが良いでしょう。
③ ログインできたらデータフローの順に確認
ログインできたらサーバの状態を確認します（筆者がよく使うLinux（CentOS）を前提にしています） 。
まずはOS全体の状態を確認します。top、w、df、free、netstat、vmstatなどを実行し、CPU・メモリ利用量・SWAP利用量・ディスク空き容量などを確認します。システムログも忘れずに確認しましょう。/var/log/messages
ディスクに空き容量がなくデータが書き込めない、メモリ不足によりSWAPを大量に利用しており応答速度が遅くなっているなどの場合はこの段階でわかります。ディスクの空き容量がない場合は古いログファイルの削除や、大きなファイルの削除などで対応します。どのファイルが消してもいいものなのかわかる場合にのみ対応しましょう。
SWAPを大量に利用している場合は原因となっているプロセスの停止や再起動で対応します。この場合もプロセスを停止してよいか判断がつく場合にのみ対応しましょう。止めてはいけない（止めるとあとがたいへんな）バッチ処理が動いているかもしれません。
次に個別のプロセスを確認します。たいていのWebシステムでは次の4種類のプロセスが起動しています。
WEB：Apache、Nginx
AP：Apache、php-fpm、Unicorn
KVS：memcached、MongoDB、Redis
DB：MySQL、MariaDB、PostgreSQL
ただし小規模なWebシステムではWEBとAPは両方Apacheが兼ね、KVSがないこともあります。また中規模以上のWebシステムではDBが別サーバに配置されていることもあります。それぞれの要素の有無や正しい配置場所は、ドキュメントや監視設定（もしあれば）を基に判断していきます。
個別のプロセスが特定できたらデータの流れる順番に沿って確認していきましょう。たいていのWebシステムではWEB→AP→KVS→DBという順になります。それぞれの要素ごとに、ソケットの有無、プロセスの有無、ログ出力内容の3つを確認します。
ここまでくると、プロセスの単位まで切り分けができます。起動していなければならないプロセスが停止している場合には起動しましょう。うまく起動しない場合にはエラーログファイルを確認し問題の原因を取り除く必要があります。
それでもわからない場合、復旧優先であればサーバごと再起動するしかないかもしれません。営業さんとお客さんの了承を取ったうえで、祈りつつ再起動しましょう。
④ 動作確認
対処が完了したら、最後に問題の再現方法をなぞり、問題が再発していないか確認しましょう。再現しなければ見事解消です。お疲れさまでした。
⑤ 根本対応
後日でかまわないので、振り返りと再発防止をしましょう。ここでは再発防止対応や、再発時の対応フロー整備などを実施します。
技術的な再発防止策だけでなく、再発時に迅速に発見して対処するために情報をとりまとめておくのも効果的です。筆者の勤めるハートビーツが提供する監視一次対応サービスを導入するのもお勧めです。
シナリオを振り返って知見をとりまとめましょう。実際の対応が終わったあとはかなり疲れているとは思いますが、振り返り、言語化し、体系化することで次回以降に活かすことができます。
今回のシナリオをざっくりまとめると次の要素がありました。
まずは落ち着いて状況を確認する
情報を集める
対応方針が決め、暫定対応・根本対応でそれぞれどうすべきか検討できる
解明ではなく切り分けに注力する
データフローの順に見ていく
勘に頼らずデータとログを見る
障害対応中はどうしても慌ててしまうため、冷静なときには普通にできることができないものです。このようにあとから体験を振り返り、要素を言語化、体系化しましょう。振り返り→言語化→体系化を繰り返すことで自分を律し、的確な対応ができるようになっていきましょう。
トラシュー事例（上級編）
自分のサーバが原因のシステムトラブルはわかりやすいのですが、クラウド基盤のシステムを運用しているとどうにもよくわからないトラブルが発生することがあります。障害対応でわかりづらいトラブル例をいくつか挙げてみました。
クラウド基盤の障害
トラブルの原因がクラウド基盤側の場合、いまいち性能が出ない、いまいち応答が悪い場合などの症状が出ることがあります。完全にダウンしてしまうとわかりやすいのですが、微妙におかしくなっている場合にはシステム自体をいくら調べても原因が掴めないことがあります。たいていはクラウド事業者が問い合わせ窓口を設けているので問い合わせてみましょう。
稼働状況を公開しているサービスもあるので事前にチェックしておきましょう（図3 ） 。ただしこのような稼働状況ページはサービス全体に関わる問題しか反映されないことがあります。また迅速に反映されるとも限りません。
図3 AWSの稼働状況ページ リアルタイムに情報が欲しい場合は、問い合わせと並行してTwitterなどで同じように困っている人がいないかリアルタイム検索してみると良いでしょう。
インターネット経路障害
A社からの利用は問題ないけどB社からの利用は問題あり、しかしA社もB社もインターネット自体の利用は問題ないというケースがあります。その場合にはインターネット接続の経路を疑ってみましょう。インターネットの経路によってトラブルが発生することがあります（実際ありました） 。
問題がある拠点・ない拠点それぞれからtracerouteを実行することで、どのような経路をたどっているか、経路のどこで問題が発生しているか確認できます（図4 ） 。
図4 tracerouteを実行[root@web ̃]$ traceroute -n 192.168.123.1
traceroute to 192.168.123.1 (192.168.123.1), 30 hops max, 60 byte packets
1 10.0.2.2 0.088 ms 0.067 ms 0.081 ms
2 192.168.24.24 60.928 ms 60.883 ms 60.802 ms
3 192.168.24.1 60.727 ms 60.543 ms 60.734 ms
4 192.168.123.1 61.466 ms 66.463 ms 66.461 ms ISPより上の経路での問題となると改善が難しいのですが、事業者に状況と確認結果を連絡して改善を促しましょう。
連携サービスの障害
システムには何も異変がないのに急にそのシステムの利用者が減ったら、ユーザの導線を確認してみましょう。
ソーシャルゲームの入り口になるプラットフォーム（たいていSNS）側で障害が発生していてユーザが流れてこない、認証の連携先で障害が発生していてユーザが認証できずシステムが利用できないなどのケースがあります。ユーザの目線で、ユーザと同じ動作を、できるだけユーザに近い環境から実施することが問題の切り分けにつながることがあります。
本稿では障害対応の簡単なロールプレイと、ちょっとややこしい事例を紹介しました。障害対応は精神的にはプレッシャーがありますが、論理的に詰めていけば問題個所は特定できます。諦めず冷静に、落ち着いて対応しましょう。
ピンチをチャンスに！
障害対応をすると自分の力不足を痛感することが多いと思います。そんなときこそ成長のチャンスです。
初心者を脱する段階で定番の苦手ポイントは以下に挙げたようなものがありますが、今後もエンジニアとしてやっていくためには避けて通れないので、苦手意識を捨てて必要なことを学びましょう。
英語のエラーメッセージを読む
英語のドキュメントを読む
Apacheなどミドルウェアのソースコードを読む
アプリのソースコード（PHP/Ruby/Python）を読む
プログラミングする
ネットワークについて知る
straceコマンドでプロセスの動きを見る
システムコールについて知る
エンジニアなら「難しい→やらない」ではなく「難しい→コンピュータの力で簡単にする」というアクションをし続けたいですね。
第1特集 MySQL アプリ開発者の必修5科目 不意なトラブルに困らないためのRDB基礎知識 第2特集 「知りたい」「 使いたい」「 発信したい」をかなえる OSSソースコードリーディングのススメ 特別企画 企業のシステムを支えるOSとエコシステムの全貌 ［特別企画］Red Hat Enterprise Linux 9最新ガイド 短期連載 今さら聞けないSSH ［前編］リモートログインとコマンドの実行 短期連載 MySQLで学ぶ文字コード ［最終回］文字コードのハマりどころTips集 短期連載 新生「Ansible」徹底解説 ［4］Playbookの実行環境（基礎編）
