Banks.ru-10年の歴史を持つプロジェクト。 異なる時間に、 banki.ruは異なる負荷を経験しました。 論理的および技術的に新しい要件を満たすためにポータルが再構築され、緊急モードで何かを、進化的に何かを変更しました。 現在、平均トラフィックは約200万ページビューです。 プロジェクトはもはや小さくはありませんが、それほど大きくはありません。

この記事は、 Roman Ivliev （CIO Banki.ru）によるHighLoad ++ Juniorトレーニング会議でのレポートの転写です。この会議は、数か月前にロシアのインターネットテクノロジーフェスティバルの一環としてモスクワで開催されました。

この記事では、最適化、その適時性、および準最適化について説明します。これは、常に、ロードされたシステムを開発するベストプラクティスがビジネスに利益をもたらすものではありません。

例を見て、質問に対する答えを探しましょう。

1. あなたの高負荷はとても高負荷ですか？
2. ハブラー効果は、高度な技術を導入する理由と考えるべきですか？
3. 「松葉杖」または「ハイテクソリューション」-何を選ぶべきか？ 長所と短所。
4. 新しい時代を始める瞬間を選ぶには？ アプリケーションの最適化を開始し、「大人の方法で」クールなものを実装することが理にかなっている基準はありますか。
5. 「Buninリスト」を使用して非常に優れたパフォーマンスを達成するにはどうすればよいですか。本当にすべてのアイテムが必要ですか？
6. 技術的な負債を処理して、コケで繁茂しないようにする方法は？

結論として、Roman Ivlievは、高負荷の分野での技術的ソリューションの置き換えに関するbanki.ruの生涯のいくつかの例と、その結果について説明します。

すべての時間がある

ローマン・イヴリーエフ（Banks.ru）

私はここであなたの前に立っています。なぜなら、私はこのITのugさを15年間ずっとやってきたからです。かなり長い間、エンジニアから上司になりました。 彼は彼のサークルでよく知られているさまざまな会社で働いていました。

そして、これはBanks.ruについてです：

あなたが私たちについて聞いたことを願っています。 銀行サービスを使用する人は誰でも、おそらくBanks.ruが何であるかを知っているでしょう。

そのような数字がどこから来たのか、そして一般に、なぜここにいるのかを説明します。 広告なし、これは私たちが実際に持っているものです。 トラフィックは役に立たないが、それにもかかわらず、私たちは1日約50万人にサービスを提供しています。 これはリクエストの数ではなく、ユニークな人の数であり、もちろんリクエストの数はもっと多くなります-200万、おそらく3でもあります。スケール外の数値があります。 中央銀行がドルを発表した2014年に、為替レートサービスの負荷は1日で85倍に増加しました。 昨日は10件のリクエストがあり、その後850件のリクエストがありました。 第二に、当然。

何について話したいですか？

原則として、プロジェクトの開発方法、つまり おそらくあなたが考えるHighLoadは、まったくHighLoadではないという事実について。 habrfektについて-特定の人はこの不名誉とそれが何であるかを聞いた。 「粗悪品」またはハイテクソリューションに固執することで、これらすべてに対処する方法について、そしてまだクールな企業の大人がやっているように、やめなければならないことに気づき、素晴らしいことを始める必要があります。 そして、概して、この不名誉のプロセスに残っているすべてのものをどうするか。

それは非常に重要です：家で試してみる前に、私が今お話しすることはすべて、まず隣人と一緒に試してください。 また、一般的に言うと、絶対にやらないほうがいいと思うこともあります。 しかし、それでも...

まだHighLoadか、それともHighLoadですか？ つまり あなたのプロジェクトはそのようにロードされていますか？

これらの問題については、プロジェクトがロードされているかどうかを理解できますか？ たとえば、リクエストの数、サーバーの数、データベース内のレコードの数から、プロジェクトがロードされているかどうかを理解できますか？

実際、これらの特定の問題について理解することはかなり困難です。なぜなら、研究は包括的であるべきだからです。 たとえば、10万のリクエストを処理する10万のサーバーがある場合（サーバーごとに1つ）、これはおそらくHighLoadではありませんが、サーバーごとに10万のリクエストを処理する取引システムがある場合おそらく2番目は検討に値します。

