为什么在系统上线时，总是申请不到机器呢？

2022-04-27 本文已影响0人有点胖的瘦子

研发团队终于把业务功能完了，向运维部门申请生产运行资源，往往需要的硬件数量非常高，这时候，运维人员会将长抱怨研发团队没有从运维角度思考问题，经常对资源不给与或者少给与资源

那运维人员说的，运维角度究竟是什么呢？

运维部门一般情况下，手头可用资源优先，如果要增加大量新硬件资源，尤其是没有提前规划好的，一般都要走采购流程。遇到疫情等原因，就会变得非常慢。

所以，如果遇到新系统上线，最好能够提前1-2个月发起资源申请，这样给采购留足时间，不影响最终上生产。

运维部门一般都会有个资源管理列表，但是研发团队是不知道的，也不能左右，所以也不会关心。所以，以往往往很难从运维团队现有资源考虑，规划，都是简单粗暴地给出需要的资源需求。

假如系统平日100人在线，高峰10000人，那么研发团队在资源申请时，就会申请10000人所需要的资源。这会是一个超过预期的资源量。

运维团队一下自无法拿出这么多资源，自然而然会认为资源申请人从运维角度触发，要求研发团队进一步精简资源，有时候也会要去把冗余高可用部分都去掉。

也不好完全拒绝，毕竟是新系统嘛，所以运维团队都会先分配出一部分现有资源，并增加一小部分新资源，满足系统最小运行要求，先确保系统可以用起来。

运维团队认为目前生产环境已经是虚拟化的，申请资源不能再是实体机形式，研发团队还是以实体机模板申请资源是不合理。

该处确实应该考虑一种新的资源评估方式，例如算力、内存、容量进行组合。

目前所以资源都在资源池中，原则上高峰需要时候就分配多一些，日常低谷可以动态抽走一些，在资源申请模式下，资源一旦申请就是独占，这样很不利于资源的动态利用。
由于研发团队也没有提供相关说明，对于这类的资源动态调配，只能在运行期间，由运维团队根据资源投入及系统实际使用状态进行调整。

改进方案之一：在业务单位使用前，先调用高峰时期以及预计使用量，有些业务系统是晚上10-12点是后台运行高峰，这个信息可以告知运维团队。

改进方案之二：在资源充足时，用户体验指标是一个参考值，如果资源抽走后，还能维持用户体验指标，那就说明资源是多的。

运维团队认为申请资源要求过高，并认为研发团队的技术优化度不够，作为成熟的中间件xxx不应该这么消耗资源。
研发团队缺乏对于中间件xxx在运行任务时消耗的权威评定，所以双方只能各持一词。

改进方案之一：对于中间件xxx的使用，双方应该有个基线值，可以基于标准化任务和标准化硬件模块进行一轮测试，再决定是否优化还是增加资源。该结果还可以列入到组织资产库中，作为性能测量的组织资产的一部分。

随着业务的试点、推广，所需要的资源也是逐步增加的，不会一下子就到达顶峰。
所以对于业务系统的硬件资源投入，也是分批投入，对应系统发展的不同阶段。

这个研发团队也未能给出，只是根据业务峰值，给出了最大资源需求。

改进方案之一：研发、业务、运维坐在一起，规划好业务系统的三个阶段，实试点节点、推广阶段、增长阶段，并给出阶段的时间规划、预计高峰量及对应硬件需求量。

如果新系统代替历史系统，历史系统将会是一个参照点，一般的历史系统虽然慢但是可以运行，新业务系统如果需要降低资源使用量，可以考虑延长任务运行时间，降低资源进一步消耗的可能性，从而降低整体成本。

历史系统被替换的原因往往是因为运行规模无法扩大，例如是单机算程序，新系统可以突破单机限制，但是同时也追求单次请求更快，就容易造成资源消耗的急剧上升，提升企业整体成本，超过新系统的资源预算。