インターネットプロジェクトの安定性：方法// Mail.Ru Technology Forum 2011のレポート：レポートのテキスト、ビデオ、プレゼンテーション

レポート「 ウェブサイトの安定性：方法 」は、Mail.Ru Technology Forum 2011の一連のトランスクリプトの次のものです。 レポートを復号化するシステムの仕組みの詳細については、 Mail.Ru Technology Forum：High-tech in event-managementの「Inside Out」記事を参照してください。 フォーラムWebサイト（ http://techforum.mail.ru ）および他のレポートのトランスクリプトへのリンクもあります。

（モバイルデバイス用のビデオバージョンをダウンロード -iOS / Android H.264 480×368、サイズ170 Mb、ビデオビットレート500 kbps、オーディオ-64 kbps）

（高解像度ビデオバージョンH.264 624×480、サイズ610 Mb、ビデオビットレート1500 kbps、オーディオ128 kbpsをダウンロードします）

（プレゼンテーションスライドのダウンロード 、5.5Mb）



大規模なサイトで作業や中断の問題が発生するたびに、膨大な議論が発生することはおそらく秘密ではありません。 私はあなたのサイトがクラッシュしないか、少なくともクラッシュしないようにする方法を教えようとします。 Mail.Ruでこれに対して行うこと、使用するメソッド。

安定性が重要です。

ウェブサイトの安定性-原則として重要ですか？ この主題については多くの意見があります。誰かがこれが重要であると考え、誰かがとりわけこれが最も重要な要因ではないと考えています。 これは非常に重要だと考えており、主な理由は3つあります。







ご存知のように、インターネット上のほとんどのサービスは無料です。 そして、あなたのサイトがダウンし、スローダウンし、いくつかの問題が発生するとすぐに、ユーザーは競合他社に向かいます。



2番目の理由は、インターネット上のサービスを切り替えるしきい値が非常に低いことです。 どこに行く必要もありません。モバイルオペレーターの場合のように切り替えに高いコストはかかりません。また、慣れているサービスが機能しない場合は、いつでも別のサイトに切り替えることができます。 さらに、そのような気分を害するユーザーがあるサイトから別のサイトに移動するのを助ける膨大な数の補助機能があるため、安定性が重要です。



3番目の理由は、インターネットに関するものではありません。 ネガティブな感情は常にポジティブな感情よりも強くなるように人が構成されていることをすべて理解する必要があり、サイトでの1つの事故は、原則として、膨大な安定した作業時間、サービスの質などをカバーします。



これら3つの理由から、サイトは安定して動作するはずですが、平均して、インターネットの安定性のレベルはそれほど高くありません。 内部統計によると、平均的なロシアのインターネットサイトには稼働時間があります。 「労働時間」-98.6％。 この数字はひどいものではありませんが、よく見ると、平均的なWebサイトがダウンしているのは1年に5日です。 これはかなり長い時間であり、問​​題が存在し、問題が非常に深刻であることを示しています。 もちろん、大規模なWebサイトの方が少しうまく機能します。 大規模なWebサイトには、年間約4時間の「非稼働」時間があります。 しかし、それでも、特に5日間ほど覚えている場合、これらはすべて大きな数字です。

事故の原因

Mail.ruの統計に基づいて、私たちとロシアのインターネット上の他のサイトで事故が発生する理由を分類しました。 量的分布について言えば、サイトの機能が機能しない、サイトが存在するなどの事故の数を意味します。インターネット上のサイトクラッシュの半分は、ソフトウェアリリースの誤り、バグのあるソフトウェアリリースによるものです。曲がった設定。 したがって、ケースの半分では、再び注意を払いたいと思います-定量的には、開発者、テストされていない、ひどくリリースされたシステム管理者などが責任を負います。 別の25％のケースはソフトウェアのクラッシュであり、これにはサイトの負荷も含まれます。16％のケースはネットワークのクラッシュ、8％はサーバー、サイトが動作するコンピューターのクラッシュです。







