私たちは自分自身を確認します: 1C がどのように導入され、どのように管理されているか: 1C 社内の文書の流れ

1C では、社内の仕事を整理するために独自の開発を広く使用しています。 特に、 「1C:ドキュメントフロー8」。 (名前が示すように) 文書管理に加えて、最新の機能も備えています。 ECM- メール、従業員の勤務カレンダー、リソースへの共有アクセスの整理 (会議室の予約など)、時間追跡、企業フォーラムなど、幅広い機能を備えたシステム (エンタープライズ コンテンツ管理 - 企業コンテンツ管理)。

1C では 11 人以上の従業員が文書管理を使用しています。 データベースはすでに膨大なものになっています (XNUMX 億件のレコード)。これは、より慎重な管理とより強力な機器が必要であることを意味します。

私たちのシステムがどのように機能するか、データベースを維持するときにどのような問題が発生するか、そしてそれらをどのように解決するか (DBMS として MS SQL Server を使用します) - 記事で説明します。

初めて 1C 製品について読む方へ。
1C:Document Flowは、業務アプリケーションを開発するためのフレームワークである1C:Enterpriseプラットフォームをベースに実装されたアプリケーションソリューション（構成）です。

「1C: Document Flow 8」（DO と略称）を使用すると、企業内のドキュメントの操作を自動化できます。 従業員とのやり取りのための主なツールの XNUMX つは電子メールです。 メールに加えて、DO は他の問題も解決します。

• 時間追跡
• 従業員の欠勤追跡
• 宅配便・運送業の申し込み
• 従業員の勤務カレンダー
• 通信の登録
• 従業員の連絡先 (アドレス帳)
• 企業フォーラム
• 部屋の予約
• イベント企画
• CRM
• ファイルの共同作業 (ファイル バージョンの保存)
• ら。

文書管理に入ります シン・クライアント (ネイティブ実行可能アプリケーション) Windows、Linux、macOS、 ウェブクライアント （ブラウザから）そして モバイルクライアント - 状況に応じて。

そして、Document Flow に接続された他の製品のおかげで、 インタラクションシステム – ドキュメント フローでは、メッセンジャーの機能を直接受け取ります – チャット、音声およびビデオ通話 (モバイル クライアントからのものも含め、現在特に重要になっているグループ通話を含む)、高速ファイル交換に加えて、チャット ボットを作成する機能を簡素化します。システムを使って作業します。 インタラクション システムを使用するもう XNUMX つの利点は (他のメッセンジャーと比較して)、特定のドキュメント フロー オブジェクト (ドキュメント、イベントなど) に関連付けられたコンテキストに応じたディスカッションを実行できることです。 つまり、インタラクション システムはターゲット アプリケーションと深く統合されており、単なる「別個のボタン」としては機能しません。

DO の文字数はすでに 100 億を超えており、DBMS には一般に 11 億を超えるレコードがあります。 合計で、システムはほぼ 30 TB のストレージを使用します。データベース ボリュームは 7,5 TB、集合作業用のファイルは個別に保存され、さらに 21 TB を占有します。

より具体的な数字について言えば、現時点での文字数とファイル数は次のとおりです。

• 送信メール – 14,7 万件。
• 受信手紙 – 85,4 万通。
• ファイルのバージョン – 70,8 万。
• 内部文書 – 30,6千件。

DO にはメールやファイルだけではありません。 その他の会計オブジェクトの数値は以下のとおりです。

• 会議室の予約 – 52
• 週次レポート – 153
• 日次レポート – 628
• 承認ビザ – 11
• 受信ドキュメント – 79
• 送信ドキュメント – 28
• ユーザーの仕事カレンダーのイベントに関するエントリ – 168
• 宅配便の申し込み – 21件
• 取引相手 – 81
• 取引相手との作業記録 – 45
• 取引相手の連絡先担当者 - 41
• イベント – 10
• プロジェクト – 6
• 従業員のタスク – 245
• フォーラムの投稿 – 26
• チャットメッセージ – 891 095
• ビジネス プロセス - 109。従業員間のやり取りは、承認、実行、レビュー、登録、署名などのプロセスを通じて発生します。 プロセスの期間、サイクル数、参加者数、返品数、期限変更リクエストの数を測定します。 そして、この情報は、企業内でどのようなプロセスが行われているかを理解し、従業員のコラボレーションの効率を高めるために分析するのに非常に役立ちます。

