人生には、あなたに分かち合い、伝え、賞賛され、喜びたいと思う良い瞬間があります。 そして、否定的な意味合いを持ち、誰も安全ではない状況があります。 あなたは彼らから学ぶ必要があるだけで、将来の繰り返しを許可しません。 約束どおり、このセクションでは、ポジティブなストーリーだけでなく、有益なストーリーも公開しています。 結局、エラーは私のせいではありませんでしたが、どういうわけか私はその日はチームの一員であり（そして今もその中に残っています）、全員と責任を共有しています。 何が起こったのか、何が根本原因だったのかを伝えることだけが残っています。
休日、誕生日、誰かに好きになったり、何か楽しいものを作ったり、誰かを愛したり、時には理由なく花を贈ったりするので、花は一年中いつでも需要があることをよく知っています。 しかし、花ビジネスには季節性があることも知られています。
最も人気のあるリクエスト「flower delivery」のいずれかについてwordstat.yandexを介してリクエストの履歴を見ると、前年については1月下旬から3月中旬、8月、11月下旬に特徴的な上昇が見られます。
これらの傾向を引き起こした日付は次のとおりです。
- 1月25日-タチアナの日。
- 2月14日-バレンタインデー;
- 2月23日-祖国の日の擁護者。
- 3月8日-国際女性の日。
- 8月中旬-子どもたちの学校への準備、教師への贈り物。
- 11月25日は母の日です。
そして、各新年の最初の3か月は、このビジネスの所有者にとって最も波乱に富んだものです。 設備の整ったこれらの休日に近づくことは非常に重要です。 私たちは年々すべてを試してみましたが、2018年2月14日に失望しました。
プロジェクトについて少し：モスクワとモスクワ地方で配信を行うオンラインフラワーショップ。プロモーションの主な情報源は、コンテキスト広告（20％、この方向を担当しています）およびSEOプロモーション（75％）と電子メールマーケティング（5％）です。 ソーシャルネットワークは実質的に関与していません。 1C-Bitrixのサイト、従来のホスティングタイムウェブ。 後者は非常に重要です。その理由を説明します。 そして、私たちのプロジェクトを監督する開発チームは遠隔地でした。 そして、これはある程度の役割を果たしました。
「花の栽培者」は、これらの休暇でほぼ6か月の収益率を得るという神話があります。これにより、他の月にパンをリラックスさせることができます。 そうではありません。 はい、注文が増え、収益が倍になります。 しかし、常に到着したわけではありません。 花を買う費用、花屋のサービス、梱包、部屋を借りる、宅配便の費用、広告費、返品-これらはすべて、需要の高い時期に大幅に増加するためです。
そのため、モスクワ時間の2月14日12時30分まではすべて順調でした。 この時点で、合計500,000ルーブルの120を超える注文を既に受け付けています。 そして、彼らは昨年の経験からさらに200件以上の注文を獲得しようとしていました。 100人以上のユーザーへの同時アクセスの記録も記録しました。
12:43に最初の障害が発生しました。 もちろん、私たちはすぐにリモートの開発者に助けを求めました。 WhatsAppの所有者とのやり取りは次のようなものでした。
エラーは502 Bad Gatewayであり、ある時点でこれを修正することもできました。
そして、これは販売と注文のピーク時間です。 開発者は自分で問題を見つけることができず、ホスティングの技術サポートに連絡しました。 しばらくして、次の回答を受け取りました。
次に、サイトクラッシュチェーンを示します。
- 12：43-12：47 = 4分
- 13：01-13：18 = 17分
- 13：27-13：42 = 15分
- 13：57-14：17 = 20分
- 14：26-14：54 = 28分
- 14：58-15：15 = 17分
- 15：30-15：46 = 16分
- 16：08-16：27 = 19分
- 16：35-16：37 = 2分
- 16：48-16：51 = 3分
そして、所有者とのそのような対話：
その瞬間、私はその時点ではありませんでした（神に感謝します！）、したがって、私はすべてのメッセージと感情からしか推測できませんでした。 サイトのコピーがなく（むしろ、メインサイトと一緒に落ちた）、花屋のすべての花（花束）を記憶から収集しなければならなかったのは怖かったです。 注文はありましたが、メールに落ちましたが、色、量、形、写真、いくつかの非標準的なブーケがあります-これはすべてクライアントから尋ねるか、個別に記憶する必要がありました。
開発者は、サイトの崩壊の原因を特定できませんでした。 ある時点で、彼らは競合他社の陰謀とDDoS攻撃の理論を信じ始めました。 ホスティングは我慢できませんか？ 私たちはこれについて考えましたが、2月14日より前には、負荷の点でもそれほど厳しくない2月13日でした。 しかし、すべてが順調に進みました。
私たちのオンラインストアは、独立した専門家としてフリーランスの仕事を最近行っていた人に頼るまで、2月15日まで残りました（残りの30件のみ注文を受けました）。
プログラマーがすぐにアドバイスした最初のことは、ホスティングを少なくともVPS（仮想サーバー）に変更し、このサイトを別のVPSに置くことでした。仮想サーバーはより強力で安定しているからです。
ログファイルの分析により、攻撃はなかったことが示されました。 確かに、誰かがホスティングでサイトをオフにすると（13：01-13：18）、つまり おそらくDDoS攻撃やPHP側のエラーではありませんでしたが、ホスティングの誰かが一定期間このサイトをオフにしたようなものでした。 これはそうでした-サーバーの負荷が非常に高いため、ホスティングスタッフが手動で切断しました。 そして、そのような急激なジャンプの理由は何だった-さらに調べる必要がありました。
各仮想アカウントに対して、ホスティング事業者は特定の容量を割り当てますが、これらの割り当てられた容量を突然超えると、ホスティング事業者はこのアカウントを一時的に送信して無視し、アカウント所有者にメッセージを書き込みます。 「。
質問へ：
「なぜ彼らは、現在の開発者に、より強力で安全な別のサーバーに切り替えるほうがよいと言わなかったのですか？」
私は非常に具体的で堅牢な答えを得ました：
「多くのプロガーはそこへの移籍を申し出ません。 結局、これを行うには、Linux管理の知識が必要であり、これはシステム管理に近いものです。
すべてがすぐに明らかになりました-無能。 それらから、次のメッセージを受け取りました。
まだDDoSのように見えますが、ややこしいです。 現在、このサイトにはほとんど人がおらず、彼は毎分40,000件のデータベースへのクエリを実行しています。 要求は大きく、キャッシュをオーバーフローさせるため、何もロードされません。 昨日は、人数の点で負荷は大きくなりましたが、サイトは対処し、そのような問題はありませんでした。 サイトのコピーを展開し、多数のユーザーのエントリをシミュレートしました。 彼は凍り始めます。 VDSに移行する必要があります。 さらに、サイトは機能し、計画どおりに整理されます。今でも、DDoSはデータベースクエリに関するものではないことを知っています。 Webサーバーへの要求はないが、データベースはある場合、これはDDoSではなく、いくつかの内部問題です...一般に、0レベル。 開発者のレベルは、ストレスの多い異常な状況ですぐに明らかになりました。 1.5日間、3〜4人のチームは、ストアの崩壊の理由を理解できず、パフォーマンスを回復できませんでした。
ある時点で、SEOがヒントを出しました。 それらは：
- Yandexボットの側面からロボットを介したサイトの負荷を軽減しました。 これまで、厳密な制限を設定しました。
- Google Webmastersを使用して、サイト上のGoogleボットの負荷を軽減しました。
- .htaccessファイルを使用してボットを閉じることにより、不要なさまざまなボットからのサイトの負荷を軽減しました。
このストーリー全体を通して私たちを助けてくれた開発者は、これらの編集にm笑的に反応し、これはまったく関係がないと言った。 誰かがトラックをクリーンアップするか悪化させる前に、何かをしなければなりませんでした。
私たちは独立系プログラマーを完全に信頼し、彼からのニュースを期待し始めました。 そして、サイトはぶら下がっていた、管理者パネルに行かせさえしなかった。 その結果、開発者はホスティングのサイトから直接サイトのコピーを取得し、ローカルでホストしました。
小さな余談：オンラインストアは2015年から運営されており、その間いくつかのSEOプロモーション代理店がサービスを提供しています。 これらの機関では十分な数の開発者が変更されており、それぞれが独自のアクセス権を持っています。 後に判明したように、ほとんどすべての「犬」がサイトへの管理者アクセス権を持っていました。 そして、SEOドライバーも同様です。
まず、すべてのアクセスが閉じられました。 はい、もちろん、1C-Bitrixはそのことで有名です-アクセスすることはできませんが、起動すると管理者を復元および追加できるスクリプトの束しかありません。 そして、サイトにアクセスした人（そして約12人）がそのようなスクリプトをどこかに置いた場合、問題なくそれを起動し、管理者とたわごととしてアクセスすることができます...
しばらくして、彼から最初の結果を得ました：
犯人の名前は付けられていませんが、責任者は次のとおりです。
\Bitrix\CmskassaEkam\CheckListTable::loadUpdates()
— . ( ), . () , . , - , - .
EKAM – - . - CMS «1-» «54- - » - .
( ), , EKAM .
, «. (cmskassa.ekam) cmskassa.ru» - «\Bitrix\CmskassaEkam\CheckListTable::loadUpdates()» . () . , , - .
EKAM . , - EKAM ( ), - , .
, 1-2 10-15 . 15 EKAM. , . , EKAM :
… EKAM , .
/ , . , , , .
, 8 . , , 14 .
, :
- ;
, – , , :
- ;
, ;
LOG- , , ;
( , , ), , , .
- ;
, . , , . , . . , , , – / . – . – .
. , 100%, .
- ;
, – , – , seo- – .. . , …
- , ;
. , . . , , . DDoS- . , .
- , . ?
, EKAM , . . , . . . , 200 1 .
, .