【第６回（最終回）】社内インフラエンジニアのために（クローズ）

前回：【第５回】社内インフラエンジニアのために（見直し）
お疲れ様です。
しらせです。

『社内インフラエンジニアのために』
第6回目となる今回は最後のフェーズ「クローズ」についてです。

ライフサイクルの進行とともに稼働しているシステムに最期がやってきます。
前回の「見直し」による移行・切り替え・撤退いずれにしても、今稼働している環境（以下、現環境）はいつかクローズになります。

システムは電源操作１つで簡単に止まりますが会社やその業務は止まりません。
万が一、1人でも使っている人がいればその人の業務ができなくなります。
リリース時と同様に細心の注意が必要です。

今回が『社内インフラエンジニアのために』の最後になります。
後半にまとめを入れています。

もくじ

クローズ計画

方針として、システムのリプレースや切り替えを含む場合には「移行計画」を作成して現環境と新しい環境（以下、新環境）を安全にスイッチさせる必要があります。
新環境の利用開始ももちろん重要ですが、現環境を全て停止して安全にクローズ状態に持っていく事も重要です。

特に重要なのが利用状況の把握と連携システムへの調整です。
1人でも使っている人がいれば個別に連絡して利用停止を促す必要があります。
グループウェアなどの場合は他のシステムと深く連携していることも多いため、関連するシステムの担当者やベンダーとクローズに関して事前に十分認識合わせを行います。

停止作業から漏れたサーバはゾンビ化して稼働しつづけたり、通信許可制御（ACL等）をそのままにするとセキュリティリスクになります。
停止作業当日は手順に沿って粛々と対応しつつ、作業漏れがないことや他システムへの影響がないこと十分を確認します。

以下、大まかなクローズに関する手続きをまとめてみました。

例

1. クローズ計画
   
   1. スケジュール
   2. 保持期間
   3. 体制図
   4. 停止方法
   5. 廃棄方法
2. 事前作業
   
   1. 全体周知
   2. サポートデスク連携
   3. 利用状況確認
   4. 連携システム調整
   5. 当日停止手順
3. 当日作業
   
   1. 作業前周知
   2. 停止作業
   3. 作業完了周知
4. 後日作業
   
   1. 廃棄手続き
   2. 解約手続き
   3. 設定解除・廃棄

まとめ

今回は比較的大規模な導入でよく利用されるウォーターフォールモデルに基づいて説明させていただきました。

もちろん、まずは小規模で導入してから細かいところを後で詰めていくというスモールスタートのやり方も十分有用です。
とは言え、スモールに始めて途中で不要になったからといって使わなくなるとそれはそれで怒られます。

私自身もこちらの方が手っ取り早くて好きです。
（時間があればこちらも試してまとめていきたいと思います。

最後に、
日々新しいサービスやシステムが続々と世に出されている現在において、沢山の技術に触れてみたいというのはエンジニアとしての本心です。
しかし、ITインフラは導入する種類や規模によらず必ずコストが掛かります。

「コストを意識した会社への責任」＜＝＞「いろいろ試してみたいエンジニアとしての興味」

この両者のバランスをうまく取りながら楽しくエンジニアリングできるような仕事に繋げられたら最高じゃないですか？
ひとり情シスやゼロ情シスが話題にあがる昨今、少しでも社内インフラエンジニアの参考にして頂けたら幸いです。

今回のシリーズ全体をまとめた図は以下の通りです。

全体図

最後まで読んで頂きありがとうございました。

以上
お疲れ様でした。