🕕 📡 👨🏿‍🌾 M. Videoからの贈り物：内部には何がありますか？ 🌐 🤲🏼 🍑

導入する代わりに

この話は2007年12月に始まりました。私はモスクワ州立工科大学の大学院生でした。 N.E. バウマンは、小さな会社に就職しました。そこで、彼らは私が当時理解していなかった名前でプロジェクトを立ち上げました-「M.Videoギフトカードの処理」。最初の営業日の簡単なトレーニングで説明したように、処理とはギフトカードのデータを保存し、それらを使ってさまざまな操作を実行できるシステムです。彼らはまた、開発はほとんどなかったと言ったが、そのようなシステムを作成することは完全に簡単だ。この点で、製品の出力は数ヶ月で以前に計画されました。「なるほど」と答え、私はまだ出ていない創造プロセスに真っ向から飛び込みました。

この記事では、将来の製品のテクノロジーとアーキテクチャに関して適切な決定を下すことがいかに重要であるかについて説明します。それらを取る方法について。そして、決定が間違っているときに何が起こるかについて。 2007年12月に現在の経験があれば、M。Videoのギフトカードの処理はスムーズに、そして十分に発展していたでしょう。朝食、昼食、夕食をモニターの前で休むことなく、多くの眠れない夜や時間の問題はありません。しかし、同時に、製品に取り組んでいるとき、それほど激しいドライブはありません。

処理とは

では、処理システムとは何ですか？このシステムを作成するための厄介で長い道のりの話を始める前に、用語を決めておくといいでしょう。

処理システム（処理）-支払い取引の作成に使用される情報を処理するように設計されています。

2つのタイプの処理を区別するのが一般的です：銀行（銀行カードでの作業：Visa、MasterCardなど）と非銀行（銀行以外のカードでの作業：ギフトカード、割引カード、プロモーションコードなど）。

おそらく既にご想像のとおり、この記事では非銀行取引処理に焦点を当てます。

すべてがどのように始まったか、または将来の製品にどのようにテクノロジーが選ばれたか。私の意見では、最初からすべての製品を作成する上で最も興味深い時期が私の意見だからです。まあ、またはほぼゼロから。製品作成の初期段階では、製品の将来が直接依存する正確性に基づいて、重要な（運命的とも言える）決定が行われます。プラットフォームの選択に誤りがありますか？この製品はトラフィックの増加にdrれるか、維持するのに費用がかかるため、会社に損失をもたらすことはありません。テクノロジーの選択に誤りがありますか？数年後、選択したテクノロジーを使用して作業できる専門家を見つけることができません（または、お金が足りないために見つけることができません）。作成と保守のコスト（この問題に何度も戻ります）は、多くのITソリューションの基礎であり、最初に適切な決定を下せば数桁安くなります。

そこで、タスクが設定されました。M。Video社の処理システムを開発するために、最初から2か月で2人で構成されるチームです。当然、システムはその時点で存在していたレガシー制限の手荷物を考慮しなければなりませんでした（カードの磁気トラックのデータ形式、レジシステムの機能など）。使用される技術の観点から-創造性の完全な自由。「すべてが急流にあります」-このようなスローガンの下、私たちは製品を何に重ねるべきかを考え始めました。処理システムを使用するときに、主な問題がどのように発生するかは知りませんでした。また、インターネット上でこれに関する有用な情報を見つけることはできませんでした-方向はかなり狭く専門化されており、私たちがよく知っているように、原則として、彼らはインターネット上のトレンドのことについて書きます（再び、市場の法則）。そのため、テクノロジーを選択する際、特定のテクノロジーを習得する際に、他のシステム、技術ロジック、およびありふれたスキルを開発する以前の経験に頼らなければなりませんでした（新しいテクノロジーを真剣に研究する時間はまったくなかったと思います）。今後の展望として、テクノロジーの選択を間違えなかったと言います（当然、天才だとは思いませんが、多くの点で幸運でした）。私は他の何か-ソフトウェアソリューションのアーキテクチャに間違えられました。しかし、まず最初に。

鉄とハードウェアのアーキテクチャ

