📊 ♨️ 🧒🏾 我们进行自我检查：如何部署和如何管理1C：1C公司内部的文档流 👵🏿 👩‍👩‍👦‍👦 🎂

我们在1C广泛使用我们自己的发展来组织公司的工作。特别地，“ 1C：文档管理8”。除了文档管理（顾名思义）之外，它也是一种现代ECM系统（企业内容管理-企业内容管理），具有多种功能-邮件，员工工作日历，对资源的共享访问权限（例如，预订会议室），会计工作时间，公司论坛等等。

在1C，一千多名员工使用文档。该数据库已经变得令人印象深刻（110亿条记录），这意味着它需要更彻底的维护和更强大的设备。

我们将在本文中介绍如何安排我们的系统工作，如何在服务数据库方面遇到哪些困难以及如何解决这些问题（我们使用MS SQL Server作为DBMS）。

对于那些最初阅读1C产品的人。
1C：文档管理是一种基于开发业务应用程序的框架实施的应用程序解决方案（配置）-1C：企业平台。

“ 1C：文档管理8”（缩写为-TO）使您可以自动处理企业中的文档。电子邮件是员工互动的主要工具之一。除了邮件，DO还解决其他任务：

时间跟踪
缺勤原因
快递/运输的应用
员工日历
函件登录
员工联系人（通讯录）
企业论坛
预订房间
活动策划
客户关系管理
文件的集体工作（保留文件版本）
等等。

在文档管理中，根据情况，我们从Windows，Linux，macOS，Web客户端（从浏览器）和移动客户端输入瘦客户端（本机可执行应用程序）。还要感谢我们连接到文档管理的其他产品- 交互系统

-直接在文档管理中获得了Messenger功能-聊天，音频和视频通话（包括群组通话，现在变得尤为重要，包括来自移动客户端的通话），快速的文件共享以及编写可简化系统工作的聊天机器人的功能。使用交互系统（与其他Messenger相比）的另一个优点是能够进行与文档管理的特定对象（文档，事件等）相关的上下文讨论。即，交互系统与目标应用程序深度集成，并且不充当“单独的按钮”。

在我们的DL中，字母的数量已经超过1亿，而在DBMS中，通常超过110亿条记录。系统总共使用了将近30 TB的存储空间：数据库为7.5 TB，用于共同工作的文件是分开的，并占用了另外21 TB。

如果我们谈论更具体的数字，那么这是目前的字母和文件数：

待发信件-1470万。
来信-8540万
文件版本-7080万
内部文件-30600

在DO中，不仅有邮件和文件。以下是其他会计对象的编号：

会议室预订-52126
每周报告-153,940
日报表-628153
签证批准-11,821
收到的文件-79677
外寄文件-28357
用户工作日历中的事件记录-168,228
快递的应用-21883
交易对手-81029
与承包商的工作记录-45632
– 41 795
– 10 243
– 6 320
– 245 980
– 26 282
– 891 095
- – 109 056. – , , , , .. , , , , . , , .

?

这些数字表明任务数量惊人，因此我们面临着为内部子公司的需求分配生产效率较高的设备的需求。迄今为止，它的特征如下：38个内核，240 GB的RAM，26 TB的驱动器。我们

提供服务器列表：将来，我们计划增加设备的容量。

服务器加载如何？

网络活动对于我们或我们的客户而言从来都不是问题。通常，弱点是处理器和磁盘，因为每个人都已经知道如何处理内存不足的问题。这是Resource Monitor中服务器的屏幕截图，显示我们没有可怕的负载，非常适中。

例如，在下面的屏幕快照中，我们看到一个SQL服务器，其中CPU负载为23％。这是一个很好的指标（作为比较：如果负载接近70％，则员工很有可能会观察到明显的减速）。

第二张屏幕截图显示了运行1C：Enterprise平台的应用程序服务器-它仅服务于用户会话。在这里，处理器负载略高-38％，它是平稳的。有磁盘加载，但是可以接受。

第三个屏幕截图显示了另一个1C：企业服务器（这是第二个，集群中有两个）。只有前一个为用户提供服务，而机器人为此进行工作。例如，他们接收邮件，路线文档，交换数据，考虑权利等。所有这些后台活动都执行大约90-100个后台任务。该服务器非常繁忙-占88％。但这并不影响人员，它仅实现了文档管理应执行的所有自动化。

确定性能的指标是什么？

