今回は、 Bugzilla について紹介します。

Bugzilla とは、不具合についての報告・修正を行うための枠組みです。 Red Hat 社の場合 Red Hat Bugzilla という名前のシステム（ https://bugzilla.redhat.com/ 、 RHBZ と略されます）を利用しています。異なる枠組みを使っているディストリビューションもあり、例えば Ubuntu の場合 Launchpad という名前のシステム（ https://launchpad.net/ 、 LP と略されます）を利用していますが、利用する上で大事なことは同様です。

RHBZ への登録を行う際に必要な情報を以下に示します。

Product:

対象となる製品名（例えば Red Hat Enterprise Linux 7 ）

Component:

対象となるパッケージ名（例えば kernel ）

Version:

対象となる製品のバージョン番号

Summary:

問題事象を1文で要約したもの。類似の既知の不具合を検索する際のヒントにもなるので、キーワードを入れるのが良い。

Description:

問題事象の詳細。具体的には以下の内容。

Description of problem:

問題事象についての説明。例えば「○○という操作をするとシステムがハングアップしてしまう」など。

Version-Release number of selected component (if applicable):

対象となるパッケージのバージョン。原則として最新版でも修正されていない問題事象であることが前提です。最新版で試すことが難しいという理由で古いバージョンを指定すると、「最新版でも再現できる？」と聞かれてしまい、そこから先へ進めなくなってしまいます。

How reproducible:

問題事象の再現性。再現性の無い問題事象は修正が困難であるため、問題事象の再現手順を確立できていることが望ましい。

Steps to Reproduce:

問題事象の再現手順。この問題に対応する人が同じ環境や設定で利用しているとは限らないので、最小限の操作で、可能であればコピー＆ペーストで問題事象を再現できるくらいに的確な手順が求められます。

Actual results:

問題事象と考える結果。（例えば「システムがハングアップする」）

Expected results:

期待される結果。（例えば「処理が正常に終了する」）

Additional info:

その他参考情報。

Attachment:

（もしあれば）添付ファイル。「 Description: 」で引用するには長すぎるログファイルなどは、ここに添付すると良いでしょう。

なお、セキュリティ上の問題を報告する場合には、「 Show Advanced Fields 」をクリックすると表示される「 Security Sensitive Bug 」オプションを選択して、非公開エントリーとして登録するようにしましょう。また、セキュリティ上の問題ではないけれども機密情報が含まれている場合には、「 Private Group 」オプションを選択することで、非公開エントリーとして登録することができます。
実際のやりとりの様子は、公開エントリー（例えば https://bugzilla.redhat.com/show_bug.cgi?id=1116237 ）を参照すると解りやすいでしょう。

RHEL の利用者であれば、 Red Hat 社からの直販、もしくは、再販パートナーから購入した RHEL サブスクリプション（直販 RHEL ）または OEM ベンダーからサーバーとセットで購入した OEM 版の RHEL サブスクリプション（ OEM 版 RHEL ）を所有しているはずです。直販 RHEL を所有しているのであれば、 Red Hat 社のサポートケース（ https://access.redhat.com/support/cases/ ）から日本語で報告を行うこともできます。 RHBZ 上でのやりとりについては、 RHEL のサポート契約に基づいた対応とはならないため、応答時間などの規定がなく、場合によっては、返答のないまま長期間放置される可能性もあります。 RHEL のサポート契約に基づいて、サポート部門からの正式な対応が必要な際は、サポートケースから問い合わせるようにしてください。なお、サポートケース経由での問合せも、内部的には RHBZ での管理を行うことになるため、直接 RHBZ に報告する場合と同様に、サポート担当者が対応しやすいように切り分けを済ませて的確な内容にしておくと、より適切で迅速な対応を期待することができます。

OSSを使って遭遇した問題事象を的確に切り分けて報告できるスキルも、OSSを利用するスキルの重要な一部です。どうやったらサポート担当者が動きやすいかも考えてみてください。

（半田哲夫）

コーヒーブレーク「始められない依頼」

前回の記事で、依頼の段階でつまずくケースについて紹介しました。それらは依頼したい内容に問題があるため、サポートセンター側として対応を開始することができない場合と考えることができます。しかし、依頼の内容に問題がなかったとしても対応に着手できない状況が存在します。さて、サポートセンターの対応範囲内の依頼で、内容が明確で、作業に必要な情報も揃っているのに、対応に着手できない状況とは、一体どのような状況でしょうか？

答えは、依頼元とサポートセンターの間で調整が必要になった場合です。具体例をあげると、作業の優先度や期限の指定、対応する費用（稼働）の条件、あるいは現地で作業して欲しい等の要望などがあると、対応について、調整が始まります。その調整が終わるまではサポート技術者は割り当てられず、作業は始まりません。

調整が始まると、サポートセンターの中で何が起こるかというと、関係者が集まり協議をします。ここで関係者とは、受け付け業務の担当者およびマネージャー、サポートチームのリーダーおよびマネージャー、顧客ごとの対応責任者（定められている場合）です。こうしたメンバーが呼び出されて、依頼の内容を見ながら対応について議論します。判断の基準は、いろいろありますが、特に重要で、そして（おそらく）依頼する側にあまり認識されていないのは、「サポートセンターとして中立性、公平性を保つ」ことです。サポートセンターが特定の依頼元に便宜を図ったり、特定の依頼を優先したりすることは許されないのです。

サポートセンター内の議論については、依頼元に議事録が送られるわけでもなく、依頼元には知ることができません。サポートセンターの中にいて、この調整を日々行っている立場からの私の助言は、依頼の際にはサポートセンターの意見に素直に耳を傾け、どうしても必要なこと以外は頑張らないことです。そう書くと、「サポートセンターの言いなりになって妥協（我慢）しろということか？」
と思われる方があるかもしれません。そうではないのです、ということについて、次回説明します（それまであなたのシステムが平和でありますように！）。

（原田季栄）

• Hinemos関連サービス
• Hinemos