
3
前言
•
有明确的采购和审批机制。
•
准备好调整资金支出,以支持业务需求。
•
有适当的部署和管理系统用于管理部署后的资源。
为什么编写和修订本书
运维工程师和软件开发工程师经常会面临一个难题,那就是无法通过任何途径获
取到关于计算保持网站或移动应用程序正常运行所需的容量的帮助信息。现有书
籍中关于计算机容量规划的内容更偏重于数学理论上的自研规划,而不是整个过
程的实际执行(参阅附录
C
)。此外,当今敏捷开发环境的现状是,容量规划是
一个连续的过程,应该灵活运用且适应当前的业务情况。基于静态理论模型的容
量规划将无法达到预期的效果。
许多著作只讲解了
Web
网站用例的基本模型,缺乏具体的信息或建议。相反,它
们倾向于只提供设计出来用于阐述排队理论原理的数学模型,这些数学模型是传
统容量计划的基础。这种方法也许在数学上有趣的“优雅”(决定何种程度的流
量峰值是有用的、可“吸收”的各种服务,由于内置的队列,而不影响网站
/
移动
App
的可用性),但是当运维工程师或开发人员得知只有一周时间来为不可预知
的额外流量做准备(可能是由于某一项超棒的新功能发布带来的)时,或者当他
看到自己的网站因为
Facebook
、纽约时报、
Reddit
、
Digg
等网站首页链接带来的
流量负荷而即将崩溃的时候,这种方法对于他们并没有太多帮助。
我们发现大部分有关网站容量规划的书都暗含着这样的假设:在非互联网环境(比
如制造业或工业工程)中建立的过程和概念在互联网环境中同样适用。尽管这类
与规划等相关的理论可能确实相似,但是这些概念的实际应用并不能很好地适应 ...