内部からのLamoda：300人のエンジニアのオンラインストア

こんにちは、Habr！ 私の名前はバレンタインです。私はラモダのCTOで、会社の設立以来ほとんど働いています。 ここ数年、チーム全体が非常に速く前進したため、少し立ち止まって自分自身について話すことはできませんでした。 時が来たと思います。







ラモダはロシアのインターネットの先駆者の一人のように思えるかもしれませんが、私たちはまだ7歳です。 2011年の創業から現在まで、当社は11人の従業員から5000人以上に成長しました。 毎月、1,000万人を超える人々がこのサイトにアクセスしています。 実際、私たちは確立されたロシアのITの新興企業でした。その結果、このような短期間で、多くの名誉ある人たちに追いつくことができました。



私たちの最も有益で興味深い成果、失敗、経験、そして私たちのチームが毎日直面しているタスクについて少しお話していただければ幸いです。 この投稿を知り合いと考えます。



2011年には、コンテンツの準備と販売用の株式の購入のみを独自に開発し、その他はすべて外注しました。 今、私たちはすべて自分でやっています。 サッカー場ほどの大きさの5階建て倉庫、3つのコンタクトセンター、顧客への配送を監督しています。 ロシアには非常に高度なIT文化があるという事実にもかかわらず、大企業はそのようなインフラストラクチャの構築方法に没頭し始めたばかりであり、ラモダでは長年にわたってこの道を順調に進んでいます。



それでは、Lamodaのテクニカルバックステージは何でできているのでしょうか？ 実際、これらは5つの大きなユニットです。

• 開発部門（ビジネスプロセス自動化部門およびオンラインストア開発部門）
  
  
• ITサポート部門（インフラストラクチャおよびセキュリティ）
  
  
• ERPシステムの実装およびサポート部門
  
  
• サービスサポート部門
  
  
• データおよび分析部門
  
  

GOのすべて

このストーリーは、eコマースプラットフォームを開発している人たちに関するもので、自由時間にはモトを運転し、クラフトビールバーのガイド付きツアーに参加します。



プラットフォームがLamodaの顧客が日常的に使用するすべてを作成するのは、eコマース開発部門です：iOSおよびAndroid向けのサイトおよびアプリケーションのデスクトップバージョンとモバイルバージョンです。 作業の複雑さはユーザー向けの機能の実装ではなく、チームはできるだけ早く新しい機能を展開する必要がありますが、品質と安定性を損なうことなく、ロシア、カザフスタン、ウクライナ、ベラルーシの4カ国でプロジェクトをサポートします。 これまで、この部門の従業員は、必要に応じて毎週サービスを実行し、「Everything in GO」というモットーの下で仕事をすることができます。





チームは主にプラットフォーム（デスクトップ、モバイルサイト、モバイルアプリ）で分けられ、バックエンドサービスのチームも4つあります。 各チームには、フロントおよびバックの開発者、アナリスト、テスター、プロダクトマネージャーが含まれます。



できるだけ頻繁に変更を提供するために、開発の反復に対するこのアプローチを実践します。スプリントの開始時に仮説を提示し、本番環境で新機能をリリースし、それをテストします。これにより、イノベーションが製品にとって有益であるかどうか、およびLamodaユーザーの生活が良くなっているかどうかがわかります。 たとえば、少し前に、ある人が見た人が最近どれだけ購入されたかを示すことを学びました。 これを行うために、製品タスクを取り、MVPを見つけて、最速の実装戦略を決定しました。 本番環境ですべてを展開する前に、コンバージョンの増加が成功の基準になると判断しました。 A / Bテストの結果によると、この機能が導入されたグループではコンバージョンが高くなっています。



少し前に、Lamodaはマイクロサービスへの大規模かつ迅速な移行を開始しました。 これにより何が得られますか？ 1つ目は、別のチームの新しい開発者またはスペシャリストの低エントリーしきい値です。 2つ目は、マイクロサービスシステムの簡単なサポートと変更です。これにより、ワークフローが単なる痛みではなく、面白​​くなります。 しかし、少数のモノリス（たとえば、注文の配信を担当するシステム）がまだ私たちと一緒に住んでおり、それらを取り除くのは現在困難で不便です。

SMSと登録なしでLamodaをゼロから収集します

誰もが間違いなく仕事がないことを知っています。 毎回、問題を解決してコードを起動するたびに、ここでそれが幸福であり、再び経験がないことを願っています。 経験について言えば、eコマースプラットフォームの開発部門の従業員は、真のファイターのように、文字通りLamodaをゼロから組み立てることができるという事実に注目する価値があります。 誤ったネットワーク設定により、クラスターがクラスターではなくなったと判断し、存在を拒否しました。 夜になると幸運でしたが、4時間でラモダに命を吹き込むことができました。 他にも話があります。







電子商取引プラットフォームの開発責任者であるティムール・ヌルディノフ：



