|
|
||||
|
|||||
|
|||||
|
|
|
|
||||||||||||||
|
||||||||||||||||
 |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||
Notes/Domino 環境におけるプロセスの定義 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||
Lotus Workplace Technical Evangelist, IBM レベル：初級 原文の掲載：2004年10月4日 更 新 日：2005年7月8日更新  原文はこちら はじめにこの記事では、Lotus Notes/Domino 環境で信頼性と可用性を保証する優れたプロセスを開発する方法について解説します。もちろん、ユーザーをスタートレックのボーグ (Borg) に変身させることのない方法です。人々が「プロセス」という言葉を耳にしたとき、多くの場合、官僚主義、形式主義、遅滞、そして (スタートレックのファンであれば) 人々の自由意志を奪うボーグの構想などを思い浮かべることでしょう。プロセスは邪魔もので物事を遅くするだけでしょうか。常にそうだとは限りません。プロセスは、生き残る方法であり、無秩序や過度のコストを防ぐ方法でもあります。このことは、特に情報技術にあてはまります。 私たちは、ボーグのように、プロセスのためのプロセスを主張するわけではありません (部屋に 20 人の人間を入れると少なくとも 20 の視点が常に得られますが、部屋に 20 のボーグを入れると非常に退屈な集団になるでしょう)。その代わりに、この記事の目的は、アプリケーション開発を円滑化し、全体の実行時間を短縮し、IT コストを削減する、共通認識としてのプロセスを推進することです。IT インフラストラクチャーはビジネスのバックボーンです。実際に、インフラストラクチャーが損なわれると、企業の利益までも損なわれてしまいます。このため、企業のビジネス情報システムのコンポーネントをアップグレードすることは、IT 投資を十分に管理および制御できない組織にとっては、遅く、単調で、イライラするようなプロセスになる可能性もあります。 この記事では、アプリケーションの開発と導入、品質保証、パフォーマンスとサイジング、根本原因分析 (RCA: Root Cause Analysis) を含むいくつかのプロセスについて解説します。記事で書かれているプロセスは、単に学術的なモデルではなく、IBM 内で使用されている実社会でのプロセスをベースとしています。したがって、グローバルな情報技術運用の一部としての各プロセスの価値について、わかりやすい実例が存在します。この記事を読むために、Lotus Notes/Domino または他の IBM/Lotus 製品に関する経験は必要ありませんが、ソフトウェア開発とシステム管理についての知識があると、記事に掲載されている例や提案を理解しやすくなります。 アプリケーション開発と導入ビジネス情報システム・フレームワーク内に存在するすべてのアプリケーションにとって、開発と導入は必要不可欠な最初のステップとなります。アプリケーションをどのような方法で開発および導入するのかは、それ以降のプロセス (たとえば、アップグレードや移行など) に大きな影響を与えます。Lotus Notes/Domino の長所の 1 つとして、アプリケーションを非常に素早く開発および導入できることが挙げられます。しかし、アプリケーションの開発、導入、およびメンテナンスを管理し、制御するためのプロセスが適切に定められていないと、この長所がすぐに短所に変わってしまうこともあります。これらのプロセスがないと、どのようなアプリケーションが環境に導入されたか、その目的は何か、誰が責任を持つのか、壊れたときはどうしたらよいのか、といったことを把握できなくなります。これは、IT 組織が直面する最も大きな悪夢である「アプリケーション・アナーキー」につながります。 標準 多くの企業では、成長とセキュリティーを考慮し、IT インフラストラクチャーに関して少なくとも何らかの基本的なルールを持っています。しかし、社内ユーザーからインフラストラクチャーを保護する方法は、必ずしも準備されているとは限りません。これを行うには、アプリケーション開発の標準を定義しなければなりません。これらの標準には、次の内容を含める必要があります (しかし、これだけに限定はされません)。
アプリケーション開発環境 標準を定義することは始まりに過ぎません。開発チームには、アプリケーションを開発し、テストするための環境が必要です。実働へスムーズに移行するためには、ターゲットの実働環境に似せてこの開発環境を構築し、同じ運用ルールに従う必要があります。ただし、1 つだけ重要な例外があります。それは、アプリケーション開発チームに、常駐アプリケーションへの開発レベルのアクセス権を与えなければならない点です。これは、ターゲットのインフラストラクチャーに適合するようアプリケーションを開発するために役立つだけでなく、期待どおりにアプリケーションが実行される可能性も高めます。 また、アプリケーションの「培養期間」を利用して、アプリケーションについて、その完成時期や目的を IT チームに知らせることができます。これは、実働に向けての最終的な配備を行うまで、アプリケーション開発を計画通りに進めることにも役立ちます。したがって、IT チームは参加時にアプリケーションが何をするために設計されるのかをある程度理解していることになります。そして、アプリケーションの品質保証や統合検証が行われる時点では、IT チームが開発チームを支援する体制が整います。これは配備プロセスの一部であり、サイジングとチャージ・バック用にアプリケーションを検証する際にも有効です。また、インフラストラクチャーのアップグレードにともなって必然的に発生する、アプリケーションの回帰テストでのアプリケーションの識別にも役立ちます。 品質保証と統合検証 一般に、品質保証は、環境の運用を保護するために設計された既存の標準にアプリケーションが適合することを保証し、統合検証は、標準の共有環境の制限内でアプリケーションが実行できる能力を検証します (言い換えると、新しいアプリケーションが既存のアプリケーションと共存できるかどうかの検証です)。実働環境に似た開発環境を用意することで、アプリケーションがこのプロセスを経て実働に至るまでのスピードを加速できます。アプリケーションの品質保証と統合検証の目的は、社内の実働環境でアプリケーションを使用する前にアプリケーション内の障害を発見することなので、問題が発見された場合は、アプリケーションを開発環境に戻して、修正を行うことになります。しかし、このような事態が発生した場合でも、長い目で見るとデータとデータの使用者にはより良い結果をもたらします。
義務の分離特にプロセスに限らず、義務を分離することは、ビジネス・アプリケーションの開発チームを、アプリケーションが置かれる環境の運用チームから確実に分離することに役立ちます。これにより、潜在的なセキュリティーと運用面での問題を緩和し、その環境のシステム管理者がアプリケーションに対する責任を負い、変更を実働に組み入れる前に、すべてのアプリケーションの配備または変更が、適正な運用に向けて十分にテストされた状態になります。したがって、これらの境界は、不慮の事故からデータとインフラストラクチャーを保護するために役立ちます。
チャージ・バック報酬の社会では、サービスへの支払いは一般的な習慣です。これを IT 運用に適用すると、アプリケーション・アナーキーを制御するための重要な手段が得られ、キャパシティを常に利用可能にするために役立ちます。これを実装する最も簡単な方法は、企業環境での使用のためにアプリケーションを所有する組織に対し課金することで、このプロセスをチャージ・バックといいます。 効果的なチャージ・バック・プロセスは、アプリケーションに必要なデータベースの数、データベースのディスク上でのサイズ、使用量、バックアップと保持の必要性、他のシステムとデータとの相互接続などを考慮しています。これは、基本的に共有インフラストラクチャーにおける貸すためのキャパシティと同一視することができるので、サポートと維持が必須となります。これがもたらす効果として、組織は使用するアプリケーションを慎重に管理し、同じ組織の不要なツールは使用されなくなります。これによって、アプリケーション・アナーキーと制御されていない IT 経費を制限することができます。 また、チャージ・バックにより、「借り手」のニーズに一致するリソースを常に用意するために利用できる適切な資金が得られます。
回帰テスト (Regression testing)人間は、ボーグが行うようにすべての市民を同化させることによって、知識や技術を得ることはできません。私たちは、伝統的な試行錯誤プロセスを通して発見し、理解します。これは、アプリケーションを初めて作成するときだけでなく、変更や更新を行うときも、作成した製品のテストが必要であることを意味します。アプリケーションの新しいリリースを公開するときは、追加された新機能とバグ・フィックスが既存の機能を損なわないことを確認するために、テストをしなければなりません。同様に、新しいアプリケーション、プラットフォーム、または他のソフトウェア・コンポーネントを環境に導入するときは、環境内の既存のアプリケーションが導入後も正常に動作し続けることを確認する必要があります。このプロセスは、回帰テスト、または簡単に回帰と呼ばれます。回帰テストは、すべてのアプリケーション開発と導入作業において必須のプロセスです。 アプリケーション・サーバーの新規リリースを使用してアプリケーションの回帰テストを行うことにより、アプリケーションのエンド・ユーザーに対して、アプリケーションの可用性が確保されます。たとえば、Lotus Domino では、メール、アプリケーション、および拡張された製品に対し、Domino 7 NSF システムと Domino 7 DB2 の両方によるテストを実施することがあります。これにより、新規リリースへのアップグレード前に、主要アプリケーションの回帰を完全にテストできます。 IT 組織にとってもう 1 つの重要な作業は、ビジネスにおける同様の要求をカバーする標準アプリケーション・テンプレート群を提供することです。たとえば、企業内において、部門別の業務、部門と組織の予算編成、ミーティング管理、プロジェクト管理のそれぞれに標準テンプレートが用意されている場合、回帰テストは各アプリケーション・タイプごとに 1 回実行するだけでよく、個々の事例に対して何百回も実行する手間が省けます。回帰テストの回数を減らすことは、アップグレードのサイクル・タイムを減らすことになり、コストを大幅に削減できます。
クラスタリングとロード・バランシング多くの企業は、ビジネス・クリティカルであると認識しているインフラストラクチャー・コンポーネントを持っています。これは、この環境が危険にさらされると、従業員の生産性も危険にさらされることを意味します。これらの多くの企業にとって、収益の向上に直接結びつくアプリケーションの中でも、電子メールは最上位に位置します。また、これには、インスタント・メッセージングなどのコラボレーション・ツールも含まれています。たとえば、インスタント・メッセージングの例として、IBM 全体で使用されている Lotus Instant Messaging (Sametime) などがあります。ツールが組織にとってクリティカルなものになるにつれ、その可用性はより緊急度が高まります。 クラスタリング 重要なアプリケーションが置かれているサーバーをクラスタリングすることは、サーバーが突然停止したときの可用性を最大限に高める優れた方法です。サーバーの停止は考えにくい状況ですが、アプリケーションまたはメール・サーバーのアップグレードによって発生する可能性があります。アプリケーション (電子メール・アプリケーションも含む) をクラスター化すると、データがアプリケーション内に蓄えられている場合は (多くの Domino アプリケーションと Domino メールではこのようになっています)、アプリケーションとデータのまったく同一のコピーが 2 つ存在し、利用できることになります。また、1 つのコンポーネントがダウンしたときに備え、全体の可用性を確保するために、データ・リポジトリーをクラスター化することもできます (データ・リポジトリーがアプリケーションと分離している場合)。 LDAP ベースのディレクトリー・サーバー (容量の要件を満たすために複数のサーバーを必要とするコア IT サービス) は、クラスタリングに適しています。当然ながら、IBM は IBM Directory Server (現在の IBM Tivoli Directory Server) を使用し、ロード・バランシングとフェイルオーバー用に IBM WebSphere Edge サーバーを使用して複数のインスタンスをクラスター化しています (ロード・バランシングの詳細については、このセクションで後述します)。 Domino メールは効果的にクラスター化できます。しかし、エンド・ユーザーは特定のメール・サーバーまたはメール・サーバーのクラスターに直接結び付けられる必要がある点で、モデルが少し異なります。可用性はクラスターのペアで維持されます。可用性の維持には、WebSphere Edgeサーバーは使用せず、Notes Client と Domino Server の組み合わせによって提供される標準機能を使用します。これによって、クラスターのパートナーがダウンしても、エンド・ユーザーからメールファイルへのアクセスが継続されます。 IBM における Lotus Instant Messaging の内部実装では、モデルは LDAP サーバーのコア・サービスにより近く、各 Community サーバーは相互に他の複製となっていて、エンド・ユーザーは特定のサーバーに結び付けられることはありません。その代わり、ホーム・サーバーがクラスター名となります。このケースでは、インスタント・メッセージング環境は、上記で説明した共有 LDAP ディレクトリー・クラスターからのディレクトリーと認証用のリソースを消費します。そして、メンバーリストとプライバシーリストは、別のリレーショナル・データベース・インフラストラクチャー (IBM のケースでは DB2 ) に保存されます。このようなサービスの連携をクラスタリング・オプションと組み合わせると、すべてのサービスの可用性を最高のレベルで維持することができます。高可用性が必要なインフラストラクチャーをアップグレードするときに、この重要性が高まります。 IBM の Lotus Instant Messaging (Sametime) の配備の詳細については、記事『The hitchhiker's guide to Sametime deployment at IBM』および『Life in the fast lane: IBM moves to Sametime 3』を参照してください。 バックエンドのリレーショナル・ストレージも、可用性の強化のために設定できます。その 1 つのオプションとして、HACMP (High Availability Cluster Multiprocessing) を使用して DB2 インスタンスをクラスター化する方法があります。これによって、データ・ストレージは Single Point of Failure (単一箇所の障害がシステム全体の障害を引き起こすこと) にはならなくなります。 Lotus Instant Messaging と Domino メールおよびアプリケーション・サーバーのケースでは、高可用性の環境もアップグレードの失敗から保護する機能を提供します。高可用性を維持したまま新しいソフトウェア・リリースを導入するには、安定したリリースを保持しながら新規リリースを検証することにより、1 つのクラスター・メイトをアップグレードします。 ロード・バランシング 弾力性のあるインフラストラクチャーを設計することは、優れた可用性を保証するための 1 つのキーとなります。これを実現する 1 つの方法として、ロード・バランシングがあります。クラスター化したシステム全体にわたって負荷を分散することにより、各キー・サービスごとに最大限の可用性が得られます。これには多くの方法がありますが、その中の 1 つとして、まず、提供されるサービスを介して IT インフラストラクチャーをセグメントに分割することから開始します。これによってサービスも分割され、各サービスは特定のインフラストラクチャー・リソースを個別にターゲットとします。これで各サービスが相互に与える影響が制限され、可用性と高い弾力性のために同様のサービスをクラスター化する手段が得られます。サービスの実装方法が異なるため、クラスタリングの手法もそれに応じて異なります。 WebSphere Edge サーバーなどのロード・バランサー技術は、ソリューションの構造が適切でない場合は、Single Point of Failure になる可能性があります。WebSphere Edge サーバーは、一次サーバーがダウンしたときに二次サーバーが「ホット」スペアとなれるように、クラスター化することができます。これは、ユーザーの負荷をターゲットのインフラストラクチャーに分散し続けることができることを意味します。
アップグレードの保護アップグレードまたは移行の際には、これ以外の注意も必要です。たとえば、Domino の新しいバージョンを混在環境に導入することは、Domino ディレクトリとテンプレートなどの主要ファイルの新しいバージョンや、ODS (on-disk structure) の更新されたバージョンが混在することを意味します。 回帰テスト機能は、前のバージョンとの互換性を検証する方法を提供します。しかし、完全に実働環境として用いられている IT 環境では、より一層の注意が必要です。システムの安定性に影響を与えるのを避けるために、新しいファイルが古いサーバーと共存できることが確認されるまでは、新たにアップグレードされたサーバーからインフラストラクチャー内の他のシステムに、新しいファイルやテンプレートを複製または移動しないようにしてください。この点に関し、構造化された手法を確立することにより、特にカスタマイズされた環境で非互換性による問題が発生した場合でも、組織はダウンタイムを削減できる利点を得られます。
パフォーマンスとサイジング言うまでもなく、ボーグはエンド・ユーザーの満足度をまったく考慮しません。しかし、私たち人間にはその点についての考慮も不可欠です。アプリケーションの成功は、エンド・ユーザーの視点から見たときにアプリケーションがどれだけスムーズに動作するかにある程度依存します。これには、エンド・ユーザーの応答時間だけではなく、予測されたエンド・ユーザー数と比較して、アプリケーションがサポートできるユーザー数も含まれています。 設計どおりにアプリケーションが機能することを確認し、実働への移行後に、最大のロード下でもアプリケーションが機能するよう十分なインフラストラクチャーを用意するには、正確なサイジングが不可欠です。パフォーマンスの標準をサポートすることで、設計がリーズナブルなパフォーマンス測定規準に合致するか、それを超えるまでは、アプリケーションが実働状態に入るのを防止できます。これによって、エンド・ユーザーが恩恵を受けるだけでなく、導入後にパフォーマンス関連の緊急事態が起きる可能性が低下します。
根本原因分析 (RCA: Root cause analysis)優れたソフトウェアに障害が発生する、という事態について考慮しましょう。IT 環境でこのような可能性をゼロにする方法は、何も変更せず、一度動き出したら誰にもそれを使用させないことです (「The only people who do nothing wrong are people who do nothing」(悪いことをしないのは、何もしない人だけ) という古い格言があります)。実際には、これは現実的ではないので、IT チームは最悪の事態に備える必要があります。 問題が発生する場合は、傾向を把握することで解決が容易になります。しかし、これは症状への対処であって、障害そのものへの対策ではないこともあります。忘れがちなのは、最初になぜ問題が発生したのかを明らかにするプロセスで、これによって、今後の発生を防止する手段を講じることができます。根本的な原因を発見することが、将来の可用性を保護する先見性のある対策となります。これを行うプロセスを (ごく自然に) 根本原因分析と呼びます。簡単に RCA と言うこともあります。 RCA は構造化されたプロセスです。RCA には、テクニカル・スキルが必要で、障害を引き起こす可能性があるすべての原因を明らかにするための時間もかかります。これには、ネットワーク・ルーターからアプリケーション・サーバー・インフラストラクチャーに至るすべてのログを解析し、このデータに基づいて、予防措置を開発して適用する、あらゆる作業が関わってきます。 RCA には、次の手順が含まれます (ただし、これだけに限定されません)。 RCA を開始する条件を定義します。 RCA の条件に基づいてレポートされたインシデントを確認します。 RCA コーディネーターを割り当てます。コーディネーターには、会社によって決められた役割やトレーニングが必要なことがあります。 引き金となったインシデントを文書に記録します。 インシデントに対する RCA 対策を定義します。これには、問題を解決し、将来的な発生を防止できる担当者を決定することも含まれます。 ビジネスおよびユーザーへの影響に基づいて、インシデントの優先順位を決定します。 RCA ミーティングとアクティビティのスケジュールを設定します。 RCA ミーティングに先立ち、考えられる原因を探るためにインシデントを調査します。この調査には、適切なシステム・ログ、変更要求、問題レポートと苦情、テスト計画、影響のあった製品の被害レポートの分析などがすべて含まれます。 関連する、または影響のあったシステムをモデル化します。 RCA ミーティングを招集します。 原因と対策について意見を交換します。 問題の詳細と推奨される修正方法を記述したレポートを起案します。 結果と推奨事項を適切なユーザーに知らせます。 問題が解決されるまで、実施した項目、交換された意見、および RCA プロセス全体の状態の推移を記録します。 根本原因分析の詳細については、記事『Applying the Fishbone diagram and Pareto principle to Domino, Part 1』および『Applying the Fishbone diagram and Pareto principle to Domino, Part 2』を参照してください。
まとめボーグは常識に近いものをほとんど示しませんでしたが、あらゆることにプロセスを持っていました。私たち人間にとって、プロセスの採用に向けた論理的な取り組みは、複雑な IT 環境をより簡単に実行するための原動力となります。そして、これらのプロセスは、コスト管理、障害にともなうダウンタイムの削減、エンド・ユーザーの満足度の改善に役立ちます。また、高可用性に対応するよう設定されたシステムは新規リリースへのアップグレード中も可用性の提供を維持できるのに対し、プロセスはアップグレードの難しさとサイクル・タイムを減少させることに貢献します。そして、結論として、ボーグが最後の決戦に敗れたことを思い出してください。これは、私たち人間が船外に出られることを意味します。
リソース
筆者について(原文のまま)Matt Broomhall started working at IBM back when Notes 3.0 first shipped. He has held positions in the Microelectronics Division and the IBM CIO office where he was responsible for deploying software tools that allow people and teams to more effectively collaborate. Matt's team deployed Sametime Connect throughout IBM. Matt has been team lead for the Solution test team within Lotus Engineering Test and has recently joined the Lotus ISV Enablement team. Matt skis in the winter and jogs when there is no snow. Matt's fondness for traveling to Disney World with his family as well as his home theater play prominently with his other leisure activities.
|
|
|||||
|
