在 Habré 的出版物中，我已经写过与我的团队建立伙伴关系的经验（ 讨论了在创办新企业时如何起草合伙协议，以免企业分崩离析）。 现在我想谈谈如何与客户建立合作伙伴关系，因为没有他们就没有任何事情会破裂。 我希望这篇文章对开始向大企业销售产品的初创公司有用。
我目前领导一家名为 MONQ Digital 实验室的初创公司，我和我的团队正在开发一款产品，用于自动化支持和运营企业 IT 的流程。 进入市场并不是一件容易的事，我们从做一些功课开始，通过市场专家、我们的合作伙伴并进行市场细分。 主要问题是了解“我们能最好地治愈谁的痛苦？”
银行进入前三名。 当然，名单上的第一名是 Tinkoff 和 Sberbank。 当我们拜访银行市场专家时，他们说：把你的产品介绍到那里，银行市场的路就打开了。 我们试图在那里和那里进入，但在俄罗斯联邦储蓄银行等待着我们的是失败，事实证明来自 Tinkoff 的人对与俄罗斯初创公司进行富有成效的沟通更加开放（也许是因为当时的储蓄银行） 我们的西方竞争对手几乎有十亿）。 一个月内我们开始了一个试点项目。 这是怎么发生的，请继续阅读。
我们多年来一直在处理运营和监控问题，现在我们正在公共部门、保险、银行、电信公司实施我们的产品，其中一个实施是与航空公司合作（在该项目之前，我们甚至没有认为航空业是一个非常依赖 IT 的行业，现在我们真的希望，尽管有新冠疫情，该公司能够崛起并腾飞）。
我们制作的产品属于企业软件，即AIOps（IT运营人工智能，或ITOps）部分。 随着公司流程成熟度的提高，实施此类系统的主要目标是：
- 扑灭火灾：识别故障，清除碎片中的警报流，向责任人员分配任务和事件；
- 提高IT服务效率：减少解决事件的时间，指出故障原因，增加IT状态的透明度；
- 提高业务效率：减少体力劳动量，降低风险，提高客户忠诚度。
根据我们的经验，银行在监控方面与所有大型 IT 基础设施一样存在以下“痛点”：
- “谁在乎什么”：技术部门很多，几乎每个人都至少有一套监控系统，而且大多数都有不止一套；
- “蚊群”警报：每个系统都会生成数百个警报，并轰炸所有对此负责的人（有时也在部门之间）。 很难持续保持对每个通知的控制重点；由于数量众多，其紧迫性和重要性也被削弱；
- 大型银行——行业领导者不仅希望持续监控其系统，了解哪里存在故障，还希望了解人工智能的真正魔力——使系统能够自我监控、自我预测和自我纠正。
当我们来到 Tinkoff 的第一次会议时，我们立即被告知他们在监控方面没有问题，也没有任何伤害他们，主要问题是：“我们能为那些已经做得很好的人提供什么？”
谈话很长，我们讨论了他们的微服务是如何构建的，部门如何工作，哪些基础设施问题比较敏感，哪些对用户不太敏感，“盲点”在哪里，以及他们的目标和SLA是什么。
顺便说一句，银行的 SLA 确实令人印象深刻。 例如，优先级 XNUMX 的网络可用性事件可能只需几分钟即可解决。 当然，这里的错误和停机成本是令人印象深刻的。
因此，我们确定了几个合作领域：
- 第一阶段是伞式监控，以提高事件解决速度
- 第二阶段是流程自动化，以降低风险并降低 IT 部门规模扩展的成本。
只能通过处理多个监控系统的信息才能将多个“白点”涂上鲜艳的警报颜色，因为无法直接获取指标；还需要将不同监控系统的数据集中到“一屏”，以便了解正在发生的事情的整体情况。 “雨伞”适合这个任务，我们当时就满足了这些要求。
我们认为，在与客户的关系中非常重要的一点是诚实。 在第一次交谈和计算许可证成本后，有人说，由于成本如此之低，因此可能值得立即购买许可证（与上面有关绿色银行的文章中的 Dynatrace Klyuch-Astrom 相比，我们的许可证费用不是 12 亿的三分之一，而是 1 GB 每月 XNUMX 卢布，对于 Sber 来说，费用会便宜几倍）。 但我们立即告诉他们我们有什么和没有什么。 也许大型集成商的销售代表会说“是的，我们可以做一切，当然购买我们的许可证”，但我们决定把所有的牌都摊在桌面上。 在发布时，我们的盒子还没有与 Prometheus 集成，带有自动化子系统的新版本即将发布，但我们尚未将其交付给客户。
试点项目开始了，边界也确定了，我们有两个月的时间。 主要任务是：
- 准备新版本的平台并将其部署在银行的基础设施中
- 连接2个监控系统（Zabbix和Prometheus）；
- 通过 Slack 和短信向负责人发送通知；
- 运行自动修复脚本。
试点项目的第一个月是为了满足试点项目的需要，以超快速模式准备了新版本的平台。 新版本立即包括与 Prometheus 的集成和自动修复功能。 感谢我们的开发团队，他们几个晚上都没有睡觉，而是在没有错过之前做出的其他承诺的最后期限的情况下发布了他们所承诺的内容。
在我们设置试点的过程中，我们遇到了一个可能会提前结束项目的新问题：为了通过 SMS 向即时消息发送警报，我们需要与 Microsoft Azure 服务器的传入和传出连接（当时我们使用这个平台）向 Slack 发送警报）和外部发送服务 SMS。 但在这个项目中，安全是一个特别关注的焦点。 按照银行的政策，这种“漏洞”在任何情况下都不能打开。 一切都必须在闭环中进行。 我们被提议使用我们自己的内部服务的 API，通过 SMS 向 Slack 发送警报，但我们没有机会直接连接此类服务。
与开发团队进行了一晚的辩论，最终成功找到了解决方案。 在翻阅了积压的工作后，我们发现了一项我们从未有足够时间和优先级的任务 - 创建一个插件系统，以便实施团队或客户可以自己编写附加组件，从而扩展平台的功能。
但我们还剩下一个月的时间，在此期间我们必须安装所有东西、配置和部署自动化。
据我们的首席架构师Sergei介绍，实现一个插件系统至少需要一个月的时间。
我们没有时间...
只有一种解决方案——去找客户并按原样告诉客户一切。 一起讨论截止日期的变化。 它奏效了。 我们得到了额外的两周时间。 他们也有自己的截止日期和内部义务来展示结果，但他们有 2 周的储备时间。 最后，我们把一切都赌上了。 不可能搞砸的。 诚实和伙伴关系再次得到了回报。
通过试点，获得了几项重要的技术成果和结论：
我们测试了处理警报的新功能
部署的系统开始正确接收来自 Prometheus 的警报并对它们进行分组。 来自 Prometheus 客户端的问题警报每 30 秒就会发出一次（未启用按时间分组），我们想知道是否可以将它们分组到“伞”本身中。 事实证明这是可能的——在平台中设置警报的处理是通过脚本实现的。 这使得实现几乎任何处理它们的逻辑成为可能。 我们已经以模板的形式在平台中实现了标准逻辑 - 如果您不想提出自己的东西，您可以使用现成的逻辑。
“合成触发器”界面。 设置对来自连接的监控系统的警报的处理
构建了系统的“健康”状态
根据警报，创建影响配置单元 (CU) 运行状况的监控事件。 我们正在实施一种资源服务模型 (RSM)，它可以使用内部 CMDB 或连接外部 CMDB - 在试点项目期间，客户没有连接自己的 CMDB。
用于使用资源服务模型的接口。 飞行员 RSM。
嗯，事实上，客户端终于有了一个单一的监控屏幕，可以看到来自不同系统的事件。 目前，“保护伞”上连接着两个系统——Zabbix和Prometheus，以及平台本身的内部监控系统。
分析界面。 单一监控画面。
推出流程自动化
监视事件触发了预配置操作的启动 - 发送警报、运行脚本、注册/丰富事件 - 未在该特定客户端上尝试后者，因为在试点项目中，没有与服务台集成。
动作设置界面。 向 Slack 发送警报并重新启动服务器。
扩展产品功能
在讨论自动化脚本时，客户要求提供 bash 支持以及可以方便地配置这些脚本的界面。 新版本做了更多的工作（能够在 Lua 中编写成熟的逻辑结构，并支持 cURL、SSH 和 SNMP），并实现了允许您管理脚本生命周期的功能（创建、编辑、版本控制） 、删除并存档）。
用于使用自动修复脚本的接口。 通过 SSH 服务器重启脚本。
主要结论
在试点期间，还创建了用户故事，以改进当前功能并为客户增加价值，以下是其中一些：
- 实现将变量直接从警报转发到自动修复脚本的功能；
- 通过Active Directory向平台添加授权。
我们还面临着更多的全球挑战——“构建”具有其他功能的产品：
- 基于机器学习而不是规则和代理自动构建资源服务模型（可能是现在的主要挑战）；
- 支持其他脚本和逻辑语言（这将是 JavaScript）。
在我看来， 最重要的是这个试点展示了两件事：
- 当有效的沟通建立在诚实和开放的基础上时，与客户的合作伙伴关系是有效性的关键，并且客户成为在短时间内取得重大成果的团队的一部分。
- 在任何情况下都不需要“定制”和构建“拐杖”——只需系统解决方案。 最好多花一点时间，但做出一个可供其他客户使用的系统解决方案。 顺便说一句，这就是发生的事情，插件系统和消除对 Azure 的依赖为其他客户提供了额外的价值（你好，联邦法 152）。
来源： habr.com