日志，把日志当作事件流，微服务架构中服务数量的爆发需要具备调用链分析能力，快速定位故障。
管理进程，把后台管理任务当作一次性进程运行，一些工具类在生产环境上的操作可能是一次性的，因此最好把它们放在生产环境中执行，而不是本地。
Gartner 提出的 DevOps 模型
文化、技术、过程和人，其中团队文化才是最难改变的，技术方面包括基础设施即代码、全局监控、持续监控。
远离日暮西山的行业。
做自己感兴趣的事情。
做有积累的事情。
一边走一边看，切勿一条道走到黑。
学无止境吗
必须要承认一个残酷的现实：人的生命是有限的，知识却是无限的。用有限的生命去学习无限的知识是不可能完成的任务。一想到此，有些工程师不免产生一些悲观情绪。如果方法得当并且足够勤奋，悲伤大可不必。
恰恰相反，平台化应该是客户什么都不做，所有的脏活累活都由平台方来做。本质上讲，平台化的价值来自于技术深度。真正体现技术深度的恰恰是设计者能够很轻松的把所有的脏活累活搞定。
所以平台化的最佳实践是：投入最少的资源，解决最多的问题。平台解决一切，客户坐享其成。
第一类常见的问题是沟通的可靠性。从可靠性的角度来讲，沟通分为TCP模式和UDP模式。TCP模式的形象表述是：我知道你知道。UDP模式的形象表述是：希望你知道。TCP模式当然比较可靠，不过成本比较高，UDP模式成本低，但是不可靠。
在沟通可靠性方面，常见错误有如下两种：
经常听到的这样的争论。一方说：“我已经告诉他了”，另一方说：“我不知道这个事情呀”。把UDP模式被当作TCP模式来使用容易产生扯皮。
过度沟通。有些同学对沟通的可靠性产生了过度焦虑，不断的重复讨论已有结论问题。把TCP模式当成UDP来使用，效率会比较低。
第二类沟通问题是时效性问题。从时效性讲，沟通分为：同步模式和异步模式。同步沟通形象地说就是：你现在给我听好了。异步沟通的形象表述是：记得给我做好了。在沟通时效性方面，有如下两种常见错误：
同样的事情发生在很多刚刚管理小团队的工程师身上。最终的结果他们：写完所有的代码，让下属无代码可写。“ 事必躬亲”当然非常糟糕，最终的往往是团队的整体绩效不高，团队成员的成长很慢，而自己却很累。