定性的分布を見ると、まったく異なります。 ご覧のとおり、最もひどいクラッシュはネットワーククラッシュとデータセンタークラッシュです。 それらから自分自身を守ることは非常に困難です。 原則として、リソース全体または大規模なホスティングを完全にオフにしますが、多くのリソースは同時に機能しません。 それらはそれぞれ30％を占めます。 以下は、新しいソフトウェアをリリースする際のクラッシュです。 これに続いてソフトウェア事故が発生し、最後には機器事故がわずかな割合を占めています。

モニタリング

あなたのサイトを安定させる方法について話すために、私たちはまず私たちのサイトで何かが間違っていることをどうやって見つけるかを議論する必要があります。 このオーディエンスのすべてのITスペシャリストが、監視が必要であると私に主張することはないと確信しています。 誰になりますか？ また、この聴衆には監視をしていない人がいると確信しています。 監視する10の理由を簡単に挙げてみましょう。 監視が必要であることに同意することは承知していますが、このリストを見ていきましょう。









最初の理由は非常に単純に聞こえます：あなたは優秀なプログラマーであり、さらに優れたシステム管理者ですが、あなたのサイトはまだ落ちます。 あなたが何をしても、それは起こります-明日、1年で-それは重要ではありません。 とにかくそれは起こります、それを戦うことは不可能です、それは間違いなくあるので、常にこれを覚えておいてください。 私たちのサイトが倒れたことを知るためだけでなく、監視が必要です。 サイトが再び機能するように、できるだけ早く対策を講じるために必要です。 サイトが短期間機能しない場合-これはユーザーにとって1つの問題であり、サイトが5日間機能しない場合-これは異なる順序の問題です。



サイトの問題についてユーザーから学ぶべきではありません。ユーザーからの書き込みに時間がかかるため、テクニカルサポートから問題について通知されたため、問題が大きすぎます。 この間、多数のユーザーが競合他社にアクセスします。 市場は、ほとんどのサービスプロバイダー（インターネットサービスプロバイダーとデータセンターサービスプロバイダーの両方）がビジネスの価値に比例して責任を負わないように設計されているため、稼働時間とサイトがダウンしている時間に対する責任があります。サービスプロバイダではなく、完全にあなたにあります。



ご存知のように、サイトが機能しない場合、ユーザーは「一時的に機能しない」、「完全に閉鎖」、「何かが起こった」などの議論を始めます。 この議論はあなたの評判を傷つけます。 さらに、事故によって直接影響を受けなかったユーザー、つまり 彼らは、それが機能していなかったときにサイトに入らず、これらの議論に参加し、まるで関与しているかのようになりました。 彼らは何かが彼らにも起こったと信じており、これは私たちが監視する必要がある別の問題であり、私たちのサイトがダウンしたときを知る必要があります。







すべてのサイトが更新され、新しい機能が絶えず改善され、新しい「機能」が起動され、サイトで新しい機能が実行されているため、複雑で長い開発プロセスが必要になります。 監視は、システムに問題があることを発見できるようにするものです。 監視によってのみ、どのチームの開発者または特定の開発者がサイトの安定性に問題を常に引き起こしているかを知ることができます。 監視によってのみ、ソフトウェアパッケージのどのモジュールに特に注意を払う必要があるかを知ることができます。



次の問題は、インターネットが大きく、サイトを完全に操作できること、完全に開くことができること、すべての機能があなたのために機能することです。しかし、あなたはそれだけで働く人です。 したがって、監視は、技術的なインフラストラクチャだけでなく、外部からも問題を確認できるようにする必要があります。 Mail.Ruといえば、世界中の約100ポイントから監視されているため、私たちだけでなく、プロバイダーの問題、プロバイダーのプロバイダーの問題についても知ることができます。 正直なところ、エンドユーザーはMail.Ruが機能しない場所を気にしません。「プロバイダープロバイダー」というフレーズは何も伝えません。 彼は、Mail.Ruが機能しないことを理解しています。 したがって、ネットワークインフラストラクチャを監視し、監視サービスを提供するオペレータのネットワークインフラストラクチャを監視しています。



繰り返しますが、適切な監視は時間の節約になります。問題があることを警告するだけでなく、現時点では機能していないこともわかるため、理解とその後の解決のための時間を節約できます。



