• 2026 年 4 月 30 日之後， AWS Systems Manager CloudWatch Dashboard 將不再可用。客戶可以繼續使用 Amazon CloudWatch 主控台來檢視、建立和管理其 Amazon CloudWatch 儀表板，就像現在一樣。如需詳細資訊，請參閱 [Amazon CloudWatch Dashboard 文件](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)。 本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 用於修補的 SSM 命令文件：`AWS-RunPatchBaseline` AWS Systems Manager 支援 `AWS-RunPatchBaseline`、適用於 的 Systems Manager 文件 (SSM 文件）Patch Manager、 中的工具 AWS Systems Manager。此 SSM 文件在受管節點上執行與安全相關和其他更新類型的修補操作。執行文件時，如果未指定修補程式群組，則會使用指定為作業系統類型之「預設」的修補基準。否則，它會使用與修補程式群組相關聯的修補基準。如需有關修補程式群組的資訊，請參閱 [修補程式群組](patch-manager-patch-groups.md)。 您可以使用 `AWS-RunPatchBaseline` 文件以套用適用於作業系統和應用程式的修補程式。(在 Windows Server 上，應用程式支援僅限於由 Microsoft 發行的應用程式更新。) 本文件支援 Linux、macOS，以及 Windows Server 受管節點。此文件會為各個平台執行適當的動作。 **注意** Patch Manager 也支援舊版 SSM 文件 `AWS-ApplyPatchBaseline`。不過，此文件僅支援 Windows 受管節點上的修補。建議您改為使用 `AWS-RunPatchBaseline`，因為它支援在 Linux、macOS 和 Windows Server 受管節點上修補。SSM Agent 的 2.0.834.0 版或更新版本，才能使用 `AWS-RunPatchBaseline` 文件。 ------ #### [ Windows Server ] 在 Windows Server 受管節點上，`AWS-RunPatchBaseline` 文件會下載並叫用 PowerShell 模組，進而下載套用至受管節點的修補基準快照。此修補基準快照集包含已核准修補程式清單，這些修補程式是藉由查詢修補基準針對 Windows Server 更新服務 (WSUS) 伺服器進行編譯。此清單會傳遞至 Windows Update API，視需要控制下載和安裝核准的修補程式。 ------ #### [ Linux ] 在 Linux 受管節點上，`AWS-RunPatchBaseline` 文件會叫用 Python 模組，進而下載套用至受管節點的修補基準快照。此修補基準快照使用已定義的規則，以及已核准與已封鎖的修補程式清單，為各個節點類型推動適當的套件管理員： + Amazon Linux 2、Oracle Linux 和 RHEL 7 受管節點使用 YUM。針對 YUM 操作，Patch Manager 需要 `Python 2.6` 或更新版本的支援版本 (2.6 - 3.12)。Amazon Linux 2023 使用 DNF。針對 DNF 操作，Patch Manager 需要 `Python 2` 或 `Python 3` 的支援版本 (2.6 - 3.12)。 + RHEL 8 受管節點使用 DNF。針對 DNF 操作，Patch Manager 需要 `Python 2` 或 `Python 3` 的支援版本 (2.6 - 3.12)。(預設不會在 RHEL 8 上安裝兩個版本。您必須手動安裝其中一個。) + Debian Server 和 Ubuntu Server 執行個體使用 APT。針對 APT 操作，Patch Manager 需要 `Python 3` 的支援版本 (3.0 - 3.12)。 ------ #### [ macOS ] 在 macOS 受管節點上，`AWS-RunPatchBaseline` 文件會叫用 Python 模組，進而下載套用至受管節點的修補基準快照。接著，Python 子程序會叫用節點上的 AWS Command Line Interface (AWS CLI)，以擷取指定套件管理員的安裝和更新資訊，並為每個更新套件驅動適當的套件管理員。 ------ 每個快照都專屬於 AWS 帳戶、修補程式群組、作業系統和快照 ID。快照是透過預先簽署的 Amazon Simple Storage Service (Amazon S3) URL 交付，快照會在建立後 24 小時過期。不過，URL 過期後，如果想要將相同的快照內容套用到其他受管節點，則您可以在建立快照後最多 3 天內產生新的預先簽署 Amazon Simple Storage Service (Amazon S3) URL。若要這麼做，請使用 [https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html) 命令。 在安裝所有已核准且適用的更新，並視需要重新啟動之後，會在受管節點上產生修補程式合規資訊，並回報 Patch Manager。 **注意** 如果在 `AWS-RunPatchBaseline` 文件中將 `RebootOption` 參數設定為 `NoReboot`，則在執行 Patch Manager 後不會重新啟動受管節點。如需詳細資訊，請參閱[參數名稱：`RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption)。 如需有關檢視修補程式合規資料的詳細資訊，請參閱[關於修補程式合規](compliance-about.md#compliance-monitor-patch)。 ## `AWS-RunPatchBaseline` 參數 `AWS-RunPatchBaseline` 支援六個參數。`Operation` 參數是必要參數。`InstallOverrideList`、`BaselineOverride` 和 `RebootOption` 參數是選用的。`Snapshot-ID` 技術上是選用的，但我們建議您在維護時段之外執行 `AWS-RunPatchBaseline` 時提供自訂值，並讓 Patch Manager 在該文件做為維護時段操作的一部分執行時自動提供自訂值。 **Topics** + [ ### 參數名稱：`Operation` ](#patch-manager-aws-runpatchbaseline-parameters-operation) + [ ### 參數名稱：`AssociationId` ](#patch-manager-aws-runpatchbaseline-parameters-association-id) + [ ### 參數名稱：`Snapshot ID` ](#patch-manager-aws-runpatchbaseline-parameters-snapshot-id) + [ ### 參數名稱：`InstallOverrideList` ](#patch-manager-aws-runpatchbaseline-parameters-installoverridelist) + [ ### 參數名稱：`RebootOption` ](#patch-manager-aws-runpatchbaseline-parameters-norebootoption) + [ ### 參數名稱：`BaselineOverride` ](#patch-manager-aws-runpatchbaseline-parameters-baselineoverride) + [ ### 參數名稱：`StepTimeoutSeconds` ](#patch-manager-aws-runpatchbaseline-parameters-steptimeoutseconds) ### 參數名稱：`Operation` **用量**：必要。 **選項**：`Scan` \$1 `Install`。 Scan 當您選擇 `Scan` 選項時，`AWS-RunPatchBaseline` 會判斷受管節點的修補程式合規狀態，並將此資訊回報至 Patch Manager。`Scan` 不會提示要安裝的更新或需要重新啟動的受管節點。反之，此操作會識別遺漏了哪些已核准且適用於節點的更新。 安裝 當您選擇 `Install` 選項，`AWS-RunPatchBaseline` 會嘗試安裝受管節點上遺漏的已核准且適用的更新。在 `Install` 操作中產生的修補程式合規資訊不會列出任何遺失的更新，但如果因為任何原因導致未成功安裝更新，則可能會報告狀態為失敗的更新。每當更新安裝於受管節點時，節點將重新啟動，以確保安裝並啟動更新。(例外：如果 `AWS-RunPatchBaseline` 文件中的 `RebootOption` 參數設為 `NoReboot`，受管節點不會在 Patch Manager 執行之後重新啟動。如需詳細資訊，請參閱 [參數名稱：`RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption)。) 如果在 Patch Manager 更新受管節點*之前*已安裝基準規則指定的修補程式，系統可能無法如預期重新啟動。當使用者手動安裝修補程式，或由其他程式自動安裝 (例如 Ubuntu Server 上的 `unattended-upgrades` 套件) 時，就會發生這種情況。 ### 參數名稱：`AssociationId` **用量**：選用。 `AssociationId` 是 State Manager ( AWS Systems Manager中的工具) 中的現有關聯的 ID。它由 Patch Manager 使用，將合規資料新增至指定的關聯。此關聯與 [Quick Setup 中的修補程式政策中設定](quick-setup-patch-manager.md)的修補操作有關。 **注意** 使用 `AWS-RunPatchBaseline` 時，如果提供 `AssociationId` 值時發生修補程式政策基準覆寫，則修補會以 `PatchPolicy` 操作的形式完成，且 `AWS:ComplianceItem` 中報告的 `ExecutionType` 值也為 `PatchPolicy`。如果未提供任何 `AssociationId` 值，則會以 `Command` 操作形式完成修補，而且提交的 `AWS:ComplianceItem` 中報告的 `ExecutionType` 值也為 `Command`。 如果您還沒有想要使用的關聯，則可以透過執行 [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html) 命令建立關聯。 ### 參數名稱：`Snapshot ID` **用量**：選用。 `Snapshot ID` 是 Patch Manager 使用的唯一 ID (GUID)，確保在單一操作中修補的一組受管節點皆有一組完全相同的核准修補程式。雖然此參數定義為選用，但我們的最佳實務建議取決於您是否會在維護時段中執行 `AWS-RunPatchBaseline`，如下表所述。 **`AWS-RunPatchBaseline` 最佳實務** | Mode | 最佳實務 | 詳細資訊 | | --- | --- | --- | | 在維護時段內執行 AWS-RunPatchBaseline | 請勿提供快照 ID。Patch Manager 將會為您提供。 | 若您使用維護時段執行 `AWS-RunPatchBaseline`，您不應提供自己產生的快照 ID。在此案例中，Systems Manager 會根據維護時段執行 ID 提供 GUID 值。這可確保維護時段中所有 `AWS-RunPatchBaseline` 呼叫皆使用正確的 ID。 如果您在此情況下指定值，則請注意修補基準的快照可能不會保留超過 3 天。之後，即使您在快照過期後指定相同的 ID，仍將會產生新的快照。 | | 在維護時段外執行 AWS-RunPatchBaseline | 為快照 ID¹ 產生及指定自訂 GUID 值。 | 如果您不是使用維護時段執行 `AWS-RunPatchBaseline`，我們建議您為每個修補基準產生並指定唯一的快照 ID，特別是如果您在相同的操作中，在多個受管節點上執行 `AWS-RunPatchBaseline` 文件時。如果您在此情況下沒有指定 ID，Systems Manager 將為命令傳送至的每個受管節點產生不同的快照 ID。這可能會導致在受管節點間指定不同的修補程式集合。 例如，假設您正在直接透過 Run Command ( AWS Systems Manager中的工具) 執行 `AWS-RunPatchBaseline` 文件，並以包含 50 個受管節點的群組為目標。指定自訂快照 ID 會產生單一基準快照，用於評估和修補所有節點，以確保它們最終處於一致的狀態。 | | ¹您可以使用任何能產生 GUID 的工具來為快照 ID 參數產生一個值。例如，在 PowerShell，您可以使用 `New-Guid` cmdlet 產生 `12345699-9405-4f69-bc5e-9315aEXAMPLE` 格式的 GUID。 | ### 參數名稱：`InstallOverrideList` **用量**：選用。 使用 `InstallOverrideList`，您可以將 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL 指定至要安裝的修補程式清單。此修補程式安裝清單 (以 YAML 格式維護) 會覆寫目前預設修補基準指定的修補程式。這可讓您更精密地控制哪些修補程式將安裝於您的受管節點。 **重要** `InstallOverrideList` 檔案名稱不能包含下列字元：反引號 (`)、單引號 (')、雙引號 (") 和美元符號 (\$1)。 使用 `InstallOverrideList` 參數時的修補操作行為在 Linux 和 macOS 受管節點與 Windows Server 受管節點之間有所不同。在 Linux 與 macOS 上，Patch Manager 會嘗試套用 `InstallOverrideList` 修補程式清單中包含的修補程式，這些修補程式存在於節點上啟用的任何儲存庫中，無論修補程式是否符合修補基準規則。不過，*只有*在 `InstallOverrideList` 修補程式清單中的修補程式也符合修補基準規則時，才會在 Windows Server 節點上套用修補程式。 請注意，合規報告根據修補基準中的指定來反映修補程式狀態，而非您在 `InstallOverrideList` 合規清單中的指定。換言之，掃描操作會忽略 `InstallOverrideList` 參數。這是為了確保合規報告根據政策而非已核准用於特定修補操作的內容，來持續反映修補程式狀態。 **注意** 當您修補僅使用 IPv6 的節點時，請確定提供的 URL 可從節點連線。如果SSM Agent組態選項`UseDualStackEndpoint`設定為 `true`，則會在提供 S3 URL 時使用雙堆疊 S3 用戶端。[教學課程：修補僅限 IPv6 環境中的伺服器](patch-manager-server-patching-iPv6-tutorial.md) 如需將代理程式設定為使用 dualstack 的詳細資訊，請參閱 。 如需如何使用 `InstallOverrideList` 參數依不同的維護時段排程將不同類型的修補程式套用至目標群組的說明，同時繼續單一修補基準，請參閱[使用 `AWS-RunPatchBaseline` 或 `AWS-RunPatchBaselineAssociation` 中 InstallOverrideList 參數的範例案例](patch-manager-override-lists.md)。 **有效的 URL 格式** **注意** 如果您的檔案存放在公開可用的儲存貯體中，則可以指定 https URL 格式或 Amazon Simple Storage Service (Amazon S3) 路徑樣式的 URL。如果您的檔案存放在私有儲存貯體中，則必須指定 Amazon Simple Storage Service (Amazon S3) 路徑樣式的 URL。 + **https URL 格式**： ``` https://s3.aws-api-domain/amzn-s3-demo-bucket/my-windows-override-list.yaml ``` + **Amazon Simple Storage Service (Amazon S3) 路徑樣式的 URL**： ``` s3://amzn-s3-demo-bucket/my-windows-override-list.yaml ``` **有效的 YAML 內容格式** 您用於在清單中指定修補程式的格式，取決於您受管節點使用的作業系統。一般格式如下： ``` patches: - id: '{patch-d}' title: '{patch-title}' {additional-fields}:{values} ``` 雖然您可以在 YAML 檔案中提供額外的欄位，但是在修補程式操作過程中會略過這些欄位。 此外，我們建議您在 S3 儲存貯體中新增或更新清單之前，確認您的 YAML 檔案格式是有效的。如需 YAML 格式的詳細資訊，請參閱 [yaml.org](http://www.yaml.org)。有關驗證工具的選項，請執行 Web 搜尋「yaml 格式驗證工具」。 ------ #### [ Linux ] **id** **id** 欄位是必要的。利用它來使用套件名稱和架構以指定修補程式。例如：`'dhclient.x86_64'`。您可以在 id 中使用萬用字元以指示多個套件。例如：`'dhcp*'` 和 `'dhcp*1.*'`。 **Title** **標題**欄位是選用的，但是在 Linux 系統上，它提供額外的篩選功能。如果您使用**標題**，它應包含套件版本資訊，並使用以下其中一種格式： YUM/SUSE Linux Enterprise Server (SLES): ``` {name}.{architecture}:{epoch}:{version}-{release} ``` APT ``` {name}.{architecture}:{version} ``` 對於 Linux 修補程式標題，您可以在任何位置使用一或多個萬用字元以擴大相符套件的數量。例如：`'*32:9.8.2-0.*.rc1.57.amzn1'`。 例如： + apt 套件版本 1.2.25 目前已安裝於您的受管節點上，但現在有 1.2.27 可用。 + 您將 apt.amd64 版本 1.2.27 新增至修補程式清單。它取決於 apt utils.amd64 版本 1.2.27，但清單中指定的是 apt-utils.amd64 版本 1.2.25。 在此情況下，將會阻擋安裝 apt 版本 1.2.27，並回報為「Failed-NonCompliant」。 ------ #### [ Windows Server ] **id** **id** 欄位是必要的。利用它來使用 Microsoft 知識庫 ID (例如 KB2736693) 和 Microsoft 資訊安全佈告欄 ID (例如 MS17-023) 指定修補程式。 您想在 Windows 修補程式清單中提供的任何其他欄位都是選用的，並僅供自己參考。您可以使用其他欄位，例如**標題**、**分類**、**嚴重性**等，提供有關指定的修補程式的更多詳細資訊。 ------ #### [ macOS ] **id** **id** 欄位是必要的。**id** 欄位的值可以使用 `{package-name}.{package-version}` 格式或 \$1package\$1name\$1 格式。 ------ **範例修補程式清單** + **Amazon Linux 2** ``` patches: - id: 'kernel.x86_64' - id: 'bind*.x86_64' title: '39.11.4-26.P2.amzn2.5.2' id: 'glibc*' - id: 'dhclient*' title: '*4.2.5-58.amzn2' - id: 'dhcp*' title: '*4.2.5-77.amzn2' ``` + **Debian Server** ``` patches: - id: 'apparmor.amd64' title: '2.10.95-0ubuntu2.9' - id: 'cryptsetup.amd64' title: '*2:1.6.6-5ubuntu2.1' - id: 'cryptsetup-bin.*' title: '*2:1.6.6-5ubuntu2.1' - id: 'apt.amd64' title: '*1.2.27' - id: 'apt-utils.amd64' title: '*1.2.25' ``` + **macOS** ``` patches: - id: 'XProtectPlistConfigData' - id: 'MRTConfigData.1.61' - id: 'Command Line Tools for Xcode.11.5' - id: 'Gatekeeper Configuration Data' ``` + **Oracle Linux** ``` patches: - id: 'audit-libs.x86_64' title: '*2.8.5-4.el7' - id: 'curl.x86_64' title: '*.el7' - id: 'grub2.x86_64' title: 'grub2.x86_64:1:2.02-0.81.0.1.el7' - id: 'grub2.x86_64' title: 'grub2.x86_64:1:*-0.81.0.1.el7' ``` + **Red Hat Enterprise Linux (RHEL)** ``` patches: - id: 'NetworkManager.x86_64' title: '*1:1.10.2-14.el7_5' - id: 'NetworkManager-*.x86_64' title: '*1:1.10.2-14.el7_5' - id: 'audit.x86_64' title: '*0:2.8.1-3.el7' - id: 'dhclient.x86_64' title: '*.el7_5.1' - id: 'dhcp*.x86_64' title: '*12:5.2.5-68.el7' ``` + **SUSE Linux Enterprise Server (SLES)** ``` patches: - id: 'amazon-ssm-agent.x86_64' - id: 'binutils' title: '*0:2.26.1-9.12.1' - id: 'glibc*.x86_64' title: '*2.19*' - id: 'dhcp*' title: '0:4.3.3-9.1' - id: 'lib*' ``` + **Ubuntu Server ** ``` patches: - id: 'apparmor.amd64' title: '2.10.95-0ubuntu2.9' - id: 'cryptsetup.amd64' title: '*2:1.6.6-5ubuntu2.1' - id: 'cryptsetup-bin.*' title: '*2:1.6.6-5ubuntu2.1' - id: 'apt.amd64' title: '*1.2.27' - id: 'apt-utils.amd64' title: '*1.2.25' ``` + **Windows** ``` patches: - id: 'KB4284819' title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)' - id: 'KB4284833' - id: 'KB4284835' title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)' - id: 'KB4284880' - id: 'KB4338814' ``` ### 參數名稱：`RebootOption` **用量**：選用。 **選項**: `RebootIfNeeded` \$1 `NoReboot` **預設**：`RebootIfNeeded` **警告** 預設選項為 `RebootIfNeeded`。請務必選取適用於您使用案例的正確選項。例如，如果您的受管節點必須立即重新啟動才能完成組態程序，則請選擇 `RebootIfNeeded`。或者，如果您需要維持受管節點的可用性，直到排定的重新啟動時間，則請選擇 `NoReboot`。 **重要** 我們不建議使用 Patch Manager 修補 Amazon EMR (以前稱為 Amazon Elastic MapReduce) 中的叢集執行個體。特別是，請勿為 `RebootOption` 參數選取 `RebootIfNeeded` 選項。(此選項在用於修補 `AWS-RunPatchBaseline`、`AWS-RunPatchBaselineAssociation` 和 `AWS-RunPatchBaselineWithHooks` 的 SSM 命令文件中可用。) 使用 Patch Manager 進行修補時所使用的基礎命令使用 `yum` 和 `dnf` 命令。因此，相關操作會因套件的安裝方式而導致不相容。如需有關在 Amazon EMR 叢集上更新軟體的慣用方法的詳細資訊，請參閱《Amazon EMR 管理指南》**中的[使用 Amazon EMR 的預設 AMI](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html) 一節。 RebootIfNeeded 當您選擇 `RebootIfNeeded` 選項時，受管節點在下列情況下會重新啟動： + Patch Manager 已安裝一或多個修補程式。 Patch Manager 不會評估修補程式是否*需要*重新開機。即使修補程式不需要重新開機，系統也會重新開機。 + Patch Manager 偵測到一或多個修補程式在 `Install` 操作期間狀態為 `INSTALLED_PENDING_REBOOT`。 `INSTALLED_PENDING_REBOOT` 狀態可能表示上次執行 `Install` 操作時已選取 `NoReboot` 選項，或者自上次重新啟動受管節點後，已在 Patch Manager 外部安裝修補程式。 在這兩種情況下重新啟動受管節點，可確保更新的套件會從記憶體中清除，並在所有作業系統中保持修補和重新啟動行為一致。 NoReboot 當您選擇 `NoReboot` 選項時，即使受管節點在 `Install` 作業期間安裝了修補程式，Patch Manager 也不會重新啟動受管節點。如果您知道您的受管節點在套用修補程式之後不需要重新啟動，或是您在節點上執行的應用程式或程序不應因於修補操作重新啟動而中斷，則此選項非常有用。當您想要進一步控制受管節點重新啟動的時間時 (例如使用維護時段)，此選項也很有用。 如果您選擇 `NoReboot` 選項並安裝修補程式，則會為修補程式指派 `InstalledPendingReboot` 的狀態。但是，受管節點本身會標示為 `Non-Compliant`。重新啟動並執行 `Scan` 操作之後，受管節點狀態會更新為 `Compliant`。 `NoReboot` 選項只會防止作業系統層級的重新啟動。服務層級的重新啟動仍然可能在修補程序中發生。例如，Docker 更新後，即使啟用了 `NoReboot`，Amazon Elastic Container Service 等相依服務也可能自動重新啟動。如果您有不能中斷的重要服務，請考慮採取其他措施，例如暫時從服務中移除執行個體或在維護時段期間排程修補。 **修補程式安裝追蹤檔案**：若要追蹤修補程式安裝，特別是自上次系統重新啟動後已安裝的修補程式，Systems Manager 會在受管節點上維護檔案。 **重要** 請勿刪除或修改追蹤檔案。如果此檔案已刪除或損毀，則受管節點的修補程式合規報告會不正確。如果發生此情況，請重新啟動節點並執行修補程式掃描作業以還原檔案。 此追蹤檔案存放於受管節點的下列位置： + Linux 作業系統： + `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json` + `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json` + Windows Server 作業系統： + `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json` + `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json` ### 參數名稱：`BaselineOverride` **用量**：選用。 您可以使用 `BaselineOverride` 參數在執行時間定義修補偏好設定。此基準覆寫會作為 S3 儲存貯體中的 JSON 物件進行維護。它可確保修補操作使用符合主機作業系統所提供的基準，而不是從預設修補基準套用規則 **重要** `BaselineOverride` 檔案名稱不能包含下列字元：反引號 (`)、單引號 (')、雙引號 (") 和美元符號 (\$1)。 如需使用 `BaselineOverride` 參數的詳細資訊，請參閱 [使用 BaselineOverride 參數](patch-manager-baselineoverride-parameter.md)。 ### 參數名稱：`StepTimeoutSeconds` **用量**：必要。 在命令完成到被認定為失敗之間的秒數，即 1 至 36,000 秒 (10 小時) 之間。