Redmine用の電報ボット。 自分と人々の生活を簡素化する方法

プロジェクトとタスク管理システムを使用している会社では、遅かれ早かれ、それをコミュニケーションを簡素化するために人気のあるメッセンジャーと組み合わせることが望まれます。 特に、このシステムを介して顧客とのやり取りがある場合。



この記事では、RedmineをTelegramとフレンドにし、既存のビジネスプロセスを壊さない方法を説明します。











主題のアイデアがどのように生まれたのかについての少しの背景。



当社は、24時間年中無休のサーバーとサイトの管理、大規模で成長中のインターネットプロジェクトのインフラストラクチャの開発、フォールトトレラントシステムの設計、DevOpsの自動化に従事しています。



顧客とやり取りするために、私たちはRedmineを使用します。Redmineはプロセスに合わせて調整されており、私たちの生活を楽にする多くの楽しいものにかかっています。



開始したばかりの2011年でしたが、タスクトラッカーを介してのみ顧客と通信することにしました。 これは、サーバーのサポートとインシデントへの対応に加えて、ほとんどの作業がインフラストラクチャ開発タスクで構成されているという事実によるものです。 インフラストラクチャの現在の状態、プロジェクト開発のベクトルを十分に理解し、ニーズとボトルネックを正しく評価し、ソリューションを提案し、それらを調整し、実装することがいつでも重要です。 問題は複雑です。多くのプロジェクトがあり、それぞれに作業しているのは1人ではなく、管理者のチームです。 同時に、管理者は交代で働いており、一部の管理者はオフィス内で常に相互に交差しているとは限らないため、タスクを実行する必要があります。 したがって、チーム内およびシフト間で知識と行動を同期させるという問題は、私たちにとって非常に重要です。



これらすべての要因を考慮して、状況を制御し続けるための唯一の可能な方法は、すべての通信とすべての作業がタスクシステム内で1か所で行われるようにすることであると判断しました。 当然、プロジェクトwikiを実行し、アクションとコンテキストの同期の問題を解決するためにさらに多くのことを行いますが、キーポイントは常に顧客との対話の単一ポイントでした。 たとえば、インスタントメッセンジャーなどの別のチャネルをコミュニケーションに追加すると、いくつかの問題をすばやく話し合うと、顧客の100％がそれを悪用し始め、無限のコメントの深inにすぐにdrれ、重要な情報が失われ始めます。 はい。管理者は、Redmineでレイアウトされ、明確なビジネスプロセスのためにレイアウトされたタスクに対して、5つの異なるウィンドウで顧客と混chaとしたコミュニケーションを行う可能性はあまり魅力的ではありませんでした。



その結果、私たちは約5年間そのように暮らしましたが、この間、多くのお客様がRedmineのシンプルさと機能性を気に入ってくれました。 彼と一緒に仕事をした誰かが彼の会社でそれを紹介することにしました。 個々のクライアントは、タスクのシステムだけでなく、何らかのメッセンジャーでもタスクを設定できるかどうかをたまにしか尋ねませんでした。



しかし、過去2年間で、このようなリクエストの数は大幅に増加しています。 そのため、それらを考慮しないことは不可能でした。 そして、これをどうするかについて考えました。 営業マネージャーは、いつものように、Skype、WhatsApp、またはTelegramを介した顧客とのコミュニケーションを作業プロセスに統合するために、奇跡的な方法でアイデアをプッシュしようとしました。 管理者はこれをまったく望んでいませんでした。



激しい議論と議論の後、すべてのクライアントメッセージをRedmineの既存のタスクに配置したり、管理者が通常の環境で作業する新しいタスクを作成したりできるTelegramボットを開発するというアイデアがありました。



彼らは小さな計画をまとめました-最初は最小限の機能で、それから楽しい些細なこと。 しばらくして、未来のボットのプロトタイプを入手しました。これは、TelegramからRedmineへ、またはその逆のメッセージを正常に配信しました。 これは、アイデアが実行可能であるという自信を与えました。 そして、私たちはそれを終わらせて立ち上げるためにあらゆる努力をしました。



