こんにちは。モバイルサイトディレクターの早岡です。
突然ですが、みなさんは『livedoor Blog』が何台のサーバで構成されていると思いますか？ 100台？ 200台？ いいえ、違います。パソコンとモバイル合わせて1000台を超える大規模のサーバ群で構成されています。これほどの規模だと、アプリケーション側だけでなく、サーバサイドでのトラブルも多々発生します。
今回は「障害対応的ディレクションスキル」というエントリーを受けて、「サーバ障害とどう向き合うか」について書きたいと思います。
■障害の連絡を受けたとき
私が担当している『livedoor Blog』のサーバは、弊社ネットワーク事業部が管理するデータセンターに置かれています。サーバに障害が発生すると、データセンターの担当者から電話連絡がきます。
ネットワークエンジニアだけで解決できる障害であれば、その場で対応してもらって問題ありませんが、アプリケーション側での修正を必要とする場合は、担当プログラマーに連絡し、対応を行ってもらう必要があります。
データセンターから伝えられた内容を伝え、作業に取り掛かってもらうわけですが、勘（？）の鋭い人なら「わざわざディレクターを介さずに、データセンターから直接プログラマーに連絡した方が早いんじゃない？」と思いますよね。確かに、対応のスピードだけを考えれば、そうかもしれません。
ただ、ブログのように大規模案件になると、スピードだけではなく、周囲へのフォローが必要とされるわけで……
・広告担当への連絡
・サポート担当への連絡
・障害発生に関する告知
……など、障害に伴う諸作業が発生します。もちろん、障害の規模によっては上長へ連絡し、判断を仰ぐこともあります。また、『livedoor Blog』の場合、パソコンとモバイルで担当者が異なります（ディレクターだけでなくプログラマもです）。たとえば「モバイルでの障害によってパソコン側にも影響が出ている」といった場合には、パソコンの担当者への連絡が必要になりますし、もちろんその逆もあり得ます。パソコン側のサーバ障害だからといって他人事ではないのです。
これは「このサーバに障害が発生したら影響範囲はここになる」といった知識がなければできないことですが、経験の積み重ねによって、適切な対応が可能になるのではないかと思います。
■事後の対応
障害から復旧するまで見届け、サービスを正常化し、原因を追究するまでが「障害対応」です。「家に帰るまでが遠足です」と同じ理論ですね。
もちろん、物理的な障害（ディスク損傷やメモリ不良など）の場合などもありますが、「サーバ過負荷による閲覧障害」などといったときは、どうして過負荷になったのか、サーバを増やす必要はあるのか、アプリケーション側で解決できる点はないのかなどを突き詰めて調査していく必要があります。
・LoadAverage の調査
・CPU使用率の調査
・apacheプロセス数の調査
・メモリ使用状況の調査
もちろん、これらはディレクターが行うわけではありませんが、「何で障害が起きたんだろうねぇ」と曖昧に終わらせることなく、原因を追究する姿勢を持つことが大切なのではないかと思います。
このような調査系は、プログラマーにとっても非常に面倒だと思いますし、依頼した際、あまりいい顔をされないこともあります。しかし、調査の必要性やサービスにどの程度影響が出ているかをアピールすることによって納得（？）させるのも、ディレクターの仕事の役割なのではないかと思ってます。
■最後に
『livedoor Blog』のような大規模案件は、その規模ゆえに障害などのトラブルに遭うことも多いです（ただ、それだけにやりがいが大きいことは確かですが）。なかでも、サーバ障害は、ディレクターとして非常に関わり方が難しい問題だと思っています。
でも「わからない」「関係ない」と思わずに、積極的に取り組んでいくことは、ディレクターとしては絶対に損ではありませんし、スキルアップにもつながります。もし、そのような局面に出合ったら「ピンチはチャンス」と思って、粘り強く対応する意識を持っていただけたらな、と思います。
突然ですが、みなさんは『livedoor Blog』が何台のサーバで構成されていると思いますか？ 100台？ 200台？ いいえ、違います。パソコンとモバイル合わせて1000台を超える大規模のサーバ群で構成されています。これほどの規模だと、アプリケーション側だけでなく、サーバサイドでのトラブルも多々発生します。
今回は「障害対応的ディレクションスキル」というエントリーを受けて、「サーバ障害とどう向き合うか」について書きたいと思います。
■障害の連絡を受けたとき
私が担当している『livedoor Blog』のサーバは、弊社ネットワーク事業部が管理するデータセンターに置かれています。サーバに障害が発生すると、データセンターの担当者から電話連絡がきます。
ネットワークエンジニアだけで解決できる障害であれば、その場で対応してもらって問題ありませんが、アプリケーション側での修正を必要とする場合は、担当プログラマーに連絡し、対応を行ってもらう必要があります。
データセンターから伝えられた内容を伝え、作業に取り掛かってもらうわけですが、勘（？）の鋭い人なら「わざわざディレクターを介さずに、データセンターから直接プログラマーに連絡した方が早いんじゃない？」と思いますよね。確かに、対応のスピードだけを考えれば、そうかもしれません。
ただ、ブログのように大規模案件になると、スピードだけではなく、周囲へのフォローが必要とされるわけで……
・広告担当への連絡
・サポート担当への連絡
・障害発生に関する告知
……など、障害に伴う諸作業が発生します。もちろん、障害の規模によっては上長へ連絡し、判断を仰ぐこともあります。また、『livedoor Blog』の場合、パソコンとモバイルで担当者が異なります（ディレクターだけでなくプログラマもです）。たとえば「モバイルでの障害によってパソコン側にも影響が出ている」といった場合には、パソコンの担当者への連絡が必要になりますし、もちろんその逆もあり得ます。パソコン側のサーバ障害だからといって他人事ではないのです。
これは「このサーバに障害が発生したら影響範囲はここになる」といった知識がなければできないことですが、経験の積み重ねによって、適切な対応が可能になるのではないかと思います。
■事後の対応
障害から復旧するまで見届け、サービスを正常化し、原因を追究するまでが「障害対応」です。「家に帰るまでが遠足です」と同じ理論ですね。
もちろん、物理的な障害（ディスク損傷やメモリ不良など）の場合などもありますが、「サーバ過負荷による閲覧障害」などといったときは、どうして過負荷になったのか、サーバを増やす必要はあるのか、アプリケーション側で解決できる点はないのかなどを突き詰めて調査していく必要があります。
・LoadAverage の調査
・CPU使用率の調査
・apacheプロセス数の調査
・メモリ使用状況の調査
もちろん、これらはディレクターが行うわけではありませんが、「何で障害が起きたんだろうねぇ」と曖昧に終わらせることなく、原因を追究する姿勢を持つことが大切なのではないかと思います。
このような調査系は、プログラマーにとっても非常に面倒だと思いますし、依頼した際、あまりいい顔をされないこともあります。しかし、調査の必要性やサービスにどの程度影響が出ているかをアピールすることによって納得（？）させるのも、ディレクターの仕事の役割なのではないかと思ってます。
■最後に
『livedoor Blog』のような大規模案件は、その規模ゆえに障害などのトラブルに遭うことも多いです（ただ、それだけにやりがいが大きいことは確かですが）。なかでも、サーバ障害は、ディレクターとして非常に関わり方が難しい問題だと思っています。
でも「わからない」「関係ない」と思わずに、積極的に取り組んでいくことは、ディレクターとしては絶対に損ではありませんし、スキルアップにもつながります。もし、そのような局面に出合ったら「ピンチはチャンス」と思って、粘り強く対応する意識を持っていただけたらな、と思います。
コメント