频道栏目
读书频道 > 数据库 > Oracle > Oracle性能预测
2.7.3 管理层需要知道什么
2013-09-04 13:20:23     我来说两句
收藏   我要投稿

本文所属图书 > Oracle性能预测

本书共10章。第1章介绍了性能预测的基本概念和范畴,分析了预测提供的信息及其价值;第2章介绍了基本的性能预测概念,深入研究了如何组合及建模性能预测;第3章介绍了提高预测精度的一些有效手段,通过选择合适的...  立即去当当网订购

你应该告诉管理层与你应该告诉技术人员的东西是完全不同的。你千万不要跑到你的经理面前,只向他出示满满一桌子的数字,甚至一个漂亮的图形,并对他说,“看起来我们的麻烦大了,老板。”如果发生问题的可能性高,那么管理层需要知道它的多种解决方案并需要把握核心问题。针对我们的例子,可以提出有关以下5点的一个简单的陈述:

即将到来的季度末结账工作负载预计将接近(目前峰值的)3倍(增加200%)。反复核实,让每个人都同意这一点。如果他们不同意,那么很显然这样的结果并没有意义。

服务水平变得不可接受的风险很大。确保每个人都明白,这个风险仍然存在。不好的事情可能会发生,业务将因此受到非常严重的影响。这是无可争议的,它将会发生。

在工作负载增加约110%时将开始出现重大业务中断。管理人员需要知道工作负载增加到刚刚超过2倍时系统的性能就将开始变差,而大家预计的工作负载将增加到3倍。所以,很显然,必须采取措施。

CPU子系统存在无法提供足够能力的风险。(我们没有调查IO子系统,但我们假设IO子系统不存在风险。)让管理层知道问题不是出在IO子系统。那么问题显然就出在CPU子系统了。因此,解决方案也需要围绕CPU子系统展开。

解决方案是……此刻,管理层害怕了,真的很害怕。他们的工作可能处于风险之中,他们迫切需要你的帮助。所以给他们一些固定的选择方案和你可能的建议。根据你的角色和责任,你可能需要为每个可能的解决方案提供成本和预期效益。不要轻率地提供肤浅的解决方案,如,“只要重启那个玩意!”现在是你成为一个闪光的IT专业人士的机会。你有3个主要的解决方案,分别围绕系统调整、购买更多的CPU能力、改善工作负载平衡来展开。我将在下一节详细讨论这些问题。

管理层关心业务(和他们的饭碗)。业务的核心是服务水平要满足业务的需求。如果你能利用你的预测实力帮助他们管理服务水平,你就会脱颖而出。如果你尝试用你的数学天才使他们印象深刻,那么我希望你在舒适的办公室隔间内好好地享受你70%的生活,因为那里是最适合你的地方。

管理人员需要知道:

商定的服务水平(以暗示或其他方式)是否会被突破?从风险和可能性两方面说明这件事,然后,你可以直接在确定风险时说出你的解决方案。它给出了圆满答案,“这里有风险。这是降低风险的办法。”

风险在哪里?由于我们将重点放在数据库服务器上,你将需要用大块的图形化的方式来解释数据库服务器安装到IT架构中的什么位置。不要花哨。只在屏幕上显示几个块。细节和精确度是没有必要的,并且会使管理层分散注意力并造成混淆。我们需要的是风险所在的普遍认可。让管理层知道,到底是CPU系统、IO子系统、内存子系统,还是网络子系统,将要耗尽燃油了。

何时将会发生预期的风险?大多数预测工作探讨未来,因此对预计何时服务水平将处于危险之中做必要的解释是很有可能的。请专注于预测传达出的东西,而不是你个人认为会发生什么。

可以采取什么措施减轻所查明的风险?正如我所提到的,此刻,管理层害怕了,他们迫切需要你的帮助。拿出多个风险缓解策略总是一个好主意。简单地说,“好了,我们需要增加5个CPU。”由于预算或政策原因可能它不是一个好的选择。所以,你应该有另一种方案。要小心,不要逾越你的权力和责任的范围。如果你不参与成本方面的事情,那么你需要清楚地向财务人员提供信息。但要小心地提出解决方案的建议,除非你清楚大部分的问题所在。

如果你能将你的原始预测转换成管理层需要的东西,那么你就是在真正地管理性能、管理服务水平,并为公司增加大量的价值。管理层接收到的是在坚实的技术分析基础上经过深思熟虑后的(以业务的视角)表述,而不是专注于技术分析的介绍,这种情况虽然理想,但是非常罕见。一定要执行坚实的技术分析,但需要花时间将分析结果转换为针对管理层的介绍。专注于管理层需要知道的东西,而不是预测相关的技术细节。这才是预测的价值所在。

您对本文章有什么意见或着疑问吗?请到论坛讨论您的关注和建议是我们前行的参考和动力  
上一篇:2.7.2 应用程序
下一篇:2.8 风险缓解策略
相关文章
图文推荐
排行
热门
最新书评
特别推荐

关于我们 | 联系我们 | 广告服务 | 投资合作 | 版权申明 | 在线帮助 | 网站地图 | 作品发布 | Vip技术培训 | 举报中心

版权所有: 红黑联盟--致力于做实用的IT技术学习网站