しかし、このような問題については、HighLoadを理解できるかどうかを理解できますか？ つまり サーバーは負荷に対処していますが、これで何かする必要がありますか、たとえば、永遠のサイクルを削除するだけで、人生のすべてがうまくいきますか？ または、一般的に、たとえば、まだネジを締めていない場所にタランツールをネジ留めする方法を考える必要がありますか？ そのような質問は理解できますか？

原則として、HighLoadは、解決しようとしているタスクへの対処が停止するためです。 あなたの小さなVPSが突然死に始めた場合、原則として、あなたはすでにHighLoadに到着しています。 あなた自身のための高負荷。 たとえば、1秒あたり10リクエストはHighLoadではないという理解がないため、1秒あたり100リクエストはHighLoadです。 したがって、少なくとも現在の状態が低下し始め、最大でも動作を停止する状態に現在の決定が下されたときの状況について引き続き説明します。

気分がよくないときのそのような例の1つはhabraeffectです。 きっとあなたは彼について聞いたことがあるでしょう。 聞いたことがない人にとって、これは突然どこかから負荷がかかったときであり、突然の程度は本当に驚くべきことです。 かつて、私がカスペルスキーで働いていたとき、誰かが、カスペルスキーのメインページの添付が解除されたことを示すペイントブラシで描かれたスクリーンショットを投稿しました。 そして-見よ！ -誰もがこの人類を動かすものを知っているため、トラフィックはほんの数分で宇宙の高さまで増加しました。 そして、対応するタイプの画像を含みます。

つまり、事後的な成長とは、何かが起こったときに突然人気が出て、リソース、アプリケーションが何であれ、突然余分な負荷がかかる状況です。

これは、たとえば、広告主があなたが奇跡を起こし、オンラインストアがIphone 6を90％割引しているという非常にクールなニュースレターを受け取って実行する場合など、予測できるプロセスです。 、条件付き。 その後、Vkontaktikaなどのソーシャルネットワークに分類され、人々は必死に再投稿を開始し、雪崩のようなプロセスが開始されます。景品は人々をも動かすので、多くの人々があなたのところに来ます。 彼らは来ています。 最初の10人はあなたの決定に圧倒され、残りの100人はあなたを母親にし、あなたを呪い、二度と来ません。 ただし、事実は事実です。

また、たとえば、同僚や他の誰かがHabréに関する成功した記事を書いたときに、ランダムなプロセスがあり、インデックスに非常にうまく取り込まれました。 一般的に、人々はどこかから来ました。 または競合他社の陰謀-これは実際にはDDoSの平凡、つまり これはhabraeffectではなくDDoSであるという状況に陥ることがあります。

しかし、これが最終的にHighLoadになったと判断する理由ですか？ 実際には-図ではありません。 20分であなたのhabraeffectが終了するので、安心します。 そして、あなたはこの「安心」を神聖に信じ続けることができます。なぜなら、これが起こる可能性が最も高いからです。 2014年に私たちは3日間ソーセージだったので、私はこれを知っています-3日間、人々は為替レートに興味を持っていました。 ドルは30〜40ルーブルでしたが、90ドルになり、ある時点で100ドルを超えました。3日間、私たちはbeatられ、釈放されました。 これは何かが起こったという兆候でしたか？ はい、そうでした。

実際、負荷が反応的に増大し始めるこれらすべての瞬間は、ストレステストを無料で実施するクールな方法であり、通常は、このような特別なパラメーターを使用して実行することはできません。 たとえば、私たちのテストインフラストラクチャは、収益性の高い貢献やお金をすぐに隠そうとする他の何かを見つけようとしていた人々によって生成されたリクエストの数を生成することすら夢見ていません。

これはすべて機会であるため、後で手放すと、必ず手放されます（手放しなかった場合、これは別のレポートのトピックです）、インフラストラクチャのレビューを実施し、あなたの弱点があなたに与えた場所を理解する機会です。 つまり どこでもすぐに死ぬことはできません。 そもそも何かが死に、蒸気エンジンが残りを引き寄せます。 つまり ベースになるか、フロントになるか、アプリケーションになります。 これを調査する必要があります（ただし、これもまた別のトピックです）。