これがどのように機能するかをよりよく説明するために、この記事は2つのブロックに分かれています。 最初のブロックには、ボットの一般的な説明とその操作例が含まれています。 第二に-ボットのデバイスと技術的側面。



記事の最後には、ボットをダウンロードする場所と設定方法のリンクがあります。



それで、私たちは何を得ましたか？

ユーザー認証

まず、ユーザーがボットを操作できるようにするには、ボットを認証する必要があります。

これを行うには、ユーザーはアクティブなRedmineアカウントを持っている必要があります。



彼はユーザー名を考え出し、Telegramアカウントの設定に登録する必要があります。







Redmineアカウントの設定の特別な追加フィールド「Telegram」に同じユーザー名を入力する必要があります。







次に、ユーザーはTelegramでボットを見つけ、[開始]をクリックします。 ボットはそれを許可し、歓迎します：

タスク設定

新しいタスクをポーズしたり、既存のタスクにコメントを追加したりするには、ボットにテキストを書くだけでオプションが提供されます。 同時に、メッセージにファイルを添付できます。







書かれたコメントを最後のアクティブなタスクに追加したり、リストからタスクを選択したり、それに基づいて新しいタスクを作成したり、何もせずにダイアログを終了したりできます。



「最後のタスクに追加」項目を選択すると、ユーザーのコメントが最後の通信が行われたタスクに追加されます。 ボットはそれを上に示しています。



「新しいタスクを作成する」を選択すると、ボットは新しいタスクを作成するモードに切り替わります。







ユーザーにプロンプ​​トを表示します：

• プロジェクトを選択します（デフォルト、デフォルトを調整しなかった場合）。

• タスクの優先度を指定します（デフォルトが機能しない場合はオプション）：

ユーザーは、デフォルト値に満足している場合はこれらの手順をスキップし、すぐに「タスクの作成」をクリックします。タイトルを指定するだけです。







その後、ボットはクライアントにタスクの作成について通知します（タスクへのリンクはクリック可能で、必要に応じてすぐにチケットにアクセスできます）。







Redmineでは次のようになります。







ユーザーが「タスクの選択」をクリックすると、ボットは現在開いているタスクのリストを提供し、そこにコメントを送信できます。







この場合、ユーザーにはRedmineで接続しているプロジェクトとタスクのみが表示されます。 これは、ボット内のすべてのアクションに適用されます。

タスクに関する対応

ボットは、タスクの変更の通知の配信をサポートしています。 たとえば、管理者はタスクを完了し、クライアントに結果を確認するように依頼します。







クライアントが受け取るものは次のとおりです。







Telegramの対応するメッセージに返信することで、タスクに回答できます。 これは、複数のタスクを同時に処理している場合に特に便利です（追加の質問なしで、すぐに回答が目的のチケットに移動します）。







結果。 クライアントはタスクを作成し、その上で通信し、これらすべてをTelegramで行いました。 彼はこれのためにRedmineに行く必要がなかった。 従業員はRedmineで通常の方法でタスクを受け取り、処理しました。標準的なビジネスプロセスの一部として、メッセンジャーに切り替えてから、連絡先をタスクシステムに転送する必要はありませんでした。

添付ファイルのサポート

ボットでは、添付ファイルのサポートを実装しました。 そして、それは両方の方法で機能します。 写真、ドキュメント、ビデオ、オーディオなど、好きなものを添付できます。 ステッカーを添付することもできますが、ブラウザではあまり見かけませんが、残念なことに、場合によっては完全に選択されたステッカーがオフィス全体の寿命を延ばします。



監視システムから、サーバーの1つに問題があると通知されたとします。 管理者はRedmineを介してタスクを作成し、監視システムのグラフをそれに添付しました。 クライアントは次のメッセージを受け取ります。







彼は音声メッセージで応答できます：







音声メッセージはタスクに配信され、管理者によって聞かれます。

制限事項

もちろんそうです。 以下に遭遇しました：

