在 1C，我們廣泛地使用自己的開發成果來組織公司的工作。尤其， 。除了文件管理（顧名思義）之外，它還是一種現代的 - 系統（Enterprise Content Management - 企業內容管理）具有廣泛的功能 - 郵件、員工工作日曆、組織對資源的共享存取（例如，預訂會議室）、時間追蹤、企業論壇等等。
超過 1 名員工在 11C 使用文件管理。這個資料庫已經變得令人印象深刻（XNUMX 億筆記錄），這意味著它需要更仔細的維護和更強大的設備。
我們的系統是如何運作的，我們在維護資料庫時遇到了哪些困難以及我們如何解決它們（我們使用MS SQL Server作為DBMS）——我們將在文章中告訴你。
適合第一次閱讀 1C 產品的人。
1C:Document Flow 是在開發業務應用程式的框架－1C:Enterprise 平台基礎上實現的應用程式解決方案（配置）。
「1C：文件流程 8」（縮寫為 DO）可讓您在企業中自動化處理文件。員工互動的主要工具之一是電子郵件。除了郵件之外，DO還解決其他問題：
- 時間追蹤
- 員工缺勤追蹤
- 快遞/運輸申請
- 員工工作行事曆
- 信件登記
- 員工聯絡人（地址簿）
- 企業論壇
- 預訂房間
- 活動企劃
- CRM
- 集體處理文件（保存文件版本）
- 等等
我們進入文件管理 （本機執行應用程式）來自 Windows、Linux、macOS、 （取自瀏覽器）和 - 視情況而定。
感謝我們與文檔流相關的其他產品 - – 我們直接在文件流中接收信使的功能 – 聊天、音訊和視訊通話（包括群組通話，這現在變得尤其重要，包括來自行動用戶端的通話）、快速文件交換以及編寫簡化聊天機器人的能力與系統一起工作。使用交互系統的另一個優點（與其他信使相比）是能夠進行與特定文檔流物件（文檔、事件等）相關的上下文討論。也就是說，互動系統與目標應用程式深度集成，而不僅僅是一個「單獨的按鈕」。
我們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磁碟。這是一個伺服器表：
未來，我們計劃增加設備的產能。
伺服器負載情況如何？
網路活動對我們或我們的客戶來說從來都不是問題。一般來說，弱點是處理器和磁碟，因為每個人都已經知道如何處理記憶體不足的問題。以下是資源監視器中我們伺服器的螢幕截圖，這表示我們沒有任何可怕的負載，它非常適中。
例如，在下面的螢幕截圖中，我們看到 SQL 伺服器的 CPU 負載為 23%。這是一個非常好的指標（作為比較：如果負載接近 70%，那麼員工很可能會觀察到工作明顯放緩）。
第二個螢幕截圖顯示了 1C:Enterprise 平台運行的應用程式伺服器 - 它只為使用者會話提供服務。這裡處理器負載稍高——38%，平穩而平靜。雖然有一些磁碟負載，但可以接受。
第三個螢幕截圖顯示了另一個 1C:Enterprise 伺服器（這是第二個，我們叢集中有兩個）。只有前一處為用戶服務，這一處由機器人工作。例如，他們接收郵件、傳送文件、交換資料、計算權利等。所有這些後台活動執行約 90-100 個背景作業。而且該伺服器的負載非常重 - 88%。但這並不影響人，而且它完全實現了文件管理應該做的所有自動化。
衡量績效的指標是什麼？
我們的子公司內建了一個嚴肅的子系統，用於衡量績效指標和計算各種指標。為了了解當下時刻以及從歷史的角度來看，系統中正在發生什麼、什麼正在變得更糟、什麼正在變得更好，這是必要的。監控工具 - 指標和時間測量 - 包含在「1C：文件流程 8」的標準交付中。指標在實施過程中需要定制，但機製本身是標準的。
指標是在某個時間點（例如，平均郵件發送時間為 10 分鐘）對各種業務指標的測量。
其中一項指標顯示資料庫中的活動使用者數量。白天平均有 1000-1400 個。此圖顯示，在截圖時，資料庫中有 2144 個活躍用戶。
這樣的動作有30多個，清單正在刪減中。表
- 登入
- 登出
- 正在載入郵件
- 更改對象的有效性
- 更改存取權限
- 改變進程的主題
- 更改物件的工作群組
- 改變套件的組成
- 更改文件
- 文件導入
- 透過郵件發送
- 移動文件
- 重定向任務
- 簽署電子簽名
- 按詳情搜尋
- 全文搜尋
- 接收文件
- 中斷行程
- 查看
- 解密
- 文件登記
- 掃描
- 取消標記刪除
- 創建對象
- 儲存到磁碟
- 流程開始
- 刪除使用者日誌條目
- 刪除電子簽名
- 設定刪除標記
- 加密
- 匯出資料夾
前一周，我們的平均用戶活動增加了一倍半（如圖中紅色所示）——這是由於大多數員工轉向遠端工作（由於眾所周知的事件）。此外，隨著員工開始積極使用手機：每個行動用戶端都會創建與伺服器的連接，活躍用戶數量增加了 3 倍（螢幕截圖中的藍色部分）。目前，平均每位員工都有 2 個與伺服器的連線。
對於我們作為管理員來說，這是一個訊號，表明我們需要更加關注效能問題，看看情況是否變得更糟。但我們根據其他參數來看這一點。例如，內部路由的郵件傳遞時間如何變化（在下面的螢幕截圖中以藍色顯示）。我們看到今年之前它一直在波動，但現在它是穩定的——對我們來說，這表明系統一切正常。
我們應用的另一個指標是從郵件伺服器下載信件的平均等待時間（在螢幕截圖中以紅色顯示）。粗略地說，這封信會在網路上流傳多久才能到達我們的員工手中。截圖顯示，這個時間最近也沒有任何變化。存在孤立的峰值 - 但它們與延遲無關，而是與郵件伺服器上的時間遺失有關。
或者，例如，另一個指標（在螢幕截圖中以藍色顯示）——更新資料夾中的字母。開啟郵件資料夾是一項非常常見的操作，需要快速完成。我們衡量它的執行速度。此指標針對每個客戶進行測量。您可以看到公司的整體情況和動態，例如單一員工的動態。螢幕截圖顯示，直到今年該指標都是不平衡的，然後我們進行了一些改進，現在它並沒有變得更糟 - 圖表幾乎是平坦的。
指標基本上是管理員用於監視系統的工具，用於快速回應系統行為的任何變化。螢幕截圖顯示了當年的內部子公司指標。圖表的跳躍是由於我們被賦予了發展內部子公司的任務。
這是一些更多指標的清單（在削減範圍內）。
指標
- 使用者活動
- 活躍用戶
- 活躍行程
- 文件數量
- 文件大小（MB）
- 文件數量
- 要傳送給收件人的物件數量
- 交易對手數量
- 未完成的任務
- 過去 10 分鐘內從郵件伺服器下載電子郵件的平均等待時間
- 外部資料緩衝區：檔案數量
- 從目前日期滯後的邊界
- 長隊
- 操作隊列
- 透過外部路由的原始帳戶年齡
- 內部路由接受佇列大小（長隊列）
- 內部路由接受佇列大小（快速佇列）
- 透過內部路由的郵件遞送時間（長隊）
- 透過內部路由的郵件傳送時間（快速佇列）
- 透過外部路由的郵件遞送時間（平均）
- 文件數量 預約
- 文件數量 缺席
- 「與對方合作的記錄」文件數量
- 郵件更新資料夾中的信件
- 郵件 開啟信卡
- 郵件 將信件轉移到資料夾
- 郵件 瀏覽資料夾
我們的系統全天候測量150多個指標，但並非所有指標都能快速監控。從某些歷史角度來看，它們稍後可能會派上用場，您可以專注於對業務最重要的事情。
例如，在其中一項實施中，僅選擇了 5 個指標。客戶設定了一個目標，即創建一組最小的指標，但同時使其涵蓋主要工作場景。將150項指標納入驗收證書是不合理的，因為即使在企業內部也很難就哪些指標被認為可以接受達成一致。他們了解這5個指標，並在實施專案開始前就已經將其呈現給系統，並將其包含在競賽文件中：開卡時間不超過3秒，完成帶文件任務的時間不超過5秒。超過XNUMX秒等在我們的子公司中，我們的指標非常清楚地反映了客戶技術規格的原始要求。
我們也對性能測量進行了概要分析。效能指標是對每個正在進行的操作（向資料庫寫信、向郵件伺服器發送信件等）持續時間的記錄。這是技術人員專用的。我們在我們的計劃中累積了許多績效指標。目前，我們測量了大約 1500 個關鍵操作，這些操作被分成多個設定檔。
對我們來說最重要的資料之一是「從消費者角度來看的郵件關鍵指標清單」。此設定檔包括例如以下指標：
- 執行指令：按標籤選擇
- 開啟表單：清單表單
- 執行命令：按資料夾選擇
- 在閱讀區域顯示字母
- 將信件儲存到您最喜歡的資料夾中
- 按詳細資訊搜尋字母
- 創建一封信
如果我們發現某些業務指標的指標變得太大（例如，特定用戶的信件已經開始到達很長一段時間），我們就開始弄清楚並轉向測量技術操作的時間。我們有一個技術操作「在郵件伺服器上歸檔信件」 - 我們看到上一個時期已經超出了該操作的時間。該操作又被分解為其他操作 - 例如，建立與郵件伺服器的連線。我們看到由於某種原因它突然變得非常大（我們有一個月的所有測量值 - 我們可以比較上週它是 10 毫秒，現在是 1000 毫秒）。我們知道這裡有些東西壞了 - 我們需要修復它。
這麼大的資料庫我們要如何維護呢？
我們的內部 DO 是一個真正有效的高負載項目的例子。我們先來談談它的資料庫的技術特點。
重組大型資料庫表需要多長時間？
SQL 伺服器需要定期維護，使表井井有條。最好每天至少執行一次此操作，對於高需求的表則應該更頻繁地執行此操作。但如果資料庫很大（而且我們的記錄數量已經超過11億筆），那麼照顧它並不容易。
六年前，我們對餐桌進行了重組，但後來開始花費太多時間，以至於我們不再適應每晚的間隔。而且由於這些操作會給 SQL Server 帶來沉重負擔，因此它無法有效地為其他使用者提供服務。
所以，現在我們必須使用各種技巧。例如，我們無法在完整的資料集上執行這些過程。您必須求助於「更新樣本 500000 行」過程 - 這需要 14 分鐘。它不會更新表中所有數據的統計信息，而是選擇 XNUMX 萬行並使用它們來計算用於整個表的統計信息。這是一些假設，但我們不得不這樣做，因為對於一個特定的表，收集整個十億筆記錄的統計數據將花費非常長的時間。
我們也透過部分優化其他維護操作。
維護 DBMS 通常是一項複雜的任務。在員工之間積極互動的情況下，資料庫快速成長，管理員維護它變得越來越困難——更新統計資料、碎片整理、索引。在這裡我們需要應用不同的策略，我們很清楚如何做到這一點，我們有經驗，我們可以分享。
如何對此類卷實施備份？
完整的 DBMS 備份每天晚上執行一次，增量備份則每小時執行一次。另外，每天都會建立一個檔案目錄，它是檔案儲存增量備份的一部分。
完成完整備份需要多長時間？
硬碟的完整備份在三小時內完成，部分備份在一小時內完成。寫入磁帶需要更長的時間（一種特殊設備，可以將備份副本複製到辦公室外儲存的特殊磁帶上；在磁帶上製作可轉移的副本，如果伺服器機房被燒毀，該副本將被保留）。備份是在完全相同的伺服器上進行的，該伺服器的參數更高 - 處理器負載為 20% 的 SQL 伺服器。當然，在備份時，系統會變得更糟，但它仍然可以正常工作。
有重複資料刪除嗎？
有文件，我們自己測試一下，很快就會納入新版文件管理。我們也正在測試交易對手重複資料刪除機制。 DBMS 等級沒有重複資料刪除，因為這是沒有必要的。 1C：企業平台將物件儲存在DBMS中，只有平台才能負責它們的一致性。
是否有唯讀節點？
沒有讀取節點（為那些需要接收任何資料進行讀取的人提供服務的專用系統節點）。 DO 不是一個會計系統放在單獨的 BI 節點上，而是有一個單獨的開發部門節點，與該節點以 JSON 格式交換訊息，典型的複製時間為單位和幾十秒。該節點仍然很小，大約有 800 億筆記錄，但成長很快。
標記為刪除的電子郵件是否根本沒有被刪除？
還沒有。我們的任務不是讓底座變得更輕。有幾個相當嚴重的案例需要引用標記為刪除的字母，其中包括 2009 年。這就是為什麼我們決定暫時保留一切。但當這樣做的成本變得不合理時，我們就會考慮拆除。但是，如果您需要從資料庫中完全刪除單獨的字母以便不留任何痕跡，則可以透過特殊請求來完成。
為什麼要儲存它？您有舊文件存取情況的統計資料嗎？
沒有統計數據。更準確地說，它是用戶日誌的形式，但不會長期儲存。超過一年的條目將從協議中刪除。
有時需要檢索五年前甚至十年前的舊信件。這樣做並不是出於無謂的好奇心，而是為了做出複雜的業務決策。曾經有過這樣的情況：如果沒有通訊記錄，就會做出錯誤的商業決策。
文件的價值如何根據保存期限進行評估和銷毀？
對於紙質文檔，這與其他人一樣以通常的傳統方式完成。我們不會為電子產品這樣做——讓他們自己保留。座位就在這裡。有好處。每個人都很好。
有哪些發展前景？
現在我們的 DO 解決了大約 30 個內部問題，其中一些我們在文章開頭列出了。 DL 也用於準備我們每年為合作夥伴舉行兩次的會議：整個計劃、所有報告、所有平行部分、大廳 - 所有這些都在 DL 中輸入，然後從中下載，以及打印的計劃被製成。
除了已經解決的任務之外，DO 還將面臨更多任務。有全公司範圍的任務，也有隻有特定部門需要的獨特且罕見的任務。有必要幫助他們，這意味著在1C範圍內擴大使用系統的「地理」——擴大應用範圍，解決各部門的問題。這將是性能和可靠性的最佳測試。我希望看到該系統能夠處理數兆筆記錄、數PB 資訊。
來源： www.habr.com