常に問題に注意する必要があります。 ロシアにのみ9つのタイムゾーンがあり、世界中には、たとえば昼間はありますが夜はある場所にユーザーを配置できます。



さて、最後の議論。 原則として、サイトの開発コストは非常に高くなります。 サイトの開発コストと比較して、監視を作成するコストは実質的に存在しません。 作成というのはカスタマイズを意味します。ダウンロードして無料で提供できるオープンアクセスソリューションがたくさんあるからです。



この部屋に自分のサイトを持ち、何らかの理由でまだ監視していないすべての人々がテクノロジーフォーラムから戻って自分で監視を設定する10の理由を次に示します。

Mail.Ruで監視するもの

実際、Mail.Ruには約140種類の監視がありますが、すべてをリストするわけではなく、合計でサーバー上の約150,000個のオブジェクトを監視します。 サービスを監視しています。 たとえば、これはHTTP経由のサービス応答である場合があります。 サービスの機能を監視し、手紙が届くかどうか、POP3を介してダウンロードされるかどうか、ユーザーが別のユーザーを友人として追加できるかどうかなどを常に確認します。 ネットワークの可用性を監視します。 私たちは世界中に見えるかどうかを確認します。 ほとんどのソフトウェアはディスクがいっぱいになると、このデータが単純に劣化し、バックアップからの復旧を余儀なくされるように書かれているため、データストレージの占有率を監視します。 また、サイトの速度も監視します。これは、30分でサイトを開くことが比較的重要でないしきい値が存在するためです。 ユーザーにとって、これはあなたのサイトが単に機能しないことを意味します。 すべての統計的排出量を監視します。 たとえば、1日に送信する手紙の数、1日に送信するメッセージの数、ソーシャルネットワーク上にある友情の数など、Mail.Ruで膨大な統計を収集します。 これらの定量的指標を観察しようとし、それらのいずれかが急速に成長または変化し始めた場合、または何らかの「外れ値」が表示された場合、モニタリングで強調表示し、これがなぜ起こったのか、何が起こったのかを分析できますこれを行うことができますなど。 そして、これらは利用可能な監視の種類のほんの一部です。





しかし、もう1つ重要なことが残っています。 監視していない場合、これは非常に悪いです。 しかし、監視を行っても機能しない場合は、ひどくなります。サイトが実際に機能しているという誤った印象を持っているからです。 したがって、Mail.Ruで最も重要で最初の監視は、監視が機能していることを監視することです。

予約とバランシング

そして、Mail.Ruがこれらの問題に取り組んでいるので、サイトが落ちないようにするためにまだ必要なことについて話しましょう。 もちろん、冗長性とバランシングから始めます。



サービスに適用するユニバーサルテーブルがあります。 それは非常に一般的ですが、少なくとも私たちのサービスのいずれかで試してみると、それがどれだけ安全か、私たちが受け取りたいものとどれだけ一致するかを理解できます。



リポジトリではないデータ処理サーバーでは、N + 1の冗長性で十分です。 この例のN + 1は、100台のサーバーに1台のスペアがあることを意味しません。これは、Nを決定することを意味します。たとえば、フロントエンドの場合、10台のWebサーバーごとに1台の予備サーバーがあります。 重要なことは、この場合、私たちは常に、もしあれば、戦闘に参加できるいくつかのサーバーを持っているということです。 データウェアハウスの場合、ハードドライブは信頼できないため、常に2つのオンラインコピーがあります。 また、あるストレージから別のストレージにいつでも切り替えることができます。 さらに、忘れられがちですが、常にデータのオフラインコピーがあります。 全体的な問題は、ハードウェアだけでなくソフトウェアにも障害があることです。この場合、不良データのある2つのアレイは必要ありません。必要に応じてロールバックできるオフラインコピーが必要です。



Mail.Ruのネットワークインフラストラクチャで受け入れられる在庫は35％です。 これは、いくつかのイベントに関連する「ピーク」を生き残るのに十分です。 これは、競合他社が働かないときに経験する出席者の流入を乗り切るのに十分です。 一般に、平均的なサイトのネットワークインフラストラクチャの35％は、発生する可能性のあるすべての災害に耐えるのに十分です。



