回到应用列表视图，我们能查看到这些应用的整理健康状态，最先应该关注的是应用的状态列，如果亮红灯，说明系统已经诊断到某个应用存在明显的健康问题，这个时候我们可以点击红灯图标，让ARMS生成一份应用诊断报告。通过应用诊断报告，能很快的知道这个应用在哪一个时间点发生了故障。比如ARMS判断故障是由应用的某一个实例导致的情况下，会把可疑实例在报告中报出，让使用者点击实例链接就能进入单实例的详情页面，从错误率、硬件资源、JVM等维度对故障进行排查。
如果在应用列表视图，并没有发现亮红灯的应用，我们可以从健康度百分比、请求数、错误数、异常数、最近10分钟响应时间等数据中，快速判断一下有没有比较明显的与实际情况存在出入的应用。比如在最近10分钟内，有一个应用从某一个时间点开始，响应时间明显变长，我们就可以把这类应用列入需要进一步进行分析的名单。
内存快照创建后，点击分析结果，就能够进入内存快照在线分析页，这个页面集成了MAT(Eclipse Memory Analyzer)内存分析工具的所有功能，具体的用法和实践可以参考MAT手册。
在繁忙的工作中，持之以恒、不断学习和进步是一件艰巨的任务，需要坚强的毅力和坚定的决心。如果方法不得当，更是事倍功半。幸好我们的古人和现在哲人已经总结了很多优秀的学习方法论，这里汇总了一些重要原则。遵循这些方法必会对大家的工作学习大有裨益。
确定目标优先级。比如：成长、生活、绩效。
确定每个目标的下限。从优化理论的角度来看，这被称为约束。比如绩效必须在一般以上，之前已经规划好的旅行不能更改，必须读完《Effective Java》等等。
最低目标必须能够轻松达成的目标，否则，从优化理论的角度来讲，该命题无解。比如，类似“半年内完成晋级两次、绩效全部S、从菜鸟成为Java专家”就不太合适作为最低目标。总之，要区分理想和梦想。
致力于在技术上有所成就的工程师，都梦想有朝一日成为技术高手。但技术高手的标准却存在很大的争议。这是一个有着悠久历史的误解：以某种技术的掌握作为技术高手的评判标准。我经常碰到这样一些情景：因为掌握了某些技术，比如Spring、Kafka、Elasticsearch等，一些工程师就自封为高手。有些工程师非常仰慕别的团队，原因竟是那个团队使用了某种技术。
特别需要避免的是“ 在其位不谋其政”的情况。团队越大，在管理方面需要投入的精力就越多。在管理技巧不成熟，技术眼界不够高的前提强行负责大团队，可能会导致个人疲于应付，团队毫无建树。最终“ 一将无能，累死三军”，效果可能适得其反。
所以平台化的最佳实践是：投入最少的资源，解决最多的问题。平台解决一切，客户坐享其成。
半夜三点你正在熟睡，或者周末正在逛街，接到一个电话：“现在有个需求，能否立刻帮忙做完。”这会非常令人郁闷，因为那并不是紧急的事情。不是所有的需求都需要立刻解决。
