Insider's Eye Windowsのパッチはいかにして作られるか？ ――　注目されるサステインド・エンジニアリング　―― Michael Cherry 2003/12/03 Copyright (C) 2003, Redmond Communications Inc. and Mediaselect Inc.

---

本記事は、（株）メディアセレクトが発行する月刊誌「Directions on Microsoft日本語版」 2003年11月15日号p.33の「Operating System パッチはいかにして作られるか？注目されるサステインド・エンジニアリング」を、許可を得て転載したものです。同誌に関する詳しい情報は、本記事の最後に掲載しています。

　WindowsチームがRTM（Release to Manufacturing）版をリリースした後は、「Windowsサステインド・エンジニアリング（以下WSE）」と呼ばれるチームが継続的なメンテナンスを引き継ぐ（「サステインド（sustained）」とは、支える、維持するという意味）。つまりWSEが、パッチ・プロセス全般にかかわる中心的な役割を果たすことになる。

　セキュリティ問題とパッチがMicrosoftにとって歓迎すべからざるニュース記事となるにつれて、フィックス（修正プログラム）の開発という緊急任務がWindows部門の無名に近いグループの双肩にますますのしかかる。このグループは、プログラム・マネージャとソフトウェア・デザイン・エンジニア、テスタからなり、「Windowsサステインド・エンジニアリング（WSE）」と呼ばれる。彼らはMicrosoftのプロダクト・サポート・サービス（PSS。製品のサポートを行う）、セキュリティ・レスポンス・チーム（セキュリティに関する一切の業務を行う）、Windowsプロダクト・グループ（製品の開発を行う）と緊密に連携して出荷製品に加えるあらゆる変更に対する研究、開発、テストを行う。現在頻発しているセキュリティの脆弱性や、新規リリースへの集中、リソースの減少などにより、同チームはますます大きな圧力にさらされる可能性がある。

編集部注：Windows Server Insdierでは、緊急性の高いWindows関連のHotFix情報、HotFix適用による不具合情報などについてWindows HotFix Briefingsとい うコーナーで公開しています。具体的なHotFix関連の情報については、そちらを参照してください。 HotFix Briefings INDEX

Windowsサステインド・エンジニアリングの責務

　WSEの懸案事項はセキュリティ・フィックスだけではない。実際、WindowsのあるバージョンがRTM版（「ゴールド版」とも呼ばれる）になると、開発を担当したプロダクト・チームはソース・コードをWSEに引き渡す。以後製品サポート期間の７年間にわたって、WSEがあらゆる追加作業について第一義的な責任を負うことになる。これにはHotfix、セキュリティ・パッチ、アップデート（クリティカルおよびノンクリティカル）、セキュリティ・ロールアップ、Feature Pack、Service Packが含まれる。WSEはまた、パッチ・プロセス自体の改善を目指すMicrosoftの取り組みで、中心的な役割を果たしている（これらの出荷品目の定義については、次の表「サステインド・エンジニアリングの出荷品目」を参照）。

出荷品目	説明	サポート技術情報（KB）記事	セキュリティ情報	テストのレベル
Hotfix	顧客の特定の問題に対処するために一般にPSSが配付するシングル・フィックス（複数ファイルの場合もある）	有	無	フィックスが問題に対処することを確認するための限定的なテスト
セキュリティ・パッチ	特定のセキュリティの脆弱性に対処するために広く公開されるフィックス	有	有	限定的なデプスおよびインテグレーション・テスト（セキュリティ・ホールの悪用が発生するまで）
クリティカル・アップデート	セキュリティ関連ではないが、クリティカルな特定の問題（例えばOSのクラッシュを引き起こすバグ）のために広く公開されるフィックス	有	無	限定的なデプスおよびインテグレーション・テスト
アップデート	クリティカルとは思われない特定の問題に対処するために広く公開されるフィックス。例えば、不便だがOSのクラッシュは引き起こさない機能のフィックス	有	無	限定的なデプスおよびインテグレーション・テスト
アップデート・ロールアップ	Hotfix、セキュリティ・パッチ、クリティカル・アップデート、アップデートの累積セット	有	無	限定的なデプス、インテグレーション、セットアップ・テスト
Service Pack	最後にリリースされたService Pack以降のすべてのHotfix、セキュリティ・パッチ、クリティカル・アップデート、アップデートの累積セット	有	無	完全なデプス、インテグレーション、セットアップ・テスト（オリジナル製品のリリースと同様）
Feature Pack	新機能のリリース	有	有	完全なデプス、インテグレーション、セットアップ・テスト（オリジナル製品のリリースと同様）
サステインド・エンジニアリングの出荷品目