新しい機能の作業を開始する前に、いつものように、必要なリソースを評価しました。 4つのチームがプロジェクトに関与しました。 他のタスクの優先順位、同僚の休暇のスケジュール、人件費を考慮しました。 その結果、32週間になりました。



1つの機能を実装するのに8か月。 それはワイルドに聞こえます。 簡単な変更の助けを借りて、市場投入までの時間を4週間に短縮できました。



プラットフォームチームのコツは、前も後ろもできることです。 これが彼らが私たちの部門で働く方法です。 しかし、バックエンドでは、多くの統合システムに変更を加える必要があり、プラットフォームチームの能力がこれを許可していません。 クライアントに最も詳細な次元グリッドを提供することに関連するサイズプロジェクトを開始しましたが、待ちたくありませんでした。 最初に、どのシステムを変更する必要があるかを把握する必要がありました。次に、適切な能力を持つ小さなチームを編成しました。 そこで、他のプラットフォームチームからのリソースを待つためにブロックを削除し、製品チームを獲得しました。 タスクについては、独自の実証済みの方法で行動しました。大きなタスクを小さなタスクに分割し、それらを製品に展開し、ユーザーの仮説をテストして、正しい方向に進んでいるかどうかを理解しました。 製品チームの作成に関するこのような成功した実験の後、従業員が単一のユニットを形成し、配達などの特定の方向性を開発するエリアでチームを編成する予定です。

倉庫自動化と15分の配達間隔

自動化の担当者は退屈する時間がなく、ここでのタスクは簡単ではありません。 たとえば、同じ高レベルのコンテンツ品質（写真スタジオの自動化）で何百万もの商品をサイトにアップロードする方法、サイトからのすべての注文を処理して考慮する方法、数百のマーケットプレイスパートナーと4つのCIS諸国を考慮する方法、5階建ての倉庫で3時間で注文を収集する方法、翌日、ロシアの600の都市で、15分間隔でクライアントに配信する方法。 そして、デザートのために、彼らはこの農場全体をB2Bパートナーとマーケットプレイスの方向に販売しています。



作業は主にPHPで行われ、倉庫の自動化にはJavaに加えてDocker / Kubernetes、Atlassianスタック、PostgreSQL、RabbitMQを使用します。















私たちの部門では、スプリントプランニング用のバケットシステムが機能します。60％がプロジェクトバケット、20％が技術的負債、10％が優先バグに割り当てられ、10％が何かが確実に外部から飛ぶことです。 特に、バックロググルーミング、オンラインプランニングポーカー、スタンドアップ、レトロ、コードレビュー360、基本的なメトリックの収集と分析、モニタリング（プロメテウス、グラファナ、イシンガ、キバナ）、一般的に、すべてがパリの開発チームの最高の家のようです。



以下は、ビジネスプロセス自動化部門の責任者であるPavel Savelyevの面白い話です。



人々はあらゆるビジネスプロセスに何らかの形で参加するため、すべてをテストして考慮することは不可能です。 そして、あなたが知っているように、人々は合理的な生き物であり、常に彼らの生活を楽にするcなタッチを考え出そうとします。 しかし、これらの同じ概念が記述されたビジネスプロセスに反すると、面白い話が起こります。



倉庫に商品を配送するシステムは、通常よりも1分間に100倍のスキャンを受け取ることに気付きました。 倉庫のスタッフがハッキングシステムを見つけて、作業を促進することにしたことがわかりました。 昼食のために、スキャナーのボタンを締めて、ユーザーセッションから外れないようにしました。 このワークハックは引き続き機能しますが、トッツ（倉庫内の商品用の特別な箱）の1つには多くの小さなアイテムがありました。 スキャナーは、マキシムのマシンガンと同様に、不運な銃手からの商品を処理し、それにより負荷の急激な上昇、システムの不具合、および開発者からの明らかなバグの検出をもたらしました。 もちろん、バグを修正しましたが、倉庫のスタッフは退屈させず、新しいものを思い付くと思います。



2番目のケースも倉庫で発生しました。 この物語は「43 Fun T-Shirts」と呼ばれています。 特にバックパック問題を解決していて、特定のボリュームにN個のオブジェクトを最適に配置する必要がある場合（3次元パッキング問題）、アルゴリズムの複雑さをすぐに認識することは常に可能とは限りません。 43個の同一のTシャツが倉庫に到着すると、商品の梱包を担当するシステムがこのケースに対して非常に多くの配布の組み合わせを生成し、記憶に十分であることが判明しました。 アルゴリズムを確認したところ、同一のTシャツを恐れなくなりましたが、何百足もの靴下がパッケージに乗ると、メーカーは一度に1枚ずつ販売することにします。 検討する価値があります...

理解できない状況では、データに焦点を当てる

ラモダの分析に関する変化は長い間続いてきており、今年は異なる分析部門と分析インフラストラクチャと習慣を1つの大きな部門に統合し始めました。 なんで？ 主な理由は、異なる分析チームに所属する従業員は同じ仕事をしますが、方法が異なることが多く、どのデータに焦点を当てるかが明確ではないためです。 異なるデータ-これは通常、チームが異なるタスクと前提条件から来ているので正常ですが、それらを理解するには多くの時間を費やす必要があります。



