在 1C，我们广泛使用自己的开发成果来组织公司的工作。 尤其， 。 除了文档管理（顾名思义）之外，它还是一种现代的 - 系统（Enterprise Content Management - 企业内容管理）具有广泛的功能 - 邮件、员工工作日历、组织对资源的共享访问（例如，预订会议室）、时间跟踪、企业论坛等等。
超过 1 名员工在 11C 使用文档管理。 该数据库已经变得令人印象深刻（XNUMX 亿条记录），这意味着它需要更仔细的维护和更强大的设备。
我们的系统是如何工作的，我们在维护数据库时遇到什么困难以及我们如何解决它们（我们使用MS SQL Server作为DBMS）-我们将在文章中告诉你。
适合那些第一次阅读 1C 产品的人。
1C:Document Flow 是在开发业务应用程序的框架——1C:Enterprise 平台基础上实现的应用程序解决方案（配置）。
“1C：文档流 8”（缩写为 DO）允许您在企业中自动化处理文档。 员工互动的主要工具之一是电子邮件。 除了邮件之外，DO还解决其他问题：
- 时间跟踪
- 员工缺勤追踪
- 快递/运输申请
- 员工工作日历
- 信件登记
- 员工联系人（地址簿）
- 企业论坛
- 预订房间
- 活动策划
- 客户关系管理
- 集体处理文件（保存文件版本）
- 等等
我们进入文档管理 （本机可执行应用程序）来自 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 信息。
来源： habr.com