十年磨一剑，运维监控、可观测性领域创业，拼的是产品细节和交付能力
从 2014 年开发 Open-Falcon 到后来开发 Nightingale 再到现在创业，算下来，在这个领域摸爬滚打 10 多年了。
有几个经常被问到的问题，在本文做一个梳理：
- 你们为什么创业？
- 为什么选择这个领域创业？
- 你们主要解决什么痛点？
- 你们跟其他同行的产品有何区别？
- 创业和在公司内做产品有何区别？
- 你们凭什么能长期存续？
先做个背景介绍。我们创业的公司叫：北京快猫星云科技有限公司，成立于 2021.10，是一家智能运维科技公司，是国家级高新技术企业。快猫星云聚焦在监控、可观测性领域，为企业提供相关的产品方案，加速企业 IT 的故障发现和定位，降低企业因为在线业务故障导致的资损和舆论影响。
快猫星云官网：https://flashcat.cloud
你们为什么创业？
其实每个人创业的原因都不止一点，就我个人而言，排在前几位的是：
- 年龄渐长，To B 这个赛道更长、更稳定，经验更有用武之地
- 去打工做个运维总监？那摊事现在比较熟悉了，是在一遍一遍的重复，没劲
- 物质方面，希望资产方面能有一个跃升
- 精神方面，希望能养活一个团队专职做开源，造福社会
- 个人很喜欢思考产品，希望打磨一款真正好用的产品
其他几位创始人，自然也有各自的考虑，我就不越俎代庖了，感兴趣的朋友可以直接联系他们交流 ：）
为什么选择这个领域创业？
首先是因为熟悉，隔行如隔山，希望这么多年的经验能创造更大价值。但是仅熟悉是不行的，容易陷入“发明者思维陷阱”（自己做了某个产品就觉得市场一定买单），所以我们也认真思考过这个领域的创业可行性。
- 国外巨头林立。比如 Datadog、Splunk、Dynatrace、New Relic，说明成熟市场对监控、可观测性是有很强的需求的
- 国内市场也被巨头教育过。比如 IBM、BMC 的产品，几十年前就覆盖过国内甲方。被教育过的市场更容易产生共识，一个是产品共识，一个是应该付费的共识
- 使用多云架构的公司在变多。多云架构下，很多企业想要寻求一款中立的监控、可观测性产品，同时覆盖异构多云环境
- 微服务、Kubernetes 等技术栈革新。之前很多 To B 同行是基于 Zabbix 二次开发做的企业版监控系统，随着行业技术栈革新，催生了新的需求
当然，上面是乐观的一些方面，其实也有悲观的一些方面，比如，企业需要一个契机才能催生采购新系统的诉求，如果甲方业务发展的不好或者没有新的业务场景，很难采购新系统。
我们创业几年之后内部谈笑，如果把我们的客户编纂一个指数基金，明显是跑赢大盘的，因为通常业务更繁荣生长的公司才会跟我们合作。
总体来看，感性上觉得这个方向还是有机会的。
有些朋友会诧异，你们做决策不应该基于数据么？不应该使用各类 SWOT 之类的模型分析吗？
确实要在各方面仔细分析，上面只是列了重点的一些方面。不过至于各类分析数据，唉，咋说呢，远看还挺有价值，如果了解其编纂过程，你就只会呵呵了。
你们解决什么痛点？
这是个好问题，To B 领域只有痛点才值得付费，爽点、痒点，都很难付费（不是说完全不会付费，说的是整体概率、意愿）。
每个 To B 企业都要认真梳理自己解决的痛点，我们解决的痛点如下：
- 企业数字化转型，会引入各类 IT 系统，这些 IT 系统需要稳定、访问快。比如医院，IT 系统挂了，都没法看诊，一些制造业，IT 系统挂了，都没法生产
- 提供在线业务的公司，IT 系统更是命根子，同样希望稳定、访问快。比如抖音、游戏、淘宝，IT 系统挂了，直接影响收入
直白来讲，就是大家都希望 IT 系统别有故障。但是说实话，故障真的无可避免，研发人员上线代码里有 Bug，或者硬件故障，或者光纤被挖断，啥奇奇怪怪的故障都有。我们能做的，不是杜绝故障，而是做好故障应对！
概括来讲：
- 故障能够及时发现：我们做了 Flashduty 产品及时发现、响应故障
- 故障能够及时止损：我们做了 Flashcat 产品来提速故障定位、止损
如果你们公司每年都会制定稳定性目标，比如确保三个 9 的可用性之类的，那一定要了解一下我们的产品。
如果你们公司的网站、App 等挂几个小时也没所谓，那我们的产品对您没啥价值。
你们跟其他同行的产品有何区别？
Flashduty 是一款一站式告警响应平台。对接云上、云下不同的监控系统，聚拢所有告警事件到一个平台，统一收敛降噪、排班、认领、升级、协同、分派、分析，一站式响应，解决告警风暴，避免告警遗漏。
下面这张图基本可以说明 Flashduty 的产品逻辑：
如果你听过 Google SRE、On-call、PagerDuty 这样的词，应该对这个领域不陌生。Flashduty 基本可以看做是国产版 PagerDuty。
Flashduty 相比 PagerDuty 更符合本土使用习惯，而且和本土 IM（飞书、钉钉、企微等） 有更好的打通。国内专门做 On-call 的产品很少，Flashduty 的体验很棒，不信？您可以免费注册试用：https://console.flashcat.cloud/
Flashcat 是一款一站式智能观测平台。指标、日志、链路追踪、事件的统一采集、存储、分析、串联，将零散的数据孤岛打通，预置了企业故障定位最佳实践，并深度使用 AI 加速故障分析过程，大幅缩短故障恢复时间。
如果您是新环境新项目，Flashcat 可以 All-in-one 帮您搞定一整套观测平台；如果您已经建立了各类零零散散的指标、日志、链路系统，您也无需推翻重建，Flashcat 可以利旧您现有的一个个数据孤岛，把各类数据做串联打通，建立定位路径，让您在页面点点点就可以定位故障。
其大概产品逻辑如下：
哦对了，现在 AI 很火，我们也引入了 AI 能力，点点点都不用了，直接 AI 就可以分析 🤣
有些朋友可能会觉得，都是做监控、可观测性的，你们的产品能有多大差别？
其实差别真的蛮大的，外行看方向、看名词，内行看逻辑、看细节。典型的差别点在：
- 构建整个产品的底层方法论。这是产品的大逻辑，而不仅仅是功能堆砌。
- 创始团队的实战经验。看他们是否真刀真枪落地过，因为一个 To B 企业的最终交付能力跟创始团队极为相关。当遇到一些奇奇怪怪的技术问题的时候，交付团队是否有足够的兜底能力。
- 先看灵活性，再说其他。公司级场景非常复杂，容易遇到各种奇怪的需求场景，To B 产品最要看的是灵活性。有时，一些一键xx的功能，看起来很好，其实背后是牺牲了灵活性。
“To B 同行之间，到底有没有技术壁垒？”这个问题我思考了很久。这么几点思考分享给大家：
- 底层一些软件，是可以有技术壁垒的，但是上层应用类软件，很难有技术壁垒，尤其是人员流动这么高的情况下，技术壁垒在几个月之后就会被打破
- To B 公司的产品，在方法论、实战经验、灵活性等方面，是会有差异的，这是客户选型的重要考量，但这不是 To B 企业自身的致胜法宝。To B 企业自身的致胜法宝是一个很虚的东西，是人员的持续迭代能力
- 甲方在选型时，如果看到乙方跟进速度快，思路、产品迭代快，我个人觉得是应该加分的
创业和在公司内做产品有何区别？
我创业之前是在百度、小米、金山云、滴滴四家企业打工，之前是觉得在公司内部做产品可以处理更大数据量、更有技术挑战。
实际上，仅限于你是在巨型头部企业，否则，大概率还是 To B 企业见识的更多。
To B 企业有几个特点：
- To B 企业要想活得好，都是要做产品，而非做定制化项目，用一套产品解决形形色色的甲方需求场景，所以产品要足够灵活。在公司里打工，即便你觉得自己做的已经很灵活，实际你仍然解决的是一家雇主的需求。我想，那些尝试做 To B 的互联网大厂，应该对此深有感受。
- 如果甲方就是一定要定制那怎么办？如果你是项目型公司，给钱就做挺好的。如果你就是产品型公司，且甲方需求无法抽象为通用产品能力，可能就要放弃这类客户。因为定制化，意味着需求很容易蔓延，难以界定边界，最终是双输的局面。
- 一些甲方的体量真的非常大，硬件投入还不能太浪费，此时就要榨干软件性能，有时需要抠更多技术细节，这是我前期始料未及的。
- 甲方的技术能力参差不齐，这需要产品有更好的交互体验，很多甲方不看文档，相比在公司内部服务内部的其他团队，会更难合作。
- 见识了更多甲方之后，对各类场景的实践经验也会水涨船高，有时可以把优秀的A公司的实践落地到B公司，当然也会把优秀的B公司的实践落地到A公司，此时 To B 公司是一个搬运工角色 🤣
你们凭什么能长期存续？
有些甲方担心，创业公司活不过几年就嗝屁了，所以不敢合作。我很理解。
我们创业接近 4 年了，现金流充沛，今年很可能会净利上岸，所以问题不大的 :)
总结来看，我们之所以能够稳健发展，是因为我们不做能力范围之外的事情，即不做过度承诺、不卖期货，这导致我们需要挑客户，不是所有的甲方都能承接。
虽然我们这样做，商业化进展会慢一些，但长期是稳健的，需要有足够的战略定力。中国 To B 领域 2024 年上市公司的净利润是 0.23%，这显然是应该改进的，是需要采用新方法的。
最后，创业路上感谢诸君支持，如果您想了解我们的产品，欢迎联系我做产品技术交流演示，我的微信：picobyte 🤝🤝🤝
