こんにちは、Habr。 多くの人が私たちのサービスについて聞いたことがあり、誰かがそれを使用しましたが、今では社内のITキッチンについて話す前に熟しています。 2014年に、Arbatのオフィスアパートメント（キッチンに会議室があります）、300人のクライアントから始まり、すべてを手で整理しました。 すべての情報はExcelで記録され、開発は臭いがしませんでした。 時間が経つにつれて、顧客の数が増え、自動化が必要になりました。今日、Qleanは開発部門に25人以上の従業員を抱える成熟した企業です。 今日、当社のサービスを通じて、3000人の接続されたパフォーマーによって1日平均約1000回のクリーニングが行われています。 私たちは、クリーニング量の面で外国のハンディとヘルプリングに次ぐ世界で3番目であり、モスクワ、サンクトペテルブルク、エカテリンブルクで働いています。 この投稿では、サービスシステムのツアーを実施し、さらにブログのトピックを発表します。
技術とその実装方法
プログラミング言語にこだわることはありませんが、歴史的には、このサービスはコーヒースクリプトやその他の驚異を備えたRuby on Railsで構築されていることが判明しました。 残っているのはapiとrailだけです-ActiveRecordと標準gemのセット。 メンテナンスしやすいシンプルで理解しやすいコードを作成しようとするため、TrailBlazerは実際には流行していません。 メインアプリケーションに加えて、CRM用の純粋なRubyマイクロサービス、雇用システム、Goのいくつかのサービス、Clojureのカップルがあります。 DDDの原則に従ってサービスを共有しようとします。つまり、各サービスはビジネスプロセス（雇用、注文の支払い、アーティストの指名など）に責任を負います。 特定のタスクと要件に基づいて言語を選択します。 フロントエンド全体がReact + Reduxにあり、モバイルアプリケーションが最近React.Nativeに完全に書き直されました。これにより、コードの記述が減り、同じ機能を異なるプラットフォーム（サイトとモバイルアプリケーションの両方）に実装できるようになります。開発者。 ネイティブアプリケーションをReact.Nativeに変換することの利点と困難さについて説明します。
合計で、70を超える仮想マシンに存在する約30の異なるサービスがあるため、コードレイアウトは最も単純ではありません。Ansible、Docker、およびNomadをオーケストラとして使用します。 レイアウトするとき、膨大な数のテスト（ユニットと統合の両方）が実行され、さらにQAエンジニアの助けを借りてすべてをチェックします。複雑なタスクにはカナリアデプロイを使用するため、頻繁に拡散することを恐れません。 週に平均15件のリリースがあります。
さらに詳細に？
システムは、クライアント、請負業者との連携、請負業者による注文の配信という3つの大きな機能部分で構成されています。
カスタマーサービス
顧客と通信するために、Webサイトとモバイルアプリケーションがあります。 ここでは、原則として、マーケティング、マーケティング、マーケティングのすべてがほぼ標準です。 1つの大きなニュアンスについては、分析に目を向けているため、ユーザーが実行するすべてのアクションを追跡および分析します。 すべてのデバイスから、イベントがGoマイクロサービスに送信されます。Goマイクロサービスは、情報を処理してデータベースに保存します。 すべてを測定するのが大好きなので、実験とA / Bテストの非常に発達した文化があります。 最初に仮説をテストします。クレジットカードのデータ入力フォームのような小さなものから始まり、罰金とサブスクリプションのモデルで終わる、最大5つの異なる実装を同じ機能のメカニズムで同時に実行できます。 各実験には、分析システムに独自のダッシュボード（Periscopeを使用）と比較するメトリックがあります。 常にコントロールグループがあり、実験が「クリーン」であること、つまりユーザーグループが可能な限り同一であることを確認します。 分析とA / Bテストについては個別に説明します。
クライナーを使用する
すべてのサービスはパフォーマーに基づいています。 私たちの場合、パフォーマーは顧客のアパートに来るので、彼らの品質とプロ意識は非常に重要です。 クライアントになる前に、面接、セキュリティチェック、指示、規制の知識のテスト、在庫の発行など、いくつかの手順を経る必要があります。 最近まで、これらの手順はすべて完全にオフラインで行われていたため、他の地域でのサービスの開始には制限が課されていました。倉庫が必要で、オフィスが必要で、コールセンターが必要です。 現在、完全に自動化された採用および供給システムを実験しています。 雇用に問題がなければ、供給にはまだ長い道のりがあります。クライアントの在庫を自動的に制御する方法はまだわかりません。 いずれにせよ、私たちの主な懸念はまだ正当化されていません。リモート採用システムは、パフォーマーとサービスの質に影響しません。 したがって、この方向でさらに発展していきます。
クライナーがランクを補充した後でも、すべての注文がすぐに利用できるわけではありません。 私たちはそれを注文に慎重に運び、仕事の質を助け、管理します。そして時間の経過とともに、すべての注文が彼に利用可能になります。 これを行うために、基本的に利用可能な注文の個々のリストを形成する注文可視性マトリックスがあります。
注文の分配
一般に、私たちの主な課題は注文の分配に関係しています。 システムを介して動作するクライアントの主な動機は、安定した収益と注文の保証されたフローです。 すべてが単純なようです。クリーナーを指名して転送し、モップを振らせます。 実際、昼食後の水曜日にのみ掃除の準備ができている人、猫やバルコニーが嫌いな人、ブトボの3ルーブル紙幣のみを掃除したい人がいます。 クライアントにも好みがありますが、性質は異なります。異なるクリーナーの数を最小限に抑える必要があります。理想的には、ベッドリネンが年に50人の見知らぬ人に触れるような人はほとんどいないため、2〜3人のクライアントが10回注文する必要があります システムはこれらすべての設定を考慮に入れ、最良の一致に従って注文を選択する必要があることがわかります。 予定の古典的なタスクのように見えますが 、請負業者は自分が好まなかった割り当てられた注文を拒否できるため、タスクは自明ではなくなります。 また、クライアントが注文を突然転送またはキャンセルできると考えると、アルゴリズムの速度に関する非常に厳しい要件が発生します。 注文がキャンセルされる確率、クライアントが特定の注文に到達する可能性を予測する複雑なモデルを使用し、以前の注文の履歴に同意する可能性が最も高いクライアントの注文を自動的に選択します。 次の記事では、このトピックについて明らかにします。
いずれにせよ、予約後、一定数の組み立てられていない注文が残り、それらはアプリケーションを通じてクリナー自身によって分解されます。 現在、特定の注文の拒否数に応じて、オークションと動的価格でモデルをテストしています。 手動で収集した後、組み立てられていない注文がすでに少数あります。 注文の1日前に、当社のコールセンターが手動で最適なパフォーマーを呼び出し、クライアントが臨床医なしで留まらないようにします。 時々アーティストがまったく見つからないこともあります（主に転送が遅いため）が、このパラメーターを最小化するために取り組んでいます（現在、1日に最大5件の注文がエグゼキューターなしで残っています）。
実際、システムにはさらに多くの詳細があります。CRMを所有し、ウェアハウスを操作しますが、短いレビュー記事にはすでに多くの情報があります。
ご質問にお答えします。
Habrユーザー向けの最初のクリーニングプロモーションコード： habr
Github