现在，很多企业都想实现数据闭环，其实闭环就是非常典型的方法论。那么，这个方法论究竟能不能解决问题？能不能在组织和团队里运行起来？背后是否缺失了哪些环节？在这里，陈新祥分享了一个国内的实际案例。
影响正常业务：如果SDK/探针存在设计上的缺陷，有可能导致应用出现不可预知的故障。这种情况极为罕见，但一旦发生，后果会非常严重，这种情况下一般也只能等待开源社区将问题修复后才能恢复使用。
重视实践，充分运用感性认知潜能，在项目中磨炼自己，才是正确的学习之道。在实践中，在某些关键动作上刻意练习，也会取得事半功倍的效果。
致力于在技术上有所成就的工程师，都梦想有朝一日成为技术高手。但技术高手的标准却存在很大的争议。这是一个有着悠久历史的误解：以某种技术的掌握作为技术高手的评判标准。
首先你得是行业里面的顶尖专家了——实在很难找到比你更强的人了！
必须要承认一个残酷的现实：人的生命是有限的，知识却是无限的。用有限的生命去学习无限的知识是不可能完成的任务。一想到此，有些工程师不免产生一些悲观情绪。如果方法得当并且足够勤奋，悲伤大可不必。
产品经理不同。普通业务需求来自于产品经理，平台化需求的产品经理可能就是工程师自己。长期被产品经理“压迫”的工程师们，在平台化上终于找到“翻身农奴把歌唱”的感觉。
第一类常见的问题是沟通的可靠性。从可靠性的角度来讲，沟通分为TCP模式和UDP模式。TCP模式的形象表述是：我知道你知道。UDP模式的形象表述是：希望你知道。TCP模式当然比较可靠，不过成本比较高，UDP模式成本低，但是不可靠。在沟通可靠性方面，常见错误有如下两种：
简化沟通意味着快速决策，该妥协的时候妥协，权责分明。
坚持真理意味着顶住压力，在原则性问题上绝不退步。
Pod和PVC是命名空间访问控制范围内的资源对象，PV则是集群访问控制范围内的资源对象。
PVC/PV模式解耦了存储资源与节点资源，即由PVC/PV定义的存储资源独立于节点资源，通过动态绑定方式随工作负载在节点资源间迁移。具体细节依赖于云厂商提供的存储插件的实现方式。