上記に基づいて、habraeffectは単に考える理由です。 まず、彼がどこから来たのかを理解します。 たとえば、マーケターが奇跡的に広告会社について警告するのを忘れてしまった場合は、二度とこれをしないように依頼する方が良いでしょう。 まあ、彼らはお金を無駄にしたので-あなたはまだ誰にも答えなかった。 それにもかかわらず、原則として、私たちはさらに作業を続けることができる弱いリンクがあります。

最初に壊れたのは何ですか？ 最初に頭に浮かぶのはそれを理解することですが、何が落ちましたか？ なぜ成長が起こったのですか？ これが再び起こる可能性はありますか？

これは非常に重要です。 特定の次のレベルに進む場合は、これを理解する必要があります（これを理解する方法-後で詳しく説明します）。 それにもかかわらず、これがシステムであることを理解している場合、これは考える理由です。 その前に。 これはあなたの情報のためです。

当然のことながら、太陽の下で死んだ魚のようにふらふらする状況では、人々が気分を良くするために何かを試してみるといいでしょう。 これには松葉杖があります。

松葉杖は輸送手段ではなく、意思決定を機能させる方法です。

「松葉杖」には2つのタイプがあります。最初の「松葉杖」は通常の「クイック」で、2つ目はハイテクの「松葉杖」です。 ほとんどの場合、これはまったく同じであり、多くは、彼らがタスクを解決するとき、「松葉杖」を挿入したと言って非常に恥ずかしいです。 何らかの理由で、これは悪いと考えられています。 実際、これは悪いことではありません。 正直に言っておきます-それもいいです。

問題をすばやく解決できます。 はい、それは必ずしも簡単ではありません、はい、それは常に賢いわけではありません-これは明らかです。 さらに、ほとんどの場合、翌日、この決定を見て、はっきりと見て、それを二度としないことを約束しますが、実際には問題を解決します-弱点を見つけ、この弱点が除去され、人々-あなたの顧客-彼らは受け取り始めます。 すべてではありませんが、もっとあります。

ほとんどの場合、これらの「クランチ」は非常に厄介に挿入されますが、生産にコードを注ぐときにプロセスがある場合は、気分が悪いときに反対のことを行うことができます。 たとえば、実サーバー上で何かを修正し、それがすべて機能することを確認してから、詰め込むことができます。 ですから、時には何もしなくても対処しました。

そして最も重要なことは、今やらなければならないことを覚えておくことです。 私たちはそれを自分自身に、システムにそれを借り、人々にそれを借りています。

技術的ソリューションの場合...技術的ソリューションについて話すとき、どういう意味ですか？ これは、あなたがすること、実際に行うこと、より意識的にすること、または何かをするときです。 これは、一種の設計、理解、認識、将来の評価、つまり、すべてがどのように機能するか、または機能しないかです。 これは同じ「松葉杖」であり、「科学によると」だけが挿入されています。 プロセス-タスクを配置し、タスクが計画に落ち、計画し、実行し、評価したなど。

ほとんどの場合、これはうまく、クールに、正確に行われますが、あなたがカバーされている状況では、それについて何もすることができず、単にこのための時間がありません。 たとえば、私たちのような状況があります。 一時的に病気になったとき、彼らはワニスをすぐに生産にねじ込んで、原則的に彼を後でそこに置いて、それを調整しただけでした。それは彼らがちょうどそのようにそれをねじ込んだとき、それはあまりうまくいかなかったからです 特に、彼は人々が来る都市、人々が見るバナー、ある種の個人的なメッセージのキャッシュを開始し、最後に誰かが404番目のエラーをキャッシュし、404番目のエラーをすべての人に5分間配布しました。おそらく。 しかしすぐに、彼らはここで何かが間違っていることに気づきました。 その後、すべてを思い起こさせ、再構成しました。