鉄から始めましょう。システムを設計するとき、機器は多くの場合、選択したソフトウェアプラットフォーム（たとえば、OracleまたはIBM、プラットフォームの仕様は最小ハードウェア要件を示します）、またはタスクの複雑さ（たとえば、指定されたパフォーマンス特性を使用した4Kビデオストリーミングの処理）に基づいて選択されます私たちの場合、どちらもどちらでもありません。選択基準は、システムの信頼性と、いくら些細なことでも予算です。「一般的に」という言葉から、「ホット」モジュールや同様のチップを交換する機能を備えたIBMのクラスターシステムは、私たちに余裕がないことがすぐに明らかになりました。そのため、システムの予約は個別に実装する必要があるという警告とともに、低価格セグメントに注意が移りました。その結果、安価なHPサーバーを選択しました。しかし、最初に構築されたバックアップメカニズムは、顧客から多くの質問を引き起こしました。しかし、システムの運用の最初の年に、それらは完全に削除されました。そのメカニズムは次のとおりでした（図1）。

図 1。

はい、それは非常に原始的です。 2つのミラー化されたフロントエンドサーバーと1つのデータベースサーバー。しかし、なぜそうなのか、このスキームの使用法は何ですか？だから誰も長い間やっていない、システムを構築するための現代のテクノロジーを24時間365日理解している読者は言うだろう、そして彼は正しいだろう...しかし、一部だけ。正しくしましょう。前述のように、非常にクールなクラスターシステムを提供するオプションは、コストが高いため考慮されませんでした。

ストーリーのこの場所では、このトピックに小さなオフトピックを挿入せざるを得ません。私は、大規模な銀行でのそのようなシステムの少なくとも2つの失敗を知っています（名前、明らかな理由で、私は与えません）。そして、それは限られた予算の問題ではありませんでした（銀行がシステムの耐障害性を確保するために数百万ドルを費やしました）が、その現実は冷酷なものでした。

最初のケースでは、酔った掘削機がメインとバックアップの両方の通信チャネルの光ファイバーを引き裂きました。これは、銀行のデータセンターのアーキテクトが建物からの通信回線の撤収を完全に正しく編成し、異なる方向に分岐するという事実にもかかわらず発生しました。バケツを1ストロークで両方のラインを切断する方法を教えてください。はい、非常に簡単です。通りの反対側で、これらの線は1つの井戸に収束しました。データセンターの設計者はこれに影響を与えることはできませんでした。彼らもそれを知りませんでした。

2番目のケースはそれほど壮大ではありませんが、興味深いものです。銀行には、従来のアクティブ/スタンバイクラスタがありました。機器の些細な障害（最も安価なクラスターであっても、絶対に重大ではない状況）によるメインノードの障害の後、バックアップノードは単純に上昇しませんでした。状況を調査した結果、その理由が明らかになりました。バックアップノードがマウントされたラックには、物理的に十分な機器がなく、ディスクドライブのセットが不完全でした。次に、不足しているディスクドライブが、他の銀行システムの操作性をサポートする運用上の交換基金として使用されていることがわかりました。そして再び疑問が生じます-さて、どのように？銀行の最も重要なITシステムの1つが動作するクラスターのバックアップノードがこのラックにマウントされていることを人々は知りませんでしたか？彼らは知っていました。しかし、幸福な（またはどちら側を見るかによっては不幸な）状況の組み合わせのため、事件の前にクラスターのバックアップノードを起動する必要があるとは考えていませんでした。長年の従業員は、これがスタンドオフを見ていた。おそらく、ラック内の機器の目的を知っていた人でさえも辞めたのでしょう。そして、これは説明された状況では非常に自然です（インフラの専門家は理解します）、生産設備の「燃焼」問題を解決するためにラックは「ナイフの下」に行きました。

これをそれほど小さくはないが、さらなるストーリーのために非常に必要な余談を要約すると、2つの基本的な結論を導きたいと思います。私の意見では、あらゆるレベルのITシステムを構築する際に考慮する必要があります：

絶対に信頼できるシステムは存在しません（角質ですが、何らかの理由で、これはしばしば忘れられます）。
実際の（紙ではない）システムの信頼性は、そのコストにわずかに依存します（これはより頻繁に忘れられます）。

