新しい状況におけるオンライン取引に迅速に適応するのに役立ったもの

Привет！

私の名前はミハイルです。Sportmaster 社の IT 部門副ディレクターです。 パンデミック中に発生した課題に私たちがどのように対処したかについてお話したいと思います。

新たな現実の最初の数日で、スポーツマスターの通常のオフライン取引フォーマットがフリーズし、主にクライアントの住所への配送という点でオンライン チャネルの負荷が 10 倍に増加しました。 わずか数週間で、私たちは巨大なオフライン ビジネスをオンライン ビジネスに転換し、サービスをクライアントのニーズに適応させました。

基本的には副業だったものが本業になりました。 あらゆるオンライン注文の重要性が非常に高まっています。 顧客が会社に持ち込んだすべてのルーブルを保存する必要がありました。 

お客様のご要望に迅速に対応するため、本社にコンタクトセンターを増設し、現在では週に約285万270件の電話を受け付けるようになりました。 同時に、XNUMX 店舗を非接触型で安全な新しい営業形式に移行し、顧客が注文を受けられるようにし、従業員の仕事を維持できるようにしました。

変革の過程で、私たちは XNUMX つの主な問題に遭遇しました。 まず、オンライン リソースの負荷が大幅に増加しました (これにどのように対処したかについては Sergey が説明します)。 第二に、まれな（新型コロナウイルス感染症以前の）オペレーションのフローが何倍にも増加しており、そのため大量の迅速な自動化が必要でした。 この問題を解決するには、これまで主要だった領域からリソースを迅速に移転する必要がありました。 エレナが私たちがこれにどう対処したかをお話します。

オンラインサービスの運営

Kolesnikov Sergey 氏、オンライン ストアとマイクロサービスの運営責任者

小売店が訪問者の出入りを禁止し始めた瞬間から、ユーザー数、アプリケーションでの注文数、アプリケーションへのリクエスト数などの指標の増加を記録し始めました。 

18月31日からXNUMX月XNUMX日までのご注文数オンライン決済マイクロサービスへのリクエストの数ウェブサイトでの注文数

最初のグラフでは増加が約 14 倍、4 番目のグラフでは XNUMX 倍であることがわかります。 当社では、アプリケーションの応答時間の指標が最も指標となると考えています。 

このグラフでは、フロントとアプリケーションの反応がわかりますが、私たち自身としては、それ自体の成長は見られないと判断しました。

これは主に、2019年末に準備作業を開始したことによるものです。 現在、サービスは予約されており、物理サーバー、仮想化システム、Docker、およびそれらのサービスのレベルでフォールト トレランスが確保されています。 同時に、サーバー リソースの容量により、複数の負荷に耐えることができます。

このストーリー全体で私たちを助けた主なツールは監視システムでした。 確かに、つい最近まで、物理的な機器やハードウェアのレベルからビジネス指標のレベルに至るまで、すべての層で指標を収集できる単一のシステムはありませんでした。 

正式には社内に監視がありましたが、原則として分散し、特定の部門の責任範囲内にありました。 実際、インシデントが発生したとき、正確に何が起こったのかについて共通の理解が得られることはほとんどなく、コミュニケーションも取れず、多くの場合、問題を見つけて解決するために問題を切り分けようと堂々巡りすることになりました。

ある時点で、私たちはこれに耐えるのはもう十分だと考え、決断しました。全体像を完全に把握するには統合システムが必要です。 当社のスタックに含まれる主なテクノロジーは、アラートおよびメトリクスのストレージ センターとしての Zabbix、アプリケーション メトリクスの収集と保存のための Prometheus、監視システム全体からのデータのログ記録と保存のための Stack ELK、視覚化のための Grafana、Swagger、Docker です。その他便利なものや身近なもの。

同時に、市場で入手可能な技術を使用するだけでなく、独自の技術も開発しています。 例えば、システム同士を統合するためのサービス、つまりメトリクスを収集するための API のようなものを作ります。 さらに、私たちは独自の監視システムにも取り組んでおり、ビジネス指標のレベルでは UI テストを使用しています。 また、チームに通知するための Telegram のボットもあります。

また、チームがモニタリング システムにアクセスできるようにして、チームが独立してメトリクスを保存して操作できるようにすることにも取り組んでいます。これには、広く使用されていない一部の狭いメトリクスに対するアラートの設定も含まれます。 