ちなみに、ここにアルゴリズムの1つがあります。 非常に重要な点は3番目です-特に中小企業では、このような上司主導の開発があり、上司が走り出すとき、それはよくあることです。 最初に頭に浮かぶのは、「これはシェフ、クリスマスツリー、スティックです。人を怒らせることはできません。」 それから、技術的にでなくても「裂け目」が生まれますが、もし彼が目から消えていたら、夕方にはなんとかして終わります。

これがアルゴリズムです。 実際、アルゴリズムはクールですが、結局は機能しません。なぜなら、最終的には、上司にとっても、つまり債務と「クランチ」の問題を抱えているからです。 あなたは理解している、彼はあなたにお金を借りている、そして今あなたは彼に借りている、すなわち。 良くない。

そのような状況を回避するために、何かを始めることはいつ意味がありますか？ つまり どんな種類のアルゴリズムがありますか？ 一般的に、ついに心を取り戻す時が来たら、ズボンを持っていると考えるのをやめ、「股」のシステムがいっぱいになっていることを思い出してください。

見る唯一の方法は監視です。 つまり 理解する方法 実際に理解するのは難しいでしょう、私は今その理由を示します。 しかし、実際には、監視がない場合、隣の部屋からの悲鳴しかない場合、そのような基準で理解することはほとんどありません。 しかし、再び、誰が叫ぶのですか？ その男が3番目の段落から大声で叫ぶなら、おそらくそれは時間です。 システムで何が起きているのかを理解するまで、システムが悪化していることに気付く可能性はまったくありません。

そして、これらの結果を分析します。 場合によっては、同じ悪名高いGoogleアナリティクスで十分であるため、これらの美しいトレンドを巧みに引き出すことができます。 それがどのように機能しないかをお見せしますが、実際には、少なくともいくつかの数字を使用すると、時間が不足していることを理解することができます。 つまり 当然、どの技術にも独自の安全マージンがあります。これは、さまざまなケースで異なって発見され、ほとんどの場合、落下によって発見されます。 または、事前に何かを始めます。

ここで、「前進」について。

予測の問題について。 純粋に理論的には、世界がそのように配置されていれば、これは起こり得、問題はまったくなかっただろう。 つまり 10人のユーザーが生成するCPU（ここではCPU）の10％がある場合、20％-20、30％-30など。 10個の核がある場合、条件付きで1000個になります。 実際、これはほとんど起こりません。 つまり、おそらく起こりますが、私は会っていません。 多くの場合、100人のユーザー（これはCPUの10％であり、200人のユーザー）がいるときに起こります。 200人のユーザーがいないこともありますが、同時に別の場所に座っています。 そのため、システムには、常に監視する必要がある4〜5ポイントが比較的あります。

監視はCPU、メモリ、チャネル、ディスク、およびデータベースへのクエリの数です。データベースもゴム状ではないため、アプリケーションのデータベースで接続数を可能な限り増やしても、これは影響しません。来る人が食べてしまうまで。

構成エラーがあります。 何かがうまくいかない最も一般的な理由は、構成エラーです。 つまり たとえば、ボックスからpostgressを取得して、それを配置すると、動作します。 テストマシンで動作し、5人のユーザーで動作し、10人のユーザーで動作し、20人では動作しません。 同じパセリはほとんどすべてで起こります。 ソリューションをプログラムし、それがうまく機能している場合、それ以上動作する必要はまったくありません。 したがって、ここで何かを行う唯一の方法は、定期的に調査を行い、これらのしきい値の周期的なスライスを実行して、おおまかに言って、負荷がカーブを変え始める瞬間を捉えることです。 たとえば、CPUの負荷があり、ほぼ線形です。 サービングを開始し、少し逸脱し始めます。ある時点でこのように逸脱します。または逸脱しませんが、他の場所で逸脱します。したがって、Zabbixを使用する場合、1つの画面に5つのモニターを表示できます。その上に、すべてが表示されます。 列に表示することをお勧めします。 なぜコラムに？ 負荷が増加すると、すべてのパラメーターで何が起こるかが明確にわかるからです。