ギフトカードM.Videoの処理に戻りましょう。 M.Videoデータセンターには、異なるプロバイダーからの2つのインターネットチャネルがあります。もちろん、建物からワイヤがどのように出てきたかは知りませんでしたが、2つのチャネルは最初は悪くありません。彼らは、2つのミラーセグメントのシステムを構築しようとしました。これらのセグメントは、異なる通信チャネルに「座って」、どういうわけか互いに予約することになっています。しかし、処理データベースを2つのミラーセグメントに分割し、それらの間で高性能（さらには非常に）のオンラインレプリケーションを確保する必要があるため、このアイデアを完全に実現することはできませんでした。今後、DBMSとしてMicrosoft SQL Server 2000を選択したと言います。このDBMSのレプリケーションメカニズムを検討した結果、必要なパフォーマンスを提供できないという結論に達しました。さらに、レプリケーションの編成には非常に高いオーバーヘッドが必要になります。そのため、彼らはデータベースを一元化することに決めました。しかし、フロントエンドサーバーには、すぐに複製する必要のあるデータが含まれていなかったため、簡単に「バラバラ」になりました。システムのクライアントモジュールにフロントエンド処理サーバー間でクライアントを切り替えるロジックを実装しましたが、これについては後で詳しく説明します。

それでは、信頼性について話しましょう。異なるプロバイダーからの2つの通信チャネルがあるため、フロントエンドの信頼性は非常に高いことが判明しました。酔っ払った掘削機（上記参照）またはデータセンターでのラックの爆発だけが、それを敷設できました。懸念は、集中型データベースサーバーによって引き起こされました。この点で、私たちが見つけた実際のシステムの動作の結果によって収集されたすべての統計データを調査しました。製品で発生する3つの最も一般的な問題を書き留めました。

通信チャネルの障害/過負荷。
ピーク時（休日、金曜日の夜など）のシステムパフォーマンスが不十分です。
エラー/ソフトウェアがクラッシュします。

機器の故障も一般リストにありましたが、TOP-3には入りませんでした。 3つの問題はすべて、ミラー化されたフロントエンドサーバーを使用するスキームを使用することでほぼ完全に解決されるので、チャンスをとることに決めました-データベースサーバーを集中化したままにします（負荷のバースト時に十分なパフォーマンスが得られるように、予算の範囲内で強力でなければならないという注意を払ってください）。ベットは正しかった。処理は、2008年3月から2014年5月まで、このハードウェアプラットフォームで機能しました。この間、上記のすべてのポイントに関連するインシデントが発生しました。しかし、機器の故障は決して起こりませんでした。誰かがそれはただ幸運だと言うでしょう。私は議論しませんが、それでもです。

最後に、説明したスキームの中で私が最も好きではなかったことをお伝えしたいと思います。 Prosharennyeシステム管理者は、スキームの各ブランチで個別のIPアドレスを持つ個別のルーターを使用していると繰り返し非難しています。同様に、これはクライアントにとって友好的ではありません-彼が2つの異なるアドレス間で切り替えられるようにするために（その時点で、クライアントモジュールは処理を行うクライアントソフトウェアではなく切り替えを担当していました）。フロントエンドサーバー間でトラフィックを自動的に分配するバランサーをインストールするか、クライアントが単一のIPアドレスを持つようにHSRPプロトコルを介して通信する2つのルーターのスキームを組み立てることが提案されました。これは私の意見です。バランサーは通常、炉内にあります。分散システムで集中リンクを作成することは最大の悪です。これは明らかです。 HSRPは分散リンク（2つのルーター）を作成しますが、コンポーネントは相互に大きく依存しています（ルーターは常に相互に通信し、プロトコルで定義されたコラボレーションのプロトコルを実装します）。このようなリンクは、実際に独立した要素（相互作用しない2つのルーター）で構成されるリンクよりも信頼性が高くなりません（少なくとも悪化しません）。数学的に証明することもできます。ここで説明する方式は、運用中にその信頼性を何度も証明しており、この点でギフトカードの処理よりも数桁高い多くのシステムを上回っています。

Webサービスプラットフォーム

