Grigory Kornilov（Kaspersky Lab）へのインタビュー

Kaspersky LabのシニアサービスマネージャーであるGrigory Kornilovにインタビューしています。 グレゴリーは、クラウドIaaSプロバイダーのリソースを使用してユーザーにコンピューティングインフラストラクチャを提供し、このサービスが厳格な企業SLAに準拠する責任を負います。



グレゴリーは、IaaSを使用した2年間の経験と、外部クラウドのリソースを使用するという決定に至った経緯について説明します。



グリゴリー、カスペルスキーはどのくらいの期間、どのような状況でクラウドサービスに注目しましたか？



インフラストラクチャでの「クラウド」サービスの使用は、5年前に、プライベートな「クラウド」を構築した会社との小さなプロジェクトから始まりました。 ただし、この会社とのやり取りは、サービスプロバイダーとのやり取りではなく、仮想化環境の機能に関する一切の義務なしに機器をホストしサポートした会社とのやり取りで行われました。 機器を購入し、サードパーティの会社に置いたところ、彼女が機器のオペレーターになったことが判明しました。 仮想化環境の機能に対する正式な法的責任の欠如は、私たちと私たちの要求に対する態度に影響を与えました。 新たな問題を解決する動機と速度は、私たちには適していませんでした。



これにより、サービスプロバイダー、つまり 私たちと一緒に仕事をするとき、責任範囲の幅を理解する企業。 当時、かなり大きな拡張が予想されていたため、管理者の数を増やしたり、ハードウェアを購入したり、頑丈なシートを購入したりすることは望みませんでした。 一定の評価を行い、サービスプロバイダーがより良いまたは同等のオファーを提供し、インフラストラクチャを開発するための人件費が最小限であることに気付きました。 また、経験から、サービスは通常安くなり、従業員は逆に高くなっています。 そのため、サービスプロバイダーのクラウドインフラストラクチャを使用することを決定し、回答の準備ができているものとサービスプロバイダーが責任を負うべきものを明確に規制しました。



ロシアのクラウドプロバイダーまたは西側のプレーヤーのみを検討しましたか？



もちろん、まずインフラストラクチャと高品質のネットワーク接続を整理する必要があるため、ロシアの代表者を検討しました。 市場、企業の認定、およびクラウドサービスの提供方法を​​調査した結果、ITサービス市場のこのセグメントはモスクワとサンクトペテルブルクで最も発展していることがわかりました。

私たちはいくつかのヨーロッパのサービスプロバイダーを見ましたが、私たち自身にとって大きな利点は見つかりませんでした。 さらに、海外に配置する場合、ネットワーク接続、速度、およびメンタリティ、専門家の3番目のラインが異なるタイムゾーンにある場合の時間差についての質問が発生します。 これらの要因はすべて、サービスサポートのレベルに悪影響を与える可能性があります。 したがって、ロシアのサービスプロバイダーが優先されました。 コストに関しては、欧米のサービスの方がはるかに収益性が高いとは言いません。



グレゴリー、従業員のコストを上げる傾向の理由は何ですか？



ソリューションをサポートする従業員を自分で維持することは問題です。 これらは非常に高いレベルの専門家です。 当社の重要な目標は、アップデートをリリースするビジネスプロセスをサポートすることです。これは、24時間年中無休で機能します。 高級専門家を含む24時間サポートサービスに投資する必要があることがわかりました。 そして、モスクワの有能な専門家のコストは増加し続けています。



グレゴリー、あなたは専用の物理サーバーを借りることを考えましたか？ クラウドと専用サーバーのレンタルに関する多くの論争と比較はまだインターネット上で行われています。



私たちの主な費用は、サーバーではなく仮想化ソフトウェアで作業するシステム管理者に費やされるため、専用サーバーのオプションを考慮しませんでした。 これらは最も高価な専門家です。 したがって、サードパーティのサービスプロバイダーのサービスを使用する場合は、仮想環境の管理も含まれます。