これは非常に簡単に実行されます。Zabbixでは、マウスをクリックしてクリックするだけで問題ありません。 まだお持ちでない場合は、ねじ込むことをお勧めします。 私たちはトイレに行く途中でそのようなテリーがぶら下がっています-これはすべてのエンジニアが日中に何度も通り過ぎる場所です。 彼は仕事をするために彼を通り過ぎ、仕事を離れます。 パスがとても舗装されているのはたまたまありました。 そして、通り過ぎると、彼は見えます。 そこでは、これらのグラフが列にぶら下がっています。3台のモニターで、すべてがはっきりと見えており、プラズマでさえ必要ありません。

, , - , , . , , JMeter , , , . つまり , , - – - « », . - , , , . , : « ?» – «, , , », - . , , , . .

- ? もちろんできます。 – . , , , . , … Hetzner – ? , -? / , , . , , , , . , , - , - , , , , 400-500 , , , 1000. 1000 – . – , , , , .

, . . - , , , , :

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

– ? , 1000 , 10 . . , . google-, . – , , . , . , , . …

– . . つまり : « ?» – «, , 500-600». . ? , ( ). つまり 4 . . つまり , « 4.5 . », . 10 ., , , , .., , . – , . , , . つまり . つまり - , -, - - . , , , ..

. つまり . これは何ですか , - . , , , , , , . , .

, , 50 , , 2 , 1 . , ± , .. . , , . , , , , , , .

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

, – , . , , - , - , , , , , Nginx, , ...

, , , , .. , . . 技術 – «», , .

, - «» . Badoo Yandex ( HighLoad), : «, «». それで何？ : «, «». , , . «» – , , .

, , . - - , - - … – « ».

, , . -, , , , , , . , -, , , - . , – , – . , «1» – , «1.1» – , «1.1» 34 , - . , .

, . , , , ? , , , . 100 . , , . , - – , Tarantool. NoSQL, Postgress ( ), - , .

. - . – ? . , , , . . , , , , , , , , , . 30 . , , , , , , , , – . , - , , .

, , . , , – . , , . , , , . , , , , , , . , – , , , , . , «»/ , Landing Page.

Landing Page? html, , Nginx' . Nginx 80 . , – . 80 . . , - , . – – , , , «» «», -, . «»? «». 解決策？ どうして？ , , , , . , 80 . , , .

, , , , .

, – , , ? , :

, 100500 , . , J:

YouTube « », , , 20. 20, , , , J

つまり , , , -. , «-».

, , , , . , , - Badoo. , , , , . , . , , , .. . , , , , . , …

, , ? , , . , , , , : «, , . ». , . « ». , 700 . , , , ID … , – , , . , , , . , «, » – , , ..

( ?) , , . つまり – « Nginx ?», « ?», « Postgress?» , , « - slow log MySQL?». . , , DBA. « ». Google , . Google , , , J.

, , ? . . 彼はそこにいません。 , : « . 1 2016 , ». , - , , . . – , .

– , .

– , , , Badoo' , , , . , , , , . - ..

«». – . つまり - . - , . – . . つまり , select * from (- ) – , . , 200 . , 200 . . , 2 , - , , , , , , , , , , , .

Badoo'? . , , , -. つまり , . つまり , – , , – 100 , , , .

? . - . つまり . – IT . , . – , , , , , . , , , , . , , «, , , , , ».

, . . , , , javascript . , , . . つまり , – .

, . – , . つまり , , . « » , - , - -, - . . , , . - . , . , - , , . . – : « ».

, , NPM . ? . «-! ». , … J – , , , . – . , javascritp … , , , , , . , - - , , url… – url , , , - . url, «--, », , «», , , , . , . . つまり , - , - , , , , , , .

. , GitHub, . . . , , .

– , , . , . , slow , , , slow. , php , , javascript . . ' , -, , . -, , . javascritp .

, . -, - , , , , , , , .

«», . . . , , , - , , , , , , . , «». – . . , - , . , , … , . - , - . - , ? あります。 , , .

? , .

, «» – . , , , , , - , «» Nginx, , , « ». , : « , . , ». , , Nginx, .