先ほど述べたように、DBMSとして、複数のデータベース間のデータ複製など、ローションのないMicrosoft SQL Server 2000を選択しました。私はこのDBMSに精通しており、銀行システムなど、負荷の高い企業システムでSQL Serverを使用する実際の例を数多く知っていました。良い議論だと思う。同じ理由で、同じMicrosoftのIISサーバーに基づいてWebサービスを編成することにしました。まだ珍しいことはありませんか？さらに興味深いのは別です。処理サービスのロジックを実装するスクリプトを記述するためのテクノロジとして、ASP.NETを採用しませんでした。ASP.NETはすでに人気を博し始めたため、ASPクラシックは誰もが忘れていました。当時の別の議論の余地のある決定は、システムの将来の成功を大きく事前に決定しました。インターネット上のASP.NETとASPクラシックのあらゆる種類の比較レビューを読んだ場合、ASP.NETを支持する主な議論は次のようになります。

より高度な技術。
より多くの機能を提供します。
より合理化されたWebアプリケーション構造。
素晴らしいパフォーマンス。

かっこいいですね。真実は。誰もが好きで、誰もが買う。マイクロソフトの販売者とマーケティング担当者はボーナスを受け取ります。すべてが順調です。それでは、ポイントに行きましょう。

パラグラフ1では、すべてが明確であり、新しいものは常に良いです。新しいジャケット、車、女の子、...、Javaのバージョン。それは常にポジティブな感情を引き起こします。これが私たちの精神の働きです。あなたがそれについてできることは何もありません...そしてあなたはしません。将来の製品にテクノロジーを選択する際に、これを「利点」と考える必要はありません。これは、技術的な特性ではなく、ファッションのトレンドに基づいて車を選択する方法です。多くの人がそうしていることは理解していますが、開発者は常に冷静な心を保ち、あらゆる問題に合理的に取り組むべきだと思います。残念ながら（私の場合は、誰かがこれを気に入っているかもしれませんが）、今では、テクノロジーを選択するためのこのような「ファッショナブルな」アプローチをよく見かけます。そして、結果は何ですか？しかし、最終的には、最新の技術は通常より高価であり、特定のプロジェクトで使用した場合の利点が顧客や請負業者によって常に明確に理解されるわけではないため、高価で愚かなことがわかります。そして、ご存知のように、新しいものは忘れられた古いものです。しかし、これは別の大きな話です。悲しいことについては話しましょう。

ポイント2-機会。機会は常に良いものです。しかし、たとえば、米国メリーランド州ボルチモアでオンラインで天気を追跡する必要がありますか？あなただけが近い将来にそこに行くか、あなたの親relativeがそこに住んでいるとは考えにくい。しかし、この機会を必要としている友人は何人いますか？この最も簡単な例では、明らかなことを示したいと思います。誰かがあなたに新しい機会を与えたとき、あなたはあなたの問題を解決することの利点を明確に理解する必要があります。 ASP ClassicにはないASP.NETの機能を検討した結果、ASP.NETにはタスクにASP Classicを超える利点はないと判断しました。

ポイント2-Webアプリケーションの構造。むかしむかし、PHPの出現の夜明けに、この言語に関する非常に良い本が友人の誕生日に紹介され、すべてのWebアプリケーションがサーバーサイドスクリプトと組み込みを使用して開発されたという声明を読みました静的HTMLに直接、深刻な欠陥が内在します。たとえば、C ++で記述されたデスクトップアプリケーションと比較して、コードの構造的構造が悪化します。そして、私はそれに完全に同意します。 C ++が開発者に特定の構造（ヘッダーファイル、プリプロセッサディレクティブ、最終的にMain（）関数）に従うように促す場合、PHP、ASPクラシック、および同様の言語はいかなる種類のコード設計も促しません。必要に応じて、好きなだけランダムまたは構造的に記述できます（ただし、構造は独立して制御する必要があります）。このトピックは完全にプログラマーに委ねられています。その素晴らしい本のリリース以来、たくさんの水が流れました。技術は進歩しており、ASP.NETは、開発者が構造化コードを使用してアプリケーションを構築するのを支援する点で、ASP Classicよりも優れています。

