多年来，Netcracker一直是电信运营商产品的供应商，同时也是整个运营商软件范围的集成商。 在这项工作中，不可避免地出现了以不同组合，来自不同开发人员和具有不同功能的产品和解决方案的大量版本同步和协调的任务。 许多运营商有意通过创建来自不同供应商的产品动物园来避免依赖一个供应商，因此在相当复杂的情况下，可能涉及多达数十个不同的系统和流程。
为了弄清楚这是什么意思，想象一下，每周一次，您需要使用一组不同的工具和技术来实现一个过程：PL / SQL过程，bash脚本，Perl脚本，启动单个应用程序和访问守护进程。 这都是由于运营商的IT环境的异质性造成的。 同时，对于每个过程，都有其自己的启动参数，退出控制以及一系列可能影响脚本后续执行的错误。 每次这样的发布都会变成一项艰巨的任务，需要高素质的IT工程师花费数小时或数天的时间-他们的培训可能需要长达三年的时间，才能发布给具有数千万用户的高效电信运营商。
显然，这些任务需要自动化。 因此，我们决定从BPMN乐队，流程计划者，监视系统中获取最大的收益，并通过分析日志和错误的能力来丰富此集合。 当然，每种系统都考虑了同类最佳代表。 但是，没有找到与该行业具体情况相匹配的实质。 因此-自己动手。
简要介绍我们在做什么：异构过程被打包到具有典型接口和属性集的“任务”中； 特定的任务序列形成一个“过程”（例如，通信服务费用的计费过程）。 此外，根据时间表或手动执行，每个进程将使用必要的参数开始其过程序列，监视执行情况，评估嵌套任务的结果，并决定方案的选择。 流程中任务之间的关系基于标准的BPMN逻辑，而在管理服务器中，我们设置了手动停止流程，暂停流程，退出当前方案并保存已处理数据的功能。 流程管理是通过具有实时监控，异常评估，监控每个流程的特定SLA的Web界面实现的。
现在，我们的“流程管理器”可以在半自动模式下工作，但实际上并不能减轻IT工程师的负担-当两个或多个复杂系统进行交互时，流程异常的可变性会增加很多倍，并且主要精力将落在错误处理上。 因此，在下一阶段，我们必须做出决定：
- 我们要如何自动执行错误处理？
- 如何根据异常分析纠正方案？
- 通常，一个人应该在多少体积和什么地方干预这种系统的运行？
我再次指出，所有这些必须实时完成，以每秒处理成千上万笔交易的关键任务系统的生产力为前提。 在这里，我们必须解决在以下情况下的查找和故障排除（所谓的故障排除）问题：
是的，我们应该遵守的另一个重要条件是不伤害。 或说官方文件的语言-减少电信提供商IT系统运行中的时间和人工成本。
提出了一个问题-自动错误处理和专家参与此类故障排除的比例应混合在一起。 接下来，让我们讨论一下这些选项。
人工智能
由于我们生活在永恒的炒作时代，我们决定将开发作为人工智能的基础-以便这种智力能够识别错误和异常，预测故障并立即进行纠正。 大型公司和小型初创公司已经在创建此类应用，甚至实施类似的解决方案。 它们的主要应用范围：用于IT基础结构的构建，维护和支持的操作。 这称为AIOps-Aritificial Intelligence（IT）运作，最流行的流行词是NoOps，即全自动IT运作。
学习系统并非易事，因为历史数据集有限，要精确复制产品成本很高，而且教学示例（主动学习）的时间太长，在我们的案例中是不准确的。 您可以尝试使用引导聚合方法-为已知案例和可疑案例模拟一组有限的场景，并基于该场景创建决策树，例如，分类和回归树，但这也是一种非常昂贵的方法。 但是，如果我们执行所有这些操作，我们将使程序为我们考虑并节省大量有用的资源（将这些资源从管理人员翻译为人工，意味着“解雇最烦人的系统管理员”）。
缺点：
- 由于系统及其交互的复杂性，实际上不可能为所有可能的情况创建和训练这种解决方案的某个“盒装”版本。 对于每个新项目，这将是其自己的单独的“培训课程”，其中包括对特定错误，异常和解决问题的适当方法的认识。
- 我们不是为有限的实现设计一个整体解决方案，而是内部解决方案（因为世界上这种规模的运营商很少）。 它很容易被发现，因此为我们的客户提供适当的“人力”外包来解决此类问题将更加经济。
- 也许我们的客户更有可能承担新的高素质工程师的成本，而不愿意承担将产品支持转移到人工智能的风险。 坦率地说，这可能引起一些担忧。
不是我我的大脑
由于无法避免人为干预，因此我们采用了老式的方法。 还记得我们曾经想过“一台机器应该工作，一个人应该思考”吗？ 我们将其重新表述为：“程序应解决已知问题，而工程师应解决未知问题。”
我们创建了一个以强化学习的概念组织的算法系统，但逻辑清晰。 系统培训在狭窄且受控的范围内进行，规则透明存储，可以对其进行编辑，扩展，指定，禁用等。 这样的发展并不比简单的“半自动化”复杂得多。 操作仍需要合格的工程师，但是其资源仅用于识别和解决新问题。 如果我们坚定地坚持“一个人不应该解决已知问题”的原则，我们可以假设一段时间后，未知问题的供应将开始枯竭，并且针对该特定应用领域，已开发系统的功能将接近AI。
这种系统最重要的部分是异常的分类，重新识别。 我们公司已经有一个类似的系统-Order Tracker，用于监视管理订单的移动运营商的业务流程。 Order Tracker每秒分析数百个事件，在单独的行和事件组合中识别异常，使用户能够对它们进行分组，设置最大值和最小值，确定不同严重性级别的错误并提出解决问题的措施。 该系统已经运行了很长时间，许多耙已经成功完成，因此我们将其用作分类工具。
现在有必要自动解决问题。 与订单管理不同，订单管理通常需要操作员的干预（例如，当您需要涉及财务部门，客户服务等）时，我们能够自动解决大部分事故，并且有一个现成的工具来设计这些解决方案-来自现成块的脚本，可以补充，扩展逻辑，包括附加检查并与每个已识别的错误类别关联。
可能出什么问题了？
仅此而已！
订单监控系统通常不需要实时进行决策和更正，任何异常都会影响有限数量的客户（从一百到几百）。 我们正在尝试对影响数十万订户的流程引入自动错误处理，并且需要实时或数小时内的解决方案。 对于我们与之合作的任何运营商来说，这都是巨大的风险，因此，对于我们的声誉而言也是如此。
我们必须显着提高脚本的灵活性，实施版本控制系统，添加实体“脚本实例”，也就是说，对于每个脚本，您现在都可以使用参数，阈值，附加检查等特定组合来创建许多子类。 我必须通过引入输入和输出参数的附加检查来增加许多任务的灵活性。
另一个发展方向是增加分析事件类别的粒度并创建元类别，即 分类程序定义的不同事件的组合。 我们添加了异常序列的估计以及不同异常在时间上的重合。 该系统变得越来越复杂，但是它仍然保留了清晰的逻辑-对于任何一对“异常类别-选定的情况”，因果关系仍然得以保留。
对于许多组合，我们已经获得了可靠的结果，并以富有成效的方式发布了它们。 以前需要花费几个小时进行搜索和更正的错误，现在可以自动模式解决。 对于其他类型的异常，我们仍然继续进行测试：在测试数据上的某个位置，以手动验证和确认所选方案的方式进行某个位置。
然后事实证明...
我们直到最近才意识到，从这些工作中获得的结果是我们一开始就没想到的-一种高效的工具，可以对他人的解决方案进行逆向工程，包括那些我们没有开发人员支持甚至没有清晰文档的解决方案。 无意间，进行了所谓的“业务流程发现”。 我们在实践中学会了分析应用程序的逻辑，识别内部错误以及与其他系统的集成问题。 现在，我们不仅可以协调其他人的应用程序，还可以为他们开发修复程序，改善集成度，而最有价值的事情就是提供我们的产品来替代现有的产品。
在下一阶段，我们希望尝试以综合产品的形式来实施我们的解决方案，以进行集成测试，该产品将自动检测错误和异常，实时学习，提供症状纠正工具以及用于搜索和分析应用程序逻辑中的问题的工具。 该解决方案的效率将不亚于流行的AIOps和NoOps，同时我们保留了透明且可管理的决策逻辑。 因此，如果几年后您遇到了市场上Netcracker提供的此类解决方案，请记住-所有这些都是从bash脚本开始的...