– , .. , . , , – . , . . - , , – , . それはすべてゴミです。 , -, , , , , «», … , « », . つまり , «-».

そして、デフォルトのようなものがあります。これは借金を返済できないことです。技術的なデフォルトは、債務を支払う能力ですが、債務を支払うことができないことでもあります。つまり実際、支払いの機会があるが、気に入らないとき。同じことがそれらについても起こります。借金。あなたはそれを行うことができますが、このビジネスを行うことは許可されていません。あなたはビジネスのために得点することができます、しかし、ビジネスはあなたのために得点します、そして、あなたは仕事を変える必要があります。つまり この状態になるのは非常に早くなりますが、非常に長い間この状態から抜け出します。

たとえば、それらのいくつかのチームがあります。 約170のタスクが集まっています-約1か月ほどです。 さて、これが天井であることが実験的に証明されました。 そして、私たちがこの上限に達したら、私は仕事に行き、プロジェクトの間に1週間または半分を与えて、この「オージェの馬小屋」からそこにプログラムしたものを一掃し、捨てるのに費やします。 常に動作するとは限りませんが、通常は簡単に説明されているため、動作します。動作しない場合、動作しなくなります。 それから、あなたは「良い仲間」とは何か、「私は誰を雇い、誰にお金を払うのか、何を...」、その他多くの言葉に耳を傾けます。 それでも、これが唯一の方法です。

負債は常に蓄積され、私は単一の会社を見たことがありません...私は欠陥なしで働くことができると主張する会社について読みました。 彼らは欠陥の外観を持っています-これは「赤い布」であり、「誰もが残して、欠陥を修復しに行きました」と言います。 正直、彼らがどれだけ早く前進しているかはわかりません。 私はこの問題を調査していませんが、これはあまりうまく機能していないようです。

そして結論として。 重要な戦略！ なぜ戦略なのか？ あなたと一緒に働く人々はみな同じように考えるべきです。 つまり ある種のfakapが発生する状況では、誰もがほぼ同じように行動する必要があります。 そのため、人類はコミュニケーションを考え出しました。そのため、同僚と話すことができます。 プログラマーは同僚と話すのは本当に好きではありませんが、それでもそれは理解しています。 一緒になって、少なくとも極端なもの、つまり 「不幸が発生した場合、ここですべてを修正します。」 ほとんどの場合、これは起こりません。 つまり 当然、誰もが私を修理するのを手伝いますが、私はこれが実際にどのように起こるかを見ました。 通常は次のようになります。チームの半分は、「まあ、e-mine！」と言い、タイプは何をすべきかを考えます。 チームの後半は次のように述べています。「それですべてです、要するに、いまいましい... 1秒あたり100件のリクエストがあり、現在は500件です！ わかりました、要するに。」 それから誰かが一人で、男の子を女の子、女の子-男の子を内なるエゴを活性化させると呼びます。 そして、「さて、少し考えてみましょう。」

考えてみましょう。 これは重要です！ 一般的に、プログラマは考える傾向があります。 あなたもそれについて考える必要があります-何が起こったのか、何をすべきかについて。 災害が発生した場合にどうすべきか、5ポイント短い計画があります。

そこにあるものはすべてこのようなものです。そこに行く、ここにあるものを見る、ここに行く、ここにあるものを見るなど。

システムを監視する必要があります。 もしあなたがプロジェクトをしているなら（今のところバイアグラのウェブサイトではありません-そこに売るのにファッショナブルなものは何ですか？）それは一ヶ月間働いて死にます。 つまり 作業中のシステム、これをあなたのマシンと考えてください。 ブレーキが潜在的に悪い車を運転しますか？ おそらくない。 一度大規模にポールに突っ込んで、ブレーキがうまく機能しないことに気付いた場合、これを繰り返したらもちろんクールになりますが、それは素晴らしいことですが、実際にはそこに何かを締めた方が良いでしょう。