しかし、ラムに戻りましょう。システムの開発者は2人しかいませんでした（さらに、コードの90％はそのうちの1人、つまり私が作成しました）。必要に応じて、アプリケーションのソースコードの構造を確保できることは明らかでした。また、特定のタスクでは、これによりASP.NETがASP Classicよりも有利になります。さて、ケーキの上のチェリー-パフォーマンス。ツリーに考えを広めることはせず（そして時間がかかります）、すぐに言います-はい、一般的な場合のASP.NETアプリケーションのパフォーマンス（このようなステートメントでこれらの言葉が大好きです）は、基本的な理由でASPクラシックアプリケーションよりも高い-コンパイル済み（プリコンパイル済み）正確に言うと、コードは解釈されたコードよりも高速です。

しかし、いつものように、微妙な違いがあります。

フレームワークとバイトコードのメモリへの読み込みが失われたために.NETアプリケーションが最初に起動されたとき（サーバーの再起動後など）、システムは「巡航」速度よりも低い速度でしばらく動作します。 ASP Classicアプリケーションは、バイトコードが不足しているため、この欠点から解放され、インタープリターが実行されるたびに、インタープリターは同じ方法でスクリプトを処理します（もちろん、スクリプトキャッシュが構成されていない限り）。もちろん、問題は小さいですが、それにもかかわらず、それは存在し、特にリクエストの強力な連続ストリームを処理するシステムで認識できます（そして、私たちの処理はまさにそれを行います）。これは、Classicアプリケーションの目標パフォーマンス値を数桁上回っただけでなく、ASP Classicを支持する選択を容易にし、ゆったりとしたものにしました。対立のトピックの最後で、ASP.NETとASP Classicは、.NETの対応物に対するASP Classicのいくつかの利点について説明します（はい、この方向にも利点があり、私の意見では非常に重要です）。

Webサーバーを再起動せずに、したがってサービスを中断することなく、Webアプリケーションを更新できます。この機能は、多くの場合、これに問題がある他の企業システムと比較して、システムをクールにしています。
システムを改良するために、標準のメモ帳以外のものは必要ありません（青いアイコンなど、誰もが知っていますが、誰も使いません）。オブジェクトの名前とポイントをキーボードで入力した後、ツールチップなしでコードを書くことができる有能な開発者は、携帯電話からでもアプリケーションを改良できます。携帯電話で.NETコードを記述できますか？同じ電話でプリコンパイルできますか？
アプリケーションの全体的な「明るさ」。ソースは何の重さもありません。それらは、ほとんどすべての、最も遅い通信チャネルを介してサーバーにアップロードできます。 2008年以降、M.Video処理システムの更新をダウンロードしなかったため、モバイル通信（2G / 3G以前）、Yota-Internet、急流オフィスチャネル、さらにはダイヤルアップ接続（幸運にもそのようなものでした）、一度だけ）。

Webサービスアーキテクチャ

ここでの「アーキテクチャ」は、その時点のシステムには原則としてアーキテクチャがなかったため、セクションのタイトルにのみ存在します。はい、はい、私たちのシステムは「Webアプリケーションのアーキテクチャを開発するときに行う必要のないこと」というトピックに関する「機能」の完全なリストを実装しています。 ASPスクリプトはHTMLコード全体に完全に制御不能に広がり、ファイルの名前が付けられたため、名前でスクリプトの意味を理解することは非常に困難な作業でした。その理由は、Webアプリケーションの開発における私の経験不足です。それにもかかわらず、この形式では、システムがアーキテクチャの「コーミング」を手に入れるまで、最初の1年間は正常に機能しました。

クライアントモジュール

