ITサービスマネージャ 2021年 春期 午後I 問題

共通の文章

複数の外部供給者に対する供給者管理に関する次の記述を読んで,RH 1~4に答 Ak K社は,医薬品メーカであり,医薬品の研究開発や製造を行っている。K社の研究 部には,研究開発を専門に行う従業員(以下,研究職員という)がおり,貸与され たPCを使用して研究開発を行っている。 K社の情報システム部は,社内システムの開発,保守,運用,及びサービスマネジ メントを行っている。社内システムの一つに研究開発管理システムがあり,研究開 発管理サービスとして研究職員にサービスを提供している。情報システム部は,研 究開発管理サービスのサービスデスクの機能の一部を,L社に外部委託している。L 社が行うサービスデスクの機能を図1に示す。 ・K社研究職員から,対象とするサービスに関する問合せ,パスワード変更など(以下,こ れらをサービス要求という)を電話又は電子メールで受け付ける。 ・サービスデスクの担当者は,ノウハウデータベース"を参照し,サービス要求を実現2?す る。 ・電話でのサービス受付時間帯は,平日の10時から18時までであり,電子メールでのサー ビス受付時間帯は24時間365日である。 ・サービス要求の実現は,平日の10時から18時30分までの間に行う。 ・ノウハウデータベースを参照しても実現できなかったサービス要求,及びノウハウデータ ベースに登録されていないサービス要求の内容を情報システム部に電子メールで送信す る。3) (1)電話での受付の場合は30分以内に送信する。 (2)電子メールでの受付の場合は次の時刻までに送信する。 ①平日の0時から10時までに受け付けたサービス要求は,同日の10時30分まで ②平日の10時から18時までに受け付けたサービス要求は,受付時刻から30分以内 @平日の18時から24時まで,又は休日に受け付けたサービス要求は,翌営業日の 10時30分まで 注りL社は,K社情報システム部が作成したサービス要求の実現方法についての指示書を ノウハウデータベースに登録している。 >サービス要求の実現とは,例えば,サービス要求が問合せの場合は回答を行うことで あり,サービス要求がパスワードの変更要求の場合は変更を行うことである。 3電子メールを受信した情報システム部は,サービス要求の対応をサービスデスクから 引き継ぎ,サービス要求を実現する。 図1 L社が行うサービスデスクの機能 _—3 ome: (MY AT LOR) K社の研究職員が作成した論文や研究資料は,これまでK社内のファイルサーバ に保管していたが,研究開発の効率向上のため,研究職員が自ら論文や研究資料を 登録し,研究部内の論文や研究資料を検索できるシステム(以下,検索システムと いう)を新規に開発した。 検索システムは,検索サーバ2台,データベースサーバ1 A,負荷分散装置(以 下,LBという)1台で構成され,平日の8時から22時まで稼働する。サーバ機器, LBはM社が納入し,設定した。また,アプリケーションプログラム(WF,APと いう)は,N社が設計し,製造した。 検索サービスの開始] 情報システム部は,検索システムを研究職員が利用する検索サービスとして提供 する。検索サービスのサービスデスク機能は,L社に外部委託する。また,情報シス テム部は,M社にシステム構成機器の管理サービスを,N社にAP管理サービスを, それぞれ外部委託し,支援を受けることにした。 情報システム部のITサービスマネージャであるP氏は,検索サービスの開始に向 けて,L社,M社及びN社(以下,それぞれをサプライヤ各社という)と必要とな る契約を検討した。また,情報システム部とサービスの顧客である研究部との間で 合意するサービスレベル項目とサービスレベル目標を検討した。 P氏は,研究部に対して検索サービスへの要求事項をヒアリングした。研究部の要 求事項は,次のとおりである。 ・検索サービスは,平日の8時から22時まで利用したい。 ・サービスデスクの電話受付は,平日の10時から18時までとしてほしい。 ・問合せの回答は,翌営業日の18時までにほしい。 ・検索を開始してから,5秒以内で検索結果を表示してほしい。 ・検索サービスを利用できない障害が発生した場合,2時間以内で検索サービスを 利用可能な状態にしてほしい。 P氏は,サプライヤ各社から提示された主な契約事項の案を表1にまとめた。 Rlサプライヤ各社から提示された主な契約事項の案 契約事項の案 Lit・サービスデスクの対象とするサービスに検索サービスを加える。 ・サービスデスクの機能は図1と同内容で行う。 ・情報システム部からの調査依頼,及びインシデントの解決の依頼を平日の8時 から22時まで受け付け,翌営業日の17時までに調査依頼の回答又はインシデ aieントの解決を行う。 ・調査の結果,システム構成機器の部品交換が必要と判明した場合,平日の8時 から22時までの間で部品交換を行う。ただし,平日の18時以降に部品交換が 必要と判明した場合は,翌営業日に対応を行う。 ・情報システム部からの調査依頼,及びインシデントの解決の依頼を平日の8時 から22時まで受け付け,翌営業日の17時までに調査依頼の回答又はインシデ N社ントの解決を行う。 ・APの不具合が判明した場合,APに対する改修を行う。改修スケジュールは改 修の規模を踏まえ,情報システム部と調整する。 P氏は,研究部の要求事項とサプライヤ各社から提示された主な契約事項の案に対 して,研究部,サプライヤ各社と調整を行った。特に,M社とは,(7)VATA 成機器の部品交換に関する契約事項の案についての調整を行った。 P氏は,サービスレベル項目とサービスレベル目標を検討し,情報システム部と研 究部で正式に合意することにした。P氏が検討したサービスレベル項目とサービスレ 1ベル目標は,表2のとおりであり,目標の達成状況は月次で集計する。 表2検索サービスのサービスレベル項目とサービスレベル目標(抜粋) 検索サービスのサービス提供時間。|平日の8時から22時まで |@|サービスデスク受付時間各(電話の場合)平日の10時から18時まで 検索サービスの応答時間5秒以内(900パーセンタイル値②) 注"受け付けたサービス要求を翌営業日18時までに実現した割合のこと 2パーセンタイル値とは,当該月の応答時間の累積信布において,応答時間がある数値 以下に含まれる百分率のこと。例えば,90パーセンタイル値とは,検索件数が100件存 在した場合,応答時間を早いものから順に並べたときに90番目に該当する値のこと 9インシデントが発生したときの受付から回復までを2時間以内で実施した割合のこと P氏は,サービスレベル目標について社内で調整を行い,情報システム部はサプラ ene 5 a イヤ各社と契約を締結した。また,サプライヤ各社は,各社間で直接契約を締結し ないので,P氏は,サプライヤ各社とのコミュニケーションの方法として,検索サー ビスに関する変更情報の共有,情報システム部と研究部とのサービスレベル報告会 議の議事録の送付,及び情報交換と討論を行う会議(以下、フォーラムという)を 行うととに心た。 [検索サービスで発生したインシデント〕 検索サービスが開始して3か月が経過した10月LAK,サービスデスクは利用者 から“検索結果が表示されるまで時間を要する"といった問合せを受け付けた。サ ービスデスクの担当者は,ノウハウデータベースを参照し,指示書に従って“しば らく待ってから再度検索してください。"と回答した。同様の問合せが,COR 20 分で10件発生した。そこで,最初に受け付けた問合せから20分経過して,サービ スデスクは,応答遅延の事象が多発している状況を情報システム部に電子メールで 送信した後,電話でも連絡した。連絡を受けたP氏は,発生している事象をインシ デントと判断した。情報システム部ではインシデントの解決方法が分からない事象 だったので,P氏は,M社とN社に調査及びインシデントの解決の依頼を行った。 N社は,検索サーバとデータベースサーバのログを使って調査を行ったが,特に不 具合は発見されなかった。M社が機器の調査を行ったところ,LBの動作が不安定に なっていることが判明し,M社は情報システム部にインシデントの回避策として, サービスを一旦停止し,LBの再起動を行ってサービスを再開する方法を提示した。 LBの再起動には10分程度必要であるとの内容であった。情報システム部は回避策 の実施を決定し,(イ)サプライヤ各社に通知した。情報システム部は回避策を実施 し,検索サービスを再開した。その結果,応答遅延の事象は発生しなくなった。最 初の応答遅延の問合せから検索サービス再開までに,1時間45分掛かった。 M社がLBの製品メーカに詳細な調査を依頼したところ,LBのファームウェアの 不具合で,間欠的な障害が発生すること,及び再発時はLBを再起動することで不安 定な状態を解消することができることが判明した。M社は,情報システム部に対し インシデントの原因,インシデント再発時の対処方法。及び製品メーカから問題を 解決するファームウェア改修版が提供され,検索サービスのLBのファームウェアの 変更が完了するまでに約3か月を要することを報告した。 ー6一 [応答時間の実績の集計] P氏は,10月分の検索サービスの応答時間の実績を集計した。10月の検索件数の 合計は5,000件であり,10月の応答時間の実績は表3のとおりであった。 表3 10月の応答時間の実績 wen|son|wo[soon|xan[oso|aso[am[aso|a00 注記例えば2.6秒など,記載していない応答時間の件数は0件である。 [検索サービスの改善〕 P氏は,サプライヤ各社とフォーラムを開催することにした。フォーラムで話し合 われた結果,ファームウェア改修版が提供されるまでに,LBの動作が不安定になる インシデントが発生する可能性が高いことから,インシデントが発生したときの処 置をインシデントモデルとしてあらかじめ決めておき,情報システム部とサプライ ヤ各社で共有することになった。M社はLBの製品メーカからの情報を基に,“10分 間で3件以上応答遅延の問合せが発生する場合は,LBの動作が不安定と判断できる” との見解を示した。そこで,今後このような事象が発生した場合,情報システム部 とサプライヤ各社は,インシデントモデルに定義された役割,インシデントプロセ スの活動,エスカレーションの手順などに従って,定義した時間内にインシデント の解決を図ることを目標こすることとした。サプライヤ各社との討論の結果は,改 善案としてまとめられた。P氏はサプライヤ各社の賛同を得て,今後の活動を決定し た。フォーラムで決定した検索サービスの改善案は表4のとおりである。 表4検索サービスの改善案 サービスの改善案 ・K社とサプライヤ各社でサービスレベルの達成状況,インシデント情報及びサ K社ービス要求実現の内容を共有できる仕組みを導入する。 ・研究部に対して,検索サービスの応答が遅いと感じた場合には,サービスデス クに連絡してもらうことを依頼する。 ”・10分間で3件以上,検索サービスの応答が遅いとの問合せを受け付けた場 合,サービスデスクは,|。| aa・検索システムで導入している機器のファームウェアなどに関する不具合の情 報,及び不具合に対するパッチ情報がないかどうかを定期的に確認する。 ・応答時間の実績集計を自動化するツールを作成する。 —_7— P氏は,表4の改善案について順次,実施していくことにした。また,P氏は,7 オーラムで行うサプライヤ各社の検討や活動が,(ウツ)サービスレベル目標を達成す るために有効と判断し,今後も定期的にフォーラムを開催することにした。

共通の文章

情報セキュリティの管理に関する次の記述を読んで,設問1,2に答えよ。 B社は,精密機械の製造・販売を行っている。精密機械の生産は,関東工場及び九 州工場で,毎週日曜日22:00から作業を開始し,その週の金曜日22:00まで連続で行 われている。B社生産部では,工場の生産活動に関わる計画及び管理を行っている。 [B社のシステム概要〕 B社情報システム部では,生産部の生産活動を支援する生産システム,社員からの メール送受信機能を担うメールシステム及びIT機器の構成情報を管理する構成管理 システムを運用している。関東工場及び九州工場のPCは,それぞれの工場に勤務す る生産部及び情報システム部の部員が使用する。B社のシステム構成を図1に,BH のシステム概要を表1に示す。 関東工場|—_ 生産サーバaサーバしっーー iE ase) 務LANインターネット SEBLANのうー |PC|…|PC 業務LAN 九州工場 _.||DBサーバ|LANES =e)||a Si SSHテッラ サーバ 保守LAN 業務LAN 業務LAN FW:ファイアウォールDB:データベース 注り業務LANと保守LANの接続・切断を制御するスイッチ 図1 B社のシステム構成 ea 9— 表1 B社のシステム概要 ・生産システムは,関東工場の生産サーバGE),DBサーバGE)及び九州工場のバックアップ サーバで構成される。 ・関東工場及び九州工場に勤務する生産部の部員が,PCを使って生産システムを利用する。 ・関東工場の生産サーバ(正)で,毎週日曜日22:00から金曜日22:00までのオンライン処理を実 行する。オンライン処理では,DBサーバ(正)の生産DBを更新し,データ更新ログを生産サ ーバ(正)のログファイルに記録する。 ・毎週金曜日22:00から24:00まで週次バッチ処理を実行する。週次バッチ処理の最終工程で,DB サーバ(正)の生産DBのデータを九州工場のバックアップサーバにフルバックアップする。こ 生産システのバックアップ処理は30分で完了する。 ム・オンライン処理実行中の0:00,8:00及び16:00に定期バッチ処理を実行する。定期バッチ処理で は,処理の開始時刻から8時間前までのデータ更新ログを対象としてバックアップサーバにコピ ーする。この処理は30分で完了する。 ・保守LANに接続されている生産サーバ(副)及びDBサーバ(BI)(以下,これらを副サーバ 群という)は,土曜日の日中を除いてLAN切替スイッチによって業務LANから切り離されてお り,生産システムのプログラムの開発とテストに使用される。テストが完了したプログラムは, 土曜日の日中に生産サーバ(正)に展開される。 ・障害が発生し,生産システムが長時間使用できない場合は,保守LANを業務LANに接続し,副 サーバ和群を稼働環境として使用することができる。 ・社内及び社外との電子メール送受信が,メールサーバで処理される。 テム ・構成管理システムでは,B社で使用するサーバ及びPCの構成情報を構成管理サーバに登録して いる。全てのサーバ及び全てのPCには,エージェントプログラムが導入されていて,業務LAN 上のサーバ及びPCの構成情報の変化を検出した場合,エージェントプログラムは構成管理サー 構成管理シバに通知し,構成管理システムが構成情報を更新する。保守LAN上のサーバ及びPCの場合は, ステム土曜日の日中に構成情報を更新する。 ・構成情報には,OSセキュリティパッチ(以下,OSパッチという)の適用状況,及びマルウェア 対策用のマルウェア定義ファイル(以下,マルウェア定義という)の更新状況が分かるマルウェ ア定義の版の情報が含まれる。 [情報セキュリティ対策の概要〕 情報システム部のセキュリティ管理課は,情報セキュリティ管理を担当している。 セキュリティ管理課は,情報セキュリティ運用支援サービスを提供している会社 (以下,C社という)と情報セキュリティサービスを契約している。C社がB社に 提供しているサービスの内容は,次のとおりである。 ・マルウェア対策ソフトウェア(以下,対策ソフトという)をB社に提供してお り,B社の全てのサーバ及び全てのPCにはC社の対策ソフトが導入されてい る。 ぜい ・0Sベンダと連携して,OSの脆弱性に関する情報を収集し,B社に適切な助言を 行う。 ・情報セキュリティインシデント対策の対応方針や手順の策定を支援する。 情報システム部の担当者は,平日600に,OSベンダから最新のOSパッチが公開 されているかどうかを確認する。サーバのOSパッチが公開されている場合は,図2 に示す手順に従って,PCのOSパッチが公開されている場合は,図3に示す手順に 従って,それぞれOSパッチを適用する。 ・(当日6:00て7:00)九州工場の業務LANに接続されているPCを使って最新のOSパッチを入手し,外部 記憶媒体に保存する。保守LAN上の副サーバ群に,外部記憶媒体に保存した最新の0Sパッチをインス トールし,再起動する。各サーバが正常に動作することを確認する。 ・(当日7:30て10:00)副サーバ和群を稼働環境として使用し,保守LAN上で生産システムのオンライン処理 が正常に稼働することを確認する。 ・(当日10:00て10:30)業務LAN上のバックアップサーバに,最新のOSパッチをインストールし,再起 動する。バックアップサーバが正常に動作することを確認する。 ・(土曜日9.00て10:00)確認が完了した最新のOSパッチを,業務LAN上の生産サーバ(正)及びDBサー バ(正)にインストールし,再起動する。業務LAN上で生産システムが正常に稼働することを確認する。 注記図は,生産システムに関わるサーバについての手順の抜粋である。 図2サーバの0Sパッチの適用手順 ・(当日7:00て7:30)九州工場の業務LANに接続されているPCを使って最新のOSパッチを入手し,外部 記憶媒体に保存する。保守LAN上のPCに最新のOSパッチをインストールし,再起動する。PCが正常 に動作することを確認する。 ・(当日11:.00て12:00)保守LAN EC,最新のOSパッチを適用したPCを使って生産システムのオンライ ン処理が正常に利用できることを確認する。 ・(当日13:00て15:00)確認が完了した最新のOSパッチを,業務LANに接続された稼働中のPCにインス トールイメージとして配付する。 注記使用しているPCへのOSパッチの適用は,PCの再起動を契機として実施される。社員がPCを再起動 する際に,自動でインストールが行われ,OSパッチが適用される。関東工場及び九州工場の生産部では, 平日夜間もPCを利用しているので,PCのシャットダウンは,金曜日の22:00に実施され,その後PCを 再起動することで,OSパッチが適用される。 図3 PCの0Sパッチの適用手順 また,C社から最新のマルウェア定義が提供されている場合は,最新のマルウェア 定義が提供される都度,次の対応を行う。 ・業務LANに接続されている機器については,マルウェア定義が自動的に配信さ れ,マルウェア定義が更新される。 ・保守LANに接続されている機器については,情報システム部の部員が,OSパ ッチの入手と同じ方法を使ってマルウェア定義を入手し,マルウェア定義を手 動で更新する。 [情報セキュリティインシデントの発生] 2020年9月15日(火)10:00に,生産システムの利用者からセキュリティ管理課 に情報セキュリティインシデント(以下,今回インシデントという)の発生連絡が あった。今回インシデントの対応状況を表2に示す。 表2今回イオインシデントの対応状況 ・関東工場のPCの利用者(以下,通告者という)からセキュリティ管理課こに“PCに保存したフ ‘eeァイルが意図せず暗号化されておりファイルを開くことができない。”"と,電話があった。セキ 7ュユリティ管理課のITサービスマネージャのD氏は,通告者に対しPCを業務LANから切り離す ように依頼した。 ・インシデント対応チームが発足され,D氏が対応を指揮することになった。C社の技術者から “今回インシデントは,9月7日(月)に他社で発生したランサムウェアの感染例に似ている。 B社社内にマルウェアが拡散しているリスクがある。業務LANに接続されている全てのサーバ 10:30及び全てのPCを業務LANから切り離す必要がある。”と,D氏に連絡が入った。D氏は,経営 ,幹部に状況を報告し対策実施の了解を得た。サーバ及びPCは,業務LANから切り離され,生 産システムは停止した。 ・生産部からD氏に,“今月の生産計画を達成するためには,遅くとも本日の18:00までに生産シ ステムを稼働する必要がある。”との要請が入った。 ・D氏が調査したところ,通告者が9月14日(A)9:45頃に不審な電子メール(以下,不審メー ・D氏は,通告者が開封した添付ファイルをCHIRAL,支援を要請した。 ・C社の技術者から,次の報告があった。 ①当該の添付ファイルは,ランサムウェアである。他社で発生したランサムウェアに似てい るが別のランサムウェアである。このランサムウェアは,感染から24時間以内に,感染した 機器のストレージに保存されたファイルの暗号化を開始する。感染した機器から,LANに接 13:00続している他の機器にOSの脆弱性を利用して攻撃を行い,短時間で急速に感染を広める。 @今回のランサムウェアの攻撃は,OSベンダが9月14日3:00に公開した最新のOSパッチ を適用することによって,回避できる。 ③今回のランサムウェアに対応できる最新のマルウェア定義の版を,本日の16:00に提供で きる。 ・D氏は,復旧計画の検討を行った。 ・まず,D氏は生産サーバ(正)及びDBサーバ(正)を使用して,生産システムを再開する方法 を検討した。16:00以降,最新のマルウェア定義の版で対策ソフトの機能を使って,マルウェア 感染の有無を確認する作業を行うことになるが,この作業には2時間30分必要となる。その TS&,BHO OSパッチを適用するが,完了予定時刻は19:00となるので,生産部から要請されて "いる18:00までに生産システムを稼働できない。 ・次に,D氏は,災害時立上げ計画!に基づいて,九州工場の副サーバ群を使って生産システム を稼働させる案の検討を開始した。副サーバ和群及びバックアップサーバに,図2の手順によっ て,最新のOSパッチが9月14日10:30までに導入され,必要な確認作業が完了していること を確認した。 表2今回イオインシデントの対応状況(続き) 経緯と対応 D氏は,復旧計画を次のとおり作成した。 ・生産システムの復旧(16:00に作業を開始し,18:00までに作業を完了する) ①生産サーバ(正)及びDBサーバ(正)の代替機として,(7)副サーバ群を起動する。 @$[』。|] $[~ゎ|] ④LAN切替スイッチを使って保守LANを業務LANに接続する。 ©バックアップサーバから生産DBのフルバックアップをDBサーバ(副)にコピーする。 ©バックアップサーバのデータ更新ログを使って,DBサーバ(Bl)を8:00の状態に復元す 14:00る。 ⑦生産システムのオンライン処理を開始する。 8:00から生産システムが停止した時点までのデータは,生産部員がデータを再投入する。 ・業務LANから切り離されたPCの復旧(16:00から18:00までの間にPC利用者が対応する) DM PCには最新の0Sパッチのインストールイメージが配付されているので,PCを再起動し, 最新のOSパッチが適用されている状態とする。 ②PCのマルウェア定義を最新の版に更新し,マルウェア感染の有無を確認する。感染してい る場合は,マルウェアを駆除する。 ③PCを業務LANに接続する(生産システムの利用は,18:00からとする)。 ・D氏は,復旧計画を経営幹部に説明し,了解を得た。 ・D氏は,C社から最新のマルウェア定義の版を受領したのち,復旧計画の作業を開始した。 ・復旧計画の全ての作業を完了した。 SE)災害時立上げ計画とは,大規模地震などの災害が発生し,関東工場が被災したときに,九州工場の各 サーバを使って生産システムを稼働させる計画のことである。 [問題点と対策〕 D氏は,今回インシデントの対応を振り返り,C社の技術者の支援も得て,情報セ キュリティに関する現状の問題点と対策案を表3のとおり整理した。 表3現状の問題点と対策案(抜粋) 社員が,不審メールに添付されているファイル|B社の全社員を対象に,不審メール受信時の対応 1を十分確認せずに開封してしまう。教育をegラーニングで定期的に実施する。また, 図4に示す不審メール対応訓練を実施する。 セキュリティ管理課では,今回のように添付フ|図4に示す不審メール対応訓練を行うことによっ 2ァイルを誤って開封してしまう社員がどのくら|て,(イ)現状を把握する。 いの割合でいるか,現状を把握できていない、。 。|セキュリティ管理課では,最新のOSパッチが[|に|を使って,PCの08パッチ 適用されていないPCを把握していない。の適用状況を把握する。 4と,バックアップのデータが利用できなくな る。 Pe Se ・関連会社のメールアドレスを装って,SMEAR L AMM—ESHA BATS.MBS IC ・業務LANに集計サーバを設置し,社員が不審メールと判断できずに添付ファイルを開封した場合は,開 封した社員のメールアドレスの情報が自動で集計サーバに送信されるシステムを構築する。 はファイルを添付して,本文に添付ファイルの開封を促すメッセージを記載しておく。 図4不審メール対応訓練

共通の文章

データセンタのファシリティマネジメントに関する次の記述を読んで,設問1<3 に答えよ。 電子機器部品メーカの情報システム子会社であるW社は,自社データセンタ(以 下,DCという)で,自社業務に使用する各システムを稼働させている。 DCにはコンピュータ室が2室あり,それぞれのコンピュータ室にはラックが設置 され,サーバが収容されている。DCには,ファシリティマネジメント部(以下, FM部という)とシステム運用部があり,事務室で執務している。FM部は,24時間 のシフト体制で担当者が2名常駐し,DC設備の監視と管理を行っている。システム 運用部は,24時間のシフト体制ですペレータが4名常駐し,システムの運用と管理 を行っている。 (DCの電力供給設備 DCは,常用電源として電力会社から電力供給を受けている。電力会社からの電力 供給に異常が発生した場合に備え,予備電源として自家発電設備(以下,自家発と いう)を設置している。 電力会社からの電力供給で瞬断が発生した場合や,自家発による電力供給に切替 えを行う場合には,コンピュータ室への電力供給が一時的に停止する。これに備え て,蓄電池を持つUPSをラックに接続して,UPSからラックに電力供給を行ってい る。UPSからラックなどの電力負荷機器に連続給電できる時間(以下,停電補償時 間という)は,負荷の容量に応じて変動する。 UPSは,一部を冗長構成にするための予備のUPSを含めて,7台設置している。 UPSで機器故障が発生した場合は,無瞬断切替え装置によって自動的に予備のUPS からの電力供給に切り替わる。 また,近年のラック内機器の高集積化に伴う発熱量増加を受けて,コンピュータ 室に設置している空調機が全て停止することを防ぐために,一部の空調機もUPSに 接続して,UPSから空調機に電力供給を行うこととしている。 DCの電力供給設備と電力負荷機器を図1に示す。 ー15一 ーーー...介代毅設備loo.anne ARE ||YES 381 |oe emia(600)|! |roトモ|空調機2(600)|:| 電カ会社a[ラック1 Ge00)|| |ーーラッ5 Ga|| :-acon|Siete ne| |(7,500)a oo|空調機3(600)|| |一|調機4(600)| !LM ft 073 6| UB]-o-o-:HeBfeIR ME neo:SE:OE 注記1 UPS-A,UPS-B,UPS-C,UPS-D,UPS-E,UPS-F,UPS-Gは,UPS機器名称である。 なお,UPS-C,UPS-D,UPS-Gは予備のUPS機器である。 注記2空調機2と空調機4は予備の空調機である。 注記3自家発の括弧内に記載された数値は,出力容量(kVA:キロボルトアンペア)を, 電力負荷機器の括弧内に記載された数値は,消費電力(kW:キロワット)を表す。 注記4消費電力が1kWの電力負荷機器には,出力容量1.25kVAの電力供給設備が必要 である。 図1 DCの電力供給設備と電力負荷機器 〔電力供給設備の課題〕 Ql)自家発の課題 自家発は,出力容量7.500kVAの電力供給能力があるが,W社の事業拡大に伴 い計画された2021年度のサーバ機器増強計画に基づき,電力供給設備の増強の 必要性有無を検討した。その結果,サーバ機器を計画どおりに増強すると,(ア) 自家発の供給電力が不足することが分かり,自家発の増強を計画した。 2021年度のサーバ機器増強計画を表1に示す。 表1 2021年度のサーバ機器増強計画 単位kW |消費電力|300|300|100|200| e0O0|900| 例5月に消費電力が300kWのサーバ機器を追加し,ラック3に収容する。 (2)UPSの停電補償時間の課題 電力会社からの電力供給が一定時間停止した場合,自家発が自動で起動する。 自家発の機器故障などで自動起動に失敗した場合は,FM部の担当者が自家発を 手動で起動する必要がある。2018年に自家発を設置したとき,“電力会社からの 電力供給停止から,自家発を手動で切り替えて電力の供給が開始されるまでの 時間"(以下,自家発切替え時間という)を測定したところ,測定結果は5分で あった。 UPSは,電力負荷機器の消費電力及び自家発切替え時間を基に選定した。こ こで,1kWの消費電力の電力負荷機器には,1.25kVAの出力容量のUPSが必要 であるとして検討した。選定の結果,UPS-A,UPS-B,UPS-C,UPS-D及び UPS-Eの5台は,UPSタイプ①のUPSを,UPS-F及びUPS-Gの2台は,UPS タイプ②のUPSの採用を決定し,設置した。それぞれのタイプ別の停電補償時 間は,表2,3のとおりである。 表2 UPSタイプ①の停電補償時間表3 UPSタイプ②の停電補償時間 |wcww|es 例OkVAより大きく1.500kVA以下を表す。Gl”OkVAより大きく900kVA以下を表す。 2020年2月に自家発の手動起動のテストを実施したところ,FM部担当者に よっては手動起動に最大20分掛かることが分かった。FM部は,自家発切替え 時間の短縮を目的にFM部担当者の訓練を行うこととした。同時に,UPSの停 電補償時間に問題がないかを確認するために,表1の2021年度のサーび機器増 強計画どおりに機器を増強した場合の必要な停電補償時間を20分とする条件で ー17一 検討した。そこで,予備のUPS機器を除いたUPS-A,UPS-B,UPS-E,UPS-F を対象に検討した結果,これらのUPSでは,(イ)必要な停電補償時間を満たせ なくなる時期が来ることから,FM部は,UPS更新計画を策定することとした。 (UPSの増設〕 W社は,電子機器部品にセンサや通信モジュールを取り付けることで,リアルタ イムで稼働状況データを収集するIoTシステム(以下,Tシステムという)を2022 年4月に稼働させることになった。Tシステムのサーボ機器は複数必要であり,ラッ ク1及びラック3に分散して収容する。Tシステムが求める高い可用性を実現するた めに,UPSの冗長性を強化することとした。そこで,メンテナンスなどせで一方の UPSを停止したときに,他方のUPSで障害が発生したときに備えて,電力供給を継 続するために,(ウ)予備のUPSを1台増設することを計画した。 〔空調機障害の発生] FM部では,空調機で障害が発生した場合は,表4に示す空調機倍止時の影響度判 定と対応に従って,対応を行うこととしている。 表4空調機停止時の影響度判定と対応 .ve.seriassie W社の全社員に障害発生メールを送信する。全社横断の皿 1急対策チームを立ち上げ,FM部の部長が責任者として,チ ~ームを指揮し,組織的な対応を行う。 FM部の全部員に障害発生メールを送信する。FM部員がラ 中一部のラック内の温度が,ック内冷却対応りと,空調機の復旧対応を行う。同時に しきい値を超過ラック内サーバに異常がながいかをオペレータに確認し,B 常がある場合は,オペレータと連携して復旧対応を行う。 -_FM部の全部員に注意喚起の障害発生メールを送信する。 注りポータプブル空調機を用いた冷却などの暫定対応を行う。 2020年10月11日23時頃,ラック1内の温度が上昇し,ラック1に収容されてい る,社内向けの勤怠管理システムを運用するサーバ(QE,サーバ1という)DE 止した。勤怠管理システムを使ったサービスは,10月11日0時から10月12日8時 までが計画停止時間帯であったので,サーバ停止による業務への影響は発生しなか うた。 今回のラック1内の温度上昇は,電力会社からの電力供給で瞬断が発生し,空調 機1が停止したことが原因であった。空調機2は保守作業中で使用できず,空調機1 の正常性確認を行ったことで再稼働するまで50分掛かったので,ラック1の温度が 上昇した。幸い,停止したサーバはサーバ1だけであった。10月11日22時30分に 発生した空調機障害の対応経緯を,表5に示す。 表5空調機障害の対応経緯 10/11|空調機1停止(FM部)空調機1の停止アラートを検知し,WRC UT,空調 22:30機の復旧対応を開始した。 ラック1内の温度が(FM部)空調機1の再稼働に時間が掛かり,ラック1内の温度が上昇 LAL,しきい値を|した。ラック1内の温度がしきい値を超過したので,影響度を中とし 超過て,ラック1の冷却対応を開始した。同時に,ラック1に収容されたサ ーバに影響が出ていないか,オペレータに確認を依頼した。 (システム運用部)オペレータはサーバの状態に異常がないことを確認 し,FM部に報告した。 回EE 23:00イメージバックアッ(システム運用部)オペレータがサーバ1の停止を検知した。ラック1 1が停止ステムの担当者であるY氏とFM部に連絡した。Y氏は自宅からサーバ プリ取得中にサーバ|に収容されているサーバ1が停止したことを,オペレータは勤怠管理シ 23:10ラック1内の温度が(FM部)ポータブル空調機を用いてラック1の冷却対応を行った。ラ 正常化ック1内の温度が正常に戻ったことを確認し,暫定対応が完了したこと をオペレータに連絡した。 (システム運用部)オペレータがY氏に,ラック1内の温度が正常に戻 ったことを連絡した。Y氏はオペレータに,サーバ1の再起動を指示 し,オペレータがサーバ1の再起動を開始した。 度が正常であることを確認した。 | 23:25サーバ1が正常起動(システム運用部)Y氏はオペレータに,サーバ1のイメージバックア ップの再取得を指示し,オペレータはイメージバックアップの再取得を 10/12|イメージバックアッ|(システム運用部)オペレータがイメージバックアップの再取得が正常 0:30プ再取得が正常終了|に終了したことを確認し,Y氏に報告した。サーバ1が正常に戻ったこ とを,オペレータがFM部に連絡した。 (FM部)サーバ1が正常に戻ったことで,空調機1停止の対応を終了 UVES | 8:00勤怠管理システムの|(システム運用部)勤怠管理システムのオンライン処理の開始時点で, オンライン処理開始|システムが異常終了した。Y氏は不具合の起きたファイルを回復し,オ Pe Laysrvmmme||トリコ0 SE月次で実施する保守作業の最終工程でイメージバックアップを取得している。 勤怠管理システムの|(省略) 10月12日8:00に勤怠管理システムのオンライン処理が開始しなかったのは,前 日の23:00にサーバ1が停止した際に発生したファイルの内容に関する不具合が原因 であった。勤怠管理システムの担当者のY氏は,10月12日8:00に出社したデータ ベースの技術者に異常終了について相談した結果,サーバ停止の状況によってはフ ァイルの内容に不具合が発生することがあることを伝えられ,問題の原因が判明し, 復旧対応を行った。 FM部は,空調機2の保守作業中に空調機1が停止したことは大きな問題と捉え, (エ)空調機佑止の再発防止策を検討することとなった。また,表5の対応を振り 返り,サーバ停止を検知した時点で,関係者を巻き込んで組織的な対応を行うべき であったことから,今後は影響度を高として対応することとし,(A)表4の判定基 準を見直すことにした。