現在地

最終回「防災訓練ノススメ」


セキュリティに関する問題が発生した時のために CSIRT (Computer Security Incident Response Team) の構築や、災害が発生した時のために事業継続計画 (Business Continuity Plan) を定めたり、標的型攻撃メールへの訓練を行ったりする組織は増えてきていると思います。

しかし、セキュリティインシデントでも災害でもないトラブルへの訓練状況についてはどうでしょうか?例えば、システムの構築時に SysRq-c を使った kdump 取得試験をするだけだったりとかいうことはないでしょうか?システムの応答が極端に遅くなった場合の対応手順について考えたことはありますでしょうか?

kdump の取得には成功したものの、ファイルサイズが巨大すぎて、サポートセンターに送付する手段を用意できなかったというケースがありました。サポート対象外になるとしても、AKARI のようなカーネルモジュールを使わないと調査できないケースや、C言語で数十行ほどのプログラムを自作したほうが問題を回避しやすいケースもありました。仮想化環境のホスト側を管理している組織とゲスト側を管理している組織とが異なっていることで、連携した調査ができないというケースもありました。トラブルの初回発生時に情報を取得できず、再発待ちのまま有耶無耶になってしまったケースや、状況報告が無いために、問題が解決したのかどうかが判らず不安なまま過ごすケースもたくさんありました。

原田が「予期せぬトラブルへの備え」の中で、問題を解決するのに必要な情報が提供されない理由のひとつに、「サポート技術者が何をもとに調査や解析を行うかがあまり知られていない」ことが挙げられるのではないかと書きました。私もその通りだと思いますが、それ以外にも、問題が起きたときに、「どんな問題が起きているのか判らない」「どこに必要な情報が保存されているのか判らない」「どうすれば必要な情報を取得できるのか判らない」「トラブルの発生後に情報取得のツールやコマンドを提示されても、すぐに使いこなせるとは限らない」など、サポートセンターが「製品別に調査に必要な情報の一覧を作っておくだけでは対処できない」部分も多く、結局のところ、各人がどれだけ想像力を働かせ、問題意識を共有して対処するためのコミュニケーションを行い、組織として対処できるように備えているかに大きく依存していると思うのです。

この連載では、私がトラブルシューティングを行う中で有用だと思ったツールやノウハウを、 LinuxCon Japan 2014 で発表した「エンタープライズ向けサーバのトラブル対応のための情報取得方法について」をベースに、日々の事例や体験を加えながら紹介してきました。大部分は RHEL の利用者を想定してきましたが、調査方法や手順を試したりするのは CentOS 環境でもできます。

OSSセンタとのサポート契約を結んでいるプロジェクトであれば、「ナレッジの泉」というドキュメントにアクセスできます。この連載の影響もありますが、トラブルが発生した場合に「情報の取得手順を知らなかった/情報を取得できるようにするための設定を行っていなかったために、再発するのを待つしかない」という残念な結果にならないように、情報の取得手順(例: sosreport の取得方法/ KVM ゲストのメモリダンプの取得方法)や解析手順(例: vmcore の初期解析方法)について、注意すべき点や、最新版以外を使用している環境にも対応できるように調整された、コマンドライン付きの手順を紹介する記事が登場してきています。ぜひ、トラブルに遭遇する前に知って、試して、問題発生時に活用していただきたいです。

どこのサポート窓口もリソースは限られています。適切な情報入手経路を確立して自分から動く姿勢を備えているプロジェクトは強いです。システムを構築する人と保守する人とが違うことに起因した不幸もあるとは思いますが、自分のシステムだと思って自助努力をしているプロジェクトほど、より困難な問題を解決できています。

サポートセンターで3年間、目隠しをしてのスイカ割りのようなトラブルシューティングを続けてきたわけですが、そこで感じたこととして「脆弱性の攻撃方法は常に変化しているが、脆弱性ではないトラブルや故障の対処方法は変化していない」というのがあります。だから、問題発生時の報告先/相談先を確認しておく以外にも、事例を共有したり対処方法を検討したりするなど、できることはあると思うのです。

OSSであってもシステムの安定稼働とセキュリティが年々重要視されてきている中で、どうしたらよりスマートに問題解決ができるかを考えていただけると、お互いに「安らかな夜」を迎えられると思います。

(半田哲夫)

コーヒーブレーク「桜の季節に」

今年も桜の季節がめぐってきました。日本では新たに秋入学の制度が始まりますが、卒業と新たな旅立ち、あるいは別れと出会いを飾るのに、桜以上のものはない、毎年桜が咲く日本に生まれて本当に良かった、私はそう思います。

私たちが品川にあるNTT OSSセンタでのサポート業務に就いたのは、ちょうど3年前の桜の季節、4月のことでした。日々の問い合わせやトラブル対応を通じて得られた経験をもとにつづってきたコラムですが、気がつけば、最初の記事から半年が経過しました。

サポートセンターというところは、なかなか忙しいところです。原理的には問い合わせやトラブルがないときは暇ができるはずなのですが、実際にはほとんどそうした日はありません。それぞれの役割や業務に追われる日々の中、読者の方々に「安らかな夜を迎えて欲しい」、そのために自分達ができることをしたい、ただその思いを羅針盤としてトピックを選び記事を書いてきました(半年間、いつも「次は何を書こうか」と考える日々を過ごしてきました)。書くべきこと、伝えたいことはまだまだあります。書いたものも不十分かもしれません。しかし、散りゆく桜の潔さに見習い、勝手ながら今回の記事をもって連載に区切りをつけることにしました。
ご愛読いただきましたOSSコラムは、今回で終了とさせていただきます。長らく拙い記事にお付き合いいただきました皆さまに、心より感謝いたします。どうもありがとうございました。

「区切りをつける」と書きましたが、現在、社内で新たな連載について検討を行っています。テーマ、開始時期など未定ですが、読者の皆さまのご意見、ご希望を反映したものにできればと思います。本ページの右上に「お問い合わせ」のボタンがありますので、「こんな話題に興味がある」「こんな連載を読んでみたい」などご意見をお聞かせください。過去のコラムへのご感想ももちろん大歓迎です。

(原田季栄)