我们在BS中内置了一个严肃的子系统，用于测量性能指标和计算各种指标。为了了解当前时间和历史观点，这是必要的，以便了解系统中正在发生的情况，正在恶化的情况，正在恶化的情况。监视工具（度量和时间度量）包含在标准软件包“ 1C：文档管理8”中。指标需要对实现进行调整，但是机制本身是典型的。

指标是在某些时间点（例如，10分钟时的平均邮件传递时间）对各种业务指标的度量。

指标之一显示数据库中的活动用户数。平均每天有1000-1400个。该图显示，在截屏时，数据库中有2144个活动用户。

这样的动作有30多种，清单已经减少。

清单

在上一周的前一周，我们的平均用户活动增加了一半半（图形显示为红色）-这是由于大多数员工转向了远程工作（与已知事件有关）。此外，随着员工开始积极使用移动设备，活动用户的数量增加了3倍（屏幕上以蓝色显示）：每个移动客户端都会创建与服务器的连接。现在，平均而言，对于我们的每位员工，服务器都有2个连接。

对于我们来说，对于管理员而言，这是一个信号，表明我们需要更加关注速度问题，以查看速度是否会变差。我们以其他方式看待它。例如，内部路由的邮件传递时间如何更改（以下屏幕截图显示为蓝色）。我们看到它一直持续到今年，现在已经稳定了-对我们来说，这表明该系统正常运行。

对我们来说，另一个适用的度量标准是从邮件服务器下载信件的平均等待时间（在屏幕截图中以红色显示）。粗略地讲，这封信要多久才能在互联网上传给我们的员工。屏幕截图显示，这次也没有任何改变。有单独的爆发-但是它们与延迟无关，而与邮件服务器上的时间浪费有关。

或者，例如，另一个指标（屏幕截图中以蓝色显示）-更新文件夹中的字母。打开邮件文件夹是非常常见的操作，需要快速完成。我们测量它执行的速度。该指标针对每个客户进行衡量。您可以查看公司的整体情况，例如单个员工的动态。屏幕截图显示，直到今年指标不平衡，然后我们进行了许多改进，现在并没有恶化-几乎是时间表。

指标基本上是管理员用来监视系统的工具，用于快速响应系统行为的任何变化。在屏幕截图上-一年的内部DO指标。图中的跳跃是由于我们已被指定开发内部子公司的任务。

这是一些其他指标的清单（已削减）。

指标

()
10
:
( )
( )
( )
( )
()
« »

我们的系统全天候对150多个指示器进行测量，但是并非所有的指示器都可以快速监控。从某些历史角度来看，它们可以在以后派上用场，您可以专注于最重要的业务。

在一种实现方式中，例如，仅选择了5个指标。客户为自己设定了制定最少指标的目标，但同时又涵盖了主要工作场景。在接受行为中包含150个指标是不合理的，因为即使在企业内部，也很难就哪些指标被认为是可接受的达成共识。他们知道这5个指标，并已在实施项目开始之前将它们提交给系统，包括在招标文件中：卡打开时间不超过3秒，任务执行时间不超过5秒，等等。在我们的子公司中，有准确的指标可以非常清楚地反映出客户需求的最初要求。

我们还对性能测量进行了分析。性能指标是所执行的每个操作的持续时间的固定（向数据库写一封信，向邮件服务器发送一封信，等等）。它仅供技术专家使用。我们的计划中有很多绩效指标。现在，我们评估了大约1,500个关键操作，这些操作已按配置文件细分。

对我们来说最重要的配置文件之一是“从消费者的角度来看邮件的关键指标列表”。例如，此配置文件包括以下指示符：

命令执行：按标签过滤
打开表单：列表表单
命令执行：按文件夹选择
在阅读区域显示字母
将一封信保存到您喜欢的文件夹
通过详细信息搜索字母
创建一封信

如果我们发现某个业务指标的度量标准变得太大（例如，特定用户的来信开始很长时间了），我们就会开始理解，我们将转向测量技术运营时间。我们的技术操作为“在邮件服务器上存档信件”-我们发现上一阶段的操作时间过长。反过来，此操作分解为其他操作-例如，建立与邮件服务器的连接。我们看到由于某种原因它突然变得非常大（我们在一个月内进行了所有测量-我们可以比较上周的10毫秒和现在的1000毫秒）。我们知道这里的东西坏了-我们需要修复它。

我们如何维护如此庞大的数据库？

我们内部的DO是一个真正有效的高负荷项目的示例。让我们谈谈其数据库的技术功能。

