Quest Software 的运维管理构架，可以形象地归纳为一个“Ｔ”形架构：横向覆盖应用系统的前端（终端用户响应）和后台（应用），纵向深入到特定被管理组件的诊断分析、问题解决和性能优化。
在过去的N年中，我遇到了很多使用囧然不同风格的开发者，下面是我所知道的一些，你还知道其它的吗？
散弹枪编程
这种编程风格是一种开发者使用非常随意的方式对待代码。“嗯，这个方法调用出错了……那么我会试着把传出的参数从 false 变成 true!”，当然依然出错，于是我们的程序员会这样：“好吧，那我就注释掉整个方法吧”，或是其它更为随意的处理方式，直到最后让这个调用成功。或是被旁边的某个程序员指出一个正确的方法。
如果我们把一个正规的程序员和一个撞大运的程序员放在一起做结地，那么，那个正规的程序可以马上变得发疯起来，并且，可以把正规的程序员的智商降到最低。两个撞大运的程序员不应该在一起做结对编程，这是因为他们破坏性的才能会造成的伤害会比只有一个还差。
撞大运编程
这是一种比散弹枪编程要温和一些的编程方式，我相信这种方式可能会是大多数程序员都会使用的方式。这种编程方式经常出现于程序员并不确切知道他们在干什么，也不知道所写的程序的本质和实际，但是可以让程序工作起来。他们以一种撞大运的方式在写程序，某些时候，他们根本就不知道某个错误的原因，就开始稀里糊涂地修改代码。一旦出现问题，他们会用两条路：1）停下来，理解一下程序，找到出错的原因。2）使用散弹枪编程方式开始解决问题。
IT 行业发展到今天已经成为企业应用系统不可或缺的基础和支撑，因此对 IT 系统的管
理，尤其是核心应用系统的管理变得越来越迫切和重要。
应用系统架构
一个典型的企业应用系统基本上由基础架构（网络、防火墙、路由器、交换机、主机等）
和应用（数据库、应用服务器 、业务应用）构成。其中，直接与业务最密切相关的就是应用，
运维工作的重点也是对应用的运维。
运维管理挑战
是的，异常开销很大。那么，这是不是就意味着您不该使用异常？当然不是。但是，何时应该使用异常，何时又不应该使用异常呢？不幸的是，答案不是一下子就说得清的。
我们要说的是，您不必放弃已经学到的好的 try-catch 编程习惯，但是使用异常时可能会遇到麻烦，创建异常就是一个例子。当创建一个异常时，需要收集一个栈跟踪（stack track），这个栈跟踪用于描述异常是在何处创建的。还记得当代码中抛出一个意料之外的异常时，您所看到的输出来的栈跟踪吗？像下面这个：
SOA与许多新技术的一个共同特点是虽然它简化了可见的、面向用户的流程或者服务，但是，它给底层的基础设施增加了巨大的复杂性。应用性能管理可以看作是SOA基础设施管理工具的三条腿之一。其它两条腿是安全管理和治理。所有这三条腿对于管理SOA基础设施以提供更高的性能、安全和结构化的SOA环境是非常重要的。
测试与生产
