パッチ適用による障害を避ける確実な方法：パッチ適用を巡る諸問題【後編】

多くの管理者を悩ませる、パッチ適用時に不可解な理由で発生する障害。これを確実に避ける方法とは何か。

[Peter Ray Allison，Computer Weekly]

iStock.com/AntonioGuillem

　前編（「迅速なパッチ適用」を妨げる事業部門）では、パッチ適用を妨げる事業部門の問題を紹介した。後編では、自動化を巡る勘違いとテスト戦略について解説する。

コスト削減

　パッチの適用に関するコストの一部は、サードパーティーツールや自動化で緩和できる可能性がある。ただし、そのプロセスが最適であり、悪い習慣が誤って引き継がれないように注意する必要がある。

　「サードパーティーのパッチ管理ソフトウェアを購入しても、既に行っていることを自動化するのであれば単に無駄なものを自動化しているだけだ。戦略が妥当ではなかったり、適切に考え抜いていなかったり、十分なドキュメントを用意していなかったりする場合は、ただ費用をかけているだけで、以前と同じ過ちを繰り返すことになる」（ギレスピー氏）

関連記事

もう管理しきれない……企業にまん延する「パッチ疲れ」が深刻化

管理できないと言わせない、パッチ管理の5つのTips

IT管理者によるWindows Updateの制御方法

実用レベルに達したSUSEのライブパッチ機能、あるとないでは大違いの理由

Linux vs. UNIX──ホットパッチ機能はLinuxがリード

　既存のパッチプロセスを最適化もせずに自動化するだけでは、効果を最大限に引き出す可能性はほとんどない。

　既存のパッチ適用プロセスの全段階を再確認することが時間とリソースの効率的な使用につながり、冗長な段階を排除できる。

　サードパーティーツールは便利だが、全面的に頼るべきではない。そのツールが特定の欠陥や脆弱性を見落とすと盲点が生まれる恐れがある。

テスト

　システムのアップデートには常にリスクが伴う。だが、綿密なテストプロセスによってそのリスクを軽減できる。それでもエラーは発生するかもしれない。システムがデフォルトの設定に戻ってしまったり、ネットワーク接続が失われてしまったりと、エラーの種類はさまざまだ。システムが完全に停止してしまうこともある。

　リア氏は次のように振り返る。「障害対応が必要になったことが2回あった。障害対応がうまくいかないリスクは常にあり、その恐れは常に心の奥底にある。『システムA』で機能したからといって『システムB』でも機能するとは限らない。二重化した冗長システムを用意してもその点は変わらない。一方のシステムにパッチを適用してそれが機能したとしても、もう一方のシステムに同じパッチを適用すると何らかの不可解な理由でうまくいかないことがある」

　こうした場合に、事業継続計画と災害復旧計画をドキュメント化して更新してきた時間が生きてくる。災害復旧計画は、システムの詳細を更新する必要がある。その際、システム構成だけでなくバージョンも含める。「システムが12カ月前と同じであることは決してない。『これがシステムの現状だ』と記載している箇所は常に更新する必要がある」とリア氏は話す。

　複数のスナップショットのカタログを用意しておけば、問題発生時にシステムの最後の「適切な」構成にロールバックするだけで済む可能性がある。

　システムには潜在的なリスクがあることから、システムが安定していることを確信するためにロールバックを複数回繰り返す必要があるかもしれない。「ロールバックは簡単なものではない。既知の最後の適切な構成が3年前のものだったら、その3年間の作業は失われてしまう」（ギレスピー氏）

　ビジネスプラクティスにライフサイクル管理を組み込んでいると、システムの維持に利用できる時間とリソースを適切に確保できる。その結果、予定外のダウンタイムが減り、5年単位のアップグレードの予算が確保される。

　「パッチ管理はIT部門だけの問題ではない。業務上のコミュニケーションや業務上の変更プログラムの一環として管理する必要がある業務上の問題だ」（ギレスピー氏）