在第一部分中，我们讨论了为什么我们决定用新系统替换数据中心中的旧 BMS 系统。不仅仅是改变，而是从头开始开发以满足您的要求。在第二部分中，我们将告诉您我们是如何做到的。
市场分析
考虑到那些描述 由于我们的意愿和拒绝更新现有系统的决定，我们编写了一份技术规范以在市场上寻找解决方案，并向几家仅从事工业 SCADA 系统创建的大公司进行了询问。
他们的第一反应表明，监控系统市场的领导者主要继续致力于硬件服务器，尽管该领域向云迁移的过程已经开始。至于保留虚拟机，没有人支持这一选项。此外，有一种感觉是，市场上可见的开发人员都没有表现出对冗余需求的理解：“云不会崩溃”是最常见的答案。事实上，我们被提议将数据中心监控放置在物理上位于同一数据中心的云中。
这里我们需要稍微题外话一下选择承包商的过程。价格当然很重要，但在实施复杂项目的任何招标中，在与供应商对话的阶段，您开始感觉到哪位候选人更感兴趣并且更有能力实施它。
这在复杂的项目中尤其明显。
根据澄清技术规范问题的性质，承包商可以分为那些对简单销售感兴趣的承包商（感受到销售经理的标准压力）和那些对开发产品感兴趣的承包商，他们听取并理解了客户的意见，提出了建设性的建议。甚至在最终选择之前就对技术规格进行修改（尽管确实存在改进别人的技术规格并失去投标的风险），但最终他们只是准备好接受专业挑战并做出好的产品。
这一切让我们注意到了当地一家相对较小的开发商——长亮集团公司，他们立即响应了我们的大部分要求，并准备好实现有关新BMS的所有需求。
风险
当大公司试图了解我们想要什么，并与我们进行包括预售级别专家的悠闲通信时，当地开发商在我们的办公室安排了一次会议，他的技术团队也参加了会议。在这次会议上，承包商再次表达了参与该项目的愿望，最重要的是，解释了如何实施所需的系统。
在会议之前，我们看到了与没有大型国内或国际公司资源支持的团队合作的两个风险：
- 专家可能会高估自己的能力，结果根本无法应对；例如，他们会使用复杂的软件或设计不可行的预订算法。
- 项目完成后，项目团队可能会解体，因此产品支持将面临危险。
为了最大限度地降低这些风险，我们邀请了我们自己的开发专家参加会议。潜在承包商的员工接受了彻底的采访，了解系统的基础是什么、计划如何实施冗余以及我们作为运营服务机构能力不足的其他问题。
结论是肯定的：现有BMS平台的架构是现代的、简单的、可靠的，可以改进，所提出的冗余和同步方案是合乎逻辑且可行的。
第一个风险已经解决。在收到承包商的确认后，第二个被排除在外，确认他们已准备好将系统的源代码和文档转移给我们，并选择了我们的专家所熟知的Python编程语言。这保证了我们有机会毫无困难地自行维护系统，并在开发公司退出市场时获得长期的员工培训。
该平台的另一个优点是它是在 Docker 容器中实现的：该环境中的内核、Web 界面和产品数据库功能。这种方法具有许多优点，包括与“经典”方法相比能够以最高速度部署解决方案的预设设置，以及轻松向系统添加新设备。 “全部在一起”的原则尽可能简化了系统的实施：只需打开系统包装即可立即使用。
使用此解决方案，可以更轻松地复制系统，并且可以在单独的环境中对其进行改进和实施升级，而无需停止整个解决方案的运行。
一旦这两种风险都最小化，承包商就提供了 CP。它涵盖了 BMS 系统对我们来说所有最重要的参数。
预订
新的 BMS 系统必须位于云端的虚拟机上。
没有硬件，没有服务器以及与此部署模型相关的所有不便和风险 - 云解决方案使我们能够永远摆脱它们。我们决定该系统将在我们位于圣彼得堡和莫斯科的两个数据中心站点的云中运行。这是两个功能齐全的系统，在主动待机模式下运行，可以访问所有授权专家。
两个系统相互保障，算力和数据传输通道都有充分的储备。还配置了其他安全措施，包括数据和通道、系统、虚拟机的备份，以及每月一次的单独数据库备份（管理和分析方面最有价值的资源）。
请注意，BMS 解决方案中的冗余选项是专门根据我们的要求开发的。预订方案本身如下所示：
Поддержка
BMS解决方案有效运行最重要的一点是技术支持。
这里一切都很简单：根据这个指标，一个新系统将花费我们 35 卢布。每月 SLA“000 小时内响应”，即 8 x 35 / 000 = 每年 12 美元。第一年免费。
相比之下，维护供应商的旧 BMS 每年的成本为 18 美元，每添加一个新设备，费用就会增加！同时，该公司没有提供专门的经理；所有互动都是通过一位销售经理进行的，他对我们作为潜在买家感兴趣，并相应强调处理请求。
用更少的钱，我们获得了全面的产品支持，有一位客户经理参与产品开发，有一个单一的入口点等等。支持变得更加灵活 - 由于可以直接访问开发人员以对系统的任何方面进行及时调整、通过 API 进行集成等。
更新
根据新BMS中提议的CP，所有更新都包含在支持成本中，即不需要额外付款。例外情况是开发超出技术规范中指定的附加功能。
旧系统需要为固件更新（例如 Java）和错误修复付费。这是无法拒绝的；在没有更新的情况下，由于内部组件的旧版本，整个系统“变慢”了。
当然，如果不购买支持包，就不可能更新软件。
灵活的方法
另一个基本要求涉及接口。我们希望通过网络浏览器从任何地方提供对它的访问，而无需工程师必须在数据中心范围内。此外，我们试图创建一个动画界面，以便值班工程师能够更清楚地了解基础设施的动态。
此外，在新系统中，有必要为工程系统中虚拟传感器的运行计算公式提供支持，例如，跨设备机架的电力优化分配。为此，您需要掌握适用于传感器指示器的所有常用数学运算。
接下来，需要访问 SQL 数据库，并能够从中获取有关设备运行的必要数据，即 20 个设备和 XNUMX 个虚拟传感器的所有监控记录，生成大约 XNUMX 万个变量。
还需要一个机架设备核算模块，提供每个单元中设备排列的图形表示，并计算硬件的总重量，维护设备库以及有关每个元素的详细信息。
批准技术规格并签署协议
当需要开始新系统的工作时，与“大”公司的通信距离讨论他们的提案的成本还很远，因此我们将收到的 CP 与更新旧 BMS 的成本进行了比较（参见. ），结果证明它在价格上更具吸引力并满足我们的要求。
做出了选择。
选定承包商后，律师开始起草协议，双方技术团队开始完善技术规格。如您所知，详细且合格的技术规范是任何工作成功的基础。技术规格中的细节越多，诸如“但这不是我们想要的”之类的失望就越少。
我将举两个例子来说明技术规范中要求的详细程度：
- 值班数据中心有权向 BMS 添加新设备，最常见的是 PDU。在旧的BMS中，这是“管理员”级别，也允许更改所有设备的变量设置，并且不可能将功能分开。这不适合我们。在新平台现有的基础版本中，方案类似。我们立即在职权范围中表示，我们希望将这些角色分开：只有授权员工才能更改设置，但值班人员应该继续能够添加设备。该方案已获接纳实施。
- 在任何标准 BMS 中，通知都分为三种典型类别：红色 - 必须立即响应，黄色 - 可以观察到，蓝色 - “信息”。传统上，我们使用蓝色警报来监控何时超出业务参数，例如客户的机架超出其容量限制。在我们的案例中，此类通知是针对经理的，运营服务对此不感兴趣，但在旧的 BMS 中，它经常堵塞活动事件列表并干扰运营工作。我们认为通知裤的逻辑和颜色区分是成功的，并保留了它，然而，技术规范特别指出，“蓝色”通知应该在不分散值班人员注意力的情况下，默默地“倒入”一个单独的部分，在那里它们将由商业专家处理。
同样详细地规定了构建图表和生成报告的格式、界面轮廓、需要监控的设备列表以及许多其他内容。
这是三个工作组真正创造性的工作：客户服务，规定了其要求和条件；双方技术专家，其任务是将这些条件转化为技术文件；承包商程序员团队根据开发的技术文档实现了客户的要求……结果，我们将一些无原则的要求适应了现有平台的功能，承包商承诺为我们添加一些东西。
两个系统并行运行
是时候付诸实施了。实际上，这意味着我们让承包商有机会在我们的虚拟云中部署 BMS 原型，并为所有需要监控的设备提供网络访问。
然而，新系统尚未准备好投入运行。在这个阶段，对我们来说重要的是在旧系统中保持监控，同时向新系统提供设备访问权限。如果没有看到其中的设备，就不可能正确构建系统，而旧系统又无法禁用旧系统的监控。
如果没有实际测试，这些设备是否能够承受两个系统的同时询问还不清楚。双同时轮询可能会导致设备频繁拒绝响应，我们会收到许多有关设备不可用的错误，这反过来又会阻止旧监控系统的运行。
网络部门从部署在云端的新BMS原型机到设备进行了虚拟路由，得到了结果：
- 通过 SNMP 协议连接的设备实际上从未因同时请求而断开连接，
- 使用 modbas-TCP 协议通过网关连接的设备存在一些问题，这些问题可以通过智能地降低轮询频率来解决。
然后我们开始观察一个新系统是如何在我们眼前构建的，我们已经熟悉的设备出现在其中，但界面不同——方便、快速，甚至可以通过手机访问。
我们将在文章的第三部分告诉你最终发生了什么。
来源： habr.com