1. 長い投稿。 テレグラムでは、1つのメッセージの長さに制限があります-4096文字。 当初、Redmineからの長いコメントはクリップされていました。 長いコメントをバラバラにするハンドラーを作成する必要がありました。 そして、それは目を楽しませた、つまり、コメントが単語の中央の4096文字で厳密に分割されず、分割がフレーズの接合部できれいに行われたということです。 顧客にとっては、この場合、いくつかのメッセージが来るという不便さがあります。
2. 書式設定 RedmineとTelegramのフォーマットは、2つの異なるユニバースです。 しかし、それは理解可能であり、その目的は多少異なります。 Redmineの書式設定はTelegramでサービスキャラクターとして表示され、読みにくい場合があります。 これまでのところ、それらを通常の形で表示する方法を理解していませんが、この迷惑を排除する希望は残していません。 すべてがTelegramからRedmineに転送されるわけでもありません。 たとえば、テキストに特定の絵文字が含まれている場合、Redmineがそのようなメッセージを受信すると、それがカットされます。 これらは、Redmineデータベース構造の機能です。 この問題を解決するためのいくつかのヒントがあり、それらはテストベンチで正しく動作しますが、これまでのところ、戦闘ベースでそれらを使用することを恐れています。
3. 画像の名前。 画像の添付ファイル（つまり、画像）をTelegramに添付すると、ボットはfile_xyz.jpg形式の名前のファイルを受け取ります。 したがって、Redmineではその名前で取得します。 ボット自体がこれらの名前のファイルを受信するため、ここではまだ何もできません。
4. これまでのインターフェースとすべてのボットメッセージはロシア語のみですが、次のバージョンの1つでは他の言語のサポートを追加する予定です。

利用統計

発売から2か月を少し過ぎました。 最初の観察：

1. 現在、タスクの約3.5％がクライアントによってボットを介して作成および更新されています。
2. 前述のように、ボットは顧客だけでなくアプリケーションによっても積極的に使用されています。 タスクに関する通知を受け取り（メールよりも早く到着する）、すぐに応答するのは非常に便利です。 ボットの起動により、内部タスクの通信速度が向上したように感じます。

ボットの仕組みについて簡単に説明します

• Cで記述されています。より正確には、Cで記述されたフレームワークで
• RedisとMySQLの2種類のデータベースを使用します
• Redmineのプラグインを作成する必要がありました。これは、タスクとコメントを作成するときにフックメカニズムをアクティブにします
• 簡単に複製およびスケーリングできます。

それでは、始めましょう...



ボットの概略図は次のとおりです。







Redmineのすべての変更はフックを使用してボットに配信され、プロジェクトが発生したイベントのタイプを調べ、このメッセージの受信者のTelegramアカウントを決定して配信します。 Telegramの側から見ると、すべてが同様の方法で発生します。メッセージのタイプ、Redmineに関連して配信されるタスクが決定されます。



それでは、少しアクションを追加して、Telegramでのメッセージ配信のいくつかの機能を理解しましょう。



Telegramは、大きなメッセージをいくつかの小さなメッセージに分割します。 これらのメッセージには多少の遅延が伴います。 すべての添付ファイルは個別のメッセージとして配信され、場合によっては（ユーザーがダウンロードする際に）長い遅延が発生します。 すなわち 受信したすべてのメッセージを受け取って転送することはできません。そうしないと、ユーザーをスパムしてカルマを台無しにします。



そして何をすべきか？ このためにメッセージキューを作成し、Redisを使用して保存することにしました。 ボットは、各着信メッセージをキューに入れ、その処理の遅延時間を更新します。 この遅延の期限が切れると、メッセージは完全に形成されたと考えられ、タスクを選択してRedmineに送信できるようになりました。



その後、Redmineで適切なタスクを選択する方法が問題になります。 実際、ボットが受信したデータをどう処理するかを理解するには、ユーザーにそれについて尋ねる必要があり、これはとにかく別のメッセージであり（ボタンのクリックであっても）、ユーザーの以前のアクションに何らかの形で接続する必要があります。 このセッションは役に立ちます。



ユーザーのテレグラムアカウントから受信した最初のメッセージ-次を含むセッションを生成します。

• セッションに関連付けられたユーザーID
• セッションのタイプ（つまり、状態）
• 何かをするためのデータ

