障害を防ぐインフラ設定変更の基本手順～検証・手順書・切り戻しまで実践解説～

設定変更が必要となった理由や、求める結果の確認を行います。内容によっては、設定変更が不要の場合もあります。本当に設定変更が必要か？ということを確認する視点も重要です。

設定変更が必要となった場合は、事前の動作確認を行います。

事前検証で本番環境へ影響を与えてしまっては大変です。動作確認は可能な限り検証環境を用意して行いましょう。状況によっては、本番環境を直接変更するケースもあるかもしれません。思わぬ結果を招く可能性があるので、可能な限り検証環境で事前の検証を行いましょう。

事前検証で問題なく変更できることを確認したら、本番作業手順書を作成します。当日は、コピー＆ペーストだけで作業できるレベルで手順書を作成しておくと安心できます。

本番作業日程が決まり、作業手順書が作成できたら本番作業に臨みます。

作業日程の考え方は様々です。お客様の影響を最小限にとどめるために夜間作業を行う。もしもの時を考えて、体制が充実している日中帯に行う。作業内容と提供しているサービスの特性を踏まえて決めると良いと思います。

最近では、検証環境で設定変更を行い、検証環境と本番環境を丸ごと入れ替える「ブルーグリーン・デプロイメント」のような方法も増えています。

設定変更作業にお困りだったお客様事例を一つご紹介します。

キュレーションサイトを運営中のB社様。社内でインフラに詳しい方がインフラ担当者として対応していました。その方の退職に伴い、インフラがブラックボックス化。そんな中、CMSを最新化する必要性が発生したため、PHPのバージョンアップが必要となりました。

一旦は社内で対応しようとしましたが、対応するのが難しそうなので弊社へご相談いただきました。

弊社エンジニアが環境の調査をしたところ、既存環境のバージョンアップを行うと、他の機能に影響が出てしまうことが判明しました。

B社様と相談のうえ、新規サーバーを構築し、最新バージョンのPHPを導入することで対応しました。

設定変更を行う場合は、対象箇所以外にも、全体を把握していないと思わぬ副作用が出ることがあります。変更することで発生する影響はどこまで及ぶか？という視点ももって対応していきましょう。