ラックシートのレンタル、機器の購入、操作の十分な経験があります。 サポートラインの費用はわかります。 自分にとって最も価値のある部分を残すことは、奉仕の方向に一歩踏み出さないようなものです。 通常、ユニットやコンポーネントで複製された機器では、本当に深刻な問題は発生しません。 したがって、ホスティングプロバイダーのみをサービスプロバイダーに提供するのは非効率的です。



グレゴリー、クラウドプロバイダーを検討する際、どのパラメーターに注意を払いましたか？



受けたいサービスのビジョンを形成しました。 SLA（要求されたペナルティなど）または私たちが期待する責任範囲の配分に同意しなかった浅いプロバイダー。 また、技術的な問題について同意していないサービスプロバイダーを解雇しました。 ユーザーは、独自のインフラストラクチャのフレームワーク内で特定のツールを使用することに慣れているため、プロバイダーは、クラウドで作業するための同一のツールを提供する必要があります。 これらはハイライトです。



何人のサービスプロバイダーがSLAの表示を拒否しましたか？



8人のうち1人は拒否しましたが、彼は私たちが要求したツールと必要なSLAに満足していませんでした。



どんなツールについて話しているのですか？



VMware vCenterでリソースプールと仮想マシンを直接管理するためのアクセスが必要です。 サービスプロバイダーが仮想化環境全体の責任を負うことを決定し、特定のリソースプールに対する管理者権限を切り捨てて、管理者が独自に新しいマシンを作成し、接続し、それらをオフにするようにします。 拒否されたサービスプロバイダーは、VMware vCloud Directorの使用を主張しました。この管理は、すでに使用しているvCenterとは大きく異なります。



VMwareも使用しているサービスプロバイダーのみを検討していることを正しく理解していますか？



はい 仮想マシンを操作する（仮想化をサポートしない、つまり仮想マシンを操作する）管理者は、vCenterの操作に慣れています。 それらを異なるインターフェースで再トレーニングし、異なる環境で動作させることは、追加の不必要なコストです。



グレゴリー、プロバイダーをどれほど深く勉強しましたか？ 宣言されたSLAを実現する実際の能力を確認しましたか？



プロバイダーの調査は、ベンダーとの認定の有無を確認することから始まりました。パートナーのステータスを確認しました。 サービスの実装に基づいてデータセンターの品質を調査し、VMwareソリューションに関するサービスプロバイダーの経験を調査しました。



私たちにとって非常に重要な点は、データストレージシステムのサービスプロバイダーの能力でした。私たちの意見では、これはインフラストラクチャで最も難しいことです。 サーバーに障害が発生すると、仮想化環境がバックアップサーバーで仮想マシンを再起動するため、一部の仮想マシンのダウンタイムがわずかになります。 また、ストレージの障害は、ほぼすべての仮想サーバーを一度に「置く」ことができます。 不適切にインストールされたソフトウェアは、ストレージ全体を使用できなくなる場合があります。



通常、製造元の構成では1つのストレージシステムが使用され、完全に複製され、フォールトトレラントです。 この場合、この倉庫を管理および保守する従業員の能力が非常に重要です。 さらに、ストレージシステム全体の大量販売を確認する十分なステータスがありません。 ストレージ管理者用の証明書が必要です。



ストレージのレベル、構成、ディスクの種類に注意を払いましたか？



はい、少なくともミッドレンジレベルのストレージシステムが必要でした。 そのため、ストレージの更新に関する運用作業は、ダウンタイムなしで実行されます。 これが前提条件でした。



データストレージシステムの使用に関する独自のプラクティスに基づいて、どのような種類のディスクサブシステム構成が必要かを事前に知っていました。 これも要件として定義しました。 サービスプロバイダーは、追加の利点（キャッシュ、ソリッドステートドライブ）を提供しました。



クラウドにどのようなタスクを引き受けましたか？



当社には、アンチウイルス製品のモジュールおよびアンチウイルスデータベースの更新を発行するビジネスプロセスがあります。 このプロセスは非常に重要であり、24時間365日継続的に実行されるパイプラインにより、サポートされているすべてのプラットフォームで更新がテストされ、時間通りにユーザーに配信されます。