部門の従業員は、会社のすべての決定がデータに基づいて行われなければならないという真の伝道者です。したがって、ここでは毎日、データのビジネス現象を熱心に研究し、データから価値を分析して抽出し、それらの適用方法を評価しています。 主なツールは、SQL、Spark、Hadoop、データ分析用のPython、Excel、レポート用のSAP BusinessObjects、視覚化用のTableauです。



チームの重要なタスクの1つは、カスタマーエクスペリエンスのパーソナライズです：各ユーザーに最も関連性の高い商品とオファーのリストが表示されるソリューションを作成し、すべてのサービスは現在行われているように、グループではなく個々のクライアントに個別に調整されます。



データ分析部長のセルゲイ・ギレフ：



分析部門は現在、2つの大きな課題に直面しています。1つ目は、合併前の多様な経済の統合です。 さらに効果的な作業を行うには、共通のメトリック、分析インフラストラクチャ、およびプロセスが必要です。 2番目の目標は、特定のプロセスまたは会社全体の「健全性」を記述する分析ダッシュボードを作成するプロジェクトです。 そのため、意思決定者のデータの可用性を大幅に向上させ、理解しにくい状況でデータに焦点を当てて作業するためのアプローチを全員に浸透させるよう努めています。

大きな動きのストーリー：顧客に気付かれずに独自の倉庫を立ち上げた方法

アウトソーシングの段階的な放棄は、私たち自身の倉庫を委託する時であるという事実に私たちを導いた。 新しい倉庫での運用プロセスを自動化するためのすべての準備に加えて、範囲を縮小せず、販売を停止しないという目標を設定しました。 当社の専門家は、追加の「仮想」倉庫の作成に基づいたソリューションを開発しました。 したがって、移転全体を通じて、3つのタイプの倉庫がありました。古い倉庫、新しい倉庫、途中の倉庫です。 商品はトラックグループによって徐々に輸送されたため、次のバッチで最終的に在庫が「仮想」倉庫に転送されました。 荷積みと荷降ろしのスケジュールがあったので、在庫がどのくらいの期間輸送されているかを正確に把握し、顧客は注文の正しい納期に向いていました。



また、移動速度のバランスを取り、1回の配達で注文のすべての商品の受領を整理できるようにするトリッキーなアルゴリズムを考案し、実装しました：人が物理的に異なる倉庫にある可能性のある複数の商品を注文したとき、1つの倉庫で注文の完全なアセンブリを整理しようとしました、また、組み立てプロセスはすでにデバッグされているため、パートナーの倉庫に利点が与えられました。



自社倉庫の立ち上げ作業は3か月間全面的に行われ、その間、クライアントは負傷しませんでした。

ブラックフライデーの準備、または買い物中毒の時代の生き残り

数年前、私たちはブラックフライデーが恐ろしいモンスターであるのを恐れていました。 このような注文の流れにシステムがどのように対応するかはわかりませんでした。 しかし、リファクタリングとインフラストラクチャ開発に関する絶え間ない作業により、システムが安定し、可能な限り予測可能になりました。 最後のブラックフライデーは、その年の最も退屈な日でした。 主要システムとDevOpsのスペシャリストがテーブルに座って、ビデオゲームをプレイしたり、映画を見たり、インフラストラクチャの状態を片目で見たりしました。 しかし、この日の準備は少し異なります。



ビジネス予測に基づいてストレステストをスケジュールし、開発者と管理者の両方がテストに合格するようにシステムを構成します。 数ヶ月のテスト、クラッシュ、修正、そしてその後のみ、私たちはユーザーと注文の波の準備ができていると信じています。









戦争室-ブラックフライデーのオペレーションセンター



ブラックフライデーを乗り切るために私たちが下す決定は、テスト中に遭遇するボトルネックに依存します。 数年前、ネットワークスイッチを物理的に交換して、帯域幅の問題を解消しました。 負荷を減らすために通常実行する別のアクションは、重要ではないサブシステムを無効にすることです。

まとめ

ここ数年、私たちは常にワークフローの改善と簡素化を試み、会社の従業員からフィードバックを収集し、ボトムアップチャネルを確立し、新鮮なアイデアと概念を完全にサポートしています。



ラモダは技術とシステムの絶対的な動物園だと誰かが言うでしょう。 私たちはしばしばこのトピックについて自分自身を冗談で言い、「私たちが使わないものを尋ねる方が良い」と言います。 しかし、この問題において、本質的な事実は、私たちが常にスタックとテクノロジーを進化させており、同時に、考え抜かれた選択肢がないということです。 これは、各新しいサービスとプロジェクトのアーキテクチャのレビュー、従業員の既存の専門知識へのガイド、およびTechnology Radarのメンテナンスに役立ちます。詳細と引数については、次の投稿でお知らせします。 また、このテーマで祝うことも嬉しく思います。