システム全体を通じて、私たちは可能な限り迅速にインシデントの事前対応と局地化を図るように努めています。 さらに、マイクロサービスとシステムの数は最近大幅に増加しており、それに応じて統合の数も増加しています。 また、統合レベルでインシデントを診断するプロセスを最適化する一環として、システム間のチェックを実行して結果を表示できるシステムを開発しています。これにより、システムのインポートや相互作用に関連する主な問題を見つけることができます。お互い。 

もちろん、オペレーティング システムに関してはまだ成長と発展の余地があり、これに積極的に取り組んでいます。 当社の監視システムについて詳しく読むことができます ここで. 

技術試験 

Orlov Sergey 氏、ウェブおよびモバイル開発のコンピテンス センター長

実店舗の休業が始まって以来、開発面ではさまざまな課題に直面してきました。 まず、負荷サージそのものです。 適切な対策を講じないと、システムに高負荷がかかると、悲しい衝撃を伴うカボチャに変わったり、パフォーマンスが完全に低下したり、機能を失ったりする可能性があることは明らかです。

XNUMX 番目の側面は、あまり明白ではありませんが、ビジネス プロセスの変化に適応して、高負荷下のシステムを非常に迅速に変更する必要があるということです。 一日に数回のこともあります。 多くの企業では、マーケティング活動が活発な場合はシステムに変更を加える必要はないというルールを設けています。 何もありません。機能する限り機能させてください。

そして、実質的には終わりのないブラックフライデーが続き、その間にシステムを変更する必要がありました。 そして、システムにエラー、問題、障害が発生すると、ビジネスにとって多大なコストがかかります。

将来的には、これらのテストになんとか対処でき、すべてのシステムが負荷に耐え、簡単に拡張でき、世界的な技術的障害は発生しなかったと言えます。

高サージ負荷に耐えるシステムの能力を支える XNUMX つの柱があります。 XNUMX つ目はモニタリングです。これについては上で説明しました。 組み込みの監視システムがなければ、システムのボトルネックを見つけることはほとんど不可能です。 優れた監視システムは家庭服のようなもので、快適で自分に合わせたものである必要があります。

XNUMX 番目の側面はテストです。 私たちはこの点を非常に真剣に受け止めており、システムごとにクラシックなユニット、統合テスト、負荷テスト、その他多くのテストを作成しています。 私たちはテスト戦略も作成しており、同時に手動チェックが不要になるまでテストのレベルを向上させようとしています。

XNUMX 番目の柱は CI/CD パイプラインです。 アプリケーションの構築、テスト、デプロイのプロセスは可能な限り自動化する必要があり、手動による介入は避けるべきです。 CI/CD パイプラインのトピックは非常に深いので、簡単に触れるだけにします。 言及する価値があるのは、各製品チームがコンピテンシー センターの支援を得てチェックする CI/CD パイプライン チェックリストがあることです。

そしてこちらがチェックリストです

このようにして、多くの目標が達成されます。 これは、リリース トレインを回避するための API のバージョン管理と機能の切り替えであり、テストが完全に自動化され、デプロイがシームレスになるなどのレベルでさまざまなテストをカバーします。

XNUMX 番目の柱は、アーキテクチャの原則と技術的ソリューションです。 アーキテクチャについては長く話せますが、注目したい原則をいくつか強調したいと思います。

まず、特定のタスクに特化したツールを選択する必要があります。 そうです、当たり前のことですが、釘はハンマーで打ち込むべきですし、腕時計は専用のドライバーを使って分解するべきであることは明らかです。 しかし、私たちの時代では、データベース、キャッシュ、フレームワークなど、ユーザーの最大セグメントをカバーするために、多くのツールが普遍化を目指しています。 たとえば、MongoDB データベースはマルチドキュメント トランザクションで動作し、Oracle データベースは json で動作します。 そして、すべてがすべてに使用できるように思えます。 しかし、生産性を重視するのであれば、各ツールの長所と短所を明確に理解し、クラスのタスクに必要なものを使用する必要があります。 

第 XNUMX に、システムを設計するときは、複雑さの増加を正当化する必要があります。 低結合の原理は誰もが知っているので、私たちは常にこのことを念頭に置く必要があります。 私は、それは特定のサービスのレベル、システム全体のレベル、そしてアーキテクチャのランドスケープのレベルで適用されるべきだと信じています。 負荷パスに沿って各システム コンポーネントを水平方向に拡張する機能も重要です。 この能力があれば、スケーリングは難しくありません。

