一度動き出したシステムや設置されたアプライアンス、デバイスは簡単に修正やアップデートを適用できないことがある。特に本番環境にデプロイされた場合はそうなりやすい。しかし、問題の発生は最小限に抑えなければならない。そういった場合に使われる方法の一つに「再起動」がある。
→連載「PowerShell Core入門 - 基本コマンドの使い方」の過去回はこちらを参照。
ソフトウエアに「完璧」はほとんどない
「バグのない完璧なソフトウエアを開発する」――プログラムを書く者であれば誰しも考えることだが、そういったソフトウエアを開発できることはほとんどない。明らかにバグが入る余地がないくらいシンプルなソースコードでない限り、どこかの段階で問題は入り込んでくる。
しかも現在はソフトウエアスタックがとても厚い。一番下をハードウエアだとした場合、まずBIOSがあり、その先にOSがある。場合によってはここにハイパーバイザが加わり、OS自体が仮想環境で動作する。
そしてOSの提供する基本的なライブラリがあり、それらを利用するサードパーティ製ライブラリがあり、それらを使ったフレームワークやコンポーネントがあり、それらを使ったアプリケーションがあり、さらにそこで動作するソフトウエアを開発し、といった具合に、アプリケーションを開発している段階でソフトウエアはすでにかなりの層になっている。
そしてここにデータベースが加わったり、WebサービスやWeb APIが加わったりと、連動して動作するほかのソフトウエアが加わり、ネットワークも利用するといった具合に、さらに多くの状況と条件が加わる。こうなってくると、不具合が発生したときにどこに問題があるのか突き止めるのはとても難しくなってくる。
現場にはデバッグやアップデートの余裕がないことも
問題が発生した場合、原因を特定してソフトウエアを書き換えるというのが通常の対策となるが、状況によってはそれが不可能なことがある。
例えば発生する問題に再現性がないとか、すでに動作しているシステムを長期にわたって停止させることができないとか、不具合を修正することで別の不具合が発生した場合のリスクがあまりにも高すぎるとか、実際問題としてデバッグや書き換えができない現場というものも存在している。
また、こうしたケースはアプライアンスや組み込み機器にも存在している。すでにデプロイしてしまったアプライアンスのバージョンアップが何らかの理由で許されないとか（検証されたバージョンでなければ運用してもらえない、組み合わせ上ほかのバージョンへ変えることができないといったことが考えられる）、すでにサポートが終了して修正版ファームウェアが提供されていないとか、状況はさまざまだが、実際に起き得るケースだ。
しかし、発生する不具合には対処しなければならない。現場のオペレータやメンテナンス担当からすれば無茶を言わないでくれということになるのだが、こうした状況はそれほど珍しいことではない。
かなり効果的な手段「再起動」
こうした場合に使える運用方法の一つに「再起動」がある。原因を特定することができなくても、システムを再起動すると問題なく稼働するようになることは多い。対処療法にすぎないのだが、前述したような事情がある場合、再起動は有効な手段になる。
ある程度の運用をこなしていくと、どの程度の頻度でシステムを再起動すると円滑な稼働を継続できるのか見えてくることがある。それは1カ月ごとかもしれないし、1週間ごとかもしれないし、1日ごとかもしれない。手間と言えば手間だが、再起動によって問題が発生しなくなることがあるのは事実だ。
不具合の原因はいくつもあるのでここで全て説明できるものではないが、よくあるのがメモリリークやメモリ消費でのメモリ不足などだ。開発したシステムでメモリを確保したまま開放していないとか、ガベージコレクタがメモリを回収できるように後処理をしていないとか、そういった作り方をしていると、ある程度の時間運用するとどこかでメモリが不足してシステムが不具合を来たすことがある。
それ以外にも、運用当時のシステム負荷だと全く問題のなかったものが、年月を重ねてシステム負荷が高い状態が続いた結果リソースのキャパシティを超えて不具合を起こすようになることもある。
Windows11 24H2向け互換性問題に対応した緊急アップデート公開