これらすべてをどのような装置で処理するのでしょうか?

これらの数字は、膨大な量のタスクを示しているため、社内子会社のニーズに合わせてかなり生産性の高い設備を割り当てる必要に直面しました。 現在、その特徴は次のとおりです: 38 コア、240 GB の RAM、26 TB のディスク。 サーバーの表は次のとおりです。


今後、設備の容量を増やしていく予定です。

サーバーの負荷はどうなっていますか?

ネットワーク活動が当社やお客様にとって問題になったことは一度もありません。 メモリ不足に対処する方法は誰もがすでに知っているため、原則として、弱点はプロセッサとディスクです。 以下はリソース モニターからのサーバーのスクリーンショットです。ひどい負荷はなく、非常に控えめであることがわかります。

たとえば、以下のスクリーンショットでは、CPU 負荷が 23% である SQL サーバーが示されています。 これは非常に優れた指標です (比較のために、負荷が 70% に近づくと、従業員の作業はかなり大幅に遅くなる可能性が高くなります)。

1 番目のスクリーンショットは、38C:Enterprise プラットフォームが実行されるアプリケーション サーバーを示しています。これはユーザー セッションのみを提供します。 ここでは、プロセッサの負荷はわずかに高く、XNUMX％であり、スムーズで穏やかです。 ディスクの読み込みが多少ありますが、許容範囲です。

1 番目のスクリーンショットは、別の 90C:Enterprise サーバーを示しています (これは 100 番目で、クラスター内に 88 台あります)。 前のものだけがユーザーにサービスを提供し、ロボットがこのものを処理します。 たとえば、メールの受信、文書の転送、データの交換、権利の計算などを行います。 これらすべてのバックグラウンド アクティビティは、約 XNUMX ～ XNUMX のバックグラウンド ジョブを実行します。 そして、このサーバーの負荷は XNUMX% と非常に高くなっています。 しかし、これは人には影響を与えず、ドキュメント管理が行うべきすべての自動化を正確に実装します。

パフォーマンスを測定する指標は何ですか?

当社の子会社には、パフォーマンス指標を測定し、さまざまな指標を計算するための本格的なサブシステムが組み込まれています。 これは、現時点および歴史的な観点から、システムで何が起こっているのか、何が悪化しているのか、何が改善しているのかを理解するために必要です。 監視ツール (メトリクスと時間測定) は、「1C: Document Flow 8」の標準提供に含まれています。 メトリクスは実装時にカスタマイズが必要ですが、メカニズム自体は標準です。

メトリクスは、特定の時点でのさまざまなビジネス指標の測定値です (たとえば、メールの平均配信時間は 10 分です)。

メトリクスの 1000 つは、データベース内のアクティブ ユーザーの数を示します。 平均すると、1400 日中に 2144 ～ XNUMX 個存在します。 グラフは、スクリーンショットの時点でデータベース内に XNUMX 人のアクティブ ユーザーがいたことを示しています。

このような行為は 30 件以上あり、リストはまだ未公開です。リスト

• ログイン
• サインアウト
• メールを読み込み中
• オブジェクトの有効性の変更
• アクセス権の変更
• プロセスの主題を変更する
• オブジェクトのワークグループの変更
• キットの構成を変更する
• ファイルの変更
• ファイルのインポート
• メールで送る
• ファイルの移動
• タスクのリダイレクト
• 電子署名に署名する
• 詳細から探す
• 全文検索
• ファイルを受信する
• プロセスの中断
• 鑑賞
• 復号化
• 文書登録
• スキャン
• 削除のマークを外す
• オブジェクトの作成
• ディスクへの保存
• プロセスの開始
• ユーザーログエントリの削除
• 電子署名の削除
• 削除マークを設定する
• 暗号化
• フォルダーをエクスポートする