Telegramから受信した後続の各メッセージは、セッションをデータで補完するか、その状態を変更する（たとえば、データのさらなる処理と配信のプロセスを開始する）か、セッションを破棄する（たとえば、ユーザーがコメントを書くように気を変えた場合）か、エラーにつながる（たとえば、受信したデータのタイプは、セッションの現在の状態に対応していません）。



ボットのもう1つの重要な要素はキャッシュです。 Redmineは、かなり多数のプロジェクト、ユーザー、その他のデータで構成されています。 ボットはしばしばこのデータにアクセスする必要があり、Redmineで毎回それらに従うと、リクエストの処理に顕著な遅延が発生します。

ボットには、Redmineから残りのプロセスに必要なデータを定期的に取得し、Redisに保存することのみに関係する別のプロセスがあります。



MySQLはどうですか？



Redisに加えて、ボットもMySQLを使用することに注意してください。 もちろん、すべてのデータはRedisに保存できますが、定期的なダンプが存在するにもかかわらず、データはまだメモリに保存されており、システムの予期しないクラッシュによってデータが失われる可能性があります。その中には、特に注意が必要な非常に重要な情報があります。 危機にwhatしているものをよりよく理解するために、記事の最初の部分を思い出してください。 ユーザーは、ボットとの対話からメッセージをどう処理するか（新しいタスクを作成するか、既存のタスクを選択する）だけでなく、メッセージに応答することもできると述べました。 ボットは、追加する必要があるタスクを理解する必要があります。



Telegramでは、メッセージにはRedmineのタスク識別子とは関係のない識別子があります。 それらを友達にするには、何らかの通信を確立し、このデータを保存する方法を決定する必要があります。 しかし、その前に、このデータがどのように形成されるのか、このデータが失われた場合に何が起こるのか、そしてこれに基づいて、その重要性を理解しようとします。



ユーザーが最初のメッセージを電報ボットに書き込むとします。 ボットはセッションを開き、ユーザーからコメントを追加する必要があるタスクを見つけます。 回答を受け取った後、ボットはデータをRedmineに送信すると同時に、この通信を自宅で保存します。



さらに、ユーザーがテレグラムでこのメッセージに返信すると、ボットは「親」メッセージの番号を受け取り、コメントの送信先のRedmineタスクの番号を決定します。 説明された対応は、この新しいメッセージに対しても確立されます。 その後、返信を行うことができます。 Redmineからのイベントについても同様です。 クライアントは、これが非常に便利なメカニズムであると考えており、統計から判断すると、非常に積極的に使用しています。



ここで、これらすべての通信が失われたと想像してみましょう。 すなわち クライアントは、習慣として、管理者から送られたメッセージへの返信をクリックし、コメントを書いてボットに送信します。 しかし、以来 説明されたアルゴリズムによるボットは、コメントを送信するタスクを理解できなくなり、エラーメッセージが表示され、次に何をすべきかを見つけるために追加の質問が行われます。



失われない他の重要なタイプのデータ（および最初のデータよりも多く失われることはありません）は、RedmineとTelegramのユーザーIDの対応です。 これが発生した場合、ユーザーはボットに何かを書き込むまで、Redmineで発生するイベントに関する情報の受信を停止します。 そして以来 世論調査によると、ボットは（メールを置換するための）通知者として使用されることが多く、ここでさらに問題が発生する可能性があります。



ユーザーを混乱させないために、このデータをより高速で信頼性の高いMySQLに配置します。



公平に言うと、MySQLを放棄してこのデータをRedisに転送するかどうかについて、私たちのチームがまだ議論していることは注目に値します。 そのため、将来的には、Redisの使用に完全に切り替えられる可能性があり、場合によっては他のストレージシステムに切り替えることもできます。 幸いなことに、アプリケーションのアーキテクチャにより、このような置換は比較的簡単になります。

スケーリングとフォールトトレランス

次に、ボットのスケーリングとフォールトトレランスを確保する方法についてお話したいと思います...



