应用在选定时间内的总请求量、平均响应时间、错误数、实时实例数、FullGC 次数、慢 SQL 次数、异常次数和慢调用次数，以及这些指标和上一天的环比、上周的同比升降幅度等信息，都能够在这个视图体现。我们可以重点关注应用应用提供服务和应用依赖服务栏展示的指标曲线，如果在某个时间点发生了突变，可以进行针对性的排查。
工程师在实践中会掌握大量细节，但是，即使掌握了所有细节，却没有深刻的总结和思考，也会陷入到“学而不思则罔”的境地。成长的“量变”来自于对细节的逐渐深入地把控，而真正的“质变”来自于对“道”的更深层次的理解。
平台化算得上是“高大上”的代名词了，很多工程师挤破头就为了和“平台化”沾点边。然而和其他业务需求相比，平台化需求并没有本质上的区别。无论是平台化需求还是普通业务需求，它的价值都来自于客户价值。
前面我们已经讲完了原则和一些困惑，那么工程师到底应该怎么提升自己呢？
成为优秀的架构师是大部分初中级工程师的阶段性目标。优秀的架构师往往具备七种核心能力：编程能力、调试能力、编译部署能力、性能优化能力、业务架构能力、在线运维能力、项目管理能力和规划能力。
ReplicaSet与StatefulSet又是一个有意思的话题，笔者会在后续系列详细介绍。应用所需的CPU/内存资源定义在Pod内，因为CPU/内存资源是容器级别的，由Pod的spec->containers->resources定义。
Guaranteed：Pod设置requests和limits，且requests 等于limits。这种Pod具有最高的资源保证。QOS级别高于Burstable和Best-Effort。所以，建议在定义应用服务的Pod模版时，对于容器资源保证，服务质量要求高的Pod，尽量配置合适的requests和limits。
举个例子：$200，这个字段文本分类是没办法对其进行语义识别的，因为它放到不同的场景中有着不同的意思，如：活动价、原价、优惠劵…，正确的做法是考虑该字段与在 UI 界面的联系（即独特的样式）来对它进行语义分析。
网站换程序也有可能触发百度搜索风控机制。随着用户体量的不断攀升，为了让页面加载更快，运营人员会对自身网站的框架进行有效的调整，重写系统框架。如果这个网站正好是一个搜索访问量很大的站点，一旦整站核心框架配置出现相关问题，就很可能导致服务器CPU资源超载，极易造成页面长期访问打不开的情况，百度搜索结果中的温馨提示也会随之而来。
在这时，不妨先问下自己“真正的用户是谁？”，再试试“笨办法”，走出办公室，走到客户那里，去问问他们、跟他们聊聊天，看看他们怎么用我们的产品。
那时候，很多问题便豁然开朗了。
自己“做业务”，结果大不同
真正要把一个平台做好，不仅要像上面说的，自己多当“标注员”，更应该做做 “业务方”。支持业务、赋能业务，跟自己做业务，还是有很大差别的。