また、予約について話すたびに、予約について話すたびに、倉庫、オフィス、またはその他の場所にあるサーバーを意味するわけではないことにも言及したいと思います。 事故が発生した瞬間には、予備を戦闘に投入するのにある程度の時間が必要だからです。 したがって、所有している予備全体が自動的に戦闘に参加する必要があります。 そして、理想的なケースでは、私たちと同様に、常に機能するはずです。 つまり 理想的な予備は、運用サーバーの冗長性です。 冗長サーバーは、通常の方法で負荷の同じ部分を処理する必要があります。これにより、サーバーのソフトウェアのコピーが常に最新になり、構成ファイルが常に最新になるようになります。



したがって、フォールトトレラントなバランスシステムの作成にどのようにアプローチするかについて、ほんの一言だけです。 HTTPサービスの例を使用してこれを説明します。 実際、ほとんどすべてのサービスでこの概念を使用できます。 このようなバランサーを作成するには、 RIPプロトコルをサポートする最もシンプルなルーターが必要です。このルーターとの通信手段が必要です。オープンソースのQuaggaソリューションを提供していますが、他のものも使用できます。







IPVSトラフィックのバランサーとカプセル化が本当に必要です。非常に有名で、膨大な数のシステム管理者がそれらを操作できます。 そして最後に必要なものは、 keepalivedサーバーの稼働状態をチェックするためのユーティリティです。 ニーズに合わせて完全にカスタマイズできるという点で優れています。 では、これは1つのデータセンターの例でどのように機能しますか？ 将来的には、複数のデータセンターの場合にこれがどのように機能するかも示します。







ここに、サーバーのグループがあります。 これらがフロントエンドだとしましょう。 HTTPを介してユーザーリクエストに応答します。 私が説明したのと同じKeepalivedがあります。これはポーリングを行い、動作する場合、IPVSでこれらの実サーバーのテーブルを更新します。 IPVSで実際に動作しているサーバーの数が、サービスに十分であると判断したしきい値よりも大きい場合、IPVSはバランサー上のサービスの仮想IPアドレスを上げます。 Mail.Ruの場合、これらは4つのIPアドレス、4つの異なるバランサーグループであることがわかります。 ルーターと通信する同じデーモンは、Mail.Ruへのルートがこの同じバランサーを通過することを通知し始めます。 さらに、ユーザーリクエストが到着すると、ルーターはルーティングテーブルを使用してバランサーに接続し、バランサーはこのトラフィックをIP-in-IPにカプセル化し（これによりパケットあたり20バイトしか追加されません）、それを実サーバーに送信します。 そして、実サーバーは、ルーター、ルーターにカプセル化せずに、直接ユーザーに送信します。



このスキームにより、毎秒約600,000パケットを処理できます。これは、人気のあるベンダーの鉄にとっても悪くありません。







ベンダーから購入したハードウェアと比較した場合、このソリューションの利点は、ユーザーが完全に制御できることです。現時点で何が起こっているかを完全に理解し、必要に応じてすべてを追加、終了、改造できます。 複数のサーバーが機能しない場合、keepalivedはすぐにそれを認識し、バランサーの実サーバーのテーブルでこれらのサーバーをオフにします。 私たちの農場が故障した場合、すなわち 現在動作しているライブサーバーの数は、設定したしきい値よりも少ないことが判明しました。同じkeepalivedが通知し、これをIPVSに報告し、バランサーから仮想IPアドレスを削除します。 その結果、ルーターとの通信を担当するデーモンは、このバランサーへのルートを強制終了し、ユーザーパッケージは、サーバーファームとバランサーが稼働している別のデータセンターに移動します。



いくつかのデータセンターの例では、これはもう少し複雑に聞こえますが、意味はほぼ同じです。 ユーザーのリクエストが届きます。 RIPメトリックが同じである場合、それらはバランサー間で均等に分散され、次に実サーバーに到達してからルーターに戻り、ユーザーに戻ります。 何らかの事故が発生した場合、監視はこれを確認し、キープアライブし、このルーターのルートを強制終了します。すべてのユーザーリクエストは、隣接するデータセンターのルーターに送信され、それに応じて隣接するデータセンターのバランサーに送信されます。







