運用業務に限らず、過去にうまくいった手順を利用することは多くあると思います。しかし、最近「その手順が必ずしもうまくいくとは限らない」というツラい経験をしたので、皆様にも共有したく記事にしました。

この記事を読んで、どうか一人でも私と同じ罠にハマってツラい思いをしないことを祈ります。
今回の画像は過去の実績をイメージしました。

▼サーバ再構築をすることになった

私が所属するチームで運営しているアプリケーションは本番環境に脆弱な箇所がないか、第三者機関から定期的な脆弱性診断を実施しています。

脆弱性診断の内容は多岐に渡り、お客様に提供しているWEBサービスのサーバについてはもちろん診断をするのですが、
運用者が利用している監視ツールや運用ツールのサーバについても脆弱性が存在していないかチェックを実施します。

その中で私が所属する運用チームで利用している監視ツール(Zabbix)のバージョンが古く、脆弱性があることが指摘されました。

このサーバは外部ネットワークには公開していないため、外部から直接攻撃をされる可能性は極めて低いのですが、脆弱性のリスクを抱えたままで運用しているのも良くないということで、Zabbixサーバのリプレイスが計画されました。

▼過去実績がある手順だから

脆弱性が発覚したZabbixのバージョンがAであり、バージョンアップ後はバージョンBにしようと決まったのですが、
実はこの手順、過去別サーバでバージョンも含め全く同じ作業を実施しておりました。

過去に実施した際は事前調査もあり結構手間取ったようですが、その時の手順も残っているため、今回はすんなり作業できるはず！とPMから判断され、突貫工事なスケジュールでリプレイス作業に挑むことになりました。

「PMがそう判断したのだからその方針でいこう」と安易に信じてしまった私にも原因があるのですが、この時は知るよしもありませんでした。。

▼やり始めたらうまくいかなかった

しかし、実際には同じ手順での作業はできず、想定よりも非常に多くの時間を費やすことになってしまいました。

そのような状態になった理由は、ありがちな「手順がそもそも間違っていた」や「詳細な箇所の記載が記録されていなかった」ではありません。

なぜだと思いますか？

正解は、
手順を実行する「本番環境の制約が変わったから」です。

実は、この過去実績がある手順ですが、2年前に実施されたものでした。

その当時、私の担当しているプロダクトはまだセキュリティに関する対策を開始し始めた頃で、そこまで制約が多くなかったのですが、

作業当時社外でのセキュリティ事故(個人情報漏洩等)のニュースなどを受け、本番環境の制約が厳しくなっていたのでした。

○内部犯行による個人情報流出事例

▼本番環境の制約内容

本番環境での制約が具体的にどういったものであったかというと、
運用者が利用する内部セグメントに属するサーバから外部サーバへの接続について、

2年前は「接続したことが記録され、業務に必要な接続だったかどうかの確認がされる」というものだったのに対し、

この作業を始めた時点では「許可された接続先のみしか接続できない」のように外部接続先がホワイトリスト方式に移行しておりました。

このホワイトリストには通常の日次運用時に利用される接続先のみしか登録されておらず、私が担当したサーバ構築作業で利用されるURLが登録されておりませんでした。

▼泥沼作業の日々

上記のような制約がされていたため、Zabbixサーバ構築手順にあったyumコマンドによるインストールがファイアウォールで拒否され、手順どおりの作業ができない状態となりました。

ホワイトリストの制約を外すにも許可をとるためには時間がかかるため、作業スケジュールを考えるとその時間がとれません。
そういったことを考えている間にも外部機関の脆弱性再診断の日付は迫ってきます。

そのためとった対策は、
ローカル環境にVMで同じOSをインストールし、
そこでyum install --downloadonlyでダウンロードしたモジュールを片っ端から本番環境に運搬しインストール。

問題が出たら次はそのモジュールを再度ローカル環境でダウンロードして運搬、、を無限に繰り返す泥沼作業をするはめになりました。

結果、残業だらけの日々を抜けてなんとかサーバリプレイスは完了しましたが、「もう二度とやりたくない作業の一つ」として私の記憶に刻まれたのでした。

▼教訓

今回の経験から、私は下記を教訓として学びました。

1. 実績のある手順だからといって安易に信用せず、その作業をした時と今で環境が変わっていないかを注意深く確認しよう。

2. ネットワークに制約を入れる作業は日次作業をしてOKとするだけでなく、必要な際に実施される作業(サーバ構築作業など)にも影響を与えないよう考慮を忘れないようにしよう

3. マネジメント側が「○○するだけ」と安易に考える作業は、大体何かしら落とし穴があるので、安心せず自身でリスク分析を実施しよう。
   作業をするのはマネジメントではなくアナタなのだから。
   

上記に気をつければ、今よりも少しだけスマートな運用業務が実施できるはずです。運用業務以外でも同じようなハマりどころはあると思いますので、運用作業をされていない皆様も、自身の作業に置き換えて教訓としていただければ幸いです。

皆様の失敗から学んだ教訓があれば、是非シェアをお願いします。

それでは今日はこのへんで♪