背景
这是本周给我印象最深的一张图：
非常有幸的是，与运营老师进行了简短的交流，其中有几句话让我感受颇深：
“在实际调研过程中，往往存在专家太忙，太多重要的事情要做等现实困境”
“我们目前在做内核行为可观测性的产品，希望能够解决运维排障时的一些痛点！”
“团队原来做的是Kindling开源，但是发现内核这东西对很多人太复杂，特别是对运维或者业务开发，很难直接拿来为自己工作提供便利，所以就出来单独做了个完整产品。”
“挺担心变成闭门造车的，所以目前也找了很多公司做技术交流分享！”
运维盲区
可能是运维职业敏感度的问题，在空闲时间我看了关于“kindlingx”官网、公众号的大部分的文章，其中又有两个盲区发人深省：
用户代码盲区
程序执行盲区
在出现生产问题时，我们大都是面向应用层解决问题，例如：OOM、慢SQL、连接数、超时时间、JVM等，然后再不断进行下钻到主机负载、网络数等，因此运维总是在故障表象是下功夫，甚至连用户代码层也碰触不到，整个过程基本都是“黑盒”！
当你傲娇地认为，虽然用户代码我不了解，但我知道程序运行的环境啊。因此运维无论是在传统架构还是云原生架构中总是在推进“一次构建，到处运行”，将因环境差异引发问题的概率尽可能降低。但无论何种交付方式，仍都脱离不开程序执行的过程：
❝
程序代码是以线程为载体进行执行，线程执行过程中可能会因为disk、sleep、lock、idle等各种原因放弃CPU上执行转入等待状态。等待事件完成之后，线程状态变成Runnale等待cpu调度，如果此时CPU资源紧张，就会出现很长的等待时间。
❞
若从操作系统层面看程序的执行过程，才是程序的真实执行过程，这里面是没有任何遗漏的。还有一点，除了本地的用户代码盲区、程序执行盲区外，还有一个盲区我们可能会忽略，那就是用户访问盲区。因为当用户访问您的业务时，整个访问过程大致可以分为三个阶段：页面生产时（服务器端状态）、页面加载时和页面运行时。以上这些一般都是用户的浏览器行为，由浏览器直接发起，页面加载性能、运行时异常以及API调用状态和耗时等数据，因此也都比较前置。而运维很大一部分的监控精力却是在服务器端对业务的运行状态进行各种监控，用户访问对我们来说也是一个盲区！
可观测性
“缺少了底层基础设施的根因都是假的”，这是来自一位资深运维无声的呐喊！因为基础设施具有全局性、放大性等关键因素，而一旦基础设施出问题，无疑会拉长整个排障周期，甚至会悻悻而归！
“ 那些杀不死你的，终将使你更强大！”，正是因为有了这些需求，可能才是我们运维存在的意义，只不过企业所在的发展阶段不一样而已！
当企业处于粗放型发展阶段时，运维面向业务CI/CD，保障业务系统的快速交付；
当企业处于平稳增长阶段时，运维面向业务稳定性，构建从基础设施层、数据层到应用层的可观测体系，快速发现问题并解决问题；
当企业处于创新突破阶段时，运维面向业务可观测性，既要将监控下沉到操作系统内核层面，又要将监控迁移至靠近用户前端访问层面，即融合厂商提供的eBPF、前端监控能力，深入融合可观测体系，来补齐企业运维能力的短板；
当然我们需要在合适的阶段做正确的事，从痛点出发，找寻最适合的解决方案。
❝
ARMS前端监控
https://help.aliyun.com/zh/arms/browser-monitoring/product-overview/what-is-arms-browser-monitoring?spm=a2c4g.11186623.0.0.1b0d66c7Bda9HL
云观秋毫
https://originx.kindlingx.com/
声明：文中观点不代表本站立场。本文传送门：https://eyangzhen.com/414478.html