ご存知のように、広告はメリットのみを説明しているものであり、私のプレゼンテーションも例外ではありません。 これが実際に機能するためには、4つのことを行う必要があります。 QuaggaのRIP更新タイマーを修正する必要があります。ルーティングテーブルが更新されるまでユーザーが待たないように、1秒に減らす必要があります。





次に、システム管理者が設定できるRIPメトリックがポイズンリバースパッケージに入らないように、Quaggaを再度修正する必要があります。 システムに複数のバランサーがあり、そのうちの1つでいくつかの作業を実行する必要がある場合に、メトリックを管理上設定することができます。 前にも言ったように、IPVSはIPヘッダーの各パケットに20バイトを追加することでパケットをカプセル化します。 Keepalivedにパッチを適用して、ユーザーリクエストに最も類似したものだけでなく、1500バイトのサイズが必要なため、MTUをクロールしないネットワーク上のどこかにパケットがある場合、すぐに発見されました。





最後に、私が約束したパフォーマンス、つまり1秒あたり600,000パケットを達成するには、サーバーのirqbalanceをオフにし、コア全体にプロセスを手動で分散させる必要があります。 実際には、ネットワークカードのkeepalivedプロセスと割り込みキューを分散させる必要があります。 ネットワークカードがMSI-Xをサポートし、複数のキューがある場合は素晴らしいでしょう。 これが、Mail.Ruのバランスです。







それでは、他のことについて少し話しましょう。 プロジェクトを安定し、信頼でき、常に機能させるため。 モジュール化する必要があります。 これにより、全体ではなく部分的に分解できます。 あなたは、あなたのサイトが何であるにせよ、あなたのユーザーはその上でいくつかの機能だけで作業することを完全に理解しています。 サイトの一部は人気があり、一部は人気がありません。 したがって、ソフトウェア製品がモジュール式の場合、完全に故障することはありません。 あなたはいくつかの部分で壊れます、そしてこれはあなたの好きなユーザーの少数に影響を与えます。 2番目は、「否定的な」回答をキャッシュすることです。 何らかの理由でシステムの一部が応答を停止した場合、そこからユーザーからすべてのリクエストを送信し続ける必要はありません。 事故の発生後、負荷に応じて、10、20、1,000パケットごとに到着するようにシステムを設計する必要があります。 したがって、サービスが正しく応答し始めるとすぐに、自動的にロックが解除され、作業が復元されます。



実装する人が少ないという非常に良いアイデアは、モジュールを非同期的に操作することです。 これは、クライアント側（AJAXを使用）とサーバー側の両方で実行できます。これにより、負荷に問題がある場合、ブレーキモジュールが他のすべての必要なデータを収集するのを待つことができます。 システムに複数のサーバーが表示されたらすぐに、タイプ別に負荷を分割することをお勧めします。 つまり、データベース、フロントエンド、メールサービスなどに指定されたサーバーを使用することです。 これにより、完全に壊れるわけではありません。

リリース管理とテスト

リリース管理とテストについて少し話しましょう。 特にこのトピックに関して会議全体を手配できるため、リリース管理全体を時間内にカバーすることはできません。 しかし、それにもかかわらず、Mail.Ruにとって最も重要で最も重要と思われるトピックがいくつかあります。



まず、プロジェクトの安定性に関する問題の半分は、新しいコードのリリースに関連しています。 そしてこれは、プロジェクトにリリース管理が必要であることを示しています。 リリース管理によって、あなた、あなたのマネージャー、プロジェクトを開発しているチームが理解すべきこと、「今日リリースするもの」、「このリリースに含まれるもの」、「責任者」、「どのような負荷」を理解しますこのリリースは私たちの生産に追加されますか？」 リリースプロセスは可能な限り自動化する必要があります。なぜなら、Mail.Ruには、「プロセスをより自動化すればするほど、生産でのサプライズが少なくなる」という簡単な言葉さえあります。 本番サーバーで何かを開始する瞬間から始めて、何かをコピーし始め、いくつかの構成ファイルを手動で修正します。間違える瞬間まで、少し時間がかかります。 自動リリースプロセスがある場合は、まず、テストしたとおりに本番環境に展開することが保証されます。 第二に、これにより、本番ライブラリなどに配信されなかった構成ファイルのエラーの数が最小限に抑えられます。 つまり、リリースを自動化するコストは小さく、その恩恵は非常に大きいと思います。



