故障升级与故障自愈
监控系统是用来监控所有的服务器状态的，有监控主机的内存CPUIO的，有监控集群状态的，有监控日志文件的。。。等等等。
监控系统存在的目的主要是为了预防故障的发生，从而在即将有故障发生或者有了故障的时候，发出告警信息通知系统管理员，进行相关的处理。。。那么从而有了故障升级和故障自愈的概念。
故障升级，当一个告警信息发送给管理员之后，如果没有处理，那么这个告警会发送给上级，如果再过一段时间没有处理，那么会继续向上级人员进行报告。。。。
乍一看，感觉很酷，但是这种策略真的好么，起初是为了让告警信息尽快的处理，但是这种策略也让一线处理的人员压力山大，如果错过了一个告警，那么就会被各种职责，这种时间存在太久，发生的如果过于频繁，是不是在挑战一线人员的抗压能力。。。。
运维的主要策略是，让系统的稳定性提高，减轻一线人员的工作量，减轻一线人员的压力，而不是增加负担，这才是主要目的。
故障自愈，应该是故障升级的更好的版本，所谓的故障自愈，就是当告警发送过来的时候，程序进行判断告警类型，如果是一般故障，那么对此类故障直接进行处理，然后发送一条信息给管理员，发生了什么，处理结果如何即可；如果是严重故障，例如发生了OOM，例如服务挂掉，在这种情况下，是否需要人为干预，在这种设计中，如果需要重启，需要服务关闭的动作，那么必须由管理员进行确认，程序可以为我做各种分析动作，但是重大的决定必须由管理员确定，也就是当发生了OOM的时候，程序可以为我保存相关的javacore文件，可以为我保存日志上下文信息，但是在要进行重启的时候，必须让管理员确认这个动作才可以。
故障自愈不是说当有告警或者故障产生的时候，所有的东西系统都帮你做好了，而是当有故障或者告警产生的时候，一般的东西是直接处理，而重大的动作，必须由管理员进行确认才能继续下去，系统只能分析，而不能用来决策结果。
业务VS系统
系统是用来承载业务的，那么我们是应该关注于系统，还是应该关注于业务呢？
感觉上来说，这应该是属于两个方向了，关注于系统，那么是架构师的方向，而关注于业务，属于什么方向呢 ？产品经理？其实我很少关注业务，所以也就无从说起了。。。。
从说法来说，一个系统管理员，最主要的职责是解决系统发生的问题，那么从底层应该是最直接方式，一眼看去，就知道本质的原因是什么，也就是直接定位问题。。。
而对于大量系统来说，除了关联系统之间的关系，那么就需要业务方面的知识了，这样才能更快在各个系统中定位到问题，而这种，也算是了解业务的一个功能了。。。。
关注系统的底层实现，就相当于一个人的内涵，这种东西很难表现出来，暴露了太多的细节，那么就不能表现的那么完美了，气质这个东西，谁能说的清楚呢？
挫败感
每个月总有那么几天。。。。
挫败感每个人都有，而挫败感产生的原因不过两种，一种是你不行，一种是别人不行。。。
第一种属于自己给自己的压力，例如，当学习一项新的知识之后，得不到自己想要的结果，从而有挫败感，对于此种情况，可以降低以下自己的压力，退一步，从熟悉的有把握的重新开始，然后向高一层次发起进攻，慢慢的探索，总是会有进展和方向的。
第二种属于别人给你的压力，例如，付出了众多的努力之后，没有达到领导的期望，从而会感觉到自己的付出得不到认可，这一种，或许可以通过讲述自己做了哪些东西，走过了哪些步骤，其实这种情况属于人和人的沟通，关键在于你的沟通能力了，这种情况下，技术其次，沟通最容易达成想要的目标。
对于追求完美的人来说，总想知道的越来越多，但是这种，可能也是一种贪欲，也是一种欲望。。。。欲望之都，偶尔也可以放下一点点。
对于有些人来说，自己犯了错，自己都恨不得弄死自己，这种人偶尔可以放低自己的要求，多尝试几次，才能抵达下一个高度，偶尔放个假，让心四处流浪的感觉也不错。
忠告
1、 永远永远不要期望别人给你做选择，为你指路。。。没有人能给你做决定！！！因为每个人技术路线不一样，志同道合的人不多，好好珍惜一条路的人。
2、 在开始一段技术之旅的时候，记住自己最想要的东西，然后一步一步走下去，过程很辛苦，但是不要忘记初心。
3、 不要用战术上的勤奋来掩盖战略上的懒惰，多抬头看看蓝天，往事不回头，以后不将就。
4、 记得感谢每一个帮助你成长的人，包括你的对手，如果没有他们，你怎么有动力一直走下去。