技術的なソリューションについて言えば、私たちは製品チームに新しい推奨事項、アイデア、ソリューションのセットを準備するよう依頼し、次のワークロードの波に備えて実装しました。

ケシ

ローカル キャッシュと分散キャッシュの選択には意識的に取り組む必要があります。 場合によっては、同じシステム内で両方を使用することが合理的です。たとえば、データの一部が本質的にショーケース キャッシュであるシステムがあります。つまり、更新のソースがシステム自体の背後にあり、システムは変更されません。このデータ。 このアプローチでは、ローカルのカフェイン キャッシュを使用します。 

また、システムが動作中に積極的に変更するデータがあり、ここではすでに Hazelcast で分散キャッシュを使用しています。 このアプローチにより、本当に必要な場合には分散キャッシュの利点を活用し、分散キャッシュがなくても済む場合には Hazelcast クラスター データを循環させるサービス コストを最小限に抑えることができます。 キャッシュについてはこれまでにたくさん書いてきました。 ここで и ここで.

さらに、Hazelcast でシリアライザーを Kryo に変更したことで、良い効果が得られました。 また、Hazelcast の ReplicatedMap から IMap + Near Cache への移行により、クラスター全体でのデータの移動を最小限に抑えることができました。 

ちょっとしたアドバイス: 大量のキャッシュが無効化された場合、XNUMX 番目のキャッシュをウォームアップしてからそれに切り替えるという戦術が適用できる場合があります。 このアプローチではメモリ消費量が XNUMX 倍になるように見えますが、実際には、これを実践したシステムではメモリ消費量が減少しました。

リアクティブスタック

私たちは非常に多くのシステムでリアクティブスタックを使用しています。 私たちの場合、これはコルーチンを備えた Webflux または Kotlin です。 リアクティブ スタックは、入出力操作が遅いと予想される場合に特に適しています。 たとえば、ファイル システムやストレージ システムを操作する低速サービスの呼び出しなどです。

最も重要な原則は、通話のブロックを避けることです。 リアクティブ フレームワークには、内部で実行される少数のライブ サービス スレッドがあります。 不注意で JDBC ドライバー呼び出しなどの直接ブロッキング呼び出しを行うことを許可すると、システムは単に停止してしまいます。 

エラーを独自のランタイム例外に変えてみてください。 プログラム実行の実際のフローはリアクティブなフレームワークに移行し、コードの実行は非線形になります。 その結果、スタック トレースを使用して問題を診断することは非常に困難になります。 そして、ここでの解決策は、すべてのエラーに対して明確で客観的な実行時例外を作成することです。

Elasticsearch

Elasticsearchを使用する場合は、未使用のデータを選択しないでください。 これも原則として非常に単純なアドバイスですが、ほとんどの場合、これは忘れられているものです。 一度に 10 件を超えるレコードを選択する必要がある場合は、スクロールを使用する必要があります。 たとえて言えば、リレーショナル データベースのカーソルに似ています。 

必要な場合を除き、ポストフィルターを使用しないでください。 メイン サンプルに大きなデータが含まれる場合、この操作によりデータベースに大きな負荷がかかります。 

該当する場合は一括操作を使用します。

API

API を設計するときは、送信データを最小限に抑えるための要件を含めます。 これは特にフロントに関連して当てはまります。このジャンクションで、私たちはデータセンターのチャネルを超えて、クライアントと私たちを接続するチャネルにすでに取り組んでいます。 少しでも問題がある場合、トラフィックが多すぎるとユーザー エクスペリエンスが低下します。

そして最後に、大量のデータを丸投げせず、消費者とサプライヤーの間の契約について明確にしてください。

組織変革

エロシュキナ・エレナ氏、IT担当副ディレクター

隔離措置が発生し、オンライン開発のペースを急激に上げ、オムニチャネル サービスを導入する必要性が生じたその時点で、私たちはすでに組織変革の過程にありました。 

当社の構造の一部は、製品アプローチの原則と実践に従って機能するように移されました。 現在、各製品の運用と開発を担当するチームが結成されています。 このようなチームの従業員は 100% 関与し、自分たちにとって望ましいものに応じてスクラムまたはカンバンを使用して仕事を構造化し、展開パイプラインの設定、技術的実践、品質保証実践などを実施します。

幸運なことに、当社の製品チームの大部分はオンラインおよびオムニチャネル サービスの分野に属していました。 これにより、効率を損なうことなく、可能な限り最短の時間 (文字通り XNUMX 日) でリモート作業モードに切り替えることができました。 カスタマイズされたプロセスにより、新しい作業条件に迅速に適応し、かなり高いペースで新機能を提供することができました。