これらのアップデートをリリースするスペシャリストのスタッフ全員が24時間体制で働いていますか？



はい。このプロセスには、システム管理者、開発者、ウイルスアナリストによる24時間体制のサービスが含まれます。 このプロセスが停止した場合、当社の製品は低品質のアンチウイルス保護を提供することになり、これは許可されません。



リソース要求プロセスは、内部顧客にとってどのように見えますか？



内部ユーザーにとって、必要なリソースを受け取る場所と根本的な違いはありません。 ユーザーは、社内ITサポートサービスにリクエストを送信して、リソースプールを拡張したり、新しいリソースプールを作成したりできます。 ユーザーは、当社がリソースプールに支払う予算がユーザーごとに分類され、内部請求が実行されることを知っています。



また、特定のレベルのリソース拡張には一定の時間が必要であると内部ユーザーに警告されることにも注意してください。 ただし、追加のリソースについては、合意された担当者のみが外部サービスプロバイダーに連絡してください。



サービスプロバイダーのSLAに含めたパラメーターはどれくらい難しいですか？



外部サービスプロバイダーとのSLAは、内部ユーザーの前でのSLAよりも厳密でなければならないという事実から進めました。



これが私たちの唯一の環境ではないことを考えると、2時間はサービスプロバイダーに許可する最大のダウンタイムです。 ダウンタイムに伴うリスクを補うことができる独自の計算能力があります。



ダウンタイムが2時間を超える場合、すでにペナルティがあります。 1か月あたりの費用の100％の支払額の罰金は、2日以上のダウンタイムで達成されます。



クラウド内のインフラストラクチャの結果をまとめましたか？



もちろん、失望させます。 サービスの可用性に関する統計を収集し、社内のビジネス顧客と話し合いました。 サービスの質は5つと評価されました。 唯一の望みは、1つのサービスプロバイダーへの依存を減らすために、同じ品質の2番目のプロバイダーからのサービスを実装することでした。



サービスの可用性をどのように測定しますか？ 監視ツールを使用していますか？



もちろん、サービスの可用性は監視システムによって管理されており、監視システムを通じて社内の顧客に報告されます。 問題は、サービスプロバイダーだけでなく、インフラストラクチャのジャンクションや当社側でも発生する可能性があります。 内部SLAがサービスプロバイダーのSLAよりも広いことに注意してください。



他のサービスをクラウドに移行する予定ですか？



現在、そのような計画はありません。 私たち自身のインフラストラクチャが私たちに残る可能性が高いことに注意してください。 社内の能力と最低限の独立性が必要です。



サービスプロバイダーに関する追加要件を提出しましたか？



はい、たとえば、サービスデスクシステムの統合。 誰かがどこかに行き、アプリケーションを作成するために何かをしなければならないという選択肢に満足していませんでした。 特定の形式の電子メールメッセージの交換に基づいて、ITサービスデスクシステムの統合を実装するための要件を決定しました。



ユーザーは、当社のITサービスデスクに連絡します。 このシステムでは、サポートスペシャリストが特定のグループのアプリケーションを指定します。 自動的に、同時に、調整されたメールボックスの要求がサービスプロバイダーに送信されます。 サービスプロバイダーは特定の形式で応答するため、その応答はITサービスデスクシステムの最初の要求に結び付けられ、ユーザーにすぐに表示されます。 したがって、サービスプロバイダーとユーザー間の対話を加速し、サポートサービスの最初の行の負荷を軽減します。



グレゴリー、クラウドの使用を考えている他の企業の同僚にどのようなアドバイスを与えることができますか？



まず、セキュリティサービスと連携して、サービスプロバイダーの側に提供するデータを調整する必要があります。 セキュリティサービスは、提供できるものとできないものを決定します。 このようなリスク評価を実施し、このサービスの使用に一定の制限を導入しました。



どうもありがとう。



またね



IT-GRADの開発ディレクター、セルゲイ・チュカノフによるインタビュー