　Microsoftはサステインド・エンジニアリングのソフトウェア・リリースに用いる用語の標準化に取り組んでいる。以下に各用語とその定義を示す（表中の「デプス」「インテグレーション」「セットアップ」については後述）。Windowsサステインド・エンジニアリング・チームは現在この定義を用いており、Microsoftのすべてのプロダクト・グループはサステインド・エンジニアリングの出荷品目に関し、これらを標準化する作業に取り組んでいる。

　WSEは進行中の変更に対し第一義的責任を負うが、プロダクト・デザイン・チームとのつながりは維持する。リリースされたコードに加えるすべての変更は、コア開発チームのしかるべき開発者（「バディ」と呼ばれる）によって再検討される。理想的なケースでは、この開発者はWSEが取り組んでいる特定のコード領域の作成に関与した人である。

独自のバグ対処とトリアージ方法

　WSEはWindowsプロダクト・グループと同様のチームおよびプロセスを採用しているが、バグへの対処と新たな問題のトリアージ（優先順位の決定）方法は異なる。WSEは一般に、新機能の仕様策定や設計を行う代わりに、開発プロセス中に先送りされたあらゆるバク・フィックスを再検討し、PSSおよびセキュリティ・レスポンス・チームと連携して新たな問題のトリアージとフィックスを行う（このプロセスについては、図「サステインド・エンジニアリングのプロセス」を参照）。

サステインド・エンジニアリングのプロセス

サステインド・エンジニアリングは、Windowsのあるバージョンのコードが「ゴールド版」、あるいは「RTM（Release to Manufacturing）版」になった日にそのサポートを引き継ぐ。この日に、ソース・コードは事実上3つに分かれる。ゴールド・コードは製造に回されてアーカイブされ、サステインド・エンジニアリングはリリース・バージョン（図中のVersion n）に着手し、開発は次期バージョン（図中のVersion n＋1）に進む。Windowsサステインド・エンジニアリング（WSE）はすでに前バージョン（Version n−1）をサポートしている。 　顧客がプロダクト・サポート・サービス経由で問題を報告したり、セキュリティ・レスポンス・センター経由で脆弱性が報告されたりすると、WSEは問題のトリアージを助け、適切なHotfixやセキュリティ・パッチ、アップデートの開発とテストを行う。これらはWindows Update経由でリリースされ、そのバージョンの次のService Packに含まれる。 　WSEはさらに、問題や脆弱性を修正するためにコードに加えられたすべての変更が次期バージョンに、また必要ならば前バージョンの次のService Packに確実に組み込まれるように手配しなければならない。

　トリアージには、問題や脆弱性、バグに関する理解、その再現、フィックスの供給が含まれる。このトリアージ段階において、WSEは顧客向けのフィックスの「プライベート版」を作成し、フィックスが報告された問題に対処するかを確認することがある。

　問題がいったん理解されたら、公開用のフィックスを開発し、WSEは必要とされるすべての言語、バージョン、インストール形式（例えばフル・インストール対アップグレード）向けのパッチを開発し始める。

　テストはすべての言語とバージョンに対して同時に実施される。これはオリジナル・リリースのテストと同様であり、「デプス」「インテグレーション」「セットアップ」の3つの基本カテゴリのテストに分類される。

●デプス・テスト
　まず、報告された欠陥が確実に修正されたことを確認するためにフィックスをテストする。さらに、機能性（残りの機能が正常に動作するか）、セキュリティ（フィックスが新たな脆弱性を生み出さないか）、相互運用性（ある機能に対するフィックスがほかの機能を阻害しないか）、コード適用範囲（ソース・コードのすべてのパスがテストされ、コードのすべてのインスタンスが修正されたことを保証できるか）のテストを行う。

●インテグレーション・テスト
　次に、WSEはフィックスを含む製品全体をテストしてアプリケーションの互換性を確認する。この際、製品の社内使用（セルフホスティング、Microsoft流の呼び方では「ドッグフード」）、ストレス・テスト（複数のアプリケーションとサービスの同時稼働）、ロングホール・テスト（テスト・パッケージを長期間リスタートなしで稼働）、パフォーマンスおよびスケーラビリティ・テストを実施する。