リスクを常に評価する必要があります。 リスク評価とは何ですか？ 私たちにとって、これは次のようなものです。1分間失敗した場合、どれだけのお金を失うか。 まあ、100ドル、比較的言えば。 そして、それは私のためにどれくらい飛ぶでしょうか？ または、これからどれくらいの会社が悪いでしょうか？

個別に説明する価値があるクールなものがまだあります-これらは評判のリスクです。 あなたのそれぞれのfakapはfakapのお金ではなく、評判のfakapです。 つまり あなたが若い初心者のソーシャルネットワークfacebook2である場合、もちろん、あなたがうろついていない方が良いでしょう。さもないと、facebook1に到達する機会がありません。 これは、偶然にも、WhatsAppのアナログである中国のchatikの男たちによって示されました。彼は誇らしげに市場に参入し、「ねえ、あなたは誰ですか、ここを去る」と言われました。 そして、彼らは中国の10億人のユーザーにとどまりました。 彼らは何かを予見しなかったし、どこかで考えもしなかったし、それを理解しなかったし、これらすべてをどうするかという戦略を持っていなかったからです。

猫を試着してください。 今では非常に安価なホスティングが仮想です-あなたはそれを取り、あなたが集めた膝の隅のどこかにあなた自身のシステムを作り、あなたが望むもの、技術、動物園を突き出します。 落ちさせて、死にさせてください。 笑いのために、そこにあなたのトラフィックの一部を送ることさえできます。 Nginxはこれを行うことができます-バランスについて覚えていますか？ そこに10人を送り、実際に何が起こるかを見てください。 Badooの人たちもそうです。 これは広告ではなく、彼らはそれについて話しました。 私の意見では、彼らはアイスランド人のサービスを分析しています。 まあ、彼らは、この世界で何が起こっているのか気にしない、ほとんどの耐震性の男を連れて行った、彼らは彼らの島に座っていて、彼らは素晴らしいです、そしてこのエイヤフィクール、彼らはすべてクールです。 そこに新しいソリューションがロードされ、見た目が変わります。 「ああ、もう一杯ビールを飲もう」 これは本当の話です、彼らはそれについて話しました。

常に現在のソフトウェアバージョンを追跡する必要があります。 すべてが常に変化しますが、微妙な違いがあります-突然何かを更新するのを忘れた場合、おそらくその時点でリポジトリに入れている次のバージョンがあなたの決定と矛盾する可能性があります。 これは、Gitのように、多くの人が忘れてしまう非常にクールなわき柱です。 しかし、Gitはあなたの所有物ではなく、この決定をした人の所有物であることを誰もが忘れています。 そして、彼のために小枝を叩くことは、原則として、彼の権利であり、彼らが言うように、インターネット憲法によって彼に与えられています。 彼のコード-彼が望むものは何でも、彼はそれでやります。 したがって、すべてを明確で、威厳のある、高貴なものにし、ソフトウェアに目を向け、調整を続け、原則としてインターネット上で何が起こるかを監視したい場合。 たとえば、通貨交換サイトの場合は、この通貨で何が起こっているかを一目で見たほうがいいでしょう。 遅かれ早かれ、トラブルが発生する可能性があるためです。

重要な言葉。 非常に賢い男が言った。 彼は、私がここで言ったすべてが、概して、私がここで言ったすべてだと言った。 つまり 本当に、何をすべきかはあなたのために決定を下すことです。

Roman Ivlievのウェビナー 「 高負荷システムの開発について、 ゼロから段階的に開発する 」で詳しく説明します 。 これは1日集中的なマスタークラスであり、そのフレームワークの中で、システムの開発、リファクタリング、リエンジニアリングについてさらに詳しく説明します。

システム開発

• 何かを始める時はいつですか？
• クラシックロードWebポータルの進化（banki.ruの例）
• システムのさまざまな要素の最適化方法
• ガイド付き劣化とその準備
• 成長に向けたシステムの準備：柔軟性と信頼性
• 誇大広告-長所と短所

リファクタリングまたはリエンジニアリング

• システム開発とのビジネス継続性
• 現在のシステムの機能を安全に使用できるのはいつですか？
• いつ新たに構築を開始する必要がありますか？
• システムのPDCAサイクルと無駄のない開発。