大型数据库表的重组需要多长时间？

SQL Server需要定期维护，清理表。以一种很好的方式，对于每天需要很高的表，应该至少每天执行一次，甚至更多。但是，如果基础很大（并且我们的记录数已经超过110亿），那么就不容易照顾它。

我们在6年前进行了表的重组，但是随后开始花费了很多时间，以至于我们不再适合夜间使用。而且，由于这些操作使SQL Server负担沉重，因此它无法为其他用户提供优质的服务。

因此，现在我们必须应用各种技巧。例如，我们无法对完整的数据集执行这些过程。您必须诉诸“更新示例500000行”过程-这需要14分钟。它不会更新表中所有数据的统计信息，而是选择五十万行，并从中计算用于整个表的统计信息。这是一个假设，但我们被迫坚持下去，因为对于特定的表，整个十亿条记录的统计信息收集时间将过长。

我们还通过使其局部化来优化其他维护操作。

维护DBMS通常是一项艰巨的任务。在员工之间进行主动交互的情况下，数据库正在快速增长，管理员维护数据库变得越来越困难-更新统计信息，进行碎片整理和建立索引。在这里，我们需要应用不同的策略，我们很清楚如何做到这一点，我们有经验，可以分享。

这样的卷如何实现备份？

DBMS的完整备份每天晚上执行一次，每天增量一次。此外，每天都会创建一个文件目录，它是文件存储增量备份的一部分。

完整备份需要多长时间？

在硬盘上，完整备份在三个小时内执行，部分备份-一小时内执行。写入磁带需要更长的时间（一种特殊的设备，可以将备份副本复制到存储在办公室外的特殊盒式磁带中；对磁带也可以复制的副本，例如，如果服务器烧毁，它将被保存）。备份完全在同一服务器上完成，该服务器的参数更高-处理器负载为20％的SQL服务器。当然，在备份时，系统会变差很多，但仍可以运行。

是否有重复数据删除？

有重复数据删除功能，我们可以自己运行它，不久它将包含在新版本的文档管理中。我们还运行对手方重复数据删除机制。在DBMS级别上没有重复记录的删除，因为这是没有必要的。1C：企业平台将对象存储在DBMS中，只有该平台才能负责其一致性。

有只读节点吗？

没有要读取的节点（专用于为需要接收任何读取数据的用户提供服务的系统节点）。DO不是要放在单独的BI节点上的会计系统，但是开发部门有一个单独的节点，该节点与JSON格式的消息交换，并且典型的复制时间为单位和数十秒。该节点仍然很小，它有大约8亿个条目，但是它正在快速增长。

标记为删除的邮件根本不会删除吗？

还没。我们没有任何便利基地的任务。在很多情况下，我不得不转向标记为删除的字母，包括2009年。因此，目前，我们决定保留所有内容。但是，如果这样做的成本不合理，我们将考虑撤离。但是，如果您需要从数据库的末尾删除一个单独的字母，以便没有痕迹，那么可以通过特殊请求来完成。

为什么要存放它？是否有关于旧文件访问的统计信息？

没有统计信息。更准确地说，它采用用户日志的形式，但存储时间不长。超过一年的记录将从协议中删除。

在某些情况下，有必要提出五年甚至十年前的旧信件。这样做并非总是出于好奇，而是为了做出复杂的业务决策。在某些情况下，如果没有通信历史，则会做出错误的业务决策。

如何根据保存期限检查文件的价值和销毁情况？

对于纸质文档，这和其他所有人一样，是以通常的传统方式完成的。对于电子产品，我们不这样做-将其存储起来。坐在这里。有好处。一切都很好。

发展前景如何？

现在，我们的DO解决了大约30个内部问题，我们在本文开头列出了其中的一些问题。DO还用于准备我们每年为合作伙伴举行两次的会议：整个程序，所有报告，所有平行部分，大厅-所有这些都由DO组成，然后从DO中下载并制作印刷程序。

在执行DO的路上，除了他已经解决的任务之外，还有其他任务。有公司范围内的任务，但是只有任何特定部门才需要独特且罕见的任务。有必要帮助他们，因此，扩大1C内部使用该系统的“地域”-扩大范围，解决所有部门的任务。这将是性能和可靠性的最佳测试。我希望看到该系统能够处理数万亿条记录和PB级的信息。

我们进行自我检查：如何部署和如何管理1C：1C公司内部的文档流

?