回复@临石 谢谢临石的回复。这样看来初始的实例布置对后来的迁移方案的设计是有影响的。

我想补充问一个大家问得最多的问题，也就是迁移的实用（在初赛范围内）。因为提交的布置计划是没有时间点这一项，也就是执行的时候，实例并不会在一个机器上运行一段时间后移动到另一个机器上，再又移动到下一个机器（至少在初赛提交的结果中，这样的计划无法表达）。那根据现在的题意，提交的迁移计划在时间t=0的时候全部执行完毕，然后所有实例都已经布置到某个机器上。剩下来就是模拟从这样一个布置开始，运行一个周期（98个时间点）后，按照给出的评估函数来给一个分数？这样的话也就是函数中的T就是这样一个周期（现阶段T为98个时间点）？

下一个拓展性的问题就是在复赛当中考虑迁移代价之后，是否会允许实例在一个周期的执行可以在不同机器间迁移？我个人的看法是应当允许的。如果迁移的获利和代价相比更高，这样动态的迁移可以使实例见缝插针地利用资源，各个机器的使用率也因此稳定下来，所以对实际场景来说是有可行意义的。

已经报名的童鞋欢迎加入调度算法大赛选手群交流，如果二维码过期，可以加大赛官方小助手微信：alibabass88

你好，这是很好的问题，我来回答一下：

可以使用常用的第三方库，这里就不对常用做限制了。复赛阶段我们会对代码进行评测，如果评测时候我们无法获取选手提交代码中使用的库，会有麻烦

剩下两个问题：

1.评价函数里的cpu利用率是否等于任意时刻一台机器所占用cpu资源总和除以他的cpu资源总数？

答：是的。Machine_A的CPU利用率在任意时刻都是部署在其上的所有instance的CPU需求（T时刻）之和。注意，我们只以最终提交的方案计算得出的终态的部署方案进行计算，中间的迁移代价不考虑，这联系到下一个问题

2.不考虑实例的迁移代价，是不是可以理解为instance数据中当前machine那一列可以忽略？

答：初赛不考虑迁移代价。但这并不会导致instance数据中当前machine失去意义。举一个例子，在初始阶段，如果Machine_B已经满了，那么不能有新的instance被部署到Machine_B上，而Machine_B是否满了，取决于有多少instance当前部署在Machine_B上。换句话说，我们给出了集群的初始状态，而不是一个空集群。

关于迁移代价的考虑这里多说两句，初赛不考虑迁移代价，但是复赛中很可能会考虑（复赛大概率和初赛有联系）。这里我建议有余力的参赛者可以在设计算的时候考虑一下迁移的代价问题，在做初赛答案的时候可以将代价设置为0。

实际场景中，迁移的代价是比较大的，尤其对于在线业务。

以上，如果有不清楚的，随时交流

祝取得好成绩