●セットアップ・テスト
　3番目に、修正されたコードは、各種インストール形式のすべてのマトリックス（新規インストール、既存バージョンに対するアップグレードなど）で実行される。

　Service PackとFeature Packだけがリリース製品と同じ完全なテスト・サイクルの対象となる。Service PackとHotfixのテストの主な違いはテストの回数と期間にある。またMicrosoftはService Packに対し、製品の新バージョンに用いるのと同様のベータおよびRC（Release Candidate。製品候補版）プロセスを適用する。これによりカスタマ・フィードバックが実現するとともに、WSEが利用できないハードウェアやソフトウェア環境への公開が可能になる。そのためService Packのフル・テスト・サイクルは、6〜9カ月かかることがある。

　これとは対照的に、セキュリティ・パッチ（悪用されていない場合）やクリティカル・アップデートのテスト・サイクルは5週間、Hotfixのテスト・サイクルは1週間以下で済む。セキュリティ・パッチが受けるテストの量は、その脆弱性が悪用され始めた時期に依存することがある。悪用の危険性が差し迫っているほど、テスト・サイクルは短縮されることになる。

フィックスの公開

　大多数のフィックスはWindows Update経由ですべての顧客に公開される。しかし、フィックスが特定の顧客の状況に極めて固有のものであるために、フルセットのテストが完了して、フィックスがService Packに含まれるまで一般に提供されない場合もある。

　フィックス公開のもう1つの方式であるセキュリティ・ロールアップCDについても記しておくべきだろう。MicrosoftはTrustworthy Computing（信頼できるコンピューティング）構想を発表した直後に、既知のセキュリティの脆弱性に対するフィックスを1つのパッケージにまとめたセキュリティ・ロールアップを2カ月ごとにリリースすると発表した。しかし、このロールアップは1回しかリリースされなかった。Microsoftによれば、一部の顧客は最初のセキュリティ・ロールアップに肯定的だったが、ほかの顧客は意見が異なり、Microsoft Software Update Services（SUS）の導入やMicrosoft Systems Management Server（SMS）の改良などを通じてフィックスの適用に対処できることを示唆したという。これらの方式は企業顧客には機能するが、Windows Updateにダイヤルアップでアクセスしている顧客のニーズには対応しない。

将来の方向性と課題

　WSEはフィックスを公開しているほか、フィックスの導入を簡略化する技術を開発している。例えば、WSEはMicrosoftのパッチ・テクノロジを8種類から2種類（OS用に1種類とアプリケーション用に1種類）に変更する取り組みを監督したり、パッチの全体サイズを縮小してフィックスやService Packのダウンロードとインストール時間を短縮する試みを行ったりしている。

　だが将来、WSEは2つの大きな難問に直面するだろう。１つは、MicrosoftがWindowsの次期リリース（開発コード名Longhorn）に非常に集中していることに起因する。Windows開発チームがWindowsのリリースに向けて仕事をするにつれ、WSEチームは頻発するセキュリティやそのほかの問題（機能の拡張や新規ハードウェアのサポートの要請など）の面で現行バージョンをサポートするのがますます困難になるだろう。なぜならば、変更の開発や見直しを助けてくれるバディがLonghornの作業に専念しているからだ。もう1つの難問は、WSEのリソースの減少に起因する。Microsoftは、Windowsやそのほかの製品の現行の売り上げから将来のサポート費用とする積み立て金を減らし始めている。これは製品の熟成とサステインド・エンジニアリング・プロセスの効率化による当然の結果かもしれないが、将来のサポート用リソースの減少をも意味するだろう。

参考資料

• Windowsのバグがどのような方法で自動収集されMicrosoftに報告されるかについての追加情報は、Directions on Microsoft日本語版2003年7月15日号の「Windows Error Reporting、バグ追跡の仕組みを探る」を参照。

• ソフトウェアのバグに関する追加情報は、Directions on Microsoft日本語版2003年8月15日号の「Microsoftのバグ追跡システムRAIDとは？発見から解決まで‐バグはこうして処理される」を参照。

Directions on Microsoft日本語版 本記事は、（株）メディアセレクトが発行するマイクロソフト技術戦略情報誌「Directions on Microsoft日本語版」から、同社の許可を得て内容を転載したものです。『Directions on Microsoft 日本語版』は、同社のWebサイトより定期購読の申込みができます。

　

「Insider's Eye」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）