今日、Webアプリケーションに基づいたシステム内のクライアントモジュールの存在は、戸惑うだけです。そして、これは理解できることです。なぜなら、現在では、原則として、Webサービスにアクセスできないソフトウェアはほとんど残っていないからです。しかし、2007年にはそのようなシステムが増え、その数にはM. Videoの興行収入が含まれていました。レジ係が処理システムとやり取りする唯一の方法は、ファイル共有でした。そして、システムだけでなく、銀行カードの処理についても話し合っています！暗号化されていないファイルを介して銀行情報を転送することを誰かに伝えた場合、これはニヤニヤするだけです。しかし、これはそれについてではありません。キャッシュデスクM.ビデオは、作成中のWebサービスに個別にアクセスできませんでした。彼女は要求ファイルを作成し、データ交換フォルダー内の応答ファイルを待つことしかできませんでした。本質的に、[ファイル] <---> [サービス]の形式のデータキャリアになるはずのクライアントモジュールの開発について疑問が生じました。繰り返しになりますが、古典的なタスクは、このかなり不器用なタスクを実行する軽量で非常に信頼性の高い（結局、小売店のチェックアウト！）クライアントモジュールを開発することです。

そして、ここでは、VBScriptでクライアントを作成するために、製品全体で最も興味深いソリューションを適用しました。標準のWindowsインタープリターで実行できるもの。きっと驚かれることでしょう。さらに言います。顧客側のプロジェクトチームでは、異なる反応をする人は一人もいませんでした。プロジェクトに取り組んでいるときにこのアイデアを聞いていないのはなぜですか：「これは深刻ではありません！」、「冗談でしょうか！」、「聞いたことがありますか、VBScriptで企業システムモジュールを書くつもりですか？」、「このソリューションは不可能です」と同様のステートメントをサポートします。その時、最も攻撃的で面白いフレーズを録音しましたが、残念ながら、このファイルを失いました。だからここに。最終的にこのアイデアは、製品全体で最も珍しいだけでなく、最も効果的なものでもあることが判明しました。そして、ここに理由があります。

このようなクライアントの最大の問題は、リモートの集中更新です。たとえば、一般的な状況であるキャッシュデスクから、データ交換ファイル形式が変更されました。したがって、すべてのキャッシュデスクですべての顧客を更新する必要があり、M.Videoは2008年に約1,000を持ちました。もちろん、すべての店舗にエンジニアを派遣することは、手作業による日没です。クライアントモジュールがWebサービスと通信し、それが古くなっていることを理解し、新しいバージョンをダウンロードして、それを自分自身で置き換えることができるメカニズムが必要です。最後のアクションは最も困難です。Windowsでは、実行中のプロセスはそのファイルを置き換えることができません。これは、アプリケーションの終了後にのみ実行できます。したがって、「更新プログラムをインストールし、コンピューターを再起動する必要があります」というメッセージの出力など、あらゆる種類の松葉杖を実装してから、次の起動前にクライアントファイルを更新するメカニズムを開始する必要があります。そして、これはすべて開発者にとって問題ではありません。これはユーザーにとって問題です。新年の前の土曜日の夕方、店が満員になり次の顧客にサービスを提供するときに、レジ画面で上記のメッセージを見た「幸せな」レジ係はいません。それを提供するとき、「幸せな」クライアントはありません。これは本当の問題です。そして、これまでのところ（そしてすでに2017年に庭で、紳士）、ほとんどのシステムはこのように設計されています。

しかし、私は高品質のソフトウェアを支持し、支持しているため、このシステムのこの問題は解決されました。非常に「気分を害する」VBScriptがこれを助けてくれました。つまり、その注目すべき特性の1つは、実行を停止せずにVBSファイルを上書きできることです。 Webサービスからの応答スクリプトが、更新が必要であることを理解し、それ自体の新しいバージョンをダウンロードし（VBSファイルは何の重さもありません）、ディスク上の独自のファイルを書き換え、自分自身の新しいバージョンを起動し、最後のコードを実行するメカニズムを実装しました、彼自身の古いバージョンを完成させました。ユーザーの観点からは、何も見えませんでした。そして、これが私たちのアイデアの最大の価値です。ユーザーは、更新が行われたことをまったく理解できませんでした。キューを提供するレジ係は、前バージョンのクライアントモジュールでトランザクションNを実行し、新しいバージョンでトランザクションN + 1-を実行しました。そして、遅延やその他の目に見える兆候のないこれらすべてが起こりました。更新は、新しいVBSスクリプトをサーバーにアップロードし、対応するデータベーステーブルの現在のバージョンを増やすことで集中管理されました。

生産性の最初のステップと最初の改善