もちろん、すべての人が間違っているので、サービスにどのような負荷がかかり、この機能または新しい機能が起動するかを常に予測することはできません。 Mail.Ruでは、このために分割テストを使用しています。 分割テストは、一部のユーザーに対してのみ新機能を起動する場合です。 第一に、最新の、最も興味深い、最も興味深いバグをすべて見るお気に入りのグループが表示されるため、ユーザー自身が非常に気に入っています。 第二に、これにより、このグループで、ロードと間違われていないか、システム全体で実行したときにクラッシュするようなことをしたかどうかを確認できます。



そして、最後に少しお話ししたいことは、すべてをリリースする必要があるたびです。 チームに複数の開発者がいて、そのうちの1人が迅速にタスクを実行し、そのうちの1人が長時間タスクを実行したとします。 そのため、ある開発者によって作成された製品がリリースの準備ができていない場合でも、何がリリースされているかを確認してください。 誰もこれらのモジュールを呼び出していない場合でも、誰もそれらを必要としていない場合でも、リリース当日にリリースします。 これにより、巨大なコードがリリースされたときのシステム管理者のブラックデイを回避できます。何かが壊れた場合、それを把握することはすでに不可能です。 そのため、毎回製品を少しずつリリースし、このプロセスを永続的にすることで、大きなメガリリースが1つも存在しないことを確認できます。その後、すべてをロールバックするにはさらに5日かかります。







もちろん、すべてを解放するだけでなく、負荷を予測することも重要です。 負荷のグラフが必要です。 仕事の速さを知る必要があります。 開発チームには、これらのグラフを見て毎回警告する責任がある人が必要です。「みんな、私たちは重要な価値に近づいているようです」。 問題についていつ叫ぶべきかを知る必要があるため、サービスのすべての応答時間にしきい値を設定する必要があります。



特定のプロジェクトがあります。 たとえば、仮想はがきサービスなど。 祝日、たとえば元旦、バレンタインの日に、そのようなサービスの負荷は20倍になります。 したがって、これを覚えていれば、このような負荷の増加に対応できます。



多くの場合、チームはプログラマーが新しい機能を開発するような方法で形成され、管理者はサイトの安定性に責任を負います-これは貧弱な組織であり、単一のチームでなければならず、人々は彼らが立ち上げているものとそれが生産にどのように影響するかを理解しなければなりません。 他の人々がサイトの安定性に責任を負っている間、一部の人々がプログラムして起動することを知っている状況はないはずです。 Mail.Ruでは、このリリースで発生する推定負荷メトリックを取得しようとしていますが、この機能には多数の追加サーバーが必要になると予測しようとしています。 また、これを行うことをお勧めします。 どこかで、おそらく

60日

負荷を推測することを学びます。 これにより、負荷を予測し、必要な容量をタイムリーに増やすことができます。

クラッシュ

それでは、事故の計画について話しましょう。 私は破壊活動を意味するのではなく、すべてが最終的に壊れたときに私たちが何をするかを意味します。 そして、私たちが覚えているように、これは避けられません。 それで、前に時間をかけてください。 事故がどのように発生したか、サイトの安定性の回復に費やす時間を何時間も節約できます。 チームのメンバーは誰でも知っておくべきです-何かが壊れている場合、その機能は何か、それは何をするのか、どのようにリザーブに入るか、バックアップはどのように展開されるか バックアップバックアップは完全に自動化する必要があります。 自動化とはどういう意味ですか？ 残念ながら、機器が故障した場合、常に事前に警告されるとは限りません。 これは夜に起こることもあれば、休暇中の人もいます。 したがって、システム管理者が遠く離れていて、データがすでに破損している状況にならないように、要求に応じてバックアップが自動的にロールアウトされるようにしてください。 サイトのスタブとライトバージョンを提供します。 故障が避けられない場合は、ユーザーの気分を少し悪くさせましょう。 最愛の「内部サーバーエラー500」ではなく、何らかの修復作業を行っているという通常のメッセージを彼に見せましょう。