先々週、当社の平均ユーザー アクティビティは 3 倍に増加しました (グラフの赤で示されています)。これは、ほとんどの従業員が (よく知られたイベントのため) リモートワークに移行したためです。 また、従業員が携帯電話を積極的に使用し始めたため、アクティブ ユーザーの数は 2 倍に増加しました (スクリーンショットでは青色で表示)。各モバイル クライアントはサーバーへの接続を作成します。 現在、平均して各従業員はサーバーに XNUMX つの接続を持っています。

私たち管理者にとって、これはパフォーマンスの問題にもっと注意を払い、状況が悪化していないかどうかを確認する必要があるという合図です。 しかし、これを他のパラメータに基づいて検討します。 たとえば、内部ルーティングのメール配信時間がどのように変化するか (下のスクリーンショットでは青で示されています)。 今年までは変動していましたが、現在は安定しています。私たちにとって、これはシステムがすべて順調であることを示す指標です。

私たちに適用されるもう XNUMX つの指標は、メール サーバーからレターをダウンロードするときの平均待ち時間です (スクリーンショットでは赤で表示されています)。 大まかに言えば、その手紙が従業員に届くまでにどれくらいの期間インターネット上に漂流することになるでしょうか。 スクリーンショットを見ると、今回も最近と何も変わっていないことがわかります。 個別のスパイクがありますが、それらは遅延に関連しているのではなく、メール サーバーでの時間が失われているという事実に関連しています。

または、たとえば、フォルダー内の文字の更新という別の指標 (スクリーンショットでは青で表示) も考えられます。 メール フォルダーを開くのは非常に一般的な操作であり、迅速に行う必要があります。 それがどれだけ速く実行されるかを測定します。 この指標はクライアントごとに測定されます。 会社の全体像と、たとえば個々の従業員のダイナミクスの両方を確認できます。 スクリーンショットは、今年まで指標のバランスが崩れていたことを示しています。その後、いくつかの改善を加えましたが、現在は悪化しておらず、グラフはほぼ平坦になっています。

メトリクスは基本的に、システムを監視し、システムの動作の変化に迅速に対応するための管理者用ツールです。 スクリーンショットは、その年の社内子会社の指標を示しています。 グラフが急上昇しているのは、社内子会社の育成という課題が与えられたことによるものです。

以下に、その他の指標のリストを示します (抜粋)。
メトリクス

• ユーザーアクティビティ
• アクティブ ユーザー
• アクティブなプロセス
• ファイル数
• ファイルサイズ(MB)
• 文書の数
• 受信者に送信されるオブジェクトの数
• 取引相手の数
• 未完了のタスク
• 過去 10 分間のメール サーバーからのメールのダウンロードの平均待ち時間
• 外部データバッファ: ファイル数
• 現在の日付からの遅行境界線
• 長蛇の列
• 操作キュー
• 外部ルーティングによる生のアカウントの経過時間
• 内部ルーティング受付キューサイズ（ロングキュー）
• 内部ルーティング受付キューサイズ（高速キュー）
• 内部ルーティングによるメール配信時間 (長いキュー)
• 内部ルーティング (高速キュー) によるメール配信時間
• 外部ルーティングによるメール配信時間（平均）
• 書類枚数 予約
• 書類数 欠席
• 文書数「取引先との作業記録」
• メール フォルダー内のレターを更新する
• メール レターカードを開く
• メール レターをフォルダーに転送する
• メール フォルダ間の移動

当社のシステムは 150 以上の指標を XNUMX 時間測定していますが、そのすべてをすぐに監視できるわけではありません。 これらは、歴史的な観点から後で役立つ可能性があり、ビジネスにとって最も重要なものに集中できます。