正直に言うと、システムが2008年3月に実稼働で稼働した後、私には思えたように、私たちの小さなチームがdr死してしまったはずの大量のインシデントが発生することを予想していました（2人しかいなかったことを思い出してください）。しかし、それは起こりませんでした。いいえ、もちろん、事件はありましたが、壮大なものはありませんでした。すぐに、少なくともスクリプトの構造を合理化する必要があることが明らかになりました。システムのWebインターフェースを完成させる最初の要求が到着しました。伝統的に、顧客は製品の最初のバージョンを受け取って初めて、本当に必要なものを理解することができました。ここでは異常なものは何も作成されなかったため、詳細に進む理由はありません。私が注意したい主なこと：製品のシステムは、いくつかの決定の「革命」に関連するすべての恐怖にもかかわらず、すぐに非常にうまく機能しました。

システムの進化と休日の危険性

この章では、システムが2008年から現在までに移動したパスについて説明し、1つ（1つのみ、そうでなければ、本をリリースする必要があります）について説明しますが、2013年に発生した技術的な観点から非常に深刻で非常に興味深いです。

そのため、2008年3月には、約1,600万のM.Videoギフトカードが処理システムのデータベースに保存されました。システムパフォーマンスは、1秒あたり16トランザクションを目標として、1秒あたり30トランザクションに達しました。現在、データベースには約1億2,000万のエンティティ（カードだけでなく）があり、生産性は毎秒700トランザクションに達します。あなたが見るように、パスは長く、常に上り坂です。この経路の主な転換点は、タイムラインに反映しようとしました（図2）。

図 2。

開発はクールですが、原則として、意図したとおりに何かがうまくいかないとき、私たちが得る最も価値のある経験の大部分があります。そして、大規模な連邦企業の処理が機能しないほどすべてがうまくいかない場合、単位時間あたりに得られる経験の量に少なくとも10を掛けます。

2013年3月8日金曜日でした。週末のリラックスした朝はうまくいきませんでした。正午頃、私の携帯電話が鳴り、ITディレクターの緊張した声が「処理が機能しない」と言いました。もちろん、私はITディレクターが個人的に電話するのを少し心配していました（通常、彼らはそのような事件のテクニカルサポートから電話をかけてきました）が、それでも、最初はこの情報を真剣に受け止めませんでした。これは、システム運用の最初の数年間に、まったく同じ文言で技術サポートからうらやましいほどの規則性で私を呼び出したという事実によるものです。そして、99.9％のケースで判明しました：掃除婦がモップで現金デスクからイーサネットケーブルを引き出した、店内の通信チャネルが落ちた、処理エンドポイントのアドレスが最近開いた店で誤って登録されたなど。サーバーにリモート接続されたラップトップをゆっくりと引き出し、現在のトランザクションフローを監視し始め、処理が機能しているのを見ました！非常に強力なストリームで、トランザクションが進行中です。テクニカルサポートとの電話での会話にしばらく時間を費やした後、処理が単に負荷に対処できないことに気付きました。 ( ), ( , 2/3 ).

«» . — / . - , - — . , -, - , 1/3 — , , 80 . . «» , , , ( ), 15 . , , 14 , , . - . , .

, , . — 500 . . 2011-2013 . , , , , 1000 . , , . . . .

, , 24/7/365, , — , 25 31 . — . , — . . — . . , : , -. . , , 1,5 , ! , . , . ( 12 14 8 )? ? 23 ? ? ?

, ( ). , ( ) -, , . - . 8 2013 , . , , . . , . , . , 2013 . . , . , , , .

結論の代わりに

, . , , . , . , , , . , , . . , . , ( ) / . , . , - . , .

最後に、非常に有名な人物を1つ引用したいと思いますが、IT界にはいません。同じ伝説のリボルバーの発明者であるサミュエル・コルトは、「殺すのは武器ではなく、殺すのは男だ」という言葉に属します。ITに関する記事のこのような引用は誰かにとって奇妙に思えるかもしれませんが、ここでは非常に役立つと思います。IT業界の意思決定者が、武器を殺していると単純に信じていることがよくあります...

M. Videoからの贈り物：内部には何がありますか？