Plumbr致力于从Java应用程序内部检测性能问题。 此应用程序是驻留在开发人员办公桌下的台式机中还是隐藏在由Bastard Operator From Hell守卫的生产保管库中,并不重要。 我们设计的软件涵盖了频谱的两端。 还是我们想到了。
过去几个月使我们怀疑自己的智慧。 只是感觉不对劲–用户与产品之间突然之间出现了更多摩擦。 因此,我们最终花时间站起来,确保我们的想法是否与现实相符。
结果令人震惊-有时似乎有人在刻意“平衡运营”的情况下故意设计了我们服务的某些方面。 我将通过一些示例来说明这一点,其中大多数示例应适用于任何B2B软件公司:
安装。 安装必须容易。 有什么比单击下载的JAR文件并按NEXT几次更容易的方法?
错误的,尤其是当您的软件打算在服务器机房的黑暗角落中运行时。 而不是基于Swing的UI,您应该开始考虑rpm -ivh yourpackage.rpm及其近亲(例如dpkg或yum) ,
更糟的是,组织使用不同的工具来支持其发布过程。 在您说“我已经解决了这个软件包管理问题”之前,您的支持渠道将超限。 将您的安装嵌入到shell脚本,持续集成工具,发行管理软件或配置管理工具中的请求将会大量涌现 。而当您认为已涵盖所有内容时,下一个Ansible指日可待。
许可证服务器 。 许多B2B解决方案均以容量受限格式获得许可。 不管某个软件是按用户数量许可的,按交易量计算的服务器容量都无关紧要。 您的企业级客户希望透明化并控制其许可交易。 因此,您可以使用自己的定制许可服务器。
仅在释放许可证服务器后的第二天发现填充您的收件箱的仇恨邮件。 显然,人们并不急于从80个不同的供应商那里安装80个不同的许可证服务器。 因此,在设计专有解决方案之前,请查看常见的许可格式,并确保可以轻松将您的许可解决方案集成到公司许可解决方案中。
API支持。 当然,您需要为服务提供API。 有什么比将接口发布为MBean更合适?
好吧,如果您不愿意在Java开发人员席位上抬头,那么您可能会再次感到惊讶。 JMX与Microsoft的WebTV一样广为人知。 但是,为操作提供他们实际上可以并且想要使用的API,您将以您甚至没有想到的方式使用您的产品来发现它们。 将您的服务创建的警报发布到即时消息解决方案,或将统计信息嵌入到自定义构建的公司范围的仪表板中。 我敢打赌你没有考虑这一点。
这里的关键还在于发布原始数据。 显然,运营商希望自由地自行汇总其数据。
推出更新。 在软件的新版本发布时通知用户并建议升级–这应该很容易,对吗?
好吧,尝试将您的软件部署到一个组织中的100个人员中,然后等待下一次更新。 Voilà ,您刚刚召集了其中的大多数,以便在同一天联系服务台,询问有关这些升级的信息。 进行频繁的升级,您已经为客户制造了噩梦。
打包。 如果您是作为-javaagent出生的,那么这应该很明显。 您希望将生活打包成一个JAR文件,如果幸运的话,可以晋升为IDE插件。
如果您以某种方式浏览了上面的安装部分,那么让我重复一下主要内容:您的解决方案必须可嵌入到不同的工具和流程中。 您可以并且会拥有自己的面Kong,但是将其捆绑到其他工具和解决方案中就不会感到惊讶。
正在记录。 没关系,对吗? log4j , slf4j , logback –选择一个,并对选择感到满意。 除非您是CekiGülcü ,否则您实际上可以掷骰子并完成它?
不。 操作似乎可以控制什么,何时以及如何记录日志。 他们中的一些人只是希望将所有内容记录下来, 以防万一,并将其扔给Logstash以便将来进行模式检测分析。 然后有些人希望在其日志中添加防篡改认证。 然后,安全审核团队介入以确保您没有记录任何财务或其他敏感信息。
为什么我们不早发现呢? 这篇博客文章涵盖的发现根源隐藏在公司基因组内部。 Plumbr创始人在软件开发方面拥有强大的背景。 我们都有不眠之夜,试图将另一个里程碑连在一起。 因此,我们有点知道软件开发人员正在处理的思维方式,工具和问题。 但是到目前为止,我们还没有任何具有运营背景的人。
导致问题立即浮出水面的另一个潜在原因是我们在产品使用方式中看到的变化。 在过去的两个季度中,客户发现将产品连接到生产环境后,他们可以从中获得更多收益。 这使Plumbr能够不断监视其软件的发展并发现潜在的性能瓶颈。 自然,这意味着我们的目标受众开始越来越多地从开发人员转移到操作人员。 我们承认了这些发现,但并未真正与实际目标受众进行核实。
总结 对于您来说,我们的读者–了解您的用户。 他们的工作方式,他们使用的工具,他们对问题的看法以及实际使用您的解决方案的情况。 技巧不在本文的讨论范围之内,但是如果您没有积极地与最终用户互动,并且不了解他们的工作流程,日常问题或工具,请停止。 世界已经充满了糟糕的软件,请退后一步,确保您不打算创建另一个软件。
对于我们–亲爱的运营伙伴,我们绝对从您那里学到了很多东西。 尽管可能需要一些时间,但我们已经并将继续推出改进版本。 我只能保证那些建立起来的人会牢记所学的教训。
翻译自: https://www.javacodegeeks.com/2014/02/creating-software-for-sysops-make-sure-you-do-not-suck.html