さらに、オンライン ビジネスの最前線にいるチームを強化する必要もあります。 その瞬間、これを実現するには社内リソースを使用するしかないことが明らかになりました。 そして、50 週間で約 XNUMX 人が以前働いていたエリアを変え、新しい製品の開発に携わりました。 

これには特別な管理努力は必要ありませんでした。なぜなら、私たちは独自のプロセスの組織化、製品の技術的改善、品質保証の実践に加えて、チームに自己組織化、つまり管理リソースを関与させずに独自の生産プロセスを管理するよう指導しているからです。

クライアントにとって今何が重要なのか、最初に実装すべき機能は何か、スループット能力を高めるために何をする必要があるのか​​、ビジネスとの調整に、その瞬間に必要なところにまさに経営資源を集中させることができました。注文の配達と処理のため。 これらすべてと明確なロールモデルにより、この期間中、本当に重要で必要なものを生産価値の流れに組み込むことが可能になりました。 

リモートワークと急速な変化により、ビジネス指標が全員の参加に依存する場合、「すべて順調に進んでいますか? はい、良さそうですよ。」 生産プロセスの客観的な指標が必要です。 これらは私たちにあり、製品チームの指標に興味がある人は誰でも利用できます。 まず第一に、チーム自体、ビジネス、下請け業者、そして経営陣です。

10 週間に XNUMX 回、各チームで状況を把握し、XNUMX 分間メトリクスを分析し、生産プロセスのボトルネックを特定し、これらのボトルネックを解消するために何ができるかという共同ソリューションを開発します。 ここでは、特定された問題がチームの影響範囲外である場合、またはすでに同様の問題に遭遇している可能性がある同僚の専門知識の範囲外である場合に、すぐに経営陣に助けを求めることができます。

しかし、何倍にも加速するには (これがまさに私たちが設定した目標です)、私たちはまだ多くのことを学び、それを日々の業務に実践する必要があることを理解しています。 現在、私たちは製品へのアプローチを他のチームや新製品にも拡張し続けています。 これを行うには、方法論者のオンラインスクールという新しい形式を習得する必要がありました。

チームがプロセスを構築し、コミュニケーションを確立し、作業効率を向上させるのを支援する方法論者は、本質的に変化の主体です。 現在、最初のグループの卒業生はチームと協力し、チームの成功を支援しています。 

現在の状況は、おそらく私たち自身もまだ十分に気づいていない機会と展望を私たちにもたらしていると思います。 しかし、私たちが現在得ている経験と実践は、私たちが開発の正しい道を選択したことを裏付けており、将来的にこれらの新しい機会を逃すことはなく、スポーツマスターが直面するであろう課題にも同様に効果的に対応できるでしょう。

所見

この困難な時期に、私たちはソフトウェア開発の基礎となる主要原則を策定しました。これは、この問題に取り組むすべての企業に関係があると思います。

人。 これがすべての上に成り立っているのです。 従業員は仕事を楽しみ、会社の目標と自分が取り組んでいる製品の目標を理解する必要があります。 そしてもちろん、彼らは専門的に成長することができます。 

Технология。 企業は、自社のテクノロジースタックを活用する成熟したアプローチを採用し、本当に必要とされる能力を構築する必要があります。 それは非常に単純かつ明白に聞こえます。 そして無視されることが非常に多いです。

Процессы。 製品チームとコンピテンス センターの作業を適切に組織し、ビジネスとの対話を確立してパートナーとして協力することが重要です。

概して、それが私たちが生き残った方法です。 私たちの時代の主要な理論は、額に鳴り響くクリック音とともに再び確認されました

多くの店舗や多くの都市を拠点とする巨大なオフライン ビジネスであっても、オンライン ビジネスを開発してください。 これは単なる追加の販売チャネルや、何かを購入できる美しいアプリケーションではありません (また、競合他社にも美しいアプリケーションがあるためです)。 これは、嵐を乗り切るための緊急用のスペアタイヤではありません。

これは絶対に必要なものです。 それには、技術的能力とインフラストラクチャだけでなく、人材とプロセスも準備する必要があります。 結局のところ、追加のメモリやスペースを購入したり、新しいインスタンスをデプロイしたりすることは、数時間以内にすぐに行うことができます。 ただし、人やプロセスは事前にこれに備えておく必要があります。

出所： habr.com