たとえば、実装の 5 つでは、150 つのインジケーターのみが選択されました。 お客様は、最小限の指標セットを作成するという目標を設定しましたが、同時に主要な作業シナリオをカバーできるようにしました。 企業内であっても、どの指標が許容されると考えられるかについて合意することは困難であるため、合格証明書に 5 の指標を含めることは不当です。 そして、彼らはこれら 3 つの指標について知っており、実装プロジェクトの開始前に既にシステムに提示しており、それらは競技文書に含まれていました。カードを開く時間は 5 秒以内、ファイルを使用してタスクを完了する時間は XNUMX 秒以内です。 XNUMX秒以上など。 私たちの子会社では、顧客の技術仕様からの元の要求を非常に明確に反映する指標を持っていました。

パフォーマンス測定のプロファイル分析もあります。 パフォーマンス指標は、進行中の各操作 (データベースへのレターの書き込み、メール サーバーへのレターの送信など) の継続時間を記録します。 これは技術者のみが使用します。 私たちのプログラムには多くのパフォーマンス指標が蓄積されています。 現在、約 1500 の主要な操作を測定しており、それらはプロファイルに分割されています。

私たちにとって最も重要なプロファイルの XNUMX つは、「消費者の観点から見たメールの主要指標のリスト」です。 このプロファイルには、たとえば次の指標が含まれます。

• コマンド実行：タグで選択
• フォームを開く: リストフォーム
• コマンド実行：フォルダで選択
• 読み取りエリアに文字を表示する
• 手紙をお気に入りのフォルダーに保存する
• 詳細から文字を検索する
• 手紙を作成する

何らかのビジネス指標の指標が大きくなりすぎていることがわかると（たとえば、特定のユーザーからの手紙が非常に長い間届き始めているなど）、私たちはそれを把握し始め、技術的な操作の時間の測定に移ります。 「メール サーバーでのレターのアーカイブ」という技術的な操作があります。この操作の時間が、最後の期間で超過していることがわかります。 この操作は、たとえばメール サーバーとの接続の確立など、他の操作に分解されます。 何らかの理由で、突然非常に大きくなったことがわかります (10 か月間すべての測定値が得られています。先週は 1000 ミリ秒でしたが、現在は XNUMX ミリ秒であると比較できます)。 そして、ここで何かが壊れていることを理解しています - それを修正する必要があります。

このような大規模なデータベースをどのように維持するのでしょうか?

当社の社内 DO は、実際に機能する高負荷プロジェクトの一例です。 そのデータベースの技術的特徴について話しましょう。

大規模なデータベーステーブルを再構築するにはどのくらい時間がかかりますか?

SQL サーバーは、テーブルを整理するための定期的なメンテナンスが必要です。 良い意味で、これは少なくとも 11 日に XNUMX 回実行する必要があり、需要の高いテーブルの場合はさらに頻繁に実行する必要があります。 しかし、データベースが大規模な場合 (レコード数がすでに XNUMX 億を超えている場合)、データベースの管理は簡単ではありません。

6 年前にテーブルの再構築を行いましたが、時間がかかりすぎて毎晩の間隔に収まらなくなりました。 また、これらの操作は SQL サーバーに大きな負荷をかけるため、他のユーザーに効率的にサービスを提供することができません。

したがって、現在はさまざまなトリックを使用する必要があります。 たとえば、完全なデータセットに対してこれらの手順を実行することはできません。 「サンプル 500000 行を更新する」手順に頼る必要があります。これには 14 分かかります。 テーブル内のすべてのデータの統計を更新するのではなく、XNUMX 万行を選択し、それらを使用してテーブル全体に使用する統計を計算します。 これはある程度の仮定ですが、特定のテーブルについて XNUMX 億件のレコード全体の統計を収集するには許容できないほど長い時間がかかるため、そうせざるを得ません。

その他のメンテナンス操作も部分的に最適化しました。

DBMS の保守は一般に複雑なタスクです。 従業員間の活発なやり取りの場合、データベースは急速に増大し、管理者が統計の更新、デフラグ、インデックス作成などデータベースを維持することがますます困難になります。 ここではさまざまな戦略を適用する必要がありますが、私たちはこれを行う方法をよく知っており、経験があり、それを共有することができます。

このようなボリュームではバックアップはどのように実装されますか?

