大家好！ 我叫Alexey Volkov。 我们与我的同事，开发人员Alexander Solovyov（
Alsov ）一起在DataLine中进行内部Web服务。 今年秋天，我们启动了服务台以取代BMC Remedy。 在帖子中，我将告诉您为什么我们拒绝现成的解决方案，而是自己做所有事情。
每天平均有450份申请通过服务台。什么补救措施不能取悦我们？
进入DataLine时，我几乎立即开始练习Remedy。 经过反复尝试以完成我们的任务后，我们决定设立服务台。 以下是我们决定放弃BMC的补救措施请求系统的原因的简短清单：
界面不便。 要注册一个应用程序，使其生效并记录其许可，我们必须进行100500次点击。
页面与事件。 至少获取需要在特殊窗口中打开的消息内容的字段。
需要打开整个选项卡级联才能编写解决方案或将事件重定向到另一个执行程序。与其他客户端界面的
集成以及任何改进都表明，即使是手鼓跳舞。 专有软件几乎没有回旋余地。 唯一的漏洞是知道如何与Remedy通信的Web服务，但是它们非常喜怒无常且不稳定。 我们完全手动且笨拙地做了一些事情：我记得我们是如何在数据库中的选择帮助下配置事件报告的上传的。
当然，还有另一种方法：雇用承包商并履行任何异想天开。 当时，该软件市场上只有一个承包商，他对此很了解。 生产过程正在调整，并且将不断需要改进。 考虑到这一点，价格标签变得不人道，起价为500万美元。
许可证不足。 在DataLine诞生之初，我们购买了100个许可证。 从那时起，公司发展成倍增长。 许可证在竞争。 越来越多的情况是工程师不得不等待许可证的发放才能开始工作。 实际上，这是最后一根稻草。
解决所有突发事件 。 我们希望与客户技术支持有关的所有事情都能在服务台中得到体现。 补救措施，实际上仅记录了请求。 关于该事件的所有实际工作都是通过邮件通信，通过电话，在吸烟室（任何地方）进行的，而并非在Remedy。 特别是如果它是一个复杂的应用程序，并且涉及多个部门的专家。 他们解决了这个问题，但是Remedy对此一无所知。 结果，该事件被分段记录，有时在“补救措施”中根本没有出现。 很难控制，理解和分析任何东西。
服务台2.0
补救功能易于更换。 新服务台的主要任务是将所有技术支持活动拖到“一个窗口”中：联系人，工作信函，文件。 我们希望对客户将应用程序发送给我们以获得支持后发生的所有情况进行记录。 在此过程中，我们希望使许多事情自动化，以减少第一线支持的负担并最大程度地消除人为因素。
以下是我们在新服务台中实现的最重要的功能：
转移事件。 我们经常收到复杂的应用程序，这些应用程序是由不同部门的专家按链条进行的。 最简单的是一种用于物理访问数据中心设备的应用程序。 首先，调度员签发通行证，然后将客户数据和通行证编号传递给在数据中心会见并陪同客户的值班工程师。 有一些要求可以持续解决5个部门的要求。
对于所有此类情况，界面中都会出现一个单独的“提交”按钮。
与客户和同事的通信。 该功能只是为了确保事件的通信不会“泄漏”到邮件中，并且与我们保持整个交流历史。
到目前为止，一切都非常简单。 该计划是要使全文编辑器能够下载文件，表格等。
约会历史和所有事件活动的历史。 这些标签可帮助您解决有争议的问题和内部调查。 目前，我正在从历史记录中下载报告，以监视将事件分配给配置文件组时调度员犯错的频率。
这就是内部事件“解雇雇员”的故事。
事件历史记录。 在这里，我们仍然会带来美丽，但是主要任务已经解决-一切都已记录。观察员 碰巧，在申请书中，客户将感兴趣的人的副本固定在副本中。 所有这些同志将显示在“观察员”选项卡中，并监视此应用程序的执行。 他们将收到有关请求状态的通知，如果愿意，他们将能够与我们的技术支持联系。 在公司内部，也需要此功能：服务经理可以适应其客户的任何请求并监视其执行。
观察者列表可以编辑：删除和添加新的观察者。
事件模式。 有很多典型的查询。 为了避免一天要多次填写通行证或垃圾清理应用程序，我们添加了创建事件模板的功能。 您只需要单击“创建事件”按钮，就会打开一个预填充的模板，其中包含指定的执行者，类型，优先级和状态。
数据中心的工作有很多定期重复的应用程序：巡回检查，测试，根据检查清单检查工程设备等。为此，配置了自动事件，这些事件以给定的频率自动落入跟踪器中。
分析。 Remedy中没有内置的分析工具，常规工具无法卸载任何工具。 在这里，我们提供了所有内容的卸载以及所有内容的进一步分析。 例如：
- 每天的请求数量；
- 反应速度
- 延迟请求；
- 请求类型；
- 按部门装载；
- 调度员的工作；
- 在客户方面出现问题的频率和质量；
- 各种依赖关系，例如，对请求类型的执行速度。
稍后，我们希望使用图表和图形制作仪表板，以便无需在Excel中进行任何卸载和巫术操作就可以了解技术支持方面的情况。
可以使用过滤器直接在服务台中生成报告。
卸载各种格式的数据。
您可以选择将在上载中显示的字段。与其他内部服务集成的API。 简单来说：服务台从目录中提取信息，其中包含客户公司，合同，订购的服务以及可以发送请求的负责人的列表。 以前，您必须先检查一个单独的文件，以确定编写者是否是客户，以及他是否可以编写来自公司的请求。
“绕过值班”是我们的另一项内部服务，服务台现在可以与之交互。 这是一个电子清单，值班人员和维护工程师每天都要对数据中心进行几次检查，以检查是否出现故障和混乱。 例如，在绕行时，服务员偶然发现设备安装不正确的客户服务台。 他只需在“绕过”程序中做一个相应的记录，有关问题的事件就会自动到达服务台。 服务员沿着旁路路线走得更远，接待问题已经开始得到解决。
可以为任何清单项目创建事件。
绕过软件内部事件的表单。 上面的挂起事件在同一对象上工作。在小事上。 我们在界面页面上显示的所有最常见的请求类型。 选择优先级后，用户会看到截止日期和进度栏，显示出他还有多少时间执行事件。
实作
在试运行期间，我们在内部应用程序上测试了工作台。 他们在AXO，基本建设，生产和服务管理部门接受了大约一个月的培训。 外部应用程序和其他部门的应用程序仍在接受补救。
然后，我们与三个客户达成协议，以运行外部应用程序的处理。 这是第一个问题发生的地方。
当他们刚开始建立新的服务台时，我非常希望我们的智能邮件解析器能够注册请求，通过专门部门分散请求，在同一事件中就同一问题归档消息。 将来，这意味着调度员将放弃处理书面请求。 在Remedy，人们已经非常习惯于依赖邮件通信；这比我们预期的要多。 解析器无法在测试中应付：分配请求时可能会使部门感到困惑，他将已经打开的事件中的新消息注册为新事件。 还有很多琐碎的困难：解析器无法读取带有证书的邮件中的来信； 我不理解非标准编码，并从问题中发送了文本。
我不得不增加体力劳动-控制室出现了。 这是对
support@dtln.ru的所有应用程序的炼狱。 从那里，调度员按部门手动分发应用程序。
在客户端，与技术支持进行交互的逻辑保持不变，只是节拍的外观发生了变化。 在早期，它们有多个叠加层，主要是由于目录中的详细联系信息不正确。 因此，其中一位客户有23位负责人，所有人都有一封普通电子邮件，例如info @。 服务台乖乖地通知了每个人，通过在此邮箱中接收来完成一个小时的每日费用。
接下来是什么？
在不久的将来-
与“我的帐户”集成 。 所有通信和联系历史记录将显示在客户资料中。 从理论上讲，这是一个机会，可以从技术支持的通信中排除邮件，并最终将客户端拖到我们的Web界面中。 让我们看看它如何扎根生活。
参数化应用程序的实现 。 有些查询包含许多参数和值，重要的是不要在其中混淆任何内容。 例如，当客户端要求将虚拟资源添加到池中或创建特定大小的虚拟机时。 对于这种情况，我们计划制作一个带有参数的构造函数。 它将自动解析通过邮件收到的此类客户端请求。 调度员通过电话接受申请时将使用它。
这就是参数化订单的样子。评估技术支持。 臭名昭著的“以五分制评估我们的服务”，并具有以自由形式书写客户的所有想法的能力。
我们希望在一个成熟
的调度员（AWP）自动化工作场所中开发一个非常重要的
调度室 ，该
室起着拐杖的作用，以帮助邮件解析器。 现在，调度员必须研究各种接口（设备会计，负责人员列表，客户服务），以收集有关客户的必要信息。 但是，在AWP中，所有内容都将在一个窗口中：客户事件，联系人，合同，订购的服务及其参数等数据。
好了，不要对
部门自动分发应用程序抱有希望。 现在，我们正在考虑针对电子邮件解析器的主题标签系统。
***
自11月份以来，服务台一直处于战斗模式，而这期间我一直看到事件数量稳步增长（+ 40％），这主要是由于内部要求所致。 我敢于希望这是由于新的服务台在各个方面都更加友好，并且要求不再流失于他的事实。
新服务台的另一个好处是灵活性。 我们已经为单个客户提供了几种定制解决方案，以便与他们的内部服务台集成或简单地适应他们的生产流程。 以前，这将花费数月甚至数百万美元，但现在所需要做的只是给开发人员写一封信，并在1-2周内完成，具体取决于任务的复杂性。