微码升级方法、装置、设备及存储介质与流程

1.本发明涉及设备管理的技术领域，尤其涉及一种微码升级方法、装置、设备及存储介质。


背景技术：

2.现有技术中，对微码进行升级是指：厂商针对特定的设备需求而向客户发送微码变更的数据更新包(简称更新包)，客户根据这些数据更新包对设备的微码进行升级。用户需要对在用设备进行批量升级时，往往是根据经验选择设定微码版本，将不同的设备统一升级至该设定版本。
3.然而客户在升级前对升级的风险获取能力较弱甚至于无，无法对升级的风险做出准备。并且，在用设备的升级可能对正被接入的其他设备或网络造成不良影响，例如，降低交互效率甚至使相关业务无法持续进行，且在用设备升级后可能导致功能异常或性能下降等问题，进一步扩散了对整个运行网络的不良影响。
4.因此，如何对设备微码的更新进行管理，以降低设备更新的风险成为一个重要问题。


技术实现要素：

5.本发明旨在至少解决现有技术中存在的技术问题之一。为此，本发明实施例提出一种微码升级方法、装置、设备及存储介质，旨在降低设备更新的风险。
6.第一方面，本发明实施例提供一种微码升级方法，包括步骤：
7.根据待升级设备的微码的当前版本对应的未修复缺陷信息，获取第一目标版本；
8.根据所述当前版本及所述第一目标版本，获取升级所需的预计升级总耗时；
9.根据所述待升级设备的端口流量的历史负载信息及所述预计升级总耗时，获取第一升级窗口时间；
10.在所述第一升级窗口时间启动下载任务，下载所述当前版本至所述第一目标版本的更新包；
11.安装所述更新包，以更新所述待升级设备的微码版本。
12.根据本发明实施例的微码升级方法，至少具有如下有益效果：通过微版本版本的未修复缺陷信息获取推荐升级的第一目标版本，并根据预计升级耗时及设备的端口负载信息获取推荐升级的第一升级窗口时间，在第一升级窗口时间内对设备进行微码升级，有效地降低了设备更新风险，提高了设备更新后的稳定性，降低了在用设备更新时对整个运行环境的不良影响，从而提高了设备所在的整个运行网络的稳健性。
13.根据本发明的一些实施例，所述根据待升级设备的微码的当前版本对应的未修复缺陷信息，获取第一目标版本包括：确定所述待升级设备的微码的所有版本的未修复缺陷列表及已修复缺陷列表；通过所述当前版本对应的所述未修复缺陷列表，查找出至少一个第二目标版本，所述第二目标版本对应的所述已修复缺陷列表中存在至少一个第一缺陷，
所述第一缺陷为所述当前版本的所述未修复缺陷列表中的缺陷；从所述第二目标版本中筛选出所述第一目标版本。
14.根据本发明的一些实施例，所述从所述第二目标版本中筛选出所述第一目标版本包括：根据预设的缺陷与缺陷严重级别映射关系，确定每个所述第一缺陷对应的缺陷严重级别，并将缺陷严重级别最高的所述第一缺陷作为第二缺陷；对于每个所述第二目标版本，分别统计所述第二目标版本的所述已修复缺陷列表中的所述第二缺陷的第一数量值；将最大第一数量值对应的所述第二目标版本作为所述第一目标版本。
15.根据本发明的一些实施例，所述从所述第二目标版本中筛选出所述第一目标版本还包括：对于每个所述第二目标版本，分别根据预设的缺陷与缺陷严重级别映射关系，确定所述第二目标版本的所述未修复缺陷列表中的每个缺陷的对应的缺陷严重级别，并统计最高缺陷严重级别对应的第二数量值；将最小第二数量值对应的所述第二目标版本作为所述第一目标版本。
16.根据本发明的一些实施例，所述根据所述当前版本及所述第一目标版本，获取升级所需的预计升级总耗时包括：根据所述当前版本及所述第一目标版本，获取相应的升级路径；统计所述升级路径中每个更新包的更新平均耗时，得到所述预计升级总耗时。
17.根据本发明的一些实施例，所述根据所述待升级设备的端口流量的历史负载信息，获取第一升级窗口时间包括：以预设频率采集所述待升级设备的每个端口的流量信息；以第一时间为步进，以第二时间为滑动窗口的长度，获取预设时间段内多个所述滑动窗口对应的所述待升级设备的所有端口的总流量信息；基于每个所述滑动窗口对应的所述待升级设备的所有端口的总流量信息以及所述预计升级总耗时，获取总流量最低的所述第一升级窗口时间。
18.根据本发明的一些实施例，所述根据所述预计升级总耗时，获取总流量最低的所述第一升级窗口时间包括：若所述第二时间大于等于所述预计升级总耗时，则获取总流量最低的所述滑动窗口，得出所述第一升级窗口时间；若所述第二时间小于所述预计升级总耗时，则根据所述预计升级总耗时合并时间段相邻的所述滑动窗口，以使合并后的所述滑动窗口对应的时间长度大于等于所述预计升级总耗时，并获取总流量最低的合并后的所述滑动窗口，得出所述第一升级窗口时间。
19.根据本发明的一些实施例，所述在所述第一升级窗口时间启动下载任务包括：根据所述预计升级总耗时，在所述第一升级窗口时间内选定一个时间点启动所述下载任务。
20.第二方面，本发明实施例提供一种微码升级装置，包括：
21.版本推荐模块，用于根据待升级设备的微码的当前版本对应的未修复缺陷信息，获取第一目标版本；
22.升级耗时预估模块，用于根据所述当前版本及所述第一目标版本，获取升级所需的预计升级总耗时；
23.升级窗口推荐模块，用于根据所述待升级设备的端口流量的历史负载信息及所述预计升级总耗时，获取第一升级窗口时间；
24.升级任务管理模块，用于在所述第一升级窗口时间启动下载任务，下载所述当前版本至所述第一目标版本的更新包，更新所述待升级设备的微码版本。
25.根据本发明实施例的微码升级装置，至少具有如下有益效果：通过微版本版本的
未修复缺陷信息获取推荐升级的第一目标版本，并根据预计升级耗时及设备的端口负载信息获取推荐升级的第一升级窗口时间，在第一升级窗口时间内对设备进行微码升级，有效地降低了设备更新风险，提高了设备更新后的稳定性，降低了在用设备更新时对整个运行环境的不良影响，从而提高了设备所在的整个运行网络的稳健性。
26.第三方面，本发明实施例提供一种设备，包括处理器以及与所述处理器耦接的存储器，所述存储器存储有可被所述处理器执行的程序指令，所述处理器执行所述存储器存储的所述程序指令时实现第一方面所述的微码升级方法。
27.第四方面，本发明实施例提供一种存储介质，所述存储介质内存储有程序指令，所述程序指令被处理器执行时实现能够实现第一方面所述的微码升级方法。
28.本发明的附加方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。
附图说明
29.本发明的上述和/或附加的方面和优点从结合下面附图对实施例的描述中将变得明显和容易理解，其中：
30.图1是本发明实施例的方法的流程示意图。
31.图2是本发明实施例的方法中微码信息库的表格形式的示例。
32.图3是本发明实施例的方法中获取第一目标版本的流程示意图。
33.图4是本发明实施例的方法中获取预计升级总耗时的流程示意图。
34.图5是本发明实施例的方法中获取第一窗口时间的流程示意图。
35.图6是本发明实施例的方法中滑动窗口的移动示例图。
36.图7是本发明实施例的装置的模块示意图。
37.图8是本发明实施例的设备的结构示意图。
38.图9是本发明实施例的存储介质的结构示意图。
具体实施方式
39.下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。在后续的描述中，使用用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本发明的说明，其本身没有特有的意义。因此，“模块”、“部件”或“单元”可以混合地使用。“第一”、“第二”等只是用于区分技术特征为目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量或者隐含指明所指示的技术特征的先后关系。在本后续的描述中，对方法步骤的连续标号是为了方便审查和理解，结合本发明的整体技术方案以及各个步骤之间的逻辑关系，调整步骤之间的实施顺序并不会影响本发明技术方案所达到的技术效果。下面通过参考附图描述的实施例是示例性的，仅用于解释本发明，而不能理解为对本发明的限制。
40.实施例1
41.参照图1，本实施例公开了一种微码升级方法，用于对设备的微码的升级管理，包括如下步骤s100至s500。
42.步骤s100，根据待升级设备的微码的当前版本对应的未修复缺陷信息，获取第一目标版本。
43.具体地，首先，获取待升级设备中微码的当前版本。获取的方法可以是，例如，读取待升级设备中微码的版本配置信息，得到当前版本。获取的方法也可以是，向该待升级设备发送表征查询微码版本的协议包或指令，接收该待升级设备返回的微码当前版本的信息。本发明的实施例中，待升级设备可以是，例如，交换机。
44.然后，获取该微码当前版本对应的未修复缺陷信息。可以根据厂商对于与待升级设备同类型的设备(例如同一型号的交换机)的微码更新发布版本的相关信息，构建如图2中所示的微码信息库。
45.该微码信息库录入了每个微码版本对应的如下信息：版本号、前置版本号、更新次数、更新平均耗时、已修复的缺陷列表(对应于图2中的修复缺陷列表)、已知的未修复缺陷的列表(对应于图2中的未修复缺陷列表)以及发布时间。图2中未示出具体的发布时间，发布时间可以是发布当天的日期也可以是发布时的时间戳。图2中，v1为该种类型的待升级设备的初始版本。
46.其中，前置版本号表示微码更新包更新至目标版本所依赖的微码版本。例如，在图2中的第4行，对应于微码版本从v2至v3的更新包的相关信息。且要使用该更新包将待升级设备的微码版本升级至v3，该待升级设备的微码版本必须已为v2。显然，根据前置版本可以获取升级路径。
47.更新次数表示从前置版本号至版本号的更新包被使用的次数。更新平均耗时表示该更新包更新所耗的平均时间。
48.本发明的实施例可以对同一类型的设备进行批量升级管理。各个待升级设备在运行更新包时，上报例如：前置版本、版本号、更新耗时等信息，本发明的实施例中，接收到上述上报信息，更新如图2的微码信息库中对应的更新次数和更新平均耗时。上述上报的更新耗时可以为包括更新开始时间及更新结束时间的形式。
49.显然地，本发明的实施例也可以对不同类型的设备进行统一升级管理，只需要按待升级设备的类型构建多个如图2中所示的微码信息库，在更新时根据待升级设备的类型对相应的微码信息库进行操作即可。
50.图2中所示的修复缺陷列表及未修改缺陷列表中，每个缺陷的信息包括：缺陷严重级别及缺陷编号。
51.缺陷严重级别，是指该缺陷对待升级设备的功能或性能可能造成的影响程度，一般被分为若干个级别，例如，三个级别，包括：一般、中等及严重。在图2中，缺陷的信息以例如“a001”的方式存在，其中，首字母表示缺陷严重级别，剩余的数字部分则为缺陷编号。a、b、c表示缺陷的严重级别由高到低。即，a表示缺陷严重级别最高，c表示缺陷严重级别最低。
52.在本发明的另一些实施例中，修复缺陷列表及未修改缺陷列表中，每个缺陷可以只包括标识缺陷的缺陷编号，该缺陷对应的缺陷严重级别则存在于预设的缺陷与缺陷严重级别的映射表中。通过缺陷编号，可以从该映射表中查找到缺陷对应的缺陷严重级别。
53.以图2中的v1版本的升级为例，获取第一目标版本的过程参照图3，包括如下步骤。
54.步骤s110，确定待升级设备的微码的所有版本的未修复缺陷列表及已修复缺陷列表。
55.具体地，可以通过厂商对于与待升级设备同类型的设备(例如同一型号的交换机)的微码更新发布版本的相关信息，构建如图2中所示的微码信息库。该微码信息库中包括了每个版本对应的未修复缺陷列表及已修复缺陷列表。
56.步骤s120，通过当前版本v1对应的未修复缺陷列表，查找出至少一个第二目标版本。在该第二目标版本对应的已修复缺陷列表中，存在至少一个第一缺陷。该第一缺陷为当前版本的未修复缺陷列表中的缺陷。
57.以图2为例，当前版本v1中的未修复缺陷列表中的第一缺陷为：a001，a002，b002，c003。由于版本v2修复了缺陷c003，版本v3修复了缺陷b002，版本v4修复了缺陷a001，因此，当前版本v1对应的第二目标版本包括：版本v2、版本v3和版本v4。
58.步骤s130，从第二目标版本中筛选出第一目标版本，作为推荐升级的目标版本。
59.从第二目标版本中筛选出第一目标版本的方法有多种，以下将分别进行描述。
60.(第一种方法)
61.第一种方法是从第二目标版本中筛选出修复了最多的缺陷严重级别最高的版本作第一目标版本，具体包括以下步骤：
62.s131，根据预设的缺陷与缺陷严重级别映射关系，确定每个第一缺陷对应的缺陷严重级别，并将缺陷严重级别最高的第一缺陷作为第二缺陷；
63.s132，对于每个第二目标版本，分别统计第二目标版本的已修复缺陷列表中的第二缺陷的第一数量值；
64.s133，将最大第一数量值对应的第二目标版本作为第一目标版本。
65.以图2中的v1版本为例，缺陷严重级别最高的第一缺陷有2个：a001和a002。将这两个缺陷作为第二缺陷，统计第二目标版本的已修复缺陷列表中第二缺陷的第一数量值，得到：版本v1至版本v3的第一数量值为0，版本v4的第一数量值为1。因此，将版本v4作为第一目标版本。
66.(第二种方法)
67.在本发明的一些实施例中，若通过上述步骤s131至s133获取的第二目标版本有多个，即有多个第二目标版本的第一数量值最大且相同，则对这些第二目标版本继续将缺陷严重级别第二高的第一缺陷作为第二缺陷，执行上述步骤s132至s133。依此类推，直至剩余最后的一个第二目标版本，或者所有缺陷严重级别比较完。
68.具体地，以缺陷严重级别为一般、中等及严重的三个级别为例，首先取修复“严重”级别缺陷最多的第二目标版本作为第一目标版本。如果修复“严重”级别缺陷的数量相同，则选取修复“中等”级别缺陷最多的第二目标版本作为第一目标版本。如果修复“中等”级别缺陷的数量相同，则选取修复“一般”级别缺陷最多的第二目标版本作为第一目标版本。
69.通过第一种方法或第二种方法，本发明的实施例，能够获取修复了当前版本中最迫切要修复的、影响级别较大的缺陷且修复缺陷数量较多的第一目标版本作为推荐升级版本，因此，相较于当前版本该推荐升级版本风险较低。由此，将待升级设备的微码升级至推荐的第一目标版本，能够有效地降低设备更新风险，从而提高设备更新后的稳定性。
70.(第三种方法)
71.在本发明的一些实施例中，若通过第一种方法或第二种方法获取的第二目标版本有多个，即有多个第二目标版本的第一数量值最大且相同，则基于缺陷严重级别继续比较
这些第二目标版本的自带缺陷(即未修复缺陷)的数量，筛选出第一目标版本，具体地包括如下步骤：
72.s134，对于每个第二目标版本，分别根据预设的缺陷与缺陷严重级别映射关系，确定第二目标版本的未修复缺陷列表中的每个缺陷的对应的缺陷严重级别，并统计最高缺陷严重级别对应的第二数量值；
73.s135，将最小第二数量值对应的第二目标版本作为第一目标版本。
74.由于微码版本在升级过程中，由于修复原有缺陷、增加功能或改进性能等原因，有可能会引入新的缺陷。通过第三种方法，可以选取出自带缺陷中最高缺陷严重级别对应的第二数量值最小的第二目标版本，作为推荐升级的第一目标版本。
75.由于该第一目标版本修复了当前版本中最迫切要修复的、影响级别较大的缺陷且修复缺陷数量较多，并且自带缺陷的影响相对较少，因此，该第一目标版本风险较低。由此，将待升级设备的微码升级至推荐的第一目标版本，能够有效地降低设备更新风险，从而提高设备更新后的稳定性。
76.(第四种方法)
77.在本发明的一些实施例中，若通过第三种方法获取的第二目标版本有多个，即有多个第二目标版本的第二数量值最小且相同，则对于这些第二目标版本，执行上述步骤s134但在上述步骤s134中统计缺陷严重级别第二高的缺陷，得到相应的第二数量值，并继续执行步骤s135。依此类推，直至剩余最后的一个第二目标版本，或者所有缺陷严重级别比较完。
78.具体地，基于缺陷严重等级，比对第二目标版本中的未修复缺陷的数量。以缺陷严重级别为一般、中等及严重的三个级别为例，首先取未修复“严重”级别缺陷最少的第二目标版本作为第一目标版本。如果未修复“严重”级别缺陷数目相同，则选取未修复“中等”级别缺陷最少的第二目标版本作为第一目标版本。如果未修复“中等”级别缺陷数目相同，则选取未修复“一般”级别缺陷最少的第二目标版本作为第一目标版本。
79.(第五种方法)
80.在本发明的一些实施例中，若通过上述方法获取的第二目标版本有多个，则继续比较第二目标版本的发布日期，根据发布日期确定出第一目标版本。
81.例如，选取发布时间超过预设时间(例如半年)但最近的第二目标版本作为第一目标版本。举例说明，如果有三个这样的第二目标版本，分别发布了一年，七个月，一个月，则选取超过半年但最近的那个第二目标版本作为第一目标版本；也就是说，将发布了七个月的第二目标版本作为第一目标版本。通常地，已发布一段时间的版本较为稳定，因此，将待升级设备的微码更新至该版本风险相对较小。
82.在上述第二种方法和/或第四方法中，也可以不比较完所有的缺陷严重级别。上述方法也可以适当地组合使用。例如，在本发明的一些实施例中，缺陷严重级别分为m个级别，则按缺陷严重级别从高至低取前n个(n≤m)级别，获取当前微码版本的这n个缺陷严重级别的未修复缺陷，通过微码信息库查找修复了这些未修复的第二目标版本。按照上述的方法，基于修复缺陷的严重级别，选取同缺陷严重级别下修复缺陷数量最多的第二目标版本作为第一目标版本。若有多个第二目标版本的每个缺陷严重级别的修复缺陷数量相同，则按缺陷严重级别从高至低取前p个(p≤m)级别，基于各版本未修复缺陷的严重级别，选取同缺陷
严重级别下未修复缺陷数量最少的第二目标版本作为第一目标版本。此时，若仍存在多个第二目标版本，前p个级别的未修复缺陷数量均相同，则根据第二目标版本的发布时间筛选出第一目标版本。
83.上述n和p可以根据实际需要进行配置，n和p可以设置为相同，也可以设置为不同。例如，在有四个缺陷严重等级的实施例中，设置n为1，p为2。即，首先在当前版本的后续版本中，筛选出修复了最高缺陷严重级别的缺陷数量最多的版本。然后，对于这些筛选出的版本，通过未修复缺陷列表获取缺陷严重级别最高的两个级别(最高和次高)的未修复缺陷(即自带缺陷)的数量。若仅有一个版本的最高缺陷严重级别的未修复缺陷数量最小，则将其作为第一目标版本。否则，若有多个版本的最高缺陷严重级别的未修复缺陷数量最小，则选取次高缺陷严重级别的未修复缺陷数量最小的版本作为第一目标版本。
84.在本发明的另一些实施例中，获取当前版本中未修复的所有缺陷，如后续版本vx中修复了当前版本中存在的缺陷，则根据这些缺陷对应的缺陷严重级别进行计分。例如，以缺陷严重级别为一般、中等及严重的三个级别为例，修复了两个严重级别的缺陷，则计分相应地累加两个100(即每修复一个严重级别加110)缺陷，修复一个中等级别的缺陷则计分累加30，修复一个一般级别的缺陷计分累加10。按照这样的方法，从后续版本中筛选出得分最高的候选版本(即第二目标版本)，然后，再按照类似的方法，从中选出未修复缺陷计分分值最小的那一个候选版本作为第一目标版本。也可以将修复缺陷计分分值视为正数，将未修复缺陷计分分值视为负数，直接相加或加权求和，将计算结果最大的第二目标版本作为第一目标版本。显然，也可以对计分统计时缺陷严重级别的范围进行限定，例如，以四个等级的缺陷严重级别为例，在对修复缺陷计分时，只计算前两个级别的缺陷，在对未修复缺陷计分时，仅计算最高级别的缺陷。
85.综上，在本发明的实施例中，通过上述方法，能够获取修复了当前版本中最迫切要修复的、影响级别较大的缺陷且修复缺陷数量较多的推荐版本，且该推荐版本中存在的缺陷的影响级别较低或同一缺陷严重级别的缺陷数量较少。由于推荐版本的风险相对较低，因此，使待升级设备的微码升级至推荐的第一目标版本，有效地降低了设备更新风险，提高了设备更新后的稳定性。
86.步骤s200，根据当前版本及第一目标版本，获取升级所需的预计升级总耗时。
87.具体地，参照图4，包括以下步骤：
88.步骤s210，根据当前版本及第一目标版本，获取相应的升级路径。
89.以图2为例，若当前版本为v1且第一目标版本为v4，则从第一目标版本v4开始，依次查找其前置版本，直到前置版本为当前版本v1，得到升级路径为：v1
→
v2
→
v3
→
v4。
90.步骤s230，获取升级路径中每个更新包的更新平均耗时。
91.上例的升级路径：v1
→
v2
→
v3
→
v4对应的更新包依次为以下三个更新：v1至v2的更新包、v2至v3的更新包、v3至v4的更新包；分别对应于图2中的第三行至最末行。由图2中可得出，每个更新包的更新平均耗时为：t1、t2、t3。
92.步骤s240，对每个更新包的更新平均耗时求和，得出预计升级总耗时。
93.上例的预计升级总耗时t为：t＝t1 t2 t3。
94.待升级设备在后续运行更新包时，会上报例如：前置版本、版本号、更新耗时(更新耗时可以是由更新开始时间及更新结束时间构成的形式)等信息，以在如图2的微码信息库
中定位至相应的项，更新对应的更新次数和更新平均耗时。这样，能够提高预计升级总耗时的计算精度，以便在后述的流程中获得更为准确的第一升级窗口时间，进一步地降低在用设备更新时对该在用设备的运行环境的不良影响。对于更新次数为0的更新包，可以为更新平均耗时设定一个默认值。在计算预计升级总耗时，使用该默认值，一旦接收到该更新包相应的上报数据，则根据上报数据替换该默认值。
95.步骤s300，根据待升级设备的端口流量的历史负载信息及预计升级总耗时，获取第一升级窗口时间。
96.具体地，参照图5，包括以下步骤s310至s330。
97.步骤s310，以预设频率采集待升级设备的每个端口的流量信息。这一步的目的是构建待升级设备的端口流量的历史负载信息。
98.步骤s320，获取预设时间段内的待升级设备的每个端口流量信息，并在该预设时间段内，以第一时间为步进，以第二时间为滑动窗口的长度，获取每个滑动窗口对应的待升级设备的所有端口的总流量信息。
99.图6中示出了滑动窗口的移动示意图，其中，第一时间为t1，第二时间为t2，预设时间段为[tp1,tp2]，tp1、tp2分别表示预设时间段的开始时间与结束时间。在图6中，预设时间段被示意为最大的虚线方框。显然，第一个滑动窗口(图6中的实线框)的时间段为tp1至tp1 t2。第二个滑动窗口对应于图6中的单点划线所界定的呈长方区域，相对于第一滑动窗口在时间上后移了第一时间t1；为了便于与第一滑动窗口区别，第二个滑动窗口被示意为比第一滑动窗口稍宽。此后，每一个滑动窗口相当前一滑动窗口在时间上后移第一时间t1。计算每个滑动窗口对应的时间段内的待升级设备的所有端口的总流量信息。例如，对于第一个滑动窗口，在从tp1至tp1 t2的时间段内，对该待升级设备的所有端口的流量信息求和，得到总流量信息。
[0100]
为防止窗口未覆盖预设时间段的所有区域，一般地，第一时间t1取小于等于第二时间t2的值。例如，在一个实施例中，在过去72小时内，以2小时为步进，6小时为滑动窗口，计算每个滑动窗口的总流量信息。
[0101]
步骤s330，基于每个滑动窗口对应的总流量信息，根据预计升级总耗时，获取端口总流量最低的第一升级窗口时间。
[0102]
具体地，在本发明的一个实施例中，若第二时间大于等于预计升级总耗时，则获取总流量最低的滑动窗口，根据该滑动窗口在预设时间段的位置，得出第一升级窗口时间。
[0103]
例如，预设时间段为当前时间之前的72小时内，第二时间为6小时，预计升级总耗时小于第二时间；并且步骤s320得到的总流量最低的滑动窗口，位于预设时间段的开始时间后的第19个小时至第25小时。则选定当前时间之后的第19个小时至第25小时作为第一升级窗口时间。
[0104]
在本实施例中，若第二时间小于预计升级总耗时，则根据预计升级总耗时合并时间段相邻的滑动窗口，以使合并后的滑动窗口对应的时间长度大于等于预计升级总耗时，获取总流量最低的合并后的滑动窗口，根据合并后的滑动窗口在预设时间段的位置，得出第一升级窗口时间。
[0105]
例如，预设时间段为当前时间之前的48小时，第二时间为0.5小时，预计升级总耗时为0.8小时。0.5《0.8《2
×
0.5，合并时间段相邻的两个滑动窗口，找出总流量最低的合并
后的滑动窗口，得出第一升级窗口时间。例如，把预设时间段的开始时间视为0，则将[0,0.5](第一数表示开始时间，第二数表示结束时间，下述相同)以及[0.5,1]的滑动窗口合并为[0,1]的滑动窗口，并将[0.5,1]以及[1,1.5]的滑动窗口合并为[1,1.5]的滑动窗口，后续依次类推。统计这些合并后的滑动窗口的总流量，获取总流量最新的合并后的滑动窗口，并根据该滑动窗口在预设时间段的位置，得出第一升级窗口时间。
[0106]
本实施例中，可以在预设升级总耗时计算出来之前，异步地执行上述步骤s310至s320，以提高计算效率。为此，可以根据历史经验将第二时间设置为合适的数值，以使通常情况下第二时间大于预设升级时间；例如，从最初始版本升级至当前最新版本(即执行全部版本的微码升级)所需要的平均时间为1小时，将第二时间设置为2小时。
[0107]
在本发明的另一实施例中，在计算出预计升级总耗时后，根据预计升级总耗时设置第二时间，在预设时间段中统计每个滑动窗口对应的总流量，此时，直接根据总流量最小的滑动窗口相对于预设时间段的位置，得出第一升级窗口时间。其中，根据预计升级总耗时设置第二时间，包括：例如，令第二时间为预计升级总耗时，或者令第二时间为预计升级总耗时向上取整后的整小时数(例如，预计升级总耗时为0.8小时，则令第二时间为1小时)，或者令第二时间为预计升级总耗时的倍数(例如，第二时间＝预计升级总耗时
×
1.5)。
[0108]
此外，在本发明的其它实施例中，在预设时间段内，以一定周期按如上所述的方法在每个周期内获取总流量最低的滑动窗口。然后，分析这些总流量最低的滑动窗口出现的规律，得出第一升级窗口时间。
[0109]
在分析这些滑动窗口时间时，可以将每个周期中偏离开始时间的相同时间的滑动窗口视为同一类型的滑动窗口。例如，当同一类型的滑动窗口在预设时间段内出现的次数最多时，依据该类型的滑动窗口得出第一升级窗口时间。举例说明，预设时间段为过去的30天内，上述一定周期为3天，即一共有10个周期，在筛选出来的总流量最低的滑动窗口中，相对于各自周期的开始时间为第10个小时的滑动窗口出现次数最多，则确定为总流量最低的时间为每隔三天的第10个小时，并将其设置为第一升级窗口时间。
[0110]
又例如，按照类型(即相对于各自周期的开始时间的偏离值)对于不同周期的滑动窗口对应的总流量进行加权求和，选取出结果最小的滑动窗口，得出第一升级窗口时间。其中，可以按照周期离当前时间最远，加权系数越小的方式来设定各周期对应的加权系数。
[0111]
综上，根据本发明的上述方法，可以根据待升级设备的端口流量的历史负载信息，选取端口流量较小的第一升级窗口时间供后续下载更新，以降低了用设备更新时对整个运行环境的不良影响，从而提高了设备所在的整个运行网络的稳健性。
[0112]
步骤s400，在第一升级窗口时间启动下载任务，下载待升级设备的当前版本至第一目标版本的更新包，更新待升级设备的微码版本。
[0113]
具体地，得到第一升级窗口时间后，配置下载任务，配置信息至少包括：预设启动时间、微码升级的目标版本、待升级设备的设备标识。然后，检测已到预设启动时间，启动下载任务，根据待升级设备的设备标识从待升级设备处获取待升级设备的微码的当前版本。下载从当前版本至第一目标版本的更新包，根据待升级设备的设备标识对待升级设备的微码进行升级。
[0114]
下载任务的配置信息还可以包括：待升级设备的微码的当前版本。这样在启动下载任务时，不再需要根据待升级设备的设备标识从待升级设备处获取待升级设备的微码的
当前版本，而是可以直接读取配置信息中的微码的当前版本，对当前版本至第一目标版本的更新包进行下载。然后，根据待升级设备的设备标识对待升级设备的微码进行升级。
[0115]
其中，下载任务的预设启动时间，可以是第一升级窗口时间[time1,time2]的开始时间time1。也可以根据预计升级总耗时t在第一升级窗口时间选定一个时间点作为下载任务的预设启动时间；例如，在第一升级窗口时间的开始时间time1至time2-t(结束时间减去预计升级总耗时)之间，随机选择一个时间点作为预设启动时间。
[0116]
本实施例的微码升级方法，通过微版本版本的未修复缺陷信息获取第一目标版本，可以获取风险相对较小的推荐升级目标版本；根据预计升级耗时及设备的端口负载信息获取第一升级窗口时间，可以获取在用设备对运行环境影响相对较小的升级窗口时间；通过在第一升级窗口时间内对设备的微码升级至第一目标版本，有效地降低了设备更新风险，提高了设备更新后的稳定性，降低了在用设备更新时对整个运行环境的不良影响，从而提高了设备所在的整个运行网络的稳健性。
[0117]
步骤s500，下载完更新包后，安装更新包，以更新待升级设备的微码版本。
[0118]
实施例2
[0119]
参照图7，本实施例提供一种装置700，包括：版本推荐模块710、升级耗时预估模块720、升级窗口推荐模块730和升级任务管理模块740。
[0120]
版本推荐模块710，用于接收待升级设备的微码的当前版本，获取当前版本对应的未修复缺陷信息，并根据当前版本对应的未修复缺陷信息来获取第一目标版本。该第一目标版本被发送给升级耗时预估模块720和升级任务管理模块740。
[0121]
升级耗时预估模块720接收待升级设备的微码的当前版本，以及，版本推荐模块710获取的第一目标版本。升级耗时预估模块720根据当前版本及第一目标版本，获取升级所需的预计升级总耗时，该预计升级总耗时被发送给升级窗口推荐模块730。
[0122]
升级窗口推荐模块730接收预计升级总耗时，并根据待升级设备的端口流量的历史负载信息，获取第一升级窗口时间。该第一升级窗口时间被发送给升级任务管理模块740。
[0123]
升级任务管理模块740根据第一升级窗口时间配置下载任务的启动时间，并配置微码更新的目标版本为第一目标版本。当到达下载任务预先配置的启动时间时，升级任务管理模块740启动下载任务，下载待升级设备的微码当前版本至第一目标版本的更新包，更新待升级设备的微码版本。
[0124]
希望理解的是，为了避免赘述，本实施例未涉及的内容可参照实施例1。
[0125]
本实施例的微码升级装置，通过微版本版本的未修复缺陷信息获取第一目标版本，可以获取风险相对较小的推荐升级目标版本；根据预计升级耗时及设备的端口负载信息获取第一升级窗口时间，可以获取在用设备对运行环境影响相对较小的升级窗口时间；通过在第一升级窗口时间内对设备的微码升级至第一目标版本，有效地降低了设备更新风险，提高了设备更新后的稳定性，降低了在用设备更新时对整个运行环境的不良影响，从而提高了设备所在的整个运行网络的稳健性。
[0126]
实施例3
[0127]
参照图8，本实施例提供一种设备，包括处理器810以及与处理器810耦接的存储器820，存储器820存储有可被处理器810执行的程序指令，处理器810执行存储器820存储的程
序指令时实现实施例1的微码升级方法。其中，处理器810还可以称为cpu(central processing unit，中央处理单元)。处理器810可能是一种集成电路芯片，具有信号的处理能力。处理器810还可以是通用处理器、数字信号处理器(dsp)、专用集成电路(asic)、现场可编程门阵列(fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。通用处理器可以是微处理器，或者，通用处理器还可以是任何常规的处理器等。存储器820可包括各种组件(例如，机器可读介质)，包括但不限于随机存取存储器组件、只读组件及其任意组合。存储器820还可包括：(例如，存储于一个或多个机器可读介质的)指令(例如，软件)；该指令实现本发明实施例的方法。
[0128]
希望理解的是，为了避免赘述，本实施例未涉及的内容可参照实施例1。
[0129]
本实施例的设备，与实施例1类似地，通过微版本版本的未修复缺陷信息获取推荐升级的第一目标版本，并根据预计升级耗时及设备的端口负载信息获取推荐升级的第一升级窗口时间，在第一升级窗口时间内对设备进行微码升级，有效地降低了设备更新风险，提高了设备更新后的稳定性，有效地降低了设备更新风险，提高了设备更新后的稳定性，降低了在用设备更新时对整个运行环境的不良影响，从而提高了设备所在的整个运行网络的稳健性。
[0130]
实施例4
[0131]
参照图9，本实施例提供一种存储介质，存储介质内存储有程序指令910，程序指令910被处理器执行时实现能够实现实施例1的微码升级方法。
[0132]
希望理解的是，为了避免赘述，本实施例未涉及的内容可参照实施例1。
[0133]
本实施例的设备，与实施例1类似地，通过微版本版本的未修复缺陷信息获取推荐升级的第一目标版本，并根据预计升级耗时及设备的端口负载信息获取推荐升级的第一升级窗口时间，在第一升级窗口时间内对设备进行微码升级，有效地降低了设备更新风险，提高了设备更新后的稳定性，有效地降低了设备更新风险，提高了设备更新后的稳定性，降低了在用设备更新时对整个运行环境的不良影响，从而提高了设备所在的整个运行网络的稳健性。
[0134]
本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、设备中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。
[0135]
在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质(简称存储介质)上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机可读介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于ram、rom、eeprom、闪存或其他存储器技术、cd-rom、数字多功能盘(dvd)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其
他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。
[0136]
以上参照附图说明了本发明的优选实施例，并非因此局限本发明的权利范围。本领域技术人员不脱离本发明的范围和实质内所作的任何修改、等同替换和改进，均应在本发明的权利范围之内。