本文主要是介绍Hotmail运维：管理超大型服务的挑战，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
现状：Hotmail目前拥有遍及全球的一万多台服务器，每天处理数十亿的电子邮件事务，存储量数千兆兆（PB），总共聘用不到100名系统管理员进行管理工作。在增加服务器数量的同时保持管理人员人数不变，即可管理性也是一项挑战。
数据移植需要考虑复杂的性能规划、数据中心空间以及能源消耗问题。
自行构建的管理工具包括部署、度量标准收集、赁单记录、故障跟踪、代码覆盖、监控、编目、故障检测和构建系统。
许多应用程序都受到I/O的限制而非磁盘的限制，如何平衡I/O与数据的关系是非常困难的。指望磁盘性能向上扩展可能会失败，应该依靠的是向外扩展。
处理一个产品模型时，必须假设一切都会出错，那么就必须处理这些故障，所有数据都必须有副本，而系统必须能够自愈。
现在有许多生产力工具可使工程师的工作更为简单，因为您可以免费获得服务。但那些服务本身可能不是最有效率的。因此在规模较小的应用程序中，您可以通过 这样的服务侥幸获得成功。但在超大规模的服务内，一切都要从头构建并加以优化以降低成本，因为与运营成本相比，研发工作只不过是小问题。
使所有的部件都保持简单，就是设计超大型服务的关键所在。
磁带备份的概念已不再可行。构建能够备份更改--将它们备份到便宜的磁盘中--的系统或许是我们的方向。
我们的操作小组从不希望信赖任何类型的用户界面。一切都必须是可通过脚本编写的、必须是可通过某种类型的命令行运行的。惟有通过这样的方式，才能够执行脚本，并收集来自上千台机器的结果。
尽量保持所有的东西一致，包括部署、应用程序、错误和警报信息。因为所有的东西都是一致的，所以需要增扩的操作人员少之又少。
在构建一种能够简便地进行管理的系统--特别是将来可能会大规模扩展的系统--时，其“咒语”就是自动化。
这篇关于Hotmail运维：管理超大型服务的挑战的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
