同时，要把数据结果融入到团队的工作流程里去，比如可以在早上八点把团队最关注的东西发到邮箱，市场推广人员可以看到相应的报表。在上午十点的时候，产品经理可以登录后台看到更新的产品功能。
从业务需求到需求规范，一定要做统一收口，如果没有线上工具化的体系，可以指定一个人，让他做统一收口，收口完成之后要形成公司或者部门内部比较完整的指标字典和维度字典。与此同时，一定要对指标字典进行拆分，看看哪些是公共性指标（跨部门或者公司级别）和个性化指标。
维护工作复杂：除了客户端的SDK和探针外，一套全链路监控方案在服务端有计算组件、存储组件、展示组件，都需要单独进行维护。以Jaeger为例，仅在数据存储方面需要维护一套独立的Elasticsearch集群，需要投入很大的工作量。
凡事预则立，不预则废。对于漫长的学习生涯而言，好的计划是成功的一半。
“一致性”算得上是计算机领域里面最经典的难题，它是所有分布式系统的基础，从多核多CPU到多线程，从跨机器到跨机房，无所不在，几乎所有的计算机从业人员都在解决这个问题，但是Paxos给出了一个很优雅的解决方案。
平台化绝对不是诸如“统一”、“全面”之类形容词的堆砌。是否需要平台化，应该综合考虑：客户数量，为客户解决的问题，以及客户价值是否值得平台化的投入。
致力于在技术上有所成就的工程师，都梦想有朝一日成为技术高手。但技术高手的标准却存在很大的争议。这是一个有着悠久历史的误解：以某种技术的掌握作为技术高手的评判标准。我经常碰到这样一些情景：因为掌握了某些技术，比如Spring、Kafka、Elasticsearch等，一些工程师就自封为高手。有些工程师非常仰慕别的团队，原因竟是那个团队使用了某种技术。
把可行性调研做成不可行性调研。这真的非常糟糕。不可行性的结论往往是：因为这样或者那样的原因，所以不可行。
古人说：“用人不疑，疑人不用。”这句话并非“放之四海而皆准”。在古代，受限于通信技术，反馈延迟显著，而且信息在传递过程中有大量噪音，变形严重。在这种情况下，如果根据短期内收集的少量变形的信息做快速决断，容易陷于草率。在公司里，这句话用于选人环节更为恰当，应该改为：录用不疑，疑人不录。
调试能力是项目能否按时、高质量提交的关键。即使一个稍具复杂度的项目，大部分工程师也无法一次性准确无误的完成。大项目都是通过不断地调试进行优化和纠错的。所以调试能力是不可或缺的能力。
多写程序，解决Bug，多请教高手是提升调试能力的重要手段。