DBMS の完全バックアップは XNUMX 日 XNUMX 回夜間に実行され、増分バックアップは XNUMX 時間ごとに実行されます。 また、ファイル ディレクトリは毎日作成され、ファイル ストレージの増分バックアップの一部となります。

完全バックアップが完了するまでにどれくらい時間がかかりますか?

ハード ドライブへの完全バックアップは 20 時間で完了し、部分バックアップは XNUMX 時間で完了します。 テープ (オフィスの外に保管されている特別なカセットにバックアップ コピーを作成する特別な装置。転送可能なコピーがテープに作成され、サーバー ルームが焼失した場合などに保存されます) への書き込みには時間がかかります。 バックアップはまったく同じサーバー上で作成されますが、そのパラメーターはより高く、プロセッサー負荷が XNUMX% の SQL サーバーです。 もちろん、バックアップ時にはシステムは大幅に悪化しますが、まだ機能しています。

重複排除はありますか?

重複排除 ファイルがありますので、私たち自身でテストしてみます。すぐに新しいバージョンの Document Management に組み込まれる予定です。 また、カウンターパーティの重複排除メカニズムもテストしています。 DBMS レベルでのレコードの重複排除は必要ないため、行われません。 1C:Enterprise プラットフォームはオブジェクトを DBMS に保存し、その一貫性に対して責任を負えるのはプラットフォームだけです。

読み取り専用ノードはありますか?

読み取りノード (読み取り用のデータを受信する必要があるユーザーにサービスを提供する専用のシステム ノード) はありません。 DO は別の BI ノードに置く会計システムではありませんが、開発部門用に別のノードがあり、JSON 形式でメッセージが交換され、通常のレプリケーション時間は単位数十秒です。 このノードはまだ小さく、レコード数は約 800 億件ですが、急速に成長しています。

削除対象としてマークされたメールはまったく削除されないのでしょうか?

まだ。 ベースを軽くするという課題はありません。 2009 年を含め、削除対象の文字に言及する必要があるかなり深刻なケースがいくつかありました。 そのため、今のところすべてを保存することにしました。 しかし、そのコストが不当になった場合には、撤去を検討することになります。 ただし、痕跡が残らないようにデータベースから別の文字を完全に削除する必要がある場合は、特別なリクエストによってこれを行うことができます。

なぜ保管するのですか? 古い文書へのアクセスに関する統計はありますか?

統計はありません。 より正確には、これはユーザー ログの形式ですが、長期間保存されるものではありません。 XNUMX 年以上前のエントリはプロトコルから削除されます。

XNUMX 年前、さらには XNUMX 年前の古い通信を検索する必要がある状況がありました。 そして、これは常にいたずらな好奇心からではなく、複雑なビジネス上の意思決定を行うために行われました。 対応履歴がなければ、誤ったビジネス上の意思決定が行われていた可能性があるケースがありました。

文書の価値はどのように評価され、保管期間に応じて廃棄されますか?

紙の文書の場合、これは他の人と同様に通常の伝統的な方法で行われます。 電子的なものにはこのようなことはしません。電子的なものは自分で保管しておいてください。 お座りはここです。 メリットもあります。 みんな元気だよ。

どのような発展の見通しがあるのでしょうか？

現在、私たちの DO は約 30 の内部問題を解決しており、その一部は記事の冒頭で挙げたものです。 DL は、パートナー向けに年 XNUMX 回開催するカンファレンスを準備するためにも使用されます。プログラム全体、すべてのレポート、すべての並行セクション、会場など、これらすべてが DL に入力され、DL からダウンロードされ、印刷されたプログラムになります。作られています。

DO では、すでに解決しているタスクに加えて、さらにいくつかのタスクが進行中です。 全社的なタスクもあれば、特定の部門のみに必要なユニークで珍しいタスクもあります。 彼らを支援する必要があります。これは、1C 内でシステムを使用する「地理」を拡大すること、つまり適用範囲を拡大し、すべての部門の問題を解決することを意味します。 これは、パフォーマンスと信頼性をテストするのに最適なテストです。 私は、このシステムが数兆件のレコード、ペタバイト単位の情報を処理できることを期待しています。

出所： habr.com