率直に言って、私のプレゼンテーションの次のトピックについては、これら2人の同志よりも良いとは言えません。彼らの話を聞いてみましょう。自分に。 しかし、私はできる。」

誰も信じられない

だから、彼らの安定性に責任があるサイトの開発に関与しているすべての人々は、あなたが誰も信用できないので、ある意味で反知能です。 もちろん、このプレゼンテーションの枠組みの中で、できます。 前のスライドで説明した「失敗からの回復」という計画を定期的に確認してください。 最新のWebサイトの開発は、多くの場合、多くの変更を伴う確率的で非常に高速なものです。 そして、6か月後、すべてを迅速に修正する方法に関する優れた計画は、せいぜい完全に機能しなくなり、最悪の場合はさらに多くの損害をもたらします。 したがって、常に個人的に確認する必要があります。 テスト目的でバックアップサーバーを実行する必要があります。テスト目的でバックアップを使用し、その後に何が起こるかを確認する必要があります。







別のトピックはバックアップです。 繰り返しになりますが、バックアップが必要であると主張する人はいませんが、何らかの理由で、何かが発生した場合、それらは決して存在しません。 このオーディエンスにバックアップを作成する責任がある人がいる場合、バックアップが保存されているサーバーにアクセスできるこのオーディエンスの人がいる場合-会議後、参加して、そこにいるかどうかを確認しますか？ 定期的に何かが壊れたり、何かが変わったり、何かが起こったりするため、最悪の場合、単にバックアップがないことがわかります。 私たちのプロジェクトが非常に大きくなり、バックアップから復旧するのに数ヶ月かかることがわかった場合があります。 そして、私もこれを見ました。 , , , .



, , , « ». 10% . - - , - - , - . , , — , .



, , , , , , , , . — , -, .



, , , BGP-, . , Mail.Ru . , , , , , . , . , , , , .

ご質問

— , , . , , . , ?

- 15, .

. , . : ?

, . , , . , , .. , .

, , . : , — - ?

— . , , . , , . - — , , .



. ? - , - ?



. - . , . . , , , , , — « , , », . — , .

, « ». , , , , - . -. , -?

- . , , «».

. . — , — . , — - . ? ..

わかった。 , . , , , — «, - , ?». . , , - , , .

— — «, »? ?

. — « — ». , . , , — . : - , , — «, , », , . . « , », « », « , ?» ..

, . , -. つまり . ? - ? ?

, . , , , , , . , - — . , — - . , , , . — , . , , , , .

, — ? ...

, . . , , , , .

. Java , ? ? . : , 500- . , -. , , — , « »?

. ? , , , , — , - - . , — . Java- — , , , , . , — . , mail.ru, Java- , , , .

. . opensource . , opensource , .

. 13 - — . , , , . mail.ru , , . .

, . . , - , - , ?

. DoS- - , . , , . , , , 10 . , , , , DoS. , - — , , , , , , - , .

. — - DoS-?

いや

, ?

— .

: Mail.Ru Group ?

, . - -. - .

. , , , , ? , : , 1- , , .

, Mail.Ru. , , 24 . Mail.Ru . .. , - - , . , , - , , 12 - , - . , .. c .

---

このテキストは、11月16日にInfospace Centerで開催されたMail.Ru Technology Forum 2011でのVladimir Gabrielyanのレポートの転写です。ビデオレポートテキストを作成するための技術の詳細については、こちらをご覧ください：Mail.Ruテクノロジーフォーラムの裏側：ハイテクイベント管理。他のレポートのビデオバージョン（モバイルデバイス用のバージョンを含む）は、フォーラムWebサイトtechforum.mail.ruで入手できます。レポートのテキスト版は、ここおよびフォーラムのWebサイトで毎週またはほとんど同じ頻度で発行されます。テキストのタイプミスについてPMでお知らせください。