任何业务都是从零开始，业务量也是逐步上升，发展到现在，应对小批量业务有多种方式，大多设计巧妙的，都是小而美的方式，（当然，更多的是那种四不像的，屎山一样的业务)。然而，随着业务量的不算上升，即便原来小而美的的设计，方方面面也逐渐触及边缘，问题不断增多，到最终也势必面临着革新。
我们先不从小业务逐渐扩大这个方向讲起。
先简化初始条件，最终再反向思考。
我们开始做下假设，凭空出现出现了一个业务，量超级大，那么随之而来的大批量机器该如何管理？
机器，是资源，是一切服务，软件运行的基础。
首先明确我们的目标，是提供一个标准化，统一的资源给服务使用，这是一个中间层，拉齐所有服务运行条件的过程。
首先，是机器上架，不同厂商，不同型号，乃至不同型号硬件的的机器，出厂设置可能均不同。我们按步骤说：
1. 网络分配，建立管理用户，这块只能依赖手工操作，没有好的办法。机器的网络管理模块首先入网，有了网络，下面就好做了，注意网络隔离，毕竟谁也不想将管理模块暴露给不怀好意的人
2. 通过厂商管理接口，比如ipmi，如今的redfish，或者不同厂商提供的接口，配置BIOS，RAID及其他硬件
3. 系统安装及初始化，涉及PXE相关工具，使用KickStart，cobbler等工具批量部署系统，如果是云服务器，则应根据云厂商提供的接口，对系统进行安装及初始化，对系统内参数设置，相应配置，所建用户，内核参数，提供的工具，软件，基本运行库等初步建立统一标准，例如监控，部署系统，服务管理工具等，此过程不应涉及业务相关特殊需求，尽量提供统一的解决方案。
4. 业务SRE使用ansible相关工具，根据所在业务对系统进行进一步调整，使之更符合业务需求，并要不断完善，当业务要求在某台机器上做其他调整时，要考虑是否对存量机器有害，如无害，则应对存量机器做同等处理，力求保持环境统一，如不适用于存量机器，则应分组处理
5. 当大批量机器构建完成，则要注意一个重要的思想的转变，那就是将以服务为中心，而不再是以机器为中心。现代大型服务系统是分布式系统，不存在单个节点，也不应存在单个节点，我们应考虑的是某个服务的某个节点挂了，不应影响整个系统的健康。因为在大批量的机器管理中，几乎每天都有机器硬件或其他问题导致机器故障，单个机器导致整个业务出现问题是不可接受的。
6.资源调度问题，即使是虚拟机或容器平台，都会存在负载均衡问题，我们简化一下，只考虑服务部署于物理机器的情况，在大批量的机器中，多个服务部署与同一个机器，总是有机器处于高负载，而有机器处于低负载的状况。诚然，我们可以不断完善监控，如：机器维度的各项资源监控，再进一步，服务发布时，发布系统自动生成该服务的各项资源使用指标。然后，我们可以再进一步，考虑如何在机器资源趋于不足时，自动进行迁移或扩容，而要做到自动进行迁移或扩容：
i. 服务必须无状态化，不能绑定单个机器
ii.需监控服务各项资源指标
迁移或扩容又需分开说：
(1). 扩容，当多个节点，或全部节点均处于资源使用率升高时，进行扩容
(2). 迁移，当单个或个别节点出现问题时，进行迁移
要完成这两项，需考虑的内容有：
(1).定义资源使用率的阈值
(2).定义问题节点占全部节点的阈值
(3).服务各个节点与机器当前资源状况的对应
7. 机器层面扩容缩容，机器数量应该是动态的，随着业务量上升或下降动态提升或缩减，需设计相应工具，当资源全部不足时给出预警，而资源冗余量过高是应自动给出提示，这其中需考虑业务状况，例如：
i.业务平稳，没有大起大落
ii.业务量经常忽大忽小，这种情况下，又可从三方面考虑：
(1).保留一定冗余的资源，阈值根据业务峰值及平时资源使用量而定
(2).公司内提供的容器平台或虚拟平台等弹性基础设施，平时需建立备用机制，当出现突峰时能够快速接入备用资源
(3).大型节假日，例如春节，春晚，五一，国庆等。可考虑接入云厂商，当冗余资源消耗到一定程度时，通过云厂商的接口，自动下单购买资源，由于这其中具有一定的时间滞后性，需考虑冗余资源消耗阈值及如何缩短时间，因为这时购买的资源，大多以时间计费。另外，考虑到成本，也应健全审批环节
未完……