ボットの出現により、私たちのRedmineは場合によってはチャットに変わり、メッセージングの強度は絶えず増大しています。 一部のお客様は、インフラストラクチャに統合することも望んでいます。 そして、私たちの開発は完全にオープンソースであるという事実を考えると、管理者/開発者の他の会社やチームがそれをどのように使用したいかは不明であり、ボットが何に遭遇するかは不明です。 したがって、プロジェクト開発の段階でさえ、その中にスケーリングの可能性を見出しました。



このプロジェクトでは、スケーリングを2つのクラスに分けることができます。

• データベースのスケーリング
  
  ここではすべてが十分に知られています：
  
  
  
  
  • MySQLの場合、Percona Clusterまたは同等のものを使用できます。
  • Redisの場合-Redisクラスター
• ボット自体のスケーリング

ボットのスケーリング方法を理解するために、メッセージを受信および処理するプロセスを詳しく見てみましょう。



回路図は次のとおりです。







「REST API」プロセスの唯一のタスクは、RedmineまたはTelegramから受信したメッセージをra-queueに入れ、次を待つことです。 このキューは、キューワーカープロセスによって常に監視されており、キューにデータが表示されると読み取られます。



Redmineからのメッセージはすぐに処理され、Telegramの適切なユーザーに送信されます。 Telegramからのイベントでは、すべてがより複雑です。なぜならすぐにRedmineに送信することはできません（その理由は上記のとおりです）。その後、ユーザーによって既に分割されている別のキューに転送されます。メッセージのタイプは、他のメッセージを待つ時間を決定します。遅かれ早かれ、これらのメッセージはすべて読み取られ、準備が行われ、何らかの形でセッションの状態が変更され、同じステップでTelegramからダウンロードされたすべての添付ファイルとともにRedmineに送信できます。



このアプローチと既存のロックメカニズムのおかげで、処理は常に1つの特定のノードで行われることに注意することが重要です。これにより、既存の負荷内で必要な数のQueue-workersプロセスでボットインスタンスを作成できます。



Redmineがメッセージを受信すると、フックがトリガーされ、同じメッセージがボットに返送された後、タスクにサブスクライブしている残りのTelegramアカウントに配信されます。



したがって、分散バージョンのボットのインフラストラクチャは次のように表すことができます。







しかし、説明したすべてが、1つのMySQLサーバーとRedisの通常の非クラスターバージョンを備えた通常のスタンドアロンバージョンでボットを使用する機能を制限するわけではありません。

ボットを試す方法は？

ボットの動作を実証するために、デモ版を作成しました。デモ版はdemo.nxs-chat.nixys.ruから入手できます。



実際に試してみるには、いくつかの準備手順に従う必要があります。

• でdemo.nxs-chat.nixys.ru/account/registerレジスタ少なくとも2アカウント（それらの間に対応することができるようにする）とで充填電報それらの少なくともいずれかの
• 作成したアカウントをアクティブ化する
• 登録中に指定された各Telegramアカウントの@nixys_demo_chat_botボットを見つけて、[ スタート ]ボタンをクリックします。demo.nxs-chat.nixys.ruの
  
  アカウント設定と同じユーザー名がTelegramアカウントの設定に設定されていることを確認してください
• Redmineでプロジェクトを作成し、作成したアカウントを「プロジェクトメンバー」の役割で追加します
• 作成されたプロジェクトで、タスクを追加してコミュニケーションを開始してください！

重要なお知らせ！ボットは、次の場合にメッセージをTelegramに送信します。

• タスクの作成者であるアカウント（特定のコメントの作成者ではない場合）
• タスクの実行者であるアカウント（これが特定のコメントの作成者ではない場合）
• タスクのオブザーバーのリストにあるアカウント（これが特定のコメントの作成者ではない場合）

ボットを取得する方法は？

ボットは完全にオープンであり、ソースコードの形式とパッケージの両方で入手できます（パッケージは現在Debian 8でのみ利用可能ですが、近い将来Debian 9およびCentOS 7で利用可能になる予定です）。ボットソースコードを使用



してGithubリポジトリにリンクします。パッケージからボットをインストールしてセットアップするための指示もあります。

おわりに

近い将来、次の機能を追加する予定です。

• タスク作成を簡素化する
• 通知を設定する
• 多言語インターフェース
• ( Redmine)
• , ,